Nortel Networks Switch 2000 User Manual

Mediant™ 2000 & TP-1610 SIP  
User’s Manual  
Version 4.4  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
Contents  
Table of Contents  
Version 4.4  
3
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Mediant 2000 SIP User’s Manual  
4
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
Contents  
Version 4.4  
5
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Mediant 2000 SIP User’s Manual  
6
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
Contents  
Version 4.4  
7
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
List of Figures  
Mediant 2000 SIP User’s Manual  
8
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
Contents  
Version 4.4  
9
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
List of Tables  
Mediant 2000 SIP User’s Manual  
10  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
Contents  
Version 4.4  
11  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Tip:  
When viewing this manual on CD, Web site or on any other electronic copy,  
all cross-references are hyperlinked. Click on the page or section numbers  
(shown in blue) to reach the individual cross-referenced item directly. To  
return back to the point from where you accessed the cross-reference, press  
the ALT and keys.  
Note:  
This User’s Manual describes the Mediant 2000 SIP media gateway and the  
the TP-1610 SIP board.  
Trademarks  
AC logo, Ardito, AudioCoded, AudioCodes, AudioCodes logo, IPmedia, Mediant, MediaPack, MP-  
MLQ, NetCoder, Stretto, TrunkPack, VoicePacketizer and VoIPerfect, are trademarks or  
registered trademarks of AudioCodes Limited. All other products or trademarks are property of  
their respective owners.  
Customer Support  
Customer technical support and service are provided by AudioCodes’ Distributors, Partners, and  
Resellers from whom the product was purchased. For Customer support for products purchased  
directly from AudioCodes, contact [email protected].  
Abbreviations and Terminology  
Each abbreviation, unless widely used, is spelled out in full when first used. Only industry-  
standard terms are used throughout this manual. Hexadecimal notation is indicated by 0x  
preceding the number.  
Related Documentation  
Document #  
Manual Name  
LTRT-690xx (e.g., LTRT-69001)  
LTRT-701xx  
Mediant 2000 SIP Release Notes  
Mediant 2000 Fast Track Installation Guide  
Warning:  
The Mediant 2000 is supplied as a sealed unit and must only be  
serviced by qualified service personnel.  
Note:  
Where “network” appears in this manual, it means Local Area Network (LAN),  
Wide Area Network (WAN), etc. accessed via the gateway’s Ethernet  
interface.  
Mediant 2000 SIP User’s Manual  
12  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
1. Overview  
1 Overview  
The Mediant 2000 SIP Voice over IP (VoIP) gateway enables voice, fax, and data traffic to be sent  
over the same IP network. The Mediant 2000 provides excellent voice quality and optimized  
packet voice streaming over IP networks.  
The Mediant 2000 uses the award-winning, field-proven Digital Signal Processing (DSP) voice  
compression technology used in other TrunkPackTM series products.  
The Mediant 2000 incorporates 1, 2, 4, 8 or 16 E1 or T1 spans for connection, directly to Public  
Switched Telephone Network (PSTN) / Private Branch Exchange (PBX) telephony trunks, and  
includes one or two 10/100 Base-TX Ethernet ports for connection to the network.  
The Mediant 2000 supports up to 480 simultaneous VoIP or Fax over IP (FoIP) calls, supporting  
various Integrated Services Digital Network (ISDN) Primary Rate Interface (PRI) protocols such  
as EuroISDN, North American NI2, Lucent™ 4/5ESS, NortelDMS100 and others. In addition, it  
supports different variants of Channel Associated Signaling (CAS) protocols for E1 and T1 spans,  
including MFC R2, E&M immediate start, E&M delay dial/start, loop start and ground start.  
The Mediant 2000 gateway, best suited for large and medium-sized VoIP applications, is a  
compact device, comprising a 19-inch 1U chassis with optional dual AC or single DC power  
supplies.  
The deployment architecture can include several Mediant 2000 gateways in branch or  
departmental offices, connected to local PBXs. Call routing is performed by the gateways  
themselves or by SIP Proxy(s).  
The Mediant 2000 gateway enables Users to make low cost long distance or international  
telephone/fax calls between distributed company offices, using their existing telephones/fax.  
These calls are routed over the existing network ensuring that voice traffic uses minimum  
bandwidth.  
The Mediant 2000 can also route calls over the network using SIP signaling protocol, enabling the  
deployment of "Voice over Packet" solutions in environments where access is enabled to PSTN  
subscribers by using a trunking media gateway. This provides the ability to transmit voice and  
telephony signals between a packet network and a TDM network. Routing of the calls from the  
PSTN to a SIP service node (e.g., Call Center) is performed by the Mediant 2000 internal routing  
feature or by a SIP Proxy.  
Version 4.4  
13  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Figure 1-1 below illustrates typical Mediant 2000 gateway applications over VoIP Network.  
Figure 1-1: Typical Mediant 2000 Gateway Application  
Telephone  
PSTN  
E1/T1 PRI/CAS  
Mediant 2000  
SIP Proxy  
Router  
LAN  
Router  
LAN  
SIP  
Service  
Node  
IPNetwork  
Mediant 2000  
Mediant 2000  
LAN  
LAN  
Router  
Router  
E1/T1 PRI/CAS  
E1/T1 PRI/CAS  
PBX - Branch A  
PBX - Branch B  
1.1 Available Configurations  
The Mediant 2000 is provided in the following configurations:  
E1 Available Configurations:  
30 Channels on 1 E1 span with gateway-1 only  
60 Channels on 2 E1 spans with gateway-1 only  
120 Channels on 4 E1 spans with gateway-1 only  
240 Channels on 8 E1 spans with gateway-1 only  
480 Channels on 16 E1 spans with gateway-1 and gateway-2  
T1 Available Configurations:  
24 Channels on 1 T1 span with gateway-1 only  
Mediant 2000 SIP User’s Manual  
14  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
1. Overview  
48 Channels on 2 T1 spans with gateway-1 only  
96 Channels on 4 T1 spans with gateway-1 only  
192 Channels on 8 T1 spans with gateway-1 only  
384 Channels on 16 T1 spans with gateway-1 and gateway-2  
1.2 SIP Overview  
SIP is an application-layer control (signaling) protocol used on the Mediant 2000 for creating,  
modifying, and terminating sessions with one or more participants. These sessions can include  
Internet telephone calls, media announcements and conferences.  
SIP invitations are used to create sessions and carry session descriptions that enable participants  
to agree on a set of compatible media types. SIP uses elements called proxy servers to help  
route requests to the user's current location, authenticate and authorize users for services,  
implement provider call-routing policies and provide features to users.  
SIP also provides a registration function that enables users to upload their current locations for  
use by proxy servers. SIP, on the Mediant 2000, complies with the IETF (Internet Engineering  
Task Force) RFC 3261 (refer to http://www.ietf.org).  
1.3 Mediant 2000 Features  
This section provides a high-level overview of some of the many Mediant 2000 supported  
features.  
1.3.1 General Features  
Superior, high quality SIP PSTN gateway for Voice and fax over IP calls.  
Up to 16 E1/T1/J1 digital spans supporting various PRI and CAS protocols.  
Compliant with SIP (RFC 3261).  
Coders include: G.711, G.723.1, G.726, G.729A and NetCoder at 6.4 to 8.8 kbps, negotiable  
per channel.  
T.38 fax with superior performance (handling a round-trip delay of up to nine seconds).  
Echo Canceler with up to 128 msec tail length.  
Silence suppression with Comfort Noise Generation.  
Web management for easy configuration and installation.  
Simple Network Management Protocol (SNMP) and Syslog support.  
Simple Network Time Protocol (SNTP) support, the time-of-day can be obtained from a  
standard SNTP server.  
1.3.2 Hardware Features  
Two 10/100 Base-TX Ethernet interface connections to the network, providing network  
redundancy.  
Compact, rugged 19-inch rack mount unit, one U high (1.75" or 44.5 mm), with two  
compactPCI(cPCI) slots.  
Optional cPCI slot for third-party CPU board.  
TP-1610/H.323 hot-swap cPCI board.  
Optional dual redundant AC or a single DC power supply.  
Version 4.4  
15  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
1.3.3 PSTN-to-SIP Interworking  
The Mediant 2000 gateway performs interworking between ISDN and CAS via E1/T1/J1 digital  
spans and SIP IETF signaling protocol. 16 E1, T1 or J1 spans are supported (480 channels) in a  
two modules gateway.  
The Mediant 2000 gateway supports various ISDN PRI protocols such as EuroISDN, North  
American NI2, Lucent 4/5ESS, Nortel DMS100, Meridian 1 DMS100, Japan J1, as well as QSIG  
(basic call). PRI support includes User Termination or Network Termination side. ISDN-PRI  
protocols can be defined on an E1/T1 basis (i.e., different variants of PRI are allowed on different  
E1/T1 spans).  
In addition, it supports numerous variants of CAS protocols for E1 and T1 spans, including MFC  
R2, E&M wink start, E&M immediate start, E&M delay dial/start, loop-start, and ground start. CAS  
protocols can be defined on an E1/T1 basis (i.e., different variants of CAS are allowed on  
different E1/T1 spans).  
PSTN to SIP and SIP to PSTN Called number can be optionally modified according to rules that  
are defined in gateway ini file.  
1.3.3.1 Supported Interworking Features  
Definition and use of Trunk Groups for routing IPPSTN calls.  
B-channel negotiation for PRI spans.  
ISDN Non Facility Associated Signaling (NFAS).  
PRI to SIP interworking according to draft-ietf-sipping-qsig2sip-04.txt.  
PRI to SIP Interworking of Q.931 Display (Calling name) information element.  
PRI (NI-2) to SIP interworking of Calling Name using Facility IE in Setup and Facility  
messages.  
Configuration of Numbering Plan and Type for IPISDN calls  
Interworking of PSTN to SIP release causes  
Interworking of ISDN redirect number to SIP diversion header (according to IETF draft-levy-  
sip-diversion-05.txt).  
Optional change of redirect number to called number for ISDNIP calls.  
Interworking of ISDN calling line Presentation & Screening indicators using RPID header  
<draft-ietf-sip-privacy-04.txt>.  
Interworking of Q.931 Called and Calling Number Type and Number Plan values using the  
RPID header.  
Supports ISDN en-block or overlap dialing for incoming TelIP calls.  
Supports routing of IPTel calls to predefined trunk groups.  
Supports a configurable channel select mode per trunk group.  
Supports various number manipulation rules for IPTel and TelIP, called and calling  
numbers.  
Option to configure ISDN Transfer Capability (per Gateway).  
1.3.4 Supported SIP Features  
The Mediant 2000 SIP main features are:  
Reliable User Datagram Protocol (UDP) transport, with retransmissions.  
T.38 real time fax (using SIP).  
Note: If the remote side includes the fax maximum rate parameter in the SDP body of the  
Invite message, the gateway returns the same rate in the response SDP.  
Mediant 2000 SIP User’s Manual  
16  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
1. Overview  
Works with Proxy or without Proxy, using an internal routing table.  
Fallback to internal routing table if Proxy is not responding.  
Supports up to four Proxy servers. If the primary Proxy fails, the Mediant 2000 automatically  
switches to a redundant Proxy.  
Supports Proxy server discovery using Domain Name Server (DNS) SRV records.  
Proxy and Registrar Authentication (handling 401 and 407 responses) using Basic or Digest  
methods.  
Supported methods: INVITE, CANCEL, BYE, ACK, REGISTER, OPTIONS, INFO, REFER,  
UPDATE, NOTIFY, PRACK and SUBSCRIBE.  
Modifying connection parameters for an already established call (re-INVITE).  
Working with a Redirect server and handling 3xx responses.  
Early Media (supporting 183 Session Progress).  
PRACK reliable provisional responses <RFC 3262>.  
Call Hold and Transfer Supplementary services using REFER, Refer-To, Referred-By,  
Replaces and NOTIFY messages.  
Supports RFC 3327 – Adding “Path” to Supported header.  
Supports RFC 3581 – Symmetric Response Routing.  
Session Timer <draft-ietf-sip-session-timer-10.txt>.  
RFC 2833 Relay for Dual Tone Multi Frequency (DTMF) digits, including payload type  
negotiation.  
DTMF out-of-band transfer using:  
INFO method <draft-choudhuri-sip-info-digit-00.txt>  
INFO method, compatible with Cisco gateways  
NOTIFY method <draft-mahy-sipping-signaled-digits-01.txt>.DTMF out-of-band transfer  
using INFO method (draft-choudhuri-sip-info-digit-00.txt)  
Can negotiate coder from a list of given coders.  
Supported coders:  
G.711 A-law 64 kbps  
G.711 µ-law 64 kbps  
G.723.1 5.3, 6.3 kbps  
G.726 32 kbps  
(10, 20, 30, 40, 50, 60, 80, 100, 120 msec)  
(10, 20, 30, 40, 50, 60, 80, 100, 120 msec)  
(30, 60, 90, 120 msec)  
(10, 20, 30, 40, 50, 60, 80, 100, 120 msec)  
(10, 20, 30, 40, 50, 60, 80, 100 msec)  
G.729A 8 kbps  
G.729B is supported if Silence Suppression is enabled.  
NetCoder 6.4, 7.2, 8.0 and 8.8 kbps(20, 40, 60, 80, 100, 120 msec).  
EVRC* 8, 4, 1 kbps  
AMR* 4.75, 5.15, 5.90, 6.70, 7.40, 7.95, 10.2, 12.2 kbps  
Transparent (20, 40, 60, 80, 100, 120 msec)  
(20, 40, 60, 80, 100, 120 msec)  
(20 msec)  
* When EVRC (Enhanced Variable Rate Codec) and AMR (Adaptive Multi-Rate) are used, the  
number of available gateway channels is reduced (refer to the documentation of the parameter  
’CoderName’ in Table 6-3).  
For more updated information on the gateway’s supported features, refer to the latest Mediant  
2000 & TP-1610 SIP Release Notes.  
Version 4.4  
17  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
18  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
2. Mediant 2000 Physical Description  
2 Mediant 2000 Physical Description  
This section provides detailed information on the Mediant 2000 hardware components, the  
location and functionality of the LEDs, buttons and connectors on the front and rear panels.  
2.1 General  
The Mediant 2000 gateway comprises the following hardware components:  
A 19-inch 1U high rack mount chassis (refer to Section 2.2 on page 20).  
A single compactPCI™ TP-1610 board (refer to Section 2.3 on page 20).  
A single TP-1610 Rear Transition Module (RTM) (refer to Section 2.4 on page 24).  
A single available cPCI slot for an optional third-party CPU board (refer to Section 2.5 on  
page 25).  
Figure 2-1 shows the front view of the Mediant 2000 media gateway.  
Figure 2-1: Mediant 2000 Front View  
3
4
11  
1
7
9
6
10  
2
5
8
6
Table 2-1: Mediant 2000 Front View Component Descriptions  
Item #  
Label  
Component Description  
Dual AC Power LED.  
1
2
FAULT  
cPCI board locking screws.  
cPCI latches.  
3
4
TP-1610 cPCI board, 16-trunk configuration.  
Status LED Indicators.  
5
6
T1/E1 STATUS  
ETH  
E1/T1 Trunk Status LED Indicators.  
Ethernet LED Indicators.  
Reset button.  
7
8
9
cPCI LED Indicators.  
10  
11  
Power and Fan LEDs  
An available cPCI slot for an optional third-party CPU board.  
Version 4.4  
19  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
2.2 The Mediant 2000 Chassis  
The Mediant 2000 chassis is an industrial platform, 19” wide, 1U high and 12” deep that houses  
the TP-1610 board in its front cage, slot #1 (the lower slot) and the TP-1610 RTM in its rear cage,  
slot #1 (the lower slot).  
Slot # 2 in the Mediant 2000 chassis’ front and rear cages can optionally be used by customers  
for a CPU board.  
Refer to Table 2-2 for detailed description of the chassis’ LED indicators.  
Table 2-2: Chassis LED Indicators  
Location  
Color  
Function  
The power is on.  
Right side of front panel  
Green  
Fan failure - indicates that any of the internal fans has significantly  
reduced its speed or has frozen.  
Right side of front panel  
Left side of front panel  
Red  
Red  
Power supply failure - indicates that one of the two AC redundant  
power supplies is faulty or disconnected from the AC/mains outlet.  
(This LED is only relevant for the dual AC power supply).  
2.2.1 Power Supply  
The Mediant 2000 power supply is available in three configuration options:  
Single universal 100-240 VAC 1 A max, 50-60 Hz.  
Dual-redundant 100-240 VAC 1.5 A max, 50-60 Hz.  
-48 VDC power supply suitable for field wiring applications.  
2.3 The TP-1610 Board  
The Mediant 2000 is populated by a single compactPCI™ board, the TP-1610 (shown in Figure  
2-2). The TP-1610 is a high-density, hot-swappable, cPCI resource board with a capacity of up to  
480 ports, supporting all necessary functions for voice, data and fax streaming over IP networks.  
The TP-1610 is composed of one or two identical media gateways modules: Gateway-1 and  
Gateway-2, each containing 240 DSP channels. These media gateways are fully independent,  
each gateway having its own MAC (Media Access Control) and IP addresses and LED indicators.  
The TP-1610 board is supplied with a rear I/O configuration in which both PSTN trunks and  
Ethernet interface are located on a passive rear I/O module (for information on the RTM, refer to  
Section 2.4 on page 24).  
Mediant 2000 SIP User’s Manual  
20  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
2. Mediant 2000 Physical Description  
Figure 2-2: Front and Upper View of the TP-1610 cPCI Board  
4
2
3
1
7
6
5
Table 2-3: Front and Upper View of the TP-1610 cPCI Board Component Descriptions  
Item #  
Label  
Component Description  
1
2
3
4
5
6
7
Status LEDs  
Ethernet LEDs  
Reset button  
cPCI LEDs  
ETH  
cPCI Latch  
T1 / E1 STATUS  
T1 / E1 STATUS  
T1/E1 Trunk Status LEDs (for each of trunks 1 to 8)  
T1/E1 Trunk Status LEDs (for each of trunks 9 to 16)  
2.3.1 Board Hot-Swap Support  
The TP-1610 cPCI board is hot-swappable and can therefore be removed from a slot (and  
inserted into a slot) while the Mediant 2000 is under power. It is recommended though that you  
power down the chassis and read the notes below before replacing the components.  
For details on removing/inserting the optional CPU board, refer to the directions accompanying it.  
Electrical Component Sensitivity  
Electronic components on printed circuit boards are extremely sensitive to static  
electricity. Normal amounts of static electricity generated by clothing can damage  
electronic equipment. To reduce the risk of damage due to electrostatic discharge when  
installing or servicing electronic equipment, it is recommended that anti-static earthing  
straps and mats be used.  
Version 4.4  
21  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Note 1: Before removing or inserting boards from / to the chassis, attach a wrist strap  
for electrostatic discharge (ESD) and connect it to the rack frame using an  
alligator clip.  
Note 2: Do not set components down without protecting them with a static bag.  
2.3.1.1 Removing Boards  
To remove the TP-1610 board from the chassis, take these 3 steps:  
1. Unfasten the screws on the plate of the board.  
2. Press the red ejector buttons on the two black ejector/injector latches on both ends and wait  
for the hot-swap blue LED to light, indicating that the board can be removed.  
3. Pull on the two ejector/injector latches and ease out the board from the slot.  
To remove the TP-1610 RTM from the chassis, take these 4 steps:  
1. Remove the cables attached to the RTM.  
2. Unfasten the screws on the brackets at both ends of the panel that secure the RTM to the  
chassis.  
3. Press the red ejector buttons on the two black ejector/injector latches on both ends.  
4. Grasp the panel and ease the RTM board out of the slot.  
2.3.1.2 Inserting Boards  
To insert the TP-1610 board into the chassis, take these 6 steps:  
1. Hold the board horizontally.  
2. With the black ejector/injector latches in the open (pulled out) position, insert the board in the  
slot, aligning the board with the grooves on each end.  
3. Ease the board all the way into the slot until the ejector/injector latches touch the chassis.  
The Blue hot-swap LED is lit.  
4. Press the two black ejector/injector latches on both ends inward, toward the middle, until you  
hear a click.  
5. Wait for the hot-swap blue LED to turn off.  
6. Fasten the screws on the front panel of the board to secure the board to the chassis and to  
ensure that the board has a chassis earthing connection.  
To insert the TP-1610 RTM into the chassis, take these 6 steps:  
1. Hold the board horizontally.  
2. With the black ejector/injector latches in the open (pulled out) position, insert the board in the  
slot, aligning the board with the grooves on each end.  
3. Ease the board all the way into the slot until the ejector/injector latches touch the chassis.  
4. Press the two black ejector/injector latches on both ends inward, toward the middle until you  
hear a click.  
5. Fasten the screws on the front panel of the board to secure the board to the chassis and to  
ensure that the board has a chassis earthing connection.  
6. Reattach the cables (refer to Section 3.4 on page 30).  
Mediant 2000 SIP User’s Manual  
22  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
2. Mediant 2000 Physical Description  
2.3.2 TP-1610 Front Panel LED Indicators  
The functionality of the front panel LEDs for the TP-1610 is described in the following four tables  
and illustrated in Figure 2-2 on page 21. Note that there is a choice of front panels according to  
the number of channels.  
Table 2-4: Status LED Indicators  
Label  
FAIL  
LED Color  
Red  
LED Function  
Normally OFF; Red indicates gateway failure (fatal error)  
Gateway initialization sequence terminated OK  
N/A  
Green  
Bi-color  
LED  
ACT  
Yellow  
Table 2-5: E1/T1 Trunk Status LED Indicators  
Label  
LED Color  
Signal Description  
Trunk is synchronized (normal operation)  
Loss due to any of the following 4 signals:  
Green  
Red  
Bi-color  
LED  
T1/E1 Status 1 to 8  
and  
T1/E1 Status 9 to 16  
LOS  
LFA  
AIS  
Loss of Signal  
Loss of Frame Alignment  
Alarm Indication Signal (the Blue Alarm)  
Remote Alarm Indication (the Yellow Alarm)  
RAI  
Note:  
On the front panel 16 LEDs are provided for 16-span units and 8 LEDs are  
provided for 1-span, 2-span, 4-span, and 8-span units. In the case of 1-span,  
2-span and 4-span units, the extra LEDs are unused.  
Table 2-6: Ethernet LED Indicators  
Label  
LINK  
ACT  
LED Color  
LED Function  
Green  
Yellow  
Link all OK  
Transmit / receive activity  
Table 2-7: cPCI LED Indicators  
LED Function  
Label  
PWR  
LED Color  
Green  
Power is supplied to the board  
The cPCI board can now be removed.  
The cPCI board was inserted successfully.  
For detailed information on the Swap-Ready LED, refer to Section  
SWAP READY  
Blue  
During correct Mediant 2000 operation, the ACT LED is lit green, the FAIL LED is off. Changing  
of the FAIL LED to red indicates a failure.  
Version 4.4  
23  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
2.4 Rear Transition Module  
The Mediant 2000 RTM includes a PSTN trunks and an Ethernet interfaces.  
The Ethernet interface features dual 10/100 Base-TX, RJ-45 shielded connectors for (an active /  
standby) redundancy scheme providing protection against the event of a failure.  
The PSTN interface is provided with a choice of rear panels (1-span, 2-span, 4-span, 8-span or  
16-span).  
Rear panel with two 50-pin female Telco connectors (DDK 57AE-40500-21D) (shown in Figure  
2-3) is required for a gateway equipped with up to 16 E1/T1 spans. Rear panel with RJ-48c  
connectors (shown in Figure 2-4) is required for a gateway equipped with 1, 2, 4, or 8 E1/T1  
spans. The physical difference between the 1-Span, 2-Span and 4-Span RTMs, and the 8-span  
RTM is that the RJ-48c ports are depopulated correspondingly.  
Figure 2-3: Rear Panel with two 50-pin Connectors for 16 Trunks  
2
3
1
Table 2-8: Rear Panel with two 50-pin Connectors for 16 Trunks Component Descriptions  
Item #  
Label  
Component Description  
1
2
3
ETHERNET  
TRUNKS  
2 Ethernet Ports. 2 RJ-45 network connectors.  
E1/T1 trunks 9 to 16. 50-pin male Telco connector.  
E1/T1 trunks 1 to 8. 50-pin male Telco connector.  
TRUNKS  
Mediant 2000 SIP User’s Manual  
24  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
2. Mediant 2000 Physical Description  
Figure 2-4: Rear Panel with 8 RJ-48c Connectors for 8 Trunks  
2
1
Table 2-9: Rear Panel with 8 RJ-48c Connectors for 8 Trunks Component Descriptions  
Item #  
Label  
Component Description  
1
2
ETHERNET  
TRUNKS  
2 Ethernet Ports. 2 RJ-45 network connectors  
8 E1/T-1 Spans. 8 RJ-48c trunk connectors  
2.5 Optional CPU Board  
The Mediant 2000 provides an optional second cPCI slot that can be optionally used for  
customer’s CPU board. This CPU board can be used for general applications such as a  
Gatekeeper, Softswitch, Application Server or other. The following CPU boards were tested for  
compliancy with the Mediant 2000 chassis:  
Sun™: CP2080 + PMC-233 (Ramix™ disk on board) + Rear Transition Module (RTM).  
Intel™ ZT5515B-1A with 40GB on-board disk plus RTM (ZT4807).  
Version 4.4  
25  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
26  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
3. Installing the Mediant 2000  
3 Installing the Mediant 2000  
This section describes the hardware installation procedures for the Mediant 2000. For information  
on how to start using the gateway, refer to Section 4 on page 35. For detailed information on the  
Mediant 2000 connectors, LEDs and buttons, refer to Section 2 on page 19.  
Caution Electrical Shock  
The equipment must only be installed or serviced by qualified service personnel.  
To install the Mediant 2000, take these 4 steps:  
1. Unpack the Mediant 2000 (refer to Section 3.1 below).  
2. Check the package contents (refer to Section 3.2 below).  
3. Mount the Mediant 2000 (refer to Section 3.3 on page 28).  
4. Cable the Mediant 2000 (refer to Section 3.4 on page 30).  
After powering-up the Mediant 2000, the Ready and LAN LEDs on the front panel turn to green  
(after a self-testing period of about 3 minutes). Any malfunction changes the Ready LED to red  
(refer to Section 2.3.2 on page 23 for details on the Mediant 2000 LEDs).  
When you have completed the above relevant sections you are then ready to start configuring the  
gateway (Section 4 on page 35).  
3.1 Unpacking  
To unpack the Mediant 2000, take these 6 steps:  
1. Open the carton and remove packing materials.  
2. Remove the Mediant 2000 gateway from the carton.  
3. Check that there is no equipment damage.  
4. Check, retain and process any documents.  
5. Notify AudioCodes or your local supplier of any damage or discrepancies.  
6. Retain any diskettes or CDs.  
3.2 Package Contents  
Ensure that in addition to the Mediant 2000, the package contains:  
For the dual AC power supply version two AC power cables are supplied; for the single AC  
power supply version one AC power cable is supplied.  
For the DC power supply version, one connectorized DC power cable (crimp connection  
type) and one DC adaptor (screw connection type) connected to the rear panel of the  
Mediant 2000 are supplied; use only one type.  
CD (software and documentation).  
Small plastic bag containing (refer to Figure 3-1):  
Two brackets and four bracket-to-device screws for 19-inch rack installation option.  
Four anti-slide bumpers for desktop / shelf installation option.  
The Mediant 2000 Fast Track Installation Guide.  
Version 4.4  
27  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Figure 3-1: 19-inch Rack & Desktop Accessories  
3.3 Mounting the Mediant 2000  
The Mediant 2000 can be mounted on a desktop, or installed in a standard 19-inch rack. Refer to  
Section 3.4 on page 30 for cabling the Mediant 2000.  
3.3.1 Mounting the Mediant 2000 on a Desktop  
No brackets are required. Optionally, attach the four (supplied) anti-slide bumpers to the base of  
the Mediant 2000 and place it on the desktop in the position you require.  
3.3.2 Installing the Mediant 2000 in a 19-inch Rack  
Users can install the device in a standard 19-inch rack either by placing the device on a shelf  
preinstalled in the rack (preferred method), or by attaching the device directly to the rack’s frame  
via integral brackets.  
Before rack mounting the chassis, attach the two (supplied) brackets to the front sides of the  
device (refer to Figure 3-2).  
To attach the two front side brackets, take these 3 steps:  
1. Remove the 2 screws nearest the front panel on either side of the device.  
2. Align a bracket over 2 holes on one side (so that the bracket’s larger holes face front) and  
with the 2 supplied replacement screws, screw in the bracket.  
3. Perform the same procedure on the other side.  
Mediant 2000 SIP User’s Manual  
28  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
3. Installing the Mediant 2000  
Figure 3-2: Mediant 2000 Front View with 19-inch Rack Mount Brackets  
Rack Mount Safety Instructions (UL)  
When installing the chassis in a rack, be sure to implement the following Safety  
instructions recommended by Underwriters Laboratories:  
Elevated Operating Ambient - If installed in a closed or multi-unit rack  
assembly, the operating ambient temperature of the rack environment may be  
greater than room ambient. Therefore, consideration should be given to  
installing the equipment in an environment compatible with the maximum  
ambient temperature (Tma) specified by the manufacturer.  
Reduced Air Flow - Installation of the equipment in a rack should be such that  
the amount of air flow required for safe operation on the equipment is not  
compromised.  
Mechanical Loading - Mounting of the equipment in the rack should be such  
that a hazardous condition is not achieved due to uneven mechanical loading.  
Circuit Overloading - Consideration should be given to the connection of the  
equipment to the supply circuit and the effect that overloading of the circuits  
might have on overcurrent protection and supply wiring. Appropriate  
consideration of equipment nameplate ratings should be used when addressing  
this concern.  
Reliable Earthing - Reliable earthing of rack-mounted equipment should be  
maintained. Particular attention should be given to supply connections other  
than direct connections to the branch circuit (e.g., use of power strips.)  
To attach the device to a 19-inch rack, take these 2 steps:  
1. Position the device in your 19-inch rack and align the left-hand and right-hand bracket holes  
to holes (of your choosing) in the vertical tracks of the 19-inch rack.  
2. Use standard 19-inch rack bolts (not provided) to fasten the device to the frame of the rack.  
AudioCodes recommends using two additional (not supplied) rear mounting brackets to provide  
added support.  
Note: Users assembling the rear brackets by themselves should note the following:  
The distance between the screws on each bracket is 26.5 mm.  
To attach the brackets, use 4-40 screws with a maximal box penetration length  
of 3.5 mm.  
To place the device on a 19-inch rack’s shelf, take these 2 steps:  
1. Place the device on the preinstalled shelf.  
Version 4.4  
29  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
2. You’re now recommended to take the optional steps of fastening the device to the frame of  
the rack (as described above) while it is placed on the shelf, so preventing it from sliding  
when inserting cables into connectors on the rear panel.  
3.4 Cabling the Mediant 2000  
Refer to Section 2 on page 19 for detailed information on the Mediant 2000 rear panel connectors  
and LEDs.  
Note that the Mediant 2000 is available in many configurations, i.e., AC or DC, in the 16-trunk, 8-  
trunk, 4-trunk, 2-trunk or 1-trunk device. The 16-trunk dual AC (Figure 3-3) and the 8-trunk DC  
(Figure 3-4) configurations are illustrated here as representative products.  
Figure 3-3: Mediant 2000 Rear Panel Cabling (16 Trunks, Dual AC Power)  
2
3
1
2
1
5
4
Table 3-1: Mediant 2000 Rear Panel Cabling (16 Trunks, Dual AC Power) Component Descriptions  
Item #  
Label  
Component Description  
1
RTM locking screws.  
Two Category 5 network cables, connected to the 2 Ethernet RJ-45  
ports.  
ETHERNET  
TRUNKS  
2
3
4
5
Two 50-pin Telco connector cables, each supporting 8 trunks.  
Protective earthing screw.  
100-240~1.5A  
Dual AC power cables.  
Mediant 2000 SIP User’s Manual  
30  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
3. Installing the Mediant 2000  
Figure 3-4: Mediant 2000 Rear Panel Cabling (8 Trunks, DC Power))  
2
3
1
3
1
5
4
Table 3-2: Mediant 2000 Rear Panel Cabling (8 Trunks, DC Power) Component Descriptions  
Item #  
Label  
Component Description  
1
2
3
4
5
RTM latches.  
ETH  
A Category 5 network cable, connected to the Ethernet 1 RJ-45 port.  
8 RJ-48c ports, each supporting a trunk.  
Protective earthing screw.  
PSTN  
48V 4A max  
2-pin connector for DC.  
Electrical Earthing  
The unit must be permanently connected to earth via the screw provided at the back on  
the unit. Use 14-16 AWG wire and a proper ring terminal for the earthing.  
To cable the Mediant 2000, take these 4 steps:  
1. Permanently connect the device to a suitable earth with the protective earthing screw on the  
rear connector panel, using 14-16 AWG wire.  
2. Connect the E1/T1 trunk interfaces (refer to Section 3.4.1 below).  
3. Install the Ethernet connection (refer to Section 3.4.2 on page 32).  
4. Connect the power supply (refer to Section 3.4.3 on page 33).  
3.4.1 Connecting the E1/T1 Trunk Interfaces  
Connect the Mediant 2000 E1/T1 Trunk Interfaces using either Telco or RJ-48 connectors:  
With 50-pin Telco connectors (16-trunk device), take these 3 steps:  
1. Attach the Trunk cable with a 50-pin male Telco connector to the 50-pin female Telco  
connector labeled “Trunks 18” on the Rear Transition Module (RTM).  
2. Connect the other end of the Trunk cable to the PBX/PSTN switch.  
Version 4.4  
31  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
3. Repeat steps 1 and 2 for the other Trunk cable but this time connect it to the connector  
labeled “Trunks 916”.  
The 50-pin male Telco cable connector must be wired according to the pinout in Table 3-3 below,  
and to mate with the female connector illustrated in Figure 3-5.  
Figure 3-5: 50-pin Female Telco Board-Mounted Connector  
Pin Numbers  
25  
1
26  
50  
Table 3-3: E1/T1 Connections on each 50-pin Telco Connector  
E1/T1 Number  
Tx Pins (Tip/Ring)  
Rx Pins (Tip/Ring)  
1 to 8  
9 to 16  
1
2
3
4
5
6
7
8
9
27/2  
29/4  
26/1  
28/3  
10  
11  
12  
13  
14  
15  
16  
31/6  
30/5  
33/8  
32/7  
35/10  
37/12  
39/14  
41/16  
34/9  
36/11  
38/13  
40/15  
With RJ-48c Connectors, take these 2 steps:  
1. Connect the E1/T1 trunk cables to the ports labeled “Trunks 1 to 8” (in the case of the 8-  
trunk device) on the Mediant 2000 RTM.  
2. Connect the other ends of the Trunk cables to the PBX/PSTN switch.  
RJ-48c trunk connectors are wired according to Figure 3-6 below.  
Figure 3-6: Pinout of RJ-48c Trunk Connectors  
RJ-48c Connector and Pinout  
1 2 3 4 5 6 7 8  
1 = Rx Ring 3, 6, 7, 8  
2 = Rx Tip  
4 = Tx Ring  
5 = Tx Tip  
not connected  
body = shield  
3.4.2 Installing the Ethernet Connection  
Connect a standard Category 5 network cable to the Ethernet RJ-45 port (and the other as  
optional redundancy/backup). Connect the other end of the Category 5 network cables to your IP  
network. The Ethernet connectors (labeled Ethernet 1 and Ethernet 2) are wired according to  
Note that for redundant operation it is recommended to connect each of the Ethernet connectors  
to a different Switch.  
When assigning an IP address to the Mediant 2000 using HTTP (under Step 1 in Section 4.1.1),  
you may be required to disconnect this cable and re-cable it differently.  
Mediant 2000 SIP User’s Manual  
32  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
3. Installing the Mediant 2000  
Figure 3-7: Pinout of RJ-45 Connectors  
RJ-45 LAN Connector and Pinout  
1 2 3 4 5 6 7 8  
1 = Tx+ 4, 5, 7, 8  
2 = Tx-  
3 = Rx+  
6 = Rx-  
not connected  
3.4.3 Connecting the Power Supply  
Connect the Mediant 2000 to the power supply using one of the following methods:  
3.4.3.1 Connecting the AC Power Supply  
When using a single AC power cable:  
Attach one end of the supplied 100/240 VAC power cable to the rear AC socket and connect the  
other end to the correct earthed AC power supply.  
When using a dual AC power cable:  
Attach one end of the supplied 100/240 VAC power cables to the rear AC sockets and connect  
the other end to a separate earthed mains circuits (for power source redundancy).  
Note:  
For the dual AC power supply note the following:  
The LED on the left side of the chassis is only connected when the dual AC is  
used. It is not relevant to the single AC power connection.  
If only a single socket is connected to the AC power, (while the other plug is left  
unconnected) the chassis’ LED (on the left side) is lit Red, indicating that one  
of the dual power inlets is disconnected.  
When both the AC power cables are connected, one of the plugs can be  
disconnected under power without affecting operation, in which case the  
chassis’ left LED is lit Red.  
UPS can be connected to either (or both) of the AC connections.  
The dual AC connections operate in a 1 + 1 configuration and provide load-  
sharing redundancy.  
Each of the dual power cables can be connected to different AC power phases.  
3.4.3.2 Connecting the DC Power Supply  
To connect the Mediant 2000 to a DC power supply use one of these two options:  
DC Terminal block with a screw connection type.  
DC Terminal block with a crimp connection type.  
When using a DC terminal block screw connector, take these 3 steps:  
1. Create a DC cable by inserting two 14-16 AWG insulated wires into the supplied adaptor  
(refer to Figure 3-8) and fasten the two screws, each one located directly above each wire.  
2. Connect the two insulated wires to the correct DC power supply. Ensure that the connections  
to the DC power supply maintain the correct polarity.  
3. Insert the terminal block into the DC inlet located on the Mediant 2000.  
Version 4.4  
33  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
Figure 3-8: DC Terminal Block Screw Connector  
When using a DC terminal block crimp connector, take these 3 steps:  
1. Remove the DC adaptor (screw connection type) that is attached to the Mediant 2000 rear  
panel.  
2. Connect the two insulated wires to the correct DC power supply. Ensure that the connections  
to the DC power supply maintain the correct polarity (refer to Figure 3-9).  
3. Insert the terminal block into the DC inlet located on the Mediant 2000.  
Figure 3-9: DC Terminal Block Crimp Connector  
2 screws for  
connecting the  
crimp terminal  
block to the  
Mediant 2000 rear  
panel  
Mediant 2000 SIP User’s Manual  
34  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
4. Getting Started  
4 Getting Started  
The Mediant 2000 is supplied with application software already resident in its flash memory (with  
factory default parameters).  
Section 4.1 below describes how to assign IP addresses to the Mediant 2000, while Section 4.1.2  
on page 35 describes how to set up the Mediant 2000 with basic parameters using a standard  
Web browser (such as Microsoft TM Internet Explorer).  
For detailed information on how to fully configure the gateway, refer to the Web Interface,  
described in Section 5 on page 39.  
4.1 Assigning the Mediant 2000 IP Address  
The Mediant 2000 is composed of one or two identical media gateway modules. These media  
gateways are fully independent, each gateway having its own MAC and IP addresses (Table 4-1  
shows the default IP addresses of the Mediant 2000). To assign an IP address to each of the  
Mediant 2000 modules use one of the following methods:  
HTTP using a Web browser (refer to Section 4.1.1 below).  
BootP (refer to Section 4.1.2 on page 36).  
Dynamic Host Control Protocol (DHCP) (refer to Section 10.2 on page 169).  
You can use the ‘Reset’ button to restore the Mediant 2000 networking parameters to their factory  
default values (refer to Section 4.2 on page 36).  
Table 4-1: Mediant 2000 Default Networking Parameters  
Mediant 2000 Version  
Default Value  
Single module (up to 8 Trunks)  
Double module (up to 16 Trunks)  
10.1.10.10  
10.1.10.10 (Trunks 1-8) and 10.1.10.11 (Trunks 9-16)  
Default subnet mask is 255.255.0.0, default gateway IP address is 0.0.0.0  
4.1.1 Assigning an IP Address Using HTTP  
To assign an IP address using HTTP, take these 9 steps:  
1. Disconnect the Mediant 2000 from the network and reconnect it to your PC using one of the  
following two methods:  
Use a standard Ethernet cable to connect the network interface on your PC to a port on  
a network hub / switch. Use a second standard Ethernet cable to connect the Mediant  
2000 to another port on the same network hub / switch.  
Use an Ethernet cross-over cable to directly connect the network interface on your PC  
to the Mediant 2000.  
2. Change your PC’s IP address and subnet mask to correspond with the Mediant 2000 factory  
default IP address and subnet mask, shown in Table 4-1. For details on changing the IP  
address and subnet mask of your PC, refer to Windows™ Online Help (Start>Help).  
3. Access the Mediant 2000 first module’s Embedded Web Server (refer to Section 5.6 on page  
41).  
4. In the ‘Quick Setup’ screen (shown in Figure 4-1), set the Mediant 2000 ‘IP Address’,  
‘Subnet Mask’ and ‘Default Gateway IP Address’ fields under ‘IP Configuration’ to  
Version 4.4  
35  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
correspond with your network IP settings. If your network doesn’t feature a default gateway,  
enter a dummy value in the ‘Default Gateway IP Address’ field.  
5. Click the Reset button and click OK in the prompt; The Mediant 2000 applies the changes  
and restarts. This takes approximately 3 minutes to complete. When the Mediant 2000 has  
finished restarting, the Ready and LAN LEDs on the front panel are lit green.  
Tip:  
Record and retain the IP address and subnet mask you assign the Mediant  
2000. Do the same when defining new username or password. If the  
Embedded Web Server is unavailable (for example, if you’ve lost your  
username and password), use the BootP/TFTP (Trivial File Transfer Protocol)  
configuration utility to access the device, “reflash” the load and reset the  
password (refer to Appendix B on page 189 for detailed information on using  
a BootP/TFTP configuration utility to access the device).  
6. Repeat steps 3 to 5 for the Mediant 2000 second module (if used).  
7. Disconnect your PC from the Mediant 2000 or from the hub / switch (depending on the  
connection method you used in step Error! Reference source not found.).  
8. Reconnect the Mediant 2000 and your PC (if necessary) to the network.  
9. Restore your PC’s IP address and subnet mask to what they originally were. If necessary,  
restart your PC and re-access the Mediant 2000 via the Embedded Web Server with its new  
assigned IP address.  
4.1.2 Assigning an IP Address Using BootP  
Note:  
BootP procedure can also be performed using any standard compatible  
BootP server.  
Tip:  
You can also use BootP to load the auxiliary files to the Mediant 2000 (refer  
to Section 6.12.1 on page 132).  
To assign an IP address using BootP, take these 4 steps:  
1. Open the BootP application (supplied with the Mediant 2000 software package).  
2. Add client configuration for the gateway that you want to initialize, refer to Section B.11.1 on  
page 195.  
3. Reset the gateway physically causing it to use BootP; the Mediant 2000 changes its network  
parameters to the values provided by the BootP.  
4. Repeat steps 2 and 3 for the Mediant 2000 second module (if used).  
4.2 Restoring Networking Parameters to their Initial  
State  
You can use the ‘Reset’ button to restore the Mediant 2000 networking parameters to their factory  
default values (described in Table 4-1) and to reset the username and password.  
Note that the Mediant 2000 returns to the software version burned in flash. This process also  
restores the Mediant 2000 parameters to their factory settings, therefore you must load your  
previously backed-up ini file, or the default ini file (received with the software kit) to set them to  
their correct values.  
Mediant 2000 SIP User’s Manual  
36  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
4. Getting Started  
This option is currently supported on one media gateway module (trunks 1-8) only.  
To restore networking parameters to their initial state, take these 6  
steps:  
1. Disconnect the Mediant 2000 from the power and network cables.  
2. Reconnect the power cable; the gateway is powered up. After approximately 45 seconds the  
ACT LED blinks for about 4 seconds.  
3. While the ACT LED is blinking, press shortly on the reset button (located on the front panel);  
the gateway resets a second time and is restored with factory default parameters (username:  
“Admin”, password: “Admin”).  
4. Reconnect the network cable.  
5. Assign the Mediant 2000 IP address (refer to Section 4.1 on page 35).  
6. Load your previously backed-up ini file, or the default ini file (received with the software kit).  
To load the ini file via the Embedded Web Server, refer to Section 5.9.5 on page 69.  
4.3 Configuring the Mediant 2000 Basic Parameters  
To configure the Mediant 2000 basic parameters use the Embedded Web Server’s ‘Quick Setup’  
screen (shown in Figure 4-1 below). Refer to Section 5.6 on page 41 for information on accessing  
the ‘Quick Setup’ screen.  
Figure 4-1: Mediant 2000 Quick Setup Screen  
To configure basic SIP parameters, take these 10 steps:  
1. If the Mediant 2000 is connected to a router with NAT (Network Address Translation)  
enabled, perform the following procedure. If it isn’t, leave the ‘NAT IP Address’ field  
undefined.  
Determine the “public” IP address assigned to the router (by using, for instance, router  
Web management). Enter this public IP address in the ‘NAT IP Address’ field.  
Version 4.4  
37  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
Enable the DMZ (Demilitarized Zone) configuration on the residential router for the LAN  
port where the Mediant 2000 gateway is connected. This enables unknown packets to  
be routed to the DMZ port.  
2. Under ‘SIP Parameters’, enter the Mediant 2000 domain name in the field ‘Gateway Name’.  
If the field is not specified, the Mediant 2000 IP address is used instead (default).  
3. When working with a Proxy server, set ‘Working with Proxy’ field to ‘Yes’ and enter the IP  
address of the primary Proxy server in the field ‘Proxy IP address’. When no Proxy is used,  
the internal routing table is used to route the calls.  
4. Enter the Proxy name in the field ‘Proxy Name’. If Proxy name is used, it replaces the Proxy  
IP address in all SIP messages. This means that messages is still sent to the physical Proxy  
IP address but the SIP URI contains the Proxy name instead.  
5. Configure ‘Enable Registration’ to ‘Yes’ or ‘No’:  
‘No’ = the Mediant 2000 does not register to a Proxy server/Registrar (default).  
‘Yes’ = the Mediant 2000 registers to a Proxy server/Registrar at power up and every  
‘Registration Time’ seconds. For detailed information on the parameter ‘Registration Time’,  
refer to Table 6-3 on page 100.  
6. Select the coder (i.e., vocoder) that best suits your VoIP system requirements. The default  
coder is: G.7231 30 msec. To program the entire list of coders you want the Mediant 2000 to  
use, click the button on the left side of the ‘1st Coder’ field; the drop-down lists for the 2nd to  
5th coders appear. Select coders according to your system requirements. Note that coders  
higher on the list are preferred and take precedence over coders lower on the list.  
Note:  
The preferred coder is the coder that the Mediant 2000 uses as a first choice  
for all connections. If the far end gateway does not use this coder, the  
Mediant 2000 negotiates with the far end gateway to select a coder that both  
sides can use.  
7. To program the Tel to IP Routing Table, press the arrow button next to ‘Tel to IP Routing  
Table’. For information on how to configure the Tel to IP Routing Table, refer to Section  
8. To program the E1/T1 B-channels, press the arrow button next to ‘Trunk Group Table’. For  
information on how to configure the Trunk Group Table, refer to Section 5.8.6 on page 58.  
9. Click the Reset button and click OK in the prompt; The Mediant 2000 applies the changes  
and restarts, taking approximately 3 minutes to complete. When the Mediant 2000 has  
finished restarting, the Ready and LAN LEDs on the front panel are lit green.  
10. After the gateway was reset, access the Advanced Configuration>Trunk Settings page, and  
select the gateway’s E1/T1 protocol type and Framing method that best suits your system  
requirements. Note that for E1 spans, the framing method must always be set to ‘Extended  
Super Frame’. For information on how to configure the Trunk Settings, refer to Section 5.9.3  
on page 66.  
You are now ready to start using the gateway. To prevent unauthorized access to the Mediant  
2000, it is recommended that you change the username and password that are used to access  
the Web Interface. Refer to Section 5.9.7 on page 71 for details on how to change the username  
and password.  
Tip:  
Once the gateway is configured correctly back up your settings by making a  
copy of the VoIP gateway configuration (ini file) and store it in a directory on  
your PC. This saved file can be used to restore configuration settings at a  
future time. For information on backing up and restoring the gateway’s  
configuration, refer to Section 5.9.5 on page 69.  
Mediant 2000 SIP User’s Manual  
38  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
5. Web Management  
5 Web Management  
5.1 Configuration Concepts  
Users can utilize the Mediant 2000 in a wide variety of applications, enabled by its parameters  
and configuration files (e.g., Call Progress Tones (CPT), etc.). The parameters can be configured  
and configuration files can be loaded using:  
A standard Web Browser (described and explained in this section).  
A configuration file referred to as the ini file. For information on how to use the ini file, refer to  
Section 6 on page 87.  
An SNMP browser software (refer to Section 11 on page 171).  
AudioCodes’ Element Management System (EMS) (refer to Section 11.8 on page 182 and to  
AudioCodes’ EMS User’s Manual or EMS Product Description).  
To upgrade the Mediant 2000 (load new software or configuration files onto the gateway) use the  
Software Upgrade wizard, available through the Web Interface (refer to Section 5.11.1 on page  
78), or alternatively use the BootP/TFTP configuration utility (refer to Section 10.3.1 on page  
169).  
For information on the configuration files, refer to Section 7 on page 135.  
5.2 Overview of the Embedded Web Server  
The Embedded Web Server is used both for gateway configuration, including loading of  
configuration files, and for run-time monitoring. The Embedded Web Server can be accessed  
from a standard Web browser, such as Microsoft™ Internet Explorer, Netscape™ Navigator, etc.  
Specifically, Users can employ this facility to set up the gateway configuration parameters. Users  
also have the option to remotely reset the gateway and to permanently apply the new set of  
parameters.  
5.3 Computer Requirements  
To use the Web Interface, the following is needed:  
A computer capable of running your Web browser.  
A network connection to the VoIP gateway.  
One of the following compatible Web browsers:  
Microsoft™ Internet Explorer™ (version 6.0 and higher).  
Netscape™ Navigator™ (version 7.0 and higher).  
Note:  
Some Java-script applications are not supported in Netscape.  
Version 4.4  
39  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
5.4 Password Control  
The Embedded Web Server is protected by a unique username and password combination. The  
first time a browser request is made, the User is requested to provide his username and  
password to obtain access. Subsequent requests are negotiated by the browser on behalf of the  
User, so that the User doesn’t have to re-enter the username and password for each request, but  
the request is still authenticated (the Embedded Web Server uses the MD5 authentication  
method supported by the HTTP 1.1 protocol).  
An additional level of protection is obtained by a restriction that no more than three IP addresses  
can access the Embedded Web Server concurrently. With this approach, a fourth User is told that  
the server is busy, even if the correct username and password were provided.  
5.4.1 Embedded Web Server Username & Password  
The default username and password for all gateways are:  
Username = “Admin” (case-sensitive)  
Password = “Admin” (case-sensitive)  
For details on changing the username and password, refer to Section 5.9.7 on page 71. Note that  
the password and username can be a maximum of 7 case-sensitive characters.  
The User can reset the Web username and password (to the default values) by enabling an ini  
file parameter called ‘ResetWebPassword’. The Web password is automatically the default  
password.  
5.5 Configuring the Web Interface via the ini File  
Two additional security preferences can be configured using ini file parameters. These security  
levels provide protection against unauthorized access (such as Internet hacker attacks),  
particularly to Users without a firewall. For information on the ini file, refer to Section 6 on page  
87.  
5.5.1 Limiting the Embedded Web Server to Read-Only Mode  
Users can limit the Web Interface to read-only mode by changing the ini file parameter  
‘DisableWebConfig’ to 1. In this mode all Web screens are read-only and cannot be modified. In  
addition, the following screens cannot be accessed: ‘Quick Setup’, ‘Change Password’, ’Reset‘,  
‘Save Configuration‘, ‘Software Upgrade Wizard’, ‘Load Auxiliary Files’, ‘Configuration File’ and  
‘Regional Settings’.  
5.5.2 Disabling the Embedded Web Server  
To deny access to the gateway through HTTP protocol, the User can disable the Embedded Web  
Server task. To disable the Web task, use the ini file parameter ‘DisableWebTask = 1’. The  
default is to Web task enabled.  
Mediant 2000 SIP User’s Manual  
40  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.6 Accessing the Embedded Web Server  
To access the Embedded Web Server, take these 4 steps:  
1. Open a standard Web-browsing application such as Microsoft™ Internet Explorer™ (Version  
6.0 and higher) or Netscape™ Navigator™ (Version 7.0 and higher).  
2. In the Uniform Resource Locator (URL) field, specify the IP address of the Mediant 2000  
(e.g., http://10.1.10.10); the Embedded Web Server’s ‘Enter Network Password’ screen  
appears, shown in Figure 5-1.  
Figure 5-1: Embedded Web Server Login Screen  
3. In the ‘User Name’ and ‘Password’ fields, enter the username (default: “Admin”) and  
password (default: “Admin”). Note that the username and password are case-sensitive.  
4. Click the OK button; the ‘Quick Setup’ screen is accessed (shown in Figure 4-1).  
5.6.1 Using Internet Explorer to Access the Embedded Web Server  
Internet explorer’s security settings may block access to the gateway’s Web browser if they’re  
configured incorrectly. In this case, the following message is displayed:  
Unauthorized  
Correct authorization is required for this area. Either your browser does not perform  
authorization or your authorization has failed. RomPager server.  
To troubleshoot blocked access to Internet Explorer, take these 2  
steps:  
1. Delete all cookies from the Temporary Internet files. If this does not clear up the problem, the  
security settings may need to be altered (refer to Step 2).  
2. In Internet Explorer, Tools, Internet Options select the Security tab, and then select Custom  
Level. Scroll down until the Logon options are displayed and change the setting to Prompt  
for username and password and then restart the browser. This fixes any issues related to  
domain use logon policy.  
Version 4.4  
41  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
5.7 Getting Acquainted with the Web Interface  
Figure 5-2 shows the general layout of the Web Interface screen.  
Figure 5-2: Mediant 2000 Web Interface  
Main Menu  
Bar  
MG Module  
Submenu  
Bar  
Title Bar  
Corporate  
Logo  
Main Action  
Frame  
Control  
Protocol  
The Web Interface screen features the following components:  
Title bar - contains three configurable elements: corporate logo, a background image and  
the product’s name. For information on how to modify these elements, refer to Appendix F  
on page 207.  
Main menu bar - always appears on the left of every screen to quickly access parameters,  
submenus, submenu options, functions and operations.  
Submenu bar - appears on the top of screens and contains submenu options.  
Main action frame - the main area of the screen in which information is viewed and  
configured.  
Corporate logo – AudioCodes’ corporate logo. For information on how to remove this logo,  
refer to Appendix F on page 207.  
Control Protocol – the Mediant 2000 control protocol.  
MG Module – the Mediant 2000 media gateway module (Module 1 or Module 2).  
5.7.1 Main Menu Bar  
The main menu bar of the Web Interface is divided into the following 7 menus:  
Quick Setup – Use this menu to configure the gateway’s basic settings; for the full list of  
configurable parameters go directly to ‘Protocol Management’ and ‘Advanced Configuration’  
menus. An example of the Quick Setup configuration is described in Section 4.2 on page 36.  
Protocol Management – Use this menu to configure the gateway’s control protocol  
parameters and tables (refer to Section 5.8 on page 44).  
Mediant 2000 SIP User’s Manual  
42  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
Advanced Configuration – Use this menu to set the gateway’s advanced configuration  
parameters (for advanced users only) (refer to Section 5.9 on page 62).  
Status & Diagnostics – Use this menu to view and monitor the gateway’s channels, Syslog  
messages, hardware / software product information, and to assess the gateway’s statistics  
and IP connectivity information (refer to Section 5.10 on page 71).  
Software Update – Use this menu when you want to load new software or configuration files  
onto the gateway (refer to Section 5.11 on page 78).  
Save Configuration – Use this menu to save configuration changes to the non-volatile flash  
memory (refer to Section 5.12 on page 84).  
Reset – Use this menu to remotely reset the gateway. Note that you can choose to save the  
gateway configuration to flash memory before reset (refer to Section 5.12 on page 84).  
When positioning your curser over a parameter name (or a table) for more than 1 second, a short  
description of this parameter is displayed. Note that those parameters that are preceded with an  
exclamation mark (!) are Not changeable on-the-fly and require reset.  
5.7.2 Saving Changes  
To save changes to the volatile memory (RAM) press the Submit button (changes to parameters  
with on-the-fly capabilities are immediately available, other parameter are updated only after a  
gateway reset). Parameters that are only saved to the volatile memory revert to their previous  
settings after hardware reset. When performing a software reset (i.e., via Web or SNMP) you can  
choose to save the changes to the non-volatile memory. To save changes so they are available  
after a power fail, you must save the changes to the non-volatile memory (flash). When Save  
Configuration is performed, all parameters are saved to the flash memory.  
To save the changes to flash, take these 2 steps:  
1. Click the Save Configuration button; the ‘Save Configuration to Flash Memory’ screen  
appears.  
2. Click the Save Configuration button in the middle of the screen; a confirmation message  
appears when the save is complete.  
Note: When you reset the Mediant 2000 from the Web Interface, you can choose to save the  
configuration to flash memory.  
5.7.3 Entering Phone Numbers in Various Tables  
Phone numbers entered into various tables on the gateway, such as the Tel to IP routing table,  
must be entered without any formatting characters. For example, if you wish to enter the phone  
number 555-1212, it must be entered as 5551212 without the hyphen (-). If the hyphen is entered,  
the entry does not work. The hyphen character is used in number entry only, as part of a range  
definition. For example, the entry [20-29] means “all numbers in the range 20 to 29”.  
Version 4.4  
43  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.8 Protocol Management  
Use this menu to configure the gateway’s SIP parameters and tables.  
5.8.1 Protocol Definition Parameters  
Use this submenu to configure the following gateway’s specific SIP protocol parameters:  
General Parameters  
Proxy & Registration Parameters  
Coders (refer to Section 5.8.1.1 below)  
DTMF & Dialing Parameters  
5.8.1.1 Coders  
From the Coders screen you can configure the first to fifth preferred coders (and their  
corresponding ptimes) for the gateway. The first coder is the highest priority coder and is used by  
the gateway whenever possible. If the far end gateway cannot use the coder assigned as the first  
coder, the gateway attempts to use the next coder and so forth.  
To configure the gateway’s coders, take these 6 steps:  
1. Open the ‘Coders’ screen (Protocol Management menu > Protocol Definition submenu >  
Coders option); the ‘Coders’ screen is displayed.  
Figure 5-3: Coders Screen  
2. From the coder drop-down list, select the coder you want to use. For the full list of available  
coders and their corresponding ptimes, refer to the ini file parameter ‘CoderName’  
(described in Table 6-3).  
Note: Each coder can appear only once.  
3. From the drop-down list to the right of the coder list, select the size of the Voice Packet  
(ptime) used with this coder in milliseconds. Selecting the size of the packet determines how  
many coder payloads are combined into one RTP (Real-Time Transport Protocol) (voice)  
packet.  
Note 1: The ptime packetization period depends on the selected coder name.  
Note 2: If not specified, the ptime gets a default value.  
Note 3: The ptime specifies the maximum packetization time the gateway can receive.  
4. Repeat steps 2 and 3 for the second to fifth coders (optional).  
5. Click the Submit button to save your changes.  
6. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Note:  
Only the ptime of the first coder in the defined coder list is declared in  
Invite/200 OK SDP, even if multiple coders are defined.  
Mediant 2000 SIP User’s Manual  
44  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.8.2 Advanced Parameters  
Use this submenu to configure the following gateway’s advanced control protocol parameters.  
Disconnect and Answer Supervision  
CDR and Debug  
Miscellaneous Parameters  
Supplementary Services  
5.8.3 Number Manipulation Tables  
The VoIP gateway provides four Number Manipulation tables for incoming and outgoing calls.  
These tables are used to modify the destination and source telephone numbers so that the calls  
can be routed correctly.  
The Manipulation Tables are:  
Destination Phone Number Manipulation Table for IPTel calls  
Destination Phone Number Manipulation Table for TelIP call  
Source Phone Number Manipulation Table for IPTel calls  
Source Phone Number Manipulation Table for TelIP calls  
Note:  
Number manipulation can be performed either before or after a routing  
decision is made. For example, you can route a call to a specific trunk group  
according to its original number, and then you can remove/add a prefix to that  
number before it is routed. To control when number manipulation is done, set  
the ‘RouteModeIP2Tel’ and the ‘RouteModeTel2IP’ parameters. For  
information on these parameters, refer to Table 6-5 on page 115.  
Possible uses for number manipulation can be as follows:  
To strip/add dialing plan digits from/to the number. For example, a user could dial 9 in front  
of each number to indicate an external line. This number (9) can be removed here before  
(after) the call is setup.  
Assignment of NPI/TON to IPTel calls. The VoIP gateway can use a single global setting  
for NPI/TON classification or it can use the setting in this table on a call by call basis. Control  
for this is done using “Protocol Management>Protocol Definition>Destination/Source  
Number Encoding Type”.  
Allow / disallow Caller ID information to be sent according to destination / source prefixes.  
To configure the Number Manipulation tables, take these 5 steps:  
1. Open the Number Manipulation screen you want to configure (Protocol Management menu  
> Manipulation Tables submenu); the relevant Manipulation table screen is displayed.  
Figure 5-4 shows the ‘Source Phone Number Manipulation Table for TelIP calls’.  
Version 4.4  
45  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Figure 5-4: Source Phone Number Manipulation Table for TelIP Calls  
2. In the ‘Table Index’ drop-down list, select the range of entries that you want to edit (up to 20  
entries can be configured for Source Number Manipulation and 50 entries for Destination  
Number Manipulation).  
3. Configure the Number Manipulation table according to Table 5-1.  
4. Click the Submit button to save your changes.  
5. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Table 5-1: Number Manipulation Parameters  
Parameter  
Description  
Destination Prefix  
Source Prefix  
Source IP  
Each entry in the Destination Prefix fields represents a destination telephone number  
prefix. An asterisk (*) represents any number.  
Each entry in the Source Prefix fields represents a source telephone number prefix.  
An asterisk (*) represents any number.  
Each entry in the Source IP fields represents the source IP address of the call  
(obtained from the Contact header in the Invite message).  
This column only applies to the ‘Destination Phone Number Manipulation Table for IP  
to Tel’.  
Note: The source IP address can include the “x” wildcard to represent single digits.  
For example: 10.8.8.xx represents all the addresses between 10.8.8.10 to 10.8.8.99.  
The manipulation rules are applied to any incoming call whose:  
Destination number prefix matches the prefix defined in the ‘Destination Number’ field.  
Source number prefix matches the prefix defined in the ‘Source Prefix’ field.  
Source IP address matches the IP address defined in the ‘Source IP’ field (if applicable).  
Note that number manipulation can be performed using a combination of each of the above criteria, or using each  
criterion independently.  
Note: For available notations that represent multiple numbers, refer to Section 5.8.3.1 on page 47.  
Enter the number of digits that you want to remove from the left of the telephone  
number prefix. For example, if you enter 3 and the phone number is 5551234, the  
new phone number is 1234.  
Num of stripped digits  
Enter the number of digits (in brackets) that you want to remove from the right of  
the telephone number prefix.  
Note: A combination of the two options is allowed (e.g., 2(3)).  
Mediant 2000 SIP User’s Manual  
46  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-1: Number Manipulation Parameters  
Description  
Parameter  
Prefix - Enter the number / string you want to add to the front of the phone  
Prefix / Suffix to add  
number. For example, if you enter 9 and the phone number is 1234, the new  
number is 91234.  
Suffix - Enter the number / string (in brackets) you want to add to the end of the  
phone number. For example, if you enter (00) and the phone number is 1234, the  
new number is 123400.  
Note: You can enter a prefix and a suffix in the same field (e.g., 9(00)).  
Number of digits to leave  
Enter the number of digits that you want to leave from the right.  
Note: The manipulation rules are executed in the following order:  
1. Num of stripped digits  
2. Number of digits to leave  
3. Prefix / suffix to add  
Figure 5-4 on the previous page exemplifies the use of these manipulation rules in the ‘Source Phone Number  
Manipulation Table for TelIP Calls’:  
When destination number equals 035000 and source number equals 20155, the source number is changed to  
97220155.  
When source number equals 1001876, it is changed to 587623.  
Source number 1234510012001 is changed to 20018.  
Source number 3122 is changed to 2312.  
NPI  
Select the Number Plan assigned to this entry.  
You can select Unknown [0], Private [9] or E.164 Public [1].  
The default is Unknown.  
For a detailed list of the available NPI/TON values, refer to Section 5.8.3.2 on page  
48.  
TON  
Select the Number Type assigned to this entry.  
If you selected Unknown as the Number Plan, you can select Unknown [0].  
If you selected Private as the Number Plan, you can select Unknown [0], Level 2  
Regional [1], Level 1 Regional [2], PSTN Specific [3] or Level 0 Regional (Local)  
[4].  
If you selected E.164 Public as the Number Plan, you can select Unknown [0],  
International [1], National [2], Network Specific [3], Subscriber [4] or Abbreviated  
[6].  
The default is Unknown.  
Presentation  
Select ‘Allowed’ to send Caller ID information when a call is made using these  
destination / source prefixes.  
Select ‘Restricted’ if you want to restrict Caller ID information for these prefixes.  
5.8.3.1 Dialing Plan Notation  
The dialing plan notation applies, in addition to the four Manipulation tables, also to TelIP  
Routing table and to IPTrunk Group Routing table.  
When entering a number in the destination and source ‘Prefix’ columns, you can create an entry  
that represents multiple numbers using the following notation:  
[n-m] represents a range of numbers  
[n,m] represents multiple numbers. Note that this notation only supports single digit numbers.  
x represents any single digit  
# (that terminates the number) represents the end of a number  
A single asterisk (*) represents any number  
For example:  
[5551200-5551300]# represents all numbers from 5551200 to 5551300  
Version 4.4  
47  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
[2,3,4]xxx# represents four-digit numbers that start with 2, 3 or 4  
54324 represents any number that starts with 54324  
54324xx# represents a 7 digit number that starts with 54324  
123[100-200]# represents all numbers from 123100 to 123200.  
The VoIP gateway matches the rules starting at the top of the table. For this reason, enter more  
specific rules above more generic rules. For example, if you enter 551 in entry 1 and 55 in entry  
2, the VoIP gateway applies rule 1 to numbers that starts with 551 and applies rule 2 to numbers  
that start with 550, 552, 553, 554, 555, 556, 557, 558 and 559. However if you enter 55 in entry 1  
and 551 in entry 2, the VoIP gateway applies rule 1 to all numbers that start with 55 including  
numbers that start with 551.  
5.8.3.2 Numbering Plans and Type of Number  
Numbers are classified by their Numbering Plan Indication (NPI) and their Type of Number  
(TON). The Mediant 2000 supports all NPI/TON classifications used in the standard. The list of  
ISDN ETSI NPI/TON values is shown as follows:  
Table 5-2: NPI/TON Values for ISDN ETSI  
NPI  
TON  
Description  
A valid classification, but one that has no information about the  
numbering plan.  
Unknown [0]  
Unknown [0]  
Unknown [0]  
International [1]  
National [2]  
A public number in E.164 format, but no information on what  
kind of E.164 number.  
A public number in complete international E.164 format. For  
example: 16135551234  
E.164 Public [1]  
A public number in complete national E.164 format. For  
example: 6135551234  
A public number in complete E.164 format representing a local  
subscriber. For example: 5551234  
Subscriber [4]  
Unknown [0]  
A private number, but with no further information about the  
numbering plan  
Level 2 Regional [1]  
Level 1 Regional [2]  
PISN Specific [3]  
Private [9]  
A private number with a location. For example: 3932200  
A private local extension number. For example: 2200  
Level 0 Regional (local) [4]  
For NI-2 and DMS-100 ISDN variants the valid combinations of TON and NPI for calling and  
called numbers are (Plan/Type):  
0/0 - Unknown/Unknown  
1/1 - International number in ISDN/Telephony numbering plan  
1/2 - National number in ISDN/Telephony numbering plan  
1/4 - Subscriber (local) number in ISDN/Telephony numbering plan  
9/4 - Subscriber (local) number in Private numbering plan  
Mediant 2000 SIP User’s Manual  
48  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.8.4 Configuring the Routing Tables  
Use this submenu to configure the gateway’s IPTel and TelIP routing tables and their  
associated parameters.  
5.8.4.1 Tel to IP Routing Table  
The Tel to IP Routing Table is used to route incoming Tel calls to IP addresses. This routing table  
associates a called / calling telephone number’s prefixes with a destination IP address or with an  
FQDN (Fully Qualified Domain Name). When a call is routed through the VoIP gateway (Proxy  
isn’t used), the called and calling numbers are compared to the list of prefixes on the IP Routing  
Table (up to 50 prefixes can be configured); Calls that match these prefixes are sent to the  
corresponding IP address. If the number dialed does not match these prefixes, the call is not  
made.  
When using a Proxy server, you do not need to configure the Telephone to IP Routing Table.  
However, if you want to use fallback routing when communication with Proxy is lost, or to use the  
‘Filter Calls to IP’ and IP Security features, or to obtain different SIP URI host names (per called  
number), you need to configure the IP Routing Table.  
Note that for the Tel to IP Routing table to take precedence over a Proxy for routing calls, set the  
parameter ‘PreferRouteTable’ to 1. The gateway checks the 'Destination IP Address' field in the  
'Tel to IP Routing' table for a match with the outgoing call. Only if a match is not found, a Proxy is  
used.  
Possible uses for Telephone to IP Routing can be as follows:  
Can fallback to internal routing table if there is no communication with the Proxy.  
Call Restriction – (when Proxy isn’t used), reject all outgoing TelIP calls that are  
associated with the destination IP address: 0.0.0.0.  
IP Security – When the IP Security feature is enabled (SecureCallFromIP = 1), the VoIP  
gateway accepts only those IPTel calls with a source IP address identical to one of the IP  
addresses entered in the Telephone to IP Routing Table.  
Filter Calls to IP – When a Proxy is used, the gateway checks the TelIP routing table  
before a telephone number is routed to the Proxy. If the number is not allowed (number isn’t  
listed or a Call Restriction routing rule was applied), the call is released.  
Always Use Routing Table – When this feature is enabled (AlwaysUseRouteTable = 1), even  
if a Proxy server is used, the SIP URI host name in the sent INVITE message is obtained  
from this table. Using this feature users are able to assign a different SIP URI host name for  
different called and/or calling numbers.  
Assign Profiles to destination address (also when a Proxy is used).  
Alternative Routing – (When Proxy isn’t used) an alternative IP destination for telephone  
number prefixes is available. To associate an alternative IP address to called telephone  
number prefix, assign it with an additional entry (with a different IP address), or use an  
FQDN that resolves to two IP addresses. Call is sent to the alternative destination when one  
of the following occurs:  
No ping to the initial destination is available, or when poor Quality of Service (QoS)  
(delay or packet loss, calculated according to previous calls) is detected, or when a  
DNS host name is not resolved. For detailed information on Alternative Routing, refer to  
Section 8.6 on page 146.  
When a release reason that is defined in the ‘Reasons for Alternative Tel to IP Routing’  
table is received. For detailed information on the ‘Reasons for Alternative Routing  
Tables’, refer to Section 5.8.4.4 on page 54.  
Alternative routing (using this table) is commonly implemented when there is no response to  
an Invite message (after Invite retransmissions). The gateway then issues an internal 408  
‘No Response’ implicit release reason. If this reason is included in the ‘Reasons for  
Version 4.4  
49  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Alternative Routing’ table, the gateway immediately initiates a call to the redundant  
destination using the next matched entry in the ‘Tel to IP Routing’ table. Note that if a domain  
name in this table is resolved to two IP addresses, the timeout for Invite retransmissions can  
be reduced by using the parameter ‘Number of RTX Before Hotswap’.  
Note: If the alternative routing destination is the gateway itself, the call can be configured to  
be routed back to PSTN. This feature is referred to as "PSTN Fallback", meaning that if  
sufficient voice quality is not available over the IP network, the call is routed through legacy  
telephony system (PSTN).  
Tip:  
Tel to IP routing can be performed either before or after applying the number  
manipulation rules. To control when number manipulation is done, set the  
RouteModeTel2IP parameter. For information on this parameter, refer to refer  
To configure the Tel to IP Routing table, take these 6 steps:  
1. Open the ‘Tel to IP Routing’ screen (Protocol Management menu > Routing Tables  
submenu > Tel to IP Routing option); the ‘Tel to IP Routing’ screen is displayed (shown in  
2. In the ‘Tel to IP Routing Mode’ field, select the Tel to IP routing mode (refer to Table 6-5).  
3. In the ‘Routing Index' drop-down list, select the range of entries that you want to edit.  
4. Configure the Tel to IP Routing table according to Table 5-3.  
5. Click the Submit button to save your changes.  
6. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Figure 5-5: Tel to IP Routing Table Screen  
Table 5-3: Tel to IP Routing Table  
Parameter  
Description  
Destination Phone Prefix  
Each entry in the Destination Phone Prefix fields represents a called telephone  
number prefix. The prefix can be 1 to 19 digits long. An asterisk (*) represents all  
numbers.  
Source Phone Prefix  
Each entry in the Source Phone Prefix fields represents a calling telephone number  
prefix. The prefix can be 1 to 19 digits long. An asterisk (*) represents all numbers.  
Mediant 2000 SIP User’s Manual  
50  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-3: Tel to IP Routing Table  
Description  
Parameter  
Any telephone number whose destination number matches the prefix defined in the ‘Destination Phone Prefix’ field and  
its source number matches the prefix defined in the adjacent ‘Source Phone Prefix‘ field, is sent to the IP address  
entered in the ‘IP Address’ field.  
Note that Tel to IP routing can be performed according to a combination of source and destination phone prefixes, or  
using each independently.  
Note 1: An additional entry of the same prefixes can be assigned to enable alternative routing.  
Note 2: For available notations that represent multiple numbers, refer to Section 5.8.3.1 on page 47.  
Destination IP Address  
In each of the IP Address fields, enter the IP address that is assigned to these  
prefixes. Domain names, such as domain.com, can be used instead of IP addresses.  
To discard outgoing IP calls, enter 0.0.0.0 in this field.  
Note: When using domain names, you must enter a DNS server IP address, or  
alternatively define these names in the ‘Internal DNS Table’.  
Profile ID  
Status  
Enter the number of the IP profile that is assigned to the destination IP address  
defined in the ‘Destination IP Address’ field.  
A read only field representing the quality of service of the destination IP address.  
N/A = Alternative Routing feature is disabled.  
OK = IP route is available  
Ping Error = No ping to IP destination, route is not available  
QoS Low = Bad QoS of IP destination, route is not available  
DNS Error = No DNS resolution (only when domain name is used instead of an IP  
address).  
5.8.4.2 IP to Trunk Group Routing Table  
The IP to Trunk Group Routing Table is used to route incoming IP calls to groups of E1/T1  
B-channels called trunk groups. Calls are assigned to trunk groups according to any combination  
of the following three options (or using each independently):  
Destination phone prefix  
Source phone prefix  
Source IP address  
The call is then sent to the VoIP gateway channels assigned to that trunk group. The specific  
channel, within a trunk group, that is assigned to accept the call is determined according to the  
trunk group’s channel selection mode which is defined in the Trunk Group Settings table  
(Section5.8.7 on page 60), or according to the global parameter ‘ChannelSelectMode’ (refer to  
Table 6-5 on page 115).  
Note: When a release reason that is defined in the ‘Reasons for Alternative IP to Tel Routing’  
table is received for a specific IPTel call, an alternative trunk group for that call is available. To  
associate an alternative trunk group to an incoming IP call, assign it with an additional entry in the  
‘IP to Trunk Group Routing’ table (repeat the same routing rules with a different trunk group ID).  
For detailed information on the ‘Reasons for Alternative Routing Tables’, refer to Section 5.8.4.4  
on page 54.  
To use trunk groups you must also do the following:  
You must assign a trunk group ID to the VoIP gateway E1/T1 B-channels on the Trunk  
Group Table. For information on how to assign a trunk group ID to a B-channel, refer to  
Section 5.8.6 on page 58.  
Version 4.4  
51  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
You can configure the Trunk Group Settings table to determine the method in which new  
calls are assigned to channels within the trunk groups (a different method for each trunk  
group can be configured). For information on how to enable this option, refer to Section 5.8.7  
on page 60. If a Channel Select Mode for a specific trunk group isn’t specified, then the  
global ‘Channel Select Mode’ parameter (defined in ‘General Parameters’ screen under  
‘Advanced Parameters’) applies.  
To configure the IP to Trunk Group Routing table, take these 6 steps:  
1. Open the ‘IP to Trunk Group Routing’ screen (Protocol Management menu > Routing  
Tables submenu > IP to Trunk Group Routing option); the ‘IP to Trunk Group Routing’  
table screen is displayed.  
Figure 5-6: IP to Trunk Group Routing Table  
2. In the ‘IP to Tel Routing Mode’ field, select the IP to Tel routing mode (refer to Table 6-5 on  
page 115).  
3. In the ‘Routing Index’ drop-down list, select the range of entries that you want to edit (up to  
24 entries can be configured).  
4. Configure the IP to Trunk Group Routing table according to Table 5-4.  
5. Click the Submit button to save your changes.  
6. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Table 5-4: IP to Trunk Group Routing Table  
Parameter  
Description  
Destination Phone Prefix  
Source Phone Prefix  
Source IP Address  
Each entry in the Destination Phone Prefix fields represents a called  
telephone number prefix. The prefix can be 1 to 49 digits long. An asterisk  
(*) represents all numbers.  
Each entry in the Source Phone Prefix fields represents a calling  
telephone number prefix. The prefix can be 1 to 49 digits long. An asterisk  
(*) represents all numbers.  
Each entry in the Source IP Address fields represents the source IP  
address of an IPTel call (obtained from the Contact header in the Invite  
message).  
Note: The source IP address can include the “x” wildcard to represent  
single digits. For example: 10.8.8.xx represents all the addresses between  
10.8.8.10 to 10.8.8.99.  
Mediant 2000 SIP User’s Manual  
52  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-4: IP to Trunk Group Routing Table  
Description  
Parameter  
Any SIP incoming call whose destination number matches the prefix defined in the ‘Destination Phone Prefix’ field and  
its source number matches the prefix defined in the adjacent ‘Source Phone Prefix‘ field and its source IP address  
matches the address defined in the ‘Source IP Address’ field, is assigned to the trunk group entered in the field to the  
right of these fields.  
Note that IP to trunk group routing can be performed according to any combination of source / destination phone  
prefixes and source IP address, or using each independently.  
Note: For available notations that represent multiple numbers (used in the prefix columns), refer to Section 5.8.3.1 on  
page 47.  
Trunk Group ID  
In each of the Trunk Group ID fields, enter the trunk group ID to which  
calls that match these prefixes are assigned.  
Profile ID  
Enter the number of the IP profile that is assigned to the routing rule.  
5.8.4.3 Internal DNS Table  
The internal DNS table, similar to a DNS resolution, translates hostnames into IP addresses. This  
table is used when hostname translation is required (e.g., ‘Tel to IP Routing’ table, etc.). Two  
different IP addresses can be assigned to the same hostname. If the hostname isn’t found in this  
table, the gateway communicates with an external DNS server.  
Assigning two IP addresses to hostname can be used for alternative routing (using the ‘Tel to IP  
Routing’ table).  
To configure the internal DNS table, take these 7 steps:  
1. Open the ‘Internal DNS Table’ screen (Protocol Management menu > Routing Tables  
submenu > Internal DNS Table option); the ‘Internal DNS Table’ screen is displayed.  
Figure 5-7: Internal DNS Table Screen  
2. In the ‘DNS Name’ field, enter the hostname to be translated. You can enter a string up to 31  
characters long.  
3. In the ‘First IP Address’ field, enter the first IP address that the hostname is translated to.  
4. In the ‘Second IP Address’ field, enter the second IP address that the hostname is translated  
to.  
5. Repeat steps 2 to 4, for each Internal DNS Table entry.  
6. Click the Submit button to save your changes.  
7. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Version 4.4  
53  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.8.4.4 Reasons for Alternative Routing  
The Reasons for Alternative Routing screen includes two tables (TelIP and IPTel). Each table  
enables you to define up to 4 different release reasons. If a call is released as a result of one of  
these reasons, the gateway tries to find an alternative route to that call. The release reason for  
IPTel calls is provided in Q.931 notation. The release reason for TelIP calls is provided in SIP  
4xx, 5xx and 6xx response codes. For TelIP calls an alternative IP address, for IPTel calls an  
alternative trunk group.  
Refer to ‘Tel to IP Routing Table’ on page 49 for information on defining an alternative IP  
address. Refer to the ‘IP to Trunk Group Routing Table’ on page 51 for information on defining an  
alternative trunk group.  
You can use this table for example:  
For TelIP calls, when there is no response to an Invite message (after Invite retransmissions),  
and the gateway then issues an internal 408 ‘No Response’ implicit release reason.  
For IPTel calls, when the destination is busy, and release reason #17 is issued or for other call  
releases that issue the default release reason (#3). Refer to ‘DefaultReleaseCause’ in Table 6-3.  
Note: The reasons for alternative routing option for TelIP calls only applies when Proxy isn’t  
used.  
To configure the reasons for alternative routing, take these 5 steps:  
1. Open the ‘Reasons for Alternative Routing’ screen (Protocol Management menu > Routing  
Tables submenu > Reasons for Alternative Routing option); the ‘Reasons for Alternative  
Routing’ screen is displayed.  
Figure 5-8: Reasons for Alternative Routing Screen  
2. In the ‘IP to Tel Reasons’ table, from the drop-down list select up to 4 different call failure  
reasons that invoke an alternative IP to Tel routing.  
3. In the ‘Tel to IP Reasons’ table, from the drop-down list select up to 4 different call failure  
reasons that invoke an alternative Tel to IP routing.  
4. Click the Submit button to save your changes.  
5. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Mediant 2000 SIP User’s Manual  
54  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.8.5 Configuring the Profile Definitions  
Utilizing the Profiles feature, the Mediant 2000 provides high-level adaptation when connected to  
a variety of equipment (from both Tel and IP sides) and protocols, each of which require a  
different system behavior. Using Profiles, users can assign different Profiles (behavior) on a per-  
call basis, using the Tel to IP and IP to Trunk Group Routing tables, or associate different Profiles  
to the gateway’s B-channels(s). The Profiles contain parameters such as Coders, T.38 Relay,  
Voice and DTMF Gains, Silence Suppression, Echo Canceler, RTP DiffServ and more. The  
Profiles feature allows users to tune these parameters or turn them on or off, per source or  
destination routing and/or the specific gateway or its ports. For example, specific E1/T! spans can  
be designated for to have a profile which always uses G.711.  
Each call can be associated with one or two Profiles, Tel Profile and (or) IP Profile. If both IP and  
Tel profiles apply to the same call, the coders and other common parameters of the preferred  
Profile (determined by the Preference option) are applied to that call. If the Preference of the Tel  
and IP Profiles is identical, the Tel Profile parameters are applied.  
Note:  
The default values of the parameters in the Tel and IP Profiles are identical to  
the Web/ini file parameter values. If a value of a parameter is changed in the  
Web/ini file, it is automatically updated in the Profiles correspondingly. After  
any parameter in the Profile is modified by the user, modifications to  
parameters in the Web/ini file no longer impact that Profile.  
5.8.5.1 Coder Group Settings  
Use the Coders Group Settings screen to define up to four different coder groups. These coder  
groups are used in the Tel and IP Profile Settings screens to assign different coders to Profiles.  
To configure the coder group settings, take these 8 steps:  
1. Open the ‘Coder Group Settings’ screen (Protocol Management menu > Profile  
Definitions submenu > Coder Group Settings option); the ‘Coder Group Settings’ screen is  
displayed.  
Figure 5-9: Coder Group Settings Screen  
2. In the ‘Coder Group ID’ drop-down list, select the coder group you want to edit (up to four  
coder groups can be configured).  
3. From the coder drop-down list, select the coder you want to use. For the full list of available  
coders and their corresponding ptimes, refer to the ini file parameter ‘CoderName_ID’  
(described in Table 6-3).  
Note: Each coder can appear only once.  
4. From the drop-down list to the right of the coder list, select the size of the Voice Packet  
(ptime) used with this coder in milliseconds. Selecting the size of the packet determines how  
many coder payloads are combined into one RTP (voice) packet.  
Note 1: The ptime packetization period depends on the selected coder name.  
Version 4.4  
55  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Note 2: If not specified, the ptime gets a default value.  
Note 3: The ptime specifies the maximum packetization time the gateway can receive.  
5. Repeat steps 3 and 4 for the second to fifth coders (optional).  
6. Repeat steps 2 to 5 for the second to forth coder groups (optional).  
7. Click the Submit button to save your changes.  
8. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Note:  
In the current version, only the ptime of the first coder is sent in the SDP  
section of the Invite message.  
5.8.5.2 Tel Profile Settings  
Use the Tel Profile Settings screen to define up to four different Tel Profiles. These Profiles are  
used in the ‘Trunk Group’ table to associate different Profiles to gateway’s B-channels, thereby  
applying different behavior to different Mediant 2000 B-channels.  
To configure the Tel Profile settings, take these 8 steps:  
1. Open the ‘Tel Profile Settings’ screen (Protocol Management menu > Profile Definitions  
submenu > Tel Profile Settings option); the ‘Tel Profile Settings’ screen is displayed.  
Figure 5-10: Tel Profile Settings Screen  
2. In the ‘Profile ID’ drop-down list, select the Tel Profile you want to edit (up to four Tel Profiles  
can be configured).  
Mediant 2000 SIP User’s Manual  
56  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
3. In the ‘Profile Preference’ drop-down list, select the preference (1-10) of the current Profile.  
The preference option is used to determine the priority of the Profile. If both IP and Tel  
profiles apply to the same call, the coders and other common parameters of the preferred  
Profile are applied to that call. If the Preference of the Tel and IP Profiles is identical, the Tel  
Profile parameters are applied.  
Note: If the coder lists of both IP and Tel Profiles apply to the same call, an intersection of  
the coders is performed (i.e., only common coders remain). The order of the coders is  
determined by the preference.  
4. Configure the Profile’s parameters according to your requirements. For detailed information  
on each parameter refer to the description of the screen in which it is configured as an  
individual parameter.  
5. In the ‘Coder Group’ drop-down list, select the coder group you want to assign to that Profile.  
You can select the gateway’s default coders (refer to Section 5.8.1.1 on page 44) or one of  
the coder groups you defined in the Coder Group Settings screen (refer to Section 5.8.5.1 on  
page 55).  
6. Repeat steps 2 to 6 for the second to fifth Tel Profiles (optional).  
7. Click the Submit button to save your changes.  
8. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
5.8.5.3 IP Profile Settings  
Use the IP Profile Settings screen to define up to four different IP Profiles. These Profiles are  
used in the Tel to IP and IP to Trunk Group Routing tables to associate different Profiles to  
routing rules. IP Profiles can also be used when working with Proxy server (set  
‘AlwaysUseRouteTable’ to 1).  
To configure the IP Profile settings, take these 8 steps:  
1. Open the ‘IP Profile Settings’ screen (Protocol Management menu > Profile Definitions  
submenu > IP Profile Settings option); the ‘IP Profile Settings’ screen is displayed.  
Figure 5-11: IP Profile Settings Screen  
Version 4.4  
57  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
2. In the ‘Profile ID’ drop-down list, select the IP Profile you want to edit (up to four IP Profiles  
can be configured).  
3. In the ‘Profile Preference’ drop-down list, select the preference (1-10) of the current Profile.  
The preference option is used to determine the priority of the Profile. If both IP and Tel  
profiles apply to the same call, the coders and other common parameters of the preferred  
Profile are applied to that call. If the Preference of the Tel and IP Profiles is identical, the Tel  
Profile parameters are applied.  
Note: If the coder lists of both IP and Tel Profiles apply to the same call, an intersection of  
the coders is performed (i.e., only common coders remain). The order of the coders is  
determined by the preference.  
4. Configure the Profile’s parameters according to your requirements. For detailed information  
on each parameter refer to the description of the screen in which it is configured as an  
individual parameter.  
5. In the ‘Coder Group’ drop-down list, select the coder group you want to assign to that Profile.  
You can select the gateway’s default coders (refer to Section 5.8.1.1 on page 44) or one of  
the coder groups you defined in the Coder Group Settings screen (refer to Section 5.8.5.1 on  
page 55).  
6. Repeat steps 2 to 6 for the second to fifth IP Profiles (optional).  
7. Click the Submit button to save your changes.  
8. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
5.8.6 Configuring the Trunk Group Table  
Use the Trunk Group table to assign trunk groups, profiles and logical telephone numbers to the  
gateway's E1/T1 B-channels. Trunk Groups are used for routing IPTel calls with common rules.  
Channels that are not defined are disabled.  
To configure the Trunk Group table, take these 4 steps:  
1. Open the ‘Trunk Group Table’ screen (Protocol Management menu > Trunk Group); the  
‘Trunk Group Table’ screen is displayed.  
Figure 5-12: Trunk Group Table Screen  
2. Configure the Trunk Group according to Table 5-5  
3. Click the Submit button to save your changes.  
4. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Mediant 2000 SIP User’s Manual  
58  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-5: Trunk Group Table  
Parameter  
Description  
Trunk ID  
The numbers (1-8) in the Trunk ID drop-down list represent the physical trunks on the back of  
the VoIP gateway.  
Channels  
To enable the trunk’s B-channels, you must enter their number in this field.  
[n-m] represents a range of channels.  
For example, enter [1-24] to specify the channels from 1 to 24.  
Note: The number of defined channels must not exceed the number of the trunk’s B-channels  
(1-24 for T1 spans and 1-30 for E1 spans).  
Phone Number  
In each of the Phone Number fields, enter the first number in an ordered sequence that is  
assigned to the range of channels defined in the adjacent ‘Channels’ field.  
Note: This field is optional. The logical numbers defined in this field are used when an  
incoming PSTN / PBX call doesn’t contain the calling number or called number (the latter  
being determined by the parameter ‘ReplaceEmptyDstWithPortNumber’), these numbers are  
used to replace them.  
These logical numbers are also used for B-channel allocation for IP to Tel calls, if the trunk  
group’s ‘Channel Select Mode’ is set to ‘By Phone Number’.  
Trunk Group ID  
In each of the Trunk Group ID fields, enter the trunk group ID (1-99) assigned to the channels.  
The same trunk group ID can be used for more than one group of channels.  
Trunk group ID is used to define a group of common behavior channels that are used for  
routing IP to Tel calls. If an IP to Tel call is assigned to a trunk group, the call is routed to the  
channel or channels that correspond to the trunk group ID.  
You can configure the Trunk Group Settings table to determine the method in which new calls  
are assigned to channels within the trunk groups (refer to Section 5.8.7 on page 60).  
Note: You must configure the IP to Trunk Group Routing Table (assigns incoming IP calls to  
the appropriate trunk group). If you do not configure the IP to Trunk Group Routing Table,  
calls do not complete.  
For information on how to configure this table, refer to Section 5.8.4.2 on page 51.  
Profile ID  
Enter the number of the Tel profile that is assigned to the B-channels defined in the  
‘Channels’ field.  
Version 4.4  
59  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
5.8.7 Configuring the Trunk Group Settings  
The Trunk Group Settings Table is used to determine the method in which new calls are assigned  
to B-channels within each trunk group. If such a rule doesn’t exist (for a specific Trunk group), the  
global rule, defined by the Channel Select Mode parameter (Protocol Definition > General  
Parameters), applies.  
To configure the Trunk Group Settings table, take these 7 steps:  
1. Open the ‘Trunk Group Settings’ screen (Protocol Management menu > Trunk Group  
Settings); the ‘Trunk Group Settings’ screen is displayed.  
Figure 5-13: Trunk Group Settings Screen  
2. In the Routing Index drop-down list, select the range of entries that you want to edit (up to  
24 entries can be configured).  
3. In the Trunk Group ID field, enter the Trunk Group ID number.  
4. In the Channel Select Mode drop-down list, select the Channel Select Mode that  
determines the method in which new calls are assigned to B-channels within the Trunk  
groups entered in the field to the right of this field. For information on available Channel  
Select Modes, refer to Table 5-6.  
5. Repeat steps 4 and 5, for each defined Trunk group.  
6. Click the Submit button to save your changes.  
7. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Mediant 2000 SIP User’s Manual  
60  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-6: Channel Select Modes  
Description  
Mode  
By phone number  
Select the gateway port according to the called number (refer to the note  
below).  
Cyclic Ascending  
Select the next available channel in an ascending cycle order. Always select  
the next higher channel number in the Trunk Group. When the gateway  
reaches the highest channel number in the Trunk Group, it selects the lowest  
channel number in the Trunk Group and then starts ascending again (default).  
Ascending  
Select the lowest available channel. Always start at the lowest channel  
number in the Trunk Group and if that channel is not available, select the next  
higher channel.  
Cyclic Descending  
Select the next available channel in descending cycle order. Always select the  
next lower channel number in the Trunk Group. When the gateway reaches  
the lowest channel number in the Trunk Group, it selects the highest channel  
number in the Trunk Group and then start descending again.  
Descending  
Select the highest available channel. Always start at the highest channel  
number in the Trunk Group and if that channel is not available, select the next  
lower channel.  
Number + Cyclic Ascending  
First select the gateway port according to the called number (refer to the note  
below). If the called number isn’t found, then select the next available channel  
in ascending cyclic order. Note that if the called number is found, but the port  
associated with this number is busy, the call is released.  
Note:  
The internal numbers of the gateway’s B-channels are defined in the ‘Trunk  
Group Table’ under the ‘Phone Number’ column. For detailed information on  
the ‘Trunk Group Table’, refer to Section 5.8.6 on page 58).  
Version 4.4  
61  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
5.9 Advanced Configuration  
Use this menu to set the gateway’s advanced configuration parameters (for advanced users  
only).  
5.9.1 Configuring the Network Settings  
From the Network Settings page you can define:  
IP settings.  
NTP settings.  
Syslog settings.  
SNMP settings.  
RTP settings.  
Ethernet Ports Information (read-only).  
To configure the Network Settings parameters, take these 4 steps:  
1. Open the ‘Network Settings’ screen (Advanced Configuration menu > Network Settings);  
the ‘Network Settings’ screen is displayed.  
2. Configure the Network Settings parameters.  
3. Click the Submit button to save your changes.  
4. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Figure 5-14: Network Settings Screen  
Note that the default RTP Base UDP Port is 6000.  
Mediant 2000 SIP User’s Manual  
62  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.9.1.1 Configuring the SNMP Managers Table  
The SNMP Managers table allows you to configure the attributes of up to five SNMP managers.  
To configure the SNMP Managers Table, take these 6 steps:  
1. Access the ‘Network Settings’ screen (Advanced Configuration menu > Network  
Settings); the ‘Network Settings’ screen is displayed (Figure 5-14).  
2. Open the SNMP Managers Table screen by clicking the arrow sign (-->) to the right of the  
SNMP Managers Table label; the SNMP Managers Table screen is displayed (Figure 5-15).  
3. Configure the SNMP managers parameters.  
4. Click the Submit button to save your changes.  
5. Click the Close Window button.  
6. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Figure 5-15: SNMP Managers Table Screen  
Note:  
If you clear a checkbox and click Submit, all settings in the same row revert  
to their defaults.  
5.9.1.2 Multiple Routers Support  
Multiple routers support is designed to assist the media gateway when it operates in a multiple  
routers network. The gateway learns the network topology by responding to ICMP redirections  
and caches them as routing rules (with expiration time).  
When a set of routers operating within the same subnet serve as gateways to that network and  
intercommunicate using a dynamic routing protocol (such as OSPF, etc.), the routers can  
determine the shortest path to a certain destination and signal the remote host the existence of  
the better route. Using multiple router support the media gateway can utilize these router  
messages to change its next hop and establish the best path.  
Note: Multiple Routers support is an integral feature that doesn’t require configuration.  
5.9.1.3 Simple Network Time Protocol Support  
The Simple Network Time Protocol (SNTP) client functionality generates requests and reacts to  
the resulting responses using the NTP version 3 protocol definitions (according to RFC 1305).  
Through these requests and responses, the NTP client is able to synchronize the system time to  
a time source within the network, thereby eliminating any potential issues should the local system  
clock 'drift' during operation. By synchronizing time to a network time source, traffic handling,  
Version 4.4  
63  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
maintenance, and debugging actions become simplified for the network administrator.  
The NTP client follows a simple process in managing system time; the NTP client requests an  
NTP update, receives an NTP response, and updates the local system clock based on a  
configured NTP server within the network.  
The client requests a time update from a specified NTP server at a specified update interval. In  
most situations this update interval should be every 24 hours based on when the system was  
restarted. The NTP server identity (as an IP address) and the update interval are configurable  
parameters that can be specified either in the ini file (NTPServerIP, NTPUpdateInterval  
respectively) or via an SNMP MIB object.  
When the client receives a response to its request from the identified NTP server it must be  
interpreted based on time zone, or location, offset that the system is to a standard point of  
reference called the Universal Time Coordinate (UTC). The time offset that the NTP client should  
use is a configurable parameter that can be specified either in the ini file (NTPServerUTCOffset)  
or via an SNMP MIB object.  
If required, the clock update is performed by the client as the final step of the update process.  
The update is done in such a way as to be transparent to the end users. For instance, the  
response of the server may indicate that the clock is running too fast on the client. The client  
slowly robs bits from the clock counter in order to to update the clock to the correct time. If the  
clock is running too slow, then in an effort to catch the clock up, bits are added to the counter,  
causing the clock to update quicker and catch up to the correct time. The advantage of this  
method is that it does not introduce any disparity in the system time, that is noticeable to an end  
user, or that could corrupt call timeouts and timestamps.  
Mediant 2000 SIP User’s Manual  
64  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.9.2 Configuring the Channel Settings  
The Channels Settings screen enables you to set the VoIP gateway channel parameters, such as  
Input and Output voice gain, Jitter buffer characteristics, Modem, Fax and DTMF transport  
modes. These parameters are applied to all Mediant 2000 channels.  
Note that several Channels Settings parameters can be configured per call using profiles (refer to  
Section 5.8.5 on page 55).  
Note:  
Channel parameters are changeable on-the-fly. Changes take effect from  
next call.  
To configure the Channel Settings parameters, take these 4 steps:  
1. Open the ‘Channel Settings’ screen (Advanced Configuration menu > Channel Settings);  
the ‘Channel Settings’ screen is displayed.  
2. Configure the Channel Settings parameters.  
3. Click the Submit button to save your changes.  
4. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Figure 5-16: Channel Settings Screen  
Note 1: The parameters ‘MF Transport Type’ and the 5 Answer Detector parameters  
are not applicable to the Mediant 2000.  
Note 2: The parameters ‘DTMF Transport Type’ and ‘Fax Transport Mode’ are  
overridden by the parameters ‘IsDTMFUsed’ and ‘IsFaxUsed’ respectively.  
Version 4.4  
65  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.9.3 Configuring the Trunk Settings  
To configure the Trunk Settings, take these 9 steps:  
1. Open the ‘Trunk Settings’ screen (Advanced Configuration menu > Trunk Settings); the  
‘Trunk Settings’ screen is displayed.  
Initially, the screen appears with the parameters fields grayed (indicating read-only). The  
Stop Trunk button appears at the bottom of the screen.  
The Trunk Status indicators appear colored. Table 5-7 shows the possible indicators and  
their descriptions.  
Figure 5-17: E1/T1 Trunk Settings Screen  
2. To configure the parameters of a specific trunk, from the trunks displayed on the top, select  
the trunk you want to configure by clicking the Trunk’s Status indicator. The first parameter  
named ‘Trunk ID’ changes according to the trunk you click. The parameters displayed are for  
the selected trunk only.  
Mediant 2000 SIP User’s Manual  
66  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
Table 5-7: Trunks Status Color Indicator Keys  
5. Web Management  
Indicator  
Color  
Description  
Gray  
Disabled  
Green  
Yellow  
Red  
Active-OK  
RAI Alarm  
LOS Alarm  
AIS Alarm  
Blue  
Orange  
D-channel Alarm  
(ISDN only)  
3. To modify the selected trunk’s parameters, click the Stop Trunk button; the trunk is stopped,  
the status of the parameter ‘Trunk Configuration State’ changes to ‘Non Active’, the  
parameters are no longer grayed and can be modified and the Apply Trunk Settings button  
appears at the bottom of the screen.  
When all trunks are stopped, the Apply to all Trunks button also appears at the bottom of  
the screen.  
Note:  
If the trunk can’t be stopped because it provides the gateway’s clock  
(assuming the Mediant 2000 is synchronized with the E1/T1 clock), assign a  
different E1/T1 trunk to provide the gateway’s clock or enable ‘TDM Bus  
PSTN Auto Clock’ on the TDM Bus Settings screen.  
To assign a different E1/T1 trunk that provides the gateway’s clock, access  
the ‘TDM Bus Setting’ screen and change the ‘TDM Bus Local Reference’  
number to any other trunk number (this operation can be performed on-the-  
fly).  
4. Select the ‘Protocol Type’ you use. Note that different trunks can be defined with different  
protocols (CAS or ISDN variants) on the same gateway (subject to the constraints in the  
Mediant 2000 Release Notes).  
Note:  
When modifying the ‘Protocol Type’ field, the menu is automatically updated  
according to the selected protocol (ISDN, CAS or Transparent). Additional  
parameters are appropriate to the selected protocol type.  
5. Modify the relevant trunk configuration parameters according to your requirements.  
6. To configure the different behavior bits: either enter the exact hexadecimal value of the bits  
in the field to the right of the relevant behavior parameter, or directly configure each bit field  
by completing the following steps:  
Click the arrow button (-->) to the right of the relevant behavior parameter; a new  
window appears.  
Modify each bit field according to your requirements.  
Click the Submit button to save your changes.  
Version 4.4  
67  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Click the Close Window button.  
7. After modifying the parameters:  
To apply the changes to the selected trunk only, click the Apply Trunk Settings button.  
To apply the changes to all the trunks, click the Apply to all Trunks button.  
The screen is refreshed, parameters become read-only (indicated by being grayed). The  
Stop Trunk button appears at the bottom of the screen.  
8. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
Note:  
Some parameter configuration options require a device reset; when this is the  
case, the Web Interface prompts the user.  
9. To reset the Mediant 2000, refer to Section 5.12 on page 84.  
5.9.4 Configuring the TDM Bus Settings  
To configure the TDM Bus Settings parameters, take these 5 steps:  
1. Open the ‘TDM Bus Settings’ screen (Advanced Configuration menu > TDM Bus  
Settings); the ‘TDM Bus Settings’ screen is displayed.  
2. Configure the TDM Bus Settings parameters.  
3. Click the Submit button to save your changes.  
4. To save the changes so they are available after a power fail, refer to Section 5.12 on page  
84.  
5. A device reset is required to activate the TDM Bus Settings parameters. To reset the  
Mediant 2000, refer to Section 5.12 on page 84.  
Figure 5-18: TDM Bus Settings Screen  
Note:  
Usually the ‘PCM Law Select’ parameter is set to A-law for E1 trunks and to  
µ-law for T1 trunks.  
Refer to Appendix E on page 205 for information on configuring the ‘TDM Bus Clock Source’,  
‘TDM Bus Enable Fallback’ and ‘TDM Bus PSTN Auto Clock’ parameters.  
Mediant 2000 SIP User’s Manual  
68  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.9.5 Restoring and Backing up the Gateway Configuration  
The Configuration File screen enables you to restore (load a new ini file to the gateway) or to  
back up (make a copy of the VoIP gateway ini file and store it in a directory on your computer) the  
current configuration the gateway is using.  
Back up your configuration if you want to protect your VoIP gateway programming. The backup  
ini file includes only those parameters that were modified and contain other than default values.  
Restore your configuration if the VoIP gateway has been replaced or has lost its programming  
information, you can restore the VoIP gateway configuration from a previous backup or from a  
newly created ini file. To restore the VoIP gateway configuration from a previous backup you  
must have a backup of the VoIP gateway information stored on your computer.  
To restore or back up the ini file:  
Open the ‘Configuration File’ screen (Advanced Configuration menu > Configuration  
File); the ‘Configuration File’ screen is displayed.  
Figure 5-19: Configuration File Screen  
To back up the ini file, take these 4 steps:  
1. Click the Get ini File button; the ‘File Download’ window opens.  
2. Click the Save button; the ‘Save As’ window opens.  
3. Navigate to the folder where you want to save the ini file.  
4. Click the Save button; the VoIP gateway copies the ini file into the folder you selected.  
To restore the ini file, take these 4 steps:  
1. Click the Browse button.  
2. Navigate to the folder that contains the ini file you want to load.  
3. Click the file and click the Open button; the name and path of the file appear in the field  
beside the Browse button.  
4. Click the Send ini File button, and click OK in the prompt; the gateway is automatically reset  
(from the cmp version stored on the flash memory).  
Version 4.4  
69  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.9.6 Regional Settings  
The ‘Regional Settings’ screen enables you to set and view the gateway’s internal date and time  
and to load to the gateway the following configuration files: Call Progress Tones, CAS and Voice  
Prompts. For detailed information on the configuration files, refer to Section 7 on page 135.  
To configure the date and time of the Mediant 2000, take these 3 steps:  
1. Open the ‘Regional Settings’ screen (Advanced Configuration menu > Regional  
Settings); the ‘Regional Settings' screen is displayed.  
Figure 5-20: Regional Settings Screen  
2. Enter the time and date where the gateway is installed.  
3. Click the Set Date & Time button; the date and time are automatically updated.  
Note that after performing a hardware reset, the date and time are returned to their defaults and  
should be updated.  
To load a configuration file to the VoIP gateway, take these 8 steps:  
1. Open the ‘Regional Settings’ screen (Advanced Configuration menu > Regional  
Settings); the ‘Regional Settings’ screen is displayed (shown in Figure 5-20).  
2. Click the Browse button adjacent to the file you want to load.  
3. Navigate to the folder that contains the file you want to load.  
4. Click the file and click the Open button; the name and path of the file appear in the field  
beside the Browse button.  
5. Click the Send File button that is next to the field that contains the name of the file you want  
to load. An exclamation mark in the screen section indicates that the file’s loading doesn’t  
take effect on-the-fly (e.g., CPT file).  
6. Repeat steps 2 to 5 for each file you want to load.  
Note 1: Saving a configuration file to flash memory may disrupt traffic on the Mediant  
2000. To avoid this, disable all traffic on the device before saving to flash  
memory.  
Note 2: A device reset is required to activate a loaded CPT file.  
Mediant 2000 SIP User’s Manual  
70  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
7. To save the loaded auxiliary files so they are available after a power fail, refer to Section  
5.12 on page 84.  
8. To reset the Mediant 2000, refer to Section 5.12 on page 84.  
5.9.7 Changing the Mediant 2000 Username and Password  
To prevent unauthorized access to the Mediant 2000, it is recommended that you change the  
username and password (both are case-sensitive) that are used to access the Web Interface.  
To change the username and password, take these 5 steps:  
1. Open the ‘Change Password’ screen (Advanced Configuration menu > Change  
Password); the ‘Change Password’ screen is displayed.  
Figure 5-21: Change Password Screen  
2. In the ‘User Name’ and ‘Password’ fields, enter the new username and the new password  
respectively. Note that the username and password can be a maximum of 7 case-sensitive  
characters.  
3. In the ‘Confirm Password’ field, reenter the new password.  
4. Click the Change Password button; the new username and password are applied and the  
‘Enter Network Password’ screen appears, shown in Figure 5-1 on page 41.  
5. Enter the updated username and password in the ‘Enter Network Password’ screen.  
5.10 Status & Diagnostic  
Use this menu to view and monitor the gateway’s channels, Syslog messages, hardware /  
software product information, and to assess the gateway’s statistics and IP connectivity  
information.  
5.10.1 Gateway Statistics  
Use the screens under Gateway Statistics to monitor real-time activity such as IP Connectivity  
information, call details and call statistics, including the number of call attempts, failed calls, fax  
calls, etc.  
Note: The Gateway Statistics screens doesn’t refresh automatically. To view updated information  
re-access the screen you require.  
5.10.1.1 IP Connectivity  
The IP Connectivity screen provides you with an online read-only network diagnostic connectivity  
information on all destination IP addresses configured in the Tel to IP Routing table.  
Note: This information is available only if the parameter ‘AltRoutingTel2IPEnable’ (described in  
Table 6-5) is set to 1 (Enable) or 2 (Status Only).  
Version 4.4  
71  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
Note:  
The information in columns ‘Quality Status’ and ‘Quality Info.’ (per IP address)  
is reset if two minutes elapse without a call to that destination.  
To view the IP connectivity information, take these 2 steps:  
1. Set ‘AltRoutingTel2IPEnable’ to 1 or 2.  
2. Open the ‘IP Connectivity’ screen (Status & Diagnostics menu > Gateway Statistics  
submenu > IP Connectivity); the ‘IP Connectivity’ screen is displayed (Figure 5-22).  
Figure 5-22: IP Connectivity Screen  
Table 5-8: IP Connectivity Parameters  
Column Name  
Description  
IP Address  
IP address defined in the destination IP address field in the Tel to IP Routing table.  
or  
IP address that is resolved from the host name defined in the destination IP address field in the  
Tel to IP Routing table.  
Host Name  
Host name (or IP address) defined in the destination IP address field in the Tel to IP Routing  
table.  
Connectivity Method The method according to which the destination IP address is queried periodically (currently  
only by ping).  
Connectivity Status  
Displays the status of the IP address’ connectivity according to the method in the ‘Connectivity  
Method’ field.  
Can be one of the following:  
OK  
Lost  
Fail  
Init  
Disable  
= Remote side responds to periodic connectivity queries.  
= Remote side didn’t respond for a short period.  
= Remote side doesn’t respond.  
= Connectivity queries not started (e.g., IP address not resolved).  
= The connectivity option is disabled (‘AltRoutingTel2IPMode’ equals 0 or 2).  
Quality Status  
Determines the QoS (according to packet loss and delay) of the IP address.  
Can be one of the following:  
Unknown  
OK  
Poor  
= Recent quality information isn’t available.  
Note 1: This field is applicable only if the parameter ‘AltRoutingTel2IPMode’ is set to 2 or 3.  
Note 2: This field is reset if no QoS information is received for 2 minutes.  
Mediant 2000 SIP User’s Manual  
72  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Table 5-8: IP Connectivity Parameters  
Description  
Column Name  
Quality Info.  
Displays QoS information: delay and packet loss, calculated according to previous calls.  
Note 1: This field is applicable only if the parameter ‘AltRoutingTel2IPMode’ is set to 2 or 3.  
Note 2: This field is reset if no QoS information is received for 2 minutes.  
DNS Status  
Can be one of the following:  
DNS Disable  
DNS Resolved  
DNS Unresolved  
5.10.1.2 Call Counters  
The Call Counters screens provide you with statistic information on incoming (IPTel) and  
outgoing (TelIP) calls. The statistic information is updated according to the release reason that  
is received after a call is terminated (during the same time as the end-of-call CDR message is  
sent). The release reason can be viewed in the Termination Reason field in the CDR message.  
For detailed information on each counter, refer to Table 5-9 on page 73.  
You can reset this information by clicking the Reset Counters button.  
To view the IPTel and TelIP Call Counters information:  
Open the Call Counters screen you want to view (Status & Diagnostics menu > Gateway  
Statistics submenu); the relevant Call Counters screen is displayed. Figure 5-23 shows the  
‘TelIP Call Counters’ screen.  
Figure 5-23: TelIP Call Counters Screen  
Table 5-9: Call Counters Description (continues on pages 73 to 74)  
Counter  
Description  
This counter indicates the number of attempted calls.  
It is composed of established and failed calls. The number of established calls is  
represented by the ‘Number of Established Calls’ counter. The number of failed  
calls is represented by the five failed-call counters. Only one of the established /  
failed call counters is incremented every time.  
Number of Attempted  
Calls  
Version 4.4  
73  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Table 5-9: Call Counters Description (continues on pages 73 to 74)  
Description  
Counter  
This counter indicates the number of established calls. It is incremented as a result  
of one of the following release reasons, if the duration of the call is bigger then zero:  
GWAPP_REASON_NOT_RELEVANT (0)  
GWAPP_NORMAL_CALL_CLEAR (16)  
GWAPP_NORMAL_UNSPECIFIED (31)  
And the internal reasons:  
RELEASE_BECAUSE_UNKNOWN_REASON  
RELEASE_BECAUSE_REMOTE_CANCEL_CALL  
RELEASE_BECAUSE_MANUAL_DISC  
Number of Established  
Calls  
RELEASE_BECAUSE_SILENCE_DISC  
RELEASE_BECAUSE_DISCONNECT_CODE  
Note: When the duration of the call is zero, the release reason  
GWAPP_NORMAL_CALL_CLEAR increments the ‘Number of Failed Calls due to  
No Answer’ counter. The rest of the release reasons increment the ‘Number of  
Failed Calls due to Other Failures’ counter.  
This counter indicates the number of calls that failed as a result of a busy line. It is  
incremented as a result of the following release reason:  
GWAPP_USER_BUSY (17)  
Number of Failed Calls  
due to a Busy Line  
This counter indicates the number of calls that weren’t answered. It is incremented  
as a result of one of the following release reasons:  
GWAPP_NO_USER_RESPONDING (18)  
Number of Failed Calls GWAPP_NO_ANSWER_FROM_USER_ALERTED (19)  
due to No Answer  
And (when the call duration is zero) as a result of the following:  
GWAPP_NORMAL_CALL_CLEAR (16)  
RELEASE_BECAUSE_NORMAL_CALL_DROP (internal)  
This counter indicates the number of calls whose destinations weren’t found. It is  
Number of Failed Calls incremented as a result of one of the following release reasons:  
due to No Route  
GWAPP_UNASSIGNED_NUMBER (1)  
GWAPP_NO_ROUTE_TO_DESTINATION (3)  
This counter indicates the number of calls that failed due to mismatched gateway  
Number of Failed Calls capabilities. It is incremented as a result of an internal identification of capability  
due to No Matched  
Capabilities  
mismatch. This mismatch is reflected to CDR via the value of the parameter  
‘DefaultReleaseReason’ (default is GWAPP_NO_ROUTE_TO_DESTINATION (3)),  
or by the GWAPP_SERVICE_NOT_IMPLEMENTED_UNSPECIFIED(79) reason.  
Number of Failed Calls This counter is incremented as a result of calls that fail due to reasons not covered  
due to Other Failures by the other counters.  
Percentage of  
The percentage of established calls from attempted calls.  
Successful Calls  
Average Call Duration  
The average call duration of established calls.  
[sec]  
Attempted Fax Calls  
This counter indicates the number of attempted fax calls.  
Counter  
Successful Fax Calls  
This counter indicates the number of successful fax calls.  
Counter  
Mediant 2000 SIP User’s Manual  
74  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.10.2 Monitoring the Mediant 2000 Trunks & Channels  
The Trunk & Channel Status screen provides real time monitoring on the current status of the  
Mediant 2000 trunks & channels.  
To monitor the status of the trunks and B-channels take this step:  
Open the ‘Trunk & Channel Status’ screen (Status & Diagnostics menu > Channel  
Status); the ‘Trunk & Channel Status’ screen is displayed.  
Figure 5-24: Mediant 2000 Trunk & Channel Status Screen  
The number of trunks and channels that appear on the screen depends on the system  
configuration. The example above depicts a system with 8 T1 spans.  
The trunk and channel status indicators appear colored. Figure 5-25 shows the possible  
indicators and their descriptions.  
Figure 5-25: Trunk and Channel Status Color Indicator Keys  
To monitor the details of a specific channel, take these 2 steps:  
1. Click the numbered icon of the specific channel whose detailed status you need to  
check/monitor; the channel-specific Channel Status screen appears, shown in Figure 5-26.  
Version 4.4  
75  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
2. Click the submenu links to check/view a specific channel’s parameter settings.  
Figure 5-26: Channel Status Details Screen  
5.10.3 Activating the Internal Syslog Viewer  
The Message Log screen displays Syslog debug messages sent by the gateway.  
Note that it is not recommended to keep a ‘Message Log’ session open for a prolonged period  
(refer to the Note below). For prolong debugging use an external Syslog server, refer to Section  
Refer to the Debug Level parameter ‘GwDebugLevel’ (described in Table 6-1) to determine the  
Syslog logging level.  
To activate the Message Log, take these 4 steps:  
1. In the General Parameters screen under Advanced Parameters submenu (accessed from  
the Protocol Management menu), set the parameter ‘Debug Level’ to 5. This parameter  
determines the Syslog logging level, in the range 0 to 5, where 5 is the highest level.  
2. Open the ‘Message Log’ screen (Status & Diagnostics menu > Message Log); the  
‘Message Log’ screen is displayed.  
Figure 5-27: Message Log Screen  
Mediant 2000 SIP User’s Manual  
76  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
3. Select the messages, copy them and paste them into a text editor such as Notepad. Send  
this txt file to our Technical Support for diagnosis and troubleshooting.  
4. To clear the screen of messages, click on the submenu Message Log; the screen is cleared  
and new messages begin appearing.  
Tip:  
Do not keep the ‘Message Log’ screen minimized for a prolonged period as a  
prolonged session may cause the Mediant 2000 to overload. As long as the  
screen is open (even if minimized), a session is in progress and messages  
are sent. Closing the screen (and accessing another) stops the messages  
and terminates the session.  
5.10.4 System Information  
The System Information screen displays specific hardware and software product information. This  
information can help you to expedite any troubleshooting process. Capture the screen and email  
it to ‘our’ Technical Support personnel to ensure quick diagnosis and effective corrective action.  
From this screen you can also view and remove any loaded auxiliary files used by the Mediant  
2000 (stored in the RAM).  
To access the System Information screen:  
Open the ‘System Information’ screen (Status & Diagnostics menu > System  
Information); the ‘System Information’ screen is displayed.  
Figure 5-28: System Information Screen  
To delete any of the loaded auxiliary files, take these 3 steps:  
1. Press the Delete button to the right of the files you want to delete. Deleting a file takes effect  
only after the Mediant 2000 is reset.  
2. Click the Reset button on the main menu bar; the Reset screen is displayed.  
3. Select the Burn option and click the Reset button. The Mediant 2000 is reset and the  
auxiliary files you chose to delete are discarded.  
Version 4.4  
77  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.11 Software Update Menu  
The ‘Software Update’ menu enables users to upgrade the Mediant 2000 software by loading a  
new cmp file along with the ini and a suite of auxiliary files, or to update the existing auxiliary files.  
The ‘Software Update’ menu comprises two submenus:  
Software Update Wizard (refer to Section 5.11.1 below).  
Auxiliary Files (refer to Section 5.11.2 on page 82).  
Note:  
When upgrading the Mediant 2000 software you must load the new cmp file  
with all other related configuration files  
5.11.1 Software Upgrade Wizard  
The Software Upgrade Wizard guides users through the process of software upgrade: selecting  
files and loading them to the gateway. The wizard also enables users to upgrade software while  
maintaining the existing configuration. Using the wizard obligates users to load a cmp file. Users  
can choose to also use the Wizard to load the ini and auxiliary files (e.g., Call Progress Tones)  
but this option cannot be pursued without loading the cmp file. For the ini and each auxiliary file  
type, users can choose to reload an existing file, load a new file or not load a file at all.  
Warning 1: The Software Upgrade Wizard requires the Mediant 2000 to be reset at  
the end of the process, disrupting any of its traffic. To avoid disruption,  
disable all traffic on the Mediant 2000 before initiating the Wizard.  
Warning 2: Verify, prior to clicking the Start Software Upgrade button that no traffic is  
running on the device. After clicking this button a device reset is  
mandatory. Even if you choose to cancel the process in the middle, the  
device resets itself and the previous configuration burned to flash is  
reloaded.  
To use the Software Upgrade Wizard, take these 9 steps:  
1. Stop all traffic on the Mediant 2000 (refer to the note above).  
2. Open the ‘Software Upgrade Wizard’ (Software Update menu > Software Upgrade  
Wizard); the ‘Start Software Upgrade’ screen appears.  
Figure 5-29: Start Software Upgrade Screen  
Mediant 2000 SIP User’s Manual  
78  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
Note: At this point, the process can be canceled with no consequence to the Mediant  
2000 (click the Cancel button). If you continue the process (by clicking the  
Start Software Upgrade button, the process must be followed through and  
completed with a Mediant 2000 reset at the end. If you click the Cancel button  
in any of the subsequent screens, the Mediant 2000 is automatically reset with  
the configuration that was previously burned in flash memory.  
3. Click the Start Software Upgrade button; the ‘Load a cmp file’ screen appears (Figure  
Note: When in the Wizard process, the rest of the Web application is unavailable and  
the background Web screen is disabled. After the process is completed,  
access to the full Web application is restored.  
Figure 5-30: Load a cmp File Screen  
4. Click the Browse button, navigate to the cmp file and click the button Send File; the cmp file  
is loaded to the Mediant 2000 and you’re notified as to a successful loading (refer to Figure  
Figure 5-31: cmp File Successfully Loaded into the Mediant 2000 Notification  
5. Note that the four action buttons (Cancel, Reset, Back, and Next) are now activated  
(following cmp file loading).  
You can now choose to either:  
Click Reset; the Mediant 2000 resets, utilizing the new cmp you loaded and utilizing the  
current configuration files.  
Version 4.4  
79  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Click Cancel; the Mediant 2000 resets utilizing the cmp, ini and all other configuration  
files that were previously stored in flash memory. Note that these are NOT the files you  
loaded in the previous Wizard steps.  
Click Back; the ‘Load a cmp File’ screen is reverted to; refer to Figure 5-30.  
Click Next; the ‘Load an ini File’ screen opens; refer to Figure 5-32. Loading a new ini  
file or any other auxiliary file listed in the Wizard is optional.  
Note that as you progress, the file type list on the left indicates which file type loading is in  
process by illuminating green (until ‘FINISH’).  
Figure 5-32: Load an ini File Screen  
6. In the ‘Load an ini File’ screen, you can now choose to either:  
Click Browse and navigate to the ini file; the check box ‘Use existing configuration’, by  
default checked, becomes unchecked. Click Send File; the ini file is loaded to the  
Mediant 2000 and you’re notified as to a successful loading.  
Ignore the Browse button (its field remains undefined and the check box ‘Use existing  
configuration’ remains checked by default).  
Ignore the Browse button and uncheck the ‘Use existing configuration’ check box; no ini  
file is loaded, the Mediant 2000 uses its factory-preconfigured values.  
You can now choose to either:  
Click Cancel; the Mediant 2000 resets utilizing the cmp, ini and all other configuration  
files that were previously stored in flash memory. Note that these are NOT the files you  
loaded in the previous Wizard steps.  
Click Reset; the Mediant 2000 resets, utilizing the new cmp and ini file you loaded up to  
now as well as utilizing the other configuration files.  
Click Back; the ‘Load a cmp file’ screen is reverted to; refer to Figure 5-30.  
Click Next; the ‘Load a CPT File’ screen opens, refer to Figure 5-33; Loading a new  
CPT file or any other auxiliary file listed in the Wizard is optional.  
Mediant 2000 SIP User’s Manual  
80  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
Figure 5-33: Load a CPT File Screen  
7. Follow the same procedure you followed when loading the ini file (refer to Step 6). The same  
procedure applies to the ‘Load a VP file’ (not applicable to the Mediant 2000 gateway)  
screen and ‘Load a coefficient file’ screen.  
8. In the ‘FINISH’ screen (refer to Figure 5-34), the Next button is disabled. Complete the  
upgrade process by clicking Reset or Cancel.  
Button  
Result  
Reset  
The Mediant 2000 ‘burns’ the newly loaded files to flash memory. The ‘Burning files to flash  
memory’ screen appears. Wait for the ‘burn’ to finish. When it finishes, the ‘End Process’  
screen appears displaying the burned configuration files (refer to Figure 5-35).  
Cancel  
The Mediant 2000 resets, utilizing the files previously stored in flash memory. (Note that  
these are NOT the files you loaded in the previous Wizard steps).  
Figure 5-34: FINISH Screen  
Version 4.4  
81  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Figure 5-35: ‘End Process’ Screen  
9. Click the End Process button; the ‘Quick Setup’ screen appears and the full Web application  
is reactivated.  
5.11.2 Auxiliary Files  
The ‘Auxiliary Files’ screen enables you to load to the gateway the following files: CAS, Call  
Progress Tones, Voice Prompts and Prerecorded Tones (PRT). For detailed information on these  
files, refer to Section 7 on page 135. For information on deleting these files from the Mediant  
2000, refer to Section 5.10.4 on page 77.  
Table 5-10 presents a brief description of each auxiliary file.  
Table 5-10: Auxiliary Files Descriptions  
Description  
File Type  
CAS  
Up to 8 different CAS files containing specific CAS protocol definitions.  
These files are provided to support various types of CAS signaling.  
Voice Prompts  
The voice announcement file contains a set of Voice Prompts to be played by the  
Mediant 2000 during operation.  
Applicable only to the VXML application.  
Call Progress Tones  
Prerecorded Tones  
This is a region-specific, telephone exchange-dependent file that contains the  
Call Progress Tones levels and frequencies that the VoIP gateway uses. The  
default CPT file is: U.S.A.  
The dat PRT file enhances the gateway’s capabilities of playing a wide range of  
telephone exchange tones that cannot be defined in the Call Progress Tones file.  
To load an auxiliary file to the gateway, take these 8 steps:  
1. Open the ‘Auxiliary Files’ screen (Software Upgrade menu > Load Auxiliary Files); the  
‘Auxiliary Files’ screen is displayed.  
Mediant 2000 SIP User’s Manual  
82  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
5. Web Management  
Figure 5-36: Auxiliary Files Screen  
2. Click the Browse button that is in the field for the type of file you want to load.  
3. Navigate to the folder that contains the file you want to load.  
4. Click the file and click the Open button; the name and path of the file appear in the field  
beside the Browse button.  
5. Click the Send File button that is next to the field that contains the name of the file you want  
to load. An exclamation mark in the screen section indicates that the file’s loading doesn’t  
take effect on-the-fly (e.g., CPT file).  
6. Repeat steps 2 to 5 for each file you want to load.  
Note 1: Saving an auxiliary file to flash memory may disrupt traffic on the Mediant  
2000. To avoid this, disable all traffic on the device before saving to flash  
memory.  
Note 2: A device reset is required to activate a loaded CPT file, and may be required  
for the activation of certain ini file parameters.  
7. To save the loaded auxiliary files so they are available after a power fail, refer to Section  
5.12 on page 84.  
8. To reset the Mediant 2000, refer to Section 5.12 on page 83.  
5.11.3 Updating the Software Upgrade Key  
Mediant 2000 gateways are supplied with a Software Upgrade Key already pre-configured for  
each of its TrunkPack Modules (TPM).  
Users can later upgrade their Mediant 2000 features, capabilities and quantity of available  
resources by specifying what upgrades they require, and purchasing a new key to match their  
specification.  
The Software Upgrade Key is sent as a string in a text file, to be loaded into the Mediant 2000.  
Stored in the device’s non-volatile flash memory, the string defines the features and capabilities  
allowed by the specific key purchased by the user. The device allows users to utilize only these  
features and capabilities. A new key overwrites a previously installed key.  
For detailed information on the Software Upgrade Key, refer to Appendix H on page 223.  
Version 4.4  
83  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5.12 Save Configuration  
The Save Configuration screen enables users to save the current parameter configuration and  
the loaded auxiliary files to the non-volatile memory so they are available after a power fail.  
Parameters that are only saved to the volatile memory revert to their previous settings after  
hardware reset.  
Note that when performing a software reset (i.e., via Web or SNMP) you can choose to save the  
changes to the non-volatile memory. Therefore, there is no need to use the Save Configuration  
screen.  
Note:  
Saving changes to the non-volatile memory may disrupt traffic on the gateway.  
To avoid this, disable all traffic before saving.  
To save the changes to the non-volatile, take these 2 steps:  
1. Click the Save Configuration button on the main menu bar; the ‘Save Configuration’ screen  
is displayed.  
Figure 5-37: Save Configuration Screen  
2. Click the Save Configuration button in the middle of the screen; a confirmation message  
appears when the save is complete.  
Mediant 2000 SIP User’s Manual  
84  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
5. Web Management  
5.13 Resetting the Mediant 2000  
The Reset screen enables you to remotely reset the gateway. Before reset you can choose to  
save the gateway configuration to flash memory.  
To reset the Mediant 2000, take these 3 steps:  
1. Click the Reset button on the main menu bar; the Reset screen is displayed.  
Figure 5-38: Reset Screen  
2. Select one of the following options:  
Burn - (default) the current configuration is burned to flash prior to reset.  
Don’t Burn - resets the device without burning the current configuration to flash  
(discards all modifications to the configuration).  
3. Click the Reset button. If the Burn option is selected, all configuration changes are saved to  
flash memory. If the Don’t Burn option is selected, all configuration changes are discarded.  
The device is shut down and re-activated. A message about the waiting period is displayed.  
The screen is refreshed.  
Note:  
When Gatekeeper is used, the gateway issues an Unregister request before it  
is reset (either from the Embedded Web Server, SNMP or BootP).  
Version 4.4  
85  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
86  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
6 ini File Configuration of the Mediant 2000  
As an alternative to configuring the VoIP gateway using the Web Interface (refer to Section 5 on  
page 39), it can be configured by loading the ini file containing Customer-configured parameters.  
The ini file is loaded via the BootP/TFTP utility (refer to Appendix B on page 189) or via any  
standard TFTP server. It can also be loaded through the Web Interface (refer to Section 5.9.5 on  
page 69).  
The ini file configuration parameters are stored in the Mediant 2000 non-volatile memory after the  
file is loaded. When a parameter is missing from the ini file, a default value is assigned to that  
parameter (according to the cmp file loaded on the Mediant 2000) and stored in the non-volatile  
memory (thereby overriding the value previously defined for that parameter). Therefore, to restore  
the default configuration parameters, use the ini file without any valid parameters or with a  
semicolon (;) preceding all lines in the file.  
Some of the Mediant 2000 parameters are configurable through the ini file only (and not via the  
Web). These parameters usually determine a low-level functionality and are seldom changed for  
a specific application.  
6.1 Secured ini File  
The ini file contains sensitive information that is required for the functioning of the Mediant 2000.  
It is loaded to, or retrieved from, the device via TFTP or HTTP. These protocols are unsecured  
and vulnerable to potential hackers. Therefore an encoded ini file significantly reduces these  
threats.  
You can choose to load an encoded ini file to the Mediant 2000. When you load an encoded ini  
file, the retrieved ini file is also encoded. Use the ‘TrunkPack Downloadable Conversion Utility’ to  
encode or decode the ini file before you load it to, or retrieve it from, the device. Note that the  
encoded ini file’s loading procedure is identical to the regular ini file’s loading procedure. For  
information on encoding / decoding an ini file, refer to Section G.1.3 on page 217.  
6.2 Modifying an ini File  
To modify the ini file, take these 3 steps:  
1. Get the ini file from the gateway using the Embedded Web Server (refer to Section 5.9.5 on  
page 69).  
2. Open the file (the file opens in Notepad or a Customer-defined text file editor) and modify the  
ini file parameters according to your requirements. Save and close the file.  
3. Load the modified ini file to the gateway (using either the BootP/TFTP utility or the  
Embedded Web Server).  
This method preserves the programming that already exists in the device, including special  
default values that were preconfigured when the unit was manufactured.  
Tip:  
Before loading the ini file to the gateway, verify that the extension of the ini  
file saved on your PC is correct: Verify that the check box ‘Hide file extension  
for known file types’ (My computer>Tools>Folder Options>View) is  
unchecked. Then, confirm that the ini file name extension is xxx.ini and NOT  
erroneously xxx.ini.ini or xxx~.ini.  
Version 4.4  
87  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
6.3 The ini File Content  
The ini file contains the following SIP gateway information:  
Basic, Logging, Web and RADIUS parameters shown in Table 6-1 on page 90.  
SNMP parameters shown in Table 6-2 on page 98.  
SIP Configuration parameters shown in Table 6-3 on page 100.  
ISDN and CAS Interworking-Related Parameters shown in Table 6-4 on page 111.  
Number Manipulation and Routing parameters shown in Table 6-5 on page 115.  
E1/T1 Configuration Parameters shown in Table 6-6 on page 122.  
Channel Parameters shown in Table 6-7 on page 128.  
Configuration Files parameters shown in Section 6.12.1 on page 132.  
6.4 The ini File Structure  
The ini file can contain any number of parameters. The parameters are divided into groups by  
their functionality. The general form of the ini file is shown in Figure 6-1 below.  
Figure 6-1: ini File Structure  
[Sub Section Name]  
Parameter_Name = Parameter_Value  
Parameter_Name = Parameter_Value  
; REMARK  
[Sub Section Name]  
6.4.1 The ini File Structure Rules  
Lines beginning with a semi-colon ‘;’ (as the first character) are ignored.  
A Carriage Return must be the final character of each line.  
The number of spaces before and after "=" is not relevant.  
If there is a syntax error in the parameter name, the value is ignored.  
Syntax errors in the parameter value field can cause unexpected errors (because  
parameters may be set to the wrong values).  
Sub-section names are optional.  
String parameters, representing file names, for example CallProgressTonesFileName, must  
be placed between two inverted commas (‘…’).  
The parameter name is NOT case-sensitive; the parameter value is NOT case-sensitive  
except for coder names.  
The ini file should be ended with one or more carriage returns.  
Mediant 2000 SIP User’s Manual  
88  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
6.5 The ini File Example  
Figure 6-2 shows an example of an ini file for the VoIP gateway.  
Figure 6-2: SIP ini File Example  
PCMLawSelect = 1  
ProtocolType = 1  
TerminationSide = 0  
FramingMethod = 0  
LineCode = 2  
TDMBusClockSource = 4  
ClockMaster = 0  
;Channel Params  
DJBufferMinDelay = 75  
RTPRedundancyDepth = 1  
IsProxyUsed = 1  
ProxyIP = 192.168.122.179  
CoderName = g7231,90  
;List of serial B-channel numbers  
TrunkGroup_1 = 0/1-24,1000  
TrunkGroup_2 = 1/1-24,2000  
TrunkGroup_3 = 2/1-24,3000  
TrunkGroup_4 = 3/1-24,4000  
EnableSyslog = 1  
SyslogServerIP = 10.2.2.1  
CallProgressTonesFilename = 'CPUSA.dat'  
;CASFileName = ‘E_M_WinkTable.dat’  
SaveConfiguration = 1  
Version 4.4  
89  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
6.6 Basic, Logging, Web and RADIUS Parameters  
Note: In Table 6-1, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
EthernetPhyConfiguration  
0 = 10 Base-T half-duplex  
1 = 10 Base-T full-duplex  
2 = 100 Base-TX half-duplex  
3 = 100 Base-TX full-duplex  
4 = auto-negotiate (Default)  
Auto-negotiate falls back to half-duplex mode (HD) when the opposite port is not in  
auto-negotiate, but the speed (10 Base-T, 100 Base -TX) in this mode is always  
configured correctly.  
DHCPEnable  
[Enable DHCP]  
0 = Disable DHCP support on the gateway (default).  
1 = Enable DHCP support on the gateway.  
After the gateway is powered up, it attempts to communicate with a BootP server. If a  
BootP server is not responding and if DHCP is enabled, then the gateway attempts to  
get its IP address and other network parameters from the DHCP server.  
Web Note: After you enable the DHCP Server (from the Web browser) follow this  
procedure:  
Click the Submit button.  
Save the configuration using the ‘Save Configuration’ button (before you reset  
the gateway). For information on how to save the configuration, refer to Section  
5.12 on page 84.  
Reset the gateway directly (Web reset doesn’t trigger the BootP/DHCP  
procedure and the parameter DHCPEnable reverts to ‘0’).  
Note that throughout the DHCP procedure the BootP/TFTP application must be  
deactivated. Otherwise, the gateway receives a response from the BootP server  
instead of the DHCP server.  
Note: The DHCPEnable is a special "Hidden" parameter. Once defined and saved in  
flash memory, its assigned value doesn’t revert to its default even if the parameter  
doesn't appear in the ini file.  
EnableDiagnostics  
0 = No diagnostics (default)  
1 = Perform diagnostics  
EnableLanWatchDog  
[Enable LAN Watchdog]  
0 = Disable LAN Watch-Dog (default).  
1 = Enable LAN Watch-Dog.  
If LAN Watch-Dog is enabled, the gateway restarts when a network failure is  
detected.  
DNSPriServerIP  
[DNS Primary Server IP]  
IP address of the primary DNS server in dotted format notation.  
IP address of the secondary DNS server in dotted format notation.  
DNSSecServerIP  
[DNS Secondary Server IP]  
Mediant 2000 SIP User’s Manual  
90  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
DNS2IP  
[Internal DNS Table]  
Internal DNS table, used to resolve host names to IP addresses. Two different IP  
addresses (in dotted format notation) can be assigned to a hostname.  
DNS2IP = <Hostname>, <first IP address>, <second IP address>  
Note 1: If the internal DNS table is configured, the gateway first tries to resolve a  
domain name using this table. If the domain name isn’t found, the gateway performs  
a DNS resolution using an external DNS server.  
Note 2: This parameter can appear up to 10 times.  
GWAppDelayTime  
[Delay After Reset [sec]]  
Defines the amount of time (in seconds) the gateway’s operation is delayed after a  
reset cycle.  
The valid range is 0 to 600. The default value is 5 seconds.  
Note: This feature helps to overcome connection problems caused by some LAN  
routers or IP configuration parameters change by a DHCP Server.  
DisableNAT  
Enables / disables the Network Address Translation (NAT) mechanism.  
0 = Enabled.  
1 = Disabled (default).  
Note: The compare operation that is performed on the IP address is enabled by  
default and is controlled by the parameter ‘EnableIPAddrTranslation’. The compare  
operation that is performed on the UDP port is disabled by default and is controlled  
by the parameter ‘EnableUDPPortTranslation’.  
EnableIPAddrTranslation  
0 = Disable IP address translation.  
1 = Enable IP address translation (default).  
When enabled, the gateway compares the source IP address of the first incoming  
packet, to the remote IP address stated in the opening of the channel. If the two IP  
addresses don’t match, the NAT mechanism is activated. Consequently, the remote  
IP address of the outgoing stream is replaced by the source IP address of the first  
incoming packet.  
Note: The NAT mechanism must be enabled for this parameter to take effect  
(DisableNAT = 0).  
EnableUDPPortTranslation  
0 = Disable UDP port translation (default).  
1 = Enable UDP port translation.  
When enabled, the gateway compares the source UDP port of the first incoming  
packet, to the remote UDP port stated in the opening of the channel. If the two UDP  
ports don’t match, the NAT mechanism is activated. Consequently, the remote UDP  
port of the outgoing stream is replaced by the source UDP port of the first incoming  
packet.  
Note: The NAT mechanism and the IP address translation must be enabled for this  
parameter to take effect (DisableNAT = 0, EnableIpAddrTranslation = 1).  
StaticNATIP  
Static NAT IP address.  
[NAT IP Address]  
Global gateway IP address. Define if static Network Address Translation (NAT)  
device is located between the gateway and the Internet.  
SyslogServerIP  
[Syslog Server IP Address]  
IP address (in dotted format notation) of the computer you are using to run the Syslog  
Server.  
The Syslog Server is an application designed to collect the logs and error messages  
generated by the VoIP gateway.  
Note: The default UDP Syslog port is 514.  
For information on the Syslog server, refer to Section 9.2 on page 165.  
EnableSyslog  
[Enable Syslog]  
1 = Send the logs and error message generated by the gateway to the Syslog Server.  
If you select 1, you must enter an IP address in the parameter SyslogServerIP.  
0 = Logs and errors are not sent to the Syslog Server (default).  
Note 1: Syslog messages may increase the network traffic.  
Note 2: To configure the Syslog logging levels use the parameter ‘GwDebugLevel’.  
Version 4.4  
91  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
BaseUDPport  
[RTP Base UDP Port]  
Lower boundary of UDP port used for RTP, RTCP (Real-Time Control Protocol) (RTP  
port + 1) and T.38 (RTP port + 2). The upper boundary is the Base UDP Port + 10 *  
(number of gateway’s channels).  
The range of possible UDP ports is 4000 to 64000.  
The default base UDP port is 6000.  
For example:  
If the Base UDP Port is set to 6000 (the default) then:  
The first channel uses the following ports: RTP 6000, RTCP 6001 and T.38 6002,  
the second channel uses: RTP 6010, RTCP 6011 and T.38 6012, etc.  
Note: If RTP Base UDP Port is not a factor of 10, the following message is  
generated: "invalid local RTP port".  
For detailed information on the default RTP/RTCP/T.38 port allocation, refer to  
Section C.3 on page 202.  
IPDiffServ  
[RTP IP Diff. Serv]  
Diff Serv Code Point (DSCP) value that is assigned to the RTP packets. The DSCP  
value is used by DiffServ compatible routers to prioritize how packets are sent. By  
prioritizing packets, the DiffServ routers can minimize the transmission delays for  
time sensitive packets such as VoIP packets.  
The valid range is 0 to 63. The default value is 0.  
Note: The parameter IPDiffServ mustn’t be used simultaneously with the parameters  
IPTOS and IPPrecedence.  
IPPrecedence  
[RTP IP Precedence]  
Value that is assigned to IP Type Of Service (TOS) field in the IP header for all RTP  
packets sent by the VoIP gateway.  
The valid range is 0 to 15. The default value is 0.  
Note: The parameters IPTOS and IPPrecedence mustn’t be used simultaneously  
with the parameter IPDiffServ.  
IPTOS  
[RTP IP TOS]  
Value that is assigned to the IP Precedence field in the IP header for all RTP  
packets sent by the VoIP gateway.  
The valid range is 0 to 7. The default value is 0.  
Note: The parameters IPTOS and IPPrecedence mustn’t be used  
simultaneously with the parameter IPDiffServ.  
MaxEchoCancellerLength  
and  
Maximum Echo Canceler Length in msec:  
0 = Internal decision to keep max channel capacity (currently 32 msec)  
4 = 32 msec  
11 = 64 msec  
EchoCancellerLength  
22 = 128 msec  
The default value is 0.  
Note: Both parameters must be  
set to the same value.  
Note 1: When set to 64 msec or more, the number of available gateway channels is  
reduced (by a factor of 5/6).  
For example:  
Gateway with 8 E1 spans capacity is reduced to 6 spans (180 channels), while  
gateway with 8 T1 spans capacity remains the same (192 channels).  
Note 2: The gateway must be reset after the value of ‘MaxEchoCancellerLength’ is  
changed.  
ECHybridLoss  
Sets the four wire to two wire worst case Hybrid loss, the ratio between the signal  
level sent to the hybrid and the echo level returning from the hybrid.  
0 = 6 dB (default)  
1 = 9 dB  
2 = 0 dB  
3 = 3 dB  
Mediant 2000 SIP User’s Manual  
92  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
GwDebugLevel  
Defines the Syslog logging level (usually set to 5 if debug traces are needed).  
[Debug Level]  
0 = Debug is disabled (default)  
1 = Flow debugging is enabled  
2 = Flow and board interface debugging are enabled  
3 = Flow, board interface and stack interface debugging are enabled  
4 = Flow, board interface, stack interface and session manager debugging are  
enabled  
5 = Flow, board interface, stack interface, session manager and board interface  
expanded debugging are enabled  
CDRReportLevel  
0 = CDR is not used  
[CDR Report Level]  
1 = Call Detail Record is sent to the Syslog server at the end of each call.  
2 = CDR report is send to Syslog at start and at the end of each call  
The CDR Syslog message complies with RFC 3161 and is identified by:  
Facility = 17 (local1) and Severity = 6 (Informational)  
Note: this parameter replaces the previous “EnableCDR” parameter  
CDRSyslogServerIP  
Defines the destination IP address for CDR logs.  
[CDR Server IP Address]  
The default value is a null string that causes the CDR messages to be sent with all  
Syslog messages.  
Note: The CDR messages are sent to UDP port 514 (default Syslog port).  
HeartBeatDestIP  
Destination IP address (in dotted format notation) to which the gateway sends  
proprietary UDP ‘ping’ packets.  
The default IP address is 0.0.0.0.  
HeartBeatDestPort  
HeartBeatIntervalmsec  
Destination UDP port to which the heartbeat packets are sent.  
The range is 0 to 64000.  
The default is 0.  
Delay (in msec) between consecutive heartbeat packets.  
10 = 100000.  
-1 = disabled (default).  
NTPServerIP  
IP address (in dotted format notation) of the NTP server.  
[NTP Server IP Address]  
The default IP address is 0.0.0.0 (the internal NTP client is disabled).  
For information on NTP support, refer to Section 5.9.1.3 on page 63.  
NTPServerUTCOffset  
[NTP UTC Offset]  
Defines the UTC (Universal Time Coordinate) offset (in seconds) from the NTP  
server.  
The default offset is 0. The offset range is –43200 to 43200 seconds.  
NTPUpdateInterval  
[NTP Update Interval]  
Defines the time interval (in seconds) the NTP client requests for a time update.  
The default interval is 86400 seconds (24 hours). The range is 0 to 214783647  
seconds.  
Note: It isn’t recommended to be set beyond one month (2592000 seconds).  
EnableRAI  
0 = Disable RAI (Resource Available Indication) service (default).  
1 = Enable RAI service.  
If RAI is enabled, an SNMP ‘acBoardCallResourcesAlarm’ Alarm Trap is sent if  
gateway resources fall below a predefined (configurable) threshold.  
RAIHighThreshold  
High Threshold (in percentage) that defines the gateway‘s busy endpoints.  
The range is 0 to 100.  
The default value is 90%.  
When the percentage of the gateway‘s busy endpoints exceeds the value configured  
in High Threshold, the gateway sends an SNMP ‘acBoardCallResourcesAlarm’  
Alarm Trap with a ‘major’ Alarm Status.  
Note: The gateway’s available Resources are calculated by dividing the number of  
busy endpoints by the total number of available gateway endpoints.  
Version 4.4  
93  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
RAILowThreshold  
Low Threshold (in percentage) that defines the gateway‘s busy endpoints.  
The range is 0 to 100.  
The default value is 90%.  
When the percentage of the gateway’s busy endpoints falls below the value defined  
in Low Threshold, the gateway sends an SNMP ‘acBoardCallResourcesAlarm’ Alarm  
Trap with a ‘cleared’ Alarm Status.  
RAILoopTime  
Time interval (in seconds) that the gateway checks for resource availability.  
The default is 10 seconds.  
Disconnect Supervision Parameters  
DisconnectOnBrokenConnect  
ion  
[Disconnect on Broken  
Connection]  
0 = Don’t release the call.  
1 = Call is released If RTP packets are not received for a predefined timeout  
(default).  
Note 1: If enabled, the timeout is set by the parameter  
‘BrokenConnectionEventTimeout’, in 100 msec resolution. The default timeout is 10  
seconds: (BrokenConnectionEventTimeout =100).  
Note 2: This feature is applicable only if RTP session is used without Silence  
Compression. If Silence Compression is enabled, the Gateway doesn’t detect that  
the RTP connection is broken.  
Note 3: During a call, if the source IP address (from where the RTP packets were  
sent) is changed without notifying the Gateway, the Gateway will filter these RTP  
packets. To overcome this issue, set ‘DisconnectOnBrokenConnection=0’; the  
Gateway doesn’t detect RTP packets arriving from the original source IP address,  
and will switch (after 300 msec) to the RTP packets arriving from the new source IP  
address.  
BrokenConnectionEventTime The amount of time (in 100 msec units) an RTP packets isn’t received, after which a  
out  
call is disconnected.  
[Broken Connection Timeout]  
The valid range is 1 to 1000. The default value is 100 (10 seconds).  
Note 1: Applicable only if ‘DisconnectOnBrokenConnection = 1’.  
Note 2: Currently this feature works only if Silence Suppression is disabled.  
EnableSilenceDisconnect  
[Disconnect Call on Silence  
Detection]  
1 = The gateway disconnect calls in which silence occurs in both (call) directions for  
more than 120 seconds.  
0 = Call is not disconnected when silence is detected (default).  
The silence duration can be set by the ‘FarEndDisconnectSilencePeriod’ parameter  
(default 120).  
Note: To activate this feature set: ‘EnableSilenceCompression’ to 1 and  
‘FarEndDisconnectSilenceMethod’ to 1.  
FarEndDisconnectSilencePeri Duration of silence period (in seconds) prior to call disconnection.  
od  
The range is 10 to 28800 (8 hours). The default is 120 seconds.  
Applicable to gateways, that use DSP templates 2 or 3.  
[Silence Detection Period]  
FarEndDisconnectSilenceMet Silence detection method.  
hod  
0 (None) = Silence detection option is disabled.  
[Silence Detection Method]  
1 (Packets Count) = According to packet count.  
2 (Voice/Energy Detectors) = N/A.  
3 (All) = N/A.  
FarEndDisconnectSilenceThr Threshold of the packet count (in percents), below which is considered silence by the  
eshold  
media gateway.  
The valid range is 1 to 100. The default is 8%.  
Note: Applicable only if silence is detected according to packet count  
(FarEndDisconnectSilenceMethod = 1).  
Web-Related Parameters  
DisableWebTask  
0 = Enable Web management (default)  
1 = Disable Web management  
Mediant 2000 SIP User’s Manual  
94  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ResetWebPassword  
Allows resetting to default of Web password to:  
Username: “Admin”  
Password: “Admin”  
DisableWebConfig  
HTTPport  
0 = Enable changing parameters from Web (default)  
1 = Operate Web Server in “read only” mode  
HTTP port used for Web management (default = 80)  
Customizing the Web Appearance Parameters  
For detailed information on customizing the Web Interface, refer to Appendix F on page 207.  
UseProductName  
0 = Disabled (default).  
1 = Enabled.  
If enabled, the ‘UserProductNane’ text string is displayed instead of the default  
product name.  
UserProductName  
UseWebLogo  
Text string that replaces the product name.  
The default is “Mediant 2000”.  
The string can be up to 29 characters.  
0 = Logo image is used (default).  
1 = Text string is used instead of a logo image.  
If enabled, AudioCodes’ default logo (or any other logo defined by the  
‘LogoFileName’ parameter) is replaced with a text string defined by the  
‘WebLogoText’ parameter.  
WebLogoText  
LogoWidth  
Text string that replaces the logo image.  
The string can be up to 15 characters.  
Width (in pixels) of the logo image.  
Note: The optimal setting depends on the resolution settings.  
The default value is 441, which is the width of AudioCodes’ displayed logo.  
LogoFileName  
Name of the image file containing the user’s logo.  
File name can be up to 47 characters.  
The logo file name can be used to replace AudioCodes’ default Web logo with a User  
defined logo.  
Use a gif, jpeg or jpg image file.  
BkgImageFileName  
RADIUS-Related Parameters  
Name of the file containing the user’s background image.  
File name can be up to 47 characters.  
The background file can be used to replace AudioCodes’ default background image  
with a User defined background.  
Use a gif, jpeg or jpg image file.  
For detailed information on the supported RADIUS attributes, refer to Section K.7 on page 251.  
EnableRADIUS  
[Enable RADIUS]  
0 = RADIUS application is disabled (default).  
1 = RADIUS application is enabled.  
AAAIndications  
[AAA Indications]  
0 = No indications (default).  
3 = Accounting only  
MaxRADIUSSessions  
[Max. RADIUS Sessions]  
Number of concurrent calls that can communicate with the RADIUS server (optional).  
The valid range is 0 to 240.  
The default value is 240.  
SharedSecret  
[Shared Secret]  
“Secret” used to authenticate the gateway to the RADIUS server. It should be a  
cryptographically strong password.  
RADIUSRetransmission  
[RADIUS Max.  
Retransmissions]  
Number of retransmission retries.  
The valid range is 1 to 10.  
The default value is 3.  
RadiusTO  
The interval between each retry (measured in seconds).  
The valid range is 1 to 30.  
The default value is 10.  
RADIUSAuthServerIP  
[RADIUS Authentication Server IP address of Authentication and Authorization server.  
IP Address]  
Version 4.4  
95  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
RADIUSAuthPort  
[RADIUS Authentication Port]  
Port number of Authentication and Authorization server.  
The default value is 1645.  
RADIUSAccServerIP  
[RADIUS Accounting Server IP  
Address]  
IP address of accounting server.  
RADIUSAccPort  
[RADIUS Accounting Port]  
Port number of Radius accounting server.  
The default value is 1646.  
RadiusAccountingType  
[RADIUS Accounting Type]  
Determines when a RADIUS accounting report is issued.  
0 = At the Release of the call only (default).  
1 = At the Connect and Release of the call.  
2 = At the Setup and Release of the call.  
BootP and TFTP Parameters  
IniFileURL  
Specifies the name of the ini file and the location of the TFTP server from which the  
gateway loads the ini and configuration files.  
For example:  
tftp://192.168.0.1/filename  
tftp://192.10.77.13/config<MAC>  
Note: The optional string “<MAC>” is replaced with the gateway’s MAC address.  
Therefore, the gateway requests an ini file name that contains its MAC address. This  
option enables loading different configurations for specific gateways.  
CmpFileURL  
Specifies the name of the cmp file and the location of the TFTP server from which the  
gateway loads a new cmp file and updates itself.  
For example: tftp://192.168.0.1/filename  
Note 1: When this parameter is set in the ini file, the gateway always loads the cmp  
file after it is reset.  
Note 2: The version of the loaded cmp file isn’t checked.  
The BootP parameters are special "Hidden" parameters. Once defined and saved in the flash memory, they are used  
even if they don't appear in the ini file.  
BootPRetries  
BootP retries. Sets the number of BootP requests the device sends during start-up.  
The device stops sending BootP requests when either BootP reply is received or  
Number of Retries is reached.  
1 = 1 BootP retry, 1 second.  
2 = 2 BootP retries, 3 second.  
3 = 3 BootP retries, 6 second (default).  
4 = 10 BootP retries, 30 second.  
5 = 20 BootP retries, 60 second.  
6 = 40 BootP retries, 120 second.  
7 = 100 BootP retries, 300 second.  
15 = BootP retries indefinitely.  
Note: This parameter only takes effect from the next reset of the device.  
BootPSelectiveEnable  
Enables the Selective BootP mechanism.  
1 = Enabled.  
0 = Disabled (default).  
The Selective BootP mechanism enables the gateway’s integral BootP client to filter  
unsolicited BootP/DHCP replies (accepts only BootP replies that contain the text  
“AUDC" in the vendor specific information field). This option is useful in environments  
where enterprise BootP/DHCP servers provide undesired responses to the gateway’s  
BootP requests.  
Note: When working with DHCP (EnableDHCP=1) the selective BootP feature must  
be disabled.  
Mediant 2000 SIP User’s Manual  
96  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-1: Basic, Logging, Web and RADIUS Parameters (continues on pages 90 to 97)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
BootPDelay  
The interval between the device’s startup and the first BootP/DHCP request that is  
issued by the device.  
1 = 1 second (default).  
2 = 3 second.  
3 = 6 second.  
4 = 30 second.  
5 = 60 second.  
Note: This parameter only takes effect from the next reset of the device.  
ExtBootPReqEnable  
0 = Disable (default).  
1 = Enable extended information to be sent in BootP request.  
If enabled, the device uses the vendor specific information field in the BootP request  
to provide device-related initial startup information such as board type, current IP  
address, software version, etc. For a full list of the vendor specific Information fields,  
refer to Section 10.3 on page 169.  
The BootP/TFTP configuration utility displays this information in the ‘Client Info’  
column (refer to Figure B-1).  
Note: This option is not available on DHCP servers.  
Version 4.4  
97  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
6.7 SNMP Parameters  
Note:  
In Table 6-2, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-2: SNMP Parameter (continues on pages 98 to 99)  
ini File Field Name  
Web Parameter Name*  
Valid Range and Description  
DisableSNMP  
0 = SNMP is enabled (default).  
[Enable SNMP]  
1 = SNMP is disabled and no traps are sent.  
SNMPPort  
The device’s local UDP port used for SNMP Get/Set commands.  
The range is 100 to 3999.  
The default port is 161.  
SNMPTrustedMGR_x  
Up to five IP addresses of remote trusted SNMP managers from which the  
SNMP agent accepts and processes get and set requests.  
Note 1: If no values are assigned to these parameters any manager can  
access the device.  
Note 2: Trusted managers can work with all community strings.  
SNMP Trap Parameters  
SNMPManagerTableIP_x  
[SNMP Managers Table]  
Up to five IP addresses of remote hosts that are used as SNMP Managers. The  
device sends SNMP traps to these IP addresses.  
Enter the IP address in dotted format notation, for example 108.10.1.255.  
Note: The first entry (out of the five) replaces the obsolete parameter  
SNMPManagerIP.  
SNMPManagerTrapPort_x  
[SNMP Managers Table]  
Up to five parameters used to define the Port numbers of the remote SNMP  
Managers. The device sends SNMP traps to these ports.  
Note: The first entry (out of the five) replaces the obsolete parameter  
SNMPTrapPort.  
The default SNMP trap port is 162  
The SNMP trap port must be between 100 to 4000.  
SNMPManagerIsUsed_x  
Up to five parameters, each determines the validity of the parameters (IP  
[SNMP Managers Table]  
address and port number) of the corresponding SNMP Manager used to  
receive SNMP traps.  
0 = Disabled (default)  
1 = Enabled  
SNMPManagerTrapSendingEnable_x Up to five parameters, each determines the activation/deactivation of sending  
[SNMP Managers Table]  
traps to the corresponding SNMP Manager.  
0 = Sending is disabled  
1 = Sending is enabled (default)  
SNMPManagerIP  
IP address (in dotted format notation) for the computer that is used as the first  
SNMP Manager. The SNMP Manager is a device that is used for receiving  
SNMP Traps.  
Note: Obsolete parameter, use  
SNMPManagerTableIP_x instead.  
Note 1: To enable the device to send SNMP Traps, set the ini file parameter  
SNMPManagerIsUsed to 1.  
Note 2: If you want to use more than one SNMP manger, ignore this parameter  
and use the parameters ‘SNMPManagerTableIP_x’ instead.  
SNMP Community String Parameters  
SNMPReadOnlyCommunityString_x Read-only community string (up to 19 chars).  
The default string is “public”.  
SNMPReadWriteCommunityString_x Read-write community string (up to 19 chars).  
The default string is “private”.  
SNMPTrapCommunityString_x  
Community string used in traps (up to 19 chars).  
The default string is “trapuser”.  
Mediant 2000 SIP User’s Manual  
98  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-2: SNMP Parameter (continues on pages 98 to 99)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
SetCommunityString  
SNMP community string (up to 19 chars).  
Default community string for read “public”, for set & get “private”.  
Note: Obsolete parameter, use  
SNMPReadWriteCommunityString_x  
instead.  
Version 4.4  
99  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
6.8 SIP Configuration Parameters  
Note:  
In Table 6-3, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ControlIPDiffServ  
[Signaling DiffServ]  
Defines the value of the 'DiffServ' field in the IP header for SIP messages.  
The valid range is 0 to 63. The default value is 0.  
SIPGatewayName  
[Gateway Name]  
Use this parameter to assign a name to the device (For example: ‘gateway1.com’).  
Ensure that the name you choose is the one that the Proxy is configured with to identify  
your media gateway.  
Note: If specified, the gateway Name is used as the host part of the SIP URL, in the  
‘From’ header. If not specified, the gateway IP address is used instead (default).  
IsProxyUsed  
[Enable Proxy]  
0 = Proxy isn’t used, the internal routing table is used instead (default).  
1 = Proxy is used.  
ProxyIP  
[Proxy IP Address]  
IP address (and optionally port number) of the primary Proxy server you are using.  
Enter the IP address as FQDN or in dotted format notation (for example 201.10.8.1).  
You can also specify the selected port in the format: <IP Address>:<port>.  
This parameter is applicable only if you select ‘Yes’ in the ‘Is Proxy Used’ field.  
If you enable Proxy Redundancy (by setting EnableProxyKeepAlive=1), the gateway  
can function with up to three Proxy servers. If there is no response from the primary  
Proxy, the gateway tries to communicate with the redundant Proxies. When a  
redundant Proxy is found, the gateway either continues working with it until the next  
failure occurs or reverts to the primary Proxy (refer to the ‘Redundancy Mode’  
parameter). If none of the Proxy servers respond, the gateway goes over the list again.  
The gateway also provides real time switching (hotswap mode), between the primary  
and redundant proxies (‘IsProxyHotSwap=1’). If the first Proxy doesn’t respond to Invite  
message, the same Invite message is immediately sent to the second Proxy.  
Note 1: If ‘EnableProxyKeepAlive=1’, the gateway monitors the connection with the  
Proxies by using keep-alive messages ("OPTIONS").  
Note 2: To use Proxy Redundancy, you must specify one or more redundant Proxies  
using multiple ’ProxyIP= <IP address>’ definitions.  
Note 3: When port number is specified (e.g., domain.com:5080), DNS SRV queries  
aren’t performed, even if ‘EnableProxySRVQuery’ is set to 1.  
ProxyIP  
ProxyIP  
ProxyIP  
[Redundant Proxy IP  
Address]  
IP addresses of the redundant Proxies you are using.  
Enter the IP address as FQDN or in dotted format notation (for example 192.10.1.255).  
You can also specify the selected port in the format: <IP Address>:<port>.  
Note 1: This parameter is available only if you select “Yes” in the ‘Is Proxy Used’ field.  
Note 2: When port number is specified, DNS SRV queries aren’t performed, even if  
‘EnableProxySRVQuery’ is set to 1.  
ini file note: The IP addresses of the redundant Proxies are defined by the second,  
third and forth repetition of the ini file parameter ‘ProxyIP’.  
ProxyName  
[Proxy Name]  
Home Proxy Domain Name. If specified, the name is used as Request-URI in  
REGISTER, INVITE and other SIP messages.  
If the proxy name isn’t specified, the Proxy IP address is used instead.  
Mediant 2000 SIP User’s Manual  
100  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
EnableProxySRVQuery  
Enables the use of DNS Service Record (SRV) queries to discover Proxy servers.  
[Enable Proxy SRV Queries] 0 = Disabled (default).  
1 = Enabled.  
If enabled and the Proxy IP address parameter contains a domain name without port  
definition (e.g., ProxyIP = domain.com), an SRV query is performed. The SRV query  
returns up to four Proxy host names and their weights. The gateway then performs  
DNS A-record queries for each Proxy host name (according to the received weights) to  
locate up to four Proxy IP addresses. Therefore, if the first SRV query returns two  
domain names, and the A-record queries return 2 IP addresses each, no more  
searches are performed.  
If the Proxy IP address parameter contains a domain name with port definition (e.g.,  
ProxyIP = domain.com:5080), the gateway performs a regular DNS A-record query.  
Note: This mechanism is applicable only if ‘EnableProxyKeepAlive = 1’.  
AlwaysSendToProxy  
0 = Use standard SIP routing rules (default)  
[Always Use Proxy]  
1 = All SIP messages and Responses are sent to Proxy server  
Note: Applicable only if Proxy server is used.  
SendInviteToProxy  
[Send All Invite to Proxy]  
0 = INVITE messages, generated as a result of Transfer or Redirect, are sent directly to  
the URL (according to the refer-to header in the REFER message or contact header in  
30x response) (default).  
1 = All INVITE messages, including those generated as a result of Transfer or Redirect  
are sent to Proxy.  
Note: Applicable only if Proxy server is used and “AlwaysSendtoProxy=0”.  
PreferRouteTable  
[Prefer Routing Table]  
Determines if the local Tel to IP routing table takes precedence over a Proxy for routing  
calls.  
0 = Only Proxy is used to route calls (default).  
1 = The Proxy checks the 'Destination IP Address' field in the 'Tel to IP Routing' table  
for a match with the outgoing call. Only if a match is not found, a Proxy is used.  
Note: Applicable only if Proxy is not always used (‘AlwaysSendToProxy’ = 0,  
‘SendInviteToProxy’ = 0).  
EnableProxyKeepAlive  
0 = Disable (default)  
[Enable Proxy Keep Alive]  
1 = Keep alive with Proxy, by sending "OPTIONS" SIP message every  
“ProxyKeepAliveTime”.  
Note: This parameter must be enabled when Proxy redundancy is used.  
ProxyKeepAliveTime  
[Proxy Keep Alive Time]  
Defines the Proxy keep-alive time interval (in seconds) between OPTIONS messages.  
The default value is 60 seconds.  
UseGatewayNameForOptio 0 = Use the gateway’s IP address in keep-alive OPTIONS messages (default).  
ns  
1 = Use ‘GatewayName’ in keep-alive OPTIONS messages.  
The OPTIONS Request-URI host part contains either the gateway’s IP address or a  
string defined by the parameter ‘Gatewayname’.  
[Use Gateway Name for  
OPTIONS]  
The gateway uses the OPTIONS request as a keep-alive message to its primary and  
redundant Proxies.  
IsProxyHotSwap  
Enable Proxy Hot Swap redundancy mode.  
[Enable Proxy Hotswap]  
0 = Disabled (default)  
1 = Enabled  
If Hot Swap is enabled, SIP INVITE message is first sent to the primary Proxy server. If  
there is no response from the primary Proxy server for “ProxyHotSwapRtx”  
retransmissions, the INVITE message is resent to the redundant Proxy server.  
ProxyHotSwapRtx  
[Number of RTX before  
Hotswap]  
Number of retransmitted INVITE messages before call is routed (hot swap) to another  
Proxy  
Range: 1-30  
The default is 3.  
Note: This parameter is also used for alternative routing using the Tel to IP Routing  
table. If a domain name in the routing table is resolved into 2 IP addresses, and if there  
is no response for ‘ProxyHotSwapRtx’ retransmissions to the Invite message that is  
sent to the first IP address, the gateway immediately initiates a call to the second IP  
address.  
Version 4.4  
101  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ProxyRedundancyMode  
[Redundancy Mode]  
0 = Parking mode: gateway continues working with the last active Proxy until the next  
failure. (default)  
1 = Homing mode: gateway always tries to work with the primary Proxy server  
(switches back to the primary Proxy whenever it is available).  
Note: To use ProxyRedundancyMode, enable Keep-alive with Proxy option  
(EnableProxyKeepAlive=1).  
IsTrustedProxy  
[Is Proxy Trusted]  
This parameter isn’t applicable and must always be set to 1.  
The parameter ‘AssertedIdMode’ should be used instead.  
IsFallbackUsed  
[Enable Fallback to  
Routing Table]  
0 = Gateway fallback is not used (default).  
1 = Internal Telephone to IP Routing table is used when Proxy servers are not  
available.  
When the gateway falls back to the internal Telephone to IP Routing table, the gateway  
continues scanning for a Proxy. When the gateway finds an active Proxy, it switches  
from internal routing back to Proxy routing.  
Note: To enable the redundant Proxies mechanism set ‘EnableProxyKeepAlive’ to 1.  
UserName  
[User Name]  
Username used for Registration and for Basic/Digest authentication process with Proxy  
/ Registrar.  
Parameter doesn’t have a default value (empty string).  
Password  
[Password]  
Password used for Basic/Digest authentication process with Proxy / Registrar.  
The default is “Default_Passwd”.  
Cnonce  
[Cnonce]  
String used by the SIP Server and client to provide mutual authentication (free format,  
i.e., “Cnonce = 0a4f113b”).  
The default is “Default_Cnonce”.  
IsRegisterNeeded  
[Enable Registration]  
0 = Gateway does not register to Proxy/Registrar (default)  
1 = Gateway registers to Proxy/Registrar at power up  
RegistrarIP  
[Registrar IP Address]  
IP address of Registrar server (optional). If not specified, the gateway registers to Proxy  
server.  
RegistrarName  
[Registrar Name]  
Registrar Domain Name.  
If specified, the name is used as Request-URI in Register messages.  
If isn’t specified (default), the Registrar IP address or Proxy name or Proxy IP  
address is used instead.  
GWRegistrationName  
Defines the user name that is used in From and To headers of Register messages.  
[Gateway Registration Name] If ‘GWRegistrationName’ isn’t specified (default), the ’Username’ parameter is used  
instead.  
RegistrationTime  
[Registration Time]  
Registration expired timeout (seconds). The value is used in "Expires = " header.  
Typically a value of 3600 is assigned, for one hour registration.  
The gateway resumes registration when half the defined timeout period expires.  
RegistrationTimeDivider  
[Re-registration Timing (%)]  
Defines the re-registration timing (in percentage). The timing is a percentage of the re-  
register timing set by the Registration server.  
The valid range is 50 to 100. The default value is 50.  
For example: If ‘RegistrationTimeDivider = 70’ (%) and Registration Expires time =  
3600, the gateway resends its registration request after 3600 x 70% = 2520 sec.  
RegistrationRetryTime  
[Registration Retry Time]  
Defines the time period (in seconds) after which a Registration request is resent if  
registration fails with 4xx, or there is no response from the Proxy/Registrar.The default  
is 30 seconds. The range is 10 to 3600.  
PrackMode  
PRACK mechanism mode for 1XX reliable responses:  
[PRACK Mode]  
0 = Disabled  
1 = Supported (default)  
2 = Required  
Note 1: The Supported and Required headers contain the “100rel” parameter.  
Note 2: The Mediant 2000 sends PRACK message if 180/183 response is received  
with “100rel” in the Supported or the Required headers.  
Mediant 2000 SIP User’s Manual  
102  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
AssertedIdMode  
[Asserted Identity Mode]  
0 = None (default).  
1 = P-asserted.  
2 = P-preferred.  
The Asserted ID mode defines the header that is used in the generated INVITE  
request. The header also depends on the calling Privacy: allowed or restricted.  
The P-asserted (or P-preferred) headers are used to present the originating party’s  
Caller ID. The Caller ID is composed of a Calling Number and (optionally) a Calling  
Name.  
P-asserted (or P-preferred) headers are used together with the Privacy header. If Caller  
ID is restricted the “Privacy: id” is included. Otherwise, for allowed Caller ID the  
“Privacy: none” is used. If Caller ID (received from PSTN) is restricted, the From header  
is set to <[email protected]>.  
EnableRPIheader  
0 = Disable (default)  
[Enable Remote Party ID]  
1 = RPI (Remote-Party-ID) headers are generated in SIP INVITE message for both  
called and calling numbers.  
SIPDestinationPort  
[SIP Destination Port]  
SIP UDP destination port for sending SIP messages.  
The default port is 5060.  
LocalSIPPort  
[SIP Local Port]  
Local UDP port used to receive SIP messages.  
The default port is 5060.  
IsUserPhone  
[Use “user=phone” in SIP  
URL]  
0 = Doesn’t use "user=phone" string in SIP URL.  
1 = "user=phone" string is part of the SIP URL (default).  
IsUserPhoneInFrom  
[Use “user=phone” in From  
header]  
0 = Doesn’t use ";user=phone" string in From header (default).  
1 = ";user=phone" string is part of the From header.  
EnablePtime  
0 = Remove the ptime header from SDP.  
1 = Include the ptime header in SDP (default).  
Version 4.4  
103  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
CoderName  
[Coders]  
CoderName = Coder,ptime (can appear up to 5 times)  
The following coder names can be selected:  
g711Alaw64k  
g711Ulaw64k  
g7231  
g7231r53  
g726  
– G.711 A-law.  
– G.711 µ-law.  
– G.723.1 6.3 kbps (default).  
– G.723 5.3 kbps.  
– G.726 ADPCM 32 kbps (Payload Type = 2).  
– G.729A.  
g729  
NetCoder6_4  
NetCoder7_2  
NetCoder8  
NetCoder8_8  
Transparent  
Evrc  
– NetCoder 6.4 kbps.  
– NetCoder 7.2 kbps.  
– NetCoder 8.0 kbps.  
– NetCoder 8.8 kbps.  
– Transparent coder.  
– EVRC coder.  
Amr  
– AMR coder.  
Note: The coder name is case-sensitive.  
The RTP packetization period (ptime, in msec) depends on the selected Coder name,  
and can have the following values:  
g711 family  
g729  
g723 family  
G.726  
NetCoder family  
EVRC  
AMR  
– 10,20,30,40,50,60,80,100,120 (default=20).  
– 10,20,30,40,50,60,80,100 (default=20).  
– 30,60,90,120 (default = 30).  
– 10, 20, 40, 60, 80, 100, 120 (default=20).  
– 20, 40, 60, 80, 100, 120 (default=20).  
– 20, 40, 60, 80, 100 (default=20).  
– 20 only.  
Transparent  
- 20, 40, 60, 80, 100, 120 (default=20)  
Note 1: If not specified, the ptime gets a default value.  
Note 2: Each coder should appear only once.  
Note 3: The ptime specifies the maximum packetization time the gateway can receive.  
Note 4: G.729B is supported if the coder G.729 is selected and  
‘EnableSilenceCompression’ equals 1 or 2.  
Note 5: The selected rate of the AMR coder is set according to the parameter  
‘AMRSendRate’. The selected rate of the EVRC coder is set according to the  
parameter ‘EVRCRate’.  
Note 6: The AMR coder is enabled only if ‘DSPVersionTemplateNumber = 1’. When  
this DSP template is selected, the maximum number of channels is 160 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk).  
Note 7: The EVRC coder is enabled only if ‘DSPVersionTemplateNumber = 2’. When  
this DSP template is selected, the maximum number of channels is 120 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk). Note that the value of  
the parameter ‘EnableRFC2658Interleaving’ must be identical on both sides of the call.  
For example:  
CoderName = g711Alaw64k,20  
CoderName = g711Ulaw64k,40  
CoderName = g7231,90  
AMRPayloadType  
Determines the payload type that is used when the selected coder is set to one of the  
AMR coder variants.  
The valid range is 0 to 120. The default value is 64.  
Mediant 2000 SIP User’s Manual  
104  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
AMRSendRate  
Determines the selected rate for the AMR coder. This parameter is relevant only if AMR  
is included in the coder list (‘CoderName’).  
0 = AMR 4.75 kbps.  
1 = AMR 5.15 kbps.  
2 = AMR 5.90 kbps.  
3 = AMR 6.70 kbps.  
4 = AMR 7.40 kbps.  
5 = AMR 7.95 kbps.  
6 = AMR 10.2 kbps.  
7 = AMR 12.2 kbps (default).  
EVRCRate  
Determines the selected rate for the EVRC coder. This parameter is relevant only if  
EVRC is included in the coder list (‘CoderName’).  
0 = Variable rate (default).  
1 = 1 kbps  
2 = 4 kbps  
3 = 8 kbps  
EVRCPayloadType  
Determines the payload type that is used when the selected coder is set to ‘Evrc’.  
The valid range is 0 to 120. The default value is 60.  
TransparentPayloadType  
Specifies the payload type that is used when the selected coder is set to ‘Transparent’.  
The valid range is 0 to120. The default value is 56.  
DSPVersionTemplateNumb Determines the number of the DSP load. Each load has a different coder list, a different  
er  
channel capacity and different supported features.  
0 = G.711, G.726, G.723, G.729, Netcoder (default).  
1 = AMR, G.711, G.726, G.723, G.729.  
2 = EVRC, G.711, G.726, G.723, G.729.  
EnableRFC2658Interleavin When enabled, RTP packets include an interleaving byte for VBR coders.  
g
0 = Disable (default).  
1 = Enable.  
Note: This parameter is applicable only to EVRC coder.  
TransparentCoderOnDataC 0 = Only use coders from the coder list (default).  
all  
1 = Use transparent coder for data calls.  
The ‘Transparent’ coder can be used on data calls. When the gateway receives a Setup  
message from the ISDN with ‘TransferCapabilities = data’, it can initiate a call using the  
coder ‘Transparent’ (even if the coder is not included in the coder list). This option is a  
proprietary feature that requires the receiving gateway to include the ‘Transparent’  
coder in its coder list.  
IsFaxUsed  
[Fax Signaling Method]  
Determines the SIP signaling method used to establish and convey a fax session after  
a fax is detected.  
0 (No Fax)  
1 (T.38 Relay)  
= No fax negotiation using SIP signaling (default).  
= Initiates T.38 fax relay.  
2 (G.711 Transport)  
= Initiates fax using the coder G.711 A-law/µ-law (if not  
previously selected) with adaptations (refer to note 1).  
Note 1: Fax adaptations:  
Echo Canceller = On  
Silence Compression = Off  
Echo Canceller Non-Linear Processor Mode = Off  
Dynamic Jitter Buffer Minimum Delay = 40  
Dynamic Jitter Buffer Optimization Factor = 13  
Note 2: If the gateway initiates a fax session using G.711 (option 2), a ‘gpmd’ attribute  
is added to the SDP in the following format:  
For A-law: ‘a=gpmd:0 vbd=yes;ecan=on’. For µ-law: ‘a=gpmd:8 vbd=yes;ecan=on’.  
Note 3: When ‘IsFaxUsed’ is set to 1 or 2, the parameter ‘FaxTransportMode’ is  
ignored.  
T38UseRTPPort  
Defines that the T.38 packets are sent / received using the same port as RTP packets.  
0 = Use the RTP port +2 to send / receive T.38 packets (default).  
1 = Use the same port as the RTP port to send / receive T.38 packets.  
Version 4.4  
105  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
CngDetectorMode  
0 = Don’t detect CNG (default)  
[CNG Detector Mode]  
2 = Detect CNG on caller side and start fax session (if IsFaxUsed=1)  
Usually T.38 fax session starts when the “preamble” signal is detected by the  
answering side. Some SIP gateways doesn’t’ support the detection of this fax signal on  
the answering side, for these cases it is possible to configure the gateways to start the  
T.38 fax session when the CNG tone is detected by the originating side. However this  
mode is not recommended.  
DefaultReleaseCause  
[Default Release Cause]  
Default Release Cause (for IP to Tel calls), used when the gateway initiates a call  
release, and if an explicit matching cause for this release isn’t found, a default release  
cause can be configured. The default release cause is described in the Q.931 notation,  
and translated to corresponding SIP equivalent response value  
The default release cause is: NO_ROUTE_TO_DESTINATION (3).  
Other common values are: NO_CIRCUIT_AVAILABLE (34) or  
DESTINATION_OUT_OF_ORDER (27), etc.  
Note: The default release cause is described in the Q.931 notation, and is translated to  
corresponding SIP 40x or 50x value. For example: 404 for 3, 503 for 34 and 502 for 27.  
For mapping of SIP to Q.931 and Q.931 to SIP release causes, refer to Appendix I on  
page 227.  
IPAlertTimeout  
[Tel to IP No Answer  
Timeout]  
Defines the time (in seconds) the gateway waits for a 200 OK response from the called  
party (IP side) after sending an Invite message. If the timer expires, the call is released.  
The valid range is 0 to 3600. The default value is 180.  
SipSessionExpires  
0 = Not activate (default)  
[Session-Expires Time]  
Timeout [seconds] for Keeping a "re-INVITE" message alive within a SIP session  
MINSE  
[Minimum Session-Expires]  
Defines the time (in seconds) that is used in the Min-SE header field. This field defines  
the minimum time that the user agent supports for session refresh.  
The valid range is 10 to 100000. The default value is 90.  
SIPMaxRtx  
[SIP Maximum Rtx]  
Number of UDP retransmissions of SIP messages.  
The range is 1 to 7.  
The default value is 7.  
SipT1Rtx  
[SIP T1 Retransmission  
Timer (msec)]  
The time interval (in msec) between the first transmission of a SIP message and the  
first retransmission of the same message.  
The default is 500.  
Note: The time interval between subsequent retransmissions of the same SIP message  
starts with SipT1Rtx and is multiplied by two until SipT2Rtx.  
For example (assuming that SipT1Rtx = 500 and SipT2Rtx = 4000):  
The first retransmission is sent after 500 msec.  
The second retransmission is sent after 1000 (2*500) msec.  
The third retransmission is sent after 2000 (2*1000) msec.  
The fourth retransmission and subsequent retransmissions until SIPMaxRtx are sent  
after 4000 (2*2000) msec.  
SipT2Rtx  
[SIP T2 Retransmission  
Timer (msec)]  
The maximum interval (in msec) between retransmission of SIP messages.  
The default is 4000.  
Note: The time interval between subsequent retransmissions of the same SIP message  
starts with SipT1Rtx and is multiplied by two until SipT2Rtx.  
EnableEarlyMedia  
0 = Early Media is disabled (default).  
[Enable Early Media]  
1 = Enable Early Media.  
If enabled, the Mediant 2000 gateway sends 183 Session Progress response with SDP  
(instead of 180 ringing), enabling the setup of the media stream prior to the answering  
of the call. Sending 183 response depends on the Progress Indicator. It is sent only if  
PI=1 or PI=8 was received in Proceeding or Alert PRI messages. For CAS gateways  
see the ‘ProgressIndicator2IP’ parameter.  
Note: Generally, this parameter is set to 1.  
EnableTransfer  
0 = Call transfer is not allowed (default).  
[Enable Transfer]  
1 = The gateway responds to a Refer message with "Referred To" header to initiates a  
Call Transfer.  
Mediant 2000 SIP User’s Manual  
106  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
XferPrefix  
[Transfer Prefix]  
Defined string that is added, as a prefix, to the transferred called number, when  
Refer/3xx message is received.  
Note 1: The number manipulation rules apply to the user part of the Refer-TO/Contact  
URL before it is sent in the Invite message.  
Note 2: The xferprefix parameter can be used to apply different manipulation rules to  
differentiate the transferred number from the original dialed number.  
EnableHold  
0 = Hold service disabled (default)  
[Enable Hold]  
1 = Hold service is enabled, held tone is played to holding party.  
EnableForward  
0 = Disable call forward (default)  
[Enable Call Forward]  
1 = Enable call forward service.  
The Mediant 2000 doesn't initiate call forward, it can only respond to call forward  
requests.  
UseSIPURIForDiversionHe Sets the URI format in the Diversion header.  
ader  
0 = “tel:” (default).  
1 = “sip:”.  
EnableCallWaiting  
[Enable Call Waiting]  
0 = Disabled (default)  
1 = Enabled  
If enabled, when the gateway initiates a Tel to IP call to a destination that is busy, it  
plays a Call Waiting Ringback tone to the originator of the call.  
Note 1: The gateway’s Call Progress Tones file must include a Call Waiting Ringback  
tone.  
Note 2: The EnableHold parameter must be enabled on the called side.  
Defines the supported Receive DTMF negotiation method.  
0 = Don’t declare RFC 2833 Telephony-event parameter in SDP  
1 = n/a  
RxDTMFOption  
[Declare RFC 2833 in SDP]  
2 = n/a  
3 = Declare RFC 2833 “Telephony-event” parameter in SDP (default)  
The gateway is designed to always be receptive to RFC 2833 DTMF relay packets.  
Therefore, it is always correct to include the “Telephony-event” parameter as a default  
in the SDP. However some gateways use the absence of the “telephony-event” from  
the SDP to decide to send DTMF digits inband using G.711 coder, if this is the case  
you can set “RxDTMFOption=0”.  
TxDTMFOption  
[DTMF RFC2833  
Negotiation]  
0 = No negotiation, DTMF digit is sent according to the “DTMFTransportType”  
parameter.  
4 = Enable RFC 2833 payload type (PT) negotiation (default).  
Note 1: This parameter is applicable only if “IsDTMFUsed=0” (out-of-band DTMF is not  
used)  
Note 2: If enabled, the gateway:  
Negotiates RFC 2833 payload type using local and remote SDPs.  
Sends DTMF packets using RFC 2833 PT according to the received SDP.  
Expects to receive RFC 2833 packets with the same PT as configured by the  
“RFC2833PayloadType” parameter.  
Note 3: If the remote party doesn’t include the RFC 2833 DTMF relay payload type in  
the SDP, the gateway uses the same PT for send and for receive.  
Note 4: If TxDTMFOption is set to 0, the RFC 2833 payload type is set according to the  
parameter ‘RFC2833PayloadType’ for both transmit and receive.  
IsDTMFUsed  
Use out-of-band signaling to relay DTMF digits.  
[Use Out-of-Band DTMF]  
0 = Disable, DTMF digits are sent according to DTMFTransportType parameter.  
(default)  
1 = Enable sending DTMF digits within INFO or NOTIFY messages.  
When out-of-band DTMF transfer is used DTMFTransportType is automatically set to 0.  
Version 4.4  
107  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
OutOfBandDTMFFormat  
[Out-of-Band DTMF Format]  
The exact method to send out-of-band DTMF digits  
1 = INFO format (Nortel)  
2 = INFO format (Cisco) - (default)  
3 = NOTIFY format <draft-mahy-sipping-signaled-digits-01.txt>  
Note 1: To use out-of-band DTMF, set “IsDTMFUsed=1”.  
Note 2: When using out-of-band DTMF, the “DTMFTransportType” parameter is  
automatically set to 0, to erase the DTMF digits from RTP path.  
DisableAutoDTMFMute  
Enables / disables the automatic mute of DTMF digits when out-of-band DTMF  
transmission is used.  
0 = Auto mute is used (default).  
1 = No automatic mute of in-band DTMF.  
When ‘DisableAutoDTMFMute=1’, the DTMF transport type is set according to the  
parameter ‘DTMFTransportType’ and the DTMF digits aren’t muted if out-of-band  
DTMF mode is selected (’IsDTMFUsed =1’). This enables the sending of DTMF digits  
in-band (transparent of RFC 2833) in addition to out-of-band DTMF messages.  
Note: Usually this mode is not recommended.  
MaxActiveCalls  
Defines the maximum number of calls that the gateway can have active at the same  
[Max Number Of Active Calls] time. If the maximum number of calls is reached, new calls are not established.  
The default value is max available channels (no restriction on the maximum number of  
calls). The valid range is 1 to 240.  
MaxCallDuration  
[Max Call Duration]  
Defines the maximum call duration in minutes. If this time expires, both sides of the call  
are released (IP and Tel).  
The valid range is 0 to 120. The default is 0 (no limitation).  
EnableBusyOut  
0 = Not used (default)  
[Enable Busy Out]  
1 = Enable busy out  
If Proxy is not responding (according to the Proxy keep alive mechanism) or if there is a  
failure in the network, and if fallback isn’t enabled (IsFallbackUsed=0), all E1/T1 trunks  
are automatically put out of service by sending a remote alarm (AIS) or Service Out  
message for T1 PRI trunks that support these messages (NI-2, 4/5-ESS, DMS-100 and  
Meridian). Note that behavior varies between different protocol types.  
EnableDigitDelivery2IP  
[Enable Digit Delivery to IP]  
0 = Disabled (default).  
1 = Enable digit delivery to IP.  
The digit delivery feature enables sending of DTMF digits to the destination IP address  
after the TelIP call was answered.  
To enable this feature, modify the called number to include at least one ’p’ character.  
The gateway uses the digits before the ‘p’ character in the initial Invite message. After  
the call was answered the gateway waits for the required time (# of ‘p’ * 1.5 seconds)  
and then sends the rest of the DTMF digits using the method chosen (in-band, out-of-  
band).  
Note: The called number can include several ‘p’ characters (1.5 seconds pause).  
For example, the called number can be as follows: pp699, p9p300.  
EnableDigitDelivery  
[Enable Digit Delivery to Tel]  
The digit delivery feature enables sending of DTMF digits to the Gateway’s B-channel  
after the call is answered.  
0 = Disabled (default).  
1 = Enable Digit Delivery feature for Mediant 2000 (two stage dialing).  
Note: For incoming IPTel calls, if the called number includes the characters ‘w’ or ‘p’,  
the Mediant 2000 Gateway places a call with the first part of the called number, and  
plays DTMF digits after the call is answered. If the character ‘p’ (pause) is used, the  
Mediant 2000 waits for 1.5 seconds before playing the next DTMF digit. If the character  
‘w’ is used, the Mediant 2000 waits for detection of dial tone before it starts playing  
DTMF digits. The character ‘w’ can appear once in the called number, and must  
precede any ‘p’ character. The ‘p’ character can appear several times.  
For example: if the number “1007766p100” is defined as the called number, the  
Mediant 2000 places a call with 1007766 as the destination number, then, after the call  
is answered, it waits for 1.5 seconds and plays the rest of the number (100) as DTMF  
digits.  
Other examples: 1664wpp102, 66644ppp503, 7774w100pp200.  
Mediant 2000 SIP User’s Manual  
108  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
Profile Parameters  
CoderName_ID  
[Coder Group Settings]  
Coder list for Profiles (up to five coders in each group).  
The CoderName_ID parameter (ID from 1 to 4) provides groups of coders that can be  
associated with IP or Tel profiles.  
You can select the following coders:  
g711Alaw64k  
g711Ulaw64k  
g7231  
g7231r53  
g726  
– G.711 A-law.  
– G.711 µ-law.  
– G.723.1 6.3 kbps (default).  
– G.723.1 5.3 kbps.  
– G.726 ADPCM 32 kbps (Payload Type = 2).  
– G.729A.  
g729  
NetCoder6_4  
NetCoder7_2  
NetCoder8  
NetCoder8_8  
Transparent  
Evrc  
– NetCoder 6.4 kbps.  
– NetCoder 7.2 kbps.  
– NetCoder 8.0 kbps.  
– NetCoder 8.8 kbps.  
– Transparent coder.  
– EVRC coder.  
Amr  
– AMR coder.  
The RTP packetization period (ptime, in msec) depends on the selected Coder name,  
and can have the following values:  
g711 family  
g729  
g723 family  
G.726 family  
– 10, 20, 30, 40, 50, 60, 80, 100, 120 (default=20).  
– 10, 20, 30, 40, 50, 60, 80, 100 (default=20).  
– 30, 60, 90, 120 (default = 30).  
– 10, 20, 30, 40, 50, 60, 80, 100, 120 (default=20)  
NetCoder family – 20, 40, 60, 80, 100, 120 (default=20).  
EVRC  
AMR  
– 20, 40, 60, 80, 100 (default=20).  
– 20 only.  
Transparent  
- 20, 40, 60, 80, 100, 120 (default=20)  
Note 1: If not specified, the ptime gets a default value.  
Note 2: Each coder should appear only once.  
Note 3: The ptime specifies the maximum packetization time the Gateway will receive.  
Note 4: G.729B is supported if the coder G.729 is selected and  
‘EnableSilenceCompression’ equals 1 or 2.  
Note 5: The selected rate of the AMR coder is set according to the parameter  
‘AMRSendRate’. The selected rate of the EVRC coder is set according to the parameter  
‘EVRCRate’.  
Note 6: The AMR coder is enabled only if ‘DSPVersionTemplateNumber = 1’. When  
this DSP template is selected, the maximum number of channels is 160 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk).  
Note 7: The EVRC coder is enabled only if ‘DSPVersionTemplateNumber = 2’. When  
this DSP template is selected, the maximum number of channels is 120 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk). Note that the value of  
the parameter ‘EnableRFC2658Interleaving’ must be identical on both sides of the call.  
ini file note 1: This parameter (CoderName_ID) can appear up to 20 times (five coders  
in four coder groups).  
ini file note 2: The coder name is case-sensitive.  
ini file note 3: Enter in the format: CoderName,ptime.  
For example, the following three coders belong to coder group with ID=1:  
CoderName_1 = g711Alaw64k,20  
CoderName_1 = g711Ulaw64k,40  
CoderName_1 = g7231,90  
Version 4.4  
109  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-3: SIP Configuration Parameters (continues on pages 100 to 110)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
IPProfile_ID  
IPProfile_<Profile ID> =  
[IP Profile Settings]  
<Profile Name>,<Preference>,<Coder Group ID>,<IsFaxUsed *>,<DJBufMinDelay *>,  
<DJBufOptFactor *>,<IPDiffServ *>,<ControlIPDiffServ  
*>,<EnableSilenceCompression>, <RTPRedundancyDepth>  
Preference = (1-10) The preference option is used to determine the priority of the  
Profile. If both IP and Tel profiles apply to the same call, the coders and other common  
parameters of the preferred Profile are applied to that call. If the Preference of the Tel  
and IP Profiles is identical, the Tel Profile parameters are applied.  
For example:  
IPProfile_1 = name1,2,1,0,10,13,15,44,1,1  
IPProfile_2 = name2,$$,$$,$$,$,$$,$$,$$,$$,1  
$$ = Not configured, the default value of the parameter is used.  
(*) = Common parameter used in both IP and Tel profiles.  
Note 1: The IP ProfileID can be used in the Tel2IP and IP2Tel routing tables (Prefix and  
PSTNPrefix parameters).  
Note 2: ‘Profile Name’ assigned to a ProfileID, enabling User’s to identify it intuitively  
and easily.  
Note 3: This parameter can appear up to 4 times.  
TelProfile_ID  
TelProfile_<Profile ID> =  
[Tel Profile Settings]  
<Profile Name>,<Preference>,<Coder Group ID>,<IsFaxUsed *>,<DJBufMinDelay *>,  
<DJBufOptFactor *>,<IPDiffServ *>,<ControlIPDiffServ*>,<DtmfVolume>,<InputGain>,  
<VoiceVolume>, <EnableDigitDelivery>, <ECE>  
Preference = (1-10) The preference option is used to determine the priority of the  
Profile. If both IP and Tel profiles apply to the same call, the coders and other common  
parameters of the preferred Profile are applied to that call. If the Preference of the Tel  
and IP Profiles is identical, the Tel Profile parameters are applied.  
For examples:  
TelProfile_1 = FaxProfile,1,2,0,10,5,22,33,2,22,34,1,1  
TelProfile_2 = ModemProfile,0,10,13,$$,$$,$$,$$,$$,0,$$,0,1  
$$ = Not configured, the default value of the parameter is used.  
(*) = Common parameter used in both IP and Tel profiles.  
Note 1: The Tel ProfileID can be used in the Trunk Group table (TrunkGroup_x  
parameter).  
Note 2: ‘Profile Name’ assigned to a ProfileID, enabling User’s to identify it intuitively  
and easily.  
Note 3: This parameter can appear up to 4 times.  
Mediant 2000 SIP User’s Manual  
110  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
6.9 ISDN and CAS Interworking-Related Parameters  
Note:  
In Table 6-4, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-4: ISDN and CAS Interworking-Related Parameters (continues on pages 111 to 114)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
EnableTDMoverIP  
[Enable TDM Tunneling]  
0 = Disabled (default).  
1 = TDM Tunneling is enabled.  
When TDM Tunneling is enabled, the originating Mediant 2000 automatically initiates  
SIP calls from all enabled B-channels belonging to the E1/T1/J1 spans that are  
configured with the ‘Transparent’ protocol. The called number of each call is the internal  
phone number of the B-channel that the call originates from. The IP to Trunk Group  
routing table is used to define the destination IP address of the terminating Mediant  
2000. The terminating Mediant 2000 gateway automatically answers these calls if its  
E1/T1 protocol is set to ‘Transparent’ (ProtocolType = 5).  
PlayRBTone2Tel  
[Play Ringback Tone to Tel]  
0 (Don’t play) = The ISDN / CAS gateway doesn’t play a Ringback Tone (RBT). No PI is  
sent to the ISDN, unless the parameter ‘Progress Indicator to ISDN’ is configured  
differently.  
1 (Play) =  
The CAS gateway plays a local RBT to PSTN after receipt of a 180 ringing response  
(with or without SDP).  
Note: Reception of a 183 response doesn’t cause the CAS gateway to play an RBT  
(unless ‘SIP183Behavior = 1’).  
The ISDN gateway functions according to the parameter ‘LocalISDNRBSource’:  
If the ISDN gateway receives a 180 ringing response (with or without SDP) and  
‘LocalISDNRBSource = 1’, it plays a RBT and sends an Alert with PI = 8 (unless  
the parameter ‘Progress Indicator to ISDN’ is configured differently).  
If ‘LocalISDNRBSource = 0’, the ISDN gateway doesn’t play an RBT and an Alert  
message (without PI) is sent to the ISDN. In this case, the PBX / PSTN should  
play the RBT to the originating terminal by itself.  
Note: Reception of a 183 response doesn’t cause the ISDN gateway to play an RBT;  
the gateway issues a Progress message (unless ‘SIP183Behavior = 1’).  
If ‘SIP183Behavior = 1’, the 183 response is treated the same way as a 180 ringing  
response.  
2 = Play according to “early media” (default).  
If a 180 response is received and the voice channel is already open (due to a previous  
183 early media response or due to an SDP in the current 180 response), the ISDN /  
CAS gateway doesn’t play the RBT; PI = 8 is sent in an ISDN Alert message (unless the  
parameter ‘Progress Indicator to ISDN’ is configured differently).  
If a 180 response is received but the “early media” voice channel is not opened, the  
CAS gateway plays an RBT to the PSTN; the ISDN gateway functions according to the  
parameter ‘LocalISDNRBSource’:  
If ‘LocalISDNRBSource = 1’, the ISDN gateway plays an RBT and sends an ISDN  
Alert with PI = 8 to the ISDN (unless the parameter ‘Progress Indicator to ISDN’ is  
configured differently).  
If ‘LocalISDNRBSource = 0’, the ISDN gateway doesn’t play an RBT.  
No PI is sent in the ISDN Alert message (unless the parameter ‘Progress Indicator  
to ISDN’ is configured differently). In this case, the PBX / PSTN should play an  
RBT tone to the originating terminal by itself.  
Note: Reception of a 183 response results in an ISDN Progress message (unless  
‘SIP183Behavior = 1’).  
If ‘SIP183Behavior = 1’ (183 is handled in the same way as a 180+SDP), the gateway  
sends an Alert message with PI = 8, without playing an RBT.  
Version 4.4  
111  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Table 6-4: ISDN and CAS Interworking-Related Parameters (continues on pages 111 to 114)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
PlayRBTone2IP  
0 = Ringback tone isn’t played (default).  
[Play Ringback Tone to IP]  
1 = Ringback tone is played (to IP) after SIP 183 session progress response is sent.  
If configured to ‘1’ (Play),  
For IPTel calls, if a Progress or an Alert message with PI is sent from the ISDN and  
‘EnableEarlyMedia = 1’, the Mediant 2000 opens a voice channel and sends 183  
response. It doesn’t play a Ringback tone to IP (assuming that the Ringback tone is  
played by the ISDN).  
Otherwise, if a voice channel isn’t opened, the Mediant 2000 plays Ringback tone to IP,  
after receiving an Alert message from the ISDN. It sends 183 response, signaling the  
originating party to open a voice channel in order to hear the played Ringback tone.  
Note 1: To enable the gateway to send a 183 response, set ‘EnableEarlyMedia’ to 1.  
Note 2: If ‘EnableDigitDelivery = 1’, the gateway doesn’t play a Ringback tone to IP and  
doesn’t send a 183 response.  
ProgressIndicator2ISDN  
0, 1 or 8  
[Progress Indicator to ISDN] -1 = Not configured (default).  
If set to "0" PI is not sent to ISDN  
If set to "1" or "8" the PI value is sent to PSTN in Q.931/Proceeding and Alerting  
messages.  
If not configured, the PI in ISDN messages is set according to the "Play Ringback to  
Tel" parameter.  
Usually if PI = 1 or 8, the PSTN/PBX cuts through the audio channel without playing  
local Ringback tone, enabling the originating party to hear remote Call Progress Tones  
or network announcements  
ProgressIndicator2IP  
[Progress Indicator to IP]  
-1 = (Not configured) for ISDN spans, the PI that is received in ISDN Proceeding,  
Progress and Alert messages is used as described in the following options (default).  
0 = (No PI) For IPTel call, the gateway sends “180 Ringing” SIP response to IP after  
receiving ISDN Alert, or (for CAS) after placing a call to PBX/PSTN.  
8, 1 = For IPTel call, if ‘EnableEarlyMedia=1’, the gateway sends “183 session in  
progress” message + SDP, after a call is placed to PBX/PSTN over the trunk. This is  
used to cut through voice path, before remote party answers the call, enabling the  
originating party to listen to network Call Progress Tones (such as Ringback tone or  
other network announcements).  
PIForDisconnectMsg  
[Set PI in Rx Disconnect  
Message]  
Defines the gateway’s behavior when a Disconnect message is received from the ISDN  
before a Connect message was received.  
-1 (Not configured) = Sends a 183 message according to the received PI in the ISDN  
Disconnect message. If PI = 1 or 8, the gateway sends a 183 response, enabling the  
PSTN to play a voice announcement to the IP side. If there isn’t a PI in the Disconnect  
message, the call is released (default).  
0 = Do not send a 183 message to IP. The call is released.  
1, 8 = Sends 183 message to IP.  
ConnectOnProgressInd  
0 = Connect message isn’t sent after 183 Session Progress is received (default).  
1 = Connect message is sent after 183 Session Progress is received.  
This feature enables the play of announcements from IP to PSTN without the need to  
answer the TelIP call. It can be used with PSTN networks that don’t support the  
opening of a TDM channel before an ISDN Connect message is received.  
SIP183Behavior  
[183 Message Behavior]  
Defines the ISDN message that is sent when 183 Session Progress message is  
received for IPTel calls.  
0 = Progress message (default).  
1 = Alert message.  
When set to 1, the gateway sends an Alert message (after the receipt of a 183  
response) instead of an ISDN Progress message.  
LocalISDNRBSource  
[Local ISDN Ringback Tone  
Source]  
Determines whether Ringback tone is played to the ISDN by the PBX / PSTN or by the  
gateway.  
0 = PBX / PSTN (default).  
1 = Gateway.  
This parameter is applicable to ISDN protocols. It is used simultaneously with the  
parameter ’PlayRBTone2Tel’.  
Mediant 2000 SIP User’s Manual  
112  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-4: ISDN and CAS Interworking-Related Parameters (continues on pages 111 to 114)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
PSTNAlertTimeout  
[PSTN Alert Timeout]  
Alert Timeout in seconds (ISDN T301 timer) for outgoing calls to PSTN.  
The default is 180 seconds. The range is 0 to 240.  
Note: The PSTN stack T301 timer can be overridden by a lower value, but it can’t be  
increased.  
ISDNTransferCapability  
[ISDN Transfer Capabilities]  
Defines the IPISDN Transfer Capability of the Bearer Capability IE in ISDN Setup  
messages.  
0 = Audio 3.1 (default).  
1 = Speech.  
2 = Data.  
Note: If this parameter isn’t configured or equals to ‘–1’, Audio 3.1 capability is used.  
ScreeningInd2IP  
[Send Screening Indicator to  
IP]  
The parameter can overwrite the calling number screening indication for ISDN TelIP  
calls.  
-1 = not configured (interworking from ISDN to IP) or set to 0 for CAS.  
0 = user provided, not screened.  
1 = user provided, verified and passed.  
2 = user provided, verified and failed.  
3 = network provided.  
Note: Applicable only if Remote Party ID (RPID) header is enabled.  
SupportRedirectInFacility  
EnableCIC  
0 = Not Supported (default).  
1 = Supports partial retrieval of Redirect Number (number only) from a Facility IE in  
ISDN Setup messages. Applicable to Redirect number according to ECMA-173 Call  
Diversion Supplementary Services.  
Note: To enable this feature, ‘ISDNDuplicateQ931BuffMode’ must be set to 1.  
0 = Do not relay the Carrier Identification Code (CIC) to ISDN (default).  
1 = CIC is relayed to ISDN in Transit Network Selection IE.  
If enabled, the CIC code (received in an Invite Request-URI) is included in a TNS IE in  
ISDN Setup message. For example: INVITE sip:555666;[email protected] sip/2.0.  
Note: Currently this feature is supported only in SIPISDN direction.  
EnableAOC  
0 = Not used (default).  
1 = ISDN Advice of Charge (AOC) messages are interworked to SIP.  
The gateway supports reception of ISDN (Euro ISDN) AOC messages. AOC messages  
can be received during a call (Facility messages) or at the end of a call (Disconnect or  
Release messages). The gateway converts the AOC messages into SIP Info (during a  
call) and Bye (end of a call) messages using a proprietary AOC SIP header. The  
gateway supports both Currency and Pulse AOC messages.  
TimeForReorderTone  
Busy or Reorder Tone duration the CAS gateway plays before releasing the line.  
The valid range is 0 to 15. The default value is 10 seconds.  
Applicable also to ISDN if ‘PlayBusyTone2ISDN = 2’. Selection of Busy or Reorder tone  
is done according to release cause received from IP.  
DisconnectOnBusyTone  
0 = Do not disconnect call on detection of busy tone  
[Disconnect Call on Detection 1 = Disconnect call on detection of busy tone (default).  
of Busy Tone]  
This parameter is applicable to CAS & ISDN protocols.  
PlayBusyTone2ISDN  
[Play Busy Tone to Tel]  
This parameter enables the Mediant 2000 ISDN gateway to play a Busy or a Reorder  
tone to the PSTN after a call is released.  
0 = Immediately sends an ISDN Disconnect message (default).  
1 = Sends an ISDN Disconnect message with PI=8 and plays a Busy or a Reorder tone  
to the PSTN (depending on the release cause).  
2 = Delays the sending of an ISDN Disconnect message for ‘TimeForReorderTone’  
seconds and plays a Busy or a Reorder tone to the PSTN. Applicable only if the call is  
released from the IP before it reaches the Connect state. Otherwise, the Disconnect  
message is sent immediately and no tones are played.  
TrunkTransferMode_X  
0 = Not supported (default).  
1 = Supports CAS NFA DMS-100 transfer.  
When a SIP Refer message is received, the gateway performs a Blind Transfer by  
executing a CAS Wink and dialing the Refer-to number to the Switch and then releasing  
the call.  
Note: A specific NFA CAS table is required.  
Version 4.4  
113  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-4: ISDN and CAS Interworking-Related Parameters (continues on pages 111 to 114)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
CASTransportType  
0 = Disable CAS relay (default).  
[CAS Transport Type]  
1 = Enable CAS relay mode using RFC 2833.  
The CAS relay mode can be used with the TDM tunneling feature to enable tunneling  
over IP for both voice and CAS signaling bearers.  
XChannelHeader  
0 = x-channel header is not used (default).  
1 = x-channel header is generated, with trunk/B-channel information.  
The header provides information on the E1/T1 physical trunk/B-channel on which the  
call is received or placed. For example “x-channel: DS/DS1-5/22”. This header is  
generated by the Mediant 2000 and is sent in the following messages: INVITE and  
183/180/200OK responses.  
This parameter enables to add an optional Information Element data (in hex format) to  
ISDN SETUP message.  
For example: to add the following IE: “0x20,0x02,0x00,0xe1”, define: “AddIEinSetup =  
200200e1”.  
AddIEinSetup  
[Add IE in SETUP]  
Note: This IE is sent from the Trunk Group IDs defined by the parameter ‘SendIEonTG’.  
SendIEonTG  
[Trunk Groups to Send IE]  
A list of Trunk Group IDs (up to 50 characters) from where the optional ISDN IE,  
defined by the parameter ‘AddIEinSetup’, is sent.  
For example: "SendIEonTG = 1,2,4,10,12,6”.  
ISDNDMSTimerT310  
Overrides the T310 timer for the DMS-100 ISDN variant.  
T310 defines the timeout between the reception of Proceeding message and the  
reception of Alert / Connect message.  
The valid range is 10 to 30. The default value is 10 (seconds).  
Note: Applicable only to Nortel DMS and Nortel MERIDIAN PRI variants (ProtocolType  
= 14 and 35).  
ISDNJapanNTTTimerT3JA  
T3_JA timer (in seconds).  
This parameter overrides the internal PSTN T301 timeout on the Users Side (TE side).  
If an outgoing call from the Mediant 2000 to ISDN is not answered during this timeout,  
the call is released.  
The valid range is 10 to 240. The default value is 50.  
Applicable only to Japan NTT PRI variant (ProtocolType = 16).  
Note: This timer is also affected by the parameter ‘PSTNAlertTimeout’.  
Mediant 2000 SIP User’s Manual  
114  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
6.10 Number Manipulation and Routing Parameters  
Note:  
In Table 6-5, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
TrunkGroup_x  
TrunkGroup_x = T/a-b,c,d  
[Trunk Group Table]  
x = Trunk group ID (1 to 99).  
T = Physical trunk number (0 to 7).  
a = Starting B-channel (from 1).  
b = Ending B-channel (up to 31).  
c = Phone number associated with the first channel (optional).  
d = Optional Tel Profile ID (1 to 5).  
For example:  
TrunkGroup_1 = 0/1-31,1000 (for E1 span).  
TrunkGroup_1 = 1/1-31,$$,1.  
TrunkGroup_2 = 2/1-24,3000 (for T1 span).  
Trunk group is the recommended method to configure the gateway's B-channels.  
The parameter ’ChannelList’ (although still supported) mustn’t be used  
simultaneously with Trunk Groups.  
Note: An optional Tel Profile ID (1 to 5) can be applied to each group of B-channels.  
ChannelList  
List of phone numbers, used to define the enabled B-channels for gateway operation,  
‘a, b, c,d’  
Note: It is recommended to use a = first channel  
TrunkGroup_x parameter  
b = number of channels starting from ‘a’  
instead.  
c = the phone number of the first channel  
d = Tel Profile ID assigned to the group of channels.  
example: ChannelList = ‘0,30,1001’  
Defines phone numbers 1001 to 1030 for 30 gateway channels.  
The ini file can include up to ten ‘ChannelList = ‘ entries  
Usually single ChannelList parameter is enough to define the complete 8 trunk  
gateway:  
ChannelList = ‘0,240,1000’; For eight E1 spans  
ChannelList = ‘0,192,1000’; For eight T1 CAS spans  
Phone numbers can be defined individually per E1 or T1 span:  
For E1 spans (CAS or ISDN): 0 to 29 for first span, 30 to 59 for second span, 60 to  
89 for 3rd span, 90 to 119 for 4th span.  
For T1 ISDN spans: 0 to 22 for first span, 23 to 45 for second span, 46 to 68 for 3rd  
span, and 69 to 91 for 4th span.  
For T1 CAS signaling: 0 to 23 for first span, 24 to 47 for second span, 48 to 71 for 3rd  
span, and 72 to 95 for 4th span.  
It is suggested to use Trunk Groups in Mediant 2000 gateway to define enabled B-  
channels, instead of ChannelList parameter.  
DefaultNumber  
[Default Destination Number]  
Defines the telephone number that the gateway uses if the parameters  
‘TrunkGroup_x’ or ’ChannelList‘ don’t include a phone number. The parameter is  
used as a starting number for the list of B-channels comprising all trunk groups in the  
gateway.  
Version 4.4  
115  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ChannelSelectMode  
[Channel Select Mode]  
Defines common rule of port allocation for IP to TEL calls.  
0 = By phone number - Select the gateway port according to the called number  
(refer to the note below).  
1 = Cyclic Ascending - Select the next available channel in an ascending cycle  
order. Always select the next higher channel number in the Trunk Group. When  
the gateway reaches the highest channel number in the Trunk Group, it selects  
the lowest channel number in the Trunk Group and then starts ascending again  
(default).  
2 = Ascending - Select the lowest available channel. Always start at the lowest  
channel number in the Trunk Group and if that channel is not available, select  
the next higher channel.  
3 = Cyclic Descending - Select the next available channel in descending cycle  
order. Always select the next lower channel number in the Trunk Group. When  
the gateway reaches the lowest channel number in the Trunk Group, it selects  
the highest channel number in the Trunk Group and then start descending  
again.  
4 = Descending - Select the highest available channel. Always start at the  
highest channel number in the Trunk Group and if that channel is not available,  
select the next lower channel.  
5 = Number + Cyclic Ascending – First select the gateway port according to the  
called number (refer to the note below). If the called number isn’t found, then  
select the next available channel in ascending cyclic order. Note that if the  
called number is found, but the port associated with this number is busy, the call  
is released.  
Note: The internal numbers of the gateway’s B-channels are defined by the  
‘TrunkGroup_x’ parameter (under ‘Phone Number’).  
TrunkGroupSettings  
[Trunk Group Settings]  
Defines rules for port allocation for specific Trunk Groups, if such rule doesn’t exist,  
the global rule defined by ChannelSelectMode applies.  
a, b  
a = Trunk Group ID number  
b = Channel select mode for that Trunk Group.  
Available values are identical to those defined by the ChannelSelectMode parameter.  
AddTrunkGroupAsPrefix  
0 = not used  
[Add Trunk Group ID as Prefix] 1 = For TelIP incoming call, Trunk Group ID is added as prefix to destination phone  
number. Applicable only if trunk group ID are configured.  
Can be used to define various routing rules.  
AddPortAsPrefix  
0 = Don’t add (default)  
[Add Trunk ID as Prefix]  
1 = Add trunk ID number (single digit in the range 1 to 8) as a prefix to the called  
phone number for TelIP incoming calls.  
This option can be used to define various routing rules.  
ReplaceEmptyDstWithPortNu 0 = Disabled (default).  
mber  
1 = Enabled, Internal channel number is used as a destination number if called  
[Replace Empty Destination  
with Port Number]  
number is missing.  
Note: Applicable only to TelIP calls, if called number is missing.  
CopyDestOnEmptySource  
0 = Leave Source Number empty (default).  
1 = If the Source Number of an incoming Tel to IP call is empty, the Destination  
Number is copied to the Source Number.  
AddNPIandTON2CallingNum 0 = Do not change the Calling Number (default).  
ber  
1 = Add NPI and TON to the Calling Number of incoming (Tel to IP) ISDN call.  
For example: After receiving a Calling Number = 555, NPI = 1 and TON = 3, the  
modified number is going to be 13555. This number can later be used for  
manipulation and routing purposes.  
AddNPIandTON2CalledNumb 0 = Do not change the Called Number (default).  
er  
1 = Add NPI and TON to the Called Number of incoming (Tel to IP) ISDN call.  
For example: After receiving a Called Number = 555, NPI=1 and TON = 3, the  
modified number is going to be 13555. This number can later be used for  
manipulation and routing purposes.  
Mediant 2000 SIP User’s Manual  
116  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
UseSourceNumberAsDisplay 0 = Interworks the Tel calling name to SIP Display Name (default).  
Name  
1 = Set Display Name to Calling Number if not configured.  
[Use Source Number as  
Display Name]  
Applicable to TelIP calls. If enabled and if the incoming Tel to IP call doesn’t  
contain the calling party name, the calling number is used instead.  
All CAS protocols don’t provide the calling party name. Therefore, in CAS, if this  
parameter is enabled, the Display Name is identical to the calling number.  
AlwaysUseRouteTable  
[Use Routing Table for Host  
Names and Profiles]  
Use the internal Tel to IP routing table to obtain the URL Host name and (optionally)  
an IP profile (per call), even if Proxy server is used.  
0 = Don’t use (default)  
1 = Use  
Note: This Domain name is used, instead of Proxy name or Proxy IP address, in the  
INVITE SIP URL.  
Prefix  
Mapping phone number to IP address, using phone number prefix  
[Tel to IP Routing Table]  
Selection of IP address (for Tel To IP calls) is according to destination and source  
prefixes.  
Prefix = <Destination Phone Prefix>, <IP Address>,<Src Phone Prefix>,<IP Profile  
ID>  
For example:  
Prefix = 20,10.2.10.2,202,1  
Prefix = 10[340-451]xxx#,10.2.10.6,*,1  
Prefix = *,gateway.domain.com,*  
Note 1: An optional IP ProfileID (1 to 5) can be applied to each routing rule.  
Note 2: <destination / source phone prefix> can be single number or a range of  
numbers.  
Note 3: This parameter can appear up to 50 times.  
Note 4: Parameters can be skipped by using the sign "$$", for example:  
Prefix = $$,10.2.10.2,202,1  
For available notations, refer to Section 5.8.3.1 on page 47.  
For detailed information on this feature, refer to Section 5.8.4.1 on page 49.  
PSTNPrefix  
PSTNPrefix = a,b,c,d,e  
[IP to Trunk Group Routing  
Table]  
a = Destination Number Prefix  
b = Trunk group ID (1 to 99)  
c = Source Number Prefix  
d = Source IP address (obtained from the Contact header in the Invite message)  
e = IP Profile ID (1 to 5)  
Selection of trunk groups (for IP to Tel calls) is according to destination number,  
source number and source IP address.  
Note 1: To support the ‘in call alternative routing’ feature, Users can use two entries  
that support the same call, but assigned it with a different trunk groups. The second  
entree functions as an alternative selection if the first rule fails as a result of one of  
the release reasons listed in the AltRouteCauseIP2Tel table.  
Note 2: An optional IP ProfileID (1 to 5) can be applied to each routing rule.  
Note 3: The Source IP Address can include the “x” wildcard to represent single  
digits. For example: 10.8.8.xx represents all IP addresses between 10.8.8.10 to  
10.8.8.99.  
RemovePrefix  
0 = Don't remove prefix (default)  
[IP to Tel Remove Routing  
Table Prefix]  
1 = Remove PSTN prefix (defined in the routing table) from a telephone number of  
an incoming IP call, before forwarding it to PSTN,  
Applicable only if number manipulation is performed after call routing for IPTel calls  
(RouteModeIP2Tel = 0).  
RouteModeIP2Tel  
[IP to Tel routing Mode]  
0 = Route calls before number manipulation (default)  
1 = Route calls after number manipulation  
Defines order between routing calls to Trunk group and manipulation of destination  
number  
Version 4.4  
117  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
RouteModeTel2IP  
[Tel to IP routing Mode]  
0 = Route calls before number manipulation (default)  
1 = Route calls after number manipulation  
Defines order between routing incoming calls to IP, using routing table, and  
manipulation of destination number  
Not applicable if Outbound Proxy is used.  
SwapRedirectNumber  
[Swap Redirect and Called  
Numbers]  
0 = Don't change numbers (default)  
1 = Incoming ISDN call that includes redirect number (sometimes referred as  
"original called number") uses this number instead of the called number.  
AddTON2RPI  
0 = TON/PLAN parameters aren’t included in the RPID header.  
[Add Number Plan and Type to 1 = TON/PLAN parameters are included in the RPID header (default).  
Remote Party ID Header]  
If RPID header is enabled (EnableRPIHeader = 1) and ‘AddTON2RPI=1’, it is  
possible to configure the calling and called number type and number plan using the  
Number Manipulation tables for TelIP calls.  
NumberMapTel2IP  
[Destination Phone Number  
Manipulation Table for TelIP  
calls]  
Manipulates the destination number for Tel to IP calls.  
NumberMapTel2IP = a,b,c,d,e,f,g  
a
b
= Destination number prefix  
= Number of stripped digits from the left, or (if brackets are used) from the  
right. A combination of both options is allowed.  
= String to add as prefix, or (if brackets are used) as suffix. A combination of  
both options is allowed.  
c
d
e
f
= Number of remaining digits from the right  
= Number Plan used in RPID header  
= Number Type used in RPID header  
= Source number prefix  
g
The ‘b’ to ‘f’ manipulations rules are applied if the called and calling numbers match  
the ‘a’ and ‘g’ conditions.  
The manipulation rules are executed in the following order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for example:  
NumberMapTel2IP=01,2,972,$$,0,0,$$  
NumberMapTel2IP=03,(2),667,$$,0,0,22  
NumberMapIP2Tel  
[Destination Phone Number  
Manipulation Table for IPTel  
calls]  
Manipulate the destination number for IP to Tel calls.  
NumberMapIP2Tel = a,b,c,d,e,f,g,h,i  
a
b
= Destination number prefix  
= Number of stripped digits from the left, or (if brackets are used) from the  
right. A combination of both options is allowed.  
= String to add as prefix, or (if brackets are used) as suffix. A combination of  
both options is allowed.  
c
d
e
f
= Number of remaining digits from the right  
= Q.931 Number Plan  
= Q.931 Number Type  
g
h
i
= Source number prefix  
= Not applicable, set to $$  
= Source IP address (obtained from the Contact header in the Invite  
message)  
The ‘b’ to ‘f’ manipulation rules are applied if the called and calling numbers match  
the ‘a’, ‘g’ and ‘i’ conditions.  
The manipulation rules are executed in the following order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for example:  
NumberMapIP2Tel =01,2,972,$$,0,$$,034  
NumberMapIP2Tel =03,(2),667,$$,$$,0,22,$$,10.13.77.8  
Note: The Source IP address can include the “x” wildcard to represent single digits.  
For example: 10.8.8.xx represents all the addresses between 10.8.8.10 to 10.8.8.99.  
Mediant 2000 SIP User’s Manual  
118  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
SourceNumberMapTel2IP  
[Source Phone Number  
Manipulation Table for TelIP  
calls]  
SourceNumberMapTel2IP = a,b,c,d,e,f,g,h  
a
b
= Source number prefix  
= Number of stripped digits from the left, or (if in brackets are used) from  
right. A combination of both options is allowed.  
= String to add as prefix, or (if in brackets are used) as suffix. A combination  
of both options is allowed.  
c
d
e
f
= Number of remaining digits from the right  
= Number Plan used in RPID header  
= Number Type used in RPID header  
g
h
=Destination number prefix  
=Calling number presentation (0 to allow presentation, 1 to restrict  
presentation)  
The ‘b’ to ‘f’ and ‘h’ manipulation rules are applied if the called and calling numbers  
match the ‘a’ and ‘g’ conditions.  
The manipulation rules are executed in the following order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for example:  
SourceNumberMapTel2IP=01,2,972,$$,0,0,$$,1  
SourceNumberMapTel2IP=03,(2),667,$$,0,0,22,0  
SourceNumberMapIP2Tel  
[Source Phone Number  
Manipulation Table for IPTel  
calls]  
Manipulate the source number for IP to Tel calls.  
SourceNumberMapIP2Tel = a,b,c,d,e,f,g,h  
a
b
= Source number prefix  
= Number of stripped digits from the left, or (if brackets are used) from the  
right. A combination of both options is allowed.  
= String to add as prefix, or (if brackets are used) as suffix. A combination of  
both options is allowed.  
c
d
e
f
= Number of remaining digits from the right  
= Q.931 Number Plan  
= Q.931 Number Type  
g
h
= Destination number prefix  
=Calling number presentation (0 to allow presentation, 1 to restrict  
presentation)  
The ‘b’ to ‘f’ and ‘h’ manipulation rules are applied if the called and calling numbers  
match the ‘a’ and ‘g’ conditions.  
The manipulation rules are executed in the following order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for example:  
SourceNumberMapIP2Tel =01,2,972,$$,0,$$,034,1  
SourceNumberMapIP2Tel =03,(2),667,$$,$$,0,22  
Version 4.4  
119  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
For ETSI ISDN variant, the following Number Plan and Type combinations (Plan/Type) are supported in the Destination  
and Source Manipulation tables:  
0,0 = Unknown, Unknown  
9,0 = Private, Unknown  
9,1 = Private, Level 2 Regional  
9,2 = Private, Level 1 Regional  
9,3 = Private, PISN Specific  
9,4 = Private, Level 0 Regional (local)  
1,0 = Public(ISDN/E.164), Unknown  
1,1 = Public(ISDN/E.164), International  
1,2 = Public(ISDN/E.164), National  
1,3 = Public(ISDN/E.164), Network Specific  
1,4 = Public(ISDN/E.164), Subscriber  
1,6 = Public(ISDN/E.164), Abbreviated  
For NI-2 and DMS-100 ISDN variants the valid combinations of TON and NPI for calling and called numbers are  
(Plan/Type):  
0/0 - Unknown/Unknown  
1/1 - International number in ISDN/Telephony numbering plan  
1/2 - National number in ISDN/Telephony numbering plan  
1/4 - Subscriber (local) number in ISDN/Telephony numbering plan  
9/4 - Subscriber (local) number in Private numbering plan  
SecureCallsFromIP  
0 = Gateway accepts all SIP calls (default).  
[IP Security]  
1 = Gateway accepts SIP calls only from IP addresses defined in the Tel to IP routing  
table. The gateway rejects all calls from unknown IP addresses.  
For detailed information on the Tel to IP Routing table, refer to Section 5.8.4.1 on  
page 49.  
Note: Specifying the IP address of a Proxy server in the Tel to IP Routing table  
enables the gateway to only accept calls originating in the Proxy server and rejects  
all other calls.  
AltRouteCauseTel2IP  
[Reasons for Alternative  
Routing Table]  
Table of call failure reason values received from the IP side. If a call is released as a  
result of one of these reasons, the gateway tries to find an alternative route to that  
call in the ‘Tel to IP Routing’ table.  
For example:  
AltRouteCauseTel2IP = 486  
AltRouteCauseTel2IP = 480 (Temporarily unavailable).  
AltRouteCauseTel2IP = 408 (No response).  
(Busy here).  
Note 1: The 408 reason can be used to specify that there was no response from the  
remote party to the INVITE request.  
Note 2: This parameter can appear up to 5 times.  
AltRouteCauseIP2Tel  
[Reasons for Alternative  
Routing Table]  
Table of call failure reason values received from the pstn side (in Q.931  
presentation). If a call is released as a result of one of these reasons, the gateway  
tries to find an alternative trunk group to that call in the ‘IP to Trunk Group Routing’  
table.  
For example:  
AltRouteCauseIP2Tel = 3  
AltRouteCauseIP2Tel = 1  
AltRouteCauseIP2Tel = 17  
(No route to destination).  
(Unallocated number).  
(Busy here).  
Note 1: This parameter can appear up to 5 times.  
Note 2: If the Mediant 2000 fails to establish a cal to the PSTN because it has no  
available channels in a specific trunk group (e.g., all of the trunk group’s channels  
are occupied, or the trunk group’s spans are disconnected or out of sync), it uses the  
internal release cause ‘3’ (no route to destination). This cause can be used in the  
‘AltRouteCauseIP2Tel’ table to define routing to an alternative trunk group.  
Mediant 2000 SIP User’s Manual  
120  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-5: Number Manipulation and Routing Parameters (continues on pages 115 to 121)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
FilterCalls2IP  
[Filter Calls To IP]  
0 = Disabled (default)  
1 = Enabled  
If the filter calls to IP feature is enabled, then when a Proxy is used, the gateway first  
checks the TelIP routing table before making a call through the Proxy. If the  
number is not allowed (number isn’t listed or a Call Restriction routing rule,  
IP=0.0.0.0, is applied), the call is released.  
Alternative Routing Parameters  
AltRoutingTel2IPEnable  
[Enable Alt Routing Tel to IP]  
Operation modes of the Alternative Routing mechanism:  
0 = Disabled (default).  
1 = Enabled.  
2 = Enabled for status only, not for routing decisions.  
AltRoutingTel2IPMode  
[Alt Routing Tel to IP Mode]  
0 (None) = Alternative routing is not used.  
1 (Conn) = Alternative routing is performed if ping to initial destination failed.  
2 (QoS) = Alternative routing is performed if poor quality of service was detected.  
3 (All) = Alternative routing is performed if, either ping to initial destination failed, or  
poor quality of service was detected, or DNS host name is not resolved (default).  
Note: QoS is quantified according to delay and packet loss, calculated according to  
previous calls. Qos statistics are reset if no new data is received for two minutes.  
For information on the Alternative Routing feature, refer to Section 8.6 on page 146.  
IPConnQoSMaxAllowedPL  
[Max Allowed Packet Loss for  
Alt Routing]  
Packet loss percentage at which the IP connection is considered a failure.  
The range is 1% to 20%. The default value is 20%.  
IPConnQoSMaxAllowedDelay  
[Max Allowed Delay for Alt  
Routing]  
Transmission delay (in msec) at which the IP connection is considered a failure.  
The range is 100 to 1000. The default value is 250 msec.  
Version 4.4  
121  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
6.11 E1/T1 Configuration Parameters  
Note:  
In Table 6-6, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
PCMLawSelect  
1 = A-law  
[PCM Law Select]  
3 = µ-Law  
Usually A-Law is used for E1 spans and µ-Law for T1 and J1 spans.  
FramingMethod  
[Framing Method]  
Selects the framing method to be used for E1/T1 spans.  
For E1  
0 = Multiframe with CRC4 (default, automatic mode, if CRC is identified in the Rx,  
CRC is sent in Tx, otherwise no CRC).  
a = Double frame  
c = Multiframe with CRC4  
For T1  
0 or D = Extended super frame with CRC6 (default)  
1 or B = Super frame D4, F12 (12-Frame multiframe)  
A = F4 (4-Frame multiframe)  
C = Extended super frame without CRC6  
F = J1 - Japan (ESF with CRC6 and JT)  
FramingMethod_x  
[Framing Method]  
Same as the description for parameter ‘FramingMethod’ for a specific trunk ID (x = 0  
to 7).  
ProtocolType  
Sets the PSTN protocol to be used for this trunk.  
[Protocol Type]  
E1_EURO_ISDN  
T1_CAS  
T1_RAW_CAS  
T1_TRANSPARENT  
= 1,  
= 2,  
= 3,  
= 4,  
E1_TRANSPARENT_31 = 5,  
E1_TRANSPARENT_30 = 6,  
E1_MFCR2  
= 7,  
E1_CAS_R2  
= 8,  
E1_RAW_CAS  
T1_NI2_ISDN  
= 9,  
= 10,  
= 11,  
= 12,  
= 13,  
= 14,  
= 15  
= 16  
= 17  
= 18  
= 19  
= 20  
= 21  
= 23  
= 35  
T1_4ESS_ISDN  
T1_5ESS_9_ISDN  
T1_5ESS_10_ISDN  
T1_DMS100_ISDN  
J1_TRANSPARENT  
T1_NTT_ISDN  
E1_AUSTEL_ISDN  
T1_HKT_ISDN  
E1_KOR_ISDN  
T1_HKT_ISDN  
E1_QSIG  
/* Japan - Nippon Telegraph  
/* Australian Telecom  
/* Hong Kong - HKT  
/* Korean operator  
/* Hong Kong - HKT over T1  
/*Basic call only  
T1_QSIG  
T1_DMS100_Meridian  
/*Basic call only  
Note: The Mediant 2000 simultaneously supports different variants of CAS and PRI  
protocols on different E1/T1 spans (no more than four simultaneous PRI variants).  
ProtocolType_x  
[Protocol Type]  
Same as the description for parameter ‘ProtocolType’ for a specific trunk ID (x = 0 to  
7).  
Mediant 2000 SIP User’s Manual  
122  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
TerminationSide  
[ISDN Termination Side]  
Selects the ISDN termination side. Applicable only to ISDN protocols.  
0 = ISDN User Termination Side (TE) (default)  
1 = ISDN Network Termination Side (NT)  
Note: select ‘User Side’ when the PSTN or PBX side is configured as ‘Network side’,  
and vice-versa. If you don’t know the Mediant 2000 ISDN termination side, choose  
‘User Side’ and refer to the ‘Status & Diagnostics>Channel Status’ screen. If the D-  
channel alarm is indicated, choose ‘Network Side’.  
TerminationSide_x  
[ISDN Termination Side]  
Same as the description for parameter ‘TerminationSide’ for a specific trunk ID (x = 0  
to 7).  
ClockMaster  
[Clock Master]  
0 = Recover clock from the E1/T1 line (default)  
1 = The clock is generated by the gateway  
Refer to Appendix E on page 205 for extended details of how to configure the  
gateway’s clock settings.  
ClockMaster_x  
[Clock Master]  
Same as the description for parameter ‘ClockMaster’ for a specific trunk ID (x = 0 to  
7).  
TDMBusClockSource  
[TDM Bus Clock Source]  
1 = Generate clock from local source (default).  
4 = Recover clock from PSTN line.  
Refer to Appendix E on page 205 for detailed information on configuring the  
gateway’s clock settings.  
TDMBusPSTNAutoClockEna 0 = Recover the clock from first E1/T1 line (default)  
ble  
1 = Recover the clock from any connected slave E1/T1 line  
This parameter is relevant only if "TDMBusClockSource = 4"  
[TDM Bus PSTN Auto Clock]  
0 to 7 (default = 0)  
TDMBusLocalReference  
Physical Trunk ID from which the gateway recovers its clock. Applicable only if  
"TDMBusClockSource = 4" and "PSTNAutoClockEnable = 0"  
[TDM Bus Local Reference]  
LineCode  
[Line Code]  
0 = use B8ZS line code (for T1 trunks only) default.  
1 = use AMI line code.  
2 = use HDB3 line code (for E1 trunks only).  
Use to select B8ZS or AMI for T1 spans, and HDB3 or AMI for E1 spans.  
LineCode_x  
Same as the description for parameter ‘LineCode’ for a specific trunk ID (x = 0 to 7).  
[Line Code]  
BchannelNegotiation  
[B-channel Negotiation]  
Determines the ISDN B-Channel negotiation mode.  
0 = Preferred  
1 = Exclusive (default)  
Applicable to ISDN protocols.  
NFASGroupNumber_x  
0 = Non NFAS trunk (default)  
[NFAS Group Number]  
1 to 4 = NFAS group number  
Indicates the NFAS group number (NFAS member) for the selected trunk.  
"x" identifies the Trunk ID (0-7).  
Trunks that belong to the same NFAS group have the same number.  
With ISDN Non-Facility Associated Signaling you can use single D-channel to control  
multiple PRI interfaces.  
Applicable only to T1 ISDN protocols.  
DchConfig_x  
0 = Primary Trunk (default)  
[D-channel Configuration]  
1 = Backup Trunk  
2 = NFAS Trunk  
D-channel configuration parameter defines primary, backup (optional) and B-  
channels only trunks.  
"x" identifies the Trunk ID (0-7).  
Primary trunk contains D-channel that is used for signaling.  
Backup trunk contains backup D-channel that is used if the primary D-channel fails.  
The other NFAS trunks contain only 24 B-channels, without a signaling D-channel.  
Applicable only to T1 ISDN protocols.  
Backup trunk is not supported for DMS PRI variants.  
Version 4.4  
123  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ISDNNFASInterfaceID_x  
Defines a different Interface ID for each T1 trunk.  
[NFAS Interface ID]  
The valid range is 0 to 100.  
The default interface ID equals to the trunk’s ID (0 to 7).  
’x’ identifies the trunk ID (0-7)  
Note: To set the NFAS interface ID, configure: ISDNIBehavior_x to include ‘512’  
feature, per each T1 trunk.  
CASTableIndex_x  
[CAS Table]  
Defines CAS protocol for each Trunk ID (x = 0 to 7) from a list of protocols defined by  
the "CASFileName_Y" parameter.  
For example:  
CASFileName_0 = 'E_M_WinkTable.dat'  
CASFileName_1 = 'E_M_ImmediateTable.dat'  
CASTableIndex_0 = 0  
CASTableIndex_1 = 0  
CASTableIndex_2 = 1  
CASTableIndex_3 = 1  
Trunks 0 and 1 use the E&M Winkstart CAS protocol, while trunks 2 and 3 use the  
E&M Immediate Start CAS protocol.  
CASFileName_0  
CASFileName_1  
CAS file name (such as "E_M_WinkTable.dat") defines the CAS protocol. It is  
possible to define up to 8 different CAS files by repeating the “CASFileName”  
parameter. Each CAS file can be associated with one or more of the gateway trunks  
using "CASTableIndex_x" parameter.  
CASFileName_7  
CASTablesNum  
1 to 8. Indicates how many CAS protocol configurations files are loaded.  
IdleABCDPattern  
Range 0x0 to 0xF  
[Idle ABCD Pattern]  
Default = -1 (default pattern = 0000)  
ABCD (CAS) Pattern to be applied to CAS signaling bus when the channel is idle.  
This is only relevant when using PSTN interface with CAS protocols. Set to -1 for  
default.  
IdlePCMPattern  
Range 0x00 to 0xFF  
[Idle PCM Pattern]  
Default = -1 (default pattern = 0xFF for µ-Law, 0x55 for A-law  
PCM Pattern to be applied to E1/T1 timeslot (B-channel) when the channel is idle.  
LineBuildOut.Loss  
0 = 0 dB (default)  
[Line Build Out Loss]  
1 = -7.5 dB  
2 = -15 dB  
3 = -22.5 dB  
Selects the line build out loss to be used for T1 trunks  
N/A for E1 trunks.  
0 = Disabled (default).  
1 = Enabled.  
ISDNRxOverlap  
Any number bigger than one = Number of digits to receive.  
Note 1: If enabled the Mediant 2000 receives ISDN called number that is sent in the  
"Overlap" mode.  
Note 2: The INVITE to IP is sent only after the number (including “Sending  
Complete” Info Element) was fully received (in SETUP and/or subsequent INFO  
Q.931 messages).  
For detailed information on ISDN overlap dialing, refer to Section 8.3 on page 140.  
Mediant 2000 SIP User’s Manual  
124  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ISDNRxOverlap_x  
[Enable Receiving of Overlap  
Dialing]  
Enable / disable Rx ISDN overlap per trunk ID (x = 0 to 7).  
0 = Disabled (default).  
1 = Enabled.  
Note 1: If enabled, the Mediant 2000 receives ISDN called number that is sent in the  
"Overlap" mode.  
Note 2: The SETUP message to IP is sent only after the number (including the  
‘Sending Complete’ Info Element) was fully received (via SETUP and/or subsequent  
INFO Q.931 messages).  
Note3: The ‘MaxDigits’ parameter can be used to limit the length of the collected  
number for Mediant 2000 ISDN overlap dialing (if sending complete was not  
received).  
TimeBetweenDigits  
Defines the time (in seconds) that the gateway waits between digits that are received  
[Inter Digit Timeout for Overlap from the ISDN when TelIP overlap dialing is performed. When this inter-digit  
Dial]  
timeout expires, the gateway uses the collected digits for the called destination  
number.  
The range is 1 to 10 seconds. The default value is 4 seconds.  
Defines the maximum number of collected destination number digits received from  
the ISDN when TelIP overlap dialing is performed. When the number of collected  
digits reaches the maximum, the gateway uses these digits for the called destination  
number.  
MaxDigits  
[Max Digits In Phone Num  
for Overlap Dialing]  
The range is 1 to 49. The default value is 30.  
DialToneDuration  
Duration (in seconds) of the dial tone played to an ISDN terminal.  
Applicable to overlap dialing when ‘ISDNInCallsBehavior = 65536’. The dial tone is  
played if the ISDN Setup message doesn’t include the called number.  
The valid range is 0 to 60. The default time is 5 seconds.  
R2Category  
[MFC R2 Category]  
MFC R2 Calling Party Category (CPC). The parameter provides information on  
calling party such as National or International call, Operator or Subscriber and  
Subscriber priority. The parameter range is 1 to 15, defining one of the MFC R2  
tones.  
RegretTime  
Determines the time period (in seconds) the gateway waits for an MFC R2 Resume  
(Reanswer) signal once a Suspend (Clear back) signal was received from the PBX. If  
this timer expires, the call is released.  
The valid range is 0 to 255. The default value is 0.  
Applicable only for MFC R2 CAS Brazil variant.  
HeldTimeout  
Determines the time period the gateway can stay on-hold. If a Resume (un-hold Re-  
Invite) message is received before the timer expires, the call is renewed. If this timer  
expires, the call is released.  
-1  
= Indefinitely (default).  
0 - 2400 =Time to wait in seconds.  
Currently applicable only to MFC R2 CAS variants.  
Version 4.4  
125  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ISDN Flexible Behavior Parameters  
ISDN protocol is implemented in different Switches / PBXs by different vendors. Several implementations vary a little  
from the specification. Therefore, to provide a flexible interface that supports these ISDN variants, the ISDN behavior  
parameters are used.  
ISDNInCallsBehavior  
2048  
= Sends Channel ID in the first response to an incoming Q.931 Call Setup  
message. Otherwise, the Channel ID is sent only if the gateway requires to change  
the proposed Channel ID (default).  
[Incoming Calls Behavior]  
8192  
= Sends Channel ID in a Q.931 Call Proceeding message.  
65536 = Includes Progress Indicator (PI=8) in Setup ACK message, if an empty  
called number is received in an incoming Setup message. Applicable to overlap  
dialing mode. The parameter also directs the gateway to play a dial tone (for  
‘DialToneDuration’), until the next called number digits are received.  
262144 = NI-2 second redirect number – Users can select and use (in Invite  
messages) the NI-2 second redirect number, if two redirect numbers are received in  
Q.931 Setup for incoming TelIP calls.  
Note: To configure the gateway to support several ‘ISDNInCallsBehavior’ features,  
summarize the individual feature values. For example to support both ‘2048’ and  
‘65536’ features, set ‘ISDNInCallsBehavior = 67584.  
ISDNIBehavior  
[Q.931 Layer Response  
Behavior]  
1 = Q.931 Status message isn’t sent if Q.931 received message contains an  
unknown/unrecognized IE(s). By default the Status message is sent. This parameter  
applies only to PRI variants in which sending of Status message is optional.  
2 = Q.931 Status message isn’t sent if an optional IE with invalid content is received.  
By default the Status message is sent. This parameter applies only to PRI variants in  
which sending of Status message is optional.  
4 = Accepts unknown/unrecognized Facility IE. Otherwise, (default) the Q.931  
message that contains the unknown Facility IE is rejected. This parameter applies to  
PRI variants where a complete ASN1 decoding is performed on Facility IE.  
128 = Connect ACK message is sent in response to received Q.931 Connect.  
Applicable only to Euro ISDN User side outgoing calls. Otherwise, the Connect ACK  
is not sent (default).  
512 = Enables to configure T1 NFAS Interface ID (refer to the parameter  
‘ISDNNFASInterfaceID_x’). Applicable to 4/5ESS, DMS, NI-2 and HKT variants.  
2048 = Always set the Channel Identification IE to explicit Interface ID, even if the B-  
channel is on the same trunk as the D-channel. Applicable to 4/5ESS, DMS and NI-2  
variants.  
65536 = Applicable to ETSI, NI-2 and 5ESS. The calling party number (octet 3a) is  
always present even when presentation and screening are at their default.  
131072 = Clears the call on reception of Q.931 Status with incompatible state.  
Otherwise, (default) no action is taken.  
Note: To configure the gateway to support several ‘ISDNIBehavior’ features,  
summarize the individual feature values. For example to support both ‘512’ and  
‘2048’ features, set ‘ISDNIBehavior = 2560’.  
Mediant 2000 SIP User’s Manual  
126  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-6: E1/T1/J1 Configuration Parameters (continues on pages 122 to 127)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
ISDNGeneralCCBehavior  
16 = The gateway clears down the call if it receives a Notify message specifying  
[General Call Control Behavior] ‘User-Suspended’. A Notify (User-Suspended) message is used by some networks  
(e.g., in Italy or Denmark) to indicate that the remote user has cleared the call,  
especially in the case of a long distance voice call.  
32 = Applies only to ETSI E1 lines (30B+D). Enables handling the differences  
between the newer QSIG standard (ETS 300-172) and other ETSI-based standards  
(ETS 300-102 and ETS 300-403) in the conversion of B-channel ID values into  
timeslot values:  
In ‘regular ETSI’ standards, the timeslot is identical to the B-channel ID value,  
and the range for both is 1 to 15 and 17 to 31. The D-channel is identified as  
channel-id #16 and carried into the timeslot #16.  
In newer QSIG standards, the channel-id range is 1 to 30, but the timeslot range  
is still 1 to 15 and 17 to 31. The D-channel is not identified as channel-id #16,  
but is still carried into the timeslot #16.  
When this bit is set, the channel ID #16 is considered as a valid B-channel ID, but  
timeslot values are converted to reflect the range 1 to 15 and 17 to 31. This is the  
new QSIG mode of operation. When this bit is not set (default), the channel_id #16 is  
not allowed, as for all ETSI-like standards.  
ISDNOutCallsBehavior  
[Outgoing Calls Behavior]  
1024 = Numbering plan / type for T1 IPTel calling number are defined according to  
the manipulation tables or according to RPID header (default). Otherwise, the Plan /  
type for T1 calls are set according to the length of the calling number  
ISDNIBehavior_x  
[Q.931 Layer Response  
Behavior]  
Same as the description for parameter ‘ISDNBehavior’ for a specific trunk ID (x = 0 to  
7)  
ISDNInCallsBehavior_x  
[Incoming Calls Behavior]  
Same as the description for parameter ‘ISDNInCallsBehavior’ for a specific trunk ID  
(x = 0 to 7)  
ISDNOutCallsBehavior_x  
[Outgoing Calls Behavior]  
Same as the description for parameter ‘ISDNOutCallsBehavior’ for a specific trunk ID  
(x = 0 to 7)  
Version 4.4  
127  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
6.12 Channel Parameters  
The Channel Parameters define the DTMF, fax and modem transfer modes. Refer to Appendix D  
on page 203 for a detailed description of Fax and Modem transfer modes; refer to Section 8.2 on  
page 139 for detailed description on DTMF transport modes.  
Note that the Default Channel Parameters are applied to all Mediant 2000 channels.  
Note:  
In Table 6-7, parameters in brackets are the format in the Embedded Web  
Server *.  
Table 6-7: Channel Parameters (continues on pages 128 to 131)  
ini File Field Name  
Web Parameter Name*  
Valid Range and Description  
0 to 150 msec (default = 70)  
DJBufMinDelay  
[Dynamic Jitter Buffer Minimum  
Delay]  
Dynamic Jitter Buffer Minimum Delay.  
Note: For more information on the Jitter Buffer, refer to Section 6.12.1 on page  
132.  
DJBufOptFactor  
[Dynamic Jitter Buffer Optimization  
Factor]  
Dynamic Jitter Buffer frame error / delay optimization factor.  
You can enter a value from 0 to 13.  
The default factor is 7.  
Note 1: Set to 13 for data (fax & modem) calls.  
Note 2: For more information on the Jitter Buffer, refer to Section 6.12.1 on page  
132.  
FaxTransportMode  
Fax transport mode that the gateway uses.  
[Fax Transport Mode]  
You can select:  
0 = Disable.  
1 = T.38 Relay (default).  
2 = Bypass.  
Note: If parameter IsFaxUsed = 1, then FaxTransportMode is always set to 1  
(T.38 relay).  
FaxRelayEnhancedRedundancyDe  
pth  
0 to 4 (default = 0)  
[Fax Relay Enhanced Redundancy  
Depth]  
Number of repetitions applied to control packets when using T.38 standard.  
FaxRelayRedundancyDepth  
[Fax Relay Redundancy Depth]  
Number of times that each fax relay payload is retransmitted to the network.  
You can enter a value from 0 to 2.  
The default value is 0.  
FaxRelayMaxRate  
Limits the maximum rate at which fax messages are transmitted.  
[Fax Relay Max Rate (bps)]  
0 = 2.4 kbps  
1 = 4.8 kbps  
2 = 7.2 kbps  
3 = 9.6 kbps  
4 = 12.0 kbps  
5 = 14.4 kbps (default).  
FaxRelayECMEnable  
[Fax Relay ECM Enable]  
0 = Disable using ECM (Error Correction Mode) mode during fax relay.  
1 = Enable using ECM mode during fax relay (default).  
FaxModemBypassCoderType  
Coder the gateway uses when performing fax/modem bypass. Usually, high-bit-  
[Fax/Modem Bypass Coder Type]  
rate coders such as G.711 should be used.  
You can select:  
0 = G711 A-law 64 (default).  
1 = G711 µ-law.  
4 = G726 32.  
11 = G726_40.  
Mediant 2000 SIP User’s Manual  
128  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-7: Channel Parameters (continues on pages 128 to 131)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
CNGDetectorMode  
[CNG Detector Mode]  
0 = Disable (default).  
1 = Event Only (N/A).  
2 = Relay. T.38 fax relay session is initiated by the originating fax if ‘IsFaxUsed =  
1’. Note that using this mode isn’t recommended.  
FaxModemBypassM  
Number of (20 msec) coder payloads that are used to generate a fax/modem  
[Fax/Modem Bypass Packing Factor] bypass packet.  
You can enter a value of 1, 2 or 3 coder payloads.  
The default value is 1 coder payload.  
FaxBypassPayloadType  
[Fax Bypass Payload Type]  
Determines the fax bypass RTP dynamic payload type.  
The valid range is 96 to 120. The default value is 102.  
ModemBypassPayloadType  
Modem Bypass dynamic payload type (range 0-127).  
The default value is 103.  
DetFaxOnAnswerTone  
[Detect Fax on Answer Tone]  
0 = Starts T.38 procedure on detection of V.21 preamble (default).  
1 = Starts T.38 Procedure on detection of CED fax answering tone.  
FaxModemBypassBasicRTPPacket 0 = set internally (default)  
Interval  
1 = 5 msec (not recommended)  
2 = 10 msec  
3 = 20 msec  
FaxModemBypassDJBufMinDelay 0 to 150 msec (default=40)  
Determines the Jitter Buffer delay during fax and modem bypass session  
NSEMode  
Cisco compatible fax and modem bypass mode  
0 = NSE disabled (default)  
1 = NSE enabled  
Note 1: This feature can be used only if VxxModemTransportType=2 (Bypass)  
Note 2: If NSE mode is enabled the SDP contains the following line:  
“a=rtpmap:100 X-NSE/8000”  
Note 3: To use this feature:  
The Cisco gateway must include the following definition: "modem  
passthrough nse payload-type 100 codec g711alaw".  
Set the Modem transport type to Bypass mode (‘VxxModemTransportType  
= 2’) for all modems.  
Configure the gateway parameter NSEPayloadType= 100  
In NSE bypass mode the gateway starts using G.711 A-Law (default) or G.711µ-  
Law, according to the parameter ‘FaxModemBypassCoderType’. The payload  
type used with these G.711 coders is a standard one (8 for G.711 A-Law and 0  
for G.711 µ-Law). The parameters defining payload type for the “old”  
AudioCodes’ Bypass mode. ‘FaxBypassPayloadType’ and  
‘ModemBypassPayloadType’ are not used with NSE Bypass. The bypass packet  
interval is selected according to the parameter  
‘FaxModemBypassBasicRtpPacketInterval’.  
NSEPayloadType  
NSE payload type for Cisco Bypass compatible mode.  
The valid range is 96-127. The default value is 105.  
Note: Cisco gateways usually use NSE payload type of 100.  
V22ModemTransportType  
[V.22 Modem Transport Type]  
V.22 Modem Transport Type that the gateway uses.  
You can select:  
0 = Transparent  
2 = Modem Bypass (default).  
V23ModemTransportType  
[V.23 Modem Transport Type]  
V.23 Modem Transport Type that the gateway uses.  
You can select:  
0 = Transparent  
2 = Modem Bypass (default).  
V32ModemTransportType  
[V.32 Modem Transport Type]  
V.32 Modem Transport Type that the gateway uses.  
You can select:  
0 = Transparent  
2 = Modem Bypass (default).  
Note: This option applies to V.32 and V.32bis modems.  
Version 4.4  
129  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table 6-7: Channel Parameters (continues on pages 128 to 131)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
V34ModemTransportType  
[V.34 Modem Transport Type]  
V.34 Modem Transport Type that the gateway uses.  
You can select:  
0 = Transparent  
2 = Modem Bypass (default).  
Note: This option applies to V.34 and V.90 modems.  
InputGain  
[Input Gain]  
PCM input gain control in dB. This parameter sets the level for the received  
(PSTNIP) signal.  
You can enter a value from -32 to 31 dB.  
The default value is 0 dB.  
Note: This parameter is intended for advanced users. Changing it affects other  
gateway functionalities.  
VoiceVolume  
[Voice Volume]  
Voice gain control in dB. This parameter sets the level for the transmitted  
(IPPSTN) signal.  
You can enter a value from -32 to 31 dB.  
The default value is 0 dB.  
RTPRedundancyDepth  
[RTP Redundancy Depth]  
0 = Disable redundancy packets generation (default)  
1 = Enable generation of RFC 2198 redundancy packets.  
RFC2198PayloadType  
RTP redundancy packet payload type, according to RFC 2198.  
The range is 96-127. The default is 104.  
Applicable if “RTPRedundancyDepth=1”  
EnableSilenceCompression  
0 = Silence Suppression disabled (default).  
[Silence Suppression]  
1 = Silence Suppression enabled.  
2 [Enable without adaptation] = A single silence packet is sent during silence  
period (applicable only to G.729).  
The parameter SCE is used to  
maintain backward compatibility.  
Silence Suppression is a method conserving bandwidth on VoIP calls by not  
sending packets when silence is detected.  
Note: If the selected coder is G.729, the following rules determine the value of  
the “annexb” parameter of the fmtp attribute in the SDP.  
EnableSilenceCompression = 0 “annexb=no”.  
EnableSilenceCompression = 1 “annexb=yes”.  
EnableSilenceCompression = 2 and IsCiscoSCEMode = 0 “annexb=yes”.  
EnableSilenceCompression = 2 and IsCiscoSCEMode = 1 “annexb=no”.  
IsCiscoSCEMode  
0 = There isn’t a Cisco gateway at the remote side (default).  
1 = There is a Cisco gateway at the remote side.  
When there is a Cisco gateway at the remote side, the local gateway must set  
the value of the “annexb” parameter of the fmtp attribute in the SDP to “no”. This  
logic should be used if ‘EnableSilenceCompression = 2’ (enable without  
adaptation). In this case, Silence Suppression should be used on the channel but  
not declared in the SDP.  
EnableEchoCanceller  
0 = Echo Canceler disabled.  
[Echo Canceler]  
1 = Echo Canceler Enabled (default).  
The parameter ECE is used to  
Note: Refer also to the parameters ‘MaxEchoCancellerLength’ and  
maintain backward compatibility.  
‘EchoCancellerLength’ (described in Table 6-1 on page 90).  
EnableStandardSIDPayloadType  
0 = Disable (default).  
[Enable RFC 3389 CN Payload Type] 1 = Enable.  
If enabled, the SID (comfort noise) packets are sent with the RTP SID payload  
type according to RFC 3389. Applicable to G.711 and G.726 coders.  
If disabled, the G.711 SID packets are sent in a proprietary method.  
DTMFVolume  
[DTMF Volume]  
-31 to 0 corresponding to -31 dBm to 0 dBm in 1 dB steps (default = -11 dBm)  
DTMF gain control.  
DTMFTransportType  
[DTMF Transport Type]  
0 = Erase digits from voice stream, do not relay to remote.  
2 = Digits remain in voice stream.  
3 = Erase digits from voice stream, relay to remote according to RFC 2833.  
Note: This parameter is automatically updated if one of the following parameters  
is configured: IsDTMFUsed, TxDTMFOption or RxDTMFOption.  
Mediant 2000 SIP User’s Manual  
130  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
Table 6-7: Channel Parameters (continues on pages 128 to 131)  
ini File Field Name  
Valid Range and Description  
Web Parameter Name*  
RFC2833PayloadType  
The RFC 2833 DTMF relay dynamic payload type.  
[RFC 2833 Payload Type]  
Range: 96 to 99, 106 to 127; Default = 96  
The 100, 102 to 105 range is allocated for proprietary usage.  
Cisco is using payload type 101 for RFC 2833.  
Note: When RFC 2833 payload type (PT) negotiation is used  
(TxDTMFOption=4), this payload type is used for the received DTMF packets. If  
negotiation isn’t used, this payload type is used for receive and for transmit.  
MGCPDTMFDetectionPoint  
0 = DTMF event is reported on the start of a detected DTMF digit.  
1 = DTMF event is reported on the end of a detected DTMF digit (default).  
Note: The parameter is used for out-of-band dialing.  
DTMFInterDigitInterval  
DTMFDigitLength  
Time in msec between generated DTMFs to PSTN side  
Default = 100 (msec)  
Time in msec for generating of DTMF tone to PSTN side  
Default = 100 (msec)  
Version 4.4  
131  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
6.12.1 Dynamic Jitter Buffer Operation  
Voice frames are transmitted at a fixed rate. If the frames arrive at the other end at the same rate,  
voice quality is perceived as good. In many cases, however, some frames can arrive slightly  
faster or slower than the other frames. This is called jitter (delay variation), and degrades the  
perceived voice quality. To minimize this problem, the gateway uses a jitter buffer. The jitter  
buffer collects voice packets, stores them and sends them to the voice processor in evenly  
spaced intervals.  
The Mediant 2000 uses a dynamic jitter buffer that can be configured using two parameters:  
Minimum delay, ‘DJBufMinDelay’ (0 msec to 150 msec). Defines the starting jitter capacity of  
the buffer. For example, at 0 msec, there is no buffering at the start. At the default level of 70  
msec, the gateway always buffers incoming packets by at least 70 msec worth of voice  
frames.  
Optimization Factor, ‘DJBufOptFactor’ (0 to 12, 13). Defines how the jitter buffer tracks to  
changing network conditions. When set at its maximum value of 12, the dynamic buffer  
aggressively tracks changes in delay (based on packet loss statistics) to increase the size of  
the buffer and doesn’t decays back down. This results in the best packet error performance,  
but at the cost of extra delay. At the minimum value of 0, the buffer tracks delays only to  
compensate for clock drift and quickly decays back to the minimum level. This optimizes the  
delay performance but at the expense of a higher error rate.  
The default settings of 70 msec Minimum delay and 7 Optimization Factor should provide a good  
compromise between delay and error rate. The jitter buffer "holds" incoming packets for 70 msec  
before making them available for decoding into voice. The coder polls frames from the buffer at  
regular intervals to produce continuous speech. As long as delays in the network do not change  
(jitter) by more than 70 msec from one packet to the next, there is always a sample in the buffer  
for the coder to use. If there is more than 70 msec of delay at any time during the call, the packet  
arrives too late. The coder tries to access a frame and is not able to find one. The coder must  
produce a voice sample even if a frame is not available. It therefore compensates for the missing  
packet by adding a Bad-Frame-Interpolation (BFI) packet. This loss is then flagged as the buffer  
being too small. The dynamic algorithm then causes the size of the buffer to increase for the next  
voice session. The size of the buffer may decrease again if the gateway notices that the buffer is  
not filling up as much as expected. At no time does the buffer decrease to less than the minimum  
size configured by the Minimum delay parameter.  
Special Optimization Factor Value: 13  
One of the purposes of the Jitter Buffer mechanism is to compensate for clock drift. If the two  
sides of the VoIP call are not synchronized to the same clock source, one RTP source generates  
packets at a lower rate, causing under-runs at the remote Jitter Buffer. In normal operation  
(optimization factor 0 to 12), the Jitter Buffer mechanism detects and compensates for the clock  
drift by occasionally dropping a voice packet or by adding a BFI packet.  
Fax and modem devices are sensitive to small packet losses or to added BFI packets. Therefore  
to achieve better performance during modem and fax calls, the Optimization Factor should be set  
to 13. In this special mode the clock drift correction is performed less frequently - only when the  
Jitter Buffer is completely empty or completely full. When such condition occurs, the correction is  
performed by dropping several voice packets simultaneously or by adding several BFI packets  
simultaneously, so that the Jitter Buffer returns to its normal condition.  
Mediant 2000 SIP User’s Manual  
132  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
6. ini File Configuration of the Mediant 2000  
6.13 Configuration Files Parameters  
The configuration files (Call Progress Tones, PRT, Voice Prompts and CAS) can be loaded to the  
Mediant 2000 via the Embedded Web Server (refer to Section 5.11.2 on page 82), or via TFTP  
session.  
To load the configuration files via TFTP, take these 3 steps:  
1. In the ini file, define the files to be loaded to the device. You can also define in the ini file  
whether the loaded files should be stored in the non-volatile memory so that the TFTP  
process is not required every time the device boots up.  
2. Locate the configuration files you want to load and the ini file in the same directory.  
3. Invoke a BootP/TFTP session; the ini and configuration files are loaded onto the device.  
Table 6-8 below describes the ini file parameters that are associated with the configuration files.  
Table 6-8: Configuration File Parameters  
Valid Range and Description  
ini File Field Name  
CallProgressTonesFilename  
The name of the file containing the Call Progress Tones definitions. Refer to Section  
7 for additional information on how to create and load this file.  
VoicePromptsFileName  
CASfilename  
The name (and path) of the file containing the Voice Prompts definitions. Refer to  
Section 7.2 on page 137 for additional information on how to create and load this  
file.  
This is the name of the file containing specific CAS protocol definition (such as  
‘E_M_WinkTable.dat’). These files are provided to support various types of CAS  
signaling.  
CASfilename_x  
It is possible to load up to 8 different CAS files (x=0 to 7), by repeating the  
CASFileName parameter. Each CAS file can be associated with one or more of the  
gateway trunks, using "CASTableIndex_x" parameter.  
CASTablesNum  
Number, 1 to 8. Specifies how many CAS configuration files are loaded.  
The name (and path) of the file containing the Prerecorded Tones.  
PrerecordedTonesFileName  
SaveConfiguration  
Set to 1 to store the CPT, PRT, CAS and Voice Prompts files in the non-volatile  
memory.  
Version 4.4  
133  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
134  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
7. Configuration Files  
7 Configuration Files  
This section describes the configuration (dat) files that are load (in addition to the ini file) to the  
gateway. The configuration files are:  
Call Progress Tones file (refer to Section 7.1 below).  
Prerecorded Tones file (refer to Section 7.2 on page 137).  
Voice Prompts file (refer to Section 7.3 on page 137).  
CAS protocol configuration files (refer to Section 7.4 on page 138).  
To load any of the configuration files to the Mediant 2000 use the Embedded Web Server (refer to  
Section 5.11.2 on page 82) or alternatively specify the name of the relevant configuration file in  
the gateway’s ini file and load it (the ini file) to the gateway (refer to Section B.6 on page 190).  
7.1 Configuring the Call Progress Tones  
The Call Progress Tones, configuration file used by the Mediant 2000 is a binary file (with the  
extension dat) which contains the definitions of the Call Progress Tones (levels and frequencies)  
that are detected / generated by the Mediant 2000.  
Users can either use, one of the supplied Mediant 2000 configuration (dat) files, or construct their  
own file. To construct their own configuration file, users are recommended, to modify the supplied  
usa_tone.ini file (in any standard text editor) to suit their specific requirements, and to convert it  
(the modified ini file) into binary format using the “TrunkPack Downloadable Conversion Utility”  
supplied with the software package. For the description of the procedure on how to convert CPT  
ini file to a binary dat file, refer to Section G.1.1 on page 214.  
Note that only the dat file can be loaded to the Mediant 2000 gateway.  
To load the Call Progress Tones (dat) file to the Mediant 2000, use the Embedded Web Server  
(refer to Section 5.11.2 on page 82) or the ini file (refer to Section 6.12.1 on page 132).  
7.1.1 Format of the Call Progress Tones Section in the ini File  
Using the CPT section of this configuration file, the User can create up to 16 different Call  
Progress Tones using up to 15 different frequencies (in the range of 300 Hz to 1980 Hz). Each of  
these Call Progress Tones is specified by its tone frequency (either single or dual frequencies are  
supported) and its tone cadence. The tone cadence is specified by 2 sets of on/off periods (you  
can discard the use of the first on/off cycle by setting the relevant parameters to zero). When a  
tone is composed of a single frequency, the second frequency field must be set to zero.  
For a continuous tone (such as dial tone), only the “First Signal On time” should be specified. In  
this case, the parameter specifies the detection period. For example, if it equals 300, the tone is  
detected after 3 seconds (300 x 10 msec). The minimum detection time is 100 msec.  
Users can specify several tones of the same type. These additional tones are used only for tone  
detection. Generation of a specific tone conforms to the first definition of the specific tone. For  
example, Users can define an additional dial tone by appending the second dial tone’s definition  
lines to the first tone definition in the ini file. The Mediant 2000 reports dial tone detection if either  
of the two tones is detected.  
The Call Progress Tones section of the ini file format starts from the following string:  
[NUMBER OF CALL PROGRESS TONES] – Contains the following key:  
“Number of Call Progress Tones” defining the number of Call Progress Tones that are  
defined in the file.  
Version 4.4  
135  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
[CALL PROGRESS TONE #X] – containing the Xth tone definition (starting from 1 and not  
exceeding the number of Call Progress Tones defined in the first section) using the following  
keys:  
Tone Type – Call Progress Tone type  
Figure 7-1: Call Progress Tone Types  
1. Dial Tone  
2. Ringback Tone  
3. Busy Tone  
7. Reorder Tone  
17.Call Waiting Ringback Tone  
23. Hold Tone  
Low Freq [Hz] – Frequency in hertz of the lower tone component in case of dual  
frequency tone, or the frequency of the tone in case of single tone.  
High Freq [Hz] – Frequency in hertz of the higher tone component in case of dual  
frequency tone, or zero (0) in case of single tone.  
Low Freq Level [-dBm] – Generation level 0 dBm to –31 dBm in [dBm].  
High Freq Level – Generation level. 0 to –31 dBm. The value should be set to ‘32’ in  
the case of a single tone.  
First Signal On Time [10 msec] – “Signal On” period (in 10 msec units) for the first  
cadence on-off cycle.  
First Signal Off Time [10 msec] – “Signal Off” period (in 10 msec units) for the first  
cadence on-off cycle.  
Second Signal On Time [10 msec] – “Signal On” period (in 10 msec units) for the  
second cadence on-off cycle.  
Second Signal Off Time [10 msec] – “Signal Off” period (in 10 msec units) for the  
second cadence on-off cycle.  
Default Duration [msec] - The default duration (in 1 msec units) of the generated tone.  
Note 1: When the same frequency is used for a continuous tone and a cadence tone,  
the ‘Signal On Time’ parameter of the continues tone must have a value that  
is greater than the ‘Signal On Time’ parameter of the cadence tone.  
Otherwise the continues tone is detected instead of the cadence tone.  
Note 2: The tones frequency should differ by at least 40 Hz from one tone to other  
defined tones.  
For example: to configure the dial tone to 440 Hz only, define the following text:  
Figure 7-2: Defining a Dial Tone Example  
#Dial tone  
[CALL PROGRESS TONE #1]  
Tone Type=1  
Low Freq [Hz]=440  
High Freq [Hz]=0  
Low Freq Level [-dBm]=10 (-10 dBm)  
High Freq Level [-dBm]=32 (use 32 only if a single tone is required)  
First Signal On Time [10msec]=300; the dial tone is detected after 3 sec  
First Signal Off Time [10msec]=0  
Second Signal On Time [10msec]=0  
Second Signal Off Time [10msec]=0  
Mediant 2000 SIP User’s Manual  
136  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
7. Configuration Files  
7.2 Prerecorded Tones (PRT) File  
The Call Progress Tones mechanism has several limitations, such as a limited number of  
predefined tones and a limited number of frequency integrations in one tone. To work around  
these limitations and provide tone generation capability that is more flexible, the PRT file can be  
used. If a specific prerecorded tone exists in the PRT file, it takes precedence over the same tone  
that exists in the CPT file and is played instead of it.  
Note that the prerecorded tones are used only for generation of tones. Detection of tones is  
performed according to the CPT file.  
7.2.1 PRT File Format  
The PRT dat file contains a set of prerecorded tones to be played by the Mediant 2000 during  
operation. Up to 40 tones (totaling approximately 10 minutes) can be stored in a single file in flash  
memory. The prerecorded tones (raw data PCM or L8 files) are prepared offline using standard  
recording utilities (such as CoolEditTM) and combined into a single file using the TrunkPack  
Downloadable Conversion utility (refer to Section G.1.4 on page 218).  
The raw data files must be recorded with the following characteristics:  
Coders:  
G.711 A-law, G.711 µ-law or Linear PCM  
Rate:  
8 kHz  
8-bit  
Resolution:  
Channels:  
mono  
The generated PRT file can then be loaded to the Mediant 2000 using the BootP/TFTP utility  
(refer to Section 6.13 on page133) or via the Embedded Web Server (Section 5.11.2 on page 82).  
The prerecorded tones are played repeatedly. This enables you to record only part of the tone  
and play it for the full duration. For example, if a tone has a cadence of 2 seconds on and 4  
seconds off, the recorded file should contain only these 6 seconds. The PRT module repeatedly  
plays this cadence for the configured duration. Similarly, a continuous tone can be played by  
repeating only part of it.  
7.3 Voice Prompts File  
Note:  
The Voice Prompts file is applicable only to the VXML application.  
The voice announcement file contains a set of Voice Prompts to be played by the Mediant 2000  
during operation. The voice announcements are prepared offline using standard recording utilities  
and combined into a single file using the TrunkPack Downloadable Conversion Utility.  
The generated announcement file can then be loaded to the Mediant 2000 using the BootP/TFTP  
utility (refer to Section 6.12.1 on page 132) or via the Embedded Web Server (Section 5.11.2 on  
page 82).  
If the size of the combined Voice Prompts file is less than 1 MB, it can permanently be stored in  
flash memory. Larger files, up to 10 MB, are stored in RAM, and should be loaded again (using  
BootP/TFTP utility) after the Mediant 2000 is reset.  
The Voice Prompts integrated file is a collection of raw voice recordings and / or wav files. These  
recordings can be prepared using standard utilities, such as CoolEdit, GoldwaveTM and others.  
The raw voice recordings must be sampled at 8000 kHz / mono / 8 bit. The wav files must be  
recorded with G.711µ-Law/A-Law/Linear.  
Version 4.4  
137  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
When the list of recorded files is converted to a single voiceprompts.dat file, every Voice Prompt  
is tagged with an ID number, starting with “1”. This ID is used later by the Mediant 2000 to start  
playing the correct announcement. Up to 1000 Voice Prompts can be used.  
Note:  
The Voice Prompt ID is used in the VXML file to specify the message that is  
to be played.  
AudioCodes provides a professionally recorded English (U.S.) Voice Prompts file.  
To generate and load the Voice Prompts file, take these 3 steps:  
1. Prepare one or more voice files using standard utilities.  
2. Use the TrunkPack Downloadable Conversion Utility to generate the voiceprompts.dat file  
from the pre-recorded voice messages (refer to Section G.1.2 on page 215).  
3. Load the voiceprompts.dat file to the Mediant 2000 either by using a TFTP procedure (refer  
to Section 6.12.1 on page 132), or via the Embedded Web Server (Section 5.11.2 on page  
82).  
7.4 CAS Protocol Configuration Files  
The CAS Protocol Configuration Files contain the CAS Protocol definitions to be used for CAS-  
terminated trunks, Users can either use the files supplied or construct their own files.  
It is possible to load up to eight files and to use different files for different trunks.  
Note that all CAS files loaded together must belong to the same Trunk Type (either E1 or T1).  
Mediant 2000 SIP User’s Manual  
138  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8 Gateway Capabilities Description  
8.1 Proxy or Registrar Registration Example  
REGISTER sip:servername SIP/2.0  
VIA: SIP/2.0/UDP 212.179.22.229;branch=z9hG4bRaC7AU234  
From: <sip:GWRegistrationName@sipgatewayname>;tag=1c29347  
To: <sip:GWRegistrationName@sipgatewayname>  
Seq: 1 REGISTER  
Expires: 3600  
Contact: sip:[email protected]  
Content-Length: 0  
The "servername" string is defined according to the following rules:  
The "servername" is equal to "RegistrarName" if configured. The "RegistrarName" can be  
any string.  
Otherwise, the "servername" is equal to "RegistrarIP" (either FQDN or numerical IP  
address), if configured.  
Otherwise the "servername" is equal to "ProxyName" if configured. The "ProxyName" can be  
any string.  
Otherwise the "servername" is equal to "ProxyIP" (either FQDN or numerical IP address).  
The parameter ‘GWRegistrationName’ can be any string. If the parameter is not defined, the  
parameter ‘UserName’ is used instead.  
The "sipgatewayname" parameter (defined in the ini file or set from the Web browser), can be  
any string. Some Proxy servers require that the "sipgatewayname" (in Register messages) is  
set equal to the Registrar / Proxy IP address or to the Registrar / Proxy domain name.  
The Register message is sent to the Registrar’s IP address (if configured) or to the Proxy’s IP  
address. The message is sent once per gateway. The registration request is resent according to  
the parameter ‘RegistrartionTimeDivider’. For example, if ‘RegistrationTimeDivider = 70’ (%) and  
Registration Expires time = 3600, the gateway resends its registration request after 3600 x 70% =  
2520 sec. The default value of ‘RegistrartionTimeDivider’ is 50%.  
8.2 Redirect Number and Calling Name (Display)  
The following tables define the Mediant 2000 redirect number and calling name (Display) support  
for various PRI variants:  
Table 8-1: Calling Name (Display)  
DMS-100  
NI-2  
4/5ESS  
Euro ISDN  
NTTE  
Yes  
Yes  
Yes  
Yes  
No  
No  
Yes  
No  
TENT  
Table 8-2: Redirect Number  
NI-2  
DMS-100  
4/5ESS  
Euro ISDN  
NTTE  
Yes  
Yes  
Yes  
Yes  
Yes  
Yes  
Yes  
No  
TENT  
Version 4.4  
139  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
8.3 ISDN Overlap Dialing  
Overlap dialing is a dialing scheme used by several ISDN variants to send and / or receive called  
number digits one right after the other (or several at a time). As opposed to the enbloc dialing  
scheme in which a complete number is sent.  
The Mediant 2000 can optionally support ISDN overlap dialing for incoming ISDN calls for the  
entire gateway by setting ‘ISDNRxOverlap’ to 1, or per E1/T1 span by setting ‘ISDNRxOverlap_x’  
to 1 (‘x’ represents the number of the trunk, 0 to 7).  
To play a Dial tone to the ISDN user side when an empty called number is received, set  
‘ISDNINCallsBehavior = 65536’ (bit #16) causing the Progress Indicator to be included in the  
SetupAck ISDN message.  
The Mediant 2000 stops collecting digits (for ISDNIP calls) when:  
The sending device transmits a "sending complete" IE in the ISDN Setup or the following  
Info messages to signal that no more digits are going to be sent.  
The inter-digit timeout (configured by the parameter ‘TimeBetweenDigits’) expires. The  
default for this timeout is 4 seconds.  
The maximum allowed number of digits (configured by the parameter ‘MaxDigits’) is  
reached. The default is 30 digits.  
Relevant parameters (described in Table 6-6 on page 122):  
ISDNRxOverlap  
ISDNRxOverlap_x  
TimeBetweenDigits  
MaxDigits  
ISDNInCallsBehavior  
Mediant 2000 SIP User’s Manual  
140  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.4 Using ISDN NFAS  
In regular (non-NFAS) T1 ISDN trunks, a single 64 kbps channel carries signaling for the other 23  
B-channels of that particular T1 trunk. This channel is called the D-channel and usually resides  
on timeslot # 24.  
The ISDN Non-Facility Associated Signaling (NFAS) feature enables use of a single D-channel to  
control multiple PRI interfaces.  
With NFAS it is possible to define a group of T1 trunks, called an NFAS group, in which a single  
D-channel carries ISDN signaling messages for the entire group. The NFAS group’s B-channels  
are used to carry traffic, such as voice or data. The NFAS mechanism also enables definition of a  
backup D-channel on a different T1 trunk, to be used if the primary D-channel fails.  
The NFAS group comprises several T1 trunks. Each T1 trunk is called an ‘NFAS member’. The  
T1 trunk whose D-channel is used for signaling is called the ‘Primary NFAS Trunk’. The T1 trunk  
whose D-channel is used for backup signaling is called the ‘Backup NFAS Trunk’. The primary  
and backup trunks each carry 23 B-channels while all other NFAS trunks each carry 24  
B-channels.  
The Mediant 2000 supports multiple NFAS groups. Each group should contain different T1 trunks.  
The NFAS group is identified by an NFAS GroupID number (possible values are 1, 2, 3 and 4).  
To assign a number of T1 trunks to the same NFAS group, use the parameter  
‘NFASGroupNumber_x = groupID’. ‘x’ stands for the physical trunkID (0 to 7).  
The parameter ‘DchConfig_x = Trunk_type’ is used to define the type of NFAS trunk. Trunk_type  
is set to 0 for the primary trunk, to 1 for the backup trunk and to 2 for an ordinary NFAS trunk. ‘x’  
stands for the physical trunkID (0 to 7).  
For example, to assign the first four Mediant 2000 T1 trunks to NFAS group #1, in which trunk #0  
is the primary trunk and trunk #1 is the backup trunk, use the following configuration:  
NFASGroupNumber_0 = 1  
NFASGroupNumber_1 = 1  
NFASGroupNumber_2 = 1  
NFASGroupNumber_3 = 1  
DchConfig_0 = 0  
DchConfig_1 = 1  
DchConfig_2 = 2  
DchConfig_3 = 2  
;Primary T1 trunk  
;Backup T1 trunk  
;24 B-channel NFAS trunk  
;24 B-channel NFAS trunk  
The NFAS parameters are described in Table 6-6 on page 122.  
Note:  
In the current version the NFAS parameters cannot be configured via the  
‘Trunk Settings’ screen in the Embedded Web Server. Use ini file  
configuration instead.  
8.4.1 NFAS Interface ID  
Several ISDN switches require an additional configuration parameter per T1 trunk, that is called  
‘Interface Identifier’. In NFAS T1 trunks the Interface Identifier is sent explicitly in Q.931 Setup /  
Channel Identification IE for all NFAS trunks, except for the B-channels of the Primary trunk (refer  
to note 1 below).  
The Interface ID can be defined per each member (T1 trunk) of the NFAS group, and must be  
coordinated with the configuration of the Switch.  
The default value of the Interface ID is identical to the number of the physical T1 trunk (0 for the  
first Mediant 2000 trunk, 1 for the second Mediant 2000 T1 trunk etc. up to 7).  
Version 4.4  
141  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
To define an explicit Interface ID for a T1 trunk (that is different from the default), use the  
following parameters:  
ISDNBehavior_x = 512 (x = 0 to 7 identifying the Mediant 2000 physical trunk)  
ISDNNFASInterfaceID_x = ID (x = 0 to 255)  
Note 1: Usually the Interface Identifier is included in the Q.931 Setup/Channel  
Identification IE only on T1 trunks that doesn’t contain the D-channel. Calls  
initiated on B-channels of the Primary T1 trunk, by default, don’t contain the  
Interface Identifier. Setting the parameter ‘ISDNBehavior_x’ to 2048’ forces  
the inclusion of the Channel Identifier parameter also for the Primary trunk.  
Note 2: The parameter ‘ISDNNFASInterfaceID_x = ID’ can define the ‘Interface ID’ for  
any Primary T1 trunk, even if the T1 trunk is not a part of an NFAS group.  
However, to include the Interface Identifier in Q.931 Setup/Channel  
Identification IE configure ‘ISDNBehavior_x = 2048’ in the ini file.  
8.4.2 Working with DMS-100 Switches  
The DMS-100 switch requires the following NFAS Interface ID definitions:  
InterfaceID #0 for the Primary trunk  
InterfaceID #1 for the Backup trunk (refer to the note below)  
InterfaceID #2 for a 24 B-channel T1 trunk  
InterfaceID #3 for a 24 B-channel T1 trunk  
Etc.  
Note: In the current version, the Mediant 2000 doesn’t support the DMS-100 Backup trunk.  
Therefore, InterfaceID #1, should not be used.  
For example, if four T1 trunks on a Mediant 2000 are configured as a single NFAS group that is  
used with a DMS-100 switch, the following parameters should be used:  
ISDNNFASInterfaceID_0 = 0  
ISDNNFASInterfaceID_1 = 2  
ISDNNFASInterfaceID_2 = 3  
ISDNNFASInterfaceID_3 = 4  
NFASGroupNumber_0 = 1  
NFASGroupNumber_1 = 1  
NFASGroupNumber_2 = 1  
NFASGroupNumber_3 = 1  
DchConfig_0 = 0 ;Primary T1 trunk  
DchConfig_2 = 2 ;24 B-channel NFAS trunk  
DchConfig_3 = 2 ;24 B-channel NFAS trunk  
DchConfig_4 = 2 ;24 B-channel NFAS trunk  
Mediant 2000 SIP User’s Manual  
142  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.5 Configuring the DTMF Transport Types  
You can control the way DTMF digits are transported over the IP network to the remote endpoint.  
The following five modes are supported:  
1. Using INFO message according to the Nortel IETF draft:  
In this mode DTMF digits are carried to the remote side within INFO messages.  
To enable this mode set:  
‘IsDTMFUsed = 1’  
& Dialing>Use Out-of-Band DTMF = Yes)  
(Protocol Management>Protocol Defenition>DTMF  
‘OutOfBandDTMFFormat = 1’  
& Dialing>Out-of-Band DTMF Format = INFO (Nortel))  
(Protocol Management>Protocol Defenition>DTMF  
‘RxDTMFOption = 0’  
(Protocol Management>Protocol Defenition>DTMF  
& Dialing>Declare RFC 2833 in SDP = No)  
Note that in this mode DTMF digits are erased from the audio stream (DTMFTransportType  
is automatically set to 0).  
2. Using INFO message according to Cisco’s style:  
In this mode DTMF digits are carried to the remote side within INFO messages.  
To enable this mode set:  
‘IsDTMFUsed = 1’  
(Use Out-of-Band DTMF = Yes)  
‘OutOfBandDTMFFormat = 2’  
‘RxDTMFOption = 0’  
(Out-of-Band DTMF Format = INFO (Cisco))  
(Declare RFC 2833 in SDP = No)  
Note that in this mode DTMF digits are erased from the audio stream (DTMFTransportType  
is automatically set to 0).  
3. Using NOTIFY messages according to <draft-mahy-sipping-signaled-digits-01.txt>:  
In this mode DTMF digits are carried to the remote side using NOTIFY messages.  
To enable this mode set:  
‘IsDTMFUsed = 1’  
(Use Out-of-Band DTMF = Yes)  
(Out-of-Band DTMF Format = NOTIFY)  
(Declare RFC 2833 in SDP = No)  
‘OutOfBandDTMFFormat = 3’  
‘RxDTMFOption = 0’  
Note that in this mode DTMF digits are erased from the audio stream (DTMFTransportType  
is automatically set to 0).  
4. Using RFC 2833 relay with Payload type negotiation:  
In this mode, DTMF digits are carried to the remote side as part of the RTP stream in  
accordance with RFC 2833 standard.  
To enable this mode set:  
‘IsDTMFUsed = 0’  
(Use Out-of-Band DTMF = No)  
‘TxDTMFOption = 4’  
(Protocol Management>Protocol Defenition>DTMF &  
Dialing> DTMF RFC 2833 Negotiation = Enable)  
‘RxDTMFOption = 3’  
(Declare RFC 2833 in SDP = Yes)  
‘DTMFTransportType = 3’ (Advanced Configuration>Channel Settings>Voice  
Settings>DTMF Transport Type = RFC 2833 Relay DTMF)  
Note that to set the RFC 2833 payload type with a different value (other than its default, 96)  
configure the ‘RFC2833PayloadType’ parameter. The gateway negotiates the RFC 2833  
payload type using local and remote SDP and sends packets using the PT from the received  
SDP. The gateway expects to receive RFC 2833 packets with the same PT as configured by  
the ‘RFC2833PayloadType’ parameter. The RFC 2833 packets are sent even if the remote  
side didn't include the send "telephone-event" parameter in its SDP, in which case the  
gateway uses the same PT for send and for receive.  
Version 4.4  
143  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
5. Sending DTMF digits (in RTP packets) as part of the audio stream (DTMF Relay is disabled):  
Note that this method is normally used with G.711 coders; with other Low Bit Rate (LBR)  
coders the quality of the DTMF digits is reduced.  
To set this mode:  
‘IsDTMFUsed = 0’  
‘TxDTMFOption = 0’  
‘RxDTMFOption = 0’  
(Use Out-of-Band DTMF = No)  
(DTMF RFC 2833 Negotiation = Disable)  
(Declare RFC 2833 in SDP = No)  
‘DTMFTransportType = 2’ (DTMF Transport Type = Transparent DTMF)  
Note 1: The gateway is always ready to receive DTMF packets over IP, in all possible  
transport modes: INFO messages, Notify and RFC 2833 (in proper payload  
type) or as part of the audio stream.  
Note 2: To exclude RFC 2833 Telephony event parameter from the gateway’s SDP,  
set ‘RxDTMFOption = 0’ in the ini file.  
The following parameters affect the way the Mediant 2000 SIP handles the DTMF digits:  
Table 8-3: Summary of DTMF Configuration Parameters (continues on pages 144 to 145)  
ini File Field Name  
Valid Range and Description  
[Web Name]  
IsDTMFUsed  
Use out-of-band signaling to relay DTMF digits.  
0 = Disable, DTMF digits are sent according to DTMFTransportType parameter. (default)  
1 = Enable sending DTMF digits within INFO or NOTIFY messages.  
[Use Out-of-Band DTMF]  
Note: When out-of-band DTMF transfer is used, DTMFTransportType is automatically  
set to 0 (erase the DTMF digits from the RTP stream).  
OutOfBandDTMFFormat  
[Out-of-Band DTMF Format]  
The exact method to send out-of-band DTMF digits  
1 = INFO format (Nortel)  
2 = INFO format (Cisco) - (default)  
3 = NOTIFY format <draft-mahy-sipping-signaled-digits-01.txt>  
Note 1: To use out-of-band DTMF, set “IsDTMFUsed=1”.  
Note 2: When using out-of-band DTMF, the “DTMFTransportType” parameter is  
automatically set to 0, to erase the DTMF digits from RTP path.  
TxDTMFOption  
[DTMF RFC 2833  
Negotiation]  
0 = No negotiation, DTMF digit is sent according to the parameters  
‘DTMFTransportType’ and ‘RFC2833PayloadType’.  
4 = Enable RFC 2833 payload type (PT) negotiation  
Note 1: This parameter is applicable only if “IsDTMFUsed=0” (out of-band DTMF is not  
used)  
Note 2: If enabled, the gateway:  
Negotiates RFC 2833 payload type using local and remote SDPs.  
Sends DTMF packets using RFC 2833 PT according to the PT in the received SDP.  
Expects to receive RFC 2833 packets with the same PT as configured by the  
“RFC2833PayloadType” parameter.  
Note 3: If the remote party doesn’t include the RFC 2833 DTMF relay payload type in  
the SDP, the gateway uses the same PT for send and for receive.  
Note 4: If TxDTMFOption is set to 0, the RFC 2833 payload type is set according to the  
parameter ‘RFC2833PayloadType’ for both transmit and receive.  
Mediant 2000 SIP User’s Manual  
144  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
Table 8-3: Summary of DTMF Configuration Parameters (continues on pages 144 to 145)  
ini File Field Name  
Valid Range and Description  
[Web Name]  
RxDTMFOption  
Defines the supported Receive DTMF negotiation method.  
0 = Don’t declare RFC 2833 Telephony-event parameter in SDP  
1 = n/a  
2 = n/a  
3 = Declare RFC 2833 “Telephony-event” parameter in SDP (default)  
The gateway is designed to always be receptive to RFC 2833 DTMF relay packets.  
Therefore, it is always correct to include the “Telephony-event” parameter as a default in  
the SDP. However some gateways use the absence of the “telephony-event” from the  
SDP to decide to send DTMF digits inband using G.711 coder, if this is the case you can  
set “RxDTMFOption=0”.  
RFC2833PayloadType  
The RFC 2833 DTMF relay dynamic payload type.  
Range: 96 to 99, 106 to 127; Default = 96  
The 100, 102 to 105 range is allocated for proprietary usage.  
Cisco is using payload type 101 for RFC 2833.  
Note: When RFC 2833 payload type (PT) negotiation is used (TxDTMFOption=4), this  
payload type is used for the received DTMF packets. If negotiation isn’t used, this  
payload type is used for receive and for transmit.  
MGCPDTMFDetectionPont 0 = Send out of-band DTMF message on starting point of DTMF digit  
1 = Send DTMF message on ending point of DTMF digit (default)  
DTMFDigitLength  
Time in msec for generating DTMF tones to the PSTN side (if received in INFO).  
The default value is 100 msec.  
DTMFInterDigitInterval  
Time in msec between generated DTMFs to PSTN side (if received in INFO).  
The default value is = 100 msec.  
DTMFVolume  
[DTMF Volume]  
DTMF level for regenerated digits to PSTN side (-31 to 0, corresponding to -31 dBm to 0  
dBm in 1 dB steps, default = -11 dBm)  
DTMFTransportType  
[DTMF Transport Type]  
0 = Erase digits from voice stream, do not relay to remote.  
2 = Digits remain in voice stream.  
3 = Erase digits from voice stream, relay to remote according to RFC 2833.  
Note: This parameter is automatically updated if one of the following parameters is  
configured: IsDTMFUsed, TxDTMFOption or RxDTMFOption.  
Version 4.4  
145  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
8.6 Configuring the Gateway’s Alternative Routing  
(based on Connectivity and QoS)  
The Alternative Routing feature enables reliable routing of Tel to IP calls when Proxy isn’t used.  
The Mediant 2000 gateway periodically checks the availability of connectivity and suitable Quality  
of Service (QoS) before routing. If the expected quality cannot be achieved, an alternative IP  
route for the prefix (phone number) is selected.  
Note that if the alternative routing destination is the gateway itself, the call can be configured to  
be routed back to one of the gateway’s trunk groups and thus back into the PSTN (PSTN  
Fallback).  
8.6.1 Alternative Routing Mechanism  
When a TelIP call is routed through the Mediant 2000 gateway, the call’s destination number is  
compared to the list of prefixes defined in the Tel to IP Routing table (described in Section 5.8.4.1  
on page 49). The Tel to IP Routing table is scanned for the destination number’s prefix starting at  
the top of the table. When an appropriate entry (destination number matches one of the prefixes)  
is found; the prefix’s corresponding destination IP address is checked. If the destination IP  
address is disallowed, an alternative route is searched for in the following table entries.  
Destination IP address is disallowed if no ping to the destination is available (ping is continuously  
initiated every 7 seconds), when an inappropriate level of QoS was detected, or when DNS host  
name is not resolved. The QoS level is calculated according to delay or packet loss of previously  
ended calls. If no call statistics are received for two minutes, the QoS information is reset.  
The Mediant 2000 gateway matches the rules starting at the top of the table. For this reason,  
enter the main IP route above any alternative route.  
8.6.2 Determining the Availability of Destination IP Addresses  
To determine the availability of each destination IP address (or host name) in the routing table,  
one (or all) of the following (configurable) methods are applied:  
Connectivity – The destination IP address is queried periodically (currently only by ping).  
QoS – The QoS of an IP connection is determined according to RTCP (Real-Time Control  
Protocol) statistics of previous calls. Network delay (in msec) and network packet loss (in  
percentage) are separately quantified and compared to a certain (configurable) threshold. If  
the calculated amounts (of delay or packet loss) exceed these thresholds the IP connection  
is disallowed.  
DNS resolution – When host name is used (instead of IP address) for the destination route, it  
is resolved to an IP address by a DNS server. Connectivity and QoS are then applied to the  
resolved IP address.  
8.6.3 PSTN Fallback as a Special Case of Alternative Routing  
The purpose of the PSTN Fallback feature is to enable the Mediant 2000 gateway to redirect  
PSTN originated calls back to the legacy PSTN network if a destination IP route is found  
unsuitable (disallowed) for voice traffic at a specific time.  
To enable PSTN fallback, assign the IP address of the gateway itself as an alternative route to  
the desired prefixes. Note that calls (now referred to as IP to Tel calls) can be re-routed to a  
specific trunk group using the Routing parameters.  
Mediant 2000 SIP User’s Manual  
146  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.6.4 Relevant Parameters  
The following parameters (described in Table 6-5) are used to configure the Alternative Routing  
mechanism:  
AltRoutingTel2IPEnable  
AltRoutingTel2IPMode  
IPConnQoSMaxAllowedPL  
IPConnQoSMaxAllowedDelay  
8.7 Working with Supplementary Services  
The Mediant 2000 SIP gateway supports the following supplementary services:  
Hold / Retrieve  
Transfer  
Call Forward (doesn't initiate call forward, only responds to call forward request)  
Call Waiting  
Mediant 2000 SIP users are only required to enable the Hold and Transfer features. The call  
forward (supporting 30x redirecting responses) and call waiting (receive of 182 response)  
features are enabled by default. Note that all call participants must support the specific used  
method.  
Note:  
When working with application servers (such as BroadSoft’s BroadWorks) in  
client server mode (the application server controls all supplementary services  
and keypad features by itself), the gateway’s supplementary services must be  
disabled.  
8.7.1 Call Hold and Retrieve Features  
The party that initiates the hold is called the holding party, the other party is called the held  
party. The Mediant 2000 can't initiate the hold, but it can respond to hold request, and as  
such it is a held party.  
After a successful hold, the held party should hear HELD_TONE, defined in gateway's Call  
Progress Tones file.  
Retrieve can be performed only by the holding party while the call is held and active.  
After a successful retrieve the voice should be connected again.  
The hold and retrieve functionalities are implemented by Reinvite messages. The IP address  
0.0.0.0 as the connection IP address or the string “a=inactive” in the received Reinvite SDP  
cause the gateway to enter Hold state and to play held tone (configured in the gateway) to  
the PBX/PSTN. If the string “a=recvonly” is received in the SDP message, the gateway stops  
sending RTP packets, but continues to listen to the incoming RTP packets. Usually, the  
remote party plays, in this scenario, Music on-hold (MOH) and the Mediant 2000 forwards  
the MOH to the held party.  
8.7.2 Call Transfer  
There are two types of call transfers:  
Consultation Transfer  
Blind Transfer  
The common way to perform a consultation transfer is as follows:  
Version 4.4  
147  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
In the transfer scenario there are three parties:  
Party A - transferring, Party B – transferred, Party C – transferred to.  
A Calls B.  
B answers.  
A presses the hookflash and puts B on-hold (party B hears a hold tone)  
A dials C.  
After A completed dialing C, A can perform the transfer by on-hooking the A phone.  
After the transfer is completed, B and C parties are engaged in a call.  
The transfer can be initiated at any of the following stages of the call between A to C:  
Just after completing dialing C phone number - Transfer from setup.  
While hearing ring back – Transfer from alert.  
While speaking to C – Transfer from active.  
Blind transfer is performed after we have a call between A and B, and A party decides to transfer  
the call to C immediately without speaking with C.  
The result of the transfer is a call between B and C (just like consultation transfer only skipping  
the consultation stage).  
The Mediant 2000 doesn't initiate call transfer, it only can respond to call transfer request.  
Mediant 2000 SIP User’s Manual  
148  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.8 TDM Tunneling  
The Mediant 2000 TDM Tunneling feature allows you to tunnel groups of digital trunk spans or  
timeslots (B-channels) over the IP network. TDM Tunneling utilizes the internal routing  
capabilities of the Mediant 2000 (working without Proxy control) to receive voice and data  
streams from TDM (1 to 16 E1/T1/J1) spans or individual timeslots, convert them into packets  
and transmit them automatically over the IP network (using point-to-point or point-to-multipoint  
gateway distributions). A Mediant 2000 opposite it (or several Mediant 2000 gateways, when  
point-to-multipoint distributions is used) converts the IP packets back into TDM traffic. Each  
timeslot can be targeted to any other timeslot within a trunk in the opposite Mediant 2000.  
8.8.1 Implementation  
When TDM Tunneling is enabled (‘EnableTDMOverIP’ is set to 1 on the originating Mediant  
2000), the originating Mediant 2000 automatically initiates SIP calls from all enabled B-channels  
belonging to the E1/T1/J1 spans that are configured with the ‘Transparent’ protocol. The called  
number of each call is the internal phone number of the B-channel that the call originates from.  
The IP to Trunk Group routing table is used to define the destination IP address of the terminating  
Mediant 2000. The terminating Mediant 2000 gateway automatically answers these calls if its  
E1/T1 protocol is set to ‘Transparent’ (ProtocolType = 5) and parameter ‘ChannelSelectMode = 0’  
(By Phone Number).  
Note: It is possible to configure both gateways to also operate in symmetric mode. To do so, set  
‘EnableTDMOverIP’ to 1 and configure the Tel to IP Routing tables in both Mediant 2000  
gateways. In this mode, each gateway (after it is reset) initiates calls to the second gateway. The  
first call for each B-channel is answered by the second gateway.  
The Mediant 2000 monitors the established connections continuously, if for some reason one or  
more calls are released, the gateway automatically reestablishes these “broken“ connections. In  
addition, when a failure in a physical trunk or in the IP network occurs, the Mediant 2000  
gateways reestablish the tunneling connections as soon as the network restores.  
Note: It is recommended to use the keep-alive mechanism for each connection by activating  
“session expires” timeout, and using Reinvite messages.  
By utilizing the ‘Profiles’ mechanism (refer to Section 5.8.5 on page 55) you can configure the  
TDM Tunneling feature to choose different settings, based on a timeslot or groups of timeslots.  
For example, you can use low-bit-rate vocoders to transport voice, and ‘Transparent’ coder to  
transport data (e.g., for D-channel). You can also use Profiles to assign ToS (for DiffServ) per  
source, a time-slot carrying data or signaling gets a higher priority value than a time-slot carrying  
voice.  
For tunneling of E1/T1 CAS trunks enable RFC 2833 CAS relay mode (CASTransportType = 1).  
Figure 8-1 and Figure 8-2 show an example of ini files for two Mediant 2000 gateways  
implementing TDM Tunneling for four E1 spans. Note that in this example both gateways are  
dedicated to TDM tunneling.  
Version 4.4  
149  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Figure 8-1: ini File Example for TDM Tunneling (Originating Side)  
EnableTDMOverIP = 1  
;E1_TRANSPARENT_31  
ProtocolType_0 = 5  
ProtocolType_1 = 5  
ProtocolType_2 = 5  
ProtocolType_3 = 5  
prefix = '*,10.8.24.12' ;(IP address of the Mediant 2000 in the opposite location)  
; Channel selection by Phone number  
ChannelSelectMode = 0  
;Profiles can be used do define different coders per B-channels, such as Transparent  
; coder for B-channels (time slot 16) that carries PRI signaling.  
TrunkGroup = 0/1-31,1000,1  
TrunkGroup = 1/1-31,2000,1  
TrunkGroup = 2/1-31,3000,1  
TrunkGroup = 3/1-31,4000,1  
TrunkGroup = 0/16-16,7000,2  
TrunkGroup = 1/16-16,7001,2  
TrunkGroup = 2/16-16,7002,2  
TrunkGroup = 3/16-16,7003,2  
CoderName = 'g7231'  
CoderName = 'Transparent'  
CoderName_1 = 'g7231'  
CoderName_2 = 'Transparent'  
TelProfile_1 = voice,$$,1,$$,$$,$$,$$,$$,$$,$$  
TelProfile_2 = data,$$,2,$$,$$,$$,$$,$$,$$,$$  
Figure 8-2: ini File Example for TDM Tunneling (Terminating Side)  
;E1_TRANSPARENT_31  
ProtocolType_0 = 5  
ProtocolType_1 = 5  
ProtocolType_2 = 5  
ProtocolType_3 = 5  
; Channel selection by Phone number  
ChannelSelectMode = 0  
TrunkGroup = 0/1-31,1000,1  
TrunkGroup = 1/1-31,2000,1  
TrunkGroup = 2/1-31,3000,1  
TrunkGroup = 3/1-31,4000,1  
TrunkGroup = 0/16-16,7000,2  
TrunkGroup = 1/16-16,7001,2  
TrunkGroup = 2/16-16,7002,2  
TrunkGroup = 3/16-16,7003,2  
CoderName = 'g7231'  
CoderName = 'Transparent'  
CoderName_1 = 'g7231'  
CoderName_2 = 'Transparent'  
TelProfile_1 = voice,$$,1,$$,$$,$$,$$,$$,$$,$$  
TelProfile_2 = data,$$,2,$$,$$,$$,$$,$$,$$,$$  
Mediant 2000 SIP User’s Manual  
150  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.9 Call Detail Report  
The Call Detail Report (CDR) contains vital statistic information on calls made by the gateway.  
CDRs are generated at the end and (optionally) at the beginning of each call (determined by the  
parameter ‘CDRReportLevel). The destination IP address for CDR logs is determined by the  
parameter ‘CDRSyslogServerIP’.  
The following CDR fields are supported:  
Table 8-4: Supported CDR Fields  
Field Name  
Description  
Cid  
CallId  
Board’s Logic Channel Number  
H.323/SIP Call Identifier  
Physical Trunk Number  
Selected B-Channel  
Trunk  
BChan  
ConId  
H.323/SIP Conference ID  
Trunk Group Number  
TG  
EPTyp  
Endpoint Type  
Orig  
Call Originator (IP, Tel)  
Source IP Address  
SourceIp  
DestIp  
Destination IP Address  
Source Phone Number Type  
Source Phone Number Plan  
Source Phone Number  
Destination Phone Number Type  
Destination Phone Number Plan  
Destination Phone Number  
Destination Number Before Manipulation  
Call Duration  
TON  
NPI  
SrcPhoneNum  
TON  
NPI  
DstPhoneNum  
DstNumBeforeMap  
Durat  
Coder  
Selected Coder  
Intrv  
Packet Interval  
RtpIp  
RTP IP Address  
Port  
Remote RTP Port  
TrmSd  
Initiator of Call Release (IP, Tel, Unknown)  
Termination Reason  
TrmReason  
Fax  
Fax Transaction during the Call  
Number of Incoming Packets  
Number of Outgoing Packets  
Number of Outgoing Lost Packets  
unique RTP ID  
InPackets  
OutPackets  
PackLoss  
UniqueId  
SetupTime  
ConnectTime  
ReleaseTime  
RTPdelay  
RTPjitter  
RTPssrc  
RemoteRTPssrc  
RedirectReason  
TON  
Call Setup Time  
Call Connect Time  
Call Release Time  
RTP Delay  
RTP Jitter  
Local RTP SSRC  
Remote RTP SSRC  
Redirect Reason  
Redirection Phone Number Type  
Redirection Phone Number Plan  
Redirection Phone Number  
NPI  
RedirectPhonNum  
Version 4.4  
151  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
8.10 Trunk to Trunk Routing Example  
This example describes two Mediant 2000 gateways, each interface with the PSTN through four  
E1 spans. Gateway "A" is configured to route all incoming TelIP calls to gateway "B". Gateway  
"B" generates calls to PSTN on the same E1 Trunk as the call was originally received (in gateway  
"A").  
Gateway "A" IP address is 192.168.3.50  
Gateway "B" IP address is 192.168.3.51  
Ini File Parameters of Gateways "A" and "B”:  
1. Define, for both gateways, four trunk groups; each with 30 B-channels:  
TrunkGroup_1 = 0/1-31,1000  
TrunkGroup_2 = 1/1-31,2000  
TrunkGroup_3 = 2/1-31,3000  
TrunkGroup_4 = 3/1-31,4000  
2. In gateway "A”, add the originating Trunk Group ID, as a prefix, to the destination number,  
for TelIP calls:  
AddTrunkGroupAsPrefix=1  
3. In gateway "A", route all incoming PSTN calls, starting with the prefixes 1, 2, 3 and 4, to  
gateway’s "B" IP address:  
Prefix = 1, 192.168.3.51  
Prefix = 2, 192.168.3.51  
Prefix = 3, 192.168.3.51  
Prefix = 4, 192.168.3.51  
Note: It is also possible to define "Prefix = *,192.168.3.51" instead of the four lines above.  
4. In gateway "B", route IPPSTN calls to Trunk Group ID according to the first digit of the  
called number:  
PSTNPrefix = 1,1  
PSTNPrefix = 2,2  
PSTNPrefix = 3,4  
PSTNPrefix = 4,4  
5. In gateway "B", remove the first digit from each IPPSTN number, before it is used in an  
outgoing call:  
NumberMapIP2Tel = *,1  
Mediant 2000 SIP User’s Manual  
152  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
8.11 SIP Call Flow Example  
The Call Flow, shown in Figure 8-3, describes SIP messages exchanged between Mediant 2000  
gateway and an MP-108 gateway during a simple call.  
MP-108 with phone number “8000”, calls Mediant 2000 with phone number “1000”:  
Figure 8-3: SIP Call Flow Example  
Mediant 2000  
10.8.201.10  
MP-108  
10.8.201.108  
INVITE  
Trying  
F1  
F2  
Ringing  
F3  
200 OK  
Ack  
F4  
F5  
BYE  
F6  
F7  
200 OK  
F1 10.8.201.108 ==> 10.8.201.10 INVITE  
INVITE sip:[email protected];user=phone SIP/2.0  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacsiJkDGd  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>  
Call-ID: [email protected]  
CSeq: 18153 INVITE  
Contact: <sip:[email protected];user=phone>  
User-Agent: Audiocodes-Sip-Gateway/MP-108 FXS/v.4.20.299.410  
Supported: 100rel,em  
Accept-Language: en  
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO  
Content-Type: application/sdp  
Content-Length: 208  
v=0  
o=AudiocodesGW 18132 74003 IN IP4 10.8.201.108  
s=Phone-Call  
c=IN IP4 10.8.201.108  
t=0 0  
m=audio 4000 RTP/AVP 8 96  
a=rtpmap:8 pcma/8000  
a=rtpmap:96 telephone-event/8000  
a=fmtp:96 0-15  
a=ptime:20  
Version 4.4  
153  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
F2 10.8.201.10 ==> 10.8.201.108 Trying  
SIP/2.0 100 Trying  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacsiJkDGd  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>  
Call-ID: [email protected]  
Server: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
CSeq: 18153 INVITE  
Content-Length: 0  
F3 10.8.201.10 ==> 10.8.201.108 180 Ringing  
SIP/2.0 180 Ringing  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacsiJkDGd  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>;tag=1c7345  
Call-ID: [email protected]  
Server: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
CSeq: 18153 INVITE  
Supported: 100rel,em  
Content-Length: 0  
Note:  
Phone "1000" answers the call, and sends "200 OK" message to MP gateway  
10.8.201.108.  
F4 10.8.201.10 ==> 10.8.201.108 200 OK  
SIP/2.0 200 OK  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacsiJkDGd  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>;tag=1c7345  
Call-ID: [email protected]  
CSeq: 18153 INVITE  
Contact: <sip:[email protected];user=phone>  
Server: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
Supported: 100rel,em  
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO  
Content-Type: application/sdp  
Content-Length: 206  
v=0  
o=AudiocodesGW 30221 87035 IN IP4 10.8.201.10  
s=Phone-Call  
c=IN IP4 10.8.201.10  
t=0 0  
m=audio 7210 RTP/AVP 8 96  
a=rtpmap:8 pcma/8000  
a=ptime:20  
a=rtpmap:96 telephone-event/8000  
a=fmtp:96 0-15  
F5 10.8.201.108 ==> 10.8.201.10 ACK  
ACK sip:[email protected];user=phone SIP/2.0  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacZYpJWxZ  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>;tag=1c7345  
Call-ID: [email protected]  
User-Agent: Audiocodes-Sip-Gateway/MP-108 FXS/v.4.20.299.410  
Mediant 2000 SIP User’s Manual  
154  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
CSeq: 18153 ACK  
Supported: 100rel,em  
Content-Length: 0  
Note:  
Phone "8000" goes on-hook; gateway 10.8.201.108 sends "BYE" to gateway  
10.8.201.10. Voice path is established.  
F6 10.8.201.108 ==> 10.8.201.10 BYE  
BYE sip:[email protected];user=phone SIP/2.0  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacRKCVBud  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>;tag=1c7345  
Call-ID: [email protected]  
User-Agent: Audiocodes-Sip-Gateway/MP-108 FXS/v.4.20.299.410  
CSeq: 18154 BYE  
Supported: 100rel,em  
Content-Length: 0F7 10.2.37.10 ==> 10.2.37.20  
200 OK  
F7 10.8.201.10 ==> 10.8.201.108 200 OK  
SIP/2.0 200 OK  
Via: SIP/2.0/UDP 10.8.201.108;branch=z9hG4bKacRKCVBud  
From: <sip:[email protected]>;tag=1c5354  
To: <sip:[email protected]>;tag=1c7345  
Call-ID: [email protected]  
Server: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
CSeq: 18154 BYE  
Supported: 100rel,em  
Content-Length: 0  
Version 4.4  
155  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
8.12 SIP Authentication Example  
Mediant 2000 gateway supports basic and digest authentication types, according to SIP RFC  
3261 standard. A proxy server might require authentication before forwarding an INVITE  
message. A Registrar/Proxy server may also require authentication for client registration. A proxy  
replies to an unauthenticated INVITE with a 407 Proxy Authorization Required response,  
containing a Proxy-Authenticate header with the form of the challenge. After sending an ACK for  
the 407, the User Agent can then resend the INVITE with a Proxy-Authorization header  
containing the credentials.  
User Agent, Redirect or Registrar servers typically use 401 Unauthorized responses to challenge  
authentication containing a WWW-Authenticate header, and expect the re-INVITE to contain an  
Authorization header.  
The following example describes the Digest Authentication procedure including computation of  
User Agent credentials.  
The REGISTER request is sent to Registrar/Proxy server for registration, as follows:  
REGISTER sip:10.2.2.222 SIP/2.0  
Via: SIP/2.0/UDP 10.1.1.200  
From: <sip: [email protected]>;tag=1c17940  
To: <sip: [email protected]>  
Call-ID: [email protected]  
User-Agent: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
CSeq: 1 REGISTER  
Contact: sip:[email protected]:  
Expires:3600  
On receiving this request the Registrar/Proxy returns 401 Unauthorized response.  
SIP/2.0 401 Unauthorized  
Via: SIP/2.0/UDP 10.2.1.200  
From: <sip:[email protected] >;tag=1c17940  
To: <sip:[email protected] >  
Call-ID: [email protected]  
Cseq: 1 REGISTER  
Date: Mon, 30 Jul 2001 15:33:54 GMT  
Server: Columbia-SIP-Server/1.17  
Content-Length: 0  
WWW-Authenticate: Digest realm="audiocodes.com",  
nonce="11432d6bce58ddf02e3b5e1c77c010d2",  
stale=FALSE,  
algorithm=MD5  
According to the sub-header present in the WWW-Authenticate header the correct REGISTER  
request is formed.  
Since the algorithm used is MD5, take:  
The username from the ini file: M2K-AudioCodes  
The realm return by the proxy: audiocodes.com  
The password from the ini file: AudioCodes.  
The equation to be evaluated: (according to RFC this part is called A1).  
“M2K-AudioCodes:audiocodes.com:AudioCodes”.  
The MD5 algorithm is run on this equation and stored for future usage.  
The result is: “a8f17d4b41ab8dab6c95d3c14e34a9e1”  
Next we need to evaluate the par called A2. We take:  
The method type “REGISTER”  
Mediant 2000 SIP User’s Manual  
156  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
Using SIP protocol “sip”  
8. Gateway Capabilities Description  
Proxy IP from ini file “10.2.2.222”  
The equation to be evaluated:  
“REGISTER:sip:10.2.2.222”.  
The MD5 algorithm is run on this equation and stored for future usage.  
The result is:”a9a031cfddcb10d91c8e7b4926086f7e”  
The final stage:  
The A1 result  
The nonce from the proxy response: “11432d6bce58ddf02e3b5e1c77c010d2”  
The A2 result  
The equation to be evaluated:  
“A1:11432d6bce58ddf02e3b5e1c77c010d2:A2”.  
The MD5 algorithm is run on this equation. The outcome of the calculation is the response  
needed by the gateway to be able top register with the Proxy.  
The response is: “b9c45d0234a5abf5ddf5c704029b38cf”  
At this time a new REGISTER request is issued with the response:  
REGISTER sip:10.2.2.222 SIP/2.0  
Via: SIP/2.0/UDP 10.1.1.200  
From: <sip: [email protected]>;tag=1c23940  
To: <sip: [email protected]>  
Call-ID: [email protected]  
Server: Audiocodes-Sip-Gateway/TrunkPack 1610/v.4.20.299.412  
CSeq: 1 REGISTER  
Contact: sip:[email protected]:  
Expires:3600  
Authorization: Digest, Username: MP108-AudioCodes,  
realm="audiocodes.com”,  
nonce="11432d6bce58ddf02e3b5e1c77c010d2",  
uri=”10.2.2.222”,  
response=“ b9c45d0234a5abf5ddf5c704029b38cf”  
On receiving this request, if accepted by the Proxy, the proxy returns a 200 OK response closing  
the REGISTER transaction.  
SIP/2.0 200 OK  
Via: SIP/2.0/UDP 10.1.1.200  
From: <sip: [email protected]>;tag=1c23940  
To: <sip: [email protected]>  
Call-ID: [email protected]  
Cseq: 1 REGISTER  
Date: Thu, 26 Jul 2001 09:34:42 GMT  
Server: Columbia-SIP-Server/1.17  
Content-Length: 0  
Contact: <sip:[email protected]>; expires="Thu, 26 Jul 2001 10:34:42 GMT"; action=proxy;  
q=1.00  
Contact: <[email protected]:>; expires="Tue, 19 Jan 2038 03:14:07 GMT"; action=proxy;  
q=0.00  
Expires: Thu, 26 Jul 2001 10:34:42 GMT  
Version 4.4  
157  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
8.13 Nortel IMS Specific Features and Configuration  
8.13.1 SIP2PRI Gateway  
To enable Nortel’s IMS SIP2PRI gateway specific features, add the  
following parameters to the ini file:  
ApplicationProfile = 4444  
IsProxyUsed = 1  
SendInviteToProxy = 1  
ProxyIP = <Proxy IP address>  
EnableHold = 1  
EnableTransfer = 1  
EnableForward = 1  
xferPrefix = $  
RemovePrefix = 1  
EnableRPIHeader = 1  
IsDTMFUsed = 1  
OutOfBandDTMFFormat = 1  
DTMFTransportType = 0  
AddTrunkGroupAsPrefix =1  
NumberMapTel2IP = *, 1  
AlwaysUseRouteTable = 1  
RouteModeIP2Tel = 0  
DefaultNumber = 9999000  
SourceNumberMapTel2IP = 9999,0,Anonymous,0  
AddIEinSetup = <IE data in (hex format), used in ISDN SETUP>  
SendIEonTG = <list of Trunk Group IDs, from where the IE is sent>  
Note:  
The parameter ‘ApplicationProfile = 4444’ enables Nortel’s ISDN PRI specific  
features.  
8.13.1.1 SIP to PRI Calls  
Routing IP-originated calls to PRI is performed according to a concatenation of domain name and  
trunk group name. Before applying any of the routing or manipulation rules on an incoming IP  
call, the SIP2PRI gateway creates a new number from the SIP INVITE message; combining the  
domain name (marked in red) followed by a forward slash ‘/’ and trunk group name (marked in  
blue), finally appended with the initial phone number (marked in pink). The routing rules are  
applied only after the new number is created.  
For example:  
INVITE sip:2145551234@nortelnetworks.com:5060;norteltrkgrp=TrkGrp3;user=phone  
SIP/2.0”  
From the above SIP INVITE message, the following called number is created:  
nortelnetworks.com/TrkGrp32145551234  
Note 1: ‘norteltrkgrp’ is a hard-coded string that always precedes the trunk group  
name.  
Note 1: Different domain and trunk group names are supported.  
Mediant 2000 SIP User’s Manual  
158  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
For the SIP2PRI gateway to be able to apply the routing rules on the combined string, the prefix  
(domain name and trunk group) must previously be defined in the IP to Trunk Group Routing  
table either using the Embedded Web Server (refer to screen below) or via the ini file:  
Figure 8-4: IP to Trunk Group Routing Table  
Via the ini file:  
PSTNPrefix = nortelnetworks.com/TrkGrp3,2  
Thus, in the above example, any number starting with the prefix ‘nortelnetworks.com/TrkGrp3’ is  
routed to trunk group number 2.  
Using the routing table, any combination of domain name and trunk group name can be routed to  
any trunk group.  
Note:  
To route calls to the trunk group before modifying the called number, add the  
parameter ‘RouteModeIP2Tel = 0’ to the ini file.  
After applying the routing rule (the trunk to which the call is to be routed is already determined), it  
is possible to modify the combined called number (before it is sent to the PRI ISDN) to its initial  
state by removing the created prefix:  
Using the ini file parameter ‘RemovePrefix = 1’; the called number is automatically modified  
(by removal of the prefix) to the original called number ‘2145551234’.  
Setting ‘RemovePrefix = 0’ and using the number manipulation rules (either via the  
Embedded Web Server or the ini file as described below):  
NumberMapIP2Tel = nortelnetworks.com/TrkGrp3,26  
8.13.1.2 PRI to SIP Calls  
Trunk group ID and domain name are added to the generated INVITE messages for ISDNIP  
calls.  
For example:  
INVITE sip:8795551212@nortelnetworks.com:5060;norteltrkgrp=5;user=phone  
SIP/2.0  
The PRI2SIP gateway sends SIP INVITE message with a trunk group number (marked in blue),  
preceded by ‘norteltrkgrp’ (hard-coded string) and domain name (marked in red).  
The trunk group number is automatically determined as the trunk group from which the call was  
received (for detailed information on trunk groups, refer to Section 5.8.4.2 on page 51).  
Version 4.4  
159  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Note:  
Usually each E1/T1 span is configured as a separate trunk group.  
Different Domain names, according to the originated trunk group (or E1/T1 spans), can be  
determined via the Tel to IP Routing table.  
To enable different domain names add the following parameters to the ini file:  
AlwaysUseRouteTable = 1  
IsProxyUsed = 1  
AddTrunkGroupAsPrefix = 1  
NumberMapTel2IP = *, 1  
The parameter ‘AddTrunkGroupAsPrefix’ is set to differentiate incoming calls, based on the trunk  
from where the call arrived (it is assumed that each trunk group is composed of a single trunk)  
and use the Tel to IP Routing table or the Prefix parameter in the ini file to link each trunk to a  
different domain name. Finally, ‘NumberMapTel2IP’ is set to remove the leftmost digit from any  
called number (the previously added trunk group ID).  
For example:  
TrunkGroup_1 = 0/1-24  
TrunkGroup_2 = 1/1-24  
TrunkGroup_3 = 2/1-24  
Prefix = 1, example1.domain  
Prefix = 2, example2.domain  
Prefix = 3, example3.domain  
In the example above, all calls that are originated in trunk 1 (associated with trunk group number  
1) are sent to example1.domain. An incoming ISDN call, from trunk number 1, with called number  
1234000, generates the following SIP message:  
INVITE sip:[email protected];norteltrkgrp=1;  
8.13.1.3 Support for RPI Header  
Support for Remote Party ID (RPI) header containing proprietary RPI-TON, RPI-NPI, privacy and  
screening parameters (EnableRPIHeader = 1).  
Configuration of NPI/TON  
Configuration of the calling number’s NPI/TON values for outgoing IPISDN calls. If the calling  
number’s NPI/TON values aren’t provided in the Remote-Party-ID (RPID) header (received with  
the INVITE message) and are also not configured in the source number IP to Tel Manipulation  
table, then the calling number NPI/TON is set equal to the called number’s NPI/TON.  
NPI/TON values for the called number are defined in the RPID header or set by Number  
manipulation rules. If both are defined, the latter takes precedence over the former.  
To configure a specific called number NPI/TON according to domain  
name and trunk group, take these 2 steps:  
1. Define RemovePrefix = 0, forcing the called number to include, as prefix, the Domain name  
and Trunk Group (this prefix can be used to define specific NPI/TON values), for example:  
nortelnetworks.com/TrunkGroup32145551234  
Mediant 2000 SIP User’s Manual  
160  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
2. Use the number manipulation table (exemplified below) to assign NPI/TON values according  
to the number’s prefix:  
NumberMapIP2TEL= nortelnetworks.com/TrunkGroup3,30,$$,$$,1,2  
In the above example, all numbers starting with the ‘nortelnetworks.com/TrunkGroup3’  
string, are modified; the first 30 characters in this prefix string (domain and trunk group  
names) are erased, and the NPI/TON are set to 1/2 respectively.  
Note:  
The $$ signs represent the empty parameters ‘Prefix to add’ and ‘Number of  
digits to leave’.  
8.13.1.4 Transfer  
To differentiate transferred calls (using the REFER method) from incoming ISDN calls, add the  
following parameter to the ini file: xferPrefix = $; the parameter adds the ‘$’ sign (or any other  
string) as a prefix to the transferred called number. The added string can be later removed using  
the number manipulation rule.  
Note:  
When using the PRI2SIP gateway, the NumberMapTel2IP = *, 1 manipulation  
rule is used. This manipulation rule also applies to transferred calls,  
corrupting the number by removing its first digit. Therefore, use the xferPrefix  
= $ parameter to prepend a single character to the transferred number so that  
the manipulation table only removes the added character without altering the  
original number.  
8.13.1.5 Other Nortel Specific Parameters  
If the parameter ‘EarlyAnswerTimeout’ > 0 and Q.931 CONNECT was not received from ISDN for  
‘EarlyAnswerTimeout’, the Mediant 2000 responds with 200 OK.  
Asserted-Identity header is ignored, if received by Mediant 2000 gateway in INVITE message and  
if ‘ApplicationProfile = 4444’.  
Mediant 2000 gateway doesn’t include the Called Number Remoty-Party-ID header in INVITE (for  
ISDNIP calls) if ‘ApplicationProfile = 4444’.  
Version 4.4  
161  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
8.13.2 SIP2CAS (Call Pilot) Gateway  
To enable SIP2CAS gateway specific features, take these 2 steps:  
1. Add the following parameters to the ini file:  
ApplicationProfile=1  
IsProxyUsed = 1  
SendInviteToProxy = 1  
ProxyIP = <Proxy IP address>  
EnableHold = 1  
EnableTransfer = 1  
EnableForward = 1  
EnableNortelHeader = 1  
ProtocolType = 2  
IsDTMFUsed = 1  
OutOfBandDTMFFormat = 1  
DTMFTransportType = 0  
TimeForReorderTone = 10  
PlayRBToneonXfer = 1  
2. Load the specific Ground Start CAS .dat file (supplied with the software package).  
8.13.2.1 Supported Features  
Proprietary header in SIP 180 Ringing response, containing information about the trunk’s  
physical port and timeslot which were seized to place the call. For example:  
SIP/2.0 180 Ringing  
Via: SIP/2.0/UDP 10.8.1.15  
From: sip:[email protected];tag=1c14356  
To: sip:[email protected];tag=1c29285  
Call-ID: [email protected]  
CSeq: 1 INVITE Supported: 100rel,em  
Channel: interface=0;timeslot=1  
Content-Length: 0  
When hook-flash is detected, the CAS gateway plays a dial tone and collects DTMF digits.  
The call is then transferred using a SIP REFER message:  
REFER sip:[email protected];user=phone SIP/2.0  
Via: SIP/2.0/UDP 10.8.8.52;branch=z9hG4bKacdLIaZOe  
From: sip:[email protected];tag=1c16026  
To: <sip:[email protected]>;tag=1c10947  
Call-ID: [email protected]  
CSeq: 36026 REFER  
Contact: 1001 <sip:[email protected]>  
Supported: 100rel,em  
Max-Forwards: 70  
Refer-To: sip:[email protected]  
Referred-By: sip:[email protected]  
Content-Length: 0  
Mediant 2000 SIP User’s Manual  
162  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
8. Gateway Capabilities Description  
If the call transfer fails, the gateway either plays a busy tone (if the destination client to whom  
the call is transferred is busy) or it plays a reorder tone (for all other reasons). The tone is  
played for 10 seconds (TimeForReorderTone=10) towards the CallPilot.  
Usually, the CallPilot detects these Call Progress Tones and either disconnects the call or  
unholds it using double hook-flash signaling. If the CallPilot doesn’t react to these tones, the  
gateway releases the call, and idle the CAS A/B bit state.  
If the call transfer fails (if user B is busy, for instance), detection of a double hook-flash from  
the CAS side unholds the call and retrieves the original call (using reINVITE).  
If the call transfer succeeds, the gateway plays a Ringback tone for ‘TimeForReorder’ (about  
10 seconds) and tears down the call. To play the Ringback tone set ‘PlayRBToneonXfer=1’.  
Disabling the B-channel – If DTMF digits aren’t received from the CallPilot after applying a  
dial tone to the CAS side (usually for 30 seconds, i.e., the duration of a dial tone), the  
gateway’s B-channel converts to ‘Block’ state. During ‘Block’ state, the channel is put out of  
service and is not used for IPTel calls. To enable the B-channel, apply CAS A/B idle state  
(0,1) from the CallPilot side.  
8.13.3 DTMF Configuration  
To use out of band SIP INFO messages to relay DTMF digits, add the following parameters to the  
ini file.  
IsDTMFUsed = 1  
OutOfBandDTMFFormat = 1  
RxDTMFOption = 0  
To use RFC 2833 DTMF relay, add the following parameters to the ini file.  
IsDTMFUsed = 0  
TxDTMFOption = 4  
RxDTMFOption = 3  
DTMFTransportType = 3  
For detailed information on DTMF transport modes, refer to Secion 8.5 on page 143.  
Version 4.4  
163  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
164  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
9. Diagnostics  
9 Diagnostics  
Several diagnostic tools are provided, enabling you to identify correct functioning of the Mediant  
2000, or an error condition with a probable cause and a solution or workaround.  
Front panel indicator LEDs on the Mediant 2000. The location and functionality of the front  
panel LEDs is shown in Section 2.3.2 on page 23.  
Mediant 2000 Self-Testing on hardware initialization (refer to Section 9.1 below).  
Syslog Event Notification Messages (refer to Section 9.2 below).  
9.1 Mediant 2000 Self-Testing  
The Mediant 2000 features two self-testing modes: rapid and detailed.  
Rapid self-test mode is invoked each time the media gateway completes the initialization  
process. This is a short test phase in which the only error detected and reported is failure in  
initializing hardware components. All Status and Error reports in this self-test phase are reported  
through Network Interface ports, as well as indicated by the LED Status Indicators.  
Detailed self-test mode is invoked when initialization of the media gateway is completed and if  
the configuration parameter EnableDiagnostics is set to 1 (this parameter can be configured  
through the ini file mechanism). In this mode, the media gateway tests all the hardware  
components (memory, DSP, etc.), outputs the status of the test results, and ends the test. To  
continue operational running, reset the media gateway again but this time configure the  
EnableDiagnostics parameter to 0.  
9.2 Syslog Support  
Syslog protocol is an event notification protocol that enables a machine to send event notification  
messages across IP networks to event message collectors -also known as Syslog servers.  
Syslog protocol is defined in the IETF RFC 3164 standard.  
Since each process, application and operating system was written independently, there is little  
uniformity to Syslog messages. For this reason, no assumption is made on the contents of the  
messages other than the minimum requirements of its priority.  
Syslog uses UDP as its underlying transport layer mechanism. The UDP port that was assigned  
to Syslog is 514  
The Syslog message is transmitted as an ASCII (American Standard Code for Information  
Interchange) message. The message starts with a leading "<" ('less-than' character), followed by  
a number, which is followed by a ">" ('greater-than' character). This is optionally followed by a  
single ASCII space.  
The number described above is known as the Priority and represents both the Facility and  
Severity as described below. The Priority number consists of one, two, or three decimal integers.  
For example:  
<37> Oct 11 16:00:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8  
Note that when NTP is enabled, a timestamp string [hour:minutes:seconds] is added to all Syslog  
messages (for information on NTP, refer to Section 5.9.1.3 on page 63).  
Version 4.4  
165  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
9.2.1 Syslog Servers  
Users can use the provided Syslog server (ACSyslog08.exe) or other third-party Syslog servers.  
Examples of Syslog servers available as shareware on the Internet:  
Netal SL4NT 2.1 Syslog Daemon: http://www.netal.com  
A typical Syslog server application enables filtering of the messages according to priority, IP  
sender address, time, date, etc.  
9.2.2 Operation  
9.2.2.1 Sending the Syslog Messages  
The Syslog client, embedded in the firmware of the Mediant 2000, sends error reports/events  
generated by the Mediant 2000 unit application to a Syslog server, using IP/UDP protocol.  
9.2.2.2 Setting the Syslog Server  
To set the Syslog server:  
Use the Mediant 2000 Embedded Web Server (Advanced Configuration>Network  
Settings>screen section Syslog Settings) to enable the Syslog Server (Enable Syslog) and  
to enter its IP address (Syslog Server IP address); refer to Figure 9-1 below.  
Figure 9-1: Setting the Syslog Server IP Address  
Alternately, use the Embedded Web Server or the BootP/TFTP utility to load the ini  
configuration file containing both the IP address and the enabling parameters:  
SyslogServerIP and EnableSyslog respectively. For detailed information on the BootP/TFTP  
utility, refer to Appendix B on page 189. For an ini file example showing these parameters,  
9.2.2.3 The ini File Example for Syslog  
Figure 9-2 shows an ini file section with an example configuration for the address parameter  
SyslogServerIP and an example configuration for the client activation parameter EnableSyslog.  
Figure 9-2: The ini File Example for Syslog  
[Syslog]  
SyslogServerIP = 10.2.0.136  
EnableSyslog = 1  
GWDebugLevel = 5  
Mediant 2000 SIP User’s Manual  
166  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
             
Mediant 2000 SIP User’s Manual  
10. BootP/DHCP Support  
10 BootP/DHCP Support  
10.1 Startup Process  
The startup process (illustrated in Figure 10-1 on page 168) begins when the gateway is reset  
(physically or from the Web / SNMP) and ends when the operational software is running. In the  
startup process, the network parameters, software and configuration files are obtained.  
After the gateway powers up or after it is physically reset, it broadcasts a BootRequest message  
to the network. If it receives a reply (from a BootP server), it changes its network parameters (IP  
address, subnet mask and default gateway address) to the values provided. If there is no reply  
from a BootP server and if DHCP is enabled (DHCPEnable = 1), the gateway initiates a standard  
DHCP procedure to configure its network parameters.  
After changing the network parameters, the gateway attempts to load the cmp and various  
configuration files from the TFTP server’s IP address, received from the BootP/DHCP servers. If  
a TFTP server’s IP address isn’t received, the gateway attempts to load the software (cmp) file  
and / or configuration files from a preconfigured TFTP server (refer to the parameters ‘IniFileURL’  
and ‘CmpFileURL’ described in Table 6-1 on page 90). Thus, the gateway can obtain its network  
parameters from BootP or DHCP servers and its software and configuration files from a different  
TFTP server (preconfigured in ini file).  
If BootP/DHCP servers are not found or when the gateway is reset from the Web / SNMP, it  
retains its network parameters and attempts to load the software (cmp) file and / or configuration  
files from a preconfigured TFTP server.  
If a preconfigured TFTP server doesn’t exist, the gateway operates using the existing software  
and configuration files loaded on its non-volatile memory.  
Note that after the operational software runs, if DHCP is configured, the gateway attempts to  
renew its lease with the DHCP server.  
Note 1: Though DHCP and BootP servers are very similar in operation, the DHCP  
server includes some differences that could prevent its operation with BootP  
clients. However, many DHCP servers, such as WindowsNT DHCP server,  
are backward-compatible with BootP protocol and can be used for gateway  
configuration.  
Note 2: The time duration between BootP/DHCP requests is set to 1 second by  
default. This can be changed by the BootPDelay ini file parameter. Also, the  
number of requests is 3 by default and can be changed by BootPRetries ini  
file parameter. (Both parameters can also be set using the BootP command  
line switches).  
Version 4.4  
167  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Figure 10-1: Mediant 2000 Startup Process  
Reset from the Web  
Interface or SNMP  
Physical Reset  
DHCP  
x times  
BootP  
x times  
No  
Response  
No  
Response  
BootP Response  
DHCP Response  
Update network  
parameters from  
BootP/DHCP reply  
BootP/DHCP  
reply contains firmware  
file name?  
No  
Yes  
Download  
firmware via  
TFTP  
BootP/DHCP  
reply contains ini file  
name?  
BootP/DHCP  
reply contains ini file  
name?  
No  
Preconfigured firmware  
URL?  
Yes  
Yes  
Download  
firmware via  
TFTP  
Yes  
No  
Device  
reset  
No  
Preconfigured ini file  
URL?  
Yes  
Download  
configuration  
files via TFTP  
No  
Run operational software  
Mediant 2000 SIP User’s Manual  
168  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
10. BootP/DHCP Support  
10.2 DHCP Support  
When the gateway is configured to use DHCP (DHCPEnable = 1), it attempts to contact the  
enterprise’s DHCP server to obtain the networking parameters (IP address, subnet mask, default  
gateway, primary/secondary DNS server and SIP server address). These network parameters  
have a "time limit". After the time limit expires, the gateway must "renew" its lease from the DHCP  
server.  
Note that if the DHCP server denies the use of the gateway's current IP address and specifies a  
different IP address (according to RFC 1541), the gateway must change its networking  
parameters. If this happens while calls are in progress, they are not automatically rerouted to the  
new network address (since this function is beyond the scope of a VoIP gateway). Therefore,  
administrators are advised to configure DHCP servers to allow renewal of IP addresses.  
Note: If the gateway's network cable is disconnected and reconnected, a DHCP renewal is  
performed (to verify that the gateway is still connected to the same network).  
When DHCP is enabled, the gateway also includes its product name (e.g., ‘Mediant 2000’) in the  
DHCP ‘option 60’ Vendor Class Identifier. The DHCP server can use this product name to assign  
an IP address accordingly.  
Note: After power-up, the gateway issues two DHCP requests. Only in the second request, the  
DHCP ‘option 60’ is contained. If the gateway is reset from the Web/SNMP, only a single DHCP  
request containing ‘option 60’ is sent.  
If DHCP procedure is used, the new gateway IP address, allocated by the DHCP server, must be  
detected.  
Note:  
If, during operation, the IP address of the gateway is changed as a result of a  
DHCP renewal, the gateway is automatically reset.  
To detect the gateway’s IP address, follow one of the procedures  
below:  
Starting with Bootload software version 1.92, the gateway can use host name in the DHCP  
request. The host name is set to acl_nnnnn, where nnnnn stands for the gateway’s serial  
number (the serial number is equal to the last 6 digits of the MAC address converted from  
Hex to decimal). If the DHCP Server registers this host name to a DNS server, the user can  
access the gateway (through a Web browser) using a URL of http://acl_<serial number>  
(instead of using the gateway’s IP address). For example, if the gateway’s MAC address is  
00908f010280, the DNS name is acl_66176.  
After physically resetting the gateway its IP address is displayed in the ‘Client Info’ column in  
the BootP/TFTP configuration utility (refer to Figure B-1 on page 191).  
Contact your System Administrator.  
10.3 BootP Support  
10.3.1 Upgrading the Mediant 2000  
When upgrading the Mediant 2000 (loading new software onto the gateway) using the  
BootP/TFTP configuration utility:  
From version 4.2 to version 4.4, the device loses its configuration. Therefore, to retain the  
previous gateway configuration you must save the ini file before you replace the cmp file,  
and reload it to the device. For information on backing up and restoring the gateway’s  
configuration, refer to Section 5.9.5 on page 69.  
Version 4.4  
169  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
From version 4.4 to version 4.4 or to any higher version, the device retains its configuration  
(ini file), however, the auxiliary files (CPT, logo, etc.) may be erased.  
When using the Software Upgrade wizard, available through the Web Interface (refer to Section  
5.11.1 on page 78), the auxiliary files are saved as well.  
Note: To save the cmp file to non-volatile memory, use the -fb command line switches. If the file  
is not saved, the gateway reverts to the old version of software after the next reset. For  
information on using command line switches, refer to Section B.11.6 on page 198.  
10.3.2 Vendor Specific Information Field  
The Mediant 2000 uses the vendor specific information field in the BootP request to provide  
device-related initial startup information. The BootP/TFTP configuration utility displays this  
information in the ‘Client Info’ column (refer to Figure B-1).  
Note: This option is not available on DHCP servers.  
The Vendor Specific Information field is disabled by default. To enable / disable this feature: set  
the ini file parameter ‘ExtBootPReqEnable’ (Table 6-1 on page 90) or use the ‘-be’ command line  
switch (refer to Table B-1 on page 198).  
Table 10-1 details the vendor specific information field according to device types:  
Table 10-1: Vendor Specific Information Field  
Tag #  
Description  
Value  
Length  
#02 = IPM-1610/TP-1610  
#03 = IPMTP260  
220  
Board Type  
1
#05 = IPMTP260  
221  
222  
223  
Current IP Address  
XXX.XXX.XXX.XXX  
X.XX  
4
4
Burned Boot Software Version  
Burned cmp Software Version  
XXXXXXXXXXXX  
12  
0 – 31  
(TP-260 Only)  
224  
Geographical Address  
1
0 – 31  
(TP-260 Only)  
225  
229  
Chassis Geographical Address  
E&M  
1
1
N/A  
Table 10-2 exemplifies the structure of the vendor specific information field for a TP-1610 slave  
module with IP Address 10.2.70.1.  
Table 10-2: Structure of the Vendor Specific Information Field  
Vendor-  
Specific  
Information  
Code  
42  
12  
220  
1
2
225  
1
1
221  
4
10  
2
70  
1
255  
Mediant 2000 SIP User’s Manual  
170  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
11 SNMP-Based Management  
Simple Network Management Protocol (SNMP) is a standard-based network control protocol  
used to manage elements in a network. The SNMP Manager (usually implemented by a Network  
Manager (NM) or an Element Manager (EM)) connects to an SNMP Agent (embedded on a  
remote Network Element (NE)) to perform network element Operation, Administration and  
Maintenance (OAM).  
Both the SNMP Manager and the NE refer to the same database to retrieve information or  
configure parameters. This database is referred to as the Management Information Base (MIB),  
and is a set of statistical and control values. Apart from the standard MIBs documented in IETF  
RFCs, SNMP additionally enables the use of private MIBs, containing a non-standard information  
set (specific functionality provided by the NE).  
Directives, issued by the SNMP Manager to an SNMP Agent, consist of the identifiers of SNMP  
variables (referred to as MIB object identifiers or MIB variables) along with instructions to either  
get the value for that identifier, or set the identifier to a new value (configuration). The SNMP  
Agent can also send unsolicited events towards the EM, called SNMP traps.  
The definitions of MIB variables supported by a particular agent are incorporated in descriptor  
files, written in Abstract Syntax Notation (ASN.1) format, made available to EM client programs so  
that they can become aware of MIB variables and their use.  
The device contains an embedded SNMP Agent supporting both general network MIBs (such as  
the IP MIB), VoP-specific MIBs (such as RTP) and our proprietary MIBs (acBoard, acGateway,  
acAlarm and other MIBs), enabling a deeper probe into the inter-working of the device. All  
supported MIB files are supplied to customers as part of the release.  
11.1 About SNMP  
11.1.1 SNMP Message Standard  
Four types of SNMP messages are defined:  
Get - A request that returns the value of a named object.  
Get-Next - A request that returns the next name (and value) of the ‘next’ object supported by  
a network device given a valid SNMP name.  
Set - A request that sets a named object to a specific value.  
Trap - A message generated asynchronously by network devices. It is an unsolicited  
message from an agent to the manager.  
Each of these message types fulfills a particular requirement of Network Managers:  
Get Request - Specific values can be fetched via the ‘get’ request to determine the  
performance and state of the device. Typically, many different values and parameters can be  
determined via SNMP without the overhead associated with logging into the device, or  
establishing a Transmission Control Protocol (TCP) connection with the device.  
Get Next Request - Enables the SNMP standard network managers to ‘walk’ through all  
SNMP values of a device (via the ‘get-next’ request) to determine all names and values that  
an operant device supports. This is accomplished by beginning with the first SNMP object to  
be fetched, fetching the next name with a ‘get-next’, and repeating this operation.  
Set Request - The SNMP standard provides a method of effecting an action associated with  
a device (via the ‘set’ request) to accomplish activities such as disabling interfaces,  
disconnecting users, clearing registers, etc. This provides a way of configuring and  
controlling network devices via SNMP.  
Version 4.4  
171  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Trap Message - The SNMP standard furnishes a mechanism by which devices can ‘reach  
out’ to a Network Manager on their own (via a ‘trap’ message) to notify or alert the manager  
of a problem with the device. This typically requires each device on the network to be  
configured to issue SNMP traps to one or more network devices that are awaiting these  
traps.  
The above message types are all encoded into messages referred to as Protocol Data Units  
(PDUs) that are interchanged between SNMP devices.  
11.1.2 SNMP MIB Objects  
The SNMP MIB is arranged in a tree-structured fashion, similar in many ways to a disk directory  
structure of files. The top level SNMP branch begins with the ISO ‘internet’ directory, which  
contains four main branches:  
The ‘mgmt’ SNMP branch - Contains the standard SNMP objects usually supported (at least  
in part) by all network devices.  
The ‘private’ SNMP branch - Contains those ‘extended’ SNMP objects defined by network  
equipment vendors.  
The ‘experimental’ and ‘directory’ SNMP branches - Also defined within the ‘internet’ root  
directory, these branches are usually devoid of any meaningful data or objects.  
The ‘tree’ structure described above is an integral part of the SNMP standard, though the most  
pertinent parts of the tree are the ‘leaf’ objects of the tree that provide actual management data  
regarding the device. Generally, SNMP leaf objects can be partitioned into two similar but slightly  
different types that reflect the organization of the tree structure:  
Discrete MIB Objects - Contain one precise piece of management data. These objects are  
often distinguished from ‘Table’ items (below) by adding a ‘.0’ (dot-zero) extension to their  
names. The operator must merely know the name of the object and no other information.  
Table MIB Objects - Contain multiple sections of management data. These objects are  
distinguished from ‘Discrete’ items (above) by requiring a ‘.’ (dot) extension to their names  
that uniquely distinguishes the particular value being referenced. The ‘.’ (dot) extension is the  
‘instance’ number of an SNMP object. For ‘Discrete’ objects, this instance number is zero.  
For ‘Table’ objects, this instance number is the index into the SNMP table. SNMP tables are  
special types of SNMP objects which allow parallel arrays of information to be supported.  
Tables are distinguished from scalar objects, so that tables can grow without bounds. For  
example, SNMP defines the ‘ifDescr’ object (as a standard SNMP object) that indicates the  
text description of each interface supported by a particular device. Since network devices  
can be configured with more than one interface, this object can only be represented as an  
array.  
By convention, SNMP objects are always grouped in an ‘Entry’ directory, within an object with a  
‘Table’ suffix. (The ‘ifDescr’ object described above resides in the ‘ifEntry’ directory contained in  
the ‘ifTable’ directory).  
11.1.3 SNMP Extensibility Feature  
One of the principal components of an SNMP manager is a MIB Compiler which allows new MIB  
objects to be added to the management system. When a MIB is compiled into an SNMP  
manager, the manager is made ‘aware’ of new objects that are supported by agents on the  
network. The concept is similar to adding a new schema to a database.  
Typically, when a MIB is compiled into the system, the manager creates new folders or directories  
that correspond to the objects. These folders or directories can typically be viewed with a MIB  
Browser, which is a traditional SNMP management tool incorporated into virtually all Network  
Management Systems.  
The act of compiling the MIB allows the manager to know about the special objects supported by  
the agent and access these objects as part of the standard object set.  
Mediant 2000 SIP User’s Manual  
172  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
11.2 Carrier Grade Alarm System  
The basic alarm system has been extended to a carrier-grade alarm system. A carrier-grade  
alarm system provides a reliable alarm reporting mechanism that takes into account EMS  
outages, network outages, and transport mechanism such as SNMP over UDP.  
A carrier-grade alarm system is characterized by the following:  
The device has a mechanism that allows a manager to determine which alarms are currently  
active in the device. That is, the device maintains an active alarm table.  
The device has a mechanism to allow a manager to detect lost alarm raise and clear  
notifications [sequence number in trap, current sequence number MIB object].  
The device has a mechanism to allow a manager to recover lost alarm raise and clear  
notifications [maintains a log history].  
The device sends a cold start trap to indicate that it is starting. This allows the EMS to  
synchronize its view of the device's active alarms.  
The SNMP alarm traps are sent as in previous releases. This system provides the mechanism for  
viewing of history and current active alarm information.  
11.2.1 Active Alarm Table  
The device maintains an active alarm table to allow a manager to determine which alarms are  
currently active in the device. Two views of the active alarm table are supported by the agent:  
acActiveAlarmTable in the enterprise acAlarm  
alarmActiveTable and alarmActiveVariableTable in the IETF standard ALARM-MIB (rooted in  
the AC tree)  
The acActiveAlarmTable is a simple, one-row per alarm table that is easy to view with a MIB  
browser.  
The ALARM-MIB is currently a draft standard and therefore has no OID assigned to it. In the  
current software release, the MIB is rooted in the experimental MIB subtree. In a future release,  
after the MIB has been ratified and an OID assigned, it is to move to the official OID.  
11.2.2 Alarm History  
The device maintains a history of alarms that have been raised and traps that have been cleared  
to allow a manager to recover any lost, raised or cleared traps. Two views of the alarm history  
table are supported by the agent:  
acAlarmHistoryTable in the enterprise acAlarm  
nlmLogTable and nlmLogVariableTable in the standard NOTIFICATION-LOG-MIB  
As with the acActiveAlarmTable, the acAlarmHistoryTable is a simple, one-row-per-alarm table  
that is easy to view with a MIB browser.  
11.3 Cold Start Trap  
Mediant 2000 technology supports a cold start trap to indicate that the device is starting. This  
allows the manager to synchronize its view of the device's active alarms. Two different traps are  
sent at start-up:  
The standard coldStart trap - iso(1).org(3).dod(6).internet(1). snmpV2(6). snmpModules(3).  
snmpMIB(1). snmpMIBObjects(1). snmpTraps(5). coldStart(1) - sent at system initialization.  
The enterprise acBoardEvBoardStarted which is generated at the end of system  
initialization. This is more of an ‘application-level’ cold start sent after the entire initializing  
process is complete and all the modules are ready.  
Version 4.4  
173  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
11.4 Third-Party Performance Monitoring  
Measurements  
Performance measurements are available for a third-party performance monitoring system  
through an SNMP interface. These measurements can be polled at scheduled intervals by an  
external poller or utility in a media server or other off-device system.  
The device provides two types of performance measurements:  
1. Gauges: Gauges represent the current state of activities on the device. Gauges, unlike  
counters, can decrease in value, and like counters, can increase. The value of a gauge is the  
current value or a snapshot of the current activity on the device.  
2. Counters: Counters always increase in value and are cumulative. Counters, unlike gauges,  
never decrease in value unless the off-device system is reset. the counters are then zeroed.  
Performance measurements are provided by three proprietary MIBs (acPerfMediaGateway,  
acPerfMediaServices and acPerfH323SIPGateway). The first MIB is a generic-type of  
performance measurements MIB available on all Mediant 2000 and related devices. The second  
is specific to the media server, and the third is for H.323/SIP media gateways.  
The generic performance measurements MIB covers:  
Control protocol  
RTP stream  
System packets statistics  
Performance measurement enterprise MIB supports statistics which apply to the  
Proxy/Gatekeeper routing tables.  
11.5 TrunkPack-VoP Series Supported MIBs  
The Mediant 2000 contains an embedded SNMP Agent supporting the following MIBs:  
Standard MIB (MIB-II) - The various SNMP values in the standard MIB are defined in RFC  
1213. The standard MIB includes various objects to measure and monitor IP activity, TCP  
activity, UDP activity, IP routes, TCP connections, interfaces and general system indicators.  
RTP MIB - The RTP MIB is supported in conformance with the IETF’s RFC 2959. It contains  
objects relevant to the RTP streams generated and terminated by the device and to RTCP  
information related to these streams.  
Trunk MIB - The Trunk MIB contains objects relevant to E1/T1 Trunk interfaces.  
NOTIFICATION-LOG-MIB - This standard MIB (RFC 3014 - iso.org.dod.internet.mgmt.mib-  
2) is supported as part of our implementation of carrier grade alarms.  
ALARM-MIB - This is an IETF proposed MIB also supported as part of our implementation of  
carrier grade alarms. This MIB is still not standard and is therefore under the  
audioCodes.acExperimental branch.  
SNMP-TARGET-MIB - This MIB is partially supported (RFC 2273). It allows for the  
configuration of trap destinations and trusted managers only.  
SNMP Research International Enterprise MIBs - Mediant 2000 supports two SNMP  
Research International MIBs: SR-COMMUNITY-MIB and TGT-ADDRESS-MASK-MIB.  
These MIBs are used in the configuration of SNMPv2c community strings and trusted  
managers.  
In addition to the standard MIBs, the complete series contains several proprietary MIBs:  
acBoard MIB - This proprietary MIB contains objects related to configuration of the device  
and channels, as well as to run-time information. Through this MIB, users can set up the  
device configuration parameters, reset the device, monitor the device’s operational  
robustness and Quality of Service during run-time, and receive traps.  
Mediant 2000 SIP User’s Manual  
174  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
Note:  
The acBoard MIB is still supported but is being replaced by five newer  
proprietary MIBs.  
The acBoard MIB has the following groups:  
boardConfiguration  
boardInformation  
channelConfiguration  
channelStatus  
reset  
acTrap  
As noted above, five new MIBs cover the device’s general parameters. Each contains a  
Configuration subtree for configuring related parameters. In some, there also are Status and  
Action subtrees.  
The 5 MIBs are:  
1. AC-ANALOG-MIB  
2. AC-CONTROL-MIB  
3. AC-MEDIA-MIB  
4. AC-PSTN-MIB  
5. AC-SYSTEM-MIB  
Other proprietary MIBs are:  
acGateway MIB - This proprietary MIB contains objects related to configuration of the device  
when applied as a SIP or H.323 media gateway only. This MIB complements the other  
proprietary MIBs.  
The acGateway MIB has the following groups:  
Common - for parameters common to both SIP and H.323  
SIP  
- for SIP parameters only  
- for H.323 parameters only  
H.323  
acAtm - This proprietary MIB contains objects related to configuration and status of the  
device when applied as an ATM media gateway only. This MIB complements the other  
proprietary MIBs.  
The acAtm MIB has the following groups:  
acAtmConfiguration - for configuring ATM related parameters  
acAtmStatus - for the status of ATM connections  
acAlarm - This is AudioCodes' proprietary carrier-grade alarm MIB. It is a simpler  
implementation of the notificationLogMIB and the IETF suggested alarmMIB (both also  
supported in all AudioCodes’ devices).  
The acAlarm MIB has the following groups:  
ActiveAlarm - straightforward (single-indexed) table, listing all currently active alarms,  
together with their bindings (the alarm bindings are defined in acAlarm.  
acAlarmVarbinds and also in acBoard.acTrap. acBoardTrapDefinitions.  
oid_1_3_6_1_4_1_5003_9_10_1_21_2_0).  
acAlarmHistory - straightforward (single-indexed) table, listing all recently raised alarms  
together with their bindings (the alarm bindings are defined in acAlarm.  
Version 4.4  
175  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
acAlarmVarbinds and also in acBoard.acTrap. acBoardTrapDefinitions.  
oid_1_3_6_1_4_1_5003_9_10_1_21_2_0).  
The table size can be altered via  
notificationLogMIB.notificationLogMIBObjects.nlmConfig.nlmConfigGlobalEntryLimit or  
notificationLogMIB.notificationLogMIBObjects.nlmConfig.nlmConfigLogTable.nlm  
ConfigLogEntry.nlmConfigLogEntryLimit.  
The table size can be any value between 50 to 1000 and is 500 by default.  
Traps - Full proprietary trap definitions and trap Varbinds are found in the acBoard MIB and  
acAlarm MIB.  
The following proprietary traps are supported in the device:  
acBoardEvResettingBoard - Sent after the device is reset.  
acBoardEvBoardStarted - Sent after the device is successfully restored and initialized  
following reset.  
acBoardTemperatureAlarm - Sent when a board exceeds its temperature limits.  
acBoardConfigurationError - Sent when a device’s settings are illegal - the trap contains  
a message stating/detailing/explaining the illegality of the setting.  
acBoardFatalError - Sent whenever a fatal device error occurs.  
acFeatureKeyError - Development pending. Intended to relay Feature Key errors, etc.  
acgwAdminStateChange - Sent when Graceful Shutdown commences and ends.  
acBoardCallResourcesAlarm - Indicates that no free channels are available.  
acBoardControllerFailureAlarm - The Gatekeeper/Proxy is not found or registration  
failed. Internal routing table can be used for routing.  
acBoardEthernetLinkAlarm - Ethernet link or links are down.  
acBoardOverloadAlarm - Overload in one or some of the system's components.  
acActiveAlarmTableOverflow - An active alarm could not be placed in the active alarm  
table because the table is full.  
acAtmPortAlarm1 - ATM Port Alarm.  
acAudioProvisioningAlarm1 - Raised if the Media Server is unable to provision its audio.  
In addition to the listed traps, the device also supports the following standard traps:  
dsx1LineStatusChange  
coldStart  
authenticationFailure  
Note 1: The following are special notes pertaining to MIBs:  
A detailed explanation of each parameter can be viewed in an SNMP browser  
in the ‘MIB Description’ field.  
Not all groups in the MIB are functional. Refer to version release notes.  
Certain parameters are non-functional. Their MIB status is marked 'obsolete'.  
When a parameter is set to a new value via SNMP, the change may affect  
device functionality immediately or may require that the device be soft reset for  
the change to take effect. This depends on the parameter type.  
Note 2: The current (updated) device configuration parameters are programmed into  
the device provided that the user does not load an ini file to the device after  
reset. Loading an ini file after reset overrides the updated parameters.  
Additional MIBs are to be supported in future releases.  
Mediant 2000 SIP User’s Manual  
176  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
11.6 SNMP Interface Details  
This section describes details of the SNMP interface that is required when developing an Element  
Manager (EM) for any of the TrunkPack-VoP Series products, or to manage a device with a MIB  
browser.  
Currently, both SNMP and ini file commands and downloads are not encrypted. For ini file  
encoding, refer to Section 6.1 on page 87.  
11.6.1 SNMP Community Names  
By default, the device uses a single, read-only community string of ‘public’ and a single read-write  
community string of ‘private’.  
Users can configure up to 5 read-only community strings and up to 5 read-write community  
strings, and a single trap community string is supported:  
11.6.1.1 Configuration of Community Strings via the ini File  
SNMPREADONLYCOMMUNITYSTRING_<x> = '#######'  
SNMPREADWRITECOMMUNITYSTRING_<x> = '#######'  
where <x> is a number between 0 and 4, inclusive. Note that the '#' character represents any  
alphanumeric character. The maximum length of the string is 20 characters.  
11.6.1.2 Configuration of Community Strings via SNMP  
To configure read-only and read-write community strings, the EM must use the srCommunityMIB.  
To configure the trap community string, the EM must also use the snmpVacmMIB and the  
snmpTargetMIB.  
To add a read-only community string (v2user):  
Add a new row to the srCommunityTable with CommunityName v2user and GroupName  
ReadGroup.  
To delete the read-only community string (v2user), take these 2 steps:  
1. If v2user is being used as the trap community string, follow the procedure for changing the  
trap community string (see below).  
2. Delete the srCommunityTable row with CommunityName v2user.  
To add a read-write community string (v2admin):  
Add a new row to the srCommunityTable with CommunityName of v2admin and GroupName  
ReadWriteGroup.  
To delete the read-write community string (v2admin), take these 2  
steps:  
1. If v2admin is being used as the trap community string, follow the procedure for changing the  
trap community string. (See below.)  
2. Delete the srCommunityTable row with a CommunityName of v2admin and GroupName of  
ReadWriteGroup.  
Version 4.4  
177  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
To change the only read-write community string from v2admin to  
v2mgr, take these 4 steps:  
1. Follow the procedure above to add a read-write community string to a row for v2mgr.  
2. Set up the EM so that subsequent ‘set’ requests use the new community string, v2mgr.  
3. If v2admin is being used as the trap community string, follow the procedure to change the  
trap community string (see below).  
4. Follow the procedure above to delete a read-write community name in the row for v2admin.  
To change the trap community string, take these 2 steps:  
(The following procedure assumes that a row already exists in the srCommunityTable for the new  
trap community string. The trap community string can be part of the TrapGroup, ReadGroup or  
ReadWriteGroup. If the trap community string is used solely for sending traps (recommended), it  
should be made part of the TrapGroup).  
1. Add a row to the vacmSecurityToGroupTable with these values: SecurityModel=2,  
SecurityName=the new trap community string, GroupName=TrapGroup, ReadGroup or  
ReadWriteGroup. The SecurityModel and SecurityName objects are row indices.  
Note:  
You must add GroupName and RowStatus on the same set.  
2. Modify the SecurityName field in the sole row of the snmpTargetParamsTable.  
11.6.2 Trusted Managers  
By default, the agent accepts ‘get’ and ‘set’ requests from any IP address, as long as the correct  
community string is used in the request. Security can be enhanced via the use of Trusted  
Managers. A Trusted Manager is an IP address from which the SNMP Agent accepts and  
processes ‘get’ and ‘set’ requests. An EM can be used to configure up to 5 Trusted Managers.  
Note:  
If Trusted Managers are defined, all community strings work from all Trusted  
Managers. That is, there is no way to associate a community string with  
particular trusted managers.  
11.6.2.1 Configuration of Trusted Managers via ini File  
To set the Trusted Mangers table from start-up, write the following in the ini file:  
SNMPTRUSTEDMGR_X = D.D.D.D  
where X is any integer between 0 and 4 (0 sets the first table entry, 1 sets the second, and so  
on), and D is an integer between 0 and 255.  
11.6.2.2 Configuration of Trusted Managers via SNMP  
To configure Trusted Managers, the EM must use the srCommunityMIB, the snmpTargetMIB and  
the TGT-ADDRESS-MASK-MIB.  
To add the first Trusted Manager, take these 3 steps:  
(The following procedure assumes that there is at least one configured read-write community.  
There are currently no Trusted Managers. The taglist for columns for all srCommunityTable rows  
are currently empty).  
Mediant 2000 SIP User’s Manual  
178  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
1. Add a row to the snmpTargetAddrTable with these values: Name=mgr0, TagList=MGR,  
Params=v2cparams.  
2. Add a row to the tgtAddressMaskTable table with these values: Name=mgr0,  
tgtAddressMask=255.255.255.255:0. The agent does not allow creation of a row in this table  
unless a corresponding row exists in the snmpTargetAddrTable.  
3. Set the value of the TransportLabel field on each non-TrapGroup row in the  
srCommunityTable to MGR.  
To add a subsequent Trusted Manager, take these 2 steps:  
(The following procedure assumes that there is at least one configured read-write community.  
There are currently one or more Trusted Managers. The taglist for columns for all rows in the  
srCommunityTable are currently set to MGR. This procedure must be performed from one of the  
existing Trusted Managers).  
1. Add a row to the snmpTargetAddrTable with these values: Name=mgrN, TagList=MGR,  
Params=v2cparams, where N is an unused number between 0 and 4.  
2. Add a row to the tgtAddressMaskTable table with these values: Name=mgrN,  
tgtAddressMask=255.255.255.255:0.  
An alternative to the above procedure is to set the tgtAddressMask column while you are  
creating other rows in the table.  
To delete a Trusted Manager (not the final one), take this step:  
(The following procedure assumes that there is at least one configured read-write community.  
There are currently two or more Trusted Managers. The taglist for columns for all rows in the  
srCommunityTable are currently set to MGR. This procedure must be performed from one of the  
existing trusted managers, but not the one that is being deleted.  
Remove the appropriate row from the snmpTargetAddrTable.  
The change takes effect immediately. The deleted trusted manager cannot access the device.  
The agent automatically removes the row in the tgtAddressMaskTable.  
To delete the final Trusted Manager, take these 2 steps:  
(The following procedure assumes that there is at least one configured read-write community.  
There is currently only one Trusted Manager. The taglist for columns for all rows in the  
srCommunityTable are currently set to MGR. This procedure must be performed from the final  
Trusted Manager.  
1. Set the value of the TransportLabel field on each row in the srCommunityTable to the empty  
string.  
2. Remove the appropriate row from the snmpTargetAddrTable  
The change takes effect immediately. All managers can now access the device.  
11.6.3 SNMP Ports  
The SNMP Request Port is 161 and the Trap Port is 162. These ports can be changed by setting  
parameters in the device ini file. The parameter name is:  
SNMPPort = <port_number>  
Valid UDP port number; default = 161  
This parameter specifies the port number for SNMP requests and responses. Usually, it should  
not be specified. Use the default.  
Version 4.4  
179  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
11.6.4 Multiple SNMP Trap Destinations  
An agent can now send traps to up to five managers. For each manager, set the following  
parameters defined in the snmpManagersTable in the acBoardMIB:  
snmpTrapManagerSending  
snmpManagerIsUsed  
snmpManagerTrapPort  
snmpManagerIP  
When snmpManagerIsUsed is set to zero (not used), the other three parameters are set to zero.  
snmpManagerIsUsed (Default = Disable(0))  
The allowed values are 0 (disable or no) and 1 (enable or yes).  
snmpManagerIp (Default = 0.0.0.0)  
This is known as SNMPMANAGERTABLEIP in the ini file and is the IP address of the  
manager.  
SnmpManagerTrapPort (Default = 162)  
The valid port range for this is 100-4000.  
snmpManagerTrapSendingEnable (Default = Enable(1))  
The allowed values are 0 (disable) and 1 (enable).  
Note 1: Each of these MIB objects is independent and can be set regardless of the  
state of snmpManagerIsUsed.  
Note 2: If the parameter IsUsed is set to 1, the IP address for that row should be  
supplied in the same SNMP PDU.  
11.6.4.1 Configuration via the ini File  
In the Mediant 2000 ini file, the parameters below can be set to enable or disable the sending of  
SNMP traps. Multiple trap destinations can be supported on the device by setting multiple trap  
destinations in the ini file.  
SNMPMANAGERTRAPSENDINGENABLE_<x> = 0 or 1 indicates if traps are to be sent to the  
specified SNMP trap manager. A value of ‘1’ means that it is enabled, while a value of ‘0’ means  
disabled.  
<x> = a number 0, 1, 2 which is the array element index. Currently, up to 5 SNMP trap managers  
can be supported.  
Figure 11-1 presents an example of entries in a device ini file regarding SNMP. The device can  
be configured to send to multiple trap destinations. The lines in the file below are commented out  
with the ‘;’ at the beginning of the line. All of the lines below are commented out since the first line  
character is a semi-colon.  
Mediant 2000 SIP User’s Manual  
180  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
11. SNMP-Based Management  
Figure 11-1: Example of Entries in a Device ini file Regarding SNMP  
; SNMP trap destinations  
; The board maintains a table of trap destinations containing 5 ;rows. The rows are  
numbered 0..4. Each block of 4 items below ;apply to a row in the table.  
; To configure one of the rows, uncomment all 4 lines in that ;block. Supply an IP  
address and if necessary, change the port ;number.  
; To delete a trap destination, set ISUSED to 0.  
; -change these entries as needed  
;SNMPManagerTableIP_0=  
;SNMPManagerTrapPort_0=162  
;SNMPManagerIsUsed_0=1  
;SNMPManagerTrapSendingEnable_0=1  
;
;SNMPManagerTableIP_1=  
;SNMPManagerTrapPort_1=162  
;SNMPManagerIsUsed_1=1  
;SNMPManagerTrapSendingEnable_1=1  
;
;SNMPManagerTableIP_2=  
;SNMPManagerTrapPort_2=162  
;SNMPManagerIsUsed_2=1  
;SNMPManagerTrapSendingEnable_2=1  
;
;SNMPManagerTableIP_3=  
;SNMPManagerTrapPort_3=162  
;SNMPManagerIsUsed_3=1  
;SNMPManagerTrapSendingEnable_3=1  
;
;SNMPManagerTableIP_4=  
;SNMPManagerTrapPort_4=162  
;SNMPManagerIsUsed_4=1  
;SNMPManagerTrapSendingEnable_4=1  
Note:  
The same information configurable in the ini file can also be configured via  
the acBoardMIB.  
11.6.4.2 Configuration via SNMP  
To configure trap destinations, the EM must use the snmpTargetMIB. Up to 5 trap destinations  
can be configured.  
To add a trap destination:  
Add a row to the snmpTargetAddrTable with these values:  
Name=trapN, TagList=AC_TRAP, Params=v2cparams, where N is an unused number  
between 0 and 4.  
All changes to the trap destination configuration take effect immediately.  
To delete a trap destination:  
Remove the appropriate row from the snmpTargetAddrTable.  
To modify a trap destination:  
(You can change the IP address and/or port number for an existing trap destination. The same  
effect can be achieved by removing a row and adding a new row).  
Modify the IP address and/or port number for the appropriate row in the  
snmpTargetAddrTable.  
Version 4.4  
181  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
To disable a trap destination:  
Change TagList on the appropriate row in the snmpTargetAddrTable to the empty string.  
To enable a trap destination:  
Change TagList on the appropriate row in the snmpTargetAddrTable to ‘AC_TRAP’.  
11.7 SNMP Manager Backward Compatibility  
With support for the Multi Manager Trapping feature, the older acSNMPManagerIP MIB object,  
synchronized with the first index in the snmpManagers MIB table, is also supported. This is  
translated in two features:  
SET/GET to either of the two MIB objects is identical.  
i.e., as far as the SET/GET are concerned OID 1.3.6.1.4.1.5003.9.10.1.1.2.7 is identical to  
OID 1.3.6.1.4.1.5003.9.10.1.1.2.21.1.1.3.  
When setting ANY IP to the acSNMPManagerIP (this is the older parameter, not the table  
parameter), two more parameters are SET to ENABLE. snmpManagerIsUsed.0 and  
snmpManagerTrapSendingEnable.0 are both set to 1.  
11.8 AudioCodes’ Element Management System  
Using AudioCodes’ Element Management System (EMS) is recommended to Customers  
requiring large deployments (multiple media gateways in globally distributed enterprise offices, for  
example), that need to be managed by central personnel.  
The EMS is not included in the device’s supplied package. Contact AudioCodes for detailed  
information on AudioCodes’ EMS and on AudioCodes’ EVN - Enterprise VoIP Network – solution  
for large VoIP deployments.  
Mediant 2000 SIP User’s Manual  
182  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
12. Selected Technical Specifications  
12 Selected Technical Specifications  
Table 12-1: Mediant 2000 Selected Technical Specifications (continues on pages 183 to 185)  
Function  
Specification  
Trunk & Channel Capacity1  
Capacity with E1  
1, 2, 4, 8 or 16 E1 spans, 30, 60, 120, 240 or 480 digital channels  
1, 2, 4, 8 or 16 T1 spans, 24, 48, 96, 192 or 384 digital channels  
Capacity with T1  
Voice & Tone Characteristics  
Voice Compression  
G.711 PCM at 64 kbps µ-law/A-law  
G.723.1 MP-MLQ at 5.3 or 6.3 kbps  
G.726 at 32 kbps ADPCM  
G.729 CS-ACELP 8 Kbps Annex A / B  
NetCoder at 6.4, 7.2, 8.0 and 8.8 kbps  
EVRC  
(10, 20, 30, 40, 50, 60, 80, 100,120 msec)  
(30, 60, 90, 120 msec)  
(10, 20, 30, 40, 50, 60, 80, 100,120 msec)  
(10, 20, 30, 40, 50, 60, 80, 100 msec)  
(20, 40, 60, 80, 100, 120 msec).  
(20, 40, 60, 80, 100 msec).  
AMR  
(20 msec only)  
Transparent  
(20, 40, 60, 80, 100, 120 msec)  
Silence Suppression  
G.723.1 Annex A  
G.729 Annex B  
PCM and ADPCM: Standard Silence Descriptor (SID) with Proprietary Voice Activity  
Detection (VAD) and Comfort Noise Generation (CNG)  
NetCoder  
Packet Loss Concealment  
Echo Cancellation  
G.711 appendix 1  
G.723.1  
G.729 a/b  
G.165 and G.168 2000, configurable tail length per gateway from 32 to 128 msec  
Dynamic range 0 to -25 dBm compliant with TIA 464B and Bellcore TR-NWT-000506.  
DTMF Detection and  
Generation  
DTMF Transport (in-band)  
Mute, transfer in RTP payload or relay in compliance with RFC 2833  
Call Progress Tone  
Detection and Generation  
16 tones: single tone or dual tones, programmable frequency & amplitude; 15  
frequencies in the range 300 to 1980 Hz, 1 or 2 cadences per tone, up to 2 sets of  
ON/OFF periods.  
Output Gain Control  
Input Gain Control  
-32 dB to +31 dB in steps of 1 dB  
-32 dB to +31 dB in steps of 1 dB  
Fax and Modem Transport Modes  
Real time Fax Relay  
Group 3 real-time fax relay up to 14400 bps with auto fallback  
Tolerant network delay (up to 9 seconds round trip delay)  
T.30 (PSTN) and T.38 (IP) compliant (real-time fax)  
CNG tone detection & Relay per T.38  
Answer tone (CED or AnsAm) detection & Relay per T.38  
1 Capacity Limitations:  
When the Echo Canceller’s length is set to 64 msec or more, the number of available gateway channels is reduced  
by a factor of 5/6. For detailed information refer to the parameter ‘MaxEchoCancellerLength’ (Table 6-1).  
When DSP template version 1 (for AMR coder) is selected, the maximum number of channels is 160 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk).  
When DSP template version 2 (for EVRC coder) is selected, the maximum number of channels is 120 instead of 240  
(rounded to full E1/T1 trunk capacity 30/24 channels per trunk).  
Version 4.4  
183  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Table 12-1: Mediant 2000 Selected Technical Specifications (continues on pages 183 to 185)  
Function  
Specification  
Fax Transparency  
Automatic fax bypass (pass-through) to G.711, ADPCM or NSE bypass mode  
Modem Transparency  
Automatic switching (pass-through) to PCM, ADPCM or NSE bypass mode for modem  
signals (V.34 or V.90 modem detection)  
Protocols  
SIP - RFC 3261  
VoIP Signaling Protocol  
Communication Protocols RTP/RTCP packetization.  
IP stack (UDP, TCP, RTP).  
Remote Software load (TFTP & BootP support).  
Telephony Protocols  
In-Band Signaling  
PRI (ETSI Euro ISDN, ANSI NI2, 4/5ESS, DMS 100, QSIG Basic Call, Japan INS1500,  
Australian Telecom, New Zealand Telecom, Hong Kong Variant, Korean MIC)  
E1/T1 CAS protocols: MFC R2, E&M wink start,  
Immediate start, delay start, loop start, ground start,  
Feature Group B, D for E1/T1  
DTMF (TIA 464A)  
MF-R1, MFC R2  
User-defined Call Progress Tones  
Interfaces  
Telephony Interface  
Network Interface  
1, 2, 4, 8 or 16 E1/T1/J1 Balanced 120/100 ohm  
Two 10/100 Base-TX, half or full duplex with auto-negotiation  
LED Indicators  
LED Indications on Front  
Panel  
Power, ACT/Fail, T1/E1 status, LAN status, Swap ready indication  
Connectors & Switches  
Rear Panel  
Trunks  
1 to 8 and 9 to 16  
Two 50-pin female Telco connectors (DDK57AE-40500-21D) or 8 RJ-48c connectors  
for trunks 1 to 8 only  
Ethernet 1 and 2  
AC Power  
Two 10/100 Base-TX, RJ-45 shielded connectors  
Standard IEC320 Appliance inlet.  
Option for a dual (fully redundant) power supply.  
DC Power  
2-pin terminal block (screw connection type) suitable for field wiring  
applications connecting DC Power connector: MSTB2.5/2-STF (5.08 mm) from  
Phoenix Contact.  
Bonding and earthing: A 6-32-UNC screw is provided. Correct ring terminal and 16  
AWG wire minimum must be used for connection.  
Or crimp connection shown below.  
Note that to meet UL approvals, users must fulfill the criteria below.  
2-pin terminal block (crimp connection type) comprising a Phoenix Contact  
Adaptor: Shroud:  
Contacts:  
MSTBC2,5/2-STZF-5,08.  
MSTBC-MT0,5-1,0  
Cable requirement:  
18 AWG x 1.5 m length.  
Physical  
AC Power Supply  
Universal 90 to 260 VAC 1A max, 47-63 Hz  
Option for a dual redundant power supply.  
DC Power Supply (optional) 36 to 72 VDC (nominal 48 VDC), 4A max, floating input  
Environmental (DC)  
Operation Temp:  
Short Term Operation Temp (per NEBS):  
Storage:  
Humidity:  
0° to 40° C / 32° to 104° F  
0° to 55° C / 32° to 131° F  
-40° to 70° C / -40° to 158° F  
10 to 90% non-condensing  
Mediant 2000 SIP User’s Manual  
184  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
12. Selected Technical Specifications  
Table 12-1: Mediant 2000 Selected Technical Specifications (continues on pages 183 to 185)  
Function  
Specification  
Environmental (AC)  
Operation Temp:  
Storage:  
Humidity:  
0° to 40° C / 32° to 104° F  
-40° to 70° C / -40° to 158° F  
10 to 90% non-condensing  
Hot Swap  
cPCI cards are full hot swap supported  
Power supplies are redundant but not hot swappable  
Enclosure Dimensions  
Installation  
445 x 44 x 300 mm; 17.5 x 1.75 x 12 inch.  
1U 19-inch 2-slot cPCI chassis, Rack mount, shelf or desk top.  
Rack mount with 2 side brackets, option 2 extra (rear) side brackets.  
Type Approvals  
Telecommunication  
Standards  
IC CS03; FCC part 68  
Chassis and Host telecom card are approved to the following telecom standards: IC  
CS03; FCC part 68; CTR 4, CTR 12 & CTR 13; JATE; Anatel, Mexico Telecom, Russia  
CCC, ASIF S016, ASIF S038.  
Safety and EMC Standards UL 60 950-1, FCC part 15 Class B, (Class A with Sun 2080 CPU card)  
CE Mark (EN 55022 Class B (Class A with Sun 2080 CPU card), EN 60950-1, EN  
55024, EN 300 386), TS001  
Environmental  
NEBS Level 3: GR-63-Core, GR-1089-Core, Type 1 & 3. Approved for DC powered  
version.  
Complies with ETS 301019; ETS 300019-1, -2, -3. (T 1.1, T 2.3, T3.2). Approved for  
AudioCodes or DC powered versions.  
Diagnostics  
Front panel Status LEDs  
E1/T1 status  
LAN status  
Gateway status (Fail, ACT, Power, and Swap Ready).  
Syslog events  
Supported by Syslog Server, per RFC 3164 IETF standard.  
SNMP v2c  
SNMP MIBs and Traps  
All specifications in this document are subject to change without prior notice.  
Version 4.4  
185  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Reader's Notes  
Mediant 2000 SIP User’s Manual  
186  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
A. Mediant 2000 SIP Software Kit  
Appendix A Mediant 2000 SIP Software Kit  
Table A-1 describes the standard supplied software kit for Mediant 2000 SIP gateways. The  
supplied documentation includes this User’s Manual, the Mediant 2000 Fast Track and the  
Mediant 2000 & TP-1610 SIP Release Notes.  
Table A-1: Mediant 2000 SIP Supplied Software Kit  
File Name  
Description  
Ram.cmp file  
Mediant_SIP_xxx.cmp  
Image file containing the software for the Mediant 2000 gateway.  
ini files and utilities  
Mediant_T1.ini  
Sample ini file for Mediant 2000 E1 gateways.  
Sample ini file for Mediant 2000 T1 gateways.  
Default loadable Call Progress Tones dat file.  
Call progress Tones ini file (used to create dat file).  
Default loadable Voice Prompts dat file.  
Mediant_E1.ini  
Usa_tones_xx.dat  
Usa_tones_xx.ini  
voice_prompts.dat  
DConvert240.exe  
TrunkPack Downloadable Conversion Utility  
Syslog server.  
ACSyslog08.exe  
bootp.exe  
BootP/TFTP configuration utility  
CAS Protocol Files  
MIB Files  
Used for various signaling types, such as E_M_WinkTable.dat.  
MIB library for SNMP browser  
CAS Capture Tool  
ISDN Capture Tool  
Utility that is used to convert CAS traces to textual form.  
Utility that is used to convert ISDN traces to textual form.  
Version 4.4  
187  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
188  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
Appendix B The BootP/TFTP Configuration Utility  
The BootP/TFTP utility enables you to easily configure and provision our boards and media  
gateways. Similar to third-party BootP/TFTP utilities (which are also supported) but with added  
functionality; our BootP/TFTP utility can be installed on Windows™ 98 or Windows™  
NT/2000/XP. The BootP/TFTP utility enables remote reset of the device to trigger the initialization  
procedure (BootP and TFTP). It contains BootP and TFTP utilities with specific adaptations to our  
requirements.  
B.1 When to Use the BootP/TFTP  
The BootP/TFTP utility can be used with the device as an alternative means of initializing the  
gateways. Initialization provides a gateway with an IP address, subnet mask, and the default  
gateway IP address. The tool also loads default software, ini and other configuration files. BootP  
Tool can also be used to restore a gateway to its initial configuration, such as in the following  
instances:  
The IP address of the gateway is not known.  
The Web browser has been inadvertently turned off.  
The Web browser password has been forgotten.  
The gateway has encountered a fault that cannot be recovered using the Web browser.  
Tip:  
The BootP is normally used to configure the device’s initial parameters. Once  
this information has been provided, the BootP is no longer needed. All  
parameters are stored in non-volatile memory and used when the BootP is  
not accessible.  
B.2 An Overview of BootP  
BootP is a protocol defined in RFC 951 and RFC 1542 that enables an internet device to discover  
its own IP address and the IP address of a BootP on the network, and to obtain the files from that  
utility that need to be loaded into the device to function.  
A device that uses BootP when it powers up broadcasts a BootRequest message on the network.  
A BootP on the network receives this message and generates a BootReply. The BootReply  
indicates the IP address that should be used by the device and specifies an IP address from  
which the unit may load configuration files using Trivial File Transfer Protocol (TFTP) described in  
RFC 906 and RFC 1350.  
B.3 Key Features  
Internal BootP supporting hundreds of entities.  
Internal TFTP.  
Contains all required data for our products in predefined format.  
Provides a TFTP address, enabling network separation of TFTP and BootP utilities.  
Tools to backup and restore the local database.  
Templates.  
User-defined names for each entity.  
Option for changing MAC address.  
Version 4.4  
189  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
Protection against entering faulty information.  
Remote reset.  
Unicast BootP response.  
User-initiated BootP respond, for remote provisioning over WAN.  
Filtered display of BootP requests.  
Location of other BootP utilities that contain the same MAC entity.  
Common log window for both BootP and TFTP sessions.  
Works with Windows™ 98, Windows™ NT, Windows™ 2000 and Windows™ XP.  
B.4 Specifications  
BootP standards: RFC 951 and RFC 1542  
TFTP standards: RFC 1350 and RFC 906  
Operating System: Windows™ 98, Windows™ NT, Windows™ 2000 and Windows™ XP  
Max number of MAC entries: 200  
B.5 Installation  
To install the BootP/TFTP on your computer, take these 2 steps:  
1. Locate the BootP folder on the VoIP gateway supplied CD ROM and open the file Setup.exe.  
2. Follow the prompts from the installation wizard to complete the installation.  
To open the BootP/TFTP, take these 2 steps:  
1. From the Start menu on your computer, navigate to Programs and then click on BootP.  
2. The first time that you run the BootP/TFTP, the program prompts you to set the user  
preferences. Refer to the Section B.10 on page 193 for information on setting the  
preferences.  
B.6 Loading the cmp File, Booting the Device  
Once the application is running, and the preferences were set (refer to Section B.10), for each  
unit that is to be supported, enter parameters into the tool to set up the network configuration  
information and initialization file names. Each unit is identified by a MAC address. For information  
on how to configure (add, delete and edit) units, refer to Section B.11 on page 195.  
To load the software and configuration files, take these 4 steps:  
1. Create a folder on your computer that contains all software and configuration files that are  
needed as part of the TFTP process.  
2. Set the BootP and TFTP preferences (refer to Section B.10).  
3. Add client configuration for the VoIP gateway that you want to initialize by the BootP, refer to  
Section B.11.1.  
4. Reset the VoIP gateway, either physically or remotely, causing the device to use BootP to  
access the network and configuration information.  
Mediant 2000 SIP User’s Manual  
190  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
B.7 BootP/TFTP Application User Interface  
Figure B-1 shows the main application screen for the BootP/TFTP utility.  
Figure B-1: Main Screen  
Log Window  
B.8 Function Buttons on the Main Screen  
Pause: Click this button to pause the BootP Tool so that no replies are sent to BootP  
requests. Click the button again to restart the BootP Tool so that it responds to all  
BootP requests. The Pause button provides a depressed graphic when the feature is  
active.  
Edit Clients: Click this button to open a new window that enables you to enter  
configuration information for each supported VoIP gateway. Details on the Clients  
window are provided in Section B.11 on page 195.  
Edit Templates: Click this button to open a new window that enables you to create or  
edit standard templates. These templates can be used when configuring new clients  
that share most of the same settings. Details on the Templates window are provided  
in Section B.12 on page 199.  
Clear Log: Click this button to clear all entries from the Log Window portion of the  
main application screen. Details on the log window are provided in Section B.9 on  
page 192.  
Filter Clients: Click this button to prevent the BootP Tool from logging BootP requests  
received from disabled clients or from clients which do not have entries in the Clients  
table.  
Reset: Click this button to open a new window where you enter an IP address  
requests for a gateway that you want to reset. Refer to Figure B-2 below.  
Figure B-2: Reset Screen  
Version 4.4  
191  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
When a gateway resets, it first sends a BootRequest. Therefore, Reset can be used to force a  
BootP session with a gateway without needing to power cycle the gateway. As with any BootP  
session, the computer running the BootP Tool must be located on the same subnet as the  
controlled VoIP gateway.  
B.9 Log Window  
The log window (refer to Figure B-1 on the previous page) records all BootP request and BootP  
reply transactions, as well as TFTP transactions. For each transaction, the log window displays  
the following information:  
Client: shows the Client address of the VoIP gateway, which is the MAC address of the  
client for BootP transactions or the IP address of the client for TFTP transactions.  
Date: shows the date of the transaction, based on the internal calendar of the computer.  
Time: shows the time of day of the transaction, based on the internal clock of the computer.  
Status: indicates the status of the transaction.  
Client Not Found: A BootRequest was received but there is no matching client entry in  
the BootP Tool.  
Client Found: A BootRequest was received and there is a matching client entry in the  
BootP Tool. A BootReply is sent.  
Client’s MAC Changed: There is a client entered for this IP address but with a different  
MAC address.  
Client Disabled: A BootRequest was received and there is a matching client entry in the  
BootP tool but this entry is disabled.  
Listed At: Another BootP utility is listed as supporting a particular client when the Test  
Selected Client button is clicked (for details on Testing a client, refer to Section B.11.4  
on page 196).  
Download Status: Progress of a TFTP load to a client, shown in %.  
New IP / File: shows the IP address applied to the client as a result of the BootP transaction,  
as well as the file name and path of a file transfer for a TFTP transaction.  
Client Name: shows the client name, as configured for that client in the Client Configuration  
screen.  
Use right-click on a line in the Log Window to open a pop-up window with the following options:  
Reset: Selecting this option results in a reset command being sent to the client VoIP  
gateway. The program searches its database for the MAC address indicated in the line. If the  
client is found in that database, the program adds the client MAC address to the Address  
Resolution Protocol (ARP) table for the computer. The program then sends a reset  
command to the client. This enables a reset to be sent without knowing the current IP  
address of the client, as long as the computer sending the reset is on the same subnet.  
Note: In order to use reset as described above, the user must have administrator privileges  
on the computer. Attempting to perform this type of reset without administrator privileges on  
the computer results in an error message. ARP Manipulation Enable must also be turned  
on in the Preferences window.  
View Client: Selecting this option, or double clicking on the line in the log window, opens the  
Client Configuration window. If the MAC address indicated on the line exists in the client  
database, it is highlighted. If the address is not in the client database, a new client is added  
with the MAC address filled out. You can enter data in the remaining fields to create a new  
client entry for that client.  
Mediant 2000 SIP User’s Manual  
192  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
B.10 Setting the Preferences  
The Preferences window, Figure B-3, is used to configure the BootP Tool parameters.  
Figure B-3: Preferences Screen  
B.10.1 BootP Preferences  
ARP is a common acronym for Address Resolution Protocol, and is the method used by all  
Internet devices to determine the link layer address, such as the Ethernet MAC address, in order  
to route Datagrams to devices that are on the same subnet.  
When ARP Manipulation is enabled on this screen, the BootP Tool creates an ARP cache entry  
on your computer when it receives a BootP BootRequest from the VoIP gateway. Your computer  
uses this information to send messages to the VoIP gateway without using ARP again. This is  
particularly useful when the gateway does not yet have an IP address and, therefore, cannot  
respond to an ARP.  
Because this feature creates an entry in the computer ARP cache, Administrator Privileges are  
required. If the computer is not set to allow administrator privileges, ARP Manipulation cannot be  
enabled.  
ARP Manipulation Enabled: Enable ARP Manipulation to remotely reset a gateway that  
does not yet have a valid IP address.  
If ARP Manipulation is enabled, the following two commands are available.  
Reply Type: Reply to a BootRequest can be either Broadcast or Unicast. The default for  
the BootP Tool is Broadcast. In order for the reply to be set to Unicast, ARP Manipulation  
must first be enabled. This then enables the BootP Tool to find the MAC address for the  
client in the ARP cache so that it can send a message directly to the requesting device.  
Normally, this setting can be left at Broadcast.  
Version 4.4  
193  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
ARP Type: The type of entry made into the ARP cache on the computer, once ARP  
Manipulation is enabled, can be either Dynamic or Static. Dynamic entries expire after a  
period of time, keeping the cache clean so that stale entries do not consume computer  
resources. The Dynamic setting is the default setting and the setting most often used. Static  
entries do not expire.  
Number of Timed Replies: This feature is useful for communicating to VoIP gateways that  
are located behind a firewall that would block their BootRequest messages from getting  
through to the computer that is running the BootP Tool. You can set this value to any whole  
digit. Once set, the BootP Tool can send that number of BootReply messages to the  
destination immediately after you send a remote reset to a VoIP gateway at a valid IP  
address. This enables the replies to get through to the VoIP gateway even if the  
BootRequest is blocked by the firewall. To turn off this feature, set the Number of Timed  
Replies = 0.  
B.10.2 TFTP Preferences  
Enabled: To enable the TFTP functionality of the BootP Tool, check the box beside this  
heading. If you want to use another TFTP application, other than the one included with the  
BootP Tool, unselect the box.  
On Interface: This pull down menu displays all network interfaces currently available on the  
computer. Select the interface that you want to use for the TFTP. Normally, there is only one  
choice.  
Directory: This option is enabled only when the TFTP is enabled. Use this parameter to  
specify the folder that contains the files for the TFTP utility to manage (cmp, ini, Call  
Progress Tones, etc.).  
Boot File Mask: Boot File Mask specifies the file extension used by the TFTP utility for the  
boot file that is included in the BootReply message. This is the file that contains VoIP  
gateway software and normally appears as cmp.  
ini File Mask: ini File mask specifies the file extension used by the TFTP utility for the  
configuration file that is included in the BootReply message. This is the file that contains  
VoIP gateway configuration parameters and normally appears as ini.  
Timeout: This specifies the number of seconds that the TFTP utility waits before  
retransmitting TFTP messages. This can be left at the default value of 5 (the more  
congested your network, the higher the value you should define in these fields).  
Maximum Retransmissions: This specifies the number of times that the TFTP utility tries to  
resend messages after timing out. This can be left at the default value of 10 (the more  
congested your network, the higher the value you should define in these fields).  
Mediant 2000 SIP User’s Manual  
194  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
B.11 Configuring the BootP Clients  
The Clients window, shown in Figure B-4 below, is used to set up the parameters for each  
specific VoIP gateway.  
Figure B-4: Client Configuration Screen  
B.11.1 Adding Clients  
Adding a client creates an entry in the BootP Tool for a specific gateway.  
To add a client to the list without using a template, take these 3 steps:  
1. Click on the Add New Client Icon;  
a client with blank parameters is displayed.  
2. Enter values in the fields on the right side of the window, using the guidelines for the fields in  
Section B.11.5 on page 197.  
3. Click Apply to save this entry to the list of clients, or click Apply & Reset to save this entry  
to the list of clients and send a reset message to that gateway to immediately implement the  
settings.  
Note: To use Apply & Reset you must enable ARP Manipulation in the Preferences  
window. Also, you must have administrator privileges for the computer you are using.  
An easy way to create several clients that use similar settings is to create a template. For  
information on how to create a template, refer to Section B.12 on page 199.  
Version 4.4  
195  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
To add a client to the list using a template, take these 5 steps:  
1. Click on the Add New Client Icon;  
a client with blank parameters is displayed.  
2. In the field Template, located on the right side of the Client Configuration Window, click  
on the down arrow to the right of the entry field and select the template that you want to use.  
3. The values provided by the template are automatically entered into the parameter fields on  
the right side of the Client Configuration Window. To use the template parameters, leave  
the check box next to that parameter selected. The parameter values appear in gray text.  
4. To change a parameter to a different value, unselect the check box to the right of that  
parameter. This clears the parameter provided by the template and enables you to edit the  
entry. Clicking the check box again restores the template settings.  
5. Click Apply to save this entry to the list of clients or click Apply & Reset to save this entry to  
the list of clients and send a reset message to that gateway to immediately implement the  
settings.  
Note: To use Apply & Reset you must enable ARP Manipulation in the Preferences  
window. Also, you must have administrator privileges for the computer you are using.  
B.11.2 Deleting Clients  
To delete a client from the BootP Tool, take these 3 steps:  
1. Select the client that you wish to delete by clicking on the line in the window for that client.  
2. Click the Delete Current Client button  
3. A warning pops up. To delete the client, click Yes.  
B.11.3 Editing Client Parameters  
To edit the parameters for an existing client, take these 4 steps:  
1. Select the client that you wish to edit by clicking on the line in the window for that client.  
2. Parameters for that client display in the parameter fields on the right side of the window.  
3. Make the changes required for each parameter.  
4. Click Apply to save the changes, or click Apply & Reset to save the changes and send a  
reset message to that gateway to immediately implement the settings.  
Note: To use Apply & Reset you must enable ARP Manipulation in the Preferences  
window. Also, you must have administrator privileges for the computer you are using.  
B.11.4 Testing the Client  
There should only be one BootP utility supporting any particular client MAC active on the network  
at any time.  
To check if other BootP utilities support this client, take these 4 steps:  
1. Select the client that you wish to test by clicking on the client name in the main area of the  
Client Configuration Window.  
2. Click the Test Selected Client button  
3. Examine the Log Window on the Main Application Screen. If there is another BootP utility  
that supports this client MAC, there is a response indicated from that utility showing the  
status Listed At along with the IP address of that utility.  
4. If there is another utility responding to this client, you must remove that client from either this  
utility or the other one.  
Mediant 2000 SIP User’s Manual  
196  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
B.11.5 Setting Client Parameters  
Client parameters are listed on the right side of the Client Configuration Window.  
Client MAC: The Client MAC is used by BootP to identify the VoIP gateway. The MAC  
address for the VoIP gateway is printed on a label located on the VoIP gateway hardware.  
Enter the Ethernet MAC address for the VoIP gateway in this field. Click the box to the right  
of this field to enable this particular client in the BootP tool (if the client is disabled, no replies  
are sent to BootP requests).  
Note: When the MAC address of an existing client is edited, a new client is added, with the  
same parameters as the previous client.  
Client Name: Enter a descriptive name for this client so that it is easier to remember which  
VoIP gateway the record refers to. For example, this name could refer to the location of the  
gateway.  
Template: Click the pull down arrow if you wish to use one of the templates that you  
configured. This applies the parameters from that template to the remaining fields.  
Parameter values that are applied by the template are indicated by a check mark in the box  
to the right of that parameter. Uncheck this box if you want to enter a different value. If  
templates are not used, the box to the right of the parameters is colored gray and is not  
selectable.  
IP: Enter the IP address you want to apply to the VoIP gateway. Use the normal dotted  
decimal format.  
Subnet: Enter the subnet mask you want to apply to the VoIP gateway. Use the normal  
dotted decimal format. Ensure that the subnet mask is correct. If the address is incorrect, the  
VoIP gateway may not function until the entry is corrected and a BootP reset is applied.  
Gateway: Enter the IP address for the data network gateway used on this subnet that you  
want to apply to the VoIP gateway. The data network gateway is a device, such as a router,  
that is used in the data network to interface this subnet to the rest of the enterprise network.  
TFTP Server IP: This field contains the IP address of the TFTP utility that is used for file  
transfer of software and initialization files to the gateway. When creating a new client, this  
field is populated with the IP address used by the BootP Tool. If a different TFTP utility is to  
be used, change the IP address in this field to the IP address used by the other utility.  
Boot File: This field specifies the file name for the software (cmp) file that is loaded by the  
TFTP utility to the VoIP gateway after the VoIP gateway receives the BootReply message.  
The actual software file is located in the TFTP utility directory that is specified in the BootP  
Preferences window. The software file can be followed by command line switches. For  
information on available command line switches, refer to Section B.11.6 on page 198.  
Note 1: Once the software file loads into the gateway, the gateway begins functioning  
from that software. In order to save this software to non-volatile memory, (only  
the cmp file, i.e., the compressed firmware file, can be burned to your device's  
flash memory), the -fb flag must be added to the end of the file name. If the  
file is not saved, the gateway reverts to the old version of software after the  
next reset.  
Note 2: The Boot file field can contain up to two file names: cmp file name to be used  
for load of application image and ini file name to be used for gateway  
provisioning. Either one, two or no file names can appear in the Boot file  
field. To use both file names use the ";" separator (without blank spaces)  
between the xxx.cmp and the yyy.ini files (e.g., ram.cmp;SIPgw.ini).  
ini File: This field specifies the configuration ini file that the gateway uses to program its  
various settings. Enter the name of the file that is loaded by the TFTP utility to the VoIP  
gateway after it receives the BootReply message. The actual ini file is located in the TFTP  
utility directory that is specified in the BootP Preferences window.  
Version 4.4  
197  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Call Agent: This field specifies the IP address of the MGCP Call Agent that is controlling the  
gateway. This field can be ignored for all other control/signaling protocols.  
B.11.6 Using Command Line Switches  
You can add command line switches in the field Boot File.  
To use a Command Line Switch, take these 4 steps:  
1. In the field Boot File, leave the file name defined in the field as it is (e.g., ramxxx.cmp).  
2. Place your cursor after cmp  
3. Press the space bar  
4. Type in the switch you require.  
Example: “ramxxx.cmp -fb” to burn flash memory.  
“ramxxx.cmp -fb -em 4” to burn flash memory and for Ethernet Mode 4 (auto-negotiate).  
Table B-1 lists and describes the switches that are available:  
Table B-1: Command Line Switch Descriptions  
Switch  
Description  
-fb  
Burn ram.cmp in flash (only for cmp files)  
-em #  
Use this switch to set Ethernet mode.  
0 = 10 Base-T half-duplex  
1 = 10 Base-T full-duplex  
2 = 100 Base-TX half-duplex  
3 = 100 Base-TX full-duplex  
4 = auto-negotiate (default)  
Auto-negotiate falls back to half-duplex mode when the opposite port is not in auto-negotiate but the speed  
(10 Base-T or 100 Base-TX) in this mode is always configured correctly.  
-br  
BootP retries. Sets the number of BootP requests the device sends during start-up. The device stops  
sending BootP requests when either BootP reply is received or Number of Retries is reached. This switch  
takes effect only from the next device reset.  
1 = 1 BootP retry, 1 second  
2 = 2 BootP retries, 3 seconds  
3 = 3 BootP retries, 6 seconds  
4 = 10 BootP retries, 30 seconds  
5 = 20 BootP retries, 60 seconds  
6 = 40 BootP retries, 120 seconds  
7 = 100 BootP retries, 300 seconds  
15 = BootP retries indefinitely  
-bd  
BootP delays. Sets the interval between the device’s start-up and the first BootP/DHCP request that is  
issued by the device. The switch only takes effect from the next reset of the device.  
1 = 1 second delay (default).  
2 = 10 second delay.  
3 = 30 second delay.  
4 = 60 second delay.  
5 = 120 second delay.  
-bs  
-be  
Use –bs 1 to enable the Selective BootP mechanism.  
Use –bs 0 to disable the Selective BootP mechanism.  
The Selective BootP mechanism enables the gateway’s integral BootP client to filter unsolicited  
BootP/DHCP replies (accepts only BootP replies that contain the text “AUDC" in the vendor specific  
information field). This option is useful in environments where enterprise BootP/DHCP servers provide  
undesired responses to the gateway’s BootP requests.  
Use -be 1 for the device to send device-related initial startup information (such as board type, current IP  
address, software version, etc.) in the vendor specific information field (in the BootP request). This  
information can be viewed in the main screen of the BootP/TFTP, under column 'Client Info‘ (refer to  
Figure B-1 showing BootP/TFTP main screen with the column 'Client Info' on the extreme right). For a full  
list of the vendor specific Information fields, refer to Section 10.3 on page 169.  
Note: This option is not available on DHCP servers.  
Mediant 2000 SIP User’s Manual  
198  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
B. The BootP/TFTP Configuration Utility  
B.12 Managing Client Templates  
Templates can be used to simplify configuration of clients when most of the parameters are the  
same.  
Figure B-5: Templates Screen  
To create a new template, take these 4 steps:  
1. Click on the Add New Template button  
2. Fill in the default parameter values in the parameter fields.  
3. Click Apply to save this new template.  
4. Click OK when you are finished adding templates.  
To edit an existing template, take these 4 steps:  
1. Select the template by clicking on its name from the list of templates in the window.  
2. Make changes to the parameters, as required.  
3. Click Apply to save this new template.  
4. Click OK when you are finished editing templates.  
To delete an existing template, take these 3 steps:  
1. Select the template by clicking its name from the list of templates in the window.  
2. Click on the Delete Current Template button.  
3. A warning pop up message appears. To delete the template, click Yes.  
Note that if this template is currently in use, the template cannot be deleted.  
Version 4.4  
199  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
200  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
C. RTP/RTCP Payload Types and Port Allocation  
Appendix C RTP/RTCP Payload Types and Port  
Allocation  
RTP Payload Types are defined in RFC 1889 and RFC 1890. We have added new payload types  
to enable advanced use of other coder types. These types are reportedly not used by other  
applications.  
Note:  
Refer to the Mediant 2000 & TP-1620 SIP Release Notes for the supported  
coders.  
C.1 Payload Types Defined in RFC 1890  
Table C-1: Packet Types Defined in RFC 1890  
Payload Type  
Description  
G.711 µ-Law  
Basic Packet Rate [msec]  
0
2
10,20  
10,20  
30  
G.726-32  
4
G.723 (6.3/5.3 kbps)  
G.711 A-Law  
G.729A  
8
10,20  
20  
18  
200  
RTCP Sender Report  
Randomly, approximately every 5 seconds (when packets are  
sent by channel)  
201  
RTCP Receiver Report  
Randomly, approximately every 5 seconds (when channel is  
only receiving)  
202  
203  
204  
RTCP SDES packet  
RTCP BYE packet  
RTCP APP packet  
C.2 Defined Payload Types  
Table C-2: Defined Payload Types (continues on pages 201 to 202)  
Payload Type  
Description  
Basic Packet Rate [msec]  
35  
36  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
49  
50  
51  
52  
G.726 32 kbps  
G.726 24 kbps  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
20  
G.726 40 kbps  
G.727 16 kbps  
G.727 24-16 kbps  
G.727 24 kbps  
G.727 32-16 kbps  
G.727 32-24 kbps  
G.727-32 kbps  
G.727 40-16 kbps  
G.727 40-24 kbps  
G.727 40-32 kbps  
NetCoder 4.8 kbps  
NetCoder 5.6 kbps  
NetCoder 6.4 kbps  
NetCoder 7.2 kbps  
Version 4.4  
201  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
Payload Type  
Description  
Basic Packet Rate [msec]  
53  
54  
NetCoder 8.0 kbps  
NetCoder 8.8 kbps  
NetCoder 9.6 kbps  
Transparent PCM  
DTMF relay per RFC 2833  
Fax Bypass  
20  
20  
20  
20  
55  
56  
96  
102  
103  
104  
105  
20  
20  
Modem Bypass  
RFC 2198 (Redundancy)  
NSE Bypass  
Same as channel’s voice coder.  
C.3 Default RTP/RTCP/T.38 Port Allocation  
The following table describes Mediant 2000 gateway default RTP/RTCP/T.38 Port Allocation.  
Table C-3: Default RTP/RTCP/T.38 Port Allocation  
Channel Number  
RTP Port  
RTCP Port  
T.38 Port  
1
6000  
6001  
6002  
2
6010  
6011  
6012  
3
6020  
6021  
6022  
4
6030  
6031  
6032  
5
6040  
6041  
6042  
6
6050  
6051  
6052  
7
6060  
6061  
6062  
8
6070  
6071  
6072  
:
n
:
:
:
6000 + 10(n-1)  
6001 + 10(n-1)  
6002 + 10(n-1)  
:
:
:
:
96  
:
6950  
6951  
6952  
:
:
:
120  
:
7190  
7191  
7192  
:
7910  
:
:
7911  
:
:
7912  
:
192  
:
240  
:
8390  
:
8391  
:
8392  
:
384  
:
9830  
:
9831  
:
9832  
:
480  
10790  
10791  
10792  
Note:  
To configure the gateway to use the same port for both RTP and T.38  
packets, set the parameter ‘T38UseRTPPort’ to 1.  
Mediant 2000 SIP User’s Manual  
202  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
D. Fax and Modem Transport Modes  
Appendix D Fax and Modem Transport Modes  
D.1 Fax/Modem Settings  
Users can choose to use for fax, and for each modem type (V.22/V.23/Bell/V.32/V.34), one of the  
following transport methods:  
Fax relay mode (demodulation / remodulation, not applicable to Modem),  
Bypass (using a high bit rate coder to pass the signal), or  
Transparent (passing the signal in the current voice coder).  
When any of the relay modes are enabled, distinction between fax and modem is not immediately  
possible at the beginning of a session. The channel is therefore in “Answer Tone” mode until a  
decision is made The packets sent to the network at this stage are T.38-complaint fax relay  
packets.  
D.1.1 Configuring Fax Relay Mode  
When FaxTransportType= 1 (relay mode), then when fax is detected the channel automatically  
switches from the current voice coder to answer tone mode, and then to T.38-complaint fax relay  
mode.  
When fax transmission ends, the reverse is carried out, and fax relay switches to voice. This  
mode switch occurs automatically, both at the local and remote endpoints.  
Users can limit the fax rate using the FaxRelayMaxRate parameter and can enable/disable ECM  
fax mode using the FaxRelayECMEnable parameter.  
When using T.38 mode, the User can define a redundancy feature to improve fax transmission  
over congested IP network. This feature is activated by “FaxRelayRedundancyDepth” and  
“EnhancedFaxRelayRedundancyDepth” parameters. Although this is a proprietary redundancy  
scheme, it should not create problems when working with other T.38 decoders.  
Note:  
T.38 mode currently supports only the T.38 UDP syntax.  
D.1.2 Configuring Fax/Modem ByPass Mode  
When VxxTransportType=2 (FaxModemBypass, Vxx can be either V32/V22/Bell/V34/Fax), then  
when fax/modem is detected, the channel automatically switches from the current voice coder to  
a high bit-rate coder, as defined by the User, with the FaxModemBypassCoderType configuration  
parameter.  
During the bypass period, the coder uses the packing factor (by which a number of basic coder  
frames are combined together in the outgoing WAN packet) set by the User in the  
FaxModemBypassM configuration parameter. The network packets to be generated and received  
during the bypass period are regular voice RTP packets (per the selected bypass coder) but with  
a different RTP Payload type.  
When fax/modem transmission ends, the reverse is carried out, and bypass coder is switched to  
regular voice coder.  
Version 4.4  
203  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
D.1.3 Supporting V.34 Faxes  
V.34 fax machine support is available only in bypass mode (fax relay is not supported) when the  
channel is configured in one of the configurations described below:  
FaxTransportMode = 2 (Bypass)  
V34ModemTransportType = 2 (Modem bypass)  
In this configuration, both T.30 and V.34 faxes work in Bypass mode  
Or  
FaxTransportMode = 1 (Relay)  
V34ModemTransportType = 2 (Modem bypass)  
In this configuration, T.30 faxes use Relay mode (T.38) while V.34 fax uses Bypass mode.  
In order to use V.34 fax in Relay mode (T.38), you must configure:  
FaxTransportMode = 1 (Relay)  
V34ModemTransportType = 0 (Transparent)  
V32ModemTransportType = 0  
V23ModemTransportType = 0  
V22ModemTransportType = 0  
This configuration forces the V.34 fax machine to work in T.30 mode.  
Mediant 2000 SIP User’s Manual  
204  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
E. Mediant 2000 Clock Settings  
Appendix E Mediant 2000 Clock Settings  
The gateway can either generate its own timing signals, using an internal clock, or recover them  
from one of the E1/T1 trunks.  
a. To use the internal gateway clock source configure the following parameters:  
TDMBusClockSource = 1  
ClockMaster = 1 (for all gateway trunks)  
b. To use the recovered clock option configure the following parameters:  
TDMBusClockSource = 4  
ClockMaster_x = 0 (for all "slave" gateway trunks connected to PBX#1)  
ClockMaster_x = 1 (for all "master" gateway trunks connected to PBX#2)  
Assuming that the gateway recovers its internal clock from one of the "slave" trunks connected to  
PBX#1, and provides clock to PBX#2 on its "master" trunks.  
In addition it is necessary to define from which of the "slave" trunks the gateway recovers its  
clock:  
TDMBusPSTNAutoClockEnable = 1 (the gateway automatically selects one of the connected  
"slave" trunks)  
Or  
TDMBusLocalReference = # (Trunk index: 0 to 7, default = 0)  
Note 1: To configure the TDM Bus Clock Source parameters, refer to Section 5.9.4 on  
page 68.  
Note 2: When the Mediant 2000 is used in a ‘non-span’ configuration, the internal  
gateway clock must be used (as explained above).  
Version 4.4  
205  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Reader's Notes  
Mediant 2000 SIP User’s Manual  
206  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
F. Customizing the Mediant 2000 Web Interface  
Appendix F Customizing the Mediant 2000 Web  
Interface  
Customers incorporating the Mediant 2000 into their portfolios can customize the device’s Web  
Interface to suit their specific corporate logo and product naming conventions.  
Customers can customize the Web Interface’s title bar (AudioCodes’ title bar is shown in Figure  
F-1; a customized title bar is shown in Figure F-3).  
Figure F-1: User-Customizable Web Interface Title Bar  
Background image can be  
OEM-customized  
Product name can be  
OEM-customized  
Corporate logo can be OEM-  
customized  
Figure F-2: Customized Web Interface Title Bar  
To customize the title bar via the Web Interface, take these 3 steps:  
1. Replace the main corporate logo (refer to Section F.1 below).  
2. Replace the title bar’s background image file (refer to Section F.2 on page 209).  
3. Customize the product’s name (refer to Section F.3 on page 210).  
F.1  
Replacing the Main Corporate Logo  
The main corporate logo can be replaced either with a different logo image file (refer to Section  
corporation logo is replaced, AudioCodes’ logo on the left bar (refer to Figure 5-2) and in the  
Software Upgrade Wizard (refer to Section 5.11.1 on page 78) disappear.  
Also note that the browser’s title bar is automatically updated with the string assigned to the  
WebLogoText parameter when AudioCodes’ default logo is not used.  
F.1.1 Replacing the Main Corporate Logo with an Image File  
Note:  
Use a gif, jpg or jpeg file for the logo image. It is important that the image file  
has a fixed height of 59 pixels (the width can be configured). The combined  
size of the image files (logo and background) is limited to 64 kbytes.  
To replace the default logo with your own corporate image via the Web  
Interface, take these 7 steps:  
1. Access the Mediant 2000 Embedded Web Server (refer to Section 5.6 on page 41).  
Version 4.4  
207  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
2. In the URL field, append the suffix ‘AdminPage’ (note that it’s case-sensitive) to the IP  
address, e.g., http://10.1.229.17/AdminPage.  
3. Click Image Load to Device; the Image Download screen is displayed (shown in Figure  
F-3).  
Figure F-3: Image Download Screen  
4. Click the Browse button in the Send Logo Image File from your computer to the Device  
box. Navigate to the folder that contains the logo image file you want to load.  
5. Click the Send File button; the file is sent to the device. When loading is complete, the  
screen is automatically refreshed and the new logo image is displayed.  
6. Note the appearance of the logo. If you want to modify the width of the logo (the default  
width is 339 pixels), in the Logo Width field, enter the new width (in pixels) and press the  
Set Logo Width button.  
7. To save the image to flash memory so it is available after a power fail, refer to Section 5.12  
on page 84.  
The new logo appears on all Web Interface screens.  
Tip:  
If you encounter any problem during the loading of the files, or you want to  
restore the default images, click the Restore Default Images button.  
To replace the default logo with your own corporate image via the ini  
file, take these 2 steps:  
1. Place your corporate logo image file in the same folder as where the device’s ini file is  
located (i.e., the same location defined in the BootP/TFTP configuration utility). For detailed  
information on the BootP/TFTP, refer to Appendix B on page 189.  
2. Add/modify the two ini file parameters in Table F-1 according to the procedure described in  
Section 6.2 on page 87.  
Note that loading the device’s ini file via the ‘Configuration File’ screen in the Web Interface  
doesn’t load the corporate logo image files as well.  
Mediant 2000 SIP User’s Manual  
208  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
F. Customizing the Mediant 2000 Web Interface  
Table F-1: Customizable Logo ini File Parameters  
Description  
Parameter  
LogoFileName  
The name of the image file containing your corporate logo.  
Use a gif, jpg or jpeg image file.  
The default is AudioCodes’ logo file.  
Note: The length of the name of the image file is limited to 47 characters.  
LogoWidth  
Width (in pixels) of the logo image.  
Note: The optimal setting depends on the resolution settings.  
The default value is 339, which is the width of AudioCodes’ displayed logo.  
F.1.2 Replacing the Main Corporate Logo with a Text String  
The main corporate logo can be replaced with a text string.  
To replace AudioCodes’ default logo with a text string via the Web Interface, modify the two  
ini file parameters in Table F-2 according to the procedure described in Section F.4 on page  
211.  
To replace AudioCodes’ default logo with a text string via the ini file, add/modify the two ini  
file parameters in Table F-2 according to the procedure described in Section 6.2 on page 87.  
Table F-2: Web Appearance Customizable ini File Parameters  
Parameter  
Description  
UseWebLogo  
WebLogoText  
0 = Logo image is used (default).  
1 = Text string is used instead of a logo image.  
Text string that replaces the logo image.  
The string can be up to 15 characters.  
F.2  
Replacing the Background Image File  
The background image file is duplicated across the width of the screen. The number of times the  
image is duplicated depends on the width of the background image and screen resolution. When  
choosing your background image, keep this in mind.  
Note:  
Use a gif, jpg or jpeg file for the background image. It is important that the  
image file has a fixed height of 59 pixels. The combined size of the image  
files (logo and background) is limited to 64 kbytes.  
To replace the background image via the Web, take these 6 steps:  
1. Access the Mediant 2000 Embedded Web Server (refer to Section 5.6 on page 41).  
2. In the URL field, append the suffix ‘AdminPage’ (note that it’s case-sensitive) to the IP  
address, e.g., http://10.1.229.17/AdminPage.  
3. Click the Image Load to Device, the Image Download screen is displayed (shown in Figure  
F-3).  
4. Click the Browse button in the Send Background Image File from your computer to  
gateway box. Navigate to the folder that contains the background image file you want to  
load.  
5. Click the Send File button; the file is sent to the device. When loading is complete, the  
screen is automatically refreshed and the new background image is displayed.  
Version 4.4  
209  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
6. To save the image to flash memory so it is available after a power fail, refer to Section 5.12  
on page 84.  
The new background appears on all Web Interface screens.  
Tip 1:  
Tip 2:  
If you encounter any problem during the loading of the files, or you want to  
restore the default images, click the Restore Default Images button.  
When replacing both the background image and the logo image, first load the  
logo image followed by the background image.  
To replace the background image via the ini file, take these 2 steps:  
1. Place your background image file in the same folder as where the device’s ini file is located  
(i.e., the same location defined in the BootP/TFTP configuration utility). For detailed  
information on the BootP/TFTP, refer to Appendix B on page 189.  
2. Add/modify the ini file parameters in Table F-3 according to the procedure described in  
Section 6.2 on page 87.  
Note that loading the device’s ini file via the ‘Configuration File’ screen in the Web Interface  
doesn’t load the logo image file as well.  
Table F-3: Customizable Logo ini File Parameters  
Parameter  
BkgImageFileName  
Description  
The name (and path) of the file containing the new background.  
Use a gif, jpg or jpeg image file.  
The default is AudioCodes background file.  
Note: The length of the name of the image file is limited to 47 characters.  
F.3  
Customizing the Product Name  
The Product Name text string can be modified according to OEMs specific requirements.  
To replace AudioCodes’ default product name with a text string via the Web Interface, modify  
the two ini file parameters in Table F-4 according to the procedure described in Section F.4  
on page 211.  
To replace AudioCodes’ default product name with a text string via the ini file, add/modify the  
two ini file parameters in Table F-4 according to the procedure described in Section 6.2 on  
page 87.  
Table F-4: Web Appearance Customizable ini File Parameters  
Parameter  
Description  
UseProductName  
UserProductName  
0 = Don’t change the product name (default).  
1 = Enable product name change.  
Text string that replaces the product name.  
The default is “Mediant 2000”.  
The string can be up to 29 characters.  
Mediant 2000 SIP User’s Manual  
210  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
F. Customizing the Mediant 2000 Web Interface  
F.4  
Modifying ini File Parameters via the Web AdminPage  
To modify ini file parameters via the AdminPage, take these 6 steps:  
1. Access the Mediant 2000 Embedded Web Server (refer to Section 5.6 on page 41).  
2. In the URL field, append the suffix ‘AdminPage’ (note that it’s case-sensitive) to the IP  
address, e.g., http://10.1.229.17/AdminPage.  
3. Click the INI Parameters option, the INI Parameters screen is displayed (shown in Figure  
F-4).  
Figure F-4: INI Parameters Screen  
4. In the Parameter Name dropdown list, select the required ini file parameter.  
5. In the Enter Value field to the right, enter the parameter’s new value.  
6. Click the Apply new value button to the right; the INI Parameters screen is refreshed, the  
parameter name with the new value appears in the fields at the top of the screen and the  
Output Window displays a log displaying information on the operation.  
Note:  
You cannot load the image files (e.g., logo/background image files) to the  
device by choosing a file name parameter in this screen.  
Version 4.4  
211  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
212  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
G. Accessory Programs and Tools  
Appendix G Accessory Programs and Tools  
The accessory applications and tools shipped with the device provide you with friendly interfaces  
that enhance device usability and smooth your transition to the new VoIP infrastructure. The  
following applications are available:  
TrunkPack Downloadable Conversion Utility (refer to Section G.1 below).  
PSTN Trace Utility (refer to Section G.1.4 on page 218).  
G.1 TrunkPack Downloadable Conversion Utility  
Use the TrunkPack Downloadable Conversion Utility to:  
Create a loadable Call Progress Tones file (refer to Section G.1.1 on page 214).  
Create a loadable Voice Prompts file from pre-recorded voice messages (refer to Section  
Encode / decode an ini file (refer to Section G.1.3 on page 217).  
Create a loadable Prerecorded Tones file (refer to Section G.1.3 on page 217).  
Figure G-1: TrunkPack Downloadable Conversion Utility Opening Screen  
Version 4.4  
213  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
G.1.1 Converting a CPT ini File to a Binary dat File  
For detailed information on creating a CPT ini file, refer to Section 7.1 on page 135.  
To convert a CPT ini file to a binary dat file, take these 10 steps:  
1. Execute the TrunkPack Downloadable Conversion Utility, DConvert240.exe (supplied with  
the software package); the utility’s main screen opens (shown in Figure G-1).  
2. Click the Process Call Progress Tones File(s) button; the Call Progress Tones screen,  
shown in Figure G-2, opens.  
Figure G-2: Call Progress Tones Conversion Screen  
3. Click the Select File… button that is in the ‘Call Progress Tone File’ box.  
4. Navigate to the folder that contains the CPT ini file you want to convert.  
5. Click the ini file and click the Open button; the name and path of both the ini file and the  
(output) dat file appears in the fields below the Select File button.  
6. Enter the Vendor Name, Version Number and Version Description in the corresponding  
required fields under the ‘User Data’ section.  
7. Set ‘CPT Version’ to ‘Version 1’ only if you use this utility with a version released before  
version 4.4 of the device software (this field is used to maintain backward compatibility).  
8. Check the ‘Use dBm units for Tone Levels’ check box. Note that the levels of the Call  
Progress Tones (in the CPT file) must be in -dBm units.  
9. Click the Make File button; you’re prompted that the operation (conversion) was successful.  
10. Close the application.  
Mediant 2000 SIP User’s Manual  
214  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
G. Accessory Programs and Tools  
G.1.2 Creating a Loadable Voice Prompts File  
For detailed information on the Voice Prompts file, refer to Section 7.2 on page 137.  
To create a loadable Voice Prompts dat file from your voice recording  
files, take these 7 steps:  
1. Execute the TrunkPack Downloadable Conversion Utility, DConvert240.exe (supplied with  
the software package); the utility’s main screen opens (shown in Figure G-1).  
2. Click the Process Voice Prompts File(s) button; the Voice Prompts screen, shown in  
Figure G-3, opens.  
Figure G-3: Voice Prompts Screen  
3. To add the pre-recorded voice files to the ‘Voice Prompts’ screen follow one of these  
procedures:  
Select the files and drag them to the ‘Voice Prompts’ screen.  
Click the Add File(s) button; the ‘Select Files’ screen opens. Select the required Voice  
Prompt files and press the Add>> button. Close the ‘Select Files’ screen.  
Version 4.4  
215  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
4. Arrange the files according to your requirements by dragging and dropping them from one  
location in the list to another. Note that the sequence of the files determines their assigned  
Voice Prompt ID.  
Tip 1:  
Tip 2:  
Use the Play button to play wav files through your PC speakers.  
Use the Remove and Remove all buttons to delete files from the list.  
5. For each of the raw files, select a coder that corresponds with the coder it was originally  
recorded in by completing the following steps:  
Double-click or right-click the required file(s); the ‘File Data’ window (shown in Figure  
G-4) appears.  
From the ‘Coder’ drop-down list, select the required coder type.  
In the ‘Description’ field, enter additional identifying information.  
Close the ‘File Data’ window.  
Note that for wav files, a coder is automatically selected from the wav file’s header.  
Figure G-4: File Data Window  
6. In the ‘Output’ field, specify the output directory in which the Voice Prompts file is generated  
followed by the name of the Voice Prompts file (the default name is voiceprompts.dat).  
7. Press the Make File(s) button; the Voice Prompts loadable file is produced.  
Mediant 2000 SIP User’s Manual  
216  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
G. Accessory Programs and Tools  
G.1.3 Encoding / Decoding an ini File  
For detailed information on secured ini file, refer to Section 6.1 on page 87.  
To encode an ini file, take these 6 steps:  
1. Execute the TrunkPack Downloadable Conversion Utility, DConvert240.exe (supplied with  
the software package); the utility’s main screen opens (shown in Figure G-1).  
2. Click the Process Encoded/Decoded ini file(s) button; the ‘Encode/Decode ini File(s)’  
screen, shown in Figure G-5, opens.  
Figure G-5: Encode/Decode ini File(s) Screen  
3. Click the Select File… button under the ‘Encode ini File(s)’ section.  
4. Navigate to the folder that contains the ini file you want to encode.  
5. Click the ini file and click the Open button; the name and path of both the ini file and the  
output encoded file appear in the fields under the Select File button. Note that the name and  
extension of the output file can be modified.  
6. Click the Encode File(s) button; an encoded ini file with the name and extension you  
specified is created.  
To decode an encoded ini file, take these 4 steps:  
1. Click the Select File… button under the ‘Decode ini File(s)’ section.  
2. Navigate to the folder that contains the file you want to decode.  
3. Click the file and click the Open button. the name and path of both the encode ini file and the  
output decoded file appear in the fields under the Select File button. Note that the name of  
the output file can be modified.  
4. Click the Decode File(s) button; a decoded ini file with the name you specified is created.  
Note that the decoding process verifies the input file for validity. Any change made to the  
encoded file causes an error and the decoding process is aborted.  
Version 4.4  
217  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
G.1.4 Creating a Loadable Prerecorded Tones File  
For detailed information on the PRT file, refer to Section 7.2 on page 137.  
To create a loadable PRT dat file from your raw data files, take these 7  
steps:  
1. Prepare the prerecorded tones (raw data PCM or L8) files you want to combine into a single  
dat file using standard recording utilities.  
2. Execute the TrunkPack Downloadable Conversion utility, DConvert240.exe (supplied with  
the software package); the utility’s main screen opens (shown in Figure G-1).  
3. Click the Process Prerecorded Tones File(s) button; the Prerecorded Tones File(s) screen,  
shown in Figure G-3, opens.  
Figure G-6: Prerecorded Tones Screen  
4. To add the prerecorded tone files (you created in Step 1) to the ‘Prerecorded Tones’ screen  
follow one of these procedures:  
Select the files and drag them to the ‘Prerecorded Tones’ screen.  
Mediant 2000 SIP User’s Manual  
218  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
G. Accessory Programs and Tools  
Click the Add File(s) button; the ‘Select Files’ screen opens. Select the required  
Prerecorded Tone files and press the Add>> button. Close the ‘Select Files’ screen.  
5. For each raw data file, define a Tone Type, a Coder and a Default Duration by completing  
the following steps:  
Double-click or right-click the required file; the ‘File Data’ window (shown in Figure G-4)  
appears.  
From the ‘Type’ drop-down list, select the tone type this raw data file is associated with.  
From the ‘Coder’ drop-down list, select the coder that corresponds to the coder this raw  
data file was originally recorded with.  
In the ‘Description’ field, enter additional identifying information (optional).  
In the ’Default’ field, enter the default duration this raw data file is repeatedly played.  
Close the ‘File Data’ window (press the Esc key to cancel your changes); you are  
returned to the Prerecorded Tones File(s) screen.  
Figure G-7: File Data Window  
6. In the ‘Output’ field, specify the output directory in which the PRT file is generated followed  
by the name of the PRT file (the default name is prerecordedtones.dat). Alternatively, use  
the Browse button to select a different output file. Navigate to the desired file and select it;  
the selected file name and its path appear in the ‘Output’ field.  
7. Click the Make File(s) button; the Progress bar at the bottom of the window is activated. The  
dat file is generated and placed in the directory specified in the ‘Output’ field. A message box  
informing you that the operation was successful indicates that the process is completed.  
Version 4.4  
219  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
G.2 PSTN Trace Utility  
These utilities are designed to convert PSTN trace binary files to textual form. The binary PSTN  
trace files are generated when the User sets the PSTN interface to trace mode.  
G.2.1 Operation  
Generating textual trace/audit file for CAS protocols -  
To generate a readable text file out of the binary trace file when using CAS protocols, rename the  
PSTN trace binary file to CASTrace0.dat and copy it to the same directory in which the translation  
utility CAS_Trace.exe is located. Then, run CAS_Trace.exe (no arguments are required). As a  
result, the textual file CASTrace0.txt is created.  
Generating textual trace/audit file for ISDN PRI protocols -  
To generate a readable text file out of the binary trace file when using ISDN protocols, copy the  
PSTN trace binary file to the same directory in which the translation utility Convert_Trace.bat is  
located. The following files should reside in the same directory: Dumpview.exe, Dumpview.cfg  
and ReadMe.txt. Please read carefully the ReadMe.txt in order to understand the usage of the  
translation utility. Next, run the Convert_Trace.bat. As a result, the textual file is created.  
To start and collect the PSTN trace via the Web, please use the following instructions. (Refer to  
Figure H-8 for a view of the Trunk Traces). Also, please note if the PSTN trace was of a PRI of  
CAS collection based on the framer involved in the trace. This information is needed to properly  
parse the captured data.  
1. Run the UDP2File utility.  
2. Determine the trace file name.  
3. Determine the UDP port.  
4. Mark the PSTN Trace check box.  
5. Push the Run button=> the UDP2File utility starts to collect the trace messages.  
6. Activate the Web page by entering <Mediant 2000 IP address>/TrunkTraces, such as:  
http://10.8.8.101/TrunkTraces. The user and password is the same for the unit.  
7. In the Web page set the trace level of each trunk.  
8. Enable the trace via the Web.  
9. Determine the UDP port (the same as in step 3).  
10. Push the Submit button => the board starts to send the trace messages.  
In the UDP2File utility (Refer to Figure H-9) you should see the number in the packets  
counter increasing.  
Mediant 2000 SIP User’s Manual  
220  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
G. Accessory Programs and Tools  
Figure H-8: Trunk Traces  
Figure H-9: UDP2File Utility  
Version 4.4  
221  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
222  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
H. Software Upgrade Key  
Appendix H Software Upgrade Key  
H.1 About the Software Upgrade Key  
Mediant 2000 gateways are supplied with a Software Upgrade Key already pre-configured for  
each of its TrunkPack Modules (TPM).  
Users can later upgrade their Mediant 2000 features, capabilities and quantity of available  
resources by specifying what upgrades they require, and purchasing a new key to match their  
specification.  
The Software Upgrade Key is sent as a string in a text file, to be loaded into the Mediant 2000.  
Stored in the device’s non-volatile flash memory, the string defines the features and capabilities  
allowed by the specific key purchased by the user. The device allows users to utilize only these  
features and capabilities. A new key overwrites a previously installed key.  
Note:  
The Software Upgrade Key is an encrypted key. Each TPM utilizes a unique  
key. The Software Upgrade Key is provided by AudioCodes only.  
H.2 Backing up the Current Software Upgrade Key  
Back up your current Software Upgrade Key before loading a new key to the device. You can  
always reload this backed-up key to restore your device capabilities to what they originally were if  
the ‘new’ key doesn’t comply with your requirements.  
To backup the current Software Upgrade Key, take these 5 steps:  
1. Access the devices Embedded Web Server (refer to Section 5.5 on page 40).  
2. Click the Software Update button.  
3. Click the Software Upgrade Key tab; the Software Upgrade Key screen is displayed (shown  
in Figure H-1).  
4. Copy the string from the Current Key field and paste it in a new file.  
5. Save the text file with a name of your choosing.  
H.3 Loading the Software Upgrade Key  
After receiving the Software Upgrade Key file (do not modify its contents in any way), ensure that  
its first line is [LicenseKeys] and that it contains one or more lines in the following format:  
S/N<Serial Number of TPM> = <long Software Upgrade Key>  
For example: S/N370604 = jCx6r5tovCIKaBBbhPtT53Yj...  
One S/N must match the S/N of your device. The device’s S/N can be viewed in the ‘Device  
Information’ screen (refer to Section 5.10.4 on page 77).  
You can load a Software Upgrade Key using:  
The Embedded Web Server (refer to Section H.3.1 below).  
The BootP/TFTP configuration utility (refer to Section H.3.2 on page 225).  
AudioCodes’ EMS (refer to Section 11.8 on page 182 and to AudioCodes’ EMS User’s  
Manual or EMS Product Description).  
Version 4.4  
223  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
H.3.1 Loading the Software Upgrade Key Using the Embedded Web  
Server  
To load a Software Upgrade Key using the Web Server, take these 5  
steps:  
1. Access the devices Embedded Web Server (refer to Section 5.5 on page 40).  
2. Click the Software Update button.  
3. Click the Software Upgrade Key tab; the Software Upgrade Key screen is displayed (shown  
in Figure H-1).  
4. When loading a single key S/N line to a device:  
Open the Software Upgrade Key file (it should open in Notepad), select and copy the key  
string of the device’s S/N and paste it into the Web field New Key. If the string is sent in the  
body of an email, copy and paste it from there. Press the Add Key button.  
When loading a Software Upgrade Key text file containing multiple S/N lines to a device  
(refer to Figure H-2):  
Click the Browse button in the Send “Upgrade Key” file from your computer to the  
device field, and navigate to the Software Upgrade Key text file.  
Click the Send File button.  
The new key is loaded to the device, validated and if valid is burned to memory. The new  
key is displayed in the Current Key field.  
Validate the new key by scrolling through the ‘Key features:’ panel and verifying the  
presence / absence of the appropriate features.  
5. After verifying that the Software Upgrade Key was successfully loaded, reset the device; the  
new capabilities and resources are active.  
Figure H-1: Software Upgrade Key Screen  
Mediant 2000 SIP User’s Manual  
224  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
H. Software Upgrade Key  
Figure H-2: Example of a Software Upgrade Key File Containing Multiple S/N Lines  
H.3.2 Loading the Software Upgrade Key Using BootP/TFTP  
To load the Software Upgrade Key file using BootP/TFTP, take these 5  
steps:  
1. Place the file in the same location you’ve saved the device’s cmp file.  
2. Start the BootP/TFTP configuration utility and from the Services menu in the main screen,  
choose option Clients; the Client Configuration screen is displayed (refer to Figure Figure  
B-4 on page 195).  
3. From the drop-down list in the INI File field, select the Software Upgrade Key file instead of  
the device’s ini file. Note that the device’s cmp file must be specified in the Boot File field.  
4. Configure the initial BootP/TFTP parameters required, and click OK (refer to Appendix B on  
page 189).  
5. Reset the device; the device’s cmp and Software Upgrade Key files are loaded to the device.  
H.4 Verifying that the Key was Successfully Loaded  
After installing the key, you can determine in the Embedded Web Server’s read-only ‘Key  
features:’ panel (Software Update menu > Software Upgrade Key) (refer to Figure H-1) that the  
features and capabilities activated by the installed string match those that were ordered.  
You can also verify that the key was successfully loaded to the device by accessing the Syslog  
server. For detailed information on the Syslog server, refer to Section 9.2 on page 165. When a  
key is successfully loaded, the following message is issued in the Syslog server:  
"S/N___ Key Was Updated. The Board Needs to be Reloaded with ini file\n"  
H.5 Troubleshooting an Unsuccessful Loading of a Key  
If the Syslog server indicates that a Software Upgrade Key file was unsuccessfully loaded (the  
SN_ line is blank), take the following preliminary actions to troubleshoot the issue:  
Open the Software Upgrade Key file and check that the S/N line of the specific device whose  
key you want to update is listed in it. If it isn’t, contact AudioCodes.  
Verify that you’ve loaded the correct file and that you haven’t loaded the device’s ini file or  
the CPT ini file by mistake. Open the file and ensure that the first line is [LicenseKeys].  
Verify that you didn’t alter in any way the contents of the file.  
H.6 Abort Procedure  
Reload the key you backed-up in Section Backing up the Current Software Upgrade Key on page  
223 to restore your device capabilities to what they originally. To load the backed-up key use the  
procedure described in Section Loading the Software Upgrade Key on page 223.  
Version 4.4  
225  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
226  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
I. Release Reason Mapping  
Appendix I Release Reason Mapping  
Table I-1 below describes the mapping of ISDN release reason to SIP response. Table I-2 on  
page 229 describes the mapping of SIP response to ISDN release reason.  
Table I-1: Mapping of ISDN Release Reason to SIP Response (continues on pages 227 to 228)  
ISDN Release  
Reason  
SIP  
Response  
Description  
Description  
1
2
3
404  
404  
404  
Unallocated number  
Not found  
No route to network  
Not found  
Not found  
No route to destination  
6
7
Channel unacceptable  
Not acceptable  
406  
Call awarded and being delivered in an  
established channel  
500  
Server internal error  
16  
17  
18  
19  
20  
21  
22  
22  
23  
26  
27  
28  
29  
30  
31  
34  
38  
41  
42  
43  
44  
47  
49  
50  
55  
57  
58  
63  
65  
-*  
Normal call clearing  
BYE  
486  
408  
480  
480  
403  
410  
410  
480  
404  
502  
484  
501  
501*  
480  
503  
503  
503  
503  
502*  
503*  
503  
503*  
503*  
403  
403  
503  
503*  
501  
User busy  
Busy here  
No user responding  
Request timeout  
Temporarily unavailable  
Temporarily unavailable  
Forbidden  
No answer from the user  
Subscriber absent  
Call rejected  
Number changed w/o diagnostic  
Number changed with diagnostic  
Redirection to new destination  
Non-selected user clearing  
Destination out of order  
Address incomplete  
Gone  
Gone  
Temporarily unavailable  
Not found  
Bad gateway  
Address incomplete  
Not implemented  
Not implemented  
Temporarily unavailable  
Service unavailable  
Service unavailable  
Service unavailable  
Service unavailable  
Bad gateway  
Facility rejected  
Response to status enquiry  
Normal unspecified  
No circuit available  
Network out of order  
Temporary failure  
Switching equipment congestion  
Access information discarded  
Requested channel not available  
Resource unavailable  
Service unavailable  
Service unavailable  
Service unavailable  
Service unavailable  
Forbidden  
QoS unavailable  
Facility not subscribed  
Incoming calls barred within CUG  
Bearer capability not authorized  
Bearer capability not presently available  
Service/option not available  
Bearer capability not implemented  
Forbidden  
Service unavailable  
Service unavailable  
Not implemented  
* Messages and responses were created since the ‘ISUP to SIP Mapping’ draft doesn’t specify their cause  
code mapping.  
Version 4.4  
227  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
ISDN Release  
Reason  
SIP  
Response  
Description  
Description  
66  
69  
480*  
503*  
Channel type not implemented  
Temporarily unavailable  
Service unavailable  
Requested facility not implemented  
Only restricted digital information bearer  
capability is available  
70  
503*  
Service unavailable  
79  
81  
82  
501  
502*  
502*  
Service or option not implemented  
Invalid call reference value  
Not implemented  
Bad gateway  
Identified channel does not exist  
Bad gateway  
Suspended call exists, but this call identity  
does not  
83  
503*  
Service unavailable  
84  
85  
503*  
503*  
Call identity in use  
No call suspended  
Service unavailable  
Service unavailable  
Call having the requested call identity has been  
cleared  
86  
408*  
Request timeout  
87  
88  
91  
95  
96  
97  
503  
503  
User not member of CUG  
Service unavailable  
Service unavailable  
Bad gateway  
Incompatible destination  
502*  
503  
Invalid transit network selection  
Invalid message  
Service unavailable  
Conflict  
409*  
480*  
Mandatory information element is missing  
Message type non-existent or not implemented  
Temporarily not available  
Message not compatible with call state or  
message type non-existent or not implemented  
98  
99  
409*  
480*  
Conflict  
Information element non-existent or not  
implemented  
Not found  
100  
101  
102  
111  
127  
501*  
503*  
408  
500  
500  
Invalid information elements contents  
Message not compatible with call state  
Recovery of timer expiry  
Not implemented  
Service unavailable  
Request timeout  
Protocol error  
Server internal error  
Server internal error  
Interworking unspecified  
Mediant 2000 SIP User’s Manual  
228  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
I. Release Reason Mapping  
Table I-2: Mapping of SIP Response to ISDN Release Reason  
SIP  
Response  
ISDN Release  
Reason  
Description  
Description  
31  
Bad request  
Normal, unspecified  
400  
401  
402  
403  
404  
405  
406  
407  
408  
409  
410  
411  
413  
414  
21  
21  
Unauthorized  
Call rejected  
Payment required  
Forbidden  
Call rejected  
21  
Call rejected  
1
Not found  
Unallocated number  
Service/option unavailable  
Service/option not implemented  
Call rejected  
63  
Method not allowed  
Not acceptable  
Proxy authentication required  
Request timeout  
Conflict  
79  
21  
102  
41  
Recovery on timer expiry  
Temporary failure  
Number changed w/o diagnostic  
Interworking  
22  
Gone  
127  
127  
127  
Length required  
Request entity too long  
Request URI too long  
Interworking  
Interworking  
415  
79  
Unsupported media type  
Service/option not implemented  
420  
480  
481*  
482*  
483  
484  
485  
486  
488  
500  
501  
502  
503  
504  
505*  
600  
603  
604  
606*  
127  
18  
127  
127  
25  
28  
1
Bad extension  
Interworking  
Temporarily unavailable  
Call leg/transaction doesn’t exist  
Loop detected  
No user responding  
Interworking  
Interworking  
Too many hops  
Exchange – routing error  
Invalid number format  
Unallocated number  
User busy  
Address incomplete  
Ambiguous  
17  
31  
41  
38  
38  
41  
102  
127  
17  
21  
1
Busy here  
Not acceptable here  
Server internal error  
Not implemented  
Bad gateway  
Normal, unspecified  
Temporary failure  
Network out of order  
Network out of order  
Temporary failure  
Recovery on timer expiry  
Interworking  
Service unavailable  
Server timeout  
Version not supported  
Busy everywhere  
Decline  
User busy  
Call rejected  
Does not exist anywhere  
Not acceptable  
Unallocated number  
Network out of order  
38  
* Messages and responses were created since the ‘ISUP to SIP Mapping’ draft doesn’t specify their cause  
code mapping.  
Version 4.4  
229  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Reader’s Notes  
Mediant 2000 SIP User’s Manual  
230  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
Appendix J SS7 Tunneling  
The Signaling System 7 (SS7) tunneling feature facilitates peer-to-peer transport of SS7 links  
between gateways that support AudioCodes' unique MTP2 (Message Transfer Part) Tunneling  
application (M2TN) for transferring SS7 MTP2 link data over IP. In this scenario, both sides of  
the link are pure TDM switches and are unaware of the IP tandem that is utilized between them.  
Using M2TN, the network operator can support SS7 connections over IP, carrying MTP level 3,  
as well as higher level SS7 layers (e.g., user parts and application protocols, such as TUP  
(Telephone User Part), Integrated ISUP (Services User Part), SCCP (Signaling Connection  
Control Part), TCAP (Transaction Capabilities Application Part), etc.).  
M2TN uses standard protocols, such as SIGTRAN (RFC 2719 Architectural Framework for  
Signaling Transport), SCTP (RFC 2960, Stream Control Transmission Protocol), M2UA (RFC  
3331, MTP2 User Adaptation Layer), the latter being used for transporting SS7-MTP2 signaling  
information over IP. M2UA architecture is shown in Figure J-1. M2TN architecture is shown in  
Figure J-1: M2UA Architecture  
Figure J-2: M2TN Architecture  
Version 4.4  
231  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
J.1  
MTP2 Tunneling Technology  
The SS7 tunneling technology is based on a pairing of remote and central gateways, as shown in  
Figure J-3. The remote gateways are configured to backhaul MTP layer 2 signaling over the IP  
network using standard M2UA protocol (over SCTP protocol). The function of the M2TN entity is  
to transmit traffic and handle all management events between MTP2 on the TDM side and  
M2UA's MGC (Media Gateway Controler) entity on the IP side. Only the actual SS7 MSU  
(Message Signaling Unit) data is sent. Management of the SS7 link is performed using M2UA  
without transporting the MTP2 LSSU (Link Status Signaling Unit) and FISU (Fill in Signaling Unit)  
messages over IP. These messages, in addition to MTP2 timing, are terminated and supported,  
respectively, by the remote and central sides. Therefore, the MTP2 connections are not affected  
by the fact that they are transported over IP.  
Figure J-3: Protocol Architecture for MTP2 Tunneling  
J.2  
SS7 Characteristics  
Only standard protocols are used on external interfaces (MTP2 on PSTN side, and M2UA  
over SCTP on IP side) - the M2TN application resides internally in the Mediant 2000.  
No extra signaling point codes are required; both endpoints are unaware that the SS7  
connection is via IP.  
Several links from multiple SS7 nodes can be concentrated into a single board on the  
‘Central’ side (using several SCTP associations per gateway).  
Mediant 2000 gateways can handle SS7 MTP2 tunneling and voice concurrently (does not  
require additional gateway or other server).  
Voice and signaling can be transferred on the same E1/T1 trunk (F-Links).  
IP traffic can be monitored via standard sniffing tools (e.g. protocol analyzers).  
Mediant 2000 SIP User’s Manual  
232  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
J.3  
SS7 Parameters  
The parameters in Table J-1 below configure all MTP attributes simultaneously. To set each MTP  
attribute individually, add _xx (xx equals the element number in the range of 0 to 2) to the end of  
the ini file field name.  
Table J-1: SS7 Parameters (continues on pages 233 to 234)  
ini File Parameter Name  
Description  
SS7_MTP2_Param_AERM_TIE  
Defines the SS7 alignment emergency error rate threshold.  
The valid range is 0 to 10.  
The default value is 1.  
SS7_MTP2_Param_AERM_TIN  
Defines the SS7 alignment normal error rate threshold.  
The valid range is 0 to 20.  
The default value is 4.  
SS7_MTP2_Param_Error_Correction_ Defines the SLI error correction method.  
Method  
0 = Basic (default)  
B = Basic  
P = PCR (Preventive Cyclic Retransmission)  
SS7_MTP2_Param_IAC_CP  
Defines the number of aborted proving attempts before sending an out-of-  
service to MTP-3.  
The valid range is 0 to 10.  
The default value is 5.  
SS7_MTP2_Param_Link_Rate  
Defines the SS7 SLI Link Rate.  
Choose either:  
0 = 64 kbps (default)  
A = 64 kbps  
D = 56 kbps  
SS7_MTP2_Param_LSSU_Length  
SS7_MTP2_Param_Octet_Counting  
Defines the SS7 MTP2 LSSU length as 1 or 2 (bytes).  
The valid range is 1 to 2.  
The default value is 1.  
Defines the SS7 MTP2 Octet received while the OCTET is in counting mode  
(# of Octets received - N Octets - while in Octet counting mode).  
The valid range is 0 to 256.  
The default value is 16.  
SS7_MTP2_Param_SUERM_SU_D  
SS7_MTP2_Param_SUERM_T  
SS7_MTP2_Param_Timer_T1  
SS7_MTP2_Param_Timer_T2  
SS7_MTP2_Param_Timer_T3  
SS7_MTP2_Param_Timer_T4E  
SS7_MTP2_Param_Timer_T4N  
SS7_MTP2_Param_Timer_T5  
Defines the SS7 Signal Unit error rate monitor D threshold.  
The valid range is 0 to 256.  
The default value is 256.  
Defines the SS7 SUERM (Signal Unit Error Rate Monitor) T threshold.  
The valid range is 0 to 256.  
The default value is 64.  
Defines the SS7 MTP2 T1 alignment ready timer (in msecs).  
The valid range is 0 to 100000.  
The default value is 50000.  
Defines the SS7 MTP2 T2 unaligned timer (in msecs).  
The valid range is 0 to 200000.  
The default value is 150000.  
Defines the SS7 MTP2 T3 timer aligned.  
The valid range is 0 to 20000.  
The default value is 2000.  
Defines the SS7 MTP2 T4e Emergency proving period timer (msec).  
The valid range is 0 to 5000.  
The default value is 500.  
Defines the SS7 MTP2 T4n Nominal proving period timer.  
The valid range is 0 to 15000.  
The default value is 8200.  
Defines the SS7 MTP2 Sending SIB timer.  
The valid range is 0 to 2400.  
The default value is 120.  
Version 4.4  
233  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
Table J-1: SS7 Parameters (continues on pages 233 to 234)  
ini File Parameter Name Description  
SS7_MTP2_Param_Timer_T6  
Defines the SS7 MTP2 Remote Congestion timer (in msec).  
The valid range is 0 to 10000.  
The default value is 6000.  
SS7_MTP2_Param_Timer_T7  
Defines the SS7 MTP2 excessive delay of the ack timer (in msec).  
The valid range is 0 to 5000.  
The default value is 2000.  
J.4 SS7 Table Parameters  
J.4.1 SIGTRAN Interface Groups  
Table J-2: SIGTRAN Interface Groups (continues on pages 234 to 235)  
ini File Parameter Name  
Description  
SS7_SIG_IF_GR_INDEX  
Indicates the SS7 interface group index for a line.  
The valid range is 0 to 15.  
SS7_IF_GR_ID  
Determines the SS7 SIGTRAN interface group index, for a line.  
The valid range is 0 to 0xFFFF.  
The default value is 0xFFFE.  
SS7_SIG_SG_MGC  
Determines the SS7 SIGTRAN interface group Signaling Gateway (SG) and  
Media Gateway Controller (MGC) option.  
The valid range is 77(MGC), 83(SG).  
The default value is 83.  
SS7_SIG_LAYER  
Determines the SIGTRAN group layer (IUA/M2UA/M3UA).  
Choose either:  
0 = no_layer (default)  
1 = iua  
2 = m2ua  
3 = m3ua  
4 = m2tunnel  
5 = V5ua  
SS7_SIG_TRAF_MODE  
SS7_SIG_T_REC  
SS7_SIG_T_ACK  
SS7_SIG_T_HB  
Determines the SS7 SIGTRAN interface group traffic mode.  
The valid range is 1 to 3.  
The default value is 1.  
Determines the SIGTRAN group T recovery.  
The valid range is 0 to 10000000.  
The default value is 2000.  
Determines the SIGTRAN group T Ack (in msec).  
The valid range is 0 to 10000000.  
The default value is 2000.  
Determines the SIGTRAN group T Hb (in msec).  
The valid range is 0 to 10000000.  
The default value is 2000.  
SS7_SIG_MIN_ASP  
Determines the SIGTRAN group minimal Application Server Process (ASP)  
number (minimum = 1).  
The valid range is 1 to .10  
The default value is 1.  
SS7_SIG_BEHAVIOUR  
SS7_SCTP_INSTANCE  
Determines the SIGTRAN group behavior bit.  
The valid range is 0 to 0xFFFFFFFE.  
The default value is 0.  
Determines the SIGTRAN group SCTP instance.  
The valid range is 0 to 0xFFFE.  
The default value is 0xFFFE.  
Mediant 2000 SIP User’s Manual  
234  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
Table J-2: SIGTRAN Interface Groups (continues on pages 234 to 235)  
ini File Parameter Name  
Description  
SS7_LOCAL_SCTP_PORT  
Determines the SIGTRAN group SCTP port.  
The valid range is 0 to 0xFFFE.  
The default value is 0Xfffe.  
SS7_SIG_NETWORK  
Determines the SIGTRAN group Network (ITU, ANSI, CHINA).  
The valid range is 1 to 3.  
The default value is 1.  
SS7_DEST_SCTP_PORT  
SS7_DEST_IP  
Determines the SIGTRAN group destination SCTP port.  
The valid range is 0 to 0xFFFE.  
The default value is 0xFFFE.  
Determines the SIGTRAN group destination IP Address  
The valid range is 0 to 0xFFFFFFFE.  
The default value is 0.  
SS7_MGC_MX_IN_STREAM  
SS7_MGC_NUM_OUT_STREAM  
Determines the SIGTRAN group maximum inbound stream.  
The valid range is 2 to 0xFFFE.  
The default value is 2.  
Determines the SIGTRAN group's number of outbound streams.  
The valid range is 2 to 0xFFFE.  
The default value is 2.  
J.4.2 SIGTRAN Interface IDs  
Table J-3: SIGTRAN Interface IDs  
ini File Parameter Name  
Description  
SS7_SIG_IF_ID_INDEX  
Determines the SS7 interface ID index, for a line.  
The valid range is 0 to 15.  
The default value is 1.  
SS7_SIG_IF_ID_VALUE  
Determines the SIGTRAN interface ID value.  
The valid range is 0 to 0xFFFFFFFE.  
The default value is 0.  
SS7_SIG_IF_ID_NAME  
Determines the SIGTRAN interface ID (text string).  
The default string is ‘INT_ID’.  
SS7_SIG_IF_ID_OWNER_GROUP  
Determines the SIGTRAN interface ID owner group.  
The valid range 0 to 0xFFFE.  
The default value is 0.  
SS7_SIG_IF_ID_LAYER  
Determines the SIGTRAN group layer (IUA/M2UA/M3UA).  
0 = no_layer (default)  
1 = iua  
2 = m2ua  
3 = m3ua  
4 = m2tunnel  
5 = V5ua  
SS7_SIG_IF_ID_NAI  
SS7_SIG_M3UA_SPC  
Determines the SIGTRAN interface ID NAI.  
The valid range 0 to 0xFFFE.  
The default value is 0xFFFE.  
Determines the SIGTRAN M3UA SPC.  
The valid range 0 to 0xFFFFFFFE.  
The default value is 0.  
Version 4.4  
235  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
J.4.3 SS7 Signaling Link  
Table J-4: SS7 Signaling Link (continues on pages 236 to 237)  
ini File Parameter Name Description  
SS7_LINK_INDEX  
Determines the index field for a line.  
The valid range is 0 to 7. The default value is 0.  
SS7_LINK_ROWSTATUS  
SS7_LINK_ACTION  
Determines the RowStatus field for a line.  
The valid range is acPARAMSET_ROWSTATUS_DOESNOTEXIST to  
acPARAMSET_ROWSTATUS_DESTROY. The default value is  
acPARAMSET_ROWSTATUS_DOESNOTEXIST.  
Determines the management field for actions.  
The valid range is acSS7LINK_PS_ACTION_NONE to  
acSS7LINK_PS_ACTION_LPR. The default value is  
acSS7LINK_PS_ACTION_NONE.  
SS7_LINK_ACTION_RESULT  
Determines the management field for actions result.  
The valid range is acPARAMSET_ACTION_RESULT_SUCCEEDED to  
acPARAMSET_ACTION_RESULT_FAILED. The default value is  
acPARAMSET_ACTION_RESULT_SUCCEEDED.  
SS7_LINK_NAME  
String name for link parameters  
The default string is "LINK”.  
SS7_LINK_OPERATIONAL_STATE  
Determines the operational state of a signaling link.  
The valid range is L3_OFFLINE to L3_INSERVICE. The default value is  
L3_OFFLINE.  
SS7_LINK_ADMINISTRATIVE_STATE Determines the administrative state of a signaling link.  
The valid range is L3_OFFLINE to L3_INSERVICE. The default value is  
L3_OFFLINE.  
SS7_LINK_TRACE_LEVEL  
Determines the trace level of a signaling link (level 2).  
The valid range is 0 to 1. The default value is 0.  
SS7_LINK_L2_TYPE  
Determines the link layer type - defines level 2 media of signaling link.  
The valid range is SS7_SUBLINK_L2_TYPE_NONE to  
SS7_SUBLINK_L2_TYPE_SAAL. The default value is  
SS7_SUBLINK_L2_TYPE_NONE.  
SS7_LINK_L3_TYPE  
Determines the link high layer type - defines level 3 or L2 high layer of  
signaling link.  
The valid range is SS7_SUBLINK_L3_TYPE_NONE to  
SS7_SUBLINK_L3_TYPE_MTP2_TUNNELING. The default value is  
SS7_SUBLINK_L3_TYPE_NONE.  
SS7_LINK_TRUNK_NUMBER  
SS7_LINK_TIMESLOT_NUMBER  
SS7_LINK_MTC_BUSY  
Determines the trunk number of a signaling link (TDM).  
The valid range is 0 to 7. The default value is 0.  
Determines the time-slot number of a signaling link (TDM).  
The valid range is 0 to 31. The default value is 16.  
Determines the link local busy indicator – if set, indicates link is busy due to  
local mtc action.  
The valid range is 0 to 1. The default value is 0.  
SS7_LINK_INHIBITION  
Determines the link inhibit indicator - if set, indicates link is inhibited.  
The valid range is 0 to 1. The default value is L3_LINK_UNINHIBITED.  
SS7_LINK_LAYER2_VARIANT  
Determines the variant (layer 2) of signaling link (TDM).  
The valid range is NET_VARIANT_OTHER to NET_VARIANT_CHINA. The  
default value is NET_VARIANT_ITU.  
SS7_LINK_MTP2_ATTRIBUTES  
Determines the MTP2 attributes of signaling link (TDM).  
The valid range is 0 to MAX_C7_MTP2_PARAMS_INDEX. The default  
value is 3.  
SS7_CONGESTION_LOW_MARK  
SS7_CONGESTION_HIGH_MARK  
SS7_LINK_M2UA_IF_ID  
Determines the link congestion low mark of signaling link (TDM).  
The valid range is 0 to 255. The default value is 5.  
Determines the link congestion high mark of signaling link (TDM).  
The valid range is 0 to 255. The default value is 20.  
Determines the interface ID (M2UA) of signaling link.  
The valid range is 0 to 0xFFFFFFFF. The default value is 0.  
Mediant 2000 SIP User’s Manual  
236  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
Table J-4: SS7 Signaling Link (continues on pages 236 to 237)  
ini File Parameter Name  
Description  
SS7_LINK_GROUP_ID  
Determines the group ID (M3UA) of signaling link.  
The valid range is 0 to 0xFFFF. The default value is 0.  
ATM_SAAL_LINK_PROFILE_NUM  
ATM_SAAL_LINK_TYPE  
Determines the ATM SAAL Link profile number  
The valid range is 0 to (MAX_SAAL_PROFILES-1). The default value is 0.  
Determines the ATM SAAL link Type PVC/SVC  
The valid range is ATM_VCC_TYPE_PVC to ATM_VCC_TYPE_SVC. The  
default value is ATM_VCC_TYPE_PVC.  
ATM_SAAL_LINK_PORT_NUM  
Determines the ATM SAAL link port num  
The valid range is 0 to ATMDB_ATM_MAX_INTERFACES_RANGE. The  
default value is 0.  
ATM_SAAL_LINK_VPI  
ATM_SAAL_LINK_VCI  
Determines the ATM SAAL link VPI  
The valid range is 0 to 255. The default value is 0.  
Determines the ATM SAAL link VCI  
The valid range is 0 to 0xFFFF. The default value is 0.  
SS7_LINK_TNL_MGC_LINK_NUMBER Determines the MTP2 Tunneling: MGC link number (MTP2 \other side\ of  
signaling link.  
The valid range is 0 to 7. The default value is 0.  
SS7_LINK_TNL_ALIGNMENT_MODE  
Determines the MTP2 Tunneling: Alignment mode of signaling links in  
tunnel.  
The valid range is 0 to 255. The default value is  
M3B_ALIGNMENT_EMERGENCY.  
SS7_LINK_TNL_CONGESTION_MODE Determines the MTP2 Tunneling: Congestion mode of signaling links in  
tunnel.  
The valid range is 0 to 255. The default value is  
M3B_CONGESTION_ACCEPT.  
SS7_LINK_TNL_WAIT_START_COMP Determines the MTP2 Tunneling Timer: wait start complete.  
LETE_TIMER  
SS7_LINK_TNL_OOS_START_DELAY Determines the MTP2 Tunneling Timer: OOS start delay.  
_TIMER  
The valid range is 500 to 0xFFFFFFFF. The default value is 5000.  
SS7_LINK_TNL_WAIT_OTHER_SIDE_I Determines the MTP2 Tunneling Timer: wait other side inservice.  
The valid range is 500 to 0xFFFFFFFF. The default value is 30000.  
NSV_TIMER  
The valid range is 500 to 0xFFFFFFFF. The default value is 30000.  
SS7_LINKSET_SN_INDEX  
Determines the first index field for line.  
The valid range is 0 to 1. The default value is 0.  
SS7_LINKSET_LINKSET_INDEX  
SS7_LINKSET_ROWSTATUS  
Determines the second index field for line.  
The valid range is 0 to 7. The default value is 0.  
Determines the RowStatusField for line.  
The valid range is acPARAMSET_ROWSTATUS_DOESNOTEXIST to  
acPARAMSET_ROWSTATUS_DESTROY. The default value is  
acPARAMSET_ROWSTATUS_DOESNOTEXIST.  
SS7_LINKSET_ACTION  
Determines the management field for actions.  
The valid range is acSS7LINKSET_PS_ACTION_NONE to  
acSS7LINKSET_PS_ACTION_DEACTIVATE. The default value is  
acSS7LINKSET_PS_ACTION_NONE.  
SS7_SN_ACTION_RESULT  
Determines the management field for actions result.  
The valid range is acPARAMSET_ACTION_RESULT_SUCCEEDED to  
acPARAMSET_ACTION_RESULT_FAILED. The default value is  
acPARAMSET_ACTION_RESULT_SUCCEEDED.  
J.5  
SS7 MTP2 Tunneling ini File Example  
For the SS7 MTP2 tunneling ini file example, note the following:  
The first ini file acts as an MTP2 tunneling central side (M2UA MGC links).  
Version 4.4  
237  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP  
There are 8 SS7 links - 4 links of type: MTP2 MGC, and 4 links of type MTP2. Each pair of  
links (1 MTP2 MGC and 1 MTP2) defines an MTP2 tunnel.  
There is 1 interface that is used for the M2UA MGC <=> M2UA SG (Signaling Gateway)  
connection.  
There are 4 interface IDs defined: 1 per link (M2UA MGC side).  
This file is intended for ITU link variant (E1 trunks).  
To load the example SS7 MTP2 tunneling ini files to Mediant 2000  
gateways, take these 3 steps:  
1. Load the ini file that is shown in Figure J-4 to a tunnel central gateway (MTP2 MGC). Load  
the ini file that is shown in Figure J-5 to a tunnel remote gateway (MTP2 SG); the MGC  
gateway connects (over IP) to the SG gateway. For information on loading an ini file to the  
gateway, refer to Section 6.2 on page 87.  
2. In the MGC gateway, change the parameter ‘SS7_DEST_IP’ to the actual IP address of the  
M2UA SG gateway.  
3. Change the value of the ‘SyslogServerIP’ parameter in the MGC and SG gateways to your  
Syslog server IP address.  
Figure J-4: SS7 MTP2 Tunneling ini File Example - MGC  
[TDM BUS configuration]  
; 1=aLaw 3=ulaw  
PCMLawSelect=  
1
;1 - internal, 3 - mvip, 4 - Network, 8 - h110a, 9 - h110b, 10 - Netref  
TDMBusClockSource= 1  
[Trunk Configuration]  
;e1_euro_isdn=1 t1_isdn=2 ;e1_cas_r2=8 (8 for fcd); e1_trans_62=5  
ProtocolType = 5  
TraceLevel  
= 0  
; acCLOCK_MASTER_ON =1  
CLOCKMASTER= 1  
;acUSER_TERMINATION_SIDE = 0  
TerminationSide = 1  
;acEXTENDED_SUPER_FRAME=0  
FramingMethod = 0  
;acB8ZS = 0  
LineCode = 0  
[SS7]  
2 for E1_CAS - FCD  
SS7_MTP2_PARAM_TIMER_T1_0=50000  
SS7_MTP2_PARAM_TIMER_T2_0=150000  
SS7_MTP2_PARAM_TIMER_T3_0=1000  
Mediant 2000 SIP User’s Manual  
238  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
Figure J-4: SS7 MTP2 Tunneling ini File Example - MGC  
SS7_MTP2_PARAM_TIMER_T4E_0=500  
SS7_MTP2_PARAM_TIMER_T4N_0=8200  
SS7_MTP2_PARAM_TIMER_T5_0=100  
SS7_MTP2_PARAM_TIMER_T6_0=3000  
SS7_MTP2_PARAM_TIMER_T7_0=2000  
[syslog]  
SYSLOGSERVERIP = 168.100.0.1  
ENABLESYSLOG = 1  
;FORCEEXCEPTIONDUMP = 1  
WATCHDOGSTATUS = 0  
[ SS7_LINK_TABLE ]  
FORMAT SS7_LINK_INDEX = SS7_LINK_NAME, SS7_LINK_TRACE_LEVEL,  
SS7_LINK_ADMINISTRATIVE_STATE,SS7_LINK_L2_TYPE, SS7_LINK_L3_TYPE, SS7_LINK_GROUP_ID,  
SS7_LINK_M2UA_IF_ID;  
SS7_LINK_TABLE 1 = new_link_1, 0, 2, 2, 3, 4, 50;  
SS7_LINK_TABLE 3 = new_link_3, 0, 2, 2, 3, 4, 12;  
SS7_LINK_TABLE 5 = new_link_5, 0, 2, 2, 3, 4, 18;  
SS7_LINK_TABLE 7 = new_link_7, 0, 2, 2, 3, 4, 1;  
[ \SS7_LINK_TABLE ]  
[ SS7_LINK_TABLE ]  
FORMAT SS7_LINK_INDEX = SS7_LINK_NAME, SS7_LINK_TRACE_LEVEL,  
SS7_LINK_ADMINISTRATIVE_STATE,SS7_LINK_L2_TYPE, SS7_LINK_L3_TYPE,  
SS7_LINK_TRUNK_NUMBER,SS7_LINK_TIMESLOT_NUMBER,  
SS7_LINK_LAYER2_VARIANT,SS7_LINK_MTP2_ATTRIBUTES,SS7_CONGESTION_LOW_M ARK,  
SS7_CONGESTION_HIGH_MARK, SS7_LINK_TNL_MGC_LINK_NUMBER, SS7_LINK_TNL_ALIGNMENT_MODE,  
SS7_LINK_TNL_CONGESTION_MODE, SS7_LINK_TNL_WAIT_START_COMPLETE_TIMER,  
SS7_LINK_TNL_OOS_START_DELAY_TIMER, SS7_LINK_TNL_WAIT_OTHER_SIDE_INSV_TIMER;  
SS7_LINK_TABLE 0 = new_link_0, 0, 2, 1, 3, 0, 15, 1, 0, 5, 50, 1, 1, 0, 30000, 5000, 30000;  
SS7_LINK_TABLE 2 = new_link_2, 0, 2, 1, 3, 3, 12, 1, 0, 5, 50, 3, 1, 0, 30000, 5000, 30000;  
SS7_LINK_TABLE 4 = new_link_4, 0, 2, 1, 3, 6, 7, 1, 0, 5, 50, 5, 1, 0, 30000, 5000, 30000;  
SS7_LINK_TABLE 6 = new_link_6, 0, 2, 1, 3, 7, 3, 1, 0, 5, 50, 7, 1, 0, 30000, 5000, 30000;  
[ \SS7_LINK_TABLE ]  
[ SS7_SIG_IF_GROUP_TABLE ]  
FORMAT SS7_SIG_IF_GR_INDEX = SS7_IF_GR_ID,SS7_SIG_SG_MGC, SS7_SIG_LAYER, SS7_SIG_TRAF_MODE,  
SS7_SIG_T_REC, SS7_SIG_T_ACK, SS7_SIG_T_HB, SS7_SIG_MIN_ASP, SS7_SIG_BEHAVIOUR,  
SS7_LOCAL_SCTP_PORT, SS7_SIG_NETWORK, SS7_DEST_SCTP_PORT, SS7_DEST_IP, SS7_MGC_MX_IN_STREAM,  
SS7_MGC_NUM_OUT_STREAM;  
Version 4.4  
239  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Figure J-4: SS7 MTP2 Tunneling ini File Example - MGC  
SS7_SIG_IF_GROUP_TABLE 4 = 4, 77, 4, 1, 2000, 2000, 30000, 1, 0, 2904, 1,2904,168.100.0.2,3,3;  
[ \SS7_SIG_IF_GROUP_TABLE ]  
[ SS7_SIG_INT_ID_TABLE ]  
FORMAT SS7_SIG_IF_ID_INDEX = SS7_SIG_IF_ID_VALUE, SS7_SIG_IF_ID_NAME, SS7_SIG_IF_ID_OWNER_GROUP,  
SS7_SIG_IF_ID_LAYER, SS7_SIG_IF_ID_NAI, SS7_SIG_M3UA_SPC;  
SS7_SIG_INT_ID_TABLE 7 = 50, BELFAST12, 4, 2, 1, 0;  
SS7_SIG_INT_ID_TABLE 8 = 12, AMSTERDAM, 4, 2, 3, 0;  
SS7_SIG_INT_ID_TABLE 9 = 18, ROTERDAM , 4, 2, 5, 0;  
SS7_SIG_INT_ID_TABLE 10 = 1, GAUDA  
[ \SS7_SIG_INT_ID_TABLE ]  
, 4, 2, 7, 0;  
Figure J-5: SS7 MTP2 Tunneling ini File Example - SG  
[TDM BUS configuration]  
; 1=aLaw 3=ulaw  
PCMLawSelect=  
1
;1 - internal, 3 - mvip, 4 - Network, 8 - h110a, 9 - h110b, 10 - Netref  
TDMBusClockSource= 1  
[Trunk Configuration]  
;e1_euro_isdn=1 t1_isdn=2 ;e1_cas_r2=8 (8 for fcd); e1_trans_62=5  
ProtocolType = 5  
TraceLevel  
= 0  
; acCLOCK_MASTER_ON =1  
ClockMaster= 1  
TerminationSide = 1  
;acEXTENDED_SUPER_FRAME=0  
FramingMethod = 0  
;acB8ZS = 0  
2 for E1_CAS - FCD  
LineCode = 0  
WATCHDOGSTATUS = 0  
[ SS7_LINK_TABLE ]  
FORMAT SS7_LINK_INDEX = SS7_LINK_NAME, SS7_LINK_TRACE_LEVEL,  
SS7_LINK_ADMINISTRATIVE_STATE,SS7_LINK_L2_TYPE, SS7_LINK_L3_TYPE,  
SS7_LINK_TRUNK_NUMBER,SS7_LINK_TIMESLOT_NUMBER,SS7_LINK_M2UA_IF_ID;  
SS7_LINK_TABLE 0 = new_link_0, 0, 2, 1,1, 1, 15,50;  
Mediant 2000 SIP User’s Manual  
240  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
Figure J-5: SS7 MTP2 Tunneling ini File Example - SG  
SS7_LINK_TABLE 1 = new_link_1, 0, 2, 1,1, 2, 12, 12;  
SS7_LINK_TABLE 2 = new_link_2, 0, 2, 1, 1, 4, 7,18;  
SS7_LINK_TABLE 3 = new_link_3, 0, 2, 1, 1, 5, 3,1;  
[\SS7_LINK_TABLE]  
[ SS7_SIG_IF_GROUP_TABLE ]  
FORMAT SS7_SIG_IF_GR_INDEX = SS7_IF_GR_ID,SS7_SIG_SG_MGC, SS7_SIG_LAYER, SS7_SIG_TRAF_MODE,  
SS7_SIG_T_REC, SS7_SIG_T_ACK, SS7_SIG_T_HB, SS7_SIG_MIN_ASP, SS7_SIG_BEHAVIOUR,  
SS7_LOCAL_SCTP_PORT, SS7_SIG_NETWORK;  
SS7_SIG_IF_GROUP_TABLE 4 = 4,83, 2, 1, 2000, 2000, 30000, 1, 0, 2904, 1;  
[ \SS7_SIG_IF_GROUP_TABLE ]  
[ SS7_SIG_INT_ID_TABLE ]  
FORMAT SS7_SIG_IF_ID_INDEX = SS7_SIG_IF_ID_VALUE, SS7_SIG_IF_ID_NAME, SS7_SIG_IF_ID_OWNER_GROUP,  
SS7_SIG_IF_ID_LAYER, SS7_SIG_IF_ID_NAI, SS7_SIG_M3UA_SPC;  
SS7_SIG_INT_ID_TABLE 7 = 50, BELFAST12, 4, 2, 0, 0;  
SS7_SIG_INT_ID_TABLE 8 = 12, AMSTERDAM, 4, 2, 1, 0;  
SS7_SIG_INT_ID_TABLE 9 = 18, ROTERDAM , 4, 2, 2, 0;  
SS7_SIG_INT_ID_TABLE 10 = 1, GAUDA  
[ \SS7_SIG_INT_ID_TABLE ]  
, 4, 2, 3, 0;  
J.6 ini File Parameters in a Table Format  
Tables of Parameter Values group related parameters of a specific entity and handle them  
together. Tables are composed of lines and columns. The columns represent parameters types,  
while each line represents an entity. The parameters in each line are called the line attributes.  
Lines in table may represent (for example) a trunk, SS7 Link, list of timers for a given application,  
etc.  
Table J-5 and Table J-6 below provide useful examples for reference.  
Note:  
Table J-5 and Table J-6 are provided as examples for the purpose of  
illustration only and are NOT actually implemented in AudioCodes products.  
Version 4.4  
241  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Table J-5: Table of Parameter Values Example - Remote Management Connections  
Index Fields:  
1. Connection Number  
Connection  
Number  
User Name  
User Password  
Time Connected (msec)  
Permissions  
0
1
Admin  
Gillian  
David  
Yellow9  
Red5  
0
1266656  
0
All  
Read Only  
Read Write  
2
Orange6  
Table J-6: Table of Parameter Values Example - Port-to-Port Connections  
Index Fields:  
1. Source Ports  
2. Destination IP  
3. Destination Port  
Source Port  
2020  
Destination IP  
10.4.1.50  
Destination Port  
Connection Name  
ATM_TEST_EQ  
Application Type  
LAB_EQ  
2020  
4050  
6010  
2314  
212.199.201.20  
10.3.3.41  
ATM_ITROP_LOOP  
REMOTE_MGMT  
LAB_EQ  
6010  
MGMT  
J.6.1 Table Indices  
Each line in a table must be unique. For this reason, each table defines one or more Index fields.  
The combination of the Index fields determines the 'line-tag'. Each line-tag may appear only once.  
In the example provided in Table J-5, there is only one index field. This is the simplest way to  
mark lines.  
In the example provided in Table J-6, there are three Index fields. This more complicated method  
is a result of the application it represents.  
J.6.2 Table Permissions  
Each field in a line has a 'permission' attribute, which determines if and when the user may  
modify the field.  
There are several types of permissions:  
Read - The user may read the value of a field (true for all fields).  
Write - The user may modify the value of the field at any time.  
Create - The user must provide a value for the field at creation time.  
The default values set for all fields already determine the initial values.  
Maintenance write - The user may modify the value of the field only when the entity  
represented by the line is in maintenance state.  
Each table includes rules to determine when it is in a maintenance state.  
In the example in Table J-5, ‘User Name’ and ‘User Password’ fields have Read-Create  
permissions. The ‘Time Connected’ field has Read-Only permission, and the ‘Permissions’ field  
has a Read-Create-Maintenance_write permission.  
Mediant 2000 SIP User’s Manual  
242  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
J. SS7 Tunneling  
J.6.3 Tables of Parameter Value Rules in the ini File Structure  
The ini file allows you to add/modify parameters in tables. When using tables, Read-Only  
parameters are not loaded, since they cause an error when trying to download the loaded file.  
Therefore read-only parameters should not be included in tables in the ini file. Consequently,  
tables are loaded with all parameters having at least one of the following permissions:  
Write  
Create  
Maintenance write  
The ‘format-line’ rule defines which fields of the table are to be modified by the given ini file (this  
may vary among ini files for the same table). The ‘format-line’ must only include fields, which can  
be modified (which are all parameters that are not specified as read-only).  
One exception is the index-fields, which are ALWAYS mandatory fields. In the example provided  
in Table J-5, all fields except the ‘Time Connected’ field are loaded.  
J.6.3.1 Tables Structure Rules  
Tables are composed of four elements:  
Table-Title - The Table's string name in square brackets (e.g. [ MY_TABLE_NAME ]).  
Format Line - This line specifies the table's fields by their string names.  
The first word MUST be "FORMAT", followed by indices field names, and after '=' sign,  
all data fields names should be listed.  
Items must be separated by ',' sign.  
The Format Line must end with ';' sign.  
Data Line(s) - The actual values for parameters are specified in each Data line. The values  
are interpreted according to the format line. The first word must be the table’s string name.  
Items must be separated by a ',' sign.  
A Data Line must end with a ';' sign.  
End-of-Table-Mark: Marks the end of a table. Same as Table title, but string name is  
preceded by '\'.  
Figure J-6 displays an example of the Table structure in an ini file.  
Figure J-6: Structure of a Table in an ini File  
; Table: Items Table.  
; Fields: Item_Name, Item_Serial_Number, Item_Color, Item_weight.  
; NOTE: Item_Color is not specified. It will be given default value.  
[Items_Table]  
; Fields declaration  
Format Item_Index = Item_Name, Item_Serial_Number, Item_weight;  
Items_Table 0 = Computer, 678678, 6;  
Items_Table 6 = Computer-screen, 127979, 9;  
Items_Table 2 = Computer-pad, 111111, $$;  
[\Items_Table]  
Indices (in both the Format line and the Data lines) must all appear in order, as determined  
by the table's specific documentation. The Index field must NOT be omitted.  
Data fields in the Format line may use a sub-set of all of the configurable fields in a table  
only. In this case, all other fields are assigned with the pre-defined default value for each  
configured line.  
Version 4.4  
243  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
The order of the Data fields in the Format line is not significant (unlike the Index-fields). Field  
values in Data lines are interpreted according to the order specified in the Format line.  
The sign '$$' in the Data line means that the user wants the pre-defined default value  
assigned to the field for the given line.  
The order of Data lines is insignificant.  
Data lines must match the Format line, i.e., it must contain exactly the same number of  
Indices and Data fields and should be in exactly the same order.  
A line in a table is identified by its table-name and its indices. Each such line may appear  
only once in the ini file.  
Tables' dependencies:  
Certain tables may depend on other tables. For example, one table may include a field, which  
specifies an entry in another table, to specify additional attributes of an entity, or to specify that a  
given entity is part of a larger entity. The tables must appear in order of dependency (i.e., if Table  
X is referred to by Table Y, then Table X must appear in the ini file before Table Y).  
J.6.3.2 Dynamic Tables versus Static Tables  
Static Table:  
The Static table type does not support adding new lines or removing (deleting) an existing line. All  
lines in a Static table are pre-configured with default values. Users may modify values in existing  
lines. After reset, all lines in a Static table are available.  
Dynamic Table:  
The Dynamic table type supports adding and removing lines. It is always initialized as an empty  
table, with no lines. Users should add lines to the Dynamic table via the ini file or at run-time.  
Note:  
Certain dynamic tables may initialize a line (or more) at start-up time. If so, it  
is documented in the table's specific section.  
J.6.3.3 Tables in the Loaded ini File  
Tables are grouped according to the applications they configure. For example, several tables are  
required to configure SS7, and other tables are required to configure ATM.  
When loading the ini file, the policy is to include only tables that belong to applications, which  
have been configured (Dynamic tables of other applications are empty, but static tables are not).  
Mediant 2000 SIP User’s Manual  
244  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Appendix K RADIUS Billing and VXML Calling  
Card Application  
The Mediant 2000 calling card application capability (included in its IVR - Interactive Voice  
Response - feature) enables Internet Telephony Service Providers (ITSPs) to provide a VoIP  
telephone service to subscribers who have purchased calling cards in advance.  
The subscriber market for calling cards is growing exponentially worldwide. Calling cards are  
often much cheaper than collect calls and operator-assisted calls made through long distance  
providers and local phone companies. VoIP service providers, using the Mediant 2000, can  
further reduce costs for calling card subscribers and substantially reduce implementation time,  
making the service extraordinarily attractive both for them and their subscribers.  
K.1 Benefits  
Using the Mediant 2000, telephony service providers can offer the calling card service over a  
VoIP network and thereby:  
Lower the cost and deployment time that a PSTN calling-card service requires  
Achieve voice quality comparable to toll quality  
Acquire a cost-effective, reliable VoIP network infrastructure  
IVR functionality can be located at the edge of the network (distributed functionality) or in a  
central location  
Connect with the PSTN over carrier interfaces  
Interoperate with other VoIP service providers and other vendors' VoIP equipment  
Become part of a world-wide network of other VoIP service providers interested in  
interconnecting  
K.2 Features  
PSTNIP and IPPSTN distributed IVR architecture  
AAA (Authentication, Authorization, Accounting) over standard RADIUS (Remote  
Authentication Dial In User Service) - stored on a RADIUS server  
Provides comprehensive management of accounting and billing support  
CDRs (Call Detail Reports) over RADIUS (stored on a RADIUS server)  
Post-paid applications (Billing model: credit)  
Pre-paid application (Billing model: debit). When credit is exhausted the call is disconnected  
(a short Prompt is played prior to disconnection)  
Common internal, on-board, Voice Prompts (in flash memory) for all VoiceXML (Voice  
Extensible Markup Language) scripts  
Multiple VXML scripts stored on external HTTP server (up to 10 different scripts)  
Caller can place multiple successive calls without re-entering the account and password  
numbers (authentication and authorization are applied without collecting the information from  
the user again)  
Supports Cisco gateway RADIUS functionality  
Interoperates with standard RADIUS-based (AAA) billing servers  
Supports 240 concurrent calls running a VXML script  
Version 4.4  
245  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Loads the VXML scripts once and stores them in the RAM; scripts can be changed without  
the need of reset  
Barge-in dialing (to shorten menu time), once prompt has started  
K.3 Supported Architecture  
Figure K-1: Mediant 2000 Supported Architecture  
Figure K-1 illustrates standard Calling Card IVR application architecture. The figure depicts in  
general terms an incoming PSTNIP call being conveyed to the IP network.  
The architecture comprises the following components:  
Mediant 2000 - The PSTN gateway that includes the VoiceXML interpreter which generates  
events in response to user actions (e.g., spoken or character input received, disconnect) and  
system events (e.g., timer expiration). These events are acted on by the VoiceXML  
interpreter itself, as specified by the VoiceXML document.  
HTTP Server – (Document Server), sends out the VoiceXML script in response to the  
Mediant 2000 (the VoiceXML interpreter) request.  
RADIUS Server – A centralized Authentication, Authorization and Accounting server for  
remote access users that communicate via the RADIUS protocol.  
VoiceBrowser - (not shown in this diagram), responsible for the TTS (Text to Speech) and  
ASR (Automatic Speech Recognition) services (not supported in this version).  
Proxy Server – Standard management tool for SIP networks. Performs essential control,  
administrative and managerial functions.  
MediaPack – Analog media gateway, provides excellent voice quality and optimized packet  
voice, fax and modem streaming over the IP network.  
Mediant 2000 SIP User’s Manual  
246  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
K.4 Implementation  
The Mediant 2000 uses an embedded VoiceXML interpreter to interpret and execute standard  
VoiceXML scripts, which are loaded from an outbound HTTP server and stored in the gateway’s  
volatile memory (RAM). The predefined VoiceXML scripts (up to 10 different scripts are  
supported) determine the development of the call according to the caller’s responses (DTMF  
digits) and AAA (Authentication, Authorization and Accounting) information exchanged with a  
RADIUS server. Interaction with the caller is conducted using a set of audio messages (stored in  
a single Voice Prompts file in the gateway’s flash/RAM memory) on the gateway’s side, and by  
pressing DTMF digits on the subscriber’s side.  
K.4.1 Basic Calling Card IVR Scenario  
Figure K-2: Basic Call Scenario  
Note:  
Some messages have been omitted from the above drawing for the sake of  
clarity.  
Version 4.4  
247  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
K.4.2 Call Flow Description  
Figure K-2 on the previous page depicts an example of a standard PSTNIP call (billing-model:  
debit).  
An incoming PSTN call with a published access number reaches the Mediant 2000.  
The Mediant 2000 accepts the call (sends an Alert message).  
The Mediant 2000 searches its internal TelIP Destination Number Manipulation table for  
the specific prefix. When it is detected, if the ‘Prefix to Add’ column corresponds to the  
predefined VXMLID parameter (in the example below: http), the Mediant 2000 determines  
that the incoming call is an IVR call.  
Figure K-3: Basic ini File VXML Parameters  
VXMLID = http  
NumberMapTel2IP = 5394288,7,http://10.8.1.19/RadAAA01.txt  
The Mediant 2000 loads the VoiceXML file (RadAAA01.txt) from an outbound HTTP Server  
(10.8.1.19) and stores it in its volatile memory. In Figure K-2 it is assumed that the VoiceXML  
already resides in the Mediant 2000.  
The Mediant 2000 sends an Answer/Connect message.  
Note:  
The following steps are according to the supplied VXML script.  
The Mediant 2000 starts by playing an initial voice message. This message is composed of  
an opening greeting and an interactive menu asking the caller to choose one of the following  
options: 1 to make a call, 2 for help, 3 for operator service, 4 to exit.  
After pressing the digit 1, the caller is immediately prompted to enter his account number  
(usually the card number) and his password or PIN (personal identification number). The  
Mediant 2000 collects the input DTMF digits and sends an Authentication message to an  
outbound RADIUS server.  
Only after the call is authenticated successfully (in this stage the RADIUS server returns the  
billing-model, in the above example: debit), the caller is asked to enter the number he wishes  
to reach, the final destination number. The gateway collects the input DTMF digits and sends  
an Authorization message to the RADIUS server.  
The RADIUS server determines if the caller is authorized to proceed with the call and  
specifies the maximum duration of the call; the Mediant 2000 conveys the call to the IP  
network and starts an internal timer.  
One minute before credit is exhausted (refer to the VXML parameter finalalerttime on page  
260); the finalalertaudio is played; finally, a minute later, the call is disconnected and the  
After the conclusion of the call, the Mediant 2000 sends an Accounting message to the  
RADIUS server containing the call details (CDR) and prompts the user either to proceed with  
another call or to disconnect.  
Mediant 2000 SIP User’s Manual  
248  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
K.5 Operation & Configuration  
To start working with the IVR system, take these 6 steps:  
1. Install the Mediant 2000 (refer to Section Installing the Mediant 2000 on page 27 and to  
Section Getting Started on page 35).  
2. Create and load a Voice Prompts file to the Mediant 2000 (refer to Section 7.3 on page 137).  
3. Create the VXML scripts (refer to Section K.9 on page 254).  
4. Install an HTTP Server, store the VXML scripts in it and provision the Mediant 2000 relevant  
VoiceXML parameters.  
5. In the Mediant 2000 Destination Manipulation tables, (PSTNIP and IPPSTN) convert the  
predefined number to the HTTP server IP address and the VXML file name.  
Assuming that the incoming number is 5394288, the IP address of the HTTP server is  
10.8.1.19 and the name of the VXML file is RadAAA01.txt, then the ini file entry should look  
like: NumberMapTel2IP = 5394288,7,http://10.8.1.19/RadAAA01.txt. For the Mediant 2000 to  
identify that the incoming call is designated to the IVR system, assign the string “http” to the  
VXMLID parameter (refer to Table K-1 on page 249 for extended provisioning information).  
Note:  
To change a VXML script on-the-fly, access the Destination Number  
Manipulation table via the Embedded Web Server and replace the name of  
the file with the name of the new script (existing calls continue to run on the  
old script, while new calls run on the new script).  
6. Install a RADIUS server, define the Mediant 2000 in it (specify a common ‘SharedSecret’  
parameter) and configure the Mediant 2000 relevant RADIUS parameters (refer to K.9 on  
page 254).  
You are now ready to start using the Calling Card Application.  
K.6 Configuration Parameters  
Table K-1: General Mediant 2000 Parameters  
ini File Field Name  
Valid Range and Description  
IVR Reference  
NumberMapTel2IP  
Manipulates the destination number for Tel to IP calls.  
NumberMapTel2IP = a,b,c,d,e,f,g  
Replaces the incoming  
destination number with a URL  
that indicates where the VXML  
script is located.  
a
b
= Destination number prefix  
= Number of stripped digits from the left, or (if  
brackets are used) from the right. A combination of both  
options is allowed.  
a = Calling Card number  
b = The length of the Calling  
c
= String to add as prefix, or (if brackets are used) Card number  
as suffix. A combination of both options is allowed.  
c = http://<HTTP server IP> + /  
+ <name of VXML file>  
(maximum length of string is 50  
characters)  
d
e
f
= Number of remaining digits from the right  
= Number Plan used in RPID header  
= Number Type used in RPID header  
= Source number prefix  
g
Note: To update the VoiceXML  
file, change the name of the file  
in the ‘c’ field.  
The ‘b’ to ‘f’ manipulations rules are applied if the called  
and calling numbers match the ‘a’ and ‘g’ conditions.  
The manipulation rules are executed in the following  
order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for  
example:  
NumberMapTel2IP=2222,4,http://10.3.0.2/AAIP.txt  
Version 4.4  
249  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
IVR Reference  
ini File Field Name  
Valid Range and Description  
NumberMapIP2Tel  
Manipulate the destination number for IP to Tel calls.  
NumberMapIP2Tel = a,b,c,d,e,f,g,h,i  
Replaces the incoming  
destination number with a URL  
that indicates where the VXML  
script is located.  
a
b
= Destination number prefix  
= Number of stripped digits from the left, or (if  
brackets are used) from the right. A combination of both  
options is allowed.  
a = Calling Card number  
b = The length of the Calling  
c
= String to add as prefix, or (if brackets are used) Card number  
as suffix. A combination of both options is allowed.  
c = http://<HTTP server IP> + /  
+ <name of VXML file>  
(maximum length of string is 50  
characters)  
d
e
f
= Number of remaining digits from the right  
= Q.931 Number Plan  
= Q.931 Number Type  
g
h
i
= Source number prefix  
= Not applicable, set to $$  
= Source IP address  
Note: To update the VoiceXML  
file, change the name of the file  
in the ‘c’ field.  
The ‘b’ to ‘f’ manipulation rules are applied if the called  
and calling numbers match the ‘a’, ‘g’ and ‘i’ conditions.  
The manipulation rules are executed in the following  
order: ‘b’, ‘d’ and ‘c’.  
Parameters can be skipped by using the sign "$$", for  
example:  
NumberMapIP2Tel =2222,4,http://10.3.0.2/AAIP.txt  
Note: The Source IP address can include the “x” wildcard  
to represent single digits. For example: 10.8.8.xx  
represents all the addresses between 10.8.8.10 to  
10.8.8.99.  
VoicePromptsFileNam The name (and path) of the file containing the Voice  
e
Prompts definitions.  
SaveConfiguration  
Set to 1 to store the Voice Prompts file in the non-volatile  
memory (file size mustn’t exceed 1Mb).  
EnableVoiceStreaming  
Set to 1 to enable the load of  
the VoiceXML file from the  
HTTP server.  
0 = Disable voice streaming (default).  
1 = Enable voice streaming.  
Table K-2: VoiceXML Related Parameters  
ini File Field Name  
Valid Range and Description  
EnableVxml  
0 = Disable the VXML feature (default).  
[Enable VXML]  
1 = Enable the VXML feature.  
VxmlID  
[VXML ID]  
According to this string, the Mediant 2000 recognizes that an incoming call is to be diverted  
to the IVR system.  
Note: Set to “http” (the “http” string must also appear in the manipulation table).  
VxmlCollectDigits  
Determines the destination to which the VXML script reports the collected number  
(username).  
0 = The collected number (username) is sent for authentication to the RADIUS server  
(default).  
1 = The collected number is sent (in INFO message) to an Application / Proxy server.  
The following RADIUS related parameters are described in Table 6-1 on page 90:  
EnableRADIUS  
MaxRADIUSSessions  
SharedSecret  
RADIUSRetransmission  
RADIUSTo  
Mediant 2000 SIP User’s Manual  
250  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
RADIUSAuthServerIP  
RADIUSAuthPort  
RADIUSAccServerIP  
RADIUSAccPort  
AAAIndications  
RADIUSAccountingType  
K.7 Supported RADIUS Attributes  
Use Table K-3 below for explanations on the RADIUS attributes contained in the communication  
packets transmitted between the Mediant 2000 and a RADIUS Server.  
Table K-3: Supported RADIUS Attributes (continues on pages 251 to 252)  
Attribute  
Number  
VSA  
No.  
Value  
Format  
Attribute Name  
Purpose  
Sample  
AAA  
Request Attributes  
Start Acc  
Stop Acc  
Authe  
String up to  
15 digits  
long  
Account number or calling  
party number or blank  
1
2
4
User-Name  
5421385747  
Autho  
Up to 15  
digits  
User-Password  
NAS-IP-Address  
Service-Type  
User password  
Autho  
Start Acc  
Stop Acc  
Authe  
IP address of the requesting  
Mediant 2000  
192.168.14.4  
3
Numeric  
Autho  
Start Acc  
Stop Acc  
6
Numeric  
Type of service requested  
H.323/SIP call identifier  
1: login  
Up to 32  
octets  
h323-incoming-  
conf-id  
Start Acc  
Stop Acc  
26  
26  
1
h323-remote-  
address  
IP address of the remote  
gateway  
23  
Numeric  
Stop Acc  
Start Acc  
Stop Acc  
Authe  
Up to 32  
octets  
26  
24  
h323-conf-id  
H.323/SIP call identifier  
Autho  
Start Acc  
Stop Acc  
26  
26  
25  
26  
String  
String  
h323-setup-time  
h323-call-origin  
h323-call-type  
Setup time in NTP format 1  
The call’s originator:  
Answering (IP) or Originator  
(PSTN)  
Answer,  
Originate etc  
Start Acc  
Stop Acc  
Protocol type or family used  
on this leg of the call  
Start Acc  
Stop Acc  
26  
26  
26  
26  
27  
28  
29  
30  
String  
String  
VoIP  
h323-connect-  
time  
Connect time in NTP format  
Stop Acc  
Stop Acc  
Stop Acc  
h323-disconnect-  
time  
Disconnect time in NTP  
format  
String  
h323-disconnect-  
cause  
Q.931 disconnect cause  
code  
Numeric  
2 The values in column ‘AAA’ are as follows:  
’Start Acc’ -  
’Stop Acc’ -  
’Authe’ -  
Start Accounting  
Stop Accounting  
Authentication  
Authorization  
’Autho’ -  
Version 4.4  
251  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Table K-3: Supported RADIUS Attributes (continues on pages 251 to 252)  
2
Attribute  
Number  
VSA  
No.  
Value  
Format  
Attribute Name  
Purpose  
Sample  
AAA  
Start Acc  
Stop Acc  
26  
33  
String  
String  
String  
h323-gw-id  
Name of the gateway  
SIPIDString  
8004567145  
2427456425  
Start Acc  
30  
Called-Station-Id  
Calling-Station-Id  
Stop Acc  
Autho  
Destination phone number  
Calling Party Number (ANI)  
Start Acc  
Stop Acc  
Authe  
31  
String  
5135672127  
Autho  
Account Request Type  
(start or stop)  
1: start, 2:  
stop  
Start Acc  
Stop Acc  
40  
41  
42  
43  
Numeric  
Numeric  
Numeric  
Numeric  
Acct-Status-Type  
Acct-Delay-Time  
Acct-Input-Octets  
No. of seconds tried in  
sending a particular record  
Start Acc  
Stop Acc  
5
Number of octets received  
for that call duration  
Stop Acc  
Stop Acc  
Acct-Output-  
Octets  
Number of octets sent for  
that call duration  
A unique accounting  
identifier - match start &  
stop  
Start Acc  
Stop Acc  
44  
String  
Acct-Session-Id  
34832  
Acct-Session-  
Time  
For how many seconds the  
user received the service  
46  
47  
48  
Numeric  
Numeric  
Numeric  
Stop Acc  
Stop Acc  
Stop Acc  
Acct-Input-  
Packets  
Number of packets received  
during the call  
Acct-Output-  
Packets  
Number of packets sent  
during the call  
Start Acc  
Stop Acc  
Authe  
Mediant 2000 physical port  
type on which the call is  
active  
0:  
61  
String  
NAS-Port-Type  
Asynchronou  
s
Autho  
Response Attributes  
Number of seconds for  
which the call is authorized  
26  
26  
26  
44  
102  
103  
109  
Numeric  
Numeric  
Numeric  
String  
h323-crdit-time  
360  
Autho  
The reason for failing  
authentication (0 = ok, other  
number failed)  
Authe  
Autho  
Stop Acc  
0 Request  
accepted  
h323-return-code  
h323-billing-model  
Acct-Session-Id  
Type of billing service for a  
specific call  
1:debit/prepai  
d
Authe  
A unique accounting  
identifier – match start &  
stop  
Stop Acc  
Mediant 2000 SIP User’s Manual  
252  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
K.8 RADIUS Server Messages  
Note:  
In Figure K-4, Figure K-5 and Figure K-6 non-standard parameters are  
preceded with brackets.  
K.8.1 Authentication  
Figure K-4: Authentication Example  
Access-Request (116)  
user-name = 111  
user-password = (encrypted)  
nas-ip-address = 212.179.22.213  
nas-port-type = 0  
calling-station-id = 202  
// Authentication non-standard parameters:  
(4923 24) h323-conf-id = 02102944 600a1899 3fd61009 0e2f3cc5  
In the Access-Accept response, the RADIUS server sends the billing model:  
(4923 109) h323-billing-model = 1/0  
The billing model is a non-standard parameter and can be one of the following:  
1 = credit (prepaid)  
0 = debit (postpaid)  
When a billing model isn’t received, the Mediant 2000 assumes a prepaid billing model (1).  
12.1.1 Authorization  
Figure K-5: Authorization Example  
Access-Request (121)  
user-name = 111  
user-password = (encrypted)  
nas-ip-address = 212.179.22.213  
nas-port-type = 0  
called-station-id = 201  
calling-station-id = 202  
// Authorization non-standard parameters:  
(4923 24) h323-conf-id = 02102944 600a1899 3fd61009 0e2f3cc5  
In the Access-Accept response, the RADIUS server sends the credit time:  
(4923 102) h323-credit-time = 6000  
The credit-time is a non-standard parameter which is measured in seconds.  
Version 4.4  
253  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
12.1.2 Accounting  
Figure K-6: Accounting Example  
Accounting-Request (361)  
user-name = 111  
acct-session-id = 1  
nas-ip-address = 212.179.22.213  
nas-port-type = 0  
acct-status-type = 2  
acct-input-octets = 4841  
acct-output-octets = 8800  
acct-session-time = 1  
acct-input-packets = 122  
acct-output-packets = 220  
called-station-id = 201  
calling-station-id = 202  
// Accounting non-standard parameters:  
(4923 33) h323-gw-id =  
(4923 23) h323-remote-address = 212.179.22.214  
(4923 1) h323-ivr-out = h323-incoming-conf-id:02102944 600a1899  
3fd61009 0e2f3cc5  
(4923 30) h323-disconnect-cause = 22 (0x16)  
(4923 27) h323-call-type = VOIP  
(4923 26) h323-call-origin = Originate  
(4923 24) h323-conf-id = 02102944 600a1899 3fd61009 0e2f3cc5  
K.9 Voice XML Interpreter  
VoiceXML (Voice Extensible Markup Language) is designed for creating audio dialogs that  
feature synthesized speech, digitized audio, recognition of speech and DTMF inputs, recording of  
spoken input, telephony, and mixed initiative conversations. Its major goal is to bring the  
advantages of Web-based development and content delivery to interactive voice response  
applications.  
K.9.1 Features  
Supports DTMF recognition.  
Executes audio dialogs between the gateway and a user, supporting mixed initiative  
applications.  
Audio prompt recording (currently not supported).  
Transfer Support - Using the <Transfer> element, the Mediant 2000 places a call to different  
destinations.  
JavaScript Expression Support - Supports ECMA script specification 3.0 (standard ECMA-  
262).  
Supports definition of the end-dial key (‘*’ or ‘#’) that terminates the DTMF collection.  
To define whether * or # are used to terminate the DTMF collection, add the following line to  
each script:  
<property name="EndDialKey" value="*">,  
OR  
<property name="EndDialKey" value="#">  
Supports number concatenation, enabling number modification per VXML script.  
<filled>  
<assign name="user_passwd" expr="'domain'+user_passwd + '.com'"/>  
<return namelist="user_account_num user_passwd"/>  
</filled>  
Mediant 2000 SIP User’s Manual  
254  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
The user_passwd parameter (that initially contained the user password collected from the user) is  
being assigned the value ‘domain'+user_passwd + '.com’.  
Calling number (recived form SIP incoming call) can optionally be used for authentication  
instead of the user name.  
form id="GetCallerId">  
<log label="VXML--> getting caller id from SIP..." />  
<object name="FCallerId" classid="builtin://com.audiocodes.ulp.input">  
<filled>  
<if cond="FCallerId.Result != 'fail'">  
<assign name="CallerId" expr="FCallerId.Result" />  
<goto next="#PerformAuthenWithoutUserName" />  
<else />  
<goto next="#PerformAuthen" />  
</if>  
</filled>  
</object>  
</form>  
Version 4.4  
255  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
K.10 Supported Elements & Attributes  
Table K-4: VoiceXML Supported Elements & Attributes (continues on pages 256 to 260)  
Element  
Element’s  
Description  
Parameter  
s
Parameter’s Description  
Supported  
<assign> Assign value to  
name  
expr  
expr  
The name of the modified variable  
The new value of the variable.  
variable  
<audio>  
<block>  
Plays an audio clip  
within a prompt  
Dynamically determines the URI to fetch by  
evaluating this ECMAScript expression.  
A container of (non-  
interactive)  
executable code  
<catch>  
Catch an event  
event  
count  
The event or events to catch.  
The occurrence of the event (default 1).  
An expression which must evaluate to true after  
conversion to Boolean in order for the event to be  
caught, (defaults true).  
cond  
<choice> Defines a menu item dtmf  
accept  
The DTMF sequence for this choice.  
Override the setting for accept in <menu> for this  
particular choice.  
next  
expr  
URI of the next dialog or doc.  
Specifies an expression to evaluate as a URI to  
transition to instead of specifying a next.  
Specify an event to be thrown instead of specifying a  
next.  
event  
An ECMAScript expression evaluating to the name of  
the event to be thrown.  
eventexpr  
message  
A message string providing additional context about  
the event being thrown.  
messageex An ECMAScript expression evaluating to the  
pr  
message string.  
<clear>  
Clear one or more  
form item variables  
namelist  
The list of variables to be reset.  
<disconnect>  
<else>  
Disconnect a session  
Used in <if>  
elements  
<elseif>  
<error>  
Used in <if>  
elements  
Catch an error event count  
The event count  
An optional condition to test to see if the event is  
caught by this element. Defaults to true.  
cond  
<exit>  
Exit a session  
expr  
A return expression.  
namelist  
Variable names to be returned to interpreter context.  
<field>  
Declares an input  
field in a form  
The form item variable in the dialog scope that holds  
the result.  
name  
expr  
The initial value of the form item variable;  
An expression that must evaluate to true after  
conversion to Boolean in order for the form item to be  
visited.  
cond  
type  
slot  
The type of field.  
The name of the grammar slot used to populate the  
variable. (Not Supported)  
Mediant 2000 SIP User’s Manual  
256  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Table K-4: VoiceXML Supported Elements & Attributes (continues on pages 256 to 260)  
Element  
Element’s  
Description  
Parameter  
s
Parameter’s Description  
Supported  
If this is false (the default) all active grammars are  
turned on while collecting this field.  
modal  
<filled>  
<form>  
An action executed  
when fields are filled  
mode  
namelist  
id  
Either all (the default), or any.  
The input items to trigger on.  
The name of the form.  
A dialog for  
presenting  
information and  
collecting data  
scope  
The default scope of the form’s grammars.  
<goto>  
Go to another dialog next  
The URI to which to transition.  
in the same or  
different document  
expr  
An ECMAScript expression that yields the URI.  
The name of the next form item to visit in the current  
form.  
nextitem  
version  
<grammar> Specify a speech  
recognition or DTMF  
grammar  
Defines the version of the grammar. (Not  
Supported)  
The language identifier of the contained or  
referenced grammar. (Not Supported)  
xml:lang  
Defines the mode of the contained or referenced  
grammar following the modes of the W3C Speech  
Recognition Grammar Specification [SRGS]. Defined  
values are "voice" and "dtmf" for DTMF input. (Not  
Supported)  
mode  
Defines the public rule which acts as the root rule of  
the grammar.  
root  
Defines the tag content format for all tags within the ꢂ  
tag-format  
base  
grammar. (Not Supported)  
Declares the base URI from which relative URIs are  
resolved. (Not Supported)  
The URI specifying the location of the grammar and  
optionally a rulename within that grammar, if it is  
external.  
src  
Either "document", which makes the grammar active  
in all dialogs of the current document or "dialog", to  
make the grammar active throughout the current  
form.  
scope  
type  
The media type of the grammar.  
The event count.  
<help>  
Catch a help event  
count  
An optional condition to test to see if the event is  
caught by this element.  
cond  
<if>  
Simple conditional  
logic  
<link>  
Specify a transition  
common to all  
dialogs in the link’s  
scope  
next  
expr  
The URI to go to.  
Like next, except that the URI is dynamically  
determined.  
The event to throw when the user matches one of the  
link grammars.  
event  
An ECMAScript expression evaluating to the name of  
eventexpr  
message  
the event to throw when the user matches one of the ꢂ  
link grammars.  
A message string providing additional context about  
the event being thrown.  
messageex An ECMAScript expression evaluating to the  
pr  
message string.  
dtmf  
The DTMF sequence for this link.  
Version 4.4  
257  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table K-4: VoiceXML Supported Elements & Attributes (continues on pages 256 to 260)  
Element  
<log>  
Element’s  
Description  
Parameter  
s
Parameter’s Description  
Supported  
Generate a debug  
message  
label  
expr  
A string which may be used.  
An ECMAscript expression evaluating to a string.  
The identifier of the menu.  
<menu>  
A dialog for choosing id  
amongst alternative  
destinations  
scope  
The menu’s grammar scope.  
When set to true, the first nine choices that have not  
explicitly specified a value for the dtmf attribute are  
given the implicit ones "1", "2", etc.  
Dtmf  
<noinput> Catch a noinput  
count  
cond  
count  
cond  
The event count.  
event  
An optional condition to test to see if the event is  
caught by this element.  
<nomatch> Catch a nomatch  
The event count.  
event  
An optional condition to test to see if the event is  
caught by this element.  
<object> Interact with a  
When the object is evaluated, it sets this variable to  
an ECMAScript value whose type is defined by the  
object.  
custom extension  
name  
expr  
The initial value of the form item variable.  
An expression that must evaluate to true after  
conversion to Boolean in order for the form item to be  
visited.  
cond  
The URI specifying the location of the object’s  
implementation.  
classid  
The base path used to resolve relative URIs  
specified by classid, data, and archive. (Not  
Supported)  
codebase  
The content type of data expected when loading the  
object specified by classid. (Not Supported)  
codetype  
data  
The URI specifying the location of the object’s data.  
The content type of the data specified by the data  
attribute. (Not Supported)  
type  
<param> Parameter in  
<object> or  
The name to be associated with this parameter when  
the object or sub-dialog is invoked.  
Name  
<subdialog>  
An expression that computes the value associated  
with name.  
expr  
value  
Associates a literal string value with name.  
One of data or ref, by default data; used to indicate to  
an object if the value associated with name is data or  
a URI (ref).  
valuetype  
type  
The media type of the result provided by a URI if the  
valuetype is ref;  
<property> Control  
implementation  
For a list of available properties, refer to Table K-5 on  
page 260.  
platform settings.  
<record> Record an audio  
name  
expr  
The input item variable that holds the recording.  
The initial value of the form item variable;  
sample  
An expression that must evaluate to true after  
conversion to Boolean in order for the form item to be  
visited.  
cond  
If this is true all non-local speech and DTMF  
grammars are not active while making the recording.  
modal  
beep  
If true, a tone is emitted just prior to recording. (Not  
Supported)  
Mediant 2000 SIP User’s Manual  
258  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Table K-4: VoiceXML Supported Elements & Attributes (continues on pages 256 to 260)  
Element  
Element’s  
Description  
Parameter  
s
Parameter’s Description  
Supported  
The interval of silence that indicates end of speech.  
(Not Supported)  
finalsilence  
dtmfterm  
If true, any DTMF keypress not matched by an active  
grammar is treated as a match of an active local  
DTMF grammar. (Not Supported)  
type  
The media format of the resulting recording.  
Return, and then throw this event.  
<return>  
Return from a  
subdialog.  
event  
Return, and then throw the event to which this  
ECMAScript expression evaluates.  
eventexpr  
message  
A message string providing additional context about  
the event being thrown.  
messageex An ECMAScript expression evaluating to the  
pr  
message string.  
namelist  
name  
Expr  
Variable names to be returned to calling dialog.  
The result returned from the sub-dialog,  
The initial value of the form item variable.  
<subdialog> Invoke another  
dialog as a subdialog  
of the current one  
An expression that must evaluate to true after  
conversion to Boolean in order for the form item to be  
visited.  
cond  
The list of variables to submit. The default is to  
submit no variables. If a namelist is supplied, it may  
contain individual variable references which are  
submitted with the same qualification used in the  
namelist. Declared VoiceXML and ECMAScript  
variables can be referenced.  
namelist  
src  
The URI of the sub-dialog.  
An ECMAScript expression yielding the URI of the  
sub-dialog  
srcexpr  
method  
next  
The URI reference.  
<submit> Submit values to a  
document server  
Like next, except that the URI reference is  
dynamically determined.  
expr  
namelist  
method  
event  
The list of variables to submit.  
The request method: get (the default) or post.  
The event being thrown.  
<throw>  
Throw an event.  
An ECMAScript expression evaluating to the name of  
the event being thrown.  
eventexpr  
message  
A message string providing additional context about  
the event being thrown.  
messageex An ECMAScript expression evaluating to the  
pr  
message string.  
<transfer> Transfer the caller to name  
Stores the outcome of a bridge transfer attempt.  
The initial value of the form item variable.  
another destination  
expr  
An expression that must evaluate to true in order for  
the form item to be visited.  
cond  
dest  
The URI of the destination (telephone, IP telephony  
address).  
An ECMAScript expression yielding the URI of the  
destination.  
destexpr  
bridge  
Determines whether the platform remains in the  
connection with the caller and callee.  
Version 4.4  
259  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Table K-4: VoiceXML Supported Elements & Attributes (continues on pages 256 to 260)  
Element  
Element’s  
Description  
Parameter  
s
Parameter’s Description  
Supported  
The URI of audio source to play while the transfer  
attempt is in progress (before far-end answer). (Not  
Supported)  
transferaudi  
o
An internal Voice Prompt ID that determines the VP  
that is played when the maximal time allowed for a  
call expires.  
endaudio  
An internal Voice Prompt ID that determines the VP  
that is played finalalerttime seconds before the  
maximal time allowed for a call expires.  
finalalertaud  
io  
Determines how many seconds before the maximal  
time allowed for a call expires, the finalalertaudio VP  
is played.  
finalalerttim  
e
<var>  
Declare a variable  
name  
expr  
The name of the variable that holds the result.  
The initial value of the variable.  
<vxml>  
Top-level element in  
each VoiceXML  
document  
The version of VoiceXML of this document  
(required). (Not Supported)  
version  
The designated namespace for VoiceXML (required).  
(Not Supported)  
xmlns  
The base URI for this document as defined in [XML-  
BASE]. (Not Supported)  
xml:base  
xml:lang  
application  
The language identifier for this document as defined  
in [RFC3066]. (Not Supported)  
The URI of this document’s application root  
document, if any. (Not Supported)  
Table K-5: VoiceXML Supported Properties  
Property description  
Default Value  
Property Name  
The maximum time (in seconds) to wait from the time the script  
is fetched.  
5 seconds  
FetchTimeout  
5 seconds  
#
TimeoutExpirationTime  
EndDialKey  
The maximum time to wait for the first digit in the user’s input.  
The user’s input that terminates the current collection.  
K.11 Provided Calling Card System  
K.11.1 Voice Prompts  
0. “Welcome to the calling card service”.  
1. “To make a call press 1, for help press 2, for operator assistance press 3, to exit press 4.  
2. “Invalid selection. Please try again”.  
3. “Unable to recognize your entry. Please try again” .  
4. “Please call again later”.  
5. “Please enter your account number followed by the pound key”.  
6. “Please enter your password followed by the pound key”.  
7. “Please wait while we verify your account number and password”.  
Mediant 2000 SIP User’s Manual  
260  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
             
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
8. “Your account number and password do not match”.  
9. “We are having technical difficulties, please call again later”.  
10. “Please enter the number that you wish to call followed by the pound key”.  
11. “The number you are calling is busy”.  
12. “The number you are calling is not answering, please call again later”.  
13. “The person you called has hung up”.  
14. “We are unable to complete your call”.  
15. “Transferring your call”.  
16. “Thank you for using the calling card service”.  
17. “The menu is currently empty”.  
18. “Operator assistance is currently unavailable”.  
19. “You are unauthorized to access the number you are attempting to call”.  
20. Final alert (one beep at 640 Hz for 0.5 second duration)  
21. Time of call expired (one beep at 640 Hz for 1.5 second duration)  
Version 4.4  
261  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
K.11.2 VXML Flow Chart  
Figure K-7: VXML Script Opening Menu  
Play VP 0  
Start  
Play VP 1  
No  
DTMF Pressed?  
Yes  
Play VP 3  
Yes  
Yes  
Pressed 1?  
No  
Go To Start  
Go To 1  
Pressed 2?  
No  
Go To 2  
Go To 3  
Yes  
Pressed 3?  
No  
Yes  
Pressed 4?  
No  
Go To 4  
Yes  
No Match  
Counter = x?  
Play VP 4  
No  
Play VP 2  
Go To End  
Go To Start  
Mediant 2000 SIP User’s Manual  
262  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Figure K-8: VXML Script Option 1, Make a Call  
1
Play VP 5  
No  
DTMF Pressed?  
Play VP 3  
Go To 1  
Yes  
Play VP 6  
DTMF Pressed?  
No  
Play VP 3  
Yes  
Play VP 7  
Waits for  
Authentication  
No  
Authentication  
Finished?  
Yes  
Yes  
Authentication  
OK?  
No  
Go To Transfer  
Yes  
No Match  
Counter = x?  
No  
Play VP 4  
Play VP 7  
No  
Go To End  
Go To 1  
Version 4.4  
263  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Figure K-9: VXML Script, Call Transfer Procedure  
Transfer  
Play VP 10  
No  
DTMF Pressed?  
Play VP 3  
Yes  
Play VP 15  
Go to Transfer  
Call for transfer  
service  
No  
Yes  
Transfer Failed?  
Play either VP  
11, 12 or 13  
according to  
Transfer failure  
reason  
No  
Yes  
Debit?  
Final alert time  
expired?  
No  
Go to End  
Yes  
Play VP 20  
Time for call  
expired?  
No  
Yes  
Play VP 21  
End  
Mediant 2000 SIP User’s Manual  
264  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Figure K-10: VXML Script, Options 2, 3 and 4  
2
Play VP 17  
Go To Start  
3
Transfer Call To  
an Operator  
End  
4
Play VP 16  
End  
Figure K-11: VXML Script, Call Termination  
End  
Yes  
VXML Script  
Terminated?  
No  
Play VP 16  
Go To Start  
Free Resources  
End  
Version 4.4  
265  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
K.12 VXML Script Example  
Figure K-12: VXML Script Example (continues on pages 266 to 270)  
<?xml version="1.0" encoding="UTF-8"?>  
<vxml version="1.0" application="http://phoenix1.iperia.com:8080/sa3/jsp/sa.jsp">  
<var name="AAStatus" expr="0"/>  
<form id="main_mc">  
<log label="starting main form"/>  
<block name="x">  
<prompt>  
<audio src="/0.wav">  
wellcome to the pre-paid call service  
</audio>  
</prompt>  
<goto next="#main_menu"/>  
</block>  
</form>  
<form id="main_menu">  
<log label="starting main_menu form"/>  
<field name="option" type="number">  
<dtmf>  
1 | 2 | 3 | 4  
</dtmf>  
<property name="TimeoutExpirationTime" value="1"/>  
<prompt bargein="true">  
<audio src="/1.wav">  
for making a call press 1  
for help press 2  
for human service press 3  
to exit press 4  
</audio>  
</prompt>  
<nomatch>  
<log label="try again interupt"/>  
<prompt>  
<audio src="/2.wav">  
that is an invalid selection. Please try again  
</audio>  
</prompt>  
</nomatch>  
<noinput>  
<log label="no try interupt"/>  
<prompt>  
<audio src="/3.wav">  
we did not get your input. Please try again  
</audio>  
</prompt>  
</noinput>  
<catch event="noinput nomatch" count="4">  
<log label="quit interupt"/>  
<prompt>  
<audio src="/4.wav">  
sorry please try again later  
</audio>  
</prompt>  
<log label="please try again later"/>  
<goto next="#disconnect"/>  
</catch>  
<filled>  
<if cond="option == '1'">  
Mediant 2000 SIP User’s Manual  
266  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
   
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Figure K-12: VXML Script Example (continues on pages 266 to 270)  
<if cond="AAStatus==0">  
<goto next="#PerformAuthen"/>  
<else/>  
<goto next="#PerformTransfer"/>  
</if>  
<elseif cond="option =='2'"/>  
<prompt>  
<audio src="/17.wav">  
sorry help is currently unavailble  
</audio>  
</prompt>  
<goto next="#main_menu"/>  
<elseif cond="option =='3'"/>  
<goto next="#HelpTransfer"/>  
<elseif cond="option == '4'"/>  
<goto next="#disconnect"/>  
</if>  
</filled>  
</field>  
</form>  
<form id="GetUserInfo">  
<log label="starting get user info form" cond="'1' == '1'"/>  
<field name="user_account_num" type="digits">  
<prompt bargein="true">  
<audio src="/5.wav">  
please enter your account number  
</audio>  
</prompt>  
</field>  
<field name="user_passwd" type="digits">  
<prompt bargein="true">  
<audio src="/6.wav">  
please enter your pin number  
</audio>  
</prompt>  
</field>  
<noinput>  
<log label="no try interupt"/>  
<prompt>  
<audio src="/3.wav">  
we did not get your input. Please try again  
</audio>  
</prompt>  
</noinput>  
<catch event="noinput nomatch" count="3">  
<prompt>  
<audio src="/4.wav">  
please try again later  
</audio>  
</prompt>  
<goto next="#disconnect"/>  
</catch>  
<filled>  
<return namelist="user_account_num user_passwd"/>  
</filled>  
Version 4.4  
267  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Figure K-12: VXML Script Example (continues on pages 266 to 270)  
</form>  
<form id="GetCalledPartyTelephone">  
<log label="starting get called party telephone form" cond="'1' == '1'"/>  
<field name="dest_number" type="digits">  
<prompt bargein="true">  
<audio src="/10.wav">  
please dial the telephone number  
</audio>  
</prompt>  
<noinput>  
<prompt>  
<audio src="/3.wav">  
illegal input  
</audio>  
</prompt>  
</noinput>  
<catch event="noinput nomatch" count="3">  
<goto next="#disconnect"/>  
</catch>  
<filled>  
<return namelist="dest_number"/>  
</filled>  
</field>  
</form>  
<form id="HelpTransfer">  
<log label="performing help transfer"/>  
<transfer name="mycall" destexpr="201" bridge="true">  
<filled>  
<goto next="#disconnect"/>  
</filled>  
</transfer>  
</form>  
<form id="PerformAuthen">  
<log label="performing authentication"/>  
<subdialog name="AuthenticationInfo" src="#GetUserInfo">  
<filled>  
<prompt>  
<audio src="/7.wav">  
please wait while your account and pin numbers are  
cheked  
</audio>  
</prompt>  
</filled>  
</subdialog>  
<object name="authenticate" classid="builtin://com.audiocodes.aaa.authenticate">  
<param name="account" expr="AuthenticationInfo.user_account_num"/>  
Mediant 2000 SIP User’s Manual  
268  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
K. RADIUS Billing and VXML Calling Card Application  
Figure K-12: VXML Script Example (continues on pages 266 to 270)  
<param name="password" expr="AuthenticationInfo.user_passwd"/>  
<nomatch>  
<prompt>  
<audio src="/8.wav">  
your account and password did not match.  
</audio>  
</prompt>  
<clear namelist="AuthenticationInfo authenticate"/>  
</nomatch>  
<catch event="nomatch" count="4">  
<goto next="#disconnect"/>  
</catch>  
<filled>  
<assign name="AAStatus" expr="1"/>  
<goto next="#PerformTransfer"/>  
</filled>  
</object>  
</form>  
<form id="PerformTransfer">  
<log label="starting transfer form"/>  
<subdialog name="Call" src="#GetCalledPartyTelephone">  
</subdialog>  
<object name="authorize" classid="builtin://com.audiocodes.aaa.authorize">  
<param name="dest" expr="Call.dest_number"/>  
<nomatch>  
<prompt>  
<audio src="/9.wav"/>  
you are not authorized.  
</prompt>  
<clear namelist=" Call authorize "/>  
</nomatch>  
<catch event="nomatch" count="3">  
<goto next="#disconnect"/>  
</catch>  
<filled>  
<prompt>  
<audio src="/15.wav">  
calling  
</audio>  
</prompt>  
</filled>  
</object>  
<transfer name="mycall" destexpr="Call.dest_number" bridge="true" endaudio="7"  
finalalertaudio="4" finalalerttime="10">  
<filled>  
<if cond="mycall.Result=='fail'">  
<prompt>  
<audio src="/14.wav">  
Version 4.4  
269  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP  
Figure K-12: VXML Script Example (continues on pages 266 to 270)  
called transfer failed  
</audio>  
</prompt>  
<goto next="#main_menu"/>  
<elseif cond="mycall.Result=='busy'"/>  
<prompt>  
<audio src="/11.wav">  
called party is busy  
</audio>  
</prompt>  
<goto next="#main_menu"/>  
<elseif cond="mycall.Result=='maxtime'"/>  
<prompt>  
<audio src="/7.wav">  
reached maximum time allowed  
</audio>  
</prompt>  
<goto next="#main_menu"/>  
<else/>  
<goto next="#main_menu"/>  
</if>  
</filled>  
</transfer>  
</form>  
<form id="disconnect">  
<block name="x">  
<prompt>  
<audio src="/16.wav">  
goodbye  
</audio>  
</prompt>  
<log label="disconnect"/>  
<exit/>  
</block>  
</form>  
</vxml>  
Mediant 2000 SIP User’s Manual  
270  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP User’s Manual  
L. SNMP Traps  
Appendix L SNMP Traps  
This section provides information on proprietary SNMP traps currently supported by the gateway.  
There is a separation between traps that are alarms and traps that are not (logs). Currently all  
have the same structure made up of the same 10 varbinds (Variable Binding)  
(1.3.6.1.4.1.5003.9.10.1.21.1).  
L.1  
Alarm Traps  
The following tables provide information on alarms that are raised as a result of a generated  
SNMP trap. The component name (described in each of the following headings) refers to the  
string that is provided in the ‘acBoardTrapGlobalsSource’ trap varbind. To clear a generated  
alarm the same notification type is sent but with the severity set to ‘cleared’.  
L.1.1 Component: System#0  
Table L-1: acBoardFatalError Alarm Trap  
Alarm:  
acBoardFatalError  
OID:  
1.3.6.1.4.1.5003.9.10.1.21.2.0.1  
Critical  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
equipmentAlarm  
underlyingResourceUnavailable (56)  
Board Fatal Error: <text>  
Any fatal error  
Alarm status:  
<text> value:  
Critical  
A run-time specific string describing the fatal error  
Condition:  
After fatal error  
Alarm status:  
Corrective Action:  
Status stays critical until reboot. A clear trap is not sent.  
Capture the alarm information and the Syslog clause, if active. Contact your first-level  
support group. The support group will likely want to collect additional data from the  
device and perform a reset.  
Table L-2: acBoardConfigurationError Alarm Trap  
acBoardConfigurationError  
1.3.6.1.4.1.5003.9.10.1.21.2.0.2  
Critical  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
equipmentAlarm  
underlyingResourceUnavailable (56)  
Board Config Error: <text>  
A configuration error was detected  
critical  
Alarm status:  
<text> value:  
A run-time specific string describing the configuration error.  
Condition:  
After configuration error  
Alarm status:  
Status stays critical until reboot. A clear trap is not sent.  
Version 4.4  
271  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP  
Table L-2: acBoardConfigurationError Alarm Trap  
Corrective Action:  
Inspect the run-time specific string to determine the nature of the configuration error. Fix  
the configuration error using the appropriate tool: Web interface, EMS, or ini file. Save  
the configuration and if necessary reset the device.  
Table L-3: acBoardTemperatureAlarm Alarm Trap  
acBoardTemperatureAlarm  
1.3.6.1.4.1.5003.9.10.1.21.2.0.3  
Critical  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
equipmentAlarm  
temperatureUnacceptable (50)  
Board temperature too high  
Temperature is above 60 degrees C (140 degrees F)  
Critical  
Alarm status:  
Condition:  
After raise, temperature falls below 55 degrees C (131 degrees F)  
Cleared  
Alarm status:  
Corrective Action:  
Inspect the system. Determine if all fans in the system are properly operating.  
Table L-4: acBoardEvResettingBoard Alarm Trap  
acBoardEvResettingBoard  
1.3.6.1.4.1.5003.9.10.1.21.2.0.5  
Critical  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
equipmentAlarm  
outOfService (71)  
User resetting board  
When a soft reset is triggered via the Web interface or SNMP.  
Critical  
Alarm status:  
Condition:  
After raise  
Alarm status:  
Corrective Action:  
Status stays critical until reboot. A clear trap is not sent.  
A network administrator has taken action to reset the device. No corrective action is  
required.  
Table L-5: acFeatureKeyError Alarm Trap  
acFeatureKeyError  
Alarm:  
1.3.6.1.4.1.5003.9.10.1.21.2.0.6  
Critical  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Note:  
processingErrorAlarm  
configurationOrCustomizationError (7)  
Feature key error  
Support of this alarm is pending  
A feature key error has been detected  
Critical  
Condition:  
Alarm status:  
Mediant 2000 SIP User’s Manual  
272  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP User’s Manual  
L. SNMP Traps  
Table L-5: acFeatureKeyError Alarm Trap  
Condition:  
After raise  
Alarm status:  
Corrective Action:  
Status stays critical until reboot. A clear trap is not sent.  
Obtain a corrected feature key from AudioCodes, activate it by loading to the device,  
then reset the device.  
Table L-6: acBoardCallResourcesAlarm Alarm Trap  
acBoardCallResourcesAlarm  
1.3.6.1.4.1.5003.9.10.1.21.2.0.8  
Major  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
processingErrorAlarm  
softwareError (46)  
Call resources alarm  
Number of free channels exceeds the predefined RAI high threshold.  
Major  
Alarm Status:  
Note:  
To enable this alarm the RAI mechanism must be activated (EnableRAI = 1).  
Condition:  
Number of free channels falls below the predefined RAI low threshold.  
Alarm Status:  
Cleared  
Table L-7: acBoardControllerFailureAlarm Alarm Trap  
acBoardControllerFailureAlarm  
1.3.6.1.4.1.5003.9.10.1.21.2.0.9  
Minor  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
processingErrorAlarm  
softwareError (46)  
Controller failure alarm  
Proxy has not been found  
Major  
Alarm Status:  
Additional Info:  
Proxy not found. Use internal routing  
or  
Proxy lost. looking for another Proxy  
Condition:  
Proxy is found.  
The clear message includes the IP address of this Proxy.  
Alarm Status:  
Cleared  
Table L-8: acBoardOverloadAlarm Alarm Trap  
acBoardOverloadAlarm  
1.3.6.1.4.1.5003.9.10.1.21.2.0.11  
Major  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
processingErrorAlarm  
softwareError (46)  
Board overload alarm  
Version 4.4  
273  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
     
Mediant 2000 SIP  
Table L-8: acBoardOverloadAlarm Alarm Trap  
Condition:  
An overload condition exists in one or more of the system components.  
Major  
Alarm Status:  
Condition:  
The overload condition passed  
Cleared  
Alarm Status:  
Mediant 2000 SIP User’s Manual  
274  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
L. SNMP Traps  
L.1.2 Component: AlarmManager#0  
Table L-9: acActiveAlarmTableOverflow Alarm Trap  
acActiveAlarmTableOverflow  
1.3.6.1.4.15003.9.10.1.21.2.0.12  
Major  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
processingErrorAlarm  
resourceAtOrNearingCapacity (43)  
Active alarm table overflow  
Too many alarms to fit in the active alarm table  
major  
Alarm status:  
Condition:  
After raise  
Alarm status:  
Status stays major until reboot. A clear trap is not sent.  
Note:  
The status stays major until reboot as it denotes a possible loss of information until the  
next reboot. If an alarm is raised when the table is full, it is possible that the alarm is  
active, but does not appear in the active alarm table.  
Corrective Action:  
Some alarm information may have been lost, but the ability of the device to perform its  
basic operations has not been impacted. A reboot is the only way to completely clear a  
problem with the active alarm table. Contact your first-level group.  
L.1.3 Component: EthernetLink#0  
Table L-10: acBoardEthernetLinkAlarm Alarm Trap  
acBoardEthernetLinkAlarm  
1.3.6.1.4.1.5003.9.10.1.21.2.0.10  
Critical  
Alarm:  
OID:  
Default Severity  
Event Type:  
Probable Cause:  
Alarm Text:  
Status Changes:  
Condition:  
equipmentAlarm  
underlyingResourceUnavailable (56)  
Ethernet link alarm: <text>  
Fault on single interface  
major  
Alarm status:  
<text> value:  
Redundant link is down  
Condition:  
Fault on both interfaces  
critical  
Alarm status:  
<text> value:  
No Ethernet link  
Condition:  
Both interfaces are operational  
cleared  
Alarm status:  
Corrective Action:  
Ensure that both Ethernet cables are plugged into the back of the system. Inspect the  
system’s Ethernet link lights to determine which interface is failing. Reconnect the cable  
or fix the network problem  
Version 4.4  
275  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
       
Mediant 2000 SIP  
L.1.4 Other Traps  
The following are provided as SNMP traps and are not alarms.  
Table L-11: coldStart Trap  
coldStart  
Trap Name:  
OID:  
1.3.6.1.6.3.1.1.5.1  
SNMPv2-MIB  
MIB  
Note:  
This is a trap from the standard SNMP MIB.  
Table L-12: authenticationFailure Trap  
authenticationFailure  
1.3.6.1.6.3.1.1.5.5  
SNMPv2-MIB  
Trap Name:  
OID:  
MIB  
Table L-13: acBoardEvBoardStarted Trap  
acBoardEvBoardStarted  
Trap Name:  
OID:  
1.3.6.1.4.1.5003.9.10.1.21.2.0.4  
AcBoard  
MIB  
cleared  
Severity  
equipmentAlarm  
Event Type:  
Probable Cause:  
Alarm Text:  
Note:  
Other(0)  
Initialization Ended  
This is the AudioCodes Enterprise application cold start trap.  
L.1.5 Trap Varbinds  
Each trap described above provides the following fields (known as ‘varbinds’). Refer to the  
AcBoard MIB for additional details on these varbinds.  
acBoardTrapGlobalsName  
acBoardTrapGlobalsTextualDescription  
acBoardTrapGlobalsSource  
acBoardTrapGlobalsSeverity  
acBoardTrapGlobalsUniqID  
acBoardTrapGlobalsType  
acBoardTrapGlobalsProbableCause  
acBoardTrapGlobalsAdditionalInfo1  
acBoardTrapGlobalsAdditionalInfo2  
acBoardTrapGlobalsAdditionalInfo3  
Note that ‘acBoardTrapGlobalsName’ is actually a number. The value of this varbind is ‘X’ minus  
1, where ‘X’ is the last number in the trap’s OID. For example, the ‘name’ of  
‘acBoardEthernetLinkAlarm’ is ‘9’. The OID for ‘acBoardEthernetLinkAlarm’ is 1.3.6.1.4.1.5003.  
9.10.1.21.2.0.10.  
Mediant 2000 SIP User’s Manual  
276  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
         
Mediant 2000 SIP User’s Manual  
M. Regulatory Information  
Appendix M Regulatory Information  
Declaration of Conformity  
Application of Council Directives:  
73/23/EEC (including amendments),  
89/336/EEC (including amendments),  
1999/5/EC Annex-II of the Directive  
Standards to which Conformity is Declared:  
EN55022: 1998, Class A  
EN55024: 1998  
EN61000-3-2: 1995  
(including amendments A1: 1998, A2: 1998, A14: 2000)  
EN61000-3-3: 1995  
EN60950-1: 2001  
TBR-4: 1995 (including amendment A1: 1997)  
TBR-13: 1996  
TBR-12: 1993 (including amendment 1: 1996)  
Manufacturer’s Name:  
Manufacturer’s Address:  
Type of Equipment:  
Model Numbers:  
AudioCodes Ltd.  
1 Hayarden Street, Airport City, Lod 70151, Israel.  
Digital VoIP System.  
Mediant 2000, Stretto 2000, IPmedia 2000  
I, the undersigned, hereby declare that the equipment specified above conforms to the above Directives and Standards.  
11th February, 2005  
Airport City, Lod, Israel  
Signature  
Date (Day/Month/Year)  
Location  
I. Zusmanovich, Compliance Engineering Manager  
Czech  
[AudioCodes Ltd] tímto prohlašuje, že tento [2000 Series] je ve shodě se základními požadavky a dalšími příslušnými ustanoveními směrnice 1999/5/ES."  
Danish  
Undertegnede [AudioCodes Ltd] erklærer herved, at følgende udstyr [2000 Series] overholder de væsentlige krav og øvrige relevante krav i direktiv  
1999/5/EF  
Dutch  
Hierbij verklaart [AudioCodes Ltd] dat het toestel [2000 Series] in overeenstemming is met de essentiële eisen en de andere relevante bepalingen van  
richtlijn 1999/5/EG  
English  
Estonian  
Finnish  
French  
German  
Greek  
Hereby, [AudioCodes Ltd], declares that this [2000 Series] is in compliance with the essential requirements and other relevant provisions of Directive  
1999/5/EC.  
Käesolevaga kinnitab [AudioCodes Ltd] seadme [2000 Series] vastavust direktiivi 1999/5/EÜ põhinõuetele ja nimetatud direktiivist tulenevatele teistele  
asjakohastele sätetele.  
[AudioCodes Ltd] vakuuttaa täten että [2000 Series] tyyppinen laite on direktiivin 1999/5/EY oleellisten vaatimusten ja sitä koskevien direktiivin muiden  
ehtojen mukainen.  
Par la présente [AudioCodes Ltd] déclare que l'appareil [2000 Series] est conforme aux exigences essentielles et aux autres dispositions pertinentes de la  
directive 1999/5/CE  
Hiermit erklärt [AudioCodes Ltd], dass sich dieser/diese/dieses [2000 Series] in Übereinstimmung mit den grundlegenden Anforderungen und den anderen  
relevanten Vorschriften der Richtlinie 1999/5/EG befindet". (BMWi)  
ΜΕ ΤΗΝ ΠΑΡΟΥΣΑ [AudioCodes Ltd] ∆ΗΛΩΝΕΙ ΟΤΙ [2000 Series] ΣΥΜΜΟΡΦΩΝΕΤΑΙ ΠΡΟΣ ΤΙΣ ΟΥΣΙΩ∆ΕΙΣ ΑΠΑΙΤΗΣΕΙΣ ΚΑΙ ΤΙΣ ΛΟΙΠΕΣ ΣΧΕΤΙΚΕΣ  
∆ΙΑΤΑΞΕΙΣ ΤΗΣ Ο∆ΗΓΙΑΣ 1999/5/ΕΚ  
Hungarian  
Alulírott, [AudioCodes Ltd] nyilatkozom, hogy a [2000 Series] megfelel a vonatkozó alapvetõ követelményeknek és az 1999/5/EC irányelv egyéb  
elõírásainak  
Icelandic  
Italian  
æki þetta er í samræmi við tilskipun Evrópusambandsins 1999/5  
Con la presente [AudioCodes Ltd] dichiara che questo (2000 Series) è conforme ai requisiti essenziali ed alle altre disposizioni pertinenti stabilite dalla  
direttiva 1999/5/CE.  
Latvian  
Ar šo [AudioCodes Ltd] deklarē, ka [2000 Series] atbilst Direktīvas 1999/5/EK būtiskajām prasībām un citiem ar to saistītajiem noteikumiem.  
Lithuanian  
Maltese  
[AudioCodes Ltd] deklaruoja, kad irenginys [2000 Series] tenkina 1999/5/EB Direktyvos esminius reikalavimus ir kitas sios direktyvos nuostatas  
Hawnhekk, [AudioCodes Ltd], jiddikjara li dan [2000 Series] jikkonforma mal-ħtiġijiet essenzjali u ma provvedimenti oħrajn relevanti li hemm fid-Dirrettiva  
1999/5/EC  
Norwegian  
Polish  
Dette produktet er i samhørighet med det Europeiske Direktiv 1999/5  
[AudioCodes Ltd], deklarujemy z pelna odpowiedzialnoscia, ze wyrób [2000 Series] spelnia podstawowe wymagania i odpowiada warunkom zawartym w  
dyrektywie 1999/5/EC  
Portuguese  
Slovak  
[AudioCodes Ltd] declara que este [2000 Series] está conforme com os requisitos essenciais e outras disposições da Directiva 1999/5/CE.  
[AudioCodes Ltd] týmto vyhlasuje, že [2000 Series] spĺňa základné požiadavky a všetky príslušné ustanovenia Smernice 1999/5/ES.  
Šiuo [AudioCodes Ltd] deklaruoja, kad šis [2000 Series] atitinka esminius reikalavimus ir kitas 1999/5/EB Direktyvos nuostatas.  
Slovene  
Spanish  
Por medio de la presente [AudioCodes Ltd] declara que el (200 Series) cumple con los requisitos esenciales y cualesquiera otras disposiciones aplicables  
o exigibles de la Directiva 1999/5/CE  
Swedish  
Härmed intygar [AudioCodes Ltd] att denna [2000 Series] står I överensstämmelse med de väsentliga egenskapskrav och övriga relevanta bestämmelser  
som framgår av direktiv 1999/5/EG.  
Safety Notices  
Installation and service of this gateway must only be performed by authorized, qualified service personnel.  
The protective earth terminal on the back of the 2000 must be permanently connected to protective earth.  
Version 4.4  
277  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
 
Mediant 2000 SIP  
Industry Canada Notice  
This equipment meets the applicable Industry Canada Terminal Equipment technical specifications. This is confirmed by the  
registration numbers. The abbreviation, IC, before the registration number signifies that registration was performed based on a  
declaration of conformity indicating that Industry Canada technical specifications were met. It does not imply that Industry  
Canada approved the equipment.  
Digital Device Warnings  
This equipment complies with Part 68 of the FCC rules and the requirements adopted by ACTA. On the bottom of this  
equipment is a label that contains a product identifier in the format US:AC1ISNANMED2KDC. If requested this number must be  
provided to the telephone company.  
The Telephone company may make changes in the facilities, equipment, operations or procedures that could affect the  
operation of the equipment. If this happens the telephone company will provide advance notice in order for you to make  
necessary modifications to maintain uninterrupted service. Should you experience trouble with this telephone equipment,  
contact: AudioCodes Inc, San Jose, CA USA. Tel: 1 408 577 0488. Do not attempt to repair this equipment!  
Do not attempt to repair this equipment!  
Facility Interface Code:  
Service Order Code:  
USOC Jack Type:  
04DU9.BN, 04DU9.DN, 04DU9.1KN, 4DU9.ISN  
6.0N  
RJ21X or RJ48C  
It this gateway causes harm to the telephone network, the telephone company will notify you in advance that temporary  
discontinuance of service may be required. But if advance notice isn’t practical, the telephone company will notify the customer  
as soon as possible. Also you will be advised of your right to file complaint with the FCC if you believe it is necessary.  
Network Information and Intent of Use  
The products are for access to ISDN at 2048 kb/s and for access to G.703 Leased lines at 2048 kb/s.  
Network Compatibility  
The products support the Telecom networks in EU that comply with TBR4 and TBR13.  
Telecommunication Safety  
The safety status of each port is declared and detailed in the table below:  
Ports  
E1 or T1  
Safety Status  
TNV-1  
Ethernet (100 Base-TX)  
SELV  
TNV-1:  
Telecommunication network voltage circuits whose normal operating voltages do not exceed the limits for SELV  
under normal operating conditions and on which over voltages from telecommunication networks are possible.  
SELV:  
Safety extra low voltage circuit.  
FCC Statement  
This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC  
Rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This  
equipment generates, uses and can radiate radio frequency energy and, if not installed and used in accordance with the  
instructions, may cause harmful interference to radio communications. However there is no guarantee that interference will not  
occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be  
determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the  
following measures:  
- Reorient or relocate the receiving antenna.  
- Increase the separation between the equipment and receiver.  
- Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.  
- Consult the dealer or an experienced radio/TV technician for help.  
Mediant 2000 SIP User’s Manual  
278  
Document #: LTRT-72504  
Download from Www.Somanuals.com. All Manuals Search And Download.  
Mediant 2000 SIP User’s Manual  
M. Regulatory Information  
Original  
printed on  
recycled paper  
and available on  
CD or Web site  
Version 4.4  
279  
July 2005  
Download from Www.Somanuals.com. All Manuals Search And Download.  
AudioCodes Offices  
International Headquarters  
AudioCodes Ltd.  
1 Hayarden Street, Airport City, Lod 70151, Israel.  
Tel: +972-3-976 4000  
Fax: +972-3-976 4040  
USA Headquarters  
AudioCodes, Inc.  
2099 Gateway Place, Suite 500  
San Jose, CA 95110  
Tel: +1-408-411-1175  
Fax: +1-408-451-9520  
USA Offices  
Boston (MA), Chicago (IL), Research Triangle Park (NC),  
Richardson (TX), Somerset (NJ)  
AudioCodes Offices Worldwide  
Beijing, London, Mexico City, Paris, Tokyo  
Download from Www.Somanuals.com. All Manuals Search And Download.  

Mr Coffee Coffeemaker CUBIKA User Manual
Multi Tech Systems Computer Drive MTD EV3 User Manual
Nady Systems Microphone dkw duo User Manual
NETGEAR Network Hardware XAVB5602 100NAS User Manual
New Holland Lawn Mower TG Series User Manual
Nilfisk ALTO Vacuum Cleaner 107402849 C User Manual
Nilfisk ALTO Vacuum Cleaner GD 2000 Series User Manual
Olympus Camcorder MODEL 2004 User Manual
Panasonic Cell Phone A100 User Manual
Parkside Saw PFS 710 A1 User Manual