User's Manual
Enterprise Session Border Controller
Analog & Digital VoIP Media Gateway
Mediant™ 1000B Gateway & E-SBC
Version 6.8
November 2014
Document # LTRT-27034
User's Manual
Contents
Table of Contents
1
Overview ............................................................................................................ 23
Getting Started with Initial Connectivity ................................................................25
2
Introduction ....................................................................................................... 27
3
Default OAMP IP Address ................................................................................. 29
4
Configuring VoIP LAN Interface for OAMP ..................................................... 31
4.1
4.2
Web Interface ......................................................................................................... 31
CLI.......................................................................................................................... 33
Management Tools ..................................................................................................35
5
Introduction ....................................................................................................... 37
6
Web-Based Management .................................................................................. 39
6.1
Getting Acquainted with the Web Interface ............................................................ 39
6.1.1
6.1.2
6.1.3
6.1.4
6.1.5
Computer Requirements..........................................................................................39
Accessing the Web Interface ...................................................................................40
Areas of the GUI ......................................................................................................41
Toolbar Description..................................................................................................42
Navigation Tree .......................................................................................................42
6.1.5.1 Displaying Navigation Tree in Basic and Full View ..................................43
6.1.5.2 Showing / Hiding the Navigation Pane .....................................................44
6.1.6 Working with Configuration Pages ..........................................................................45
6.1.6.1 Accessing Pages ......................................................................................45
6.1.6.2 Viewing Parameters .................................................................................45
6.1.6.3 Modifying and Saving Parameters ...........................................................47
6.1.6.4 Working with Tables .................................................................................48
6.1.7 Searching for Configuration Parameters .................................................................49
6.1.8 Creating a Login Welcome Message.......................................................................51
6.1.9 Getting Help .............................................................................................................51
6.1.10 Logging Off the Web Interface .................................................................................52
6.2
Viewing the Home Page......................................................................................... 53
6.2.1
6.3
6.3.1
6.3.2
6.4
6.5
6.6
6.7
7
Assigning a Port Name ............................................................................................55
Configuring Web User Accounts ............................................................................ 56
Basic User Accounts Configuration .........................................................................57
Advanced User Accounts Configuration ..................................................................59
Displaying Login Information upon Login ............................................................... 62
Configuring Web Security Settings ........................................................................ 63
Web Login Authentication using Smart Cards ....................................................... 64
Configuring Web and Telnet Access List ............................................................... 64
CLI-Based Management.................................................................................... 67
7.1
Getting Familiar with CLI ........................................................................................ 67
7.1.1
7.1.2
7.1.3
7.1.4
7.1.5
Version 6.8
Understanding Configuration Modes .......................................................................67
Using CLI Shortcuts .................................................................................................68
Common CLI Commands ........................................................................................69
Configuring Tables in CLI ........................................................................................70
Understanding CLI Error Messages ........................................................................70
3
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
7.2
Enabling CLI........................................................................................................... 71
7.2.1
7.2.2
7.3
7.4
7.5
7.6
8
Establishing a CLI Session .................................................................................... 73
Configuring Maximum Telnet/SSH Sessions ......................................................... 74
Viewing and Terminating Current CLI Sessions .................................................... 75
Configuring Displayed Output Lines in CLI Terminal Window ............................... 76
SNMP-Based Management ............................................................................... 77
8.1
8.2
8.3
8.4
9
Enabling Telnet for CLI ............................................................................................71
Enabling SSH with RSA Public Key for CLI.............................................................72
Enabling SNMP and Configuring SNMP Community Strings ................................. 77
Configuring SNMP Trap Destinations .................................................................... 78
Configuring SNMP Trusted Managers ................................................................... 80
Configuring SNMP V3 Users.................................................................................. 80
INI File-Based Management .............................................................................. 83
9.1
INI File Format ....................................................................................................... 83
9.1.1
9.1.2
9.1.3
9.2
9.3
9.4
9.5
9.6
Configuring Individual ini File Parameters ...............................................................83
Configuring Table ini File Parameters .....................................................................83
General ini File Formatting Rules ............................................................................85
Configuring an ini File ............................................................................................ 85
Loading an ini File to the Device ............................................................................ 86
Secured Encoded ini File ....................................................................................... 86
Configuring Password Display in ini File ................................................................ 87
INI Viewer and Editor Utility ................................................................................... 88
General System Settings ........................................................................................89
10 Configuring SSL/ TLS Certificates ................................................................... 91
10.1.1
10.1.2
10.1.3
10.1.4
10.1.5
10.1.6
10.1.7
Configuring TLS Certificate Contexts ......................................................................91
Assigning CSR-based Certificates to TLS Contexts ...............................................95
Assigning Externally Created Private Keys to TLS Contexts ..................................96
Generating Private Keys for TLS Contexts..............................................................97
Creating Self-Signed Certificates for TLS Contexts ................................................98
Importing Certificates and Certificate Chain into Trusted Certificate Store .............99
Configuring Mutual TLS Authentication .................................................................100
10.1.7.1 TLS for SIP Clients ................................................................................ 100
10.1.7.2 TLS for Remote Device Management ................................................... 101
10.1.8 Configuring TLS Server Certificate Expiry Check .................................................102
11 Date and Time .................................................................................................. 103
11.1 Configuring Date and Time Manually ................................................................... 103
11.2 Configuring Automatic Date and Time using SNTP ............................................. 103
11.3 Configuring Daylight Saving Time ........................................................................ 105
General VoIP Configuration ..................................................................................107
12 Network ............................................................................................................ 109
12.1 Configuring Physical Ethernet Ports .................................................................... 109
12.2 Configuring Ethernet Port Groups ........................................................................ 111
12.3 Configuring Underlying Ethernet Devices ............................................................ 113
User's Manual
4
Document #: LTRT-27034
User's Manual
Contents
12.4 Configuring IP Network Interfaces ....................................................................... 116
12.4.1 Assigning NTP Services to Application Types ......................................................119
12.4.2 Multiple Interface Table Configuration Summary and Guidelines .........................119
12.4.3 Networking Configuration Examples .....................................................................120
12.4.3.1 One VoIP Interface for All Applications ................................................. 120
12.4.3.2 VoIP Interface per Application Type...................................................... 121
12.4.3.3 VoIP Interfaces for Combined Application Types ................................. 121
12.4.3.4 VoIP Interfaces with Multiple Default Gateways ................................... 123
12.5 Configuring Static IP Routes ................................................................................ 123
12.5.1 Configuration Example of Static IP Routes ...........................................................125
12.5.2 Troubleshooting the Routing Table .......................................................................126
12.6 Configuring Quality of Service.............................................................................. 127
12.7 Configuring ICMP Messages ............................................................................... 129
12.8 DNS...................................................................................................................... 130
12.8.1 Configuring the Internal DNS Table.......................................................................130
12.8.2 Configuring the Internal SRV Table .......................................................................131
12.9 Open Solution Network (OSN) Server ................................................................. 133
12.9.1 Configuring Native VLAN for OSN Server .............................................................133
12.9.2 Disabling Internal Switch Port for OSN..................................................................133
12.10 Configuring NFS Settings..................................................................................... 134
12.11 Network Address Translation Support ................................................................. 135
12.11.1 Device Located behind NAT ..................................................................................135
12.11.1.1 Configuring a Static NAT IP Address for All Interfaces ......................... 136
12.11.1.2 Configuring NAT Translation per IP Interface ....................................... 137
12.11.2 Remote UA behind NAT ........................................................................................138
12.11.2.1 SIP Signaling Messages ....................................................................... 138
12.11.2.2 Media (RTP/RTCP/T.38) ....................................................................... 139
12.12 Robust Receipt of Media Streams by Media Latching ......................................... 141
12.13 Multiple Routers Support...................................................................................... 142
13 Security ............................................................................................................ 143
13.1 Configuring Firewall Settings ............................................................................... 143
13.2 Configuring General Security Settings ................................................................. 147
13.3 Intrusion Detection System .................................................................................. 148
13.3.1
13.3.2
13.3.3
13.3.4
Enabling IDS ..........................................................................................................149
Configuring IDS Policies ........................................................................................149
Assigning IDS Policies ...........................................................................................153
Viewing IDS Alarms ...............................................................................................155
14 Media ................................................................................................................ 157
14.1 Configuring Voice Settings ................................................................................... 157
14.1.1 Configuring Voice Gain (Volume) Control .............................................................157
14.1.2 Silence Suppression (Compression) .....................................................................157
14.1.3 Echo Cancellation ..................................................................................................158
14.2 Fax and Modem Capabilities................................................................................ 159
14.2.1 Fax/Modem Operating Modes ...............................................................................160
14.2.2 Fax/Modem Transport Modes ...............................................................................160
14.2.2.1 T.38 Fax Relay Mode ............................................................................ 160
14.2.2.2 G.711 Fax / Modem Transport Mode .................................................... 162
14.2.2.3 Fax Fallback .......................................................................................... 163
14.2.2.4 Fax/Modem Bypass Mode .................................................................... 164
14.2.2.5 Fax / Modem NSE Mode ....................................................................... 165
14.2.2.6 Fax / Modem Transparent with Events Mode ....................................... 166
Version 6.8
5
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.2.7 Fax / Modem Transparent Mode ........................................................... 166
14.2.2.8 RFC 2833 ANS Report upon Fax/Modem Detection ............................ 167
14.2.3 V.34 Fax Support ...................................................................................................167
14.2.3.1 Bypass Mechanism for V.34 Fax Transmission .................................... 168
14.2.3.2 Relay Mode for T.30 and V.34 Faxes ................................................... 168
14.2.4 V.152 Support ........................................................................................................168
14.2.5 Fax Transmission behind NAT ..............................................................................169
14.3 Configuring RTP/RTCP Settings .......................................................................... 170
14.3.1 Configuring the Dynamic Jitter Buffer ....................................................................170
14.3.2 Comfort Noise Generation .....................................................................................171
14.3.3 Dual-Tone Multi-Frequency Signaling ...................................................................172
14.3.3.1 Configuring DTMF Transport Types...................................................... 172
14.3.3.2 Configuring RFC 2833 Payload ............................................................ 173
14.3.4 Configuring RTP Base UDP Port ...........................................................................174
14.4 Answering Machine Detector (AMD) .................................................................... 175
14.4.1
14.4.2
14.4.3
14.4.4
Detecting Answering Machine Beeps ....................................................................178
SIP Call Flow Example of AMD .............................................................................178
Configuring AMD ...................................................................................................180
Enabling IP-to-Tel Call Disconnection upon Detection of Answering Machine .....180
14.5 Automatic Gain Control (AGC) ............................................................................. 181
14.6 Configuring Analog Settings................................................................................. 182
14.7 Configuring Ground- or Loop-Start Signaling per Analog Port ............................. 183
14.8 Configuring DSP Templates................................................................................. 184
14.9 DSP Channel Resources for Transcoding ........................................................... 184
14.10 Configuring Media (SRTP) Security ..................................................................... 186
15 Services ........................................................................................................... 189
15.1 DHCP Server Functionality .................................................................................. 189
15.1.1
15.1.2
15.1.3
15.1.4
15.1.5
Configuring the DHCP Server ...............................................................................189
Configuring the Vendor Class Identifier .................................................................193
Configuring Additional DHCP Options ...................................................................194
Configuring Static IP Addresses for DHCP Clients ...............................................196
Viewing and Deleting DHCP Clients......................................................................197
15.2 RADIUS Authentication ........................................................................................ 199
15.2.1
15.2.2
15.2.3
15.2.4
Setting Up a Third-Party RADIUS Server ..............................................................200
Configuring RADIUS Authentication ......................................................................201
Securing RADIUS Communication ........................................................................202
Authenticating RADIUS in the URL .......................................................................202
15.3 LDAP-based Management and SIP Services ...................................................... 203
15.3.1 Enabling the LDAP Service ...................................................................................204
15.3.2 Enabling LDAP-based Web/CLI User Login Authentication and Authorization.....204
15.3.3 Configuring LDAP Servers.....................................................................................205
15.3.4 Configuring LDAP DNs (Base Paths) per LDAP Server........................................208
15.3.5 Configuring the LDAP Search Filter Attribute ........................................................209
15.3.6 Configuring Access Level per Management Groups Attributes ............................210
15.3.7 Configuring LDAP Search Methods.......................................................................212
15.3.8 Configuring the Device's LDAP Cache ..................................................................212
15.3.9 Configuring Local Database for Management User Authentication ......................214
15.3.10 LDAP-based Login Authentication Example..........................................................216
15.3.11 Active Directory-based Routing for Microsoft Lync ...............................................219
15.3.11.1 Querying the AD and Routing Priority ................................................... 220
15.3.11.2 Configuring AD-Based Routing Rules ................................................... 223
15.3.11.3 Querying the AD for Calling Name ........................................................ 225
15.4 Least Cost Routing............................................................................................... 226
15.4.1 Overview ................................................................................................................226
User's Manual
6
Document #: LTRT-27034
User's Manual
Contents
15.4.2 Configuring LCR ....................................................................................................228
15.4.2.1 Enabling the LCR Feature ..................................................................... 228
15.4.2.2 Configuring Cost Groups ....................................................................... 230
15.4.2.3 Configuring Time Bands for Cost Groups ............................................. 231
15.4.2.4 Assigning Cost Groups to Routing Rules .............................................. 232
15.5 Configuring Call Setup Rules ............................................................................... 233
15.5.1 Call Setup Rule Examples .....................................................................................237
16 Quality of Experience...................................................................................... 239
16.1 Reporting Voice Quality of Experience to SEM.................................................... 239
16.1.1 Configuring the SEM Server ..................................................................................239
16.1.2 Configuring Clock Synchronization between Device and SEM .............................240
16.1.3 Enabling RTCP XR Reporting to SEM ..................................................................240
16.2 Configuring Quality of Experience Profiles........................................................... 240
16.3 Configuring Bandwidth Profiles ............................................................................ 244
16.4 Configuring Media Enhancement Profiles ............................................................ 247
17 Control Network .............................................................................................. 251
17.1
17.2
17.3
17.4
17.5
17.6
Configuring Media Realms ................................................................................... 251
Configuring Remote Media Subnets .................................................................... 254
Configuring SRDs ................................................................................................ 256
Configuring SIP Interfaces ................................................................................... 258
Configuring IP Groups.......................................................................................... 262
Configuring Proxy Sets ........................................................................................ 272
18 SIP Definitions ................................................................................................. 279
18.1 Configuring SIP Parameters ................................................................................ 279
18.2 Configuring Registration Accounts ....................................................................... 279
18.2.1 Regular Registration Mode ....................................................................................282
18.2.2 Single Registration for Multiple Phone Numbers using GIN..................................282
18.3 Configuring Proxy and Registration Parameters .................................................. 283
18.3.1 SIP Message Authentication Example ..................................................................285
18.4 Configuring SIP Message Manipulation ............................................................... 286
18.5 Configuring SIP Message Policy Rules................................................................ 291
19 Coders and Profiles ........................................................................................ 295
19.1
19.2
19.3
19.4
Configuring Default Coders .................................................................................. 295
Configuring Coder Groups ................................................................................... 298
Configuring Tel Profile.......................................................................................... 299
Configuring IP Profiles ......................................................................................... 302
Gateway Application .............................................................................................329
20 Introduction ..................................................................................................... 331
21 Digital PSTN ..................................................................................................... 333
21.1 Configuring Trunk Settings................................................................................... 333
21.2 TDM and Timing................................................................................................... 336
21.2.1 Configuring TDM Bus Settings ..............................................................................336
21.2.2 Clock Settings ........................................................................................................336
Version 6.8
7
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.2.2.1 Recovering Clock from PSTN Line Interface ........................................ 337
21.2.2.2 Configuring Internal Clock as Clock Source ......................................... 337
21.3 Configuring CAS State Machines......................................................................... 338
21.4 Configuring Digital Gateway Parameters ............................................................. 340
21.5 Tunneling Applications ......................................................................................... 341
21.5.1 TDM Tunneling ......................................................................................................341
21.5.1.1 DSP Pattern Detector ............................................................................ 344
21.5.2 QSIG Tunneling .....................................................................................................344
21.6 ISDN Non-Facility Associated Signaling (NFAS) ................................................. 346
21.6.1
21.6.2
21.6.3
21.6.4
NFAS Interface ID..................................................................................................346
Working with DMS-100 Switches ..........................................................................347
Creating an NFAS-Related Trunk Configuration ...................................................348
Performing Manual D-Channel Switchover in NFAS Group ..................................348
21.7 ISDN Overlap Dialing ........................................................................................... 348
21.7.1 Collecting ISDN Digits and Sending Complete Number in SIP .............................349
21.7.2 Interworking ISDN Overlap Dialing with SIP According to RFC 3578 ...................350
21.8 Redirect Number and Calling Name (Display) ..................................................... 350
22 Trunk Group .................................................................................................... 351
22.1 Configuring Trunk Group Table............................................................................ 351
22.2 Configuring Trunk Group Settings........................................................................ 353
23 Manipulation .................................................................................................... 359
23.1
23.2
23.3
23.4
23.5
23.6
23.7
23.8
Configuring General Settings ............................................................................... 359
Configuring Source/Destination Number Manipulation Rules .............................. 359
Manipulating Number Prefix ................................................................................. 365
SIP Calling Name Manipulations.......................................................................... 366
Configuring Redirect Number IP to Tel ................................................................ 369
Manipulating Redirected and Diverted Numbers for Call Diversion ..................... 373
Mapping NPI/TON to SIP Phone-Context ............................................................ 374
Configuring Release Cause Mapping .................................................................. 375
23.8.1
23.8.2
23.8.3
23.8.4
Fixed Mapping of SIP Response to ISDN Release Reason..................................377
Fixed Mapping of ISDN Release Reason to SIP Response..................................378
Reason Header......................................................................................................381
Mapping PSTN Release Cause to SIP Response ................................................381
23.9 Numbering Plans and Type of Number ................................................................ 382
24 Routing............................................................................................................. 383
24.1
24.2
24.3
24.4
24.5
Configuring General Routing Parameters ............................................................ 383
Configuring Outbound IP Routing Table .............................................................. 383
Configuring Inbound IP Routing Table ................................................................. 392
IP Destinations Connectivity Feature ................................................................... 396
Alternative Routing for Tel-to-IP Calls .................................................................. 398
24.5.1
24.5.2
24.5.3
24.5.4
Alternative Routing Based on IP Connectivity .......................................................398
Alternative Routing Based on SIP Responses ......................................................399
Alternative Routing upon SIP 3xx with Multiple Contacts......................................402
PSTN Fallback .......................................................................................................402
24.6 Alternative Routing for IP-to-Tel Calls .................................................................. 403
24.6.1 Alternative Routing to Trunk upon Q.931 Call Release Cause Code ...................403
24.6.2 Alternative Routing to an IP Destination upon a Busy Trunk ................................404
24.6.3 Alternative Routing upon ISDN Disconnect ...........................................................406
User's Manual
8
Document #: LTRT-27034
User's Manual
Contents
25 Configuring DTMF and Dialing ....................................................................... 407
25.1 Dialing Plan Features ........................................................................................... 408
25.1.1 Digit Mapping .........................................................................................................408
25.1.2 External Dial Plan File ...........................................................................................410
26 Configuring Supplementary Services ........................................................... 411
26.1
26.2
26.3
26.4
26.5
Call Hold and Retrieve ......................................................................................... 413
Call Pickup ........................................................................................................... 415
BRI Suspend and Resume................................................................................... 415
Consultation Feature ............................................................................................ 415
Call Transfer......................................................................................................... 416
26.5.1 Consultation Call Transfer .....................................................................................416
26.5.2 Consultation Transfer for QSIG Path Replacement ..............................................417
26.5.3 Blind Call Transfer .................................................................................................417
26.6 Call Forward ......................................................................................................... 418
26.6.1
26.6.2
26.6.3
26.6.4
Call Forward Reminder Ring .................................................................................419
Call Forward Reminder (Off-Hook) Special Dial Tone ..........................................419
Call Forward Reminder Dial Tone (Off-Hook) upon Spanish SIP Alert-Info..........420
BRI Call Forwarding...............................................................................................420
26.7 Call Waiting .......................................................................................................... 421
26.8 Message Waiting Indication ................................................................................. 422
26.9 Caller ID ............................................................................................................... 423
26.9.1 Caller ID Detection / Generation on the Tel Side ..................................................424
26.9.2 Debugging a Caller ID Detection on FXO..............................................................424
26.9.3 Caller ID on the IP Side .........................................................................................425
26.10 Three-Way Conferencing ..................................................................................... 426
26.11 Emergency E911 Phone Number Services.......................................................... 428
26.11.1 FXS Device Emulating PSAP using DID Loop-Start Lines....................................428
26.11.2 FXO Device Interworking SIP E911 Calls from Service Provider's IP Network to
PSAP DID Lines .................................................................................................................431
26.11.3 Pre-empting Existing Calls for E911 IP-to-Tel Calls ..............................................434
26.11.4 Enhanced 9-1-1 Support for Lync Server 2010 .....................................................435
26.11.4.1 About E9-1-1 Services .......................................................................... 435
26.11.4.2 Microsoft Lync Server 2010 and E9-1-1................................................ 436
26.11.4.3 AudioCodes ELIN Gateway for Lync Server 2010 E9-1-1 Calls to PSTN
440
26.11.4.4 Configuring AudioCodes ELIN Gateway ............................................... 444
26.12 Multilevel Precedence and Preemption................................................................ 447
26.12.1 MLPP Preemption Events in SIP Reason Header ................................................449
26.12.2 Precedence Ring Tone ..........................................................................................450
26.13 Denial of Collect Calls .......................................................................................... 450
26.14 Configuring Multi-Line Extensions and Supplementary Services ......................... 451
26.15 Detecting Collect Calls ......................................................................................... 453
26.16 Advice of Charge Services for Euro ISDN ........................................................... 453
26.17 Configuring Charge Codes................................................................................... 454
26.18 Configuring Voice Mail ......................................................................................... 456
27 Analog Gateway .............................................................................................. 457
27.1 Configuring Keypad Features .............................................................................. 457
27.2 Configuring Metering Tones ................................................................................. 459
Version 6.8
9
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
27.3 Configuring FXO Settings .................................................................................... 459
27.4 Configuring Authentication ................................................................................... 460
27.5 Configuring Automatic Dialing .............................................................................. 462
27.6 Configuring Caller Display Information................................................................. 463
27.7 Configuring Call Forward ..................................................................................... 464
27.8 Configuring Caller ID Permissions ....................................................................... 466
27.9 Configuring Call Waiting....................................................................................... 467
27.10 Rejecting Anonymous Calls ................................................................................. 468
27.11 Configuring FXS Distinctive Ringing and Call Waiting Tones per
Source/Destination Number .......................................................................................... 468
27.12 FXS/FXO Coefficient Types ................................................................................. 470
27.13 FXO Operating Modes ......................................................................................... 470
27.13.1 FXO Operations for IP-to-Tel Calls ........................................................................471
27.13.1.1 One-Stage Dialing ................................................................................. 471
27.13.1.2 Two-Stage Dialing ................................................................................. 472
27.13.1.3 DID Wink ............................................................................................... 472
27.13.2 FXO Operations for Tel-to-IP Calls........................................................................473
27.13.2.1 Automatic Dialing .................................................................................. 473
27.13.2.2 Collecting Digits Mode........................................................................... 474
27.13.2.3 FXO Supplementary Services ............................................................... 474
27.13.3 Call Termination on FXO Devices .........................................................................475
27.13.3.1 Calls Termination by PBX ..................................................................... 475
27.13.3.2 Call Termination before Call Establishment .......................................... 476
27.13.3.3 Ring Detection Timeout ......................................................................... 476
27.14 Remote PBX Extension between FXO and FXS Devices .................................... 476
27.14.1 Dialing from Remote Extension (Phone at FXS) ...................................................477
27.14.2 Dialing from PBX Line or PSTN .............................................................................477
27.14.3 Message Waiting Indication for Remote Extensions .............................................478
27.14.4 Call Waiting for Remote Extensions ......................................................................478
27.14.5 FXS Gateway Configuration ..................................................................................479
27.14.6 FXO Gateway Configuration ..................................................................................480
Session Border Controller Application................................................................481
28 SBC Overview .................................................................................................. 483
28.1 SIP Network Definitions ....................................................................................... 484
28.2 SIP Dialog Initiation Process ................................................................................ 484
28.3 User Registration ................................................................................................. 486
28.3.1
28.3.2
28.3.3
28.3.4
28.3.5
Initial Registration Request Processing .................................................................487
SBC Users Registration Database ........................................................................487
Routing using Users Registration Database..........................................................488
Registration Refreshes ..........................................................................................488
Registration Restriction Control .............................................................................489
28.4 SBC Media Handling ............................................................................................ 489
28.4.1
28.4.2
28.4.3
28.4.4
28.4.5
28.4.6
28.4.7
28.4.8
28.4.9
User's Manual
Media Anchoring without Transcoding (Transparent) ...........................................490
Media Anchoring with Transcoding .......................................................................491
No Media Anchoring ..............................................................................................493
Transcoding Modes ...............................................................................................494
Restricting Coders .................................................................................................495
Coder Transcoding ................................................................................................495
Prioritizing Coder List in SDP Offer .......................................................................497
SRTP-RTP and SRTP-SRTP Transcoding ...........................................................497
Multiple RTP Media Streams per Call Session .....................................................497
10
Document #: LTRT-27034
User's Manual
Contents
28.4.10 Interworking DTMF Methods .................................................................................498
28.5 Fax Negotiation and Transcoding ........................................................................ 498
28.6 Limiting SBC Call Duration................................................................................... 499
28.7 SBC Authentication .............................................................................................. 499
28.7.1 SIP Authentication Server Functionality ................................................................499
28.7.2 User Authentication based on RADIUS .................................................................500
28.8 Interworking SIP Signaling ................................................................................... 500
28.8.1 Interworking SIP 3xx Redirect Responses ............................................................500
28.8.1.1 Resultant INVITE Traversing Device .................................................... 501
28.8.1.2 Local Handling of SIP 3xx ..................................................................... 502
28.8.2 Interworking SIP Diversion and History-Info Headers ...........................................502
28.8.3 Interworking SIP REFER Messages......................................................................503
28.8.4 Interworking SIP PRACK Messages .....................................................................504
28.8.5 Interworking SIP Session Timer ............................................................................504
28.8.6 Interworking SIP Early Media ................................................................................504
28.8.7 Interworking SIP re-INVITE Messages ..................................................................506
28.8.8 Interworking SIP UPDATE Messages ...................................................................506
28.8.9 Interworking SIP re-INVITE to UPDATE................................................................506
28.8.10 Interworking Delayed Offer ....................................................................................506
28.8.11 Interworking Call Hold............................................................................................507
28.9 Call Survivability ................................................................................................... 507
28.9.1 Auto-Provisioning of Subscriber-Specific Information for BroadWorks Server for
Survivability.........................................................................................................................507
28.9.2 BroadSoft's Shared Phone Line Call Appearance for SBC Survivability...............508
28.9.3 Call Survivability for Call Centers ..........................................................................509
28.9.4 Survivability Mode Display on Aastra IP Phones ..................................................511
28.10 Call Forking .......................................................................................................... 512
28.10.1 Initiating SIP Call Forking ......................................................................................512
28.10.2 SIP Forking Initiated by SIP Proxy Server .............................................................512
28.10.3 Call Forking-based IP-to-IP Routing Rules............................................................513
28.11 Alternative Routing on Detection of Failed SIP Response ................................... 514
29 SBC Configuration .......................................................................................... 515
29.1 Configuring General Settings ............................................................................... 515
29.1.1 Interworking Dialog Information in SIP NOTIFY Messages ..................................515
29.2
29.3
29.4
29.5
Configuring Admission Control............................................................................. 517
Configuring Allowed Audio Coder Groups ........................................................... 520
Configuring Allowed Video Coder Groups ........................................................... 522
Routing SBC ........................................................................................................ 522
29.5.1 Configuring Classification Rules ............................................................................522
29.5.1.1 Classification Based on URI of Selected Header Example................... 527
29.5.2 Configuring Message Condition Rules ..................................................................528
29.5.3 Configuring SBC IP-to-IP Routing .........................................................................530
29.5.4 Configuring SIP Response Codes for Alternative Routing Reasons .....................538
29.6 SBC Manipulations............................................................................................... 540
29.6.1 Configuring IP-to-IP Inbound Manipulations ..........................................................542
29.6.2 Configuring IP-to-IP Outbound Manipulations .......................................................545
Cloud Resilience Package ....................................................................................551
Version 6.8
11
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
30 CRP Overview .................................................................................................. 553
31 CRP Configuration .......................................................................................... 555
31.1
31.2
31.3
31.4
Enabling the CRP Application .............................................................................. 555
Configuring Call Survivability Mode ..................................................................... 556
Pre-Configured IP Groups.................................................................................... 557
Pre-Configured IP-to-IP Routing Rules ................................................................ 558
31.4.1 Normal Mode .........................................................................................................558
31.4.2 Emergency Mode...................................................................................................559
31.4.3 Auto Answer to Registrations ................................................................................559
31.5 Configuring PSTN Fallback .................................................................................. 560
Maintenance ...........................................................................................................561
32 Basic Maintenance .......................................................................................... 565
32.1
32.2
32.3
32.4
Resetting the Device ............................................................................................ 565
Remotely Resetting Device using SIP NOTIFY ................................................... 566
Locking and Unlocking the Device ....................................................................... 567
Saving Configuration ............................................................................................ 568
33 Disconnecting Active Calls ............................................................................ 569
34 Replacing Modules.......................................................................................... 571
35 Resetting Channels ......................................................................................... 573
35.1 Resetting an Analog Channel .............................................................................. 573
35.2 Restarting a B-Channel ........................................................................................ 573
36 Software Upgrade............................................................................................ 575
36.1 Loading Auxiliary Files ......................................................................................... 575
36.1.1 Call Progress Tones File .......................................................................................577
36.1.1.1 Distinctive Ringing ................................................................................. 579
36.1.2 Prerecorded Tones File .........................................................................................581
36.1.3 Voice Prompts File.................................................................................................582
36.1.4 CAS Files ...............................................................................................................582
36.1.5 Dial Plan File..........................................................................................................583
36.1.5.1 Creating a Dial Plan File........................................................................ 583
36.1.5.2 External Dial Plan File ........................................................................... 583
36.1.5.3 Dial Plan Prefix Tags for Routing .......................................................... 585
36.1.5.4 Obtaining IP Destination from Dial Plan File ......................................... 589
36.1.5.5 Modifying ISDN-to-IP Calling Party Number ......................................... 590
36.1.6 User Information File .............................................................................................591
36.1.6.1 Enabling the User Info Table ................................................................. 591
36.1.6.2 Gateway User Information for PBX Extensions and "Global" Numbers 591
36.1.6.3 User Information File for SBC User Database ...................................... 595
36.1.7 AMD Sensitivity File ...............................................................................................598
36.2 Software License Key .......................................................................................... 599
36.2.1 Obtaining the Software License Key File...............................................................599
36.2.2 Installing the Software License Key.......................................................................600
36.2.2.1 Installing Software License Key using Web Interface ........................... 600
36.2.2.2 Installing Software License Key using CLI ............................................ 601
36.3 Software Upgrade Wizard .................................................................................... 602
36.4 Backing Up and Loading Configuration File ......................................................... 607
User's Manual
12
Document #: LTRT-27034
User's Manual
Contents
37 Automatic Update Mechanism ....................................................................... 609
37.1 Automatic Configuration Methods ........................................................................ 609
37.1.1 DHCP-based Provisioning .....................................................................................609
37.1.1.1 Provisioning from HTTP Server using DHCP Option 67 ....................... 610
37.1.1.2 Provisioning from TFTP Server using DHCP Option 66 ....................... 611
37.1.2 HTTP-based Provisioning ......................................................................................611
37.1.3 FTP- or NFS-based Provisioning ...........................................................................612
37.1.4 Provisioning using AudioCodes EMS ....................................................................612
37.2 HTTP/S-Based Provisioning using the Automatic Update Feature ...................... 613
37.2.1
37.2.2
37.2.3
37.2.4
37.2.5
37.2.6
37.2.7
37.2.8
37.2.9
Files Provisioned by Automatic Update .................................................................613
File Location for Automatic Update .......................................................................613
Triggers for Automatic Update ...............................................................................614
Access Authentication with HTTP Server ..............................................................615
Querying Provisioning Server for Updated Files ...................................................615
File Download Sequence .......................................................................................617
Cyclic Redundancy Check on Downloaded Configuration Files ...........................618
MAC Address Automatically Inserted in Configuration File Name ........................618
Automatic Update Configuration Examples ...........................................................619
37.2.9.1 Automatic Update for Single Device ..................................................... 619
37.2.9.2 Automatic Update from NFS, FTP and HTTP Servers ......................... 620
37.2.9.3 Automatic Update for Mass Deployment............................................... 621
38 Restoring Factory Defaults ............................................................................ 623
38.1 Restoring Defaults using CLI ............................................................................... 623
38.2 Restoring Defaults using Hardware Reset Button................................................ 624
38.3 Restoring Defaults using an ini File...................................................................... 624
39 Automatic Archiving of Configuration File ................................................... 625
Status, Performance Monitoring and Reporting .................................................627
40 System Status ................................................................................................. 629
40.1 Viewing Device Information.................................................................................. 629
40.2 Viewing Ethernet Port Information ....................................................................... 630
41 Carrier-Grade Alarms ...................................................................................... 631
41.1 Viewing Active Alarms.......................................................................................... 631
41.2 Viewing Alarm History .......................................................................................... 631
42 Performance Monitoring ................................................................................. 633
42.1
42.2
42.3
42.4
Viewing MOS per Media Realm ........................................................................... 633
Viewing Trunk Utilization ...................................................................................... 634
Viewing Quality of Experience ............................................................................. 635
Viewing Average Call Duration ............................................................................ 637
43 VoIP Status ...................................................................................................... 639
43.1
43.2
43.3
43.4
43.5
Viewing Trunks & Channels Status ...................................................................... 639
Viewing Analog Port Information .......................................................................... 640
Viewing NFAS Groups and D-Channel Status ..................................................... 641
Viewing Active IP Interfaces................................................................................. 642
Viewing Ethernet Device Status ........................................................................... 642
Version 6.8
13
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
43.6 Viewing Static Routes Status ............................................................................... 643
43.7 Viewing Performance Statistics............................................................................ 643
43.8 Viewing CDR History............................................................................................ 644
43.9 Viewing Call Counters .......................................................................................... 645
43.10 Viewing Registered Users .................................................................................... 648
43.11 Viewing Registration Status ................................................................................. 649
43.12 Viewing Call Routing Status ................................................................................. 650
43.13 Viewing IP Connectivity........................................................................................ 651
44 Reporting Information to External Party ....................................................... 653
44.1 Configuring RTCP XR .......................................................................................... 653
44.2 Generating Call Detail Records............................................................................ 656
44.2.1 Configuring CDR Reporting ...................................................................................657
44.2.2 CDR Field Description ...........................................................................................657
44.2.2.1 CDR Fields for SBC Signaling .............................................................. 657
44.2.2.2 CDR Fields for SBC Media ................................................................... 660
44.2.2.3 CDR Fields for Gateway/IP-to-IP Application ....................................... 661
44.2.2.4 Release Reasons in CDR ..................................................................... 665
44.3 Configuring RADIUS Accounting ......................................................................... 667
44.4 Event Notification using X-Detect Header ............................................................ 671
44.5 Querying Device Channel Resources using SIP OPTIONS ................................ 674
Diagnostics ............................................................................................................675
45 Syslog and Debug Recordings ...................................................................... 677
45.1 Syslog Message Format ...................................................................................... 677
45.1.1
45.1.2
45.1.3
45.1.4
45.2
45.3
45.4
45.5
Event Representation in Syslog Messages ...........................................................678
Identifying AudioCodes Syslog Messages using Facility Levels ...........................680
Syslog Fields for Answering Machine Detection (AMD) ........................................680
SNMP Alarms in Syslog Messages .......................................................................681
Enabling Syslog ................................................................................................... 681
Configuring Web Operations to Report to Syslog ................................................ 683
Configuring Debug Recording .............................................................................. 683
Filtering Syslog Messages and Debug Recordings ............................................. 684
45.5.1 Filtering IP Network Traces ...................................................................................687
45.6 Viewing Syslog Messages ................................................................................... 688
45.7 Collecting Debug Recording Messages ............................................................... 689
45.8 Debug Capturing on Physical VoIP Interfaces ..................................................... 692
46 Self-Testing ...................................................................................................... 693
47 Creating Core Dump and Debug Files upon Device Crash ......................... 695
48 Analog Line Testing ........................................................................................ 697
48.1 FXO Line Testing ................................................................................................. 697
48.2 FXS Line Testing.................................................................................................. 698
49 Testing SIP Signaling Calls ............................................................................ 699
49.1 Configuring Test Call Endpoints........................................................................... 699
49.2 Starting and Stopping Test Calls.......................................................................... 703
49.3 Viewing Test Call Statistics .................................................................................. 704
User's Manual
14
Document #: LTRT-27034
User's Manual
49.4
49.5
49.6
49.7
Contents
Configuring DTMF Tones for Test Calls............................................................... 705
Configuring Basic Test Call .................................................................................. 706
Configuring SBC Test Call with External Proxy ................................................... 707
Test Call Configuration Examples ........................................................................ 708
Appendix ................................................................................................................711
50 Dialing Plan Notation for Routing and Manipulation.................................... 713
51 Configuration Parameters Reference ............................................................ 715
51.1 Management Parameters..................................................................................... 715
51.1.1
51.1.2
51.1.3
51.1.4
51.1.5
51.1.6
51.1.7
51.1.8
General Parameters ..............................................................................................715
Web Parameters ....................................................................................................716
Telnet Parameters .................................................................................................719
ini File Parameters .................................................................................................719
SNMP Parameters .................................................................................................720
Serial Parameters ..................................................................................................723
Auxiliary and Configuration File Name Parameters ..............................................724
Automatic Update Parameters ..............................................................................725
51.2 Networking Parameters........................................................................................ 728
51.2.1 Ethernet Parameters..............................................................................................728
51.2.2 Multiple VoIP Network Interfaces and VLAN Parameters .....................................729
51.2.3 Routing Parameters ...............................................................................................729
51.2.4 Open Solution Network (OSN) Parameters ...........................................................730
51.2.5 Quality of Service Parameters ...............................................................................730
51.2.6 NAT and STUN Parameters ..................................................................................731
51.2.7 NFS Parameters ....................................................................................................733
51.2.8 DNS Parameters....................................................................................................734
51.2.9 DHCP Parameters .................................................................................................734
51.2.10 NTP and Daylight Saving Time Parameters ..........................................................736
51.3 Debugging and Diagnostics Parameters.............................................................. 738
51.3.1
51.3.2
51.3.3
51.3.4
General Parameters ..............................................................................................738
SIP Test Call Parameters ......................................................................................740
Syslog, CDR and Debug Parameters ....................................................................741
Resource Allocation Indication Parameters...........................................................746
51.4 Security Parameters............................................................................................. 748
51.4.1
51.4.2
51.4.3
51.4.4
51.4.5
51.4.6
General Security Parameters ................................................................................748
HTTPS Parameters ...............................................................................................748
SRTP Parameters..................................................................................................749
TLS Parameters.....................................................................................................751
SSH Parameters ....................................................................................................753
IDS Parameters .....................................................................................................754
51.5 Quality of Experience Parameters ....................................................................... 756
51.6 Control Network Parameters ................................................................................ 758
51.6.1 IP Group, Proxy, Registration and Authentication Parameters .............................758
51.6.2 Network Application Parameters ...........................................................................770
51.7 General SIP Parameters ...................................................................................... 772
51.8 Coders and Profile Parameters ............................................................................ 800
51.9 Channel Parameters ............................................................................................ 803
51.9.1
51.9.2
51.9.3
51.9.4
Version 6.8
Voice Parameters ..................................................................................................803
Coder Parameters .................................................................................................805
DTMF Parameters .................................................................................................806
RTP, RTCP and T.38 Parameters .........................................................................807
15
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
51.10 Gateway and IP-to-IP Parameters ....................................................................... 812
51.10.1 Fax and Modem Parameters .................................................................................812
51.10.2 DTMF and Hook-Flash Parameters.......................................................................817
51.10.3 Digit Collection and Dial Plan Parameters.............................................................822
51.10.4 Voice Mail Parameters...........................................................................................825
51.10.5 Supplementary Services Parameters ....................................................................830
51.10.5.1 Caller ID Parameters ............................................................................. 830
51.10.5.2 Call Waiting Parameters........................................................................ 835
51.10.5.3 Call Forwarding Parameters ................................................................. 837
51.10.5.4 Message Waiting Indication Parameters............................................... 838
51.10.5.5 Call Hold Parameters ............................................................................ 840
51.10.5.6 Call Transfer Parameters ...................................................................... 842
51.10.5.7 Multi-Line Extensions and Supplementary Services Parameters ......... 844
51.10.5.8 Three-Way Conferencing Parameters .................................................. 845
51.10.5.9 MLPP and Emergency Call Parameters ............................................... 847
51.10.5.10 Call Cut-Through Parameters.......................................................... 853
51.10.5.11 Automatic Dialing Parameters ......................................................... 854
51.10.5.12 Direct Inward Dialing Parameters .................................................... 854
51.10.5.13 ISDN BRI Parameters ..................................................................... 856
51.10.6 PSTN Parameters..................................................................................................857
51.10.6.1 General Parameters .............................................................................. 857
51.10.6.2 TDM Bus and Clock Timing Parameters ............................................... 863
51.10.6.3 CAS Parameters ................................................................................... 865
51.10.6.4 ISDN Parameters .................................................................................. 868
51.10.7 ISDN and CAS Interworking Parameters ..............................................................915
51.10.8 Answer and Disconnect Supervision Parameters .................................................931
51.10.9 Tone Parameters ...................................................................................................936
51.10.9.1 Telephony Tone Parameters ................................................................. 936
51.10.9.2 Tone Detection Parameters .................................................................. 943
51.10.9.3 Metering Tone Parameters ................................................................... 944
51.10.10 Telephone Keypad Sequence Parameters ......................................................946
51.10.11 FXO and FXS Parameters ...............................................................................949
51.10.12 Trunk Groups and Routing Parameters ...........................................................953
51.10.13 IP Connectivity Parameters ..............................................................................961
51.10.14 Alternative Routing Parameters .......................................................................962
51.10.15 Number Manipulation Parameters....................................................................965
51.11 SBC Parameters .................................................................................................. 975
51.12 Standalone Survivability Parameters ................................................................... 989
51.13 IP Media Parameters ........................................................................................... 993
51.14 Services ............................................................................................................. 1003
51.14.1 RADIUS and LDAP Parameters ......................................................................... 1003
51.14.1.1 General Parameters ............................................................................ 1003
51.14.1.2 RADIUS Parameters ........................................................................... 1003
51.14.1.3 LDAP Parameters ............................................................................... 1006
51.14.2 Least Cost Routing Parameters ......................................................................... 1008
51.14.3 Call Setup Rules Parameters ............................................................................. 1010
User's Manual
16
Document #: LTRT-27034
User's Manual
Contents
52 SBC and Channel Capacity .......................................................................... 1011
52.1 Signaling-Media Sessions & User Registrations ................................................ 1011
52.2 DSP Templates and Channel Capacity.............................................................. 1013
52.2.1
52.2.2
52.2.3
52.2.4
Analog (FXS/FXO) Interfaces ............................................................................. 1013
BRI Interfaces ..................................................................................................... 1014
E1/T1 Interfaces ................................................................................................. 1015
Media Processing Interfaces .............................................................................. 1016
53 Technical Specifications .............................................................................. 1019
Version 6.8
17
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
18
Document #: LTRT-27034
User's Manual
Notices
Notice
This document describes AudioCodes Mediant 1000B Gateway & Enterprise Session Border
Controller (E-SBC).
Information contained in this document is believed to be accurate and reliable at the time of
printing. However, due to ongoing product improvements and revisions, AudioCodes cannot
guarantee accuracy of printed material after the Date Published nor can it accept responsibility
for errors or omissions. Before consulting this document, check the corresponding Release
Notes regarding feature preconditions and/or specific support in this release. In cases where
there are discrepancies between this document and the Release Notes, the information in the
Release Notes supersedes that in this document. Updates to this document and other
documents as well as software files can be downloaded by registered customers at
http://www.audiocodes.com/downloads.
© Copyright 2014 AudioCodes Ltd. All rights reserved.
This document is subject to change without notice.
Date Published: December-03-2014
Trademarks
AudioCodes, AC, AudioCoded, Ardito, CTI2, CTI², CTI Squared, HD VoIP, HD VoIP
Sounds Better, InTouch, IPmedia, Mediant, MediaPack, NetCoder, Netrake, Nuera, Open
Solutions Network, OSN, Stretto, TrunkPack, VMAS, VoicePacketizer, VoIPerfect,
VoIPerfectHD, What’s Inside Matters, Your Gateway To VoIP and 3GX are trademarks or
registered trademarks of AudioCodes Limited. All other products or trademarks are
property of their respective owners. Product specifications are subject to change without
notice.
WEEE EU Directive
Pursuant to the WEEE EU Directive, electronic and electrical waste must not be disposed
of with unsorted waste. Please contact your local recycling authority for disposal of this
product.
Customer Support
AudioCodes continually strives to produce high quality documentation. If you have any
comments (suggestions or errors) regarding this document, please fill out the
Documentation Feedback form on our Web site at http://www.audiocodes.com/downloads.
Abbreviations and Terminology
Each abbreviation, unless widely used, is spelled out in full when first used.
Version 6.8
19
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Related Documentation
Manual Name
SIP CPE Release Notes
Mediant 1000B Gateway and E-SBC Hardware Installation Manual
Complementary Guides
CLI Reference Guide
CPE Configuration Guide for IP Voice Mail
SNMP Reference Guide
SBC Design Guide
Recommended Security Guidelines Configuration Note
SIP Message Manipulations Quick Reference Guide
SAS Application Configuration Guide
CAS Protocol Table Configuration Note
IP-to-IP Application Configuration Guide
Utility Guides
INI Viewer & Editor Utility User's Guide
DConvert User's Guide
AcBootP Utility User's Guide
CLI Wizard User's Guide
Notes and Warnings
Note: This device is considered an INDOOR unit and therefore, must be installed only
indoors. In addition, FXS and Ethernet port interface cabling must be routed only
indoors and must not exit the building.
Note: The scope of this document does not fully cover security aspects for deploying
the device in your environment. Security measures should be done in accordance
with your organization’s security policies. For basic security guidelines, refer to
AudioCodes Recommended Security Guidelines document.
Note: Throughout this manual, unless otherwise specified, the term device refers to
your AudioCodes product.
User's Manual
20
Document #: LTRT-27034
User's Manual
Notices
Note: Before configuring the device, ensure that it is installed correctly as instructed
in the Hardware Installation Manual.
Notes:
• By default, the device supports export-grade (40-bit and 56-bit) encryption due to
US government restrictions on the export of security technologies. To enable 128bit and 256-bit encryption on your device, contact your AudioCodes sales
representative.
• This device includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit (http://www.openssl.org/).
• This device includes cryptographic software written by Eric Young
(eay@cryptsoft.com).
Note: Some of the features listed in this document are available only if the relevant
Software License Key has been purchased from AudioCodes and installed on the
device. For a list of Software License Keys that can be purchased, please consult
your AudioCodes sales representative.
Note: OPEN SOURCE SOFTWARE. Portions of the software may be open source
software and may be governed by and distributed under open source licenses, such
as the terms of the GNU General Public License (GPL), the terms of the Lesser
General Public License (LGPL), BSD and LDAP, which terms are located at:
http://www.audiocodes.com/support and all are incorporated herein by reference. If
any open source software is provided in object code, and its accompanying license
requires that it be provided in source code as well, Buyer may receive such source
code by contacting AudioCodes, by following the instructions available on
AudioCodes website.
Documentation Feedback
AudioCodes continually strives to produce high quality documentation. If you have any
comments (suggestions or errors) regarding this document, please fill out the
Documentation Feedback form on our Web site at http://www.audiocodes.com/downloads.
Version 6.8
21
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
22
Document #: LTRT-27034
User's Manual
1
1. Overview
Overview
AudioCodes' Mediant 1000B Gateway and E-SBC (hereafter referred to as device) is a
member of AudioCodes family of Enterprise Session Border Controllers (E-SBC), enabling
connectivity and security between small medium businesses (SMB) and service providers'
VoIP networks. The device provides SBC functionality as well as voice-over-IP (VoIP)
media gateway functionality. The device offers enhanced dialing plans and voice routing
capabilities along with SIP-to-SIP mediation, allowing enterprises to implement SIP
Trunking services (IP-to-IP call routing) and IP-based Unified Communications, as well as
flexible PSTN and legacy PBX connectivity.
The device is designed as a secured VoIP platform. Enhanced media gateway security
features include, for example, SRTP for media, TLS for SIP control, and IPSec for
management. A fully featured enterprise-class SBC provides a secured voice network
deployment based on a Back-to-Back User Agent (B2BUA) implementation. The SBC
functionality provides perimeter defense for protecting the enterprise from malicious VoIP
attacks; mediation for allowing the connection of any PBX and/or IP PBX to any service
provider; and service assurance for service quality and manageability.
The device also offers call "survivability" solutions using its Stand Alone Survivability (SAS)
or Cloud Resilience Package applications, ensuring service continuity to enterprises served
by a centralized SIP-based IP-Centrex server or branch offices of distributed enterprises.
Call survivability enables internal office communication between SIP clients in the case of
disconnection from the centralized SIP IP-Centrex server or IP-PBX.
The device also provides an integrated Open Solution Network (OSN) Server module
(based on an Intel CPU). The OSN can host a variety of third-party applications such as IPPBX, Call Center, and Conferencing.
The device supports various telephony interfaces, available according to model (refer to
the Release Notes):

Up to 6 Foreign Exchange Station (FXS) modules, where each module provides 4
FXS port interfaces. This is used for connecting legacy telephones, fax machines, and
modems to the IP network. The FXS interfaces also support an analog Lifeline,
enabling an FXS port to connect directly to the PSTN upon power and/or network
failure.

Up to 6 Foreign Exchange Office (FXO) modules, where each module provides 4 FXO
port interfaces. This is used for connecting analog lines (PBX or PSTN) to the IP
network. When deployed with a combination of FXO and FXS interfaces, the device
can be used as a PBX for small office home office (SOHO) users, and businesses not
equipped with a PBX.

Up to 6E1/8T1 spans, available in 1, 2, or 4 spans per module, for connecting the
PSTN/PBX to the IP network. These modules can be configured with up to 1 or 2
paired spans for switching to the PSTN in case of power or network failure (PSTN
Fallback).

Up to 5 Basic Rate Interface (BRI) modules, where each module provides 4 BRI ports
(therefore, supporting up to 20 BRI digital ports). This is used for connecting BRIbased PSTN or PBX lines to the IP network. The BRI module can be configured for
PSTN Fallback, switching to the PSTN in case of power failure or network problems.

Up to 4 MPM modules for media processing such as announcements and
conferencing.
Note: For maximum call capacity figures, see Section "SBC and Channel Capacity"
on page 1011.
Version 6.8
23
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The device also provides up to 6 Ethernet ports (2 ports on the CRMX module and 4 ports
on the LAN Expansion module). These ports operate in port-pair redundancy, providing up
to 3 port-pair groups. The port groups can be assigned to IP network interfaces enabling
physical separation between interfaces.
The device allows full management through its HTTP/S-based embedded Web server. This
user-friendly Web interface allows remote configuration using any standard Web browser
(such as Microsoft™ Internet Explorer™).
User's Manual
24
Document #: LTRT-27034
Part I
Getting Started with Initial
Connectivity
User's Manual
2
2. Introduction
Introduction
This part describes how to initially access the device's management interface and change
its default IP address to correspond with your networking scheme.
Version 6.8
27
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
28
Document #: LTRT-27034
User's Manual
3
3. Default OAMP IP Address
Default OAMP IP Address
The device is shipped with a factory default IP address for operations, administration,
maintenance, and provisioning (OAMP), through its VoIP LAN interface. You can use this
address to initially access the device from any of its management tools (embedded Web
server, EMS, or Telnet/SSH). You can also access the device through the console CLI, by
connecting the device's serial (RS-232) port to a PC.
The table below lists the device's default IP address.
Table 3-1: Default VoIP LAN IP Address for OAMP
IP Address
Value
Application Type
OAMP + Media + Control
IP Address
192.168.0.2
Prefix Length
255.255.255.0 (24)
Default Gateway
192.168.0.1
Underlying Device
1
Interface Name
"O+M+C"
Version 6.8
29
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
30
Document #: LTRT-27034
User's Manual
4
4. Configuring VoIP LAN Interface for OAMP
Configuring VoIP LAN Interface for OAMP
You can change the IP address of the VoIP-LAN interface for OAMP, using any of the
following methods:
4.1

Embedded HTTP/S-based Web server - see ''Web Interface'' on page 31

Embedded command line interface (CLI) - see ''CLI'' on page 33
Web Interface
The following procedure describes how to change the IP address of the OAMP on the
VoIP-LAN interface, using the Web-based management tool (Web interface). The default
IP address is used to initially access the device.
 To configure the VoIP-LAN IP Address for OAMP, using the Web interface:
1.
Connect one of the Ethernet ports located on the CRMX module directly to the
network interface of your computer, using a straight-through Ethernet cable.
2.
Change the IP address and subnet mask of your computer to correspond with the
default OAMP IP address and subnet mask of the device.
3.
Access the Web interface:
a.
On your computer, start a Web browser and in the URL address field, enter the
default IP address of the device; the Web interface's Web Login screen appears:
Figure 4-1: Web Login Screen
b.
c.
4.
Version 6.8
In the 'Username' and 'Password' fields, enter the case-sensitive, default login
username ("Admin") and password ("Admin").
Click Login.
Open the Physical Ports Settings page (Configuration tab > VoIP menu > Network >
Physical Ports Table) and then configure the device's physical Ethernet port-pair
(group) that you want to later assign to the OAMP interface. For more information, see
Configuring Physical Ethernet Ports on page 109.
31
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
5.
Open the Interface Table page (Configuration tab > VoIP menu > Network > IP
Interfaces Table).
6.
Select the 'Index' radio button corresponding to the OAMP + Media + Control
application type, and then click Edit.
7.
Change the IP address to correspond with your network IP addressing scheme, for
example:
•
IP Address: 10.8.6.86
•
Prefix Length: 24 (for 255.255.255.0)
•
Gateway: 10.8.6.85
•
Underlying Device: Select the Ethernet Device (VLAN and associated Ethernet
port group) for OAMP
8.
Click Submit.
9.
Save your settings by resetting the device with a flash burn (see ''Resetting the
Device'' on page 565).
10. Disconnect the device from the PC and cable the device to your network. You can
now access the management interface using the new OAMP IP address.
Note: When you complete the above procedure, change your PC's IP address to
correspond with your network requirements.
User's Manual
32
Document #: LTRT-27034
User's Manual
4.2
4. Configuring VoIP LAN Interface for OAMP
CLI
This procedure describes how to configure the VoIP-LAN IP address for OAMP using the
device's CLI. The procedure uses the regular CLI commands. Alternatively, you can use
the CLI Wizard utility to set up your device with the initial OAMP settings. The utility
provides a fast-and-easy method for initial configuration of the device through CLI. For
more information, refer to the CLI Wizard User's Guide.
 To configure the OAMP IP address in the CLI:
1.
Connect the RS-232 port of the device to the serial communication port on your
computer. For more information, refer to the Hardware Installation Manual.
2.
Establish serial communication with the device using a terminal emulator program
such as HyperTerminal, with the following communication port settings:
3.
•
Baud Rate: 115,200 bps
•
Data Bits: 8
•
Parity: None
•
Stop Bits: 1
•
Flow Control: None
At the CLI prompt, type the username (default is "Admin" - case sensitive):
Username: Admin
4.
At the prompt, type the password (default is "Admin" - case sensitive):
5.
At the prompt, type the following:
Password: Admin
enable
6.
At the prompt, type the password again:
Password: Admin
7.
Access the VoIP configuration mode:
# configure voip
8.
Access the Interface table:
9.
Configure the IP address:
(config-voip)# interface network-if 0
(network-if-0)# ip-address <IP address>
10. Configure the prefix length:
(network-if-0)# prefix-length <prefix length / subnet mask, e.g., 16>
Version 6.8
33
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
11. Configure the Default Gateway address:
(network-if-0)# gateway <IP address>
12. Exit the Interface table:
(network-if-0)# exit
13. Exit the VoIP configuration mode:
(config-voip)# exit
14. Reset the device with a flash burn:
# reload now
15. Cable the device to your network. You can now access the device's management
interface using this new OAMP IP address.
User's Manual
34
Document #: LTRT-27034
Part II
Management Tools
User's Manual
5
5. Introduction
Introduction
This part provides an overview of the various management tools that can be used to
configure the device. It also provides step-by-step procedures on how to configure these
management tools.
The device provides the following management tools:

Embedded HTTP/S-based Web server - see ''Web-based Management'' on page 39

Command Line Interface (CLI) - see ''CLI-Based Management'' on page 67

Simple Network Management Protocol (SNMP) - see ''SNMP-Based Management'' on
page 76

Configuration ini file - see ''INI File-Based Management'' on page 83
Notes:
• Some configuration settings can only be done using a specific management tool.
For example, some configuration can only be done using the Configuration ini file
method.
• Throughout this manual, whenever a parameter is mentioned, its corresponding
Web, CLI, and ini file parameter is mentioned. The ini file parameters are enclosed
in square brackets [...].
• For a list and description of all the configuration parameters, see ''Configuration
Parameters Reference'' on page 715.
Version 6.8
37
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
38
Document #: LTRT-27034
User's Manual
6
6. Web-Based Management
Web-Based Management
The device provides an embedded Web server (hereafter referred to as Web interface),
supporting fault management, configuration, accounting, performance, and security
(FCAPS), including the following:

Full configuration

Software and configuration upgrades

Loading auxiliary files, for example, the Call Progress Tones file

Real-time, online monitoring of the device, including display of alarms and their
severity

Performance monitoring of voice calls and various traffic parameters
The Web interface provides a user-friendly, graphical user interface (GUI), which can be
accessed using any standard Web browser (e.g., Microsoft™ Internet Explorer).
Access to the Web interface is controlled by various security mechanisms such as login
user name and password, read-write privileges, and limiting access to specific IP
addresses.
Notes:
• The Web interface allows you to configure most of the device's settings. However,
additional configuration parameters may exist that are not available in the Web
interface and which can only be configured using other management tools.
• Some Web interface pages and/or parameters are available only for certain
hardware configurations or software features. The software features are
determined by the installed Software License Key (see ''Software License Key'' on
page 599).
6.1
Getting Acquainted with the Web Interface
This section provides a description of the Web interface.
6.1.1
Computer Requirements
The client computer requires the following to work with the Web interface of the device:

A network connection to the device

One of the following Web browsers:

•
Microsoft™ Internet Explorer™ (Version 6.0 and later)
•
Mozilla Firefox® (Versions 5 through 9.0)
Recommended screen resolutions: 1024 x 768 pixels, or 1280 x 1024 pixels
Note: Your Web browser must be JavaScript-enabled to access the Web interface.
Version 6.8
39
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
6.1.2
Accessing the Web Interface
The following procedure describes how to access the Web interface.
 To access the Web interface:
1.
Open a standard Web browser (see ''Computer Requirements'' on page 39).
2.
In the Web browser, specify the OAMP IP address of the device (e.g.,
http://10.1.10.10); the Web interface's Login window appears, as shown below:
Figure 6-1: Web Login Screen
3.
In the 'Username' and 'Password' fields, enter the case-sensitive, user name and
password respectively.
4.
Click Login; the Web interface is accessed, displaying the Home page. For a detailed
description of the Home page, see ''Viewing the Home Page'' on page 53.
Notes:
• By default, Web access is only through the IP address of the OAMP interface.
However, you can allow access from all of the device's IP network interfaces, by
setting the EnableWebAccessFromAllInterfaces parameter to 1.
• The default login username and password is "Admin". To change the login
credentials, see ''Configuring the Web User Accounts'' on page 56.
• If you want the Web browser to remember your password, select the 'Remember
Me' check box and then agree to the browser's prompt (depending on your
browser) to save the password for future logins. On your next login attempt, simply
press the Tab or Enter keys to auto-fill the 'Username' and 'Password' fields, and
then click Login.
• Depending on your Web browser's settings, a security warning box may be
displayed. The reason for this is that the device's certificate is not trusted by your
PC. The browser may allow you to install the certificate, thus skipping the warning
box the next time you connect to the device. If you are using Windows Internet
Explorer, click View Certificate, and then Install Certificate. The browser also
warns you if the host name used in the URL is not identical to the one listed in the
certificate. To resolve this, add the IP address and host name (ACL_nnnnnn,
where nnnnnn is the serial number of the device) to your hosts file, located at
/etc/hosts on UNIX or C:\Windows\System32\Drivers\ETC\hosts on Windows; then
use the host name in the URL (e.g., https://ACL_280152). Below is an example of
a host file:
127.0.0.1 localhost
10.31.4.47 ACL_280152
User's Manual
40
Document #: LTRT-27034
User's Manual
6.1.3
6. Web-Based Management
Areas of the GUI
The areas of the Web interface's GUI are shown in the figure below and described in the
subsequent table.
Figure 6-2: Main Areas of the Web Interface GUI
Table 6-1: Description of the Web GUI Areas
Item #
Description
1
AudioCodes company logo.
2
Product name.
3
Toolbar, providing frequently required command buttons. For more information, see
''Toolbar Description'' on page 42.
4
Displays the username of the Web user that is currently logged in.
5
Navigation bar, providing the following tabs for accessing various functionalities in
the Navigation tree:
 Configuration, Maintenance, and Status & Diagnostics tabs: Access the
configuration menus (see ''Working with Configuration Pages'' on page 45)
 Search tab: Enables a search engine for searching configuration parameters (see
''Searching for Configuration Parameters'' on page 49)
6
Navigation tree, displaying a tree-like structure of elements (configuration menus or
search engine) pertaining to the selected tab on the Navigation bar. For more
information, see ''Navigation Tree'' on page 42.
7
Work pane, displaying the configuration page of the selected menu in the Navigation
tree. This is where configuration is done. For more information, see ''Working with
Configuration Pages'' on page 45.
Version 6.8
41
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
6.1.4
Toolbar Description
The toolbar provides frequently required command buttons, described in the table below:
Table 6-2: Description of Toolbar Buttons
Icon
Button
Name
Description
Submit
Applies parameter settings to the device (see ''Saving Configuration''
on page 568).
Note: This icon is grayed out when not applicable to the currently
opened page.
Burn
Saves parameter settings to flash memory (see ''Saving
Configuration'' on page 568).
Device Opens a drop-down list with frequently needed commands:
Actions  Load Configuration File: Opens the Configuration File page for
loading an ini file to the device (see ''Backing Up and Loading
Configuration File'' on page 607).
 Save Configuration File: Opens the Configuration File page for
saving the ini file to a folder on your PC (see ''Backing Up and
Loading Configuration File'' on page 607).
 Reset: Opens the Maintenance Actions page for performing
various maintenance procedures such as resetting the device
(see ''Resetting the Device'' on page 565).
 Software Upgrade Wizard: Starts the Software Upgrade Wizard
for upgrading the device's software (see ''Software Upgrade
Wizard'' on page 602).
Home
Help
-
6.1.5
Opens the Home page (see ''Viewing the Home Page'' on page 53).
Opens the Online Help topic of the currently opened configuration
page (see ''Getting Help'' on page 51).
Log off
Logs off a session with the Web interface (see ''Logging Off the Web
Interface'' on page 52).
Reset
If you modify a parameter on a page that takes effect only after a
device reset, after you click the Submit button, the toolbar displays
"Reset". This is a reminder that you need to later save your settings
to flash memory and reset the device.
Navigation Tree
The Navigation tree is located in the Navigation pane and displays a tree-like structure of
menus pertaining to the selected tab on the Navigation bar. You can drill-down to the
required page item level to open its corresponding page in the Work pane.
The terminology used throughout this manual for referring to the hierarchical structure of
the tree is as follows:

Menu: first level (highest level)

Submenu: second level - contained within a menu
User's Manual
42
Document #: LTRT-27034
User's Manual

6. Web-Based Management
Page item: last level (lowest level in a menu) - contained within a menu or submenu
Figure 6-3: Navigating in Hierarchical Menu Tree (Example)
Note: The figure above is used only as an example. The displayed menus depend on
supported features based on the Software License Key installed on your device.
6.1.5.1
Displaying Navigation Tree in Basic and Full View
You can view an expanded or reduced display of the Navigation tree. This affects the
number of displayed menus and submenus in the tree. The expanded view displays all the
menus pertaining to the selected configuration tab; the reduced view displays only
commonly used menus.

Version 6.8
To display a reduced menu tree, select the Basic option (default).
43
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

To display all menus and submenus, select the Advanced option.
Figure 6-4: Basic and Full View Options
Note: After you reset the device, the Web GUI is displayed in Basic view.
6.1.5.2
Showing / Hiding the Navigation Pane
You can hide the Navigation pane to provide more space for elements displayed in the
Work pane. This is especially useful when the Work pane displays a wide table. The arrow
button located below the Navigation bar is used to hide and show the pane.

To hide the Navigation pane, click the left-pointing arrow
the button is replaced by the right-pointing arrow button.

To show the Navigation pane, click the right-pointing arrow
; the pane is
displayed and the button is replaced by the left-pointing arrow button.
; the pane is hidden and
Figure 6-5: Show and Hide Button (Navigation Pane in Hide View)
User's Manual
44
Document #: LTRT-27034
User's Manual
6.1.6
6. Web-Based Management
Working with Configuration Pages
The configuration pages contain the parameters for configuring the device and are
displayed in the Work pane.
6.1.6.1
Accessing Pages
The configuration pages are accessed by clicking the required page item in the Navigation
tree.
 To open a configuration page:
1.
On the Navigation bar, click the required tab (Configuration, Maintenance, or Status
& Diagnostics); the menus pertaining to the selected tab appear in the Navigation
tree.
2.
Navigate to the required page item, by performing the following:
3.
•
Drill-down using the plus
sign to expand the menu and submenus.
•
Drill-up using the minus
sign to collapse the menu and submenus.
Click the required page item; the page opens in the Work pane.
You can also access previously opened pages by clicking the Web browser's Back button
until you have reached the required page. This is useful if you want to view pages in which
you have performed configurations in the current Web session.
Note: Depending on the access level of your Web user account, certain pages may
not be accessible or may be read-only (see ''Configuring Web User Accounts'' on
page 56). If a page is read-only, "Read-Only Mode" is displayed at the bottom of the
page.
6.1.6.2
Viewing Parameters
Some pages allow you to view a reduced or expanded display of parameters. The Web
interface provides two methods for displaying page parameters:

Displaying "basic" and "advanced" parameters - see ''Displaying Basic and Advanced
Parameters'' on page 45

Displaying parameter groups - see ''Showing / Hiding Parameter Groups'' on page 46
6.1.6.2.1 Displaying Basic and Advanced Parameters
Some pages provide a toggle button that allows you to show and hide parameters. This
button is located on the top-right corner of the page and has two display states:

Advanced Parameter List button with down-pointing arrow: click this button to
display all parameters.

Basic Parameter List button with up-pointing arrow: click this button to show only
common (basic) parameters.
Version 6.8
45
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The figure below shows an example of a page displaying basic parameters only. If you
click the Advanced Parameter List button (shown below), the page will also display the
advanced parameters.
Figure 6-6: Toggling between Basic and Advanced View
Notes:
• When the Navigation tree is in Advanced display mode (see ''Navigation Tree'' on
page 42), configuration pages display all their parameters.
• If you reset the device, the Web pages display only the basic parameters.
• The basic parameters are displayed in a different background color to the
advanced parameters.
6.1.6.2.2 Showing / Hiding Parameter Groups
Some pages group parameters under sections, which can be hidden or shown. To toggle
between hiding and showing a group, simply click the group title name that appears above
each group. The button appears with a down-pointing or up-pointing arrow, indicating that it
can be collapsed or expanded when clicked, respectively.
Figure 6-7: Expanding and Collapsing Parameter Groups
User's Manual
46
Document #: LTRT-27034
User's Manual
6.1.6.3
6. Web-Based Management
Modifying and Saving Parameters
When you modify a parameter value on a page, the Edit
icon appears to the right of the
parameter. This indicates that the parameter has been modified, but has yet to be applied
(submitted). After you click Submit the
icon disappears.
Figure 6-8: Edit Symbol after Modifying Parameter Value
 To save configuration changes on a page to the device's volatile memory
(RAM):

On the toolbar, click the Submit

At the bottom of the page, click the Submit
button.
button.
When you click Submit, modifications to parameters with on-the-fly capabilities are
immediately applied to the device and take effect. Parameters displayed on the page with
the lightning
icon take effect only after a device reset. For resetting the device, see
''Resetting the Device'' on page 565.
Note: Parameters saved to the volatile memory (by clicking Submit), revert to their
previous settings after a hardware or software reset, or if the device is powered down.
Thus, to ensure parameter changes (whether on-the-fly or not) are retained, save
('burn') them to the device's non-volatile memory, i.e., flash (see ''Saving
Configuration'' on page 568).
Version 6.8
47
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
If you enter an invalid parameter value (e.g., not in the range of permitted values) and then
click Submit, a message box appears notifying you of the invalid value. In addition, the
parameter value reverts to its previous value and is highlighted in red, as shown in the
figure below:
Figure 6-9: Value Reverts to Previous Valid Value
6.1.6.4
Working with Tables
Many of the Web configuration pages provide tables for configuring various functionalities
of the device. The figure below and subsequent table describe the areas of a typical
configuration table:
Figure 6-10: Displayed Details Pane
Table 6-3: Enhanced Table Design Description
Item #
Button
1
Add
Adds a new index entry row to the table. When you click this button, a
dialog box appears with parameters for configuring the new entry.
When you have completed configuration, click the Submit button in
the dialog box to add it to the table.
2
Edit
Edits the selected row.
3
Delete
User's Manual
Removes the selected row from the table. When you click this button,
a confirmation box appears requesting you to confirm deletion. Click
Delete to accept deletion.
48
Document #: LTRT-27034
User's Manual
6. Web-Based Management
Item #
Button
4
Show/Hide
5
-
Selected index row entry for editing, deleting and showing
configuration.
6
-
Displays the full configuration of the selected row when you click the
Show/Hide button.
7
-
Links to access additional configuration tables related to the current
configuration.
Toggles between displaying and hiding the full configuration of a
selected row. This configuration is displayed below the table (see Item
#6) and is useful for large tables that cannot display all its columns in
the work pane.
Some tables also provide the Up and Down buttons for changing the position (index
number) of a selected table row. These buttons become available only if the table contains
more than one row.
You can also define the number of rows to display on the page and to navigate between
pages displaying multiple rows. This is done using the page navigation area located below
the table, as shown in the figure below:
Figure 6-11: Viewing Table Rows per Page
Table 6-4: Row Display and Page Navigation
Item #
Description
1
Defines the page that you want to view. Enter the required page number or use the
following page navigation buttons:

- Displays the next page

- Displays the last page

- Displays the previous page

- Displays the first page
2
Defines the number of rows to display per page. You can select 5 or 10, where the
default is 10.
3
Displays the currently displayed page number.
6.1.7
Searching for Configuration Parameters
You can locate the exact Web page on which a specific parameter appears, by using the
Search feature. To search for a Web parameter, you must use the ini file parameter name
as the search key. The search key can include the full parameter name (e.g.,
"EnableSyslog") or a substring of it (e.g., "sys"). If you search for a substring, all
parameters containing the specified substring in their names are listed in the search result.
Version 6.8
49
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To search for a parameter:
1.
On the Navigation bar, click the Search tab; the Search engine appears in the
Navigation pane.
2.
In the field alongside the Search button, enter the parameter name or a substring of
the name for which you want to search. If you have done a previous search for such a
parameter, instead of entering the required string, you can use the 'Search History'
drop-down list to select the string saved from a previous search.
3.
Click Search; a list of found parameters based on your search key appears in the
Navigation pane. Each searched result displays the following:
4.
•
ini file parameter name
•
Link (in green) to the Web page on which the parameter appears
•
Brief description of the parameter
•
Menu navigation path to the Web page on which the parameter appears
In the searched list, click the required parameter (green link) to open the page on
which the parameter appears; the relevant page opens in the Work pane and the
searched parameter is highlighted in the page for easy identification, as shown in the
figure below:
Figure 6-12: Searched Result Screen
Table 6-5: Search Description
Item #
Description
1
Search field for entering search key and Search button for activating the search
process.
2
Search results listed in Navigation pane.
3
Found parameter, highlighted on relevant Web page
User's Manual
50
Document #: LTRT-27034
User's Manual
6.1.8
6. Web-Based Management
Creating a Login Welcome Message
You can create a Welcome message box that is displayed on the Web Login page. The
figure below displays an example of a Welcome message:
Figure 6-13: User-Defined Web Welcome Message after Login
To enable and create a Welcome message, use the WelcomeMessage table ini file
parameter, as described in the table below. If this parameter is not configured, no Welcome
message is displayed.
Table 6-6: ini File Parameter for Welcome Login Message
Parameter
[WelcomeMessage]
6.1.9
Description
Enables and defines a Welcome message that appears on the Web Login
page for logging in to the Web interface.
The format of this parameter is as follows:
[WelcomeMessage]
FORMAT WelcomeMessage_Index = WelcomeMessage_Text;
[\WelcomeMessage]
For Example:
[WelcomeMessage ]
FORMAT WelcomeMessage_Index = WelcomeMessage_Text;
WelcomeMessage 1 = "*********************************";
WelcomeMessage 2 = "********* This is a Welcome message **";
WelcomeMessage 3 = "*********************************";
[\WelcomeMessage]
Each index row represents a line of text in the Welcome message box. Up
to 20 lines (or rows) of text can be defined.
Getting Help
The Web interface provides you with context-sensitive Online Help. The Online Help
provides brief descriptions of parameters pertaining to the currently opened page.
Version 6.8
51
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To view the Help topic of a currently opened page:
1.
On the toolbar, click the Help
page appears, as shown below:
button; the Help topic pertaining to the opened
Figure 6-14: Help Topic for Current Page
2.
To view a description of a parameter, click the plus
To collapse the description, click the minus
sign.
3.
To close the Help topic, click the close
sign to expand the parameter.
button located on the top-right corner of
the Help topic window or simply click the Help
button.
Note: Instead of clicking the Help button for each page you open, you can open it
once for a page and then simply leave it open. Each time you open a different page,
the Help topic pertaining to that page is automatically displayed.
6.1.10 Logging Off the Web Interface
The following procedure describes how to log off the Web interface.
 To log off the Web interface:
1.
On the toolbar, click the Log Off
appears:
icon; the following confirmation message box
Figure 6-15: Log Off Confirmation Box
2.
User's Manual
Click OK; you are logged off the Web session and the Web Login dialog box appears
enabling you to re-login, if required.
52
Document #: LTRT-27034
User's Manual
6.2
6. Web-Based Management
Viewing the Home Page
The Home page is displayed when you access the device's Web interface. The Home page
provides you with a graphical display of the device's front panel, showing color-coded
status icons for various operations device.
 To access the Home page:

On the toolbar, click the Home
icon.
Note: The displayed number and type of telephony interfaces depends on the
ordered hardware configuration.
In addition to the color-coded status information depicted on the graphical display of the
device, the Home page displays various read-only information in the General Information
pane:

IP Address: IP address of the device

Subnet Mask: Subnet mask address of the device

Default Gateway Address: Default gateway used by the device

Digital Port Number: Number of digital PRI ports (depending on ordered hardware
configuration)

BRI Port Number: Number of BRI ports (depending on ordered hardware
configuration))

Analog Port Number: Number of analog (FXS and FXO) ports (depending on
ordered hardware configuration)

Firmware Version: Software version running on the device

Protocol Type: Signaling protocol currently used by the device (i.e. SIP)

Gateway Operational State:
•
"LOCKED": device is locked (i.e. no new calls are accepted)
•
"UNLOCKED": device is not locked
•
"SHUTTING DOWN": device is currently shutting down
To perform these operations, see ''Basic Maintenance'' on page 565.
Version 6.8
53
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The table below describes the areas of the Home page.
Table 6-7: Home Page Description
Item #
1
Description
Displays the highest severity of an active alarm raised (if any) by the device:
Green: No alarms
Red: Critical alarm
Orange: Major alarm
Yellow: Minor alarm
To view active alarms, click the Alarms area to open the Active Alarms page (see
Viewing Active Alarms on page 631).




2
Module slot number.
3
Module type (e.g., FXS, FXO, and DIGITAL)
4
Module status icon:
5

(green): Module has been inserted or is correctly configured

(gray): Module was removed and "Reserved" is displayed

(red): Module failure and "Failure" is displayed
Port (trunk or channel) status icon.
Icon
(grey)
Trunk Description
(Digital Module)
Disable: Trunk not configured (not
in use)
Idle: Channel is currently onhook
Active - OK: Trunk synchronized
Call Connected: Active RTP
stream
(green)
(yellow)
(red)
(blue)
Channel Description
(Analog Module)
RAI Alarm: Remote Alarm Indication (RAI), also known as the Yellow
Alarm
LOS / LOF Alarm: Loss due to LOS
(Loss of Signal) or LOF (Loss of
Frame)
Not Connected: No analog
line is connected to this port
or port out of service due to
Serial Peripheral Interface
(SPI) failure (applicable only
to FXO interfaces)
AIS Alarm: Alarm Indication Signal
(AIS), also known as the Blue Alarm
Handset Offhook: Channel is
off-hook, but there is no
active RTP session
D-Channel Alarm: D-channel alarm
-
NFAS Alarm
-
(light orange)
(dark orange)
If you click a port, a shortcut menu appears with commands allowing you to do the
following:
 Reset channel (Analog ports only): Resets the analog port (see Resetting an
Analog Channel on page 573)
User's Manual
54
Document #: LTRT-27034
User's Manual
6. Web-Based Management
Item #
Description

Port Settings: Displays trunk status (see ''Viewing Trunk and Channel Status'' on
page 639) and analog port status (see ''Viewing Analog Port Information'' on page
640)
 Update Port Info: Assigns a name to the port (see ''Assigning a Port Name'' on
page 55)
6
Ethernet port status icons:

(green): Ethernet link is working

(gray): Ethernet link is not connected
To view detailed Ethernet port information, click these icons to open the Ethernet
Port Information page (see Viewing Ethernet Port Information on page 630).
7
CRMX module for data.
8
Fan tray unit status icon:
9

(green): Fan tray operating

(red): Fan tray failure
Power Supply Unit 1 status icon:

(green): Power supply is operating

(red): Power supply failure or no power supply unit installed
10
Power Supply Unit 2 status indicator. See Item #8 for a description.
11
SWX LAN expansion module, providing 4 Ethernet ports operating in port-pair group
redundancy.
6.2.1
Assigning a Port Name
You can configure an arbitrary name or a brief description for each telephony port
displayed on the Home page. This description is displayed as a tooltip when you hover
your mouse over the port.
Note: Only alphanumerical characters can be used in the port description.
 To add a port description:
1.
Open the Home page.
2.
Click the required port icon; a shortcut menu appears:
3.
From the shortcut menu, choose Update Port Info; a text box appears:
4.
Type a brief description for the port, and then click Apply Port Info.
Version 6.8
55
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
6.3
Configuring Web User Accounts
Web user accounts define users for the Web interface and CLI. User accounts permit login
access to these interfaces as well as different levels of read and write privileges. Thus,
user accounts prevent unauthorized access to these interfaces, permitting access only to
users with correct credentials (i.e., username and password).
Each user account is based on the following:

Username and password: Credentials that enable authorized login access to the
Web interface.

User level (user type): Access privileges specifying what the user can view in the
Web interface and its read/write privileges. The table below describes the different
types of Web user account access levels:
Table 6-8: Web User Access Levels and Privileges
User Level
Numeric
Representation in
RADIUS
Privileges
Security
Administrator
200
Read / write privileges for all pages. It can create all user
types and is the only one that can create the first Master
user.
Note: At least one Security Administrator user must exits.
Master
220
Read / write privileges for all pages. Can create all user
types, including additional Master users and Security
Administrators. It can delete all users except the last
Security Administrator.
Administrator
100
Read / write privileges for all pages, except securityrelated pages (read-only).
Monitor
50
No access to security-related and file-loading pages;
read-only access to all other pages.
No Access
0
No access to any page.
Note: This access level is not applicable when using
advanced Web user account configuration in the Web
Users table.
By default, the device is pre-configured with the following two Web user accounts:
Table 6-9: Pre-configured Web User Accounts
User Access Level
Security Administrator
Monitor
Username
(Case-Sensitive)
Password
(Case-Sensitive)
Admin
Admin
User
User
After you log in to the Web interface, the username is displayed on the toolbar.
If the Web session is idle (i.e., no actions are performed) for more than five minutes, the
Web session expires and you are once again requested to login with your username and
password. Users can be blocked for a period of time upon a user-defined number of
unsuccessful login attempts. Login information (such as how many login attempts were
made and the last successful login time) can be presented to the user.
User's Manual
56
Document #: LTRT-27034
User's Manual
6. Web-Based Management
 To prevent user access after a specific number of failed logins:
1.
From the 'Deny Access On Fail Count' drop-down list, select the number of failed
logins after which the user is prevented access to the device for a user-defined time
(see next step).
2.
In the 'Deny Authentication Timer' field, enter the interval (in seconds) that the user
needs to wait before a new login attempt from the same IP address can be done after
reaching the number of failed login attempts (defined in the previous step).
Notes:
• For security, it's recommended that you change the default username and
password of the pre-configured users (i.e., Security Administrator and Monitor
users).
• The Security Administrator user can change all attributes of all Web user
accounts. Web users with access levels other than Security Administrator can
change only their password and username.
• To restore the two Web user accounts to default settings (usernames and
passwords), set the ini file parameter ResetWebPassword to 1.
• To log in to the Web interface with a different Web user, click the Log off button
and then login with with a different username and password.
• You can set the entire Web interface to read-only (regardless of Web user access
levels), by using the ini file parameter DisableWebConfig (see ''Web and Telnet
Parameters'' on page 715).
• You can define additional Web user accounts using a RADIUS server (see
''RADIUS Authentication'' on page 65).
6.3.1
Basic User Accounts Configuration
This section describes basic Web user account configuration. This is relevant only if the
two default, pre-configured Web user accounts--Security Administrator ("Admin") and
Monitor ("User")--are sufficient for your management scheme.
The Web user account parameters that can be modified depends on the access level of the
currently logged-in Web user:
Table 6-10: Allowed Modifications per Web User Level
Logged-in User
Web User Level
Allowed Modifications
Security
Administrator
(Default) Security Administrator
Username and password
Monitor
Username, password, and access level
Monitor
(Default) Security Administrator
None
Monitor
Username and password
Notes:
• The username and password can be a string of up to 19 characters and are casesensitive.
• When only the basic user accounts are being used, up to two users can be
concurrently logged in to the Web interface, and they can be the same user.
Version 6.8
57
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure the two pre-configured Web user accounts:
1.
Open the Web User Accounts page (Configuration tab > System menu > Web User
Accounts). If you are logged in as Security Administrator, both Web user accounts
are displayed (as shown below). If you are logged in with the second user account,
only the details of this user account are displayed.
Figure 6-16: WEB User Accounts Page (for Users with 'Security Administrator' Privileges)
2.
To change the username of an account:
a.
b.
c.
3.
To change the password of an account:
a.
b.
c.
d.
4.
In the 'Current Password' field, enter the current password.
In the 'New Password' and 'Confirm New Password' fields, enter the new
password.
Click Change Password; if you are currently logged in to the Web interface with
this account, the 'Web Login' dialog box appears.
Log in with your new password.
To change the access level of the optional, second account:
a.
b.
User's Manual
In the 'User Name' field, enter the new user name.
Click Change User Name; if you are currently logged in to the Web interface with
this account, the 'Web Login' dialog box appears.
Log in with your new user name.
Under the Account Data for User: User group, from the 'Access Level' dropdown list, select a new access level user.
Click Change Access Level; the new access level is applied immediately.
58
Document #: LTRT-27034
User's Manual
6.3.2
6. Web-Based Management
Advanced User Accounts Configuration
The Web Users table lets you configure advanced Web user accounts. This configuration
is relevant only if you need the following management schemes:

Enhanced security settings per Web user (e.g., limit session duration)

More than two Web user accounts (up to 10 Web user accounts)

Master users
Notes:
• Only the Security Administrator user can initially access the Web Users table.
• Only Security Administrator and Master users can add, edit, or delete users.
• Admin users have read-only privileges in the Web Users table; Monitor users have
no access to this table.
• For advanced user accounts, up to five users can be concurrently logged in to the
Web interface, and they can be the same user.
• If you delete a user who is currently in an active Web session, the user is
immediately logged off by the device.
• All users can change their own passwords. This is done in the WEB Security
Settings page (see ''Configuring Web Security Settings'' on page 63).
• To remove the Web Users table and revert to the Web User Accounts page with
the pre-configured, default Web user accounts, set the ResetWebPassword ini file
parameter to 1. This also deletes all other Web users.
• Once the Web Users table is accessed, Monitor users and Admin users can only
change their passwords in the Web Security Settings page (see ''Configuring Web
Security Settings'' on page 63). The new password must have at least four
different characters than the previous password. (The Security Administrator users
and Master users can change their passwords in the Web Users table and in the
Web Security Settings page.)
The following procedure describes how to configure Web users in the Web interface. You
can also configure this using the CLI command web-users.
 To add Web user accounts with advanced settings:
1.
Open the Web Users Table page:
•
Upon initial access:
a. Open the Web User Accounts page (Configuration tab > System menu >
Web User Accounts).
b. Under the Web Users Table group, click the Create Table button.
•
Subsequent access: Configuration tab > System menu > Web User Accounts.
The Web Users table appears, listing the two default, pre-configured Web use
accounts - Security Administrator ("Admin") and Monitor ("User"):
Figure 6-17: Web Users Table Page
Version 6.8
59
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
2.
Click Add; the following dialog box is displayed:
Figure 6-18: Web Users Table - Add Record Dialog Box
3.
Configure a Web user according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 6-11: Web User Table Parameter Descriptions
Parameter
Description
Index
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Web: Username
CLI: user-name
Defines the Web user's username.
The valid value is a string of up to 40 alphanumeric characters,
including the period ".", underscore "_", and hyphen "-" signs.
Web: Password
CLI: password
Defines the Web user's password.
The valid value is a string of 8 to 40 ASCII characters, which must
adhere to the following guidelines:
 Include at least eight characters.
 Include at least two letters that are upper case (e.g., A).
 Include at least two letters that are lower case (e.g., a).
 Include at least two numbers (e.g., 4).
 Include at least two symbols (non-alphanumeric characters) (e.g., $,
#, %).
 Must contain no spaces.
 Include at least four new characters that were not used in the
previous password.
User's Manual
60
Document #: LTRT-27034
User's Manual
6. Web-Based Management
Parameter
Description
Web: Status
CLI: status
Defines the status of the Web user.
 New = (Default) User is required to change its password on the next
login. When the user logs in to the Web interface, the user is
immediately prompted to change the current password.
 Valid = User can log in to the Web interface as normal.
 Failed Access = This state is automatically set for users that exceed
a user-defined number of failed login attempts, set by the 'Deny
Access on Fail Count' parameter (see ''Configuring Web Security
Settings'' on page 63). These users can log in only after a userdefined timeout configured by the 'Block Duration' parameter (see
below) or if their status is changed (to New or Valid) by a System
Administrator or Master.
 Old Account = This state is automatically set for users that have not
accessed the Web interface for a user-defined number of days, set
by the 'User Inactivity Timer' (see ''Configuring Web Security
Settings'' on page 63). These users can only log in to the Web
interface if their status is changed (to New or Valid) by a System
Administrator or Master.
Notes:
 The Old Account status is applicable only to Admin and Monitor
users; System Administrator and Master users can be inactive
indefinitely.
 For security, it is recommended to set the status of a newly added
user to New in order to enforce password change.
Web: Password Age
CLI: pw-age-interval
Defines the duration (in days) of the validity of the password. When this
duration elapses, the user is prompted to change the password;
otherwise, access to the Web interface is blocked.
The valid value is 0 to 10000, where 0 means that the password is
always valid. The default is 90.
Web: Session Limit
CLI: session-limit
Defines the maximum number of Web interface sessions allowed for
the user. In other words, this allows the same user account to log in to
the device from different sources (i.e., IP addresses).
The valid value is 0 to 5. The default is 2.
Note: Up to 5 users can be concurrently logged in to the Web interface.
Web: Session Timeout
CLI: session-timeout
Defines the duration (in minutes) of Web inactivity of a logged-in user,
after which the user is automatically logged off the Web interface.
The valid value is 0 to 100000. The default value is according to the
settings of the 'Session Timeout' global parameter (see ''Configuring
Web Security Settings'' on page 63).
Web: Block Duration
CLI: block-time
Defines the duration (in seconds) for which the user is blocked when
the user exceeds a user-defined number of failed login attempts. This is
configured by the 'Deny Access On Fail Count' parameter (see
''Configuring Web Security Settings'' on page 63).
The valid value is 0 to 100000, where 0 means that the user can do as
many login failures without getting blocked. The default is according to
the settings of the 'Deny Authentication Timer' parameter (see
''Configuring Web Security Settings'' on page 63).
Note: The 'Deny Authentication Timer' parameter relates to failed Web
logins from specific IP addresses.
Version 6.8
61
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Web: User Level
CLI: user-level
6.4
Description
Defines the user's access level.
 Monitor = (Default) Read-only user. This user can only view Web
pages and access to security-related pages is denied.
 Administrator = Read/write privileges for all pages, except securityrelated pages including the Web Users table where this user has
only read-only privileges.
 Security Administrator = Read/write privileges for all pages. This
user is the Security Administrator.
 Master = Read/write privileges for all pages. This user also functions
as a security administrator.
Notes:
 At least one Security Administrator must exist. The last remaining
Security Administrator cannot be deleted.
 The first Master user can be added only by a Security Administrator
user.
 Additional Master users can be added, edited and deleted only by
Master users.
 If only one Master user exists, it can be deleted only by itself.
 Master users can add, edit, and delete Security Administrators (but
cannot delete the last Security Administrator).
 Only Security Administrator and Master users can add, edit, and
delete Administrator and Monitor users.
Displaying Login Information upon Login
The device can display login information immediately upon Web login.
 To enable display of user login information upon a successful login:
1.
Open the WEB Security Settings page (Configuration tab > System menu >
Management > WEB Security Settings).
2.
From the 'Display Login Information' drop-down list, select Yes.
3.
Click Submit.
Once enabled, the Login Information window is displayed upon a successful login, as
shown in the example below:
Figure 6-19: Login Information Window
User's Manual
62
Document #: LTRT-27034
User's Manual
6.5
6. Web-Based Management
Configuring Web Security Settings
The WEB Security Settings page is used to configure security for the device's Web
interface.
By default, the device accepts HTTP and HTTPS access. However, you can enforce
secure Web access communication method by configuring the device to accept only
HTTPS.
For a description of these parameters, see ''Web and Telnet Parameters'' on page 715.
 To define Web access security:
1.
Open the WEB Security Settings page (Configuration tab > System menu >
Management > WEB Security Settings).
2.
Set the 'Secured Web Connection (HTTPS)' parameter to HTTPS Only.
3.
Configure the parameters as required.
4.
Click Submit.
5.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
Version 6.8
63
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
6.6
Web Login Authentication using Smart Cards
You can enable Web login authentication using certificates from a third-party, common
access card (CAC) with user identification. When a user attempts to access the device
through the Web browser (HTTPS), the device retrieves the Web user’s login username
(and other information, if required) from the CAC. The user attempting to access the device
is only required to provide the login password. Typically, a TLS connection is established
between the CAC and the device’s Web interface, and a RADIUS server is implemented to
authenticate the password with the username. Therefore, this feature implements a twofactor authentication - what the user has (i.e., the physical card) and what the user knows
(i.e., the login password).
This feature is enabled using the EnableMgmtTwoFactorAuthentication parameter.
Note: For specific integration requirements for implementing a third-party smart card
for Web login authentication, contact your AudioCodes representative.
 To log in to the Web interface using CAC:
6.7
1.
Insert the Common Access Card into the card reader.
2.
Access the device using the following URL: https://<host name or IP address>; the
device prompts for a username and password.
3.
Enter the password only. As some browsers require that the username be provided,
it’s recommended to enter the username with an arbitrary value.
Configuring Web and Telnet Access List
The Web & Telnet Access List page is used to define IP addresses (up to ten) that are
permitted to access the device's Web, Telnet, and SSH interfaces. Access from an
undefined IP address is denied. If no IP addresses are defined, this security feature is
inactive and the device can be accessed from any IP address. The Web and Telnet Access
List can also be defined using the ini file parameter WebAccessList_x (see ''Web and
Telnet Parameters'' on page 715).
 To add authorized IP addresses for Web, Telnet, and SSH interfaces access:
1.
Open the Web & Telnet Access List page (Configuration tab > System menu >
Management > Web & Telnet Access List).
Figure 6-20: Web & Telnet Access List Page - Add New Entry
User's Manual
64
Document #: LTRT-27034
User's Manual
2.
6. Web-Based Management
To add an authorized IP address, in the 'Add an authorized IP address' field, enter the
required IP address, and then click Add New Entry; the IP address you entered is
added as a new entry to the Web & Telnet Access List table.
Figure 6-21: Web & Telnet Access List Table
3.
To delete authorized IP addresses, select the Delete Row check boxes corresponding
to the IP addresses that you want to delete, and then click Delete Selected
Addresses; the IP addresses are removed from the table and these IP addresses can
no longer access the Web and Telnet interfaces.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
Notes:
• The first authorized IP address in the list must be your PC's (terminal) IP address;
otherwise, access from your PC is denied.
• Delete your PC's IP address last from the 'Web & Telnet Access List page. If it is
deleted before the last, subsequent access to the device from your PC is denied.
Version 6.8
65
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
66
Document #: LTRT-27034
User's Manual
7
7. CLI-Based Management
CLI-Based Management
This chapter provides an overview of the CLI-based management and provides
configuration relating to CLI management.
Notes:
• For security, CLI is disabled by default.
• For a description of the CLI commands, refer to the CLI Reference Guide.
7.1
Getting Familiar with CLI
This section describes the basic structure of the device's CLI, which you may need to know
before configuring the device through CLI.
7.1.1
Understanding Configuration Modes
Before you begin your CLI session, you should familiarize yourself with the CLI command
modes. Each command mode provides different levels of access to commands, as
described below:

Basic command mode: This is the initial mode that is accessed upon a successful
CLI login authentication. Any user level can access this mode and thus, the
commands supported by this command tier are limited, as is interaction with the
device itself. This mode allows you to view various information (using the show
commands) and activate various debugging capabilities.
Welcome to AudioCodes CLI
Username: Admin
Password:
>
The Basic mode prompt is ">".

Enable command mode: This mode is the high-level tier in the command hierarchy,
one step up from the Basic Mode. A password ("Admin", by default) is required to
access this mode after you have accessed the Basic mode. This mode allows you to
configure all the device's settings. The Enable mode is accessed by typing the
following commands:
> enable
Password: <password>
#
The Enable mode prompt is "#".
Notes:
• The enable command is required only for users with Administrator or Monitor
access levels; Security Administrator and Master access levels automatically enter
Enable mode upon initial login. For configuring user access levels, see
Configuring Web User Accounts on page 56.
• The default password for accessing the Enable mode is "Admin" (case-sensitive).
To change this password, use the CLIPrivPass ini file parameter.
Version 6.8
67
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The Enable mode groups the configuration commands under the following command
sets:
7.1.2
•
config-system: Provides the general and system related configuration
commands, for example, Syslog configuration. This set is accessed by typing the
following command:
# configure system
(config-system)#
•
config-voip: Provides the VoIP-related configuration commands, for example,
SIP and media parameters, and VoIP network interface configuration. This set is
accessed by typing the following command:
# configure voip
(config-voip)#
Using CLI Shortcuts
The CLI provides several editing shortcut keys to help you configure your device more
easily, as listed in the table below.
Table 7-1: CLI Editing Shortcut keys
Shortcut Key
Description
Up arrow key
Retypes the previously entered command. Continuing to press the Up
arrow key cycles through all commands entered, starting with the most
recent command.
<Tab> key
Pressing the <Tab> key after entering a partial (but unique) command
automatically completes the command, displays it on the command prompt
line, and waits for further input.
Pressing the <Tab> key after entering a partial and not unique command
displays all completing options.
? (question mark)

<Ctrl + A>
Moves the cursor to the beginning of the command line.
<Ctrl + E>
Moves the cursor to the end of the command line.
User's Manual
Displays a list of all subcommands in the current mode, for example:
(config-voip)# voip-network ?
dns
Enter voip-network dns
ip-group IP Group table
nat-translation
NATTranslationtable
...
 Displays a list of available commands beginning with certain letter(s),
for example:
(config)# voip-network d?
dns
Enter voip-network dns
 Displays syntax help for a specific command by entering the command,
a space, and then a question mark (?). This includes the range of valid
values and a brief description of the next parameter expected for that
particular command. For example:
(config)# voip-network dns srv2ip ?
[0-9]
index
If a command can be invoked (i.e., all its arguments have been entered),
the question mark at its end displays "<cr>" to indicate that a carriage
return (Enter) can now be entered to run the command, for example:
(config)# logging host 10.1.1.1 ?
<cr>
68
Document #: LTRT-27034
User's Manual
7. CLI-Based Management
Shortcut Key
<Ctrl + U>
Description
Deletes all the characters on the command line.
auto finish
You need only enter enough letters to identify a command as unique. For
example, entering "int G 0/0" at the configuration prompt provides you
access to the configuration parameters for the specified Gigabit-Ethernet
interface. Entering "interface GigabitEthernet 0/0" would work as well, but is
not necessary.
Space Bar at the --More- Displays the next screen of output. You can configure the size of the
-prompt
displayed output, as described in ''Configuring Displayed Output Lines in
CLI Terminal Window'' on page 76.
7.1.3
Common CLI Commands
The following table contains descriptions of common CLI commands.
Table 7-2: Common CLI Commands
Command
Description
do
Provides a way to execute commands in other command sets without taking the
time to exit the current command set. The following example shows the do
command, used to view the GigabitEthernet interface configuration while in the
virtual-LAN interface command set:
(config)# interface vlan 1
(conf-if-VLAN 1)# do show interfaces GigabitEthernet 0/0
no
Undoes an issued command or disables a feature. Enter no before the
command:
# no debug log
activate
Activates a command. When you enter a configuration command in the CLI, the
command is not applied until you enter the activate and exit commands.
Note: Offline configuration changes require a reset of the device. A reset can be
performed at the end of the configuration changes. A required reset is indicated
by an asterisk (*) before the command prompt.
exit
Leaves the current command-set and returns one level up. If issued on the top
level, the session ends.
For online parameters, if the configuration was changed and no activate
command was entered, the exit command applies the activate command
automatically. If issued on the top level, the session will end:
(config)# exit
# exit
(session closed)
display
help
history
list
| <filter>
Version 6.8
Displays the configuration of current configuration set.
Displays a short help how-to string.
Displays a list of previously run commands.
Displays the available command list of the current command-set.
Applied to a command output. The filter should be typed after the command with
a pipe mark (|).
Supported filters:
 include <word> – filter (print) lines which contain <word>
69
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Command
Description





exclude <word> – filter lines which does not contain <word>
grep <options> - filter lines according to grep common Unix utility options
egrep <options> - filter lines according to egrep common Unix utility options
begin <word> – filter (print) lines which begins with <word>
between <word1> <word2> – filter (print) lines which are placed between
<word1> and <word2>
 count – show the output’s line count
Example:
# show system version | grep Number
;Serial Number: 2239835;Slot Number: 1
7.1.4
Configuring Tables in CLI
Throughout the CLI, many configuration elements are in table format, where each table row
is represented by an index number. When you add a new row to a table, the device
automatically assigns it the next consecutive, available index number. You can also specify
an index number, if required. When you add a new table row, the device accesses the
row's configuration mode.
Table rows are added using the new command:
# <table name> new
For example, if three rows are configured in the Account table (account-0, account-1, and
account-2) and a new entry is subsequently added, account-3 is automatically created and
its configuration mode is accessed:
(config-voip)# sip-definition account new
(account-3)#
You can also add a new table row to any specific index number, even if a row has already
been configured for that index number. The row that was previously assigned that index
number is subsequently incremented to the next index number, as well as all the index
rows listed further down in the table.
To add a new table row to a specific index number, use the insert command:
# <table name> <index> insert
For example, if three rows are configured in the Account table (account-0, account-1, and
account-2) and a new row is subsequently added with index 1, the previous account-1
becomes account-2 and the previous account-2 becomes account-3, and so on. The
following command is run for this example:
(config-voip)# sip-definition account 1 insert
Note: This behavior when inserting table rows is applicable only to tables that do not
have "child" tables (sub-tables).
7.1.5
Understanding CLI Error Messages
The CLI provides feedback on commands by displaying informative messages:

User's Manual
Failure reason of a run command. The failure message is identical to the notification
failure message sent by Syslog. For example, an invalid Syslog server IP address is
displayed in the CLI as follows:
(logging)# syslog-ip 1111.1.1.1
Parameter 'SyslogServerIP' does NOT accept the IP-Address:
70
Document #: LTRT-27034
User's Manual
7. CLI-Based Management
1111.1.1.1, illegal IPAddress.
Configuration failed
Command Failed!
7.2

"Invalid command" message: The command may not be valid in the current command
mode, or you may not have entered sufficient characters for the command to be
recognized. Use "?" to determine your error.

"Incomplete command" message: You may not have entered all of the pertinent
information required to make the command valid. Use "?" to determine your error.
Enabling CLI
Access to the device's CLI through Telnet and SSH is disabled by default. This section
describes how to enable these protocols.
7.2.1
Enabling Telnet for CLI
The following procedure describes how to enable Telnet. You can enable a secured Telnet
that uses Secure Socket Layer (SSL) where information is not transmitted in the clear. If
SSL is used, a special Telnet client is required on your PC to connect to the Telnet
interface over a secured connection; examples include C-Kermit for UNIX and Kermit-95
for Windows.
For security, some organizations require the display of a proprietary notice upon starting a
Telnet session. You can use the configuration ini file parameter, WelcomeMessage to
configure such a message (see ''Creating a Login Welcome Message'' on page 51).
 To enable Telnet:
1.
Open the Telnet/SSH Settings page (Configuration tab > System menu >
Management > Telnet/SSH Settings).
2.
Set the ‘Embedded Telnet Server’ parameter to Enable Unsecured or Enable
Secured (i.e, SSL).
3.
Configure the other Tenet parameters as required. For a description of these
parameters, see ''Telnet Parameters'' on page 719.
4.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
Version 6.8
71
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
7.2.2
Enabling SSH with RSA Public Key for CLI
Unless configured for TLS, Telnet is not secure as it requires passwords to be transmitted
in clear text. To overcome this, Secure SHell (SSH) is used, which is the de-facto standard
for secure CLI. SSH 2.0 is a protocol built above TCP, providing methods for key
exchange, authentication, encryption, and authorization.
SSH requires appropriate client software for the management PC. Most Linux distributions
have OpenSSH pre-installed; Windows-based PCs require an SSH client software such as
PuTTY,
which
can
be
downloaded
from
http://www.chiark.greenend.org.uk/~sgtatham/putty/.
By default, SSH uses the same username and password as the Telnet and Web server.
SSH supports 1024/2048-bit RSA public keys, providing carrier-grade security. Follow the
instructions below to configure the device with an administrator RSA key as a means of
strong authentication.
 To enable SSH and configure RSA public keys for Windows (using PuTTY SSH
software):
1.
Start the PuTTY Key Generator program, and then do the following:
a.
b.
c.
d.
Under the 'Parameters' group, do the following:
♦
Select the SSH-2 RSA option.
♦
In the 'Number of bits in a generated key' field, enter "1024" bits.
Under the 'Actions' group, click Generate and then follow the on-screen
instructions.
Under the 'Actions' group, click Save private key to save the new private key to a
file (*.ppk) on your PC.
Under the 'Key' group, select the displayed encoded text between "ssh-rsa" and
"rsa-key-….", as shown in the example below:
Figure 7-1: Selecting Public RSA Key in PuTTY
2.
Open the Telnet/SSH Settings page (Configuration tab > System menu >
Management > Telnet/SSH Settings), and then do the following:
a.
b.
User's Manual
Set the 'Enable SSH Server' parameter to Enable.
Paste the public key that you copied in Step 1.d into the 'Admin Key' field, as
shown below:
72
Document #: LTRT-27034
User's Manual
7. CLI-Based Management
c.
d.
e.
f.
3.
Configure the other SSH parameters as required. For a description of these
parameters, see ''SSH Parameters'' on page 753.
Click Submit.
Start the PuTTY Configuration program, and then do the following:
a.
b.
4.
For additional security, you can set the 'Require Public Key' to Enable. This
ensures that SSH access is only possible by using the RSA key and not by using
user name and password.
In the 'Category' tree, drill down to Connection, then SSH, and then Auth; the
'Options controlling SSH authentication' pane appears.
Under the 'Authentication parameters' group, click Browse and then locate the
private key file that you created and saved in Step 4.
Connect to the device with SSH using the username "Admin"; RSA key negotiation
occurs automatically and no password is required.
 To configure RSA public keys for Linux (using OpenSSH 4.3):
7.3
1.
Run the following command to create a new key in the admin.key file and to save the
public portion to the admin.key.pub file:
ssh-keygen -f admin.key -N "" -b 1024
2.
Open the admin.key.pub file, and then copy the encoded string from "ssh-rsa" to the
white space.
3.
Open the Telnet/SSH Settings page (Configuration tab > System menu >
Management > Telnet/SSH Settings), and then paste the value copied in Step 2 into
the 'Admin Key' field.
4.
Click Submit.
5.
Connect to the device with SSH, using the following command:
ssh -i admin.key xx.xx.xx.xx
where xx.xx.xx.xx is the device's IP address. RSA-key negotiation occurs
automatically and no password is required.
Establishing a CLI Session
The device's CLI can be accessed using any of the following methods:

RS-232: The device can be accessed through its RS-232 serial port, by connecting a
VT100 terminal to it or using a terminal emulation program (e.g., HyperTerminal) with
a PC. For connecting to the CLI through RS-232, see ''CLI'' on page 33.

Secure SHell (SSH): The device can be accessed through its Ethernet interface by
the SSH protocol using SSH client software. A popular and freeware SSH client
software is Putty, which can be downloaded from
www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
Version 6.8
73
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Telnet: The device can be accessed through its Ethernet interface by the Telnet
protocol using Telnet client software.The following procedure describes how to
establish a CLI session with the device.
The following procedure describes how to access the CLI through Telnet/SSH.
Note: The CLI login credentials are the same as all the device's other management
interfaces (such as Web interface). The default username and password is "Admin"
and "Admin" (case-sensitive), respectively. For configuring login credentials, see
''Configuring Web User Accounts'' on page 56.
 To establish a CLI session with the device:
1.
Connect the device to the network.
2.
Establish a Telnet or SSH session using the device's OAMP IP address.
3.
Log in to the session using the username and password assigned to the Admin user of
the Web interface:
a.
b.
c.
d.
7.4
At the Username prompt, type the username, and then press Enter:
Username: Admin
At the Password prompt, type the password, and then press Enter:
Password: Admin
At the prompt, type the following, and then press Enter:
> enable
At the prompt, type the password again, and then press Enter:
Password: Admin
Configuring Maximum Telnet/SSH Sessions
You can set the maximum (up to five) number of concurrent Telnet/SSH sessions permitted
on the device.
Note: Before changing this setting, make sure that not more than this number of
sessions are currently active; otherwise, the new setting will not take effect.
 To configure the maximum number of concurrent Telnet/SSH sessions:
1.
Open the Telnet/SSH Settings page (Configuration tab > System menu >
Management > Telnet/SSH Settings).
2.
In the 'Maximum Telnet Sessions' field, enter the maximum number of concurrent
sessions.
3.
Click Submit.
User's Manual
74
Document #: LTRT-27034
User's Manual
7.5
7. CLI-Based Management
Viewing and Terminating Current CLI Sessions
You can view and terminate users that are currently logged in to the device's CLI. This
applies to users logged in to the CLI through RS-232 (console), Telnet, or SSH. For each
logged-in user, the following is displayed: the type of interface (console, Telnet, or SSH),
user's username, remote IP address from where the user logged in, and the duration (days
and time) of the session. Each user is displayed with a unique index (session ID).
 To view currently logged-in CLI users:
# show users
[0] console
Admin
local
0d00h03m15s
[1] telnet
John
10.4.2.1
0d01h03m47s
[2]* ssh
Alex
192.168.121.234
12d00h02m34s
The current session from which this show command was run is displayed with an asterisk
(*).
Note: The device can display management sessions of up to 24 hours. After this time,
the duration counter is reset.
 To end the CLI session of a specific CLI user:
# clear user <session ID>
When this command is run, it ends the Telnet/SSH session (logs out the RS-232 session)
and displays the CLI login prompt.
Note: The session from which the command is run cannot be terminated.
Version 6.8
75
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
7.6
Configuring Displayed Output Lines in CLI Terminal
Window
You can configure the maximum number of lines (height) displayed in the terminal window
for the output of CLI commands (Telnet and SSH). The number of displayed lines can be
specified from 0 to 65,535, or determined by re-sizing the terminal window by mousedragging the window's border.
 To configure a specific number of output lines:
(config-system)# cli-terminal
<cli-terminal># window-height [0-65535]
If window-height is set to 0, the entire command output is displayed. In other words, even if
the output extends beyond the visible terminal window length, the --MORE-- prompt is not
displayed.
 To configure the number of lines according to dragged terminal window:
(config-system)# cli-terminal
<cli-terminal># window-height automatic
When this mode is configured, each time you change the height of the terminal window
using your mouse (i.e., dragging one of the window's borders or corners), the number of
displayed output command lines is changed accordingly.
User's Manual
76
Document #: LTRT-27034
User's Manual
8
8. SNMP-Based Management
SNMP-Based Management
The device provides an embedded SNMP Agent that allows it to be managed by
AudioCodes Element Management System (EMS) or a third-party SNMP Manager (e.g.,
element management system). The SNMP Agent supports standard Management
Information Base (MIBs) and proprietary MIBs, enabling a deeper probe into the
interworking of the device. The SNMP Agent can also send unsolicited events (SNMP
traps) towards the SNMP Manager. All supported MIB files are supplied to customers as
part of the release.
AudioCodes EMS is an advanced solution for standards-based management that covers all
areas vital for the efficient operation, administration, management and provisioning
(OAM&P) of the device. The standards-compliant EMS uses distributed SNMP-based
management software, optimized to support day-to-day Network Operation Center (NOC)
activities, offering a feature-rich management framework. It supports fault management,
configuration and security.
This section provides configuration relating to SNMP management.
Notes:
• SNMP-based management is enabled by default. For disabling it, see ''Enabling
SNMP and Configuring SNMP Community Strings'' on page 77.
• For more information on the device's SNMP support (e.g., SNMP traps), refer to
the SNMP User's Guide.
• EMS support is available only if the device is installed with a Software License Key
that includes this feature. For installing a Software License Key, see ''Software
License Key'' on page 599.
• For more information on using the EMS tool, refer to the EMS User's Manual and
EMS Server IOM Manual.
8.1
Enabling SNMP and Configuring SNMP Community
Strings
The SNMP Community String page lets you configure up to five read-only and up to five
read-write SNMP community strings and to configure the community string that is used for
sending traps.
For detailed descriptions of the SNMP parameters, see ''SNMP Parameters'' on page 720.
Version 6.8
77
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure SNMP community strings:
1.
Open the SNMP Community String page (Configuration tab > System menu >
Management > SNMP > SNMP Community String).
2.
Configure SNMP community strings according to the table below.
3.
Click Submit, and then save ("burn") your settings to flash memory.
To delete a community string, select the Delete check box corresponding to the community
string that you want to delete, and then click Submit.
Table 8-1: SNMP Community String Parameter Descriptions
Parameter
Community String
Description

Read Only [SNMPReadOnlyCommunityString_x]: Up to five
read-only community strings (up to 19 characters each). The
default string is 'public'.
 Read / Write [SNMPReadWriteCommunityString_x]: Up to
five read / write community strings (up to 19 characters each).
The default string is 'private'.
Trap Community String
Community string used in traps (up to 19 characters).
CLI: configure system > snmp
The default string is 'trapuser'.
trap > community-string
[SNMPTrapCommunityString]
8.2
Configuring SNMP Trap Destinations
The SNMP Trap Destinations page allows you to configure up to five SNMP trap
managers. You can associate a trap destination with SNMPv2 users and specific SNMPv3
users. Associating a trap destination with SNMPv3 users sends encrypted and
authenticated traps to the SNMPv3 destination. By default, traps are sent unencrypted
using SNMPv2.
User's Manual
78
Document #: LTRT-27034
User's Manual
8. SNMP-Based Management
 To configure SNMP trap destinations:
1.
Open the SNMP Trap Destinations page (Configuration tab > System menu >
Management > SNMP > SNMP Trap Destinations).
Figure 8-1: SNMP Trap Destinations Page
2.
Configure the SNMP trap manager parameters according to the table below.
3.
Select the check box corresponding to the SNMP Manager that you wish to enable.
4.
Click Submit.
Note: Only row entries whose corresponding check boxes are selected are applied
when clicking Submit; otherwise, settings revert to their defaults.
Table 8-2: SNMP Trap Destinations Parameters Description
Parameter
Description
Web: SNMP Manager
[SNMPManagerIsUsed_x]
Enables the SNMP Manager to receive traps and checks
the validity of the configured destination (IP address and
port number).
 [0] (check box cleared) = (Default) Disables SNMP
Manager
 [1] (check box selected) = Enables SNMP Manager
Web: IP Address
[SNMPManagerTableIP_x]
Defines the IP address (in dotted-decimal notation, e.g.,
108.10.1.255) of the remote host used as the SNMP
Manager. The device sends SNMP traps to this IP
address.
Trap Port
[SNMPManagerTrapPort_x]
Defines the port number of the remote SNMP Manager.
The device sends SNMP traps to this port.
The valid value range is 100 to 4000. The default is 162.
Web: Trap User
[SNMPManagerTrapUser]
Associates a trap user with the trap destination. This
determines the trap format, authentication level, and
encryption level.
 v2cParams (default) = SNMPv2 user community string
 SNMPv3 user configured in ''Configuring SNMP V3
Users'' on page 80
Trap Enable
Activates the sending of traps to the SNMP Manager.
[SNMPManagerTrapSendingEnable_x]  [0] Disable
 [1] Enable (Default)
Version 6.8
79
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
8.3
Configuring SNMP Trusted Managers
The SNMP Trusted Managers table lets you configure up to five SNMP Trusted Managers
based on IP addresses. By default, the SNMP agent accepts SNMP Get and Set requests
from any IP address as long as the correct community string is used in the request.
Security can be enhanced by using Trusted Managers, which is an IP address from which
the SNMP agent accepts and processes SNMP requests.
The following procedure describes how to configure SNMP trusted managers in the Web
interface. You can also configure this using the table ini file parameter,
SNMPTrustedMgr_x or CLI command, configure system > snmp > trusted-managers.
 To configure SNMP Trusted Managers:
1.
Open the SNMP Trusted Managers page (Configuration tab > System menu >
Management > SNMP > SNMP Trusted Managers).
Figure 8-2: SNMP Trusted Managers
8.4
2.
Select the check box corresponding to the SNMP Trusted Manager that you want to
enable and for whom you want to define an IP address.
3.
Define an IP address in dotted-decimal notation.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Configuring SNMP V3 Users
The SNMP v3 Users table lets you configure up to 10 SNMP v3 users for authentication
and privacy.
The following procedure describes how to configure SNMP v3 users in the Web interface.
You can also configure this using the table ini file parameter, SNMPUsers or CLI
command, configure system > snmp v3-users.
User's Manual
80
Document #: LTRT-27034
User's Manual
8. SNMP-Based Management
 To configure an SNMP v3 user:
1.
Open the SNMP v3 Users page (Configuration tab > System menu > Management
> SNMP > SNMP V3 Users).
2.
Click Add; the following dialog box appears:
Figure 8-3: SNMP V3 Setting Page - Add Record Dialog Box
3.
Configure the SNMP V3 Setting parameters according to the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Note: If you delete a user that is associated with a trap destination (see ''Configuring
SNMP Trap Destinations'' on page 78), the configured trap destination becomes
disabled and the trap user reverts to default (i.e., SNMPv2).
Table 8-3: SNMP V3 Users Parameters
Parameter
Description
Index
[SNMPUsers_Index]
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
User Name
CLI: username
[SNMPUsers_Username]
Name of the SNMP v3 user. This name must be unique.
Authentication Protocol
Authentication protocol of the SNMP v3 user.
CLI: auth-protocol
 [0] None (default)
[SNMPUsers_AuthProtocol]  [1] MD5
 [2] SHA-1
Privacy Protocol
CLI: priv-protocol
[SNMPUsers_PrivProtocol]
Privacy protocol of the SNMP v3 user.
 [0] None (default)
 [1] DES
 [2] 3DES
 [3] AES-128
 [4] AES-192
 [5] AES-256
Authentication Key
Authentication key. Keys can be entered in the form of a text
Version 6.8
81
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
CLI: auth-key
[SNMPUsers_AuthKey]
password or long hex string. Keys are always persisted as long hex
strings and keys are localized.
Privacy Key
CLI: priv-key
[SNMPUsers_PrivKey]
Privacy key. Keys can be entered in the form of a text password or
long hex string. Keys are always persisted as long hex strings and
keys are localized.
Group
CLI: group
[SNMPUsers_Group]
User's Manual
The group with which the SNMP v3 user is associated.
[0] Read-Only (default)
[1] Read-Write
[2] Trap
Note: All groups can be used to send traps.



82
Document #: LTRT-27034
User's Manual
9
9. INI File-Based Management
INI File-Based Management
The device can be configured using an ini file, which is a text-based file with an ini file
extension name that can be created using any standard text-based editor such as
Notepad. Each configuration element of the device has a corresponding ini file parameter
that you can use in the ini file for configuring the device. When you have created the ini file
with your ini file parameter settings, you apply these settings to the device by installing
(loading) the ini file to the device.
Notes:
• For a list and description of the ini file parameters, see ''Configuration Parameters
Reference'' on page 715.
• To restore the device to default settings using the ini file, see ''Restoring Factory
Defaults'' on page 623.
9.1
INI File Format
The ini file can be configured with any number of parameters. These ini file parameters can
be one of the following types:
9.1.1

Individual parameters - see ''Configuring Individual ini File Parameters'' on page 83

Table parameters - see ''Configuring Table ini File Parameters'' on page 83
Configuring Individual ini File Parameters
The syntax for configuring individual ini file parameters in the ini file is as follows:

An optional, subsection name (or group name) enclosed in square brackets "[...]". This
is used to conveniently group similar parameters by their functionality.

Parameter name, followed by an equal "=" sign and then its value.
 Comments must be preceded by a semicolon ";".
[subsection name]
parameter name = value
parameter name = value
; this is a comment line
; for example:
[System Parameters]
SyslogServerIP = 10.13.2.69
EnableSyslog = 1
For general ini file formatting rules, see ''General ini File Formatting Rules'' on page 85.
9.1.2
Configuring Table ini File Parameters
The table ini file parameters allow you to configure tables, which include multiple
parameters (columns) and row entries (indices). When loading an ini file to the device, it's
recommended to include only tables that belong to applications that are to be configured
(dynamic tables of other applications are empty, but static tables are not).
The table ini file parameter is composed of the following elements:

Title of the table: The name of the table in square brackets, e.g.,
[MY_TABLE_NAME].

Format line: Specifies the columns of the table (by their string names) that are to be
Version 6.8
83
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
configured.


•
The first word of the Format line must be "FORMAT", followed by the Index field
name and then an equal "=" sign. After the equal sign, the names of the columns
are listed.
•
Columns must be separated by a comma ",".
•
The Format line must only include columns that can be modified (i.e., parameters
that are not specified as read-only). An exception is Index fields, which are
mandatory.
•
The Format line must end with a semicolon ";".
Data line(s): Contain the actual values of the columns (parameters). The values are
interpreted according to the Format line.
•
The first word of the Data line must be the table’s string name followed by the
Index field.
•
Columns must be separated by a comma ",".
•
A Data line must end with a semicolon ";".
End-of-Table Mark: Indicates the end of the table. The same string used for the
table’s title, preceded by a backslash "\", e.g., [\MY_TABLE_NAME].
The following displays an example of the structure of a table ini file parameter.
[Table_Title]
; This is the title of the table.
FORMAT Index = Column_Name1, Column_Name2, Column_Name3;
; This is the Format line.
Index 0 = value1, value2, value3;
Index 1 = value1, $$, value3;
; These are the Data lines.
[\Table_Title]
; This is the end-of-the-table-mark.
The table ini file parameter formatting rules are listed below:

Indices (in both the Format and the Data lines) must appear in the same order. The
Index field must never be omitted.

The Format line can include a subset of the configurable fields in a table. In this case,
all other fields are assigned with the pre-defined default values for each configured
line.

The order of the fields in the Format line isn’t significant (as opposed to the Index
fields). The fields in the Data lines are interpreted according to the order specified in
the Format line.

The double dollar sign ($$) in a Data line indicates the default value for the parameter.

The order of the 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 must be in exactly the same order.

A row in a table is identified by its table name and Index field. Each such row may
appear only once in the ini file.

Table dependencies: Certain tables may depend on other tables. For example, one
table may include a field that specifies an entry in another table. This method is used
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 the order of their dependency (i.e., if Table X
is referred to by Table Y, Table X must appear in the ini file before Table Y).
For general ini file formatting rules, see ''General ini File Formatting Rules'' on page 85.
The table below displays an example of a table ini file parameter:
[ CodersGroup0 ]
FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime,
CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce;
User's Manual
84
Document #: LTRT-27034
User's Manual
9. INI File-Based Management
CodersGroup0 0 = g711Alaw64k, 20, 0, 255, 0;
CodersGroup0 1 = eg711Ulaw, 10, 0, 71, 0;
[ \CodersGroup0 ]
Note: Do not include read-only parameters in the table ini file parameter as this can
cause an error when attempting to load the file to the device.
9.1.3
General ini File Formatting Rules
The ini file must adhere to the following formatting rules:
9.2

The ini file name must not include hyphens "-" or spaces; if necessary, use an
underscore "_" instead.

Lines beginning with a semi-colon ";" are ignored. These can be used for adding
remarks in the ini file.

A carriage return (i.e., Enter) must be done at the end of each line.

The number of spaces before and after the equals sign "=" is irrelevant.

Subsection names for grouping parameters are optional.

If there is a syntax error in the parameter name, the value is ignored.

Syntax errors in the parameter's value can cause unexpected errors (parameters may
be set to the incorrect values).

Parameter string values that denote file names (e.g., CallProgressTonesFileName)
must be enclosed with inverted commas, e.g., CallProgressTonesFileName =
'cpt_usa.dat'.

The parameter name is not case-sensitive.

The parameter value is not case-sensitive, except for coder names.

The ini file must end with at least one carriage return.
Configuring an ini File
There are different methods that you can use for configuring the ini file before you load it to
the device.

Modifying the device's current ini file. This method is recommended if you mainly need
to change the settings of parameters that you have previously configured.
1.
2.
3.
4.

Save the device's current configuration as an ini file on your computer, using the
Web interface (see ''Saving Configuration'' on page 568).
Open the file using a text file editor, and then modify the ini file as required.
Save and close the file.
Load the file to the device.
Creating a new ini file that includes only updated configuration:
1. Open a text file editor such as Notepad.
2. Add only the required parameters and their settings.
3. Save the file with the ini file extension name (e.g., myconfiguration.ini).
4. Load the file to the device.
For loading the ini file to the device, see ''Loading an ini File to the Device'' on page 86.
Version 6.8
85
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Note: To restore the device to default settings using the ini file, see ''Restoring
Factory Defaults'' on page 623.
9.3
Loading an ini File to the Device
You can load an ini file to the device using the following methods:

CLI:
•

Voice Configuration: # copy voice-configuration from <URL>
Web interface:
•
Load Auxiliary Files page (see ''Loading Auxiliary Files'' on page 575): The device
updates its configuration according to the loaded ini file, while preserving the
remaining current configuration.
•
Configuration File page (see ''Backing Up and Loading Configuration File'' on
page 607): The device updates its configuration according to the loaded ini file,
and applies default values to parameters that were not included in the loaded ini
file. Thus, all previous configuration is overridden.
When you load an ini file to the device, its configuration settings are saved to the device's
non-volatile memory.
Note: Before you load an ini file to the device, make sure that the file extension name
is .ini.
9.4
Secured Encoded ini File
The ini file contains sensitive information that is required for the functioning of the device.
The file may be loaded to the device using HTTP. These protocols are not secure and are
vulnerable to potential hackers. To overcome this security threat, the AudioCodes
DConvert utility allows you to binary-encode (encrypt) the ini file before loading it to the
device. For more information, refer to the DConvert Utility User's Guide.
Note: If you save an ini file from the device to a folder on your PC, an ini file that was
loaded to the device encoded is saved as a regular ini file (i.e., unencoded).
User's Manual
86
Document #: LTRT-27034
User's Manual
9.5
9. INI File-Based Management
Configuring Password Display in ini File
Passwords can be displayed in the ini file in one of the following formats, configured by the
INIPasswordsDisplayType ini file parameter:

Obscured: The password characters are concealed and displayed as encoded. The
password is displayed using the syntax, $1$<obscured password>, for example,
$1$S3p+fno=.

Hidden: the password is replaced with an asterisk (*).
When you save an ini file from the device to a PC, the passwords are displayed according
to the enabled format. When you load an ini file to the device, obscured passwords are
parsed and applied to the device; hidden passwords are ignored.
By default, the enabled format is obscured passwords, thus enabling their full recovery in
case of configuration restore or copy to another device.
When obscured password mode is enabled, you can enter a password in the ini file using
any of the following formats:

$1$<obscured password>: Password in obscured format as generated by the device;
useful for restoring device configuration and copying configuration from one device to
another.

$0$<plain text>: Password can be entered in plain text; useful for configuring a new
password. When the ini file is loaded to the device and then later saved from the
device to a PC, the password is displayed obscured (i.e., $1$<obscured password>).
Version 6.8
87
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
9.6
INI Viewer and Editor Utility
AudioCodes INI Viewer & Editor utility provides a user-friendly graphical user interface
(GUI) that lets you easily view and modify the device's ini file. This utility is available from
AudioCodes Web site at www.AudioCodes.com/downloads, and can be installed on any
Windows-based PC.
For more information, refer to the INI Viewer & Editor User's Guide.
User's Manual
88
Document #: LTRT-27034
Part III
General System Settings
User's Manual
10
10. Configuring SSL/ TLS Certificates
Configuring SSL/ TLS Certificates
The TLS Contexts page lets you configure X.509 certificates, which are used for secure
management of the device, secure SIP transactions, and other security applications.
Notes:
• The device is shipped with an active, default TLS setup. Thus, configure
certificates only if required.
• Since X.509 certificates have an expiration date and time, you must configure the
device to use Network Time Protocol (NTP) to obtain the current date and time
from an NTP server. Without the correct date and time, client certificates cannot
work. For configuring NTP, see Configuring Automatic Date and Time using SNTP
on page 103.
10.1.1 Configuring TLS Certificate Contexts
The TLS Contexts table lets you configure up to 15 TLS certificates, referred to as TLS
Contexts. The Transport Layer Security (TLS), also known as Secure Socket Layer (SSL),
is used to secure the device's SIP signaling connections, Web interface, and Telnet server.
The TLS/SSL protocol provides confidentiality, integrity, and authenticity between two
communicating applications over TCP/IP. TLS Contexts are applicable to Gateway and
SBC calls.
The device is shipped with a default TLS Context (ID 0 and string name "default"), which
includes a self-generated random private key and a self-signed server certificate. The
subject name for the default certificate is "ACL_nnnnnnn", where nnnnnnn denotes the
serial number of the device. The default TLS Context can be used for SIP over TLS (SIPS)
or any other supported application such as Web (HTTPS), Telnet, and SSH.The default
TLS Context cannot be deleted.
The user-defined TLS Contexts are used only for SIP over TLS (SIPS). This enables you
to use different TLS certificates for your IP Groups (SIP entities). This is done by assigning
a specific TLS Context to the Proxy Set and/or SIP Interface associated with the IP Group.
Each TLS Context can be configured with the following:

Context ID and name

TLS version - SSL 2.0 (only for TLS handshake), SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2)

Encryption ciphers for server and client - DES, RC4 compatible, Advanced Encryption
Standard (AES)

Online Certificate Status Protocol (OCSP). Some Public-Key Infrastructures (PKI) can
revoke a certificate after it has been issued. You can configure the device to check
whether a peer's certificate has been revoked, using the OCSP. When OCSP is
enabled, the device queries the OCSP server for revocation information whenever a
peer certificate is received (IPSec, TLS client mode, or TLS server mode with mutual
authentication).

Private key - externally created and then uploaded to device

X.509 certificates - self-signed certificates or signed as a result of a certificate signing
request (CSR)

Trusted root certificate authority (CA) store (for validating certificates)
Version 6.8
91
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
When the device establishes a TLS connection (handshake) with a SIP user agent (UA),
the TLS Context is determined as follows:

Incoming calls:
1.
2.
3.

Proxy Set: If the incoming call is successfully classified to an IP Group based on
Proxy Set (i.e., IP address of calling party) and the Proxy Set is configured for
TLS ('Transport Type' parameter is set to TLS), the TLS Context assigned to the
Proxy Set is used. For configuring Proxy Sets, see Configuring Proxy Sets on
page 272.
SIP Interface: If the Proxy Set is either not configured for TLS (i.e., the 'Transport
Type' parameter is set to UDP) or not assigned a TLS Context, and/or
classification to a Proxy Set fails, the device uses the TLS Context assigned to
the SIP Interface used for the call. For configuring SIP Interfaces, see Configuring
SIP Interfaces on page 258.
Default TLS Context (ID 0): If the SIP Interface is not assigned a TLS Context or
no SIP Interface is used for the call, the device uses the default TLS Context.
Outgoing calls:
1.
2.
3.
Proxy Set: If the outgoing call is sent to an IP Group associated with a Proxy Set
that is assigned a TLS Context and the Proxy Set is configured for TLS (i.e.,
'Transport Type' parameter is set to TLS), the TLS Context is used. If the
'Transport Type' parameter is set to UDP, the device uses UDP to communicate
with the proxy and no TLS Context is used.
SIP Interface: If the Proxy Set is not assigned a TLS Context, the device uses the
TLS Context assigned to the SIP Interface used for the call.
Default TLS Context (ID 0): If the SIP Interface is not assigned a TLS Context or
no SIP Interface is used for the call, the device uses the default TLS Context.
Notes:
• If the TLS Context used for an existing TLS connection is changed during the call
by the user agent, the device ends the connection.
• The device does not query OCSP for its own certificate.
• Some PKIs do not support OCSP, but generate Certificate Revocation Lists
(CRLs). For such scenarios, set up an OCSP server such as OCSPD.
TLS Context certification also enables employing different levels of security strength (key
size) per certificate. This feature also enables the display of the list of all trusted certificates
currently installed on the device. For each certificate, detailed information such as issuer
and expiration date is shown. Certificates can be deleted or added from/to the Trusted
Root Certificate Store.
You can also configure TLS certificate expiry check, whereby the device periodically
checks the validation date of the installed TLS server certificates and sends an SNMP trap
event if a certificate is nearing expiry. This feature is configured globally for all TLS
Contexts. For configuring TLS certificate expiry check, see 'Configuring TLS Server
Certificate Expiry Check' on page 102.
The following procedure describes how to configure a TLS Context in the Web interface.
You can also configure this using the table ini file parameter, TLSContexts or CLI
command, configure system > tls <ID>.
User's Manual
92
Document #: LTRT-27034
User's Manual
10. Configuring SSL/ TLS Certificates
 To configure a TLS Context:
1.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
2.
Click Add; the following dialog box appears:
Figure 10-1: TLS Contexts Table - Add Record Dialog Box
3.
Configure the TLS Context according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
TLS Context Parameter Descriptions
Parameter
Description
Web: Index
CLI: tls <ID>
[TLSContexts_Index
]
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Web: Name
CLI: name
[TLSContexts_Name
]
Defines an arbitrary name to easily identify the TLS Context.
The valid value is a string of up to 31 characters.
Web: Version
CLI: tls-version
[TLSContexts_TLSV
ersion]
Defines the supported SSL/TLS protocol version.
 [0] 0 = (Default) SSL 3.0 and all TLS versions (1.0, 1.1, and 1.2) are
supported. SSL/TLS handshakes always start with an SSL 2.0compatible handshake and then switch to the highest TLS version
supported by both peers.
 [1] 1 = Only TLS 1.0 is used. Clients attempting to contact the device
using any other version are rejected.
Version 6.8
93
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Web: Ciphers Server
CLI: ciphers-server
[TLSContexts_Serve
rCipherString]
Defines the supported cipher suite for the TLS server (in OpenSSL cipher
list format).
For valid values, refer to URL
http://www.openssl.org/docs/apps/ciphers.html. The default is "AES:RC4".
For example, use "ALL" for all ciphers suites (e.g., for ARIA encryption for
TLS). The only ciphers available are RC4 and DES, and the cipher bit
strength is limited to 56 bits.
Notes:
 If the installed Software License Key includes the Strong Encryption
feature, the default of this parameter is changed to RC4:EXP, enabling
RC-128-bit encryption.
 The value "ALL" can be used only if the installed Software License Key
includes the Strong Encryption feature.
Web: Ciphers Client
Defines the supported cipher suite for TLS clients.
CLI: ciphers-client
The valid value is up to 255 strings (e.g., "EXP"). The default is
[TLSContexts_Client "ALL:!ADH".
CipherString]
For possible values and additional details, refer to
http://www.openssl.org/docs/apps/ciphers.html.
Web: Ocsp Server
CLI: ocsp-server
[TLSContexts_Ocsp
Enable]
Enables or disables certificate checking using OCSP.
[0] Disable (default)
[1] Enable


Web: Ocsp Server
Primary
CLI: ocsp-serverprimary
[TLSContexts_Ocsp
ServerPrimary]
Defines the IP address (in dotted-decimal notation) of the primary OCSP
server.
The default IP address is 0.0.0.0.
Web: Ocsp Server
Secondary
CLI: ocsp-serversecondary
[TLSContexts_Ocsp
ServerSecondary]
Defines the IP address (in dotted-decimal notation) of the secondary OCSP
server (optional).
The default IP address is 0.0.0.0.
Web: Ocsp Port
CLI: ocsp-port
[TLSContexts_Ocsp
ServerPort]
Defines the OCSP server's TCP port number.
The default port number is 2560.
Web: Ocsp Default
Response
CLI: ocsp-defaultresponse
[TLSContexts_Ocsp
DefaultResponse]
Determines whether the device allows or rejects peer certificates if it
cannot connect to the OCSP server.
 [0] Reject (default)
 [1] Allow
User's Manual
94
Document #: LTRT-27034
User's Manual
10. Configuring SSL/ TLS Certificates
10.1.2 Assigning CSR-based Certificates to TLS Contexts
The following procedure describes how to request a digitally signed certificate from a
Certification Authority (CA) for a TLS Context. This process is referred to as a certificate
signing request (CSR) and is required if your organization employs a Public Key
Infrastructure (PKI) system. The CSR contains information identifying the device (such as a
distinguished name in the case of an X.509 certificate).
 To assign a CSR-based certificate to a TLS Context:
1.
Your network administrator should allocate a unique DNS name for the device (e.g.,
dns_name.corp.customer.com). This DNS name is used to access the device and
therefore, must be listed in the server certificate.
2.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
3.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Certificates
button, located at the bottom of the TLS Contexts page;
the Context Certificates page appears.
4.
Under the Certificate Signing Request group, do the following:
a.
b.
c.
In the 'Subject Name [CN]' field, enter the DNS name.
Fill in the rest of the request fields according to your security provider's
instructions.
Click the Create CSR button; a textual certificate signing request is displayed in
the area below the button:
Figure 10-2: Certificate Signing Request Group
5.
Version 6.8
Copy the text and send it to your security provider (CA) to sign this request.
95
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
6.
When the CA sends you a server certificate, save the certificate to a file (e.g., cert.txt).
Ensure that the file is a plain-text file containing the"‘BEGIN CERTIFICATE" header,
as shown in the example of a Base64-Encoded X.509 Certificate below:
-----BEGIN CERTIFICATE----MIIDkzCCAnugAwIBAgIEAgAAADANBgkqhkiG9w0BAQQFADA/MQswCQYDVQQGEw
JGUjETMBEGA1UEChMKQ2VydGlwb3N0ZTEbMBkGA1UEAxMSQ2VydGlwb3N0ZSBT
ZXJ2ZXVyMB4XDTk4MDYyNDA4MDAwMFoXDTE4MDYyNDA4MDAwMFowPzELMAkGA1
UEBhMCRlIxEzARBgNVBAoTCkNlcnRpcG9zdGUxGzAZBgNVBAMTEkNlcnRpcG9z
dGUgU2VydmV1cjCCASEwDQYJKoZIhvcNAQEBBQADggEOADCCAQkCggEAPqd4Mz
iR4spWldGRx8bQrhZkonWnNm`+Yhb7+4Q67ecf1janH7GcN/SXsfx7jJpreWUL
f7v7Cvpr4R7qIJcmdHIntmf7JPM5n6cDBv17uSW63er7NkVnMFHwK1QaGFLMyb
FkzaeGrvFm4k3lRefiXDmuOe+FhJgHYezYHf44LvPRPwhSrzi9+Aq3o8pWDguJ
uZDIUP1F1jMa+LPwvREXfFcUW+w==
-----END CERTIFICATE-----
7.
Scroll down to the Upload certificates files from your computer group, click the
Browse button corresponding to the 'Send Device Certificate...' field, navigate to the
cert.txt file, and then click Send File.
8.
After the certificate successfully loads to the device, save the configuration with a
device reset.
9.
Open the TLS Contexts page again, select the TLS Context index row, and then verify
that under the Certificate Information group, the 'Private key' field displays "OK";
otherwise, consult your security administrator:
Figure 10-3: Private key "OK" in Certificate Information Group
Notes:
• The certificate replacement process can be repeated when necessary (e.g., the
new certificate expires).
• It is possible to use the IP address of the device (e.g., 10.3.3.1) instead of a
qualified DNS name in the Subject Name. This is not recommended since the IP
address is subject to change and may not uniquely identify the device.
• The device certificate can also be loaded via the Automatic Update Facility by
using the HTTPSCertFileName ini file parameter.
10.1.3 Assigning Externally Created Private Keys to TLS Contexts
The following procedure describes how to assign an externally created private key to a TLS
Context.
 To assign an externally created private key to a TLS Context:
1.
Obtain a private key in either textual PEM (PKCS #7) or PFX (PKCS #12) format
(typically provided by your security administrator). The file may be encrypted with a
short pass-phrase.
2.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
3.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Certificates
button, located at the bottom of the TLS Contexts page;
the Context Certificates page appears.
User's Manual
96
Document #: LTRT-27034
User's Manual
4.
10. Configuring SSL/ TLS Certificates
Scroll down to the Upload certificate files from your computer group.
Figure 10-4: Upload Certificate Files from your Computer Group
5.
Fill in the 'Private key pass-phrase' field, if required.
6.
Click the Browse button corresponding to the 'Send Private Key' field, navigate to the
private key file (Step 1), and then click Send File.
7.
If the security administrator has provided you with a device certificate file, load it using
the 'Send Device Certificate' field.
8.
After the files successfully load to the device, save the configuration with a device
reset.
9.
Open the TLS Contexts page again, select the TLS Context index row, and then verify
that under the Certificate Information group, the 'Private key' field displays "OK";
otherwise, consult your security administrator.
10.1.4 Generating Private Keys for TLS Contexts
The device can generate the private key for a TLS Context, as described in the procedure
below.
 To generate a new private key for a TLS Context:
1.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
2.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Certificates
button, located at the bottom of the TLS Contexts page;
the Context Certificates page appears.
3.
Scroll down to the Generate new private key and self-signed certificate group:
Figure 10-5: Generate new private key and self-signed certificate Group
Version 6.8
97
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
4.
From the 'Private Key Size' drop-down list, select the desired private key size (in bits)
for RSA public-key encryption for newly self-signed generated keys:
•
512
•
1024 (default)
•
2048
5.
Click Generate Private Key; a message appears requesting you to confirm key
generation.
6.
Click OK to confirm key generation; the device generates a new private key, indicated
by a message in the Certificate Signing Request group.
Figure 10-6: Indication of Newly Generated Private Key
7.
Continue with the certificate configuration, by either creating a CSR or generating a
new self-signed certificate.
8.
Save the configuration with a device reset for the new certificate to take effect.
10.1.5 Creating Self-Signed Certificates for TLS Contexts
The following procedure describes how to assign a certificate that is digitally signed by the
device itself to a TLS Context. In other words, the device acts as a CA.
 To assign a self-signed certificate to a TLS Context:
1.
Before you begin, make sure that:
•
You have a unique DNS name for the device (e.g.,
dns_name.corp.customer.com). This name is used to access the device and
therefore, must be listed in the server certificate.
•
No traffic is running on the device. The certificate generation process is disruptive
to traffic and should be done during maintenance time.
2.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
3.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Certificates
button, located at the bottom of the TLS Contexts page;
the Context Certificates page appears.
4.
Under the Certificate Signing Request group, in the 'Subject Name [CN]' field, enter
the fully-qualified DNS name (FQDN) as the certificate subject.
User's Manual
98
Document #: LTRT-27034
User's Manual
5.
10. Configuring SSL/ TLS Certificates
Scroll down the page to the Generate new private key and self-signed certificate
group:
Figure 10-7: Generate new private key and self-signed certificate Group
6.
Click Generate Self-Signed Certificate; a message appears (after a few seconds)
displaying the new subject name.
7.
Save the configuration with a device reset for the new certificate to take effect.
10.1.6 Importing Certificates and Certificate Chain into Trusted
Certificate Store
The device provides its own Trusted Root Certificate Store. This lets you manage
certificate trust. You can add up to 20 certificates to the store per TLS Context (but this
may be less depending on certificate file size).
The trusted store can also be used for certificate chains. A certificate chain is a sequence
of certificates where each certificate in the chain is signed by the subsequent certificate.
The last certificate in the list of certificates is the Root CA certificate, which is self-signed.
The purpose of a certificate chain is to establish a chain of trust from a child certificate to
the trusted root CA certificate. The CA vouches for the identity of the child certificate by
signing it. A client certificate is considered trusted if one of the CA certificates up the
certificate chain is found in the server certificate directory.
Figure 10-8: Certificate Chain Hierarchy
For the device to trust a whole chain of certificates per TLS Context, you need to add them
to the device's Trusted Certificates Store, as described below.
 To import certificates into device's Trusted Root Certificate Store:
1.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
2.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Trusted-Roots
button, located at the bottom of the TLS Contexts
page; the Trusted Certificates page appears.
Version 6.8
99
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Click the Import button, and then select the certificate file to load.
Figure 10-9: Importing Certificate into Trusted Certificates Store
4.
Click OK; the certificate is loaded to the device and listed in the Trusted Certificates
store.
You can also do the following with certificates that are in the Trusted Certificates store:

Delete certificates: Select the required certificate, click Remove, and then in the
Remove Certificate dialog box, click Remove.

Save certificates to a file on your PC: Select the required certificate, click Export, and
then in the Export Certificate dialog box, browse to the folder on your PC where you
want to save the file and click Export.
10.1.7 Configuring Mutual TLS Authentication
10.1.7.1 TLS for SIP Clients
When Secure SIP (SIPS) is implemented using TLS, it is sometimes required to use twoway (mutual) authentication between the device and a SIP user agent (client). When the
device acts as the TLS server in a specific connection, the device demands the
authentication of the SIP client’s certificate. Both the device and the client use certificates
from a CA to authenticate each other, sending their X.509 certificates to one another during
the TLS handshake. Once the sender is verified, the receiver sends its' certificate to the
sender for verification. SIP signaling starts when authentication of both sides completes
successfully.
TLS mutual authentication can be configured for specific calls by enabling mutual
authentication on the SIP Interface used by the call. The TLS Context associated with the
SIP Interface or Proxy Set belonging to these calls are used.
Note: SIP mutual authentication can also be configured globally for all calls, using the
'TLS Mutual Authentication' parameter (SIPSRequireClientCertificate) in the General
Security Settings page (Configuration tab > VoIP menu > Security > General
Security Settings).
 To configure mutual TLS authentication for SIP messaging:
1.
Enable two-way authentication on the specific SIP Interface:
a.
b.
User's Manual
In the SIP Interface Table page (see Configuring SIP Interfaces on page 258), set
the 'TLS Mutual Authentication' parameter to Enable for the specific SIP
Interface.
Click Submit, and then reset the device with a burn-to-flash for your settings to
take effect.
100
Document #: LTRT-27034
User's Manual
2.
10. Configuring SSL/ TLS Certificates
Configure a TLS Context with the following certificates:
•
Import the certificate of the CA that signed the certificate of the SIP client, into the
Trusted Root Store so that the device can authenticate the client (see 'Importing
Certificates and Certificate Chain into Trusted Certificate Store' on page 99).
•
Make sure that the TLS certificate is signed by a CA that the SIP client trusts so
that the client can authenticate the device.
10.1.7.2 TLS for Remote Device Management
By default, servers using TLS provide one-way authentication. The client is certain that the
identity of the server is authentic. When an organizational PKI is used, two-way
authentication may be desired - both client and server should be authenticated using X.509
certificates. This is achieved by installing a client certificate on the management PC and
loading the root CA's certificate to the device's Trusted Root Certificate Store. The Trusted
Root Certificate file may contain more than one CA certificate combined, using a text
editor.
 To enable mutual TLS authentication for HTTPS:
1.
Set the 'Secured Web Connection (HTTPS)' field to HTTPS Only in the Web Security
Settings page (see Configuring Web Security Settings on page 63) to ensure you have
a method for accessing the device in case the client certificate does not work. Restore
the previous setting after testing the configuration.
2.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
3.
In the TLS Contexts table, select the required TLS Context index row, and then click
the Context Trusted-Roots
button, located at the bottom of the TLS Contexts
page; the Trusted Certificates page appears.
4.
Click the Import button, and then select the certificate file.
5.
When the operation is complete, set the 'Requires Client Certificates for HTTPS
connection' field to Enable in the Web Security Settings page.
6.
Save the configuration with a device reset (see Saving Configuration).
When a user connects to the secured Web interface of the device:

If the user has a client certificate from a CA that is listed in the Trusted Root Certificate
file, the connection is accepted and the user is prompted for the system password.

If both the CA certificate and the client certificate appear in the Trusted Root
Certificate file, the user is not prompted for a password (thus, providing a single-signon experience - the authentication is performed using the X.509 digital signature).

If the user does not have a client certificate from a listed CA or does not have a client
certificate, the connection is rejected.
Notes:
• The process of installing a client certificate on your PC is beyond the scope of this
document. For more information, refer to your operating system documentation,
and/or consult your security administrator.
• The root certificate can also be loaded via the Automatic Update facility, using the
HTTPSRootFileName ini file parameter.
• You can enable the device to check whether a peer's certificate has been revoked
by an OCSP server, per TLS Context (see 'Configuring TLS Certificate Contexts'
on page 91).
Version 6.8
101
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
10.1.8 Configuring TLS Server Certificate Expiry Check
You can also configure the TLS Server Certificate Expiry Check feature, whereby the
device periodically checks the validation date of the installed TLS server certificates. You
can also configure the device to send a notification SNMP trap event
(acCertificateExpiryNotification) at a user-defined number of days before the installed TLS
server certificate is to expire. This trap event indicates the TLS Context to which the
certificate belongs.
Note: TLS certificate expiry check is configured globally for all TLS Contexts.
 To configure TLS certificate expiry checks and notification:
1.
Open the TLS Contexts page (Configuration tab > System menu > TLS Contexts).
2.
Scroll down the page to the TLS Expiry Settings group:
Figure 10-10: TLS Expiry Settings Group
3.
In the 'TLS Expiry Check Start' field, enter the number of days before the installed TLS
server certificate is to expire at which time the device sends an SNMP trap event to
notify of this.
4.
In the 'TLS Expiry Check Period' field, enter the periodical interval (in days) for
checking the TLS server certificate expiry date. By default, the device checks the
certificate every 7 days.
5.
Click the Submit TLS Expiry Settings button.
User's Manual
102
Document #: LTRT-27034
User's Manual
11
11. Date and Time
Date and Time
The date and time of the device can be configured manually or it can be obtained
automatically from a Simple Network Time Protocol (SNTP) server.
11.1
Configuring Date and Time Manually
You can manually configure the date and time of the device (instead of using an NTP
server), as described in the procedure below. You can also configure the following with
your manually configured date and time:

UTC time offset (e.g., GMT +1). To configure the offset, use the 'NTP UTC Offset'
(NTPServerUTCOffset) parameter (see 'Configuring Automatic Date and Time using
SNTP' on page 103)

Daylight Saving Time (DST) - see 'Configuring Daylight Saving Time' on page 105
 To manually configure the device's date and time, using the Web interface:
1.
Open the Regional Settings page (Configuration tab > System menu > Regional
Settings).
Figure 11-1: Regional Settings Page
2.
Enter the current date and time of the geographical location in which the device is
installed.
3.
Click Submit.
Notes:
• If the device is configured to obtain the date and time from an SNTP server, the
fields on this page are read-only, displaying the received date and time.
• After performing a hardware reset, the date and time are returned to their defaults
and thus, should be updated.
11.2
Configuring Automatic Date and Time using SNTP
The device's 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 device, as an NTP
client, synchronizes the system time to a time source within the network, thereby
eliminating any potential issues should the local system clock 'drift' during operation. The
NTP client follows a simple process in managing system time: the NTP client requests an
NTP update, receives an NTP response, and then updates the local system clock based on
an NTP server within the network. The client requests a time update from the user-defined
NTP server (IP address or FQDN) at a user-defined update interval. Typically, this update
interval is every 24 hours based on when the system was restarted.
You can also configure a time offset for the time received from the NTP server, according
to your region. For example, Germany Berlin region is UTC/GMT +1 hours and therefore,
you would configure the offset to "1". For USA New York, the UTC/GMT offset is -5 hours
and therefore, the offset is a minus value and configured as "-5". To configure Daylight
Saving Time (DST), see 'Configuring Daylight Saving Time' on page 105.
Version 6.8
103
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
You can also configure the device to authenticate and validate the NTP messages received
from the NTP server. Authentication is done using an authentication key with the MD5
cryptographic hash algorithm. When this feature is enabled, the device ignores NTP
messages received without authentication.
The following procedure describes how to configure SNTP. For detailed descriptions of the
configuration parameters, see NTP and Daylight Saving Time Parameters on page 736.
 To configure SNTP using the Web interface:
1.
Open the Application Settings page (Configuration tab > System menu >
Application Settings).
2.
Scroll down to the 'NTP Settings' group:
Figure 11-2: SNTP Configuration in Application Settings Page
3.
Configure the NTP server address:
•
In the 'NTP Server Address' (NTPServerIP) field, configure the primary NTP
server's address (IP or FQDN).
•
In the 'NTP Secondary Server Address' (NTPSecondaryServerIP) field, configure
the secondary NTP server.
4.
In the 'NTP UTC Offset' (NTPServerUTCOffset) field, configure the time offset in
relation to the UTC. For example, if your region is GMT +1 (an hour ahead), enter "1".
5.
In the 'NTP Updated Interval' (NTPUpdateInterval) field, configure the period after
which the date and time of the device is updated.
6.
Configure NTP message authentication:
7.
User's Manual
•
In the 'NTP Authentication Key Identifier' field, configure the NTP authentication
key identifier.
•
In the 'NTP Authentication Secret Key' field, configure the secret authentication
key shared between the device and the NTP server.
Verify that the device has received the correct date and time from the NTP server. You
can do this by viewing the date and time in the Regional Settings page (see
'Configuring Date and Time Manually' on page 103).
104
Document #: LTRT-27034
User's Manual
11.3
11. Date and Time
Configuring Daylight Saving Time
You can apply daylight saving time (DST) to the date and time of the device. DST defines a
date range in the year (summer) where the time is brought forward so that people can
experience more daylight. DST applies an offset of up to 60 minutes (default) to the local
time. For example, Germany Berlin has DST from 30 March to 26 October, where the time
is brought forward by an hour (e.g., 02:00 to 03:00 on 30 March). Therefore, you would
configure the DST offset to 60 minutes (one hour).
 To configure DST using the Web interface:
1.
Open the Application Settings page (Configuration tab > System menu >
Application Settings).
2.
Scroll down to the 'Day Light Saving Time' group:
Figure 11-3: Configuring DST
3.
From the 'Day Light Saving Time' (DayLightSavingTimeEnable) drop-down list, select
Enable.
4.
From the 'DST Mode' drop-down list, select the range type for configuring the start and
end dates for DST:
•
Day of year: The range is configured by exact date (day number of month), for
example, from March 30 to October 30. If 'DST Mode' is set to Day of year, in the
'Start Time' (DayLightSavingTimeStart) and 'End Time' (DayLightSavingTimeEnd)
drop-down lists, configure the period for which DST is relevant.
•
Day of month: The range is configured by month and day type, for example,
from the last Sunday of March to the last Sunday of October. If 'DST Mode' is set
to Day of month, in the 'Day of Month Start' and 'Day of Month End' drop-down
lists, configure the period for which DST is relevant.
5.
In the 'Offset' (DayLightSavingTimeOffset) field, configure the DST offset in minutes.
6.
If the current date falls within the DST period, verify that it has been successful applied
to the device's current date and time. You can view the device's date and time in the
Regional Settings page (see 'Configuring Date and Time Manually' on page 103).
Version 6.8
105
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
106
Document #: LTRT-27034
Part IV
General VoIP Configuration
User's Manual
12
12. Network
Network
This section describes the network-related configuration.
12.1
Configuring Physical Ethernet Ports
The Physical Ports Settings table lets you configure the device's Ethernet ports. This
includes port speed and duplex mode, Native VLAN (PVID), and a brief description.
By default, the Ethernet ports are grouped into pairs called Ethernet Groups. However, you
can change this port assignment including assigning only a single port to an Ethernet
Group. For more information and for configuring Ethernet Groups, see 'Configuring
Ethernet Port Groups' on page 111.
The device's management tools (e.g., Web interface) use hard-coded strings to represent
the physical ports, as shown below:
Figure 12-1: Mapping of Logical String Names to Physical Ports
To view the mapping of the physical ports to these logical ports (strings) as well as view
port status, use the CLI command, show voip ports. This displays the MAC address and
port status (up or down) of the physical port and its corresponding logical port. Below
shows an example of the mapping results from running this command:
# show voip ports
Port Num
------1
2
Port Name MAC Address Speed Duplexity Link Status Native VLAN
--------- ---------- ------ --------- ---------- ---------GE1_1
00:1e:67:11:7c:28 100Mbps FULL
UP
1
GE1_2
00:1e:67:11:7c:28 100Mbps FULL
DOWN
1
Note: All the LAN ports (including those of the optional SWX Expansion module) have
the same MAC address. This is the MAC address of the device itself.
Version 6.8
109
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The following procedure describes how to configure the Ethernet ports in the Web
interface. You can also configure these ports using the table ini file parameter,
PhysicalPortsTable or CLI command, configure voip/physical-port.
 To configure the physical Ethernet ports:
1.
Open the Physical Ports Settings page (Configuration tab > VoIP menu > Network >
Physical Ports Table).
2.
Select a port that you want to configure by clicking its table row, and then click Edit;
the following dialog box appears:
Figure 12-2: Physical Ports Settings Page - Edit Record
3.
Configure the port according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 4: Physical Port Settings Parameter Descriptions
Parameter
Description
Port
CLI: port
[PhysicalPortsTable_Port]
(Read-only) Displays the port number.
Mode
CLI: mode
[PhysicalPortsTable_Mode]
(Read-only) Displays the mode of the port:
 [0] Disable
 [1] Enable (default)
Native Vlan
CLI: native-vlan
[PhysicalPortsTable_NativeVlan]
Defines the Native VLAN or PVID of the port. Incoming
packets without a VLAN ID are tagged with this VLAN. For
outgoing packets, if the VLAN ID as defined in the
Interface table is the same as the Native VLAN ID, the
device sends the packet without a VLAN; otherwise, the
VLAN ID as defined in the Interface table takes
precedence.
The valid value range is 1 to 4096. The default is 1.
Speed & Duplex
CLI: speed-duplex
[PhysicalPortsTable_SpeedDuplex]
Defines the speed and duplex mode of the port.
 [0] 10BaseT Half Duplex
 [1] 10BaseT Full Duplex
 [2] 100BaseT Half Duplex
 [3] 100BaseT Full Duplex
 [4] Auto Negotiation (default)
 [6] 1000BaseT Half Duplex
 [7] 1000BaseT Full Duplex
User's Manual
110
Document #: LTRT-27034
User's Manual
12. Network
Parameter
Description
Description
Defines an arbitrary description of the port.
CLI: port-description
[PhysicalPortsTable_PortDescription]
Group Member
CLI: group-member
[PhysicalPortsTable_GroupMember]
(Read-only) Displays the group to which the port belongs.
Group Status
CLI: group-status
[PhysicalPortsTable_GroupStatus]
(Read-only) Displays the status of the port:
 "Active" - the active port
 "Redundant" - the standby (redundant) port
12.2
Configuring Ethernet Port Groups
The Ethernet Group Settings table lets you configure Ethernet Groups. An Ethernet Group
represents a physical Ethernet port(s) on the device. You can assign an Ethernet Group
with one, two, or no ports (members). When two ports are assigned to an Ethernet Group,
1+1 Ethernet port redundancy can be implemented in your network. In such a
configuration, one port is active while the other is in standby mode. This provides port
redundancy within the Ethernet Group, whereby if an active port is disconnected, the
device switches over to the standby port. If you configure an Ethernet Group with only one
port, the Ethernet Group operates as a single port, without redundancy. You can also
configure a combination of Ethernet Group types, where some contain one port and others
two ports.
The Ethernet Group Settings table also lets you configure the transmit (Tx) and receive
(Rx) settings for the Ethernet ports per Ethernet Group. The Tx/Rx setting applies only to
Ethernet Groups that contain two ports. This setting determines whether both ports or only
one of the ports can receive and/or transmit traffic.
The maximum number of Ethernet Groups that can be configured is the same as the
number of Ethernet ports provided by the device. Thus, the device supports up to six
Ethernet Groups, each containing one port, or up to three Ethernet Groups, each
containing two ports. By default, each Ethernet Group is assigned two ports; the other
Ethernet Groups are empty.
Note: The SWX LAN Expansion module is a customer-ordered item. For more
information, contact your AudioCodes sales representative.
You can assign Ethernet ports to IP network interfaces. This is done by first configuring an
Ethernet Device with the required Ethernet Group containing the port or ports (see
'Configuring Underlying Ethernet Devices' on page 113). Then by assigning the Ethernet
Device to the IP network interface in the Interface table (see 'Configuring IP Network
Interfaces' on page 116). This enables physical separation of network interfaces, providing
a higher level of segregation of sub-networks. Equipment connected to different physical
ports is not accessible to one another; the only connection between them can be
established by cross connecting them with media streams (VoIP calls).
The port names (strings) displayed in the Ethernet Group Settings table represent the
physical ports on the device. For the mapping of these strings to the physical ports, see
'Configuring Physical Ethernet Ports' on page 109.
Version 6.8
111
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The following procedure describes how to configure Tx/Rx mode in the Web interface. You
can also configure this using the table ini file parameter, EtherGroupTable or CLI
command, configure voip/ether-group.
Note: Before you can re-assign a port to a different Ethernet Group, you must first
remove the port from its current Ethernet Group. To remove the port, either set the
'Member' field to None or to a different port.
 To configure Ethernet Groups:
1.
Open the Ethernet Group Settings page (Configuration tab > VoIP menu > Network
> Ethernet Groups Table).
2.
If the port that you want to assign to a specific Ethernet Group is already associated
with another Ethernet Group, you must first remove the port from the currently
associated Ethernet Group before you can associate it with the desired Ethernet
Group:
a.
Select the Ethernet Group to which the port is currently associated, and then click
Edit; the following dialog box appears:
Figure 12-3: Ethernet Group Settings Page
b.
c.
Set the 'Member 1' or 'Member 2' field (depending on where the port appears) to
None (or to a different port).
Click Submit; the port is removed from the Ethernet Group.
3.
Select the Ethernet Group that you want to configure and associate a port(s), and then
click Edit.
4.
Configure the Ethernet Group according to the parameters described in the table
below.
5.
Click Submit, and then save ("burn") your settings to flash memory.
User's Manual
112
Document #: LTRT-27034
User's Manual
12. Network
Table 5: Ethernet Group Settings Parameter Descriptions
Parameter
Description
Group
CLI: group
[EtherGroupTable_Group]
(Read-only) Displays the Ethernet Group number.
Mode
CLI: mode
[EtherGroupTable_Mode]
Defines the mode of operation of the ports in the Ethernet Group.
This applies only to Ethernet Groups containing two ports.
 [2] 1RX/1TX = (Default) At any given time, only a single port in
the Ethernet Group can transmit and receive packets. If a link
exists on both ports, then the active one is either the first to have
a link up or the lower-numbered port if both have the same link
up from start.
 [3] 2RX/1TX = Both ports in the Ethernet Group can receive
packets, but only one port can transmit. The transmitting port is
determined arbitrarily by the device. If the selected port fails at a
later stage, a switchover to the redundant port is done, which
begins to transmit as well as receive.
 [4] 2RX/2TX = Both ports in the Ethernet Group can receive and
transmit packets.
 [5] Single = If the Ethernet Group contains only one port, use this
option.
 [6] None = If no port is assigned to the Ethernet Group, use this
option.
Note: It is recommended to use the 2RX/1TX option. In such a
setup, the ports can be connected to the same LAN switch or each
to a different switch where both are in the same subnet. If
connecting each port to a different switch, the 2RX/2TX option can
be used but only if the port group is associated with OAMP and/or
Control application types, not media.
Member 1
Assigns the first port to the Ethernet Group. To assign no port, set
CLI: member1
this field to None.
[EtherGroupTable_Member1] Note: Before you can re-assign a port to a different Ethernet Group,
you must first remove the port from its current Ethernet Group. To
remove the port, either set this field to None or to a different port.
Member 2
Assigns the second port to the Ethernet Group. To assign no port,
CLI: member2
set this field to None.
[EtherGroupTable_Member2] Note: Before you can re-assign a port to a different Ethernet Group,
you must first remove the port from its current Ethernet Group. To
remove the port, either set this field to None or to a different port.
12.3
Configuring Underlying Ethernet Devices
The Ethernet Device table lets you configure Ethernet Devices (underlying devices). An
Ethernet Device represents a Layer-2 bridging device and is assigned with a VLAN ID. An
Ethernet Device is associated with an IP network interface in the Interface table
('Underlying Device' field) and/or with a static route in the Static Route table ('Device Name'
field). Multiple IP interfaces can be associated with the same Ethernet Device and thereby,
implement mutihoming (multiple addresses on the same interface/VLAN).
The Ethernet Device table lets you configure Ethernet Devices by defining a VLAN ID
assigning it an arbitrary name for future reference to other configuration items, and
associating it with an Ethernet Port Group.
Version 6.8
113
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
You can view configured Ethernet Devices that have been successfully applied to the
device (saved to flash), in the Ethernet Device Status Table page. This page is accessed
by clicking the Ethernet Device Status Table button, located at the bottom of the Ethernet
Device Table page. The Ethernet Device Status Table page can also be accessed from the
Status & Diagnostics tab > VoIP Status menu > Ethernet Device Status Table (see
''Viewing Ethernet Device Status'' on page 642).
Note: You cannot delete an Ethernet Device that is associated with an IP network
interface (in the Interface table). Only after the Ethernet Device has been
disassociated from the IP network interface can it be deleted.
The following procedure describes how to configure Ethernet devices in the Web interface.
You can also configure this using the table ini file parameter, DeviceTable or CLI
command, config-voip > interface network-dev.
 To configure an Ethernet Device:
1.
Open the Ethernet Device Table page (Configuration tab > VoIP menu > Network >
Ethernet Device Table).
2.
Click Add; the following dialog box appears:
User's Manual
114
Document #: LTRT-27034
User's Manual
12. Network
3.
Configure an Ethernet Device according to the parameters described in the table
below.
4.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
Table 12-6: Ethernet Device Table Parameter Descriptions
Parameter
Description
Index
[DeviceTable_Index]
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
VLAN ID
CLI: vlan-id
[DeviceTable_VlanID]
Defines a VLAN ID.
The valid value is 1 to 3999. The default value is 1.
Note: Each Ethernet Port Group must be configured with a
unique VLAN ID.
Underlying Interface
Assigns an Ethernet Port Group to the VLAN (mandatory field).
CLI: underlying-if
For configuring Ethernet Port Groups, see Configuring Ethernet
[DeviceTable_UnderlyingInterface] Port Groups on page 111.
Name
CLI: name
[DeviceTable_DeviceName]
Version 6.8
Defines a name for the VLAN. This name is used to associate
the VLAN with an IP network interface in the Interface table
('Underlying Device' field - see ''Configuring IP Network
Interfaces'' on page 116) and/or with a static route in the Static
Route table ('Device Name' field - see ''Configuring Static IP
Routing'' on page 123).
By default, the device automatically assigns a name using the
following syntax: "dev <next available table row index>" (e.g.,
"dev 3").
115
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
12.4
Configuring IP Network Interfaces
You can configure a single VoIP network interface for all applications, including OAMP
(management traffic), call control (SIP signaling messages), and media (RTP traffic), or
you can configure multiple logical, IP network interfaces for these applications. You may
need to logically separated network segments for these applications for administration and
security. This can be achieved by employing Layer-2 VLANs and Layer-3 subnets. The
figure below illustrates a typical network architecture where the device is configured with
three network interfaces, each representing the OAMP, call control, and media
applications. The device is connected to a VLAN-aware switch for directing traffic from and
to the device to the three separated Layer-3 broadcast domains according to VLAN tags
(middle pane).
Figure 12-4: Multiple Network Interfaces
The device is shipped with a default OAMP interface. For more information, see ''Default
OAMP IP Address'' on page 29. The Interface table lets you change this OAMP interface
and configure additional network interfaces for control and media, if necessary. You can
configure up to 12 interfaces, consisting of up to 11 Control and Media interfaces and 1
OAMP interface. Each IP interface is configured with the following:

Application type allowed on the interface:
•
Control: call control signaling traffic (i.e., SIP)
•
Media: RTP traffic
•
Operations, Administration, Maintenance and Provisioning (OAMP): management
(i.e., Web, CLI, and SNMP based management)

IP address (IPv4 and IPv6) and subnet mask (prefix length)

For configuring Quality of Service (QoS), see ''Configuring the QoS Settings'' on page
127.

Default Gateway: Traffic from this interface destined to a subnet that does not meet
any of the routing rules (local or static) are forwarded to this gateway

Primary and secondary domain name server (DNS) addresses (optional)
User's Manual
116
Document #: LTRT-27034
User's Manual

12. Network
Underlying Ethernet Device: Layer-2 bridging device and assigned a VLAN ID. As the
Ethernet Device is associated with an Ethernet Port Group, this is useful for setting
trusted and un-trusted networks on different physical Ethernet ports. Multiple entries in
the Interface table may be associated with the same Ethernet Device, providing multihoming IP configuration (i.e., multiple IP addresses on the same interface/VLAN).
Complementing the Interface table is the Static Route table, which lets you configure static
routing rules for non-local hosts/subnets. For more information, see ''Configuring Static IP
Routing'' on page 123.
Notes:
• Before configuring IP interfaces, it is recommended that you read the IP interface
configuration guidelines in ''Interface Table Configuration Guidelines'' on page
119.
• The IPv6 feature is available only if the device is installed with a Software License
Key that includes this feature. For installing a Software License Key, see Software
License Key on page 599.
The following procedure describes how to configure the IP network interfaces in the Web
interface. You can also configure IP network interfaces using the table ini file parameter,
InterfaceTable or CLI command, configure voip/interface network-if.
 To configure IP network interfaces:
1.
Open the Interface Table page (Configuration tab > VoIP menu > Network > IP
Interfaces Table).
2.
Click Add; a dialog box appears.
3.
Configure the IP network interface according to the parameters described in the table
below.
4.
Click Submit.
To view configured network interfaces that are currently active, click the IP Interface
Status Table
button. For more information, see ''Viewing Active IP Interfaces'' on page
642.
Version 6.8
117
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Table 12-7: Interface Table Parameters Description
Parameter
Description
Table parameters
Index
CLI: network-if
[InterfaceTable_Index]
Table index row of the interface.
The range is 0 to 11.
Web: Application Type
EMS: Application Types
CLI: application-type
[InterfaceTable_ApplicationTyp
es]
Defines the applications allowed on the interface.
 [0] OAMP = Operations, Administration, Maintenance and
Provisioning (OAMP) applications (e.g., Web, Telnet, SSH,
and SNMP).
 [1] Media = Media (i.e., RTP streams of voice).
 [2] Control = Call Control applications (e.g., SIP).
 [3] OAMP + Media = OAMP and Media applications.
 [4] OAMP + Control = OAMP and Call Control applications.
 [5] Media + Control = Media and Call Control applications.
 [6] OAMP + Media + Control = All application types are
allowed on the interface.
Web: Interface Mode
[InterfaceTable_InterfaceMode]
Defines the method that the interface uses to acquire its IP
address.
 [3] IPv6 Manual Prefix = IPv6 manual prefix IP address
assignment. The IPv6 prefix (higher 64 bits) is set manually
while the interface ID (the lower 64 bits) is derived from the
device's MAC address.
 [4] IPv6 Manual = IPv6 manual IP address (128 bits)
assignment.
 [10] IPv4 Manual = IPv4 manual IP address (32 bits)
assignment.
Web/EMS: IP Address
CLI: ip-address
[InterfaceTable_IPAddress]
Defines the IPv4/IPv6 address, in dotted-decimal notation.
Web/EMS: Prefix Length
CLI: prefix-length
[InterfaceTable_PrefixLength]
Defines the prefix length of the related IP address. This is a
Classless Inter-Domain Routing (CIDR)-style representation of a
dotted-decimal subnet notation. The CIDR-style representation
uses a suffix indicating the number of bits which are set in the
dotted-decimal format. For example, 192.168.0.0/16 is
synonymous with 192.168.0.0 and subnet 255.255.0.0. This
CIDR lists the number of ‘1’ bits in the subnet mask (i.e., replaces
the standard dotted-decimal representation of the subnet mask
for IPv4 interfaces). For example, a subnet mask of 255.0.0.0 is
represented by a prefix length of 8 (i.e., 11111111 00000000
00000000 00000000) and a subnet mask of 255.255.255.252 is
represented by a prefix length of 30 (i.e., 11111111 11111111
11111111 11111100).
The prefix length is a Classless Inter-Domain Routing (CIDR)
style presentation of a dotted-decimal subnet notation. The CIDRstyle presentation is the latest method for interpretation of IP
addresses. Specifically, instead of using eight-bit address blocks,
it uses the variable-length subnet masking technique to allow
allocation on arbitrary-length prefixes.
The prefix length for IPv4 must be set to a value from 0 to 30. The
prefix length for IPv6 must be set to a value from 0 to 64.
Web/EMS: Default Gateway
Defines the IP address of the default gateway for the interface.
User's Manual
118
Document #: LTRT-27034
User's Manual
12. Network
Parameter
Description
CLI: gateway
[InterfaceTable_Gateway]
When traffic is sent from this interface to an unknown destination
(i.e., not in the same subnet and not defined for any static routing
rule), it is forwarded to this default gateway.
Web/EMS: Interface Name
CLI: name
[InterfaceTable_InterfaceName]
Defines a name for the interface. This name is used in various
configuration tables to associate the network interface with other
configuration entities such as Media Realms. It is also displayed
in management interfaces (Web, CLI, and SNMP) for clarity
where it has no functional use.
The valid value is a string of up to 16 characters.
Web/EMS: Primary DNS
CLI: primary-dns
[InterfaceTable_PrimaryDNSSe
rverIPAddress]
(Optional) Defines the primary DNS server's IP address (in
dotted-decimal notation), which is used for translating domain
names into IP addresses for the interface.
By default, no IP address is defined.
Web/EMS: Secondary DNS
CLI: secondary-dns
[InterfaceTable_SecondaryDNS
ServerIPAddress]
(Optional) Defines the secondary DNS server's IP address (in
dotted-decimal notation), which is used for translating domain
names into IP addresses for the interface.
By default, no IP address is defined.
Underlying Device
CLI: underlying-dev
[InterfaceTable_UnderlyingDevic
e]
Assigns an Ethernet Device to the IP interface. An Ethernet
Device is a VLAN ID associated with a physical Ethernet port
(Ethernet Group). To configure Ethernet Devices, see Configuring
Underlying Ethernet Devices on page 113.
12.4.1 Assigning NTP Services to Application Types
You can associate the Network Time Protocol (NTP) application with the OAMP or Control
application type. This is done using the EnableNTPasOAM ini file parameter.
12.4.2 Multiple Interface Table Configuration Summary and Guidelines
The Interface table configuration must adhere to the following rules:

Multiple Control and Media interfaces can be configured with overlapping IP
addresses and subnets.

The prefix length replaces the dotted-decimal subnet mask presentation and must
have a value of 0-30 for IPv4 addresses and a value of 0-64 for IPv6 addresses.

One OAMP interface must be configured and this must be an IPv4 address. This
OAMP interface can be combined with Media and Control.

At least one Control interface must be configured.

At least one Media interface must be configured.

Multiple Media and/or Control interfaces can be configured with an IPv6 address.

The network interface types can be combined:
Version 6.8
•
Example 1:
♦
One combined OAMP-Media-Control interface with an IPv4 address
•
Example 2:
♦
One OAMP interface with an IPv4 address
♦
One or more Control interfaces with IPv4 addresses
119
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
♦
•
One or more Media interfaces with IPv4 interfaces
Example 3:
♦
One OAMP with an IPv4 address
♦
One combined Media-Control interface with IPv4 address
♦
One combined Media-Control interface with IPv6 address

Each network interface can be configured with a Default Gateway. The address of the
Default Gateway must be in the same subnet as the associated interface. Additional
static routing rules can be configured in the Static Route table.

The interface name must be configured (mandatory) and must be unique for each
interface.

For IPv4 addresses, the 'Interface Mode' column must be set to IPv4 Manual. For IPv6
addresses, this column must be set to IPv6 Manual or IPv6 Manual Prefix.
Note: Upon device start up, the Interface table is parsed and passes comprehensive
validation tests. If any errors occur during this validation phase, the device sends an
error message to the Syslog server and falls back to a "safe mode", using a single
interface without VLANs. Ensure that you view the Syslog messages that the device
sends in system startup to see if any errors occurred.
12.4.3 Networking Configuration Examples
This section provides configuration examples of networking interfaces.
12.4.3.1 One VoIP Interface for All Applications
This example describes the configuration of a single VoIP interface for all applications:
1.
Interface table: Configured with a single interface for OAMP, Media and Control:
Table 12-8: Example of Single VoIP Interface in Interface Table
Index
0
Application
Type
Interface
Mode
IP Address
Prefix
Length
Default
Gateway
Underlying
Device
Interface
Name
OAMP,
Media &
Control
IPv4
192.168.0.2
16
192.168.0.1
1
myInterface
2.
Static Route table: Two routes are configured for directing traffic for subnet
201.201.0.0/16 to 192.168.11.10, and all traffic for subnet 202.202.0.0/16 to
192.168.11.1:
Table 12-9: Example of Static Route Table
Destination
Prefix Length
201.201.0.0
16
192.168.11.10
202.202.0.0
16
192.168.11.1
3.
User's Manual
Gateway
The NTP applications remain with their default application types.
120
Document #: LTRT-27034
User's Manual
12. Network
12.4.3.2 VoIP Interface per Application Type
This example describes the configuration of three VoIP interfaces; one for each application
type:
1.
Interface table: Configured with three interfaces, each for a different application type,
i.e., one for OAMP, one for Call Control, and one for RTP Media, and each with a
different VLAN ID and default gateway:
Table 12-10: Example of VoIP Interfaces per Application Type in Interface Table
Index
Application Interface
Type
Mode
IP Address
Prefix
Length
Default
Gateway
Underlying
Device
Interface
Name
0
OAMP
IPv4
Manual
192.168.0.2
16
192.168.0.1
1
ManagementIF
1
Control
IPv4
Manual
200.200.85.14
24
200.200.85.1
200
myControlIF
2
Media
IPv4
Manual
211.211.85.14
24
211.211.85.1
211
myMediaIF
2.
Static Route table: A routing rule is required to allow remote management from a
host in 176.85.49.0 / 24:
Table 12-11: Example Static Route Table
Destination
Prefix Length
Gateway
176.85.49.0
24
192.168.11.1
3.
All other parameters are set to their respective default values. The NTP application
remains with its default application types.
12.4.3.3 VoIP Interfaces for Combined Application Types
This example describes the configuration of multiple interfaces for the following
applications:

One interface for the OAMP application.

Interfaces for Call Control and Media applications, where two of them are IPv4
interfaces and one is an IPv6 interface.
1.
Interface table:
Table 12-12: Example of VoIP Interfaces of Combined Application Types in Interface Table
Inde Applicatio Interfac
x
n Type
e Mode
IP Address
Prefix
Lengt
h
Default
Gateway
Underlyin
g Device
Interface
Name
0
OAMP
IPv4
Manual
192.168.0.2
16
192.168.0.1
1
Mgmt
1
Media &
Control
IPv4
Manual
200.200.85.14
24
200.200.85.
1
201
MediaCntrl1
2
Media &
Control
IPv4
Manual
200.200.86.14
24
200.200.86.
1
202
MediaCntrl2
Version 6.8
121
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Inde Applicatio Interfac
x
n Type
e Mode
3
Media &
Control
2.
IP Address
Prefix
Lengt
h
Default
Gateway
Underlyin
g Device
Interface
Name
64
::
202
V6CntrlMedia
2
IPv6
2000::1:200:200:86:1
Manual
4
Static Route table: A routing rule is required to allow remote management from a
host in 176.85.49.0/24:
Table 12-13: Example of Static Route Table
Destination
Prefix Length
Gateway
176.85.49.0
24
192.168.0.10
3.
The NTP application is configured (using the ini file) to serve as OAMP applications:
EnableNTPasOAM = 1
4.
DiffServ table:
•
Layer-2 QoS values are assigned:
♦
For packets sent with DiffServ value of 46, set VLAN priority to 6
♦
For packets sent with DiffServ value of 40, set VLAN priority to 6
♦
For packets sent with DiffServ value of 26, set VLAN priority to 4
♦
For packets sent with DiffServ value of 10, set VLAN priority to 2
•
Layer-3 QoS values are assigned:
♦
For Media Service class, the default DiffServ value is set to 46
♦
For Control Service class, the default DiffServ value is set to 40
♦
For Gold Service class, the default DiffServ value is set to 26
♦
For Bronze Service class, the default DiffServ value is set to 10
Figure 12-5: Example of Layer-2 QoS in DiffServ Table
User's Manual
122
Document #: LTRT-27034
User's Manual
12. Network
12.4.3.4 VoIP Interfaces with Multiple Default Gateways
Below is a configuration example using default gateways per IP network interface. In this
example, the default gateway for OAMP is 192.168.0.1 and for Media and Control it is
200.200.85.1.
Table 12-14: Configured Default Gateway Example
Application Interface
Type
Mode
Index
IP Address
Prefix
Length
Default
Gateway
Underlying
Device
Interface
Name
0
OAMP
IPv4
Manual
192.168.0.2
16
192.168.0.1
100
Mgmt
1
Media &
Control
IPv4
Manual
200.200.85.14
24
200.200.85.1
200
CntrlMedia
A separate Static Route table lets you configure static routing rules. Configuring the
following static routing rules enables OAMP applications to access peers on subnet
17.17.0.0 through the gateway 192.168.10.1 (which is not the default gateway of the
interface), and Media & Control applications to access peers on subnet 171.79.39.0
through the gateway 200.200.85.10 (which is not the default gateway of the interface).
Table 12-15: Separate Static Route Table Example
Destination
Prefix Length
Gateway
Device Name
17.17.0.0
16
192.168.10.1
100
171.79.39.0
24
200.200.85.10
200
12.5
Configuring Static IP Routes
The Static Route table lets you configure up to 30 static IP routing rules. Using static routes
lets you communicate with LAN networks that are not located behind the Default Gateway
specified for the IP network interface, configured in the Interface table, from which the
packets are sent.
Before sending an IP packet, the device searches the Static Route table for an entry that
matches the requested destination host/network. If an entry is found, the device sends the
packet to the gateway that is configured for the static route. If no explicit entry is found, the
packet is sent to the Default Gateway configured for the IP network interface.
You can view the status of the configured static routes in the IP Routing Status Table page.
This page can be accessed by clicking the Static Route Status Table button, located at
the bottom of the Static Route table page, or it can be accessed from the Navigation tree
under the Status & Diagnostics tab (see ''Viewing Static Routes Status'' on page 643).
The following procedure describes how to configure static routes in the Web interface. You
can also configure this using the table ini file parameter, StaticRouteTable or the CLI
command, configure voip/routing static.
 To configure a static IP route:
1.
Open the Static Route Table page (Configuration tab > VoIP menu > Network >
Static Route Table).
2.
Click Add; the following dialog box appears:
Version 6.8
123
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Configure a static route according to the parameters described in the table below.
4.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
Note: You can delete only static routing rules that are inactive.
Static Route Table Parameter Descriptions
Parameter
Description
Index
[StaticRouteTable_Index]
Defines an index number for the new table record.
The valid value is 0 to 29.
Note: Each table row must be configured with a unique index.
Device Name
CLI: device-name
[StaticRouteTable_DeviceNa
me]
Assigns an IP network interface through which the static route's
Gateway is reached. The Device Name (or underlying device)
represents the IP network interface, including VLAN ID and
associated physical port(s).
The value must be identical to the value in the 'Underlying Device'
parameter of the required IP network interface in the Interface
table (see Configuring IP Network Interfaces on page 116).
For configuring Ethernet Devices, see Configuring Underlying
Ethernet Devices on page 113.
Destination
CLI: destination
[StaticRouteTable_Destinatio
n]
Defines the IP address of the destination host/network. The
destination can be a single host or a whole subnet, depending on
the prefix length configured for this routing rule.
Prefix Length
CLI: prefix-length
[StaticRouteTable_PrefixLen
gth]
Defines the Classless Inter-Domain Routing (CIDR)-style
representation of a dotted-decimal subnet notation of the
destination host/network. The CIDR-style representation uses a
suffix indicating the number of bits that are set in the dotteddecimal format. For example, the value 16 represents subnet
255.255.0.0. The value must be 0 to 31 for IPv4 interfaces and a
value of 0 to 64 for IPv6 interfaces.
The address of the host/network you want to reach is determined by an AND operation that is
applied to the fields 'Destination' and 'Prefix Length'. For example, to reach the network 10.8.x.x,
enter 10.8.0.0 in the 'Destination' field and 16 in the 'Prefix Length'. As a result of the AND
operation, the value of the last two octets in the 'Destination' field is ignored. To reach a specific
host, enter its IP address in the 'Destination' field and 32 in the 'Prefix Length' field.
User's Manual
124
Document #: LTRT-27034
User's Manual
12. Network
Parameter
Description
Gateway
CLI: gateway
[StaticRouteTable_Gateway]
Defines the IP address of the Gateway (next hop) used for traffic
destined to the subnet/host defined in the 'Destination' / 'Prefix
Length' field.
Notes:
 The Gateway's address must be in the same subnet as the IP
address of the network interface that is associated with the
static route (using the 'Device Name' parameter - see above).
 The IP network interface associated with the static route must
be of the same IP address family (IPv4 or IPv6).
Description
CLI: description
[StaticRouteTable_Descriptio
n]
Defines an arbitrary name to easily identify the static route rule.
The valid value is a string of up to 20 characters.
12.5.1 Configuration Example of Static IP Routes
An example of the use for static routes is shown in the figure below. In the example
scenario, the device needs to communicate with a softswitch at IP address 10.1.1.10.
However, the IP network interface from which packets destined for 10.1.1.10 is sent, is
configured to send the packets to a Default Gateway at 10.15.0.1. Therefore, the packets
do not reach the softswitch. To resolve this problem, a static route is configured to specify
the correct gateway (10.15.7.22) in order to reach the softswitch.
Note the following configuration:

The static route is configured with a subnet mask of 24 (255.255.255.0), enabling the
device to use the static route to send all packets destined for 10.1.1.x to this gateway
and therefore, to the network in which the softswitch resides.

The static route in the Static Route table is associated with the IP network interface in
the Interface table, using the 'Device Name' and 'Underlying Device' parameters,
respectively.
Version 6.8
125
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

The static route's Gateway address in the Static Route table is in the same subnet as
the IP address of the IP network interface in the Interface table.
Figure 6: Example of using Static Route
12.5.2 Troubleshooting the Routing Table
When adding a new static route to the Static Route table, the added rule passes a
validation test. If errors are found, the static route is rejected and not added to the table.
Failed static route validations may result in limited connectivity (or no connectivity) to the
destinations specified in the incorrect static route. For any error found in the Static Route
table or failure to configure a static route, the device sends a notification message to the
Syslog server reporting the problem.
Common static routing configuration errors may include the following:

The IP address specified in the 'Gateway' field is unreachable from the IP network
interface associated with the static route.

The same destination is configured in two different static routes.

More than 30 static routes have been configured.
Note: If a static route is required to access OAMP applications (for remote
management, for example) and the route is not configured correctly, the route is not
added and the device is not accessible remotely. To restore connectivity, the device
must be accessed locally from the OAMP subnet and the required routes be
configured.
User's Manual
126
Document #: LTRT-27034
User's Manual
12.6
12. Network
Configuring Quality of Service
The QoS Settings page lets you configure Layer-2 and Layer-3 Quality of Service (QoS).
Differentiated Services (DiffServ) is an architecture providing different types or levels of
service for IP traffic. DiffServ (according to RFC 2474), prioritizes certain traffic types
based on priority, accomplishing a higher-level QoS at the expense of other traffic types.
By prioritizing packets, DiffServ routers can minimize transmission delays for time-sensitive
packets such as VoIP packets.
You can assign DiffServ to the following class of services (CoS) and assign VLAN priorities
(IEEE 802.1p) to various values of DiffServ:

Media Premium – RTP packets sent to the LAN

Control Premium – control protocol (SIP) packets sent to the LAN

Gold – HTTP streaming packets sent to the LAN

Bronze – OAMP packets sent to the LAN
The Layer-3 QoS parameters define the values of the DiffServ field in the IP header of the
frames related to a specific service class. The Layer-2 QoS parameters define the values
for the 3 priority bits in the VLAN tag according to the value of the DiffServ field in the
packet IP header (according to the IEEE 802.1p standard). The DiffServ table lets you
configure up to 64 DiffServ-to-VLAN Priority mapping (Layer 2 class of service). For each
packet sent to the LAN, the VLAN Priority of the packet is set according to the DiffServ
value in the IP header of the packet.
The mapping of an application to its CoS and traffic type is shown in the table below:
Table 12-16: Traffic/Network Types and Priority
Application
Traffic / Network Types
Class-of-Service (Priority)
Debugging interface
Management
Bronze
Telnet
Management
Bronze
DHCP
Management
Network
Web server (HTTP)
Management
Bronze
SNMP GET/SET
Management
Bronze
Web server (HTTPS)
Management
Bronze
RTP traffic
Media
Premium media
RTCP traffic
Media
Premium media
T.38 traffic
Media
Premium media
SIP
Control
Premium control
SIP over TLS (SIPS)
Control
Premium control
Syslog
Management
Bronze
SNMP Traps
Management
Bronze
DNS client
Varies according to DNS settings:
 OAMP
 Control
Depends on traffic type:
 Control: Premium Control
 Management: Bronze
NTP
Varies according to the interface
type associated with NTP (see
''Assigning NTP Services to
Depends on traffic type:
 Control: Premium control
Version 6.8
127
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Application
Traffic / Network Types
Application Types'' on page 119):
 OAMP
 Control
Class-of-Service (Priority)

Management: Bronze
The following procedure describes how to configure DiffServ-to-VLAN priority mapping in
the Web interface. You can also configure this using the table ini file parameter,
DiffServToVlanPriority or CLI command configure voip > qos vlan-mapping.
 To configure QoS:
1.
2.
Open the Diff Serv Table page (Configuration tab > VoIP menu > Network > QoS
Settings).
Configure DiffServ-to-VLAN priority mapping (Layer-2 QoS):
a.
Click Add; the following dialog box appears:
Figure 12-7: DiffServ Table Page - Add Record
b.
c.
Configure a DiffServ-to-VLAN priority mapping (Layer-2 QoS) according to the
parameters described in the table below.
Click Submit, and then save ("burn") your settings to flash memory.
Table 12-17: DiffServ Table Parameter Descriptions
Parameter
Description
Index
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Differentiated Services
CLI: diff-serv
[DiffServToVlanPriority_DiffServ]
Defines a DiffServ value.
The valid value is 0 to 63.
VLAN Priority
Defines the VLAN priority level.
CLI: vlan-priority
The valid value is 0 to 7.
[DiffServToVlanPriority_VlanPriority]
3.
Under the Differentiated Services group, configure DiffServ (Layer-3 QoS) values per
CoS.
Figure 12-8: QoS Settings Page - Differentiated Services
User's Manual
128
Document #: LTRT-27034
User's Manual
12.7
12. Network
Configuring ICMP Messages
Internet Control Message Protocol (ICMP) is one of the core protocols of the Internet
Protocol suite. It is used by network devices such as routers to send error messages
indicating, for example, that a requested service is unavailable.
You can configure the device to handle ICMP messages as follows:

Send and receive ICMP Redirect messages.

Send ICMP Destination Unreachable messages. The device sends this message in
response to a packet that cannot be delivered to its destination for reasons other than
congestion. The device sends a Destination Unreachable message upon any of the
following:
•
Address unreachable
•
Port unreachable
This feature is applicable to IPv4 and IPv6 addressing schemes.
The following procedure describes how to configure ICMP messaging in the Web interface.
You can also configure ICMP messaging using the ini file parameters
DisableICMPUnreachable (ICMP Unreachable messages) and DisableICMPRedirects
(ICMP Redirect messages).
 To configure handling of ICMP messages:
1.
Open the Network Settings page (Configuration tab > VoIP menu > Network >
Network Settings).
Figure 12-9: Configuring ICMP Messaging in Network Settings Page
2.
To enable or disable sending and receipt of ICMP Redirect messages, use the 'Send
and Receive ICMP Redirect Messages' parameter.
3.
To enable or disable the sending of ICMP Destination Unreachable messages, use
the 'Send ICMP Unreachable Messages' parameter.
4.
Click Submit.
Version 6.8
129
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
12.8
DNS
You can use the device's embedded domain name server (DNS) or an external, third-party
DNS to translate domain names into IP addresses. This is useful if domain names are used
as the destination in call routing. The device supports the configuration of the following
DNS types:

Internal DNS table - see ''Configuring the Internal DNS Table'' on page 130

Internal SRV table - see ''Configuring the Internal SRV Table'' on page 131
12.8.1 Configuring the Internal DNS Table
The Internal DNS table, similar to a DNS resolution, translates up to 20 host (domain)
names into IP addresses. This functionality can be used when a domain name (FQDN) is
configured as an IP destination in a routing rule. Up to four different IP addresses can be
assigned to the same host name. This is typically used for alternative Tel-to-IP call routing.
Note: The device initially attempts to resolve a domain name using the Internal DNS
table. If the domain name is not configured in the table, the device performs a DNS
resolution using an external DNS server for the related IP network interface (see
''Configuring IP Network Interfaces'' on page 116).
The following procedure describes how to configure the DNS table in the Web interface.
You can also this using the table ini file parameter, DNS2IP or CLI command, configure
voip > voip-network dns dns-to-ip.
 To configure the internal DNS table:
1.
Open the Internal DNS Table page (Configuration tab > VoIP menu > Network >
DNS > Internal DNS Table).
2.
Click Add; the following dialog box appears:
Figure 12-10: Internal DNS Table - Add Record Dialog Box
3.
Configure the DNS rule, as required. For a description of the parameters, see the
table below.
4.
Click Submit; the DNS rule is added to the table.
User's Manual
130
Document #: LTRT-27034
User's Manual
12. Network
Table 12-18: Internal DNS Table Parameter Description
Parameter
Description
Domain Name
CLI: domain-name
[Dns2Ip_DomainName]
Defines the host name to be translated.
The valid value is a string of up to 31 characters.
First IP Address
CLI: first-ip-address
[Dns2Ip_FirstIpAddress]
Defines the first IP address (in dotted-decimal format notation) to
which the host name is translated. The IP address can be
configured as an IPv4 and/or IPv6 address.
Second IP Address
CLI: second-ip-address
[Dns2Ip_SecondIpAddress]
Defines the second IP address (in dotted-decimal format notation)
to which the host name is translated.
Third IP Address
CLI: third-ip-address
[Dns2Ip_ThirdIpAddress]
Defines the third IP address (in dotted-decimal format notation) to
which the host name is translated.
Fourth IP Address
CLI: fourth-ip-address
[Dns2Ip_FourthIpAddress]
Defines the fourth IP address (in dotted-decimal format notation) to
which the host name is translated.
12.8.2 Configuring the Internal SRV Table
The Internal SRV table resolves host names to DNS A-Records. Three different A-Records
can be assigned to each host name, where each A-Record contains the host name,
priority, weight, and port.
Note: If you configure the Internal SRV table, the device initially attempts to resolve a
domain name using this table. If the domain is not configured in the table, the device
performs a Service Record (SRV) resolution using an external DNS server,
configured in the Interface table (see ''Configuring IP Network Interfaces'' on page
116).
The following procedure describes how to configure the Internal SRV table in the Web
interface. You can also configure this using the table ini file parameter, SRV2IP or CLI
command, configure voip > voip-network dns srv2ip.
Version 6.8
131
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure an SRV rule:
1.
Open the Internal SRV Table page (Configuration tab > VoIP menu > Network >
DNS > Internal SRV Table).
2.
Click Add; the following dialog box appears:
Figure 12-11: Internal SRV Table Page
3.
Configure an SRV rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 12-19: Internal SRV Table Parameter Descriptions
Parameter
Description
Domain Name
CLI: domain-name
[Srv2Ip_InternalDomain]
Defines the host name to be translated.
The valid value is a string of up to 31 characters.
Transport Type
CLI: transport-type
[Srv2Ip_TransportType]
Defines the transport type.
 [0] UDP (default)
 [1] TCP
 [2] TLS
DNS Name (1-3)
CLI: dns-name-1|2|3
[Srv2Ip_Dns1/2/3]
Defines the first, second or third DNS A-Record to which the host
name is translated.
Priority (1-3)
CLI: priority-1|2|3
[Srv2Ip_Priority1/2/3]
Defines the priority of the target host. A lower value means that it is
more preferred.
Weight (1-3)
CLI: weight-1|2|3
[Srv2Ip_Weight1/2/3]
Defines a relative weight for records with the same priority.
User's Manual
132
Document #: LTRT-27034
User's Manual
12. Network
Parameter
Port (1-3)
CLI: port-1|2|3
[Srv2Ip_Port1/2/3]
12.9
Description
Defines the TCP or UDP port on which the service is to be found.
Open Solution Network (OSN) Server
This section describes various networking settings for the OSN server.
Notes:
• The OSN is a customer-ordered item.
• For information on cabling the OSN, refer to the device's Hardware Installation
Manual.
12.9.1 Configuring Native VLAN for OSN Server
You can configure a VLAN ID associated with any application type (Media, Control, or
OAMP) to access the Open Solution Network (OSN) server through the device's internal
port switch. By default, access to the OSN is from the OAMP interface VLAN (ID 1).
Configuring a Native VLAN is useful, for example, to separate traffic within the device between the OSN (i.e., application traffic) and voice traffic.
This feature is applicable only if you connect to the OSN through one of the device's VoIP
LAN ports (on the front panel). If you are connecting to the OSN through the OSN's Gigabit
Ethernet port (on the rear panel), this feature is not applicable.
 To configure a Native VLAN for the OSN:
1.
Open the Application Settings page (Configuration tab > System menu >
Application Settings).
2.
In the 'OSN Native VLAN ID' field, set the VLAN ID.
3.
Click Submit.
When set to 0 (default), the OSN uses the OAMP VLAN ID. When set to any other value, it
specifies a VLAN configured in the Ethernet Device table (see ''Configuring Underlying
Ethernet Devices'' on page 113), which is assigned to a Media and/or Control application in
the Interface table.
12.9.2 Disabling Internal Switch Port for OSN
You can enable (default) or disable the Ethernet port of the device's internal switch that
interfaces with the OSN. You can view the port status (Up or Down) by running the
following CLI command:
# show system interface osn
 To enable / disable the internal switch's Ethernet port interfacing with OSN:
1.
Open the Application Settings page (Configuration tab > System menu >
Application Settings).
2.
From the 'Block OSN Port' drop-down list, select Enable or Disable.
3.
Click Submit.
Version 6.8
133
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
12.10 Configuring NFS Settings
Network File System (NFS) enables the device to access a remote server's shared files
and directories and to handle them as if they're located locally. The device can use NFS to
load cmp, ini, and auxiliary files through the Automatic Update mechanism (see
Configuration using FTP or NFS).
You can configure up to 16 different NFS file systems. As a file system, the NFS is
independent of machine types, operating systems and network architectures. Note that an
NFS file server can share multiple file systems. There must be a separate row for each
remote file system shared by the NFS file server that needs to be accessed by the device.
The following procedure describes how to configure NFS in the Web interface. You can
also configure this using the table ini file parameter, NFSServers or CLI command,
configure system > nfs > servers.
 To configure an NFS file systems:
1.
Open the Application Settings page (Configuration tab > System menu >
Application Settings).
2.
Under the NFS Settings group, click the NFS Table
appears.
3.
Click Add; the following dialog box appears:
button; the NFS Table page
Figure 12-12: NFS Table Page - Add Record
4.
Configure the NFS parameters according to the table below.
5.
Configure an NFS according to the parameters described in the table below.
6.
Click Submit, and then save ("burn") your settings to flash memory. The remote NFS
file system is immediately applied, which can be verified by the appearance of the
"NFS mount was successful" message in the Syslog server.
Notes:
• To avoid terminating current calls, do not delete or edit a row while the device is
currently accessing files on that remote NFS file system.
• The combination of 'Host Or IP' and 'Root Path' must be unique for each row in the
table. For example, the table must include only one row with a Host/IP of
192.168.1.1 and Root Path of /audio.
Table 12-20: NFS Table Parameter Descriptions
Parameter
Index
User's Manual
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
134
Document #: LTRT-27034
User's Manual
12. Network
Parameter
Description
Host or IP
CLI: host
[NFSServers_HostOrIP]
The domain name or IP address of the NFS server. If a domain name is
provided, a DNS server must be configured.
Root Path
CLI: root-path
[NFSServers_RootPath]
Path to the root of the remote file system in the format: /[path]. For
example, '/audio'.
NFS Version
CLI: version
[NFSServers_NfsVersion]
NFS version used to access the remote file system.
 [2] NFS Version 2
 [3] NFS Version 3 (default)
Authentication Type
CLI: authentication-type
[NFSServers_AuthType]
Authentication method used for accessing the remote file system.
 [0] Null
 [1] Unix (default)
User ID
CLI: uid
[NFSServers_UID]
User ID used in authentication when using Unix.
The valid range is 0 to 65537. The default is 0.
Group ID
CLI: gid
[NFSServers_GID]
Group ID used in authentication when using Unix.
The valid range is 0 to 65537. The default is 1.
VLAN Type
CLI: vlan-type
[NFSServers_VlanType]
The VLAN type for accessing the remote file system.
 [0] OAMP
 [1] Media (default)
Note: This parameter applies only if VLANs are enabled or if Multiple
IPs is configured (see ''Configuring IP Network Interfaces'' on page
116).
12.11 Network Address Translation Support
Network Address Translation (NAT) is a mechanism that maps internal IP addresses (and
ports) used within a private network to global IP addresses and vice versa, providing
transparent routing to end hosts. The primary advantages of NAT include (1) reduction in
the number of global IP addresses required in a private network (global IP addresses are
only used to connect to the Internet) and (2) better network security by hiding the internal
architecture.
The design of SIP creates a problem for VoIP traffic to pass through NAT. SIP uses IP
addresses and port numbers in its message body. However, the NAT server is unable to
modify the SIP messages and thus, can’t change local addresses to global addresses.
This section discusses the device's solutions for overcoming NAT traversal issues.
12.11.1 Device Located behind NAT
Two different streams traverse through NAT - signaling and media. A device located
behind a NAT that initiates a signaling path has problems receiving incoming signaling
responses as they are blocked by the NAT server. Therefore, the initiating device must
inform the receiving device where to send the media. To resolve this NAT problem, the
following solutions are provided by the device, listed in priority of the selected method used
by the device:
a. If configured, uses the single Static NAT IP address for all interfaces - see
''Configuring a Static NAT IP Address for All Interfaces'' on page 136.
Version 6.8
135
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
b.
If configured, uses the NAT Translation table which configures NAT per interface - see
Configuring NAT Translation per IP Interface on page 137.
If NAT is not configured by any of the above-mentioned methods, the device sends the
packet according to its IP address configured in the Interface table.
Note: The priority list above is applicable only to the Gateway calls.
The figure below illustrates the NAT problem faced by the SIP networks where the device
is located behind a NAT:
Figure 12-13: Device behind NAT and NAT Issues
12.11.1.1
Configuring a Static NAT IP Address for All Interfaces
You can configure a global (public) IP address of the router to enable static NAT between
the device and the Internet for all network interfaces. Thus, the device replaces the source
IP address for media of all outgoing SIP messages sent on any of its network interfaces to
this public IP address.
The following procedure describes how to configure a static NAT address in the Web
interface. You can also configure this using the ini file parameter, StaticNATIP or CLI
command, configure voip > sip-definition general-settings > nat-ip-addr.
 To configure a single static NAT IP address:
1.
Open the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters).
Figure 12-14: Configuring Static NAT IP Address in SIP General Parameters Page
2.
In the 'NAT IP Address' field, enter the NAT IP address in dotted-decimal notation.
3.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
User's Manual
136
Document #: LTRT-27034
User's Manual
12.11.1.2
12. Network
Configuring NAT Translation per IP Interface
The NAT Translation table lets you configure up to 32 network address translation (NAT)
rules for translating source IP addresses per VoIP interface (SIP control and RTP media
traffic) into NAT IP addresses (global or public), when the device is located behind NAT.
This allows, for example, the separation of VoIP traffic between different ITSP’s, and
topology hiding of internal IP addresses to the “public” network. Each IP interface
(configured in the Interface table) can be associated with a NAT rule in this table,
translating the source IP address and port of the outgoing packet into the NAT address (IP
address and port range). The device's NAT traversal mechanism replaces the source IP
address of SIP messages sent from a specified VoIP interface to a public IP address.
The following procedure describes how to configure NAT translation rules in the Web
interface. You can also configure Bandwidth Profiles using the table ini file parameter,
NATTranslation or CLI command, voip-network NATTranslation.
 To configure NAT translation rules:
1.
Open the NAT Translation Table page (Configuration tab > VoIP menu > VoIP
Network > NAT Translation Table).
2.
Click Add; the following dialog box appears:
Figure 12-15: NAT Translation Table Page
3.
Configure a NAT translation rule according to the parameters described in the table
below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 12-21: NAT Translation Table Parameter Descriptions
Parameter
Index
CLI: index
[NATTranslation_Index]
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a
unique index.
Source Interface Name
Defines the name of the IP interface, as configured in
CLI: SourceIPInterfaceName
the Interface table.
[NATTranslation_SourceIPInterfaceName]
Target IP Address
CLI: TargetIPAddress
[NATTranslation_TargetIPAddress]
Version 6.8
Defines the global IP address. This address is set in
the SIP Via and Contact headers as well as in the o=
and c= SDP fields.
137
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Source Start Port
CLI: SourceStartPort
[NATTranslation_SourceStartPort]
Defines the optional starting port range (1-65536) of
the IP interface, used as matching criteria for this NAT
rule. If not configured, the match is done on the entire
port range. Only IP addresses and ports of matched
source ports will be replaced.
Source End Port
CLI: SourceEndPort
[NATTranslation_SourceEndPort]
Defines the optional ending port range (1-65536) of
the IP interface, used as matching criteria for this NAT
rule. If not configured, the match is done on the entire
port range. Only IP addresses and ports of matched
source ports will be replaced.
Target Start Port
CLI: TargetStartPort
[NATTranslation_TargetStartPort]
Defines the optional, starting port range (1-65536) of
the global address. If not configured, the ports are not
replaced. Matching source ports are replaced with the
target ports. This address is set in the SIP Via and
Contact headers, as well as in the o= and c= SDP
fields.
Target End Port
CLI: TargetEndPort
[NATTranslation_TargetEndPort]
Defines the optional, ending port range (1-65536) of
the global address. If not configured, the ports are not
replaced. Matching source ports are replaced with the
target ports. This address is set in the SIP Via and
Contact headers, as well as in the o= and c= SDP
fields.
12.11.2 Remote UA behind NAT
12.11.2.1
SIP Signaling Messages
By default, the device resolves NAT issues for SIP signaling, using its NAT Detection
mechanism. The NAT Detection mechanism checks whether the endpoint is located behind
NAT, by comparing the incoming packet's source IP address with the SIP Contact header's
IP address. If the packet's source IP address is a public address and the Contact header's
IP address a local address, the device considers the endpoint as located behind NAT. In
this case, the device sends the SIP messages to the endpoint, using the packet's source IP
address. Otherwise (or if you have disabled the NAT Detection mechanism), the device
sends the SIP messages according to the SIP standard RFC 3261, where requests within
the SIP dialog are sent using the IP address in the Contact header, and responses to
INVITEs are sent using the IP address in the Via header. To enable or disable the device's
NAT Detection mechanism, use the 'SIP NAT Detection' parameter.
If necessary, you can also configure the device to always consider incoming SIP INVITE
messages as sent from endpoints that are located behind NAT. When this is enabled, the
device sends responses to the INVITE (to the endpoint), using the the source IP address of
the packet (INVITE) initially received from the endpoint. This is especially useful in
scenarios where the endpoint is located behind a NAT firewall and the device (for whatever
reason) is unable to identify NAT using its regular NAT Detection mechanism. This feature
is enabled per specific calls using IP Groups. To configure this feature, use the 'Always
Use Source Address' parameter in the IP Group table (see ''Configuring IP Groups'' on
page 261). If this feature is disabled, the device's NAT detection is according to the settings
of the global parameter, 'SIP NAT Detection' parameter.
User's Manual
138
Document #: LTRT-27034
User's Manual
12.11.2.2
12. Network
Media (RTP/RTCP/T.38)
When a remote UA initiates a call and is not located behind a NAT server, the device
sends the RTP (or RTCP, T.38) packets to the remote UA using the IP address / UDP port
in the SIP message (Contact header). However, if the UA is located behind NAT, the
device sends the RTP with the IP address of the UA (i.e., private IP address) as the
destination, instead of that of the NAT server. Thus, the RTP will not reach the UA.
To resolve this NAT traversal problem, the device offers the following features:

First Incoming Packet Mechanism - see ''First Incoming Packet Mechanism'' on page
139

RTP No-Op packets according to the avt-rtp-noop draft - see ''No-Op Packets'' on
page 140
The figure below illustrates a typical network architecture where the remote UA is located
behind NAT:
Figure 12-16: Remote UA behind NAT
12.11.2.2.1
First Incoming Packet Mechanism
In scenarios where the remote user agent (UA) resides behind a NAT server, it’s possible
that the device, if not configured for NAT traversal, will send the media (RTP, RTCP and
T.38) streams to an invalid IP address / UDP port (i.e., private IP address:port of UA and
not the public address). When the UA is located behind a NAT, although the UA sends its
private IP address:port in the original SIP message (INVITE), the device receives the
subsequent media packets with a source address of a public IP address:port (i.e., allocated
by the NAT server). Therefore, to ensure that the media reaches the UA, the device must
send it to the public address.
The device identifies whether the UA is located behind NAT, by comparing the source IP
address of the first received media packet, with the IP address and UDP port of the first
received SIP message (INVITE) when the SIP session was started. This is done for each
media type--RTP, RTCP and T.38--and therefore, they can have different destination IP
addresses and UDP ports than one another.
The EnableIpAddrTranslation and EnableUdpPortTranslation parameters specify the type
of compare operation that occurs on the first incoming packet. To compare only the IP
address, set EnableIpAddrTranslation to 1 and EnableUdpPortTranslation to 0. In this
case, if the first incoming packet arrives with only a difference in the UDP port, the sending
addresses won’t change. If both the IP address and UDP port need to be compared, then
both parameters need to be set to 1.
You can configure the device's NAT feature to operate in one of the following modes:

Version 6.8
Auto-Detect: NAT is performed only if necessary. If the UA is identified as being
located behind NAT, the device sends the media packets to the public IP address:port
obtained from the source address of the first media packet received from the UA.
Otherwise, the packets are sent using the IP address:port obtained from the first
139
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
received SIP message. Note also that if the SIP session is established (ACK) and the
device (not the UA) sends the first packet, it sends it to the address obtained from the
SIP message and only after the device receives the first packet from the UA, does it
determine whether the UA is behind NAT.

NAT Is Not Used: (Default) NAT feature is disabled. The device considers the UA as
not located behind NAT and always sends the media packets to the UA using the IP
address:port obtained from the first received SIP message.

NAT Is Used: NAT is always performed. The device considers the UA as located
behind NAT and always sends the media packets to the UA using the source address
obtained from the first media packet received from the UA. In this mode, the device
does not send any packets until it receives the first packet from the UA (in order to
obtain the IP address).
 To enable NAT resolution using the First Incoming Packet mechanism:
1.
Open the General Settings page (Configuration tab > VoIP menu > Media > General
Media Settings).
2.
Set the 'NAT Mode parameter to one of the following:
3.
12.11.2.2.2
•
[0] Auto-Detect
•
[1] NAT Is Not Used
•
[2] NAT Is Used
Click Submit.
No-Op Packets
The device's No-Op packet support can be used to verify Real-Time Transport Protocol
(RTP) and T.38 connectivity, and to keep NAT bindings and Firewall pinholes open. The
No-Op packets are available for sending in RTP and T.38 formats.
You can control the activation of No-Op packets by using the ini file parameter
NoOpEnable. If No-Op packet transmission is activated, you can control the time interval in
which No-Op packets are sent in the case of silence (i.e., no RTP or T.38 traffic). This is
done using the ini file parameter NoOpInterval. For a description of the RTP No-Op ini file
parameters, see ''Networking Parameters'' on page 728.

RTP No-Op: The RTP No-Op support complies with IETF Internet-Draft draft-wingavt-rtp-noop-03 ("A No-Op Payload Format for RTP"). This IETF document defines a
No-Op payload format for RTP. The draft defines the RTP payload type as dynamic.
You can control the payload type with which the No-Op packets are sent. This is
performed using the RTPNoOpPayloadType ini parameter (see ''Networking
Parameters'' on page 728). The default payload type is 120.

T.38 No-Op: T.38 No-Op packets are sent only while a T.38 session is activated. Sent
packets are a duplication of the previously sent frame (including duplication of the
sequence number).
Note: Receipt of No-Op packets is always supported.
User's Manual
140
Document #: LTRT-27034
User's Manual
12. Network
12.12 Robust Receipt of Media Streams by Media Latching
The Robust Media mechanism (or media latching) is an AudioCodes proprietary
mechanism to filter out unwanted media (RTP, RTCP, SRTP, SRTCP, and T.38) streams
that are sent to the same port number of the device. Media ports may receive additional
multiple unwanted media streams (from multiple sources of traffic) as result of traces of
previous calls, call control errors, or deliberate malicious attacks (e.g., Denial of Service).
When the device receives more than one media stream on the same port, the Robust
Media mechanism detects the valid media stream and ignores the rest. Thus, this can
prevent an established call been stolen by a malicious attacker on the media stream.
For a detailed description of the robust media parameters, see ''General Security
Parameters'' on page 748.
Version 6.8
141
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
12.13 Multiple Routers Support
Multiple routers support is designed to assist the device when it operates in a multiple
routers network. The device learns the network topology by responding to Internet Control
Message Protocol (ICMP) redirections and caches them as routing rules (with expiration
time).
When a set of routers operating within the same subnet serve as devices to that network
and intercommunicate using a dynamic routing protocol, 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 device 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.
User's Manual
142
Document #: LTRT-27034
User's Manual
13
13. Security
Security
This section describes the VoIP security-related configuration.
13.1
Configuring Firewall Settings
The Firewall Settings table lets you configure the device's Firewall, which defines network
traffic filtering rules (access list). You can add up to 50 firewall rules. The access list offers
the following firewall possibilities:

Block traffic from known malicious sources

Allow traffic only from known "friendly" sources, and block all other traffic

Mix allowed and blocked network sources

Limit traffic to a user-defined rate (blocking the excess)

Limit traffic to specific protocols, and specific port ranges on the device
For each packet received on the network interface, the table is scanned from top to bottom
until the first matching rule is found. This rule can either permit (allow) or deny (block) the
packet. Once a rule in the table is located, subsequent rules further down the table are
ignored. If the end of the table is reached without a match, the packet is accepted.
Notes:
• This firewall applies to a very low-level network layer and overrides all your other
security-related configuration. Thus, if you have configured higher-level security
features (e.g., on the Application level), you must also configure firewall rules to
permit this necessary traffic. For example, if you have configured IP addresses to
access the Web and Telnet interfaces in the Web Access List (see ''Configuring
Web and Telnet Access List'' on page 64), you must configure a firewall rule that
permits traffic from these IP addresses.
• Only Security Administrator users or Master users can configure firewall rules.
• Setting the 'Prefix Length' field to 0 means that the rule applies to all packets,
regardless of the defined IP address in the 'Source IP' field. Thus, it is highly
recommended to set this parameter to a value other than 0.
• It is recommended to add a rule at the end of your table that blocks all traffic and
to add firewall rules above it that allow required traffic (with bandwidth limitations).
To block all traffic, use the following firewall rule:
√
Source IP: 0.0.0.0
√
Prefix Length: 0 (i.e., rule matches all IP addresses)
√
Start Port - End Port: 0-65535
√
Protocol: Any
√
Action Upon Match: Block
The following procedure describes how to configure Firewall rules in the Web interface.
You can also configure this using the table ini file parameter, AccessList or the CLI
command, configure voip/access-list.
Version 6.8
143
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure a Firewall rule:
1.
Open the Firewall Settings page (Configuration tab > VoIP menu > Security >
Firewall Settings).
2.
Click Add; the following dialog box appears:
Figure 13-1: Firewall Settings Page - Add Record
3.
Configure a Firewall rule according to the parameters described in the table below.
4.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
Table 13-1: Firewall Settings Table Parameter Descriptions
Parameter
Description
Index
Defines an index number for the new table record.
Note: Each table row must be configured with a unique
index.
Source IP
CLI: source-ip
[AccessList_Source_IP]
Defines the IP address (or DNS name) or a specific host
name of the source network (i.e., from where the incoming
packet is received).
Source Port
CLI: src-port
[AccessList_Source_Port]
Defines the source UDP/TCP ports (of the remote host)
from where packets are sent to the device.
The valid range is 0 to 65535.
Note: When set to 0, this field is ignored and any source
port matches the rule.
User's Manual
144
Document #: LTRT-27034
User's Manual
13. Security
Parameter
Description
Prefix Length
CLI: prefixLen
[AccessList_PrefixLen]
(Mandatory) Defines the IP network mask - 32 for a single
host or the appropriate value for the source IP addresses.
 A value of 8 corresponds to IPv4 subnet class A
(network mask of 255.0.0.0).
 A value of 16 corresponds to IPv4 subnet class B
(network mask of 255.255.0.0).
 A value of 24 corresponds to IPv4 subnet class C
(network mask of 255.255.255.0).
The IP address of the sender of the incoming packet is
trimmed in accordance with the prefix length (in bits) and
then compared to the parameter ‘Source IP’.
The default is 0 (i.e., applies to all packets). You must
change this value to any of the above options.
Note: A value of 0 applies to all packets, regardless of the
defined IP address. Therefore, you must set this parameter
to a value other than 0.
Start Port
CLI: start-port
[AccessList_Start_Port]
Defines the destination UDP/TCP start port (on this device)
to where packets are sent.
The valid range is 0 to 65535.
Note: When the protocol type isn't TCP or UDP, the entire
range must be provided.
End Port
CLI: end-port
[AccessList_End_Port]
Defines the destination UDP/TCP end port (on this device)
to where packets are sent.
The valid range is 0 to 65535.
Note: When the protocol type isn't TCP or UDP, the entire
range must be provided.
Protocol
CLI: protocol
[AccessList_Protocol]
Defines the protocol type (e.g., UDP, TCP, ICMP, ESP or
'Any') or the IANA protocol number in the range of 0 (Any) to
255.
Note: This field also accepts the abbreviated strings 'SIP'
and 'HTTP'. Specifying these strings implies selection of the
TCP or UDP protocols, and the appropriate port numbers as
defined on the device.
Use Specific Interface
Determines whether you want to apply the rule to a specific
CLI: use-specific-interface
network interface defined in the Interface table (i.e., packets
[AccessList_Use_Specific_Interface] received from that defined in the Source IP field and
received on this network interface):
 [0] Disable (default)
 [1] Enable
Notes:
 If enabled, then in the 'Interface Name' field (described
below), select the interface to which the rule is applied.
 If disabled, then the rule applies to all interfaces.
Interface Name
CLI: network-interface-name
[AccessList_Interface_x]
Version 6.8
Defines the network interface to which you want to apply the
rule. This is applicable if you enabled the 'Use Specific
Interface' field. The list displays interface names as defined
in the Interface table in ''Configuring IP Network Interfaces''
on page 116.
145
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Packet Size
CLI: packet-size
[AccessList_Packet_Size]
Defines the maximum allowed packet size.
The valid range is 0 to 65535.
Note: When filtering fragmented IP packets, this field
relates to the overall (re-assembled) packet size, and not to
the size of each fragment.
Byte Rate
CLI: byte-rate
[AccessList_Byte_Rate]
Defines the expected traffic rate (bytes per second), i.e., the
allowed bandwidth for the specified protocol. In addition to
this field, the 'Burst Bytes' field provides additional
allowance such that momentary bursts of data may utilize
more than the defined byte rate, without being interrupted.
For example, if 'Byte Rate' is set to 40000 and 'Burst Bytes'
to 50000, then this implies the following: the allowed
bandwidth is 40000 bytes/sec with extra allowance of 50000
bytes; if, for example, the actual traffic rate is 45000
bytes/sec, then this allowance would be consumed within 10
seconds, after which all traffic exceeding the allocated
40000 bytes/sec is dropped. If the actual traffic rate then
slowed to 30000 bytes/sec, then the allowance would be
replenished within 5 seconds.
Burst Bytes
CLI: byte-burst
[AccessList_Byte_Burst]
Defines the tolerance of traffic rate limit (number of bytes).
The default is 0.
Action Upon Match
CLI: allow-type
[AccessList_Allow_Type]
Defines the firewall action to be performed upon rule match.
 "Allow" = (Default) Permits these packets
 "Block" = Rejects these packets
Match Count
[AccessList_MatchCount]
(Read-only) Displays the number of packets accepted or
rejected by the rule.
The table below provides an example of configured firewall rules:
Table 13-2: Configuration Example of Firewall Rules
Firewall Rule
Parameter
1
2
3
4
5
Source IP
12.194.231.76 12.194.230.7
0.0.0.0
192.0.0.0
0.0.0.0
Prefix Length
16
16
0
8
0
Start Port and End
Port
0-65535
0-65535
0-65535
0-65535
0-65535
Protocol
Any
Any
icmp
Any
Any
Use Specific
Interface
Enable
Enable
Disable
Enable
Disable
Interface Name
WAN
WAN
None
Voice-Lan
None
Byte Rate
0
0
40000
40000
0
Burst Bytes
0
0
50000
50000
0
Action Upon Match
Allow
Allow
Allow
Allow
Block
User's Manual
146
Document #: LTRT-27034
User's Manual
13. Security
The firewall rules in the above configuration example do the following:
13.2

Rules 1 and 2: Typical firewall rules that allow packets ONLY from specified IP
addresses (e.g., proxy servers). Note that the prefix length is configured.

Rule 3: A more "advanced” firewall rule - bandwidth rule for ICMP, which allows a
maximum bandwidth of 40,000 bytes/sec with an additional allowance of 50,000 bytes.
If, for example, the actual traffic rate is 45,000 bytes/sec, then this allowance would be
consumed within 10 seconds, after which all traffic exceeding the allocated 40,000
bytes/sec is dropped. If the actual traffic rate then slowed to 30,000 bytes/sec, the
allowance would be replenished within 5 seconds.

Rule 4: Allows traffic from the LAN voice interface and limits bandwidth.

Rule 5: Blocks all other traffic.
Configuring General Security Settings
The device uses TLS over TCP to encrypt and optionally, authenticate SIP messages. This
is referred to as Secure SIP (SIPS). SIPS uses the X.509 certificate exchange process, as
described in 'Configuring SSL/TLS Certificates' on page 91, where you need to configure
certificates (TLS Context).
Notes:
• When a TLS connection with the device is initiated by a SIP client, the device also
responds using TLS, regardless of whether or not TLS was configured.
• For backward compatibility, the following parameters can be used:
√
SIPTransportType to enable TLS.
√
TLSLocalSIPPort to configure the device's port used for TLS traffic.
 To configure SIPS:
1.
Configure a TLS Context as required.
2.
Assign the TLS Context to a Proxy Set or SIP Interface (see Configuring Proxy Sets
on page 272 and Configuring SIP Interfaces on page 258, respectively).
3.
Configure a SIP Interface with a TLS port number.
4.
Configure various SIPS parameters in the General Security Settings page
(Configuration tab > VoIP menu > Security > General Security Settings).
For a description of the TLS parameters, see TLS Parameters on page 751.
5.
Version 6.8
By default, the device initiates a TLS connection only for the next network hop. To
enable TLS all the way to the destination (over multiple hops), set the 'Enable SIPS'
(EnableSIPS) parameter to Enable in the SIP General Parameters page
(Configuration tab > VoIP menu > SIP Definitions > General Parameters).
147
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
13.3
Intrusion Detection System
The device's Intrusion Detection System (IDS) feature detects malicious attacks on the
device and reacts accordingly. A remote host is considered malicious if it has reached or
exceeded a user-defined threshold (counter) of specified malicious attacks.
If malicious activity is detected, the device can do the following:

Block (blacklist) remote hosts (IP addresses / ports) considered by the device as
malicious. The device automatically blacklists the malicious source for a user-defined
period after which it is removed from the blacklist.

Send SNMP traps to notify of malicious activity and/or whether an attacker has been
added to or removed from the blacklist. For more information, see ''Viewing IDS
Alarms'' on page 155.
The Intrusion Detection System (IDS) is an important feature for Enterprises to ensure
legitimate calls are not being adversely affected by attacks and to prevent Theft of Service
and unauthorized access.
There are many types of malicious attacks, the most common being:

Denial of service: This can be Denial of Service (DoS) where an attacker wishing to
prevent a server from functioning correctly directs a large amount of requests –
sometimes meaningless and sometimes legitimate, or it can be Distributed Denial of
Service (DDoS) where the attacker controls a large group of systems to coordinate a
large scale DoS attack against a system:
•
Message payload tampering: Attacker may inject harmful content into a message,
e.g., by entering meaningless or wrong information, with the goal of exploiting a
buffer overflow at the target. Such messages can be used to probe for
vulnerabilities at the target.
•
Message flow tampering: This is a special case of DoS attacks. These attacks
disturb the ongoing communication between users. An attacker can then target
the connection by injecting fake signaling messages into the communication
channel (such as CANCEL messages).
•
Message Flooding: The most common DoS attack is where an attacker sends a
huge amount of messages (e.g., INVITEs) to a target. The goal is to overwhelm
the target’s processing capabilities, thereby rendering the target inoperable.

SPAM over Internet Telephony (SPIT): VoIP spam is unwanted, automatically
dialed, pre-recorded phone calls using VoIP. It is similar to e-mail spam.

Theft of Service (ToS): Service theft can be exemplified by phreaking, which is a type
of hacking that steals service (i.e., free calls) from a service provider, or uses a service
while passing the cost to another person.
The IDS configuration is based on IDS Policies, where each policy can be configured with
a set of IDS rules. Each rule defines a type of malicious attack to detect and the number of
attacks during an interval (threshold) before an SNMP trap is sent. Each policy is then
applied to a target under attack (SIP interface) and/or source of attack (Proxy Set and/or
subnet address).
User's Manual
148
Document #: LTRT-27034
User's Manual
13. Security
13.3.1 Enabling IDS
The following procedure describes how to enable IDS.
 To enable IDS:
1.
Open the IDS Global Parameters page (Configuration tab > VoIP menu > Security >
Intrusion Detection and Prevention > Global Parameters).
Figure 13-2: Enabling IDS on IDS Global Parameters Page
2.
From the 'Intrusion Detection System' drop-down list, select Enable.
3.
Click Submit, and then reset the device with a burn-to-flash for the setting to take
effect.
13.3.2 Configuring IDS Policies
Configuring IDS Policies is a two-stage process that includes the following tables:
1.
IDS Policy (parent table): Defines a name and description for the IDS Policy. You
can configure up to 20 IDS Policies.
2.
IDS Rules table (child table): Defines the actual rules for the IDS Policy. Each IDS
Policy can be configured with up to 20 rules.
Note: A maximum of 100 IDS rules can be configured (regardless of how many rules
are assigned to each policy).
The device provides the following pre-configured IDS Policies that can be used in your
deployment (if they meet your requirements):

"DEFAULT_FEU": IDS Policy for far-end users in the WAN

"DEFAULT_PROXY": IDS Policy for proxy server

"DEFAULT_GLOBAL": IDS Policy with global thresholds
These default IDS Policies are read-only and cannot be modified.
 To configure an IDS Policy:
1.
Open the IDS Policy Table page (Configuration tab > VoIP menu > Security >
Intrusion Detection and Prevention > Policy Table); the table shows the preconfigured IDS policies:
Figure 13-3: IDS Policy Table with Default Rules
Version 6.8
149
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
2.
Click Add; the following dialog box appears:
Figure 13-4: IDS Policy Table - Add Record
3.
Configure an IDS Policy name according to the parameters described in the table
below.
4.
Click Submit.
Table 13-3: IDS Policy Table Parameter Descriptions
Parameter
Description
Index
CLI: policy
[IDSPolicy_Index]
Defines an index number for the new table record.
Name
CLI: rule
[IDSPolicy_Description]
Defines an arbitrary name to easily identify the IDS Policy.
The valid value is a string of up to 20 characters.
Description
[IDSPolicy_Name]
Defines a brief description for the IDS Policy.
The valid value is a string of up to 100 characters.
5.
In the IDS Policy table, select the required IDS Policy row, and then click the IDS Rule
Table link located below the table; the IDS Rule table opens:
Figure 13-5: IDS Rule Table of Selected IDS Policy
User's Manual
150
Document #: LTRT-27034
User's Manual
6.
13. Security
Click Add; the following dialog box appears:
Figure 13-6: IDS Rule Table - Add Record
The figure above shows a configuration example. If 15 malformed SIP messages are
received within a period of 30 seconds, a minor alarm is sent. Every 30 seconds, the
rule’s counters are cleared. In addition, if more than 25 malformed SIP messages are
received within this period, the device blacklists the remote IP host from where the
messages were received for 60 seconds.
7.
Configure an IDS Rule according to the parameters described in the table below.
8.
Click Submit, and then save ("burn") your settings to flash memory.
Table 13-4: IDS Rule Table Parameter Descriptions
Parameter
Description
Index
CLI: rule-id
[IDSRule_RuleID]
Defines an index number for the new table record.
Reason
CLI: reason
[IDSRule_Reason]
Defines the type of intrusion attack (malicious event).
 [0] Any = All events listed below are considered as attacks
and are counted together.
 [1] Connection abuse (default) = TLS authentication failure.
 [2] Malformed message =
 Message exceeds a user-defined maximum message
length (50K)
 Any SIP parser error
 Message Policy match (see ''Configuring SIP Message
Policy Rules'')
 Basic headers not present
 Content length header not present (for TCP)
 Header overflow
 [3] Authentication failure =
 Local authentication ("Bad digest" errors)
 Remote authentication (SIP 401/407 is sent if original
message includes authentication)
 [4] Dialog establish failure =
 Classification failure (see ''Configuring Classification
Rules'' on page 522)
 Routing failure
 Other local rejects (prior to SIP 180 response)
 Remote rejects (prior to SIP 180 response)
Version 6.8
151
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description

[5] Abnormal flow =
 Requests and responses without a matching
transaction user (except ACK requests)
 Requests and responses without a matching
transaction (except ACK requests)
Threshold Scope
CLI: threshold-scope
[IDSRule_ThresholdScope]
Defines the source of the attacker to consider in the device's
detection count.
 [0] Global = All attacks regardless of source are counted
together during the threshold window.
 [2] IP = Attacks from each specific IP address are counted
separately during the threshold window.
 [3] IP+Port = Attacks from each specific IP address:port are
counted separately during the threshold window. This option
is useful for NAT servers, where numerous remote
machines use the same IP address but different ports.
However, it is not recommended to use this option as it may
degrade detection capabilities.
Threshold Window
CLI: threshold-window
[IDSRule_ThresholdWindow]
Defines the threshold interval (in seconds) during which the
device counts the attacks to check if a threshold is crossed.
The counter is automatically reset at the end of the interval.
The valid range is 1 to 1,000,000. The default is 1.
Minor-Alarm Threshold
CLI: minor-alrm-thr
[IDSRule_MinorAlarmThreshold]
Defines the threshold that if crossed a minor severity alarm is
sent.
The valid range is 1 to 1,000,000. A value of 0 or -1 means not
defined.
Major-Alarm Threshold
CLI: major-alrm-thr
[IDSRule_MajorAlarmThreshold]
Defines the threshold that if crossed a major severity alarm is
sent.
The valid range is 1 to 1,000,000. A value of 0 or -1 means not
defined.
Critical-Alarm Threshold
Defines the threshold that if crossed a critical severity alarm is
CLI: critical-alrm-thr
sent.
[IDSRule_CriticalAlarmThreshold] The valid range is 1 to 1,000,000. A value of 0 or -1 means not
defined.
Deny Threshold
[IDSRule_DenyThreshold]
Defines the threshold that if crossed, the device blocks
(blacklists) the remote host (attacker).
The default is -1 (i.e., not configured).
Note: This parameter is applicable only if the 'Threshold
Scope' parameter is set to IP or IP+Port.
Deny Period
[IDSRule_DenyPeriod]
Defines the duration (in sec) to keep the attacker on the
blacklist.
The valid range is 0 to 1,000,000. The default is -1 (i.e., not
configured).
User's Manual
152
Document #: LTRT-27034
User's Manual
13. Security
13.3.3 Assigning IDS Policies
The IDS Match table lets you implement your configured IDS Policies. You do this by
assigning specific IDS Policies to any, or a combination of, the following configuration
entities:

SIP Interface: For detection of malicious attacks on specific SIP Interface(s). For
configuring SIP Interfaces, see ''Configuring SIP Interfaces'' on page 258.

Proxy Sets: For detection of malicious attacks from specified Proxy Set(s). For
configuring Proxy Sets, see ''Configuring Proxy Sets'' on page 272.

Subnet addresses: For detection of malicious attacks from specified subnet
addresses.
You can configure up to 20 IDS Policy-Matching rules.
 To configure an IDS Policy-Matching rule:
1.
Open the IDS Match Table page (Configuration tab > VoIP menu > Security >
Intrusion Detection and Prevention > Match Table).
2.
Click Add; the following dialog box appears:
Figure 13-7: IDS Match Table - Add Record
The figure above shows a configuration example where the IDS Policy "SIP Trunk" is
applied to SIP Interfaces 1 and 2, and all source IP addresses outside of subnet
10.1.0.0/16 and IP address 10.2.2.2.
3.
Configure a rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 13-5: IDS Match Table Parameter Descriptions
Parameter
Description
Index
[IDSMatch_Index]
Defines an index number for the new table record.
SIP Interface ID
CLI: sip-interface
[IDSMatch_SIPInterface]
Defines the SIP Interface(s) to which you want to assign the IDS
Policy. This indicates the SIP Interfaces that are being attacked.
The valid value is the ID of the SIP Interface. The following syntax is
supported:
 A comma-separated list of SIP Interface IDs (e.g., 1,3,4)
 A hyphen "-" indicates a range of SIP Interfaces (e.g., 3,4-7 means
IDs 3, and 4 through 7)
 A prefix of an exclamation mark "!" means negation of the set (e.g.,
!3,4-7 means all indexes excluding 3, and excluding 4 through 7)
Proxy Set ID
CLI: proxy-set
Defines the Proxy Set(s) to which the IDS Policy is assigned. This
indicates the Proxy Sets from where the attacks are coming from. The
Version 6.8
153
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
[IDSMatch_ProxySet]
following syntax is supported:
 A comma-separated list of Proxy Set IDs (e.g., 1,3,4)
 A hyphen "-" indicates a range of Proxy Sets (e.g., 3,4-7 means
IDs 3, and 4 through 7)
 A prefix of an exclamation mark "!" means negation of the set (e.g.,
!3,4-7 means all indexes excluding 3, and excluding 4 through 7)
Notes:
 Only the IP address of the Proxy Set is considered (not port).
 If a Proxy Set has multiple IP addresses, the device considers the
Proxy Set as one entity and includes all its IP addresses in the
same IDS count.
Subnet
CLI: subnet
[IDSMatch_Subnet]
Defines the subnet to which the IDS Policy is assigned. This indicates
the subnets from where the attacks are coming from. The following
syntax can be used:
 Basic syntax is a subnet in CIDR notation (e.g., 10.1.0.0/16 means
all sources with IP address in the range 10.1.0.0–10.1.255.255)
 An IP address can be specified without the prefix length to refer to
the specific IP address.
 Each subnet can be negated by prefixing it with "!", which means
all IP addresses outside that subnet.
 Multiple subnets can be specified by separating them with "&"
(and) or "|" (or) operations. For example:
 10.1.0.0/16 | 10.2.2.2: includes subnet 10.1.0.0/16 and IP
address 10.2.2.2.
 !10.1.0.0/16 & !10.2.2.2: includes all addresses except those
of subnet 10.1.0.0/16 and IP address 10.2.2.2. Note that the
exclamation mark "!" appears before each subnet.
 10.1.0.0/16 & !10.1.1.1: includes subnet 10.1.0.0/16, except IP
address 10.1.1.1.
Policy
CLI: policy
[IDSMatch_Policy]
Assigns an IDS Policy (configured in ''Configuring IDS Policies'' on
page 149).
User's Manual
154
Document #: LTRT-27034
User's Manual
13. Security
13.3.4 Viewing IDS Alarms
For the IDS feature, the device sends the following SNMP traps:

Traps that notify the detection of malicious attacks:
•
acIDSPolicyAlarm: The device sends this alarm whenever a threshold of a
specific IDS Policy rule is crossed. The trap displays the crossed severity
threshold (Minor or Major), IDS Policy and IDS Rule, and the IDS Policy-Match
index.
•
acIDSThresholdCrossNotification: The device sends this event for each scope
(IP address) that crosses the threshold. In addition to the crossed severity
threshold (Minor or Major) of the IDS Policy-Match index, this event shows the IP
address (or IP address:port) of the malicious attacker.
If the severity level is raised, the alarm of the former severity is cleared and the
device sends a new alarm with the new severity. The alarm is cleared after a
user-defined period (configured by the ini file parameter, IDSAlarmClearPeriod)
during which no thresholds have been crossed. However, this "quiet" period must
be at least twice the 'Threshold Window' value (configured in ''Configuring IDS
Policies'' on page 149). For example, if you set IDSAlarmClearPeriod to 20 sec
and 'Threshold Window' to 15 sec, the IDSAlarmClearPeriod parameter is
ignored and the alarm is cleared only after 30 seconds (2 x 15 sec).
The figure below displays an example of IDS alarms in the Active Alarms table
(''Viewing Active Alarms'' on page 631). In this example, a Minor threshold alarm
is cleared and replaced by a Major threshold alarm:
Figure 13-8: IDS Alarms in Active Alarms Table

acIDSBlacklistNotification event: The device sends this event whenever an attacker
(remote host at IP address and/or port) is added to or removed from the blacklist.
You can also view IDS alarms in the CLI, using the following commands:

To view all active IDS alarms:
# show voip security ids active-alarm all

To view all IP addresses that crossed the threshold for an active IDS alarm:
# show voip security ids active-alarm match <IDS Match Policy ID> rule
<IDS Rule ID>
The IP address is displayed only if the 'Threshold Scope' parameter is set to IP or
IP+Port; otherwise, only the alarm is displayed.

To view the blacklist:
# show voip security ids blacklist active
For example:
Active blacklist entries:
10.33.5.110(NI:0) remaining 00h:00m:10s in blacklist
Where SI is the SIP Interface and NI is the network interface.
The device also sends IDS notifications and alarms in Syslog messages to a Syslog
server. This only occurs if you have configured Syslog (see ''Enabling Syslog'' on page
681). An example of a Syslog message with IDS alarms and notifications is shown below:
Version 6.8
155
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Figure 13-9: Syslog Message Example with IDS Alarms and Notifications
The table below lists the Syslog text messages per malicious event:
Table 13-6: Types of Malicious Events and Syslog Text String
Type
Description
Syslog String
Connection
Abuse
TLS authentication failure
abuse-tls-auth-fail
Malformed
Messages







Message exceeds a user-defined maximum
message length (50K)
Any SIP parser error
Message policy match
Basic headers not present
Content length header not present (for TCP)
Header overflow





malformed-invalidmsg-len
malformed-parse-error
malformed-messagepolicy
malformed-missheader
malformed-misscontent-len
malformed-headeroverflow
Authentication
Failure


Local authentication ("Bad digest" errors)
Remote authentication (SIP 401/407 is sent if
original message includes authentication)


auth-establish-fail
auth-reject-response
Dialog
Establishment
Failure




Classification failure
Routing failure
Other local rejects (prior to SIP 180 response)
Remote rejects (prior to SIP 180 response)




establish-classify-fail
establish-route-fail
establish-local-reject
establish-remote-reject
Abnormal Flow



flow-no-match-tu
flow-no-matchtransaction
User's Manual
Requests and responses without a matching
transaction user (except ACK requests)
 Requests and responses without a matching
transaction (except ACK requests)
156
Document #: LTRT-27034
User's Manual
14
14. Media
Media
This section describes the media-related configuration.
14.1
Configuring Voice Settings
The Voice Settings page configures various voice parameters such as voice volume,
silence suppression, and DTMF transport type. For a detailed description of these
parameters, see ''Configuration Parameters Reference'' on page 715.
 To configure the voice parameters:
1.
Open the Voice Settings page (Configuration tab > VoIP menu > Media > Voice
Settings).
2.
Configure the Voice parameters as required.
3.
Click Submit.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
14.1.1 Configuring Voice Gain (Volume) Control
The device allows you to configure the level of the received (input gain) Tel-to-IP signal
and the level of the transmitted (output gain) IP-to-Tel signal. The gain can be set between
-32 and 31 decibels (dB).
The following procedure describes how to configure gain control using the Web interface:
 To configure gain control using the Web interface:
1.
Open the Voice Settings page (Configuration tab > VoIP menu > Media > Voice
Settings).
Figure 14-1: Voice Volume Parameters in Voice Settings Page
2.
3.
Configure the following parameters:
•
'Voice Volume' (VoiceVolume) - Defines the voice gain control (in decibels) for IPto-Tel
•
'Input Gain' (InputGain) - Defines the PCM input gain control (in decibels) for Telto-IP
Click Submit.
14.1.2 Silence Suppression (Compression)
Silence suppression (compression) is a method for conserving bandwidth on VoIP calls by
not sending packets when silence is detected. The device uses its VAD feature to detect
periods of silence in the voice channel during an established call. When silence is
detected, it stops sending packets in the channel.
The following procedure describes how to enable silence suppression using the Web
interface.
Version 6.8
157
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To enable silence suppression using the Web interface:
1.
Open the Voice Settings page (Configuration tab > VoIP menu > Media > Voice
Settings).
Figure 14-2: Enabling Silence Suppression in Voice Settings Page
2.
Set the 'Silence Suppression' (EnableSilenceCompression) field to Enable.
3.
Click Submit.
14.1.3 Echo Cancellation
The device supports adaptive linear (line) echo cancellation according to G.168-2002.
Echo cancellation is a mechanism that removes echo from the voice channel. Echoes are
reflections of the transmitted signal.
In this line echo, echoes are generated when two-wire telephone circuits (carrying both
transmitted and received signals on the same wire pair) are converted to a four-wire circuit.
Echoes are reflections of the transmitted signal, which result from impedance mismatch in
the hybrid (bi-directional 2-wire to 4-wire converting device).
An estimated echo signal is built by feeding the decoder output signal to an RLS-like
adaptive filter, which adapts itself to the characteristics of the echo path. The ‘estimated
echo signal’ (the output of this filter) is then subtracted from the input signal (which is the
sum of the desired input signal and the undesired echo) to provide a clean signal. To
suppress the remaining residual echo, a Non Linear Processor (NLP) is used, as well as a
double-talk (two people speak at the same time) detector that prevents false adaptation
during near-end speech.
The following procedure describes how to configure echo cancellation using the Web
interface:
 To configure echo cancellation using the Web interface:
1.
Configure line echo cancellation:
a.
Open the Voice Settings page (Configuration tab > VoIP menu > Media > Voice
Settings).
Figure 14-3: Enabling Echo Cancellation in Voice Settings Page
b.
c.
d.
Set the 'Echo Canceller' field (EnableEchoCanceller) to Enable.
Open the General Media Settings page (Configuration tab > VoIP menu > Media
> General Media Settings).
From the 'Max Echo Canceller Length' drop-down list (MaxEchoCancellerLength),
select the maximum echo path delay (tail length) for the echo canceller.
Note: The following additional echo cancellation parameters are configurable only
through the ini file:
• ECHybridLoss - defines the four-wire to two-wire worst-case Hybrid loss
• ECNLPMode - defines the echo cancellation Non-Linear Processing (NLP) mode
• EchoCancellerAggressiveNLP - enables Aggressive NLP at the first 0.5 second of
the call
User's Manual
158
Document #: LTRT-27034
User's Manual
14.2
14. Media
Fax and Modem Capabilities
This section describes the device's fax and modem capabilities and corresponding
configuration. The fax and modem configuration is done in the Fax/Modem/CID Settings
page.
Notes:
• Unless otherwise specified, the configuration parameters mentioned in this section
are available on this page.
• Some SIP parameters override these fax and modem parameters. For example,
the IsFaxUsed parameter and V.152 parameters in Section ''V.152 Support'' on
page 168.
• For a detailed description of the parameters appearing on this page, see
''Configuration Parameters Reference'' on page 715.
 To access the fax and modem parameters:
1.
Open the Fax/Modem/CID Settings page (Configuration tab > VoIP menu > Media >
Fax/Modem/CID Settings).
Figure 14-4: Fax/Modem/CID Settings Page
2.
Configure the parameters, as required.
3.
Click Submit.
Version 6.8
159
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.1 Fax/Modem Operating Modes
The device supports two modes of operation:

Fax/modem negotiation that is not performed during the establishment of the call.

Voice-band data (VBD) mode for V.152 implementation (see ''V.152 Support'' on page
168): fax/modem capabilities are negotiated between the device and the remote
endpoint at the establishment of the call. During a call, when a fax/modem signal is
detected, transition from voice to VBD (or T.38) is automatically performed and no
additional SIP signaling is required. If negotiation fails (i.e., no match is achieved for
any of the transport capabilities), fallback to existing logic occurs (according to the
parameter IsFaxUsed).
14.2.2 Fax/Modem Transport Modes
The device supports the following transport modes for fax per modem type
(V.22/V.23/Bell/V.32/V.34):

T.38 fax relay (see ''T.38 Fax Relay Mode'' on page 160)

G.711 Transport: switching to G.711 when fax/modem is detected (see ''G.711 Fax /
Modem Transport Mode'' on page 162)

Fax fallback to G.711 if T.38 is not supported (see ''Fax Fallback'' on page 163)

Fax and modem bypass: a proprietary method that uses a high bit rate coder (see
''Fax/Modem Bypass Mode'' on page 164)

NSE Cisco’s Pass-through bypass mode for fax and modem (see ''Fax / Modem NSE
Mode'' on page 165)

Transparent with events: passing the fax / modem signal in the current voice coder
with adaptations (see ''Fax / Modem Transparent with Events Mode'' on page 166)

Transparent: passing the fax / modem signal in the current voice coder (see ''Fax /
Modem Transparent Mode'' on page 166)

RFC 2833 ANS Report upon Fax/Modem Detection (see ''RFC 2833 ANS Report
upon Fax/Modem Detection'' on page 167)
‘Adaptations’ refer to automatic reconfiguration of certain DSP features for handling
fax/modem streams differently than voice.
14.2.2.1 T.38 Fax Relay Mode
In Fax Relay mode, fax signals are transferred using the T.38 protocol. T.38 is the ITU
standard for sending fax across IP networks in real-time mode. The device currently
supports only the T.38 UDP syntax.
T.38 can be configured in the following ways:

Switching to T.38 mode using SIP Re-INVITE messages (see ''Switching to T.38
Mode using SIP Re-INVITE'' on page 161)

Automatically switching to T.38 mode without using SIP Re-INVITE messages (see
''Automatically Switching to T.38 Mode without SIP Re-INVITE'' on page 161)
When fax transmission ends, the reverse switching from fax relay to voice is automatically
performed at both the local and remote endpoints.
You can change the fax rate declared in the SDP, using the 'Fax Relay Max Rate'
parameter (FaxRelayMaxRate). This parameter does not affect the actual transmission
rate. You can also enable or disable Error Correction Mode (ECM) fax mode using the 'Fax
Relay ECM Enable' parameter (FaxRelayECMEnable).
When using T.38 mode, you can define a redundancy feature to improve fax transmission
over congested IP networks. This feature is activated using the 'Fax Relay Redundancy
Depth' parameter (FaxRelayRedundancyDepth) and the 'Fax Relay Enhanced
User's Manual
160
Document #: LTRT-27034
User's Manual
14. Media
Redundancy Depth' parameter (FaxRelayEnhancedRedundancyDepth). Although this is a
proprietary redundancy scheme, it should not create problems when working with other
T.38 decoders.
14.2.2.1.1 Switching to T.38 Mode using SIP Re-INVITE
In the Switching to T.38 Mode using SIP Re-INVITE mode, upon detection of a fax signal
the terminating device negotiates T.38 capabilities using a Re-INVITE message. If the farend device doesn't support T.38, the fax fails. In this mode, the 'Fax Transport Mode'
parameter (FaxTransportMode) is ignored.
 To configure T.38 mode using SIP Re-INVITE messages:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to T.38
Relay (IsFaxUsed = 1).
2.
In the Fax/Modem/CID Settings page, configure the following optional parameters:
•
'Fax Relay Redundancy Depth' (FaxRelayRedundancyDepth)
•
'Fax Relay Enhanced Redundancy Depth'
(FaxRelayEnhancedRedundancyDepth)
•
'Fax Relay ECM Enable' (FaxRelayECMEnable)
•
'Fax Relay Max Rate' (FaxRelayMaxRate)
Note: The terminating gateway sends T.38 packets immediately after the T.38
capabilities are negotiated in SIP. However, the originating device by default, sends
T.38 (assuming the T.38 capabilities are negotiated in SIP) only after it receives T.38
packets from the remote device. This default behavior cannot be used when the
originating device is located behind a firewall that blocks incoming T.38 packets on
ports that have not yet received T.38 packets from the internal network. To resolve
this problem, the device should be configured to send CNG packets in T.38 upon
CNG signal detection (CNGDetectorMode = 1).
14.2.2.1.2 Automatically Switching to T.38 Mode without SIP Re-INVITE
In the Automatically Switching to T.38 Mode without SIP Re-INVITE mode, when a fax
signal is detected, the channel automatically switches from the current voice coder to
answer tone mode and then to T.38-compliant fax relay mode.
 To configure automatic T.38 mode:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax (IsFaxUsed = 0).
2.
In the Fax/Modem/CID Settings page, set the 'Fax Transport Mode' parameter to T.38
Relay (FaxTransportMode = 1).
3.
Configure the following optional parameters:
Version 6.8
•
'Fax Relay Redundancy Depth' (FaxRelayRedundancyDepth)
•
'Fax Relay Enhanced Redundancy Depth'
(FaxRelayEnhancedRedundancyDepth)
•
'Fax Relay ECM Enable' (FaxRelayECMEnable)
•
'Fax Relay Max Rate' (FaxRelayMaxRate)
161
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.2.1.3 Fax over IP using T.38 Transmission over RTP
The device supports Fax-over-IP (FoIP) transmission using T.38 over RTP, whereby the
T.38 payload is encapsulated in the RTP packet, instead of being sent in dedicated T.38
packets (out-of-band). To configure this support, set the coder type to T.38 Over RTP.
To indicate T.38 over RTP, the SDP body uses "udptl" (Facsimile UDP Transport Layer) in
the 'a=ftmp' line. The device supports T.38 over RTP according to this standard as well as
according to AudioCodes proprietary method:

Call Parties belong to AudioCodes Devices: AudioCodes proprietary T.38-overRTP method is used, whereby the device encapsulates the entire T.38 packet
(payload with all its headers) in the sent RTP. For T.38 over RTP, AudioCodes
devices use the proprietary identifier "AcUdptl" in the 'a=ftmp' line of the SDP. For
example:
v=0
o=AudiocodesGW 1357424688 1357424660 IN IP4 10.8.6.68
s=Phone-Call
c=IN IP4 10.8.6.68
t=0 0
m=audio 6080 RTP/AVP 18 100 96
a=ptime:20
a=sendrecv
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 t38/8000
a=fmtp:100 T38FaxVersion=0
a=fmtp:100 T38MaxBitRate=0
a=fmtp:100 T38FaxMaxBuffer=3000
a=fmtp:100 T38FaxMaxDatagram=122
a=fmtp:100 T38FaxRateManagement=transferredTCF
a=fmtp:100 T38FaxUdpEC=t38UDPRedundancy
a=fmtp:100 AcUdptl
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15

AudioCodes Call Party with non-AudioCodes Party: The device uses the standard
T.38-over-RTP method, which encapsulates the T.38 payload only, without its headers
(i.e., includes only fax data) in the sent RTP packet (RFC 4612).
The T.38-over-RTP method also depends on call initiator:

Device initiates a call: The device always sends the SDP offer with the proprietary
token "AcUdpTl" in the 'fmtp' attribute. If the SDP answer includes the same token, the
device employs AudioCodes proprietary T.38-over-RTP mode; otherwise, the
standard mode is used.

Device answers a call: If the SDP offer from the remote party contains the 'fmtp'
attribute with "AcUdpTl", the device answers with the same attribute and employs
AudioCodes proprietary T.38-over-RTP mode; otherwise, the standard mode is used.
Note: If both T.38 (regular) and T.38 Over RTP coders are negotiated between the
call parties, the device uses T.38 Over RTP.
14.2.2.2 G.711 Fax / Modem Transport Mode
In this mode, when the terminating device detects fax or modem signals (CED or AnsAM),
it sends a Re-INVITE message to the originating device, requesting it to re-open the
channel in G.711 VBD with the following adaptations:
User's Manual
162
Document #: LTRT-27034
User's Manual
14. Media

Echo Canceller = off

Silence Compression = off

Echo Canceller Non-Linear Processor Mode = off

Dynamic Jitter Buffer Minimum Delay = 40

Dynamic Jitter Buffer Optimization Factor = 13
After a few seconds upon detection of fax V.21 preamble or super G3 fax signals, the
device sends a second Re-INVITE enabling the echo canceller (the echo canceller is
disabled only on modem transmission).
A ‘gpmd’ attribute is added to the SDP according to the following format:

For G.711 A-law:
a=gpmd:0 vbd=yes;ecan=on (or off for modems)

For G.711 µ-law:
a=gpmd:8 vbd=yes;ecan=on (or off for modems)
The following parameters are ignored and automatically set to Events Only:

'Fax Transport Mode' (FaxTransportMode)

'Vxx ModemTransportType' (VxxModemTransportType)
 To configure fax / modem transparent mode:

In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to
G.711 Transport (IsFaxUsed = 2).
14.2.2.3 Fax Fallback
In this mode, when the terminating device detects a fax signal, it sends a Re-INVITE
message to the originating device with T.38. If the remote device doesn’t support T.38
(replies with SIP response 415 "Media Not Supported"), the device sends a new ReINVITE with G.711 VBD with the following 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
When the device initiates a fax session using G.711, a ‘gpmd’ attribute is added to the SDP
according to the following format:

For G.711A-law:
a=gpmd:0 vbd=yes;ecan=on

For G.711 µ-law:
a=gpmd:8 vbd=yes;ecan=on
In this mode, the 'Fax Transport Mode' (FaxTransportMode) parameter is ignored and
automatically set to Disable (transparent mode).
 To configure fax fallback mode:

Version 6.8
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to Fax
Fallback (IsFaxUsed = 3).
163
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.2.4 Fax/Modem Bypass Mode
In this proprietary mode, when fax or modem signals are detected, the channel
automatically switches from the current voice coder to a high bit-rate coder, according to
the 'Fax/Modem Bypass Coder Type' parameter (FaxModemBypassCoderType). The
channel is also automatically reconfigured with the following fax / modem adaptations:

Disables silence suppression

Enables echo cancellation for fax

Disables echo cancellation for modem

Performs certain jitter buffering optimizations
The network packets generated and received during the bypass period are regular voice
RTP packets (per the selected bypass coder), but with a different RTP payload type
according to the following parameters:

'Fax Bypass Payload Type' (FaxBypassPayloadType)

ModemBypassPayloadType (ini file)
During the bypass period, the coder uses the packing factor, configured by the 'Fax/Modem
Bypass Packing Factor' parameter (FaxModemBypassM). The packing factor determines
the
number
of
coder
payloads
(each
the
size
of
FaxModemBypassBasicRTPPacketInterval) that are used to generate a single fax/modem
bypass packet. When fax/modem transmission ends, the reverse switching, from bypass
coder to regular voice coder is performed.
 To configure fax / modem bypass mode:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax (IsFaxUsed = 0).
2.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
f.
Set the 'Fax Transport Mode' parameter to Bypass (FaxTransportMode = 2).
Set the 'V.21 Modem Transport Type' parameter to Enable Bypass
(V21ModemTransportType = 2).
Set the 'V.22 Modem Transport Type' parameter to Enable Bypass
(V22ModemTransportType = 2).
Set the 'V.23 Modem Transport Type' parameter to Enable Bypass
(V23ModemTransportType = 2).
Set the 'V.32 Modem Transport Type' parameter to Enable Bypass
(V32ModemTransportType = 2).
Set the 'V.34 Modem Transport Type' parameter to Enable Bypass
(V34ModemTransportType = 2).
3.
Set the ini file parameter, BellModemTransportType to 2 (Bypass).
4.
Configure the following optional parameters:
•
'Fax/Modem Bypass Coder Type' (FaxModemBypassCoderType).
•
'Fax Bypass Payload Type' (FaxBypassPayloadType) - in the RTP/RTCP
Settings page (Configuration tab > VoIP menu > Media > RTP/RTCP Settings).
•
ModemBypassPayloadType (ini file).
•
FaxModemBypassBasicRTPPacketInterval (ini file).
•
FaxModemBypasDJBufMinDelay (ini file).
Note: When the device is configured for modem bypass and T.38 fax, V.21 low-speed
modems are not supported and fail as a result.
User's Manual
164
Document #: LTRT-27034
User's Manual
14. Media
Tip:
When the remote (non-AudioCodes) gateway uses the G.711 coder for
voice and doesn’t change the coder payload type for fax or modem transmission, it is
recommended to use the Bypass mode with the following configuration:
• EnableFaxModemInbandNetworkDetection = 1.
• 'Fax/Modem Bypass Coder Type' = same coder used for voice.
• 'Fax/Modem Bypass Packing Factor'(FaxModemBypassM) = same interval as
voice.
• ModemBypassPayloadType = 8 if voice coder is A-Law or 0 if voice coder is MuLaw.
14.2.2.5 Fax / Modem NSE Mode
In this mode, fax and modem signals are transferred using Cisco-compatible Pass-through
bypass mode. Upon detection of fax or modem answering tone signal, the terminating
device sends three to six special NSE RTP packets (configured by the NSEpayloadType
parameter; usually to 100). These packets signal the remote device to switch to G.711
coder, according to the 'Fax/Modem Bypass Packing Factor' parameter. After a few NSE
packets are exchanged between the devices, both devices start using G.711 packets with
standard payload type (8 for G.711 A-Law and 0 for G.711 Mu-Law). In this mode, no ReINVITE messages are sent. The voice channel is optimized for fax/modem transmission
(same as for usual bypass mode).
The parameters defining payload type for AudioCodes proprietary Bypass mode -- 'Fax
Bypass Payload Type' (RTP/RTCP Settings page) and ModemBypassPayloadType (ini file)
-- are not used with NSE Bypass.
When configured for NSE mode, the device includes in its SDP the following line:
a=rtpmap:100 X-NSE/8000
Where 100 is the NSE payload type.
The Cisco gateway must include the following definition:
modem passthrough nse payload-type 100 codec g711alaw
 To configure NSE mode:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax (IsFaxUsed = 0).
2.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
f.
Set the 'Fax Transport Mode' parameter to Bypass (FaxTransportMode = 2).
Set the 'V.21 Modem Transport Type' parameter to Enable Bypass
(V21ModemTransportType = 2).
Set the 'V.22 Modem Transport Type' parameter to Enable Bypass
(V22ModemTransportType = 2).
Set the 'V.23 Modem Transport Type' parameter to Enable Bypass
(V23ModemTransportType = 2).
Set the 'V.32 Modem Transport Type' parameter to Enable Bypass
(V32ModemTransportType = 2).
Set the 'V.34 Modem Transport Type' parameter to Enable Bypass
(V34ModemTransportType = 2).
3.
Set the ini file parameter, BellModemTransportType to 2 (Bypass).
4.
Set the ini file parameter, NSEMode parameter to 1 (enables NSE).
5.
Set the ini file parameter, NSEPayloadType parameter to 100.
Version 6.8
165
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.2.6 Fax / Modem Transparent with Events Mode
In this mode, fax and modem signals are transferred using the current voice coder with the
following automatic adaptations:

Echo Canceller = on (or off for modems)

Echo Canceller Non-Linear Processor Mode = off

Jitter buffering optimizations
 To configure fax / modem transparent with events mode:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax (IsFaxUsed = 0).
2.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
f.
3.
Set the 'Fax Transport Mode' parameter to Events Only (FaxTransportMode =
3).
Set the 'V.21 Modem Transport Type' parameter to Events Only
(V21ModemTransportType = 3).
Set the 'V.22 Modem Transport Type' parameter to Events Only
(V22ModemTransportType = 3).
Set the 'V.23 Modem Transport Type' parameter to Events Only
(V23ModemTransportType = 3).
Set the 'V.32 Modem Transport Type' parameter to Events Only
(V32ModemTransportType = 3).
Set the 'V.34 Modem Transport Type' parameter to Events Only
(V34ModemTransportType = 3).
Set the ini file parameter, BellModemTransportType to 3 (transparent with events).
14.2.2.7 Fax / Modem Transparent Mode
In this mode, fax and modem signals are transferred using the current voice coder without
notifications to the user and without automatic adaptations. It's possible to use Profiles (see
''Coders and Profiles'' on page 295) to apply certain adaptations to the channel used for fax
/ modem. For example, to use the coder G.711, to set the jitter buffer optimization factor to
13, and to enable echo cancellation for fax and disable it for modem.
 To configure fax / modem transparent mode:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax (IsFaxUsed = 0).
2.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
f.
3.
User's Manual
Set the 'Fax Transport Mode' parameter to Disable (FaxTransportMode = 0).
Set the 'V.21 Modem Transport Type' parameter to Disable
(V21ModemTransportType = 0).
Set the 'V.22 Modem Transport Type' parameter to Disable
(V22ModemTransportType = 0).
Set the 'V.23 Modem Transport Type' parameter to Disable
(V23ModemTransportType = 0).
Set the 'V.32 Modem Transport Type' parameter to Disable
(V32ModemTransportType = 0).
Set the 'V.34 Modem Transport Type' parameter to Disable
(V34ModemTransportType = 0).
Set the ini file parameter, BellModemTransportType to 0 (transparent mode).
166
Document #: LTRT-27034
User's Manual
4.
14. Media
Configure the following optional parameters:
a.
b.
c.
d.
Coders table - (Configuration tab > VoIP menu > Coders and Profiles >
Coders).
'Dynamic Jitter Buffer Optimization Factor' (DJBufOptFactor) - RTP/RTCP
Settings page (Configuration tab > VoIP menu > Media > RTP/RTCP Settings).
'Silence Suppression' (EnableSilenceCompression) - Voice Settings page
(Configuration tab > VoIP menu > Media > Voice Settings).
'Echo Canceller' (EnableEchoCanceller) - Voice Settings page.
Note: This mode can be used for fax, but is not recommended for modem
transmission. Instead, use the Bypass (see ''Fax/Modem Bypass Mode'' on page 164)
or Transparent with Events modes (see ''Fax / Modem Transparent with Events
Mode'' on page 166) for modem.
14.2.2.8 RFC 2833 ANS Report upon Fax/Modem Detection
The device (terminator gateway) sends RFC 2833 ANS/ANSam events upon detection of
fax and/or modem answer tones (i.e., CED tone). This causes the originator to switch to
fax/modem. This parameter is applicable only when the fax or modem transport type is set
to bypass, Transparent-with-Events, V.152 VBD, or G.711 transport. When the device is
located on the originator side, it ignores these RFC 2833 events
 To configure RFC 2833 ANS Report upon fax/modem detection:
1.
In the SIP General Parameters page (Configuration tab > VoIP menu > SIP
Definitions > General Parameters), set the 'Fax Signaling Method' parameter to No
Fax or Fax Fallback (IsFaxUsed = 0 or 3).
2.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
3.
Set the 'Fax Transport Mode' parameter to Bypass (FaxTransportMode = 2).
Set the 'V.xx Modem Transport Type' parameters to Enable Bypass
(VxxModemTransportType = 2).
Set the ini file parameter, FaxModemNTEMode to 1 (enables this feature).
14.2.3 V.34 Fax Support
V.34 fax machines can transmit data over IP to the remote side using various methods.
The device supports the following modes for transporting V.34 fax data over IP:

Bypass mechanism for V.34 fax transmission (see ''Bypass Mechanism for V.34 Fax
Transmission'' on page 168)

T38 Version 0 relay mode, i.e., fallback to T.38 (see ''Relay Mode for T.30 and V.34
Faxes'' on page 168)
Note: The CNG detector is disabled in all the subsequent examples. To disable the
CNG detector, set the 'CNG Detector Mode' parameter (CNGDetectorMode) to
Disable.
Version 6.8
167
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.2.3.1 Bypass Mechanism for V.34 Fax Transmission
In this proprietary scenario, the device uses bypass (or NSE) mode to transmit V.34 faxes,
enabling the full utilization of its speed.
 To use bypass mode for T.30 and V.34 faxes:
1.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
Set the 'Fax Transport Mode' parameter to Bypass (FaxTransportMode = 2).
Set the 'V.22 Modem Transport Type' parameter to Enable Bypass
(V22ModemTransportType = 2).
Set the 'V.23 Modem Transport Type' parameter to Enable Bypass
(V23ModemTransportType = 2).
Set the 'V.32 Modem Transport Type' parameter to Enable Bypass
(V32ModemTransportType = 2).
Set the 'V.34 Modem Transport Type' parameter to Enable Bypass
(V34ModemTransportType = 2).
 To use bypass mode for V.34 faxes, and T.38 for T.30 faxes:
1.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
Set the 'Fax Transport Mode' parameter to T.38 Relay (FaxTransportMode = 1).
Set the 'V.22 Modem Transport Type' parameter to Enable Bypass
(V22ModemTransportType = 2).
Set the 'V.23 Modem Transport Type' parameter to Enable Bypass
(V23ModemTransportType = 2).
Set the 'V.32 Modem Transport Type' parameter to Enable Bypass
(V32ModemTransportType = 2).
Set the 'V.34 Modem Transport Type' parameter to Enable Bypass
(V34ModemTransportType = 2).
14.2.3.2 Relay Mode for T.30 and V.34 Faxes
In this scenario, V.34 fax machines are forced to use their backward compatibility with T.30
faxes and operate in the slower T.30 mode.
 To use T.38 mode for V.34 and T.30 faxes:
1.
In the Fax/Modem/CID Settings page, do the following:
a.
b.
c.
d.
e.
Set the 'Fax Transport Mode' parameter to Relay (FaxTransportMode = 1).
Set the 'V.22 Modem Transport Type' parameter to Disable
(V22ModemTransportType = 0).
Set the 'V.23 Modem Transport Type' parameter to Disable
(V23ModemTransportType = 0).
Set the 'V.32 Modem Transport Type' parameter to Disable
(V32ModemTransportType = 0).
Set the 'V.34 Modem Transport Type' parameter to Disable
(V34ModemTransportType = 0).
14.2.4 V.152 Support
The device supports the ITU-T recommendation V.152 (Procedures for Supporting VoiceBand Data over IP Networks). Voice-band data (VBD) is the transport of modem, facsimile,
and text telephony signals over a voice channel of a packet network with a codec
appropriate for such signals.
User's Manual
168
Document #: LTRT-27034
User's Manual
14. Media
For V.152 capability, the device supports T.38 as well as VBD codecs (i.e., G.711 A-law
and G.711 μ-law). The selection of capabilities is performed using the coders table (see
''Configuring Default Coders'' on page 295).
When in VBD mode for V.152 implementation, support is negotiated between the device
and the remote endpoint at the establishment of the call. During this time, initial exchange
of call capabilities is exchanged in the outgoing SDP. These capabilities include whether
VBD is supported and associated RTP payload types ('gpmd' SDP attribute), supported
codecs, and packetization periods for all codec payload types ('ptime' SDP attribute). After
this initial negotiation, no Re-INVITE messages are necessary as both endpoints are
synchronized in terms of the other side's capabilities. If negotiation fails (i.e., no match was
achieved for any of the transport capabilities), fallback to existing logic occurs (according to
the parameter IsFaxUsed).
Below is an example of media descriptions of an SDP indicating support for V.152. In the
example, V.152 implementation is supported (using the dynamic payload type 96 and
G.711 u-law as the VBD codec) as well as the voice codecs G.711 μ-law and G.729.
v=0
o=- 0 0 IN IPV4 <IPAdressA>
s=t=0 0
p=+1
c=IN IP4 <IPAddressA
m=audio <udpPort A> RTP/AVP 18 0
a=ptime:10
a=rtpmap:96 PCMU/8000
a=gpmd: 96 vbd=yes
Instead of using VBD transport mode, the V.152 implementation can use alternative relay
fax transport methods (e.g., fax relay over IP using T.38). The preferred V.152 transport
method is indicated by the SDP ‘pmft’ attribute. Omission of this attribute in the SDP
content means that VBD mode is the preferred transport mechanism for voice-band data.
To configure T.38 mode, use the CodersGroup parameter.
Note: You can also configure the device to handle G.711 coders received in INVITE
SDP offers as VBD coders, using the HandleG711asVBD parameter. For example, if
the device is configured with G.729 and G.711 VBD coders and it receives an INVITE
with an SDP offer containing G.729 and “regular” G.711 coders, it sends an SDP
answer containing G.729 and G.711 VBD coders, allowing subsequent bypass
(passthrough) sessions if fax / modem signals are detected during the call.
14.2.5 Fax Transmission behind NAT
The device supports transmission from fax machines (connected to the device) located
inside (behind) a Network Address Translation (NAT). Generally, the firewall blocks T.38
(and other) packets received from the WAN, unless the device behind the NAT sends at
least one IP packet from the LAN to the WAN through the firewall. If the firewall blocks T.38
packets sent from the termination IP fax, the fax fails.
To overcome this, the device sends No-Op (“no-signal”) packets to open a pinhole in the
NAT for the answering fax machine. The originating fax does not wait for an answer, but
immediately starts sending T.38 packets to the terminating fax machine upon receipt of a
re-INVITE with T.38 only in the SDP, or T.38 and audio media in the SDP. This feature is
configured using the T38FaxSessionImmediateStart parameter. The No-Op packets are
enabled using the NoOpEnable and NoOpInterval parameters.
Version 6.8
169
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.3
Configuring RTP/RTCP Settings
This section describes configuration relating to Real-Time Transport Protocol (RTP) and
RTP Control Protocol (RTCP).
14.3.1 Configuring the Dynamic Jitter Buffer
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. However, some frames may 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 device uses a jitter buffer. The
jitter buffer collects voice packets, stores them and sends them to the voice processor in
evenly spaced intervals.
The device uses a dynamic jitter buffer that can be configured with the following:

Minimum delay: 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 10 msec, the device
always buffers incoming packets by at least 10 msec worth of voice frames.

Optimization Factor: 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 decay 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 10 msec Minimum delay and 10 Optimization Factor should provide
a good compromise between delay and error rate. The jitter buffer ‘holds’ incoming packets
for 10 msec before making them available for decoding into voice. The coder polls frames
from the buffer at regular intervals in order to produce continuous speech. As long as
delays in the network do not change (jitter) by more than 10 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 10
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 BadFrame-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 device 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.
In certain scenarios, the Optimization Factor is set to 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.
The following procedure describes how to configure the jitter buffer using the Web
interface.
User's Manual
170
Document #: LTRT-27034
User's Manual
14. Media
 To configure jitter buffer using the Web interface:
1.
Open the RTP/RTCP Settings page (Configuration tab > VoIP menu > Media >
RTP/RTCP Settings). The relevant parameters are listed under the 'General Settings'
group, as shown below:
Figure 14-5: Jitter Buffer Parameters in the RTP/RTCP Settings Page
2.
Set the 'Dynamic Jitter Buffer Minimum Delay' parameter (DJBufMinDelay) to the
minimum delay (in msec) for the Dynamic Jitter Buffer.
3.
Set the 'Dynamic Jitter Buffer Optimization Factor' parameter (DJBufOptFactor) to the
Dynamic Jitter Buffer frame error/delay optimization factor.
4.
Click Submit.
14.3.2 Comfort Noise Generation
The device can generate artificial background noise, called comfort noise, in the voice
channel during periods of silence (i.e. when no call party is speaking) for Gateway calls.
This is useful in that it reassures the call parties that the call is still connected. The device
detects silence using its Voice Activity Detection (VAD) mechanism. When the Calling
Tone (CNG) is enabled and silence is detected, the device transmits Silence Identifier
Descriptors (SIDs) parameters to reproduce the local background noise at the remote
(receiving) side.
The Comfort Noise Generation (CNG) support also depends on the silence suppression
(SCE) setting for the coder used in the voice channel. For more information, see the
description of the CNG-related parameters.
The following procedure describes how to configure CNG using the Web interface.
 To configure CNG using the Web interface:
1.
Open the RTP/RTCP Settings page (Configuration tab > VoIP menu > Media >
RTP/RTCP Settings). The relevant parameters are listed under the 'General Settings'
group, as shown below:
Figure 14-6: Comfort Noise Parameter in RTP/RTCP Settings Page
2.
Set the 'Comfort Noise Generation Negotiation' parameter (ComfortNoiseNegotiation)
to Enable.
3.
Click Submit.
Note: This feature is applicable only to the Gateway application.
Version 6.8
171
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.3.3 Dual-Tone Multi-Frequency Signaling
This section describes the configuration of Dual-Tone Multi-Frequency (DTMF) signaling.
14.3.3.1 Configuring DTMF Transport Types
The device supports various methods for transporting DTMF digits over the IP network to
the remote endpoint. These methods and their configuration are configured in the DTMF &
Dialing page (Configuration tab > VoIP menu > GW and IP to IP > DTMF and
Supplementary > DTMF & Dialing):

Using INFO message according to Nortel IETF draft: DTMF digits are sent to the
remote side in INFO messages. To enable this mode, define the following:
a. Set the 'Declare RFC 2833 in SDP' parameter to No (RxDTMFOption = 0).
b. Set the '1st Tx DTMF Option' parameter to INFO (Nortel) (TxDTMFOption = 1).
Note: In this mode, DTMF digits are removed from the audio stream (and the 'DTMF
Transport Type' parameter is automatically set to Mute DTMF).

Using INFO message according to Cisco’s mode: DTMF digits are sent to the
remote side in INFO messages. To enable this mode, define the following:
a. Set the 'Declare RFC 2833 in SDP' parameter to No (RxDTMFOption = 0).
b. Set the '1st Tx DTMF Option' parameter to INFO (Cisco) (TxDTMFOption = 3).
Note: In this mode, DTMF digits are removed from the audio stream (and the 'DTMF
Transport Type' parameter is automatically set to Mute DTMF).

Using NOTIFY messages according to IETF Internet-Draft draft-mahy-sippingsignaled-digits-01: DTMF digits are sent to the remote side using NOTIFY
messages. To enable this mode, define the following:
a. Set the 'Declare RFC 2833 in SDP' parameter to No (RxDTMFOption = 0).
b. Set the '1st Tx DTMF Option' parameter to NOTIFY (TxDTMFOption = 2).
Note: In this mode, DTMF digits are removed from the audio stream (and the 'DTMF
Transport Type' parameter is automatically set to Mute DTMF).

Using RFC 2833 relay with Payload type negotiation: DTMF digits are sent to the
remote side as part of the RTP stream according to RFC 2833. To enable this mode,
define the following:
a. Set the 'Declare RFC 2833 in SDP' parameter to Yes (RxDTMFOption = 3).
b. Set the '1st Tx DTMF Option' parameter to RFC 2833 (TxDTMFOption = 4).
Note: To set the RFC 2833 payload type with a value other than its default, use the
RFC2833PayloadType parameter. The device negotiates the RFC 2833 payload type
using local and remote SDP and sends packets using the payload type from the
received SDP. The device expects to receive RFC 2833 packets with the same
payload type as configured by this parameter. If the remote side doesn’t include
‘telephony-event’ in its SDP, the device sends DTMF digits in transparent mode (as
part of the voice stream).

Sending DTMF digits (in RTP packets) as part of the audio stream (DTMF Relay
is disabled): This method is typically used with G.711 coders. With other low-bit rate
(LBR) coders, the quality of the DTMF digits is reduced. To enable this mode, define
the following:
a.
b.
c.

Using INFO message according to Korea mode: DTMF digits are sent to the
remote side in INFO messages. To enable this mode, define the following:
a.
User's Manual
Set the 'Declare RFC 2833 in SDP' parameter to No (RxDTMFOption = 0).
Set the '1st Tx DTMF Option' parameter to Not Supported (TxDTMFOption = 0).
Set the ini file parameter, DTMFTransportType to 2 (i.e., transparent).
Set the 'Declare RFC 2833 in SDP' parameter to No (RxDTMFOption = 0).
172
Document #: LTRT-27034
User's Manual
14. Media
b. Set the '1st Tx DTMF Option' parameter to INFO (Cisco) (TxDTMFOption = 3).
Note: In this mode, DTMF digits are removed from the audio stream (and the 'DTMF
Transport Type' parameter is automatically set to Mute DTMF).
Notes:
• The device 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.
• To exclude RFC 2833 Telephony event parameter from the device's SDP, set the
'Declare RFC 2833 in SDP' parameter to No.
The following parameters affect the way the device handles the DTMF digits:

TxDTMFOption, RxDTMFOption, RFC2833TxPayloadType, and
RFC2833RxPayloadType

MGCPDTMFDetectionPoint, DTMFVolume, DTMFTransportType, DTMFDigitLength,
and DTMFInterDigitInterval
14.3.3.2 Configuring RFC 2833 Payload
The following procedure describes how to configure the RFC 2833 payload using the Web
interface:
 To configure RFC 2833 payload using the Web interface:
1.
Open the RTP/RTCP Settings page (Configuration tab > VoIP menu > Media >
RTP/RTCP Settings). The relevant parameters are listed under the 'General Settings'
group, as shown below:
Figure 14-7: RFC 2833 Payload Parameters in RTP/RTCP Settings Page
2.
3.
Version 6.8
Configure the following parameters:
•
'RTP Redundancy Depth' (RTPRedundancyDepth) - enables the device to
generate RFC 2198 redundant packets.
•
'Enable RTP Redundancy Negotiation' (EnableRTPRedundancyNegotiation) enables the device to include the RTP redundancy dynamic payload type in the
SDP, according to RFC 2198.
•
'RFC 2833 TX Payload Type' (RFC2833TxPayloadType) - defines the Tx RFC
2833 DTMF relay dynamic payload type.
•
'RFC 2833 RX Payload Type' (RFC2833RxPayloadType) - defines the Rx RFC
2833 DTMF relay dynamic payload type.
•
'RFC 2198 Payload Type' (RFC2198PayloadType) - defines the RTP redundancy
packet payload type according to RFC 2198.
Click Submit.
173
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.3.4 Configuring RTP Base UDP Port
You can configure the range of local UDP ports for RTP, RTCP, and T.38 media streams.
The range of possible UDP ports that can be used, depending on configuration, is 6,000
through to 64,000. The device assigns ports randomly to the traffic within the configured
port range.
For RTCP and T.38 traffic, the port offset from the RTP port used for the voice session
(channel) is one and two, respectively. For example, if the voice session uses RTP port
6000, the RTCP port and T.38 port for the session is 6001 and 6002, respectively.
However, you can configure the device to use the same port for RTP and T.38 packets, by
setting the T38UseRTPPort parameter to 1.
Within the port range, the device allocates the UDP ports in "jumps" (spacing) of 10
(default). For example, if the port range starts at 6000 and the UDP port spacing is 10, the
available ports include 6000, 6010, 6020, 6030, and so on.
The port range is calculated using the following equation:
BaseUDPPort to (BaseUDPPort + number of channels*10)
Where, BaseUDPPort is a parameter for configuring the lower boundary of the UDP port
range (default is 6000).
For example, if the base UDP port is set to 6000, the port range for 20 channels is:
6000 to (6000 + 20*10) = 6000 to (6000 + 200) = 6000 to 6200
You can also configure specific port ranges per logical media-type IP network interface,
using Media Realms (see Configuring Media Realms on page 251). However, the port
range configured for the Media Realm must be within the range configured by the
BaseUDPPort parameter.
The following procedure describes how to configure the RTP base UDP port in the Web
interface.
 To configure the RTP base UDP port:
1.
Open the RTP/RTCP Settings page (Configuration tab > VoIP menu > Media >
RTP/RTCP Settings). The relevant parameter is listed under the 'General Settings'
group, as shown below:
Figure 14-8: RTP Based UDP Port in RTP/RTCP Settings Page
2.
Set the 'RTP Base UDP Port' parameter to the required value.
3.
Click Submit.
4.
Reset the device for the settings to take effect.
Note: You can also configure the base UDP port for calls belonging to a specific SIP
entity (IP Group), using IP Profiles (see Configuring IP Profiles on page 302).
User's Manual
174
Document #: LTRT-27034
User's Manual
14.4
14. Media
Answering Machine Detector (AMD)
The device's Answering Machine Detection (AMD) feature can detect whether an outbound
call has been answered by a human (including fax) or an answering machine. The device
analyzes the sound (speech) patterns received in the first few seconds of the call to
determine whether a human (live person) or machine has answered the call. Typically,
when a human answers the call, there is a short "hello ..." followed by silence to wait for the
other party to respond. In contrast, when an answering machine answers the call, there is
constant speech (answering message) followed by a beep to leave a voice-mail message.
Once the device detects what answered the call (human or machine), it can forward this
information to, for example, a third-party, application server used for automatic dialing
applications. You can also configure the device to disconnect IP-to-Tel calls upon detection
of an answering machine on the Tel side. For more information, see 'Enabling IP-to-Tel
Call Disconnection upon Detection of Answering Machine' on page 180.
The device's default AMD feature is based on voice detection for North American English.
It uses AudioCodes sophisticated speech detection algorithms which are based on
hundreds of real-life recordings of answered calls by live voice and answering machines in
English. The algorithms are used to detect whether it's human or machine based on voice
and silence duration as well as speech patterns. The algorithms of the language-based
recordings are compiled into a file called AMD Sensitivity. This file is provided by default,
pre-installed on the device.
If you wish to implement AMD in a different language or region or if you wish to fine-tune
the default AMD algorithms to suit your specific deployment, please contact your
AudioCodes sales representative for more information on this service. You will be typically
required to provide AudioCodes with a database of recorded voices (calls) in the language
on which the device's AMD feature can base its voice detector algorithms. The data
needed for an accurate calibration should be recorded under the following guidelines:

Statistical accuracy: The number of recorded calls should be as high as possible (at
least 100) and varied. The calls must be made to different people. The calls must be
made in the specific location in which the device's AMD feature is to operate.

Real-life recording: The recordings should simulate real-life answering of a called
person picking up the phone, and without the caller speaking.

Normal environment interferences: The environment in which the recordings are done
should simulate real-life scenarios, in other words, not sterile but not too noisy either.
Interferences, for example, could include background noises of other people talking,
spikes, and car noises.
Once you have provided AudioCodes with your database of recordings, AudioCodes
compiles it into a loadable file. For a brief description of the file format and for installing the
file on the device, see 'AMD Sensitivity File' on page 598.
Note: As the main factor (algorithm) for detecting human and machine is the voice
pattern and silence duration, the language on which the detection algorithm is based,
is in most cases not important as these factors are similar across most languages.
Therefore, the default, pre-installed AMD Sensitivity file, which is based on North
American English, may suffice your deployment even if the device is located in a
region where a language other than English is used.
The device supports up to eight AMD algorithm suites called Parameter Suites, where each
suite defines a range of detection sensitivity levels. Sensitivity levels refer to how
accurately, based on AudioCodes voice detection algorithms, the device can detect
whether a human or machine has answered the call. Each level supports a different
detection sensitivity to human and machine. For example, a specific sensitivity level may
be more sensitive to detecting human than machine. In deployments where the likelihood
Version 6.8
175
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
of a call answered by an answering machine is low, it would be advisable to configure the
device to use a sensitivity level that is more sensitive to human than machine. Each suite
can support up to 16 sensitivity levels (0 to 15), except for Parameter Suite 0, which
supports up to 8 levels (0 to 7). The default, pre-installed AMD Sensitivity file, based on
North American English, provides the following Parameter Suites:

Parameter Suite 0 (normal sensitivity) - contains 8 sensitivity detection levels

Parameter Suite 1 (high sensitivity) - contains 16 sensitivity detection levels
As Parameter Suite 1 provides a greater range of detection sensitivity levels (i.e., higher
detection resolution), this may be the preferable suite to use in your deployment.
The Parameter Suite and sensitivity level can be applied globally for all calls, or for specific
calls using IP Profiles. For enabling AMD and selecting the Parameter Suite and sensitivity
level, see 'Configuring AMD' on page 180.
The tables below show the success rates of the default, pre-installed AMD Sensitivity file
(based on North American English) for correctly detecting "live" human voice and
answering machine:
Approximate AMD Normal Detection Sensitivity - Parameter Suite 0 (Based on North American
English)
Performance
AMD Detection
Sensitivity
Success Rate for Live Calls
Success Rate for Answering Machine
0 (Best for
Answering
Machine)
-
-
1
82.56%
97.10%
2
85.87%
96.43%
3
88.57%
94.76%
4
88.94%
94.31%
5
90.42%
91.64%
6
90.66%
91.30%
7 (Best for Live
Calls)
94.72%
76.14%
Approximate AMD High Detection Sensitivity - Parameter Suite 1 (Based on North American
English)
Performance
AMD Detection
Sensitivity
Success Rate for Live Calls
Success Rate for Answering Machine
0 (Best for
Answering
Machine)
72%
97%
1
77%
96%
2
79%
95%
3
80%
95%
User's Manual
176
Document #: LTRT-27034
User's Manual
14. Media
Performance
AMD Detection
Sensitivity
Success Rate for Live Calls
Success Rate for Answering Machine
4
84%
94%
5
86%
93%
6
87%
92%
7
88%
91%
8
90%
89%
9
90%
88%
10
91%
87%
11
94%
78%
12
94%
73%
13
95%
65%
14
96%
62%
15 (Best for Live
Calls)
97%
46%
When the device detects human or machine using its AMD feature, the device can notify
an application server of the detection by sending a SIP INFO message that contains the
following in its message body:

Human Voice:
Type= AMD
SubType= VOICE

Answering Machine:
Type= AMD
SubType= AUTOMATA

Silence (i.e., no voice detected):
Type= AMD
SubType= SILENT
The device can also detect beeps played by an answering machine at the end of its
greeting message. The device also uses SIP INFO messages to report this detection. For
more information, see 'Detecting Answering Machine Beeps' on page 178. The detected
AMD type (e.g., voice) and success of detecting it correctly are also sent in CDR and
Syslog messages. For information on Syslog fields for AMD, see Syslog Fields for
Answering Machine Detection (AMD)' on page 680. For an example of a SIP call flow for
AMD showing the SIP INFO messages, see 'SIP Call Flow Example of AMD' on page 178.
Version 6.8
177
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.4.1 Detecting Answering Machine Beeps
The device supports the detection of the beep sound played by an answering machine to
indicate the end of the answering machine's greeting message. This is useful in that the
device can then notify, for example, a third-party, application server that it can now leave a
voice message on the answering machine. The device supports the following methods for
detecting and reporting beeps:

AMD-based Detection: The device uses its beep detector that is integrated in the
AMD feature. You can configure the beep detection timeout and beep detection
sensitivity level (for more information, see 'Configuring AMD' on page 180). To enable
the AMD beep detection, the received INVITE message must contain an X-Detect
header with the value "Request=AMD",
X-Detect: Request=AMD
and the AMDBeepDetectionMode parameter must be set to 1 or 2. If set to 1, the beep
is detected only after the answering machine is detected. If set to 2, the beep is
detected even if the answering machine was not detected.

Tone-based Detection (Call Progress Tone): The device detects the beep
according to a call progress tone (CPT). This is enabled if the device receives a
specific beep tone (Tone Type #46) that is also defined in the installed CPT file, and
the received INVITE message contains an X-Detect header with the value
"Request=CPT":
X-Detect: Request=CPT
For more information on the CPT file, see 'Call Progress Tones File' on page 577.
The device reports beep detections to application servers, by sending a SIP INFO
message that contains a body with one of the following values, depending on the method
used for detecting the beep:

AMD-detected Beep:
Type= AMD
SubType= Beep

CPT-detected Beep:
Type= CPT
SubType=Beep
14.4.2 SIP Call Flow Example of AMD
The SIP call flow below shows an example of implementing the device's AMD feature that
enables a third-party, application server to play a recorded voice message to an answering
machine:
1.
User's Manual
Upon detection by the device of the answering machine, the device sends a SIP INFO
message to the application server:
INFO sip:sipp@172.22.2.9:5060 SIP/2.0
Via: SIP/2.0/UDP 172.22.168.249;branch=z9hG4bKac1566945480
Max-Forwards: 70
From: sut <sip:3000@172.22.168.249:5060>;tag=1c1505895240
To: sipp <sip:sipp@172.22.2.9:5060>;tag=1
Call-ID: 1-29758@172.22.2.9
CSeq: 1 INFO
Contact: <sip:56700@172.22.168.249>
Supported: em,timer,replaces,path,resource-priority
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO
,SUBSCRIBE,UPDATE
User-Agent: Audiocodes-Sip-Gateway/v.6.80A.227.005
Content-Type: application/x-detect
178
Document #: LTRT-27034
User's Manual
14. Media
Content-Length: 30
Type= AMD
SubType= AUTOMATA
2.
Upon detection by the device of the start of voice (i.e., the greeting message of the
answering machine), the device sends the following INFO message to the application
server:
INFO sip:sipp@172.22.2.9:5060 SIP/2.0
Via: SIP/2.0/UDP 172.22.168.249;branch=z9hG4bKac482466515
Max-Forwards: 70
From: sut <sip:3000@172.22.168.249:5060>;tag=1c419779142
To: sipp <sip:sipp@172.22.2.9:5060>;tag=1
Call-ID: 1-29753@172.22.2.9
CSeq: 1 INFO
Contact: <sip:56700@172.22.168.249>
Supported: em,timer,replaces,path,resource-priority
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO
,SUBSCRIBE,UPDATE
User-Agent: Audiocodes-Sip-Gateway/v.6.80A.227.005
Content-Type: application/x-detect
Content-Length: 34
Type= PTT
SubType= SPEECH-START
3.
Upon detection by the device of the end of voice (i.e., end of the greeting message of
the answering machine), the device sends the following INFO message to the
application server:
INFO sip:sipp@172.22.2.9:5060 SIP/2.0
Via: SIP/2.0/UDP 172.22.168.249;branch=z9hG4bKac482466515
Max-Forwards: 70
From: sut <sip:3000@172.22.168.249:5060>;tag=1c419779142
To: sipp <sip:sipp@172.22.2.9:5060>;tag=1
Call-ID: 1-29753@172.22.2.9
CSeq: 1 INFO
Contact: <sip:56700@172.22.168.249>
Supported: em,timer,replaces,path,resource-priority
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO
,SUBSCRIBE,UPDATE
User-Agent: Audiocodes-Sip-Gateway/v.6.80A.227.005
Content-Type: application/x-detect
Content-Length: 34
Type= PTT
SubType= SPEECH-END
4.
The application server sends its message to leave on the answering message.
Version 6.8
179
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.4.3 Configuring AMD
You can configure AMD for all calls using the global AMD parameters, or for specific calls
using IP Profiles. The procedure below describes how to configure AMD for all calls. For
configuring AMD for specific calls, use the AMD parameters in the IP Profile table (see
'Configuring IP Profiles' on page 302). You can also configure AMD per call based on the
called number or Trunk Group. This is achieved by configuring AMD for a specific IP Profile
and then assigning the IP Profile to a Trunk Group in the Inbound IP Routing table (see
'Configuring Inbound IP Routing' on page 392).
 To enable and configure AMD for all calls:
1.
Open the IPMedia Settings page (Configuration tab > VoIP > Media > IPMedia
Settings):
Figure 14-9: AMD Parameters on the IPMedia Settings Page
2.
From the 'IPMedia Detectors' drop-down list (EnableDSPIPMDetectors), select
Enable to enable AMD.
3.
Select the AMD algorithm suite:
a.
b.
4.
Configure the answering machine beep detection:
a.
b.
5.
In the 'Answer Machine Detector Sensitivity Parameter Suit' field, select the
required Parameter Suite included in the installed AMD Sensitivity file.
In the 'Answer Machine Detector Sensitivity' field, enter the required detection
sensitivity level of the selected Parameter Suite.
In the 'Answer Machine Detector Beep Detection Timeout' field
(AMDBeepDetectionTimeout), enter the duration that the beep detector operates
from when detection is initiated.
In the 'Answer Machine Detector Beep Detection Sensitivity' field
(AMDBeepDetectionSensitivity), enter the AMD beep detection sensitivity level.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
For a complete list of AMD-related parameters, see 'IP Media Parameters' on page 993.
14.4.4 Enabling IP-to-Tel Call Disconnection upon Detection of
Answering Machine
The device can disconnect an IP-to-Tel call upon detection of an answering machine on
the Tel side. Once detected, the device disconnects the call after the receipt of an ISDN
Connect from the Tel side and then sends a SIP BYE message to the IP side to disconnect
the call. You can enable this feature for all calls (globally) using the AMDmode parameter,
or for specific calls using IP Profiles where the IP Profile parameter 'AMD Mode'
(IpProfile_AmdMode) is set to [1] Disconnect on AMD (see 'Configuring IP Profiles' on
page 302).
User's Manual
180
Document #: LTRT-27034
User's Manual
14.5
14. Media
Automatic Gain Control (AGC)
Automatic Gain Control (AGC) adjusts the energy of the output signal to a required level
(volume). This feature compensates for near-far gain differences. AGC estimates the
energy of the incoming signal from the IP or PSTN, determined by the 'AGC Redirection'
parameter, calculates the essential gain, and then performs amplification. Feedback
ensures that the output signal is not clipped. You can configure the required Gain Slope in
decibels per second using the 'AGC Slope' parameter and the required signal energy
threshold using the 'AGC Target Energy' parameter.
When the AGC first detects an incoming signal, it begins operating in Fast Mode, which
allows the AGC to adapt quickly when a conversation starts. This means that the Gain
Slope is 8 dB/sec for the first 1.5 seconds. After this period, the Gain Slope is changed to
the user-defined value. You can disable or enable the AGC's Fast Mode feature, using the
ini file parameter AGCDisableFastAdaptation. After Fast Mode is used, the signal should
be off for two minutes in order to have the feature turned on again.
Note: The AGC feature is applicable only to Digital interfaces.
The following procedure describes how to configure AGC using the Web interface:
 To configure AGC using the Web interface:
1.
Open the IPMedia Settings page (Configuration tab > VoIP menu > Media >
IPMedia Settings). The AGC parameters are shown in the figure below:
Figure 14-10: AGC Parameters in IPMedia Settings Page
2.
Configure the following parameters:
•
'Enable AGC' (EnableAGC) - Enables the AGC mechanism.
•
'AGC Slope' (AGCGainSlope) - Determines the AGC convergence rate.
•
'AGC Redirection' (AGCRedirection) - Determines the AGC direction.
•
'AGC Target Energy' - Defines the signal energy value (dBm) that the AGC
attempts to attain.
•
'AGC Minimum Gain' (AGCMinGain) - Defines the minimum gain (in dB) by the
AGC when activated.
•
'AGC Maximum Gain' (AGCMaxGain) - Defines the maximum gain (in dB) by the
AGC when activated.
•
'AGC Disable Fast Adaptation' (AGCDisableFastAdaptation) - Enables the AGC
Fast Adaptation mode.
3.
When using AGC with the SBC application, the 'Transcoding Mode'
(TranscodingMode) parameter must be set to Force. This parameter can either be the
global parameter or per IP Profile.
4.
Click Submit.
Version 6.8
181
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.6
Configuring Analog Settings
The Analog Settings page allows you to configure various analog parameters. For a
detailed description of the parameters appearing on this page, see ''Configuration
Parameters Reference'' on page 715.
This page also selects the type (USA or Europe) of FXS and/or FXO coefficient
information. The FXS coefficient contains the analog telephony interface characteristics
such as DC and AC impedance, feeding current, and ringing voltage.
 To configure the analog parameters:
1.
Open the Analog Settings page (Configuration tab > VoIP menu > Media > Analog
Settings).
Figure 14-11: Analog Settings Page
2.
Configure the parameters as required.
3.
Click Submit.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
User's Manual
182
Document #: LTRT-27034
User's Manual
14.7
14. Media
Configuring Ground- or Loop-Start Signaling per
Analog Port
The Port Ground Start table lets you configure the signaling control method per analog
(FXS or FXO) port. You can set the port to ground-start or loop-start signaling.
Notes:
• For ground-start signaling, make sure that the device's chassis houses the FXO G
module (and not the regular FXO module).
• To support FXO ground-start signaling, set the following additional parameters:
√
EnableCurrentDisconnect to 1
√
FXOBetweenRingTime to 300
• The FXS ground-start interface does not generate a ringing voltage; the FXS
interface initiates the signaling by grounding the TIP lead.
The following procedure describes how to configure the Port Ground Start table in the Web
interface. You can also configure the Port Ground Start table using the ini file table
parameter, GroundKeyDetection_x.
 To configure signaling method per port:
1.
Open the Port Ground Start Table page (Configuration tab > VoIP menu > Media >
Port Ground Start Table).
Figure 14-12: Port Ground Start Table Page
2.
3.
Version 6.8
For each port, select one of the following from the Ground Start drop-down list:
•
[0] Disable = (Default) Port uses loop-start signaling.
•
[1] Enable = Port uses ground-start signaling.
Click Submit, and then save ("burn") your settings to flash memory with a device
reset.
183
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
14.8
Configuring DSP Templates
The DSP Template determines the coders that can be used by the device and various
other functionalities. For a list of DSP templates and the maximum number of channels
supported by each coder, see DSP Templates. You can select a single DSP Template.
Note: If you do not configure a DSP template, the device uses the default DSP
template (i.e., Template 0).
The following procedure describes how to configure a DSP template in the Web interface.
You can also configure this using the table ini file parameter, DSPVersionTemplateNumber
or CLI command, configure voip > media general > DSP-version-template-number.
 To select a DSP Template:
1.
Open the General Settings page (Configuration tab > VoIP menu > Media > General
Media Settings).
Figure 14-13: Defining Single DSP Template in General Settings Page
14.9
2.
In the 'DSP Version Template Number' field, enter the required DSP Template
number.
3.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
DSP Channel Resources for Transcoding
In addition to DSP resources (channels) required for PRI trunk interfaces, the device
provides flexibility in making additional DSP resources available for SBC and IP-to-IP
functionality. This is achieved by the following:

Obtaining DSP resources from the Media Processing Module (MPM)

"Borrowing" DSP resources from the PRI interfaces (i.e., TRUNKS module)
DSP channels are required for the following:

IP-to-IP application: Each IP-to-IP call session includes two legs, requiring two DSP
resources.

SBC application: Typically, the SBC application does not require DSP resources.
However, it requires DSP resources for transcoding, where it uses two DSP
resources.
Note: In some scenarios, the IP-to-IP application does not require DSP resources.
User's Manual
184
Document #: LTRT-27034
User's Manual
14. Media
To support these capabilities and to allow optimal management of the required DSP
resources, you need to ensure suitable hardware and software configuration, as described
below:

Hardware Configuration: The device can obtain DSP resources using one of the
following hardware configurations:
•
MPM Modules: MPM modules provide DSP resources for the SBC application,
the IP-to-IP application, and/or IP media for IP media functionality such as IPbased conferencing. The device can house up to four MPM modules. When the
MPM modules are installed in chassis slots #2, #3, #4, and #5 and not used for
conferencing, the device supports up to 192 DSP resources (i.e., 96 transcoding
sessions), where each module provides up to 48 DSP resources.
Notes:
• If the device is installed with three MPM modules or more, no other telephony
interface module can be installed in the device.
• For conferencing, an MPM module must be installed in Slot #6. If conferencing is
not required, it is recommended not to install an MPM module in Sot #6 as this
reduces the available channels for transcoding form 40 to 20.
•
TRUNKS (PRI) Modules: DSP resources can be obtained from installed PRI
modules (thereby, "disabling" some trunk span interfaces).
Note: DSP resources cannot be "borrowed" from span interfaces that use CAS.
•
Version 6.8
Combination of MPM and PRI Modules: DSP resources can be obtained from
MPM and PRI modules. For example, to achieve 120 channels (with
conferencing), you need to use two MPM modules (installed in slots #5 and #6)
and one PRI module providing two PRI spans (installed in Slot #1).
185
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Software Configuration: The device must be configured as follows:
•
Set the MediaChannels parameter to the maximum number of required IP media
channels, regardless of the module from where the channels are obtained.
Note: Setting the MediaChannels parameter to a value that is greater than the
available DSP resources that is provided by the MPM module(s) can result in the
"stealing" of DSP resources from the B-channels of the PRI spans.
•
Set the IPmediaChannels parameter to the number of DSP channels that you
want to “borrow” (use) from each PRI module for the SBC application and IP-to-IP
application. The setting below shows an example of borrowing DSP channels
from PRI modules #1 and #2:
[IPMediaChannels]
FORMAT IPMediaChannels_Index = IPMediaChannels_ModuleID,
IPMediaChannels_DSPChannelsReserved;
IPMediaChannels 1 = 1, 15;
IPMediaChannels 2 = 2, 10;
[\IPMediaChannels]
Notes:
• If the device is not installed with an MPM module and you want the device to
"borrow" DSP channels from the PRI modules, you must set the
EnableIPMediaChannels parameter to 1. This parameter is automatically enabled
when the device is installed with an MPM module.
• The value of IPMediaChannels_DSPChannelsReserved must be in multiples of 5.
• By default, the MPM module is set to the maximum number of IP media channels.
Therefore, there is no need to define it with the IPmediaChannels parameter.
• By default, the IPMediaChannels_DSPChannelsReserved parameter for all PRI
modules is set to 0 (i.e., no "borrowing" of IP media channels).
14.10 Configuring Media (SRTP) Security
The device supports Secured RTP (SRTP) according to RFC 3711. SRTP is used to
encrypt RTP and RTCP transport for protecting VoIP traffic. SRTP requires a key
exchange mechanism that is performed according to RFC 4568 – “Session Description
Protocol (SDP) Security Descriptions for Media Streams”. The key exchange is done by
adding a 'crypto' attribute to the SDP. This attribute is used (by both sides) to declare the
various supported cipher suites and to attach the encryption key. If negotiation of the
encryption data is successful, the call is established.
SRTP supports the following cipher suites (all other suites are ignored):

AES_CM_128_HMAC_SHA1_32

AES_CM_128_HMAC_SHA1_80
When the device is the offering side, it generates an MKI of a size configured by the
'Master Key Identifier (MKI) Size' parameter. The length of the MKI is limited to four bytes.
If the remote side sends a longer MKI, the key is ignored. The key lifetime field is not
supported. However, if it is included in the key it is ignored and the call does not fail.
User's Manual
186
Document #: LTRT-27034
User's Manual
14. Media
The device supports the following session parameters (as defined in RFC 4568, SDP
Security Descriptions for Media Streams):

UNENCRYPTED_SRTP

UNENCRYPTED_SRTCP

UNAUTHENTICATED_SRTP
Session parameters should be the same for the local and remote sides. When the device is
the offering side, the session parameters are configured by the following parameter 'Authentication On Transmitted RTP Packets', 'Encryption On Transmitted RTP Packets,
and 'Encryption On Transmitted RTCP Packets'. When the device is the answering side,
the device adjusts these parameters according to the remote offering. Unsupported
session parameters are ignored, and do not cause a call failure.
Below is an example of crypto attributes usage:
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:PsKoMpHlCg+b5X0YLuSvNrImEh/dAe
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:IsPtLoGkBf9a+c6XVzRuMqHlDnEiAd
The device also supports symmetric MKI negotiation, whereby it can be configured to
forward the MKI size received in the SDP offer crypto line in the SDP answer crypto line.
To configure the device's mode of operation if negotiation of the cipher suite fails, use the
'Media Security Behavior' parameter. This parameter can be set to enforce SRTP, whereby
incoming calls that don’t include encryption information are rejected.
Notes:
• For a detailed description of the SRTP parameters, see ''SRTP Parameters'' on
page 749.
• When SRTP is used, the channel capacity may be reduced.
Version 6.8
187
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To enable and configure SRTP:
1.
Open the Media Security page (Configuration tab > VoIP menu > Media > Media
Security).
2.
Set the 'Media Security' parameter to Enable to enable SRTP.
3.
Configure the other SRTP parameters as required.
4.
Click Submit.
5.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
User's Manual
188
Document #: LTRT-27034
User's Manual
15
15. Services
Services
This section describes configuration for various supported services.
15.1
DHCP Server Functionality
The device can serve as a Dynamic Host Configuration Protocol (DHCP) server that
assigns and manages IP addresses from a user-defined address pool for DHCP clients.
The DHCP server can also be configured to supply additional information to the requesting
client such as the IP address of the TFTP server, DNS server, NTP server, and default
router (gateway). The DHCP server functionality complies with IETF RFC 2131 and RFC
2132.
The DHCP server can service up to 600 DHCP clients. The DHCP clients are typically IP
phones that are connected to the device's LAN port.
The DHCP server is activated when you configure a valid entry in the DHCP Servers table
(see ''Configuring the DHCP Server'' on page 189) and associate it with an active IP
network interface (listed in the Interface table). When an IP phone on the LAN requests an
IP address, the DHCP server allocates one from the address pool. In scenarios of
duplicated IP addresses on the LAN (i.e., an unauthorized network device using one of the
IP addresses of the DHCP address pool), the DHCP server detects this condition using an
Address Resolution Protocol (ARP) request and temporarily blacklists the duplicated
address.
You can also configure the DHCP server to respond only to DHCPDiscover requests from
DHCP clients that contain a specific value for Option 60 (Vendor Class Identification). For
more information, see ''Configuring the Vendor Class Identifier'' on page 193.
15.1.1 Configuring the DHCP Server
The DHCP Servers table lets you configure the device's DHCP server. The DHCP Server
table configures the DHCP server implementation. This includes configuring the DHCP IP
address pool from where IP addresses are allocated to requesting DHCP clients, as well
as configuring other information such as IP addresses of the DNS server, NTP server,
default router (gateway), and SIP proxy server. The DHCP server sends the information in
DHCP Options. The table below lists the DHCP Options that the DHCP server sends to the
DHCP client and which are configurable in the DHCP Servers table.
Table 15-1: Configurable DHCP Options in DHCP Servers Table
DHCP Option Code
DHCP Option Name
Option 53
DHCP Message Type
Option 54
DHCP Server Identifier
Option 51
IP Address Lease Time
Option 1
Subnet Mask
Option 3
Router
Option 6
Domain Name Server
Option 44
NetBIOS Name Server
Option 46
NetBIOS Node Type
Option 42
Network Time Protocol Server
Option 2
Time Offset
Version 6.8
189
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
DHCP Option Code
DHCP Option Name
Option 66
TFTP Server Name
Option 67
Boot file Name
Option 120
SIP Server
Once you have configured the DHCP server, you can configure the following:

DHCP Vendor Class Identifier names (DHCP Option 60) - see ''Configuring the
Vendor Class Identifier'' on page 193

Additional DHCP Options - see ''Configuring Additional DHCP Options'' on page 194

Static IP addresses for DHCP clients - see ''Configuring Static IP Addresses for DHCP
Clients'' on page 196
Note: If you configure additional DHCP Options in the DHCP Option table, they
override the default ones, which are configured in the DHCP Servers table. For
example, if you configure Option 67 in the DHCP Option table, the device uses the
value configured in the DHCP Option table instead of the value configured in the
DHCP Servers table.
To view and delete currently serviced DHCP clients, see ''Viewing and Deleting DHCP
Clients'' on page 197.
The following procedure describes how to configure the DHCP server in the Web interface.
You can also configure this using the table ini file parameter, DhcpServer or CLI command,
configure voip > dhcp server <index>.
 To configure the device's DHCP server:
1.
Open the DHCP Servers page (Configuration tab > VoIP menu > Services > DHCP
Severs).
2.
Click Add; the following dialog box appears:
Figure 15-1: DHCP Servers Table - Add Record Dialog Box
User's Manual
190
Document #: LTRT-27034
User's Manual
15. Services
3.
Configure a DHCP server according to the parameters described in the table below.
4.
Click Submit.
Table 15-2: DHCP Servers Table Parameter Descriptions
Parameter
Description
Web: Index
CLI: dhcp server <index>
Defines an index number for the new table record.
Notes:
 Each table row must be configured with a unique index.
 Currently, only one index row can be configured.
Web: Interface Name
CLI: network-if
[DhcpServer_InterfaceName]
Associates an IP interface on which the DHCP server
operates. The IP interfaces are configured in the Interface
table (see Configuring IP Network Interfaces).
By default, no value is defined.
Web: Start IP Address
CLI: start-address
[DhcpServer_StartIPAddress]
Defines the starting IP address (IPv4 address in dotteddecimal format) of the IP address pool range used by the
DHCP server to allocate addresses.
The default value is 192.168.0.100.
Note: The IP address must belong to the same subnet as the
associated interface’s IP address.
Web: End IP Address
CLI: end-address
[DhcpServer_EndIPAddress]
Defines the ending IP address (IPv4 address in dotteddecimal format) of the IP address pool range used by the
DHCP server to allocate addresses.
The default value is 192.168.0.149.
Note: The IP address must belong to the same subnet as the
associated interface’s IP address and must be "greater or
equal" to the starting IP address defined in 'Start IP Address'.
Web: Subnet Mask
CLI: subnet-mask
[DhcpServer_SubnetMask]
Defines the subnet mask (for IPv4 addresses) for the DHCP
client. The value is sent in DHCP Option 1 (Subnet Mask).
The default value is 0.0.0.0.
Note: The value must be "narrower" or equal to the subnet
mask of the associated interface’s IP address. If set to
"0.0.0.0", the subnet mask of the associated interface is
used.
Web: Lease Time
CLI: lease-time
[DhcpServer_LeaseTime]
Defines the duration (in minutes) of the lease time to a DHCP
client for using an assigned IP address. The client needs to
request a new address before this time expires. The value is
sent in DHCP Option 51 (IP Address Lease Time).
The valid value range is 0 to 214,7483,647. The default is
1440. When set to 0, the lease time is infinite.
Web: DNS Server 1
CLI: dns-server-1
[DhcpServer_DNSServer1]
Defines the IP address (IPv4) of the primary DNS server that
the DHCP server assigns to the DHCP client. The value is
sent in DHCP Option 6 (Domain Name Server).
The default value is 0.0.0.0.
Web: DNS Server 2
CLI: dns-server-2
[DhcpServer_DNSServer2]
Defines the IP address (IPv4) of the secondary DNS server
that the DHCP server assigns to the DHCP client. The value
is sent in DHCP Option 6 (Domain Name Server).
Version 6.8
191
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Web: NetBIOS Name Server
CLI: netbios-server
[DhcpServer_NetbiosNameServer]
Defines the IP address (IPv4) of the NetBIOS WINS server
that is available to a Microsoft DHCP client. The value is sent
in DHCP Option 44 (NetBIOS Name Server).
The default value is 0.0.0.0.
Web: NetBIOS Node Type
CLI: netbios-node-type
[DhcpServer_NetbiosNodeType]
Defines the node type of the NetBIOS WINS server for a
Microsoft DHCP client. The value is sent in DHCP Option 46
(NetBIOS Node Type).
 [0] Broadcast (default)
 [1] peer-to-peer
 [4] Mixed
 [8] Hybrid
Web: NTP Server 1
CLI: ntp-server-1
[DhcpServer_NTPServer1]
Defines the IP address (IPv4) of the primary NTP server that
the DHCP server assigns to the DHCP client. The value is
sent in DHCP Option 42 (Network Time Protocol Server).
The default value is 0.0.0.0.
Web: NTP Server 2
CLI: ntp-server-2
[DhcpServer_NTPServer2]
Defines the IP address (IPv4) of the secondary NTP server
that the DHCP server assigns to the DHCP client. The value
is sent in DHCP Option 42 (Network Time Protocol Server).
The default value is 0.0.0.0.
Web: Time Offset
CLI: time-offset
[DhcpServer_TimeOffset]
Defines the Greenwich Mean Time (GMT) offset (in seconds)
that the DHCP server assigns to the DHCP client. The value
is sent in DHCP Option 2 (Time Offset).
The valid range is -43200 to 43200. The default is 0.
Web: TFTP Server
CLI: tftp-server-name
[DhcpServer_TftpServer]
Defines the IP address or name of the TFTP server that the
DHCP server assigns to the DHCP client. The TFTP server
typically stores the boot file image, defined in the 'Boot file
name' parameter (see below). The value is sent in DHCP
Option 66 (TFTP Server Name).
The valid value is a string of up to 80 characters. By default,
no value is defined.
Web: Boot file name
CLI: boot-file-name
[DhcpServer_BootFileName]
Defines the name of the boot file image for the DHCP client.
The boot file stores the boot image for the client. The boot
image is typically the operating system the client uses to load
(downloaded from a boot server). The value is sent in DHCP
Option 67 (Bootfile Name). To define the server storing the
file, use the 'TFTP Server' parameter (see above).
The valid value is a string of up to 256 characters. By default,
no value is defined.
The name can also include the following case-sensitive
placeholder strings that are replaced with actual values if the
'Expand Boot-file Name' parameter is set to Yes:
 <MAC>: Replaced by the MAC address of the client (e.g.,
boot_<MAC>.ini). The MAC address is obtained in the
client's DHCP request.
 <IP>: Replaced by the IP address assigned by the DHCP
server to the client.
User's Manual
192
Document #: LTRT-27034
User's Manual
15. Services
Parameter
Description
Web: Expand Boot-file Name
Enables the use of the placeholders in the boot file name,
CLI: expand-boot-file-name
defined in the 'Boot file name' parameter.
[DhcpServer_ExpandBootfileName]  [0] No
 [1] Yes (default)
Web: Override Router
CLI: override-router-address
[DhcpServer_OverrideRouter]
Defines the IP address (IPv4 in dotted-decimal notation) of
the default router that the DHCP server assigns the DHCP
client. The value is sent in DHCP Option 3 (Router).
The default value is 0.0.0.0. If not specified (empty or
“0.0.0.0”), the IP address of the default gateway configured in
the Interface table for the IP network interface that you
associated with the DHCP server (see the 'Interface Name'
parameter above) is used.
Web: SIP Server
CLI:sip-server
[DhcpServer_SipServer]
Defines the IP address or DNS name of the SIP server that
the DHCP server assigns the DHCP client. The client uses
this SIP server for its outbound SIP requests. The value is
sent in DHCP Option 120 (SIP Server). After defining this
parameter, use the 'SIP server type' parameter (see below)
to define the type of address (FQDN or IP address).
The valid value is a string of up to 256 characters. The
default is 0.0.0.0.
Web: SIP server type
CLI: sip-server-type
[DhcpServer_SipServerType]
Defines the type of SIP server address. The actual address is
defined in the 'SIP server' parameter (see above). Encoding
is done per SIP Server Type, as defined in RFC 3361.
 [0] DNS names = (Default) The 'SIP server' parameter is
configured with an FQDN of the SIP server.
 [1] IP address = The 'SIP server' parameter is configured
with an IP address of the SIP server.
15.1.2 Configuring the Vendor Class Identifier
The DHCP Vendor Class table lets you configure up to 10 Vendor Class Identifier (VCI)
names (DHCP Option 60). When the table is configured, the device's DHCP server
responds only to DHCPDiscover requests that contain Option 60 and that match one of the
DHCP VCIs configured in the table. If you have not configured any entries in the table, the
DHCP server responds to all DHCPDiscover requests, regardless of the VCI.
The VCI is a string that identifies the vendor and functionality of a DHCP client to the
DHCP server. For example, Option 60 can show the unique type of hardware (e.g.,
"AudioCodes 440HD IP Phone") or firmware of the DHCP client. The DHCP server can
then differentiate between DHCP clients and process their requests accordingly.
The following procedure describes how to configure the DHCP VCIs in the Web interface.
You can also configure this using the table ini file parameter, DhcpVendorClass or CLI
command, configure voip > dhcp vendor-class.
 To configure DHCP Vendor Class Identifiers:
1.
Open the DHCP Servers page (Configuration tab > VoIP menu > Services > DHCP
Severs).
2.
In the DHCP Servers table, select the row of the desired DHCP server for which you
want to configure VCIs, and then click the DHCP Vendor Class Table link located at
the bottom of the page; the DHCP Vendor Class Table page opens.
Version 6.8
193
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Click Add; the following dialog box appears:
Figure 15-2: DHCP Vendor Class Table - Add Record Dialog Box
4.
Configure a VCI for the DHCP server according to the parameters described in the
table below.
5.
Click Submit.
Table 15-3: DHCP Vendor Class Table Parameter Descriptions
Parameter
Web: Index
CLI: dhcp vendor-class <index>
[DhcpVendorClass_Index]
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique
index.
Web: DHCP Server Index
Associates the VCI table entry with a DHCP server that
CLI: dhcp-server-number
you configured in ''Configuring the DHCP Server'' on page
[DhcpVendorClass_DhcpServerIndex] 189.
Note: Currently, only one DHCP server (Index 0) can be
configured and therefore, this parameter is always set at 0.
Web: Vendor Class Identifier
CLI: vendor-class
[DhcpVendorClass_VendorClassId]
Defines the value of the VCI DHCP Option 60.
The valid value is a string of up to 80 characters. By
default, no value is defined.
15.1.3 Configuring Additional DHCP Options
The DHCP Option table lets you configure up to 10 additional DHCP Options that the
DHCP server can use to service the DHCP client. These DHCP Options are included in the
DHCPOffer response sent by the DHCP server.
The following procedure describes how to configure DHCP Options in the Web interface.
You can also configure this using the table ini file parameter, DhcpOption or CLI command,
configure voip > dhcp option.
Note: The additional DHCP Options configured in the DHCP Option table override the
default ones, which are configured in the DHCP Servers table. In other words, if you
configure Option 67 in the DHCP Option table, the device uses the value configured
in the DHCP Option table instead of the value configured in the DHCP Servers table.
 To configure DHCP Options:
1.
Open the DHCP Servers page (Configuration tab > VoIP menu > Services > DHCP
Severs).
2.
In the DHCP Servers table, select the row of the desired DHCP server for which you
want to configure additional DHCP Options, and then click the DHCP Option Table
link located at the bottom of the page; the DHCP Option Table page opens.
User's Manual
194
Document #: LTRT-27034
User's Manual
3.
15. Services
Click Add; the following dialog box appears:
Figure 15-3: DHCP Option Table - Add Record Dialog Box
4.
Configure additional DHCP Options for the DHCP server according to the parameters
described in the table below.
5.
Click Submit.
Table 15-4: DHCP Option Table Parameter Descriptions
Parameter
Web: Index
CLI: dhcp option
[DhcpOption_Index]
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Web: DHCP Server Index
Associates the DHCP Option table entry with a DHCP server that
CLI: dhcp-server-number
you configured in ''Configuring the DHCP Server'' on page 189.
[DhcpOption_DhcpServerIndex] Note: Currently, only one DHCP server (Index 0) can be
configured and therefore, this parameter is always set at 0.
Web: Option
CLI: option
[DhcpOption_Option]
Defines the code of the DHCP Option.
The valid value is 1 to 254. The default is 159.
For example, for DHCP Option 150 (Cisco proprietary for defining
multiple TFTP server IP addresses), enter the value 150.
Web: Type
CLI: type
[DhcpOption_Type]
Defines the format (type) of the DHCP Option value that is
configured in the 'Value' parameter (see below).
 [0] ASCII = (Default) Plain-text string (e.g., when the value is
a domain name).
 [1] IP address = IPv4 address.
 [2] Hexadecimal = Hexadecimal-encoded string.
For example, if you set the 'Value' parameter to "company.com",
you need to set the 'Type' parameter to ASCII.
Version 6.8
195
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Web: Value
CLI: value
[DhcpOption_Value]
Defines the value of the DHCP Option. For example, if you are
using Option 66, this parameter is used for specifying the TFTP
provisioning server (e.g.,
http://192.168.3.155:5000/provisioning/).
The valid value is a string of up to 256 characters. By default, no
value is defined. For IP addresses, the value can be one or more
IPv4 addresses, each separated by a comma (e.g.,
192.168.10.5,192.168.10.20). For hexadecimal values, the value
is a hexadecimal string (e.g., c0a80a05).
You can also configure the parameter with case-sensitive
placeholder strings that are replaced with actual values if the
'Expand Value' parameter (see below) is set to Yes:
 <MAC>: Replaced by the MAC address of the client. The
MAC address is obtained from the client's DHCP request. For
example, the parameter can be set to:
http://192.168.3.155:5000/provisioning/cfg_<MAC>.txt
 <IP>: Replaced by the IP address assigned by the DHCP
server to the client. For example, the parameter can be set
to: http://192.168.3.155:5000/provisioning/cfg_<IP>.txt
Web: Expand Value
CLI: expand-value
[DhcpOption_ExpandValue]
Enables the use of the special placeholder strings, "<MAC>" and
"<IP>" for configuring the 'Value' parameter (see above).
 [0] No
 [1] Yes (default)
Note: This parameter is applicable only to values of type ASCII
(see the 'Type' parameter above.
15.1.4 Configuring Static IP Addresses for DHCP Clients
The DHCP Static IP table lets you configure up to 100 DHCP clients with static IP
addresses. The static IP address is a "reserved" IP address for a specified DHCP client
defined by MAC address. In other words, instead of assigning the DHCP client with a
different IP address upon each IP address lease renewal request, the DHCP server
assigns the client the same IP address. For DHCP clients that are not listed in the table,
the DHCP server assigns a random IP address from its address pool, as in normal
operation.
The following procedure describes how to configure static IP addresses for DHCP clients in
the Web interface. You can also configure this using the table ini file parameter,
DhcpStaticIP or CLI command, configure voip > dhcp static-ip <index>.
 To configure static IP addresses for DHCP clients:
1.
Open the DHCP Servers page (Configuration tab > VoIP menu > Services > DHCP
Severs).
2.
In the DHCP Servers table, select the row of the desired DHCP server for which you
want to configure static IP addresses for DHCP clients, and then click the DHCP
Static IP Table link located at the bottom of the page; the DHCP Static IP Table page
opens.
User's Manual
196
Document #: LTRT-27034
User's Manual
3.
15. Services
Click Add; the following dialog box appears:
Figure 15-4: DHCP Static IP Table - Add Record
4.
Configure a static IP address for a specific DHCP client according to the parameters
described in the table below.
5.
Click Submit.
Table 15-5: DHCP Static IP Table Parameter Descriptions
Parameter
Web: Index
CLI: dhcp static-ip <index>
[DhcpStaticIP_Index]
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Web: DHCP Server Index
Associates the DHCP Static IP table entry with a DHCP server
CLI: dhcp-server-number
that you configured in ''Configuring the DHCP Server'' on page
[DhcpStaticIP_DhcpServerIndex] 189.
Note: Currently, only one DHCP server (Index 0) can be
configured and therefore, this parameter is always set at 0.
Web: IP Address
CLI: ip-address
[DhcpStaticIP_IPAddress]
Defines the "reserved", static IP address (IPv4) to assign the
DHCP client.
The default is 0.0.0.0.
Web: MAC Address
CLI: mac-address
[DhcpStaticIP_MACAddress]
Defines the DHCP client by MAC address (in hexadecimal
format).
The valid value is a string of up to 20 characters. The format
includes six groups of two hexadecimal digits, each separated
by a colon. The default MAC address is 00:90:8f:00:00:00.
15.1.5 Viewing and Deleting DHCP Clients
The DHCP Clients table lets you view all currently serviced DHCP clients by the DHCP
server. The table also lets you delete DHCP clients. If you delete a client, the DHCP server
ends the lease of the IP address to the client and the IP address becomes available for
allocation by the DHCP server to another client.
The following procedure describes how to view DHCP clients in the Web interface. You can
also view this using the following CLI commands:

To view DHCP clients:
# show voip dhcp clients

To view DHCP clients according to IP address:
# show voip dhcp ip

To view DHCP clients according to MAC address:
# show voip dhcp mac

To view DHCP clients that have been blacklisted from DHCP implementation (due to
Version 6.8
197
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
duplicated IP addresses in the network, where another device is using the same IP
address as the one assigned to the client):
# show voip dhcp black-list
 To view or delete DHCP clients:
1.
Open the DHCP Servers page (Configuration tab > VoIP menu > Services > DHCP
Severs).
2.
In the DHCP Servers table, select the row of the desired DHCP server for which you
want to view DHCP clients, and then click the DHCP Clients Table link located at the
bottom of the page; the DHCP Clients Table page opens:
Figure 15-5: DHCP Clients Table
The table displays the following per client:
3.
•
Index: Table index number.
•
DHCP Server Index: The index number of the configured DHCP server scope in
the DHCP Server table (see ''Configuring the DHCP Server'' on page 189) with
which the client is associated.
•
IP Address: IP address assigned to the DHCP client by the DHCP server.
•
MAC Address: MAC address of the DHCP client.
•
Lease Expiration: Date on which the lease of the DHCP client's IP address
obtained from the DHCP server expires.
To delete a client:
a.
b.
c.
User's Manual
Select the table row index of the DHCP client that you want to delete.
Click the Action button, and then from the drop-down menu, choose Delete; a
confirmation message appears.
Click OK to confirm deletion.
198
Document #: LTRT-27034
User's Manual
15.2
15. Services
RADIUS Authentication
You can enhance security for your device by implementing Remote Authentication Dial-In
User Service (RADIUS - RFC 2865) for authenticating multiple management user accounts
of the device’s embedded Web and Telnet (CLI) servers. Thus, RADIUS also prevents
unauthorized access to your device.
When RADIUS authentication is not used, the user's login username and password are
locally authenticated by the device in its Web Users table (database). However, the Web
Users table can be used as a fallback mechanism in case the RADIUS server does not
respond. For configuring local user accounts, see Configuring Web User Accounts.
When RADIUS authentication is used, the RADIUS server stores the user accounts usernames, passwords, and access levels (authorization). When a management user
(client) tries to access the device, the device sends the RADIUS server the user's
username and password for authentication. The RADIUS server replies with an acceptance
or a rejection notification. During the RADIUS authentication process, the device’s Web
interface is blocked until an acceptance response is received from the RADIUS server.
Note that communication between the device and the RADIUS server is done by using a
shared secret, which is not transmitted over the network.
Figure 15-6: RADIUS Login Authentication for Management
For using RADIUS, you need to do the following:

Set up a RADIUS server (third-party) to communicate with the device - see 'Setting Up
a Third-Party RADIUS Server' on page 200

Configure the device as a RADIUS client for communication with the RADIUS server see 'Configuring RADIUS Authentication' on page 201
Version 6.8
199
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
15.2.1 Setting Up a Third-Party RADIUS Server
The following procedure provides an example for setting up the third-party RADIUS sever,
FreeRADIUS, which can be downloaded from www.freeradius.org. Follow the instructions
on this Web site for installing and configuring the server. If you use a RADIUS server from
a different vendor, refer to its appropriate documentation.
 To set up a third-party RADIUS server (e.g., FreeRADIUS):
1.
Define the AudioCodes device as an authorized client of the RADIUS server, with the
following:
•
Predefined shared secret (password used to secure communication between the
device and the RADIUS server)
•
Vendor ID
Below is an example of the clients.conf file (FreeRADIUS client configuration):
#
# clients.conf - client configuration directives
#
client 10.31.4.47 {
secret
= FutureRADIUS
shortname
= audc_device
}
2.
If access levels are required, set up a Vendor-Specific Attributes (VSA) dictionary for
the RADIUS server and select an attribute ID that represents each user's access level.
The example below shows a dictionary file for FreeRADIUS that defines the attribute
"ACL-Auth-Level" with "ID=35". For the device's user access levels and their
corresponding numeric representation in RADIUS servers, see Configuring Web User
Accounts.
#
# AudioCodes VSA dictionary
#
VENDOR AudioCodes 5003
ATTRIBUTE ACL-Auth-Level 35 integer AudioCodes
VALUE ACL-Auth-Level ACL-Auth-UserLevel 50
VALUE ACL-Auth-Level ACL-Auth-AdminLevel 100
VALUE ACL-Auth-Level ACL-Auth-SecurityAdminLevel 200
3.
Define the list of users authorized to use the device, using one of the password
authentication methods supported by the server implementation. The example below
shows a user configuration file for FreeRADIUS using a plain-text password:
# users - local user configuration database
john
sue
4.
User's Manual
Auth-Type := Local, User-Password == "qwerty"
Service-Type = Login-User,
ACL-Auth-Level = ACL-Auth-SecurityAdminLevel
Auth-Type := Local, User-Password == "123456"
Service-Type = Login-User,
ACL-Auth-Level = ACL-Auth-UserLevel
Record and retain the IP address, port number, shared secret code, vendor ID, and
VSA access level identifier (if access levels are implemented) used by the RADIUS
server.
200
Document #: LTRT-27034
User's Manual
15. Services
15.2.2 Configuring RADIUS Authentication
The following procedure describes how to configure the RADIUS feature. For a detailed
description of the RADIUS parameters, see 'RADIUS Parameters' on page 755.
 To configure RADIUS:
1.
Open the Authentication Settings page (Configuration tab > System menu >
Management > Authentication Settings).
Figure 15-7: Authentication Settings Page - RADIUS Configuration
2.
Set the 'Enable RADIUS Access Control' parameter to Enable to enable the RADIUS
application.
3.
Set the 'Use RADIUS for Web/Telnet Login' parameter to Enable to enable RADIUS
authentication for Web and Telnet login.
4.
Define the RADIUS server:
a.
b.
c.
In the 'RADIUS Authentication Server IP Address' field, enter the RADIUS
server’s IP address.
In the 'RADIUS Authentication Server Port' field, enter the RADIUS server’s port
number.
In the 'RADIUS Shared Secret' field, enter the shared secret used to authenticate
the device to the RADIUS server.
5.
In the 'RADIUS VSA Vendor ID' field, enter the same vendor ID number as set on the
RADIUS server.
6.
When implementing Web user access levels, do one of the following:
Version 6.8
•
If the RADIUS server response includes the access level attribute: In the
'RADIUS VSA Access Level Attribute' field, enter the code that indicates the
access level attribute in the VSA section of the received RADIUS packet. For
defining the RADIUS server with access levels, see 'Setting Up a Third-Party
RADIUS Server' on page 200.
•
If the RADIUS server response does not include the access level attribute:
In the 'Default Access Level' field, enter the default access level that is applied to
all users authenticated by the RADIUS server.
201
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
7.
Configure RADIUS timeout handling:
a.
b.
c.
8.
9.
From the 'Behavior upon Authentication Server Timeout' drop-down list, select
the option if the RADIUS server does not respond within five seconds:
♦
Deny Access: device denies user login access.
♦
Verify Access Locally: device checks the username and password
configured locally for the user (in the Web User Accounts page or Web
Users table), and if correct, allows access.
In the 'Password Local Cache Timeout' field, enter a time limit (in seconds) after
which the username and password verified by the RADIUS server becomes
invalid and a username and password needs to be re-validated with the RADIUS
server.
From the 'Password Local Cache Mode' drop-down list, select the option for the
local RADIUS password cache timer:
♦
Reset Timer Upon Access: upon each access to a Web page, the timer
resets (reverts to the initial value configured in the previous step).
♦
Absolute Expiry Timer: when you access a Web page, the timer doesn’t
reset, but continues its count down.
Configure when the Web Users table must be used to authenticate login users. From
the 'Use Local Users Database' drop-down list, select one of the following:
•
When No Auth Server Defined (default): When no RADIUS server is configured
(or as fallback if the server is inaccessible).
•
Always: Always, but if not found, use the RADIUS server to authenticate the
user.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
15.2.3 Securing RADIUS Communication
RADIUS authentication requires HTTP basic authentication (according to RFC 2617).
However, this is insecure as the usernames and passwords are transmitted in clear text
over plain HTTP. Thus, as digest authentication is not supported with RADIUS, it is
recommended that you use HTTPS with RADIUS so that the usernames and passwords
are encrypted.
To configure the device to use HTTPS, set the 'Secured Web Connection (HTTPS)'
parameter to HTTPS Only, in the WEB Security Settings page (Configuration tab >
System menu > Management > WEB Security Settings).
15.2.4 Authenticating RADIUS in the URL
RADIUS authentication is typically done after the user accesses the Web interface by
entering only the device's IP address in the Web browser's URL field (for example,
http://10.13.4.12/), and then entering the username and password credentials in the Web
interface login screen. However, authentication with the RADIUS server can also be done
immediately after the user enters the URL, if the URL also contains the login credentials,
for
example:
http://10.4.4.112/Forms/RadiusAuthentication?WSBackUserName=John&WSBackPasswor
d=1234
Note: This feature allows up to five simultaneous users only.
User's Manual
202
Document #: LTRT-27034
User's Manual
15.3
15. Services
LDAP-based Management and SIP Services
The device supports the Lightweight Directory Access Protocol (LDAP) application protocol
and can operate with third-party, LDAP-compliant servers such as Microsoft Active
Directory (AD).
You can use LDAP for the following LDAP services:

SIP-related (Control) LDAP Queries: This can be used for routing or manipulation
(e.g., calling name and destination address). The device connects and binds to the
remote LDAP server (IP address or DNS/FQDN) during the service’s initialization (at
device start-up) or whenever you change the LDAP server's IP address and port.
Binding to the LDAP server is based on username and password (Bind DN and
Password). Service makes 10 attempts to connect and bind to the remote LDAP
server, with a timeout of 20 seconds between attempts. If connection fails, the service
remains in disconnected state until the LDAP server's IP address or port is changed. If
connection to the LDAP server later fails, the service attempts to reconnect.
For the device to run a search, the path to the directory’s subtree, known as the
distinguished name (DN), where the search is to be done must be configured (see
'Configuring LDAP DNs (Base Paths) per LDAP Server' on page 208). The search key
(filter), which defines the exact DN to search, and one or more attributes whose values
must be returned to the device must also be configured. For more information on
configuring these attributes and search filters, see 'Active Directory-based Routing for
Microsoft Lync' on page 219.
The device can store recent LDAP queries and responses in its local cache. The
cache is used for subsequent queries and/or in case of LDAP server failure. For more
information, see 'Configuring the Device's LDAP Cache' on page 212.
If connection with the LDAP server disconnects (broken), the device sends the SNMP
alarm, acLDAPLostConnection. Upon successful reconnection, the alarm clears. If
connection with the LDAP server is disrupted during the search, all search requests
are dropped and an alarm indicating a failed status is sent to client applications.

Management-related LDAP Queries: This is used for authenticating and authorizing
management users (Web and CLI) and is based on the user's login username and
password (credentials) when attempting login to one of the device's management
platforms. When configuring the login username (LDAP Bind DN) and password
(LDAP Password) to send to the LDAP server, you can use templates based on the
dollar ($) sign, which the device replaces with the actual username and password
entered by the user during the login attempt. You can also configure the device to
send the username and password in clear-text format or encrypted using TLS (SSL).
The device connects to the LDAP server (i.e., an LDAP session is created) only when
a login attempt occurs. The LDAP Bind operation establishes the authentication of the
user based on the username-password combination. The server typically checks the
password against the userPassword attribute in the named entry. A successful Bind
operation indicates that the username-password combination is correct; a failed Bind
operation indicates that the username-password combination is incorrect.
Once the user is successfully authenticated, the established LDAP session may be
used for further LDAP queries to determine the user's management access level and
privileges (Operator, Admin, or Security Admin). This is known as the user
authorization stage. To determine the access level, the device searches the LDAP
directory for groups of which the user is a member, for example:
CN=\# Support Dept,OU=R&D
Groups,OU=Groups,OU=APC,OU=Japan,OU=ABC,DC=corp,DC=abc,DC=com
CN=\#AllCellular,OU=Groups,OU=APC,OU=Japan,OU=ABC,DC=corp,DC=a
bc,DC=com
The device then assigns the user the access level configured for that group (in
'Configuring Access Level per Management Groups Attributes' on page 210). The
Version 6.8
203
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
location in the directory where you want to search for the user's member group(s) is
configured using the following:
•
Search base object (distinguished name or DN, e.g.,
"ou=ABC,dc=corp,dc=abc,dc=com"), which defines the location in the directory
from where the LDAP search begins, and is configured in 'Configuring LDAP DNs
(Base Paths) per LDAP Server' on page 208.
•
Search filter, for example, (&(objectClass=person)(sAMAccountName=JohnD)),
which filters the search in the subtree to include only the specific username. The
search filter can be configured with the dollar ($) sign to represent the username,
for example, (sAMAccountName=$). For configuring the search filter, see
'Configuring the LDAP Search Filter Attribute' on page 209.
•
Management attribute (e.g., memberOf), from where objects that match the
search filter criteria are returned. This shows the user's member groups. The
attribute is configured in the LDAP Configuration table (see 'Configuring LDAP
Servers' on page 205).
If the device finds a group, it assigns the user the corresponding access level and
permits login; otherwise, login is denied. Once the LDAP response has been received
(success or failure), the device ends the LDAP session.
For both of the previously discussed LDAP services, the following additional LDAP
functionality is supported:

Search method for searching DN object records between LDAP servers and within
each LDAP server (see 'Configuring LDAP Search Methods' on page 212).

Default access level that is assigned to the user if the queried response does not
contain an access level.

Local users database (Web Users table) for authenticating users instead of the LDAP
server (for example, when a communication problem occurs with the server). For more
information, see 'Configuring Local Database for Management User Authentication' on
page 214.
15.3.1 Enabling the LDAP Service
Before you can configure LDAP support, you need to enable the LDAP service.
 To enable LDAP:
1.
Open the LDAP Settings page (Configuration tab > VoIP menu > Services > LDAP
> LDAP Settings).
Figure 15-8: Enabling LDAP on the LDAP Settings Page
2.
Under LDAP Settings, from the 'LDAP Service' drop-down list, select Enable.
3.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
15.3.2 Enabling LDAP-based Web/CLI User Login Authentication and
Authorization
The LDAP service can be used for authenticating and authorizing device management
users (Web and CLI), based on the user's login username and password (credentials). At
the same, it can also be used to determine users' management access levels (privileges).
Before you can configure LDAP-based login authentication, you must enable this type of
LDAP service, as described in the following procedure.
User's Manual
204
Document #: LTRT-27034
User's Manual
15. Services
 To enable LDAP-based login authentication:
1.
Open the Authentication Settings page (Configuration tab > System menu >
Management > Authentication Settings).
Figure 15-9: Authentication Settings Page - Enabling LDAP-based Login
2.
Under LDAP Settings, from the 'Use LDAP for Web/Telnet Login' drop-down list,
select Enable.
3.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
15.3.3 Configuring LDAP Servers
The LDAP Configuration table lets you configure up to four LDAP servers. This table
defines the address and connectivity settings of the LDAP server. The LDAP server can be
configured for SIP-related queries (e.g., routing and manipulation) or LDAP-based
management user login authentication and authorization (username-password).
The following procedure describes how to configure an LDAP server in the Web interface.
You can also configure this using the table ini file parameter, LdapConfiguration or CLI
command, configure voip/ldap/ldap-configuration.
 To configure an LDAP server:
1.
Open the LDAP Configuration Table page (Configuration tab > VoIP menu >
Services > LDAP > LDAP Configuration Table).
2.
Click Add; the following dialog box appears:
Figure 15-10: LDAP Configuration Table - Add Record
3.
Configure an LDAP server according to the parameters described in the table below.
4.
Click Submit.
LDAP Configuration Table Parameter Descriptions
Parameter
Index
[LdapConfiguration_In
Version 6.8
Description
Defines an index number for the new table record.
205
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
dex]
Description
Note: Each table row must be configured with a unique index.
LDAP Server IP
Defines the IP address of the LDAP server (in dotted-decimal notation,
CLI: server-ip
e.g., 192.10.1.255).
[LdapConfiguration_Ld By default, no IP address is defined.
apConfServerIp]
Note: If you want to use an FQDN for the LDAP server, leave this
parameter undefined and configure the FQDN in the 'LDAP Server
Domain Name' parameter (see below).
LDAP Server Port
Defines the port number of the LDAP server.
CLI: server-port
The valid value range is 0 to 65535. The default port number is 389.
[LdapConfiguration_Ld
apConfServerPort]
LDAP Server Max
Respond Time
CLI: max-respond-time
[LdapConfiguration_Ld
apConfServerMaxResp
ondTime]
Defines the duration (in msec) that the device waits for LDAP server
responses.
The valid value range is 0 to 86400. The default is 3000.
Note: If the response time expires, you can configure the device to use
its local database (Web Users table) for authenticating the user. For
more information, see 'Configuring Local Database for Management User
Authentication' on page 214.
LDAP Server Domain
Name
CLI: domain-name
[LdapConfiguration_Ld
apConfServerDomainN
ame]
Defines the domain name (FQDN) of the LDAP server. The device tries
to connect to the LDAP server according to the IP address listed in the
received DNS query. If there is no connection to the LDAP server or the
connection to the LDAP server fails, the device tries to connect to the
LDAP server with the next IP address in the DNS query list.
Note: The 'LDAP Server IP' parameter takes precedence over this
parameter. Thus, if you want to use an FQDN, leave the 'LDAP Server
IP' parameter undefined.
LDAP Password
Defines the user password for accessing the LDAP server during
CLI: password
connection and binding operations.
[LdapConfiguration_Ld  LDAP-based SIP queries: The parameter is the password used by the
apConfPassword]
device to authenticate itself, as a client, to obtain LDAP service from
the LDAP server.
 LDAP-based user login authentication: The parameter represents the
login password entered by the user during a login attempt. You can
use the $ (dollar) sign in this value to enable the device to
automatically replace the $ sign with the user's login password in the
search filter, which it sends to the LDAP server for authenticating the
user's username-password combination. For example, $.
Note: By default, the device sends the password in clear-text format. You
can enable the device to encrypt the password using TLS (see the 'Use
SSL' parameter below).
User's Manual
206
Document #: LTRT-27034
User's Manual
15. Services
Parameter
Description
LDAP Bind DN
Defines the LDAP server's bind Distinguished Name (DN) or username.
CLI: bind-dn
 LDAP-based SIP queries: The DN is used as the username during
[LdapConfiguration_Ld
connection and binding to the LDAP server. The DN is used to
apConfBindDn]
uniquely name an AD object. Below are example parameter settings:
 cn=administrator,cn=Users,dc=domain,dc=com
 administrator@domain.com
 domain\administrator
 LDAP-based user login authentication: This parameter represents the
login username entered by the user during a login attempt. You can
use the $ (dollar) sign in this value to enable the device to
automatically replace the $ sign with the user's login username in the
search filter, which it sends to the LDAP server for authenticating the
user's username-password combination. An example configuration for
this parameter is $@sales.local, where the device replaces the $ with
the entered username, for example, JohnD@sales.local. The
username can also be configured with the domain name of the LDAP
server.
Note: By default, the device sends the username in clear-text format.
You can enable the device to encrypt the username using TLS (see the
'Use SSL' parameter below).
LDAP Network Interface Assigns one of the device's IP network interfaces for communicating with
CLI: interface-type
the LDAP server.
[LdapConfiguration_Ld  [0] Control Interface (default) = The top-most IP network interface row
apConfInterfaceType]
in the IP Interfaces table that is configured for a Control application
(may be combined with other applications such as OAMP and Media)
is used.
 [1] OAM Interface = The OAMP interface (may be combined with
other applications such as Control and Media) in the IP Interfaces
table is used.
For configuring IP network interfaces, see Configuring IP Network
Interfaces.
Type
CLI: type
[LdapConfiguration_Ty
pe]
Defines whether the LDAP server is used for SIP-related queries or
management login authentication-related queries.
 [0] Control (Default)
 [1] Management
Note: If you use the same LDAP server for both management and SIP
(Control) related applications, the device establishes different LDAP
sessions for each application.
Management Attribute
CLI: mgmt-attr
[LdapConfiguration_M
ngmAuthAtt]
Defines the LDAP attribute name to query, which contains a list of groups
to which the user is a member. For Active Directory, this attribute is
typically "memberOf". The attribute's values (groups) are used to
determine the user's management access level; the group's
corresponding access level is configured in 'Configuring Access Level
per Management Groups Attributes' on page 210.
Notes:
 This parameter is applicable only to LDAP-based login authentication
and authorization (i.e., the 'Type' parameter is set to Management).
 If this functionality is not used, the device assigns the user the
configured default access level. For more information, see
'Configuring Access Level per Management Groups Attributes' on
page 210.
Version 6.8
207
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Use SSL
CLI:
[LdapConfiguration_us
eTLS]
Connection Status
CLI: connection-status
[LdapConfiguration_C
onnectionStatus]
Enables the device to encrypt the username and password (for Control
and Management related queries) using TLS when sending them to the
LDAP server.
 [0] No = (Default) Username and password are sent in clear-text
format.
 [1] Yes
(Read-only) Displays the connection status with the LDAP server.
"Not Applicable"
"LDAP Connection Broken"
"Connecting"
"Connected"
Note: For more information about a disconnected LDAP connection, see
your Syslog messages generated by the device.




15.3.4 Configuring LDAP DNs (Base Paths) per LDAP Server
The LDAP Search DN Table table lets you configure LDAP base paths. The table is a
"child" of the LDAP Configuration table (see 'Configuring LDAP Servers' on page 205) and
configuration is done per LDAP server. For the device to run a search using the LDAP
service, the base path to the directory’s subtree, referred to as the distinguished name
object (or DN), where the search is to be done must be configured. For each LDAP server,
you can configure up to three base paths.
The following procedure describes how to configure DNs per LDAP server in the Web
interface. You can also configure this using the table ini file parameter,
LdapServersSearchDNs or CLI command, configure voip/ldap/ldap-servers-search-dns.
 To configure an LDAP base path per LDAP server:
1.
Open the LDAP Configuration Table page (Configuration tab > VoIP menu >
Services > LDAP > LDAP Configuration Table).
2.
In the LDAP Configuration table, select the row of the LDAP server for which you want
to configure DN base paths, and then click the Search DNs link (located at the bottom
of the page); the LDAP Search DN Table page opens.
3.
Click Add; the following dialog box appears:
Figure 15-11: LDAP Search DN Table - Add Record
4.
Configure an LDAP DN base path according to the parameters described in the table
below.
5.
Click Submit, and then save ("burn") your settings to flash memory.
User's Manual
208
Document #: LTRT-27034
User's Manual
15. Services
LDAP Search DN Table Parameter Descriptions
Parameter
Description
Index
CLI: set internal-index
[LdapServersSearchD
Ns_Index]
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Base Path
CLI: set base-path
[LdapServersSearchD
Ns_Base_Path]
Defines the full path (DN) to the objects in the AD where the query is
done.
The valid value is a string of up to 256 characters.
For example: OU=NY,DC=OCSR2,DC=local. In this example, the DN
path is defined by the LDAP names, OU (organizational unit) and DC
(domain component).
15.3.5 Configuring the LDAP Search Filter Attribute
When the LDAP-based login username-password authentication succeeds, the device
searches the LDAP server for all groups of which the user is a member. The LDAP query is
based on the following LDAP data structure:

Search base object (distinguished name or DN, e.g.,
"ou=ABC,dc=corp,dc=abc,dc=com"): The DN defines the location in the directory
from which the LDAP search begins and is configured in 'Configuring LDAP DNs
(Base Paths) per LDAP Server' on page 208.

Filter (e.g., "(&(objectClass=person)(sAMAccountName=johnd))"): This filters the
search in the subtree to include only the login username (and excludes others). This is
configured by the 'LDAP Authentication Filter' parameter, as described in the following
procedure. You can use the dollar ($) sign to represent the username. For example,
the filter can be configured as "(sAMAccountName=$)", where if the user attempts to
log in with the username "SueM", the LDAP search is done only for the attribute
sAMAccountName that equals "SueM".

Attribute (e.g., "memberOf") to return from objects that match the filter criteria:
The attribute is configured by the 'Management Attribute' parameter in the LDAP
Configuration table (see 'Configuring LDAP Servers' on page 205).
Therefore, the LDAP response includes only the groups of which the specific user is a
member.
Notes:
• The search filter is applicable only to LDAP-based login authentication and
authorization queries.
• The search filter is a global setting that applies to all LDAP-based login
authentication and authorization queries, across all configured LDAP servers.
Version 6.8
209
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure the LDAP search filter for management users:
1.
Open the LDAP Settings page (Configuration tab > VoIP menu > Services > LDAP
> LDAP Settings).
Figure 15-12: LDAP Settings Page - LDAP Search Filter
2.
Under LDAP Settings, in the 'LDAP Authentication Filter' parameter, enter the LDAP
search filter attribute for searching the login username for user authentication.
3.
Click Submit.
15.3.6 Configuring Access Level per Management Groups Attributes
The Management LDAP Groups table lets you configure LDAP group objects and their
corresponding management user access level. The table is a "child" of the LDAP
Configuration table (see 'Configuring LDAP Servers' on page 205) and configuration is
done per LDAP server. For each LDAP server, you can configure up to three table row
entries of LDAP group(s) and their corresponding access level.
Notes:
• The Management LDAP Groups table is applicable only to LDAP-based login
authentication and authorization queries.
• If the LDAP response received by the device includes multiple groups of which the
user is a member and you have configured different access levels for some of
these groups, the device assigns the user the highest access level. For example,
if the user is a member of two groups where one has access level "Monitor" and
the other "Administrator", the device assigns the user the "Administrator" access
level.
• When the access level is unknown, the device assigns the default access level to
the user, configured by the 'Default Access Level' parameter in the Authentication
Settings page (Configuration tab > System menu > Management >
Authentication Settings). This can occur in the following scenarios:
√
The user is not a member of any group.
√
The group of which the user is a member is not configured on the device (as
described in this section).
√
The device is not configured to query the LDAP server for a management
attribute (see 'Configuring LDAP Servers' on page 205).
Group objects represent groups in the LDAP server of which the user is a member. The
access level represents the user account's permissions and rights in the device's
management interface (e.g., Web and CLI). The access level can either be Monitor,
Administrator, or Security Administrator. For an explanation on the privileges of each level,
see Configuring Web User Accounts.
When the username-password authentication with the LDAP server succeeds, the device
searches the LDAP server for all groups of which the user is a member. The LDAP query is
based on the following LDAP data structure:

Search base object (distinguished name or DN, e.g.,
"ou=ABC,dc=corp,dc=abc,dc=com"), which defines the location in the directory from
which the LDAP search begins. This is configured in 'Configuring LDAP DNs (Base
Paths) per LDAP Server' on page 208.

Filter (e.g., "(&(objectClass=person)(sAMAccountName=johnd))"), which filters the
search in the subtree to include only the login username (and excludes others). This is
User's Manual
210
Document #: LTRT-27034
User's Manual
15. Services
configured by the 'LDAP Authentication Filter' parameter.

Attribute (e.g., "memberOf") to return from objects that match the filter criteria. This
attribute is configured by the 'Management Attribute' parameter in the LDAP
Configuration table.
The LDAP response includes all the groups of which the specific user is a member, for
example:
CN=\# Support Dept,OU=R&D
Groups,OU=Groups,OU=APC,OU=Japan,OU=ABC,DC=corp,DC=abc,DC=com
CN=\#AllCellular,OU=Groups,OU=APC,OU=Japan,OU=ABC,DC=corp,DC=abc,D
C=com
The device searches this LDAP response for the group names that you configured in the
Management LDAP Groups table in order to determine the user's access level. If the
device finds a group name, the user is assigned the corresponding access level and login
is permitted; otherwise, login is denied. Once the LDAP response has been received
(success or failure), the LDAP session terminates.
The following procedure describes how to configure an access level per management
groups in the Web interface. You can also configure this using the table ini file parameter,
MgmntLDAPGroups or CLI command, configure voip > ldap > mgmt-ldap-groups.
 To configure management groups and corresponding access level:
1.
Open the LDAP Configuration Table page (Configuration tab > VoIP menu >
Services > LDAP > LDAP Configuration Table).
2.
In the LDAP Configuration table, select the row of the LDAP server for which you want
to configure management groups with a corresponding access level, and then click the
Management LDAP Groups Table link (located at the bottom of the page); the
Management LDAP Groups Table page opens.
3.
Click Add; the following dialog box appears:
Figure 15-13: Management LDAP Groups Table - Add Record
4.
Configure a group name(s) with a corresponding access level according to the
parameters described in the table below.
5.
Click Submit, and then save ("burn") your settings to flash memory.
Management LDAP Groups Table Parameter Descriptions
Parameter
Index
[MgmntLDAPGroups_
GroupIndex]
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique index.
Level
Defines the access level of the group(s).
[MgmntLDAPGroups_L  [0] Monitor (Default)
evel]
 [1] Security Administrator
 [2] Administrator
Version 6.8
211
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Groups
[MgmntLDAPGroups_
Group]
Defines the attribute names of the groups in the LDAP server.
The valid value is a string of up to 256 characters. To define multiple
groups, separate each group name with a semicolon (;).
15.3.7 Configuring LDAP Search Methods
You can configure the device's method for searching the LDAP server(s) for the configured
DN objects:


DN Search Method between Two LDAP Servers: When two LDAP servers are
implemented, the device runs an LDAP query to search for DN object records on both
LDAP servers. You can configure how the device queries the DN object record
between the two LDAP servers:
•
Parallel Search: The device queries the LDAP servers simultaneously.
•
Sequential Search: The device first queries one of the LDAP servers, and if the
DN object is not found, it queries the second LDAP server.
DN Search Method within an LDAP Server: You can configure how the device
queries the DN object record within each LDAP server:
•
Parallel Search: The device queries all DN objects simultaneously. For example,
a search for the DN object record "JohnD" is done at the same time in the
"Marketing", "Sales" and "Administration" DN objects.
•
Sequential Search: The device queries each DN object, one by one, until a
result is found. For example, a search for the DN object record "JohnD" is first run
in DN object "Marketing" and if a result is not found, it searches in "Sales", and if
not found, it searches in "Administration", and so on.
 To configure LDAP search methods:
1.
Open the LDAP Settings page (Configuration tab > VoIP menu > Services > LDAP
> LDAP Settings).
Figure 15-14: LDAP Settings Page - Search Methods
2.
3.
Under LDAP Settings, configure the following:
•
Search method for DN objects between two LDAP servers, using the 'LDAP
Search Server Method' parameter (LDAPSearchServerMethod).
•
Search method for DN objects within an LDAP server, using the 'search dns in
parallel' parameter (LdapSearchDnsInParallel).
Click Submit.
15.3.8 Configuring the Device's LDAP Cache
The device can optionally store recent LDAP queries and responses with an LDAP server
in its local cache. The cache is used for subsequent queries and/or in case of LDAP server
failure.
Note: The LDAP Cache feature is applicable only to LDAP-based SIP queries
(Control).
User's Manual
212
Document #: LTRT-27034
User's Manual
15. Services
The advantage of enabling this feature includes the following:

Improves routing decision performance by using local cache for subsequent LDAP
queries

Reduces number of queries performed on an LDAP server and corresponding
bandwidth consumption

Provides partial survivability in case of intermittent LDAP server failure (or network
isolation)
The handling of LDAP queries with the LDAP cache is shown in the flowchart below:
Figure 15-15: LDAP Query Process with Local LDAP Cache
Note: If for the first LDAP query, the result fails for at least one attribute and is
successful for at least one, the partial result is cached. However, for subsequent
queries, the device does not use the partially cached result, but does a new query
with the LDAP server again.
Version 6.8
213
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The following procedure describes how to configure the device's LDAP cache in the Web
interface. For a full description of the cache parameters, see 'LDAP Parameters' on page
1003.
 To configure the LDAP cache:
1.
Open the LDAP Settings page (Configuration tab > VoIP menu > Services > LDAP
> LDAP Settings).
Figure 15-16: LDAP Settings Page - Cache Parameters
2.
Under LDAP Cache, do the following:
a.
b.
c.
3.
From the 'LDAP Cache Service' drop-down list, select Enable to enable LDAP
cache.
In the 'LDAP Cache Entry Timeout' field, enter the duration (in minutes) for which
an entry in the LDAP cache is valid.
In the 'LDAP Cache Entry Removal Timeout' field, enter the duration (in hours)
after which the device removes the LDAP entry from the cache.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
The LDAP Settings page also provides you with the following buttons:

LDAP Refresh Cache by Key: Refreshes a saved LDAP entry response in the cache
of a specified LDAP search key. If a request with the specified key exists in the cache,
the request is resent to the LDAP server.

LDAP Clear All Cache: Removes all LDAP entries in the cache.
15.3.9 Configuring Local Database for Management User
Authentication
You can configure the device to use its local database (Web Users table) to authenticate
management users based on the username-password combination. You can configure the
device to use the Web Users table upon the following scenarios:

LDAP or RADIUS server is not configured (or broken connection), or always use the
Web Users table and only if the user is not found, to use the server.

Connection with the LDAP or RADIUS server fails due to a timeout. In such a
scenario, the device can deny access or verify the user's credentials (usernamepassword) locally in the Web Users table.
If user authentication using the Web Users table succeeds, the device grants management
access to the user; otherwise access is denied. The access level assigned to the user is
also determined by the Web Users table. To configure local Web/CLI users in the Web
Users table, see Configuring Web User Accounts.
Notes:
• This feature is applicable to LDAP and RADIUS servers.
• This feature is applicable only to user management authentication.
User's Manual
214
Document #: LTRT-27034
User's Manual
15. Services
 To use the Web Users table for authenticating management users:
1.
Open the Authentication Settings page (Configuration tab > System menu >
Management > Authentication Settings).
Figure 15-17: Authentication Settings Page - Local Database for Login Authentication
2.
3.
Version 6.8
Under General Login Authentication Settings:
•
Configure when the Web Users table must be used to authenticate login users.
From the 'Use Local Users Database' drop-down list, select one of the following:
♦
When No Auth Server Defined (default): When no LDAP/RADIUS server
is configured (or as fallback if the server is inaccessible).
♦
Always: Always, but if not found, use the LDAP/RADIUS server to
authenticate the user.
•
Configure whether the Web Users table must be used to authenticate login users
upon connection timeout with the server. From the 'Behavior upon Authentication
Server Timeout' drop-down list, select one of the following:
♦
Deny Access: User is denied access to the management platform.
♦
Verify Access Locally (default): The device verifies the user's credentials
in the Web Users table.
Click Submit.
215
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
15.3.10 LDAP-based Login Authentication Example
To facilitate your understanding on LDAP entry data structure and how to configure the
device to use and obtain information from this LDAP directory, a brief configuration
example is described in this section. The example applies to LDAP-based user login
authentication and authorization (access level), and assumes that you are familiar with
other aspects of LDAP configuration (e.g., LDAP server's address).
The LDAP server's entry data structure schema in the example is as follows:

DN (base path): OU=testMgmt,OU=QA,DC=testqa,DC=local. The DN path to search
for the username in the directory is shown below:
Figure 15-18: Base Path (DN) in LDAP Server
User's Manual
216
Document #: LTRT-27034
User's Manual

15. Services
Search Attribute Filter: (sAMAccountName=$). The login username is found based
on this attribute (where the attribute's value equals the username):
Figure 15-19: Username Found using sAMAccount Attribute Search Filter

Management Attribute: memberOf. The attribute contains the member groups of the
user:
Figure 15-20: User's memberOf Attribute
Version 6.8
217
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Management Group: mySecAdmin. The group to which the user belongs, as listed
under the memberOf attribute:
Figure 15-21: User's mySecAdmin Group in memberOf Management Attribute
The configuration to match the above LDAP data structure schema is as follows:

The DN is configured in the LDAP Configuration table (see 'Configuring LDAP
Servers' on page 205):
Figure 15-22: Configuring DN

The search attribute filter based on username is configured by the 'LDAP
Authentication Filter' parameter in the LDAP Settings page (see 'Configuring the LDAP
Search Filter Attribute' on page 209):
Figure 15-23: Configuring Search Attribute Filter
User's Manual
218
Document #: LTRT-27034
User's Manual

15. Services
The group management attribute is configured by the 'Management Attribute'
parameter in the LDAP Configuration table:
Figure 15-24: Configuring Management Attribute

The management group and its corresponding access level is configured in the
Management LDAP Groups table (see 'Configuring Access Level per Management
Groups Attributes' on page 210):
Figure 15-25: Configuring Management Group Attributes for Determining Access Level
15.3.11 Active Directory-based Routing for Microsoft Lync
Typically, enterprises wishing to deploy the Microsoft® Lync™ Server are faced with a
complex, call routing dial plan when migrating users from their existing PBX or IP PBX to
the Lync Server platform. As more and more end-users migrate to the new voice system,
dialing plan management and PBX link capacity can be adversely impacted. To resolve this
issue, enterprises can employ Microsoft's Active Directory (AD), which provides a central
database to manage and maintain information regarding user’s availability, presence, and
location.
The device supports outbound IP call routing decisions based on information stored on the
AD. Based on queries sent to the AD, the device can route the call to one of the following
IP domains:

Lync client - users connected to Lync Server through the Mediation Server

PBX or IP PBX - users not yet migrated to Lync Server

Mobile - mobile number

Private - private telephone line for Lync users (in addition to the primary telephone
line)
Version 6.8
219
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
15.3.11.1
Querying the AD and Routing Priority
The device queries the AD using the initial destination number (i.e., called number). The
query can return up to four user phone numbers, each pertaining to one of the IP domains
(i.e., private number, Lync number, PBX / IP PBX number, and mobile number). The
configuration parameters listed in the table below are used to configure the query attribute
keys that defines the AD attribute that you wish to query in the AD:
Parameters for Configuring Query Attribute Key
Parameter
Query or Query Result
Example
Queried User Domain (Attribute) in AD
MSLDAPPBXNumAttribute
Name
MSLDAPOCSNumAttribute
Name
MSLDAPMobileNumAttribu
teName
PBX or IP PBX number (e.g.,
"telephoneNumber" - default)
telephoneNumber=
+3233554447
Mediation Server / Lync client number (e.g.,
"msRTCSIP-line")
msRTCSIPline=john.smith@compan
y.com
Mobile number (e.g., "mobile")
mobile=+3247647156
MSLDAPPrivateNumAttrib
uteName
Any attribute (e.g., "msRTCSIPPrivateLine")
Note: Used only if set to same value as
Primary or Secondary key.
msRTCSIP-PrivateLine=
+3233554480
MSLDAPPrimaryKey
Primary Key query search instead of PBX
key - can be any AD attribute
msRTCSIP-PrivateLine=
+3233554480
MSLDAPSecondaryKey
Secondary Key query key search if Primary
Key fails - can be any attribute
-
The process for querying the AD and subsequent routing based on the query results is as
follows:
1.
If the Primary Key is configured, it uses the defined string as a primary key instead of
the one defined in MSLDAPPBXNumAttributeName. It requests the attributes which
are described below.
2.
If the primary query is not found in the AD and the Secondary Key is configured, it
does a second query for the destination number using a second AD attribute key
name, configured by the MSLDAPSecondaryKey parameter.
3.
If none of the queries are successful, it routes the call to the original dialed destination
number according to the routing rule matching the "LDAP_ERR" destination prefix
number value, or rejects the call with a SIP 404 "Not Found" response.
4.
For each query (primary or secondary), it queries the following attributes (if
configured):
•
MSLDAPPBXNumAttributeName
•
MSLDAPOCSNumAttributeName
•
MSLDAPMobileNumAttributeName
In addition, it queries the special attribute defined in
MSLDAPPrivateNumAttributeName, only if the query key (primary or secondary) is
equal to its value.
5.
User's Manual
If the query is found: The AD returns up to four attributes - Lync, PBX / IP PBX, private
(only if it equals Primary or Secondary key), and mobile.
220
Document #: LTRT-27034
User's Manual
6.
15. Services
The device adds unique prefix keywords to the query results in order to identify the
query type (i.e., IP domain). These prefixes are used as the prefix destination number
value in the Outbound IP Routing table to denote the IP domains:
•
"PRIVATE" (PRIVATE:<private_number>): used to match a routing rule based on
query results of the private number (MSLDAPPrivateNumAttributeName)
•
"OCS" (OCS:<Lync_number>): used to match a routing rule based on query
results of the Lync client number (MSLDAPOCSNumAttributeName)
•
"PBX" (PBX:<PBX_number>): used to match a routing rule based on query
results of the PBX / IP PBX number (MSLDAPPBXNumAttributeName)
•
"MOBILE" (MOBILE:<mobile_number>): used to match a routing rule based on
query results of the mobile number (MSLDAPMobileNumAttributeName)
•
"LDAP_ERR": used to match a routing rule based on a failed query result when
no attribute is found in the AD
Note: These prefixes are involved only in the routing and manipulation processes;
they are not used as the final destination number.
7.
The device uses the Outbound IP Routing table to route the call based on the LDAP
query result. The device routes the call according to the following priority:
1.
2.
3.
4.
5.
6.
Private line: If the query is done for the private attribute and it's found, the device
routes the call according to this attribute.
Mediation Server SIP address (Lync): If the private attribute does not exist or is
not queried, the device routes the call to the Mediation Server (which then routes
the call to the Lync client).
PBX / IP PBX: If the Lync client is not found in the AD, it routes the call to the
PBX / IP PBX.
Mobile number: If the Lync client (or Mediation Server) is unavailable (e.g., SIP
response 404 "Not Found" upon INVITE sent to Lync client), and the PBX / IP
PBX is also unavailable, the device routes the call to the user's mobile number (if
exists in the AD).
Alternative route: If the call routing to all the above fails (e.g., due to unavailable
destination - call busy), the device can route the call to an alternative destination
if an alternative routing rule is configured.
"Redundant" route: If the query failed (i.e., no attribute found in the AD), the
device uses the routing rule matching the "LDAP_ERR" prefix destination number
value.
Note: For Enterprises implementing a PBX / IP PBX system, but yet to migrate to
Lync Server, if the PBX / IP PBX system is unavailable or has failed, the device uses
the AD query result for the user’s mobile phone number, routing the call through the
PSTN to the mobile destination.
Version 6.8
221
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The flowchart below summarizes the device's process for querying the AD and routing the
call based on the query results:
Figure 15-26: LDAP Query Flowchart
Note: If you are using the device's local LDAP cache, see 'Configuring the Device's
LDAP Cache' on page 212 for the LDAP query process.
User's Manual
222
Document #: LTRT-27034
User's Manual
15.3.11.2
15. Services
Configuring AD-Based Routing Rules
The following procedure describes how to configure outbound IP routing based on LDAP
queries.
 To configure LDAP-based IP routing for Lync Server:
1.
Configure the LDAP server parameters, as described in 'Configuring LDAP Servers'
on page 205.
2.
Configure the AD attribute names used in the LDAP query:
a.
Open the Advanced Parameters page (Configuration tab > VoIP menu > SIP
Definitions > Advanced Parameters).
Figure 15-27: LDAP Parameters for Microsoft Lync Server 2010
b.
3.
a.
b.
c.
d.
4.
Open the Outbound IP Routing table (Configuration tab > VoIP menu > GW and
IP to IP > Routing > Tel to IP Routing). For more information, see Configuring
Outbound IP Routing Table on page 383.
Configure query-result routing rules for each IP domain (private, PBX / IP PBX,
Lync clients, and mobile), using the LDAP keywords (case-sensitive) for the
prefix destination number:
♦
PRIVATE: Private number
♦
OCS: Lync client number
♦
PBX: PBX / IP PBX number
♦
MOBILE: Mobile number
♦
LDAP_ERR: LDAP query failure
Configure a routing rule for routing the initial Tel call to the LDAP server, using
the value "LDAP" for denoting the IP address of the LDAP server.
For alternative routing, enable the alternative routing mechanism and configure
corresponding SIP reasons for alternative routing. For this feature, alternative
routing starts from the table row located under the LDAP query row.
SBC application: Configure AD-based IP-to-IP routing rules:
a.
b.
Version 6.8
Configure the LDAP attribute names as desired.
Gateway application: Configure AD-based Tel-to-IP routing rules:
Open the IP-to-IP Routing Table page (Configuration tab > VoIP menu > SBC >
Routing SBC > IP-to-IP Routing Table). For more information, see Configuring
SBC IP-to-IP Routing Rules.
Configure query-result routing rules for each IP domain (private, PBX / IP PBX,
Lync clients, and mobile), using the LDAP keywords (case-sensitive) in the
Destination Username Prefix field:
♦
PRIVATE: Private number
♦
OCS: Lync client number
♦
PBX: PBX / IP PBX number
♦
MOBILE: Mobile number
223
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
♦
LDAP_ERR: LDAP query failure
Configure a routing rule for routing the initial call (LDAP query) to the LDAP
server, by setting the 'Destination Type' field to LDAP for denoting the IP address
of the LDAP server.
d. For alternative routing, enable the alternative routing mechanism and configure
corresponding SIP reasons for alternative routing. For this feature, alternative
routing starts from the table row located under the LDAP query row.
The table below shows an example for configuring AD-based Tel-to-IP routing rules in the
Outbound IP Routing table:
c.
AD-Based Tel-to-IP Routing Rule Configuration Examples
Index
Dest. Phone Prefix
Dest. IP Address
1
PRIVATE:
10.33.45.60
2
PBX:
10.33.45.65
3
OCS:
10.33.45.68
4
MOBILE:
10.33.45.100
5
LDAP_ERR
10.33.45.80
6
*
LDAP
7
*
10.33.45.72
The table below shows an example for configuring AD-based SBC routing rules in the IPto-IP Routing Table:
AD-Based SBC IP-to-IP Routing Rule Configuration Examples
Destination Username
Prefix
Index
Destination Type
Destination
Address
1
PRIVATE:
Dest Address
10.33.45.60
2
PBX:
Dest Address
10.33.45.65
3
OCS:
Dest Address
10.33.45.68
4
MOBILE:
Dest Address
10.33.45.100
5
LDAP_ERR
Dest Address
10.33.45.80
6
*
LDAP
7
*
Dest Address
10.33.45.72
The configured routing rule example is explained below:

Rule 1: Sends call to private telephone line (at 10.33.45.60) upon successful AD
query result for the private attribute.

Rule 2: Sends call to IP PBX (at 10.33.45.65) upon successful AD query result for the
PBX attribute.

Rule 3: Sends call to Lync client (i.e., Mediation Server at 10.33.45.68) upon
successful AD query result for the Lync attribute.

Rule 4: Sends call to user's mobile phone number (to PSTN through the device's IP
address at 10.33.45.100) upon successful AD query result for the Mobile attribute.

Rule 5: Sends call to IP address of device (10.33.45.80) if AD query failure (e.g., no
response from LDAP server or attribute not found).
User's Manual
224
Document #: LTRT-27034
User's Manual
15. Services

Rule 6: Sends query for original destination number of received call to the LDAP
server.

Rule 7: Alternative routing rule that sends the call of original dialed number to IP
destination 10.33.45.72. This rule is applied in any of the following cases
•
LDAP functionality is disabled.
•
LDAP query is successful but call fails (due to, for example, busy line) to all the
relevant attribute destinations (private, Lync, PBX, and mobile), and a relevant
Tel-to-IP Release Reason (see Alternative Routing for Tel-to-IP Calls) or SBC
Alternative Routing Reason (see Configuring SIP Response Codes for Alternative
Routing Reasons) has been configured.
Once the device receives the original incoming call, the first rule that it uses is Rule 6,
which queries the AD server. When the AD replies, the device searches the table, from the
first rule down, for the matching destination phone prefix (i.e., "PRIVATE:, "PBX:", "OCS:",
"MOBILE:", and "LDAP_ERR:"), and then sends the call to the appropriate destination.
15.3.11.3
Querying the AD for Calling Name
The device can retrieve the calling name (display name) from an LDAP-compliant server
(for example, Microsoft Active Directory / AD) for Tel-to-IP calls that are received without a
calling name.
The device uses the calling number (PBX or mobile number) for the LDAP query. Upon an
incoming INVITE, the device queries the AD based on the Calling Number search key (tries
to match the calling number with the appropriate "telephoneNumber" or "mobile" number
AD attribute entry). It then searches for the corresponding calling name attribute,
configured by the MSLDAPDisplayNameAttributeName parameter (e.g., “displayName”).
The device uses the resultant calling name as the display name parameter in the SIP From
header of the outgoing INVITE message.
To configure this feature, the following keywords are used in the Calling Name
Manipulation Table for Tel-to-IP Calls table for the 'Prefix/Suffix to Add' fields, which can be
combined with other characters:

"$LDAP-PBX": LDAP query using the MSLDAPPBXAttrName parameter as the search
key

"$LDAP-MOBILE": LDAP query using MSLDAPMobileAttrName parameter as the
search key
If the source (calling) number of the Tel-to-IP call matches the PBX / MOBILE (e.g.,
"telephoneNumber" and "mobile") number in the AD server, the device uses the resultant
Display Name instead of the keyword(s).
For example, assume the following configuration in the Calling Name Manipulation Table
for Tel-to-IP Calls:

'Source Prefix' field is set to "4".

'Prefix to Add' field is set to "$LDAP-PBX Office".
If the calling number is 4046 and the resultant LDAP query display name is "John Doe", the
device sends the INVITE message with the following From header:
From: John Doe <sip:4064@company.com>
Notes:
• The Calling Name Manipulation Table for Tel-to-IP Calls table uses the numbers
before manipulation, as inputs.
• The LDAP query uses the calling number after source number manipulation, as
the search key value.
Version 6.8
225
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
15.4
Least Cost Routing
This section provides a description of the device's least cost routing (LCR) feature and how
to configure it.
15.4.1 Overview
The LCR feature enables the device to choose the outbound IP destination routing rule
based on lowest call cost. This is useful in that it enables service providers to optimize
routing costs for customers. For example, you may wish to define different call costs for
local and international calls, or different call costs for weekends and weekdays (specifying
even the time of call). The device sends the calculated cost of the call to a Syslog server
(as Information messages), thereby enabling billing by third-party vendors.
LCR is implemented by defining Cost Groups and assigning them to routing rules in the
Outbound IP Routing table (Gateway calls) or IP-to-IP Routing table (SBC calls). The
device searches this routing table for matching routing rules, and then selects the rule with
the lowest call cost. If two routing rules have identical costs, then the rule appearing higher
up in the table is used (i.e., first-matched rule). If a selected route is unavailable, the device
selects the next least-cost routing rule. However, even if a matched rule is not assigned a
Cost Group, the device can select it as the preferred route over other matched rules with
Cost Groups. This is determined according to the settings of the Default Cost parameter in
the Routing Rule Groups table.
The Cost Group defines a fixed connection cost (connection cost) and a charge per minute
(minute cost). Cost Groups can also be configured with time segments (time bands), which
define connection cost and minute cost based on specific days of the week and time of day
(e.g., from Saturday through Sunday, between 6:00 and 18:00). If multiple time bands are
configured per Cost Group and a call spans multiple time bands, the call cost is calculated
using only the time band in which the call was initially established.
In addition to Cost Groups, the device can calculate the call cost using an optional, userdefined average call duration value. The logic in using this option is that a Cost Group may
be cheap if the call duration is short, but due to its high minute cost, may prove very
expensive if the duration is lengthy. Thus, together with Cost Groups, the device can use
this option to determine least cost routing. The device calculates the Cost Group call cost
as follows: Total Call Cost = Connection Cost + (Minute Cost * Average Call Duration).
The below table shows an example of call cost when taking into consideration call duration.
This example shows four defined Cost Groups and the total call cost if the average call
duration is 10 minutes:
Table 15-6: Call Cost Comparison between Cost Groups for different Call Durations
Total Call Cost per Duration
Connection
Cost
Minute Cost
A
1
B
Cost Group
1 Minute
10 Minutes
6
7
61
0
10
10
100
C
0.3
8
8.3
80.3
D
6
1
7
16
If four matching routing rules are located in the routing table and each one is assigned a
different Cost Group as listed in the table above, then the rule assigned Cost Group "D" is
selected. Note that for one minute, Cost Groups "A" and "D" are identical, but due to the
average call duration, Cost Group "D" is cheaper. Therefore, average call duration is an
important factor in determining the cheapest routing role.
Below are a few examples of how you can implement LCR:
User's Manual
226
Document #: LTRT-27034
User's Manual

15. Services
Example 1: This example uses two different Cost Groups for routing local calls and
international calls:
Two Cost Groups are configured as shown below:
Cost Group
Connection Cost
Minute Cost
1. "Local Calls"
2
1
2. "International Calls"
6
3
The Cost Groups are assigned to routing rules for local and international calls:
Routing Index
Dest Phone Prefix
Destination IP
Cost Group ID
1
2000
x.x.x.x
1 "Local Calls"
2
00
x.x.x.x
2 "International Calls"

Example 2: This example shows how the device determines the cheapest routing rule
in the Outbound IP Routing table:
The Default Cost parameter (global) in the Routing Rule Groups table is set to Min,
meaning that if the device locates other matching LCR routing rules (with Cost Groups
assigned), the routing rule without a Cost Group is considered the lowest cost route.
•
The following Cost Groups are configured:
Cost Group
Connection Cost
Minute Cost
1. "A"
2
1
2. "B"
6
3
•
Routing Index
The Cost Groups are assigned to routing rules:
Dest Phone Prefix
Destination IP
Cost Group
1
201
x.x.x.x
"A'
2
201
x.x.x.x
"B"
3
201
x.x.x.x
0
4
201
x.x.x.x
"B"
The device calculates the optimal route in the following index order: 3, 1, 2, and then
4, due to the following logic:
Version 6.8
•
Index 1 - Cost Group "A" has the lowest connection cost and minute cost
•
Index 2 - Cost Group "B" takes precedence over Index 4 entry based on the firstmatched method rule
•
Index 3 - no Cost Group is assigned, but as the Default Cost parameter is set to
Min, it is selected as the cheapest route
•
Index 4 - Cost Group "B" is only second-matched rule (Index 1 is the first)
227
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Example 3: This example shows how the cost of a call is calculated if the call spans
over multiple time bands:
Assume a Cost Group, "CG Local" is configured with two time bands, as shown below:
Cost Group
CG Local
Time Band
Start Time
End Time
Connection
Cost
Minute Cost
TB1
16:00
17:00
2
1
TB2
17:00
18:00
7
2
Assume that the call duration is 10 minutes, occurring between 16:55 and 17:05. In
other words, the first 5 minutes occurs in time band "TB1" and the next 5 minutes
occurs in "TB2", as shown below:
Figure 15-28: LCR using Multiple Time Bands (Example)
The device calculates the call using the time band in which the call was initially
established, regardless of whether the call spans over additional time bands:
Total call cost = "TB1" Connection Cost + ("TB1" Minute Cost x call duration) = 2 + 1
x 10 min = 12
15.4.2 Configuring LCR
The following main steps need to be done to configure LCR:
1.
Enable the LCR feature and configure the average call duration and default call
connection cost - see ''Enabling LCR and Configuring Default LCR'' on page 228.
2.
Configure Cost Groups - see ''Configuring Cost Groups'' on page 230.
3.
Configure Time Bands for a Cost Group - see ''Configuring Time Bands for Cost
Groups'' on page 231.
4.
Assign Cost Groups to outbound IP routing rules - see ''Assigning Cost Groups to
Routing Rules'' on page 232.
15.4.2.1 Enabling the LCR Feature
The Routing Rule Groups table lets you enable the LCR feature. This also includes
configuring the average call duration and default call cost for routing rules that are not
assigned Cost Groups in the Outbound IP Routing table.
The following procedure describes how to enable LCR in the Web interface. You can also
do this using the table ini file parameter, RoutingRuleGroups or CLI command, configure
voip > services least-cost-routing routing-rule-groups.
User's Manual
228
Document #: LTRT-27034
User's Manual
15. Services
 To enable LCR:
1.
Open the Routing Rule Groups Table page (Configuration tab > VoIP menu >
Services > Least Cost Routing > Routing Rule Groups Table).
2.
Click Add; the following dialog box appears:
Figure 15-29: Routing Rule Groups Table - Add Record
3.
Enable LCR according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 15-7: Routing Rule Groups Table Parameter Descriptions
Parameter
Description
Index
[RoutingRuleGroups_Index]
Defines an index number for the new table record.
Note: Only one index entry can be configured.
LCR Enable
CLI: lcr-enable
[RoutingRuleGroups_LCREnable]
Enables the LCR feature:
 [0] Disabled (default)
 [1] Enabled
LCR Call Length
CLI: lcr-call-length
[RoutingRuleGroups_LCRAverage
CallLength]
Defines the average call duration (in minutes) and is used to
calculate the variable portion of the call cost. This is useful, for
example, when the average call duration spans over multiple
time bands. The LCR is calculated as follows: cost = call
connect cost + (minute cost * average call duration)
The valid value range is 0-65533. The default is 1.
For example, assume the following Cost Groups:
 "Weekend A": call connection cost is 1 and charge per
minute is 6. Therefore, a call of 1 minute cost 7 units.
 "Weekend_ B": call connection cost is 6 and charge per
minute is 1. Therefore, a call of 1 minute cost 7 units.
Therefore, for calls under one minute, "Weekend A" carries
the lower cost. However, if the average call duration is more
than one minute, then "Weekend B" carries the lower cost.
Default Cost
CLI: lcr-default-cost
[RoutingRuleGroups_LCRDefault
Cost]
Determines whether routing rules in the Outbound IP Routing
table without an assigned Cost Group are considered a higher
cost or lower cost route compared to other matched routing
rules that are assigned Cost Groups.
 [0] Lowest Cost = If the device locates other matching LCR
routing rules, this routing rule is considered the lowest cost
route and therefore, it is selected as the route to use
(default.)
 [1] Highest Cost = If the device locates other matching
LCR routing rules, this routing rule is considered as the
Version 6.8
229
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
highest cost route and therefore, is not used or used only if
the other cheaper routes are unavailable.
Note: If more than one valid routing rule without a defined
Cost Group exists, the device selects the first-matched rule.
15.4.2.2 Configuring Cost Groups
The Cost Group table lets you configure Cost Groups. A Cost Group defines a fixed call
connection cost and a call rate (charge per minute). Once configured, you can configure
Time Bands per Cost Group. Up to 10 Cost Groups can be configured.
The following procedure describes how to configure Cost Groups in the Web interface. You
can also configure this using the table ini file parameter, CostGroupTable or CLI command,
configure voip > services least-cost-routing cost-group.
 To configure a Cost Group:
1.
Open the Cost Group Table page (Configuration tab > VoIP menu > Services >
Least Cost Routing > Cost Group Table).
2.
Click Add; the following dialog box appears:
3.
Configure a Cost Group according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 15-8: Cost Group Table Parameter Descriptions
Parameter
Description
Index
[CostGroupTable_Index]
Defines an index number for the new table record.
Note: Each table row must be configured with a
unique index.
Cost Group Name
CLI: cost-group-name
[CostGroupTable_CostGroupName]
Defines an arbitrary name for the Cost Group.
The valid value is a string of up to 30 characters.
Note: Each Cost Group must have a unique name.
Default Connection Cost
Defines the call connection cost (added as a fixed
CLI:default-connection-cost
charge to the call) for a call outside the time bands.
[CostGroupTable_DefaultConnectionCost] The valid value range is 0-65533. The default is 0.
Note: When calculating the cost of a call, if the
current time of the call is not within a time band
configured for the Cost Group, then this default
connection cost is used.
User's Manual
230
Document #: LTRT-27034
User's Manual
15. Services
Parameter
Description
Default Minute Cost
CLI: default-minute-cost
[CostGroupTable_DefaultMinuteCost]
Defines the call charge per minute for a call outside
the time bands.
The valid value range is 0-65533. The default is 0.
Note: When calculating the cost of a call, if the
current time of the call is not within a time band
configured for the Cost Group, then this default
charge per minute is used.
15.4.2.3 Configuring Time Bands for Cost Groups
The Time Band table lets you configure Time Bands per Cost Group. A Time Band defines
a day and time range (e.g., from Saturday 05:00 to Sunday 24:00), as well as the fixed call
connection charge and call rate per minute for this interval. You can configure up to 70
Time Bands, where up to 21 Time Bands can be assigned to each Cost Group.
Note: You cannot configure overlapping Time Bands.
The following procedure describes how to configure Time Bands per Cost Group in the
Web interface. You can also configure this using the table ini file parameter,
CostGroupTimebands or CLI command, configure voip >services least-cost-routing costgroup-time-bands.
 To configure a Time Band per Cost Group:
1.
Open the Cost Group Table page (Configuration tab > VoIP menu > Services >
Least Cost Routing > Cost Group Table).
2.
Select a Cost Group for which you want to assign Time Bands, and then click the
Time Band link located below the table; the Time Band table for the selected Cost
Group appears.
3.
Click Add; the following dialog box appears:
4.
Configure a Time Band according to the parameters described in the table below.
5.
Click Submit, and then save ("burn") your settings to flash memory.
Table 15-9: Time Band Table Description
Parameter
Index
CLI: timeband-index
Version 6.8
Description
Defines an index number for the new table record.
Note: Each table row must be configured with a unique
231
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
[CostGroupTimebands_TimebandIndex]
index.
Start Time
CLI: start-time
[CostGroupTimebands_StartTime]
Defines the day and time of day from when this time
band is applicable. The format is DDD:hh:mm, where:
 DDD is the day of the week, represented by the first
three letters of the day in upper case (i.e., SUN,
MON, TUE, WED, THU, FRI, or SAT).
 hh and mm denote the time of day, where hh is the
hour (00-23) and mm the minutes (00-59)
For example, SAT:22:00 denotes Saturday at 10 pm.
End Time
CLI: end-time
[CostGroupTimebands_EndTime]
Defines the day and time of day until when this time
band is applicable. For a description of the valid values,
see the parameter above.
Connection Cost
Defines the call connection cost during this time band.
CLI: connection-cost
This is added as a fixed charge to the call.
[CostGroupTimebands_ConnectionCost] The valid value range is 0-65533. The default is 0.
Note: The entered value must be a whole number (i.e.,
not a decimal).
Minute Cost
CLI: minute-cost
[CostGroupTimebands_MinuteCost]
Defines the call cost per minute charge during this
timeband.
The valid value range is 0-65533. The default is 0.
Note: The entered value must be a whole number (i.e.,
not a decimal).
15.4.2.4 Assigning Cost Groups to Routing Rules
To use your configured Cost Groups, you need to assign them to routing rules:

Gateway application: Outbound IP Routing table - see Configuring Outbound IP
Routing Table on page 383

SBC application: IP-to-IP Routing table - see Configuring SBC IP-to-IP Routing Rules
on page 530
User's Manual
232
Document #: LTRT-27034
User's Manual
15.5
15. Services
Configuring Call Setup Rules
The Call Setup Rules table lets you configure up to 40 Call Setup rules. Call Setup rules
define various sequences that are run upon the receipt of an incoming call (dialog) at call
setup, before the device routes the call to its destination. Call Setup rules can be
configured for any call direction (SBC, Tel-to-IP, or IP-to-Tel). Call Setup rules provides you
with full flexibility in implementing simple or complex script-like rules that can be used for
Lightweight Directory Access Protocol (LDAP) based routing as well as other advanced
routing logic requirements such as manipulation. These Call Setup rules are assigned to
routing rules.
Below is a summary of functions for which you can employ Call Setup rules:

LDAP query rules: LDAP is used by the device to query Microsoft’s Active Directory
(AD) server for specific user details for routing, for example, office extension number,
mobile number, private number, OCS (Lync) address, and display name. Call Setup
rules provides full flexibility in AD-lookup configuration to suite just about any customer
deployment requirement:
•
Routing based on query results.
•
Queries based on any AD attribute.
•
Queries based on any attribute value (alphanumeric), including the use of the
asterisk (*) wildcard as well as the source number, destination number, redirect
number, and SBC SIP messages. For example, the following Call Setup rule
queries the attribute "proxyAddresses" for the record value "WOW:" followed by
source number: "proxyAddresses=WOW:12345*"
•
Conditional LDAP queries, for example, where the query is based on two
attributes (&(telephoneNumber=4064)(company=ABC).
•
Conditions for checking LDAP query results.
•
Manipulation of call parameters such as source number, destination number, and
redirect number and SBC SIP messages, while using LDAP query results.
•
Multiple LDAP queries.

Manipulation (similar to the Message Manipulations table) of call parameters (such as
source number, destination number, and redirect number) and SBC SIP messages.

Conditions for routing, for example, if the source number equals a specific value, then
use the call routing rule.
You configure Call Setup rules with a Set ID, similar to the Message Manipulations table,
where multiple rules can be associated with the same Set ID. This lets you perform multiple
Call Setup rules on the same call setup dialog.
To use your Call Setup rule(s), you need to assign the Call Setup Rules Set ID to the
relevant routing rule. This is done using the 'Call Setup Rules Set ID' field in the routing
table:

SBC IP-to-IP routing - see Configuring SBC IP-to-IP Routing Rules on page 530

Tel-to-IP routing rules - see Configuring Outbound IP Routing Table on page 383

IP-to-Tel routing rules - see ''Configuring Inbound IP Routing Table'' on page 392
If an incoming call matches the characteristics of a routing rule, the device first runs the
assigned Call Setup Rules Set ID. The device uses the routing rule to route the call,
depending on the result of the Call Setup Rules Set ID:

Version 6.8
Rule's condition is met: The device performs the rule's action and then runs the next
rule in the Set ID until the last rule or until a rule with an Exit Action Type. If the Exit
rule is configured with a "True" Action Value, the device uses the current routing rule.
If the Exit rule is configured with a "False" Action Value, the device moves to the next
routing rule. If an Exit Action Type is not configured and the device has run all the
rules in the Set ID, the default Action Value of the Set ID is "True" (i.e., use the current
233
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
routing rule).

Rule's condition is not met: The device runs the next rule in the Set ID. When the
device reaches the end of the Set ID and no Exit was performed, the Set ID ends with
a "True" result.
Note: If the source and/or destination numbers are manipulated by the Call Setup
rules, they revert to their original values if the device moves to the next routing rule.
The following procedure describes how to configure Call Setup Rules in the Web interface.
You can also configure Call Setup Rules using the table ini file parameter, CallSetupRules
or CLI command, configure voip/services call-setup-rules.
 To configure a Call Setup rule:
1.
Open the Call Setup Rules table (Configuration tab > VoIP menu > Services > Call
Setup Rules).
2.
Click Add; the following dialog box appears:
Figure 15-30: Call Setup Rules Table - Add Record
3.
Configure a Call Setup rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 15-10: Call Setup Rules Parameter Descriptions
Parameter
Description
Index
[CallSetupRules_Index]
Defines an index number for the new table record.
Note: Each rule must be configured with a unique index.
Rules Set ID
CLI: rules-set-id
[CallSetupRules_RulesSetID]
Defines a Set ID for the rule. You can define the same Set
ID for multiple rules to create a group of rules. You can
configure up to 10 Set IDs, where each Set ID can include
up to 10 rules.The Set ID is used to assign the Call Setup
rules to a routing rule in the routing table.
The valid value is 0 to 9. The default is 0.
User's Manual
234
Document #: LTRT-27034
User's Manual
15. Services
Parameter
Description
Attributes To Query
Defines the query string that the device sends to the LDAP
CLI: attr-to-query
server.
[CallSetupRules_AttributesToQuery] The valid value is a string of up to 100 characters.
Combined strings and values can be configured like in the
Message Manipulations table, using the '+' operator. Single
quotes (') can be used for specifying a constant string (e.g.,
'12345').
For example:
 'mobile=' + param.call.dst.user (searches for the AD
attribute, "mobile" that has the value of the destination
user part of the incoming call)
 'telephoneNumber=' + param.call.redirect + '*' (searches
for the AD attribute, "telephoneNumber" that has a
redirect number)
Attributes To Get
CLI: attr-to-get
[CallSetupRules_AttributesToGet]
Defines the attributes of the queried LDAP record that the
device must handle (e.g., retrieve value).
The valid value is a string of up to 100 characters. Up to five
attributes can be defined, each separated by a comma (e.g.,
msRTCSIP-PrivateLine,msRTCSIP-Line,mobile).
Note: The device saves the retrieved attributes' values for
future use in other rules, until the next LDAP query or until
the call is connected. Thus, the device does not need to requery the same attributes.
Row Role
CLI: row-role
[CallSetupRules_RowRole]
Determines which condition must be met in order for this
rule to be performed.
 [0] Use Current Condition = The Condition configured for
this rule must be matched in order to perform the
configured action (default).
 [1] Use Previous Condition = The Condition configured
for the rule located directly above this rule in the Call
Setup table must be matched in order to perform the
configured action. This option lets you configure multiple
actions for the same Condition.
Condition
CLI: condition
[CallSetupRules_Condition]
Defines the condition that must exist for the device to
perform the action.
The valid value is a string of up to 200 characters (caseinsensitive). Regular Expression (regex) can also be used,
for example:
 ldap.attr.mobile exists (attribute "mobile" exists in AD)
 param.call.dst.user == ldap.attr.msRTCSIP-PrivateLine
(called number is the same as the number in the attribute
"msRTCSIP-PrivateLine")
 ldap.found !exists (LDAP record not found)
 ldap.err exists (LDAP error exists)
Version 6.8
235
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Action Subject
CLI: action-subject
[CallSetupRules_ActionSubject]
Defines the element (header, parameter, or body) upon
which you want to perform the action.
The valid value is a string of up to 100 characters (caseinsensitive).
Examples:
 header.from contains '1234' (SBC calls only)
 param.call.dst.user (called number)
 param.call.src.user (calling number)
 param.call.src.name (calling name)
 param.call.redirect (redirect number)
 param.call.src.host (source host)
 param.call.dst.host (destination host)
Action Type
CLI: action-type
[CallSetupRules_ActionType]
Defines the type of action to perform.
 [0] Add (default) = Adds new message header,
parameter or body elements.
 [1] Remove = Removes message header, parameter, or
body elements.
 [2] Modify = Sets element to the new value (all element
types).
 [3] Add Prefix = Adds value at the beginning of the string
(string element only).
 [4] Add Suffix = Adds value at the end of the string
(string element only).
 [5] Remove Suffix = Removes value from the end of the
string (string element only).
 [6] Remove Prefix = Removes value from the beginning
of the string (string element only).
 [20] Exit = Stops the Rule Set ID and returns a result
("True" or "False").
 [21 Run Rules Set = Performs a different Rule Set ID,
specified in the 'Action Value' parameter (below).
Action Value
CLI: action-value
[CallSetupRules_ActionValue]
Defines a value that you want to use in the action.
The valid value is a string of up to 300 characters (caseinsensitive).
Examples:
 '+9723976'+ldap.attr.alternateNumber
 '9764000'
 ldap.attr.displayName
 true (if the 'Action Type' is set to Exit)
 false (if the 'Action Type' is set to Exit)
User's Manual
236
Document #: LTRT-27034
User's Manual
15. Services
15.5.1 Call Setup Rule Examples
Below are configuration examples for using Call Setup Rules.


Example 1: This example configures the device to replace (manipulate) the incoming
call's source number with a number retrieved from the AD by an LDAP query. The
device queries the AD server for the attribute record, "telephoneNumber" whose value
is the same as the received source number (e.g., "telephoneNumber =4064"). If such
an attribute is found, the device retrieves the number of the attribute record,
"alternateNumber" and uses this number as the source number.
•
Call Setup Rules table configuration:
♦
'Rules Set ID': 1
♦
'Attributes to Query': ‘telephoneNumber=’ + param.call.src.user
♦
'Attributes to Get': alternateNumber
♦
'Row Role': Use Current Condition
♦
'Condition': ldap.attr. alternateNumber exists
♦
'Action Subject': param.call.src.user
♦
'Action Type': Modify
♦
'Action Value': ldap.attr. alternateNumber
•
Routing table configuration: A single routing rule is assigned the Call Setup
Rule Set ID.
♦
Index 1:
 'Call Setup Rules Set Id': 1
Example 2: This example configures the device to replace (manipulate) the incoming
call's calling name (caller ID) with a name retrieved from the AD by an LDAP query.
The device queries the AD server for the attribute record, "telephoneNumber" whose
value is the same as the received source number (e.g., "telephoneNumber =5098"). If
such an attribute is found, the device retrieves the name from the attribute record,
"displayName" and uses this as the calling name in the incoming call.
•
Call Setup Rules table configuration:
'Rules Set ID': 2
♦
'Attributes to Query': ‘telephoneNumber=’ + param.call.src.user
♦
'Attributes to Get': displayName
♦
'Row Role': Use Current Condition
♦
'Condition': ldap.attr. displayName exists
♦
'Action Subject': param.call.src.name
♦
'Action Type': Modify
♦
'Action Value': ldap.attr. displayName
♦
•
Version 6.8
Routing table configuration: A single routing rule is assigned the Call Setup
Rule Set ID.
♦
Index 1:
 'Call Setup Rules Set Id': 2
237
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

User's Manual
Example 3: This example configures the device to route the incoming call according
to whether or not the source number of the incoming call also exists in the AD server.
The device queries the AD server for the attribute record, "telephoneNumber" whose
value is the same as the received source number (e.g., telephoneNumber=4064"). If
such an attribute is found, the device sends the call to the Lync server; if the query
fails, the device sends the call to the PBX.
•
Call Setup Rules table configuration:
♦
'Rules Set ID': 3
♦
'Attributes to Query': ‘telephoneNumber=’ + param.call.src.user
♦
'Attributes to Get': telephoneNumber
♦
'Row Role': Use Current Condition
♦
'Condition': ldap.found !exists
♦
'Action Subject': ♦
'Action Type': Exit
♦
'Action Value': false
If the attribute record is found (i.e., condition is not met), the rule ends with a
default exit result of true and uses the first routing rule (Lync). If the attribute
record does not exist (i.e., condition is met), the rule exits with a false result and
uses the second routing rule (PBX).
•
Routing table configuration: Two routing rules are assigned with the same
matching characteristics. Only the main routing rule is assigned a Call Setup
Rules Set ID.
♦
Index 1:
 'Call Setup Rules Set Id': 3
 'Destination IP Group ID': 3 (IP Group for Lync)
♦
Index 2:
 'Destination IP Group ID': 4 (IP Group of PBX)
238
Document #: LTRT-27034
User's Manual
16
16. Quality of Experience
Quality of Experience
This chapter describes how to configure the Quality of Experience feature.
16.1
Reporting Voice Quality of Experience to SEM
The device can be configured to report voice (media) Quality of Experience (QoE) to
AudioCodes' Session Experience Manager (SEM) server, a plug-in for AudioCodes EMS.
The reports include real-time metrics of the quality of the actual call experience, which are
then processed by the SEM.
SEM is a VoIP-quality monitoring and analysis tool. SEM provides comprehensive details
on voice traffic quality, allowing system administrators to quickly identify, fix and prevent
issues that could affect the voice calling experience in enterprise and service provider VoIP
networks. IT managers and administrators can employ SEM in their VoIP networks to
guarantee effective utilization, smooth performance, reliable QoS levels, and SLA
fulfillment.
Note: For information on the SEM server, refer to the EMS User's Manual.
16.1.1 Configuring the SEM Server
The device can be configured to report QoE voice metrics to a single SEM server or to two
SEM/EMS servers deployed in a Geographic Redundancy, High-Availability (HA) mode.
Geographic Redundancy is when each SEM/EMS server is located in a different network
subnet and has its own IP address. Thus, for the device to report QoE to both servers, you
need to configure the IP address of each server.
For regular HA mode, when both EMS/SEM servers are located in the same subnet, a
single EMS/SEM server (global, virtual) IP address is used for all network components
(EMS clients and managed devices). Thus, in such a setup, you need to configure only this
IP address.
 To configure the SEM server to where the device sends voice metrics:
1.
Open the Session Experience Manager Server page (Configuration tab > VoIP menu
> Quality of Experience > Session Experience Manager Server).
Figure 16-1: Session Experience Manager Server Page
2.
In the 'Server IP' field, enter the primary SEM server's IP address.
3.
If Geographical-Redundancy HA mode exists, in the 'Redundant Server IP' field, enter
the secondary SEM server's IP address.
4.
In the 'Port' field, enter the port number for the SEM server.
5.
In the 'Interface Name' field, enter the device's IP network interface on which the
device sends the reports to the SEM server.
6.
Click Submit, and then save ("burn") your settings to flash memory.
Version 6.8
239
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
16.1.2 Configuring Clock Synchronization between Device and SEM
To ensure accurate call quality statistics and analysis by the SEM server, you must
configure the device and the SEM server with the same clock source for clock
synchronization. In other words, you need to configure them with the same NTP server.
The NTP server can be one of the following:

AudioCodes EMS server (also acting as an NTP server)

Third-party, external NTP server
Once you have determined the NTP server, all the elements--device, SEM, and EMS--must
be configured with the same NTP server address.
To configure, the NTP server's address on the device, see Configuring Automatic Date and
Time using SNTP on page 103.
16.1.3 Enabling RTCP XR Reporting to SEM
In order for the device to be able to send voice metric reports to the SEM, you need to
enable the RTP Control Protocol Extended Reports (RTCP XR) VoIP management
protocol. RTCP XR defines a set of voice metrics that contain information for assessing
VoIP call quality and diagnosing problems. Enabling RTCP XR means that the device can
send RTCP XR messages, containing the call-quality metrics, to the SEM server.
For enabling RTCP XR reporting, see Configuring RTCP XR on page 653. For determining
what to report to the SEM, see Configuring Quality of Experience Profiles on page 240.
16.2
Configuring Quality of Experience Profiles
The Quality of Experience feature lets you monitor the quality of voice calls traversing the
device in your network. Voice-metric monitoring profiles (Quality of Experience Profiles)
can be configured and applied to specific network links, including IP Groups (see
''Configuring IP Groups'' on page 261), Media Realms (see ''Configuring Media Realms'' on
page 251), and Remote Media Subnets (see ''Configuring Remote Media Subnets'' on
page 254). The monitored voice metrics include the following:

Mean Opinion Score (MOS): MOS is the average grade on a quality scale,
expressed as a single number in the range of 1 to 5, where 1 is the lowest audio
quality and 5 the highest audio quality.

Delay (or latency): Time it takes for information to travel from source to destination
(round-trip time).

Packet Loss: Lost packets are RTP packets that are not received by the voice
endpoint. Packet loss can result in choppy voice transmission.

Jitter: Jitter can result from uneven delays between received voice packets. To space
evenly, the device's jitter buffer adds delay. The higher the measurement, the greater
the impact of the jitter buffer's delay on audio quality.

Residual Echo Return Loss (RERL): An echo is a reflection of sound arriving at the
listener at some time after the sound was initiated (often by the listener). Echo is
typically caused by delay.
At any given time during a call, a voice metric can be in one of the following color-coded
quality states:

Green: Indicates good call quality

Yellow: Indicates medium call quality

Red: Indicates poor call quality
User's Manual
240
Document #: LTRT-27034
User's Manual
16. Quality of Experience
Quality of Experience Profiles lets you define quality thresholds per monitored voice metric.
These are based on the following color-coded quality thresholds:

Green-Yellow threshold: Lower threshold that indicates changes from Green to
Yellow or vice versa when the threshold is crossed.

Yellow-Red threshold: Higher threshold that indicates changes from Yellow to Red
or vice versa when the threshold is crossed.
Hysteresis is also used to configure the threshold. This defines the amount of fluctuation
from a threshold in order for the threshold to be considered as crossed (i.e., change in
color state). Hysteresis is used to avoid false reports being sent by the device.
Each time a configured voice metric threshold is crossed (i.e., color changes), the device
can do the following, depending on configuration:

Report the change in the measured metrics to AudioCodes' Session Experience
Manager (SEM) server. The SEM displays this call quality status for the associated
SEM link (IP Group, Media Realm, or Remote Media Subnet). For configuring the
SEM server's address, see ''Configuring SEM Server'' on page 239.

Determine access control and media enhancements based on measured metrics.
Depending on the crossed threshold type, you can configure the device to accept or
reject calls, or use an alternative IP Profile for the IP Group to which the call belongs.
For more information, see ''Configuring Media Enhancement Profiles'' on page 247.

Alternative routing based on measured metrics. If a call is rejected because of a
crossed threshold, the device generates a SIP 806 response. You can configure this
SIP response code as a reason for alternative routing (see ''Configuring SIP
Response Codes for Alternative Routing Reasons'' on page 538).
Note: For your convenience, the device provides pre-configured Quality of
Experience Profiles. One of these pre-configured profiles is the default Quality of
Experience Profile. Therefore, if you do not configure a Quality of Experience Profile,
this default is used.
The following procedure describes how to configure Quality of Experience Profiles in the
Web interface. You can also configure Quality of Experience Profiles using other
management platforms:

Quality of Experience Profile table: Table ini file parameter, QoEProfile or CLI
command, configure voip/qoe qoe-profile

Quality of Experience Color Rules table: Table ini file parameter, QOEColorRules
or CLI command, configure voip/qoe qoe-profile qoe-color-rules
 To configure a QoE Profile:
1.
Open the Quality of Experience Profile page (Configuration tab > VoIP menu >
Quality of Experience > Quality of Experience Profile).
2.
Click Add; the following dialog box appears:
Figure 16-2: Quality of Experience Profile - Add Record
Version 6.8
241
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Configure a QoE Profile according to the parameters described in the table below.
4.
Click Submit.
Table 16-1: Quality of Experience Profile Table Parameter Descriptions
Parameter
Description
Index
[QOEProfile_Index]
Defines an index number for the new table record.
Profile Name
CLI: name
[QOEProfile_Name]
Defines an arbitrary name to easily identify the QoE Profile.
The valid value is a string of up to 20 characters.
Sensitivity Level
CLI: sensitivity-level
[QOEProfile_SensitivityLevel]
Defines the pre-configured threshold profile to use.
 [0] User Defined = Need to define thresholds per monitored
parameter in the Quality of Experience Color Rules table.
 [1] Low = Pre-configured low sensitivity thresholds.
 [2] Medium = Pre-configured medium sensitivity thresholds.
 [3] High = Pre-configured high sensitivity thresholds.
Reporting is done for small fluctuations in parameter values.
5.
In the Quality of Experience Profile page, select the QoE Profile index row for which
you want to configure QoE thresholds, and then click the Quality of Experience
Color Rules link located below the table; the Quality of Experience Color Rules page
appears.
6.
Click Add; the following dialog box appears:
Figure 16-3: Quality of Experience Page - Add Record Dialog Box
The figure above shows a configuration example where if the MOS value changes by
0.1 (hysteresis) to 3.3 or 3.5, the Green-Yellow threshold is crossed. The device
considers a change to 3.3 as a Yellow state (i.e., medium quality) and a change to 3.5
as a Green state.
7.
Configure a QoE Color rule according to the parameters described in the table below.
8.
Click Submit, and then save ("burn") your settings to flash memory.
Table 16-2: Quality of Experience Color Rules Table Parameter Descriptions
Parameter
Index
CLI: index
[QOEColorRules_ColorRuleIndex]
User's Manual
Description
Defines an index number for the new table record.
242
Document #: LTRT-27034
User's Manual
16. Quality of Experience
Parameter
Monitored Parameter
CLI: monitored-parameter
[QOEColorRules_monitoredParam]
Description
Defines the parameter to monitor and report.
[0] MOS (default)
[1] Delay
[2] Packet Loss
[3] Jitter
[4] RERL [Echo]





Direction
CLI: direction
[QOEColorRules_direction]
Defines the monitoring direction.
 [0] Device Side (default)
 [1] Remote Side
Sensitivity Level
CLI: sensitivity-level
[QOEColorRules_profile]
Defines the sensitivity level of the thresholds.
 [0] User Defined = Need to define the thresholds in
the parameters described below.
 [1] Low = Pre-configured low sensitivity threshold
values. Thus, reporting is done only if changes in
parameters' values is significant.
 [2] Medium = (Default) Pre-configured medium
sensitivity threshold values.
 [3] High = Pre-configured high sensitivity threshold
values. Thus, reporting is done for small
fluctuations in parameter values.
Green Yellow Threshold
CLI: green-yellow-threshold
[QOEColorRules_GreenYellowThreshold]
Defines the parameter threshold values between
Green (good quality) and Yellow (medium quality)
states.
The valid threshold values are as follows:
 MOS values are in multiples of 10. For example, to
denote a MOS of 3.2, the value 32 (i.e., 3.2*10)
must be entered.
 Delay values are in msec.
 Packet Loss values are in percentage (%).
 Jitter is in msec.
 Echo measures the Residual Echo Return Loss
(RERL) in dB.
Green Yellow Hysteresis
Defines the fluctuation (change) from the value
CLI: green-yellow-hysteresis
configured for the Green-Yellow threshold. When the
[QOEColorRules_GreenYellowHysteresis] threshold is exceeded by this hysteresis, the device
sends a report to the SEM indicating this change.
Note: If the monitored parameter crosses two
thresholds at once (e.g., from Green to Red), the
device ignores the hysteresis value and reports the
call state change to the SEM.
Version 6.8
243
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Yellow Red Threshold
CLI: yellow-red-threshold
[QOEColorRules_YellowRedThreshold]
Defines the parameter threshold values between
Yellow (medium quality) and Red (poor quality) states.
The valid threshold values are as follows:
 MOS values are in multiples of 10. For example, to
denote a MOS of 3.2, the value 32 (i.e., 3.2*10)
must be entered.
 Delay values are in msec.
 Packet Loss values are in percentage (%).
 Jitter is in msec.
 Echo measures the Residual Echo Return Loss
(RERL) in dB.
Yellow Red Hysteresis
CLI: yellow-red-hysteresis
[QOEColorRules_YellowRedHysteresis]
Defines the fluctuation (change) from the value
configured for the Yellow-Red threshold. When the
threshold is exceeded by this hysteresis value, the
device sends a report to the SEM indicating this
change.
Note: If the monitored parameter crosses two
thresholds at once (e.g., from Green to Red), the
device ignores the hysteresis value and reports the
call state change to the SEM.
16.3
Configuring Bandwidth Profiles
Bandwidth Profiles enhance the device's monitoring of bandwidth utilization. A Bandwidth
Profile defines bandwidth utilization thresholds for audio and/or video traffic (incoming and
outgoing). Bandwidth Profiles can be assigned to IP Groups (see ''Configuring IP Groups''
on page 261), Media Realms (see ''Configuring Media Realms'' on page 251), and Remote
Media Subnets (see ''Configuring Remote Media Subnets'' on page 254).
Each time a configured bandwidth threshold is crossed, the device can do the following,
depending on configuration:

Determine access control and media enhancements based on bandwidth utilization.
Depending on the crossed threshold type, you can configure the device to accept or
reject calls, or use an alternative IP Profile for the IP Group to which the call belongs.
For more information, see ''Configuring Media Enhancement Profiles'' on page 247.

Alternative routing based on bandwidth utilization. If a call is rejected because of a
crossed threshold, the device generates a SIP 806 response. You can configure this
SIP response code as a reason for alternative routing (see ''Configuring SIP
Response Codes for Alternative Routing Reasons'' on page 538).

Send an SNMP alarm (acMediaRealmBWThresholdAlarm). The device clears the
alarm when bandwidth utilization returns to normal (within the thresholds).
The thresholds of Bandwidth Profiles use the same color-coding as the Quality of
Experience Profile:

Green-Yellow threshold: Lower threshold that indicates that the bandwidth exceeded
a user-defined percentage of the configured threshold. This is referred to as a
"Warning" alarm (i.e., warning you that bandwidth is nearing the threshold). When
bandwidth goes over the threshold, the device considers it as a Yellow state; when it
goes below the threshold, it considers it as a Green state.

Yellow-Red threshold: Indicates that bandwidth has exceeded the configured
threshold. When bandwidth goes over the threshold, the device considers it as a Red
state; when it goes below the threshold, it considers it as a Yellow state.
User's Manual
244
Document #: LTRT-27034
User's Manual
16. Quality of Experience
Hysteresis is also used to configure the threshold. This defines the amount of fluctuation
from a threshold in order for the threshold to be considered as crossed (i.e., change in
color state). Hysteresis is used to avoid false reports.
The following procedure describes how to configure Bandwidth Profiles in the Web
interface. You can also configure Bandwidth Profiles using the table ini file parameter,
BWProfile or CLI command, configure voip/qoe bw-profile.
 To configure Bandwidth Profiles:
1.
Open the Bandwidth Profile page (Configuration tab > VoIP menu > Quality of
Experience > Bandwidth Profile).
2.
Click Add; the following dialog box appears:
Figure 16-4: Bandwidth Profile Page - Add Record
The figure above shows a configuration example where if the outgoing voice traffic
threshold of 64,000 increases by 80% (70% warning threshold plus 10% hysteresis) to
115,200 (64,000 plus 51,200), a Yellow state occurs and an alarm is sent. If the
threshold increases by 10%, a Red state occurs and an alarm is sent.
3.
Configure a Bandwidth Profile according to the parameters described in the table
below.
4.
Click Submit, and then reset the device with a save ("burn") to flash memory.
Table 16-3: Bandwidth Profile Table Parameter Descriptions
Parameter
Description
Index
[BWProfile_Index]
Defines the index of the table row entry.
Name
CLI: name
[BWProfile_Name]
Defines an arbitrary name to easily identify the Bandwidth
Profile.
The valid value is a string of up to 20 characters.
Egress Audio Bandwidth
CLI: egress-audio-bandwidth
[BWProfile_EgressAudioBandwidth]
Defines the outgoing audio traffic threshold (in Kbps).
Ingress Audio Bandwidth
Defines the incoming audio traffic threshold (in Kbps).
CLI: ingress-audio-bandwidth
[BWProfile_IngressAudioBandwidth]
Version 6.8
245
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Egress Video Bandwidth
CLI: egress-video-bandwidth
[BWProfile_EgressVideoBandwidth]
Defines the outgoing video traffic threshold (in Kbps).
Ingress Video Bandwidth
CLI: ingress-video-bandwidth
[BWProfile_IngressVideoBandwidth]
Defines the incoming video traffic threshold (in Kbps).
Total Egress Bandwidth
CLI: total-egress-bandwidth
[BWProfile_TotalEgressBandwidth]
Defines the total (video and audio) outgoing bandwidth
threshold (in Kbps).
Total Ingress Bandwidth
CLI: total-ingress-bandwidth
[BWProfile_TotalIngressBandwidth]
Defines the total (video and audio) incoming bandwidth
threshold (in Kbps).
Warning Threshold
CLI: warning-threshold
[BWProfile_WarningThreshold]
Defines the threshold (in percentage) of the bandwidth
thresholds that if exceeded is considered a Warning alarm
(Green-Yellow threshold). This applies to any of the
configured bandwidth thresholds. The Hysteresis is also
added to this Warning threshold. For example, if set to 70%
and the Hysteresis to 10%, when the current outgoing voice
traffic exceeds 80% of the configured threshold, the Yellow
state occurs and a Warning threshold alarm is sent if
'Generate Alarm' is set to Enable.
Hysteresis
CLI: hysteresis
[BWProfile_hysteresis]
Defines the bandwidth fluctuation (change) from the
bandwidth threshold value (in percentage). The threshold is
considered crossed if bandwidth exceeds the configured
threshold plus this hysteresis, and a Red state occurs. For
example, assume this parameter is set to 10% and the
configured bandwidth threshold is set to 64000 Kbps. If
current bandwidth reaches 70,400 Kbps (additional 10%),
the threshold is considered crossed.
Generate Alarm
CLI: generate-alarms
[BWProfile_GenerateAlarms]
Enables the generation of an SNMP alarm if the threshold
(with the hysteresis) is crossed.
 [0] Disable (default)
 [1] Enable
If enabled, an alarm is sent if one of the following scenarios
occurs:
 Warning threshold is exceeded (Warning severity Yellow threshold).
 Any configured bandwidth threshold is exceeded (Major
severity - Red threshold).
User's Manual
246
Document #: LTRT-27034
User's Manual
16.4
16. Quality of Experience
Configuring Media Enhancement Profiles
Media Enhancement Profiles provides support for access control and media quality
enhancements based on call quality measurements (configured in ''Configuring Quality of
Experience Profiles'' on page 240) and bandwidth utilization (configured in ''Configuring
Bandwidth Profiles'' on page 244). These profiles contain color-coded thresholds that are
used to trigger access control and/or media enhancements.
The Media Enhancement Profile table lets you configure any one of the following actions
when a specific color-coded threshold (Green-Yellow or Yellow-Red) is crossed for a
specific monitored voice metrics (e.g., MOS) or bandwidth (e.g., Egress Audio Bandwidth):

Reject new calls until the voice metrics or bandwidth returns to below the threshold.
This can be used, for example, to reject new calls when bandwidth threshold is
exceeded.

Use a different IP Profile. For example, if packet loss is detected, the IP Group (to
which the Media Enhancement Rule is later assigned) can switch to an IP Profile
configured with a higher RTP redundancy level. The ability to use a different IP Profile
when call quality or bandwidth thresholds are crossed provides a wide range of
options for media enhancement and traffic shaping. For example, it may be used to:

•
switch to a low bit-rate coder,
•
negotiate different p-time (and perform transrating if required),
•
increase RTP redundancy level,
•
or block video calls.
Accept calls
A Media Enhancement Profile can later be assigned to an IP Group (in the IP Group table).
However, when the device analyzes the call and determines whether Media Enhancement
Profile should be applied or not, it searches for the "most relevant" Quality of Experience
Profile or Bandwidth Profile in the following order: 1) Remote Media Subnet, 2) Media
Realm, and then 3) IP Group. Thus, a Media Enhancement Profile associated with a
specific IP Group may actually "respond" to Quality of Experience or bandwidth thresholds
crossed at the Media Realm or Remote Media Subnet level.
Notes:
• The color-coded threshold is first calculated for the IP Group and only then for the
Media Realm. The device uses the "worst" color-coded threshold crossing. For
example, if a Media Realm crossed a Green-Yellow threshold and an IP Group a
Yellow-Red threshold, the action defined for the Red color state is used.
• The device applies Media Enhancements Profiles on new calls only, based on the
information gathered from previous and/or currently established calls.
The following procedure describes how to configure Media Enhancement Profiles in the
Web interface. You can also configure Media Enhancement Profiles using other
management platforms:

Media Enhancement Profile table: Table ini file parameter,
MediaEnhancementProfile or CLI command, configure voip/qoe media-enhancement

Media Enhancement Rules table: Table ini file parameter, MediaEnhancementRules
or CLI command, configure voip/qoe media-enhancement-rules
Version 6.8
247
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure a Media Enhancement Profile:
1.
Open the Media Enhancement Profile page (Configuration tab > VoIP menu >
Quality of Experience > Media Enhancement Profile).
2.
Click Add; the following dialog box appears:
Figure 16-5: Media Enhancement Profile Table - Add Record
3.
Configure a Media Enhancement Profile according to the parameters described in the
table below.
4.
Click Submit.
Table 16-4: Media Enhancement Profile Table Parameter Descriptions
Parameter
Index
[MediaEnhancementProfile_Index]
Description
Defines the index of the table row entry.
Name
Defines an arbitrary name to easily identify the Media
CLI: profile-name
Enhancement Profile.
[MediaEnhancementProfile_ProfileName] The valid value is a string of up to 20 characters.
5.
In the Media Enhancement Profile table, select the required Media Enhancement
Profile index row, and then click the Media Enhancement Rules link located below
the table; the Media Enhancement Rules page appears.
6.
Click Add; the following dialog box appears:
Figure 16-6: Media Enhancement Rules - Add Record
7.
Configure a Media Enhancement Rule according to the parameters described in the
table below.
8.
Click Submit, and then reset the device with a save ("burn") to flash memory.
Table 16-5: Media Enhancement Rules Table Parameter Descriptions
Parameter
Index
CLI: rule-index
[MediaEnhancementRules_RuleIndex]
User's Manual
Description
Defines the index of the table row entry.
248
Document #: LTRT-27034
User's Manual
16. Quality of Experience
Parameter
Description
Trigger
CLI: trigger
[MediaEnhancementRules_Trigger]
Defines the monitored metrics parameter or bandwidth
associated with this rule.
 [0] MOS (default)
 [1] Delay
 [2] Packet Loss
 [3] Jitter
 [4] Bandwidth
Color
CLI: color
[MediaEnhancementRules_Color]
Defines the color-coded threshold change of the
monitored metrics or bandwidth (configured in the
'Trigger' parameter) for which this rule is done.
 [0] Red (default) = Yellow-to-Red threshold is
crossed.
 [1] Yellow = Green-to-Yellow threshold is crossed.
Rule Action
CLI: action-rule
[MediaEnhancementRules_ActionRule]
Defines the action that the device performs when the
color-coded threshold is crossed:
 [0] Accept Calls (default)
 [1] Reject Calls
 [2] Alternative IP Profile = An alternative IP Profile ID
is used, as configured in the 'Value' field (below).
Notes:
 If this parameter is set to a restrictive action (i.e.,
Reject Calls or Alternative IP Profile) for Yellow
and no action is set for Red, the device also applies
the Yellow action to Red, if this color-coded threshold
occurs.
 If this parameter is set to a permissive action (i.e.,
Accept Calls) for Red and no action is set for
Yellow, the device applies the same action to Yellow,
if this color-coded threshold occurs.
Value
Defines an alternative IP Profile ID for the IP Group that
CLI: value
is associated with this rule, if this rule is applied. This
[MediaEnhancementRules_ActionValue] parameter is applicable only if the 'Rule Action'
parameter is set to Alternative IP Profile.
Version 6.8
249
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
250
Document #: LTRT-27034
User's Manual
17
17. Control Network
Control Network
This section describes configuration of the network at the SIP control level.
17.1
Configuring Media Realms
The Media Realm table lets you configure a pool of up to 64 SIP media interfaces, termed
Media Realms. Media Realms allow you to divide a Media-type interface (configured in the
Interface table) into several realms, where each realm is specified by a UDP port range.
Media Realms also define the maximum number of permitted media sessions. Media
Realms can later be assigned to IP Groups (see ''Configuring IP Groups'' on page 261) and
SRDs (see ''Configuring SRDs'' on page 256).
You can also apply the device's Quality of Experience feature to Media Realms:

Quality of Experience Profile: Call quality monitoring based on thresholds for voice
metrics (e.g., MOS) can be applied per Media Realm. For example, if MOS is
considered poor, calls on this Media Realm can be rejected. For configuring Quality of
Experience Profiles, see ''Configuring Quality of Experience Profiles'' on page 240.

Bandwidth Profile: Bandwidth utilization thresholds can be applied per Media Realm.
For example, if bandwidth thresholds are crossed, the device can reject any new new
calls on this Media Realm. For configuring Bandwidth Profiles, see ''Configuring
Bandwidth Profiles'' on page 244.
You can also configure remote destination subnets per Media Realm and assign each
subnet a Quality of Experience Profile and Bandwidth Profile. For configuring Remote
Media Subnets, see ''Configuring Remote Media Subnets'' on page 254.
Notes:
• If an IP Group is associated with an SRD and different Media Realms are
assigned to the IP Group and SRD, the IP Group’s Media Realm takes
precedence.
• If you modify a Media Realm currently being used by a call, the device does not
perform Quality of Experience for the call. If you delete the Media Realm during
the call, the device maintains the call until the call parties end the call.
Version 6.8
251
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The following procedure describes how to configure Media Realms in the Web interface.
You can also configure Media Realms using the table ini file parameter, CpMediaRealm or
CLI command, configure voip/voip-network realm.
 To configure a Media Realm:
1.
Open the Media Realm Table page (Configuration tab > VoIP menu > VoIP Network
> Media Realm Configuration).
2.
Click Add; the following dialog box appears:
Figure 17-1: Media Realm Page - Add Record Dialog Box
3.
Configure the Media Realm according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 17-1: Media Realm Table Parameter Descriptions
Parameter
Index
[CpMediaRealm_Index]
Description
Defines an index number for the new table record.
The valid value is 0 to 63.
Media Realm Name
Defines an arbitrary name to easily identify the Media Realm.
CLI: name
The valid value is a string of up to 40 characters.
[CpMediaRealm_MediaRealmName]
Notes:
 This parameter is mandatory.
 The name assigned to the Media Realm must be unique.
IPv4 Interface Name
CLI: ipv4
[CpMediaRealm_IPv4IF]
Assigns an IPv4 network interface to the Media Realm. This
is the name of the interface as configured in the 'Interface
Name' field of the Interface table.
IPv6 Interface Name
CLI: ipv6if
[CpMediaRealm_IPv6IF]
Assigns an IPv6 network interface to the Media Realm. This
is the name of the interface as configured for the 'Interface
Name' field of the Interface table.
Port Range Start
CLI: port-range-start
[CpMediaRealm_PortRangeStart]
Defines the starting port for the range of Media interface UDP
ports.
Notes:
 You must either configure all Media Realms with port
ranges, or all without; not some with and some without.
 The available UDP port range is according to the
BaseUDPport parameter. For more information, see
Configuring RTP Base UDP Port on page 174.
User's Manual
252
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description

Media Realms must not have overlapping port ranges.
Number of Media Session Legs
CLI: session-leg
[CpMediaRealm_MediaSessionLeg]
Defines the number of media sessions associated with the
range of ports. This is the number of media sessions
available in the port range. For example, 100 ports
correspond to 10 media sessions, since ports are allocated in
chunks of 10.
Port Range End
CLI: port-range-end
[CpMediaRealm_PortRangeEnd]
(Read-only field) Displays the ending port for the range of
media interface UDP ports. This field is calculated by adding
the 'Media Session Leg' field (multiplied by the port chunk
size) to the 'Port Range Start' field. A value appears once a
row has been successfully added to the table.
Default Media Realm
CLI: is-default
[CpMediaRealm_IsDefault]
Defines the Media Realm as the default Media Realm. This
default Media Realm is used when no Media Realm is
configured for an IP Group or SRD for a specific call.
 [0] No (default)
 [1] Yes
Notes:
 This parameter can be set to Yes for only one defined
Media Realm.
 If the parameter is not configured, then the first Media
Realm in the table is used as default.
 If the table is not configured, the default Media Realm
includes all the configured media interfaces.
QoE Profile
CLI: qoe-profile
[CpMediaRealm_QoeProfile]
Assigns a QoE Profile to the Media Realm. For configuring
QoE Profiles, see ''Configuring Quality of Experience
Profiles'' on page 240.
BW Profile
CLI: bw-profile
[CpMediaRealm_BWProfile]
Assigns a Bandwidth Profile to the Media Realm. For
configuring Bandwidth Profiles, see ''Configuring Bandwidth
Profiles'' on page 244.
Version 6.8
253
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
17.2
Configuring Remote Media Subnets
Remote Media Subnets define destination subnets for media (RTP/SRTP) traffic on a
specific Media Realm. Each Remote Media Subnet can be assigned different call quality
(Quality of Experience Profile) and bandwidth utilization (Bandwidth Profile) profiles. These
profiles are configured in ''Configuring Quality of Experience Profiles'' on page 240 and
''Configuring Bandwidth Profiles'' on page 244, respectively. Thus, you can apply these
profiles to remote media subnets instead of Media Realms or IP Groups. You can configure
up to five Remote Media Subnets per Media Realm.
The figure below illustrates an example for implementing Remote Media Subnets. IP Group
#2 represents a SIP Trunk which routes international (USA and India) and local calls. As
international calls are typically more prone to higher delay than local calls, different Quality
of Experience Profiles are assigned to them. This is done by creating Remote Media
Subnets for each of these call destinations and assigning each Remote Media Subnet a
different Quality of Experience Profile. A Quality of Experience Profile that defines a packet
delay threshold is assigned to the international calls, which if crossed, a different IP Profile
is used that defines higher traffic priority to voice over other traffic. In addition, IP Group #2
has a 10-Mbps bandwidth threshold and a "tighter" bandwidth limitation (e.g., 1 Mbps) is
allocated to local calls. If this limit is exceeded, the device rejects new calls to this Remote
Media Subnet.
Figure 17-2: Remote Media Subnets Example
The following procedure describes how to configure Remote Media Subnets in the Web
interface. You can also configure Remote Media Subnets using the table ini file parameter,
RemoteMediaSubnet or CLI command, configure voip > voip-network realm
remotemediasubnet.
 To configure a Remote Media Subnet:
1.
Open the Media Realm Table page (Configuration tab > VoIP menu > VoIP Network
> Media Realm Configuration).
2.
Select the Media Realm index row for which you want to add Remote Media Subnets,
and then click the Remote Media Subnet link located below the table; the Remote
Media Subnet table appears.
User's Manual
254
Document #: LTRT-27034
User's Manual
3.
17. Control Network
Click Add; the following dialog box appears:
Figure 17-3: Remote Media Subnet - Add Record
4.
Configure the Remote Media Subnet according to the parameters described in the
table below.
5.
Click Submit, and then save ("burn") your settings to flash memory.
Table 17-2: Remote Media Subnet Table Parameter Descriptions
Parameter
Description
Index
[RemoteMediaSubnet_RemoteMediaSubnetIndex]
Defines an index number for the new table
record.
Sub-Realm Name
Defines an arbitrary name to easily identify
CLI: name
the Remote Media Subnet.
[RemoteMediaSubnet_RemoteMediaSubnetName] The valid value is a string of up to 20
characters.
Prefix Length
CLI: prefix-length
[RemoteMediaSubnet_PrefixLength]
Defines the subnet mask in Classless InterDomain Routing (CIDR) notation. For
example, 16 denotes 255.255.0.0.
The default is 16.
Address Family
CLI: address-family
[RemoteMediaSubnet_AddressFamily]
Defines the IP address protocol.
 [2] IPv4 Manual (default)
 [10] IPv6 Manual
Destination IP
CLI: dst-ip-address
[RemoteMediaSubnet_DstIPAddress]
Defines the IP address of the destination.
The default is 0.0.0.0.
QOE Profile Name
CLI: qoe-profile
[RemoteMediaSubnet_QOEProfileName]
Assigns a Quality of Experience Profile to the
Remote Media Subnet.
BW Profile Name
CLI: bw-profile
[RemoteMediaSubnet_BWProfileName]
Assigns a Bandwidth Profile to the Remote
Media Subnet.
Version 6.8
255
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
17.3
Configuring SRDs
The SRD table lets you configure up to 32 signaling routing domains (SRD). An SRD
represents a logical VoIP network. Each logical or physical connection requires an SRD.
For example, if the device interfaces with both the LAN and WAN, you would need to
configure an SRD for each one.
The SRD is composed of the following:

SIP Interface: The SIP Interface defines a listening port and type (TLS) for SIP
signaling traffic on a specific logical IP network interface of the device.

Media Realm: The Media Realm defines a UDP port range for RTP (media) traffic on a
specific logical IP network interface of the device.
An SRD is a set of definitions together creating multiple, virtual multi-service IP gateways:

Multiple and different SIP signaling interfaces (SRD associated with a SIP Interface)
and RTP media (associated with a Media Realm) for multiple Layer-3 networks. Due
to the B2BUA nature of the SBC application, different interfaces can be assigned to
each leg of the call.

Can operate with multiple gateway customers that may reside either in the same or in
different Layer-3 networks as the device. This allows separation of signaling traffic
between different customers. In such a scenario, the device is configured with multiple
SRD's.
Typically, one SRD is defined for each SIP entity (e.g. proxies, IP phones, application
servers, gateways, and softswitches) that communicate with each other. This provides
these entities with VoIP services that reside on the same Layer-3 network (must be able to
communicate without traversing NAT devices and must not have overlapping IP
addresses). Routing from one SRD to another is possible, whereby each routing
destination (IP Group or destination address) indicates the SRD to which it belongs.
Once configured, you can use the SRD as follows:

Associate it with a SIP Interface (see ''Configuring SIP Interfaces'' on page 258)

Associate it with an IP Group (see ''Configuring IP Groups'' on page 261)

Associate it with a Proxy Set (see ''Configuring Proxy Sets'' on page 272)

Associated it with an Admission Control rule (see Configuring Admission Control Table
on page 517)

Define it as a Classification rule for incoming SIP requests (see ''Configuring
Classification Rules'' on page 522)

Use it as a destination IP-to-IP routing rule (see Configuring Outbound IP Routing
Table on page 383 for the Gateway application and Configuring SBC IP-to-IP Routing
Rules on page 530 for the SBC application)
The following procedure describes how to configure SRDs in the Web interface. You can
also configure this using the table ini file parameter, SRD or CLI command, configure voip
> voip-network srd.
User's Manual
256
Document #: LTRT-27034
User's Manual
17. Control Network
 To configure an SRD:
1.
Open the SRD Table page (Configuration tab > VoIP menu > VoIP Network > SRD
Table).
2.
Click Add; the following dialog box appears:
Figure 17-4: SRD Settings Page
3.
Configure an SRD according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 17-3: SRD Table Parameter Descriptions
Parameter
Description
Index
[SRD_Index]
Defines an index for the new table record.
The valid value is 0 to 31.
SRD Name
CLI: name
[SRD_Name]
Defines an arbitrary name to easily identify the SRD.
The valid value can be a string of up to 21 characters.
Note: This parameter is mandatory.
Media Realm Name
CLI: media-realm
[SRD_MediaRealm]
Assigns a Media Realm to the SRD. The listed Media Realms are
the identifiable names that you configured for the Media Realms in
the 'Media Realm Name' field of the Media Realm table (see
''Configuring Media Realms'' on page 251).
Note: If the Media Realm is later deleted from the Media Realm
table, this value becomes invalid in the SRD table.
Media Anchoring
CLI: intra-srd-media-anchoring
[SRD_IntraSRDMediaAnchori
ng]
Enables the Media Anchoring feature (Anti-Tromboning) per SRD,
whereby RTP (media) flows directly between the call parties (i.e.,
does not traverse the device).
 [0] Enable = (Default) RTP traverses the device and each leg
uses a different coder or coder parameters.
 [1] Disable = The RTP packet flow does not traverse the device;
instead, the two SIP UAs establish a direct RTP/SRTP (media)
flow between one another.
Notes:
 If this parameter is enabled and the two call endpoints belong to
the same SRD, calls cannot be established if the following
scenario exists:
a. One of the endpoints is defined as a foreign user (for
example, “follow me service”)
b. and one endpoint is located on the WAN and the other on the
LAN.
Version 6.8
257
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
The reason for this is that in Media Anchoring, the device does
not interfere in the SIP signaling such as manipulation of IP
addresses, which is necessary for calls between LAN and WAN.
 When the global parameter SBCDirectMedia is disabled, Media
Anchoring can only be enabled for calls between endpoints
belonging to the same SRD.
 For more information on Media Anchoring, see No Media
Anchoring (Anti-Tromboning) on page 493.
Block Unregistered Users
CLI: block-un-reg-users
[SRD_BlockUnRegUsers]
Determines whether the device blocks (rejects) incoming calls
(INVITE requests) from unregistered users (pertaining to User-type
IP Groups) for the SRD.
 [0] No = Calls from unregistered users are not blocked (default).
 [1] Yes = Blocks calls from unregistered users.
Note: When the call is blocked, the device sends a SIP 500 "Server
Internal Error" response to the remote end.
Max. Number of Registered
Users
CLI: max-reg-users
[SRD_MaxNumOfRegUsers]
Maximum number of users belonging to this SRD that can register
with the device. By default, no limitation exists for registered users
Enable Un-Authenticated
Registrations
CLI: enable-un-auth-registrs
[SRD_EnableUnAuthenticated
Registrations]
Determines whether the device blocks REGISTER requests from
new users (i.e., users not registered in the device's registration
database) when the destination is a User-type IP Group.
 [0] No = The device sends REGISTER requests to the SIP proxy
server and only if authenticated by the server does the device
add the user registration to its database.
 [1] Yes = The device adds REGISTER requests to its database
even if the requests are not authenticated by a SIP proxy
(default).
17.4
Configuring SIP Interfaces
The SIP Interface table lets you configure up to 32 SIP Interfaces. A SIP Interface defines
a listening port and type (UDP, TCP, or TLS) for SIP signaling traffic on a specific logical IP
network interface (configured in the Interface table). The SIP Interface can be configured
for a specific application (i.e., Gateway\IP-to-IP, SAS, SBC) and associated with an SRD.
For each SIP Interface, you can assign a SIP message policy rule, assign SIP message
manipulation rules, enable TLS mutual authentication, enable TCP keepalive, assign a
SSL/TLS certificate (TLS Context), and configure the SIP response sent upon classification
failure.
SIP Interfaces can be used, for example, for the following:

Using SIP signaling interfaces per call leg (i.e., each SIP entity communicates with a
specific SRD).

Using different SIP listening ports for a single or for multiple IP network interfaces.

Differentiating between applications by creating SIP Interfaces per application.

Separating signaling traffic between networks (e.g., different customers) to use
different routing tables, manipulations, SIP definitions, and so on.
The following procedure describes how to configure SIP interfaces in the Web interface.
You can also configure this using the table ini file parameter, SIPInterface or the CLI
command, configure voip > voip-network sip-interface.
User's Manual
258
Document #: LTRT-27034
User's Manual
17. Control Network
 To configure a SIP Interface:
1.
Open the SIP Interface Table page (Configuration tab > VoIP menu > VoIP Network
> SIP Interface Table).
2.
Click Add; the following dialog box appears:
3.
Configure a SIP Interface according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 17-4: SIP Interface Table Parameter Descriptions
Parameter
Index
[SIPInterface_Index]
Description
Defines an index for the new table record.
The valid value is 0 to 31.
Interface Name
Defines an arbitrary name to easily identify the SIP Interface.
CLI: interface-name
The valid value is a string of up to 21 characters.
[SIPInterface_InterfaceName
]
Network Interface
CLI: network-interface
[SIPInterface_NetworkInterf
ace]
Assigns a Control-type IP network interface to the SIP Interface. This
string value must be identical (case-sensitive) to that configured in
the 'Interface Name' field of the Interface table (see ''Configuring IP
Network Interfaces'' on page 116).
By default, no value is defined.
Application Type
CLI: application-type
[SIPInterface_ApplicationTy
pe]
Defines the application type associated with the SIP Interface.
 [0] GW/IP2IP (default) = Gateway / IP-to-IP application.
 [1] SAS = Stand-Alone Survivability (SAS) application.
 [2] SBC = SBC application.
UDP Port
CLI: udp-port
[SIPInterface_UDPPort]
Defines the listening and source UDP port.
The valid range is 1 to 65534. The default is 5060.
Notes:
 This port must be outside of the RTP port range.
 Each SIP Interface must have a unique signaling port (i.e., no two
SIP Interfaces can share the same port - no port overlapping).
Version 6.8
259
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
TCP Port
CLI: tcp-port
[SIPInterface_TCPPort]
Defines the listening TCP port.
The valid range is 1 to 65534. The default is 5060.
Notes:
 This port must be outside of the RTP port range.
 Each SIP Interface must have a unique signaling port (i.e., no two
SIP Interfaces can share the same port - no port overlapping).
TLS Port
CLI: tls-port
[SIPInterface_TLSPort]
Defines the listening TLS port.
The valid range is 1 to 65534. The default is 5061.
Notes:
 This port must be outside of the RTP port range.
 Each SIP Interface must have a unique signaling port (i.e., no two
SIP Interfaces can share the same port - no port overlapping).
SRD
CLI: srd
[SIPInterface_SRD]
Assigns an SRD ID to the SIP Interface (configured in ''Configuring
SRDs'' on page 256).
The default is 0.
Notes:
 You can assign the same SRD ID to up to two SIP Interfaces of
the same application type.
 For the SAS application, use only SRD ID 0.
 Each SIP Interface of the same application type (e.g., SBC) that
is assigned to the same SRD must be configured with the same
IP version (IPv4 or IPv6).
 All the SIP Interfaces that are assigned to the same SRD must
have the same network interface (assigned in the 'Network
Interface' parameter, above).
Message Policy
CLI: message-policy
[SIPInterface_MessagePolic
y]
Assigns a SIP message policy to the SIP interface (configured in
''Configuring SIP Message Policy Rules'').
TLS Context Name
CLI: tls-context-name
[SIPInterface_TLSContext]
Assigns a TLS Context (SSL/TLS certificate) to the SIP Interface.
The TLS Context is assigned by name, as configured in the 'Name'
field of the TLS Contexts table.
 Incoming calls: This TLS Context is used if no TLS Context is
configured for the Proxy Set associated with the call or
classification to an IP Group based on Proxy Set fails.
 Outgoing calls: This TLS Context is used if no TLS Context is
configured for the Proxy Set associated with the call.
For more information about how certificates are associated with calls
and for configuring TLS Contexts, see Configuring SSL/TLS
Certificates on page 91.
TLS Mutual Authentication
CLI: tls-mutual-auth
[SIPInterface_TLSMutualAut
hentication]
Enables TLS mutual authentication for the SIP Interface.
 [-1] Not Configured = (Default) The SIPSRequireClientCertificate
global parameter setting is applied.
 [0] Disable = Device does not request the client certificate for TLS
connection on this SIP Interface.
 [1] Enable = Device requires receipt and verification of the client
certificate to establish the TLS connection on this SIP Interface.
User's Manual
260
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description
Enable TCP Keepalive
CLI: tcp-keepalive-enable
[SIPInterface_TCPKeepalive
Enable]
Enables the TCP Keep-Alive mechanism with the IP entity on this
SIP Interface. TCP keep-alive can be used, for example, to keep a
NAT entry open for clients located behind a NAT server, or simply to
check that the connection to the IP entity is available.
 [0] Disable (default)
 [1] Enable
Note: For configuring TCP keepalive, use the following ini file
parameters: TCPKeepAliveTime, TCPKeepAliveInterval, and
TCPKeepAliveRetry.
Classification Failure
Response Type
CLI:
classification_fail_response_ty
pe
[SIPInterface_Classification
FailureResponseType]
Defines the SIP response code that the device sends if a received
SIP request (OPTIONS, REGISTER, or INVITE) has failed the SBC
Classification process.
The valid value can be a SIP response code from 400 through 699,
or it can be set to 0 to not send any response at all. The default
response code is 500 (Server Internal Error).
This feature is important for preventing Denial of Service (DoS)
attacks, typically initiated from the WAN. Malicious attackers can use
SIP scanners to detect ports used by SIP devices. These scanners
scan devices by sending UDP packets containing a SIP request to a
range of specified IP addresses, listing those that return a valid SIP
response. Once the scanner finds a device that supports SIP, it
extracts information from the response and identifies the type of
device (IP address and name) and can execute DoS attacks. A way
to defend the device against such attacks is to not send a SIP reject
response to these unclassified "calls" so that the attacker assumes
that no device exists at such an IP address and port.
Note: This parameter is applicable only if the device is set to reject
unclassified calls. This is configured using the 'Unclassified Calls'
parameter on the General Settings page (Configuration tab > VoIP
menu > SBC > General Settings).
Web: Pre Classification
ManSet
CLI: preclassification-manset
[SIPInterface_PreClassificati
onManipulationSet]
Assigns a Message Manipulation Set ID to the SIP Interface. This
lets you apply SIP message manipulation rules on incoming SIP
initiating-dialog request messages (not in-dialog), received on this
SIP Interface, prior to the Classification process.
By default, no Message Manipulation Set ID is defined.
For configuring Message Manipulation Sets, see Configuring SIP
Message Manipulation on page 286.
Notes:
 The Message Manipulation Set assigned to a SIP Interface that is
associated with an outgoing call, is ignored. Only the Message
Manipulation Set assigned to the associated IP Group is applied
to the outgoing call.
 If both the SIP Interface and IP Group associated with the
incoming call are assigned a Message Manipulation Set, the one
assigned to the SIP Interface is applied first.
 This parameter is applicable only to SBC calls.
Version 6.8
261
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
17.5
Configuring IP Groups
The IP Group table lets you configure up to 100 IP Groups. An IP Group represents a SIP
entity in the network with which the device communicates. This can be a server (e.g., IP
PBX or ITSP) or it can be a group of users (e.g., LAN IP phones). For servers, the IP
Group is typically used to define the server's IP address by associating it with a Proxy Set
(see Configuring Proxy Sets on page 272).
IP Groups can be used for the following:

SBC application: The IP Group table can be used to classify incoming SIP dialoginitiating requests (e.g., INVITE messages) to specific IP Groups. This classification is
based on the Proxy Set ID associated with the IP Group. If the source address of the
incoming SIP dialog is defined for this Proxy Set, the device assigns the SIP dialog to
the associated IP Group. This feature is configured using the 'Classify by Proxy Set'
parameter in the IP Group table.
Note: It is highly recommended to use the Classification table for classifying incoming
SIP dialogs to IP Groups (see Configuring Classification Rules on page 522).

SBC application: IP Groups are used for configuring IP-to-IP routing rules where they
represent the source and destination of the call (see Configuring SBC IP-to-IP Routing
Rules on page 530).

SIP dialog registration and authentication (digest user/password) of specific IP Groups
(Served IP Group, e.g., corporate IP-PBX) with other IP Groups (Serving IP Group,
e.g., ITSP). This is configured in the Account table (see ''Configuring Registration
Accounts'' on page 279).

Gateway application: Call routing rules:
•
Outgoing IP calls (IP-to-IP or Tel-to-IP): The IP Group identifies the source of the
call and is used as the destination of the outgoing IP call (configured in the
Outbound IP Routing table). For Tel-to-IP calls, the IP Group (Serving IP Group)
can be used as the IP destination to where all SIP dialogs that are initiated from a
Trunk Group are sent (configured in Configuring Trunk Group Settings on page
353).
•
Incoming IP calls (IP-to-IP or IP-to-Tel): The IP Group identifies the source of the
IP call.
•
The IP Group can be used to associate a number manipulation rule with specific
calls identified by IP Group.
You can also apply the device's Quality of Experience feature to IP Groups:

Quality of Experience Profile: Call quality monitoring based on thresholds for voice
metrics (e.g., MOS) can be applied per IP Group. For example, if MOS is considered
poor, calls belonging to this IP Group can be rejected. For configuring Quality of
Experience Profiles, see ''Configuring Quality of Experience Profiles'' on page 240.

Bandwidth Profile: Bandwidth utilization thresholds can be applied per IP Group. For
example, if bandwidth thresholds are crossed, the device can reject any new calls on
this IP Group. For configuring Bandwidth Profiles, see ''Configuring Bandwidth
Profiles'' on page 244.
Notes:
• IP Group ID 0 cannot be used. This IP Group is set to default values and is used
by the device when IP Groups are not implemented.
• If different SRDs are configured in the IP Group and Proxy Set tables, the SRD
defined for the Proxy Set takes precedence.
User's Manual
262
Document #: LTRT-27034
User's Manual
17. Control Network
The following procedure describes how to configure IP Groups in the Web interface. You
can also configure IP Groups using the table ini file parameter, IPGroup or CLI command,
configure voip > control-network ip-group.
 To configure an IP Group:
1.
Open the IP Group Table page (Configuration tab > VoIP menu > VoIP Network >
IP Group Table).
2.
Click Add; the following dialog box appears:
Figure 17-5: IP Group Table - Add Dialog Box
3.
Configure an IP Group according to to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 17-5: IP Group Table Parameter Descriptions
Parameter
Description
Common Parameters
Index
[IPGroup_Index]
Defines an index for the new table record.
Type
CLI:type
[IPGroup_Type]
Defines the type of IP Group:
 [0] Server = Used when the destination address, configured by
the Proxy Set, of the IP Group (e.g., ITSP, Proxy, IP-PBX, or
Application server) is known.
 [1] User = Represents a group of users such as IP phones and
softphones where their location is dynamically obtained by the
device when REGISTER requests and responses traverse (or are
terminated) by the device. These users are considered remote
Version 6.8
263
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
(far-end) users.
Typically, this IP Group is configured with a Serving IP Group that
represents an IP-PBX, Application or Proxy server that serves
this User-type IP Group. Each SIP request sent by a user of this
IP Group is proxied to the Serving IP Group. For registrations, the
device updates its internal database with the AOR and contacts
of the users.
Digest authentication using SIP 401/407 responses (if needed) is
performed by the Serving IP Group. The device forwards these
responses directly to the SIP users.
To route a call to a registered user, a rule must be configured in
the Outbound IP Routing table or SBC IP-to-IP Routing table. The
device searches the dynamic database (by using the request
URI) for an entry that matches a registered AOR or Contact.
Once an entry is found, the IP destination is obtained from this
entry, and a SIP request is sent to the destination.
The device also supports NAT traversal for the SIP clients located
behind NAT. In this case, the device must be defined with a
global IP address.
 [2] Gateway = This is applicable only to the SBC application in
scenarios where the device receives requests to and from a
gateway representing multiple users. This IP Group type is
necessary as the other IP Group types are not suitable:
 The IP Group cannot be defined as a Server since its
destination address is unknown during configuration.
 The IP Group cannot be defined as a User since the SIP
Contact header of the incoming REGISTER does not
represent a specific user. The Request-URI user part can
change and therefore, the device is unable to identify an
already registered user and therefore, adds an additional
record to the database.
The IP address of the Gateway IP Group is obtained dynamically
from the host part of the Contact header in the REGISTER
request received from the IP Group. Therefore, routing to this IP
Group is possible only once a REGISTER request is received. If a
REGISTER refresh request arrives, the device updates the new
location (i.e., IP address) of the IP Group. If the REGISTER fails,
no update is performed. If an UN-REGISTER request arrives, the
IP address associated with the IP Group is deleted and therefore,
no routing to the IP Group is done.
Note: This field is applicable only to the SBC and IP-to-IP
application.
Description
CLI: description
[IPGroup_Description]
Defines a brief description for the IP Group.
The valid value is a string of up to 29 characters. The default is an
empty field.
Proxy Set ID
CLI: proxy-set-id
[IPGroup_ProxySetId]
Assigns a Proxy Set ID to the IP Group. All INVITE messages
destined to this IP Group are sent to the IP address configured for
the Proxy Set.
Notes:
 The Proxy Set is applicable only to Server-type IP Groups.
 The SRD configured for this Proxy Set in the Proxy Set table is
automatically assigned to this IP Group (see the 'SRD' field
below).
User's Manual
264
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description

To configure Proxy Sets, see ''Configuring Proxy Sets'' on page
272.
SIP Group Name
CLI: sip-group-name
[IPGroup_SIPGroupName]
Defines the SIP Request-URI host name used in INVITE and
REGISTER messages sent to this IP Group, or the host name in the
From header of INVITE messages received from this IP Group.
The valid value is a string of up to 100 characters. The default is an
empty field.
Notes:
 If this parameter is not configured, the value of the global
parameter, ProxyName is used instead (see ''Configuring Proxy
and Registration Parameters'' on page 283).
 If the IP Group is of User type, this parameter is used internally
as a host name in the Request-URI for Tel-to-IP initiated calls.
For example, if an incoming call from the device's T1 trunk is
routed to a User-type IP Group, the device first creates the
Request-URI (<destination_number>@<SIP Group Name>), and
then it searches the internal database for a match.
Contact User
CLI: contact-user
[IPGroup_ContactUser]
Defines the user part of the From, To, and Contact headers of SIP
REGISTER messages, and the user part of the Contact header of
INVITE messages received from this IP Group and forwarded by the
device to another IP Group.
Notes:
 This parameter is applicable only to Server-type IP Groups.
 This parameter is overridden by the ‘Contact User’ parameter in
the ‘Account’ table (see ''Configuring Registration Accounts'' on
page 279).
SRD
CLI: srd
[IPGroup_SRD]
Assigns an SRD to the IP Group.
The default is 0.
Notes:
 For this parameter to take effect, a device reset is required.
 To configure SRDs, see Configuring SRDs on page 256.
 For Server-type IP Groups, if you assign the IP Group with a
Proxy Set ID (in the 'Proxy Set ID' field), the SRD field is
automatically set to the SRD value assigned to the Proxy Set in
the Proxy Set table.
Media Realm Name
CLI: media-realm-name
[IPGroup_MediaRealm]
Assigns a Media Realm to the IP Group. The string value must be
identical (including case-sensitive) to the Media Realm name defined
in the Media Realm table (see Configuring Media Realms on page
251).
Notes:
 For this parameter to take effect, a device reset is required.
 If the Media Realm is deleted from the Media Realm table, this
value becomes invalid.
IP Profile ID
CLI: ip-profile-id
[IPGroup_ProfileId]
Assigns an IP Profile to the IP Group. To configure IP Profiles, see
''Configuring IP Profiles'' on page 302.
The default is 0.
Local Host Name
CLI: local-host-name
[IPGroup_ContactName]
Defines the host name (string) that the device uses in the SIP
message's Via and Contact headers. This is typically used to define
an FQDN as the host name. The device uses this string for Via and
Version 6.8
265
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Contact headers in outgoing INVITE messages sent to a specific IP
Group, and the Contact header in SIP 18x and 200 OK responses for
incoming INVITE messages received from a specific IP Group. The
Inbound IP Routing table can be used to identify the source IP Group
from where the INVITE message was received.
If this parameter is not configured (default), these headers are
populated with the device's dotted-decimal IP address of the network
interface on which the message is sent.
Note: To ensure proper device handling, this parameter should be a
valid FQDN.
QoE Profile
CLI: qoe-profile
[IPGroup_QOEProfile]
Assigns a Quality of Experience Profile rule. For configuring Quality
of Experience Profiles, see ''Configuring Quality of Experience
Profiles'' on page 240.
Bandwidth Profile
CLI: bandwidth-profile
[IPGroup_BWProfile]
Assigns a Bandwidth Profile rule. For configuring Bandwidth Profiles,
see ''Configuring Bandwidth Profiles'' on page 244.
Media Enhancement Profile
CLI: media-enhancementprofile
[IPGroup_MediaEnhanceme
ntProfile]
Assigns a Media Enhancement Profile rule. For configuring Media
Enhancement Profiles, see ''Configuring Media Enhancement
Profiles'' on page 247.
Always Use Source Address
CLI: always-use-source-addr
[IPGroup_AlwaysUseSource
Addr]
Enables the device to always send SIP requests and responses,
within a SIP dialog, to the source IP address received in the previous
SIP message packet. This feature is especially useful in scenarios
where the IP Group endpoints are located behind a NAT firewall (and
the device is unable to identify this using its regular NAT
mechanism).
 [0] No = (Default) The device sends SIP requests according to
the settings of the global parameter, SIPNatDetection.
 [1] Yes = The device sends SIP requests and responses to the
source IP address received in the previous SIP message packet.
For information on NAT traversal, see Remote UA behind NAT on
page 138.
CLI: Msg-Man-User-DefinedDefines a value for the SIP user part that can be used in Message
String1
Manipulation rules configured in the Message Manipulations table.
[IPGroup_MsgManUserDef1] The Message Manipulation rule obtains this value from the IP Group,
by using the following syntax: param.ipg.<src|dst>.user-defined.<0>.
The valid value is a string of up to 30 characters.
For configuring Message Manipulation rules, see ''Configuring SIP
Message Manipulation'' on page 286.
CLI: Msg-Man-User-DefinedDefines a value for the SIP user part that can be used in Message
String2
Manipulation rules configured in the Message Manipulations table.
[IPGroup_MsgManUserDef2] The Message Manipulation rule obtains this value from the IP Group,
by using the following syntax: param.ipg.<src|dst>.user-defined.<1>.
The valid value is a string of up to 30 characters.
For configuring Message Manipulation rules, see ''Configuring SIP
Message Manipulation'' on page 286.
Gateway Parameters
Always Use Route Table
CLI: always-use-route-table
User's Manual
Defines the Request-URI host name in outgoing INVITE messages.
 [0] No (default).
266
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description

[IPGroup_AlwaysUseRouteTa
ble]
[1] Yes = The device uses the IP address (or domain name)
defined in the Outbound IP Routing table (see Configuring the
Outbound IP Routing Table on page 383) as the Request-URI
host name in outgoing INVITE messages, instead of the value
configured in the 'SIP Group Name' field.
Note: This parameter is applicable only to Server-type IP Groups.
Routing Mode
CLI: routing-mode
[IPGroup_RoutingMode]
Defines the routing mode for outgoing SIP INVITE messages.
 [-1] Not Configured = (Default) The routing is according to the
selected Serving IP Group. If no Serving IP Group is selected, the
device routes the call according to the Outbound IP Routing table
(see Configuring Outbound IP Routing Table on page 383).
 [0] Routing Table = The device routes the call according to the
Outbound IP Routing table.
 [1] Serving IP Group = The device sends the SIP INVITE to the
selected Serving IP Group. If no Serving IP Group is selected, the
default IP Group is used. If the Proxy server(s) associated with
the destination IP Group is not alive, the device uses the
Outbound IP Routing table (if the parameter IsFallbackUsed is set
1, i.e., fallback enabled - see ''Configuring Proxy and Registration
Parameters'' on page 283).
 [2] Request-URI = The device sends the SIP INVITE to the IP
address according to the received SIP Request-URI host name.
Notes:
 This parameter is applicable only to the IP-to-IP application.
 This parameter is applicable only to Server-type IP Groups.
SIP Re-Routing Mode
CLI: re-routing-mode
[IPGroup_SIPReRoutingMode
]
Defines the routing mode after a call redirection (i.e., a 3xx SIP
response is received) or transfer (i.e., a SIP REFER request is
received).
 [-1] Not Configured (Default)
 [0] Standard = INVITE messages that are generated as a result
of Transfer or Redirect are sent directly to the URI, according to
the Refer-To header in the REFER message or Contact header in
the 3xx response.
 [1] Proxy = Sends a new INVITE to the Proxy. This is applicable
only if a Proxy server is used and the parameter
AlwaysSendtoProxy is set to 0.
 [2] Routing Table = Uses the Routing table to locate the
destination and then sends a new INVITE to this destination.
Notes:
 When this parameter is set to [1] and the INVITE sent to the
Proxy fails, the device re-routes the call according to the
Standard mode [0].
 When this parameter is set to [2] and the INVITE fails, the device
re-routes the call according to the Standard mode [0]. If DNS
resolution fails, the device attempts to route the call to the Proxy.
If routing to the Proxy also fails, the Redirect / Transfer request is
rejected.
 When this parameter is set to [2], the XferPrefix parameter can
be used to define different routing rules for redirected calls.
 This parameter is ignored if the parameter AlwaysSendToProxy is
set to 1.
Version 6.8
267
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Enable Survivability
CLI: enable-survivability
[IPGroup_EnableSurvivability]
Defines how the device handles registration messages and whether
Survivability mode is enabled for User-type IP Groups.
 [0] Disable (default).
 [1] Enable if Necessary = Survivability mode is enabled only if the
Serving IP Group is unavailable. The device saves in its
Registration database the registration messages sent by the
clients (e.g., IP phones) belonging to the User-type IP Group. If
communication with the Serving IP Group (e.g., IP-PBX) fails, the
User-type IP Group enters into Survivability mode in which the
device uses its database for routing calls between the clients of
the User-type IP Group. In Survivability mode, the RTP packets
between the clients always traverse through the device, and new
registrations can also be processed. When the Serving IP Group
is available again, the device returns to normal mode, sending
INVITE and REGISTER messages to the Serving IP Group.
 [2] Always Enable = Survivability mode is always enabled. The
communication with the Serving IP Group is always considered
as failed. The device uses its database for routing calls between
the clients of the User-type IP Group.
 [3] Always Terminate Register = The registration messages
received from the clients are saved in the device's registration
database without forwarding them to the proxy server. Upon
receipt of the registration message, the device returns a SIP 200
OK to the client.
Notes:
 This parameter is applicable only to the IP-to-IP application.
 This parameter is applicable only to User-type IP Groups.
Serving IP Group ID
CLI: serving-ip-group-id
[IPGroup_ServingIPGroup]
If configured, INVITE messages initiated from the IP Group are sent
to this Serving IP Group (range 1 to 9). In other words, the INVITEs
are sent to the address defined for the Proxy Set associated with this
Serving IP Group. The Request-URI host name in the INVITE
messages are set to the value of the ‘SIP Group Name’ parameter
defined for the Serving IP Group.
Notes:
 This parameter is applicable only to the IP-to-IP application.
 If the PreferRouteTable parameter is set to 1, the routing rules in
the Outbound IP Routing table take precedence over this ‘Serving
IP Group ID’ parameter.
 If this parameter is not configured, the INVITE messages are sent
to the default Proxy or according to the Outbound IP Routing
table.
SBC Parameters
Classify By Proxy Set
Defines whether the incoming INVITE is classified to the IP Group
CLI: classify-by-proxy-set
according to its associated Proxy Set.
[IPGroup_ClassifyByProxySet]  [0] Disable
 [1] Enable (default)
This classification occurs only if classification according to the
device's database fails to (i.e., received INVITE is not from a
registered user). The classification proceeds with checking whether
the INVITE's IP address (if host names, then according to the
dynamically resolved IP address list) is defined for a Proxy Set ID (in
the Proxy Set table). If a Proxy Set ID has such an IP address, the
User's Manual
268
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description
device classifies the INVITE as belonging to the IP Group associated
with this Proxy Set. The Proxy Set ID is assigned to the IP Group
using the IP Group table's 'Proxy Set ID' parameter (see above).
Notes:
 In cases where multiple IP Groups are associated with the same
Proxy Set ID, do not enable this feature. If enabled, the device is
unable to correctly classify the incoming INVITEs to their
appropriate IP Groups.
 To enhance security, it is highly recommended to disable this
parameter so that the device can use the Classification table
rules to classify the call. If this parameter is enabled, the
Classification table is not used if an associated Proxy Set is
found.
 This parameter is applicable only to Server-type IP Groups.
Max. Number of Registered
Users
CLI: max-num-of-reg-users
[IPGroup_MaxNumOfRegUser
s]
Defines the maximum number of users in this IP Group that can
register with the device. By default, no limitation exists for registered
users.
Note: This field is applicable only to User-type IP Groups.
Inbound Message
Manipulation Set
CLI: inbound-mesgmanipulation-set
[IPGroup_InboundManSet]
Assigns a Message Manipulation Set (rule) to the IP Group for SIP
message manipulation on the inbound message. To configure
Message Manipulation rules, see Configuring SIP Message
Manipulation on page 286.
Outbound Message
Manipulation Set
CLI: outbound-mesgmanipulation-set
[IPGroup_OutboundManSet]
Assigns a Message Manipulation Set (rule) to the IP Group for SIP
message manipulation on the outbound message. To configure
Message Manipulation rules, see Configuring SIP Message
Manipulation on page 286.
Registration Mode
CLI: registration-mode
[IPGroup_RegistrationMode]
Defines the registration mode for the IP Group:
 [0] User Initiates Registration (default)
 [1] SBC Initiates Registration = Used when the device serves as
a client (e.g., with an IP PBX). This functions only with the User
Info file.
 [2] Registrations not Needed = The device adds users to its
database in active state.
Version 6.8
269
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Authentication Mode
CLI: authentication-mode
[IPGroup_AuthenticationMode
]
Defines the authentication mode.
 [0] User Authenticates = (Default) The device does not handle the
authentication, but simply passes the authentication messages
between the SIP user agents.
 [1] SBC as Client = The device authenticates as a client. It
receives the 401/407 response from the proxy requesting for
authentication. The device sends the proxy the authorization
credentials (i.e., username and password) according to one of the
following: 1) account defined in the Account table (only if
authenticating Server-type IP Group), 2) global username and
password parameters (only if authenticating Server-type IP
Group), 3) User Information file, or 4) sends request to users
requesting credentials (only if authenticating User-type IP Group).
 [2] SBC as Server = The device acts as an Authentication server:
 Authenticates SIP clients, using the usernames and
passwords in the User Information table (see SBC User
Information for SBC User Database on page 595). This is
applicable only to User-type IP Groups.
 Authenticates SIP severs. This is applicable only to Servertype IP Groups.
Authentication Method List
Defines SIP methods received from the IP Group that must be
CLI: authentication-method-list challenged by the device, when the device acts as an Authentication
[IPGroup_MethodList]
server. If this parameter is not defined (i.e., empty value), no
methods are challenged.
The default value is null. Multiple entries are separated by a
backslash "\", for example, INVITE\REGISTER.
Note: This parameter is applicable only if the 'Authentication Mode'
parameter is set to SBC as Server [2].
SBC Client Forking Mode
CLI: enable-sbc-client-forking
[IPGroup_EnableSBCClientFo
rking]
Defines call forking of INVITE messages to up to five separate SIP
outgoing legs for User-type IP Groups. This occurs if multiple
contacts are registered under the same AOR in the device's
registration database.
 [0] Sequential = (Default) Sequentially sends the INVITE to each
contact. If there is no answer from the first contact, it sends the
INVITE to the second contact, and so on until a contact answers.
If no contact answers, the call fails or is routed to an alternative
destination, if configured.
 [1] Parallel = Sends the INVITE simultaneously to all contacts.
The call is established with the first contact that answers.
 [2] Sequential Available Only = Sequentially sends the INVITE
only to available contacts (i.e., not busy). If there is no answer
from the first available contact, it sends the INVITE to the second
contact, and so on until a contact answers. If no contact answers,
the call fails or is routed to an alternative destination, if
configured.
Note: The device can also fork INVITE messages received for a
Request-URI of a specific contact (user) registered in the database
to all other users located under the same AOR as the specific
contact. This is configured using the SBCSendInviteToAllContacts
parameter.
Source URI Input
CLI: src-uri-input
[IPGroup_SourceUriInput]
Defines the SIP header in the incoming INVITE that is used for call
matching characteristics based on source URIs.
 [-1] Not Configured (default)
User's Manual
270
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description












[0] From
[1] To
[2] Request-URI
[3] P-Asserted - First Header
[4] P-Asserted - Second Header
[5] P-Preferred
[6] Route
[7] Diversion
[8] P-Associated-URI
[9] P-Called-Party-ID
[10] Contact
[11] Referred-by
Notes:
 This parameter is applicable only when classification is done
according to the Classification table.
 If the configured SIP header does not exist in the incoming
INVITE message, the classification of the message to a source IP
Group fails.
 If the device receives an INVITE as a result of a REFER request
or a 3xx response, then the incoming INVITE is routed according
to the Request-URI. The device identifies such INVITEs
according to a specific prefix in the Request-URI header,
configured by the SBCXferPrefix parameter. Therefore, in this
scenario, the device ignores this parameter setting.
Destination URI Input
CLI: dst-uri-input
[IPGroup_DestUriInput]
Version 6.8
Defines the SIP header in the incoming INVITE to use as a call
matching characteristic based on destination URIs. The parameter is
used for classification and routing purposes. The device first uses
the parameter’s settings as a matching characteristic (input) to
classify the incoming INVITE to an IP Group (source IP Group) in the
Classification table. Once classified, the device uses the parameter
for routing the call. For example, if set to To, the URI in the To
header of the incoming INVITE is used as a matching characteristic
for classifying the call to an IP Group in the Classification table. Once
classified, the device uses the URI in the To header as the
destination.
 [-1] Not Configured (default)
 [0] From
 [1] To
 [2] Request-URI
 [3] P-Asserted - First Header
 [4] P-Asserted - Second Header
 [5] P-Preferred
 [6] Route
 [7] Diversion
 [8] P-Associated-URI
 [9] P-Called-Party-ID
 [10] Contact
 [11] Referred-by
Notes:
 The parameter is applicable only when classification is done
271
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
according to the Classification table.
If the configured SIP header does not exist in the incoming
INVITE message, the classification of the message to a source IP
Group fails.
 If the device receives an INVITE as a result of a REFER request
or a 3xx response, the incoming INVITE is routed according to
the Request-URI. The device identifies such INVITEs according
to a specific prefix in the Request-URI header, configured by the
SBCXferPrefix parameter. Therefore, in this scenario, the device
ignores this parameter setting.

Username
CLI: username
[IPGroup_Username]
Defines the shared username for authenticating the IP Group, when
the device acts as an Authentication server.
The valid value is a string of up to 51 characters. By default, no
username is defined.
Notes:
 This parameter is applicable only to Server-type IP Groups and
when the 'Authentication Mode' parameter is set to SBC as
Server (i.e., authentication of servers).
 To specify the SIP request types (e.g., INVITE) that must be
challenged by the device, use the 'Authentication Method List'
parameter.
Password
CLI: password
IPGroup_Password]
Defines the shared password for authenticating the IP Group, when
the device acts as an Authentication server.
The valid value is a string of up to 51 characters. By default, no
password is defined.
Notes:
 This parameter is applicable only to Server-type IP Groups and
when the 'Authentication Mode' parameter is set to SBC as
Server (i.e., authentication of servers).
 To specify the SIP request types (e.g., INVITE) that must be
challenged by the device, use the 'Authentication Method List'
parameter.
17.6
Configuring Proxy Sets
The Proxy Sets table lets you configure up to 100 Proxy Sets. A Proxy Set defines the
destination address (IP address or FQDN) and transport type (e.g., UDP) of a SIP server
(e.g., Proxy). Each Proxy Set can be configured with up to 10 addresses configured as an
IP address and/or DNS host name (FQDN), enabling you to implement load balancing and
redundancy between multiple servers. If you configure the address as an FQDN, you can
configure the method (A-record DNS, SRV, or NAPTR) for resolving the domain name to
an IP address. The device supports up to 30 DNS-resolved IP addresses. (If the DNS
resolution provides more than this number, the device uses the first 30 IP addresses in the
received list, and ignores the rest.)
You can assign each Proxy Set with a specific SSL/TLS certificate (TLS Context), enabling
the use of different certificates per SIP entity (IP Group).
Proxy Sets are later assigned to Server-type IP Groups, in the IP Group table. When the
device sends an INVITE message to an IP Group, it sends it to the address configured for
the Proxy Set. You can also enable the classification of incoming SBC SIP dialogs to IP
Groups based on Proxy Set. If the source address of the incoming SIP dialog is the same
as the address of a Proxy Set that is assigned to an IP Group, the device classifies the SIP
User's Manual
272
Document #: LTRT-27034
User's Manual
17. Control Network
dialog as belonging to that IP Group. This feature is configured using the 'Classify by Proxy
Set' parameter in the IP Group table. For configuring IP Groups, see ''Configuring IP
Groups'' on page 261.
Note: For classifying incoming SIP dialogs to IP Groups, it is highly recommended to
use ONLY the Classification table (see Configuring Classification Rules on page 522).
The following procedure describes how to configure Proxy Sets in the Web interface. You
can also configure Proxy Sets using the following management tools:

Proxy Set ID with IP addresses: table ini file parameter, ProxyIP or CLI command,
configure voip > voip-network proxy-ip > proxy-set-id

Attributes for the Proxy Set: table ini file parameter, ProxySet or CLI command,
configure voip > voip-network proxy-set
 To configure a Proxy Set:
1.
Open the Proxy Sets Table page (Configuration tab > VoIP menu > VoIP Network >
Proxy Sets Table).
Figure 17-6: Proxy Sets Table Page
2.
Configure a Proxy Set according to the parameters described in the table below.
3.
Click Submit, and then save ("burn") your settings to flash memory.
Version 6.8
273
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Table 17-6: Proxy Sets Table Parameter Description
Parameter
Description
Web: Proxy Set ID
EMS: Index
CLI: configure voip > voipnetwork proxy-set
[ProxySet_Index]
Defines an index number for the new table record.
Proxy Address
CLI: voip-network proxy-ip >
proxy-address
[ProxyIp_IpAddress]
Defines the address of the Proxy server. Up to 10 addresses can
be configured per Proxy Set.
The address can be defined as an IP address in dotted-decimal
notation (e.g., 201.10.8.1) or FQDN. You can also specify the port
in the following format:
 IPv4 address: <IP address>:<port> (e.g., 201.10.8.1:5060)
 IPv6 address: <[IPV6 address]>:<port> (e.g.,
[2000::1:200:200:86:14]:5060)
Transport Type
CLI: voip-network proxy-ip >
transport-type
[ProxyIp_TransportType]
Defines the transport type for communicating with the Proxy
server.
 [0] UDP
 [1] TCP
 [2] TLS
 [-1] = Undefined
Note: If this parameter is not defined, the setting of the global
parameter SIPTransportType is used.
Proxy Name
CLI: proxy-name
[ProxySet_ProxyName]
Defines an arbitrary name to easily identify the Proxy Set.
The valid value is a string of up to 20 characters.
DNS Resolve Method
CLI: dns-resolve-method
[ProxySet_DNSResolveMethod
]
Defines the DNS query record type for resolving the Proxy
server's host name into an IP address.
 [-1] = DNS resolving is done according to the settings of the
global parameter, Proxy DNS Query Type.
 [0] A-Record = (Default) A-record DNS query.
 [1] SRV = If the Proxy address is configured with a domain
name without a port (e.g., domain.com), an SRV query is
done. The SRV query returns the host names (and their
weights). The device then performs DNS A-record queries per
host name (according to the received weights). If the
configured Proxy address contains a domain name with a port
(e.g., domain.com:5080), the device performs a regular DNS
A-record query.
 [2] NAPTR = NAPTR query is done. If successful, an SRV
query is sent according to the information received in the
NAPTR response. If the NAPTR query fails, an SRV query is
done according to the configured transport type. If the
configured Proxy address contains a domain name with a port
(e.g., domain.com:5080), the device performs a regular DNS
A-record query. If the transport type is configured for the Proxy
address, a NAPTR query is not performed.
Note: An SRV query can return up to four host names. For each
host name, the subsequent DNS A-record query can be resolved
into up to 15 IP addresses. However, the device supports up to
30 DNS-resolved IP addresses. If the device receives more than
this number of DNS-resolved IP addresses, the device uses the
User's Manual
274
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description
first 30 IP addresses in the received list, and ignores the rest.
Web/EMS: Enable Proxy Keep
Alive
CLI: voip-network proxy-set >
proxy-enable-keep-alive
[ProxySet_EnableProxyKeepAl
ive]
Enables the device's Proxy Keep-Alive mechanism, which checks
communication with the Proxy server.
 [0] Disable (default).
 [1] Using Options = Enables the Proxy Keep-Alive mechanism
using SIP OPTIONS messages. The device sends this
message every user-defined interval, configured by the 'Proxy
Keep Alive Time' parameter. If the device receives a SIP
response code that is also configured in the 'Keep-Alive
Failure Responses' parameter (below), the device considers
the Proxy as down. You can also configure whether to use the
device's IP address or string name ("gateway name") in the
OPTIONS message (see the UseGatewayNameForOptions
parameter).
 [2] Using Register = Enables the Proxy Keep-Alive
mechanism using SIP REGISTER messages. The device
sends the REGISTER message every user-defined interval,
configured by the RegistrationTime parameter (Gateway
application) or SBCProxyRegistrationTime parameter (SBC
application). Any SIP response from the Proxy - success (200
OK) or failure (4xx response) - is considered as if the Proxy is
"alive". If the Proxy does not respond to INVITE messages
sent by the device, the Proxy is considered as down (offline).
If you enable Proxy Keep-Alive mechanism, the device can
operate with multiple Proxy servers (addresses) for redundancy
and load balancing (configured by the 'Proxy Load Balancing
Method' parameter).
Notes:
 For Survivability mode for User-type IP Groups, this parameter
must be enabled (1 or 2).
 If this parameter is enabled and the Proxy uses the TCP/TLS
transport type, you can enable CRLF Keep-Alive mechanism,
using the UsePingPongKeepAlive parameter.
Web: Proxy Keep Alive Time
EMS: Keep Alive Time
CLI: voip-network proxy-set >
proxy-keep-alive-time
[ProxySet_ProxyKeepAliveTim
e]
Defines the interval (in seconds) between Keep-Alive messages
sent by the device when the Keep-Alive mechanism is enabled.
The valid range is 5 to 2,000,000. The default is 60.
Note: This parameter is applicable only if the 'Enable Proxy Keep
Alive' parameter is set to Using Options.
Web: Keep-Alive Failure
Responses
CLI: keepalive-fail-resp
[ProxySet_KeepAliveFailureRe
sp]
Defines SIP response codes that if any is received in response to
a keep-alive message using SIP OPTIONS, the device considers
the Proxy as down.
Up to three response codes can be configured, where each code
is separated by a comma (e.g., 407,404). By default, no
responses are defined. If no responses are configured or
responses received are not those configured, the proxy is
considered "alive".
Note: The SIP 200 response code is not supported by this
feature.
Web: Proxy Load Balancing
Method
EMS: Load Balancing Method
Enables the Proxy Load Balancing mechanism per Proxy Set.
 [0] Disable = Load Balancing is disabled (default)
Version 6.8
275
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
CLI: voip-network proxy-set >
proxy-load-balancing-method
[ProxySet_ProxyLoadBalancin
gMethod]

Web/EMS: Is Proxy Hot Swap
CLI: voip-network proxy-set > isproxy-hot-swap
[ProxySet_IsProxyHotSwap]
Enables the Proxy Hot-Swap redundancy mechanism, which
provides real-time switching from the primary Proxy server to
redundant Proxies when no response is received from the
primary.
 [0] No (default)
 [1] Yes = The device sends the SIP INVITE/REGISTER
message to the first address (Proxy/Registrar server) listed in
the Proxy Set. If a SIP response is received and this response
code is defined in the 'Keep Alive Failure Response'
parameter (above), the device assumes the Proxy as down
and sends the message again; otherwise, the device assumes
the proxy "alive" and does not send the message again. Each
time a defined response code is received, the device re-sends
the message. This can occur until a user-defined maximum
number of retransmissions, configured by the HotSwapRtx
parameter, after which the device sends the same message to
the next address (redundant Proxy/Registrar), and so on. If
there is no response from any of the Proxies, the device goes
through the address list again until a "live" Proxy is located.
Web/EMS: Proxy Redundancy
Mode
CLI: voip-network proxy-set >
proxy-redundancy-mode
[ProxySet_ProxyRedundancyM
ode]
Determines whether the device switches from a redundant Proxy
to the primary Proxy when it becomes available again.
 [-1] Not configured = (Default) The global parameter,
ProxyRedundancyMode applies.
 [0] Parking = The device continues operating with the
redundant (now active) Proxy until the next failure, after which
it operates with the next redundant Proxy.
 [1] Homing = The device always attempts to operate with the
User's Manual
[1] Round Robin = A list of all possible Proxy IP addresses is
compiled. This list includes all IP addresses per Proxy Set
after necessary DNS resolutions (including NAPTR and SRV,
if configured). After this list is compiled, the Proxy Keep-Alive
mechanism (according to parameters EnableProxyKeepAlive
and ProxyKeepAliveTime) tags each entry as 'offline' or
'online'. Load balancing is only performed on Proxy servers
that are tagged as 'online'. All outgoing messages are equally
distributed across the list of IP addresses. REGISTER
messages are also distributed unless a RegistrarIP is
configured. The IP addresses list is refreshed according to
ProxyIPListRefreshTime. If a change in the order of the entries
in the list occurs, all load statistics are erased and balancing
starts over again.
 [2] Random Weights = The outgoing requests are not
distributed equally among the Proxies. The weights are
received from the DNS server, using SRV records. The device
sends the requests in such a fashion that each Proxy receives
a percentage of the requests according to its' assigned weight.
A single FQDN should be configured as a Proxy IP address.
Random Weights Load Balancing is not used in the following
scenarios:
 The Proxy Set includes more than one Proxy IP address.
 The only Proxy defined is an IP address and not an
FQDN.
 SRV is not enabled (DNSQueryType).
 The SRV response includes several records with a
different Priority value.
276
Document #: LTRT-27034
User's Manual
17. Control Network
Parameter
Description
primary Proxy. The device switches back to the primary Proxy
whenever it becomes available.
Notes:
 To enable this functionality, you must also enable the Proxy
Keep-Alive mechanism (using the 'Enable Proxy Keep Alive'
parameter).
 The Homing option can only be used if the 'Enable Proxy
Keep Alive' parameter is set to Using Options.
Web/EMS: SRD Index
CLI: voip-network proxy-set >
srd-id
[ProxySet_SRD]
Assigns an SRD to the Proxy Set ID.
The default is SRD 0.
Notes:
 For this parameter to take effect, a device reset is required.
 To configure SRDs, see Configuring SRDs on page 256.
Web/EMS: Classification Input
CLI: voip-network proxy-set >
classification-input
[ProxySet_ClassificationInput]
Defines how the device classifies IP calls to the Proxy Set.
 [0] IP Only = (Default) The call is classified to the Proxy Set
according to its IP address only.
 [1] IP + Port + Transport = The call is classified to the Proxy
Set according to its IP address, port, and transport type.
Note: This parameter is applicable only if the IP Group table's
parameter, 'Classify by Proxy Set' is set to Enable.
Web/EMS: TLS Context Index
CLI: tls-context-index
[ProxySet_TLSContext]
Assigns a TLS Context (SSL/TLS certificate) to the Proxy Set.
The TLS Context is assigned by index number, as configured in
the TLS Contexts table.
 Incoming calls: If the 'Transport Type' parameter (above) is set
to TLS and the incoming call is successfully classified to an IP
Group based on this Proxy Set, this TLS Context is used. If
the 'Transport Type' parameter is set to UDP or classification
to this Proxy Set fails, this TLS Context is not used. Instead,
the device uses the TLS Context configured for the SIP
Interface (see Configuring SIP Interfaces on page 258) used
for the call; otherwise, the default TLS Context (ID 0) is used.
 Outgoing calls: If the 'Transport Type' parameter (above) is set
to TLS and the outgoing call is sent to an IP Group that is
associated with this Proxy Set, this TLS Context is used.
Instead, the device uses the TLS Context configured for the
SIP Interface (see Configuring SIP Interfaces) used for the
call; otherwise, the default TLS Context (ID 0) is used. If the
'Transport Type' parameter is set to UDP, the device uses
UDP to communicate with the proxy and no TLS Context is
used.
For more information about how certificates are associated with
calls and for configuring TLS Contexts, see Configuring SSL/TLS
Certificates on page 91.
Version 6.8
277
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
278
Document #: LTRT-27034
User's Manual
18
18. SIP Definitions
SIP Definitions
This section describes configuration of SIP parameters.
18.1
Configuring SIP Parameters
Many of the stand-alone SIP parameters associated with various features can be
configured in the following pages:

SIP General Parameters page: Provides SIP parameters for configuring general SIP
features. To access this page, use the following path: Configuration tab > VoIP menu
> SIP Definitions > General Parameters.

SIP Advanced Parameters page: Provides SIP parameters for configuring advanced
SIP features. To access this page, use the following path: Configuration tab > VoIP
menu > SIP Definitions > Advanced Parameters.
For a description of these parameters, refer to the section corresponding to the feature or
see ''Configuration Parameters Reference'' on page 715.
18.2
Configuring Registration Accounts
The Account table lets you configure up to 100 Accounts. An Account defines registration
information for registering and authenticating (digest) "served" Trunk Groups or IP Groups
(e.g., IP PBX) with a "serving" IP Group (e.g., ITSP). Registration information includes a
username, password, host name (AOR), and contact user name (AOR). The device
includes this information in the REGISTER message sent to the "serving" IP Group. Up to
10 Accounts can be configured per "served" Trunk Group or IP Group.
A "served" Trunk Group or IP Group can register to more than one "serving" IP Group (e.g.,
multiple ITSPs). This is done by configuring multiple entries in the Account table for the
same "served" Trunk Group or IP Group, but with different "serving" IP Groups, user
name/password, host name, and contact user values.
Note: If no match is found in the Account table for incoming or outgoing calls, the
username and password is taken from:
• FXS interfaces: Authentication table (see Configuring Authentication on page 460
per Port)
• 'UserName' and 'Password' parameters on the Proxy & Registration page
The following procedure describes how to configure Accounts in the Web interface. You
can also configure Accounts using the table ini file parameter, Account or CLI command,
configure voip > sip-definition account.
 To configure an Account:
1.
Open the Account Table page (Configuration tab > VoIP menu > SIP Definitions >
Account Table).
2.
Click Add; the following dialog box appears:
Version 6.8
279
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Configure an account according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Once you have configured Accounts, you can register or un-register them, as described
below:
 To register or un-register an Account:
1.
In the table, select the required Account entry row.
2.
From the Action drop-down list, choose one of the following commands:
•
Register to register the Account.
•
Un-Register to un-register an Account.
To view Account registration status, see ''Viewing Registration Status'' on page 649.
If all trunks belonging to the Trunk Group are down, the device un-registers them. If any
trunk belonging to the Trunk Group is returned to service, the device registers them again.
This ensures, for example, that the Proxy does not send INVITEs to trunks that are out of
service.
If registration with an IP Group fails for all accounts of a specific Trunk Group that includes
all the channels in the Trunk Group, the Trunk Group is set to Out-Of-Service if the
OOSOnRegistrationFail parameter is set to 1 (see Proxy & Registration Parameters on
page 283).
Table 18-1: Account Table Parameter Descriptions
Parameter
Index
Description
Defines an index for the new table record.
Served Trunk Group
Defines the Trunk Group ID that you want to register and/or
CLI: served-trunk-group
authenticate.
[Account_ServedTrunkGroup]  For Tel-to-IP calls, the served Trunk Group is the source Trunk
Group from where the call originated.
 For IP-to-Tel calls, the served Trunk Group is the Trunk Group ID
to where the call is sent.
Note: This parameter is applicable only to the Gateway application.
Served IP Group
CLI: served-ip-group
[Account_ServedIPGroup]
Defines the IP Group (e.g., IP-PBX) that you want to register and/or
authenticate.
Note: This parameter is applicable only to the SBC and Gateway's
IP-to-IP application.
Serving IP Group
Defines the IP Group to where the device sends the SIP REGISTER
User's Manual
280
Document #: LTRT-27034
User's Manual
18. SIP Definitions
Parameter
Description
CLI: serving-ip-group
[Account_ServingIPGroup]
requests (if enabled) for registration and authentication.
 For Tel-to-IP calls, the serving IP Group is the destination IP
Group configured in the Trunk Group Settings table or Outbound
IP Routing table (see Configuring the Outbound IP Routing Table
on page 383).
 For IP-to-Tel calls, the serving IP Group is the 'Source IP Group
ID' configured in the Inbound IP Routing table (see Configuring the
Inbound IP Routing Table on page 392).
User Name
CLI: user-name
[Account_Username]
Defines the digest MD5 Authentication username.
The valid value is a string of up to 50 characters.
Password
CLI: password
[Account_Password]
Defines the digest MD5 Authentication password.
The valid value is a string of up to 50 characters.
Host Name
CLI: host-name
[Account_HostName]
Defines the Address of Record (AOR) host name. The host name
appears in SIP REGISTER From/To headers as
ContactUser@HostName. For a successful registration, the host
name is also included in the URI of the INVITE From header.
The valid value is a string of up to 49 characters.
Note: If this parameter is not configured or if registration fails, the 'SIP
Group Name' parameter value configured in the IP Group table is
used instead.
Register
CLI: register
[Account_Register]
Enables registration.
 [0] No (Default)
 [1] Regular = Regular registration process. For more information,
see ''Regular Registration Mode'' on page 282.
 [2] GIN = Registration for legacy PBXs, using Global Identification
Number (GIN). For more information, see ''Single Registration for
Multiple Phone Numbers using GIN'' on page 282.
Notes:
 (Gateway application) To enable registration, you also need to set
the 'Registration Mode' parameter to Per Account in the Trunk
Group Settings table (see Configuring Trunk Group Settings on
page 353).
 The Trunk Group account registration is not affected by the
IsRegisterNeeded parameter.
Contact User
CLI: contact-user
[Account_ContactUser]
Defines the AOR username. This appears in REGISTER From/To
headers as ContactUser@HostName, and in INVITE/200 OK Contact
headers as ContactUser@<device's IP address>.
Notes:
 If this parameter is not configured, the 'Contact User' parameter in
the IP Group table is used instead.
 If registration fails, the user part in the INVITE Contact header
contains the source party number.
Application Type
CLI: application-type
[Account_ApplicationType]
Version 6.8
Defines the application type:
[0] GW/IP2IP = (Default) Gateway and IP-to-IP application.
[2] SBC = SBC application.


281
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
18.2.1 Regular Registration Mode
When you configure the registration mode in the Account table to Regular, the device
sends REGISTER requests to the Serving IP Group. The host name (in the SIP From/To
headers) and contact user (user in From/To and Contact headers) are taken from the
configured Account table upon successful registration. See the example below:
REGISTER sip:xyz SIP/2.0
Via: SIP/2.0/UDP 10.33.37.78;branch=z9hG4bKac1397582418
From: <sip:ContactUser@HostName>;tag=1c1397576231
To: <sip: ContactUser@HostName >
Call-ID: 1397568957261200022256@10.33.37.78
CSeq: 1 REGISTER
Contact: <sip:ContactUser@10.33.37.78>;expires=3600
Expires: 3600
User-Agent: Sip-Gateway/v.6.00A.008.002
Content-Length: 0
18.2.2 Single Registration for Multiple Phone Numbers using GIN
When you configure the registration mode in the Account table to GIN, the Global
Identifiable Number (GIN) registration method is used, according to RFC 6140. The device
performs GIN-based registration of users to a SIP registrar on behalf of a SIP PBX. In
effect, the PBX registers with the service provider, just as a directly hosted SIP endpoint
would register. However, because a PBX has multiple user agents, it needs to register a
contact address on behalf of each of these. Rather than performing a separate registration
procedure for each user agents, GIN registration mode does multiple registrations using a
single REGISTER transaction.
According to this mechanism, the PBX delivers to the service provider in the Contact
header field of a REGISTER request a template from which the service provider can
construct contact URIs for each of the AORs assigned to the PBX and thus, can register
these contact URIs within its location service. These registered contact URIs can then be
used to deliver to the PBX inbound requests targeted at the AORs concerned. The
mechanism can be used with AORs comprising SIP URIs based on global E.164 numbers
and the service provider's domain name or sub-domain name.
The SIP REGISTER request sent by the device for GIN registration with a SIP server
provider contains the Require and Proxy-Require headers. These headers contain the
token 'gin'. The Supported header contains the token 'path' and the URI in the Contact
header contains the parameter 'bnc' without a user part:
Contact: <sip:198.51.100.3;bnc>;
The figure below illustrates the GIN registration process:
User's Manual
282
Document #: LTRT-27034
User's Manual
18. SIP Definitions
The figure below illustrates an incoming call using GIN:
18.3
Configuring Proxy and Registration Parameters
The Proxy & Registration page allows you to configure the Proxy server and registration
parameters. For a description of the parameters appearing on this page, see
''Configuration Parameters Reference'' on page 715.
Note: To view the registration status of endpoints with a SIP Registrar/Proxy server,
see Viewing Endpoint Registration Status on page 649.
Version 6.8
283
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure the Proxy and registration parameters:
1.
Open the Proxy & Registration page (Configuration tab > VoIP menu > SIP
Definitions > Proxy & Registration).
2.
Configure the parameters as required.
3.
Click Submit.
 To register or un-register the device to a Proxy/Registrar:

Click the Register button to register.

Click Un-Register button to un-register.
Instead of registering the entire device, you can register specific entities as listed below by
using the Register button located on the page in which these entities are configured:

FXS/FXO endpoints, BRI endpoints, Trunk Groups - Trunk Group table (see
Configuring Trunk Group Table on page 351)

Accounts - Account table (see ''Configuring Registration Accounts'' on page 279)
Click the Proxy Set Table
button to Open the Proxy Sets Table page to configure
groups of proxy addresses. Alternatively, you can open this page from the Proxy Sets
Table page item (see ''Configuring Proxy Sets'' on page 272 for a description of this page).
User's Manual
284
Document #: LTRT-27034
User's Manual
18. SIP Definitions
18.3.1 SIP Message Authentication Example
The device supports basic and digest (MD5) 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 re-send the INVITE with a ProxyAuthorization header containing the credentials.
User agents, Redirect or Registrar servers typically use the SIP 401 Unauthorized
response to challenge authentication containing a WWW-Authenticate header, and expect
the re-INVITE to contain an Authorization header.
The following example shows the Digest Authentication procedure, including computation
of user agent credentials:
1.
The REGISTER request is sent to a Registrar/Proxy server for registration:
REGISTER sip:10.2.2.222 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.200
From: <sip: 122@10.1.1.200>;tag=1c17940
To: <sip: 122@10.1.1.200>
Call-ID: 634293194@10.1.1.200
User-Agent: Sip-Gateway/Medaint 1000B Gateway and
SBC/v.6.60.010.006
CSeq: 1 REGISTER
Contact: sip:122@10.1.1.200:
Expires:3600
2.
Upon receipt of this request, the Registrar/Proxy returns a 401 Unauthorized
response:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.2.1.200
From: <sip:122@10.2.2.222 >;tag=1c17940
To: <sip:122@10.2.2.222 >
Call-ID: 634293194@10.1.1.200
Cseq: 1 REGISTER
Date: Mon, 30 Jul 2012 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
3.
According to the sub-header present in the WWW-Authenticate header, the correct
REGISTER request is created.
4.
Since the algorithm is MD5:
5.
•
The username is equal to the endpoint phone number "122".
•
The realm return by the proxy is "audiocodes.com".
•
The password from the ini file is "AudioCodes".
•
The equation to be evaluated is "122:audiocodes.com:AudioCodes". According to
the RFC, this part is called A1.
•
The MD5 algorithm is run on this equation and stored for future usage.
•
The result is "a8f17d4b41ab8dab6c95d3c14e34a9e1".
The par called A2 needs to be evaluated:
•
Version 6.8
The method type is "REGISTER".
285
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
•
6.
Using SIP protocol "sip".
•
Proxy IP from ini file is "10.2.2.222".
•
The equation to be evaluated is "REGISTER:sip:10.2.2.222".
•
The MD5 algorithm is run on this equation and stored for future usage.
•
The result is "a9a031cfddcb10d91c8e7b4926086f7e".
Final stage:
•
A1 result: The nonce from the proxy response is
"11432d6bce58ddf02e3b5e1c77c010d2".
•
A2 result: The equation to be evaluated is
"A1:11432d6bce58ddf02e3b5e1c77c010d2:A2".
•
The MD5 algorithm is run on this equation. The outcome of the calculation is the
response needed by the device to register with the Proxy.
•
The response is "b9c45d0234a5abf5ddf5c704029b38cf".
At this time, a new REGISTER request is issued with the following response:
REGISTER sip:10.2.2.222 SIP/2.0
Via: SIP/2.0/UDP 10.1.1.200
From: <sip: 122@10.1.1.200>;tag=1c23940
To: <sip: 122@10.1.1.200>
Call-ID: 654982194@10.1.1.200
Server: Audiocodes-Sip-Gateway/Medaint 1000B Gateway and
SBC/v.6.60.010.006
CSeq: 1 REGISTER
Contact: sip:122@10.1.1.200:
Expires:3600
Authorization: Digest, username: 122,
realm="audiocodes.com”,
nonce="11432d6bce58ddf02e3b5e1c77c010d2",
uri=”10.2.2.222”,
response=“b9c45d0234a5abf5ddf5c704029b38cf”
7.
18.4
Upon receiving this request and if accepted by the Proxy, the Proxy returns a 200 OK
response, completing the registration transaction:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.200
From: <sip: 122@10.1.1.200>;tag=1c23940
To: <sip: 122@10.1.1.200>
Call-ID: 654982194@10.1.1.200
Cseq: 1 REGISTER
Date: Thu, 26 Jul 2012 09:34:42 GMT
Server: Columbia-SIP-Server/1.17
Content-Length: 0
Contact: <sip:122@10.1.1.200>; expires="Thu, 26 Jul 2012
10:34:42 GMT"; action=proxy; q=1.00
Contact: <122@10.1.1.200:>; expires="Tue, 19 Jan 2038 03:14:07
GMT"; action=proxy; q=0.00
Expires: Thu, 26 Jul 2012 10:34:42 GMT
Configuring SIP Message Manipulation
The Message Manipulations table lets you configure up to 100 Message Manipulation
rules. A Message Manipulation rule defines a manipulation sequence for SIP messages.
SIP message manipulation enables the normalization of SIP messaging fields between
communicating network segments. For example, it allows service providers to design their
own policies on the SIP messaging fields that must be present before a SIP call enters
their network. Similarly, enterprises and small businesses may have policies for the
User's Manual
286
Document #: LTRT-27034
User's Manual
18. SIP Definitions
information that can enter or leave their networks for policy or security reasons from a
service provider. SIP message manipulations can also be implemented to resolve
incompatibilities between SIP devices inside the enterprise network.
Each Message Manipulation rule is configured with a Manipulation Set ID. You can create
groups (sets) of Message Manipulation rules by assigning each of the relevant Message
Manipulation rules to the same Manipulation Set ID. The Manipulation Set ID is used to
assign the rules to specific calls.


SBC application: Message manipulation rules can be applied pre- or postclassification:
•
Pre-classification Process: Message manipulation can be done on incoming
SIP dialog-initiating messages (e.g., INVITE) prior to the classification process.
You configure this by assigning the Manipulation Set ID to the SIP Interface on
which the call is received (see Configuring SIP Interfaces on page 258).
•
Post-classification Process: Message manipulation can be done on inbound
and/or outbound SIP messages after the call has been successfully classified.
You configure this by assigning the Manipulation Set ID to the relevant IP Group
in the IP Group table (see Configuring IP Groups on page 261).
Gateway application: Message Manipulation rules are applied to calls as follows:
•
Manipulating Inbound SIP INVITE Messages: Message manipulation can be
applied only to all inbound calls (not specific calls). This is done by assigning a
Manipulation Set ID to the "global" ini file parameter,
GWInboundManipulationSet.
•
Manipulating Outbound SIP INVITE Messages:
a. Message manipulation can be done for specific calls, by assigning a
Manipulation Set ID to an IP Group in the IP Group table, using the
'Outbound Message Manipulation Set' parameter.
b. Message manipulation can be applied to all outbound calls (except for IP
Groups that have been assigned a Manipulation Set ID). This is done by
assigning a Manipulation Set ID to the "global" ini file parameter,
GWOutboundManipulationSet.
The device also supports a built-in SIP message normalization feature that can be enabled
per Message Manipulation rule. The normalization feature removes unknown SIP message
elements before forwarding the message. These elements can include SIP headers, SIP
header parameters, and SDP body fields.
The SIP message manipulation feature supports the following:

Manipulation on SIP message type (Method, Request/Response, and Response type)

Addition of new SIP headers

Removal of SIP headers ("black list")

Modification of SIP header components such as values, header values (e.g., URI
value of the P-Asserted-Identity header can be copied to the From header), call's
parameter values

Deletion of SIP body (e.g., if a message body is not supported at the destination
network this body is removed)

Translating one SIP response code to another

Topology hiding (generally present in SIP headers such as Via, Record Route, Route
and Service-Route).

Configurable identity hiding (information related to identity of subscribers, for example,
P-Asserted-Identity, Referred-By, Identity and Identity-Info)

Apply conditions per rule - the condition can be on parts of the message or call’s
parameters

Multiple manipulation rules on the same SIP message
Version 6.8
287
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The figure below illustrates a SIP message manipulation example:
Figure 18-1: SIP Header Manipulation Example
Notes:
• For a detailed description of the syntax used for configuring Message Manipulation
rules, refer to the SIP Message Manipulations Quick Reference Guide.
• For the SBC application, Inbound message manipulation is done only after the
Classification, inbound/outbound number manipulations, and routing processes.
• Each message can be manipulated twice - on the source leg and on the
destination leg (i.e., source and destination IP Groups).
• Unknown SIP parts can only be added or removed.
• SIP manipulations do not allow you to remove or add mandatory SIP headers.
They can only be modified and only on requests that initiate new dialogs.
Mandatory SIP headers include To, From, Via, CSeq, Call-Id, and Max-Forwards.
User's Manual
288
Document #: LTRT-27034
User's Manual
18. SIP Definitions
The following procedure describes how to configure Message Manipulation rules in the
Web interface. You can also configure Message Manipulation rules using the table ini file
parameter, MessageManipulations or CLI command, configure voip > sbc manipulations
message-manipulations.
 To configure SIP message manipulation rules:
1.
Open the Message Manipulations page (Configuration tab > VoIP menu > SIP
Definitions > Msg Policy & Manipulation > Message Manipulations).
2.
Click Add; the following dialog box appears:
Figure 18-2: Message Manipulations Table - Add Record Dialog Box
3.
Configure a Message Manipulation rule according to the parameters described in the
table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
An example of configured message manipulation rules are shown in the figure below:
Figure 18-3: Message Manipulations Page

Index 0: Adds the suffix ".com" to the host part of the To header.

Index 1: Changes the user part of the From header to the user part of the P-AssertedID.

Index 2: Changes the user part of the SIP From header to "200".

Index 3: If the user part of the From header equals "unknown", then it is changed
according to the srcIPGroup call’s parameter.

Index 4: Removes the Priority header from an incoming INVITE message.
Version 6.8
289
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Table 18-2: Message Manipulations Parameter Descriptions
Parameter
Description
Index
[MessageManipulations_Index]
Defines an index number for the new table record.
Note: Each rule must be configured with a unique index.
Manipulation Name
CLI: manipulation-name
[MessageManipulations_Manipulati
onName]
Defines an arbitrary name to easily identify the Message
Manipulation rule.
The valid value is a string of up to 16 characters.
Manipulation Set ID
CLI: manipulation-set-id
[MessageManipulations_ManSetID]
Defines a Manipulation Set ID for the rule. You can define
the same Manipulation Set ID for multiple rules to create a
group of rules. The Manipulation Set ID is used to assign the
manipulation rules to an IP Group (in the IP Group table) for
inbound and/or outbound messages.
The valid value is 0 to 19. The default is 0.
Matching Characteristics
Message Type
CLI: message-type
[MessageManipulations_MessageT
ype]
Defines the SIP message type that you want to manipulate.
The valid value is a string (case-insensitive) denoting the SIP
message.
For example:
 Empty = rule applies to all messages
 Invite = rule applies to all INVITE requests and responses
 Invite.Request = rule applies to INVITE requests
 Invite.Response = rule applies to INVITE responses
 subscribe.response.2xx = rule applies to SUBSCRIBE
confirmation responses
Note: Currently, SIP 100 Trying messages cannot be
manipulated.
Condition
CLI: condition
[MessageManipulations_Condition]
Defines the condition that must exist for the rule to apply.
The valid value is a string (case-insensitive).
For example:
 header.from.url.user== '100' (indicates that the user part
of the From header must have the value "100")
 header.contact.param.expires > '3600'
 header.to.url.host contains 'domain'
 param.call.dst.user != '100'
Operation
Action Subject
Defines the SIP header upon which the manipulation is
CLI: action-subject
performed.
[MessageManipulations_ActionSubj The valid value is a string (case-insensitive).
ect]
Action Type
CLI: action-type
[MessageManipulations_ActionTyp
e]
User's Manual
Defines the type of manipulation.
 [0] Add (default) = Adds new header/param/body (header
or parameter elements).
 [1] Remove = Removes header/param/body (header or
parameter elements).
 [2] Modify = Sets element to the new value (all element
types).
 [3] Add Prefix = Adds value at the beginning of the string
290
Document #: LTRT-27034
User's Manual
18. SIP Definitions
Parameter
Description
(string element only).
[4] Add Suffix = Adds value at the end of the string (string
element only).
 [5] Remove Suffix = Removes value from the end of the
string (string element only).
 [6] Remove Prefix = Removes value from the beginning
of the string (string element only).
 [7] Normalize = Removes unknown SIP message
elements before forwarding the message.

Action Value
Defines a value that you want to use in the manipulation.
CLI: action-value
The default value is a string (case-insensitive) in the
[MessageManipulations_ActionValu following syntax:
e]
 string/<message-element>/<call-param> +
 string/<message-element>/<call-param>
For example:
 'itsp.com'
 header.from.url.user
 param.call.dst.user
 param.call.dst.host + '.com'
 param.call.src.user + '<' + header.from.url.user + '@' +
header.p-asserted-id.url.host + '>'
Note: Only single quotation marks must be used.
Row Role
CLI: row-role
[MessageManipulations_RowRole]
18.5
Determines which condition must be used for the rule of this
table row.
 [0] Use Current Condition = The condition entered in this
row must be matched in order to perform the defined
action (default).
 [1] Use Previous Condition = The condition of the rule
configured directly above this row must be used in order
to perform the defined action. This option allows you to
configure multiple actions for the same condition.
Note: When multiple manipulations rules apply to the same
header, the next rule applies to the result string of the
previous rule.
Configuring SIP Message Policy Rules
The Message Policy table lets you configure up to 20 SIP Message Policy rules. SIP
Message Policy rules are used to block (blacklist) unwanted incoming SIP messages or
permit (whitelist) receipt of desired SIP messages. You can configure legal and illegal
characteristics of a SIP message. This feature is helpful against VoIP fuzzing (also known
as robustness testing), which sends different types of packets to its "victims" for finding
bugs and vulnerabilities. For example, the attacker might try sending a SIP message
containing either an oversized parameter or too many occurrences of a parameter.
To apply SIP Message Policy rules, you need to assign them to SIP Interfaces associated
with the relevant IP Groups (see ''Configuring SIP Interfaces'' on page 258).
Each Message Policy rule can be configured with the following:

Maximum message length

Maximum header length
Version 6.8
291
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Maximum message body length

Maximum number of headers

Maximum number of bodies

Option to send 400 "Bad Request" response if message request is rejected

Blacklist and whitelist for defined methods (e.g., INVITE)

Blacklist and whitelist for defined bodies
The following procedure describes how to configure Message Policy rules in the Web
interface. You can also configure Message Policy rules using the table ini file parameter,
MessagePolicy or the CLI command, configure voip > sbc message-policy.
 To configure SIP Message Policy rules:
1.
Open the Message Policy Table page (Configuration tab > VoIP menu > SIP
Definitions > Msg Policy & Manipulation > Message Policy Table).
2.
Click Add; the following dialog box appears:
Figure 18-4: Message Policy Table - Add Record Dialog Box
3.
Configure a Message Policy rule according to the parameters described in the table
below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 18-3: Message Policy Table Parameter Descriptions
Parameter
Index
[MessagePolicy_Index]
Description
Defines an index number for the new table record.
Max Message Length
Defines the maximum SIP message length.
CLI: max-message-length
The valid value is up to 32,768 characters. The default is
[MessagePolicy_MaxMessageLength] 32,768.
Max Header Length
CLI: max-header-length
[MessagePolicy_MaxHeaderLength]
Defines the maximum SIP header length.
The valid value is up to 512 characters. The default is 512.
Max Body Length
CLI: max-body-length
[MessagePolicy_MaxBodyLength]
Defines the maximum SIP message body length. This is
the value of the Content-Length header.
The valid value is up to 1,024 characters. The default is
1,024.
User's Manual
292
Document #: LTRT-27034
User's Manual
18. SIP Definitions
Parameter
Description
Max Num Headers
CLI: max-num-headers
[MessagePolicy_MaxNumHeaders]
Defines the maximum number of SIP headers.
The valid value is any number up to 32. The default is 32.
Note: The device supports up to 20 SIP Record-Route
headers that can be received in a SIP INVITE request or
200 OK response. If it receives more than this, it responds
with a SIP 513 'Message Too Large' response.
Max Num Bodies
CLI: max-num-bodies
[MessagePolicy_MaxNumBodies]
Defines the maximum number of bodies (e.g., SDP) in the
SIP message.
The valid value is any number up to 8. The default is 8.
Send Rejection
CLI: send-rejection
[MessagePolicy_SendRejection]
Determines whether the device sends a 400 "Bad
Request" response if a message request is rejected.
 [0] Policy Reject = (Default) If the message is a request,
then the device sends a response to reject the request.
 [1] Policy Drop = The device ignores the message
without sending any response.
SIP Method Blacklist-Whitelist Policy
Method List
CLI: method-list
[MessagePolicy_MethodList]
Defines SIP methods (e.g., INVITE\BYE) to blacklist or
whitelist.
Multiple methods are separated by a backslash (\). The
method values are case-insensitive.
Method List Type
CLI: method-list-type
[MessagePolicy_MethodListType]
Defines the policy (blacklist or whitelist) for the SIP
methods specified in the 'Method List' parameter (above).
 [0] Policy Blacklist = The specified methods are
rejected.
 [1] Policy Whitelist = (Default) Only the specified
methods are allowed; the others are rejected.
SIP Body Blacklist-Whitelist Policy
Body List
CLI: body-list
[MessagePolicy_BodyList]
Defines the SIP body type (i.e., value of the Content-Type
header) to blacklist or whitelist. For example,
application/sdp.
The values of this parameter are case-sensitive.
Body List Type
CLI: body-list-type
[MessagePolicy_BodyListType]
Defines the policy (blacklist or whitelist) for the SIP body
specified in the 'Body List' parameter (above).
 [0] Policy Blacklist =The specified SIP body is rejected.
 [1] Policy Whitelist = (Default) Only the specified SIP
body is allowed; the others are rejected.
Version 6.8
293
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
294
Document #: LTRT-27034
User's Manual
19
19. Coders and Profiles
Coders and Profiles
This section describes configuration of the coders and SIP profiles parameters.
19.1
Configuring Default Coders
The Coders table lets you configure up to 10 voice coders for the device. This is the default
Coder Group, which is used by the device for all calls, unless a different Coder Group,
configured in the Coder Group Settings table (see ''Configuring Coder Groups'' on page
298) is assigned to specific calls, using Tel or IP Profiles.
Each coder can be configured with packetization time (ptime), bit rate, payload type, and
silence suppression. The first coder configured in the table has the highest priority and is
used by the device whenever possible. If the remote side cannot use the first coder, the
device attempts to use the next coder in the table, and so on.
Notes:
• Only the packetization time of the first coder in the coder list is declared in
INVITE/200 OK SDP, even if multiple coders are defined. The device always uses
the packetization time requested by the remote side for sending RTP packets. If
not specified, the packetization time is assigned the default value.
• The value of several fields is hard-coded according to common standards (e.g.,
payload type of G.711 U-law is always 0). Other values can be set dynamically. If
no value is specified for a dynamic field, a default value is assigned. If a value is
specified for a hard-coded field, the value is ignored.
• The G.722 coder provides Packet Loss Concealment (PLC) capabilities, ensuring
higher voice quality.
• For information on V.152 and implementation of T.38 and VBD coders, see
''Supporting V.152 Implementation'' on page 168.
The following procedure describes how to configure the Coders table in the Web interface.
You can also configure this table using the table ini file parameter, CodersGroup0 or CLI
command, configure voip > coders-and-profiles coders-group.
 To configure coders:
1.
Open the Coders page (Configuration tab > VoIP menu > Coders and Profiles >
Coders).
Figure 19-1: Coders Table Page
Version 6.8
295
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
2.
Configure coders according to the parameters described in the table below.
3.
Click Submit, and then reset the device with a save ("burn") to flash memory.
Table 19-1: Coders Table Parameter Descriptions
Parameter
Description
Coder Name
CLI: name
[CodersGroup0_Name]
Defines the coder.
Note: Each coder type (e.g., G.729) can be configured only once
in the table.
Packetization Time
CLI: p-time
[CodersGroup0_pTime]
Defines the packetization time (in msec) for the coder. The
packetization time determines how many coder payloads are
combined into a single RTP packet.
Rate
CLI: rate
[CodersGroup0_rate]
Defines the bit rate (in kbps) for the coder.
Payload Type
CLI: payload-type
[CodersGroup0_PayloadType]
Defines the payload type if the payload type (i.e., format of the
RTP payload) for the coder is dynamic.
Note: Both GSM-FR and MS-GSM coders use Payload Type 3.
When using SDP, it is not possible to differentiate between the
two. Thus, it is recommended to configure only one of these
coders in the table.
Silence Suppression
CLI: silence-suppression
[CodersGroup0_Sce]
Enables silence suppression for the coder.
 [0] Disable (Default)
 [1] Enable
 [2] Enable w/o Adaptation =Applicable only to G.729.
Notes:
 If silence suppression is not configured for a coder, the
settings of the EnableSilenceCompression parameter is used.
 If G.729 is configured with silence suppression disabled, the
device includes 'annexb=no' in the SDP of the relevant SIP
messages. If silence suppression is enabled or set to Enable
w/o Adaptations, 'annexb=yes' is included. An exception to
this logic is when the remote gateway is Cisco equipment
(IsCiscoSCEMode).
The table below lists the supported coders:
Table 19-2: Supported Coders
Coder Name
Packetization Time
(msec)
Rate (kbps)
Payload
Type
Silence
Suppression
G.711 A-law
[g711Alaw64k]
10, 20 (default), 30, 40,
50, 60, 80, 100, 120
64
8


[0] Disable
[1] Enable
G.711 U-law
[g711Ulaw64k]
10, 20 (default), 30, 40,
50, 60, 80, 100, 120
64
0


[0] Disable
[1] Enable
G.711A-law_VBD
[g711AlawVbd]
10, 20 (default), 30, 40,
50, 60, 80, 100, 120
64
Dynamic (0- N/A
127);
Default 180
G.711U-law_VBD
[g711UlawVbd]
10, 20 (default), 30, 40,
50, 60, 80, 100, 120
64
Dynamic (0- N/A
127);
Default 120
User's Manual
296
Document #: LTRT-27034
User's Manual
Coder Name
19. Coders and Profiles
Packetization Time
(msec)
Rate (kbps)
Payload
Type
Silence
Suppression
G.722
[g722]
20 (default), 40, 60, 80,
100, 120
64 (default)
9
N/A
G.723.1
[g7231]
30 (default), 60, 90, 120,
150

[0] 5.3
(default)
 [1] 6.3
4


G.726
[g726]
10, 20 (default), 30, 40,
50, 60, 80, 100, 120



[0] 16
[1] 24
[2] 32
(default)
 [3] 40
Dynamic (0-  [0] Disable
127);
 [1] Enable
Default 23
G.727 ADPCM
10, 20 (default), 30, 40,
50, 60, 80, 100, 120
16, 24, 32, 40
Dynamic (0-  [0] Disable
127)
 [1] Enable
G.729
[g729]
10, 20 (default), 30, 40,
50, 60, 80, 100
8
18



[0] Disable
[1] Enable
[2] Enable
w/o
Adaptation
s
GSM-FR
[gsmFullRate]
20 (default), 40, 60, 80
13
3


[0] Disable
[1] Enable
GSM-EFR
0, 20 (default), 30, 40, 50,
[gsmEnhancedFullRate] 60, 80, 100
12.2
Dynamic (0-  [0] Disable
127)
 [1] Enable
MS-GSM
[gsmMS]
40 (default)
13
3
AMR
[Amr]
20 (default)








QCELP
[QCELP]
20 (default), 40, 60, 80,
100, 120
13
12
EVRC
[Evrc]
20 (default), 40,60, 80,
100

[0] Variable
(default)
 [1] 1/8
 [3] 1/2
 [4] Full
Dynamic (0-  [0] Disable
127)
 [1] Enable
iLBC
[iLBC]
20 (default), 40, 60, 80,
100, 120
15 (default)
30 (default), 60, 90, 120
13
Dynamic (0-  [0] Disable
127);
 [1] Enable
Default 65
10, 20 (default), 40, 60,
80, 100, 120
64
Transparent
[Transparent]
Version 6.8
297
[0] 4.75
[1] 5.15
[2] 5.90
[3] 6.70
[4] 7.40
[5] 7.95
[6] 10.2
[7] 12.2
(default)


[0] Disable
[1] Enable
[0] Disable
[1] Enable
Dynamic (0-  [0] Disable
127)
 [1] Enable


[0] Disable
[1] Enable
Dynamic (0-  [0] Disable
127)
 [1] Enable
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Coder Name
Packetization Time
(msec)
Rate (kbps)
Payload
Type
Silence
Suppression
T.38
[t38fax]
N/A
N/A
N/A
N/A
T.38 Over RTP
N/A
N/A
Dynamic
(90 - 127);
Default 106
N/A
19.2
Configuring Coder Groups
The Coder Group Settings table lets you configure up to 10 Coder Groups. A Coder Group
is a set of configured coders (coder type, packetization time, rate, payload type, and
silence suppression). Each Coder Group can include up to 10 coders.
The first coder in the Coder Group has the highest priority and is used by the device
whenever possible. If the remote side cannot use the first coder, the device attempts to use
the next coder in the Coder Group, and so on.
To define coders for specific calls, you can configure a Coder Group with the necessary
coders and then assign the Coder Group to the calls using Tel Profiles (see Configuring Tel
Profiles on page 299) or IP Profiles (see ''Configuring IP Profiles'' on page 302). In this
configuration, Coder Groups can be used as Extension Coders and/or Allowed Coders for
the SBC application.
Notes:
• To define coders for calls that are not assigned a specific Coder Group using Tel
Profiles or IP Profiles, see ''Configuring Default Coders'' on page 295. This group
of coders is termed the Default Coder Group.
• For a list of supported coders, see ''Configuring Default Coders'' on page 295.
The following procedure describes how to configure the Coders table in the Web interface.
You can also configure this table using the table ini file parameter, CodersGroupX or CLI
command, configure voip > coders-and-profiles coders-group.
 To configure a Coder Group:
1.
Open the Coder Group Settings page (Configuration tab > VoIP menu > Coders and
Profiles > Coders Group Settings).
Figure 19-2: Coder Group Settings Page
User's Manual
298
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
2.
Configure the Coder Group according to the parameters described in the table below.
3.
Click Submit, and then reset the device with a save ("burn") to flash memory.
Table 19-3: Coder Group Settings Table Parameter Descriptions
Parameter
Description
Coder Group ID
[CodersGroupX_Index]
Defines an ID for the Coder Group.
Coder Name
CLI: name
[CodersGroupX_Name]
Defines the coder type.
Note: Each coder type (e.g., G.729) can be configured only once
in the table.
Packetization Time
CLI: p-time
[CodersGroupX_pTime]
Defines the packetization time (in msec) for the coder. The
packetization time determines how many coder payloads are
combined into a single RTP packet.
Rate
CLI: rate
[CodersGroupX_rate]
Defines the bit rate (in kbps) for the coder.
Payload Type
CLI: payload-type
[CodersGroupX_PayloadType]
Defines the payload type if the payload type (i.e., format of the
RTP payload) for the coder is dynamic.
Silence Suppression
CLI: silence-suppression
[CodersGroupX_Sce]
Enables silence suppression for the coder.
 [0] Disable (Default)
 [1] Enable
 [2] Enable w/o Adaptation =Applicable only to G.729.
Notes:
 If silence suppression is not configured for a coder, the
settings of the EnableSilenceCompression parameter is used.
19.3
Configuring Tel Profile
The Tel Profile Settings table lets you configure up to nine Tel Profiles. A Tel Profile is a set
of parameters with specific settings which can be assigned to specific calls. The Tel Profile
Settings table includes a wide range of parameters for configuring the Tel Profile. Each of
these parameters has a corresponding "global" parameter, which when configured applies
to all calls. The main difference, if any, between the Tel Profile parameters and their
corresponding global parameters are their default values.
Tel Profiles provide high-level adaptation when the device interworks between different
equipment and protocols (at both the Tel and IP sides), each of which may require different
handling by the device. For example, if specific channels require the use of the G.711
coder, you can configure a Tel Profile with this coder and assign it to these channels.
To use your Tel Profile for specific calls, you need to assign it to specific channels (trunks)
in the Trunk Group table (see Configuring Trunk Group Table on page 351)).
The following procedure describes how to configure Tel Profiles in the Web interface. You
can also configure Tel Profiles using the table ini file parameter, TelProfile or CLI
command, configure voip/coders-and-profiles tel-profile.
 To configure a Tel Profile:
1.
Open the Tel Profile Settings page (Configuration tab > VoIP menu > Coders and
Profiles > Tel Profile Settings).
2.
Click Add; the following dialog box appears:
Version 6.8
299
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
3.
Configure a Tel Profile according to the parameters described in the table below. For a
description of each parameter, refer to the corresponding "global" parameter.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 19-4: Tel Profile Table Parameters and Corresponding Global Parameters
Tel Profile Parameter
Global Parameter
Common
Web: Index
[TelProfile_Index]
Defines an index number for the new table record.
Web: Profile Name
CLI: profile-name
[TelProfile_ProfileName]
Defines an arbitrary name to easily identify the Tel Profile.
Web: Profile Preference
CLI: tel-preference
[TelProfile_TelPreference]
Defines the priority of the Tel Profile, where 1 is the lowest priority and 20
the highest priority.
The valid value is a string of up to 20 characters.
Notes:
1. If both the IP Profile and Tel Profile apply to the same call, the coders and
common parameters of the Preferred profile are applied to the call.
2. If the Preference of the Tel Profile and IP Profile are identical, the Tel
Profile parameters are applied.
3. If the coder lists of both the IP Profile and Tel Profile apply to the same
call, only the coders common to both are used. The order of the coders is
determined by the preference.
Web: Fax Signaling Method
CLI: fax-sig-method
[TelProfile_IsFaxUsed]
IsFaxUsed
Web: Enable Digit Delivery
CLI: digit-delivery
[TelProfile_EnableDigitDelivery]
EnableDigitDelivery
Web: Time For Reorder Tone
CLI: time-for-reorder-tone
[TelProfile_TimeForReorderTone]
TimeForReorderTone
Web: Disconnect Call on Detection of Busy
Tone
CLI: disconnect-on-busy-tone
[TelProfile_DisconnectOnBusyTone]
DisconnectOnBusyTone
User's Manual
300
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Tel Profile Parameter
Global Parameter
Web: Enable Voice Mail Delay
CLI: enable-voice-mail-delay
[TelProfile_EnableVoiceMailDelay]
VoiceMailInterface
Web: Dial Plan Index
CLI: dial-plan-index
[TelProfile_DialPlanIndex]
DialPlanIndex
Web: Swap Tel To IP Phone Numbers
CLI: swap-teltoip-phone-numbers
[TelProfile_SwapTelToIpPhoneNumbers]
SwapTEl2IPCalled&CallingNumbers
Web: Digital Cut Through
CLI: digital-cut-through
[TelProfile_DigitalCutThrough]
DigitalCutThrough
Web: Call Priority Mode
CLI: call-priority-mode
[TelProfile_CallPriorityMode]
CallPriorityMode
This is useful for disabling voice mail services per Trunk Group to eliminate
the phenomenon of call delay on Trunks that do not implement voice mail
when voice mail is enabled using the global parameter.
IP Related
Web: Coders Group ID
CLI: coders-group-id
[TelProfile_CodersGroupID]
CodersGroup0
Web: RTP IP DiffServ
CLI: rtp-ip-diffserv
[TelProfile_IPDiffServ]
PremiumServiceClassMediaDiffServ
Web: Signaling DiffServ
CLI: signaling-diffserv
[TelProfile_SigIPDiffServ]
PremiumServiceClassControlDiffServ
Web: Enable Early Media
CLI: early-media
[TelProfile_EnableEarlyMedia]
EnableEarlyMedia
Web: Progress Indicator to IP
CLI: prog-ind-to-ip
[TelProfile_ProgressIndicator2IP]
ProgressIndicator2IP
Channel
Web: Dynamic Jitter Buffer Minimum Delay
CLI: jitter-buffer-minimum-delay
[TelProfile_JitterBufMinDelay]
DJBufMinDelay
Web: Dynamic Jitter Buffer Optimization Factor
CLI: jitter-buffer-optimization-factor
[TelProfile_JitterBufOptFactor]
DJBufOptFactor
Web: DTMF Volume
CLI: dtmf-volume
[TelProfile_DtmfVolume]
DTMFVolume
Web: Input Gain
CLI: input-gain
[TelProfile_InputGain]
InputGain
Web: Voice Volume
CLI: voice-volume
[TelProfile_VoiceVolume]
VoiceVolume
Web: Echo Canceler
CLI: echo-canceller
[TelProfile_EnableEC]
EnableEchoCanceller
Web: Enable AGC
CLI: enable-agc
[TelProfile_EnableAGC]
EnableAGC
Version 6.8
301
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Tel Profile Parameter
Web: EC NLP Mode
CLI: echo-canceller-nlp-mode
[TelProfile_ECNlpMode]
Global Parameter
ECNLPMode
Analog
Web: Enable Polarity Reversal
CLI: polarity-rvrsl
[TelProfile_EnableReversePolarity]
EnableReversalPolarity
Web: Enable Current Disconnect
CLI: current-disconnect
[TelProfile_EnableCurrentDisconnect]
EnableCurrentDisconnect
Web: MWI Analog Lamp
CLI: mwi-analog-lamp
[TelProfile_MWIAnalog]
MWIAnalogLamp
Web: MWI Display
CLI: mwi-display
[TelProfile_MWIDisplay]
MWIDisplay
Web: Flash Hook Period
CLI: flash-hook-period
[TelProfile_FlashHookPeriod]
FlashHookPeriod
Web: DID Wink
CLI: enable-did-wink
[TelProfile_EnableDIDWink]
EnableDIDWink
Web: Two Stage Dialing
CLI: is-two-stage-dial
[TelProfile_IsTwoStageDial]
IsTwoStageDial
Web: Enable 911 PSAP
CLI: enable-911-psap
[TelProfile_Enable911PSAP]
Enable911PSAP
Web: FXO Double Answer
CLI: fxo-double-answer
[TelProfile_EnableFXODoubleAnswer]
EnableFXODoubleAnswer
Web: FXO Ring Timeout
CLI: fxo-ring-timeout
[TelProfile_FXORingTimeout]
FXORingTimeout
19.4
Note: If this parameter is configured for a specific FXO port, Caller ID
detection does not occur, and the RingBeforeCallerID and
FXONumberOfRings parameters do not affect the outgoing INVITE for that
FXO port.
Configuring IP Profiles
The IP Profile Settings table lets you configure up to 40 IP Profiles. An IP Profile is a set of
parameters with user-defined settings relating to signaling (e.g., SIP message terminations
such as REFER) and media (e.g., coder type). An IP Profile can later be assigned to
specific IP calls (inbound and/or outbound). Thus, IP Profiles provide high-level adaptation
when the device interworks between different IP entities, each of which may require
different handling by the device. This can include, for example, transcoding or even
transrating (of packetization time). For example, if a specific IP entity uses the G.711 coder
only, you can configure an IP Profile with G.711 for this IP entity.
To use your IP Profile for specific calls, you need to assign it to any of the following:

IP Groups - see ''Configuring IP Groups'' on page 261

Gateway application: Outbound IP routing rules - see Configuring Outbound IP
Routing Table on page 383

Gateway application: Inbound IP routing rules - see Configuring Inbound IP Routing
Table on page 392
User's Manual
302
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
The device selects the IP Profile as follows:

If you assign different IP Profiles (not default) to the same specific calls in all of the
above-mentioned tables, the device uses the IP Profile that has the highest preference
level (as set in the 'Profile Preference' parameter). If these IP Profiles have the same
preference level, the device uses the IP Profile that you assigned in the IP Group
table.

If you assign different IP Profiles to all of the above-mentioned tables and one table is
set to the default IP Profile, the device uses the IP Profile that is not the default.
Many of the parameters in the IP Profile table have a corresponding "global" parameter.
For calls that are not associated with any IP Profile, the settings of the "global" parameters
are applied.
Note: IP Profiles can also be implemented when using a Proxy server (when the
AlwaysUseRouteTable parameter is set to 1).
The following procedure describes how to configure IP Profiles in the Web interface. You
can also configure IP Profiles using the table ini file parameter, IPProfile or the CLI
command, configure voip > coders-and-profiles ip-profile.
 To configure an IP Profile:
1.
Open the IP Profile Settings page (Configuration tab > VoIP menu > Coders and
Profiles > IP Profile Settings).
2.
Click Add; the following dialog box appears:
3.
Configure an IP Profile according to the parameters described in the table below.
Version 6.8
303
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 19-5: IP Profile Settings Table Parameter Descriptions
Parameter
Description
Common
Web: Index
[IpProfile_Index]
Defines an index number for the new table record.
Web: Profile Name
CLI: profile-name
[IpProfile_ProfileName]
Defines an arbitrary name to easily identify the IP Profile.
The valid value is a string of up to 20 characters.
Web: Profile Preference
CLI: ip-preference
[IpProfile_IpPreference]
Defines the priority of the IP Profile, where 20 is the highest priority
and 1 the lowest priority.
Notes:
 If both an IP Profile and a Tel Profile apply to the same call, the
coders and other common parameters of the profile with the
highest preference are applied to the call. If the preference of
the profiles is identical, the Tel Profile parameters are applied.
 If the coder lists of both an IP Profile and a Tel Profile apply to
the same call, only the coders common to both are used. The
order of the coders is determined by the preference.
 This parameter is applicable only to the Gateway application.
Web: Dynamic Jitter Buffer
Minimum Delay
CLI: jitter-buffer-minimum-delay
[IpProfile_JitterBufMinDelay]
Defines the minimum delay (in msec) of the device's dynamic Jitter
Buffer.
The valid range is 0 to 150. The default delay is 10.
Notes:
 For more information on the Jitter Buffer, see Dynamic Jitter
Buffer Operation on page 170.
 The corresponding global parameter is DJBufMinDelay.
Web: Dynamic Jitter Buffer
Optimization Factor
CLI: jitter-buffer-optimizationfactor
[IpProfile_JitterBufOptFactor]
Defines the Dynamic Jitter Buffer frame error/delay optimization
factor.
The valid range is 0 to 12. The default factor is 10.
Notes:
 For data (fax and modem) calls, set this parameter to 12.
 For more information on Jitter Buffer, see Dynamic Jitter Buffer
Operation on page 170.
 The corresponding global parameter is DJBufOptFactor.
Web: RTP IP DiffServ
CLI: rtp-ip-diffserv
[IpProfile_IPDiffServ]
Defines the DiffServ value for Premium Media class of service
(CoS) content.
The valid range is 0 to 63. The default is 46.
Note: The corresponding global parameter is
PremiumServiceClassMediaDiffServ.
Web: Signaling DiffServ
CLI: signaling-diffserv
[IpProfile_SigIPDiffServ]
Defines the DiffServ value for Premium Control CoS content (Call
Control applications).
The valid range is 0 to 63. The default is 40.
Note: The corresponding global parameter is
PremiumServiceClassControlDiffServ.
Web: Silence Suppression
CLI: sce
[IpProfile_SCE]
Enables the Silence Suppression feature. When enabled, the
device, upon detection of silence period during a call does not send
packets, thereby conserving bandwidth during the VoIP call.
User's Manual
304
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description



[0] Disable (default)
[1] Enable = Silence Suppression is enabled.
[2] Enable Without Adaptation = A single silence packet is sent
during a silence period (applicable only to G.729).
Notes:
 If the coder is G.729, the value of the 'annexb' parameter of the
'fmtp' attribute in the SDP is determined by the following:
 This parameter is set to Disable [0]: 'annexb=no'
 This parameter is set to Enable [1]: 'annexb=yes'
 This parameter is set to Enable Without Adaptation [2] and
IsCiscoSCEMode to [0]: 'annexb=yes'
 Enable Without Adaptation is set to Enable Without
Adaptation [2] and IsCiscoSCEMode to [1]: 'annexb=no'
 The corresponding global parameter is
EnableSilenceCompression.
Web: RTP Redundancy Depth
CLI: rtp-redundancy-depth
[IpProfile_RTPRedundancyDe
pth]
Enables the device to generate RFC 2198 redundant packets. This
can be used for packet loss where the missing information (audio)
can be reconstructed at the receiver's end from the redundant data
that arrives in subsequent packets. This is required, for example, in
wireless networks where a high percentage (up to 50%) of packet
loss can be experienced.
 [0] 0 = (Default) Disable.
 [1] 1 = Enable - previous voice payload packet is added to
current packet.
Notes:
 When enabled, you can configure the payload type, using the
RFC2198PayloadType parameter.
 The RTP redundancy dynamic payload type can be included in
the SDP, by using the EnableRTPRedundancyNegotiation
parameter.
 The corresponding global parameter is RTPRedundancyDepth.
Web: Echo Canceler
CLI: echo-canceller
[IpProfile_EnableEchoCancell
er]
Enables echo cancellation (i.e., echo from voice calls is removed).
 [0] Disable
 [1] Line (default)
Notes:
 For more information on the Echo Cancellation feature, see
Echo Cancellation on page 158.
 The corresponding global parameter is EnableEchoCanceller.
Web: Disconnect on Broken
Connection
CLI: disconnect-on-brokenconnection
[IpProfile_DisconnectOnBrok
enConnection]
Enables the device to release the call if RTP packets are not
received within a user-defined timeout, configured by the
BrokenConnectionEventTimeout parameter.
 [0] No
 [1] Yes (default)
Notes:
 This feature is applicable only if the RTP session is used without
Silence Compression. If Silence Compression is enabled, the
device doesn't detect a broken RTP connection.
 During a call, if the source IP address (from where the RTP
packets are received) is changed without notifying the device,
the device filters these RTP packets. To overcome this, set the
Version 6.8
305
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
DisconnectOnBrokenConnection parameter to 0; the device
doesn't detect RTP packets arriving from the original source IP
address and switches (after 300 msec) to the RTP packets
arriving from the new source IP address.
 The corresponding global parameter is
DisconnectOnBrokenConnection.
Web: Input Gain
CLI: input-gain
[IpProfile_InputGain]
Defines the pulse-code modulation (PCM) input gain control (in
decibels). This defines the level of the received signal for Tel-to-IP
calls.
The valid range is -32 to 31 dB. The default is 0 dB.
Note: The corresponding global parameter is InputGain.
Web: Voice Volume
CLI: voice-volume
[IpProfile_VoiceVolume]
Defines the voice gain control (in decibels). This defines the level of
the transmitted signal for IP-to-Tel calls.
The valid range is -32 to 31 dB. The default is 0 dB.
Note: The corresponding global parameter is VoiceVolume.
Web: Media IP Version
Preference
CLI: media-ip-versionpreference
[IpProfile_MediaIPVersionPrefer
ence]
Defines the preferred RTP media IP addressing version for
outgoing SIP calls. This is indicated in the "c=" field (Connection
Information) of the SDP.
 [0] Only IPv4 = (Default) SDP offer includes only IPv4 media IP
addresses.
 [1] Only IPv6 = SDP offer includes only IPv6 media IP
addresses.
 [2] Prefer IPv4 = SDP offer includes IPv4 and IPv6 media IP
addresses, but the first media is IPv4.
 [3] Prefer IPv6 = SDP offer includes IPv4 and IPv6 media IP
addresses, but the first media is IPv6.
Notes:
 This parameter is applicable only when the device offers an
SDP.
 The IP addressing version is determined according to the first
SDP "m=" field.
 The corresponding global parameter is
MediaIPVersionPreference.
Web: Symmetric MKI
CLI: enable-symmetric-mki
[IpProfile_EnableSymmetricM
KI]
Enables symmetric MKI negotiation.
 [0] Disable = (Default) The device includes the MKI in its SIP
200 OK response according to the SRTPTxPacketMKISize
parameter (if set to 0, it is not included; if set to any other value,
it is included with this value).
 [1] Enable = The answer crypto line contains (or excludes) an
MKI value according to the selected crypto line in the offer. For
example, assume that the device receives an INVITE containing
the following two crypto lines in SDP:
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:TAaxNnQt8/qLQMnDuG4vxYfWl6K7eBK/ufk04pR4
|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80
inline:bnuYZnMxSfUiGitviWJZmzr7OF3AiRO0l5Vnh0kH
|2^31
The first crypto line includes the MKI parameter "1:1". In the 200
OK response, the device selects one of the crypto lines (i.e., '2'
or '3'). Typically, it selects the first line that supports the crypto
User's Manual
306
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
suite. However, for SRTP-to-SRTP in SBC sessions, it can be
determined by the remote side on the outgoing leg. If the device
selects crypto line '2', it includes the MKI parameter in its
answer SDP, for example:
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:R1VyA1xV/qwBjkEklu4kSJyl3wCtYeZLq1/QFuxw
|2^31|1:1
If the device selects a crypto line that does not contain the MKI
parameter, then the MKI parameter is not included in the crypto
line in the SDP answer (even if the SRTPTxPacketMKISize
parameter is set to any value other than 0).
Note: The corresponding global parameter is
EnableSymmetricMKI.
Web: MKI Size
CLI: mki-size
[IpProfile_MKISize]
Defines the size (in bytes) of the Master Key Identifier (MKI) in
SRTP Tx packets.
The valid value is 0 to 4. The default is 0 (i.e., new keys are
generated without MKI).
Notes:
 Gateway application: The device only initiates the MKI size.
 SBC application: The device can forward MKI size as is for
SRTP-to-SRTP flows or override the MKI size during
negotiation. This can be done on the inbound or outbound leg.
 The corresponding global parameter is SRTPTxPacketMKISize.
Web: Reset SRTP Upon Re-key
CLI: reset-srtp-upon-re-key
[IpProfile_ResetSRTPStateUp
onRekey]
Enables synchronization of the SRTP state between the device and
a server when a new SRTP key is generated upon a SIP session
expire. This feature ensures that the roll-over counter (ROC), one
of the parameters used in the SRTP encryption/decryption process
of the SRTP packets, is synchronized on both sides for transmit
and receive packets.
 [0] Disable = (Default) ROC is not reset on the device side.
 [1] Enable = If the session expires causing a session refresh
through a re-INVITE, the device or server generates a new key
and the device resets the ROC index (and other SRTP fields) as
done by the server, resulting in a synchronized SRTP.
Notes:
 If this feature is disabled and the server resets the ROC upon a
re-key generation, one-way voice may occur.
 The corresponding global parameter is
ResetSRTPStateUponRekey.
Generate SRTP keys mode
Enables the device to generate a new SRTP key upon receipt of a
CLI: generate-srtp-keys
re-INVITE with this SIP entity.
[IpProfile_GenerateSRTPKeys  [0] Only If Required= (Default) The device generates an SRTP
]
key only if necessary.
 [1] Always = The device always generates a new SRTP key
Jitter Buffer Max Delay
CLI: jitter-buffer-max-delay
[IpProfile_JitterBufMaxDelay]
Defines the maximum delay and length (in msec) of the Jitter
Buffer.
The valid range is 150 to 2,000. The default is 250.
GW
Web: Coders Group ID
Version 6.8
Defines coders supported by this SIP entity, by assigning a Coders
307
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
CLI: coders-group-id
[IpProfile_CodersGroupID]
Group.
The value, Default Coders Group represents the coders configured
in the Coders table (see Configuring Coders on page 295). All
other optional values (e.g., Coders Group 1), represent the coders
defined for the specific Coder Group configured in the Coder Group
Settings table (see Configuring Coder Groups on page 298).
Web: Fax Signaling Method
CLI: fax-sig-method
[IpProfile_IsFaxUsed]
Defines the SIP signaling method for establishing and transmitting
a fax session when the device detects a fax.
 [0] No Fax = (Default) No fax negotiation using SIP signaling.
The fax transport method is according to the FaxTransportMode
parameter.
 [1] T.38 Relay = Initiates T.38 fax relay.
 [2] G.711 Transport = Initiates fax/modem using the coder
G.711 A-law/Mu-law with adaptations (see Note below).
 [3] Fax Fallback = Initiates T.38 fax relay. If the T.38 negotiation
fails, the device re-initiates a fax session using the coder G.711
A-law/-law with adaptations (see the Note below).
Notes:
 Fax adaptations (for options 2 and 3):
 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
 If the device initiates a fax session using G.711 (option 2 or 3), a
'gpmd' attribute is added to the SDP in the following format:
 For A-law: 'a=gpmd:8 vbd=yes;ecan=on'
 For Mu-law: 'a=gpmd:0 vbd=yes;ecan=on'
 When this parameter is set to 1, 2, or 3, the parameter
FaxTransportMode is ignored.
 When this parameter is set to 0, T.38 might still be used without
the control protocol's involvement. To completely disable T.38,
set FaxTransportMode to a value other than 1.
 For more information on fax transport methods, see Fax/Modem
Transport Modes on page 160.
 The corresponding global parameter is IsFaxUsed.
Web: Remote RTP Base UDP
Port
CLI: remote-base-udp-port
[IpProfile_RemoteBaseUDPPort
]
Defines the lower boundary of the UDP port used for RTP, RTCP
(RTP port + 1) and T.38 (RTP port + 2). For example, if the Base
UDP Port is set to 6000, then one channel may use the ports RTP
6000, RTCP 6001, and T.38 6002, while another channel may use
RTP 6010, RTCP 6011, and T.38 6012, and so on. For more
information, see Configuring RTP Base UDP Port on page 174.
The range of possible UDP ports is 6,000 to 64,000. The default
base UDP port is 6000.
Notes:
 For this parameter to take effect, a device reset is required.
 If you set this parameter to a value that is not a factor of 10, the
following message is generated: "invalid local RTP port".
 The UDP ports are allocated randomly to channels.
 You can also configure a UDP port range per Media Realm (see
Configuring Media Realms on page 251).
 The corresponding global parameter is BaseUDPPort.
User's Manual
308
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
Web: CNG Detector Mode
CLI: cng-mode
[IpProfile_CNGmode]
Enables the detection of the fax calling tone (CNG) and defines the
detection method.
 [0] Disable = (Default) The originating fax does not detect CNG;
the device passes the CNG signal transparently to the remote
side.
 [1] Relay = The originating fax detects CNG. The device sends
CNG packets to the remote side according to T.38 (if IsFaxUsed
is set to 1) and the fax session is started. A SIP Re-INVITE
message is not sent and the fax session starts by the
terminating fax. This option is useful, for example, when the
originating fax is located behind a firewall that blocks incoming
T.38 packets on ports that have not yet received T.38 packets
from the internal network (i.e., originating fax). To also send a
Re-INVITE message upon detection of a fax CNG tone in this
mode, set the parameter FaxCNGMode to 1.
 [2] Event Only = The originating fax detects CNG and a fax
session is started by the originating fax, using the Re-INVITE
message. Typically, T.38 fax session starts when the preamble
signal is detected by the answering fax. Some SIP devices do
not support the detection of this fax signal on the answering fax
and thus, in these cases, it is possible to configure the device to
start the T.38 fax session when the CNG tone is detected by the
originating fax. However, this mode is not recommended.
Note: The corresponding global parameter is CNGDetectorMode.
Web: Vxx Modem Transport
Type
CLI: vxx-transport-type
[IpProfile_VxxTransportType]
Defines the modem transport type.
 [-1] Not Configured = The settings of the global parameters are
used:
 V21ModemTransportType
 V22ModemTransportType
 V23ModemTransportType
 V32ModemTransportType
 V34ModemTransportType
 [0] Disable = Transparent.
 [2] Enable Bypass (Default)
 [3] Events Only = Transparent with Events.
For a detailed description of this parameter per modem type, see
the relevant global parameter (listed above).
Web: NSE Mode
CLI: nse-mode
[IpProfile_NSEMode]
Enables Cisco's compatible fax and modem bypass mode, Named
Signaling Event (NSE) packets.
 [0] Disable (Default)
 [1] Enable
In NSE bypass mode, the device starts using G.711 A-Law
(default) or G.711-Law, according to the
FaxModemBypassCoderType parameter. The payload type for
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'
Bypass mode FaxBypassPayloadType and
ModemBypassPayloadType are not used with NSE Bypass. The
bypass packet interval is configured according to the
FaxModemBypassBasicRtpPacketInterval parameter.
The SDP contains the following line:
Version 6.8
309
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
'a=rtpmap:100 X-NSE/8000'.
Notes:
 When enabled, the following conditions must also be met:
 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 is set to 2) for all modems.
 Set the NSEPayloadType parameter to 100.
 The corresponding global parameter is NSEMode.
Web: Play RB Tone to IP
CLI: play-rbt-to-ip
[IpProfile_PlayRBTone2IP]
Enables the device to play a ringback tone to the IP side for IP-toTel calls.
 [0] Disable (Default)
 [1] Enable = Plays a ringback tone after a SIP 183 session
progress response is sent.
Notes:
 To enable the device to send a 183/180+SDP responses, set
the EnableEarlyMedia parameter to 1.
 If the EnableDigitDelivery parameter is set to 1, the device
doesn't play a ringback tone to IP and doesn't send 183 or
180+SDP responses.
 Digital interfaces: If this parameter is enabled and
EnableEarlyMedia is set to 1, the device plays a ringback tone
according to the following:
 CAS: The device opens a voice channel, sends a 183+SDP
response, and then plays a ringback tone to IP.
 ISDN: If a Progress or an Alerting message with PI (1 or 8)
is received from the ISDN, the device opens a voice
channel, sends a 183+SDP or 180+SDP response, but
doesn't play a ringback tone to IP. If PI (1 or 8) is received
from the ISDN, the device assumes that ringback tone is
played by the ISDN switch; otherwise, the device plays a
ringback tone to IP after receiving an Alerting message from
the ISDN. It sends a 180+SDP response, signaling to the
calling party to open a voice channel to hear the played
ringback tone.
 The corresponding global parameter is PlayRBTone2IP.
Web: Early Media
CLI: early-media
[IpProfile_EnableEarlyMedia]
Enables the Early Media feature for sending media (e.g., ringing)
before the call is established.
 [0] Disable (default)
 [1] Enable
 Digital: The device sends a SIP 18x response with SDP,
allowing the media stream to be established before the call
is answered.
 Analog: The device sends a SIP 183 Session Progress
response with SDP instead of a 180 Ringing, allowing the
media stream to be established before the call is answered.
Notes:
 Digital: The inclusion of the SDP in the 18x response depends
on the ISDN Progress Indicator (PI). The SDP is sent only if PI
is set to 1 or 8 in the received Proceeding, Alerting, or Progress
PRI messages. See also the ProgressIndicator2IP parameter,
which if set to 1 or 8, the device behaves as if it received the
User's Manual
310
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description




ISDN messages with the PI.
 CAS: See the ProgressIndicator2IP parameter.
 ISDN: Sending a 183 response depends on the ISDN PI. It
is sent only if PI is set to 1 or 8 in the received Proceeding
or Alerting PRI messages. Sending 183 response also
depends on the
ReleaseIP2ISDNCallOnProgressWithCause parameter,
which must be set to any value other than 2.
See also the IgnoreAlertAfterEarlyMedia parameter. This
parameter allows, for example, to interwork Alert with PI to SIP
183 with SDP instead of 180 with SDP.
You can also configure early SIP 183 response immediately
upon the receipt of an INVITE, using the EnableEarly183
parameter.
Analog: To send a 183 response, you must also set the
ProgressIndicator2IP parameter to 1. If set to 0, a 180 Ringing
response is sent.
The corresponding global parameter is EnableEarlyMedia.
Web: Progress Indicator to IP
CLI: prog-ind-to-ip
[IpProfile_ProgressIndicator2IP]
Defines the progress indicator (PI) sent to the IP.
 [-1] Not Configured = (Default)
 Analog: Default values are used (1 for FXO interfaces and 0
for FXS interfaces).
 Digital ISDN: The PI received in ISDN Proceeding,
Progress, and Alerting messages is used, as described in
the options below.
 [0] No PI =
 Analog: For IP-to-Tel calls, the device sends a 180 Ringing
response to IP after placing a call to a phone (FXS) or PBX
(FXO).
 Digital: For IP-to-Tel calls, the device sends 180 Ringing
response to IP after receiving ISDN Alerting or (for CAS)
after placing a call to PBX/PSTN.
 [1] PI = 1:
 Analog: For IP-to-Tel calls, if the EnableEarlyMedia
parameter is set to 1, the device sends a 183 Session
Progress message with SDP immediately after a call is
placed to a phone/PBX. This is used to cut-through the
voice path before the remote party answers the call. This
allows the originating party to listen to network call progress
tones such as ringback tone or other network
announcements.
 Digital: For IP-to-Tel calls, if the parameter
EnableEarlyMedia is set to 1, the device sends 180 Ringing
with SDP in response to an ISDN Alerting or it sends a 183
Session Progress message with SDP in response to only
the first received ISDN Proceeding or Progress message
after a call is placed to PBX/PSTN over the trunk.
 [8] PI = 8: same as PI = 1.
Note: The corresponding global parameter is ProgressIndicator2IP.
Web: Copy Destination Number
to Redirect Number
CLI: copy-dst-to-redirectnumber
Enables the device to copy the called number, received in the SIP
INVITE message, to the redirect number in the outgoing Q.931
Setup message, for IP-to-Tel calls. Thus, even if there is no SIP
Diversion or History header in the incoming INVITE message, the
Version 6.8
311
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
[IpProfile_CopyDest2RedirectN
umber]
outgoing Q.931 Setup message will contain a redirect number.
 [0] Disable (default).
 [1] After Manipulation = Copies the called number after
manipulation. The device first performs IP-to-Tel destination
phone number manipulation, and only then copies the
manipulated called number to the redirect number sent in the
Q.931 Setup message to the Tel. Thus, the called and redirect
numbers are the same.
 [2] Before Manipulation = Copies the called number before
manipulation. The device first copies the original called number
to the SIP Diversion header, and then performs IP-to-Tel
destination phone number manipulation. Thus, the called (i.e.,
SIP To header) and redirect (i.e., SIP Diversion header)
numbers are different.
Note: The corresponding global parameter is
CopyDest2RedirectNumber.
Web: Media Security Behavior
CLI: media-security-behaviour
[IpProfile_MediaSecurityBehavi
our]
Defines the handling of SRTP for this SIP entity.
 [-1] Not Configured = Applies the settings of the corresponding
global parameter, MediaSecurityBehaviour.
 [0] Preferable = (Default) The device initiates encrypted calls to
this SIP entity. However, if negotiation of the cipher suite fails,
an unencrypted call is established. The device accepts incoming
calls received from the SIP entity that don't include encryption
information.
 [1] Mandatory = The device initiates encrypted calls to this SIP
entity, but if negotiation of the cipher suite fails, the call is
terminated. The device rejects incoming calls received from the
SIP entity that don't include encryption information.
 [2] Disable = This SIP entity does not support encrypted calls
(i.e., SRTP).
 [3] Preferable - Single Media = The device sends SDP with a
single media ('m=') line only (e.g., m=audio 6000 RTP/AVP 4 0
70 96) with RTP/AVP and crypto keys. The SIP entity can
respond with SRTP or RTP parameters:
 If the SIP entity does not support SRTP, it uses RTP and
ignores the crypto lines.
 If the device receives an SDP offer with a single media (as
shown above) from the SIP entity, it responds with SRTP
(RTP/SAVP) if the EnableMediaSecurity parameter is set to
1. If SRTP is not supported (i.e., EnableMediaSecurity is set
to 0), it responds with RTP.
Notes:
 This parameter is applicable only when the
EnableMediaSecurity parameter is set to 1.
 If this parameter is set to Preferable [3] and two 'm=' lines are
received in the SDP offer, the device prefers the SAVP (secure
audio video profile), regardless of the order in the SDP.
 The corresponding global parameter is
MediaSecurityBehaviour.
Web: Number of Calls Limit
CLI: call-limit
[IpProfile_CallLimit]
Defines the maximum number of concurrent calls (incoming and
outgoing). If the number of concurrent calls reaches this limit, the
device rejects any new incoming and outgoing calls belonging to
this IP Profile.
User's Manual
312
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
This parameter can also be set to the following:
 [-1] = (Default) No limitation on calls.
 [0] = All calls are rejected.
Note: For Gateway IP-to-IP calls, you can configure the device to
route calls to an alternative IP Group when this maximum number
of concurrent calls is reached. To do so, you need to add an
alternative routing rule in the Outbound IP Routing table that
reroutes the call to an alternative IP Group. You also need to add a
rule to the Reason for Alternative Routing table to initiate an
alternative rule for Tel-to-IP calls using cause 805.
Web: First Tx DTMF Option
CLI: first-tx-dtmf-option
[IpProfile_FirstTxDtmfOption]
Defines the first preferred transmit DTMF negotiation method.
 [0] Not Supported = No negotiation - DTMF digits are sent
according to the parameters DTMFTransportType and
RFC2833PayloadType (for transmit and receive).
 [1] INFO (Nortel) = Sends DTMF digits according to IETF
Internet-Draft draft-choudhuri-sip-info-digit-00.
 [2] NOTIFY = Sends DTMF digits according to IETF InternetDraft draft-mahy-sipping-signaled-digits-01.
 [3] INFO (Cisco) = Sends DTMF digits according to the Cisco
format.
 [4] RFC 2833 (Default) = The device:
 negotiates RFC 2833 payload type using local and remote
SDPs.
 sends DTMF packets using RFC 2833 payload type
according to the payload type in the received SDP.
 expects to receive RFC 2833 packets with the same
payload type as configured by the parameter
RFC2833PayloadType.
 removes DTMF digits in transparent mode (as part of the
voice stream).
 [5] INFO (Korea) = Sends DTMF digits according to the Korea
Telecom format.
Notes:
 When out-of-band DTMF transfer is used ([1], [2], [3], or [5]),
the DTMFTransportType parameter is automatically set to 0
(DTMF digits are removed from the RTP stream).
 If an ISDN phone user presses digits (e.g., for interactive voice
response / IVR applications such as retrieving voice mail
messages), ISDN Information messages received by the device
for each digit are sent in the voice channel to the IP network as
DTMF signals, according to the settings of this parameter.
 The corresponding global parameter is TxDTMFOption.
Web: Second Tx DTMF Option
CLI: second-tx-dtmf-option
[IpProfile_SecondTxDtmfOption
]
Defines the second preferred transmit DTMF negotiation method.
For a description, see IpProfile_FirstTxDtmfOption (above).
Note: The corresponding global parameter is TxDTMFOption
Web: Rx DTMF Option
CLI: rx-dtmf-option
[IpProfile_RxDTMFOption]
Enables the device to declare the RFC 2833 'telephony-event'
parameter in the SDP.
 [0] Not Supported
 [3] Supported (default)
The device is always receptive to RFC 2833 DTMF relay packets.
Version 6.8
313
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Thus, it is always correct to include the 'telephony-event' parameter
by default in the SDP. However, some devices use the absence of
the 'telephony-event' in the SDP to decide to send DTMF digits inband using G.711 coder. If this is the case, set this parameter to 0.
Note: The corresponding global parameter is RxDTMFOption.
Web: Hold
CLI: enable-hold
[IpProfile_EnableHold]
Enables the Call Hold feature (analog interfaces) and interworking
of the Hold/Retrieve supplementary service from ISDN PRI to SIP
(digital interfaces). The Call Hold feature allows users, connected
to the device, to place a call on hold (or remove from hold), using
the phone's Hook Flash button.
 [0] Disable
 [1] Enable (default)
Notes:
 Digital interfaces: To interwork the Hold/Retrieve supplementary
service from SIP to ISDN (QSIG and Euro ISDN), set the
EnableHold2ISDN parameter to 1.
 Analog interfaces: To use the call hold service, the devices at
both ends must support this option.
 The corresponding global parameter is EnableHold.
Web: Add IE In Setup
CLI: add-ie-in-setup
[IpProfile_AddIEInSetup]
Defines an optional Information Element (IE) data (in hex format)
which is added to ISDN Setup messages. For example, to add IE
'0x20,0x02,0x00,0xe1', enter the value "200200e1".
Notes:
 This IE is sent from the Trunk Group that are defined by the
SendIEonTG parameter .
 You can configure different IE data for Trunk Group by
configuring this parameter for different IP Profiles and then
assigning the required IP Profile ID in the Inbound Routing
table.
 This feature is similar to that of the EnableISDNTunnelingIP2Tel
parameter. If both parameters are configured, the
EnableISDNTunnelingIP2Tel parameter takes precedence.
 The corresponding global parameter is AddIEinSetup
Web: AMD Sensitivity
Parameter Suite
CLI: amd-sensitivity-parametersuit
[IpProfile_AMDSensitivityParam
eterSuit]
Defines the AMD Parameter Suite to use for the Answering
Machine Detection (AMD) feature.
 [0] 0 = (Default) Parameter Suite 0 based on North American
English with standard detection sensitivity resolution (8
sensitivity levels, from 0 to 7). This AMD Parameter Suite is
provided by the AMD Sensitivity file, which is shipped preinstalled on the device.
 [1] 1 = Parameter Suite 1 based on North American English
with high detection sensitivity resolution (16 sensitivity levels,
from 0 to 15). This AMD Parameter Suite is provided by the
AMD Sensitivity file, which is shipped pre-installed on the
device.
 [2] 2 to [7] 7 = Optional Parameter Suites that you can create
based on any language (16 sensitivity levels, from 0 to 15). This
requires a customized AMD Sensitivity file that needs to be
installed on the device. For more information, contact your
AudioCodes sales representative.
Notes:
 To configure the detection sensitivity level, use the 'AMD
User's Manual
314
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
Sensitivity Level' parameter.
For more information on the AMD feature, see 'Answering
Machine Detection (AMD)' on page 175.
 The corresponding global parameter is
AMDSensitivityParameterSuit.

Web: AMD Sensitivity Level
CLI: amd-sensitivity-level
[IpProfile_AMDSensitivityLevel]
Defines the AMD detection sensitivity level of the selected AMD
Parameter Suite (using the 'AMD Sensitivity Parameter Suite'
parameter).
For Parameter Suite 0, the valid range is 0 to 7, where 0 is for best
detection of an answering machine and 7 for best detection of a
live call. For any Parameter Suite other than 0, the valid range is 0
to 15, where 0 is for best detection of an answering machine and
15 for best detection of a live call.
Note: The corresponding global parameter is AMDSensitivityLevel.
Web: AMD Max Greeting Time
CLI: amd-max-greeting-time
[IpProfile_AMDMaxGreetingTim
e]
Defines the maximum duration (in 5-msec units) that the device
can take to detect a greeting message.
The valid range value is 0 to 511. The default is 300.
Note: The corresponding global parameter is
AMDMaxGreetingTime.
Web: AMD Max Post Silence
Greeting Time
CLI: amd-max-post-silencegreeting-time
[IpProfile_AMDMaxPostSilence
GreetingTime]
Defines the maximum duration of silence from after the greeting
time is over (configured by AMDMaxGreetingTime) until the
device's AMD decision.
Note: The corresponding global parameter is
AMDMaxPostGreetingSilenceTime.
Web: AMD Mode
CLI: amd-mode
[IpProfile_AmdMode]
Enables the device to disconnect the IP-to-Tel call upon detection
of an answering machine on the Tel side.
 [0] Don't Disconnect = (Default) Device does not disconnect call
upon detection of an answering machine.
 [1] Disconnect on AMD = Device disconnects call upon
detection of an answering machine. It disconnects the call only
after receipt of an ISDN Connect from the Tel side. In such a
scenario, the device sends a SIP BYE message upon AMD
Notes:
 This feature (when set to [1]) cannot work together when the
EnableEarlyAMD parameter is set to [1].
 This feature does not need the receipt of the SIP X-Detect
header in the incoming INVITE to activate the AMD.
 The corresponding global parameter is AMDmode.
Web: QSIG Tunneling
CLI: enable-qsig-tunneling
[IpProfile_EnableQSIGTunnelin
g]
Enables QSIG tunneling-over-SIP for this SIP entity. This is
according to IETF Internet-Draft draft-elwell-sipping-qsig-tunnel-03
and ECMA-355 and ETSI TS 102 345.
 [0] Disable (default).
 [1] Enable = Enables QSIG tunneling from QSIG to SIP, and
vice versa. All QSIG messages are sent as raw data in
corresponding SIP messages using a dedicated message body.
Notes:
 QSIG tunneling must be enabled on originating and terminating
devices.
 To enable this function, set the ISDNDuplicateQ931BuffMode
Version 6.8
315
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
parameter to 128 (i.e., duplicate all messages).
To define the format of encapsulated QSIG messages, use the
QSIGTunnelingMode parameter.
 Tunneling according to ECMA-355 is applicable to all ISDN
variants (in addition to the QSIG protocol).
 For more information on QSIG tunneling, see QSIG Tunneling
on page 344.
 The corresponding global parameter is EnableQSIGTunneling.

Web: Early 183
CLI: enable-early-183
[IpProfile_EnableEarly183]
Enables the device to send SIP 183 responses with SDP to the IP
upon receipt of INVITE messages. This parameter is applicable to
IP-to-Tel (ISDN) and IP-to-IP calls, and applies to all calls.
 [0] Disable (default)
 [1] Enable =
 IP-to-Tel calls: By sending the 183 response, the device
opens an RTP channel before receiving the "progress" tone
from the ISDN side. The device sends RTP packets
immediately upon receipt of an ISDN Progress, Alerting with
Progress indicator, or Connect message according to the
initial negotiation without sending the 183 response again,
thereby saving response time and avoiding early media
clipping.
 IP-to-IP calls: Sending the 183 response enables SIP
servers that require a stream of early media, to keep
sessions open.
Notes:
 To enable this feature, set the EnableEarlyMedia parameter to
1.
 When the BChannelNegotiation parameter is set to a nonExclusive value (Preferred or Any), the EnableEarly183
parameter is ignored and a SIP 183 is not sent upon receipt of
an INVITE. In such a case, you can set the
ProgressIndicator2IP parameter to 1 (PI = 1) for the device to
send a SIP 183 upon receipt of an ISDN Call Proceeding
message.
 The corresponding global parameter is EnableEarly183.
Web: Early Answer Timeout
CLI: early-answer-timeout
[IpProfile_EarlyAnswerTimeout]
Defines the duration (in seconds) that the device waits for an ISDN
Connect message from the called party (Tel side), started from
when it sends a Setup message. If this timer expires, the call is
answered by sending a SIP 200 OK message (to the IP side).
The valid range is 0 to 2400. The default is 0 (i.e., disabled).
Note: The corresponding global parameter is EarlyAnswerTimeout.
SBC
Web: Extension Coders Group
ID
CLI: sbc-ext-coders-group-id
[IpProfile_SBCExtensionCoders
GroupID]
User's Manual
Assigns a Coder Group ID used for Extended (additional) coders,
added to the outgoing leg for this SIP entity. This is used when
transcoding is required between two IP entities (i.e., the SDP
answer from one doesn’t include any coder included in the offer
previously sent by the other). Therefore, to allow IP entities to
communicate with each other regardless of their capabilities, an
Extended coders table with at least one coder that is supported by
each IP entity needs to be assigned to each IP Group. Therefore,
each offer destined to specific IP Groups includes this coder.
Note: To configure Coders Groups, see Configuring Coder Groups
316
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
on page 298.
Web: Transcoding Mode
CLI: transcoding-mode
[IpProfile_TranscodingMode]
Defines the voice transcoding mode (media negotiation) for this
SIP entity.
 [0] Only if Required = (Default) Transcoding is done only when
necessary. Many of the media settings (such as gain control)
are not implemented on the voice stream. The device forwards
RTP packets transparently (RTP-to-RTP), without processing
them.
 [1] Force = Transcoding is always done on the outgoing leg.
The device interworks the media between for this SIP entity (as
both legs have different media capabilities), by implementing
DSP transcoding. This enables the device to receive capabilities
that are not negotiated between the SIP entities. For example, it
can enforce Gain Control to use voice transcoding even though
both legs have negotiated without the device's intervention
(such as Extension coders).
Notes:
 To implement transcoding, you must configure the number of
required DSP channels for transcoding (using the
MediaChannels parameter). Each transcoding session uses two
DSP resources.
 When transcoding is required, it is recommended that the
device be installed with the MPM(s) module for handling this
functionality.
 The corresponding global parameter is TranscodingMode.
Allowed Media Types
CLI: sbc-allowed-media-types
[IPProfile_SBCAllowedMediaTy
pes]
Defines media types permitted for this SIP entity. The media type
appears in the SDP 'm=' line (e.g., 'm=audio'). The device permits
only media types that appear in both the SDP offer and this
configured list. If no common media types exist between the SDP
offer and this list, the device drops the call.
The valid value is a string of up to 64 characters. To configure
multiple media types, separate the strings with a comma, e.g.,
"media, audio" (without quotes). By default, no media types are
configured (i.e., all media types are permitted).
Web: Allowed Coders Group ID
CLI: sbc-allowed-coders-groupid
[IpProfile_SBCAllowedCodersG
roupID]
Assigns an Allowed Coders Group to this SIP entity. This defines
audio (voice) coders that can be used for this SIP entity.
To configure Allowed Coders Groups, see Configuring Allowed
Audio Coder Groups on page 520.
For a description of the Allowed Coders feature, see ''Restricting
Coders'' on page 495.
Web: Allowed Video Coders
Group ID
CLI: sbc-allowed-video-codersgroup-id
[IPProfile_SBCAllowedVideoCo
dersGroupID]
Assigns an Allowed Video Coders Group to this SIP entity. This
defines permitted video coders when forwarding video streams to
the SIP entity. The video coders are listed in the "video" media type
in the SDP (i.e., 'm=video' line). For this SIP entity, the device uses
only video coders that appear in both the SDP offer and the
Allowed Video Coders Group ID.
By default, no Allowed Video Coders Group is assigned (i.e., all
video coders are allowed).
To configure Allowed Video Coders Groups, see Configuring
Allowed Video Coder Groups on page 522.
Web: Allowed Coders Mode
Defines the mode of the Allowed Coders feature for this SIP entity.
Version 6.8
317
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
CLI: sbc-allowed-coders-mode
[IpProfile_SBCAllowedCodersM
ode]

Web: SBC Media Security
Behavior
CLI: sbc-media-securitybehaviour
[IpProfile_SBCMediaSecurityBe
haviour]
Defines the handling of RTP and SRTP for this SIP entity.
 [0] As is = (Default) No special handling for RTP\SRTP is done.
 [1] SRTP = SBC legs negotiate only SRTP media lines, and
RTP media lines are removed from the incoming SDP
offer\answer.
 [2] RTP = SBC legs negotiate only RTP media lines, and SRTP
media lines are removed from the incoming offer\answer.
 [3] Both = Each offer\answer is extended (if not already) to two
media lines - one RTP and the other SRTP.
If two SBC legs (after offer\answer negotiation) use different
security types (i.e., one RTP and the other SRTP), the device
performs RTP-SRTP transcoding. To transcode between RTP and
SRTP, the following prerequisites must be met:
 At least one supported SDP "crypto" attribute and parameters.
 EnableMediaSecurity must be set to 1.
If one of the above transcoding prerequisites is not met, then:
 any value other than “As is” is discarded.
 if the incoming offer is SRTP, force transcoding, coder
transcoding, and DTMF extensions are not applied.
Web: RFC 2833 Behavior
CLI: sbc-rfc2833-behavior
[IpProfile_SBCRFC2833Behavi
or]
Defines the handling of RFC 2833 SDP offer\answer negotiation for
this SIP entity.
 [0] As is = (Default) The device does not intervene in the RFC
2833 negotiation.
 [1] Extend = Each outgoing offer\answer includes RFC 2833 in
the offered SDP (the device adds RFC 2833 only if the incoming
offer does not include RFC 2833).
 [2] Disallow = The device removes RFC 2833 from the incoming
offer.
Note: If the device interworks between different DTMF methods
and one of the methods is in-band DTMF packets (RFC 2833),
detection and generation of DTMF methods requires DSP
resources.
Web: Alternative DTMF Method
The device's first priority for DTMF method at each leg is RFC
User's Manual
[0] Restriction = In the incoming SDP offer, the device uses only
Allowed coders; the rest are removed from the SDP offer (i.e.,
only coders common between those in the received SDP offer
and the Allowed coders are used). If an Extension Coders
Group is also assigned (using the 'Extension Coders Group ID'
parameter, above), these coders are added to the SDP offer.
 [1] Preference = The device re-arranges the priority (order) of
the coders in the incoming SDP offer according to their order of
appearance in the Allowed Coders Group or Allowed Video
Coders tables. The coders received in the SDP offer are listed
after the Allowed coders.
 [2] Restriction and Preference = Performs both Restriction and
Preference.
Notes:
 This parameter is applicable only if Allowed coders are assigned
to the IP Profile (using the 'Allowed Coders Group ID' or
'Allowed Video Coders Group ID' parameters).
 For more information on the Allowed Coders feature, see
Restricting Coders on page 495.
318
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
CLI: sbc-alternative-dtmfmethod
[IpProfile_SBCAlternativeDTMF
Method]
2833. Thus, if the device successfully negotiates RFC 2833 for this
SIP entity, the chosen DTMF method for this leg is RFC 2833.
When RFC 2833 negotiation fails, the device uses this parameter
to define the DTMF method for the leg.
 [0] As Is = (Default) The device does not attempt to interwork
any special DTMF method.
 [1] In Band
 [2] INFO - Cisco
 [3] INFO - Nortel
 [4] INFO - Lucent = INFO, Korea
Note: If the device interworks between different DTMF methods
and one of the methods is in-band DTMF packets (RFC 2833),
detection and generation of DTMF methods requires DSP
resources.
Web: P-Asserted-Identity
CLI: sbc-assert-identity
[IpProfile_SBCAssertIdentity]
Defines the device's handling of the SIP P-Asserted-Identity header
for this SIP entity. This header indicates how the outgoing SIP
message asserts identity.
 [0] As Is = (Default) P-Asserted Identity header is not affected
and the device uses the same P-Asserted-Identity header (if
present) in the incoming message for the outgoing message.
 [1] Add = Adds a P-Asserted-Identity header. The header's
values are taken from the source URL.
 [2] Remove = Removes the P-Asserted-Identity header.
Notes:
 This parameter affects only the initial INVITE request.
 The corresponding global parameter is SBCAssertIdentity.
Web: Diversion Mode
CLI: sbc-diversion-mode
[IpProfile_SBCDiversionMode]
Defines the device’s handling of the SIP Diversion header for this
SIP entity. For more information on interworking of the History-Info
and Diversion headers, see Interworking SIP Diversion and
History-Info Headers on page 502.
 [0] As Is = (Default) Diversion header is not handled.
 [1] Add = History-Info header is converted to a Diversion
header.
 [2] Remove = Removes the Diversion header and the
conversion to the History-Info header depends on the settings of
the SBCHistoryInfoMode parameter.
Note: If the Diversion header is used, you can specify the URI type
(e.g., "tel:") to use in the header, using the SBCDiversionUriType
parameter.
Web: History-Info Mode
CLI: sbc-history-info-mode
[IpProfile_SBCHistoryInfoMode]
Defines the device’s handling of the SIP History-Info header for this
SIP entity. For more information on interworking of the History-Info
and Diversion headers, see Interworking SIP Diversion and
History-Info Headers on page 502.
 [0] As Is = (Default) History-Info header is not handled.
 [1] Add = Diversion header is converted to a History-Info
header.
 [2] Remove = History-Info header is removed from the SIP
dialog and the conversion to the Diversion header depends on
the settings of the SBCDiversionMode parameter.
Web: Fax Coders Group ID
Assigns a Coders Group ID to define the supported fax coders for
Version 6.8
319
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
CLI: sbc-fax-coders-group-id
fax negotiation for this SIP entity. For configuring Coder Groups,
[IpProfile_SBCFaxCodersGroup see Configuring Coder Groups on page 298.
ID]
Note: The parameter is applicable only if you set the
IpProfile_SBCFaxBehavior parameter to a value other than [0].
Web: Fax Behavior
CLI: sbc-fax-behavior
[IpProfile_SBCFaxBehavior]
Defines the fax-offer negotiation method for this SIP entity.
 [0] As Is = (Default) Pass fax transparently, without interference.
 [1] Handle always = Handle fax according to fax settings in the
IP Profile for all offer-answer transactions (including the initial
INVITE).
 [2] Handle on re-INVITE = Handle fax according to fax settings
in the IP Profile for all re-INVITE offer-answer transactions
(except for initial INVITE).
Note: The fax settings in the IP Profile include
IpProfile_SBCFaxCodersGroupID, IpProfile_SBCFaxOfferMode,
and IpProfile_SBCFaxAnswerMode.
Web: Fax Offer Mode
CLI: sbc-fax-offer-mode
[IpProfile_SBCFaxOfferMode]
Defines the coders included in the outgoing SDP offer (sent to the
called "fax") for this SIP entity.
 [0] All coders = (Default) Use only (and all) the coders of the
selected Coders Group ID configured using the
SBCFaxCodersGroupID parameter.
 [1] Single coder = Use only one coder. If a coder in the
incoming offer (from the calling "fax") matches a coder in the
SBCFaxCodersGroupID, then the device uses this coder. If no
match exists, then the device uses the first coder listed in the
Coders Group ID (SBCFaxCodersGroupID).
Note: The parameter is applicable only if you set the
IpProfile_SBCFaxBehavior parameter to a value other than [0].
Web: Fax Answer Mode
CLI: sbc-fax-answer-mode
[IpProfile_SBCFaxAnswerMode
]
Defines the coders included in the outgoing SDP answer (sent to
the calling "fax") for this SIP entity.
 [0] All coders = Use matched coders between the incoming
offer coders (from the calling "fax") and the coders of the
selected Coders Group ID (configured using the
SBCFaxCodersGroupID parameter).
 [1] Single coder = (Default) Use only one coder. If the incoming
answer (from the called "fax") includes a coder that matches a
coder match between the incoming offer coders (from the calling
"fax") and the coders of the selected Coders Group ID
(SBCFaxCodersGroupID, then the device uses this coder. If no
match exists, the device uses the first listed coder of the
matched coders between the incoming offer coders (from the
calling "fax") and the coders of the selected Coders Group ID.
Note: The parameter is applicable only if you set the
IpProfile_SBCFaxBehavior parameter to a value other than [0].
Web: PRACK Mode
CLI: sbc-prack-mode
[IpProfile_SbcPrackMode]
Defines the device's handling of SIP PRACK messages for this SIP
entity.
 [1] Optional = PRACK is optional. If required, the device
performs the PRACK process on behalf of the SIP entity.
 [2] Mandatory = PRACK is required for this SIP entity. Calls
from endpoints that do not support PRACK are rejected. Calls
destined to these endpoints are also required to support
PRACK.
 [3] Transparent (default) = The device does not intervene with
User's Manual
320
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
the PRACK process and forwards the request as is.
Web: Session Expires Mode
Defines the required session expires mode for this SIP entity.
CLI: sbc-session-expires-mode  [0] Transparent = (Default) The device does not interfere with
[IpProfile_SBCSessionExpiresM
the session expires negotiation.
ode]
 [1] Observer = If the SIP Session-Expires header is present, the
device does not interfere, but maintains an independent timer
for each leg to monitor the session. If the session is not
refreshed on time, the device disconnects the call.
 [2] Not Supported = The device does not allow a session timer
with this SIP entity.
 [3] Supported = The device enables the session timer with this
SIP entity. If the incoming SIP message does not include any
session timers, the device adds the session timer information to
the sent message. You can configure the value of the SessionExpires and Min-SE headers, using the SBCSessionExpires
and SBCMinSE parameters, respectively.
Web: Remote Update Support
CLI: sbc-rmt-update-supp
[IpProfile_SBCRemoteUpdateS
upport]
Defines whether this SIP entity supports the SIP UPDATE
message.
 [0] Not Supported = UPDATE message is not supported.
 [1] Supported Only After Connect = UPDATE message is
supported only after the call is connected.
 [2] Supported = (Default) UPDATE message is supported
during call setup and after call establishment.
Web: Remote re-INVITE
CLI: sbc-rmt-re-invite-supp
[IpProfile_SBCRemoteReinvite
Support]
Defines whether the destination UA of the re-INVITE request
supports re-INVITE messages and if so, whether it supports reINVITE with or without SDP.
 [0] Not Supported = re-INVITE is not supported and the device
does not forward re-INVITE requests. The device sends a SIP
response to the re-INVITE request, which can either be a
success or a failure, depending on whether the device can
bridge the media between the endpoints.
 [1] Supported only with SDP = re-INVITE is supported, but only
with SDP. If the incoming re-INVITE arrives without SDP, the
device creates an SDP and adds it to the outgoing re-INVITE.
 [2] Supported = (Default) re-INVITE is supported with or without
SDP.
Web: Remote Delayed Offer
Support
CLI: sbc-rmt-delayed-offer
[IpProfile_SBCRemoteDelayed
OfferSupport]
Defines whether the remote endpoint supports delayed offer (i.e.,
initial INVITEs without an SDP offer).
 [0] Not Supported = Initial INVITE requests without SDP are not
supported.
 [1] Supported = (Default) Initial INVITE requests without SDP
are supported.
Note: For this parameter to function, you need to configure a valid
Extension Coders Group ID for IP Profiles that do not support
delayed offer.
Web: Remote REFER Behavior Defines the device's handling of REFER requests for this SIP
CLI: sbc-rmt-refer-behavior
entity.
[IpProfile_SBCRemoteReferBeh  [0] Regular = (Default) Refer-To header is unchanged and the
avior]
device forwards the REFER as is.
 [1] Database URL = Changes the Refer-To header so that the
Version 6.8
321
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
re-routed INVITE is sent through the SBC:
a. Before forwarding the REFER request, the device changes
the host part to the device's IP address and adds a special
prefix ("T~&R_") to the Contact user part.
b. The incoming INVITE is identified as a REFER-resultant
INVITE according to this special prefix.
c. The device replaces the host part in the Request-URI with
the host from the REFER contact. The special prefix
remains in the user part for regular classification,
manipulation, and routing. The special prefix can also be
used for specific routing rules for REFER-resultant INVITEs.
d. The special prefix is removed before the resultant INVITE is
sent to the destination.
 [2] IP Group Name = Sets the host part in the REFER message
to the name defined for the IP Group (in the IP Group table).
 [3] Handle Locally = Handles the incoming REFER request itself
without forwarding the REFER. The device generates a new
INVITE to the alternative destination according to the rules in
the IP-to-IP Routing table (the 'Call Trigger' field must be set to
REFER).
Note: The corresponding global parameter is SBCReferBehavior.
Web: Remote 3xx Behavior
CLI: sbc-rmt-3xx-behavior
[IpProfile_SBCRemote3xxBeha
vior]
User's Manual
Defines the device's handling of SIP 3xx redirect responses for this
SIP entity. By default, the device's handling of SIP 3xx responses is
to send the Contact header unchanged. However, some SIP
entities may support different versions of the SIP 3xx standard
while others may not even support SIP 3xx.
When enabled, the device handles SIP redirections between
different subnets (e.g., between LAN and WAN sides). This is
required when the new address provided by the redirector
(Redirect sever) may not be reachable by the far-end user (FEU)
located in another subnet. For example, a far-end user (FEU) in the
WAN sends a SIP request via the device to a Redirect server in the
LAN, and the Redirect server replies with a SIP 3xx response to a
PBX in the LAN in the Contact header. If the device sends this
response as is (i.e., with the original Contact header), the FEU is
unable to reach the new destination.
 [0] Transparent = (Default) The device forwards the received
SIP 3xx response as is, without changing the Contact header
(i.e.,transparent handling).
 [1] Database URL = The device changes the Contact header so
that the re-route request is sent through the device. The device
changes the URI in the Contact header of the received SIP 3xx
response to its own URI and adds a special user prefix
("T~&R_”), which is then sent to the FEU. The FEU then sends
a new INVITE to the device, which the device then sends to the
correct destination.
 [2] Handle Locally = The device handles SIP 3xx responses on
behalf of the dialog-initiating UA and retries the request (e.g.,
INVITE) using one or more alternative URIs included in the 3xx
response. The device sends the new request to the alternative
destination according to the IP-to-IP Routing table (the 'Call
Trigger' field must be set to 3xx).
Notes:
 When this parameter is changed from 1 to 0, new 3xx Contact
headers remain unchanged. However, requests with the special
322
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description




Web: Remote Multiple 18x
CLI: sbc-rmt-mltple-18x-supp
[IpProfile_SBCRemoteMultiple1
8xSupport]
prefix continue using the device's database to locate the new
destination.
Only one database entry is supported for the same host, port,
and transport combination. For example, the following URLs
cannot be distinguished by the device:
 sip:10.10.10.10:5060;transport=tcp;param=a
 sip:10.10.10.10:5060;transport=tcp;param=b
The database entry expires two hours after the last use.
The maximum number of destinations (i.e., database entries) is
50.
The corresponding global parameter is SBC3xxBehavior.
Defines whether multiple 18x responses including 180 Ringing, 181
Call is Being Forwarded, 182 Call Queued, and 183 Session
Progress are forwarded to the caller, for this SIP entity.
 [0] Not Supported = Only the first 18x response is forwarded to
the caller.
 [1] Supported = (Default) Multiple 18x responses are forwarded
to the caller.
Web: Remote Early Media
Defines the SIP provisional response type - 180 or 183 - for
Response Type
forwarding early media to the caller, for this SIP entity.
CLI: sbc-rmt-early-media-resp
 [0] Transparent = (Default) All early media response types are
[IpProfile_SBCRemoteEarlyMed
supported; the device forwards all responses as is (unchanged).
iaResponseType]
 [1] 180 = Early media is sent as 180 response only.
 [2] 183 = Early media is sent as 183 response only.
Web: Remote Early Media
Defines whether the remote side can accept early media or not.
CLI: sbc-rmt-early-media-supp
 [0] Not Supported = Early media is not supported.
[IpProfile_SBCRemoteEarlyMed
 [1] Supported = (Default) Early media is supported.
iaSupport]
Web: Enforce MKI Size
CLI: sbc-enforce-mki-size
[IpProfile_SBCEnforceMKISize]
Enables MKI length negotiation for SRTP-to-SRTP flows between
SIP networks (i.e., IP Groups). This includes the capability of
modifying the MKI length on the inbound or outbound SBC call leg
for this SIP entity.
 [0] Don't enforce = (Default) Device forwards the MKI size as is.
 [1] Enforce = Device changes the MKI length according to the
settings of the IP Profile parameter, MKISize.
Web: Remote Early Media RTP Defines whether the destination UA sends RTP immediately after it
Behavior
sends 18x response.
CLI: sbc-rmt-early-media-rtp
 [0] Immediate = (Default) Remote client sends RTP immediately
[IpProfile_SBCRemoteEarlyMed
after it sends 18x response with early media. Device forwards
iaRTP]
18x and RTP as is.
 [1] Delayed = After sending 18x response, the remote client
waits before sending RTP (e.g., Microsoft Lync environment).
For the device's handling of this remote UA support, see
Interworking SIP Early Media on page 504.
Web: Remote RFC 3960
Gateway Model Support
CLI: sbc-rmt-rfc3960-supp
[IpProfile_SBCRemoteSupports
RFC3960]
Version 6.8
Defines whether the destination UA is capable of receiving 18x
messages with delayed RTP.
 [0] Not Supported = (Default) UA does not support receipt of
18x messages with delayed RTP. For the device's handling of
this remote UA support, see Interworking SIP Early Media on
page 504.
323
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description

[1] Supported = UA is capable of receiving 18x messages with
delayed RTP.
Web: Remote Can Play
Ringback
CLI: sbc-rmt-can-play-ringback
[IpProfile_SBCRemoteCanPlay
Ringback]
Defines whether the destination UA can play a local ringback tone.
 [0] No = UA does not support local ringback tone. The device
sends 18x with delayed SDP to the UA.
 [1] Yes = (Default) UA supports local ringback tone. For the
device's handling of this remote UA support, see Interworking
SIP Early Media on page 504.
Web: RFC 2833 DTMF Payload
Type
CLI: sbc-2833dtmf-payload
[IpProfile_SBC2833DTMFPaylo
adType]
Defines the payload type of DTMF digits for this SIP entity. This
enables the interworking of the DTMF payload type for RFC 2833
between different SBC call legs. For example, if two entities require
different DTMF payload types, the SDP offer received by the
device from one entity is forwarded to the destination entity with its
payload type replaced with the configured payload type, and vice
versa.
The value range is 0 to 200. The default is 0 (i.e., the device
forwards the received payload type as is).
Web: User Registration Time
CLI: sbc-usr-reg-time
[IpProfile_SBCUserRegistration
Time]
Defines the duration (in seconds) of the periodic registrations that
occur between the users of this SIP entity and the device (the
device responds with this value to the user).
The valid range is 0 to 2,000,000 seconds. The default is 0. When
set to 0, the device does not change the Expires header's value
received in the user’s REGISTER request. If no Expires header is
received in the REGISTER message and this parameter is set to 0,
the Expires header's value is set to 180 seconds, by default.
Note: The corresponding global parameter is
SBCUserRegistrationTime.
Web: Reliable Held Tone
Source
CLI: reliable-heldtone-source
[IPProfile_ReliableHoldToneSo
urce]
Enables the device to consider the received call-hold request (reINVITE/UPDATE) with SDP containing 'a=sendonly', as genuine.
 [0] No (default) = Even if the received SDP contains
'a=sendonly', the device plays a held tone to the held party. This
is useful in cases where the initiator of the call hold does not
support the generation of held tones.
 [1] Yes = If the received SDP contains 'a=sendonly', the device
does not play a held tone to the held party (and assumes that
the initiator of the call hold plays the held tone).
Note: The device plays a held tone only if the 'SBC Play Held
Tone' parameter is set to Yes.
Web: Play Held Tone
CLI: play-held-tone
[IpProfile_SBCPlayHeldTone]
Enables the device to play a held tone to the held party. This is
useful if the held party does not support playing a local held tone,
or for IP entities initiating call hold that do not support the
generation of held tones.
 [0] No (default)
 [1] Yes
Note: If this parameter is set to Yes, the device plays the tone only
if the 'SBC Remote Hold Format' parameter is set to transparent,
send-only, send only 0.0.0.0, or not supported.
Web: Remote Hold Format
CLI: remote-hold-Format
[IPProfile_SBCRemoteHoldFor
mat]
Defines the format of the SDP in the re-INVITE for call hold that the
device sends to the held party.
 [0] Transparent = Device forwards SDP as is.
 [1] Send Only = Device sends SDP with 'a=sendonly'.
User's Manual
324
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description

[2] Send Only Zero ip = Device sends SDP with 'a=sendonly'
and 'c=0.0.0.0'.
 [3] Inactive = Device sends SDP with 'a=inactive'.
 [4] Inactive Zero ip = Device sends SDP with 'a=inactive' and
'c=0.0.0.0'.
 [5] Not Supported = Used when remote side cannot identify a
call-hold message. The device terminates the received call-hold
message (re-INVITE / UPDATE) and sends a 200 OK to the
initiator of the call hold. The device plays a held tone to the held
party if the 'SBC Play Held Tone' parameter is set to Yes.
Web: Remote Replaces
Behavior
CLI: sbc-rmt-replaces-behavior
[IpProfile_SBCRemoteReplaces
Behavior]
Enables the device to handle an incoming INVITE with the
Replaces header for this SIP entity (which does not support this
header). The Replaces header is used to replace an existing SIP
dialog with a new dialog such as in call transfer or call pickup
 [0] Transparent = (Default) SIP entity supports the Replaces
header. The device forwards the received INVITE with the
Replaces header as is to the SIP entity.
 [1] Handle Locally = The SIP entity does not support INVITE
with the Replaces header. The device terminates the received
INVITE with the Replaces header and establishes a new call
between the SIP entity and the new call party. It then
disconnects the call with the initial call party, by sending it a SIP
BYE request.
For example, assume that the device establishes a call between A
and B. If B initiates a call transfer to C, the device receives an
INVITE with the Replaces header from C. If A supports the
Replaces header, the device simply forwards the INVITE as is to A;
a new call is established between A and C and the call between A
and B is disconnected. However, if A does not support the
Replaces header, the device uses this feature to terminate the
INVITE with Replaces header and handles the transfer for A. The
device does this by connecting A to C, and disconnecting the call
between A and B, by sending a SIP BYE request to B. Note that if
media transcoding is required, the device sends an INVITE to C on
behalf of A with a new SDP offer.
Web: SDP Ptime Answer
CLI: sbc-sdp-ptime-ans
[IpProfile_SBCSDPPtimeAnswe
r]
Defines the packetization time (ptime) of the coder in RTP packets
for this SIP entity. This is useful when implementing transrating.
 [0] Remote Answer (Default) = Use ptime according to SDP
answer.
 [1] Original Offer = Use ptime according to SDP offer.
 [2] Preferred Value= Use preferred ptime for negotiation, if
configured by the 'Preferred Ptime' parameter.
Web: Preferred Ptime
CLI: sbc-preferred-ptime
[IpProfile_SBCPreferredPTime]
Defines the packetization time (in msec) for this SIP entity if the
'SBC SDP Ptime Answer' parameter is set to Preferred Value.
The valid range is 0 to 200. The default is 0 (i.e., preferred ptime is
not used).
Web: Use Silence Suppression Defines silence suppression support for this SIP entity.
CLI: sbc-use-silence-supp
 [0] Transparent (default) = Forward as is.
[IpProfile_SBCUseSilenceSupp]  [1] Add = Enable silence suppression for each relevant coder
listed in the SDP.
 [2] Remove = Disable silence suppression for each relevant
Version 6.8
325
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
coder listed in the SDP.
Web: Play RBT To Transferee
CLI: sbc-play-rbt-to-xferee
[IpProfile_SBCPlayRBTToTrans
feree]
Enables the device to play a ringback tone to the transferred party
(transferee) during a blind call transfer, for this SIP entity (which
does not support such a tone generation during call transfer). The
ringback tone indicates to the transferee of the ringing of the
transfer target (to where the transferee is being transferred).
 [0] No (Default)
 [1] Yes
Typically, the transferee hears a ringback tone only if the transfer
target sends it early media. However, if the transferee is put onhold before being transferred, no ringback tone is heard.
When this feature is enabled, the device generates a ringback tone
to the transferee during call transfer in the following scenarios:
 Transfer target sends a SIP 180 (Ringing) to the device.
 For non-blind transfer, if the call is transferred while the transfer
target is ringing and no early media occurs.
 The 'Remote Early Media RTP Behavior parameter is set to
Delayed (used in the Lync environment), and transfer target
sends a 183 Session progress with SDP offer. If early media
from the transfer target has already been detected, the
transferee receives RTP stream from the transfer target. If it has
not been detected, the device generates a ringback tone to the
transferee and stops the tone generation once RTP has been
detected from the transfer target.
For any of these scenarios, if the transferee is put on-hold by the
transferor, the device retrieves the transferee from hold, sends a
re-INVITE if necessary, and then plays the ringback tone.
Note: For the device to play the ringback tone, it must be loaded
with a Prerecorded Tones (PRT) file. For more information, see
Prerecorded Tones File on page 581.
Web: RTCP Mode
CLI: sbc-rtcp-mode
[IPProfile_SBCRTCPMode]
Defines how the device handles RTCP packets during call sessions
for this SIP entity. This is useful for interworking RTCP between
SIP entities. For example, this may be necessary when incoming
RTCP is not compatible with the destination SIP entity's (this IP
Profile) RTCP support. In such a scenario, the device can generate
the RTCP and send it to the SIP entity.
 [0] Transparent (default) = RTCP is forwarded as is (unless
transcoding is done, in which case, the device generates RTCP
on both legs).
 [1] Generate Always = Generates RTCP packets during active
and inactive (e.g., during call hold) RTP periods (i.e., media is
'a=recvonly' or 'a=inactive' in the INVITE SDP).
 [2] Generate only if RTP Active = Generates RTCP packets
only during active RTP periods. In other words, the device does
not generate RTCP when there is no RTP traffic (such as when
a call is on hold).
Note: The corresponding global parameter is SBCRTCPMode.
Web: Jitter Compensation
CLI: sbc-jitter-compensation
[IpProfile_SBCJitterCompensati
on]
Enables the on-demand jitter buffer for SBC calls. This jitter buffer
can be used when other functionality such as voice transcoding are
not done on the call. This jitter buffer is useful when incoming
packets are received at inconsistent intervals (i.e., packet delay
variation). The jitter buffer stores the packets and sends them out
User's Manual
326
Document #: LTRT-27034
User's Manual
19. Coders and Profiles
Parameter
Description
at a constant rate (according to the coder's settings).
 [0] Disable (default)
 [1] Enable
Notes:
 The jitter buffer parameters, 'Dynamic Jitter Buffer Minimum
Delay' (DJBufMinDelay) and 'Dynamic Jitter Buffer Optimization
Factor' (DJBufOptFactor) can be used to configure minimum
packet delay only when transcoding is employed.
 This functionality may require DSP resources. For more
information, contact your AudioCodes sales representative.
Web: Remote Renegotiate on
Fax Detection
CLI: sbc-rmt-renegotiate-on-faxdetect
[IPProfile_SBCRemoteReneg
otiateOnFaxDetection]
Version 6.8
Enables local handling of fax detection and negotiation by the
device on behalf of the SIP entity (to which the IP Profile is
assigned). This applies to faxes sent immediately upon the
establishment of a voice channel (i.e., after 200 OK).
The device attempts to detect the fax (CNG tone) from the
originating SIP entity within a user-defined interval (see the
SBCFaxDetectionTimeout parameter) immediately after the voice
call is established.
Once fax is detected, the device can handle the subsequent fax
negotiation by sending re-INVITE messages to both SIP entities.
The device also negotiates the fax coders between the two SIP
entities. The negotiated coders are according to the list of fax
coders assigned to each SIP entity, using the IP Profile parameter
'Fax Coders Group ID'.
 [0] Don't Care = (Default) Device does not interfere in the fax
transaction and assumes that the SIP entity fully supports fax
renegotiation upon fax detection.
 [1] Only on Answer Side = The SIP entity supports fax
renegotiation upon fax detection only if it is the terminating
(answering) fax, and does not support renegotiation if it is the
originating fax.
 [2] No = The SIP entity does not support fax re-negotiation upon
fax detection when it is the originating or terminating fax.
Notes:
 This feature is applicable only when both SIP entities do not
fully support fax detection (receive or send) and negotiation: one
SIP entity must be assigned an IP Profile where this parameter
is set to [1] or [2], while the peer SIP entity must be assigned an
IP Profile where this parameter is set to [2].
 This feature is supported only if at least one of the SIP entities
uses the G.711 coder.
 This feature utilizes DSP resources. If there are insufficient
resources, the fax transaction fails.
327
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
328
Document #: LTRT-27034
Part V
Gateway Application
User's Manual
20
20. Introduction
Introduction
This section describes configuration of the Gateway application. The Gateway application
refers to IP-to-Tel (PSTN) call routing and vice versa.
Notes:
• The IP-to-IP application has been superseded by the SBC application.
• In some areas of the Web interface, the term "GW" refers to the Gateway
application.
• The terms IP-to-Tel and Tel-to-IP refer to the direction of the call relative to the
device. IP-to-Tel refers to calls received from the IP network and destined to the
PSTN/PBX (i.e., telephone connected directly or indirectly to the device); Tel-to-IP
refers to calls received from telephones connected directly to the device's FXS
ports or from the PSTN/PBX, and destined for the IP network.
• FXO (Foreign Exchange Office) is the interface replacing the analog telephone
and connects to a Public Switched Telephone Network (PSTN) line from the
Central Office (CO) or to a Private Branch Exchange (PBX). The FXO is designed
to receive line voltage and ringing current, supplied from the CO or the PBX (just
like an analog telephone). An FXO VoIP device interfaces between the CO/PBX
line and the Internet.
• FXS (Foreign Exchange Station) is the interface replacing the Exchange (i.e., the
CO or the PBX) and connects to analog telephones, dial-up modems, and fax
machines. The FXS is designed to supply line voltage and ringing current to these
telephone devices. An FXS VoIP device interfaces between the analog telephone
devices and the Internet.
Version 6.8
331
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
332
Document #: LTRT-27034
User's Manual
21
21. Digital PSTN
Digital PSTN
This section describes the configuration of the public switched telephone network (PSTN)
related parameters.
21.1
Configuring Trunk Settings
The Trunk Settings page allows you to configure the device's trunks. This includes
selecting the PSTN protocol and configuring related parameters.
This page also enables the following maintenance procedures:

Taking a Trunk Out of Service: Some parameters can be configured when the trunk
is in service, while others require you to take the trunk out of service. This is done by
clicking the Stop
button. Once you have "stopped" a trunk, all current calls are
dropped and no new calls can be made on the trunk.

Deactivating a Trunk: You can deactivate a trunk for maintenance. This is done by
clicking the Deactivate
button. Deactivation temporarily disconnects
(logically) the trunk from the PSTN network. Upon trunk deactivation, the device
generates an AIS alarm on the trunk to the far-end. As a result, an RAI alarm signal
may be received by the device. A subsequent trunk activation, done by clicking the
Activate
button, reconnects the trunk to the PSTN network and clears
the AIS alarm. Trunk deactivation is typically used for maintenance such as checking
the trunk's physical integrity.

Creating a Loopback Line: You can create (and remove) remote loopback for DS1
lines. This is done by clicking the Create Loopback
button. To
remove the loopback, click the Remove Loopback
button.
Notes:
• To delete a previously configured trunk, set the 'Protocol Type' parameter to
NONE.
• For a description of the trunk parameters, see ''PSTN Parameters'' on page 857.
• During trunk deactivation, you cannot configure trunks.
• You cannot activate or deactivate a stopped trunk.
• If the trunk can’t be stopped because it provides the device’s clock (assuming the
device is synchronized with the E1/T1 clock), assign a different E1/T1 trunk to
provide the device’s clock or enable ‘TDM Bus PSTN Auto Clock’ in the TDM Bus
Settings page (see ''TDM and Timing'' on page 336).
• If the ‘Protocol Type’ parameter is set to NONE (i.e., no protocol type is selected)
and no other trunks have been configured, after selecting a PRI protocol type you
must reset the device.
• The displayed parameters depend on the protocol selected.
• All PRI trunks of the device must be of the same line type (i.e., E1 or T1).
However, different variants of the same line type can be configured on different
trunks, for example, E1 Euro ISDN and E1 CAS (subject to the constraints in the
device's Release Notes).
• BRI trunks can operate with E1 or T1 trunks.
• If the protocol type is CAS, you can assign or modify a dial plan (in the 'Dial Plan'
field) and perform this without stopping the trunk.
Version 6.8
333
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure trunks:
1.
Open the Trunk Settings page (Configuration tab > VoIP menu > PSTN > Trunk
Settings).
On the top of the page, a bar with Trunk number icons displays the status of each
trunk, according to the following color codes:
2.
•
Grey: Disabled
•
Green: Active
•
Yellow: RAI alarm (also appears when you deactivate a Trunk by clicking the
Deactivate button)
•
Red: LOS/LOF alarm
•
Blue: AIS alarm
•
Orange: D-channel alarm (ISDN only)
Select the trunk that you want to configure by clicking the desired Trunk number icon.
The bar initially displays the first eight trunk number icons (i.e., trunks 1 through 8). To
scroll through the trunk number icons (i.e., view the next/last or previous/first group of
eight trunks), see the figure below:
Figure 21-1: Trunk Scroll Bar (Used Only as an Example)
User's Manual
334
Document #: LTRT-27034
User's Manual
21. Digital PSTN
Note: If the Trunk scroll bar displays all available trunks, the scroll bar buttons are
unavailable.
After you have selected a trunk, the following is displayed:
3.
•
The read-only 'Module ID' field displays the module number to which the trunk
belongs.
•
The read-only 'Trunk ID' field displays the selected trunk number.
•
The read-only ‘Trunk Configuration State’ displays the state of the trunk ('Active'
or 'Inactive').
•
The displayed parameters pertain to the selected trunk only.
Click the Stop Trunk
button (located at the bottom of the page) to take the trunk
out of service so that you can configure the currently grayed out (unavailable)
parameters. (Skip this step if you want to configure parameters that are available
when the trunk is active). The stopped trunk is indicated by the following:
•
The ‘Trunk Configuration State’ field displays ‘Inactive’.
•
The Stop Trunk button is replaced by the Apply Trunk Settings
When all trunks are stopped, the Apply to All Trunks
•
button.
button also appears.
All the parameters are available and can be modified.
4.
Configure the trunk parameters as required.
5.
Click the Apply Trunk Settings button to apply the changes to the selected trunk (or
click Apply to All Trunks to apply the changes to all trunks); the Stop Trunk button
replaces Apply Trunk Settings and the ‘Trunk Configuration State’ displays 'Active'.
6.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
7.
To reset the device, see ''Resetting the Device'' on page 565.
Version 6.8
335
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.2
TDM and Timing
This section describes the configuration of the TDM and clock timing parameters.
21.2.1 Configuring TDM Bus Settings
The TDM page allows you to configure the device's Time-Division Multiplexing (TDM) bus
settings. For a description of these parameters, see ''PSTN Parameters'' on page 857.
 To configure the TDM Bus settings:
1.
Open the TDM page (Configuration tab > VoIP menu > TDM > TDM Bus Settings).
Figure 21-2: TDM Bus Settings Page
2.
Configure the parameters as required.
3.
Click Submit.
4.
Save the changes to flash memory, see ''Saving Configuration'' on page 568.
21.2.2 Clock Settings
In a traditional TDM service network such as PSTN, both ends of the TDM connection must
be synchronized. If synchronization is not achieved, voice frames are either dropped (to
prevent a buffer overflow condition) or inserted (to prevent an underflow condition). In both
cases, connection quality and reliability is affected.

PSTN line clock (see ''Recovering Clock from PSTN Line'' on page 337)

Internal clock (see ''Configuring Internal Clock as Clock Source'' on page 337)
Note: When the device is used in a ‘non-span’ configuration, the internal device clock
must be used (as explained above).
User's Manual
336
Document #: LTRT-27034
User's Manual
21. Digital PSTN
21.2.2.1 Recovering Clock from PSTN Line Interface
This section provides a brief description for configuring synchronization based on
recovering clock from the PSTN line interface. For a full description of the clock
parameters, see ''PSTN Parameters'' on page 857.
 To configure synchronization based on clock from PSTN line:
1.
In the TDM Bus Settings page, do the following:
a.
b.
Set the 'TDM Bus Clock Source' parameter (TDMBusClockSource) to Network to
recover the clock from the line interface.
Select the trunk from which the clock is derived, using the 'TDM Bus Local
Reference' parameter (TDMBusLocalReference).
Note: The E1/T1 trunk should recover the clock from the remote side (see below
description of the 'Clock Master' parameter). The BRI trunk should be configured as
an ISDN user-side.
c.
2.
Enable automatic switchover to the next available "slave" trunk if the device
detects that the local-reference trunk is no longer capable of supplying the clock
to the system:
a. Set the 'TDM Bus PSTN Auto FallBack Clock' parameter
(TDMBusPSTNAutoClockEnable) to Enable.
b. Enable the device to switch back to a previous trunk that returns to service if
it has higher switchover priority, using the 'TDM Bus PSTN Auto Clock
Reverting' parameter (TDMBusPSTNAutoClockRevertingEnable).
c. In the Trunk Settings page, configure the priority level of the trunk for taking
over as a local-reference trunk, using the 'Auto Clock Trunk Priority'
parameter (AutoClockTrunkPriority). A value of 100 means that it never uses
the trunk as local reference.
For E1/T1 trunks only: Set the PSTN trunk to recover/derive clock from/to the remote
side of the PSTN trunk (i.e. clock slave or clock master): In the Trunk Settings page,
set the 'Clock Master' parameter (ClockMaster) to one of the following:
•
Recovered - to recover clock (i.e. slave)
•
Generated - to transmit clock (i.e. master)
21.2.2.2 Configuring Internal Clock as Clock Source
This section describes how to configure the device to use its internal clock source. The
internal clock source is a stratum 4E-compliant clock source. When the device has no line
interfaces, the device should be configured in this mode.
 To configure internal clock as clock source:
1.
Set the clock source to be from the device's internal oscillator. In the TDM Bus
Settings page, set the 'TDM Bus Clock Source' parameter (TDMBusClockSource) to
Internal.
2.
For E1/T1 trunks only, set the line to drive the clock on all trunks: In the Trunk Settings
page, set the 'Clock Master' parameter (ClockMaster) to Generated (for all trunks).
Version 6.8
337
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.3
Configuring CAS State Machines
The CAS State Machine page allows you to modify various timers and other basic
parameters to define the initialization of the CAS state machine without changing the state
machine itself (no compilation is required). The change doesn't affect the state machine
itself, but rather the configuration.
The CAS table used can be chosen in two ways (using the parameter CasChannelIndex):

Single CAS table per trunk

Different CAS table per group of B-channels in a trunk
 To modify the CAS state machine parameters:
1.
Open the CAS State Machine page (Configuration tab > VoIP menu > PSTN > CAS
State Machines).
Figure 21-3: CAS State Machine Page
2.
Ensure that the trunk is inactive. The trunk number displayed in the 'Related Trunks'
field must be green. If it is red, indicating that the trunk is active, click the trunk number
to open the Trunk Settings page (see ''Configuring Trunk Settings'' on page 333),
select the required Trunk number icon, and then click Stop Trunk.
3.
In the CAS State Machine page, modify the required parameters according to the
table below.
4.
Once you have completed the configuration, activate the trunk if required in the Trunk
Settings page, by clicking the trunk number in the 'Related Trunks' field, and in the
Trunk Settings page, select the required Trunk number icon, and then click Apply
Trunk Settings.
5.
Click Submit, and then reset the device (see ''Resetting the Device'' on page 565).
Notes:
• The CAS state machine can only be configured using the Web-based
management tool.
• Don't modify the default values unless you fully understand the implications of the
changes and know the default values. Every change affects the configuration of
the state machine parameters and the call process related to the trunk you are
using with this state machine.
• You can modify CAS state machine parameters only if the following conditions are
met:
1) Trunks are inactive (stopped), i.e., the 'Related Trunks' field displays the trunk
number in green.
2) State machine is not in use or is in reset, or when it is not related to any trunk. If
it is related to a trunk, you must delete the trunk or de-activate (Stop) the trunk.
• Field values displaying '-1' indicate CAS default values. In other words, CAS state
machine values are used.
• The modification of the CAS state machine occurs at the CAS application
initialization only for non-default values (-1).
• For more information on the CAS Protocol table, refer to the CAS Protocol Table
Configuration Note.
User's Manual
338
Document #: LTRT-27034
User's Manual
21. Digital PSTN
Table 21-1: CAS State Machine Parameters Description
Parameter
Description
Generate Digit On Time
[CasStateMachineGenerateDigitOnTim
e]
Generates digit on-time (in msec).
The value must be a positive value. The default is -1 (use
value from CAS state machine).
Generate Inter Digit Time
[CasStateMachineGenerateInterDigitTi
me]
Generates digit off-time (in msec).
The value must be a positive value. The default is -1 (use
value from CAS state machine).
DTMF Max Detection Time
[CasStateMachineDTMFMaxOnDetecti
onTime]
Detects digit maximum on time (according to DSP
detection information event) in msec units.
The value must be a positive value. The default is -1 (use
value from CAS state machine).
DTMF Min Detection Time
[CasStateMachineDTMFMinOnDetectio
nTime]
Detects digit minimum on time (according to DSP
detection information event) in msec units. The digit time
length must be longer than this value to receive a
detection. Any number may be used, but the value must
be less than
CasStateMachineDTMFMaxOnDetectionTime.
The value must be a positive value. The default is -1 (use
value from CAS state machine).
MAX Incoming Address Digits
[CasStateMachineMaxNumOfIncoming
AddressDigits]
Defines the limitation for the maximum address digits that
need to be collected. After reaching this number of digits,
the collection of address digits is stopped.
The value must be an integer. The default is -1 (use value
from CAS state machine).
MAX Incoming ANI Digits
[CasStateMachineMaxNumOfIncoming
ANIDigits]
Defines the limitation for the maximum ANI digits that
need to be collected. After reaching this number of digits,
the collection of ANI digits is stopped.
The value must be an integer. The default is -1 (use value
from CAS state machine).
Collet ANI
[CasStateMachineCollectANI]
In some cases, when the state machine handles the ANI
collection (not related to MFCR2), you can control the
state machine to collect ANI or discard ANI.
 [0] No = Don't collect ANI.
 [1] Yes = Collect ANI.
 [-1] Default = Default value - use value from CAS state
machine.
Digit Signaling System
[CasStateMachineDigitSignalingSyste
m]
Defines which Signaling System to use in both directions
(detection\generation).
 [0] DTMF = Uses DTMF signaling.
 [1] MF = Uses MF signaling (default).
 [-1] Default = Default value - use value from CAS state
machine.
Version 6.8
339
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.4
Configuring Digital Gateway Parameters
The Digital Gateway Parameters page allows you to configure miscellaneous digital
parameters. For a description of these parameters, see ''Configuration Parameters
Reference'' on page 715.
 To configure the digital gateway parameters:
1.
Open the Digital Gateway Parameters page (Configuration tab > VoIP menu > GW
and IP to IP > Digital Gateway > Digital Gateway Parameters).
Figure 21-4: Digital Gateway Parameters Page
User's Manual
340
Document #: LTRT-27034
User's Manual
21.5
21. Digital PSTN
2.
Configure the parameters as required.
3.
Click Submit.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
Tunneling Applications
This section discusses the device's support for VoIP tunneling applications.
21.5.1 TDM Tunneling
The device's TDM Tunneling feature allows you to tunnel groups of digital trunk spans or
timeslots (B-channels) over the IP network. TDM Tunneling utilizes the device's internal
routing (without Proxy control) capabilities to receive voice and data streams from TDM
spans or individual timeslots, convert them into packets, and then transmit them over the IP
network (using point-to-point or point-to-multipoint device distributions). A device opposite it
(or several devices when point-to-multipoint distribution 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 device.
Note: TDM tunneling is applicable to PRI and BRI.
When TDM Tunneling is enabled (the parameter EnableTDMoverIP is set to '1') on the
originating device, the originating device automatically initiates SIP calls from all enabled
B-channels belonging to the spans that are configured with the protocol type ‘Transparent’
(for ISDN trunks) or ‘Raw CAS’ (for CAS trunks). The called number of each call is the
internal phone number of the B-channel from where the call originates. The Inbound IP
Routing table is used to define the destination IP address of the terminating device. The
terminating device automatically answers these calls if the protocol type is set to
‘Transparent’ (ProtocolType = 5) or ‘Raw CAS’ (ProtocolType = 3 for T1 and 9 for E1) and
the parameter ChannelSelectMode is set to 0 (By Dest Phone Number).
Note: It's possible to configure both devices to also operate in symmetric mode. To
do so, set EnableTDMOverIP to 1 and configure the Outbound IP Routing table in
both devices. In this mode, each device (after it's reset) initiates calls to the second
device. The first call for each B-channel is answered by the second device.
The device continuously monitors the established connections. If for some reason, one or
more calls are released, the device automatically re-establishes these ‘broken’
connections. When a failure in a physical trunk or in the IP network occurs, the device reestablishes the tunneling connections when the network is restored.
Note: It's recommended to use the keep-alive mechanism for each connection, by
activating the ‘session expires’ timeout and using Re-INVITE messages.
Version 6.8
341
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The
device
supports
the
configuration
(TDMoIPInitiateInviteTime
and
TDMoIPInviteRetryTime parameters) of the following timers for the TDM-over-IP tunneling
application:

Time between successive INVITEs sent from the same trunk.

Time between call release and the new INVITE that is sent on the same channel. The
call can be released if the device receives a 4xx or 5xx response.
By utilizing the ‘Profiles’ mechanism (see ''Coders and Profiles'' on page 295), 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 timeslot carrying data or signaling is assigned a
higher priority value than a timeslot carrying voice.
For tunneling CAS trunks, set the protocol type to 'Raw CAS' (ProtocolType = 3 / 9) and
enable RFC 2833 CAS relay mode ('CAS Transport Type' parameter is set to 'CAS
RFC2833 Relay').
Note: For TDM over IP, the parameter CallerIDTransportType must be set to '0'
(disabled), i.e., transparent.
Below is an example of ini files for two devices implementing TDM Tunneling for four E1
spans. Note that in this example both devices are dedicated to TDM tunneling.
Terminating Side:
EnableTDMOverIP = 1
;E1_TRANSPARENT_31
ProtocolType_0 = 5
ProtocolType_1 = 5
ProtocolType_2 = 5
ProtocolType_3 = 5
[PREFIX]
PREFIX_DestinationPrefix, PREFIX_DestAddress, PREFIX_SourcePrefix,
PREFIX_ProfileId, PREFIX_MeteringCode, PREFIX_DestPort,
PREFIX_SrcIPGroupID, PREFIX_DestHostPrefix, PREFIX_DestIPGroupID,
PREFIX_SrcHostPrefix, PREFIX_TransportType,
PREFIX_SrcTrunkGroupID, PREFIX_DestSRD, PREFIX_CostGroup,
PREFIX_ForkingGroup;
Prefix 1 = *,10.8.24.12;
[\PREFIX]
;IP address of the device 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 (timeslot 16) that carries PRI ;signaling.
[TrunkGroup]
FORMAT TrunkGroup_Index = TrunkGroup_TrunkGroupNum,
TrunkGroup_FirstTrunkId, TrunkGroup_LastTrunkId,
TrunkGroup_FirstBChannel, TrunkGroup_LastBChannel,
TrunkGroup_FirstPhoneNumber, TrunkGroup_ProfileId,
TrunkGroup_Module;
TrunkGroup 1 = 0,0,0,1,31,1000,1;
TrunkGroup 1 = 0,1,1,1,31,2000,1;
TrunkGroup 1 = 0,2,2,1,31,3000,1;
User's Manual
342
Document #: LTRT-27034
User's Manual
21. Digital PSTN
TrunkGroup 1 = 0,3,3,1,31,4000,1;
TrunkGroup 1 = 0,0,0,16,16,7000,2;
TrunkGroup 1 = 0,1,1,16,16,7001,2;
TrunkGroup 1 = 0,2,2,16,16,7002,2;
TrunkGroup 1 = 0,3,3,16,16,7003,2;
[/TrunkGroup]
[ CodersGroup0 ]
FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime,
CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce;
CodersGroup0 0 = g7231;
CodersGroup0 1 = Transparent;
[ \CodersGroup0 ]
[TelProfile]
FORMAT TelProfile_Index = TelProfile_ProfileName,
TelProfile_TelPreference, TelProfile_CodersGroupID,
TelProfile_IsFaxUsed, TelProfile_JitterBufMinDelay,
TelProfile_JitterBufOptFactor, TelProfile_IPDiffServ,
TelProfile_SigIPDiffServ, TelProfile_DtmfVolume,
TelProfile_InputGain, TelProfile_VoiceVolume,
TelProfile_EnableReversePolarity,
TelProfile_EnableCurrentDisconnect,
TelProfile_EnableDigitDelivery, TelProfile_EnableEC,
TelProfile_MWIAnalog, TelProfile_MWIDisplay,
TelProfile_FlashHookPeriod, TelProfile_EnableEarlyMedia,
TelProfile_ProgressIndicator2IP;
TelProfile 1 = voice,$$,1,$$,$$,$$,$$,$$,$$,$$;
TelProfile 2 = data,$$,2,$$,$$,$$,$$,$$,$$,$$;
[\TelProfile]
Originating Side:
;E1_TRANSPARENT_31
ProtocolType_0 = 5
ProtocolType_1 = 5
ProtocolType_2 = 5
ProtocolType_3 = 5
;Channel selection by Phone number.
ChannelSelectMode = 0
[TrunkGroup]
FORMAT TrunkGroup_Index = TrunkGroup_TrunkGroupNum,
TrunkGroup_FirstTrunkId, TrunkGroup_LastTrunkId,
TrunkGroup_FirstBChannel, TrunkGroup_LastBChannel,
TrunkGroup_FirstPhoneNumber, TrunkGroup_ProfileId,
TrunkGroup_Module;
TrunkGroup 0 = 0,0,0,1,31,1000,1;
TrunkGroup 0 = 0,1,1,1,31,2000,1;
TrunkGroup 0 = 0,2,2,1,31,3000,1;
TrunkGroup 0 = 0,3,1,31,4000,1;
TrunkGroup 0 = 0,0,0,16,16,7000,2;
TrunkGroup 0 = 0,1,1,16,16,7001,2;
TrunkGroup 0 = 0,2,2,16,16,7002,2;
TrunkGroup 0 = 0,3,3,16,16,7003,2;
[\TrunkGroup]
[ CodersGroup0 ]
FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime,
CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce;
CodersGroup0 0 = g7231;
CodersGroup0 1 = Transparent;
[ \CodersGroup0 ]
Version 6.8
343
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
[TelProfile]
FORMAT TelProfile_Index = TelProfile_ProfileName,
TelProfile_TelPreference, TelProfile_CodersGroupID,
TelProfile_IsFaxUsed, TelProfile_JitterBufMinDelay,
TelProfile_JitterBufOptFactor, TelProfile_IPDiffServ,
TelProfile_SigIPDiffServ, TelProfile_DtmfVolume,
TelProfile_InputGain, TelProfile_VoiceVolume,
TelProfile_EnableReversePolarity,
TelProfile_EnableCurrentDisconnect,
TelProfile_EnableDigitDelivery, TelProfile_EnableEC,
TelProfile_MWIAnalog, TelProfile_MWIDisplay,
TelProfile_FlashHookPeriod, TelProfile_EnableEarlyMedia,
TelProfile_ProgressIndicator2IP;
TelProfile_1 = voice,$$,1,$$,$$,$$,$$,$$,$$,$$
TelProfile_2 = data,$$,2,$$,$$,$$,$$,$$,$$,$$
[\TelProfile]
21.5.1.1 DSP Pattern Detector
For TDM tunneling applications, you can use the DSP pattern detector feature to initiate
the echo canceller at call start. The device can be configured to support detection of a
specific one-byte idle data pattern transmitted over digital E1/T1 timeslots. The device can
be configured to detect up to four different one-byte data patterns. When the defined idle
data pattern is detected, the channel resets its echo canceller.
 To configure DSP pattern detector:
1.
In the IPMedia Settings page (Configuration tab > VoIP menu > Media > IPMedia
Settings), do the following:
a.
b.
Set the 'IPMedia Detectors' parameter (EnableDSPIPMDetectors) to Enable.
Set the 'Enable Pattern Detector' parameter (EnablePatternDetector) to Enable.
2.
Configure the number (e.g., 5) of consecutive patterns to trigger the pattern detection
event, using the ini file parameter, PDThreshold.
3.
Configure the patterns that can be detected by the Pattern Detector, using the ini file
parameter, PDPattern. For example:
PDPattern = 84, 85, 212, 213 ; for idle patterns 54, 55, D4
and D5
21.5.2 QSIG Tunneling
The device supports QSIG tunneling over SIP, according to IETF Internet-Draft draft-elwellsipping-qsig-tunnel-03 ("Tunnelling of QSIG over SIP") and ECMA-355/ISO/IEC 22535.
This is applicable to all ISDN variants. QSIG tunneling can be applied to all calls or to
specific calls using IP Profiles.
Note: TDM tunneling is applicable to PRI and BRI.
QSIG tunneling sends all QSIG messages as raw data in corresponding SIP messages
using a dedicated message body. This is used, for example, to enable two QSIG
subscribers connected to the same or different QSIG PBX to communicate with each other
over an IP network. Tunneling is supported in both directions (Tel-to-IP and IP-to-Tel).
The term tunneling means that messages are transferred ‘as is’ to the remote side without
being converted (QSIG > SIP > QSIG). The advantage of tunneling over QSIG-to-SIP
User's Manual
344
Document #: LTRT-27034
User's Manual
21. Digital PSTN
interworking is that by using interworking, QSIG functionality can only be partially achieved.
When tunneling is used, all QSIG capabilities are supported and the tunneling medium (the
SIP network) does not need to process these messages.
QSIG messages are transferred in SIP messages in a separate Multipurpose Internet Mail
Extensions (MIME) body. Therefore, if a message contains more than one body (e.g., SDP
and QSIG), multipart MIME must be used. The Content-Type of the QSIG tunneled
message is ‘application/QSIG’. The device also adds a Content-Disposition header in the
following format:
Content-Disposition: signal; handling=required.
QSIG tunneling is done as follows:

Call setup (originating device): The QSIG Setup request is encapsulated in the SIP
INVITE message without being altered. After the SIP INVITE request is sent, the
device does not encapsulate the subsequent QSIG message until a SIP 200 OK
response is received. If the originating device receives a 4xx, 5xx, or 6xx response, it
disconnects the QSIG call with a ‘no route to destination’ cause.

Call setup (terminating device): After the terminating device receives a SIP INVITE
request with a 'Content-Type: application/QSIG', it sends the encapsulated QSIG
Setup message to the Tel side and sends a 200 OK response (no 1xx response is
sent) to IP. The 200 OK response includes an encapsulated QSIG Call Proceeding
message (without waiting for a Call Proceeding message from the Tel side). If
tunneling is disabled and the incoming INVITE includes a QSIG body, a 415 response
is sent.

Mid-call communication: After the SIP connection is established, all QSIG
messages are encapsulated in SIP INFO messages.

Call tear-down: The SIP connection is terminated once the QSIG call is complete.
The Release Complete message is encapsulated in the SIP BYE message that
terminates the session.
 To enable QSIG tunneling:
1.
In the Digital Gateway Parameters page (Configuration tab > VoIP menu > GW and
IP to IP > Digital Gateway > Digital Gateway Parameters), set the 'Enable QSIG
Tunneling' parameter (EnableQSIGTunneling) to Enable on the originating and
terminating devices.
2.
Configure the QSIGTunnelingMode parameter for defining the format of encapsulated
QSIG message data in the SIP message MIME body (0 for ASCII presentation; 1 for
binary encoding).
3.
Set the ISDNDuplicateQ931BuffMode parameter to 128 to duplicate all messages.
4.
Set the ISDNInCallsBehavior parameter to 4096.
5.
Set the ISDNRxOverlap parameter to 0 for tunneling of QSIG overlap-dialed digits
(see below for description).
The configuration of the ISDNInCallsBehavior and ISDNRxOverlap parameters allows
tunneling of QSIG overlap-dialed digits (Tel to IP). In this configuration, the device delays
the sending of the QSIG Setup Ack message upon receipt of the QSIG Setup message.
Instead, the device sends the Setup Ack message to QSIG only when it receives the SIP
INFO message with Setup Ack encapsulated in its MIME body. The PBX sends QSIG
Information messages (to complete the Called Party Number) only after it receives the
Setup Ack. The device relays these Information messages encapsulated in SIP INFO
messages to the remote party.
Version 6.8
345
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.6
ISDN Non-Facility Associated Signaling (NFAS)
In regular T1 ISDN trunks, a single 64 kbps channel carries signaling for the other 23 Bchannels of that particular T1 trunk. This channel is called the D-channel and usually
resides on timeslot # 24. ISDN Non-Facility Associated Signaling (NFAS) enables the use
of a single D-channel to control multiple PRI interfaces.
Note: NFAS is applicable only to T1 trunks.
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 device supports up to 12 NFAS groups. Each group can comprise up to 10 T1 trunks
and each group must contain different 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 NFAS group is identified by an NFAS GroupID number (possible values are 1 to 12).
To assign a number of T1 trunks to the same NFAS group, use the NFASGroupNumber_x
= groupID (where x is the physical trunk ID (0 to the maximum number of trunks) or the
Web interface (see ''Configuring Trunk Settings'' on page 333).
The parameter DchConfig_x = Trunk_type defines 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’ denotes the physical trunk ID (0 to the maximum number of trunks). You can also
use the Web interface (see ''Configuring Trunk Settings'' on page 333).
For example, to assign the first four 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
;Primary T1 trunk
DchConfig_1 = 1
;Backup T1 trunk
DchConfig_2 = 2
;24 B-channel NFAS trunk
DchConfig_3 = 2
;24 B-channel NFAS trunk
The NFAS parameters are described in ''PSTN Parameters'' on page 857.
21.6.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 (see note below).
The Interface ID can be defined per 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 trunk, 1 for the second T1
trunk, and so on, up to the maximum number of trunks).
User's Manual
346
Document #: LTRT-27034
User's Manual
21. Digital PSTN
To define an explicit Interface ID for a T1 trunk (that is different from the default), use the
following parameters:

ISDNIBehavior_x = 512 (x = 0 to the maximum number of trunks identifying the
device's physical trunk)

ISDNNFASInterfaceID_x = ID (x = 0 to 255)
Notes:
• 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 ISDNIBehavior_x to 2048’ forces the
inclusion of the Channel Identifier parameter also for the Primary trunk.
• 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
ISDNIBehavior_x = 2048 in the ini file.
21.6.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

InterfaceID #2 for a 24 B-channel T1 trunk

InterfaceID #3 for a 24 B-channel T1 trunk, and so on for subsequent T1 trunks
For example, if four T1 trunks on a device are configured as a single NFAS group with
Primary and Backup T1 trunks that is used with a DMS-100 switch, the following
parameters should be used:
NFASGroupNumber_0 = 1
NFASGroupNumber_1 = 1
NFASGroupNumber_2 = 1
NFASGroupNumber_3 = 1
DchConfig_0 = 0
;Primary T1 trunk
DchConfig_1 = 1
;Backup T1 trunk
DchConfig_2 = 2
;B-Channel NFAS trunk
DchConfig_3 = 2
;B-channel NFAS trunk
If there is no NFAS Backup trunk, the following configuration should be used:
ISDNNFASInterfaceID_0 = 0
ISDNNFASInterfaceID_1 = 2
ISDNNFASInterfaceID_2 = 3
ISDNNFASInterfaceID_3 = 4
ISDNIBehavior = 512
;This parameter should be added because of
;ISDNNFASInterfaceID coniguration above
NFASGroupNumber_0 = 1
NFASGroupNumber_1 = 1
NFASGroupNumber_2 = 1
NFASGroupNumber_3 = 1
DchConfig_0 = 0
;Primary T1 trunk
DchConfig_1 = 2
;B-Channel NFAS trunk
DchConfig_2 = 2
;B-Channel NFAS trunk
DchConfig_3 = 2
;B-channel NFAS trunk
Version 6.8
347
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.6.3 Creating an NFAS-Related Trunk Configuration
The procedures for creating and deleting an NFAS group must be performed in the correct
order, as described below.
 To create an NFAS Group:
1.
If there’s a backup (‘secondary’) trunk for this group, it must be configured first.
2.
Configure the primary trunk before configuring any NFAS (‘slave’) trunk.
3.
Configure NFAS (‘slave’) trunks.
 To stop / delete an NFAS Group:
1.
Stop or delete (by setting ProtocolType to 0, i.e., 'None') all NFAS (‘slave’) trunks.
2.
Stop or delete (by setting ProtocolType to 0, i.e., 'None') the backup trunk if a backup
trunk exists.
3.
Stop or delete (by setting ProtocolType to 0, i.e., 'None') the primary trunk.
Notes:
• All trunks in the group must be configured with the same values for trunk
parameters TerminationSide, ProtocolType, FramingMethod, and LineCode.
• After stopping or deleting the backup trunk, delete the group and then reconfigure
it.
21.6.4 Performing Manual D-Channel Switchover in NFAS Group
If an NFAS group is configured with two D-channels (Primary and Backup), you can do a
manual switchover between these D-channels.
 To manually switchover from active to standby D-channel:
1.
Open the NFAS Group & D-Channel Status page (Status & Diagnostics tab > VoIP
Status menu > NFAS Group & D-Channel Status).
2.
Select the required NFAS group, and then click the Switch Activity button.
Notes:
• The Switch Activity button is unavailable (i.e, grayed out) if a switchover cannot
be done due to, for example, alarms or unsuitable states.
• This feature is applicable only to T1 ISDN protocols supporting NFAS, and only if
the NFAS group is configured with two D-channels.
21.7
ISDN Overlap Dialing
Overlap dialing is a dialing scheme used by several ISDN variants to send and/or receive
called number digits one after the other (or several at a time). This is in contrast to en-bloc
dialing in which a complete number is sent in one message.
The device supports the following ISDN overlap dialing methods:

Collects ISDN called party number digits and then sends the SIP INVITE to the IP side
with the complete destination number (see ''Collecting ISDN Digits and Sending
Complete Number in SIP'' on page 349)

Interworks ISDN overlap dialing with SIP, according to RFC 3578 (see ''Interworking
ISDN Overlap Dialing with SIP According to RFC 3578'' on page 350)
User's Manual
348
Document #: LTRT-27034
User's Manual
21. Digital PSTN
Note: ISDN overlap dialing is applicable to PRI and BRI.
21.7.1 Collecting ISDN Digits and Sending Complete Number in SIP
The device can support an overlap dialing mode whereby the device collects the called
party number digits from ISDN Q.931 Information messages or DTMF signals, and then
sends a SIP INVITE message to the IP side containing the complete destination number.
ISDN overlap dialing for incoming ISDN calls can be configured for the entire device or per
ISDN trunk. This is configured using the global, ISDNRxOverlap parameter or the
ISDNRxOverlap_x parameter (where x denotes the trunk number), respectively.
By default (see the ISDNINCallsBehavior parameter), the device plays a dial tone to the
ISDN user side when it receives an empty called number from the ISDN. In this scenario,
the device includes the Progress Indicator in the SetupAck ISDN message that it sends to
the ISDN side.
The device can also mute in-band DTMF detection until it receives the complete
destination number from the ISDN. This is configured using the MuteDTMFInOverlap
parameter. The Information digits can be sent in-band in the voice stream, or out-of-band
using Q.931 Information messages. If Q.931 Information messages are used, the DTMF inband detector must be disabled. Note that when at least one digit is received in the ISDN
Setup message, the device stops playing a dial tone.
The device stops collecting digits (from the ISDN) upon the following scenarios:

The device receives a Sending Complete IE in the ISDN Setup or Information
messages, indicating no more digits.

The timeout between received digits expires (configured by the TimeBetweenDigits
parameter).

The maximum number of received digits has been reached (configured by the
MaxDigits parameter).

A match is found with the defined digit map (configured by the DigitMapping
parameter).
Relevant parameters (described in ''PSTN Parameters'' on page 857):

ISDNRxOverlap_x = 1 (can be configured per trunk)

TimeBetweenDigits

MaxDigits

MuteDTMFInOverlap

DigitMapping
For configuring ISDN overlap dialing using the Web interface, see ''Configuring Trunk
Settings'' on page 333.
Version 6.8
349
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
21.7.2 Interworking ISDN Overlap Dialing with SIP According to RFC
3578
The device supports the interworking of ISDN overlap dialing to SIP and vice versa,
according to RFC 3578.

Interworking ISDN overlap dialing to SIP (Tel to IP): The device sends collected
digits each time it receives them (initially from the ISDN Setup message and then from
subsequent Q.931 Information messages) to the IP side, using subsequent SIP
INVITE messages. You can also define the minimum number of overlap digits to
collect before sending the first SIP message (INVITE) for routing the call, using the
MinOverlapDigitsForRouting parameter.

Interworking SIP to ISDN overlap dialing (IP to Tel): For each received SIP INVITE
pertaining to the same dialog session, the device sends an ISDN Setup message (and
subsequent Q.931 Information messages) with the collected digits to the Tel side. For
all subsequent INVITEs received, the device sends a SIP 484 "Address Incomplete"
response to the IP in order to maintain the current dialog session and to receive
additional digits from subsequent INVITEs.
Relevant parameters (described in ''PSTN Parameters'' on page 857):

ISDNRxOverlap = 2

ISDNTxOverlap

ISDNOutCallsBehavior = 2

MinOverlapDigitsForRouting

TimeBetweenDigits

MaxDigits

DigitMapping

MuteDTMFInOverlap
For configuring ISDN overlap dialing using the Web interface, see ''Configuring Trunk
Settings'' on page 333.
21.8
Redirect Number and Calling Name (Display)
The following tables define the device's redirect number and calling name (Display) support
for various ISDN variants according to NT (Network Termination) / TE (Termination
Equipment) interface direction:
Table 21-2: Calling Name (Display)
NT/TE Interface
DMS-100
NI-2
4/5ESS
Euro ISDN
QSIG
NT-to-TE
Yes
Yes
Yes
Yes
Yes
TE-to-NT
Yes
Yes
Yes
No
Yes
Table 21-3: Redirect Number
NT/TE Interface
DMS-100
NI-2
4/5ESS
Euro ISDN
QSIG
NT-to-TE
Yes
Yes
Yes
Yes
Yes
TE-to-NT
Yes
Yes
Yes
Yes*
Yes
* When using ETSI DivertingLegInformation2 in a Facility IE (not Redirecting Number IE).
User's Manual
350
Document #: LTRT-27034
User's Manual
22
22. Trunk Group
Trunk Group
This section describes the configuration of the device's channels, which includes assigning
them to Trunk Groups.
22.1
Configuring Trunk Group Table
The Trunk Group table lets you configure up to 120 Trunk Groups. A Trunk Group is a
logical group of physical trunks and channels. A Trunk Group can include multiple trunks
and ranges of channels. To enable and activate the channels of the device, Trunk Groups
need to be configured and assigned with telephone numbers. Channels that are not
configured in this table are disabled.
Once you have configured your Trunk Groups, you need to use them for routing incoming
IP calls to the Tel side, which is represented by a specific Trunk Group (ID). For configuring
IP-to-Tel routing rules, see ''Configuring Inbound IP Routing Table'' on page 392. You can
also use Trunk Groups for routing Tel calls to the IP side. For configuring Tel-to-IP routing
rules, see ''Configuring Outbound IP Routing Table'' on page 383.
The following procedure describes how to configure Trunk Groups in the Web interface.
You can also configure this using the table ini file parameter, TrunkGroup_x or CLI
command, configure voip > gw hunt-or-trunk-group trunk-group.
 To configure a Trunk Group:
1.
Open the Trunk Group Table page (Configuration tab > VoIP menu > GW and IP to
IP > Trunk Group > Trunk Group).
2.
Configure a Trunk Group according to the parameters described in the table below.
3.
Click Submit, and then save ("burn") your settings to flash memory.
You can also register all your Trunk Groups. The registration method per Trunk Group is
configured by the 'Registration Mode' parameter in the Trunk Group Settings page (see
''Configuring Trunk Group Settings'' on page 353).

To register the Trunk Groups, click the Register button, located below the Trunk
Group table.

To unregister the Trunk Groups, click the Unregister button, located below the Trunk
Group table.
Version 6.8
351
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Table 22-1: Trunk Group Table Parameter Descriptions
Parameter
Description
Module
CLI: module
[TrunkGroup_Module]
Defines the module (i.e., FXS, FXO, PRI, or BRI) for which you
want to define the Trunk Group.
From Trunk
CLI: first-trunk-id
[TrunkGroup_FirstTrunkId]
Defines the starting physical Trunk number in the Trunk Group.
The number of listed Trunks depends on the device's hardware
configuration.
Note: This parameter is applicable only to PRI and BRI
modules.
To Trunk
CLI: last-trunk-id
[TrunkGroup_LastTrunkId]
Defines the ending physical Trunk number in the Trunk Group.
The number of listed Trunks depends on the device's hardware
configuration.
Note: This parameter is applicable only to PRI and BRI
modules.
Channels
CLI: first-b-channel
[TrunkGroup_FirstBChannel]
CLI: last-b-channel
[TrunkGroup_LastBChannel]
Defines the device's channels/ports (analog module) or Trunk
B-channels (digital module). To enable channels, enter the
channel numbers.
You can enter a range of channels by using the syntax n-m,
where n represents the lower channel number and m the higher
channel number. For example, "1-4" specifies channels 1
through 4. To represent all the Trunk's B-channels, enter a
single asterisk (*).
Note: The number of defined channels must not exceed the
maximum number of the Trunk’s B-channels.
Phone Number
Defines the telephone number(s) of the channels.
CLI: first-phone-number
The valid value can be up to 50 characters.
[TrunkGroup_FirstPhoneNumber]
For a range of channels, enter only the first telephone number.
Subsequent channels are assigned the next consecutive
telephone number. For example, if you enter 400 for channels
1 to 4, then channel 1 is assigned phone number 400, channel
2 is assigned phone number 401, and so on.
These numbers are also used for channel allocation for IP-toTel calls if the Trunk Group’s ‘Channel Select Mode’ parameter
is set to By Dest Phone Number.
Notes:
 If this field includes alphabetical characters and the phone
number is defined for a range of channels (e.g., 1-4), then
the phone number must end with a number (e.g., 'user1').
 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 ReplaceEmptyDstWithPortNumber
parameter). These numbers are used to replace them.
 This field is ignored if routing of IP-to-Tel calls is done
according to the Supp Services table, where multiple line
extension numbers are configured per port (see
''Configuring ISDN BRI Supplementary Services'' on page
451). For this routing method, the 'Channel Select Mode'
must be set to Select Trunk By Supplementary Services
Table in the Trunk Group Settings table (see ''Configuring
Trunk Group Settings'' on page 353).
User's Manual
352
Document #: LTRT-27034
User's Manual
22. Trunk Group
Parameter
Description
Trunk Group ID
CLI: trunk-group-id
[TrunkGroup_TrunkGroupNum]
Defines the Trunk Group ID for the specified channels. The
same Trunk Group ID can be assigned to more than one group
of channels. If an IP-to-Tel call is assigned to a Trunk Group,
the IP call is routed to the channel(s) pertaining to that Trunk
Group ID.
The valid value can be 0 to 119.
Tel Profile ID
CLI: tel-profile-id
[TrunkGroup_ProfileId]
Assigns a Tel Profile ID to the Trunk Group.
Note: For configuring Tel Profiles, see ''Configuring Tel
Profiles'' on page 299.
22.2
Configuring Trunk Group Settings
The Trunk Group Settings lets you configure various settings per Trunk Group. The main
settings include:

Channel select method, which defines how the device allocates IP-to-Tel calls to the
channels of a Trunk Group.

Registration method for registering Trunk Groups to remote IP servers (Serving IP
Group).
For configuring Trunk Groups, see Configuring Trunk Group Table on page 351.
The following procedure describes how to configure settings for Trunk Groups in the Web
interface. You can also configure this using the table ini file parameter, TrunkGroupSettings
or CLI command, configure voip/gw hunt-or-trunk-group trunk-group-setting.
 To configure settings for Trunk Group Settingss:
1.
Open the Trunk Group Settings page (Configuration tab > VoIP menu > GW and IP
to IP > Trunk Group > Trunk Group Settings).
2.
Configure a Trunk Group according to the parameters described in the table below.
3.
Click Submit, and then save ("burn") your settings to flash memory.
Table 22-2: Trunk Group Settings Parameter Descriptions
Parameter
Trunk Group ID
CLI: trunk-group-id
[TrunkGroupSettings_TrunkGr
Version 6.8
Description
Defines the Trunk Group ID that you want to configure.
353
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Channel Select Mode
CLI: channel-select-mode
[TrunkGroupSettings_Channel
SelectMode]
Defines the method by which IP-to-Tel calls are assigned to the
channels of the Trunk Group.
 [0] By Dest Phone Number = The channel is selected
according to the called (destination) number. If the number is
not located, the call is released. If the channel is unavailable
(e.g., busy), the call is put on call waiting (if call waiting is
enabled and no other call is on call waiting); otherwise, the call
is released.
 [1] Cyclic Ascending = The next available channel in the Trunk
Group, in ascending cyclic order is selected. After the device
reaches the highest channel number in the Trunk Group, it
selects the lowest channel number in the Trunk Group, and
then starts ascending again.
 [2] Ascending = The lowest available channel in the Trunk
Group is selected, and if unavailable, the next higher channel
is selected.
 [3] Cyclic Descending = The next available channel in
descending cyclic order is selected. The next lower channel
number in the Trunk Group is always selected. When the
device reaches the lowest channel number in the Trunk
Group, it selects the highest channel number in the Trunk
Group, and then starts descending again.
 [4] Descending = The highest available channel in the Trunk
Group is selected, and if unavailable, the next lower channel is
selected.
 [5] Dest Number + Cyclic Ascending = The channel is
selected according to the called number. If the called number
isn't found, the next available channel in ascending cyclic
order is selected.
Note: If the called number is located, but the port associated
with the number is busy, the call is released.
 [6] By Source Phone Number = The channel is selected
according to the calling number.
 [7] Trunk Cyclic Ascending = The channel from the first
channel of the next trunk (adjacent to the trunk from which the
previous channel was selected) is selected. This option is
applicable only to digital interfaces.
 [8] Trunk & Channel Cyclic Ascending = The device
implements the Trunk Cyclic Ascending and Cyclic Ascending
methods to select the channel. This method selects the next
physical trunk in the Trunk Group, and then selects the Bchannel of this trunk according to the Cyclic Ascending
method (i.e., selects the channel after the last allocated
channel). This option is applicable only to digital interfaces.
For example, if the Trunk Group includes two physical trunks,
0 and 1:
 For the first incoming call, the first channel of Trunk 0 is
selected.
 For the second incoming call, the first channel of Trunk 1
is selected.
 For the third incoming call, the second channel of Trunk 0
is selected.
oupId]
User's Manual
354
Document #: LTRT-27034
User's Manual
22. Trunk Group
Parameter
Description

[9] Ring to Hunt Group = The device allocates IP-to-Tel calls
to all the FXS ports (channels) in the Hunt Group. When a call
is received for the Hunt Group, all telephones connected to the
FXS ports belonging to the Hunt Group start ringing. The call
is eventually received by whichever telephone first answers
the call (after which the other phones stop ringing). This option
is applicable only to FXS interfaces.
 [10] Select Trunk by Supplementary Services Table = The BRI
port/module is selected according to the settings in the ISDN
Supplementary Services table (see Configuring ISDN BRI
Supplementary Services on page 451), allowing the routing of
IP-to-Tel calls to specific BRI endpoints according to extension
number.
 [11] Dest Number + Ascending = The device allocates a
channels to incoming IP-to-Tel calls as follows:
a. The device attempts to route the call to the channel that is
associated with the destination (called) number. If located,
the call is sent to that channel.
b. If the number is not located or the channel is unavailable
(e.g., busy), the device searches in ascending order for
the next available channel in the Trunk Group. If located,
the call is sent to that channel.
c. If all the channels are unavailable, the call is released.
Note: If this parameter is not configured, the Trunk Group's
channel select method is according to the global parameter,
ChannelSelectMode.
Registration Mode
Defines the registration method for the Trunk Group:
CLI: registration-mode
 [1] Per Gateway = (Default) Single registration for the entire
[TrunkGroupSettings_Registrat
device. This is applicable only if a default Proxy or Registrar IP
ionMode]
is configured and Registration is enabled (i.e., parameter
IsRegisterUsed is set to 1). In this mode, the SIP URI user
part in the From, To, and Contact headers is set to the value
of the global registration parameter, GWRegistrationName or
username if GWRegistrationName is not configured.
 [0] Per Endpoint = Each channel in the Trunk Group registers
individually. The registrations are sent to the 'Serving IP Group
ID' if defined in the table, otherwise, it is sent to the default
Proxy, and if no default Proxy, then to the Registrar IP.
 [4] Don't Register = No registrations are sent by endpoints
pertaining to the Trunk Group. For example, if the device is
configured globally to register all its endpoints (using the
parameter ChannelSelectMode), you can exclude some
endpoints from being registered by assigning them to a Trunk
Group and configuring the Trunk Group registration mode to
'Don't Register'.
 [5] Per Account = Registrations are sent (or not) to an IP
Group, according to the settings in the Account table (see
''Configuring Registration Accounts'' on page 279).
An example is shown below of a REGISTER message for
registering endpoint "101" using the registration Per Endpoint
mode:
REGISTER sip:SipGroupName SIP/2.0
Via: SIP/2.0/UDP
Version 6.8
355
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
10.33.37.78;branch=z9hG4bKac862428454
From: <sip:101@GatewayName>;tag=1c862422082
To: <sip:101@GatewayName>
Call-ID: 9907977062512000232825@10.33.37.78
CSeq: 3 REGISTER
Contact: <sip:101@10.33.37.78>;expires=3600
Expires: 3600
User-Agent: Sip-Gateway/v.6.60A.011.002
Content-Length: 0
The "SipGroupName" in the Request-URI is configured in the IP
Group table (see ''Configuring IP Groups'' on page 261).
Notes:
 If this parameter is not configured, the registration is
performed according to the global registration parameter,
ChannelSelectMode.
 To enable Trunk Group registration, set the global parameter,
IsRegisterNeeded to 1. This is unnecessary for 'Per Account'
registration mode.
 If the device is configured globally to register Per Endpoint and
an channel group includes four channels to register Per
Gateway, the device registers all channels except the first four
channels. The group of these four channels sends a single
registration request.
Serving IP Group ID
CLI: serving-ip-group
[TrunkGroupSettings_ServingI
PGroup]
Assigns an IP Group to where INVITE messages received from
this Trunk Group are sent. The actual destination to where these
INVITE messages are sent is according to the Proxy Set ID
associated with the IP Group. The Request-URI host name in the
INVITE and REGISTER messages (except for 'Per Account'
registration modes) is set to the value of the 'SIP Group Name'
parameter configured in the IP Group table (see ''Configuring IP
Groups'' on page 261).
Notes:
 If this parameter is not configured, the INVITE messages are
sent to the default Proxy or according to the Outbound IP
Routing table (see ''Configuring Outbound IP Routing Table''
on page 383).
 If the PreferRouteTable parameter is set to 1 (see
''Configuring Proxy and Registration Parameters'' on page
283), the routing rules in the Outbound IP Routing table take
precedence over the selected Serving IP Group ID.
Gateway Name
CLI: gateway-name
[TrunkGroupSettings_Gateway
Name]
Defines the host name for the SIP From header in INVITE
messages and for the From/To headers in REGISTER requests.
Note: If this parameter is not configured, the global parameter,
SIPGatewayName is used.
Contact User
CLI: contact-user
[TrunkGroupSettings_Contact
User]
Defines the user part for the SIP Contact URI in INVITE
messages and for the From, To, and Contact headers in
REGISTER requests.
Notes:
 This parameter is applicable only if the 'Registration Mode'
parameter is set to 'Per Account' and registration through the
Account table is successful.
 If registration fails, the user part in the INVITE Contact header
is set to the source party number.
User's Manual
356
Document #: LTRT-27034
User's Manual
22. Trunk Group
Parameter
Description

The 'Contact User' parameter in the Account table overrides
this parameter (see ''Configuring Registration Accounts'' on
page 279).
Trunk Group Name
CLI: trunk-group-name
[TrunkGroupSettings_TrunkGr
oupName]
Defines a name for the Trunk Group. This name represents the
Trunk Group in the SIP 'tgrp' parameter of the outgoing INVITE
messages (according to RFC 4904). For example:
sip:+16305550100;tgrp=TG-1;trunk-context=+1630@isp.example.net;user=phone
The valid value can be a string of up to 20 characters. By default,
no name is configured.
Notes:
 If this parameter is not configured, the Trunk Group decimal
number is used in the SIP 'tgrp' parameter.
 This feature is enabled by any of the following parameters:
 UseSIPtgrp
 UseBroadsoftDTG
 Currently, this parameter can only be configured using the ini
file.
MWI Interrogation Type
CLI: mwi-interrogation-type
[TrunkGroupSettings_MWIInterro
gationType]
Defines MWI QSIG-to-IP interworking for interrogating MWI
supplementary services:
 [255] Not Configured
 [0] None = Disables the feature.
 [1] Use Activate Only = MWI Interrogation messages are not
sent and only "passively" responds to MWI Activate requests
from the PBX.
 [2] Result Not Used = MWI Interrogation messages are sent,
but the result is not used. Instead, the device waits for MWI
Activate requests from the PBX.
 [3] Use Result = MWI Interrogation messages are sent, its
results are used, and the MWI Activate requests are used.
MWI Activate requests are interworked to SIP NOTIFY MWI
messages. The SIP NOTIFY messages are sent to the IP
Group defined by the NotificationIPGroupID parameter.
Note: This parameter appears in the table only if the
VoiceMailInterface parameter is set to 3 (QSIG). Configuring
Voice Mail on page 456.
Version 6.8
357
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This page is intentionally left blank.
User's Manual
358
Document #: LTRT-27034
User's Manual
23
23. Manipulation
Manipulation
This section describes the configuration of various manipulation processes.
23.1
Configuring General Settings
The General Settings page allows you to configure general manipulation parameters. For a
description of the parameters appearing on this page, see ''Configuration Parameters
Reference'' on page 715.
 To configure the general manipulation parameters:
1.
Open the General Settings page (Configuration tab > VoIP menu > GW and IP to IP
> Manipulations >General Settings).
Figure 23-1: General Settings Page
23.2
2.
Configure the parameters as required.
3.
Click Submit.
Configuring Source/Destination Number
Manipulation Rules
The number manipulation tables lets you configure rules for manipulating source and
destination telephone numbers for IP-to-Tel and Tel-to-IP calls. The number manipulation
tables include the following:


Tel-to-IP calls:
•
Source Phone Number Manipulation Table for Tel > IP Calls (up to 120 entries)
•
Destination Phone Number Manipulation Table for Tel > IP Calls (up to 120
entries)
IP-to-Tel calls:
•
Source Phone Number Manipulation Table for IP > Tel Calls (up to 120 entries)
•
Destination Phone Number Manipulation Table for IP > Tel Calls (up to 120
entries)
The number manipulation tables provide two configuration areas:

Matching characteristics (Rule) of incoming call, for example, prefix of destination
number.

Manipulation operation (Action), for example, remove user-defined number of digits
from the left of the number.
If the incoming call matches the characteristics of a rule, its manipulation action is applied.
The device searches a matching manipulation rule starting from the first entry (i.e., top of
the table). In other words, a rule at the top of the table takes precedence over a rule
defined lower down in the table. Thus, define more specific rules above more generic rules.
For example, if you enter 551 in Index 1 and 55 in Index 2, the device applies rule 1 to
numbers that start with 551 and applies rule 2 to numbers that start with 550, 552, 553, and
so on until 559. However, if you enter 55 in Index 1 and 551 in Index 2, the device applies
rule 1 to all numbers that start with 55, including numbers that start with 551.
Version 6.8
359
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
You can perform a second "round" (additional) of source and destination number
manipulations for IP-to-Tel calls, on an already manipulated number. The initial and
additional number manipulation rules are both configured in the number manipulation
tables for Ip-to-Tel calls. The additional manipulation is performed on the initially
manipulated number. Thus, for complex number manipulation schemes, you only need to
configure relatively few manipulation rules in these tables (that would otherwise require
many rules). To enable this additional manipulation, use the following parameters:

Source number manipulation - PerformAdditionalIP2TELSourceManipulation

Destination number manipulation - PerformAdditionalIP2TELDestinationManipulation
Telephone number manipulation can be useful, for example, for the following:

Stripping or adding dialing plan digits from or to the number, respectively. For
example, a user may need to first dial 9 before dialing the phone number to indicate
an external line. This number 9 can then be removed by number manipulation before
the call is setup.

Allowing or blocking Caller ID information according to destination or source prefixes.
For more information on Caller ID, see Configuring Caller Display Information on page
463.

For digital modules only: Assigning Numbering Plan Indicator (NPI) and Type of
Numbering (TON) to IP-to-Tel calls. The device can use a single global setting for
NPI/TON classification or it can use the setting in the manipulation tables on a call-bycall basis.
Number manipulation can occur 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 or add a prefix to that number before it is routed. To determine when
number manipulation is performed, use the 'IP to Tel Routing Mode' parameter
(RouteModeIP2Tel) described in ''Configuring Inbound IP Routing Table'' on page 392, and
'Tel to IP Routing Mode' parameter (RouteModeTel2IP) described in ''Configuring
Outbound IP Routing Table'' on page 383.
The device manipulates the number in the following order: 1) strips digits from the left of
the number, 2) strips digits from the right of the number, 3) retains the defined number of
digits, 4) adds the defined prefix, and then 5) adds the defined suffix.
The following procedure describes how to configure number manipulation rules in the Web
interface. You can also configure this using the following management tools:

Destination Phone Number Manipulation Table for IP > Tel Calls table: ini file
table parameter, NumberMapIP2Tel or CLI command, configure voip/gw
manipulations dst-number-map-ip2tel

Destination Phone Number Manipulation Table for Tel > IP Calls table: ini file
table parameter, NumberMapTel2IP or CLI command, configure voip/gw
manipulations dst-number-map-tel2ip

Source Phone Number Manipulation Table for IP > Tel Calls table: ini file table
parameter, SourceNumberMapIP2Tel or CLI command, configure voip/gw
manipulations src-number-map-ip2tel

Source Phone Number Manipulation Table for Tel > IP Calls table: ini file table
parameter, SourceNumberMapTel2IP or CLI command, configure voip/gw
manipulations src-number-map-tel2ip
User's Manual
360
Document #: LTRT-27034
User's Manual
23. Manipulation
 To configure a number manipulation rule:
1.
Open the required Number Manipulation page (Configuration tab > VoIP menu > GW
and IP to IP > Manipulations > Dest Number IP->Tel, Dest Number Tel->IP,
Source Number IP->Tel, or Source Number Tel->IP); the relevant Manipulation
table page is displayed.
2.
Click Add; the following dialog box appears:
Figure 23-2: Number Manipulation Table - Add Dialog Box
3.
Configure a number manipulation rule according to the parameters described in the
table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
The table below shows configuration examples of Tel-to-IP source phone number
manipulation rules, where:

Rule 1: When the destination number has the prefix 03 (e.g., 035000), source number
prefix 201 (e.g., 20155), and from source IP Group ID 2, the source number is
changed to, for example, 97120155.

Rule 2: When the source number has prefix 1001 (e.g., 1001876), it is changed to
587623.

Rule 3: When the source number has prefix 123451001 (e.g., 1234510012001), it is
changed to 20018.

Rule 4: When the source number has prefix from 30 to 40 and a digit (e.g., 3122), it is
changed to 2312.

Rule 5: When the destination number has the prefix 6, 7, or 8 (e.g., 85262146),
source number prefix 2001, it is changed to 3146.
Parameter
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Source IP Group
2
0
-
-
-
Destination
Prefix
03
*
*
[6,7,8]
Source Prefix
201
1001
123451001#
[30-40]x
2001
Stripped Digits
from Left
-
4
-
-
5
Stripped Digits
from Right
-
-
-
1
-
Version 6.8
361
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Rule 1
Rule 2
Rule 3
Rule 4
Rule 5
Prefix to Add
971
5
-
2
3
Suffix to Add
-
23
8
-
-
Number of
Digits to Leave
-
-
4
-
-
Allowed
Restricted
-
-
-
Presentation
Table 23-1: Number Manipulation Tables Parameter Descriptions
Parameter
Description
Index
[_Index]
Defines an index number for the new table record.
Manipulation Name
[_ManipulationName]
Defines an arbitrary name to easily identify the manipulation rule.
The valid value is a string of up to 20 characters. By default, no value is
defined.
Matching Characteristics (Rule)
Web: Destination Prefix
EMS: Prefix
CLI: dst-prefix
[_DestinationPrefix]
Defines the destination (called) telephone number prefix and/or suffix.
You can use special notations for denoting the prefix. For example,
[100-199](100,101,105) denotes a number that starts with 100 to 199
and ends with 100, 101 or 105. You can also use the $ sign to denote
calls without a called number. For a description of available notations,
see ''Dialing Plan Notation for Routing and Manipulation Tables'' on
page 713.
Web/EMS: Source Prefix
CLI: src-prefix
[_SourcePrefix]
Defines the source (calling) telephone number prefix and/or suffix. You
can use special notations for denoting the prefix. For example, [100199](100,101,105) denotes a number that starts with 100 to 199 and
ends with 100, 101 or 105. You can also use the $ sign to denote calls
without a calling number. For a description of available notations, see
''Dialing Plan Notation for Routing and Manipulation Tables'' on page
713.
Web/EMS: Source IP
Address
CLI: src-ip-address
[_SourceAddress]
Defines the source IP address of the caller. This is obtained from the
Contact header in the INVITE message.
Notes:
 This parameter is applicable only to the number manipulation tables
for IP-to-Tel calls.
 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.
 The source IP address can include the asterisk (*) wildcard to
represent any number between 0 and 255. For example, 10.8.8.*
represents all IP addresses between 10.8.8.0 and 10.8.8.255.
Web: Source Host Prefix
CLI: src-host-prefix
[_SrcHost]
Defines the URI host name prefix of the incoming SIP INVITE message
in the From header.
Notes:
 This parameter is applicable only to the number manipulation tables
for IP-to-Tel calls.
 The asterisk (*) wildcard can be used to denote any prefix.
 If the P-Asserted-Identity header is present in the incoming INVITE
message, then the value of this parameter is compared to the P-
User's Manual
362
Document #: LTRT-27034
User's Manual
23. Manipulation
Parameter
Description
Asserted-Identity URI host name (instead of the From header).
Web: Destination Host
Prefix
CLI: dst-host-prefix
[_DestHost]
Defines the Request-URI host name prefix of the incoming SIP INVITE
message.
Notes:
 This parameter is applicable only to the number manipulation tables
for IP-to-Tel calls.
 The asterisk (*) wildcard can be used to denote any prefix.
Web: Source Trunk Group
CLI: src-trunk-group-id
[_SrcTrunkGroupID]
Defines the source Trunk Group ID for Tel-to-IP calls. To denote all
Trunk Groups, leave this field empty.
Notes:
 The value -1 indicates that this field is ignored in the rule.
 This parameter is applicable only to the number manipulation tables
for Tel-to-IP calls.
 For IP-to-IP call routing, this parameter is not required (i.e., leave
the field empty).
Web: Source IP Group
CLI: src-ip-group-id
[_SrcIPGroupID]
Defines the IP Group from where the IP call originated. Typically, the IP
Group of an incoming INVITE is determined or classified using the
Inbound IP Routing table. If not used (i.e., any IP Group), leave the field
empty.
Notes:
 The value -1 indicates that this field is ignored.
 This parameter is applicable only to the number manipulation tables
for Tel-to-IP calls.
 If this Source IP Group has a Serving IP Group, then all calls from
this Source IP Group are sent to the Serving IP Group. In this
scenario, this table is used only if the PreferRouteTable parameter
is set to 1.
Web: Destination IP Group
CLI: dst-ip-group-id
[_DestIPGroupID]
Defines the IP Group to where the call is sent.
Notes:
 The value -1 indicates that this field is ignored.
 This parameter is applicable only to the Destination Phone Number
Manipulation Table for Tel -> IP Calls.
Operation (Action)
Web: Stripped Digits From
Left
EMS: Number Of Stripped
Digits
CLI: remove-from-left
[_RemoveFromLeft]
Defines the number of digits 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.
Web: Stripped Digits From
Right
EMS: Number Of Stripped
Digits
CLI: remove-from-right
[RemoveFromRight]
Defines the number of digits to remove from the right of the telephone
number prefix. For example, if you enter 3 and the phone number is
5551234, the new phone number is 5551.
Web: Prefix to Add
EMS: Prefix/Suffix To Add
CLI: prefix-to-add
[Prefix2Add]
Defines the number or string that you want added to the front of the
telephone number. For example, if you enter 9 and the phone number
is 1234, the new number is 91234.
Version 6.8
363
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Web: Suffix to Add
EMS: Prefix/Suffix To Add
CLI: suffix-to-add
[Suffix2Add]
Defines the number or string that you want added to the end of the
telephone number. For example, if you enter 00 and the phone number
is 1234, the new number is 123400.
Web/EMS: Number of
Digits to Leave
CLI: num-of-digits-to-leave
[LeaveFromRight]
Defines the number of digits that you want to keep from the right of the
phone number. For example, if you enter 4 and the phone number is
00165751234, then the new number is 1234.
Web: NPI
EMS: Number Plan
CLI: npi
[NumberPlan]
Defines the Numbering Plan Indicator (NPI).
 [0] Unknown (default)
 [9] Private
 [1] E.164 Public
 [-1] Not Configured = value received from PSTN/IP is used
Notes:
 This parameter is applicable only to number manipulation tables for
IP-to-Tel calls.
 NPI can be used in the SIP Remote-Party-ID header by using the
EnableRPIHeader and AddTON2RPI parameters.
 For more information on available NPI/TON values, see Numbering
Plans and Type of Number on page 382.
Web: TON
EMS: Number Type
CLI: ton
[NumberType]
Defines the Type of Number (TON).
 If you selected 'Unknown' for the NPI, you can select Unknown [0].
 If you selected 'Private' for the NPI, you can select Unknown [0],
Level 2 Regional [1], Level 1 Regional [2], PISN Specific [3] or
Level 0 Regional (Local) [4].
 If you selected 'E.164 Public' for the NPI, you can select Unknown
[0], International [1], National [2], Network Specific [3], Subscriber
[4] or Abbreviated [6].
The default is 'Unknown'.
Notes:
 This parameter is applicable only to number manipulation tables for
IP-to-Tel calls.
 TON can be used in the SIP Remote-Party-ID header by using the
EnableRPIHeader and AddTON2RPI parameters.
 For more information on available NPI/TON values, see Numbering
Plans and Type of Number on page 382.
Web: Presentation
Enables caller ID.
EMS: Is Presentation
 Not Configured = Privacy is determined according to the Caller ID
Restricted
table (see Configuring Caller Display Information on page 463).
CLI: is-presentation [0] Allowed = Sends Caller ID information when a call is made using
restricted
these destination/source prefixes.
[IsPresentationRestricted]
 [1] Restricted = Restricts Caller ID information for these prefixes.
Notes:
 This field is applicable only to number manipulation tables for source
phone number manipulation.
 If this field is set to Restricted and the 'Asserted Identity Mode'
(AssertedIdMode) parameter is set to Add P-Asserted-Identity, the
From header in the INVITE message includes the following: From:
'anonymous' <sip: anonymous@anonymous.invalid> and 'privacy:
id' header.
User's Manual
364
Document #: LTRT-27034
User's Manual
23.3
23. Manipulation
Manipulating Number Prefix
The device supports a notation for adding a prefix where part of the prefix is first extracted
from a user-defined location in the original destination or source number. This notation is
entered in the 'Prefix to Add' field in the Number Manipulation tables (see ''Configuring
Source/Destination Number Manipulation'' on page 359): x[n,l]y...
where,

x = any number of characters/digits to add at the beginning of the number (i.e. first
digits in the prefix).

[n,l] = defines the location in the original destination or source number where the digits
y are added:

•
n = location (number of digits counted from the left of the number) of a specific
string in the original destination or source number.
•
l = number of digits that this string includes.
y = prefix to add at the specified location.
For example, assume that you want to manipulate an incoming IP call with destination
number +5492028888888 (area code 202 and phone number 8888888) to the number
0202158888888. To perform such a manipulation, the following configuration is required in
the Number Manipulation table:
1.
The following notation is used in the 'Prefix to Add' field:
0[5,3]15
where,
2.
•
0 is the number to add at the beginning of the original destination number.
•
[5,3] denotes a string that is located after (and including) the fifth character (i.e.,
the first '2' in the example) of the original destination number, and its length being
three digits (i.e., the area code 202, in the example).
•
15 is the number to add immediately after the string denoted by [5,3] - in other
words, 15 is added after (i.e. to the right of) the digits 202.
The first seven digits from the left are removed from the original number, by entering
"7" in the 'Stripped Digits From Left' field.
Table 23-2: Example of Configured Rule for Manipulating Prefix using Special Notation
Parameter
Rule 1
+5492028888888
Destination Prefix
Source Prefix
*
Source IP Address
*
Stripped Digits from Left
7
0[5,3]15
Prefix to Add
In this configuration example, the following manipulation process occurs:
1.
The prefix is calculated as 020215.
2.
The first seven digits from the left are removed from the original number, thereby
changing the number to 8888888.
3.
The prefix that was previously calculated is then added.
Version 6.8
365
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
23.4
SIP Calling Name Manipulations
The calling name manipulation tables lets you configure up to 120 manipulation rules for
manipulating the calling name (i.e., caller ID) in SIP messages, for IP-to-Tel and Tel-to-IP
calls. Manipulation includes modifying or removing the calling name. The calling name
manipulation tables include the following:

Calling Name Manipulation Table for IP-to-Tel Calls table

Calling Name Manipulation Table for Tel-to-IP Calls table
For example, assume that an incoming SIP INVITE message includes the following
header:
P-Asserted-Identity: "company:john" sip:6666@78.97.79.104
Using the Calling Name Manipulation Table for IP-to-Tel table, the text "company" can be
changed to "worker" in the outgoing INVITE, as shown below:
P-Asserted-Identity: "worker:john" sip:996666@10.13.83.10
The calling name manipulation tables provide two configuration areas:

Matching characteristics (Rule) of incoming call, for example, prefix of destination
number.

Manipulation operation (Action), for example, remove user-defined number of digits
from the left of the calling name.
If the incoming call matches the characteristics of a rule, its manipulation action is applied.
Note: For using the Calling Name Manipulation Table for Tel-to-IP Calls table for
retrieving the calling name (display name) from an Active Directory using LDAP
queries, see Querying the AD for Calling Name on page 225.
The following procedure describes how to configure calling name manipulation rules in the
Web interface. You can also configure these rules using the the following management
tools:

Calling Name Manipulation Table for Tel-to-IP Calls table: table ini file parameter,
CallingNameMapTel2Ip or CLI command, configure voip/gw manipulations callingname-map-tel2ip

Calling Name Manipulation Table for IP-to-Tel Calls table: table ini file parameter,
CallingNameMapIp2Tel or CLI command, configure voip/gw manipulations callingname-map-ip2tel
User's Manual
366
Document #: LTRT-27034
User's Manual
23. Manipulation
 To configure calling name manipulation rules:
1.
Open the required calling name manipulations page (Configuration tab > VoIP menu
> GW and IP to IP > Manipulations > Calling Name IP->Tel or Calling Name Tel>IP).
2.
Click Add; the following dialog box appears:
Figure 23-3: Calling Name Manipulation IP2Tel - Rule Tab
3.
Configure a manipulation rule according to the parameters described in the table
below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 23-3: Calling Name Manipulation Tables Parameter Descriptions
Parameter
Description
Index
[_Index]
Defines an index number for the new table record.
Manipulation Name
CLI: manipulation-name
[_ManipulationName]
Defines an arbitrary name to easily identify the manipulation rule.
The valid value is a string of up to 20 characters.
Matching Characteristics (Rule)
Web: Destination Prefix
CLI: dst-prefix
[_DestinationPrefix]
Defines the destination (called) telephone number prefix and/or suffix.
You can use special notations for denoting the prefix. For example,
[100-199](100,101,105) denotes a number that starts with 100 to 199
and ends with 100, 101 or 105. You can also use the $ sign to denote
calls without a called number. For a description of available notations,
see ''Dialing Plan Notation for Routing and Manipulation Tables'' on
page 713.
The default value is the asterisk (*) symbol (i.e., any destination prefix).
Web/EMS: Source Prefix
CLI: src-prefix
[_SourcePrefix]
Defines the source (calling) telephone number prefix and/or suffix.
You can use special notations for denoting the prefix. For example,
[100-199](100,101,105) denotes a number that starts with 100 to 199
and ends with 100, 101 or 105. You can also use the $ sign to denote
calls without a calling number. For a description of available notations,
see ''Dialing Plan Notation for Routing and Manipulation Tables'' on
page 713.
Version 6.8
367
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
The default value is the asterisk (*) symbol (i.e., any source prefix).
Web: Calling Name Prefix
CLI: calling-name-prefix
[_CallingNamePrefix]
Defines the caller name (i.e., caller ID) prefix.
You can use special notations for denoting the prefix. For example, to
denote calls without a calling name, use the $ sign. For a description of
available notations, see ''Dialing Plan Notation for Routing and
Manipulation Tables'' on page 713.
The default value is the asterisk (*) symbol (i.e., any calling name
prefix).
Web: Source Trunk Group
ID
CLI: src-trunk-group-id
[_SrcTrunkGroupID]
Defines the source Trunk Group ID from where the Tel-to-IP call was
received.
The default value is -1, which denotes any Trunk Group.
Note: This parameter is applicable only to the Calling Name
Manipulation Table for Tel-to-IP Calls table.
Web: Source IP Group ID
CLI: src-ip-group-id
[_SrcIPGroupID]
Defines the IP Group from where the IP call was received.
The default value is -1, which denotes any IP Group.
Notes:
 This parameter is applicable only to the IP-to-IP application.
 This parameter is applicable only to the Calling Name Manipulation
Table for Tel-to-IP Calls table.
Web/EMS: Source IP
Address
CLI: src-ip-address
[_SourceAddress]
Defines the source IP address of the caller, for IP-to-Tel calls. The
source IP address appears in the SIP Contact header in the INVITE
message.
 The default value is the asterisk (*) symbol (i.e., any IP address).
The source IP address can include the following wildcards:
 "x" wildcard: represents single digits. For example, 10.8.8.xx
represents all IP addresses between 10.8.8.10 to 10.8.8.99.
 "*" (asterisk) wildcard: represents any number between 0 and 255.
For example, 10.8.8.* represents all IP addresses between 10.8.8.0
and 10.8.8.255.
Note: This parameter is applicable only to the Calling Name
Manipulation Table for IP-to-Tel Calls table.
Web: Source Host Prefix
CLI: src-host-prefix
[_SrcHost]
Defines the URI host name prefix of the incoming SIP INVITE message
in the From header.
The default value is the asterisk (*) symbol (i.e., any source host prefix).
Notes:
 This parameter is applicable only to the Calling Name Manipulation
Table for IP-to-Tel Calls table.
 If the P-Asserted-Identity header is present in the incoming INVITE
message, then the value of this parameter is compared to the PAsserted-Identity URI host name (instead of the From header).
Web: Destination Host
Prefix
CLI: dst-host-prefix
[_DestHost]
Defines the Request-URI host name prefix of the incoming SIP INVITE
message.
The default value is the asterisk (*) symbol (i.e., any destination host
prefix).
Note: This parameter is applicable only to the Calling Name
Manipulation Table for IP-to-Tel Calls table.
Operation (Action)
Web: Stripped Digits From
User's Manual
Defines the number of characters to remove from the left of the calling
368
Document #: LTRT-27034
User's Manual
23. Manipulation
Parameter
Description
Left
EMS: Number Of Stripped
Digits
CLI: remove-from-left
[_RemoveFromLeft]
name. For example, if you enter 3 and the calling name is
"company:john", the new calling name is "pany:john".
Web: Stripped Digits From
Right
EMS: Number Of Stripped
Digits
CLI: remove-from-right
[_RemoveFromRight]
Defines the number of characters to remove from the right of the calling
name. For example, if you enter 3 and the calling name is
"company:name", the new name is "company:n".
Web/EMS: Number of
Digits to Leave
CLI: num-of-digits-to-leave
[LeaveFromRight]
Defines the number of characters that you want to keep from the right
of the calling name. For example, if you enter 4 and the calling name is
"company:name", the new name is "name".
Web: Prefix to Add
EMS: Prefix/Suffix To Add
CLI: prefix-to-add
[_Prefix2Add]
Defines the number or string to add at the front of the calling name. For
example, if you enter ITSP and the calling name is "company:name",
the new name is ITSPcompany:john".
Web: Suffix to Add
EMS: Prefix/Suffix To Add
CLI: suffix-to-add
[_Suffix2Add]
Defines the number or string to add at the end of the calling name. For
example, if you enter 00 and calling name is "company:name", the new
name is "company:name00".
23.5
Configuring Redirect Number IP to Tel
The redirect number manipulation tables let you configure rules for manipulating the
redirect number received in SIP messages. The redirect number manipulation tables
include:

Redirect Number IP-to-Tel table: This table defines IP-to-Tel redirect number
manipulation. You can manipulate the value of the received SIP Diversion, ResourcePriority, or History-Info headers, which is then added to the Redirecting Number
Information Element (IE) in the ISDN Setup message sent to the Tel side. This also
includes the reason for the call redirection. This is configured in the Redirect Number
IP > Tel table.

Redirect Number Tel to IP table: This table defines Tel-to-IP redirect number
manipulation. You can manipulate the prefix of the redirect number, received from the
Tel side, in the outgoing SIP Diversion, Resource-Priority, or History-Info headers sent
to the IP side. This is configured in the Redirect Number Tel > IP table.
The redirect number manipulation tables provide two configuration areas:

Matching characteristics (Rule) of incoming call, for example, prefix of redirect
number.

Manipulation operation (Action), for example, remove user-defined number of digits
from the left of the redirect number.
If the incoming call matches the characteristics of a rule, its manipulation action is applied.
Version 6.8
369
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Notes:
• If the device copies the received destination number to the outgoing SIP redirect
number (enabled by the CopyDest2RedirectNumber parameter), no redirect
number Tel-to-IP manipulation is done.
• The manipulation rules are done in the following order: Stripped Digits From Left,
Stripped Digits From Right, Number of Digits to Leave, Prefix to Add, and then
Suffix to Add.
• The device uses the 'Redirect Prefix' parameter before it manipulates the prefixi.
The following procedure describes how to configure redirect number manipulation rules in
the Web interface. You can also configure these rules using the following management
tools:

Redirect Number IP to Tel table: ini file parameter, RedirectNumberMapIp2Tel or CLI
command, configure voip/gw manipulations redirect-number-map-ip2tel

Redirect Number Tel to IP table: ini file parameter, RedirectNumberMapTel2Ip or CLI
command, configure voip/gw manipulations redirect-number-map-tel2ip (CLI)
 To configure a redirect number manipulation rule:
1.
Open the redirect number manipulation table (Configuration tab > VoIP menu > GW
and IP to IP > Manipulations > Redirect Number Tel > IP or Redirect Number IP >
Tel).
2.
Click Add; the following dialog box appears (e.g., Redirect Number Tel-to-IP table):
Figure 23-4: Redirect Number Manipulation (e.g., Tel to IP)
3.
Configure a manipulation rule according to the parameters described in the table
below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 23-4: Redirect Number Manipulation Tables Parameter Description
Parameter
Description
Index
[_Index]
Defines an index number for the new table record.
Manipulation Name
CLI: manipulation-name
[_ManipulationName]
Defines an arbitrary name to easily identify the manipulation rule.
The valid value is a string of up to 20 characters.
Matching Characteristics - Rule
User's Manual
370
Document #: LTRT-27034
User's Manual
23. Manipulation
Parameter
Description
Web/EMS: Destination Prefix
CLI: dst-prefix
[_DestinationPrefix]
Defines the destination (called) telephone number prefix.
The default value is the asterisk (*) symbol (i.e., any number).
For manipulating the diverting and redirected numbers for call
diversion, you can use the strings "DN" and "RN" to denote the
destination prefix of these numbers. For more information, see
Manipulating Redirected and Diverted Numbers for Call Diversion on
page 373.
Web/EMS: Redirect Prefix
CLI: redirect-prefix
[_RedirectPrefix]
Defines the redirect telephone number prefix.
The default value is the asterisk (*) symbol (i.e., any number prefix).
Web: Source Trunk Group ID Defines the Trunk Group from where the Tel call is received.
CLI: src-trunk-group-id
To denote any Trunk Group, leave this field empty. The value -1
[_SrcTrunkGroupID]
indicates that this field is ignored in the rule.
Notes:
 This parameter is applicable only to the Redirect Number Tel > IP
table.
 This parameter is not applicable to IP-to-IP call routing.
Source IP Group ID
CLI: src-ip-group-id
[_SrcIPGroupID]
Defines the IP Group from where the IP call originated. Typically, the
IP Group of an incoming INVITE is determined or classified by the
Inbound IP Routing table.
If not used (i.e., any IP Group), leave the field empty. The value -1
indicates that it is ignored in the rule.
Notes:
 This parameter is applicable only to the Redirect Number Tel > IP
table.
 This parameter is applicable only to the IP-to-IP application.
Web/EMS: Source IP
Address
CLI: src-ip-address
[_SourceAddress]
Defines the IP address of the caller. The IP address appears in the
SIP Contact header of the incoming INVITE message.
The default value is the asterisk (*) symbol (i.e., any IP address). The
value can include the following wildcards:
 "x": represents single digits, for example, 10.8.8.xx denotes all
addresses between 10.8.8.10 and 10.8.8.99.
 "*": represents any number between 0 and 255, for example,
10.8.8.* denotes all addresses between 10.8.8.0 and 10.8.8.255.
Note: This parameter is applicable only to the Redirect Number IP-toTel table.
Web: Source Host Prefix
CLI: src-host-prefix
[_SrcHost]
Defines the URI host name prefix of the caller. The host name
appears in the SIP From header of the incoming SIP INVITE
message.
The default value is the asterisk (*) symbol (i.e., any host name
prefix).
Notes:
 This parameter is applicable only to the Redirect Number IP-to-Tel
table.
 If the P-Asserted-Identity header is present in the incoming INVITE
message, then the value of this parameter is compared to the PAsserted-Identity URI host name (instead of to the From header).
Web: Destination Host Prefix
Defines the Request-URI host name prefix, which appears in the
Version 6.8
371
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
CLI: dst-host-prefix
[_DestHost]
Description
incoming SIP INVITE message.
The default value is the asterisk (*) symbol (i.e., any prefix).
Note: This parameter is applicable only to the Redirect Number IP-toTel table.
Operation (Action)
Web: Stripped Digits From
Left
EMS: Remove From Left
CLI: remove-from-left
[_RemoveFromLeft]
Defines the number of digits to remove from the left of the redirect
number prefix. For example, if you enter 3 and the redirect number is
5551234, the new number is 1234.
Web: Stripped Digits From
Right
EMS: Remove From Right
CLI: remove-from-right
[_RemoveFromRight]
Defines the number of digits to remove from the right of the redirect
number prefix. For example, if you enter 3 and the redirect number is
5551234, the new number is 5551.
Web/EMS: Number of Digits
to Leave
CLI: num-of-digits-to-leave
[_LeaveFromRight]
Defines the number of digits that you want to retain from the right of
the redirect number.
Web/EMS: Prefix to Add
CLI: prefix-to-add
[_Prefix2Add]
Defines the number or string that you want added to the front of the
redirect number. For example, if you enter 9 and the redirect number
is 1234, the new number is 91234.
Web/EMS: Suffix to Add
CLI: suffix-to-add
[_Suffix2Add]
Defines the number or string that you want added to the end of the
redirect number. For example, if you enter 00 and the redirect number
is 1234, the new number is 123400.
Web: Presentation
Enables caller ID.
EMS: Is Presentation
 Not Configured = Privacy is determined according to the Caller ID
Restricted
table (see Configuring Caller Display Information on page 463).
CLI: is-presentation [0] Allowed = Sends Caller ID information when a call is made
restricted
using these destination / source prefixes.
[_IsPresentationRestricted]
 [1] Restricted = Restricts Caller ID information for these prefixes.
Note: If this parameter is set to Restricted and the 'AssertedIdMode'
parameter is set to Add P-Asserted-Identity, the From header in the
INVITE message includes the following:
From: 'anonymous' <sip:
anonymous@anonymous.invalid> and 'privacy: id'
header.
Web: TON
EMS: Number Type
CLI: ton
[_NumberType]
User's Manual
Defines the Type of Number (TON).
The default is Not Configured [-1].
 If NPI is set to Unknown, you can set TON to Unknown [0].
 If NPI is set to Private, you can set TON to Unknown [0],
International [1], National [2], Network Specific [3] or Subscriber
[4].
 If NPI is set to E.164 Public, you can set TON to Unknown [0],
International [1], National [2], Network Specific [3], Subscriber [4]
or Abbreviated [6].
For more information on available NPI/TON values, see Numbering
Plans and Type of Number on page 382.
372
Document #: LTRT-27034
User's Manual
23. Manipulation
Parameter
Description
Web: NPI
EMS: Number Plan
CLI: npi
[_NumberPlan]
23.6
Defines the Numbering Plan Indicator (NPI).
[-1] Not Configured = (Default) Value received from PSTN/IP is
used
 [0] Unknown
 [1] E.164 Public
 [9] Private
For more information on available NPI/TON values, see Numbering
Plans and Type of Number on page 382.

Manipulating Redirected and Diverted Numbers for
Call Diversion
You can configure manipulation rules to manipulate the Diverted-to and Diverting numbers
received in the incoming Call Redirection Facility message for call diversion, which is
interworked to outgoing SIP 302 responses. This feature is applicable to the Euro ISDN
and QSIG variants, and to IP-to-Tel calls.
The incoming redirection Facility message includes, among other parameters, the
Diverted-to number and Diverting number. The Diverted-to number (i.e., new destination) is
mapped to the user part in the Contact header of the SIP 302 response. The Diverting
number is mapped to the user part in the Diversion header of the SIP 302 response.
These two numbers can be manipulated by entering the following special strings in the
'Destination Prefix' field of the Redirect Number Tel-to-IP table:

"RN" - used in the rule to manipulate the Redirected number (i.e., originally called
number or Diverting number).

"DN" - used in the rule to manipulate the Diverted-to number (i.e., the new called
number or destination). This manipulation is done on the user part in the Contact
header of the SIP 302 response.
For example, assume the following required manipulation:

Manipulate Redirected number 6001 (originally called number) to 6005

Manipulate Diverted-to number 8002 (the new called number or destination) to 8005
The configuration in the Redirect Number Tel-to-IP table is as follows:
Table 23-5: Redirect Number Configuration Example
Parameter
Rule 1
Rule 2
RN
DN
Redirect Prefix
6
8
Stripped Digits From Right
1
1
Suffix to Add
5
5
Number of Digits to Leave
5
-
Destination Prefix
After the above manipulation is done, the device sends the following outgoing SIP 302
response:
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TLS 10.33.45.68;branch=z9hG4bKac54132643;alias
From: "MP118 1" <sip:8001@10.33.45.68>;tag=1c54119560
To: <sip:6001@10.33.45.69;user=phone>;tag=1c664560944
Version 6.8
373
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Call-ID: 541189832710201115142@10.33.45.68
CSeq: 1 INVITE
Contact: <sip:8005@10.33.45.68;user=phone>
Supported: em,timer,replaces,path,early-session,resource-priority
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUB
SCRIBE,UPDATE
Diversion: <tel:6005>;reason=unknown;counter=1
Server: Audiocodes-Sip-Gateway-IPmedia 260_UN/v.6.20A.043.001
Reason: SIP ;cause=302 ;text="302 Moved Temporarily"
Content-Length: 0
23.7
Mapping NPI/TON to SIP Phone-Context
The Phone Context table lets you configure rules for mapping the Numbering Plan
Indication (NPI) and Type of Number (TON) to the SIP 'phone-context' parameter, and vice
versa. The 'phone-context' parameter appears in the standard SIP headers where a phone
number is used (i.e., Request-URI, To, From, and Diversion). When a call is received from
the ISDN/Tel side, the NPI and TON are compared against the table and the matching
'phone-context' value is used in the outgoing SIP INVITE message. The same mapping
occurs when an INVITE with a 'phone-context' parameter is received.
For example, for a Tel-to-IP call with NPI/TON set as E164 National (values 1/2), the
device can send the following SIP INVITE URI:
sip:12365432;phone-context= na.e.164.nt.com
For an IP-to-Tel call, if the incoming INVITE contains this 'phone-context' (e.g. "phonecontext= na.e.164.nt.com"), the NPI/TON of the called number in the outgoing Setup
message is changed to E164 National.
The following procedure describes how to configure NPI/TON-SIP phone-context mapping
rules in the Web interface. You can also configure this using the table ini file parameter,
PhoneContext or CLI command, configure voip > gw manipulations phone-context-table.
 To configure NPI/TON-SIP phone-context mapping rules:
1.
Open the Phone Context Table page (Configuration tab > VoIP menu > GW and IP
to IP > Manipulations > Phone Context).
2.
Click Add; the following dialog box appears:
Figure 23-5: Phone Context Table Page
3.
Configure a mapping rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Note: You can configure multiple rows with the same NPI/TON or same SIP 'phonecontext'. In such a configuration, a Tel-to-IP call uses the first matching rule in the
table.
User's Manual
374
Document #: LTRT-27034
User's Manual
23. Manipulation
Table 23-6: Phone Context Table Parameter Description
Parameter
Description
Index
[PhoneContext_Index]
Defines an index number for the new table record.
Add Phone Context As Prefix
CLI: configure voip > gw
manipulations general-setting
> add-ph-cntxt-as-pref
[AddPhoneContextAsPrefix]
Determines whether the received SIP 'phone-context' parameter is
added as a prefix to the outgoing ISDN Setup message (for digital
interfaces) with called and calling numbers.
 [0] Disable (default)
 [1] Enable
NPI
CLI: npi
[PhoneContext_Npi]
Defines the Number Plan Indicator (NPI).
 [0] Unknown (default)
 [1] E.164 Public
 [9] Private
For a detailed list of the available NPI/TON values, see Numbering
Plans and Type of Number on page 382.
TON
CLI: ton
[PhoneContext_Ton]
Defines the Type of Number (TON).
 If you selected Unknown as the NPI, you can select Unknown [0].
 If you selected Private as the NPI, you can select one of the
following:
 [0] Unknown
 [1] Level 2 Regional
 [2] Level 1 Regional
 [3] PSTN Specific
 [4] Level 0 Regional (Local)
 If you selected E.164 Public as the NPI, you can select one of the
following:
 [0] Unknown
 [1] International
 [2] National
 [3] Network Specific
 [4] Subscriber
 [6] Abbreviated
Phone Context
CLI: context
[PhoneContext_Context]
Defines the SIP 'phone-context' URI parameter.
23.8
Configuring Release Cause Mapping
The release cause mapping tables let you configure rules to map up to 12 different ISDN
ITU-T Q.850 release cause codes (call failure) to SIP response codes, and vice versa.
These tables allow you to override the default ISDN-SIP release cause mappings,
described in ''Fixed Mapping of ISDN Release Reason to SIP Response'' on page 378 and
''Fixed Mapping of SIP Response to ISDN Release Reason'' on page 377.
The release cause mapping tables include:

Release Cause Mapping from SIP to ISDN table: Maps SIP release codes to ISDN
cause codes. When a SIP response is received from the IP side, the device searches
this table for a match. If the SIP response is found, the Q.850 Release Cause
assigned to it is sent to the PSTN. If no match is found, the default static mapping is
used.

Release Cause Mapping from ISDN to SIP table: Maps ISDN cause codes to SIP
Version 6.8
375
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
release codes. When a Release Cause is received from the PSTN, the device
searches this table for a match. If the Q.850 Release Cause is found, the SIP
response assigned to it is sent to the IP side. If no match is found, the default static
mapping is used.
Note: For Tel-to-IP calls, you can also map the less commonly used SIP responses to
a single default ISDN Release Cause, using the DefaultCauseMapISDN2IP
parameter. This parameter defines a default ISDN Cause that is always used except
when the following Release Causes are received: Normal Call Clearing (16), User
Busy (17), No User Responding (18) or No Answer from User (19).
The following procedure describes how to configure ISDN-SIP release cause mapping in
the Web interface. You can also configure this mapping using the following management
platforms:

Release Cause Mapping from ISDN to SIP table: ini file parameter,
CauseMapISDN2SIP or CLI command, configure voip > gw manipulations cause-mapisdn2sip

Release Cause Mapping from SIP to ISDN table:ini file parameter,
CauseMapSIP2ISDN or CLI command, configure voip > gw manipulations cause-mapsip2isdn
 To configure an ISDN-SIP release cause mapping rule:
1.
Open the required release cause mapping table (Configuration tab > VoIP menu >
GW and IP to IP > Manipulations > Release Cause SIP > ISDN or Release Cause
ISDN > SIP).
2.
Click Add; the following dialog box appears:
Figure 23-6: Release Cause Mapping - Add Record
3.
Configure a mapping rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
Table 23-7: Release Cause Mapping Tables Parameter Descriptions
Parameter
Description
Index
[CauseMapSip2Isdn_Index]
[CauseMapIsdn2Sip_Index]
Defines an index number for the new table record.
Sip Response
CLI: sip-response
[CauseMapSip2Isdn_SipResponse]
[CauseMapIsdn2Sip_SipResponse]
Defines the SIP response code (e.g., 406).
Q.850 Causes
Defines the ISDN Q.850 cause code (e.g., 6).
CLI: q850-causes
[CauseMapSip2Isdn_IsdnReleaseCause]
[CauseMapIsdn2Sip_IsdnReleaseCause]
User's Manual
376
Document #: LTRT-27034
User's Manual
23. Manipulation
23.8.1 Fixed Mapping of SIP Response to ISDN Release Reason
The following table describes the mapping of SIP response to ISDN release reason.
Table 23-8: Mapping of SIP Response to ISDN Release Reason
SIP Response
Description
ISDN Release
Reason
Description
400*
Bad request
31
Normal, unspecified
401
Unauthorized
21
Call rejected
402
Payment required
21
Call rejected
403
Forbidden
21
Call rejected
404
Not found
1
Unallocated number
405
Method not allowed
63
Service/option unavailable
406
Not acceptable
79
Service/option not implemented
407
Proxy authentication required
21
Call rejected
408
Request timeout
102
Recovery on timer expiry
409
Conflict
41
Temporary failure
410
Gone
22
Number changed w/o diagnostic
411
Length required
127
Interworking
413
Request entity too long
127
Interworking
414
Request URI too long
127
Interworking
415
Unsupported media type
79
Service/option not implemented
420
Bad extension
127
Interworking
480
Temporarily unavailable
18
No user responding
481*
Call leg/transaction doesn’t
exist
127
Interworking
482*
Loop detected
127
Interworking
483
Too many hops
127
Interworking
484
Address incomplete
28
Invalid number format
485
Ambiguous
1
Unallocated number
486
Busy here
17
User busy
488
Not acceptable here
31
Normal, unspecified
500
Server internal error
41
Temporary failure
501
Not implemented
38
Network out of order
502
Bad gateway
38
Network out of order
503
Service unavailable
41
Temporary failure
504
Server timeout
102
Recovery on timer expiry
505*
Version not supported
127
Interworking
Version 6.8
377
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
SIP Response
ISDN Release
Reason
Description
Description
600
Busy everywhere
17
User busy
603
Decline
21
Call rejected
604
Does not exist anywhere
1
Unallocated number
606*
Not acceptable
38
Network out of order
* Messages and responses were created because the ‘ISUP to SIP Mapping’ draft does
not specify their cause code mapping.
23.8.2 Fixed Mapping of ISDN Release Reason to SIP Response
The following table describes the mapping of ISDN release reason to SIP response.
Table 23-9: Mapping of ISDN Release Reason to SIP Response
ISDN Release
Reason
SIP
Response
Description
Description
1
Unallocated number
404
Not found
2
No route to network
404
Not found
3
No route to destination
404
Not found
6
Channel unacceptable
406
*
7
Call awarded and being delivered in an
established channel
500
16
Normal call clearing
17
User busy
486
Busy here
18
No user responding
408
Request timeout
19
No answer from the user
480
Temporarily unavailable
21
Call rejected
403
Forbidden
22
Number changed w/o diagnostic
410
Gone
26
Non-selected user clearing
404
Not found
27
Destination out of order
502
Bad gateway
28
Address incomplete
484
Address incomplete
29
Facility rejected
501
Not implemented
30
Response to status enquiry
501*
Not implemented
31
Normal unspecified
480
Temporarily unavailable
34
No circuit available
503
Service unavailable
38
Network out of order
503
Service unavailable
41
Temporary failure
503
Service unavailable
42
Switching equipment congestion
503
Service unavailable
43
Access information discarded
502*
Bad gateway
User's Manual
-*
378
Not acceptable
Server internal error
BYE
Document #: LTRT-27034
User's Manual
ISDN Release
Reason
23. Manipulation
SIP
Response
Description
Description
44
Requested channel not available
503*
Service unavailable
47
Resource unavailable
503
Service unavailable
49
QoS unavailable
503*
Service unavailable
50
Facility not subscribed
503*
Service unavailable
55
Incoming calls barred within CUG
403
Forbidden
57
Bearer capability not authorized
403
Forbidden
58
Bearer capability not presently available
503
Service unavailable
63
Service/option not available
503*
Service unavailable
65
Bearer capability not implemented
501
Not implemented
66
Channel type not implemented
480*
Temporarily unavailable
69
Requested facility not implemented
503*
Service unavailable
70
Only restricted digital information bearer
capability is available
503*
Service unavailable
79
Service or option not implemented
501
Not implemented
81
Invalid call reference value
502*
Bad gateway
82
Identified channel does not exist
502*
Bad gateway
83
Suspended call exists, but this call
identity does not
503*
Service unavailable
84
Call identity in use
503*
Service unavailable
85
No call suspended
503*
Service unavailable
86
Call having the requested call identity
has been cleared
408*
Request timeout
87
User not member of CUG
503
Service unavailable
88
Incompatible destination
503
Service unavailable
91
Invalid transit network selection
502*
Bad gateway
95
Invalid message
503
Service unavailable
96
Mandatory information element is
missing
409*
Conflict
97
Message type non-existent or not
implemented
480*
Temporarily not available
98
Message not compatible with call state
or message type non-existent or not
implemented
409*
Conflict
99
Information element non-existent or not
implemented
480*
Not found
100
Invalid information elements contents
501*
Not implemented
Version 6.8
379
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
ISDN Release
Reason
SIP
Response
Description
Description
101
Message not compatible with call state
503*
Service unavailable
102
Recovery of timer expiry
408
Request timeout
111
Protocol error
500
Server internal error
127
Interworking unspecified
500
Server internal error
* Messages and responses were created because the ‘ISUP to SIP Mapping’ draft doesn’t
specify their cause code mapping.
User's Manual
380
Document #: LTRT-27034
User's Manual
23. Manipulation
23.8.3 Reason Header
The device supports the SIP Reason header according to RFC 3326. The Reason header
conveys information describing the disconnection cause of a call:

Sending Reason header: If a call is disconnected from the Tel side (ISDN), the
Reason header is set to the received Q.850 cause in the appropriate message
(BYE/CANCEL/final failure response) and sent to the SIP side. If the call is
disconnected because of a SIP reason, the Reason header is set to the appropriate
SIP response.

Receiving Reason header: If a call is disconnected from the IP side and the SIP
message includes the Reason header, it is sent to the Tel side according to the
following logic:
•
•
If the Reason header includes a Q.850 cause, it is sent as is.
If the Reason header includes a SIP response:
If the message is a final response, the response status code is translated to
Q.850 format and passed to ISDN.
♦
If the message isn’t a final response, it is translated to a Q.850 cause.
♦
•
When the Reason header is received twice (i.e., SIP Reason and Q.850), the
Q.850 takes precedence over the SIP reason and is sent to the Tel side.
23.8.4 Mapping PSTN Release Cause to SIP Response
The device's FXO interface interoperates between the SIP network and the PSTN/PBX.
This interoperability includes the mapping of PSTN/PBX Call Progress tones to SIP 4xx or
5xx responses for IP-to-Tel calls. The converse is also true - for Tel-to-IP calls, the SIP 4xx
or 5xx responses are mapped to tones played to the PSTN/PBX.
When establishing an IP-to-Tel call, the following rules are applied:

If the remote party (PSTN/PBX) is busy and the FXO device detects a busy tone, it
sends a SIP 486 Busy response to IP. If it detects a reorder tone, it sends a SIP 404
Not Found (no route to destination) to IP. In both cases the call is released. Note that
if the 'Disconnect Call on Busy Tone Detection' parameter is set to Disable, the FXO
device ignores the detection of busy and reorder tones and does not release the call.

For all other FXS/FXO release types such as:
•
no free channels in the Trunk Group,
•
an appropriate call routing rule to a Trunk Group doesn’t exist, or
•
the phone number isn’t found
then the device sends a SIP response to the IP according to the 'Default Release
Cause' parameter. This parameter defines Q.931 release causes. Its default value is
3, which is mapped to the SIP 404 response. By changing its value to 34, the SIP 503
response is sent. Other causes can be used as well.
Version 6.8
381
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
23.9
Numbering Plans and Type of Number
The IP-to-Tel destination or source number manipulation tables allow you to classify
numbers by their Numbering Plan Indication (NPI) and Type of Number (TON). The device
supports all NPI/TON classifications used in the ETSI ISDN variant, as shown in the table
below:
Table 23-10: NPI/TON Values for ETSI ISDN Variant
NPI
TON
Description
Unknown [0]
Unknown [0]
A valid classification, but one that has no information
about the numbering plan.
E.164 Public
[1]
Unknown [0]
A public number in E.164 format, but no information
on what kind of E.164 number.
International [1]
Private [9]
A public number in complete international E.164
format, e.g., 16135551234.
National [2]
A public number in complete national E.164 format,
e.g., 6135551234.
Network Specific [3]
The type of number "network specific number" is
used to indicate administration / service number
specific to the serving network, e.g., used to access
an operator.
Subscriber [4]
A public number in complete E.164 format
representing a local subscriber, e.g., 5551234.
Abbreviated [6]
The support of this code is network dependent. The
number provided in this information element presents
a shorthand representation of the complete number
in the specified numbering plan as supported by the
network.
Unknown [0]
A private number, but with no further information
about the numbering plan.
Level 2 Regional [1]
Level 1 Regional [2]
A private number with a location, e.g., 3932200.
PISN Specific [3]
Level 0 Regional (local) [4]
A private local extension number, e.g., 2200.
For NI-2 and DMS-100 ISDN variants, the valid combinations of TON and NPI for calling
and called numbers include (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
User's Manual
382
Document #: LTRT-27034
User's Manual
24
24. Routing
Routing
This section describes the configuration of call routing rules.
24.1
Configuring General Routing Parameters
The Routing General Parameters page allows you to configure general routing parameters.
For a description of these parameters, see ''Configuration Parameters Reference'' on page
715.
 To configure general routing parameters:
1.
24.2
Open the Routing General Parameters page (Configuration tab > VoIP menu > GW
and IP to IP > Routing > General Parameters).
2.
Configure the parameters as required.
3.
Click Submit.
Configuring Outbound IP Routing Table
The Outbound IP Routing table lets you configure up to 180 Tel-to-IP or outbound IP call
routing rules. The device uses these rules to route calls from the Tel or IP to a user-defined
IP destination. You can also configure the device to process the routing rule before or after
it has performed number manipulation, if necessary.
The Outbound IP Routing table provides two configuration areas:

Version 6.8
Matching Characteristics: Characteristics of the incoming call. If the call
characteristics match a table entry, the routing rule is used to route the call to the
specified destination. One or more characteristics can be defined for the rule:
•
Source IP Group (to which the call belongs)
•
Source and destination Request-URI host name prefix
•
Source Trunk Group (from where the call is received)
•
Source (calling) and destination (called) telephone number prefix and suffix
383
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
•

Source and destination Request-URI host name prefix
Destination: If the call matches the configured characteristics, the device routes the
call to an IP destination. If no characteristics match is found in the table, the call is
rejected. The destination can be any of the following:
•
IP address in dotted-decimal notation.
•
Fully Qualified Domain Name (FQDN).
•
E.164 Telephone Number Mapping (ENUM service).
•
Lightweight Directory Access Protocol (LDAP). For a description, see Routing
Based on LDAP Active Directory Queries on page 226.
•
IP Group, where the call is routed to the IP address configured for the Proxy Set
or SRD associated with the IP Group (configured in ''Configuring IP Groups'' on
page 261). If the device is configured with multiple SRDs, you can also indicate
(in the table's 'Dest. SRD' field) the destination SRD for routing to one of the
following destination types - IP address, FQDN, ENUM, or LDAP. If the SRD is
not specified, then the default SRD (0) is used. In scenarios where routing is to
an IP Group, the destination SRD is obtained from the SRD associated with the
IP Group (in the IP Group table). The specified destination SRD determines the:
♦
Destination SIP interface (SIP port and control IP interface) - important when
using multiple SIP control VLANs
♦
Media Realm (port and IP interface for media / RTP voice)
♦
Other SRD-related interfaces and features on which the call is routed
Since each call must have a destination IP Group (even in cases where the
destination type is not to an IP Group), in cases when the IP Group is not specified,
the SRD's default IP Group is used, which is the first configured IP Group that belongs
to the SRD.
Figure 24-1: Locating SRD
User's Manual
384
Document #: LTRT-27034
User's Manual
24. Routing
Notes:
When using a proxy server, you do not need to configure this table, unless
you require one of the following:
• Fallback (alternative) routing if communication is lost with the proxy server.
• IP security, whereby the device routes only received calls whose source IP
addresses are defined in this table. IP security is enabled using the
SecureCallsFromIP parameter.
• Filter Calls to IP feature: the device checks this table before a call is routed to the
proxy server. However, if the number is not allowed, i.e., the number does not
exist in the table or a Call Restriction (see below) routing rule is applied, the call is
released.
• Obtain different SIP URI host names (per called number).
• Assign IP Profiles to calls.
• For this table to take precedence over a proxy for routing calls, you need to set the
parameter PreferRouteTable to 1. The device checks the 'Destination IP Address'
field in this table for a match with the outgoing call; a proxy is used only if a match
is not found.
In addition to basic outbound IP routing, this table supports the following features:

Least Cost Routing (LCR): If the LCR feature is enabled, the device searches the
routing table for matching routing rules and then selects the one with the lowest call
cost. The call cost of the routing rule is done by assigning it a Cost Group. For
configuring Cost Groups, see ''Least Cost Routing'' on page 226. If two routing rules
have identical costs, then the rule appearing higher up in the table (i.e., first-matched
rule) is used. If a selected route is unavailable, the device uses the next least-cost
routing rule. However, even if a matched rule is not assigned a Cost Group, the device
can select it as the preferred route over other matched routing rules with Cost Groups,
according to the settings of the LCR parameter, LCRDefaultCost (see ''Enabling LCR
and Configuring Default LCR'' on page 228).

Call Forking: If the Tel-to-IP Call Forking feature is enabled, the device can send a
Tel call to multiple IP destinations. An incoming Tel call with multiple matched routing
rules (e.g., all with the same source prefix numbers) can be sent (forked) to multiple IP
destinations if all these rules are configured with a Forking Group. The call is
established with the first IP destination that answers the call.

Call Restriction: Rejects calls whose matching routing rule is configured with the
destination IP address of 0.0.0.0.

Always Use Routing Table: Even if a proxy server is used, the SIP Request-URI
host name in the outgoing INVITE message is obtained from this table. Using this
feature, you can assign a different SIP URI host name for different called and/or
calling numbers. This feature is enabled using the AlwaysUseRouteTable parameter.

IP Profiles: IP Profiles can be assigned to destination addresses (also when a proxy
is used).

Alternative Routing (when a proxy isn't used): An alternative IP destination
(alternative routing rule) can be configured for specific calls ("main" routing rule).
When the "main" route fails (e.g., busy), the device can send the call to the alternative
route. You must configure the alternative routing rules in table rows (indices) that are
located anywhere below the "main" routing rule. For example, if you configure a "main"
routing rule in Index 4, the alternative routing rule can be configured in Index 6. In
addition, you must configure the alternative routing rules with identical matching
characteristics (e.g., destination prefix number) to the "main" routing rule, but assigned
with different destination IP addresses. Instead of an IP address, you can use an
FQDN to resolve into two IP addresses. For more information on alternative routing,
see ''Alternative Routing for Tel-to-IP Calls'' on page 398.

Advice of Charge (AOC): AOC is a pre-billing feature that tasks the rating engine
Version 6.8
385
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
with calculating the cost of using a service (Tel-to-IP call) and relaying that information
to the customer. AOC, which is configured in the Charge Codes table, can be applied
per Tel-to-IP routing rule.
Note: You can configure up to three alternative routing rules per "main" routing rule in
the Inbound IP Routing table.
The following procedure describes how to configure Tel-to-IP or outbound IP routing rules
in the Web interface. You can also configure these rules using the table ini file parameter,
Prefix or CLI command, configure voip > gw routing tel2ip-routing.
 To configure Tel-to-IP or outbound IP routing rules:
1.
Open the Outbound IP Routing Table page (Configuration tab > VoIP menu > GW
and IP to IP > Routing > Tel to IP Routing).
Figure 24-2: Outbound IP Routing Page
2.
From the 'Routing Index' drop-down list, select the range of entries that you want to
add.
3.
Configure a routing rule according to the parameters described in the table below.
4.
Click Submit, and then save ("burn") your settings to flash memory.
The table below shows configuration examples of Tel-to-IP or outbound IP routing rules,
where:

Rule 1 and 2 (Least Cost Routing rule): For both rules, the called (destination)
phone number prefix is 10, the caller's (source) phone number prefix is 100, and the
call is assigned IP Profile ID 1. However, Rule 1 is assigned a cheaper Cost Group
than Rule 2, and therefore, the call is sent to the destination IP address (10.33.45.63)
associated with Rule 1.

Rule 3 (IP Group destination rule): For all callers (*), if the called phone number
prefix is 20, the call is sent to IP Group 1 (whose destination is the IP address
configured for its associated Proxy Set ID).

Rule 4 (domain name destination rule): If the called phone number prefix is 5, 7, 8,
or 9 and the caller belongs to Trunk Group ID 1, the call is sent to domain.com.

Rule 5 (block rule): For all callers (*), if the called phone number prefix is 00, the call
is rejected (discarded).

Rule 6, 7, and 8 (Forking Group rule): For all callers (*), if the called phone number
prefix is 100, the call is sent to Rule 7 and 9 (belonging to Forking Group "1"). If their
destinations are unavailable and alternative routing is enabled, the call is sent to Rule
8 (Forking Group "2").
User's Manual
386
Document #: LTRT-27034
User's Manual
24. Routing

Rule 9 (IP-to-IP rule): If an incoming IP call from Source IP Group 2 with domain.com
as source host prefix in its SIP Request-URI, the IP call is sent to IP address
10.33.45.65.
Table 24-1: Example of Tel-to-IP Source Phone Number Manipulation Rules
Parameter
Rule 1
Rule 2
Rule
3
Rule 4
Rule 5
Rule 6
Rule 7
Rule 8
Rule 9
Src.
Trunk
Group ID
*
0
1
-
-
-
-
-
-
Src.
Trunk
Group ID
-
-
*
1
-
*
*
*
-
Dest.
Phone
Prefix
10
10
20
[5,7-9]
00
100
100
100
*
Source
Phone
Prefix
100
100
*
*
*
*
*
*
*
Dest. IP
Address
10.33.45.63 10.33.45.50
-
domain.com 0.0.0.0 10.33.45.68 10.33.45.67 domain.com 10.33.45.65
Dest IP
Group ID
-
-
1
-
-
-
-
-
-
IP Profile
ID
1
1
-
-
-
-
-
-
-
Cost
Group ID
Weekend
Weekend_B
-
-
-
-
-
-
-
-
-
-
1
2
1
-
Forking
Group
Table 24-2: Outbound IP Routing Table Parameter Descriptions
Parameter
Description
Index
[PREFIX_Index]
Defines an index number for the new table record.
Web/EMS: Tel to IP Routing
Mode
CLI: configure voip > gw routing
general-setting > tel2ip-rte-mode
[RouteModeTel2IP]
Determines whether to route received calls to an IP destination
before or after manipulation of the destination number.
 [0] Route calls before manipulation = Calls are routed before
the number manipulation rules are applied (default).
 [1] Route calls after manipulation = Calls are routed after the
number manipulation rules are applied.
Notes:
 This parameter is not applicable if outbound proxy routing is
used.
 For number manipulation, see ''Configuring Source/Destination
Number Manipulation'' on page 359.
Route Name
CLI: route-name
[PREFIX_RouteName]
Defines an arbitrary name to easily identify the routing rule.
The valid value is a string of up to 20 characters. By default, no
Version 6.8
387
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
value is defined.
Matching Call Characteristics
Web: Src. IP Group ID
EMS: Source IP Group ID
CLI: src-ip-group-id
[PREFIX_SrcIPGroupID]
Defines the IP Group from where the incoming IP call is received.
Typically, the IP Group of an incoming INVITE is determined
according to the Inbound IP Routing table.
Notes:
 This parameter is applicable only to the Gateway's IP-to-IP
routing application.
 To denote all IP Groups, leave this field empty.
 If this IP Group has a Serving IP Group (configured in the IP
Group table), calls from the IP Group are sent to the Serving IP
Group and therefore, this routing rule is ignored. However, if
you want the call to be sent to a destination configured for this
routing rule instead, set the PreferRouteTable parameter to 1.
Web: Src. Host Prefix
EMS: Source Host Prefix
CLI: src-host-prefix
[PREFIX_SrcHostPrefix]
Defines the prefix of the SIP Request-URI host name in the From
header of the incoming SIP INVITE message.
To denote any prefix, use the asterisk (*) symbol.
Note: This parameter is applicable only to the Gateway's IP-to-IP
routing application.
Web: Dest. Host Prefix
EMS: Destination Host Prefix
CLI: dst-host-prefix
[PREFIX_DestHostPrefix]
Defines the SIP Request-URI host name prefix of the incoming
SIP INVITE message.
To denote any prefix, use the asterisk (*) symbol.
Note: This parameter is applicable only to the Gateway's IP-to-IP
routing application.
Web: Src. Trunk Group ID
EMS: Source Trunk Group ID
CLI: src-trunk-group-id
[PREFIX_SrcTrunkGroupID]
Defines the Trunk Group from where the call is received.
To denote any Trunk Group, use the asterisk (*) symbol.
Web: Dest. Phone Prefix
EMS: Destination Phone Prefix
CLI: dst-phone-prefix
[PREFIX_DestinationPrefix]
Defines the prefix and/or suffix of the called (destination)
telephone number. The suffix is enclosed in parenthesis after the
suffix value. You can use special notations for denoting the prefix.
For example, [100-199](100,101,105) denotes a number that
starts with 100 to 199 and ends with 100, 101 or 105. To denote
any prefix, use the asterisk (*) symbol or to denote calls without a
called number, use the $ sign. For a description of available
notations, see ''Dialing Plan Notation for Routing and Manipulation
Tables'' on page 713.
The number can include up to 50 digits.
Notes:
 For LDAP-based routing, enter the LDAP query keyword as the
prefix number to denote the IP domain:
 "PRIVATE" = Private number
 "OCS" = Lync / OCS client number
 "PBX" = PBX / IP PBX number
 "MOBILE" = Mobile number
 "LDAP_ERR" = LDAP query failure
For more information, see Routing Based on LDAP Active
Directory Queries on page 226.
 If you want to configure re-routing of ISDN Tel-to-IP calls to fax
destinations, you need to enter the value string "FAX" (case-
User's Manual
388
Document #: LTRT-27034
User's Manual
24. Routing
Parameter
Description
sensitive) as the destination phone prefix. For more information
regarding this feature, see the FaxReroutingMode parameter.
Web/EMS: Source Phone Prefix
CLI: src-phone-prefix
[PREFIX_SourcePrefix]
Defines the prefix and/or suffix of the calling (source) telephone
number. You can use special notations for denoting the prefix. For
example, [100-199](100,101,105) denotes a number that starts
with 100 to 199 and ends with 100, 101 or 105. To denote any
prefix, use the asterisk (*) symbol or to denote calls without a
calling number, use the $ sign. For a description of available
notations, see ''Dialing Plan Notation for Routing and Manipulation
Tables'' on page 713.
The number can include up to 50 digits.
Call Setup Rules Set ID
Assigns a Call Setup Rule Set ID to the routing rule. The device
CLI: call-setup-rules-set-id
performs the Call Setup rules of this Set ID if the incoming call
[PREFIX_CallSetupRulesSetId] matches the characteristics of this routing rule. The device routes
the call to the destination according to the routing rule's configured
action, only after it has performed the Call Setup rules.
For configuring Call Setup rules, see ''Configuring Call Setup
Rules'' on page 233.
Operation (IP Destination)
Web: Dest. IP Address
EMS: Address
CLI: dst-ip-address
[PREFIX_DestAddress]
Version 6.8
Defines the IP address (in dotted-decimal notation or FQDN) to
where the call is sent. If an FQDN is used (e.g., domain.com),
DNS resolution is done according to the DNSQueryType
parameter.
The IP address can include the following wildcards:
 "x": represents single digits. For example, 10.8.8.xx denotes all
addresses between 10.8.8.10 and 10.8.8.99.
 "*": represents any number between 0 and 255. For example,
10.8.8.* denotes all addresses between 10.8.8.0 and
10.8.8.255.
For ENUM-based routing, enter the string "ENUM". The device
sends an ENUM query containing the destination phone number to
an external DNS server, configured in the Interface table. The
ENUM reply includes a SIP URI which is used as the Request-URI
in the subsequent outgoing INVITE and for routing (if a proxy is
not used). To configure the type of ENUM service (e.g.,
e164.arpa), use the EnumService parameter.
For LDAP-based routing, enter the string value "LDAP" for
denoting the IP address of the LDAP server. For more information,
see Routing Based on LDAP Active Directory Queries on page
226.
Notes:
 This field and any value assigned to it is ignored if you have
configured a destination IP Group for this routing rule (in the
'Dest IP Group ID' field).
 To reject calls, enter the IP address 0.0.0.0. For example, if you
want to prohibit international calls, then in the 'Dest Phone
Prefix' field, enter 00 and in the 'Dest IP Address' field, enter
0.0.0.0.
 For routing calls between phones connected to the device (i.e.,
local routing), enter the device's IP address.
 When the device's IP address is unknown (e.g., when DHCP is
389
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description

used), enter IP address 127.0.0.1.
When using domain names, enter the DNS server's IP address
or alternatively, configure these names in the Internal DNS
table (see ''Configuring the Internal DNS Table'' on page 130).
Web: Port
EMS: Destination Port
CLI: dst-port
[PREFIX_DestPort]
Defines the destination port to where you want to route the call.
Web/EMS: Transport Type
CLI: transport-type
[PREFIX_TransportType]
Defines the transport layer type for sending the IP call:
 [-1] Not Configured
 [0] UDP
 [1] TCP
 [2] TLS
Note: When set to Not Configured (-1), the transport type defined
by the SIPTransportType parameter is used.
Web: Dest. IP Group ID
EMS: Destination IP Group ID
CLI: dst-ip-group-id
[PREFIX_DestIPGroupID]
Defines the IP Group to where you want to route the call. The SIP
INVITE message is sent to the IP address defined for the Proxy
Set ID associated with the IP Group.
Notes:
 If you select an IP Group, you do not need to configure a
destination IP address. However, if both parameters are
configured in this table, the INVITE message is sent only to the
IP Group (and not the defined IP address).
 If the source IP Group, configured in the 'Src. IP Group ID'
parameter above, has a Serving IP Group (configured in the IP
Group table), calls from the IP Group are sent to the Serving IP
Group and therefore, this routing rule is ignored. However, if
you want this routing rule to be used instead and sent to this
destination IP Group, set the PreferRouteTable parameter to 1.
 If the destination is a User-type IP Group, the device searches
for a match between the Request-URI (of the received INVITE)
to an AOR registration record in the device's database. The
INVITE is then sent to the IP address of the registered contact.
 If the parameter AlwaysUseRouteTable is set to 1 (see
''Configuring IP Groups'' on page 261), then the Request-URI
host name in the INVITE message is set to the value defined
for the parameter 'Dest. IP Address' (above); otherwise, if no IP
address is defined, it is set to the value of the parameter 'SIP
Group Name' (defined in the IP Group table).
 This parameter is used as the 'Serving IP Group' in the Account
table for acquiring authentication user/password for this call
(see ''Configuring Registration Accounts'' on page 279).
 For defining Proxy Set ID's, see ''Configuring Proxy Sets'' on
page 272.
Dest SRD
CLI: dst-srd
[PREFIX_DestSRD]
Defines the SRD to where you want to route the call. The actual
destination is defined by the Proxy Set associated with the SRD.
This allows you to route the call to a specific SIP Media Realm and
SIP Interface.
To configure SRD's, see Configuring SRDs on page 256.
IP Profile ID
CLI: ip-profile-id
Assigns an IP Profile ID to this IP destination call. This allows you
to assign numerous configuration attributes (e.g., voice codes) per
routing rule. To configure IP Profiles, see ''Configuring IP Profiles''
User's Manual
390
Document #: LTRT-27034
User's Manual
24. Routing
Parameter
Description
[PREFIX_ProfileId]
on page 302.
Status
(Read-only field) Displays the connectivity status of the routing
rule's IP destination. If there is connectivity with the destination,
this field displays "OK" and the device uses this routing rule if
required.
The routing rule is not used if any of the following is displayed:
 "n/a" = The destination IP Group is unavailable
 "No Connectivity" = No connection with the destination (no
response to the SIP OPTIONS).
 "QoS Low" = Poor Quality of Service (QoS) of the destination.
 "DNS Error" = No DNS resolution. This status is applicable only
when a domain name is used (instead of an IP address).
 "Unavailable" = The destination is unreachable due to
networking issues.
Web/EMS: Charge Code
CLI: charge-code
[PREFIX_MeteringCode]
Assigns a Charge Code to the routing rule. To configure Charge
Codes, see ''Configuring Charge Codes Table'' on page 454.
Note: This parameter is applicable only to FXS interfaces and E1
Euro ISDN trunks.
Cost Group ID
CLI: cost-group-id
[PREFIX_CostGroup]
Assigns a Cost Group with the routing rule for determining the cost
of the call. To configure Cost Groups, see ''Configuring Cost
Groups'' on page 230.
Forking Group
CLI: forking-group
[PREFIX_ForkingGroup]
Defines a forking group ID for the routing rule. This enables forking
of incoming Tel calls to multiple IP destinations. The device sends
simultaneous INVITE messages and handles multiple SIP dialogs
until one of the calls is answered. When a call is answered, the
other calls are dropped.
If all matched routing rules belong to the same Forking Group
number, the device sends an INVITE to all the destinations
belonging to this group and according to the following logic:
 If matched routing rules belong to different Forking Groups, the
device sends the call to the Forking Group of the first matched
routing rule. If the call cannot be established with any of the
destinations associated with this Forking Group and alternative
routing is enabled, the device forks the call to the Forking
Group of the next matched routing rules as long as the Forking
Group is defined with a higher number than the previous
Forking Group. For example:
 Table index entries 1 and 2 are defined with Forking Group "1",
and index entries 3 and 4 with Forking Group "2": The device
first sends the call according to index entries 1 and 2, and if
unavailable and alternative routing is enabled, sends the call
according to index entries 3 and 4.
 Table index entry 1 is defined with Forking Group "2", and
index entries 2, 3, and 4 with Forking Group "1": The device
sends the call according to index entry 1 only and ignores the
other index entries even if the destination is unavailable and
alternative routing is enabled. This is because the subsequent
index entries are defined with a Forking Group number that is
lower than that of index entry 1.
 Table index entry 1 is defined with Forking Group "1", index
entry 2 with Forking Group "2", and index entries 3 and 4 with
Version 6.8
391
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
Forking Group "1": The device first sends the call according to
index entries 1, 3, and 4 (all belonging to Forking Group "1"),
and if the destination is unavailable and alternative routing is
enabled, the device sends the call according to index entry 2.
 Table index entry 1 is defined with Forking Group "1", index
entry 2 with Forking Group "3", index entry 3 with Forking
Group "2", and index entry 4 with Forking Group "1": The
device first sends the call according to index entries 1 and 4 (all
belonging to Forking Group "1"), and if the destination is
unavailable and alternative routing is enabled, the device sends
the call according to index entry 2 (Forking Group "3"). Even if
index entry 2 is unavailable and alternative routing is enabled,
the device ignores index entry 3 because it belongs to a
Forking Group that is lower than index entry 2.
Notes:
 To enable Tel-to-IP call forking, set the 'Tel2IP Call Forking
Mode' (Tel2IPCallForkingMode) parameter to Enable.
 You can configure the device to immediately send the INVITE
message to the first member of the Forking Group (as in
normal operation) and then only after a user-defined interval,
send (simultaneously) the INVITE messages to the other
members. If the device receives a SIP 4xx or 5xx in response
to the first INVITE, it immediately sends INVITEs to all the other
members, regardless of the interval. To configure this feature,
use the ForkingDelayTimeForInvite ini file parameter.
 You can implement Forking Groups when the destination is an
LDAP server or a domain name using DNS. In such scenarios,
the INVITE is sent to all the queried LDAP or resolved IP
addresses, respectively. You can also use LDAP routing rules
with standard routing rules for Forking Groups.
 When the UseDifferentRTPportAfterHold parameter is enabled,
every forked call is sent with a different RTP port. Thus, ensure
that the device has sufficient available RTP ports for these
forked calls.
24.3
Configuring Inbound IP Routing Table
The Inbound IP Routing table lets you configure up to 120 inbound call routing rules:

For IP-to-IP routing: The table is used to identify an incoming call as an IP-to-IP call
and subsequently, to assign the call to an IP Group, referred to as a source IP Group.
These IP-to-IP calls can later be routed to an outbound destination IP Group (see
Configuring Outbound IP Routing Table on page 383).

For IP-to-Tel routing: This table is used to route incoming IP calls to Trunk Groups.
The specific channel pertaining to the Trunk Group to which the call is routed is
determined according to the Trunk Group's channel selection mode. The channel
selection mode can be defined per Trunk Group (see ''Configuring Trunk Group
Settings'' on page 353) or for all Trunk Groups using the global parameter
ChannelSelectMode.
The Inbound IP Routing table provides two configuration areas:

Matching characteristics of incoming IP call, for example, prefix of destination number.

Operation (destination), for example, sends to a specific Trunk Group.
User's Manual
392
Document #: LTRT-27034
User's Manual
24. Routing
If the incoming call matches the characteristics of a rule, the call is sent to the destination
configured for that rule.
The device also supports alternative routing if the IP-to-Tel call cannot be routed to the
Trunk Group:

Routing to an Alternative Trunk Group: If a call release reason (cause) code (e.g.,
17 for User Busy) is received from the Tel side for a specific IP-to-Tel call and you
have configured this reason code in the Reasons for IP-to-Tel Alternative Routing
table, the device re-routes the call to an alternative Trunk Group if an alternative
routing rule has been configured. You must configure the alternative routing rules in
table rows (indices) that are located anywhere below the "main" routing rule. For
example, if you configure a "main" routing rule in Index 4, the alternative routing rule
can be configured in Index 6. In addition, you must configure the alternative routing
rules with identical matching characteristics (e.g., destination prefix number) to the
"main" routing rule, but assigned with different destinations (i.e., Trunk Groups). For
more information on IP-to-Tel alternative routing and for configuring call release
reasons for alternative routing, see ''Alternative Routing to Trunk upon Q.931 Call
Release Cause Code'' on page 403.

Routing to an IP Destination (i.e., Call Redirection): The device can re-route the
IP-to-Tel call to an alternative IP destination, using SIP 3xx responses. For more
information, see ''Alternative Routing to IP Destinations upon Busy Trunk'' on page
404.

Routing to an Alternative Physical FXO port or Trunk Within the Same Trunk
Group: The device can re-route an IP-to-Tel call to a different physical FXO port or
trunk if the destined trunk or FXO port within the same Trunk Group is out of service
(e.g., physically disconnected). When the physical FXO port or trunk is disconnected,
the device sends the SNMP trap, GWAPP_TRAP_BUSYOUT_LINK notifying of the
out-of-service state for the specific trunk number. When the physical FXO port or trunk
is physically reconnected, this trap is sent notifying of the back-to-service state.
Notes:
• You can configure up to three alternative routing rules per "main" routing rule in
the Inbound IP Routing table.
• If your deployment includes calls of many different called (source) and/or calling
(destination) numbers that need to be routed to the same destination, you can
employ user-defined prefix tags to represent these numbers. Thus, instead of
configuring many routing rules, you need to configure only one routing rule using
the prefix tag as the source and destination number matching characteristics, and
a destination for the calls. For more information on prefix tags, see ''Dial Plan
Prefix Tags for IP-to-Tel Routing'' on page 585.
The following procedure describes how to configure Inbound IP Routing rules in the Web
interface. You can also configure Inbound IP Routing rules using the table ini file
parameter, PSTNPrefix or CLI command, configure voip > gw routing ip2tel-routing.
Version 6.8
393
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure IP-to-Tel or inbound IP routing rules:
1.
Open the Inbound IP Routing Table page (Configuration tab > VoIP menu > GW and
IP to IP > Routing > IP to Trunk Group Routing).
Figure 24-3: Inbound IP Routing Table
The previous figure displays the following configured routing rules:
•
Rule 1: If the incoming IP call destination phone prefix is between 10 and 19, the
call is assigned settings configured for IP Profile ID 2 and routed to Trunk Group
ID 1.
•
Rule 2: If the incoming IP call destination phone prefix is between 501 and 502
and source phone prefix is 101, the call is assigned settings configured for IP
Profile ID 1 and routed to Trunk Group ID 2.
•
Rule 3: If the incoming IP call has a From URI host prefix as domain.com, the call
is routed to Trunk Group ID 3.
•
Rule 4: If the incoming IP call has IP address 10.13.64.5 in the INVITE's Contact
header, the call is identified as an IP-to-IP call and assigned to Source IP Group
4. This call is routed according to the outbound IP routing rules for this Source IP
Group configured in the Outbound IP Routing table.
2.
Configure a routing rule according to the parameters described in the table below.
3.
Click Submit.
Table 24-3: IP-to-Tel or Inbound IP Routing Table Parameter Description
Parameter
Description
IP to Tel Routing Mode
CLI: configure voip/gw routing
general-setting/ip2tel-rte-mode
[RouteModeIP2Tel]
Determines whether to route the incoming IP call before or after
manipulation of destination number, configured in ''Configuring
Source/Destination Number Manipulation'' on page 359.
 [0] Route calls before manipulation = (Default) Incoming IP
calls are routed before number manipulation.
 [1] Route calls after manipulation = Incoming IP calls are
routed after number manipulation.
Index
[PstnPrefix_Index]
Defines an index number for the new table record.
Route Name
CLI: route-name
[PstnPrefix_RouteName]
Defines an arbitrary name to easily identify the routing rule.
The valid value is a string of up to 20 characters. By default, no
value is defined.
Matching Characteristics
Web: Dest. Host Prefix
CLI: dst-phone-prefix
[PstnPrefix_DestPrefix]
User's Manual
Defines the Request-URI host name prefix of the incoming SIP
INVITE message.
By default, no value is defined (i.e., not used in routing rule). To
denote any prefix, use the asterisk (*) wildcard.
394
Document #: LTRT-27034
User's Manual
24. Routing
Parameter
Description
Web: Source Host Prefix
CLI: src-host-prefix
[PstnPrefix_SrcHostPrefix]
Defines the From URI host name prefix of the incoming SIP
INVITE message.
By default, no value is defined (i.e., not used in routing rule). To
denote any prefix, use the asterisk (*) wildcard.
Note: If the P-Asserted-Identity header is present in the
incoming INVITE message, the value of this parameter is
compared to the P-Asserted-Identity URI host name (and not
the From header).
Web: Dest. Phone Prefix
CLI: dst-host-prefix
[PstnPrefix_DestHostPrefix]
Defines the prefix or suffix of the called (destined) telephone
number. You can use special notations for denoting the prefix.
For example, [100-199](100,101,105) denotes a number that
starts with 100 to 199 and ends with 100, 101 or 105. To
denote any prefix, use the asterisk (*) symbol or to denote calls
without a called number, use the $ sign. For a description of
available notations, see ''Dialing Plan Notation for Routing and
Manipulation Tables'' on page 713.
The prefix can include up to 49 digits.
Web: Source Phone Prefix
CLI: src-phone-prefix
[PstnPrefix_SourcePrefix]
Defines the prefix or suffix of the calling (source) telephone
number. You can use special notations for denoting the prefix.
For example, [100-199](100,101,105) denotes a number that
starts with 100 to 199 and ends with 100, 101 or 105. To
denote any prefix, use the asterisk (*) symbol or to denote calls
without a calling number, use the $ sign. For a description of
available notations, see ''Dialing Plan Notation for Routing and
Manipulation Tables'' on page 713.
The prefix can include up to 49 digits.
Note: If the P-Asserted-Identity header is present in the
incoming INVITE message, the value of this parameter is
compared to the P-Asserted-Identity URI host name (and not
the From header).
Web: Source IP Address
CLI: src-ip-address
[PstnPrefix_SourceAddress]
Defines the source IP address of the incoming IP call that can
be used for routing decisions.
The IP address can be configured in dotted-decimal notation
(e.g., 10.8.8.5) or as an FQDN. If the address is an FQDN,
DNS resolution is done according to the DNSQueryType
parameter.
Notes:
 The source IP address is obtained from the Contact header
in the INVITE message.
 You can configure from where the source IP address is
obtained, using the SourceIPAddressInput parameter.
 The source IP address can include the following wildcards:
 "x": denotes single digits. For example, 10.8.8.xx
represents all the addresses between 10.8.8.10 and
10.8.8.99.
 "*": denotes any number between 0 and 255. For
example, 10.8.8.* represents all addresses between
10.8.8.0 and 10.8.8.255.
Web: Source SRD ID
CLI: src-srd-id
[PstnPrefix_SrcSRDID]
Defines the SRD from where the incoming packet is received.
Note: When the incoming INVITE matches the SRD in the
routing rule, if the 'Source IP Group ID' parameter (see below)
Version 6.8
395
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Parameter
Description
is defined and it is associated with a different SRD, the
incoming SIP call is rejected. If the 'Source IP Group ID'
parameter is not defined, the SRD's default IP Group is used. If
there is no valid source IP Group, the call is rejected.
Call Setup Rules Set ID
Assigns a Call Setup Rule Set ID to the routing rule. The device
performs the Call Setup rules of this Set ID if the incoming call
CLI: call-setup-rules-set-id
[PstnPrefix_CallSetupRulesSetId] matches the characteristics of this routing rule. The device
routes the call to the destination according to the routing rule's
configured action, only after it has performed the Call Setup
rules.
For configuring Call Setup rules, see ''Configuring Call Setup
Rules'' on page 233.
Operation (Destination)
Web: Trunk Group ID
CLI: trunk-group-id
[PstnPrefix_TrunkGroupId]
For IP-to-Tel calls: Defines the Trunk Group to where the
incoming SIP call is sent.
For IP-to-IP calls: Identifies the call as an IP-to-IP call if this
parameter is set to -1.
Web: Trunk ID
CLI: trunk-id
[PstnPrefix_TrunkId]
Defines the Trunk to where the incoming SIP call is sent.
Notes:
 If both 'Trunk Group ID' and 'Trunk ID' parameters are
configured in the table, the routing is done according to the
'Trunk Group ID' parameter.
 The method for selecting the trunk's channel to which the IP
call is sent is configured by the global parameter,
ChannelSelectMode.
 Currently, this field can only be configured using the ini file.
Web: IP Profile ID
CLI: ip-profile-id
[PstnPrefix_ProfileId]
Assigns an IP Profile (configured in ''Configuring IP Profiles'' on
page 302) to the call.
Web: Source IP Group ID
CLI: src-ip-group-id
[PstnPrefix_SrcIPGroupID]
For IP-to-Tel calls: Defines the IP Group associated with the
incoming IP call. This is the IP Group that sent the INVITE
message. This IP Group can later be used as the 'Serving IP
Group' in the Account table for obtaining authentication user
name/password for this call.
For IP-to-IP calls: Assigns the IP Group to the incoming IP call.
This IP Group can later be used for outbound IP routing and as
the 'Serving IP Group' in the Account table for obtaining
authentication user name/password for this call.
For configuring registration accounts in the Account table, see
''Configuring Account Table'' on page 279.
24.4
IP Destinations Connectivity Feature
The device can be configured to check the integrity of the connectivity to IP destinations of
Tel-to-IP routing rules in the Outbound IP Routing table. The IP Connectivity feature can be
used for the Alternative Routing feature, whereby the device attempts to re-route calls from
unavailable Tel-to-IP routing destinations to available ones (see ''Alternative Routing Based
on IP Connectivity'' on page 398).
The device supports the following methods for checking the connectivity of IP destinations:
User's Manual
396
Document #: LTRT-27034
User's Manual

24. Routing
Network Connectivity: The device checks the network connectivity of the IP
destination configured by the 'Alt Routing Tel to IP Connectivity Method' parameter:
•
SIP OPTIONS: The device sends "keep-alive" SIP OPTIONS messages to the IP
destination. If the device receives a SIP 200 OK in response, it considers the
destination as available. If the destination does not respond to the OPTIONS
message, then it is considered unavailable. You can configure the time interval
for sending these OPTIONS messages, using the 'Alt Routing Tel to IP Keep
Alive Time' parameter.
These parameters are configured in the Routing General Parameters page
(Configuration tab > VoIP menu > GW and IP to IP > Routing > General
Parameters), as shown below:
Figure 24-4: IP Connectivity Method in Routing General Parameters Page

Quality of Service (QoS): You can enable the device to check the QoS of IP
destinations. The device measures the QoS according to RTCP statistics of previously
established calls with the IP destination. The RTCP includes packet delay (in
milliseconds) and packet loss (in percentage). If these measured statistics exceed a
user-defined threshold, the destination is considered unavailable. Note that if call
statistics is not received within two minutes, the QoS data is reset. These thresholds
are configured using the following parameters:
•
'Max Allowed Packet Loss for Alt Routing' (IPConnQoSMaxAllowedPL): defines
the threshold value for packet loss after which the IP destination is considered
unavailable.
•
'Max Allowed Delay for Alt Routing' (IPConnQoSMaxAllowedDelay): defines the
threshold value for packet delay after which the IP destination is considered
unavailable
These parameters are configured in the Routing General Parameters page, as shown
below:
Figure 24-5: IP QoS Thresholds in Routing General Parameters Page

DNS Resolution: When a host name (FQDN) is used (instead of an IP address) for
the IP destination, it is resolved into an IP address by a DNS server. The device
checks network connectivity and QoS of the resolved IP address. If the DNS host
name is unresolved, the device considers the connectivity of the IP destination as
unavailable.
You can view the connectivity status of IP destinations in the following Web interface
pages:

Outbound IP Routing Table: The connectivity status of the IP destination per routing
rule is displayed in the 'Status' column. For more information, see ''Configuring
Outbound IP Routing Table'' on page 383.

IP Connectivity: This page displays a more informative connectivity status of the IP
destinations used in Tel-to-IP routing rules in the Outbound IP Routing table. For
viewing this page, see ''Viewing IP Connectivity'' on page 651.
Version 6.8
397
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
24.5
Alternative Routing for Tel-to-IP Calls
The device supports various alternative Tel-to-IP call routing methods, as described in this
section.
24.5.1 Alternative Routing Based on IP Connectivity
You can configure the device to route Tel-to-IP calls to an alternative IP destination when
the connectivity state of an IP destination is unavailable. The alternative routing rules are
configured in the Outbound IP Routing table. These rules must be configured anywhere
below the "main" routing rule and with identical matching characteristics (e.g., destination
prefix number) to the "main" routing rule. The device uses the first alternative route that is
available. For more information on configuring alternative Tel-to-IP routing rules in the
Outbound IP Routing table, see ''Configuring Outbound IP Routing Table'' on page 383.
Note: Alternative routing based on IP connectivity is applicable only when a proxy
server is not used.
The device searches for an alternative IP destination when any of the following connectivity
states are detected with the IP destination of the initial Tel-to-IP routing rule:

No response received from SIP OPTIONS messages. This depends on the chosen
method for checking IP connectivity.

Poor QoS according to the configured thresholds for packet loss and delay.

Unresolved DNS, if the configured IP destination is a domain name (or FQDN). If the
domain name is resolved into two IP addresses, the timeout for INVITE retransmissions can be configured using the HotSwapRtx parameter. For example, if
you set this parameter to 3, the device attempts up to three times to route the call to
the first IP address and if unsuccessful, it attempts up to three times to re-route it to
the second resolved IP address.
The connectivity status of the IP destination is displayed in the 'Status' column of the
Outbound IP Routing table per routing rule. If it displays a status other than "ok", then the
device considers the IP destination as unavailable and attempts to re-route the call to an
alternative destination. For more information on the IP connectivity methods and on
viewing IP connectivity status, see ''IP Destinations Connectivity Feature'' on page 396.
The table below shows an example of alternative routing where the device uses an
available alternative routing rule in the Outbound IP Routing table to re-route the initial Telto-IP call.
Table 24-4: Alternative Routing based on IP Connectivity Example
Destination
Phone Prefix
IP Destination
IP Connectivity
Status
Rule Used?
Main Route
40
10.33.45.68
"No Connectivity"
No
Alternative Route #1
40
10.33.45.70
"QoS Low"
No
Alternative Route #2
40
10.33.45.72
"ok"
Yes
User's Manual
398
Document #: LTRT-27034
User's Manual
24. Routing
The steps for configuring alternative Tel-to-IP routing based on IP connectivity are
summarized below.
 To configure alternative Tel-to-IP routing based on IP connectivity:
1.
In the Outbound IP Routing table, add alternative Tel-to-IP routing rules for specific
calls.
2.
In the Routing General Parameters page (Configuration tab > VoIP menu > GW and
IP to IP > Routing > General Parameters), do the following:
a.
b.
c.
Enable alternative routing based on IP connectivity, by setting the 'Enable Alt
Routing Tel to IP AltRouting' (Tel2IPEnable) parameter to Enable.
Configure the IP connectivity reason for triggering alternative routing, by setting
the 'Alt Routing Tel to IP Mode' parameter (AltRoutingTel2IPMode) to one of the
following:
♦
SIP OPTIONS failure
♦
Poor QoS
♦
SIP OPTIONS failure, poor QoS, or unresolved DNS
The device plays a tone to the Tel endpoint (for analog interfaces) whenever an
alternative route is used. This tone is played for a user-defined time configured by
the 'Alternative Routing Tone Duration' parameter.
24.5.2 Alternative Routing Based on SIP Responses
The device can perform alternative routing based on the received SIP response code (i.e.,
4xx, 5xx, 6xx, or 8xx). If you have configured this response code in the Reasons for Tel-toIP Alternative Routing table, the device attempts to re-route the call to an alternative
destination, if configured. You can configure up to 10 SIP response codes in the Reasons
for Tel-to-IP Alternative Routing table.
Typically, the device performs alternative routing when there is no response at all to an
INVITE message. This is done after a user-defined number of INVITE re-transmissions,
configured by the SIPMaxRtx parameter. In such a scenario, the device issues itself the
SIP response code 408 (Request Timeout). You can also configure the device to perform
alternative routing for the following proprietary response codes that are issued by the
device itself:

805 IP Profile Call Limit: The device generates this response code when Call
Admission Control (CAC) limits are exceeded for an IP Group. The CAC rules are
configured in the IP Profile table (see ''Configuring IP Profiles'' on page 302). When
this occurs, the device sends a SIP 480 (Temporarily Unavailable) response to the
SIP entity.

806 Media Limits Exceeded: The device generates this response code when the call
is terminated due to crossed thresholds of QoE metrics such as MOS, packet delay,
and packet loss (configured in the Quality of Experience Profile table) and/or media
bandwidth (configured in the Bandwidth profile table). When this occurs, the device
sends a SIP 480 (Temporarily Unavailable) response to the SIP entity. This is
configured by 1) assigning an IP Group a QoE and/or Bandwidth profile that rejects
calls if the threshold is crossed, 2) configuring 806 in the Reasons for Tel-to-IP
Alternative Routing table and 3) configuring an alternative routing rule.
Note: The device also plays a tone to the endpoint whenever an alternative route is
used. This tone is played for a user-defined time, configured by the
AltRoutingToneDuration parameter.
Version 6.8
399
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Depending on configuration, the alternative routing is done using one of the following
configuration entities:

Outbound IP Routing Rules: You configure alternative routing rules for a specific
routing rule in the Outbound IP Routing table. If the destination of the "main" routing
rule is unavailable, the device searches the table for the next matching rule (e.g.,
destination phone number), and if available attempts to re-route the call to the IP
destination configured for this alternative routing rule. For more information on
configuring alternative Tel-to-IP routing rules, see ''Configuring Outbound IP Routing
Table'' on page 383. The table below shows an example of alternative routing where
the device uses the first available alternative routing rule to re-route the initial,
unsuccessful Tel-to-IP call destination:
Table 24-5: Alternative Routing based on SIP Response Code Example
Destination
Phone Prefix
IP Destination
SIP Response
Rule Used?
Main Route
40
10.33.45.68
408 Request
Timeout
No
Alternative Route #1
40
10.33.45.70
486 Busy Here
No
Alternative Route #2
40
10.33.45.72
200 OK
Yes

Proxy Sets: Proxy Sets are used for Server-type IP Groups (e.g., an IP PBX or
proxy), which define the address (IP address or FQDN) of the server (see ''Configuring
Proxy Sets'' on page 272). As you can configure multiple IP destinations per Proxy
Set, the device supports proxy redundancy, which works together with the alternative
routing feature. If the destination of a routing rule in the Outbound IP Routing table is
an IP Group, the device routes the call to the IP destination configured for the Proxy
Set associated with the IP Group. If the first IP destination of the Proxy Set is
unavailable, the device attempts to re-route the call to the next proxy destination, and
so on until an available IP destination is located. To enable the Proxy Redundancy
feature for a Proxy Set, set the IsProxyHotSwap parameter to 1 and the
EnableProxyKeepAlive parameter to 1.
When the Proxy Redundancy feature is enabled, the device continually monitors the
connection with the proxies by using keep-alive messages (SIP OPTIONS). The
device sends these messages every user-defined interval (ProxyKeepAliveTime
parameter). If the first (primary) proxy in the list replies with a SIP response code that
you have also configured by the 'Keep-Alive Failure Responses' parameter, the device
considers the Proxy as down; otherwise, the device considers the proxy as "alive". If
the proxy is still considered down after a user-defined number of re-transmissions
(configured by the HotSwapRtx parameter), the device attempts to communicate
(using the same INVITE) with the next configured (redundant) proxy in the list, and so
on until an available redundant proxy is located. Once an available proxy is located,
the device can operate in one of the following modes (configured by the
ProxyRedundancyMode parameter):
•
Parking mode: The device continues operating with the redundant proxy (now
active) until the next failure occurs, after which it switches to the next redundant
proxy.
•
Homing mode: The device always attempts to operate with the primary proxy. In
other words, it switches back to the primary proxy whenever it's available again.
If none of the proxy servers respond, the device goes over the list again.
User's Manual
400
Document #: LTRT-27034
User's Manual
24. Routing
Note: The device assumes that all the proxy servers belonging to the Proxy Set are
synchronized with regards to registered users. Thus, when the device locates an
available proxy using the Hot Swap feature, it does not re-register the users; new
registration (refresh) is done as normal.
The steps for configuring alternative Tel-to-IP routing based on SIP response codes are
summarized below.
 To configure alternative Tel-to-IP routing based on SIP response codes:
1.
Configure SIP response codes (call failure reasons) that invoke alternative Tel-to-IP
routing:
a.
b.
Open the Reasons for Tel-to-IP Alternative Routing page (Configuration tab >
VoIP menu > GW and IP to IP > Routing > Alternative Reasons > Reasons
for Tel-to-IP).
Click Add; the following dialog box appears:
Figure 24-6: Reasons for Tel-to-IP Alternative Routing Table - Add Record
c.
d.
Configure a SIP response code for alternative routing according to the
parameters described in the table below.
Click Submit, and then save ("burn") your settings to flash memory.
Table 24-6: Reasons for Tel-to-IP Alternative Routing Table Parameter Descriptions
Parameter
Index
[AltRouteCauseTel2Ip_Index]
Description
Defines an index number for the new table record.
Release Cause
Defines a SIP response code that if received, the device
CLI: rel-cause
attempts to route the call to an alternative destination (if
[AltRouteCauseTel2Ip_ReleaseCause] configured).
2.
Enable alternative routing based on SIP responses, by setting the 'Redundant Routing
Mode' parameter in the Proxy & Registration page to one of the following:
•
Routing Table: Outbound IP Routing table is used for alternative routing.
•
Proxy: Proxy Set redundancy feature is used for alternative routing.
3.
If you are using the Outbound IP Routing table, configure alternative routing rules with
identical call matching characteristics, but with different IP destinations.
4.
If you are using the Proxy Set, configure redundant proxies.
Version 6.8
401
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
24.5.3 Alternative Routing upon SIP 3xx with Multiple Contacts
You can configure how the device handles received SIP 3xx responses that contain
multiple alternative contacts. The 3xx response indicates that the original destination is
unavailable (e.g., 301 Moved Permanently – user cannot be found) and that the call can be
redirected to alternative destinations specified in the SIP Contact headers.
Configured by the '3xx Use Alt Route Reasons' parameter, the device can handle the
receipt of 3xx responses using one of the following methods:

The device tries each contact sequentially, listed in the Contact headers, until a
successful destination is found. If a contact responds with a SIP 486 or 600, the
device does not try to redirect the call to the next contact and drops the call.

The device tries each contact sequentially, listed in the Contact headers. If a SIP 6xx
Global Failure response is received during this process (e.g., 600 Busy Everywhere),
the device does not try to redirect the call to the next contact and drops the call.

The device redirects the call to the first contact listed in the Contact header. If the
contact responds with a SIP response that is configured in the Reasons for Tel-to-IP
Alternative Routing table (see ''Alternative Routing Based on SIP Responses'' on page
399), the device tries to redirect the call to the next contact, and so on. If a contact
responds with a response that is not configured in the table, the device does not try to
redirect the call to the next contact and drops the call.
Note: If a SIP 401 or 407 response is received from a contact, the device does not try
to redirect the call to the next contact. Instead, the device continues with the regular
authentication process, as indicated by these response types.
24.5.4 PSTN Fallback
The PSTN Fallback feature enables the device to re-route a Tel-to-IP call to the legacy
PSTN using one of its trunks if the IP destination is unavailable. For example, if poor voice
quality is detected over the IP network, the device attempts to re-route the call to the
PSTN.
The steps for configuring alternative Tel-to-IP routing to the legacy PSTN are summarized
below.
 To configure alternative Tel-to-IP routing to the legacy PSTN:
1.
Configure an alternative routing rule in the Outbound IP Routing table with the same
call matching characteristics (e.g., phone number destination), but where the
destination is the IP address of the device itself.
2.
Configure an IP-to-Tel routing rule in the Inbound IP Routing table to route calls
received from the device (i.e., its IP address) to a specific Trunk Group connected to
the PSTN. This configuration is necessary as the re-routed call is now considered an
IP-to-Tel call. For configuring IP-to-Tel routing rules, see ''Configuring the Inbound IP
Routing Table'' on page 392.
Note: The PSTN Fallback feature is applicable only to digital interfaces (e.g., E1 / T1
trunks).
User's Manual
402
Document #: LTRT-27034
User's Manual
24.6
24. Routing
Alternative Routing for IP-to-Tel Calls
The device supports alternative IP-to-Tel call routing, as described in this section.
24.6.1 Alternative Routing to Trunk upon Q.931 Call Release Cause
Code
You can configure up to 10 ISDN Q.931 release cause codes, which if received from the
Tel side, the device routes the IP-to-Tel call to an alternative Trunk Group, if configured.
Alternative IP-to-Tel routing rules are configured in the Inbound IP Routing table. These
rules must be configured anywhere below the "main" routing rule and with identical
matching characteristics (e.g., destination prefix number) to the "main" routing rule. The
device uses the first alternative route that is available. For more information on configuring
alternative IP-to-Tel routing rules in the Inbound IP Routing table, see ''Configuring Inbound
IP Routing Table'' on page 392.
A release cause code indicates that the IP-to-Tel call has been rejected or disconnected on
the Tel side. The release cause codes are configured in the Reasons for IP-to-Tel
Alternative Routing table. For example, you can configure alternative IP-to-Tel routing for
scenarios where the initial Tel destination is busy and a Q.931 Cause Code No. 17 is
received (or for other call releases that issue the default Cause Code No. 3).
You can configure a default release cause code that the device issues itself upon the
following scenarios:

The device initiates a call release whose cause is unknown.

No free channels (i.e., busy) in the Trunk Group.

No appropriate routing rule located in the Inbound IP Routing table.

Phone number is not located in the Inbound IP Routing table.
This default release code is set to Cause Code No. 3 (No Route to Destination).You can
change the code number using the 'Default Release Cause' parameter, located on the
Advanced Parameters page (Configuration tab > VoIP menu > SIP Definitions >
Advanced Parameters).
Notes:
• If a Trunk is disconnected or not synchronized, the device issues itself the internal
Cause Code No. 27. This cause code is mapped (by default) to SIP 502.
• The default release cause is described in the Q.931 notation and translated to
corresponding SIP 40x or 50x values (e.g., Cause Code No. 3 to SIP 404, and
Cause Code No. 34 to SIP 503).
• For analog interfaces: For information on mapping PSTN release causes to SIP
responses, see PSTN Release Cause to SIP Response Mapping on page 381.
• For mapping SIP-to-Q.931 and Q.931-to-SIP release causes, see Configuring
Release Cause Mapping on page 375.
The following procedure describes how to configure alternative routing reasons for IP-toTel calls in the Web interface. You can also configure alternative routing reasons for IP-toTel calls using the table ini file parameter, AltRouteCauseIP2Tel or CLI command,
configure voip/gw routing alt-route-cause-ip2tel.
Version 6.8
403
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure alternative Trunk Group routing based on Q.931 cause codes:
1.
In the Proxy & Registration page, set the 'Redundant Routing Mode' parameter to
Routing Table so that the device uses the Inbound IP Routing table for alternative
routing.
2.
In the Inbound IP Routing table, configure alternative routing rules with the same call
matching characteristics, but with different Trunk Group destinations.
3.
Configure Q.931 cause codes that invoke alternative IP-to-Tel routing:
a.
b.
Open the Reasons for IP-to-Tel Alternative Routing page (Configuration tab >
VoIP menu > GW and IP to IP > Routing > Alternative Routing Reasons >
Reasons for IP-to-Tel).
Click Add; the following dialog box appears:
Figure 24-7: IP to Tel Reasons - Reasons for Alternative Routing Page
c.
d.
Configure a Q.931 release cause code for alternative routing according to the
parameters described in the table below.
Click Submit, and then save ("burn") your settings to flash memory.
Table 24-7: Reasons for IP-to-Tel Alternative Routing Table Parameter Descriptions
Parameter
Index
[AltRouteCauseIP2Tel_Index]
Description
Defines an index number for the new table record.
Release Cause
Defines a Q.931 release code that if received, the device
CLI: rel-cause
attempts to route the call to an alternative destination (if
[AltRouteCauseIP2Tel_ReleaseCause] configured).
24.6.2 Alternative Routing to an IP Destination upon a Busy Trunk
The Forward on Busy Trunk Destination table lets you configure alternative routing rules for
forwarding (i.e., call redirection) IP-to-Tel calls to an alternative IP destination using SIP
3xx responses. These rules are used upon the following:

For digital interfaces: Trunk Group has no free channels (i.e., “busy”).

For analog interfaces: Unavailable FXS / FXO Trunk Group. This feature can be used,
for example, to forward the call to another FXS / FXO device.
This feature is configured per Trunk Group. The alternative destination can be defined as a
host name or as a SIP Request-URI user name and host part (i.e., user@host). For
example, the below configuration forwards IP-to-Tel calls to destination user “112” at host
IP address 10.13.4.12, port 5060, using transport protocol TCP, if Trunk Group ID 2 is
unavailable:
ForwardOnBusyTrunkDest 1 = 2, 112@10.13.4.12:5060;transport=tcp;
When configured with user@host, the original destination number is replaced by the user
part.
User's Manual
404
Document #: LTRT-27034
User's Manual
24. Routing
The device forwards calls using this table only if no alternative IP-to-Tel routing rule has
been configured in the Inbound IP Routing table or alternative routing fails and the
following reason(s) in the SIP Diversion header of 3xx messages exists:

For digital interfaces: “out-of-service” - all trunks are unavailable/disconnected

"unavailable":
•
For digital interfaces: All trunks are busy or unavailable
•
For analog interfaces: All FXS / FXO lines pertaining to a Trunk Group are busy
or unavailable
The following procedure describes how to configure Forward on Busy Trunks in the Web
interface. You can also configure this using the table ini file parameter,
ForwardOnBusyTrunkDest or CLI command, configure voip/gw routing fwd-on-bsy-trk-dst.
 To configure a Forward on Busy Trunk Destination rule:
1.
Open the Forward on Busy Trunk Destination page (Configuration tab > VoIP menu
> GW and IP to IP > Routing > Forward on Busy Trunk).
2.
Click Add; the following dialog box appears:
Figure 24-8: Forward on Busy Trunk Destination Page - Add Record
The figure above displays a configuration that forwards IP-to-Tel calls destined for
Trunk Group ID 1 to destination IP address 10.13.5.67 if the conditions mentioned
earlier exist.
3.
Configure a rule according to the parameters described in the table below.
4.
Click Submit, and then reset the device with a burn-to-flash for your settings to take
effect.
Table 24-8: Forward on Busy Trunk Destination Parameter Descriptions
Parameter
Description
Trunk Group ID
CLI: trunk-group-id
[ForwardOnBusyTrunkDest_Tr
unkGroupId]
Defines the Trunk Group ID to which the IP call is destined to.
Forward Destination
CLI: forward-dst
[ForwardOnBusyTrunkDest_Fo
rwardDestination]
Defines the alternative IP destination for the call used if the Trunk
Group is busy or unavailable.
The valid value can be an IP address in dotted-decimal notation,
an FQDN, or a SIP Request-URI user name and host part (i.e.,
user@host). The following syntax can also be used:
host:port;transport=xxx (i.e., IP address, port and transport type).
Note: When configured with a user@host, the original destination
number is replaced by the user part.
Version 6.8
405
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
24.6.3 Alternative Routing upon ISDN Disconnect
You can configure when the device sends a call to an alternative route if it receives an
ISDN Q.931 Disconnect message with a Progress Indicator (PI) IE from the Tel side for IPto-Tel calls. The Disconnect message indicates that the call cannot be established due to,
for example, a busy state on the Tel side. Using the DisconnectCallwithPIifAlt ini file
parameter, you can configure the following modes of operation:

The device does not immediately disconnect the call. Instead, it waits for any
subsequent media from the Tel side (e.g., "this number is currently busy") and
forwards it to the IP side (SIP 183 for early media). Only when it receives a Q.931
Release message, does the device disconnect the call (sends a SIP BYE message to
the IP side). If you have configured an alternative route, the device sends the IP call to
the alternative route.

The device immediately sends the IP call to an alternative route, if you have
configured one. If no alternative route has been configured and the Disconnect
message is received with PI, the device forwards the subsequent early media to the IP
side. The device disconnects the IP call only upon receipt of the subsequent Release
message.
User's Manual
406
Document #: LTRT-27034
User's Manual
25
25. Configuring DTMF and Dialing
Configuring DTMF and Dialing
The DTMF & Dialing page is used to configure parameters associated with dual-tone multifrequency (DTMF) and dialing. For a description of the parameters appearing on this page,
see ''Configuration Parameters Reference'' on page 715.
 To configure the DTMF and dialing parameters:
1.
Open the DTMF & Dialing page (Configuration tab > VoIP menu > GW and IP to IP
> DTMF & Supplementary > DTMF & Dialing).
2.
Configure the parameters as required.
3.
Click Submit.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
Version 6.8
407
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
25.1
Dialing Plan Features
This section describes various dialing plan features supported by the device.
25.1.1 Digit Mapping
Digit map pattern rules are used for Tel-to-IP ISDN overlap dialing (by setting the
ISDNRxOverlap parameter to 1) to reduce the dialing period (for digital interface). For more
information on digit maps for ISDN overlapping, see ISDN Overlap Dialing on page 348.
The device collects digits until a match is found in the user-defined digit pattern (e.g., for
closed numbering schemes). The device stops collecting digits and starts sending the
digits (collected number) upon any of the following scenarios:

Maximum number of digits is received. You can define (using the MaxDigits
parameter) the maximum number of collected destination number digits that can be
received (i.e., dialed) from the Tel side by the device. When the number of collected
digits reaches the maximum (or a digit map pattern is matched), the device uses these
digits for the called destination number.

Inter-digit timeout expires (e.g., for open numbering schemes). This is defined using
the TimeBetweenDigits parameter. This is the time that the device waits between each
received digit. When this inter-digit timeout expires, the device uses the collected
digits to dial the called destination number.

The phone's pound (#) key is pressed.

Digit string (i.e., dialed number) matches one of the patterns defined in the digit map.
Digit map (pattern) rules are defined using the DigitMapping parameter. The digit map
pattern can contain up to 52 options (rules), each separated by a vertical bar ("|"). The
maximum length of the entire digit pattern is 152 characters. The available notations are
described in the table below:
Table 25-1: Digit Map Pattern Notations
Notation
[n-m]
Description
Range of numbers (not letters).
.
(single dot) Repeat digits until next notation (e.g., T).
x
Any single digit.
Note: This notation does not apply to some scenarios when using the star (*)
or hash (#) key. For example, the key sequence of ** must be presented in the
dial plan as *x.s (instead of xx).
T
Dial timeout (configured by the TimeBetweenDigits parameter).
S
Short timer (configured by the TimeBetweenDigits parameter; default is two
seconds) that can be used when a specific rule is defined after a more general
rule. For example, if the digit map is 99|998, then the digit collection is
terminated after the first two 9 digits are received. Therefore, the second rule
of 998 can never be matched. But when the digit map is 99s|998, then after
dialing the first two 9 digits, the device waits another two seconds within which
the caller can enter the digit 8.
User's Manual
408
Document #: LTRT-27034
User's Manual
25. Configuring DTMF and Dialing
Below is an example of a digit map pattern containing eight rules:
DigitMapping = 11xS|00[17]xxx|8xxxxxxx|#xxxxxxx|*xx|91xxxxxxxxxx|9011x|xx.T
In the example, the rule "00[1-7]xxx" denotes dialed numbers that begin with 00, and then
any digit from 1 through 7, followed by three digits (of any number). Once the device
receives these digits, it does not wait for additional digits, but starts sending the collected
digits (dialed number) immediately.
Notes:
• If you want the device to accept/dial any number, ensure that the digit map
contains the rule "xx.T"; otherwise, dialed numbers not defined in the digit map are
rejected.
• If you are using an external Dial Plan file for dialing plans (see ''Dialing Plans for
Digit Collection'' on page 583), the device first attempts to locate a matching digit
pattern in the Dial Plan file, and if not found, then attempts to locate a matching
digit pattern in the Digit Map (configured by the DigitMapping parameter).
• It may be useful to configure both Dial Plan file and Digit Maps. For example, the
Digit Map can be used for complex digit patterns (which are not supported by the
Dial Plan) and the Dial Plan can be used for long lists of relatively simple digit
patterns. In addition, as timeout between digits is not supported by the Dial Plan,
the Digit Map can be used to define digit patterns (MaxDigits parameter) that are
shorter than those defined in the Dial Plan, or left at default. For example, “xx.T”
Digit Map instructs the device to use the Dial Plan and if no matching digit pattern,
it waits for two more digits and then after a timeout (TimeBetweenDigits
parameter), it sends the collected digits. Therefore, this ensures that calls are not
rejected as a result of their digit pattern not been completed in the Dial Plan.
Version 6.8
409
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
25.1.2 External Dial Plan File
The device can be loaded with a Dial Plan file with user-defined dialing plans. For more
information, see ''Dial Plan File'' on page 583.
User's Manual
410
Document #: LTRT-27034
User's Manual
26
26. Configuring Supplementary Services
Configuring Supplementary Services
This section describes SIP supplementary services that can enhance your telephone
service.
Notes:
• All call participants must support the specific supplementary service that is used.
• When working with certain application servers (such as BroadSoft’s BroadWorks)
in client server mode (the application server controls all supplementary services
and keypad features by itself), the device's supplementary services must be
disabled.
The Supplementary Services page is used to configure many of the discussed
supplementary services parameters. For a description of the parameters appearing on this
page, see ''Configuration Parameters Reference'' on page 715.
Version 6.8
411
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
 To configure supplementary services parameters:
1.
Open the Supplementary Services page (Configuration tab > VoIP menu > GW and
IP to IP > DTMF & Supplementary > Supplementary Services).
2.
Configure the parameters as required.
3.
Click Submit, or click the Subscribe to MWI or Unsubscribe to MWI buttons to save
your changes and to subscribe / unsubscribe to the MWI server.
4.
To save the changes to flash memory, see ''Saving Configuration'' on page 568.
User's Manual
412
Document #: LTRT-27034
User's Manual
26.1
26. Configuring Supplementary Services
Call Hold and Retrieve
Initiating Call Hold and Retrieve:

Active calls can be put on-hold by pressing the phone's hook-flash button.

The party that initiates the hold is called the holding party; the other party is called the
held party.

After a successful Hold, the holding party hears a dial tone (HELD_TONE defined in
the device's Call Progress Tones file).

Call retrieve can be performed only by the holding party while the call is held and
active.

The holding party performs the retrieve by pressing the telephone's hook-flash button.

After a successful retrieve, the voice is connected again.

Hold is performed by sending a re-INVITE message with IP address 0.0.0.0 or
a=sendonly in the SDP, according to the HoldFormat parameter.

The hold and retrieve functionalities are implemented by re-INVITE messages. The IP
address 0.0.0.0 as the connection IP address or the string ‘a=inactive’ in the received
re-INVITE SDP cause the device to enter Hold state and to play the held tone
(configured in the device) to the PBX/PSTN. If the string ‘a=sendonly’ is received in
the SDP message, the device 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 device forwards the MOH to the held party.
Receiving Hold/Retrieve:

When an active call receives a re-INVITE message with IP address 0.0.0.0 or
‘inactive’ string in SDP, the device stops sending RTP and plays a local held tone.

When an active call receives a re-INVITE message with the ‘sendonly’ string in SDP,
the device stops sending RTP and listens to the remote party. In this mode, it is
expected that on-hold music (or any other hold tone) is played (over IP) by the remote
party.
You can also configure the device to keep a call on-hold for a user-defined time after which
the call is disconnected, using the HeldTimeout parameter.
Version 6.8
413
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The device also supports "double call hold" for FXS interfaces where the called party,
which has been placed on-hold by the calling party, can then place the calling party on hold
as well and make a call to another destination. The flowchart below provides an example of
this type of call hold:
Figure 26-1: Double Hold SIP Call Flow
The flowchart above describes the following "double" call-hold scenario:
1.
A calls B and establishes a voice path.
2.
A places B on hold; A hears a dial tone and B hears a held tone.
3.
A calls C and establishes a voice path.
4.
B places A on hold; B hears a dial tone.
5.
B calls D and establishes a voice path.
6.
A ends call with C; A hears a held tone.
7.
B ends call with D.
8.
B retrieves call with A.
User's Manual
414
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
Notes:
• If a party that is placed on hold (e.g., B in the above example) is called by another
party (e.g., D), then the on-hold party receives a call waiting tone instead of the
held tone.
• While in a Double Hold state, placing the phone on-hook disconnects both calls
(i.e. call transfer is not performed).
• You can enable the device to handle incoming re-INVITE messages with
"a=sendonly" in the SDP, in the same way as if "a=inactive" is received in the
SDP. This is configured using the SIPHoldBehavior parameter. When enabled, the
device plays a held tone to the Tel phone and responds with a 200 OK containing
"a=recvonly" in the SDP.
26.2
Call Pickup
The device supports the Call Pick-Up feature, whereby the FXS user can answer someone
else's telephone call by pressing a user-defined sequence of phone keys. When the user
dials the user-defined digits (e.g., #77), the incoming call from the other phone is forwarded
to the FXS user's phone. This feature is configured using the parameter KeyCallPickup.
Note: The Call Pick-Up feature is supported only for FXS endpoints pertaining to the
same Trunk Group ID.
26.3
BRI Suspend and Resume
The device supports call suspend and resume services initiated by ISDN BRI phones
connected to the device. During an ongoing call, the BRI phone user can suspend the call
by typically pressing the phone’s “P” button or a sequence of keys (depending on the
phone), and then on-hooking the handset. To resume the call, the phone user typically
presses the same keys or button again and then off-hooks the phone. During the
suspended state, the device plays a howler tone to the remote party. This service is also
supported when instead of pressing the call park button(s), the phone cable is
disconnected (suspending the call) and then reconnected again (resuming the call).
If the phone user does not resume the call within a user-defined interval (configured using
the HeldTimeout parameter), the device releases the call.
Note: Only one call can be suspended per trunk. If another suspend request is
received from a BRI phone while there is already a suspended call (even if done by
another BRI phone connected to the same trunk), the device rejects this suspend
request.
26.4
Consultation Feature
The device's Consultation feature allows you to place one number on hold and make a
second call to another party.

Version 6.8
After holding a call (by pressing hook-flash), the holding party hears a dial tone and
can then initiate a new call, which is called a Consultation call.
415
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

While hearing a dial tone, or when dialing to the new destination (before dialing is
complete), the user can retrieve the held call by pressing hook-flash.

The held call can’t be retrieved while ringback tone is heard.

After the Consultation call is connected, the user can toggle between the held and
active call by pressing the hook-flash key.
Note: The Consultation feature is applicable only to FXS interfaces.
26.5
Call Transfer
This section describes the device's support for call transfer types.
26.5.1 Consultation Call Transfer
The device supports Consultation Call Transfer using the SIP REFER message and
Replaces header. The common method to perform a consultation transfer is described in
the following example, which assumes three call parties:

Party A = transferring

Party B = transferred

Party C = transferred to
1.
A Calls B.
2.
B answers.
3.
A presses the hook-flash button and places B on-hold (party B hears a hold tone).
4.
A dials C.
5.
After A completes dialing C, A can perform the transfer by on-hooking the A phone.
6.
After the transfer is complete, 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 and C:

Just after completing dialing C phone number - transfer from setup

While hearing ringback – transfer from alert

While speaking to C - transfer from active
Note: For FXS interfaces, the device can also handle call transfers using SIP INVITE
and re-INVITE messages, instead of REFER messages. This is useful when
communicating with SIP UAs that do not support the receipt of REFER messages.
This feature is applicable to FXS interfaces. To enable this support, use the
EnableCallTransferUsingReinvites parameter.
The device also supports attended (consultation) call transfer for BRI phones (user side)
connected to the device and using the Euro ISDN protocol. BRI call transfer is according to
ETSI TS 183 036, Section G.2 (Explicit Communication Transfer – ECT). Call transfer is
enabled using the EnableTransfer and EnableHoldtoISDN parameters.
The Explicit Call Transfer (ECT, according to ETS-300-367, 368, 369) supplementary
service is supported for BRI and PRI trunks. This service provides the served user who has
two calls to ask the network to connect these two calls together and release its connection
to both parties. The two calls can be incoming or outgoing calls. This service is similar to
NI-2 Two B-Channel Transfer (TBCT) Supplementary Service. The main difference is that
User's Manual
416
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
in ECT one of the calls must be in HELD state. The ECT standard defines two methods Implicit and Explicit. In implicit method, the two calls must be on the same trunk. BRI uses
the implicit mechanism, and PRI the explicit mechanism.
26.5.2 Consultation Transfer for QSIG Path Replacement
The device can interwork consultation call transfer requests for ISDN QSIG-to-IP calls.
When the device receives a request for a consultation call transfer from the PBX, the
device sends a SIP REFER message with a Replaces header to the SIP UA to transfer it to
another SIP UA. Once the two SIP UA parties are successfully connected, the device
requests the PBX to disconnect the ISDN call, thereby freeing resources on the PBX.
For example, assume legacy PBX user "A" has two established calls connected through
the device – one with remote SIP UA "B" and the other with SIP UA "C". In this scenario,
user "A" initiates a consultation call transfer to connect "B" with "C". The device receives
the consultation call transfer request from the PBX and then connects "B" with "C", by
sending "B" a REFER message with a Replaces header (i.e., replace caller "A" with "C").
Upon receipt of a SIP NOTIFY 200 message in response to the REFER, the device sends
a Q.931 Disconnect messages to the PBX, notifying the PBX that it can disconnect the
ISDN calls (of user "A").
This feature is enabled by the QSIGPathReplacementMode parameter.
26.5.3 Blind Call Transfer
Blind call transfer is done (using SIP REFER messages) after a call is established between
call parties A and B, and party A decides to immediately transfer the call to C without first
speaking to C. The result of the transfer is a call between B and C (similar to consultation
transfer, but skipping the consultation stage).
You can also use the ManipulateIP2PSTNReferTo parameter to manipulate the destination
number according to the number received in the SIP Refer-To header. This is applicable to
all types of blind transfers to the PSTN (e.g., TBCT, ECT, RLT, QSIG, FXO, and CAS).
During blind transfer, the device initiates a new call to the PSTN and the destination
number of this call can be manipulated if this parameter is enabled. The following is an
example of such a blind transfer:
1.
IP phone "A" calls PSTN phone "B", and the call is established.
2.
"A" performs a blind transfer to PSTN phone "C". It does this as follows:
a.
"A" sends a SIP REFER message (with the phone number of "C" in the Refer-To
header) to the device.
b. The device sends a Q.931 Setup message to "C". This feature enables
manipulating the called party number in this outgoing Setup message.
The manipulation is done as follows:
1.
If you configure a value for the xferPrefix parameter, then this value (string) is added
as a prefix to the number in the Refer-To header.
2.
This called party number is then manipulated using the IP-to-Tel Destination Phone
Number Manipulation table.
3.
The source number of the transferred call is taken from the original call, according to
its initial direction:
Version 6.8
•
Tel-to-IP call: source number of the original call.
•
IP-to-Tel call: destination number of the original call.
•
If the UseReferredByForCallingNumber parameter is set to 1, the source number
is taken from the SIP Referred-By header if included in the received SIP REFER
message.
417
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
This source number can also be used as the value for the 'Source Prefix' field in the
IP-to-Tel Destination Phone Number Manipulation table. The local IP address is used
as the value for the 'Source IP Address' field.
Note: Manipulation using the ManipulateIP2PSTNReferTo parameter does not affect
IP-to-Trunk Group routing rules.
26.6
Call Forward
For digital interfaces: The device supports Call Deflection (ETS-300-207-1) for Euro ISDN
and QSIG (ETSI TS 102 393) for Network and User sides, which provides IP-ISDN
interworking of call forwarding (call diversion) when the device receives a SIP 302
response.
Call forward performed by the SIP side: Upon receipt of a Facility message with Call
Rerouting IE from the PSTN, the device initiates a SIP transfer process by sending a SIP
302 (including the Call Rerouting destination number) to the IP in response to the remote
SIP entity's INVITE message. The device then responds with a Disconnect message to the
PSTN side.
Call forward performed by the PSTN side: When the device sends the INVITE message to
the remote SIP entity and receives a SIP 302 response, the device sends a Facility
message with the same IE mentioned above to the PSTN, and waits for the PSTN side to
disconnect the call. This is configured using the CallReroutingMode.
For analog interfaces: The following methods of call forwarding are supported:

Immediate: incoming call is forwarded immediately and unconditionally.

Busy: incoming call is forwarded if the endpoint is busy.

No Reply: incoming call is forwarded if it isn't answered for a specified time.

On Busy or No Reply: incoming call is forwarded if the port is busy or when calls are
not answered after a specified time.

Do Not Disturb: immediately reject incoming calls. Upon receiving a call for a Do Not
Disturb, the 603 Decline SIP response code is sent.
Three forms of forwarding parties are available:

Served party: party configured to forward the call (FXS device).

Originating party: party that initiates the first call (FXS or FXO device).

Diverted party: new destination of the forwarded call (FXS or FXO device).
The served party (FXS interface) can be configured through the Web interface (see
Configuring Call Forward on page 464) or ini file to activate one of the call forward modes.
These modes are configurable per endpoint.
Notes:
• When call forward is initiated, the device sends a SIP 302 response with a contact
that contains the phone number from the forward table and its corresponding IP
address from the routing table (or when a proxy is used, the proxy’s IP address).
• For receiving call forward, the device handles SIP 3xx responses for redirecting
calls with a new contact.
User's Manual
418
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
26.6.1 Call Forward Reminder Ring
The device supports the Call Forward Reminder Ring feature for FXS interfaces, whereby
the device's FXS endpoint emits a short ring burst, only in onhook state, when a third-party
Application Server (e.g., softswitch) forwards an incoming call to another destination. This
is important in that it notifies (audibly) the FXS endpoint user that a call forwarding service
is currently being performed.
Figure 26-2: Call Forward Reminder with Application Server
The device generates a Call Forward Reminder ring burst to the FXS endpoint each time it
receives a SIP NOTIFY message with a “reminder ring” xml body. The NOTIFY request is
sent from the Application Server to the device each time the Application Server forwards an
incoming call. The service is cancelled when an UNSUBSCRIBE request is sent from the
device, or when the Subscription time expires.
The reminder-ring tone can be defined by using the parameter CallForwardRingToneID,
which points to a ring tone defined in the Call Progress Tone file.
The following parameters are used to configure this feature:

EnableNRTSubscription

ASSubscribeIPGroupID

NRTSubscribeRetryTime

CallForwardRingToneID
26.6.2 Call Forward Reminder (Off-Hook) Special Dial Tone
The device plays a special dial tone (stutter dial tone - Tone Type #15) to a specific FXS
endpoint when the phone is off-hooked and when a third-party Application server (AS),
e.g., a softswitch is used to forward calls intended for the endpoint, to another destination.
This is useful in that it reminds the FXS user of this service. This feature does not involve
device subscription (SIP SUBSCRIBE) to the AS.
Activation/deactivation of the service is notified by the server. An unsolicited SIP NOTIFY
request is sent from the AS to the device when the Call Forward service is activated or deactivated. Depending on this NOTIFY request, the device plays either the standard dial
tone or the special dial tone for Call Forward.
For playing the special dial tone, the received SIP NOTIFY message must contain the
following headers:

From and To: contain the same information, indicating the specific endpoint

Event: ua-profile

Content-Type: "application/simservs+xml"
Version 6.8
419
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

Message body is the XML body and contains the “dial-tone-pattern” set to "specialcondition-tone" (<ss:dial-tone-pattern>special-condition-tone</ss:dial-tone-pattern>),
which is the special tone indication.
To cancel the special dial tone and playing the regular dial tone, the received SIP NOTIFY
message must contain the following headers:

From and To: contain the same information, indicating the specific endpoint

Event: ua-profile

Content-Type: "application/simservs+xml"

Message body is the XML body containing the “dial-tone-pattern” set to "standardcondition-tone" (<ss:dial-tone-pattern>standard-condition-tone</ss:dial-tone-pattern>),
which is the regular dial tone indication.
Therefore, the special dial tone is valid until another SIP NOTIFY is received that instructs
otherwise (as described above).
Note: if the MWI service is active, the MWI dial tone overrides this special Call
Forward dial tone.
26.6.3 Call Forward Reminder Dial Tone (Off-Hook) upon Spanish SIP
Alert-Info
The device plays a special dial tone to FXS phones in off-hook state that are activated with
the call forwarding service. The special dial tone is used as a result of the device receiving
a SIP NOTIFY message from a third-party softswitch providing the call forwarding service
with the following SIP Alert-Info header:
Alert-Info: <http://127.0.0.1/Tono-Espec-Invitacion>;lpiaviso=Desvio-Inmediato
This special tone is a stutter dial tone (Tone Type = 15), as defined in the CPT file.
The FXS phone user, connected to the device, activates the call forwarding service by
dialing a special number (e.g., *21*xxxxx) and as a result, the device sends a regular SIP
INVITE message to the softswitch. The softswitch later notifies of the activation of the
forwarding service by sending an unsolicited NOTIFY message with the Alert-Info header,
as mentioned above.
When the call forwarding service is de-activated, for example, by dialing #21# and sending
an INVITE with this number, the softswitch sends another SIP NOTIFY message with the
following Alert-Info header:
Alert-Info: <http://127.0.0.1/ Tono-Normal-Invitacion>; Aviso =
Desvi‫ף‬-Inmediato
From this point on, the device plays a normal dial tone to the FXS phone when it goes offhook.
26.6.4 BRI Call Forwarding
405B
The device supports call forwarding (CF) services initiated by ISDN Basic BRI phones
connected to it. Upon receipt of an ISDN Facility message for call forward from the BRI
phone, the device sends a SIP INVITE to the softswitch with a user-defined code in the SIP
To header, representing the reason for the call forward.
The codes for the call forward can be defined using the following parameters:

SuppServCodeCFU - Call Forward Unconditional

SuppServCodeCFUDeact - Call Forward Unconditional Deactivation
User's Manual
420
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services

SuppServCodeCFB - Call Forward on Busy

SuppServCodeCFBDeact - Call Forward on Busy Deactivation

SuppServCodeCFNR - Call Forward on No Reply

SuppServCodeCFNRDeact - Call Forward on No Reply Deactivation
Note: These codes must be defined according to the settings of the softswitch (i.e.,
the softswitch must recognize them).
Below is an example of an INVITE message sent by the device indicating an unconditional
call forward (“*72”) to extension number 100. This code is defined using the
SuppServCodeCFU parameter.
INVITE sip:*72100@10.33.8.53;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.33.2.5:5060;branch=z9hG4bKWDSUKUHWFEXQSVOUVJGM
From: <sip:400@10.33.2.5;user=phone>;tag=DUOROSXSOYJJLNBFRQTG
To: <sip:*72100@10.33.8.53;user=phone>
Call-ID: GMNOVQRRXUUCYCQSFAHS@10.33.2.5
CSeq: 1 INVITE
Contact: <sip:400@10.33.2.5:5060>
Supported: em,100rel,timer,replaces
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUB
SCRIBE
User-Agent: Sip Message Generator V1.0.0.5
User-to-User: 31323334;pd=4
Content-Type: application/sdp
Content-Length: 155
26.7
Call Waiting
The Call Waiting feature enables FXS devices to accept an additional (second) call on
busy endpoints. If an incoming IP call is designated to a busy port, the called party hears a
call waiting tone (several configurable short beeps) and (for Bellcore and ETSI Caller IDs)
can view the Caller ID string of the incoming call. The calling party hears a call waiting
ringback tone. The called party can accept the new call using hook-flash, and can toggle
between the two calls.
 To enable call waiting:
1.
Set the parameter EnableCallWaiting to 1.
2.
Set the parameter EnableHold to 1.
3.
Define the Call Waiting indication and call waiting ringback tones in the Call Progress
Tones file. You can define up to four call waiting indication tones (refer to the
FirstCallWaitingToneID parameter).
4.
To configure the call waiting indication tone cadence, modify the following parameters:
NumberOfWaitingIndications,
WaitingBeepDuration
and
TimeBetweenWaitingIndications.
5.
To configure a delay interval before a Call Waiting Indication is played to the currently
busy port, use the parameter TimeBeforeWaitingIndication. This enables the caller to
hang up before disturbing the called party with Call Waiting Indications. Applicable
only to FXS modules.
Both the calling and called sides are supported by FXS interfaces; FXO interfaces support
only the calling side.
Version 6.8
421
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
To indicate Call Waiting, the device sends a 182 Call Queued response. The device
identifies Call Waiting when a 182 Call Queued response is received.
Note: The Call Waiting feature is applicable only to FXS/FXO interfaces.
26.8
Message Waiting Indication
The device supports Message Waiting Indication (MWI) according to IETF RFC 3842. The
device also supports subscribing to an MWI server (using SIP SUBSCRIBE messages).
For analog interfaces: The FXS device can accept a SIP MWI NOTIFY message that
indicates waiting messages or cleared messages. Users are informed of these messages
by a stutter dial tone. You can define the stutter and confirmation tones in the CPT file. If
the MWI display is configured, the number of waiting messages is also displayed. If the
MWI lamp is configured, the phone’s lamp (on a phone that is equipped with an MWI lamp)
is lit. The device can subscribe to the MWI server per port (usually used on FXS) or per
device (used on FXO).
Note: For more information on IP voice mail configuration, refer to the IP Voice Mail
CPE Configuration Guide.
To configure MWI, use the following parameters:

EnableMWI

MWIServerIP, or MWISubscribeIPGroupID and ProxySet

MWIAnalogLamp

MWIDisplay

StutterToneDuration

EnableMWISubscription

MWIExpirationTime

SubscribeRetryTime

SubscriptionMode

CallerIDType (determines the standard for detection of MWI signals)

ETSIVMWITypeOneStandard

BellcoreVMWITypeOneStandard

VoiceMailInterface

EnableVMURI
The device supports the following digital PSTN-based MWI features:

ISDN BRI: The device supports MWI for its BRI phones, using the Euro ISDN BRI
variant. When this feature is activated and a voice mail message is recorded to the
mail box of a BRI extension, the softswitch sends a notification to the device. In turn,
the device notifies the BRI extension and a red light flashes on the BRI extension’s
phone. Once the voice message is retrieved, the MWI light on the BRI phone turns off.
This is configured by setting the VoiceMailInterface parameter to 8 (“ETSI”) and
enabled by the EnableMWI parameter.

Euro-ISDN MWI: The device supports Euro-ISDN MWI for IP-to-Tel calls. The device
interworks SIP MWI NOTIFY messages to Euro-ISDN Facility information element (IE)
User's Manual
422
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
MWI messages. This is configured by setting the VoiceMailInterface parameter to 8.

ISDN PRI NI-2: The device support the interworking of the SIP MWI NOTIFY
messages to ISDN PRI NI-2 Message Waiting Notification (MWN), sent in the ISDN
Facility IE message. This is applicable when the device is connected to a PBX through
an ISDN PRI trunk configured to NI-2. This is configured by setting the
VoiceMailInterface parameter to [9].

QSIG MWI: The device supports the interworking of QSIG MWI to IP (in addition to
interworking of SIP MWI NOTIFY to QSIG Facility MWI messages). This provides
interworking between an ISDN PBX with voice mail capabilities and a softswitch,
which requires information on the number of messages waiting for a specific user.
This support is configured using the TrunkGroupSettings_MWIInterrogationType
parameter (in the Trunk Group Settings table), which determines the device's handling
of MWI Interrogation messages. The process for sending the MWI status upon request
from a softswitch is as follows:
1.
2.
The softswitch sends a SIP SUBSCRIBE message to the device.
The device responds by sending an empty SIP NOTIFY to the softswitch, and
then sending an ISDN Setup message with Facility IE containing an MWI
Interrogation request to the PBX.
3. The PBX responds by sending to the device an ISDN Connect message
containing Facility IE with an MWI Interrogation result, which includes the number
of voice messages waiting for the specific user.
4. The device sends another SIP NOTIFY to the softswitch, containing this MWI
information.
5. The SIP NOTIFY messages are sent to the IP Group defined by the
NotificationIPGroupID parameter.
When a change in the status occurs (e.g., a new voice message is waiting or the user
has retrieved a message from the voice mail), the PBX initiates an ISDN Setup
message with Facility IE containing an MWI Activate request, which includes the new
number of voice messages waiting for the user. The device forwards this information
to the softswitch by sending a SIP NOTIFY.
Depending on PBX support, the MWIInterrogationType parameter can be configured
to handle these MWI Interrogation messages in different ways. For example, some
PBXs support only the MWI Activate request (and not MWI Interrogation request).
Some support both these requests. Therefore, the device can be configured to disable
this feature or enable it with one of the following support:
26.9
•
Responds to MWI Activate requests from the PBX by sending SIP NOTIFY MWI
messages (i.e., does not send MWI Interrogation messages).
•
Send MWI Interrogation message, but don't use its result. Instead, wait for MWI
Activate requests from the PBX.
•
Send MWI Interrogation message, use its result, and use the MWI Activate
requests.
Caller ID
This section describes the device's Caller ID support.
Note: The Caller ID feature is applicable only to FXS/FXO interfaces.
Version 6.8
423
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
26.9.1 Caller ID Detection / Generation on the Tel Side
By default, generation and detection of Caller ID to the Tel side is disabled. To enable
Caller ID, set the parameter EnableCallerID to 1. When the Caller ID service is enabled:

For FXS: the Caller ID signal is sent to the device's port

For FXO: the Caller ID signal is detected
The configuration for Caller ID is described below:

Use the parameter CallerIDType to define the Caller ID standard. Note that the Caller
ID standard that is used on the PBX or phone must match the standard defined in the
device.

Select the Bellcore caller ID sub standard using the parameter
BellcoreCallerIDTypeOneSubStandard

Select the ETSI FSK caller ID sub standard using the parameter
ETSICallerIDTypeOneSubStandard

Enable or disable (per port) the caller ID generation (for FXS) and detection (for FXO)
using the ‘Generate / Detect Caller ID to Tel’ table (EnableCallerID). If a port isn’t
configured, its caller ID generation / detection are determined according to the global
parameter EnableCallerID.

EnableCallerIDTypeTwo: disables / enables the generation of Caller ID type 2 when
the phone is off-hooked (used for call waiting).

RingsBeforeCallerID: sets the number of rings before the device starts detection of
caller ID (FXO only). By default, the device detects the caller ID signal between the
first and second rings.

AnalogCallerIDTimimgMode: determines the time period when a caller ID signal is
generated (FXS only). By default, the caller ID is generated between the first two
rings.

PolarityReversalType: some Caller ID signals use reversal polarity and/or wink
signals. In these scenarios, it is recommended to set PolarityReversalType to 1 (Hard)
(FXS only).

The Caller ID interworking can be changed using the parameters
UseSourceNumberAsDisplayName and UseDisplayNameAsSourceNumber.
26.9.2 Debugging a Caller ID Detection on FXO
The following procedure describes debugging caller ID detection in FXO interfaces.
 To debug a Caller ID detection on an FXO interface:
1.
Verify that the parameter EnableCallerID is set to 1.
2.
Verify that the caller ID standard (and substandard) of the device matches the
standard
of
the
PBX
(using
the
parameters
CallerIDType,
BellcoreCallerIDTypeOneSubStandard, and ETSICallerIDTypeOneSubStandard).
3.
Define the number of rings before the device starts the detection of caller ID (using the
parameter RingsBeforeCallerID).
4.
Verify that the correct FXO coefficient type is selected (using the parameter
CountryCoefficients), as the device is unable to recognize caller ID signals that are
distorted.
5.
Connect a phone to the analog line of the PBX (instead of to the device's FXO
interface) and verify that it displays the caller ID.
If the above does not solve the problem, you need to record the caller ID signal (and send
it to AudioCodes), as described below.
User's Manual
424
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
 To record the caller ID signal using the debug recording mechanism:
1.
Access the FAE page (by appending "FAE" to the device's IP address in the Web
browser's URL, for example, http://10.13.4.13/FAE).
2.
Press the Cmd Shell link.
3.
Enter the following commands:
dr
ait <IP address of PC to collect the debug traces sent from
the device>
AddChannelIdTrace ALL-WITH-PCM <port number, which starts from
0>
Start
4.
Make a call to the FXO.
5.
To stop the DR recording, at the CLI prompt, type STOP.
26.9.3 Caller ID on the IP Side
Caller ID is provided by the SIP From header containing the caller's name and "number",
for example:
From: “John” <SIP:101@10.33.2.2>;tag=35dfsgasd45dg
If Caller ID is restricted (received from Tel or configured in the device), the From header is
set to:
From: “anonymous” <anonymous@anonymous.invalid>; tag=35dfsgasd45dg
The P-Asserted (or P-Preferred) headers are used to present the originating party’s caller
ID even when the caller ID is restricted. These headers are used together with the Privacy
header.


If Caller ID is restricted:
•
The From header is set to “anonymous” <anonymous@anonymous.invalid>
•
The ‘Privacy: id’ header is included
•
The P-Asserted-Identity (or P-Preferred-Identity) header shows the caller ID
If Caller ID is allowed:
•
The From header shows the caller ID
•
The ‘Privacy: none’ header is included
•
The P-Asserted-Identity (or P-Preferred-Identity) header shows the caller ID
The caller ID (and presentation) can also be displayed in the Calling Remote-Party-ID
header.
The ‘Caller Display Information’ table (CallerDisplayInfo) is used for the following:

FXS interfaces - to define the caller ID (per port) that is sent to IP.

FXO interfaces - to define the caller ID (per port) that is sent to IP if caller ID isn’t
detected on the Tel side, or when EnableCallerID = 0.

FXS and FXO interfaces - to determine the presentation of the caller ID (allowed or
restricted).

To maintain backward compatibility - when the strings ‘Private’ or ‘Anonymous’ are
set in the Caller ID/Name field, the caller ID is restricted and the value in the
Presentation field is ignored.
The value of the ‘Presentation’ field that is defined in the ‘Caller Display Information’ table
can be overridden by configuring the ‘Presentation’ parameter in the ‘Tel to IP Source
Number Manipulation’ table. Therefore, this table can be used to set the presentation for
specific calls according to Source / Destination prefixes.
Version 6.8
425
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The caller ID can be restricted/allowed (per port) using keypad features KeyCLIR and
KeyCLIRDeact (FXS only).
AssertedIdMode defines the header that is used (in the generated INVITE request) to
deliver the caller ID (P-Asserted-Identity or P-Preferred-Identity). Use the parameter
UseTelURIForAssertedID to determine the format of the URI in these headers (sip: or tel:).
The parameter EnableRPIheader enables Remote-Party-ID (RPI) headers for calling and
called numbers for Tel-to-IP calls.
26.10 Three-Way Conferencing
The device supports three-way conference calls. These conference calls can also occur
simultaneously.
The device supports the following conference modes:

Conferencing managed by an external, AudioCodes Conference (media) server:
The Conference-initiating INVITE sent by the device uses the ConferenceID
concatenated with a unique identifier as the Request-URI. This same Request-URI is
set as the Refer-To header value in the REFER messages that are sent to the two
remote parties.
This mode is configured by setting the 3WayConferenceMode parameter to 0
(default.)


Conference Managed by External, Third-party Conferencing Server: Two optional
modes of operation:
•
The conference-initiating INVITE sent by the device uses only the ConferenceID
as the Request-URI. The Conferencing server sets the Contact header of the 200
OK response to the actual unique identifier (Conference URI) to be used by the
participants. This Conference URI is included (by the device) in the Refer-To
header value in the REFER messages sent by the device to the remote parties.
The remote parties join the conference by sending INVITE messages to the
Conferencing server using this conference URI. This mode is configured by
setting the 3WayConferenceMode parameter to 1.
•
The conference-initiating INVITE sent by the device uses only the ConferenceID
as the Request-URI. The Conferencing server sets the Contact header of the 200
OK response to the actual unique identifier (Conference URI) to be used by the
participants. The Conference URI is included in the URI of the REFER with a
Replaces header sent by the device to the Conferencing server. The
Conferencing server then sends an INVITE with a Replaces header to the remote
participants. This mode is configured by setting the 3WayConferenceMode
parameter to 3.
Local, on-board conferencing: The conference is established on the device without
the need for an external Conference server. This feature includes local mixing and
transcoding of the 3-Way Call legs on the device, and even allowing multi-codec
conference calls. The number of simultaneous, on-board conferences can be limited
using the parameter MaxInBoardConferenceCalls. The device sets up the call
conference using its IP media channels, which are obtained from the Media
Processing module (MPM). Thus, MPM module(s) must be installed in the device for
three-way conferencing. The device supports up to five simultaneous, on-board, threeway conference calls.
This mode is configured by setting the 3WayConferenceMode parameter to 2.
User's Manual
426
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
For N-way conferencing, the device can house up to four MPM modules. DSP resource
allocation is as follows:
Table 26-1: Installed MPM and Supported Channels for Conferencing
Chassis Slot No.
Channels
Comments
6
20 (thereby, supporting up to 6 three-way
conferences)
5
40
-
4
40
-
3
40
-
MPM in Slot #6 enables the
conferencing feature
Therefore, when the MPMs are installed in chassis slots #3, #4, #5, and #6, the device
provides up to 140 DSP resources, supporting up to 140 conference participants, which is
46 three-way conference calls.
Notes:
• If the device houses all three MPMs or more, no other telephony interface module
can be installed in the device.
• Three-way conferencing using an external conference server is supported only by
FXS interfaces.
• Instead of using the flash-hook button to establish a three-way conference call,
you can dial a user-defined hook-flash code (e.g., "*1"), configured by the
HookFlashCode parameter.
• Three-way conferencing is applicable only to FXS and BRI interfaces. Three-way
conferencing support for the BRI phones connected to the device complies with
ETS 300 185.
The following example demonstrates three-way conferencing using the device's local, onboard conferencing feature. In this example, telephone "A" connected to the device
establishes a three-way conference call with two remote IP phones, "B" and "C":
1.
A establishes a regular call with B.
2.
A places B on hold, by pressing the telephone's flash-hook button and the number "1"
key.
3.
A hears a dial tone and then makes a call to C.
4.
C answers the call.
5.
A establishes a three-way conference call with B and C, by pressing the flash-hook
button and the number "3" key.
To configure local, on-board three-way conferencing:
1.
Open the Supplementary Services page.
2.
Set 'Enable 3-Way Conference' to Enable (Enable3WayConference = 1).
3.
Set '3-Way Conference Mode' to On Board (3WayConferenceMode = 2).
4.
Set 'Flash Keys Sequence Style'
(FlashKeysSequenceStyle = 1 or 2).
Version 6.8
427
to
Sequence
1
or
Sequence
2
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
26.11 Emergency E911 Phone Number Services
This section describes the device's support for emergency phone number services. The
device supports the North American emergency telephone number system known as
Enhanced 911 (E911), according to the TR-TSY-000350 and Bellcore's GR-350-Jun2003
standards. The E911 emergency system automatically associates a physical address with
the calling party's telephone number, and routes the call to the most appropriate (closest)
Public Safety Answering Point (PSAP), allowing the PSAP to quickly dispatch emergency
response (e.g., police) to the caller's location.
Typically, the dialed emergency number is routed to the appropriate PSAP by the
telephone company's switch, known as a 911 Selective Router (or E911 tandem switch). If
the PSAP receives calls from the telephone company on old-style digital trunks, they are
specially formatted Multi-Frequency (MF) trunks that pass only the calling party's number
(known as Automatic Number Identification - ANI). Once the PSAP receives the call, it
searches for the physical address that is associated with the calling party's telephone
number (in the Automatic Location Identification database - ALI).
26.11.1 FXS Device Emulating PSAP using DID Loop-Start Lines
The device's FXS interface can be configured to emulate PSAP (using DID loop start lines),
according to the Telcordia GR-350-CORE specification.
Figure 26-3: FXS Device Emulating PSAP using DID Loop-Start Lines
The call flow of an E911 call to the PSAP is as follows:
1.
The E911 tandem switch seizes the line.
2.
The FXS device detects the line seize, and then generates a wink signal (nominal 250
msec). The wink can be delayed by configuring the parameter DelayBeforeDIDWink to
200 (for 200 msec or a higher value).
3.
The switch detects the wink and then sends the MF Spill digits with ANI and (optional)
Pseudo-ANI (P ANI).
4.
The FXS device collects the MF digits, and then sends a SIP INVITE message to the
PSAP with all collected MF digits in the SIP From header as one string.
User's Manual
428
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
5.
The FXS device generates a mid-call wink signal (two subsequent polarity reversals)
toward the E911 tandem switch upon either detection of an RFC 2833 "hookflash"
telephony event, or if a SIP INFO message with a "hooflash" body is received from the
PSAP (see the example below). The duration of this "flashhook" wink signal is
configured using the parameter FlashHookPeriod (usually 500 msec). Usually the wink
signal is followed by DTMF digits sent by PSAP to perform call transfer. Another way
to perform the call transfer is to use SIP REFER messages, as described below.
6.
The FXS device supports call transfer initiated by the PSAP. If it receives a SIP
REFER message with the Refer-To URI host part containing an IP address that is
equal to the device's IP address, the FXS device generates a 500-msec wink signal
(double polarity reversals), and then (after a user-defined interval configured by the
parameter WaitForDialTime), plays DTMF digits according to the transfer number
received in the SIP Refer-To header URI userpart.
7.
When the call is answered by the PSAP operator, the PSAP sends a SIP 200 OK to
the FXS device, and the FXS device then generates a polarity reversal signal to the
E911 switch.
8.
After the call is disconnected by the PSAP, the PSAP sends a SIP BYE to the FXS
device, and the FXS device reverses the polarity of the line toward the tandem switch.
The following parameters need to be configured:

EnableDIDWink = 1

EnableReversalPolarity = 1

PolarityReversalType = 1

FlashHookPeriod = 500 (for 500 msec "hookflash" mid-call Wink)

WinkTime = 250 (for 250 msec signalling Wink generated by the FXS device after it
detects the line seizure)

EnableTransfer = 1 (for call transfer)

LineTransferMode = 1 (for call transfer)

WaitforDialTime = 1000 (for call transfer)

SwapTEl2IPCalled&CallingNumbers = 1

DTMFDetectorEnable = 0

MFR1DetectorEnable = 1

DelayBeforeDIDWink = 200 (for 200 msec) - can be configured in the range from 0
(default) to 1000.
Note: Modification of the WinkTime parameter requires a device reset.
The outgoing SIP INVITE message contains the following headers:
INVITE sip:Line@DomainName
From: <sip:*81977820#@sipgw>;tag=1c143
To: <sip:Line@DomainName>
Where:

Line = as configured in the Endpoint Phone Number Table

SipGtw = configured by the SIPGatewayName parameter

From header/user part = calling party number as received from the MF spill
The ANI and the pseudo-ANI numbers are sent to the PSAP either in the From and/or PAssertedID SIP header.
Version 6.8
429
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
Typically, the MF spills are sent from the E911 tandem switch to the PSAP, as shown in
the table below:
Table 26-2: Dialed MF Digits Sent to PSAP
Digits of Calling Number
Dialed MF Digits
8 digits "nnnnnnnn" (ANI)
"KPnnnnnnnnST"
12 digits "nnnnnnnnnnnn" (ANI)
"KPnnnnnnnnnnnnSTP"
12 digits ANI and 10 digits PANI
"KPnnnnnnnnnnnnSTKPmmmmmmmmmmST"
two digits "nn"
"KPnnSTP"
The MF KP, ST, and STP digits are mapped as follows:

* for KP

# for ST

B for STP
For example, if ANI and PANI are received, the SIP INVITE contains the following From
header:
From: <sip:*nnnnnnnnnnnn#*mmmmmmmmmm#@10.2.3.4>;tag=1c14
Note: It is possible to remove the * and # characters, using the device's number
manipulation rules.
If the device receives the SIP INFO message below, it then generates a "hookflash" midcall Wink signal:
INFO sip:4505656002@192.168.13.40:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.13.2:5060
From: port1vega1 <sip:06@192.168.13.2:5060>
To: <sip:4505656002@192.168.13.40:5060>;tag=1328787961040067870294
Call-ID: 0010-0016-D69A7DA8-1@192.168.13.2
CSeq:2 INFO
Content-Type: application/broadsoft
Content-Length: 17
event flashhook
User's Manual
430
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
26.11.2 FXO Device Interworking SIP E911 Calls from Service Provider's
IP Network to PSAP DID Lines
The device's FXO interface can interwork SIP emergency E911 calls from the Service
Provider's IP network to the analog PSAP DID lines. The standards that define this
interface include TR-TSY-000350 or Bellcore’s GR-350-Jun2003. This protocol defines
signaling between the E911 tandem switch (E911 Selective Router) and the PSAP, using
analog loop-start lines. The FXO device can be implemented instead of an E911 switch, by
connecting directly to the PSAP DID loop-start lines.
Figure 26-4: FXO Device Interfacing between E911 Switch and PSAP
When an IP phone subscriber dials 911, the device receives the SIP INVITE message and
makes a call to the PSAP as follows:
1.
The FXO device seizes the line.
2.
PSAP sends a Wink signal (250 msec) to the device.
3.
Upon receipt of the Wink signal, the device dials MF digits after a user-defined time
(WaitForDialTime) containing the caller's ID (ANI) obtained from the SIP headers
From or P-Asserted-Identity.
4.
When the PSAP operator answers the call, the PSAP sends a polarity reversal to the
device, and the device then sends a SIP 200 OK to the IP side.
5.
After the PSAP operator disconnects the call, the PSAP reverses the polarity of the
line, causing the device to send a SIP BYE to the IP side.
6.
If, during active call state, the device receives a Wink signal (typically of 500 msec)
from the PSAP, the device generates a SIP INFO message that includes a "hookflash"
body, or sends RFC 2833 hookflash Telephony event (according to the
HookFlashOption parameter).
7.
Following the "hookflash" Wink signal, the PSAP sends DTMF digits. These digits are
detected by the device and forwarded to the IP, using RFC 2833 telephony events (or
Version 6.8
431
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
inband, depending on the device's configuration). Typically, this Wink signal followed
by the DTMF digits initiates a call transfer.
For supporting the E911 service, used the following configuration parameter settings:

Enable911PSAP = 1 (also forces the EnableDIDWink and EnableReversalPolarity)

HookFlashOption = 1 (generates the SIP INFO hookflash message) or 4 for RFC 2833
telephony event

WinkTime = 700 (defines detection window of 50 to 750 msec for detection of both
winks - 250 msec wink sent by the PSAP for starting the device's dialing; 500 msec
wink during the call)

IsTwoStageDial = 0

EnableHold = 0

EnableTransfer = 0
•
Use RFC 2833 DTMF relay:
♦
RxDTMFOption = 3
♦
TxDTMFOption = 4
♦
RFC2833PayloadType = 101

TimeToSampleAnalogLineVoltage = 100

WaitForDialTime = 1000 (default is 1 sec)

SetDefaultLinePolarityState = 0 (you need to verify that the RJ-11 two-wire cable is
connected without crossing, Tip to Tip, Ring to Ring. Typically, the Tip line is positive
compared to the Ring line.)
Note: If the two-wire cable is crossed, the SetDefaultLinePolarityState parameter
must be set to 1.
The device expects to receive the ANI number in the From and/or P-Asserted-Identity SIP
header. If the pseudo-ANI number exists, it should be sent as the display name in these
headers.
Table 26-3: Dialed Number by Device Depending on Calling Number
Digits of Calling
Number (ANI)
Digits of Displayed Number
Number Dialed MF Digits
8
"nnnnnnnn"
-
MF dialed "KPnnnnnnnnST"
12
"nnnnnnnnnnnn"
None
"KPnnnnnnnnnnnnSTP"
12
"nnnnnnnnnnnn"
10
"mmmmmmmmmm" (pANI)
"KPnnnnnnnnnnnnSTKPmmmmmmmmmmST"
2
"nn"
None
"KPnnSTP"
1
"n"
-
MF dialed "KPnST"
For example:
"From: <sip:8>@xyz.com>" generates device
MF spill of KP 8 ST
Table notes:

User's Manual
For all other cases, a SIP 484 response is sent.
432
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services

KP is for .

ST is for #.

STP is for B.
The MF duration of all digits, except for the KP digit is 60 msec. The MF duration of the KP
digit is 120 msec. The gap duration is 60 msec between any two MF digits.
Notes:
• Manipulation rules can be configured for the calling (ANI) and called number (but
not on the "display" string), for example, to strip 00 from the ANI "00INXXYYYY".
• The called number, received as userpart of the Request URI ("301" in the example
below), can be used to route incoming SIP calls to FXO specific ports, using the
TrunkGroup and PSTNPrefix parameters.
• When the PSAP party off-hooks and then immediately on-hooks (i.e., the device
detects wink), the device releases the call sending SIP response "403 Forbidden"
and the release reason 21 (i.e., call rejected) "Reason: Q.850 ;cause=21" is sent.
Using the cause mapping parameter, it is possible to change the 403 to any other
SIP reason, for example, to 603.
• Sometimes a wink signal sent immediately after the FXO device seizes the line is
not detected. To overcome this problem, configure the parameter
TimeToSampleAnalogLineVoltage to 100 (instead of 1000 msec, which is the
default value). The wink is then detected only after this timeout + 50 msec
(minimum 150 msec).
Below are two examples for a) INVITE messages and b) INFO messages generated by
hook-flash.

Version 6.8
Example A: INVITE message with ANI = 333333444444 and pseudo-ANI =
0123456789:
INVITE sip:301@10.33.37.79;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.33.37.78;branch=z9hG4bKac771627168
Max-Forwards: 70
From: "0123456789"
<sip:333333444444@audiocodes.com>;tag=1c771623824
To: <sip:301@10.33.37.79;user=phone>
Call-ID: 77162335841200014153@10.33.37.78
CSeq: 1 INVITE
Contact: <sip:101@10.33.37.78>
Supported: em,100rel,timer,replaces,path
Allow:
REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO
,SUBSCRIBE,UPDATE
User-Agent: Audiocodes-Sip-Gateway-FXO/v.6.00A.020.077
Privacy: none
P-Asserted-Identity: "0123456789"
<sip:3333344444@audiocodes.com>
Content-Type: application/sdp
Content-Length: 253
v=0
o=AudiocodesGW 771609035 771608915 IN IP4 10.33.37.78
s=Phone-Call
c=IN IP4 10.33.37.78
t=0 0
m=audio 4000 RTP/AVP 8 0 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
433
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Example B: The detection of a Wink signal generates the following SIP INFO
message:
INFO sip:4505656002@192.168.13.40:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.13.2:5060
From: port1vega1 <sip:06@192.168.13.2:5060>
To: <sip:4505656002@192.168.13.40:5060>;tag=1328787961040067870294
Call-ID: 0010-0016-D69A7DA8-1@192.168.13.2
CSeq:2 INFO
Content-Type: application/broadsoft
Content-Length: 17
event flashhook
26.11.3 Pre-empting Existing Calls for E911 IP-to-Tel Calls
If the device receives an E911 call from the IP network destined to the Tel, and there are
unavailable channels (e.g., all busy), the device terminates one of the calls (arbitrary) and
then sends the E911 call to that channel. The preemption is done only on a channel
pertaining to the same Trunk Group for which the E911 call was initially destined and if the
channel select mode (configured by the ChannelSelectMode parameter) is set to a value
other than “By Dest Phone Number” (0).
The preemption is done only if the incoming IP-to-Tel call is identified as an emergency
call. The device identifies emergency calls by one of the following:

The destination number of the IP call matches one of the numbers defined by the
EmergencyNumbers parameter. For E911, you must defined this parameter with the
value "911".

The Priority header of the incoming SIP INVITE message contains the “emergency”
value.
Emergency pre-emption of calls can be enabled for all calls, using the global parameter
CallPriorityMode, or for specific calls using the Tel Profile parameter CallPriorityMode.
Notes:
• For Trunk Groups configured with call preemption, all must be configured to MLPP
[1] or all configured to Emergency [2]. In other words, you cannot set some trunks
to [1] and some to [2].
• The global parameter must be set to the same value as that of the Tel Profile
parameter; otherwise, the Tel Profile parameter is not applied.
• If you configure call preemption using the global parameter and a new Tel Profile
is subsequently added, the TelProfile_CallPriorityMode parameter automatically
acquires the same setting as well.
• This feature is applicable to FXO, CAS and ISDN interfaces.
• For FXO interfaces, the preemption is done only on existing IP-to-Tel calls. In
other words, if all the current FXO channels are busy with calls that were
answered by the FXO device (i.e., Tel-to-IP calls), new incoming emergency IP-toTel calls are rejected.
User's Manual
434
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
26.11.4 Enhanced 9-1-1 Support for Lync Server 2010
The Enhanced 9-1-1 (E9-1-1) service is becoming the mandatory emergency service
required in many countries around the world. The E9-1-1 service, based on its predecessor
911, enables emergency operators to pinpoint the location (granular location) of callers
who dial the 9-1-1 emergency telephone number.
Today, most enterprises implement an IP-based infrastructure providing a VoIP network
with fixed and nomadic users, allowing connectivity anywhere with any device. This,
together with an often deployed multi-line telephone system (MLTS) poses a challenge for
E9-1-1 due to the difficulty in accurately locating the E9-1-1 caller.
This section describes the E9-1-1 solution provided by Microsoft Lync Server 2010
(hereafter referred to as Lync Server 2010), and the deployed AudioCodes ELIN Gateway
which provides the ISDN (or CAMA) connectivity to the PSTN-based E9-1-1 emergency
providers. This section also describes the configuration of AudioCodes ELIN Gateway for
interoperating between the Lync Server 2010 environment and the E9-1-1 emergency
provider.
26.11.4.1
About E9-1-1 Services
E9-1-1 is a national emergency service for many countries, enabling E9-1-1 operators to
automatically identify the geographical location and phone number of a 911 caller. In E9-11, the 911 caller is routed to the nearest E9-1-1 operator, termed public safety answering
point (PSAP) based on the location of the caller. Automatic identification of the caller's
location and phone number reduces the time spent on requesting this information from the
911 caller. Therefore, the E9-1-1 service enables the PSAP to quickly dispatch the relevant
emergency services (for example, fire department or police) to the caller's location. Even if
the call prematurely disconnects, the operator has sufficient information to call back the
911 caller.
The figure below illustrates the routing of an E9-1-1 call to the PSAP:
Figure 26-5: Call Flow of E9-1-1 to PSTN-Based Emergency Services Provider
1.
The VoIP user dials 9-1-1.
2.
The call is eventually sent to the PSTN through a PSTN Gateway.
3.
The PSTN identifies the call is an emergency call and sends it to an E9-1-1 Selective
Router in the Emergency Services provider's network.
Version 6.8
435
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
4.
The E9-1-1 Selective Router determines the geographical location of the caller by
requesting this information from an Automatic Location Identification (ALI) database
based on the phone number or Automatic Number Identifier (ANI) of the 911 caller.
Exact location information is also supplied by the Master Street Address Guide
(MSAG) database, which is a companion database to the ALI database. Phone
companies and public safety agencies collaborate beforehand to create master maps
that match phone numbers, addresses and cross streets to their corresponding PSAP.
This MSAG is the official record of valid streets (with exact spelling), street number
ranges, and other address elements with which the service providers are required to
update their ALI databases.
5.
The E9-1-1 Selective Router sends the call to the appropriate PSAP based on the
retrieved location information from the ALI.
6.
The PSAP operator dispatches the relevant emergency services to the E9-1-1 caller.
26.11.4.2
Microsoft Lync Server 2010 and E9-1-1
Microsoft Lync Server 2010 enables Enterprise voice users to access its unified
communications platform from virtually anywhere and through many different devices. This,
together with a deployed MLTS, poses a challenge for E9-1-1 due to the difficulty in
accurately locating the E9-1-1 caller. However, Lync Server 2010 offers an innovative
solution to solving Enterprises E9-1-1 location problems.
26.11.4.2.1
Gathering Location Information of Lync 2010 Clients for 911 Calls
When a Microsoft® Lync™ 2010 client (hereafter referred to as Lync 2010 client) is
enabled for E9-1-1, the location data that is stored on the client is sent during an
emergency call. This stored location information is acquired automatically from the
Microsoft Location Information Server (LIS). The LIS stores the location of each network
element in the enterprise. Immediately after the Lync 2010 client registration process or
when the operating system detects a network connection change, each Lync 2010 client
submits a request to the LIS for a location. If the LIS is able to resolve a location address
for the client request, it returns the address in a location response. Each client then caches
this information. When the Lync 2010 client dials 9-1-1, this location information is then
included as part of the emergency call and used by the Emergency Services provider to
route the call to the correct PSAP.
The gathering of location information in the Lync Server 2010 network is illustrated in the
figure below:
Figure 26-6: Microsoft Lync Server 2010 Client Acquiring Location Information
User's Manual
436
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
1.
The Administrator provisions the LIS database with the location of each network
element in the Enterprise. The location is a civic address, which can include
contextual in-building and company information. In other words, it associates a
specific network entity (for example, a WAP) with a physical location in the Enterprise
(for example, Floor 2, Wing A, and the Enterprise's street address). For more
information on populating the LIS database, see ''Adding ELINs to the Location
Information Server'' on page 438.
2.
The Administrator validates addresses with the Emergency Services provider's MSAG
–a companion database to the ALI database. This ensures that the civic address is
valid as an official address (e.g., correct address spelling).
3.
The Lync 2010 client initiates a location request to the LIS under the following
circumstances:
•
Immediately after startup and registering the user with Lync Server 2010
•
Approximately every four hours after initial registration
•
Whenever a network connection change is detected (such as roaming to a new
WAP)
The Lync 2010 client includes in its location request the following known network
connectivity information:
•
Always included:
♦
IPv4 subnet
♦
Media Access Control (MAC) address
•
Depends on network connectivity:
Wireless access point (WAP) Basic Service Set Identifier (BSSID)
♦
Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED)
chassis ID and port ID
For a Lync 2010 client that moves inside the corporate network such as a soft phone
on a laptop that connects wirelessly to the corporate network, Lync Server 2010 can
determine which subnet the phone belongs to or which WAP / SSID is currently
serving the soft-client.
♦
4.
The LIS queries the published locations for a location and if a match is found, returns
the location information to the client. The matching order is as follows:
•
WAP BSSID
•
LLDP switch / port
•
LLDP switch
•
Subnet
•
MAC address
This logic ensures that for any client that is connected by a wireless connection, a
match is first attempted based on the hardware address of its connected access point.
The logic is for the match to be based on the most detailed location. The subnet
generally provides the least detail. If no match is found in the LIS for WAP BSSID,
LLDP switch / port, LLDP switch, or subnet, the LIS proxies the MAC address to an
integrated Simple Network Management Protocol (SNMP) scanning application. Using
SNMP may benefit some organizations for the following reasons:
•
LLDP is not supported by Lync Server 2010 so this provides a mechanism for soft
phones to acquire detailed location information.
•
Installed Layer-2 switches may not support LLDP.
If there is no match and the LIS cannot determine the location, the user may be prompted
to manually enter the location. For example, the client may be located in an undefined
subnet, at home, in a coffee shop or anywhere else outside the network. When a user
manually provides a location, the location is mapped based on the MAC address of the
default gateway of the client’s network and stored on the client. When the client returns to
Version 6.8
437
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
any previously stored location, the client is automatically set to that location. A user can
also manually select any location stored in the local users table and manage existing
entries.
26.11.4.2.2
Adding ELINs to the Location Information Server
As mentioned in the previous section, the Administrator needs to populate the Location
Information Server (LIS) database with a network wire map, which maps the Enterprise's
network elements to civic addresses. Once done, it can automatically locate clients within
a network. You can add addresses individually to the LIS or in a batch using a commaseparated value (CSV) file containing the column formats listed in the table below.
Table 26-4: Columns in the LIS Database
Network
Element
Columns
<BSSID>,<Description>,<Location>,<CompanyName>,<HouseNumber>,<HouseNum
Wireless
berSuffix>,<PreDirectional>,…<StreetName>,<StreetSuffix>,<PostDirectional>,<City>,
access point
<State>,<PostalCode>,<Country>
Subnet
<Subnet>,<Description>,<Location>,<CompanyName>,<HouseNumber>,<HouseNum
berSuffix>,<PreDirectional>,…<StreetName>,<StreetSuffix>,<PostDirectional>,<City>,
<State>,<PostalCode>,<Country>
Port
<ChassisID>,<PortIDSubType>,<PortID>,<Description>,<Location>,<CompanyName>
,<HouseNumber>,<HouseNumberSuffix>,…<PreDirectional>,<StreetName>,<StreetS
uffix>,<PostDirectional>,<City>,<State>,<PostalCode>,<Country>
Switch
<ChassisID>,<Description>,<Location>,<CompanyName>,<HouseNumber>,<HouseN
umberSuffix>,<PreDirectional>,…<StreetName>,<StreetSuffix>,<PostDirectional>,<Cit
y>,<State>,<PostalCode>,<Country>
For the ELIN number to be included in the SIP INVITE (XML-based PIDF-LO message)
sent by the Mediation Server to the ELIN Gateway, the Administrator must add the ELIN
number to the <CompanyName> column (shown in the table above in bold typeface). As
the ELIN Gateway supports up to five ELINs per PIDF-LO, the <CompanyName> column
can be populated with up to this number of ELINs, each separated by a semicolon. The
digits of each ELIN can be separated by hyphens (xxx-xxx-xxx) or they can be adjacent
(xxxxxxxxx).
When the ELIN Gateway receives the SIP INVITE, it extracts the ELINs from the NAM field
in the PIDF-LO (e.g., <ca:NAM>1111-222-333; 1234567890 </ca:NAM>), which
corresponds to the <CompanyName> column of the LIS.
If you do not populate the location database, and the Lync Server 2010 location policy,
Location Required is set to Yes or Disclaimer, the user will be prompted to enter a location
manually.
26.11.4.2.3
Passing Location Information to the PSTN Emergency Provider
When a Lync 2010 client, enabled for E9-1-1 emergency services, dials 9-1-1, the location
data and callback information stored on the client is sent with the call through the Mediation
Server to a PSTN-based Emergency Services provider. The Emergency Services provider
then routes the call to the nearest and most appropriate PSAP based on the location
information contained within the call.
Lync Server 2010 passes the location information of the Lync 2010 client in an IETFstandard format - Presence Information Data Format - Location Object (PIDF-LO)–in a SIP
INVITE message. However, this content cannot be sent on the PSTN network using ISDN
PRI due to protocol limitations. To overcome this, Enterprises using PSTN Gateways can
divide their office space into Emergency Response Locations (ERLs) and assign a
User's Manual
438
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
dedicated Emergency Location Identification Number (ELIN) to each ERL (or zone). When
Lync Server 2010 sends a SIP INVITE message with the PIDF-LO to the PSTN Gateway, it
can parse the content and translate the calling number to an appropriate ELIN. The PSTN
Gateway then sends the call to the PSTN with the ELIN number as the calling number.
This ELIN number is sent to the Emergency Services provider, which sends it on to the
appropriate PSAP according to the ELIN address match in the ALI database lookup.
The ERL defines a specific location at a street address, for example, the floor number of
the building at that address. The geographical size of an ERL is according to local or
national regulations (for example, less than 7000 square feet per ERL). Typically, you
would have an ERL for each floor of the building. The ELIN is used as the phone number
for 911 callers within this ERL.
The figure below illustrates the use of ERLs and ELINs, with an E9-1-1 call from floor 2 at
the branch office:
Figure 26-7: Implementing ERLs and ELINs for E9-1-1 in Lync Server 2010
The table below shows an example of designating ERLs to physical areas (floors) in a
building and associating each ERL with a unique ELIN.
Table 26-5: Designating ERLs and Assigning to ELINs
ERL Number
Physical Area
IP Address
ELIN
1
Floor 1
10.13.124.xxx
503 972-4410
2
Floor 2
10.15.xxx.xxx
503 972-4411
3
Floor 3
10.18.xxx.xxx
503 972-4412
Version 6.8
439
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
In the table above, a unique IP subnet is associated per ERL. This is useful if you
implement different subnets between floors. Therefore, IP phones, for example, on a
specific floor are in the same subnet and therefore, use the same ELIN when dialing 9-1-1.
26.11.4.3
AudioCodes ELIN Gateway for Lync Server 2010 E9-1-1 Calls to
PSTN
The Microsoft Mediation Server sends the location information of the E9-1-1 caller in the
XML-based PIDF-LO body contained in the SIP INVITE message. However, this content
cannot be sent on the PSTN network using ISDN PRI due to protocol limitations. To solve
this issue, Lync Server 2010 requires a PSTN Gateway (ELIN Gateway) to send the E9-1-1
call to the PSTN. When Lync Server 2010 sends the PIDF-LO to the PSTN Gateway, it
parses the content and translates the calling number to an appropriate ELIN. This ensures
that the call is routed to an appropriate PSAP, based on ELIN-address match lookup in the
Emergency Services provider's ALI database.
The figure below illustrates an AudioCodes ELIN Gateway deployed in the Lync Server
2010 environment for handling E9-1-1 calls between the Enterprise and the PSTN.
Figure 26-8: AudioCodes ELIN Gateway for E9-1-1 in Lync Server 2010 Environment
26.11.4.3.1
Detecting and Handling E9-1-1 Calls
The ELIN Gateway identifies E9-1-1 calls and translates their incoming E9-1-1 calling
numbers into ELIN numbers, sent toward the PSAP. The ELIN Gateway handles the
received E9-1-1 calls as follows:
1.
The ELIN Gateway identifies E9-1-1 calls if the incoming SIP INVITE message
contains a PIDF-LO XML message body. This is indicated in the SIP Content-Type
header, as shown below:
Content-Type: application/pidf+xml
2.
The ELIN Gateway extracts the ELIN number(s) from the "NAM" field in the XML
message. The "NAM" field corresponds to the <CompanyName> column in the
Location Information Server (LIS). The ELIN Gateway supports up to five ELIN
numbers per XML message. The ELINs are separated by a semicolon. The digits of
the ELIN number can be separated by hyphens (xxx-xxx-xxx) or they can be adjacent
(xxxxxxxxx), as shown below:
<ca:NAM>1111-222-333; 1234567890 </ca:NAM>
User's Manual
440
Document #: LTRT-27034
User's Manual
3.
26. Configuring Supplementary Services
The ELIN Gateway saves the From header value of the SIP INVITE message in its
ELIN database table (Call From column). The ELIN table is used for PSAP callback,
as discussed later in ''PSAP Callback to Lync 2010 Clients for Dropped E9-1-1 Calls''
on page 443. The ELIN table also stores the following information:
•
ELIN: ELIN number
•
Time: Time at which the original E9-1-1 call was terminated with the PSAP
•
Count: Number of E9-1-1 calls currently using this ELIN
An example of the ELIN database table is shown below:
ELIN
Time
Count
Index
Call From
4257275678
22:11:52
0
2
4258359333
4257275999
22:11:57
0
3
4258359444
4257275615
22:12:03
0
0
4258359555
4257275616
22:11:45
0
1
4258359777
The ELIN table stores this information for a user-defined period (see ''Configuring the
E9-1-1 Callback Timeout'' on page 444), starting from when the E9-1-1 call,
established with the PSAP, terminates. After this time expires, the table entry with its
ELIN is disregarded and no longer used (for PSAP callback). Therefore, table entries
of only the most recently terminated
E9-1-1 callers are considered in the ELIN table.
The maximum entries in the ELIN table depend on the AudioCodes ELIN Gateway
deployed in the Lync Server 2010 environment:
4.
•
Mediant 1000 Series and Mediant 2000: 100 entries
•
Mediant 3000: 300 entries
The ELIN Gateway uses the ELIN number as the E9-1-1 calling number and sends it
in the ISDN Setup message (as an ANI / Calling Party Number) to the PSTN.
An example of a SIP INVITE message received from an E9-1-1 caller is shown below. The
SIP Content-Type header indicating the PIDF-LO, and the NAM field listing the ELINs are
shown in bold typeface.
INVITE sip:911;phone-context=Redmond@192.168.1.12;user=phone
SIP/2.0
From:
"voip_911_user1"<sip:voip_911_user1@contoso.com>;epid=1D19090AED;t
ag=d04d65d924
To: <sip:911;phone-context=Redmond@192.168.1.12;user=phone>
CSeq: 8 INVITE
Call-ID: e6828be1-1cdd-4fb0-bdda-cda7faf46df4
VIA: SIP/2.0/TLS 192.168.0.244:57918;branch=z9hG4bK528b7ad7
CONTACT:
<sip:voip_911_user1@contoso.com;opaque=user:epid:R4bCDaUj51a06PUbk
raS0QAA;gruu>;text;audio;video;image
PRIORITY: emergency
CONTENT-TYPE: multipart/mixed; boundary= -----=_NextPart_000_4A6D_01CAB3D6.7519F890
geolocation: <cid:voip_911_user1@contoso.com>;insertedby="sip:voip_911_user1@contoso .com"
Message-Body:
------=_NextPart_000_4A6D_01CAB3D6.7519F890
Content-Type: application/sdp ; charset=utf-8
v=0
Version 6.8
441
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
o=- 0 0 IN IP4 Client
s=session
c=IN IP4 Client
t=0 0
m=audio 30684 RTP/AVP 114 111 112 115 116 4 3 8 0 106 97
c=IN IP4 172.29.105.23
a=rtcp:60423
a=label:Audio
a=rtpmap:3 GSM/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
------=_NextPart_000_4A6D_01CAB3D6.7519F890
Content-Type: application/pidf+xml
Content-ID: <voip_911_user1@contoso.com>
<?xml version="1.0" encoding="utf-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:bp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:ms="urn:schema:Rtc.LIS.msftE911PidfExtn.2008"
entity="sip:voip_911_user1@contoso.com"><tuple
id="0"><status><gp:geopriv><gp:locationinfo><ca:civicAddress><ca:country>US</ca:country><ca:A1>WA</ca:A1>
<ca:A3>Redmond</ca:A3><ca:RD>163rd</ca:RD><ca:STS>Ave</ca:STS><ca:
POD>NE</ca:POD><ca:HNO>3910</ca:HNO><ca:LOC>40/4451</ca:LOC>
<ca:NAM>1111-222-333; 1234567890 </ca:NAM>
<ca:PC>98052</ca:PC></ca:civicAddress></gp:locationinfo><gp:usage-rules><bp:retransmissionallowed>true</bp:retransmission-allowed></gp:usagerules></gp:geopriv><ms:msftE911PidfExtn><ms:ConferenceUri>sip:+142
55550199@contoso.com;user=phone</ms:ConferenceUri><ms:ConferenceMo
de>twoway</ms:ConferenceMode><LocationPolicyTagID
xmlns="urn:schema:Rtc.Lis.LocationPolicyTagID.2008">usertagid</LocationPolicyTagID
></ms:msftE911PidfExtn></status><timestamp>1991-0922T13:37:31.03</timestamp></tuple></presence>
------=_NextPart_000_4A6D_01CAB3D6.7519F890--
26.11.4.3.2
Pre-empting Existing Calls for E9-1-1 Calls
If the ELIN Gateway receives an E9-1-1 call from the IP network and there are unavailable
channels (for example, all busy), the ELIN Gateway immediately terminates one of the
non-E9-1-1 calls (arbitrary) and accepts the E9-1-1 call on the freed channel.
The preemption is done only on a channel pertaining to the same Trunk Group for which
the E9-1-1 call was initially destined. For example, if an E9-1-1 call is destined for Trunk
Group #2 and all the channels belonging to this group are busy, the ELIN Gateway
terminates one of the calls in this group to free a channel for accepting the E9-1-1 call.
This feature is initiated only if the received SIP INVITE message contains a Priority header
set to "emergency", as shown below:
PRIORITY: emergency
User's Manual
442
Document #: LTRT-27034
User's Manual
26.11.4.3.3
26. Configuring Supplementary Services
PSAP Callback to Lync 2010 Clients for Dropped E9-1-1 Calls
As the E9-1-1 service automatically provides all the contact information of the E9-1-1 caller
to the PSAP, the PSAP operator can call back the E9-1-1 caller. This is especially useful in
cases where the caller disconnects prematurely. However, as the Enterprise sends ELINs
to the PSAP for E9-1-1 calls, a callback can only reach the original E9-1-1 caller using the
ELIN Gateway to translate the ELIN number back into the E9-1-1 caller's extension
number.
In the ELIN table of the ELIN Gateway, the temporarily stored From header value of the
SIP INVITE message originally received from the E9-1-1 caller is used for PSAP callback.
When the PSAP makes a callback to the E9-1-1 caller, the ELIN Gateway translates the
called number (i.e., ELIN) received from the PSAP to the corresponding E9-1-1 caller's
extension number as matched in the ELIN table.
The handling of PSAP callbacks by the ELIN Gateway is as follows:
1.
When the ELIN Gateway receives any call from the PSTN, it searches the ELIN table
for an ELIN that corresponds to the received Called Party Number in the incoming
PSTN call.
2.
If a match is found in the ELIN table, it routes the call to the Mediation Sever by
sending a SIP INVITE, where the values of the To and Request-URI are taken from
the value of the original From header that is stored in the ELIN table (in the Call From
column).
3.
The ELIN Gateway updates the Time in the ELIN table. (The Count is not affected).
The PSAP callback can be done only within a user-defined timeout (see ''Configuring the
E9-1-1 Callback Timeout'' on page 444) started from after the original E9-1-1 call
established with the PSAP is terminated. After this time expires, the table entry with its
ELIN is disregarded and no longer used (for PSAP callback). Therefore, table entries of
only the most recently terminated
E9-1-1 callers are considered in the ELIN table. If the PSAP callback is done after this
timeout expires, the ELIN Gateway is unable to route the call to the E9-1-1 caller and
instead, either sends it as a regular call or most likely, rejects it if there are no matching
routing rules. However, if another E9-1-1 caller has subsequently been processed with the
same ELIN number, then the PSAP callback is routed to this new E9-1-1 caller.
In scenarios where the same ELIN number is being used by multiple E9-1-1 callers, upon
receipt of a PSAP callback, the ELIN Gateway sends the call to the most recent E9-1-1
caller. For example, if the ELIN number "4257275678" is being used by three E9-1-1
callers, as shown in the table below, then when a PSAP callback is received, the ELIN
Gateway sends it to the E9-1-1 caller with phone number "4258359555".
Table 26-6: Choosing Caller of ELIN
ELIN
Time
Call From
4257275678
11:00
4258359333
4257275678
11:01
4258359444
4257275678
11:03
4258359555
26.11.4.3.4
Selecting ELIN for Multiple Calls within Same ERL
The ELIN Gateway supports the receipt of up to five ELIN numbers in the XML message of
each incoming SIP INVITE message. As discussed in the preceding sections, the ELIN
Gateway sends the ELIN number as the E9-1-1 calling number to the PSTN-based
emergency provider. If the XML message contains more than one ELIN number, the ELIN
Gateway chooses the ELIN according to the following logic:
Version 6.8
443
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC

If the first ELIN in the list is not being used by other active calls, it chooses this ELIN.

If the first ELIN in the list is being used by another active call, the ELIN Gateway skips
to the next ELIN in the list, and so on until it finds an ELIN that is not being used and
sends this ELIN.

If all the ELINs in the list are in use by active calls, the ELIN Gateway selects the ELIN
number as follows:
1.
The ELIN with the lowest count (i.e., lowest number of active calls currently using
this ELIN).
2. If the count between ELINs is identical, the ELIN Gateway selects the ELIN with
the greatest amount of time passed since the original E9-1-1 call using this ELIN
was terminated with the PSAP. For example, if E9-1-1 caller using ELIN
4257275678 was terminated at 11:01 and E9-1-1 caller using ELIN 4257275670
was terminated at 11:03, then the ELIN Gateway selects ELIN 4257275678.
In this scenario, multiple E9-1-1 calls will be sent with the same ELIN.
26.11.4.3.5
Location Based Emergency Routing
The device supports location-based emergency routing (E-911) in Lync Server 2010. This
ensures that E-911 calls from remote branches are routed to emergency providers that are
relevant to the geographical area in which the remote branch callers are physically located.
To support this, the device enables routing and SIP header / number manipulation of such
emergency calls based on the geographical location of the caller. The device manipulates
the received destination number (i.e., 911) from the remote branch callers, into a
destination number of an emergency provider that is relevant to the geographical area in
which the remote branch office is located.
26.11.4.4
Configuring AudioCodes ELIN Gateway
This section describes E9-1-1 configuration of the AudioCodes ELIN Gateway deployed in
the Lync Server 2010 environment.
26.11.4.4.1
Enabling the E9-1-1 Feature
By default, the E9-1-1 feature in the ELIN Gateway for Lync Server 2010 is disabled. To
enable it, the following ini file parameter setting must be done:
E911Gateway = 1
26.11.4.4.2
Configuring the E9-1-1 Callback Timeout
The PSAP can use the ELIN to call back the E9-1-1 caller within a user-defined time
interval (in minutes) from when the initial call established with the PSAP has been
terminated. By default, an ELIN can be used for PSAP callback within 30 minutes after the
call is terminated. You can change this interval, by using the following ini file parameter:
E911CallbackTimeout = <time value>
; where <time value > can be
any value from 0 through 60
26.11.4.4.3
Configuring the SIP Release Cause Code for Failed E9-1-1 Calls
When a Lync 2010 client makes an emergency call, the call is routed through the Microsoft
Mediation Server to the ELIN Gateway, which sends it on to the PSTN. In some scenarios,
the call may not be established due to either the PSTN (for example, the destination is
busy or not found) or ELIN Gateway (for example, lack of resources or an internal error). In
such a scenario, the Mediation Server requires that the ELIN Gateway "reject" the call with
the SIP release cause code 503 "Service Unavailable" instead of the designated release
call. Such a release cause code enables the Mediation Server to issue a failover to another
User's Manual
444
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
entity (for example, another ELIN Gateway), instead of retrying the call or returning the
release call to the user.
To support this requirement, the ELIN Gateway can be configured to send the 503 "Service
Unavailable" release cause code instead of SIP 4xx if an emergency call cannot be
established. To enable this support, the following ini file parameter setting must be done:
Note: This can also be configured
EmergencySpecialReleaseCause.
using
the
ini
file
parameter,
 To enable SIP response 503 upon failed E911:
1.
Open the Advanced Parameters page (Configuration tab > VoIP menu > SIP
Definitions > Advanced Parameters).
2.
From the 'Emergency Special Release Cause' drop-down list, select Enable.
26.11.4.4.4
Configuring Location-Based Emergency Routing
The device identifies the geographical location of emergency callers by their ELIN
numbers, which is present in the PIDF-LO XML body of received SIP INVITE messages.
Therefore, you need to configure the device to route emergency calls to a destination (i.e.,
emergency center such as police) that is appropriate to the caller's ELIN number. As the
destination of incoming calls is the emergency number (e.g., 999), the device needs to
manipulate the destination number to a number that represents the caller's local
emergency center (e.g., +4420999 for London police).
To add manipulation rules for location-based emergency routing, you need to use the
Destination Phone Number Manipulation Table for IP-to-Tel Calls table. In this table, you
need to use the ELIN number (e.g., 5000) as the source prefix, with the "ELIN" string value
added in front of it (e.g., ELIN5000) which is used internally by the device to identify the
number as an ELIN number (and not used for any other routing processes etc.). For each
corresponding ELIN source number prefix entry, you need to configure the manipulation
action required on the destination number so that the call is routed to the appropriate
destination.
Following is an example of how to configure location-based emergency routing:


Version 6.8
Assumptions:
•
Company with offices in different cities -- London and Manchester.
•
Each city has its local police department.
•
In an emergency, users need to dial 999.
•
Company employs Microsoft Lync for communication between employers, and
between employers and the external telephone network (PSTN). In other words,
all employers are seemingly (virtual) in the same location in respect to the IP
network.
•
ELIN numbers are used to identify the geographical location of emergency calls
dialed by users:
♦
London ELIN is 5000.
♦
Manchester ELIN is 3000.
Configuration Objectives:
•
Emergency calls received from London office users are routed by the device to
the London police department, which is +4420999.
•
Emergency calls received from Manchester office users are routed by the device
to the Manchester police department, which is +44161999.
445
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The international code, +44 for England is used for IP routing considerations, but can
be omitted depending on your specific network environment.
The above example scenario is configured as follows:
1.
Enable location-based emergency routing, by loading an ini file to the device with the
following parameter setting:
E911Gateway = 2
2.
In the Destination Phone Number Manipulation Table for IP-to-Tel Calls
(Configuration tab > VoIP menu > GW and IP to IP > Manipulations > Dest
Number IP->Tel), add the following two rules for manipulating the destination number
of incoming emergency calls, based on ELIN numbers:
Figure 26-9: Destination Number Manipulation Rules for Location-Based Emergency Routing
Index 0 manipulates the destination number for London emergency callers; Index 1
manipulates the destination number for Manchester emergency callers.
26.11.4.4.5
Viewing the ELIN Table
You can view the ELIN table of the ELIN Gateway:

Using the following CLI command:
# show voip gw e911
ELIN
Time
Count Index Call From
-----------------------------------------------------------4257275678
22:11:52 0 2 4258359333
4257275999
22:11:57 0 3 4258359444
4257275615
22:12:03 0 0 4258359555
4257275616
22:11:45 0 1 4258359777
------------ Current Time: 22:12:40

User's Manual
Using Syslog, by invoking the following Web command shell:
SIP / GateWay / E911Dump
446
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
26.12 Multilevel Precedence and Preemption
The device supports Multilevel Precedence and Preemption (MLPP) service. MLPP is a
call priority scheme, which does the following:

Assigns a precedence level (priority level) to specific phone calls or messages.

Allows higher priority calls (precedence call) and messages to preempt lower priority
calls and messages (i.e., terminates existing lower priority calls) that are recognized
within a user-defined domain (MLPP domain ID). The domain specifies the collection
of devices and resources that are associated with an MLPP subscriber. When an
MLPP subscriber that belongs to a particular domain places a precedence call to
another MLPP subscriber that belongs to the same domain, MLPP service can
preempt the existing call that the called MLPP subscriber is on for a higherprecedence call. MLPP service availability does not apply across different domains.
MLPP is typically used in the military where, for example, high-ranking personnel can
preempt active calls during network stress scenarios such as a national emergency or
degraded network situations.
MLPP can be enabled for all calls, using the global parameter, CallPriorityMode, or for
specific calls using the Tel Profile parameter, CallPriorityMode.
Notes:
• MLPP is supported on ISDN PRI and BRI interfaces.
• The device provides MLPP interworking between SIP and ISDN (both directions).
• For Trunk Groups configured with call preemption, all must be configured to MLPP
[1] or all configured to Emergency [2]. In other words, you cannot set some trunks
to [1] and some to [2].
• The global parameter must be set to the same value as that of the Tel Profile
parameter; otherwise, the Tel Profile parameter is not applied.
• If you configure call preemption using the global parameter and a new Tel Profile
is subsequently added, the TelProfile_CallPriorityMode parameter automatically
acquires the same setting as well.
The Resource Priority value in the Resource-Priority SIP header can be any one of those
listed in the table below. A default MLPP call Precedence Level (configured by the
SIPDefaultCallPriority parameter) is used if the incoming SIP INVITE or PRI Setup
message contains an invalid priority or Precedence Level value respectively. For each
MLPP call priority level, the Multiple Differentiated Services Code Points (DSCP) can be
set to a value from 0 to 63.
Table 26-7: MLPP Call Priority Levels (Precedence) and DSCP Configuration Parameters
MLPP Precedence Level
Precedence Level in ResourcePriority SIP Header
DSCP Configuration Parameter
0 (lowest)
routine
MLPPRoutineRTPDSCP
2
priority
MLPPPriorityRTPDSCP
4
immediate
MLPPImmediateRTPDSCP
6
flash
MLPPFlashRTPDSCP
8
flash-override
MLPPFlashOverRTPDSCP
9 (highest)
flash-override-override
MLPPFlashOverOverRTPDSCP
Version 6.8
447
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
The device automatically interworks the network identity digits (NI) in the ISDN Q.931
Precedence Information Element (IE) to the network domain subfield of the INVITE's
Resource-Priority header, and vice versa. The SIP Resource-Priority header contains two
fields, namespace and priority. The namespace is subdivided into two subfields, networkdomain and precedence-domain. Below is an example of a Resource-Priority header
whose network-domain subfield is "uc", r-priority field is "priority" (2), and precedencedomain subfield is "000000":
Resource-Priority: uc-000000.2
The MLPP Q.931 Setup message contains the Precedence IE. The NI digits are presented
by four nibbles found in octets 5 and 6. The device checks the NI digits according to the
translation table of the Department of Defense (DoD) Unified Capabilities (UC)
Requirements (UCR 2008, Changes 3) document, as shown below:
Table 26-8: NI Digits in ISDN Precedence
Level IE
Network Domain in SIP Resource-Priority Header
0000
uc
0001
cuc
0002
dod
0003
nato
Notes:
• If the received ISDN message contains NI digits that are not listed in the
translation table, the device sets the network-domain to "uc" in the outgoing SIP
message.
• If the received SIP message contains a network-domain value that is not listed in
the translation table, the device sets the NI digits to "0000" in the outgoing ISDN
message.
• If the received ISDN message does not contain a Precedence IE, you can
configure the namespace value - dsn (default), dod, drsn, uc, or cuc - in the SIP
Resource-Priority header of the outgoing INVITE message. This is done using the
MLPPDefaultNamespace parameter. You can also configure up to 32 user-defined
namespaces, using the table ini file parameter, ResourcePriorityNetworkDomains.
Once defined, you need to set the MLPPDefaultNamespace parameter value to
the desired table row index.
By default, the device maps the received Resource-Priority field of the SIP ResourcePriority header to the outgoing ISDN PRI Precedence Level (priority level) field as follows:

If the network-domain field in the Resource-Priority header is "uc", then the device
sets the Precedence Level field in the ISDN PRI Precedence Level IE according to
Table 5.3.2.12-4 (Mapping of RPH r-priority Field to PRI Precedence Level Value):
Table 26-9: Mapping of SIP Resource-Priority Header to PRI Precedence Level for MLPP
MLPP Precedence Level
PRI Precedence Level
SIP Resource-Priority Header Field
Routine
4
0
Priority
3
2
Immediate
2
4
Flash
1
6
Flash Override
0
8
User's Manual
448
Document #: LTRT-27034
User's Manual

26. Configuring Supplementary Services
If the network-domain field in the Resource-Priority header is any value other than
"uc", then the device sets the Precedence Level field to "0 1 0 0" (i.e., "routine").
This can be modified using the EnableIp2TelInterworkingtable field of the ini file parameter,
ResourcePriorityNetworkDomains.
Notes:
• If required, you can exclude the "resource-priority” tag from the SIP Require
header in INVITE messages for Tel-to-IP calls when MLPP priority call handling is
used. This is configured using the RPRequired parameter.
• For a complete list of the MLPP parameters, see ''MLPP and Emergency Call
Parameters'' on page 847.
26.12.1 MLPP Preemption Events in SIP Reason Header
The device sends the SIP Reason header (as defined in RFC 4411) to indicate the reason
and type of a preemption event. The device sends a SIP BYE or CANCEL request, or SIP
480, 486, 488 response (as appropriate) with a Reason header whose Reason-params can
includes one of the following preemption cause classes:

Reason: preemption ;cause=1 ;text=”UA Preemption”

Reason: preemption ;cause=2 ;text=”Reserved Resources Preempted”

Reason: preemption ;cause=3 ;text=”Generic Preemption”

Reason: preemption ;cause=4 ;text=”Non-IP Preemption”
This Reason cause code indicates that the session preemption has occurred in a nonIP portion of the infrastructure. The device sends this code in the following scenarios:

•
The device performs a network preemption of a busy call (when a high priority
call is received), the device sends a SIP BYE or CANCEL request with this
Reason cause code.
•
The device performs a preemption of a B-channel for a Tel-to-IP outbound call
request from the softswitch for which it has not received an answer response
(e.g., Connect), and the following sequence of events occurs:
a. The device sends a Q.931 DISCONNECT over the ISDN MLPP PRI to the
partner switch to preempt the remote end instrument.
b. The device sends a 488 (Not Acceptable Here) response with this Reason
cause code.
Reason: preemption; cause=5; text=”Network Preemption”
This Reason cause code indicates preempted events in the network. Within the
Defense Switched Network (DSN) network, the following SIP request messages and
response codes for specific call scenarios have been identified for signaling this
preemption cause:
•
SIP:BYE - If an active call is being preempted by another call
•
CANCEL - If an outgoing call is being preempted by another call
•
480 (Temporarily Unavailable), 486 (User Busy), 488 (Not Acceptable Here) Due to incoming calls being preempted by another call.
The device receives SIP requests with preemption reason cause=5 in the following
cases:
•
Version 6.8
The softswitch performs a network preemption of an active call - the following
sequence of events occurs:
a. The softswitch sends the device a SIP BYE request with this Reason cause
code.
449
Mediant 1000B Gateway & SBC
Mediant 1000B Gateway & SBC
b.
c.
•
The device initiates the release procedures for the B-channel associated
with the call request and maps the preemption cause to PRI Cause = #8
‘Preemption’. This value indicates that the call is being preempted. For PRI,
it also indicates that the B-channel is not reserved for reuse.
The device sends a SIP 200 OK in response to the received BYE, before the
SIP end instrument can proceed with the higher precedence call.
The softswitch performs a network preemption of an outbound call request for the
device that has not received a SIP 2xx response - the following sequence of
events occur:
a. The softswitch sends the device a SIP 488 (Not Acceptable Here) response
code with this Reason cause code. The device initiates the release
procedures for the B-channel associated with the call request and maps the
preemption cause to PRI Cause = #8 ‘Preemption’.
b. The device deactivates any user signaling (e.g., ringback tone) and when
the call is terminated, it sends a SIP ACK message to the softswitch.
26.12.2 Precedence Ring Tone
You can assign a ring tone that is defined in the CPT file to be played when a precedence
call is received from the IP side. This is configured by the PrecedenceRingingType
parameter. You can configure the duration for which the device plays a preemption tone to
the Tel and IP sides if a call is preempted, using the PreemptionToneDuration parameter.
Emergency Telecommunications Services (ETS) calls (e.g., E911) can be configured with
a higher priority than any MLPP call (default), using the E911MLPPBehavior parameter.
26.13 Denial of Collect Calls
You can configure the device to reject (disconnect) incoming Tel-to-IP collect calls and to
signal this denial to the PSTN. This capability is required, for example, in the Brazilian
telecommunication system to deny collect calls. When this feature is enabled upon
rejecting the incoming call, the device sends a sequence of signals to the PSTN. This
consists of an off-hook, an on-hook after one second, and then an off-hook after two
seconds. In other words, this is in effect, a double-answer sequence.
This feature can be enabled for all calls, using the EnableFXODoubleAnswer "global"
parameter, or it can be enabled for specific calls, by enabling this feature in a Tel Profile.
Notes:
• This feature is applicable only to FXO interfaces.
• If automatic dialing is also configured for an FXO port enabled with Denial of
Collect Calls, the FXO line does not answer the incoming call (ringing) until a SIP
200 OK is received from the remote destination. When a 200 OK is received, a
double answer is sent from the FXO line.
• Ensure that the PSTN side is configured to identify this double-answer signal.
User's Manual
450
Document #: LTRT-27034
User's Manual
26. Configuring Supplementary Services
26.14 Configuring Multi-Line Extensions and
Supplementary Services
The Supplementary Services table lets you configure up to 100 supplementary services for
endpoints connected to the device. These endpoints include analog FXS phones and
Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) phones. This table
lets you configure multiple phone line extension numbers per FXS/BRI port. Thus, this
offers support for point-to-multipoint configuration of several phone numbers per FXS/BRI
channel.
For each line extension, you can also configure the following:

User ID and password for registering the endpoint to a third-party softswitch for
authentication and/or billing. For viewing registration status, see ''Viewing Endpoint
Registration Status'' on page 649.

Caller ID name that is displayed to the dialed destination, if enabled.

Enable the receipt of caller ID from incoming calls.
The Supplementary Services table can also be used to to route IP-to-Tel calls (including
voice and fax) to specific endpoints based on the called line extension number. To enable
this functionality, in the Trunk Group Settings, set the 'Channel Select Mode' field to Select
Trunk by Supplementary Services Table for the Trunk Group to which the FXS/BRI port
belongs (see ''Configuring Trunk Group Settings'' on page 353).
Note: To allow the end-user to hear a dial tone when picking up the BRI phone, it is
recommended to set the Progress Indicator in the Setup Ack bit (0x10000=65536).
Therefore, the recommended value is 0x10