Release Notes. Version 6.0

Release Notes Version 6.0 Document #: LTRT-69017 February 2010

SIP Release Notes Contents Table of Contents 1 What's New in Release 6.0... 9 1.1 Supported Hardware Platforms... 9 1.1.1 New Models and Hardware Configurations Introduced in this Release... 9 1.1.2 Existing Hardware Platforms... 9 1.1.3 Hardware Platforms No Longer Supported... 10 1.2 SIP New Features... 10 1.3 B2BUA Transcoding New Feature... 29 1.3.1 SIP Network Definitions... 29 1.3.1.1 Signaling Routing Domain (SRD) Entities... 29 1.3.1.2 SIP Interfaces... 30 1.3.1.3 Media Realm... 31 1.3.2 SIP Dialog Initiation Process... 32 1.3.2.1 Determining Source and Destination URL... 33 1.3.2.2 Source IP Group Classification... 33 1.3.2.3 IP-to-IP Routing... 35 1.3.2.4 IP-to-IP Inbound and Outbound Manipulation... 36 1.3.3 Media Handling... 38 1.3.3.1 Media Anchoring without Transcoding (Transparent)... 39 1.3.3.2 Media Anchoring with Transcoding... 40 1.3.3.3 Transcoding Modes... 41 1.4 Voice, RTP and RTCP New Features... 42 1.5 Security New Features... 44 1.6 PSTN New Features... 45 1.7 Web New Features... 54 1.8 SNMP New Features... 56 1.9 Miscellaneous New Features... 57 1.10 New Parameters... 58 1.10.1 SIP Parameters... 58 1.10.2 B2BUA Transcoding Parameters... 71 1.10.3 Voice, RTP and RTCP Parameters... 78 1.10.4 Security Parameters... 80 1.10.5 PSTN Parameters... 82 1.10.6 Existing ini File Parameters Now Configurable in the Web... 84 1.11 Modified Parameters... 85 1.11.1 SIP Parameters... 85 1.11.2 Voice, RTP and RTCP Parameters... 95 1.11.3 PSTN Parameters... 96 1.12 Obsolete Parameters... 98 2 Supported Features... 99 2.1 SIP Features... 99 2.1.1 Supported SIP Features... 99 2.1.2 Unsupported SIP Features... 102 2.1.3 SIP Compliance Tables... 103 2.1.3.1 SIP Functions... 103 2.1.3.2 SIP Methods... 103 2.1.3.3 SIP Headers... 104 2.1.3.4 SDP Headers... 106 2.1.3.5 SIP Responses... 106 Version 6.0 3 February 2010

Mediant 2000 & Mediant 3000 2.2 PSTN to SIP Interworking... 111 2.2.1 Supported Interworking Features... 111 2.2.2 Interworking Features Not Supported... 112 2.3 DSP Firmware Templates... 112 2.4 Template Mix Feature... 116 2.5 Product Capability Comparison... 117 3 Known Constraints... 119 3.1 Voice, RTP and RTCP Constraints... 119 3.2 Infrastructure Constraints... 120 3.3 Networking Constraints... 121 3.4 Security Constraints... 121 3.5 High Availability Constraints... 121 3.6 PSTN Constraints... 122 3.7 Web Constraints... 123 3.8 SNMP Constraints... 124 3.9 CLI Constraints... 124 4 Resolved Constraints... 125 4.1 Voice, RTP and RTCP Resolved Constraints... 125 4.2 Web Resolved Constraints... 125 4.3 SNMP Resolved Constraints... 125 5 Earlier Releases... 127 SIP Release Notes 4 Document #: LTRT-69017

SIP Release Notes Contents List of Tables Table 1-1: New SIP Parameters for Release 6.0... 58 Table 1-2: New B2BUA Transcoding Parameters for Release 6.0... 71 Table 1-3: New Voice, RTP and RTCP Parameters for Release 6.0... 78 Table 1-4: New Security Parameters for Release 6.0... 80 Table 1-5: New PSTN Parameters for Release 6.0... 82 Table 1-6: ini File Parameters now Configurable in the Web Interface for Release 6.0... 84 Table 1-7: Modified SIP Parameters for Release 6.0... 85 Table 1-8: Modified Voice, RTP and RTCP Parameter for Release 6.0... 95 Table 1-9: Modified PSTN Parameter for Release 6.0... 96 Table 1-10: Obsolete Parameters... 98 Table 2-1: Supported SIP Functions... 103 Table 2-2: Supported SIP Methods... 103 Table 2-3: Supported SIP Headers... 104 Table 2-4: Supported SDP Headers... 106 Table 2-5: Supported 1xx SIP Responses... 107 Table 2-6: Supported 2xx SIP Responses... 107 Table 2-7: Supported 3xx SIP Responses... 108 Table 2-8: Supported 4xx SIP Responses... 108 Table 2-9: Supported 5xx SIP Responses... 110 Table 2-10: Supported 6xx SIP Responses... 110 Table 2-11: DSP Firmware Templates for Mediant 2000... 113 Table 2-12: DSP Firmware Templates for Mediant 3000... 114 Table 2-13: DSP Firmware Templates for Mediant 3000 16 E1 /21 T1... 115 Table 2-14: Template Mix Feature Channel Capacity... 116 Table 2-15: Capability Comparison between Devices... 117 Version 6.0 5 February 2010

Mediant 2000 & Mediant 3000 Reader s Notes SIP Release Notes 6 Document #: LTRT-69017

SIP Release Notes Notices Notice This document describes the release of the AudioCodes Mediant 2000 Voice-over-IP (VoIP) SIP media gateway (housing the TP-1610 blade) and Mediant 3000 VoIP SIP media gateway (housing the TP-6310 or TP-8410 TrunkPack (TP) SIP cpci blades). 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. Updates to this document and other documents can be viewed by registered customers at http://www.audiocodes.com/downloads. Copyright 2010 AudioCodes Ltd. All rights reserved. This document is subject to change without notice. Date Published: February-03-2010 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 Customer technical support and service are provided by AudioCodes Distributors, Partners, and Resellers from whom the product was purchased. For Customer support for products purchased directly from AudioCodes, contact support@audiocodes.com. Abbreviations and Terminology Each abbreviation, unless widely used, is spelled out in full when first used. Only industrystandard terms are used throughout this manual. Hexadecimal notation is indicated by 0x preceding the number. Version 6.0 7 February 2010

Mediant 2000 & Mediant 3000 Related Documentation Document Name Product Reference Manual for SIP CPE Devices Mediant 2000 SIP Installation Manual Mediant 2000 SIP User's Manual Mediant 3000 SIP User's Manual Mediant 3000 & IPmedia 3000 SIP-MGCP-MEGACO Installation Manual CPE SIP Configuration Guide for IP Voice Mail Notes: Throughout this manual, unless otherwise specified, the term device refers to the Mediant 2000 and Mediant 3000 media gateways. SIP Release Notes 8 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1 What's New in Release 6.0 Note: This document uses a one-row table with check boxes convention to indicate the products for which each feature is applicable. Only the products with marked check boxes are applicable to the feature. For example, the table below indicates that the feature is applicable only to Mediant 3000 High Availability (HA) housing the TP-6310. Mediant 2000 Mediant 3000 Mediant 3000 1.1 Supported Hardware Platforms 1.1.1 New Models and Hardware Configurations Introduced in this Release Not applicable. 1.1.2 Existing Hardware Platforms The following existing hardware platforms are supported in this release: Mediant 3000 system: 2U carrier-grade chassis, supporting multiple configuration options of VoP cpci blades: Mediant 3000 hosting a single TP-8410 blade, providing 16 E1/ 21 T1 PSTN interfaces. Mediant 3000 hosting a single TP-8410 blade, providing up to 63 E1/ 84 T1 PSTN interfaces. Mediant 3000 hosting two TP-8410 blades for 1+1 High Availability (HA), providing up to 16 E1/ 21 T1 PSTN interfaces. Mediant 3000 hosting two TP-8410 blades for 1+1 HA, providing up to 63 E1/ 84 T1 PSTN interfaces. Mediant 3000 hosting a single TP-6310 blade, providing SONET/SDH or T3 PSTN interfaces. Mediant 3000 hosting two TP-6310 blades for 1+1 HA, providing SONET/SDH or T3 PSTN interfaces. Mediant 3000 hosting a single TP-8410 blade providing 16 E1/ 21 T1 PSTN interfaces with an integrated CPU (Intel Pentium) blade (M3K-ICPU-1), hosting third-party applications (such as SS7 GWC). Mediant 3000 hosting a single TP-8410 blade providing up to 63 E1/ 84 T1 PSTN interfaces with an integrated CPU (Intel Pentium) blade (M3K-ICPU-1), hosting third-party applications (such as SS7 GWC). Mediant 2000 system: 1U chassis hosting a TP-1610 cpci blade with E1/T1 interfaces. Version 6.0 9 February 2010

Mediant 2000 & Mediant 3000 1.1.3 Hardware Platforms No Longer Supported Not applicable. 1.2 SIP New Features The device supports the following new SIP features: 1. Sending SIP Response to UDP Port from where SIP Request Received regardless of "rport" Parameter: Mediant 2000 Mediant 3000 Mediant 3000 In previous releases, the device sent SIP responses to the UDP port defined in the SIP Via header. If the Via header contained the "rport" parameter, the device sent the response to the UDP port from where the SIP request was received. In this release, the device can be configured (using the new parameter, SIPForceRport) to send SIP responses to the UDP port from where the SIP request was received even if the "rport" parameter is not received in the Via header. Relevant parameter: SIPForceRport. 2. Maximum Proxy Sets Increased to 10: Mediant 2000 Mediant 3000 Mediant 3000 The device now allows you to configure up to 10 Proxy Sets (compared to only 6 in previous releases). These are configured in the 'Proxy Sets' table (ProxySet). Relevant Parameter: ProxySet. 3. Offered Coders Increased to 10: Mediant 2000 Mediant 3000 Mediant 3000 4. The device now supports the configuration of up to 10 coders (compared to only 5 in the previous release) for offering the remote end. This also applies to Coder Groups, where up to 10 coders can now be defined per Coder Group (compared to only 5 in the previous release). In addition, a new parameter, CodersGroup now replaces the CoderName parameter (from previous versions). This new parameter supports backward compatibility, allowing users from previous versions to seamlessly upgrade to Version 6.0 (the coders defined under the CoderName parameter are transferred to the CodersGroup parameter). Relevant parameter: CodersGroup. SIP Release Notes 10 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameters Added to Tel Profile: Mediant 2000 Mediant 3000 Mediant 3000 The following parameters have now been added to the device's Tel Profile feature: 5. SwapTelToIpPhoneNumbers - representing the global parameter SwapTEl2IPCalled&CallingNumbers EnableAGC - representing the global parameter EnableAGC ECNlpMode - representing the global parameter ECNlpMode Relevant parameter: TelProfile. Trunk Groups Increased to 120: Mediant 2000 Mediant 3000 Mediant 3000 6. The device now supports the configuration of up to 120 Trunk Groups (compared to 24 for Mediant 2000, and 100 for Mediant 3000 in previous releases). The Trunk Group ID range has also been increased accordingly from 0-99 to 0-119. This increase is reflected in the Trunk Group (TrunkGroup) and Trunk Group Settings (TrunkGroupSettings) tables. Relevant parameters: TrunkGroup; TrunkGroupSettings. Trunk and Channel Cyclic Ascending for Channel Select Mode: Mediant 2000 Mediant 3000 Mediant 3000 7. The device now supports a new method - Trunk and Channel Cyclic Ascending - for allocating incoming IP-to-Tel calls to a trunk s B-channels. This method combines two existing methods: Cyclic Ascending and Trunk Cyclic Ascending. This method selects the next physical trunk (pertaining to the Trunk Group) and then selects the B-channel of this trunk according to the cyclic ascending method (i.e., selects the channel after the last allocated channel). For example, assume that a Trunk Group includes two physical trunks, 0 and 1: a. For the first incoming call, the first channel of Trunk 0 is allocated. b. For the second incoming call, the first channel of Trunk 1 is allocated. c. For the third incoming call, the second channel of Trunk 0 is allocated. Relevant parameters: ChannelSelectMode; TrunkGroupSettings. Version 6.0 11 February 2010

Mediant 2000 & Mediant 3000 Tel-to-IP Destination Number Manipulation Entries Increased to 120: Mediant 2000 Mediant 3000 Mediant 3000 8. The device now allows you to configure up to 120 Tel-to-IP destination number manipulation rules (compared to 100 in the previous release). These are configured in the 'Destination Phone Number Manipulation Table for Tel to IP Calls' table (NumberMapTel2IP). Relevant parameter: NumberMapTel2IP. IP-to-Tel Redirect Number Manipulation: Mediant 2000 Mediant 3000 Mediant 3000 9. The device now supports IP-to-Tel redirect number manipulation, configured using the new table, Redirect Number IP to Tel table. This feature allows you to manipulate the value of the received SIP Diversion, Resource-Priority, or History-Info header, which is then added to the Redirecting Number Information Element (IE) in the ISDN Setup message sent to the Tel side. Relevant parameter: RedirectNumberMapIp2Tel. Tel-to-IP Redirect Number Manipulation: Mediant 2000 Mediant 3000 Mediant 3000 10. The device now supports Tel-to-IP Redirect Number manipulation, configured using the new table, Redirect Number Tel to IP table. This feature allows you to manipulate the prefix of the redirect number received from the PSTN for the outgoing SIP Diversion, Resource-Priority, or History-Info header that is sent to IP. Relevant parameter: RedirectNumberMapTel2Ip. Routing IP-to-Tel Calls to Specific Trunk Groups According to CIC Parameter in Request URI: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports IP-to-Tel routing decisions based on the SIP carrier identification code ("cic") parameter. It uses the "cic" parameter in the incoming SIP INVITE message to route the call to a specific Trunk Group. The SIP carrier identification code (CIC) enables the transmission of the CIC parameter from the SIP network to the ISDN (CIC=+<country code of carrier><cic of preferred interlata carrier of caller>). The CIC parameter is a three- or four- digit code used in routing tables to identify the network that serves the remote user when a call is routed over many different networks. The CIC parameter is carried in SIP INVITE and maps to the ISDN Transit Network Selection Information Element (TNS IE) in the outgoing ISDN Setup message (if the EnableCIC parameter is set to 1). The TNS IE identifies the requested transportation networks and allows different providers equal access support, based on customer choice. SIP Release Notes 12 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 For supporting this new feature, this release introduces the new parameter, AddCicAsPrefix. When this parameter is enabled, the device adds the "cic" prefix to the destination number (for IP-to-Tel calls). For example: INVITE sip:5550001;cic=+16789@172.18.202.60:5060;user=phone SIP/2.0 11. After number manipulation performed by the device, the destination number results in "cic+167895550001". Note: After the cic prefix is added, the IP-to-Trunk Group Routing table can be used to route this call to a specific Trunk Group. The Destination Number IP to Tel Manipulation table must be used to remove this prefix before placing the call to the ISDN. Relevant parameter: AddCicAsPrefix. SIP "dtg" Parameter for Routing IP-to-Tel Calls to Trunk Groups: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the "dtg" parameter for defining the Trunk Group for routing IP-to-Tel calls. This parameter can be used instead of the "tgrp/trunk-context" parameters. The "dtg" parameter appears in the INVITE, for example: INVITE sip:123456@192.168.1.2;dtg=56;user=phone SIP/2.0 12. The "dtg" parameter also appears in the SIP To header. This feature is enabled by the new parameter, UseBroadsoftDTG (set to 1). If the Trunk Group is not found based on the "dtg" parameter, the IP to Trunk Group Routing table is used instead for routing the call to the appropriate Trunk Group. Relevant parameter: UseBroadsoftDTG. IP-to-Tel Routing Precedence using "tgrp"/"dtg" Parameters or IP to Trunk Group Table: Mediant 2000 Mediant 3000 Mediant 3000 In previous releases, IP-to-Tel routing was determined by the IP to Trunk Group Routing table (PSTNPrefix ini file parameter), and only if a matching rule was not found in this table did the device use the "tgrp"/"dtg" parameters for routing the call. However, in this release, you can change this priority so that the device first places precedence on the tgrp/dtg parameters for IP-to-Tel routing. If the received INVITE request URI does not contain the tgrp/dtg parameters, or if the Trunk Group number is not defined, then the IP to Trunk Group Routing table is used for routing the call. The IP-to-Tel Routing Precedence feature is enabled using a new parameter, TGRProutingPrecedence. If set to 1, the device performs routing according to the tgrp/dtg parameters. If set to 0 (default), the behavior is the same as in previous releases (first locates a match in the routing table and only if not found, attempts to route the call according to the tgrp parameter). Version 6.0 13 February 2010

Mediant 2000 & Mediant 3000 Below is an example of an INVITE request URI with the tgrp parameter, indicating that the IP call should be routed to Trunk Group 7: INVITE sip:200;tgrp=7;trunk-context=example.com@10.33.2.68;user=phone SIP/2.0 13. Note that the UseSIPTgrp parameter must be set to 2 for enabling routing based on the SIP tgrp parameter. Relevant parameters: UseSIPTgrp; TGRProutingPrecedence. IP-to-Tel Call Forwarding to IP Destination upon Busy Trunk Group: Mediant 2000 Mediant 3000 Mediant 3000 14. The device now supports the forwarding of IP-to-Tel calls to a different IP destination, using SIP 3xx response if a Trunk Group has no free channels (i.e., busy Trunk Group). This feature is configured using the new table, Forward On Busy Trunk Destination, which defines an alternative IP destination (IP address, port and transport type) per Trunk Group. The device forwards calls using this new table only if no alternative IP-to-Tel routing has been configured or alternative routing fails, and one of the following reasons (included in the SIP Diversion header of 3xx messages) exists: out-of-service - all trunks are unavailable/disconnected "unavailable" - all trunks are busy or unavailable Relevant parameter: ForwardOnBusyTrunkDest. Selecting SIP Header for IP-to-Tel Destination Number: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports selecting the SIP header for obtaining the called (destination) number (for IP-to-Tel calls). The device can be configured, using the new parameter SelectSourceHeaderForCalledNumber (replacing now obsolete IsUseToHeaderAsCalledNumber parameter), to use one of the following headers for obtaining the destination number: Request-URI (default) To P-Called-Party-ID Relevant parameters: SelectSourceHeaderForCalledNumber. SIP Release Notes 14 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 15. LDAP Support for Microsoft Active Directory Queries: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports Lightweight Directory Access Protocol (LDAP), allowing the device to make call routing decisions based on information stored on a third-party LDAP server (or Microsoft s Active Directory-based enterprise directory server). Therefore, this feature enables the usage of one common, popular database to manage and maintain information regarding user s availability, presence, and location. The LDAP feature can be configured using the ini file, Web interface, SNMP, and CLI (for debugging only). The device supports 20 for Mediant 2000 and 80 for Mediant 3000 LDAP search requests. Connection: The device connects and binds to the remote LDAP server either during the service s initialization (at device start-up) or whenever the LDAP server's IP address and port is changed. 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 either the LDAP server's IP address or port is changed. If connection to the LDAP server later fails, the service attempts to reconnect, as described previously. The SNMP alarm acldaplostconnection is sent when connection is broken. Upon successful reconnection, the alarm is cleared. Binding to the LDAP server can be anonymous or not. For anonymous binding, the LDAPBindDN and LDAPPassword parameters must not be defined or set to an empty string. The address of the LDAP server can be a DNS name (using the LDAPServerName parameter) or an IP address (using the LDAPServerIP parameter). Search: To run a search using the LDAP service, the path to the directory s subtree where the search is to be performed must be defined (using the LDAPSearchDN parameter). In addition, the search key (known as filter in LDAP references), which defines the exact DN to be found and one or more attributes whose values should be returned, must be defined. If connection to 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. Version 6.0 15 February 2010

Mediant 2000 & Mediant 3000 16. CLI: The LDAP CLI is located in the directory IPNetworking\OpenLdap. The following commands can be used: LdapSTatus - displays connection status LdapSearch - searches an LDAP server LDapOpen - opens connection to the LDAP server using parameters provided in configuration file LDapSetDebugmode - sets the LdapDebugLevelMode parameter LDapGetDebugmode gets the LdapDebugLevelMode parameter value Relevant parameters: LDAPServiceEnable; LDAPServerIP; LDAPServerDomainName; LDAPServerPort; LDAPPassword; LDAPBindDN; LDAPSearchDN; LDAPDebugMode; LDAPServerMaxRespondTime. Active Directory-Based Tel-to-IP Call Routing for Microsoft OCS 2007 Environment: Mediant 2000 Mediant 3000 Mediant 3000 Typically, enterprises wishing to deploy Microsoft s Office Communication Server 2007 (OCS 2007) are faced with a complex, call routing dial plan when migrating users from their existing PBX/IP-PBX to the OCS 2007 platform. As more and more end-users migrate to the new voice system, dialing plan management and PBX link capacity can be adversely impacted. Moreover, it s easy to perceive that even a temporary failure (or disconnection) of Microsoft s Office Communications Server 2007 Mediation Server (Mediation Server) results in no incoming voice calls from the PBX/IP-PBX/PSTN and therefore, it will be impossible to reach the user on the user s Microsoft Office Communicator (OC) client. This new feature enables the device to make Tel-to-IP call routing decisions based on information stored on Microsoft s Active Directory-based (AD) enterprise directory server. Therefore, this implements one common, central database to manage and maintain information regarding user s availability, presence, and location. Based on queries sent to the AD, this feature allows you to route incoming Tel calls to one of the following IP domains: PBX/IP-PBX (for users yet to migrate to the OCS 2007 platform) OCS clients (clients connected to the OCS 2007 platform) Mobile The device queries the AD using the destination number. The device's AD queries returns up to three user phone number IP destinations, each pertaining to one of the IP domains listed above. The device routes the call according to the following priority: OCS SIP address: Call is routed to Mediation Server (which then routes the call to the OCS client) Mobile number: If the Mediation Server or OCS client is unavailable (e.g., SIP response 404 "Not Found" upon INVITE sent to OCS client), the device routes the call to the user's mobile number (if exists in the AD). PBX/IP-PBX number: If no OCS client exits in the AD, then the device routes the call to the PBX/IP-PBX (if this fails, the call is routed to the mobile number, if exists). SIP Release Notes 16 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 For enterprises implementing a PBX/IP-PBX system but yet to migrate to the OCS 2007 platform, if the PBX/IP-PBX system is unavailable, the device queries the AD for the users mobile phone number and then routes the call through the PSTN to the mobile destination. This feature is configured in the Outbound IP Routing table, where the "LDAP" keywords are entered for the destination phone prefixes. For each IP domain (listed above), the destination numbers will be prefixed (case-sensitive) as follows: OCS client number: "OCS:" PBX number: "PBX:" Mobile number: "MOBILE:" LDAP failure: "LDAP_ERR:" Note that these prefixes are only involved in the routing and manipulation stages; they are not used as the final destination number. In addition, once you have configured the LDAP parameters (see previous feature), you need to enter the "LDAP" value for the destination IP address of the LDAP server in the Outbound IP Routing table. For enabling alternative routing, you need to enable the alternative routing mechanism and configure corresponding SIP reasons for alternative routing. For this feature, alternative routing always starts again from the top of the table (first routing rule entry) and not from the next row. This feature introduces three new parameters to configure the attribute names in the Active Directory used in the LDAP query: AD attribute for Mediation Server: MSLDAPOCSNumAttributeName (the default is "msrtcsipprimaryuseraddress") AD attribute for PBX/IP-PBX: MSLDAPPBXNumAttributeName (the default is "telephonenumber") AD attribute for mobile number: MSLDAPMobileNumAttributeName (the default is "mobile") Below is an example of configuring Active Directory-based routing rules in the Outbound IP Routing Table: First rule: sends call to IP-PBX (10.33.45.65) if AD query replies with prefix "PBX:" Second rule: sends call to OCS client (i.e., Mediation Server at 10.33.45.68) if AD query replies with prefix "OCS:" Third rule: sends call to users mobile phone number (to PSTN through the device's IP address, 10.33.45.100) if AD query replies with prefix "MOBILE:" Version 6.0 17 February 2010

Mediant 2000 & Mediant 3000 17. Fourth rule: sends call to IP address of device (e.g., 10.33.45.80) if no response from LDAP server Fifth rule: sends query of received Tel destination number to LDAP server and then routes the call according to query reply and routing rules at top of table Sixth rule: if LDAP functionality is not enabled, routes calls to IP address 10.33.45.72 Therefore, once the device receives the incoming Tel call, the first rule that it uses is the fifth rule, 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., "PBX:", "OCS:", "MOBILE:", and "LDAP_ERR:"), and then sends the call to the appropriate destination. Relevant parameters: MSLDAPOCSNumAttributeName; MSLDAPPBXNumAttributeName; MSLDAPMobileNumAttributeName. MLPP Preemption Events in SIP Reason Header - "preemption; cause=4" Instead of "preemption; cause=3": Mediant 2000 Mediant 3000 Mediant 3000 18. Preemption ensures that existing calls of lower priority are terminated in order to accept higher priority calls. The SIP Reason header indicates the reason a preemption event occurred and the type of preemption event. Non-IP Preemption indicates that the session preemption has occurred in a non-ip portion of the infrastructure, and this is the Reason cause code given by the SIP device. In the previous release, the device sent a SIP BYE or CANCEL request, or 480, 486, 488 responses (as appropriate) with a Reason header whose reason-params contained the value preemption; cause=3; text=" Generic Preemption. However, in this release, according to Unified Capabilities Requirements 2008 (UCR 2008), the Reason header instead includes Reason: preemption ;cause=4 ;text= Non-IP Preemption, in the following scenarios: Whenever 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 a Reason header whose Reason-params has the value preemption ;cause=4 ;text= Non-IP Preemption, instead of cause=3. Whenever 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), then 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 that includes a Reason header whose Reason-params contains the value preemption; cause=4; text= Non-IP Preemption (instead of cause=3). SIP Release Notes 18 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 SIP Reason Header (Reason: preemption; cause=5; text= Network Preemption ) for MLPP Preemption Network Events (RFC 4411): Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the SIP Reason header (as defined by RFC 4411) to support the signaling of preemption-related events in the network. A new preemption cause class is defined along with five cause values for the new cause class. 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 Reason: preemption; cause=5; text= Network Preemption Within the DSN network, the following SIP request messages and response codes for specific call scenarios have been identified for signaling this new class of preemption causes: SIP:BYE - If an active call is being preempted by another call CANCEL - If an outgoing call is being preempted by another call 1. 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: 2. Whenever 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 a Reason header whose Reason-params contain the value preemption; cause=5; text= Network Preemption. b. 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. c. 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. Whenever 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 a Reason header whose Reason-params contain the value preemption;cause=5; text= Network Preemption. 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. Version 6.0 19 February 2010

Mediant 2000 & Mediant 3000 19. Same SIP Resource-Priority Header in Subsequent Re-INVITEs for MLPP: Mediant 2000 Mediant 3000 Mediant 3000 The device now sends a 403 Forbidden response upon receipt of a Re-INVITE whose Resource-Priority header is different to that received in the initial INVITE. This is for MLPP calls in the IP-to-Tel direction. 20. Invalid SIP Resource-Priority Header for MLPP: Mediant 2000 Mediant 3000 Mediant 3000 When the device receives an unknown (invalid) Network-Domain in the SIP Resource- Priority header, the Network-Domain is changed to "dsn" and the r-priority is set to 0. The precedence-domain remains as the original. In other words, the device sends the following namespace: dsn-<original precedence-domain>.0. 21. Warning Header Included in 488 Response for Rejected MLPP Calls: Mediant 2000 Mediant 3000 Mediant 3000 22. The device now rejects an MLPP call if a B-channel is unavailable to preempt, by sending a 488 (Not Acceptable Here) response code that includes a Warning header field with warning code 370 (Insufficient Bandwidth) to the softswitch serving the SIP entity. This warning code is added to the Warning header (and the MLPP call is subsequently rejected) in the following cases: If there are no preemptable resources to accommodate the new outbound precedence call request. Whenever the device performs a preemption of a B-channel for an outbound call (initiated from IP side) request for which it has not received a response (e.g. Connect) from the Tel side, then the following sequence occurs: a. The device sends an Q.931 DISCONNECT over the ISDN. b. The device sends to the IP side a 488 (Not Acceptable Here) response code that includes the Warning header field with the warning code. After sending the Q.931 SETUP related to the preempting call, the switch can reject the call by sending in a clearing message a cause of Precedence Call Blocked (Cause Value #46). Upon receipt of this cause, the device sends a 488 (Not Acceptable Here) response code that includes a Warning header field with warning code 370 (Insufficient Bandwidth) in order to perform precedence failure intercept announcement treatment. Note: When preempting a channel on ALERT state, the device rejects the MLPP call by sending a 480 response (not 488 and no Warning header is sent). SIP Release Notes 20 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Configurable MLPP Network Identifier: Mediant 2000 Mediant 3000 Mediant 3000 The device now allows you to configure the MLPP network identifier (for IP-to-ISDN calls), according to the UCR 2008 and ITU Q.955 specifications. This specifies that octets 5 and 6 of the MLPP ISDN PRI Precedence Level Information Element should represent the network identifier (international prefix). In previous releases, this was hard-coded to USA Telephony Country Code (TCC) 1. This network identifier is included in the Facility IE of the ISDN Setup message. The network identifier can be defined using the new parameter MLPPNetworkIdentifier. For example: MLPPNetworkIdentifier set to default (i.e., USA, 1): PlaceCall- MLPPNetworkID:0100 MlppServiceDomain:123abc, MlppPrecLevel:5 Fac(1c): 91 a1 15 02 01 05 02 01 19 30 0d 0a 01 05 0a 01 01 04 05 01 00 12 3a bc MLPPNetworkIdentifier set to 972: PlaceCall- MLPPNetworkID:7209 MlppServiceDomain:123abc, MlppPrecLevel:5 Fac(1c): 91 a1 15 02 01 08 02 01 19 30 0d 0a 01 05 0a 01 01 04 05 72 09 12 3a bc MLPPNetworkIdentifier set to 490: PlaceCall- MLPPNetworkID:9004 MlppServiceDomain:123abc, MlppPrecLevel:5 Fac(1c): 91 a1 15 02 01 0a 02 01 19 30 0d 0a 01 05 0a 01 01 04 05 90 04 12 3a bc Relevant parameter: MLPPNetworkIdentifier. 23. DSCP Based on Resource-Priority Header upon Receipt of SIP UPDATE: Mediant 2000 Mediant 3000 Mediant 3000 Upon receipt of the SIP UPDATE (with or without SDP), the device populates the Differentiated Service Code Point (DSCP) markings in the session media stream packets, based on the received precedence level from the SIP Resource-Priority header. 24. Version 6.0 21 February 2010

Mediant 2000 & Mediant 3000 Enhanced Call Forking Support: Mediant 2000 Mediant 3000 Mediant 3000 The device now allows the configuration of a timeout (in seconds) that is started once the first SIP 2xx response has been received for a User Agent when a proxy server performs call forking (proxy server forwards the INVITE to multiple SIP User Agents). The device sends a SIP ACK and BYE in response to any additional SIP 2xx received from the proxy within this timeout. Once this timeout elapses, the device ignores subsequent SIP 2xx responses. In addition, the number of supported forking calls per channel has been increased from 4 to 20. In other words, the device can now receive up to 20 forking responses from a single INVITE message. Relevant parameter: ForkingTimeOut. 25. Fake Retry-After Header: Mediant 2000 Mediant 3000 Mediant 3000 26. This feature enables the device to operate with proxy servers that do not include the Retry-After SIP header in SIP 503 (Service Unavailable) responses to indicate an unavailable service. The Retry-After header is used with the 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting SIP client. The value of this field can either be an HTTP-date or an integer number of seconds (in decimal) after the time of the response. The device maintains a list of available proxies, by using the Keep-Alive (KA) mechanism. The device checks the availability of proxies by sending SIP OPTIONS every KA timeout to all potential proxies. However, some third-party media servers reply to SIP OPTIONS even if they are unavailable. In such cases, the third-party server rejects the SIP INVITE, by sending a 503 (Service Unavailable) response. As a result, the device performs a failover and must periodically retry the availability of the server, by sending new calls to it to detect the possibility that the anomaly condition has been cleared. In previous releases, upon receipt of a SIP 503 response, the device discarded the call and the proxy remained in the live proxy list, since it responded to the device's SIP OPTIONS. Unless the 503 response included a Retry-After response-header, the device did not send new call to the proxy for a period specified in the header. Therefore, for third-party media servers that do not support the Retry-After responseheader, this release introduces a new parameter, FakeRetryAfter to resolve this issue. If this parameter is set to a positive value (in seconds), when the device receives a 503 response without a Retry-After response-header, it behaves as if the 503 response included a Retry-After response-header with the period specified by this parameter. If this parameter is set to zero, this "Fake Retry-After" feature is disabled. Relevant parameter: FakeRetryAfter. SIP Release Notes 22 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Increased Number of SIP URIs in Received 302 Contact Header: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the receipt of up to eight SIP Uniform Resource Identifiers (URIs) in the received 302 Contact header. This feature allows the device to handle the received redirection (302) response messages from the proxy with one or more contacts in one or more Contact headers (for example, Contact: a@audio.com, b@audio.com). The device uses the URIs in the Contact header, which could be one per Contact header or one Contact header could have multiple URIs, to formulate one or more new outbound call requests. 27. Early SIP 183 Response upon Receipt of INVITE: Mediant 2000 Mediant 3000 Mediant 3000 28. The device now supports sending a SIP 183 Session Progress response with SDP immediately upon receipt of an INVITE message. However, the device sends the RTP packets only after it receives an ISDN Progress, Alerting with Progress indicator, or Connect message from the PSTN. This feature is enabled by the new parameter, EnableEarly183 (when set to 1), and also by the existing parameter, EnableEarlyMedia (when set to 1). For example, if the device receives an ISDN Progress message, it starts sending RTP packets according to the initial negotiation without having to send the 183 response again. Therefore, this feature reduces clipping of early media. Relevant parameters: EnableEarly183; EnableEarlyMedia. Mapping Additional SIT Tones to Q.850 Causes: Mediant 2000 Mediant 3000 Mediant 3000 Until now, the device was capable of detecting and reporting the following Special Information Tones (SIT) types from the PSTN: SIT-NC (No Circuit found) SIT-IC (Operator Intercept) SIT-VC (Vacant Circuit - non-registered number) SIT-RO (Reorder - System Busy) These four SIT tones were mapped to Q.850 cause, using the SITQ850Cause parameter (set to 34, by default). In this release, the device now also supports the detection of an additional three SIT tones (which are detected as one of the above SIT tones): The NC* SIT tone - detected as NC The RO* SIT tone - detected as RO The IO* SIT tone - detected as VC Version 6.0 23 February 2010

Mediant 2000 & Mediant 3000 The device can now map each of these SIT tones to a Q.850 cause and then map them to SIP 5xx/4xx responses, using the parameters SITQ850CauseForNC, SITQ850CauseForIC, SITQ850CauseForVC, and SITQ850CauseForRO. Note that if these parameters are not used (default), the SIT specific tone is mapped according to the configuration of the SITQ850Cause parameter. The SIT tones and their frequency durations reported by the device are shown in the table below: Special Information Tones (SITs) Name Description First Tone Frequency Duration Second Tone Frequency Duration Third Tone Frequency Duration (Hz) (ms) (Hz) (ms) (Hz) (ms) NC No circuit found 985.2 380 1428.5 380 1776.7 380 IC Operator intercept 913.8 274 1370.6 274 1776.7 380 VC Vacant circuit (non registered number) 985.2 380 1370.6 274 1776.7 380 RO Reorder (system busy) 913.8 274 1428.5 380 1776.7 380 NC* - 913.8 380 1370.6 380 1776.7 380 RO* - 985.2 274 1370.6 380 1776.7 380 IO* - 913.8 380 1428.5 274 1776.7 380 Relevant parameters: SITQ850CauseForNC; SITQ850CauseForIC; SITQ850CauseForVC; SITQ850CauseForRO; SITQ850Cause. 29. IP-to-IP RTP Tunneling: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports IP-to-IP RTP tunneling. This feature is relevant only when transcoding is not required in the IP-to-IP path, and instead, a UDP-to-UDP path is used to forward RTP packets internally. In this mode, RTP events (i.e., Broken Connection, First Incoming Packet, and RTCP counters) are not generated. 30. Transcoding using Third-Party Call Control (RFC 4117): Mediant 2000 Mediant 3000 Mediant 3000 The device now supports RFC 4117 - Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) - providing transcoding services (i.e., acting as a transcoding server). This is implemented in scenarios where two SIP User Agents (UA) wish to establish a session, but do not have a common coder or media type. When such incompatibilities exist, the UAs need to invoke transcoding services to successfully establish the session. (Note that transcoding can also be performed using NetAnn according to RFC 4240.) To enable the RFC 4117 feature, this releases introduces a new parameter, EnableRFC4117Transcoding, which must be set to 1 (after which a device reset is required). SIP Release Notes 24 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 The 3pcc call flow is as follows: The device receives from one of the UAs, a single INVITE with an SDP containing two media lines. Each media represents the capabilities of each of the two UAs. The device needs to find a match for both of the media, and opens two channels with two different media ports to the different UAs. The device performs transcoding between the two voice calls. In the example below, the Application Server sends a special INVITE that consists of two media (m=) lines to perform transcoding between G.711 and G.729. m=audio 20000 RTP/AVP 0 c=in IP4 A.example.com m=audio 40000 RTP/AVP 18 c=in IP4 B.example.com Relevant parameter: EnableRFC4117Transcoding. 31. Forced Expiration (SIP Unregistration) using Contact Header Value "*": Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the removal of SIP UA registration bindings in a Registrar, according to RFC 3261. Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UAs should support this mechanism so that bindings can be removed before their expiration interval has passed. The REGISTER-specific Contact header field value of "*" applies to all registrations, but it can only be used if the Expires header field is present with a value of "0". Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record (AOR) without knowing their precise values. This feature is supported by the introduction of the new parameter, UnRegistrationMode. Relevant parameter: UnregistrationMode. 32. Hiding SIP Passwords: Mediant 2000 Mediant 3000 Mediant 3000 The device now hides configured SIP passwords. Passwords are configured in the 'Proxy & Registration' and 'Account Table' pages. Once you configure a password in the Web interface (and the Submit button is clicked), the Web GUI displays the entered password as an asterisk (*). If you load an ini file that includes a configured password, the Web GUI also displays it as an asterisk. When you save an ini file to a PC, the global parameter Password and its value are not displayed in the file. If a password is defined in a table ('Account Table'), the saved ini file displays the password value as an asterisk. Note: If the Password parameter has an asterisk as its value and is loaded to the device, it has no affect on the device's configuration (i.e., the existing value of the Password parameter is retained). Version 6.0 25 February 2010

Mediant 2000 & Mediant 3000 33. SRTP Option without SDP Capability Negotiation: Mediant 2000 Mediant 3000 Mediant 3000 In previous releases, the device supported two security modes (configured by the parameter MediaSecurityBehaviour): Mandatory mode: The device initiates encrypted calls, but if negotiation of the cipher suite fails, the call is terminated. Incoming calls that do not include encryption information are rejected. Preferable mode: The device initiates encrypted calls. If negotiation of the cipher suite fails, an un-encrypted call is established. Incoming calls that do not include encryption information are accepted (default). In this mode, the device initiates SDP with two media lines (m=) - one for RTP and one for SRTP. In this release, the device supports an additional mode, "Preferable - Single Media", also configured by the existing MediaSecurityBehaviour parameter. This mode is the same as the Preferable mode, except for the following differences: Instead of two "m=" lines in the suggested SDP, it uses only a single m= line. Instead of a media line with RTP/SAVP, it uses RTP/AVP. In addition, in this mode, if the remote SIP UA does not support SRTP, it ignores the crypto lines. An example of an SDP with one "m=" line and crypto, v=0 o=audiocodesgw 1772695605 1772695471 IN IP4 10.33.4.126 s=phone-call c=in IP4 10.33.4.126 t=0 0 m=audio 6000 RTP/AVP 4 0 70 96 a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:0 PCMU/8000 a=rtpmap:70 EG711A/8000 a=rtpmap:96 telephone-event/8000 a=fmtp:96 0-15 a=ptime:30 a=sendrecv a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9lxqem1/dgtln2ehp46jfuxrpgpxdwpu/bmsvu9l 2^31 a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:5orhfgojn8onjoorisznrcpegbhmv5d3ji9wqbp4 2^31 This feature can also be assigned to an IP Profile. Note that for this feature to be functional, the EnableMediaSecurity parameter must be set to 1. Relevant parameters: MediaSecurityBehaviour; IPProfile. SIP Release Notes 26 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 34. Retain Active Call's SRTP Key after Blade Switchover: Mediant 2000 Mediant 3000 Mediant 3000 The device now retains (uses) the same Secure Real-time Transport Protocol (SRTP) key of an active call after a blade switchover has occurred. In previous releases, the device changed SRTP keys in its offer or answer if a Re-INVITE was sent or received for an active call after switchover to the redundant blade. This sometimes resulted in one-way voice. 35. Sending Re-INVITE with New SRTP Key upon Receipt of 181 Response: Mediant 2000 Mediant 3000 Mediant 3000 The device now can be configured to send a Re-INVITE with a new SRTP key upon receipt of a SIP 181 response ("call is being forwarded"). This is in accordance with the UCR 2008 standard. If the device sends an INVITE with SDP and receives a 181 response, it changes the SRTP key by sending a Re-INVITE with a new SRTP key in its SDP. Relevant parameter: EnableRekeyAfter181. 36. Maximum SAS Registrations: Mediant 2000 Mediant 3000 Mediant 3000 The device now rejects additional SAS registrations for endpoints if the maximum number of registrations has been reached. For fully populated chassis, the device will not register more than 500 endpoints (i.e., the 501 endpoint registration will be rejected). For depopulated chassis configuration, the maximum SAS endpoint registrations is 2,000. 37. Interworking SAS behind NAT: Mediant 2000 Mediant 3000 Mediant 3000 Since SAS is implemented as a standard proxy, it s default behavior while relaying requests is as follows: Adds a new SIP Via header (with the SAS IP address) as the top-most Via header. Does not modify the original SIP Contact header. This default and standard proxy result in the top-most Via header and the Contact header to point to different hosts. However, some SBC s (e.g., ACME) require that incoming requests must point to the same host in the top-most Via header and the Contact header. For interoperability support with such an SBC, the device can now operate in a new mode that changes the Contact header so that it points to the SAS host, and therefore, the top-most Via header and the Contact header point to the same host. Version 6.0 27 February 2010

Mediant 2000 & Mediant 3000 Note that operating in this mode causes all incoming dialog requests to traverse the SAS, and thus, may cause load problems. Parameter: SASEnableContactReplace. 38. SIP Record-Route Header for SAS: Mediant 2000 Mediant 3000 Mediant 3000 39. The device's SAS application now can be configured to add the SIP Record-Route header to SIP requests. This feature ensures that SIP messages traverse the device's SAS agent, by including the SAS IP address in the Record-Route header. The Record-Route header is inserted in a request by a proxy server to force future requests in the dialog session to be routed through the proxy. Each traversed proxy in the path can insert this header, causing all future dialogs in the session to pass through it as well. When this feature is enabled, the SIP Record-Route header includes the URI "lr" parameter. The presence of this parameter indicates loose routing; the lack of 'lt' indicates strict routing. For example: Loose routing: Record-Route: <sip:server10.biloxi.com;lr> Strict routing: Record-Route: <sip:bigbox3.site3.atlanta.com> Relevant parameter: SASEnableRecordRoute. SAS IP2IP Routing Table for SAS Normal Mode: Mediant 2000 Mediant 3000 Mediant 3000 40. The device's SAS application now uses the SAS IP2IP Routing table for routing requests received from the active proxy when in SAS Normal mode (previously used only for SAS Emergency mode). When SAS receives a SIP INVITE request from an active proxy server, the following routing logic is performed: a. Sends the request according to rules configured in the IP2IP Routing table. b. If no matching routing rule exists, the device sends the request according to its SAS registration database. c. If no routing rule is located in the database, the device sends the request according to the Request-URI header. SAS in Normal Mode Responds to REGISTER Requests with 200 OK without Relaying them to Proxy: Mediant 2000 Mediant 3000 Mediant 3000 The device's SAS application when in Normal mode can now be configured to respond to REGISTER requests by sending a SIP 200 OK (instead of relaying the registration requests to a proxy) and entering the registrations in the SAS database. This new feature is enabled by the new option "Auto-answer REGISTER" (3) for the existing SASSurvivabilityMode parameter. Relevant parameter: SASSurvivabilityMode. SIP Release Notes 28 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.3 B2BUA Transcoding New Feature The Mediant 3000 device now supports the Back-to-Back User Agent (B2BUA) Transcoding application. This application performs transparent transcoding of voice coders for IP-to-IP calls without affecting the SIP signaling messages. A description of the subsections: 1.3.1 SIP Network Definitions B2BUA Transcoding application is provided in the following The following SIP terms are used for configuring the B2BUA Transcoding application: Signaling Routing Domain/SRD (refer to Section 1.3.1.1 on page 29) SIP Interfaces (refer to Section 1.3.1.2 on page 30) Media Realms (refer to Section 1.3.1.3 on page 31) 1.3.1.1 Signaling Routing Domain (SRD) Entities The device now supports the configuration of Signaling Routing Domain (SRD) entities, using the SRD table. An SRD is a set of definitions of IP interfaces, device resources, SIP behaviors and other definitions that together create (from the IP user s perspective) from one physical device, multiple virtual multi service gateways. SRD provides the following capabilities: Multiple, different SIP signaling (SRD associated with a SIP Interface, described in below) and RTP media (associated with a Media Realm) interfaces for multiple Layer-3 networks. Due to the B2BUA nature of the Transcoding application, different interfaces can be assigned to each leg of the call, and between different networks. Ability to 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 group of SIP User Agents/UA (e.g. proxies, IP phones, application servers, gateways, 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). Typically, a different SRD is configured for each network. Routing from one SRD to another is possible, whereby each routing destination (IP Group or destination address) must indicate the SRD to which it belongs. The configuration of an SRD includes assigning it a unique name and assigning it a Media Realm (media port range associated with a Media IP interface, defined in the SIP Media Realm table) as well as associating it with a SIP Signaling interface (described below). Once configured, the SRD can then be assigned to an IP Group (in the IP Group table) and to a Proxy Set (in the Proxy Set table). Relevant parameter: SRD. The figure below illustrates two SRD's - one for Netwrok-1 and one for Network-2. Each of the applications (i.e., SAS, Gateway\IP2IP, and B2BUA Transcoding) pertain to the same SRD, but each having its own SIP interface. Version 6.0 29 February 2010

Mediant 2000 & Mediant 3000 Figure 1-1: Example Showing SIP Interfaces per Application Within SRD 1.3.1.2 SIP Interfaces The device now supports the configuration of multiple SIP signaling interfaces, using the SIP Interface table. A SIP Interface represents one SIP signaling entity, which is a combination of UDP, TCP, and TLS ports relating to one specific IP address (network interface, configured in the Multiple Interface table). The SIP Interface is configured with a corresponding SRD. This allows User Agents on the network to communicate with a specific SRD, using the SIP Interface (signaling interface) associated with it. Each SRD may be associated with up to three SIP Interfaces (one per application type - SAS, Gateway\IP-to-IP, and B2BUA Transcoding). Each SIP Interface must have a unique signaling port (i.e., no two SIP Interfaces can share the same port - no overlapping). SIP Interfaces are used for the following: Defining different SIP signaling ports (listening UDP, TCP, and TLS, and the UDP source ports) for a single or multiple interfaces. Differentiating between the different applications supported by the device (i.e., SAS, Gateway\IP2IP, and B2BUA Transcoding). Only one signaling interfaces (IPv4) per application type is allowed per SRD. Separating signaling traffic of different customers to use different routing tables, manipulations, SIP definitions, etc.. Relevant parameter: SIPInterface. The figure below illustrates the B2BUA Transcoding call flow between an enterprises LAN (IP PBX) and an ITSP (Network-2), implementing different interfaces (IP addresses and ports) for RTP packets and SIP signaling. In addition, for each leg, different interfaces are also used. The example uses the following IP addresses: IP-PBX: 10.2.2.6 Network-1: 10.2.2.3 Network-2: 212.179.1.12 ITSP: 212.179.1.13 Network-1 Media: 10.2.2.2:5000-6000 SIP Release Notes 30 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Network-2 Media: 212.179.1.11:7000-8000 Figure 1-2: Back-to-Back B2BUA Transcoding Call Flow (RTP and Signaling) 1.3.1.3 Media Realm A pool of media interfaces called Media Realms can be defined in the SIP Media Realm table. A Media Realm is range of UDP ports, which are associated with a media IP interface (defined in the Multiple Interface table). Therefore, Media Realms allow the user to divide a media-type IP interface into several realms, where each realm is specified by a UDP port range. Once created, the Media Realm can be assigned to an IP Group ID (in the 'IP Group' table), and/or SRD (in the 'SRD' table). Relevant ini file parameters: CpMediaRealm; cpdefaultmediarealmname; IPGroup. Version 6.0 31 February 2010

Mediant 2000 & Mediant 3000 1.3.2 SIP Dialog Initiation Process The device s SIP dialog initiation process concerns all incoming SIP dialog initiation requests. This includes the SIP methods such as INVITE, SUBSCRIBE, OPTIONS, REFER, INFO, UNSOLICITED NOTIFY, MESSAGE, and REGISTER. The SIP dialog initiation process consists of the following stages: Determining Source and Destination URL (refer to Section 1.3.2.1 on page 33) Source IP Group Classification (refer to Section 1.3.2.2 on page 33) IP-to-IP Routing (refer to Section 1.3.2.3 on page 35) IP-to-IP Inbound and Outbound Manipulation (refer to Section 1.3.2.4 on page 36) The flowchart below illustrates this process: Figure 1-3: Routing Process SIP Release Notes 32 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.3.2.1 Determining Source and Destination URL The SIP protocol has more than one URL in a dialog establishing request that might represent the source and destination URL. When handling an incoming request, the device determines which SIP headers are used for source and destination URL s. Once these URL s are determined, the input user and host are taken from these URLs. INVITE dialogs: Source URL: if exists, obtained from the P-Asserted\Preferred-Identity header; Otherwise, from the From header Destination URL: obtained from the Request URI REGISTER dialogs: Source URL: obtained from the To header Destination URL: obtained from the Request URI 1.3.2.2 Source IP Group Classification The device now supports the configuration of rules for classifying incoming SIP dialog initiating request. The classification identifies the incoming SIP dialog request as belonging to a specific IP Group (from where the SIP dialog request originated). Classification begins in the device's Registration database, where it searches for a match by checking if the request arrived from a registered user: Compares received Contact to the Contact of the registered user Compares P-Asserted/From URL to the registered AOR If the database search is unsuccessful, the classification process proceeds with locating a Proxy Set (associated with the SIP dialog request s IP address) and then finding a match with a corresponding IP Group in the IP Group table. Each IP Group can be classified according to its Proxy Set (if in the IP Group table the parameter ClassifyByProxySet is enabled). If enabled, the device classifies Requests arriving from the IP Group s Proxy Set as coming from this IP Group. The classification is done according to the Proxy IP list (in case of host names, then according to the dynamically resolved IP address list). Note that this classification is not relevant in cases where multiple IP Groups use the same Proxy Set. If classification based on Proxy Set is unsuccessful, the device proceeds to the Classification table, which searches for a source IP Group based on the following matching rules: Source IP Address, Source Username Prefix, Source Host Prefix, Destination Username Prefix, Destination Host Prefix, and Source SRD. If the above classification process fails to determine the source IP Group to which the incoming packet belongs, the call can either be rejected, or allowed and processed (by assigning it to the default IP Group of the default SRD). This last classification is determined by the parameter AllowUnclassifiedCalls. Version 6.0 33 February 2010

Mediant 2000 & Mediant 3000 This IP Group is afterwards used for the following purposes: Input for the manipulation and routing processes Defining SIP behavior and IP Profile, Media realm and matching account Note: Incoming REGISTER messages are recorded in the device s database sent to a destination only if they are associated with a source IP Group that is of USER type. The flowchart below illustrates the classification process: Figure 1-4: Classification Process (Identifying IP Group or Rejecting Call) SIP Release Notes 34 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.3.2.3 IP-to-IP Routing The device's B2BUA Transcoding application employs a comprehensive and flexible routing scheme: Routing rules according to Layer 3/4 and SIP characteristics Routing to multiple destination types: Request-URI (of incoming SIP dialog initiating requests) Specific destination IP address Specific FQDN (NAPTR/SRV/A-Record Resolutions) Registered Contact in device's database (User-type IP Groups) IP Group (address defined for Proxy Set associated with the IP Group), with the ability of load balancing and redundancy Alternative Routing Routing between two different Layer-3 networks Transport protocol translator (UDP to TCP to TLS) Source and destination user name manipulation (pre/post routing) The device now provides a new IP-to-IP Routing table (IP2IPRouting) for configuring the IPto-IP routing rules. This table provides enhanced IP-to-IP call routing capabilities for routing received SIP messages such as INVITE messages to a destination IP address. The routing rule must match one of the following input characteristics: Source IP Group, Source Phone Prefix, and/or Source Host Prefix. Note: SIP REGISTER messages are routed only by using Destination IP Groups defined in the IP-to-IP routing rules. The IP2IP Routing table determines the destination route according to any one of the following: Registered User Contact listed in the device's database (only for USER IP Groups) Destination IP Group's associated Proxy Set (allows redundancy/load balancing) Specific destination address (can be based on IP address, Host name, port, transport type, and/or SRD). Routing to a host name can be resolved using NAPTR/SRV/A- Record. Incoming Request URI For all destination types listed above except destination IP Group, the IP Group can optionally be itself, configured to provide destination SRD and/or IP Profile. If neither destination SRD nor destination IP Group are defined, the destination SRD is the source SRD and the destination IP Group is its default IP Group. Version 6.0 35 February 2010

Mediant 2000 & Mediant 3000 Figure 1-5: IP-to-IP Routing Types In addition to the alternative routing/load balancing provided by the Destination's IP Group's associated Proxy Set, the IP2IP Routing table also allows the configuration of alternative routes, whereby if a route fails, the next adjacent rule in the table that is configured as 'Alt Route Ignore/Consider Inputs' are used. The alternative routes rules can be set to enforce the input matching criteria or to ignore any matching criteria. For alternative routing, alternative routing reasons (i.e., 4xx, 5xx, and 6xx SIP responses) must be configured in the Alternative Routing Reasons table (SBCAlternativeRoutingReasons). If no matching rule is located in the table, the call is rejected. 1.3.2.4 IP-to-IP Inbound and Outbound Manipulation The device now supports SIP URI user part (source and destination) manipulations, whereby a manipulation rule in the table is located according to the source IP group, and source and destination host and user prefixes. Since outbound manipulations are performed after routing, the outbound manipulation rule matching can also be done by destination IP Group. The manipulation rules apply to INVITE, OPTIONS, and SUBSCRIBE messages (not REGISTER messages). Host name (source and destination) manipulations are simply host name substitutions with the names defined for the source and destination IP Groups respectively (if any, in the IP Group table). SIP Release Notes 36 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Manipulated destination user and host are performed to the following SIP headers: Request URI, To, and Remote party ID (if exists). Manipulated source user and host are performed to the following SIP headers: From, P-Asserted (if exists), P-Preferred (if exists), and Remote party ID (if exists). Figure 1-6: IP-to-IP Routing Process Below is an example of a call flow and consequent SIP URI manipulations: Figure 1-7: SIP INVITE (Manipulations) between Different Networks The B2BUA Transcoding application above performs the following SIP message manipulations (contributing to typical topology hiding): SIP Manipulation From To Inbound Source SIP URI User Name 7000 97000 (blue) Source IP Group Name (SIP URI Host Name) 10.2.2.6 IP_PBX (blue) Inbound Destination SIP URI User Name 1000 9721000 (red) Destination IP Group Name (SIP URI Host Name) 10.2.2.3 ITSP (red) Relevant ini file parameters: IPOutboundManipulation; IPInboundManipulation. Version 6.0 37 February 2010

Mediant 2000 & Mediant 3000 1.3.3 Media Handling Media behavior includes anything related to the establishment, management and termination of media sessions within the SIP protocol. Media sessions are created using the SIP "offer"/"answer" mechanism, if successful, the result is a bi-directional media (RTP) flow (e.g. audio, fax, modem, DTMF). Each offer/answer may create more than one media session of different types (e.g. audio and fax). In a SIP dialog, multiple offer/answer transactions may occur, each may change the media sessions characteristics (e.g. IP address, port, coders, media types, and RTP mode). The media capabilities exchanged in an offer/answer transactions include the following: Media types (Audio, Secure Audio, Video, Fax, Text...) IP addresses and ports of the media flow Media flow mode (send receive, receive only, send only, inactive) Media coders (coders and their characteristics used in each media flow) Other (standard or proprietary) media and session characteristics Even though the device usually does not change the negotiated media capabilities (mainly performed by the remote user agents), it does examine the media exchange to control negotiated media types (if necessary) and to know how to open the RTP media channels (IP addresses, coder type, payload type etc.). The device is aware and sometimes active in the offer\answer process due to the following: NAT traversal: the device changes the SDP address to be its own address, thereby, resolving NAT problems. Firewall and security: RTP pin holes - only RTP packets related to a successful offer\answer negotiation traverse the device: When the device initializes, there are no RTP pin holes opened, this means that each RTP\RTCP packets destined to the device are discarded. Once an offer\answer transaction ends successfully, an RTP pin hole is opened and RTP\RTCP flows between the two remote user agents. Once a pin hole is opened, the payload type and RTP header version is validated for each packet. RTP pin holes close if one of the associated SIP dialogs is closed (may also be due to broken connection). Late rogue detection - once a dialog is disconnected, the related pin holes also disconnect Deep Packet inspection of the RTP that flows through the opened pin holes Adding of media functionality to SIP user agents: Transcoding Broken connection According to the above functionalities, the call can be configured to operate in one of the following modes: Media Anchoring without Transcoding (Transparent): RTP traverses the device with minimal RTP packet changes (no DSP resources needed). This is typically used to solve NAT, firewall, and security issues. In this mode, all the audio coders in the received offer are included in the outgoing offer. The Coder Table configuration has no effect on the coders in the outgoing offer. Media Anchoring with Transcoding: RTP traverses the device and each leg uses a different coder or coder parameters (DSP resources are required). SIP Release Notes 38 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.3.3.1 Media Anchoring without Transcoding (Transparent) To direct the RTP to flow through the device (for NAT traversal, firewall and security), all IP address fields in the SDP are modified: Origin: IP address, session and version id Session connection attribute ('c=' field) Media connection attribute ('c=' field) Media port number RTCP media attribute IP address and port (if the parameter EnableRTCPAttribute is set to 1) Each B2BUA transcoding leg allocates and uses the device's local ports (e.g., for RTP\RTCP\fax). The local ports are allocated from a Media Realm associated with each leg. These legs are associated with a Media Realm as follows: If the leg s IP Group is configured with a Media Realm, then this is the associated Media Realm; otherwise, the leg s SRD Media Realm is the associated one. The figure below illustrates an example of SDP handling for a call between IP Phone 10.2.2.6 (Network-1) and a remote IP Phone 212.179.1.13 (Network-2). Figure 1-8: SDP Offer/Answer Example 1.3.3.2 Version 6.0 39 February 2010

Mediant 2000 & Mediant 3000 Media Anchoring with Transcoding The device performs transcoding when there are no common coders between the two user agents (i.e., the SDP answer from one user agent doesn t include any coder included in the offer previously sent by the other user agent). For transcoding, the device can be configured to add media capabilities to user agents pertaining to a specific IP Group, and then perform transcoding in cases where the selected coder in the answer SDP is not one that appears in the original offer. The capabilities that can be added are one or more of the device's supported coders and are configured by using the parameter SBCExtensionCodersGroupID (points to a coders list) in the IP Profile table (which is assigned to the IP Group). Therefore, to allow user agents of different IP Groups to communicate with each other (regardless of their capabilities), an extended coders table with at least one coder that is supported by each IP Groups' user agents needs to be assigned to each IP Group. Therefore, each offer destined to specific IP Groups include this coder. In the scenario depicted in the figure below, the IP phone on the Network-1 side initiates a call to the IP phone in Network-2. The initial SDP offer (from the Network-1 leg) includes codec G.711 as its supported codec. Since this is sent to a Destination IP Group that is configured with an extended coder list, on the Network-2 leg the device adds another supported codec G.729 to the SDP, which is now offered to the Network- 2 IP phone. The Network-2 IP phone chooses the extended codec (G.729) in its SDP answer to the device's Network-2 leg. Since this codec was not included in the original incoming offer, the device performs transcoding (between G.729 and G.711) between its two legs, allowing the streaming of media to occur. Figure 1-9: Transcoding using Extended Coders (Example) For an SDP offer to provide an extended coder list to a remote user agent, the following prerequisites must be fulfilled: An extended coders list has been configured for the user agent s IP Group (i.e., Destination IP Group) The incoming offer contains at least one supported coder (otherwise, transcoding can t be performed) SIP Release Notes 40 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Both legs have available DSP s T.38 doesn t appear in the offer If the above prerequisites are not met, the SDP offer is sent without the extended coders list. The coders from the extended list are added after the ones from the original offer (decreases transcoding probability). Coders common between the extended coders list and those in the original SDP offer are not added. Transcoding may be performed even in scenarios when the same coder has been chosen - this occurs if the coders use different coder parameters (e.g. rate and packetization time). The device also supports early media, whereby the first offer\answer transaction is finalized and the media flow starts before the SIP call is connected (before the INVITE 200 OK response). The offer and answer options can be included in the following SIP messages: Offer in first INVITE, answer on 180, and no or same answer in the 200 OK Offer in first INVITE, answer on 180, and a different answer in the 200 OK (not standard) INVITE without SDP, offer in 180, and answer in PRACK PRACK and UPDATE transactions can also be used for initiating subsequent offer\answer transactions before the INVITE 200 OK response. In a SIP dialog life time, media characteristics after originally determined by the first offer\answer transaction can be changed by using subsequent offer\answer transactions. These transactions may be carried either in UPDATE or ReINVITE SIP transactions. The media handling is similar to the original offer/answer handling. If the offer is rejected by the remote party, then no media changes occur (e.g. INVITE without SDP, then 200 OK and ACK, offer\answer within an offer/answer, and Hold ReINVITE with IP address of 0.0.0.0 - IP address is unchanged). 1.3.3.3 Transcoding Modes The device supports the configuration of the voice transcoding mode (media negotiation) between the two legs. The device can be configured to perform transcoding only when necessary. Typically, the B2BUA Transcoding application passes RTP packets transparently (RTP-to-RTP) between the two user agents. If the device is configured to always perform transcoding, then transcoding is performed on the outgoing leg and the device's B2BUA Transcoding application interworks the media by implementing PSTN transcoding (since both legs have different media capabilities). In the B2BUA Transcoding application, forced transcoding of voice in a B2BUA session allows the device to receive capabilities that are not negotiated between the legs. For example, to force Gain Control on the B2BUA session to use voice transcoding even though both sides of the session have negotiated without the device s intervention (for example coder extension). Note: To implement transcoding, you must configure the number of required DSP channels used for transcoding (for example, MediaChannels = 120). Each transcoding session uses two DSP resources. Relevant ini file parameters: TranscodingMode; IPProfile; MediaChannels. Version 6.0 41 February 2010

Mediant 2000 & Mediant 3000 1.4 Voice, RTP and RTCP New Features The device supports the following new voice, RTP and RTCP features: 1. GSM Coders Enhanced Support: Mediant 2000 Mediant 3000 Mediant 3000 2. The device's support for GSM speech coders MS GSM (Microsoft's version of GSM) and Full-Rate GSM (FR GSM) has been enhanced. These coders have also been added to DSP Version Template Number 0 (in previous releases they were supported only on DSP Template 1). Relevant parameter: CodersGroup. Packet Loss Concealment (PLC) G.722 Support: Mediant 2000 Mediant 3000 Mediant 3000 3. Packet Loss Concealment (PLC) capability has been added to the G.722 coder, thereby, ensuring higher voice quality. Relevant parameter: CodersGroup. T.38 Version 3 Fax-over-IP Relay Protocol: Mediant 2000 Mediant 3000 Mediant 3000 4. The device now supports T.38 Version 3 for fax-over-ip transmission. This provides a fast (up to 33.6 kbps) V.34 fax connection over T.38. This new capability is supported on a new DSP version template number (DSPVersionTemaplateNumber = 10). The T.38 version (0 through 3) can be selected (Web interface or ini file), using the new parameter, T38Version. Note: This feature will be supported only on post GA release. For more information, please contact AudioCodes representative. Relevant parameters: T38Version; FaxRelayMaxRate. SIP Release Notes 42 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Microsoft MS RTA (NB) Coder Support: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the Microsoft real-time audio, narrowband coder (MS RTA NB), at clock rate of 8 khz. The coder supports various transmit (Tx) bit rates (userdefined). In addition, the user can disable the Coder Forward Error Correction (FEC) operation. This coder is supported by the new DSP version template number 9. For MS RTA NB, the a=rtpmap and a=fmtp lines appear as follows (assumes the default dynamic payload type of 115 is used): a=rtpmap:115 x-msrta/8000 a=fmtp:115 bitrate=11800 Relevant parameters: MSRTATxBitRate; MSRTAForwardErrorCorrectionEnable. 5. Answering Machine Beep Detection using X-Detect Header Extension: Mediant 2000 Mediant 3000 Mediant 3000 Mediant 3000 HA 6. The device now supports the detection of beeps at the end of an answering machine message, by using the X-Detect header extension. The device sends a SIP INFO message containing one of the following field values: Type=AMD and SubType=Beep Type=CPT and SubType=Beep The device supports two methods for detecting and reporting beeps: Using the AMD detector. This detector is integrated in the existing AMD feature. The beep detection timeout (in 100 msec units - default 200, i.e., 20 seconds) and beep detection sensitivity (0-3. where 0 is the least sensitive - default 0) are configurable. Using the Call Progress Tone detector - several beep tones (Tone Type #46) can be configured in the CPT file This feature allows users of certain third-party, Application servers to leave a voice message after an answering machine plays a beep. Relevant parameters: AMDBeepDetectionMode; AMDBeepDetectionTimeout; AMDBeepDetectionSensitivity. High-Resolution Answering Machine Detector Sensitivity: Mediant 2000 Mediant 3000 Mediant 3000 Mediant 3000 HA The device now supports up to 16 levels of Answering Machine Detector sensitivity configurations (compared to only 8 levels in previous releases, using the parameter AMDDetectionSensitivity). Relevant parameters: AMDDetectionSensitivityHighResolution; AMDSensitivityResolution. Version 6.0 43 February 2010

Mediant 2000 & Mediant 3000 7. AMD Minimum Voice Activity Detection: Mediant 2000 Mediant 3000 Mediant 3000 Mediant 3000 HA The device now supports the configuration of the Answer Machine Detector minimum voice activity detection (in 5-ms units). Voice activity duration below this threshold is ignored and considered as non-voice. Relevant parameter: AMDMinimumVoiceLength. 1.5 Security New Features The device supports the following new security features: 1. IPSec/IKE Unified Configuration Table: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the combined configuration of the Internet Key Exchange (IKE) and IP Security (IPSec) protocols using a single ini file parameter table. This allows for quick and easy configuration (as well as diagnoses) of up to 20 peers. In addition, the user can now use a separate new ini file parameter table for configuring up to four IKE proposal settings, where each proposal defines an encryption algorithm, an authentication algorithm, and a Diffie-Hellman group identifier. Relevant parameters: IPSecSATable; IPSecProposalTable. SIP Release Notes 44 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.6 PSTN New Features The device supports the following new PSTN features: 1. Configurable Numbering Type and Plan for ISDN Connected Number: Mediant 2000 Mediant 3000 Mediant 3000 In previous releases, the Connected Number IE (interworked from SIP 200 OK P- Asserted-Identity header to the ISDN Q.931 Connect message) was hard-coded [Numbering Type = 0 (unknown) and Plan = 0 (unknown)]. However, for some ISDN variants (e.g., 4ESS), Type = unknown (0) is not a valid value and the Connected Number is rejected by the PSTN stack. In this releases, the device now allows the configuration of the Numbering Type and Plan of the Connected Number IE using two new parameters, ConnectedNumberType and ConnectedNumberPlan. The default value is 0 for both (i.e., unknown). Relevant parameters: ConnectedNumberType; ConnectedNumberPlan. 2. Interworking QSIG Facility Message with calltranfercomplete to SIP UPDATE: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports interworking of the QSIG Facility message with calltranfercomplete invoke application protocol data unit (APDU), to SIP UPDATE message with P-Asserted-Identity and optional Privacy headers. The redirectionnumber and redirectionname in the calltransfercomplete invoke is derived from the P-Asserted-Identity and Privacy headers. This feature is supported in the IPto-Tel and Tel-to-IP directions. The new parameter, EnableQSIGTransferUpdate is used to enable this feature. For example, assume A and C are PBX call parties, and B is the SIP IP phone: a. A calls B; B answers the call. b. A places B on hold, and calls C; C answers the call. c. A performs a call transfer (the transfer is done internally by the PBX); B and C are connected to one another. In the above example scenario, the PBX updates B that it is now talking with C. The PBX updates this by sending a QSIG Facility message with calltranfercomplete invoke APDU. The device interworks this message to a SIP UPDATE message containing a P-Asserted-Identity header with the number and name derived from QSIG calltranfercomplete redirectionnumber and redirectionname. Relevant parameter: EnableQSIGTransferUpdate. Version 6.0 45 February 2010

Mediant 2000 & Mediant 3000 3. PSTN Support using Software Upgrade Key: Mediant 2000 Mediant 3000 Mediant 3000 4. The device now supports enabling and disabling PSTN functionality using a Software Upgrade Key. Therefore, the device can now be offered as a standalone IP-to-IP Media Gateway. As supported in previous releases, the Software Upgrade Key can also be used to activate a standalone PSTN-IP Media Gateway, or a combined GW/IPto-IP Media Gateway. When the PSTN functionality is disabled, the relevant PSTN menus and pages are not displayed: PSTN Settings SS7 Configuration Sigtran Configuration QSIG MWI-to-IP Interworking Interrogation: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the interworking of QSIG Message Waiting Indication (MWI) to IP, by introducing a new parameter (MWIInterrogationType) in the Trunk Group Settings table. This parameter determines the device's handling of MWI Interrogation messages, as described below. This feature provides interworking between an ISDN PBX with voice-mail capabilities and a softswitch, which requires information on the number of messages waiting (i.e., MWI) for a specific user. The process for sending the MWI status upon request from a softswitch is as follows: a. The softswitch sends a SIP SUBSCRIBE message to the device. b. 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. c. 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. d. The device sends another SIP NOTIFY to the softswitch, containing this MWI information. e. The SIP NOTIFY messages are sent to the IP Group defined by the new parameter NotificationIPGroupID. In addition, 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 the PBX support, the new 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. SIP Release Notes 46 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 5. Therefore, the device can be configured to disable this feature, or enable it with one of the following support: Responds to MWI Activate requests from the PBX by sending SIP NOTIFY MWI messages (i.e., does not send MWI Interrogation messages). Sends MWI Interrogation messages, but does not use their results. Instead, waits for MWI Activate requests from the PBX. Sends MWI Interrogation messages, uses their results, and uses the MWI Activate requests. Relevant parameters: MWIInterrogationType; TrunkGroupSettings; EnableMWI; NotificationIPGroupID. Configuration of Redirect Number Screening Indicator: Mediant 2000 Mediant 3000 Mediant 3000 6. The device now allows you to configure a value for the Redirect Number Screening Indicator in ISDN Setup messages for IP-to-Tel calls. Relevant parameter: SetIp2TelRedirectScreeningInd. SIP-ISDN Interworking tgrp DoD UCR 2008 Parameters: Mediant 2000 Mediant 3000 Mediant 3000 When a hotline call is setup between the softswitch and the device, the indication that the call is a hotline call is required in order to meet the hotline screening requirements of the terminating subscriber s switch. This indication is provided by the SIP "tgrp" parameter and the ISDN optional Off-hook Indicator" Information Element (IE). The device now supports interworking of this SIP indication with the ISDN indication. For Tel-to-IP calls, the SIP "tgrp" to ISDN Q.931 mapping is shown in the table below: SIP "tgrp" Value Q.931 Bearer Capability Off Hook IE (Optional) No label Speech ccdata unrestricted 64 Kbit/s hotline Speech Voice hotline-ccdata unrestricted 64 Kbit/s Data The Hotline Feature is applicable only for the ISDN NI-2 variant and is defined according to the UCR-2008 specification. This feature is enabled by setting the UseSIPTGRP parameter to 3. If enabled, the device performs the following interworking between SIP INVITE and ISDN Setup: For IP-to-ISDN calls: The device interworks the SIP tgrp=hotline parameter (received in INVITE) to ISDN Setup with the Off Hook Indicator IE of Voice, and Speech Bearer Capability IE. Note that the Off Hook Indicator IE is described in UCR 2008 specifications. Version 6.0 47 February 2010

Mediant 2000 & Mediant 3000 The device interworks the SIP tgrp=hotline-ccdata parameter (received in INVITE) to ISDN Setup with an Off Hook Indicator IE of Data, and with Unrestricted 64k Bearer Capability IE. The following is an example of the INVITE with tgrp=hotline-ccdata: INVITE sip:1234567;tgrp=hotline-ccdata;trunk-context=dsn.mil@nortel.com SIP/2.0 7. For ISDN-to-IP calls: The device interworks ISDN Setup with an Off Hook Indicator of Voice to SIP INVITE with tgrp=hotline;trunk-context=dsn.mil in the Contact header. The device interworks ISDN Setup with an Off Hook indicator of Data to SIP INVITE with tgrp=hotline-ccdata;trunk-context=dsn.mil in the Contact header. If ISDN Setup does not contain an Off Hook Indicator IE and the Bearer Capability IE contains Unrestricted 64k, the outgoing INVITE includes tgrp=ccdata;trunk-context=dsn.mil. If the Bearer Capability IE contains Speech, the INVITE in this case does not contain tgrp and trunk-context parameters. Relevant parameter: UseSIPTgrp. Interworking SIP with ISDN ETSI, QSIG CONP and CNIR Supplementary Services: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports interworking between SIP and ISDN ETSI or QSIG's Connected Name Identification Presentation (CONP) and Calling/Connected Name Identification Restriction (CNIR) supplementary services. Interworking of QSIG Calling Name: The device already supports (in the previous release) interworking of the QSIG Calling Name, including its privacy (presentation = allowed or restricted) to SIP P-Asserted-Identity and Privacy headers (ISO 13868). The Privacy=id header in the outgoing INVITE describes the privacy for both calling number and calling name. If one of these ISDN parameters contains the value "presentation=restricted", then the Privacy=id header is included in the INVITE. In the IP-to-Tel direction, if the device receives a SIP INVITE containing a Privacy=id header, both calling number and calling name privacy are set to restricted. Interworking of QSIG Connected Line Number: The device supports interworking of SIP with ETSI or QSIG Connected Line Number, using the SIP P-Asserted- Identity and Privacy headers included in the 200 OK response. The P-Asserted- Identity and Privacy headers are interworked from SIP 200 OK to ISDN Connected Line Identification (ISO 14136), using the ISDN Connected Party Number IE. SIP Release Notes 48 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 8. Interworking of ETSI/QSIG Connected Name: If the device receives a P- Asserted-Identity header in the 200 OK response that contains also the Display name, the Display name is interworked to the ETSI/QSIG Connected Name, including its Presentation (allowed or restricted). In the Tel-to-IP direction, if the device receives an ISDN Connect message containing Connected Name and Connected Line Number, these parameters are interworked to the SIP P-Asserted-Identity header in the 200 OK response. If one of these parameter includes presentation=restricted, a "Privacy: id" header is added to the 200 OK. Relevant parameter: AssertedIdMode. SIP Overlap Dialing for ISDN: Mediant 2000 Mediant 3000 Mediant 3000 9. The device now supports the interworking of ISDN overlap dialing to SIP, based on RFC 3578. Interworking ISDN overlap dialing to SIP (Tel to IP): The device sends collected digits each time they are received (initially from ISDN Setup and then from subsequent Info Q.931 messages) to the IP, 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 new parameter MinOverlapDigitsForRouting. Interworking SIP to ISDN overlap dialing (IP to Tel): For each received INVITE pertaining to the same dialog session, the device sends an ISDN Setup (and subsequent ISDN Info Q.931 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: MinOverlapDigitsForRouting; ISDNTxOverlap; ISDNRxOverlap. Version 6.0 49 February 2010

Mediant 2000 & Mediant 3000 ISDN-to-IP Calling Number Modification using Dial Plan: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports changing the Calling Party Number value (source number) in the received ISDN incoming call when sending to IP, using the Dial Plan file. For this feature, the Dial Plan file supports the following syntax: <ISDN Calling Party Number>,0,<new calling number> The Dial Plan file can also include a range for the source number, using the syntax: [x-y]. Below is an example of such a configuration in the Dial Plan file: [ PLAN1 ] ; specific received number changed to 04343434181. 0567811181,0,04343434181 ; number range that changes to 04343434181. 056788118[2-4],0,04343434181 The device adds the newly manipulated calling number to the URI user part in the From header and to the Contact header in the SIP INVITE sent to the IP side. For example, a received Calling Number Party of 0567811181 that is changed to 04343434181 (see Dial Plan file example above) is sent to the IP with a SIP INVITE as follows: Via: SIP/2.0/UDP 211.192.160.214:5060;branch=z9hG4bK3157667347 From: <sip:04343434181@kt.co.kr:5060>;tag=de0004b1 To: sip:01066557573@kt.co.kr:5060 Call-ID: 585e60ec@211.192.160.214 CSeq: 1 INVITE Contact:<sip:04343434181@211.192.160.214:5060;transport=udp> Notes: 10. Tel-to-IP routing is performed on the original source number if the parameter 'Tel to IP Routing Mode' is set to 'Route calls before manipulation'. Tel-to-IP routing is performed on the modified source number as defined in the Dial Plan file if the parameter 'Tel To IP Routing Mode' is set to 'Route calls after manipulation'. Source number Tel-to-IP manipulation is performed on the modified source number as defined in the Dial Plan file. Increased Timers for TDM-over-IP Tunneling: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the configuration of the timers for the TDM-over-IP tunneling application. This includes the following timers: Time between successive INVITEs sent from the same E1/T1 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. Relevant parameters: TDMoIPInitiateInviteTime; TDMoIPInviteRetryTime. 11. Mute DTMF for ISDN Overlap Dialing: SIP Release Notes 50 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Mediant 2000 Mediant 3000 Mediant 3000 The device now allows you to mute in-band DTMF detection until the device receives the full destination number from the ISDN (for Tel-to-IP calls). With ISDN overlap dialing, DTMF digits can be sent in-band in the voice stream, or out-of-band using Q.931 Info messages. If Q.931 Info messages are used for overlap dialing, the DTMF in-band detector must be disabled. Note that when at least one digit is received from the ISDN (Setup), the device stops playing a dial tone. Relevant parameter: MuteDTMFInOverlap. 12. ECT and TBCT Network Side: Mediant 2000 Mediant 3000 Mediant 3000 The device now also supports Network side (in addition to already supported User side) ISDN supplementary services: ETSI ECT (Explicit Call Transfer, ETS-300-369) NI2 TBCT (Two B-channel Transfer, GR-2865-CORE) This feature provides interworking of TBCT and ECT path replacement for IP-to-ISDN calls. The device sends a SIP REFER message to the remote call party if such a path replacement is received from the PRI/BRI side (e.g., from a PBX). Relevant parameter: EnableNetworkISDNTransfer. 13. TBCT for Verizon GTD-5 Switch (Based on FSD 01-02-40AG): Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the NI2 TBCT for Verizon GTD-5 EAX switch (General Telephone Digital Number 5 Electronic Automatic Exchange). This ISDN Supplementary Service (User side) is based on FSD 01-02-40AG specification. This digital central office telephone circuit Class-5 switching system is used in the former GTE service areas and by many smaller telecommunications service providers. TBCT allows the user on a PRI to request the GTD-5 EAX to connect two independent calls on the user's interface. If the request is accepted, the controller is released from the calls and the other two users are directly connected. Relevant parameter: ISDNGeneralCCBehavior. Version 6.0 51 February 2010

Mediant 2000 & Mediant 3000 14. Call Deflection for Euro ISDN and QSIG: Mediant 2000 Mediant 3000 Mediant 3000 The device now 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 for call forwarding (call diversion) when the device receives a 302. In previous releases, upon receipt of a Facility message with Call Rerouting invoke method from the PSTN, the device initiated a SIP transfer process by sending a SIP 302 response in response to the remote SIP entity's INVITE message. The device then responded with a Disconnect message to the PSTN side. In this new feature, the opposite direction is now also supported, i.e., the call forward is performed by the PSTN side instead of the SIP side. When the device sends the INVITE message to the remote SIP entity and receives in response a SIP 302, the device sends to the PSTN a Facility message with the same Facility IE mentioned above and waits for the PSTN side to disconnect the call. Relevant parameter: CallReroutingMode. 15. T310 Timer for Euro ISDN Variants: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the configuration of the T310 timer for DMS and Euro ISDN variants, using the new parameter ISDNTimerT310. This parameter replaces the old ISDNDmsTimerT310 that was used for DMS variants. The ISDNDmsTimerT310 will be obsolete in future releases. When both the parameters ISDNDmsTimerT310 and ISDNTimerT310 are configured, the value of the parameter ISDNTimerT310 prevails. Relevant parameter: ISDNTimerT310. 16. Multi-CAS Variants per Trunk: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the configuration of different CAS variants per CAS trunk, by using the parameter CasChannelIndex. This parameter defines the loaded CAS table per B-channel pertaining to a CAS trunk. This parameter is assigned a string value and can be set in one of two formats: CAS table per channel, for example, "1,2,1,3 ". For this format, 31 indices must be defined for E1 trunks (including dummy for B-channel 16) or 24 indices for T1 trunks. CAS table per channel group, for example, "1-10:1,11-31:3". Every B-channel (including 16 for E1) must belong to a channel group. Note that only one of these formats must be implemented. SIP Release Notes 52 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Below is an example ini file for configuring a T1 CAS trunk (Trunk 5) with several CAS variants: ProtocolType_5 = 7 CASFILENAME_0='E_M_FGBWinkTable.dat' CASFILENAME_1='E_M_FGDWinkTable.dat' CASFILENAME_2='E_M_WinkTable.txt' CasChannelIndex_5 = 0,0,0,1,1,1,2,2,2,0,0,0,1,1,1,0,1,2,0,2,1,2,2,2 CASDelimitersPaddingUsage_5 = 1 Below is an example ini file for configuring an E1 CAS trunk (Trunk 5) with several CAS variants: ProtocolType_5 = 8 CASFILENAME_2='E1_R2D' CASFILENAME_7= E_M_ImmediateTable_A-Bit.txt' CasChannelIndex_5 = 1-10:2,11-20:7,21-31:2 Relevant parameter: CasChannelIndex. 17. Fractional CAS Trunk: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports the configuration of a fractional CAS trunk in deployments where the device is connected to only a single trunk and the device's DSP resources are insufficient to support a full CAS trunk. 18. Performance Monitoring for Number of Active Calls per Trunk/Trunk Group: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports performance monitoring of the number of active calls per Trunk and Trunk Group. These performance monitoring include the following: Established Tel-to-IP calls per Trunk (Tel2IPTrunkEstablishedCalls) Established IP-to-Tel calls per Trunk (IP2TelTrunkEstablishedCalls) Established Tel-to-IP calls per Trunk Group (Tel2IPTrunkGroupEstablishedCalls) Established IP-to-Tel calls per Trunk Group (IP2TelTrunkGroupEstablishedCalls) 19. Collect Call Indication in INVITE for ISDN-to-SIP Calls: Version 6.0 53 February 2010

Mediant 2000 & Mediant 3000 Mediant 2000 Mediant 3000 Mediant 3000 The device now adds a new proprietary SIP header, "X-Siemens-Call-Type: collectcall" to outgoing INVITE messages in response to received ISDN calls that are collect calls. This feature was developed for Brazil and is supported only for the Euro ISDN protocol. The device identifies these ISDN collect calls according to the Reverse Charging Indication IE in Setup messages. 1.7 Web New Features The device supports the following new Web interface features: 1. New Submenu "Application Network Setting": Mediant 2000 Mediant 3000 Mediant 3000 2. A new submenu folder - Application Network Setting - has been added under the Protocol Configuration menu folder in the Navigation tree. This submenu contains the following items (previously located under the SBC submenu folder): SRD Table SIP Interface Table 'EtherDiscover Operation Mode' Parameter Removed from Web: Mediant 2000 Mediant 3000 Mediant 3000 The 'EtherDiscover Operation Mode' (EtherDiscoverMode) parameter (appearing in the 'General Security Settings' page) has now been removed from the Web interface. 3. B2BUA Transcoding Feature added in Web Interface: Mediant 2000 Mediant 3000 Mediant 3000 The Web interface now provides pages for configuring the B2BUA Transcoding feature: The 'Applications Enabling' page (under the Protocol Configuration menu) provides the Enable B2BUA Transcoding parameter for enabling the B2BUA Transcoding feature. A new submenu, B2BUA Transcoding has now been added under the Protocol Configuration menu, which includes configuration pages related to the B2BUA Transcoding feature. SIP Release Notes 54 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 4. SCE Parameter Removed from Web: Mediant 2000 Mediant 3000 Mediant 3000 The 'SCE' parameter (appearing in the 'IP Profile Settings' page) has now been removed from the Web interface. 5. Status of Registration per Account: Mediant 2000 Mediant 3000 Mediant 3000 6. The Web interface now displays registration status per Account. This information is displayed in a new table in the existing 'Registration Status' page (Status & Diagnostics tab > Gateway Statistics menu > Registration Status). Status of Active Proxy in Proxy Set: Mediant 2000 Mediant 3000 Mediant 3000 7. The Web interface now displays the status of the active proxy defined for a Proxy Set. This information is displayed in a new table (Active Proxy Sets Status) in the existing 'Call Routing Status' page (Status & Diagnostics tab > Gateway Statistics menu > Call Routing Status). Software Upgrade Progress Bar Indication: Mediant 2000 Mediant 3000 Mediant 3000 The device's Web interface now displays a progress bar in the 'Software Upgrade Wizard' page for indicating the progress in real-time of the software file download process. Version 6.0 55 February 2010

Mediant 2000 & Mediant 3000 1.8 SNMP New Features The device supports the following new Simple Network Management Protocol (SNMP) features: 1. Trunk Status Alarm: Mediant 2000 Mediant 3000 Mediant 3000 The device now provides a new column actrunkstatusalarm in the actrunkstatustable for indicating the trunk's alarm status. 2. Deprecated Parameters: Mediant 2000 Mediant 3000 Mediant 3000 The following SNMP MIB objects have now been deprecated: AC-CONTROL-MIB: accpnamingendpoint accpnamingtrunk accpnamingendpointprefix acmcnamepatternlogicalatm acmcnamenumberphysicalendpointmin acmcnamenumberstreamendpointatmstart acmcprofilebinary AC-SYSTEM-MIB: acsyshttpclientfxscoefffileurl. acsyshttpclientfxocoefffileurl. acsysvlannetworkserviceclasspriority. acsysvlanpremiumserviceclassmediapriority. acsysvlangoldserviceclasspriority. acsysvlanbronzeserviceclasspriority. acsysvlanpremiumserviceclasscontrolpriority. acsysikepolicytable acsysipsecspdtable SIP Release Notes 56 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 3. Hotline Option Added for sipmiscusesiptgrp: Mediant 2000 Mediant 3000 Mediant 3000 4. The SNMP MIB parameter sipmiscusesiptgrp now provides option value 3, "hotline". The Object Identifier (OID) is 1.3.6.1.4.1.5003.9.10.3.1.2.7.19 and the full path is: iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).audiocodes(5003).acproducts (9).acBoardMibs(10).acGateway(3).gwConfiguration(1).sip(2).sipMisc(7).sipMiscUseSI PTgrp(19). This parameter determines whether the SIP 'tgrp' tag is used, which specifies the Trunk Group to which the call belongs, according to RFC 4904. For example: INVITE sip::+16305550100;tgrp=1;trunk-context=example.com@10.1.0.3;user=phone SIP/2.0 Future Release 6.2 - Change in Enumeration Names: Mediant 2000 Mediant 3000 Mediant 3000 In the next major release - Release 6.2 - all hyphens (" - ") will be removed from labels of named-number enumeration. This is in accordance with RFC 2578 SMIv2, which prohibits the use of hyphens. The length of labels will also be shortened to ensure that they are less than 32 characters. 1.9 Miscellaneous New Features The device supports the following miscellaneous new features: 1. Automatic Syslog Debug Level Selection Based on CPU Usage: Mediant 2000 Mediant 3000 Mediant 3000 The device now supports a new debug level of 7. When set to this level, the Syslog level automatically changes between level 5, level 1 and level 0, depending on the device's CPU consumption. In addition, to improve device performance, several Syslog messages are now merged and sent as a single UDP datagram. A new parameter, MaxBundleSyslogLength defines the maximum size of this bundled UDP packet. Relevant parameters: GWDebugLevel; MaxBundleSyslogLength. Version 6.0 57 February 2010

Mediant 2000 & Mediant 3000 1.10 New Parameters This section describes the new parameters for Release 6.0. These new parameters can be configured using the ini file parameter (enclosed in square brackets) and/or the corresponding Web interface parameter (if supported). 1.10.1 SIP Parameters The table below describes the new SIP parameters for Release 6.0. Table 1-1: New SIP Parameters for Release 6.0 Parameter [SIPForceRport] [MLPPNetworkIdentifier] Web: Set Redirect number Screening Indicator to TEL [SetIp2TelRedirectScreeni ngind] Description Determines whether the device sends SIP responses to the UDP port from where SIP requests are received even if the "rport" parameter is not included in the Via header. [0] (default) = Disabled - the device sends the SIP response to the UDP port defined in the Via header. If the Via header contains the "rport" parameter, the response is sent to the UDP port from where the SIP request is received. [1] = Enabled - SIP responses are sent to the UDP port from where SIP requests are received even if the "rport" parameter is not included in the Via header. Defines the MLPP network identifier (i.e., International prefix or Telephone Country Code/TCC) for IP-to-ISDN calls, according to the UCR 2008 and ITU Q.955 specifications. The valid range is 1 to 999. The default is 1 (i.e., USA). The MLPP network identifier is sent in the Facility IE of the Setup message. For example: MLPPNetworkIdentifier set to default (i.e., USA, 1): PlaceCall- MLPPNetworkID:0100 MlppServiceDomain:123abc, MlppPrecLevel:5 Fac(1c): 91 a1 15 02 01 05 02 01 19 30 0d 0a 01 05 0a 01 01 04 05 01 00 12 3a bc MLPPNetworkIdentifier set to 490: PlaceCall- MLPPNetworkID:9004 MlppServiceDomain:123abc, MlppPrecLevel:5 Fac(1c): 91 a1 15 02 01 0a 02 01 19 30 0d 0a 01 05 0a 01 01 04 05 90 04 12 3a bc Defines the value of the Redirect Number screening indicator in ISDN Setup messages. [-1] Not Configured (default) [0] User Provided [1] User Passed [2] User Failed [3] Network Provided SIP Release Notes 58 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description Web: Redirect Number Tel -> IP [RedirectNumberMapTel2I P] This ini file table parameter manipulates the redirect number for Tel-to- IP calls. The manipulated Redirect Number is sent in the SIP Diversion, History-Info, or Resource-Priority headers. The format of this parameter is as follows: [RedirectNumberMapTel2Ip] FORMAT RedirectNumberMapTel2Ip_Index = RedirectNumberMapTel2Ip_DestinationPrefix, RedirectNumberMapTel2Ip_RedirectPrefix, RedirectNumberMapTel2Ip_NumberType, RedirectNumberMapTel2Ip_NumberPlan, RedirectNumberMapTel2Ip_RemoveFromLeft, RedirectNumberMapTel2Ip_RemoveFromRight, RedirectNumberMapTel2Ip_LeaveFromRight, RedirectNumberMapTel2Ip_Prefix2Add, RedirectNumberMapTel2Ip_Suffix2Add, RedirectNumberMapTel2Ip_IsPresentationRestricted, RedirectNumberMapTel2Ip_SrcTrunkGroupID, RedirectNumberMapTel2Ip_SrcIPGroupID; [\RedirectNumberMapTel2Ip] For example: RedirectNumberMapTel2Ip 1 = *, 4, 255, 255, 0, 0, 255,, 972, 255, 1, 2; Notes: This parameter table can include up to 20 indices (1-20). If the table's matching characteristics rule (i.e., DestinationPrefix, RedirectPrefix, SrcTrunkGroupID, and SrcIPGroupID) is located for the Tel-to-IP call, then the redirect number manipulation rule (defined by the other parameters) is applied to the call. The parameters NumberType and NumberPlan are applicable only for the SIP Resource-Priority header. The manipulation rules are performed in the following order: RemoveFromLeft, RemoveFromRight, LeaveFromRight, Prefix2Add, and then Suffix2Add. Version 6.0 59 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Web: Redirect Number IP -> Tel [RedirectNumberMapIp2T el] Web: Forward On Busy Trunk Destination [ForwardOnBusyTrunkDe st] This ini file table parameter manipulates the redirect number for IP-to- Tel calls. This manipulates the value of the SIP Diversion, History-Info, or Resource-Priority headers (including the reason the call was redirected). The format of this parameter is as follows: [RedirectNumberMapIp2Tel] FORMAT RedirectNumberMapIp2Tel_Index = RedirectNumberMapIp2Tel_DestinationPrefix, RedirectNumberMapIp2Tel_RedirectPrefix, RedirectNumberMapIp2Tel_SourceAddress, RedirectNumberMapIp2Tel_NumberType, RedirectNumberMapIp2Tel_NumberPlan, RedirectNumberMapIp2Tel_RemoveFromLeft, RedirectNumberMapIp2Tel_RemoveFromRight, RedirectNumberMapIp2Tel_LeaveFromRight, RedirectNumberMapIp2Tel_Prefix2Add, RedirectNumberMapIp2Tel_Suffix2Add, RedirectNumberMapIp2Tel_IsPresentationRestricted; [\RedirectNumberMapIp2Tel] For example: RedirectNumberMapIp2Tel 1 = *, 88, *, 1, 1, 2, 0, 255, 9,, 255; Notes: This parameter table can include up to 20 indices (1-20). If the table's matching characteristics rule (i.e., DestinationPrefix, RedirectPrefix, and SourceAddress) is located for the IP-to-Tel call, then the redirect number manipulation rule (defined by the other parameters) is applied to the call. The manipulation rules are executed in the following order: RemoveFromLeft, RemoveFromRight, LeaveFromRight, Prefix2Add, and Suffix2Add. The RedirectPrefix parameter is used before any manipulation has been performed on it. The redirect manipulation is performed after the parameter CopyDest2RedirectNumber. This ini file table parameter configures the Forward On Busy Trunk Destination table. This table allows you to define an alternative call destination (IP address) per Trunk Group for IP-to Tel calls. The IP-to- Tel call is forwarded to this destination (using 3xx Response) if the Trunk Group has no available channels ( busy ). The device forwards calls using this new table only if no alternative routing has been configured or alternative routing fails, and one of the following call forward reasons (which is included in the SIP Diversion header of 3xx messages) exist: out-of-service - all trunks are unavailable (disconnected) "unavailable" - all trunks are busy or unavailable The format of this parameter is as follows: [ForwardOnBusyTrunkDest] SIP Release Notes 60 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter [SASEnableContactRepla ce] Web: Enable Record-Route [SASEnableRecordRoute] Description FORMAT ForwardOnBusyTrunkDest_Index = ForwardOnBusyTrunkDest_TrunkGroupId, ForwardOnBusyTrunkDest_ForwardDestination; [\ForwardOnBusyTrunkDest] Where: TrunkGroupId = Trunk Group for which you want to define a call forwarding destination. The default is 0. ForwardDestination = Alternative destination, using the syntax "host:port;transport=xxx"(i.e., IP address, port and transport type). For example, the below configuration forwards IP-to-Tel calls to destination IP address 10.13.4.12, port 5060 using transport protocol TCP, if Trunk Group ID 2 is busy: ForwardOnBusyTrunkDest 1 = 2, 10.13.4.12:5060;transport=tcp; Notes: The maximum number of indices (starting from Index 1) depends on the maximum number of Hunt/Trunk Groups. For the destination, instead of a dotted-decimal IP address, FQDN can be used. Enables the device to change the Contact header so that it points to the SAS host, and therefore, the top-most Via header and the Contact header point to the same host. [0] (default) = Disable - when relaying requests, the SAS agent adds a new SIP Via header (with the SAS IP address) as the topmost Via header and retains the original SIP Contact header. Thus, the top-most Via header and the Contact header point to different hosts. [1] = Enable - the device changes the Contact header so that it points to the SAS host and therefore, the top-most Via header and the Contact header point to the same host. Note: Operating in this mode causes all incoming dialog requests to traverse the SAS and thus, may cause load problems. Determines whether the device's SAS application adds the SIP Record-Route header to SIP requests. This ensures that SIP messages traverse the device's SAS agent, by including the SAS IP address in the Record-Route header. [0] Disable (default) [1] Enable The Record-Route header is inserted in a request by a SAS proxy to force future requests in the dialog session to be routed through the SAS agent. Each traversed proxy in the path can insert this header, causing all future dialogs in the session to pass through it as well. When this feature is enabled, the SIP Record-Route header includes the URI "lr" parameter. The presence of this parameter indicates loose routing; the lack of 'lt' indicates strict routing. For example: Loose routing: Record-Route: <sip:server10.biloxi.com;lr> Strict routing: Record-Route: <sip:bigbox3.site3.atlanta.com> Version 6.0 61 February 2010

Mediant 2000 & Mediant 3000 Parameter Web: LDAP Service [LDAPServiceEnable] Web: LDAP Server IP [LDAPServerIP] Web: LDAP Server Port [LDAPServerPort] Web: LDAP Server Domain Name [LDAPServerDomainName ] Web: LDAP Password [LDAPPassword] Web: LDAP Bind DN [LDAPBindDN] Web: LDAP Search Dn [LDAPSearchDN] Web: LDAP Server Max Respond Time [LDAPServerMaxRespond Time] [LDAPDebugMode] Web: MS LDAP OCS Number attribute name [MSLDAPOCSNumAttribut ename] Web: MS LDAP PBX Number attribute name [MSLDAPPBXNumAttribut ename] Web: MS LDAP MOBILE Number attribute name [MSLDAPMobileNumAttrib utename] [0] Disable (default) Description Determines whether to enable the LDAP service. [1] Enable Note: For this parameter to take effect, a device reset is required. Defines the LDAP server's IP address in dotted-decimal notation (e.g., 192.10.1.255). The default is 0.0.0.0. Defines the LDAP server's port number. The valid value range is 0 to 65535. The default port number is 389. Defines the host name of the LDAP server. Defines the LDAP server's user password. Defines the LDAP server's bind DN. This is used as the username during connection and binding to the server. For example: LDAPBindDN = "CN=Search user,ou=labs,dc=ocsr2,dc=local" Defines the search DN for LDAP search requests. This is the top DN of the subtree where the search is performed. This parameter is mandatory for the search. For example: LDAPSearchHDN = "CN=Search user,ou=labs,dc=ocsr2,dc=local" Defines the time (in seconds) that the device waits for LDAP server responses. The valid value range is 0 to 86400. The default is 3000. Determines whether to enable the LDAP task debug messages. This is used for providing debug information regarding LDAP tasks. The valid value range is 0 to 3. The default is 0. The name of the attribute that represents the user OCS number in the Microsoft AD database. The valid value is a string of up to 49 characters. The default is "msrtcsip-primaryuseraddress". The name of the attribute that represents the user PBX number in the Microsoft AD database. The valid value is a string of up to 49 characters. The default is "telephonenumber". The name of the attribute that represents the user Mobile number in the Microsoft AD database. The valid value is a string of up to 49 characters. The default is "mobile". SIP Release Notes 62 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter [EnableRekeyAfter181] Web: Min Routing Overlap Digits [MinOverlapDigitsForRout ing] Web: ISDN Overlap IP to Tel Dialing [ISDNTxOverlap] Web: Add CIC [AddCicAsPrefix] Description Enables the device to send a Re-INVITE with a new (different) SRTP key (in the SDP) upon receipt of a SIP 181 response ("call is being forwarded"). [0] Disable (default) [1] Enable Note: This parameter is applicable only if SRTP is used. Minimum number of overlap digits to collect (for ISDN overlap dialing) before sending the first SIP message for routing Tel-to-IP calls. The valid value range is 0 to 49. The default is 1. Note: This parameter is applicable when the ISDNRxOverlap parameter is set to [2]. Enables ISDN overlap IP-to-Tel dialing. This feature is part of ISDN-to- SIP overlap dialing according to RFC 3578. [0] Disable (default) [1] Enable When enabled, for each received INVITE of the same dialog session, the device sends an ISDN Setup (and subsequent ISDN INFO Q.931 messages) with the collected digits to the Tel side. For all subsequent INVITEs received, the device sends a SIP 484 Address Incomplete response to maintain the current dialog session and receive additional digits from subsequent INVITEs. Note: When IP-to-Tel overlap dialing is enabled, to send ISDN Setup message without Sending Complete IE, the CC_USER_SENDING_COMPLETE bit (=2) must be enabled for the ISDNOutgoingCallsBehavior parameter. Determines whether to add the Carrier Identification Code (CIC) as a prefix to the destination phone number for IP-to-Tel calls. [0] No (default) [1] When this parameter is enabled, the cic parameter in the incoming SIP INVITE can be used for IP-to-Tel routing decisions. It routes the call to the appropriate Trunk Group based on this parameter's value. The SIP cic parameter enables the transmission of the cic parameter from the SIP network to the ISDN (CIC=+<country code of carrier><cic of preferred interlata carrier of caller>). The cic parameter is a three- or four- digit code used in routing tables to identify the network that serves the remote user when a call is routed over many different networks. The cic parameter is carried in SIP INVITE and maps to the ISDN Transit Network Selection Information Element (TNS IE) in the outgoing ISDN SETUP message (if the EnableCIC parameter is set to 1). The TNS IE identifies the requested transportation networks and allows different providers equal access support, based on customer choice. For example: INVITE sip:5550001;cic=+16789@172.18.202.60:5060;user=phone SIP/2.0 The destination number after number manipulation is Version 6.0 63 February 2010

Mediant 2000 & Mediant 3000 Parameter Web: Mute DTMF In Overlap [MuteDTMFInOverlap] Web: Fake Retry After [sec] [FakeRetryAfter] [TDMoIPInitiateInviteTime] [TDMoIPInviteRetryTime] cic+167895550001. Description Note: After the cic prefix is added, the IP-to-Trunk Group Routing table can be used to route this call to a specific Trunk Group. The Destination Number IP to Tel Manipulation table must be used to remove this prefix before placing the call to ISDN. Enables the muting of in-band DTMF detection until the device receives the complete destination number from the ISDN (for Tel-to-IP calls). In other words, the device does not accept DTMF digits received in the voice stream from the PSTN, but only accepts digits from PSTN INFO messages. [0] Don't Mute (default) [1] Mute DTMF in Overlap Dialing = The device ignores in-band DTMF digits received during ISDN overlap dialing (disables the DTMF in-band detector). Notes: When enabled and at least one digit is received from the ISDN (Setup), the device stops playing a dial tone. This parameter is applicable only to ISDN Overlap mode, when dialed numbers are sent using Q.931 INFO messages. Determines whether the device, upon receipt of a SIP 503 response without a Retry-After header, behaves as if the 503 response includes a Retry-After header and with the period (in seconds) specified by this parameter. [0] Disable Any positive value (in seconds) for enabling this feature When enabled, this feature allows the device to operate with proxy servers that do not include the Retry-After SIP header in SIP 503 (Service Unavailable) responses to indicate an unavailable service. The Retry-After header is used with the 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting SIP client. The device maintains a list of available proxies, by using the Keep-Alive (KA) mechanism. The device checks the availability of proxies by sending SIP OPTIONS every KA timeout to all proxies. If the device receives a SIP 503 response to an INVITE, it also marks that the proxy is out of service for the defined "Retry-After" period. Determines the time (in msec) between the first INVITE issued within the same trunk when implementing the TDM tunneling application. The valid value range is: Mediant 2000: 500 to 1000. The default is 500. Mediant 3000: 2000 to 4000. The default is 2000. Determines the time (in msec) between call release and a new INVITE when implementing the TDM tunneling application. The valid value range is: Mediant 2000: 10,000 to 20,000. The default is 10,000. Mediant 3000: 30,000 to 60,000. The default is 30,000. SIP Release Notes 64 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter [UseBroadsoftDTG] Web: TGRP Routing Precedence [TGRProutingPrecedence] Web: Enable Early 183 [EnableEarly183] [0] Disable (default) Description Determines whether the device uses the dtg parameter for routing IP-to-Tel calls to a specific Trunk Group. [1] Enable When this parameter is enabled, if the Request URI in the received SIP INVITE includes the dtg parameter, the device routes the call to the Trunk Group according to its value. This parameter is used instead of the "tgrp/trunk-context" parameters. The "dtg" parameter appears in the INVITE Request URI (and in the To header). For example, the received SIP message below routes the call to Trunk Group ID 56: INVITE sip:123456@192.168.1.2;dtg=56;user=phone SIP/2.0 Note: If the Trunk Group is not found based on the "dtg" parameter, the IP to Trunk Group Routing table is used instead for routing the call to the appropriate Trunk Group. Determines the precedence method for routing IP-to-Tel calls - according to the IP to Trunk Group Routing table or tgrp/dtg parameters. [0] (default) = IP-to-Tel routing is determined by the IP to Trunk Group Routing table (PSTNPrefix ini file parameter). If a matching rule is not found in this table, the device uses the Trunk Group parameters for routing the call. [1] = The device first places precedence on the tgrp/dtg parameters for IP-to-Tel routing. If the received INVITE request URI does not contain the tgrp/dtg parameters, or if the Trunk Group number is not defined, then the IP to Trunk Group Routing table is used for routing the call. Below is an example of an INVITE request URI with the tgrp parameter, indicating that the IP call should be routed to Trunk Group 7: INVITE sip:200;tgrp=7;trunkcontext=example.com@10.33.2.68;user=phone SIP/2.0 Notes: For enabling routing based on the SIP tgrp parameter, the UseSIPTgrp parameter must be set to 2. For IP-to-Tel routing based on the dtg parameter (instead of the tgrp parameter), use the parameter UseBroadsoftDTG Determines whether the device sends a SIP 183 response with SDP to the IP immediately upon receipt of an INVITE message (for IP-to- Tel calls). The device sends the RTP packets only once it receives an ISDN Progress, Alerting with Progress indicator, or Connect message from the PSTN. [0] Disable (default) [1] Enable For example, if enabled and the device receives an ISDN Progress message, it starts sending RTP packets according to the initial negotiation without sending the 183 response again. Therefore, this feature reduces clipping of early media. Version 6.0 65 February 2010

Mediant 2000 & Mediant 3000 Parameter Web: SIT Q850 Cause For NC [SITQ850CauseForNC] Web: SIT Q850 Cause For IC [SITQ850CauseForIC] Web: SIT Q850 Cause For VC [SITQ850CauseForVC] Web: SIT Q850 Cause For RO [SITQ850CauseForRO] [SelectSourceHeaderForC allednumber] Web: Enable RFC 4117 Transcoding [EnableRFC4117Transcod ing] Notes: Description To enable this feature, the EnableEarlyMedia parameter must also be set to 1. This feature is applicable only to ISDN interfaces. Determines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-NC (No Circuit Found Special Information Tone) is detected from the PSTN for IP-to- Tel calls. The valid range is 0 to 127. The default value is 34. Note: When not configured (i.e., default), the SITQ850Cause parameter is used. Determines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-IC (Operator Intercept Special Information Tone) is detected from the PSTN for IPto-Tel calls. The valid range is 0 to 127. The default value is -1 (not configured). Note: When not configured (i.e., default), the SITQ850Cause parameter is used. Determines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-VC (Vacant Circuit - non-registered number Special Information Tone) is detected from the PSTN for IP-to-Tel calls. The valid range is 0 to 127. The default value is -1 (not configured). Note: When not configured (i.e., default), the SITQ850Cause parameter is used. Determines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when SIT-RO (Reorder - System Busy Special Information Tone) is detected from the PSTN for IP-to-Tel calls. The valid range is 0 to 127. The default value is -1 (not configured). Note: When not configured (i.e., default), the SITQ850Cause parameter is used. Determines the SIP header used for obtaining the called (destination) number (for IP-to-Tel calls). [0] Request-URI header (default) = Obtains the destination number from the user part of the Request-URI. [1] To header = Obtains the destination number from the user part of the To header. [2] P-Called-Party-ID header = Obtains the destination number from the P-Called-Party-ID header. Enables transcoding of calls according to RFC 4117. [0] Disable (default) [1] Enable Note: For this parameter to take effect, a device reset is required. SIP Release Notes 66 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description [UnregistrationMode] [MaxBundleSyslogLength] [NotificationIPGroupID] Web: Coders Table/Coder Group Settings [CodersGroup0] [CodersGroup1] [CodersGroup2] [CodersGroup3] [CodersGroup4] Determines whether the device performs an explicit unregister. [0] Disable (default) [1] Enable = The device sends an asterisk ( * ) value in the Contact header, instructing the registrar server to remove all previous registration bindings. This parameter removes SIP UA registration bindings in a Registrar, according to RFC 3261. Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UAs should support this mechanism so that bindings can be removed before their expiration interval has passed. Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record (AOR) without knowing their precise values. Note: The REGISTER-specific Contact header field value of "*" applies to all registrations, but it can only be used if the Expires header field is present with a value of "0". The maximum size (in bytes) threshold of logged, bundled (into a single UDP packet) Syslog messages, after which they are sent to a Syslog server. The valid value range is 0 to 1220 (where 0 indicates that no bundling occurs). The default is 1220. Note: This parameter is applicable only if the GWDebugLevel parameter is set to 7. Determines the IP Group ID to where the device sends SIP NOTIFY MWI messages. This ini file table parameter defines the device's coders. Up to five groups of coders can be defined, where each group can consist of up to 10 coders. The first Coder Group is the default coder list and the default Coder Group. These Coder Groups can later be assigned to IP or Tel Profiles. The format of this parameter is as follows: [ CodersGroup0] FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime, CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce; [ \CodersGroup0 ] Where, Index = Coder entry 0-9, i.e., up to 10 coders per group. Name = Coder name. Ptime = Packetization time (ptime) - how many coder payloads are combined into a single RTP packet. Rate = Packetization rate. PayloadType = Identifies the format of the RTP payload. Version 6.0 67 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Sce = Enables silence suppression: [0] Disabled (default) [1] Enabled For example, below are defined two Coder Groups (0 and 1): [ CodersGroup0 ] FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime, CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce; CodersGroup0 0 = g711alaw64k, 20, 0, 255, 0; CodersGroup0 1 = eg711ulaw, 10, 0, 71, 0; CodersGroup0 2 = eg711ulaw, 10, 0, 71, 0; [ \CodersGroup0 ] [ CodersGroup1 ] FORMAT CodersGroup1_Index = CodersGroup1_Name, CodersGroup1_pTime, CodersGroup1_rate, CodersGroup1_PayloadType, CodersGroup1_Sce; CodersGroup1 0 = Transparent, 20, 0, 56, 0; CodersGroup1 1 = g726, 20, 0, 23, 0; [ \CodersGroup1 ] The table below lists the supported coders: Coder Name Packetization Time (msec) Rate (kbps) Payload Type Silence Suppression G.711 A-law 10, 20 (default), [g711alaw6 30, 40, 50, 60, 4k] 80, 100, 120 G.711 U-law [g711ulaw6 4k] 10, 20 (default), 30, 40, 50, 60, 80, 100, 120 Always 64 Always 8 Disable [0] Enable [1] Always 64 Always 0 Disable [0] Enable [1] EG.711 A- law [eg711alaw] 10 (default), 20, 30 Always 64 Dynamic (96-127) N/A EG.711 U- law [eg711ulaw] 10 (default), 20, 30 Always 64 Dynamic (96-127) N/A G.729 [g729] 10, 20 (default), 30, 40, 50, 60, 80, 100 Always 8 Always 18 Disable [0] Enable [1] Enable w/o Adaptations [2] G.729.1 [g7291] 20 (default), 40, 60, 80, 100, 120 8, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32 (default) Dynamic (0-120) N/A G.722 [g722] 20 (default), 40, 60, 80, 100, 120 64 (default) Always 9 N/A G.723.1 [g7231] 30 (default), 60, 90, 120 5.3 [0], 6.3 [1] (default) Always 4 Disable [0] Enable [1] G.726 [g726] 10, 20 (default), 30, 40, 50, 60, 80, 100, 120 16 [0], 24 [1], 32 [2] (default) 40 [3] Dynamic (0-120) Disable [0] Enable [1] SIP Release Notes 68 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description GSM-FR [gsmfullrat e] 20 (default), 40, 60, 80 Always 13 Always 3 Disable [0] Enable [1] GSM-EFR [gsmenhanc edfullrate] AMR [Amr] AMR-WB [Amr-WB] 0, 20 (default), 30, 40, 50, 60, 80, 100 20 (default) 4.75 [0], 5.15 [1], 5.90 [2], 6.70 [3], 7.40 [4], 7.95 [5], 10.2 [6], 12.2 [7] (default) 20 (default) 6.6 [0], 8.85 [1], 12.65 [2], 14.25 [3], 15.85 [4], 18.25 [5], 19.85 [6], 23.05 [7], 23.85 [8] (default) 12.2 Dynamic (0-127) Dynamic (0-120) Dynamic (0-120) Disable [0] Enable [1] Disable [0] Enable [1] Disable [0] Enable [1] EVRC [Evrc] 20 (default), 40,60, 80, 100 Variable [0] (default), 1/8 [1], 1/2 [3], Full [4] Dynamic (0-120) Disable [0] Enable [1] EVRC-B (4GV) [EvrcB] 20 (default), 40, 60, 80, 100, 120 Variable [0] (default), 1/8 [1], 1/4 [2], 1/2 [3], Full [4] Dynamic (0-120) N/A ilbc [ilbc] 20 (default), 40, 60, 80, 100, 120 15 (default) Dynamic (0-120) Disable [0] Enable [1] 30 (default), 60, 90, 120 13 MS-GSM [gsmms] 40 (default) Always 13 Always 3 Disable [0] Enable [1] QCELP [QCELP] Transparent [Transparen t] 20 (default), 40, 60, 80, 100, 120 20 (default), 40, 60, 80, 100, 120 Always 13 Always 12 Disable [0] Enable [1] Always 64 Dynamic (0-120) Disable [0] Enable [1] G.711Alaw_VBD [g711alawv bd] 10, 20 (default), 30, 40, 50, 60, 80, 100, 120 Always 64 Dynamic (0-120) N/A G.711Ulaw_VBD [g711ulawv bd] 10, 20 (default), 30, 40, 50, 60, 80, 100, 120 Always 64 Dynamic (0-120) N/A T.38 [t38fax] MS RTA (NB) N/A 20 (default), 40, 60, 80 N/A N/A N/A Variable 73 N/A Version 6.0 69 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Notes: The coder name is case-sensitive. Each coder type can appear only once per Coder Group. Only the packetization time of the first coder in the defined 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. If silence suppression is not defined for a specific coder, the value defined by the parameter EnableSilenceCompression is used. If G.729 is selected and silence suppression is enabled (for this coder), the device includes the string 'annexb=no' in the SDP of the relevant SIP messages. If silence suppression is set to 'Enable w/o Adaptations', 'annexb=yes' is included. An exception is when the remote device is a Cisco gateway (IsCiscoSCEMode). Silence suppression is currently not supported for the MS RTA coder. The coder G.722 provides Packet Loss Concealment (PLC) capabilities, ensuring higher voice quality. Both GSM-FR and MS-GSM coders use Payload Type 3. When using SDP, it isn t possible to differentiate between the two. Therefore, it is recommended not to select both coders simultaneously. A pre-defined table can be configured to provide a set of rules for automatic AMR rate change. The decision for the change is based upon packet loss rate. SIP Release Notes 70 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.10.2 B2BUA Transcoding Parameters The table below describes the new B2BUA application parameters for Release 6.0. Table 1-2: New B2BUA Transcoding Parameters for Release 6.0 Parameter Web: Enable B2BUA Application [EnableSBCApplication] Web: Enable IP2IP Application [EnableIP2IPApplication] [ProxySet] [Account] [IPProfile] Description Enables the Back-to-Back User Agent (B2BUA) Transcoding application. [0] Disable (default) [1] Enable Notes: For this parameter to take effect, a device reset is required. In addition to enabling this parameter, the number of maximum IP-to-IP SIP dialog sessions must be defined in the Software Upgrade Key. Enables the IP-to-IP call routing application. [0] Disable (default) [1] Enable Note: For this parameter to take effect, a device reset is required. Parameter added to existing Proxy Set table: [ProxySet_SRD] SRD Index: The SRD associated with the Proxy Set ID. Note: If no SRD is defined for this parameter, by default, SRD ID 0 is associated with the Proxy Set. Parameter added to existing Account table: [ApplicationType]: [0] GW/IP2IP (default); [2] B2BUA Parameters added to existing IP Profile table: [IpProfile_SBCExtensionCodersGroupID] SBC Extension Coders Group ID: Defines the Coder Group ID for extended (additional) coders. This is used when transcoding is required between two user agents (i.e., the SDP answer from one user agent doesn t include any coder included in the offer previously sent by the other user agent). Therefore, to allow user agents of different IP Groups to communicate with each other (regardless of their capabilities), an extended coders table with at least one coder that is supported by each IP Groups' user agents needs to be assigned to each IP Group. Therefore, each offer destined to specific IP Groups include this coder. [IPProfile_TranscodingMode] Transcoding Mode: Defines the voice transcoding mode (media negotiation) for the SBC application, between the two SBC legs. [0] Only if Required = Do not force (default). Many of the media settings (such as gain control) are not implemented on the voice stream. The SBC application passes packets RTP to RTP without any processing. [1] Force = Force transcoding on outgoing SBC leg. The device's SBC application interworks the media by implementing DSP transcoding. Version 6.0 71 February 2010

Mediant 2000 & Mediant 3000 [IPGroup] Parameter [WanMgmtHttpPort] [WanMgmtHttpsPort] Web: Transcoding Mode [TranscodingMode] Web: Allow Unclassified Calls [AllowUnclassifiedCalls] Default CP Media Realm Name [cpdefaultmediarealmnam e] Description Parameters added to existing IP Group table [IPGroup_SRD] SRD: The SRD associated with the IP Group. The default is 0. [IPGroup_MediaRealm] Media Realm: The Media Realm name associated with this IP Group. [IPGroup_ClassifyByProxySet] Classify By Proxy Set: Determines whether the incoming INVITE is classified to an IP Group according to the Proxy Set: [0] Disable; [1] Enable (default) WAN HTTP port number. This parameter allows remote device Web management from the WAN. To enable Web management from the WAN, configure the desired port (e.g., port 80, which is the default HTTP port). The default is 0 (i.e., no remote Web management). Note: If the parameter HTTPSOnly is set to 1, HTTP access is not allowed. WAN HTTPS port number. This parameter allows secure remote device Web management from the WAN. To enable secure Web management, configure the desired port (e.g., port 443). The default is 0 (i.e., remote Web management is not secured). Defines the voice transcoding mode (media negotiation) for the SBC application, between the two SBC legs. [0] Only if Required = Do not force (default). Many of the media settings (such as gain control) are not implemented on the voice stream. The SBC application passes packets RTP to RTP without any processing. [1] Force = Force transcoding on outgoing SBC leg. The device's SBC application interworks the media by implementing DSP transcoding. Note: This parameter can also be defined for an IP Profile (using the IPProfile parameter). Determines whether calls (incoming packets) that cannot be classified (i.e. classification process fails) into a Source IP Group (in the Classification table) are either rejected or processed. [0] Reject = the call is rejected if classification fails. [1] Allow = if classification fails, the incoming packet is assigned to the default IP Group of the default SRD (and the call is subsequently processed). (Default.) Defines any one of the realms listed in the SIP Media Realm table as the default Media Realm. This default is used when no Media Realm is configured for an IP Group or SRD for a specific call. The valid range is a string of up to 39 characters. Notes: If this parameter is not configured, then the first Media Realm configured in the SIP Media Realm table (cpmediarealm) is used as the default Media Realm. If the SIP Media Realm table is not configured, then the default Media Realm includes all the device's media interfaces. SIP Release Notes 72 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description Web: SIP Media Realm Table [CpMediaRealm] Web: Signaling Routing Domain (SRD) Table This ini file table parameter configures the SIP Media Realm table. The Media Realm table allows you to divide a Media-type interface (defined in the Multiple Interface table) into several realms, where each realm is specified by a UDP port range. Once created, the Media Realm can be assigned to an IP Group (in the IP Group) or SRD (in the SRD table). The format of this parameter is as follows: [CpMediaRealm] FORMAT CpMediaRealm_Index = CpMediaRealm_MediaRealmName, CpMediaRealm_IPv4IF, CpMediaRealm_IPv6IF, CpMediaRealm_PortRangeStart, CpMediaRealm_MediaSessionLeg, CpMediaRealm_PortRangeEnd; [\CpMediaRealm] For example, CpMediaRealm 1 = Mrealm1, Voice,, 6600, 20, 6790; CpMediaRealm 2 = Mrealm2, Voice,, 6800, 10, 6890; Notes: If different Media Realms are assigned to an IP Group and SRD, the IP Group s Media Realm takes precedence. This table can include up to 16 indices (where 0 is the first index). However, only up to 8 Media Realms can be used by the device (as a maximum of 8 IP Groups can be configured). Each table index must be unique. For this parameter to be effective, a device reset is required. The parameter cpdefaultmediarealmname can be used to define one of the Media Realms appearing in this table as the default Media Realm, if no Media Realm is assigned to an SRD or IP Group for a specific call. If the parameter cpdefaultmediarealmname is not configured, then the first Media Realm appearing in this table is used as the default Media Realm. If this table is not configured, then the default realm includes all defined media interfaces. [SRD] This ini file table parameter configures the Signaling Routing Domain (SRD) table. The format of this parameter is as follows: [[SRD] FORMAT SRD_Index = SRD_Name, SRD_MediaRealm, SRD_IntraSRDMediaAnchoring, SRD_BlockUnRegUsers, SRD_MaxNumOfRegUsers, SRD_EnableUnAuthenticatedRegistrations; [\SRD] For example: SRD 1 = NW1_SRD, MR1, 1, 1, -1, 1; SRD 2 = NW2_SRD, MR1, 1, 1, -1, 1; Note: This table can include up to 5 indices (where 0 is the first index). Version 6.0 73 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Web: SIP Interface Table [SIPInterface] Web: SBC Classification Table This ini file table parameter configures the SIP Interface table. The SIP Interface represents a SIP signaling entity, comprising ports (UDP, TCP, and TLS) and associated with a specific IP address and an SRD ID. SIP Interfaces allow you (for example) to use different SIP signaling interfaces for each of the two SBC legs. The format of this parameter is as follows: [SIPInterface] FORMAT SIPInterface_Index = SIPInterface_NetworkInterface, SIPInterface_ApplicationType, SIPInterface_UDPPort, SIPInterface_TCPPort, SIPInterface_TLSPort, SIPInterface_SRD; [\SIPInterface] For example: SIPInterface 0 = Voice, 2, 5060, 5060, 5061, 1; SIPInterface 1 = Voice, 2, 5070, 5070, 5071, 2; SIPInterface 2 = Voice, 0, 5090, 5000, 5081, 2; Notes: This table can include up to 6 indices (where 0 is the first index). Each SIP Interface must have a unique signaling port (i.e., no two SIP Interfaces can share the same port - no port overlapping). You can define up to three different SIP Interfaces per SRD, where each SIP Interface pertains to a different application type (i.e., GW, SAS, and SBC). [Classification] This ini file table parameter configures the Classification table for SBC. This table classifies the incoming SIP INVITE to a Source IP Group. The format of this parameter is as follows: [Classification] FORMAT Classification_Index = Classification_SrcIPGroupID, Classification_SrcSRDID, Classification_SrcAddress, Classification_SrcUsernamePrefix, Classification_SrcHost, Classification_DestUsernamePrefix, Classification_DestHost; [\Classification] For example: Classification 1 = -1, -1,, *, *, *, *; Notes: This table can include up to 20 indices (where 0 is the first index). For a specific classification rule to be effective, the matching characteristics must match. If this classification process fails to determine the Source IP Group to which the incoming packet belongs, the call can either be rejected or assigned to the default IP Group of the default SRD (and processed), according to the parameter AllowUnclassifiedCalls. This table is applicable only for the SBC application. SIP Release Notes 74 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description Web: IP-to-IP Routing Table [IP2IPRouting] This ini file table parameter configures the IP-to-IP Routing table for routing received SIP INVITE messages to a destination IP address. The format of this parameter is as follows: [IP2IPRouting] FORMAT IP2IPRouting_Index = IP2IPRouting_SrcIPGroupID, IP2IPRouting_SrcUsernamePrefix, IP2IPRouting_SrcHost, IP2IPRouting_DestUsernamePrefix, IP2IPRouting_DestHost, IP2IPRouting_DestType, IP2IPRouting_DestIPGroupID, IP2IPRouting_DestSRDID, IP2IPRouting_DestAddress, IP2IPRouting_DestPort, IP2IPRouting_DestTransportType, IP2IPRouting_AltRouteOptions; [\IP2IPRouting] For example: IP2IPRouting 1 = -1, *, *, *, *, 0, -1, -1,, 0, -1, 0; Notes: Web: Alternative Routing Reasons Table This table can include up to 120 indices (where 0 is the first index). For a specific routing rule to be effective, the matching characteristics must match. If no matching rule is located, the call is rejected. If neither Destination SRD nor Destination IP Group are configured, the destination SRD is the source SRD and the destination IP Group is its default IP Group. [SBCAlternativeRoutingRea sons] This ini file table parameter configures the SBC Alternative Routing Reasons table. This table is used for alternative IP-to-IP routing (defined in the IP2IP Routing table). If 4xx, 5xx, or 6xx SIP responses are received as a result of outgoing INVITE (or OPTIONS, SUBSCRIBE and other dialog initiating methods), the device re-sends this message if the response is defined in this table, and if there is an alternative route in the IP2IP Routing table. The format of this parameter is as follows: [ SBCAlternativeRoutingReasons ] FORMAT SBCAlternativeRoutingReasons_Index = SBCAlternativeRoutingReasons_ReleaseCause; [ \SBCAlternativeRoutingReasons ] For example: SBCAlternaiveRoutingReasons 0 = 403; SBCAlternativeRoutingReasons 1 = 404; Note: This table can include up to five indices (where 0 is the first index). Version 6.0 75 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Web: IP to IP Inbound Manipulation Table [IPInboundManipulation] This ini file table parameter configures the IP to IP Inbound Manipulation table. This table allows you to manipulate the SIP URI user part (source and/or destination) of the inbound INVITE message. The format of this parameter is as follows: [IPInboundManipulation] FORMAT IPInboundManipulation_Index = IPInboundManipulation_IsAdditionalManipulation, IPInboundManipulation_ManipulatedURI, IPInboundManipulation_ManipulationPurpose, IPInboundManipulation_SrcIPGroupID, IPInboundManipulation_SrcUsernamePrefix, IPInboundManipulation_SrcHost, IPInboundManipulation_DestUsernamePrefix, IPInboundManipulation_DestHost, IPInboundManipulation_RequestType, IPInboundManipulation_RemoveFromLeft, IPInboundManipulation_RemoveFromRight, IPInboundManipulation_LeaveFromRight, IPInboundManipulation_Prefix2Add, IPInboundManipulation_Suffix2Add; [\IPInboundManipulation] For example: IPInboundManipulation 1 = 0, 0, -1, *, *, *, *, 0, 0, 255,, ; Notes: Web: IP to IP Outbound Manipulation Table This table can include up to 100 indices. For a specific manipulation rule to be effective, the matching characteristics must match. Manipulated destination SIP URI user names are done in the following SIP headers: Request URI, To, and Remote Party ID (if exists). Manipulated source SIP URI user names are done in the following SIP headers: From, P-Asserted (if exists), P-Preferred (if exists), and Remote Party ID (if exists). For SIP URI host name (source and destination) manipulations, use the 'IP Group' table. These host names are simply replaced with the names configured for the Source and Destination IP Groups respectively. [IPOutboundManipulation] This ini file table parameter configures the IP to IP Outbound Manipulation table. This table allows you to manipulate the SIP URI user part (source and/or destination) of the outbound INVITE message. The format of this parameter is as follows: [ IPOutboundManipulation ] FORMAT IPOutboundManipulation_Index = IPOutboundManipulation_IsAdditionalManipulation, IPOutboundManipulation_ManipulatedURI, IPOutboundManipulation_SrcIPGroupID, IPOutboundManipulation_DestIPGroupID, IPOutboundManipulation_SrcUsernamePrefix, IPOutboundManipulation_SrcHost, IPOutboundManipulation_DestUsernamePrefix, SIP Release Notes 76 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description IPOutboundManipulation_DestHost, IPOutboundManipulation_RemoveFromLeft, IPOutboundManipulation_RemoveFromRight, IPOutboundManipulation_LeaveFromRight, IPOutboundManipulation_Prefix2Add, IPOutboundManipulation_Suffix2Add; For example: IPOutboundManipulation 1 = 0, 0, -1, -1, *, *, *, *, 0, 0, 255,, ; Notes: This table can include up to 100 indices (where 0 is the first index). For a specific manipulation rule to be effective, the matching characteristics must match. IP-to-IP manipulation rules apply to INVITE and other dialog initiating SIP messages (except REGISTER messages). Manipulated destination SIP URI user names are done in the following SIP headers: Request URI, To, and Remote Party ID (if exists). Manipulated source SIP URI user names are done in the following SIP headers: From, P-Asserted (if exists), P-Preferred (if exists), and Remote Party ID (if exists). For SIP URI host name (source and destination) manipulations, use the 'IP Group' table. These host names are simply replaced with the names configured for the Source and Destination IP Groups respectively. Version 6.0 77 February 2010

Mediant 2000 & Mediant 3000 1.10.3 Voice, RTP and RTCP Parameters The table below describes the new voice, RTP and RTCP parameters for Release 6.0. Table 1-3: New Voice, RTP and RTCP Parameters for Release 6.0 Web: T38 Version [T38Version] Parameter Web: Microsoft RTA Bit Rate [MSRTATxBitRate] Web: Microsoft RTA Forward Error Correction Mode [MSRTAForwardErrorCorrectionEnable] Web: AMD Beep Detection Mode [AMDBeepDetectionMode] Web: Answer Machine Detector Beep Detection Timeout [AMDBeepDetectionTimeout] Web: Answer Machine Detector Beep Detection Sensitivity [AMDBeepDetectionSensitivity] Description Selects the T.38 fax relay version. [0] T.38 version 0 (default) [1] T.38 version 1 [2] T.38 version 2 [3] T.38 version 3 = T.38 Version 3 (V.34 over T.38 support) Determines the transmit (Tx) bit rate for the Microsoft real-time audio, narrowband coder (MS RTA NB) at clock rate of 8 khz. The valid values are 0 or any value between 8,800 to 29,000. The default is 0 (i.e., automatically determined according to received RTCP). Enables or disables the Forward Error Correction (FEC) mode for the coder MS RTA NB. [0] Disable [1] Enable (default) Determines the AMD beep detection mode. This mode detects the beeps played at the end of an answering machine message, by using the X-Detect header extension. The device sends a SIP INFO message containing the field values Type=AMD and SubType=Beep. This feature allows users of certain third-party, Application server to leave a voice message after an answering machine plays the beep. [0] Disabled (default) [1] Start After AMD [2] Start Immediately Determines the Answer Machine Detector (AMD) Beep detection timeout. This is used for detecting beeps at the end of an answering machine message. The valid value is in units of 100 milliseconds, from 0 to 1638. The default value is 200 (i.e., 20 seconds). Determines the AMD Beep detection sensitivity. The valid value is 0 to 3, where 0 is the least sensitive. The default is 0. SIP Release Notes 78 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Web: Answer Machine Detector High Resolution Sensitivity [AMDDetectionSensitivityHighResolution] Web: Answer Machine Detector Sensitivity Resolution [AMDSensitivityResolution] [AMDMinimumVoiceLength] Description Determines the AMD high-resolution detection sensitivity. The high resolution has 16 levels of sensitivity (while the normal resolution, configured by the parameter AMDDetectionSensitivity has only 8 levels). The valid value range is 0 (for best detection of an answering machine) to 15 (for best detection of a live call). The default value is 8. Determines the AMD detection sensitivity resolution (normal or high). [0] Normal (default) = Normal detection sensitivity resolution (8 sensitivity levels). [1] High = High detection sensitivity resolution (16 sensitivity levels). Determines the AMD minimum voice activity detection (in 5-ms units). Voice activity duration below this threshold is ignored and considered as non-voice. The valid value range is 10 to 100. The default is 42 (i.e., 210 ms). Version 6.0 79 February 2010

Mediant 2000 & Mediant 3000 1.10.4 Security Parameters The table below describes the new security parameters for Release 6.0. Table 1-4: New Security Parameters for Release 6.0 Parameter Description Web: IP Security Associations Table [IPSecSATable] This ini file table parameter configures the IPSec SA table. This table allows you to configure the Internet Key Exchange (IKE) and IP Security (IPSec) protocols. You can define up to 20 IPSec peers. The format of this parameter is as follows: [ IPsecSATable ] FORMAT IPsecSATable_Index = IPsecSATable_RemoteEndpointAddressOrName, IPsecSATable_AuthenticationMethod, IPsecSATable_SharedKey, IPsecSATable_SourcePort, IPsecSATable_DestPort, IPsecSATable_Protocol, IPsecSATable_Phase1SaLifetimeInSec, IPsecSATable_Phase2SaLifetimeInSec, IPsecSATable_Phase2SaLifetimeInKB, IPsecSATable_DPDmode, IPsecSATable_IPsecMode, IPsecSATable_RemoteTunnelAddress, IPsecSATable_RemoteSubnetIPAddress, IPsecSATable_RemoteSubnetPrefixLength; [ \IPsecSATable ] Where: RemoteEndpointAddressOrName = IP address or DNS host name of the peer. AuthenticationMethod = Method used for peer authentication during IKE main mode. SharedKey = Defines the pre-shared key (in textual format). SourcePort = Defines the source port to which this configuration applies. DestPort = Defines the destination port to which this configuration applies. Protocol = Defines the protocol type to which this configuration applies. Standard IP protocol numbers should be used, e.g., 0 = Any protocol (default); 17 = UDP ;6 = TCP. InterfaceIndex = Interface Index. Phase1SaLifetimeInSec = Determines the duration (in seconds) for which the negotiated IKE SA (main mode) is valid. After the time expires, the SA is re-negotiated. Phase2SaLifetimeInSec = Determines the duration (in seconds) for which the negotiated IPSec SA (quick mode) is valid. After the time expires, the SA is re-negotiated. Phase2SaLifetimeInKB = Determines the maximum volume of traffic (in kilobytes) for which the negotiated IPSec SA (quick mode) is valid. DPDmode = Controls dead peer detection (DPD) according to RFC 3706. SIP Release Notes 80 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description Web: IP Security Proposal Table IPsecMode = Selects the IPSec mode of operation: [0] = Transport mode (default) [1] = Tunnel mode RemoteTunnelAddress =IP address of the peer router. The default is 0.0.0.0. RemoteSubnetIPAddress = IP address of the remote subnetwork. The default is 0.0.0.0. RemoteSubnetPrefixLength = Prefix length of the Remote Subnet IP Address parameter (in bits). The default is 16. For example: IPsecSATable 1 = 0, 10.3.2.73, 0, 123456789, 0, 0, 0, 0, 28800, 3600; In the above example, a single IPSec/IKE peer (10.3.2.73) is configured. Pre-shared key authentication is selected, with the preshared key set to 123456789. In addition, a lifetime of 28800 seconds is selected for IKE and a lifetime of 3600 seconds is selected for IPSec. Notes: Each row in the table refers to a different IP destination. To support more than one Encryption / Authentication proposal, for each proposal specify the relevant parameters in the Format line. The proposal list must be contiguous. [IPSecProposalTable] This ini file table parameter configures up to four IKE proposal settings, where each proposal defines an encryption algorithm, an authentication algorithm, and a Diffie-Hellman group identifier. [ IPsecProposalTable ] FORMAT IPsecProposalTable_Index = IPsecProposalTable_EncryptionAlgorithm, IPsecProposalTable_AuthenticationAlgorithm, IPsecProposalTable_DHGroup; [ \IPsecProposalTable ] Where: EncryptionAlgorithm = Selects the encryption (privacy) algorithm: [0] NONE [1] DES CBC [2] 3DES CBC [3] AES (default) AuthenticationAlgorithm = Selects the message authentication (integrity) algorithm: [0] NONE [2] HMAC SHA1 96 [4] HMAC MD5 96 (default) DHGroup = Selects the Diffie-Hellman group: [0] Group 1 (768 Bits) [1] Group 2 (1024 Bits) - default For example: IPsecProposalTable 0 = 3, 2, 1; IPsecProposalTable 1 = 2, 2, 1; Version 6.0 81 February 2010

Mediant 2000 & Mediant 3000 Parameter Description In the example above, two proposals are defined: Proposal 0: AES, SHA1, DH group 2 Proposal 1: 3DES, SHA1, DH group 2 Notes: Each row in the table refers to a different IKE peer. To support more than one Encryption / Authentication / DH Group proposal, for each proposal specify the relevant parameters in the Format line. The proposal list must be contiguous. 1.10.5 PSTN Parameters The table below describes the new PSTN parameters for Release 6.0. Table 1-5: New PSTN Parameters for Release 6.0 Parameter Web: Enable QSIG Transfer Update [EnableQSIGTransferUpdate ] [ConnectedNumberType] Description Determines whether the device interworks QSIG Facility messages with calltranfercomplete invoke application protocol data unit (APDU), to SIP UPDATE messages with P-Asserted-Identity and optional Privacy headers. This feature is supported for IP-to-Tel and Tel-to-IP directions. [0] Disable (default) = Ignores QSIG Facility message with calltranfercomplete invoke [1] Enable For example, assume A and C are PBX call parties, and B is the SIP IP phone: 1 A calls B; B answers the call. 2 A places B on hold, and calls C; C answers the call. 3 A performs a call transfer (the transfer is done internally by the PBX); B and C are connected to one another. In the above example, the PBX updates B that it is now talking with C. The PBX updates this by sending a QSIG Facility message with calltranfercomplete invoke APDU. The device interworks this message to a SIP UPDATE message containing a P-Asserted- Identity header with the number and name derived from QSIG calltranfercomplete redirectionnumber and redirectionname. Note: For IP-to-Tel, the redirectionnumber and redirectionname in the calltransfercomplete invoke is derived from the P-Asserted- Identity and Privacy headers. Defines the Numbering Type of the ISDN Q.931 Connected Number IE that the device sends in the Connect message to the ISDN (for Tel-to-IP calls). This is interworked from the SIP 200 OK P- Asserted-Identity header. The default is [0] (i.e., unknown). SIP Release Notes 82 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter [ConnectedNumberPlan] [ISDNTimerT310] [CasChannelIndex] Description Defines the Numbering Plan of the ISDN Q.931 Connected Number IE that the device sends in the Connect message to the ISDN (for Tel-to-IP calls). This is interworked from the SIP 200 OK P- Asserted-Identity header. The default is [0] (i.e., unknown). Defines the T310 override timer for DMS and Euro ISDN variants. An ISDN timer is started when a Q.931 Call Proceeding message is received. The timer is stopped when a Q.931 Alerting/Connect/Disconnect message is received from the other end. The call clears on expiration of the T310 timer. The valid value range is 0 to 600. The default is 0 (i.e., 10 seconds). Notes: For this parameter to take effect, a device reset is required. When both the parameters ISDNDmsTimerT310 and ISDNTimerT310 are configured, the value of the parameter ISDNTimerT310 prevails. Defines the loaded CAS protocol table index per B-channel, pertaining to a CAS trunk. This parameter is assigned a string value and can be set in one of two formats: CAS table per channel: Each channel is separated by a comma (e.g., "1,2,1,3 "). For this format, 31 indices must be defined for E1 trunks (including dummy for B-channel 16), or 24 indices for T1 trunks. Below is an example for configuring a T1 CAS trunk (Trunk 5) with several CAS variants ProtocolType_5 = 7 CASFILENAME_0='E_M_FGBWinkTable.dat' CASFILENAME_1='E_M_FGDWinkTable.dat' CASFILENAME_2='E_M_WinkTable.txt' CasChannelIndex_5 = 0,0,0,1,1,1,2,2,2,0,0,0,1,1,1,0,1,2,0,2,1,2,2,2 CASDelimitersPaddingUsage_5 = 1 CAS table per channel group: Each channel group is separated by a colon and each channel is separated by a comma. The syntax is <x-y channel range>:<cas index>, (e.g., "1-10:1,11-31:3"). Every B-channel (including 16 for E1) must belong to a channel group. Below is an example for configuring an E1 CAS trunk (Trunk 5) with several CAS variants: ProtocolType_5 = 8 CASFILENAME_2='E1_R2D' CASFILENAME_7= E_M_ImmediateTable_A-Bit.txt' CasChannelIndex_5 = 1-10:2,11-20:7,21-31:2 Note: Only one of these formats must be implemented; not both. Version 6.0 83 February 2010

Mediant 2000 & Mediant 3000 1.10.6 Existing ini File Parameters Now Configurable in the Web The table below lists the ini interface for Release 6.0. file parameters that are now also configurable in the Web Table 1-6: ini File Parameters now Configurable in the Web Interface for Release 6.0 ini File Parameter [EnableDelayedOffer] Web Parameter Enable Delayed Offer SIP Release Notes 84 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.11 Modified Parameters This section describes parameters from the previous release that have been modified in Release 6.0. These parameters can be configured using the ini file parameter (enclosed in square brackets) and/or the corresponding Web interface parameter (if supported). 1.11.1 SIP Parameters The table below describes SIP parameters from the previous release that have been modified in Release 6.0. Table 1-7: Modified SIP Parameters for Release 6.0 Parameter Web: Select Receiving of Overlap Dialing [ISDNRxOverlap] Description (Modification: New option [2] added; notes added regarding MinOverlapDigitsForRouting and ISDNTxOverlap.) Determines the receiving (Rx) type of ISDN overlap dialing for Tel-to-IP calls. [0] None (default) = Disabled. [1] Local receiving = ISDN Overlap Dialing - the complete number is sent in the INVITE Request-URI user part. The device receives ISDN called number that is sent in the 'Overlap' mode. The ISDN Setup message is sent to IP only after the number (including the Sending Complete IE) is fully received (via Setup and/or subsequent INFO Q.931 messages). In other words, the device waits until it has received all the ISDN signaling messages containing parts of the called number, and only then it sends a SIP INVITE with the entire called number in the Request-URI. [2] Through SIP = Interworking of ISDN Overlap Dialing to SIP, based on RFC 3578. The device interworks ISDN to SIP, by sending digits each time they are received (from Setup and subsequent Info Q.931 messages) to the IP, using subsequent SIP INVITE messages. Notes: When option [2] is configured, you can define the minimum number of overlap digits to collect before sending the first SIP message for routing the call, using the MinOverlapDigitsForRouting parameter. When option [2] is configured, even if SIP 4xx responses are received during this ISDN overlap receiving, the device does not release the call. The MaxDigits parameter can be used to limit the length of the collected number for ISDN overlap dialing (if Sending Complete is not received). If a digit map pattern is defined (using the DigitMapping or DialPlanIndex parameters), the device collects digits until a match is found (e.g., for closed numbering schemes) or until a timer expires (e.g., for open numbering schemes). If a match is found (or the timer expires), the digit collection process is terminated even if Sending Complete is not received. For enabling ISDN overlap dialing for IP-to-Tel calls, use the ISDNTxOverlap parameter. Version 6.0 85 February 2010

Mediant 2000 & Mediant 3000 Parameter Web: Use Tgrp Information [UseSIPTgrp] Description (Modification: New option [3] "UCR 2008" added.) Determines whether the SIP 'tgrp' parameter is used. This SIP parameter specifies the Trunk Group to which the call belongs (according to RFC 4904). For example, the SIP message below indicates that the call belongs to Trunk Group 1: INVITE sip::+16305550100;tgrp=1;trunkcontext=example.com@10.1.0.3;user=phone SIP/2.0 [0] Disable (default) = The 'tgrp' parameter isn't used. [1] Send Only = The Trunk Group number is added to the 'tgrp' parameter value in the Contact header of outgoing SIP messages. If a Trunk Group number is not associated with the call, the 'tgrp' parameter isn't included. If a 'tgrp' value is specified in incoming messages, it is ignored. [2] Send and Receive = The functionality of outgoing SIP messages is identical to the functionality described in option 1. In addition, for incoming SIP INVITEs, if the Request-URI includes a 'tgrp' parameter, the device routes the call according to that value (if possible). The Contact header in the outgoing SIP INVITE (PSTN-to- IP call) contains tgrp=<source trunk group ID>;trunkcontext=<gateway IP address>. The <source trunk group ID> is the Trunk Group ID where incoming calls from PSTN is received. For IP- PSTN calls, the SIP 200 OK device's response contains tgrp=<destination trunk group ID>;trunk-context=<gateway IP address>. The <destination trunk group ID> is the Trunk Group ID used for outgoing PSTN calls. The <gateway IP address> in trunkcontext can be configured using the parameter SIPGatewayName. [3] UCR 2008 = Interworks the hotline "Off Hook Indicator" parameter between SIP and ISDN: For IP-to-ISDN calls: - The device interworks the SIP tgrp=hotline parameter (received in INVITE) to ISDN Setup with the Off Hook Indicator IE of Voice, and Speech Bearer Capability IE. Note that the Off Hook Indicator IE is described in UCR 2008 specifications. - The device interworks the SIP tgrp=hotline-ccdata parameter (received in INVITE) to ISDN Setup with an Off Hook Indicator IE of Data, and with Unrestricted 64k Bearer Capability IE. The following is an example of the INVITE with tgrp=hotlineccdata: INVITE sip:1234567;tgrp=hotline-ccdata;trunkcontext=dsn.mil@example.com For ISDN-to-IP calls: - The device interworks ISDN Setup with an Off Hook Indicator of Voice to SIP INVITE with tgrp=hotline;trunkcontext=dsn.mil in the Contact header. - The device interworks ISDN Setup with an Off Hook indicator of Data to SIP INVITE with tgrp=hotline-ccdata;trunkcontext=dsn.mil in the Contact header. - If ISDN Setup does not contain an Off Hook Indicator IE and the Bearer Capability IE contains Unrestricted 64k, the outgoing INVITE includes tgrp=ccdata;trunk-context=dsn.mil. If the Bearer Capability IE contains Speech, the INVITE in this case does not contain tgrp and trunk-context parameters. SIP Release Notes 86 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Web: Channel Select Mode [ChannelSelectMode] Description Note: IP-to-Tel configuration (using the parameter PSTNPrefix) overrides the 'tgrp' parameter in incoming INVITE messages. (Modification: New option [8] Trunk & Channel Cyclic Ascending.) Port (B-channel) allocation method for incoming IP-to-Tel calls. [0] By Dest Phone Number (default) = Selects the device's channel according to the called number. [1] Cyclic Ascending = Selects the next available channel in an ascending cyclic order. Always selects the next higher channel number in the Trunk Group. When 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 = Selects the lowest available channel. It always starts at the lowest channel number in the Trunk Group and if that channel is not available, selects the next higher channel. [3] Cyclic Descending = Selects the next available channel in descending cyclic order. Always selects the next lower channel number in the Trunk Group. 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 = Selects the highest available channel. Always starts at the highest channel number in the Trunk Group and if that channel is not available, selects the next lower channel. [5] Dest Number + Cyclic Ascending = First selects the device's port according to the called number. If the called number isn't found, it then selects the next available channel in ascending cyclic order. Note that if the called number is found, but the port associated with this number is busy, the call is released. [6] By Source Phone Number = Selects the device's channel according to the calling number. [7] Trunk Cyclic Ascending = Selects the device's port from the first channel of the next trunk (next to the trunk from which the previous channel was allocated. [8] Trunk & Channel Cyclic Ascending = Uses the Trunk Cyclic Ascending and Cyclic Ascending methods to select the device's channel. This method selects the next physical trunk (pertaining to the Trunk Group) and then selects the B-channel of this trunk according to the cyclic ascending method (i.e., selects the channel after the last allocated channel). 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 allocated. For the second incoming call, the first channel of Trunk 1 is allocated. For the third incoming call, the second channel of Trunk 0 is allocated. Version 6.0 87 February 2010

Mediant 2000 & Mediant 3000 Parameter Web: Trunk Group Table [TrunkGroup] Web: Trunk Group Settings Table [TrunkGroupSettings] Description (Modification: Maximum entries increased to 120.) This ini file table parameter is used to define and activate the device's Trunks, define telephone numbers for them, and assign them to Trunk Group IDs. The format of this parameter is shown below: [TrunkGroup] FORMAT TrunkGroup_Index = TrunkGroup_TrunkGroupNum, TrunkGroup_FirstTrunkId, TrunkGroup_FirstBChannel, TrunkGroup_LastBChannel, TrunkGroup_FirstPhoneNumber, TrunkGroup_ProfileId, TrunkGroup_LastTrunkId, TrunkGroup_Module; [\TrunkGroup] Notes: This parameter can include up to 120 indices (0-119). The Trunk Group can be assigned an ID between 0 and 119. The parameter TrunkGroup_Module is not applicable. ( Modification: Maximum entries increased to 120; new parameter added - MWIInterrogationType.) This ini file table parameter defines rules for channel allocation per Trunk Group. If no rule exists, the global rule defined by the parameter ChannelSelectMode takes precedence. The format of this parameter is as follows: [TrunkGroupSettings] FORMAT TrunkGroupSettings_Index = TrunkGroupSettings_TrunkGroupId, TrunkGroupSettings_ChannelSelectMode, TrunkGroupSettings_RegistrationMode, TrunkGroupSettings_GatewayName,TrunkGroupSettings_ContactUser, TrunkGroupSettings_ServingIPGroup, TrunkGroupSettings_MWIInterrogationType; [\TrunkGroupSettings] Where, MWIInterrogationType = defines QSIG MWI to IP interworking for interrogating MWI supplementary services: [0] None = disables the feature. [1] Use Activate Only = don't send any MWI Interrogation messages and only "passively" respond to MWI Activate requests from the PBX. [2] Result Not Used = send MWI Interrogation message, but don't use its result. Instead, wait for MWI Activate requests from the PBX. [3] Use Result = send MWI Interrogation messages, use its results, and use the MWI Activate requests. 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. For example: [TrunkGroupSettings] TrunkGroupSettings 0 = 1, 0, 5, audio, user, 1, 0; TrunkGroupSettings 1 = 2, 1, 0, localname, user1, 2, 1; [\TrunkGroupSettings] Note: This parameter can include up to 120 indices (0-119). SIP Release Notes 88 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Web: Asserted Identity Mode [AssertedIdMode] Web: SAS Survivability Mode [SASSurvivabilityMode] Description (Modification: Interworking SIP with ISDN QSIG CONP/CNIR.) Determines whether P-Asserted-Identity or P-Preferred-Identity is used in the generated INVITE request for Caller ID (or privacy). [0] Disabled = None (default) [1] Adding PAsserted Identity [2] Adding PPreferred Identity The Asserted ID mode defines the header (P-Asserted-Identity or P- Preferred-Identity) that is used in the generated INVITE request and in 200 OK response. The header also depends on the calling Privacy (allowed or restricted). The P-Asserted-Identity (or P-Preferred-Identity) headers are used to present the originating or connected party's Caller ID. The Caller ID is composed of a Calling/Connected Number and (optionally) a Calling Name. P-Asserted-Identity (or P-Preferred-Identity) headers are used together with the Privacy header. If Caller ID is restricted, the Privacy header includes the value 'id' ('Privacy: id'). Otherwise, for allowed Caller ID, 'Privacy: none' is used. If Caller ID is restricted (received from PSTN), the From header is set to <anonymous@anonymous.invalid>. The 200 OK response can contain the connected party CallerID: Connected Number and Connected Name. For example, if the call is answered by the device, the 200 OK response includes the P-Asserted- Identity with CallerID. The device interworks (in some ISDN variants), the Connected Party number and name from Q.931 Connect message to SIP 200 OK with the P-Asserted-Identity header. In the opposite direction, if the ISDN device receives a 200 OK with P-Asserted-Identity header, it interworks it to the Connected party number and name in the Q.931 Connect message, including its privacy. (Modification: New option 3, "Auto-answer REGISTER".) Determines the Survivability mode used by the SAS application. [0] Standard = All incoming INVITE and REGISTER requests are forwarded to the defined Proxy list in SASProxySet in Normal mode and handled by the SAS application in Emergency mode (default). [1] Always Emergency = The SAS application does not use Keep- Alive messages towards the SASProxySet and instead, always operates in Emergency mode (as if no Proxy in the SASProxySet is available). [2] Ignore REGISTER = Use regular SAS Normal/Emergency logic (same as option 0), but when in Normal mode, incoming REGISTER requests are ignored. [3] Auto-answer REGISTER = When in Normal mode, the device responds to received REGISTER requests by sending a SIP 200 OK and enters the registrations in its SAS database. Version 6.0 89 February 2010

Mediant 2000 & Mediant 3000 Parameter Description Web: Media Security Behavior [MediaSecurityBehaviou r] Web: Tel Profile Settings Table [TelProfile] (Modification: New option "Preferable - Single Media".) Determines the device's mode of operation when SRTP is used (i.e., when EnableMediaSecurity is set to 1). [0] Preferable (default) = The device initiates encrypted calls. If negotiation of the cipher suite fails, an unencrypted call is established. Incoming calls that don't include encryption information are accepted. [1] Mandatory = The device initiates encrypted calls, but if negotiation of the cipher suite fails, the call is terminated. Incoming calls that don't include encryption information are rejected. [2] Preferable - Single Media = The device sends SDP with only a single media line ('m=') with RTP/AVP and crypto keys. If the remote SIP UA does not support SRTP, it ignores the crypto lines. Note: Before configuring this parameter, set the EnableMediaSecurity parameter to 1. (Modification: New parameters and SwapTelToIpPhoneNumbers, EnableAGC, and ECNlpMode.) This ini file table parameter configures the Tel Profile table. Each Tel Profile ID includes a set of parameters, which are typically configured separately using their individual, "global" parameters. You can later assign these Tel Profile IDs to other elements (e.g., to Trunk Groups - TrunkGroup parameter). Therefore, Tel Profiles allows you to apply the same parameter settings of a group of parameters to multiple channels, and apply specific behaviours to specific channels. The format of this parameter is as follows: [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_TimeForReorderTone, TelProfile_EnableDIDWink, TelProfile_IsTwoStageDial, TelProfile_DisconnectOnBusyTone, TelProfile_EnableVoiceMailDelay, TelProfile_DialPlanIndex, TelProfile_Enable911PSAP, TelProfile_SwapTelToIpPhoneNumbers, TelProfile_EnableAGC, TelProfile_ECNlpMode; [\TelProfile] Where, SwapTelToIpPhoneNumbers = Swaps the calling and called numbers received from the Tel side (for Tel-to-IP calls): [-1] Not set (default) [0] Disabled [1] Enabled EnableAGC = Activates the Automatic Gain Control (AGC) SIP Release Notes 90 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description Web: IP Profile Settings Table [IPProfile] mechanism: [-1] Not set [0] Disabled [1] Enabled ECNlpMode = Defines the echo cancellation Non-Linear Processing (NLP) mode: [-1] Not set [0] Adaptive NLP [1] Disabled NLP [2] Silence Output NLP For example: TelProfile 1 = ITSP_audio, 1, 0, 0, 10, 10, 46, 40, -11, 0, 0, 0, 0, 0, 1, 0, 0, 700, 0, -1, 255, 0, 1, 1, 1, -1, 1, 0, 0, 0; Notes: You can configure up to nine Tel Profiles (i.e., indices 1 through 9). The parameter TelPreference determines the priority of the Tel Profile (1 to 20, where 20 is the highest priority). If both IP and Tel profiles apply to the same call, the coders and parameters common to Tel and IP Profiles of the preferred Profile are applied to that call. If the preference of the Tel and IP profiles is identical, the Tel Profile parameters take precedence. The parameter EnableVoiceMailDelay is applicable only if voice mail is enabled globally (using the parameter VoiceMailInterface). To use the settings of the corresponding global parameter, enter the value -1. For a detailed description of each parameter, refer to its corresponding "global" parameter. The following parameters are not applicable: EnableReversePolarity, EnableCurrentDisconnect, MWIAnalog, MWIDisplay, EnableDIDWink, IsTwoStageDial, DisconnectOnBusyTone, and Enable911PSAP. (Modification: option 2 for MediaSecurityBehaviour.) This ini file table parameter configures the IP Profile table. Each IP Profile ID includes a set of parameters (which are typically configured separately using their individual, "global" parameters). You can later assign these IP Profiles to Tel-to-IP routing rules (Prefix parameter), IPto-Trunk Group routing rules (PSTNPrefix parameter), and IP Groups (IPGroup parameter). The format of this parameter is as follows: [IPProfile] FORMAT IPProfile_Index = IPProfile_ProfileName, IPProfile_IpPreference, IPProfile_CodersGroupID, IPProfile_IsFaxUsed, IPProfile_JitterBufMinDelay, IPProfile_JitterBufOptFactor, IPProfile_IPDiffServ, IPProfile_SigIPDiffServ, IpProfile_SCE, IPProfile_RTPRedundancyDepth, IPProfile_RemoteBaseUDPPort, IPProfile_CNGmode, IPProfile_VxxTransportType, IPProfile_NSEMode, IpProfile_IsDTMFUsed, IPProfile_PlayRBTone2IP, IPProfile_EnableEarlyMedia, IPProfile_ProgressIndicator2IP, IPProfile_EnableEchoCanceller, IPProfile_CopyDest2RedirectNumber, Version 6.0 91 February 2010

Mediant 2000 & Mediant 3000 Parameter Description IPProfile_MediaSecurityBehaviour, IPProfile_CallLimit, IPProfile_ DisconnectOnBrokenConnection, IPProfile_FirstTxDtmfOption, IPProfile_SecondTxDtmfOption, IPProfile_RxDTMFOption, IpProfile_EnableHold, IpProfile_InputGain, IpProfile_VoiceVolume, IpProfile_AddIEInSetup, IpProfile_SBCExtensionCodersGroupID, IPProfile_MediaIPVersionPreference, IPProfile_TranscodingMode; [\IPProfile] For example: IPProfile 0 = Sevilia, 1, 1, 0, 10, 10, 46, 40, 0, 0, 0, 0, 2, 0, 0, 0, 0, -1, 1, 0, 0, -1, 1, -1, -1, 1, 1, 0, 0,, -1, 4294967295, 0; Notes: You can configure up to nine IP Profiles (i.e., indices 1 through 9). The parameters RemoteBaseUDPPort and IsDTMFUsed (deprecated) are not applicable. The parameter IpPreference determines the priority of the IP Profile (1 to 20, where 20 is the highest preference). If both IP and Tel Profiles apply to the same call, the coders and common parameters (i.e., parameters configurable in both IP and Tel Profiles) of the preferred profile are applied to that call. If the Tel and IP Profiles are identical, the Tel Profile parameters take precedence. To assign the parameter's default value, enter two dollar signs ('$$'). To use the settings of the corresponding global parameter, enter the value -1. Configure intuitive names (ProfileName) for the IP Profiles so that they can later be easily identified. The parameter CallLimit defines the maximum number of concurrent calls allowed for that Profile. If the Profile is set to some limit, the device maintains the number of concurrent calls (incoming and outgoing) pertaining to the specific Profile. A limit value of [-1] indicates that there is no limitation on calls (default). A limit value of [0] indicates that all calls are rejected. When the number of concurrent calls is equal to the limit, the device rejects any new incoming and outgoing calls pertaining to that profile. RxDTMFOption configures the received DTMF negotiation method: [-1] not configured, use the global parameter; [0] don t declare RFC 2833; [1] declare RFC 2833 payload type is SDP. FirstTxDtmfOption and SecondTxDtmfOption configures the transmit DTMF negotiation method: [-1] not configured, use the global parameter; for the remaining options, refer to the global parameter. IP Profiles can also be used when operating with a Proxy server (set the parameter AlwaysUseRouteTable to 1). SIP Release Notes 92 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Web: Enable Early Media [EnableEarlyMedia] Web: SIT Q850 Cause [SITQ850Cause] Web: Debug Level [GwDebugLevel] Web: Proxy Set Table [ProxySet] Description (Modification: Note added for EnableEarly183.) Enables the device to send a 183 Session Progress response with SDP (instead of 180 Ringing), allowing the media stream to be established prior to the answering of the call. [0] Disable = Early Media is disabled (default). [1] Enable = Enables Early Media. Sending a 183 response depends on the ISDN Progress Indicator (PI). It is sent only if PI is set to 1 or 8 in the received Proceeding or Alert PRI messages. For CAS devices, see the ProgressIndicator2IP parameter. Note: You can also configure early SIP 183 response immediately upon receipt of an INVITE, using the EnableEarly183 parameter. (Modification: Note added for additional SIT tones.) Determines the Q.850 cause value specified in the SIP Reason header that is included in a 4xx response when Special Information Tone (SIT) is detected on an IP-to-Tel call. The valid range is 0 to 127. The default value is 34. Note: For mapping specific SIT tones, you can use the SITQ850CauseForNC, SITQ850CauseForIC, SITQ850CauseForVC, SITQ850CauseForRO parameters. (Modification: New option 7 added.) Syslog debug logging level. [0] 0 (default) = Debug is disabled. [1] 1 = Flow debugging is enabled. [5] 5 = Flow, device interface, stack interface, session manager, and device interface expanded debugging are enabled. [7] 7 = The Syslog debug level automatically changes between level 5, level 1, and level 0, depending on the device's CPU consumption. Notes: Usually set to 5 if debug traces are needed. Options 2, 3, 4, and 6 are not recommended for use. (Modification: Maximum Proxy Sets increased from 6 to 10.) This ini file table parameter configures the Proxy Set ID table. It is used in conjunction with the ProxyIP ini file table parameter, which defines IP addresses per Proxy Set ID. The ProxySet ini file table parameter defines additional attributes per Proxy Set ID. This includes, for example, Proxy keep-alive and load balancing and redundancy mechanisms (if a Proxy Set contains more than one proxy address). The format of this parameter is as follows: [ProxySet] FORMAT ProxySet_Index = ProxySet_EnableProxyKeepAlive, ProxySet_ProxyKeepAliveTime, ProxySet_ProxyLoadBalancingMethod, ProxySet_IsProxyHotSwap, ProxySet_SRD; Version 6.0 93 February 2010

Mediant 2000 & Mediant 3000 Parameter Description [\ProxySet] For example: ProxySet 0 = 0, 60, 0, 0; ProxySet 1 = 1, 60, 1, 0; Notes: This table parameter can include up to 10 indices (0-9). For configuring IP addresses per Proxy Set ID, use the ini file parameter ProxyIP. The parameter ProxySet_SRD is not applicable. Web: Destination Phone Number Manipulation Table for Tel to IP Calls [NumberMapTel2IP] (Modification: Maximum entries increased from 100 to 120.) This ini file table parameter manipulates the destination number of Telto-IP calls. The format of this parameter is as follows: [NumberMapTel2Ip] FORMAT NumberMapTel2Ip_Index = NumberMapTel2Ip_DestinationPrefix, NumberMapTel2Ip_SourcePrefix, NumberMapTel2Ip_SourceAddress, NumberMapTel2Ip_NumberType, NumberMapTel2Ip_NumberPlan, NumberMapTel2Ip_RemoveFromLeft, NumberMapTel2Ip_RemoveFromRight, NumberMapTel2Ip_LeaveFromRight, NumberMapTel2Ip_Prefix2Add, NumberMapTel2Ip_Suffix2Add, NumberMapTel2Ip_IsPresentationRestricted, NumberMapTel2Ip_SrcTrunkGroupID, NumberMapTel2Ip_ SrcIPGroupID; [\NumberMapTel2Ip] For example: NumberMapTel2Ip 0 = 01,$$,*,0,0,2,$$,$$,971,$$,$$,$$,$$; NumberMapTel2Ip 1 = 10,10,*,255,255,3,0,5,100,$$,255,$$,$$; Notes: This table parameter can include up to 120 indices (0-119). The parameters SourceAddress and IsPresentationRestricted are not applicable. Set these to $$. The parameter RemoveFromLeft, RemoveFromRight, Prefix2Add, Suffix2Add, LeaveFromRight, NumberType, and NumberPlan are applied if the called and calling numbers match the DestinationPrefix and SourcePrefix conditions. The manipulation rules are executed in the following order: RemoveFromLeft, RemoveFromRight, LeaveFromRight, Prefix2Add, and Suffix2Add. Parameters can be skipped by using two dollar signs ('$$'). Number Plan and Type can optionally be used in Remote Party ID (RPID) header by using the EnableRPIHeader and AddTON2RPI parameters. SIP Release Notes 94 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 1.11.2 Voice, RTP and RTCP Parameters The table below describes voice, RTP and RTCP parameters from the previous release that have been modified in Release 6.0. Table 1-8: Modified Voice, RTP and RTCP Parameter for Release 6.0 Parameter Web: Fax Relay Max Rate (bps) [FaxRelayMaxRate] Description (Modification: Additional values 6 to 13.) Maximum rate (in bps) at which fax relay messages are transmitted (outgoing calls). [0] 2400bps = 2.4 kbps [1] 4800bps = 4.8 kbps [2] 7200bps = 7.2 kbps [3] 9600bps = 9.6 kbps [4] 12000bps = 12.0 kbps [5] 14400bps = 14.4 kbps (default for Mediant 2000) [6] 16800bps = 16.8 kbps [7] 19200bps = 19.2 kbps [8] 21600bps = 21.6 kbps [9] 24000bps = 24 kbps [10] 26400bps = 26.4 kbps [11] 28800bps = 28.8 kbps [12] 31200bps = 31.2 kbps [13] 33600bps = 33.6 kbps (default for Mediant 3000) Note: The rate is negotiated between the sides (i.e., the device adapts to the capabilities of the remote side). Version 6.0 95 February 2010

Mediant 2000 & Mediant 3000 1.11.3 PSTN Parameters The table below describes PSTN parameters from the previous release that have been modified in Release 6.0. Table 1-9: Modified PSTN Parameter for Release 6.0 Parameter Web: General Call Control Behavior [ISDNGeneralCCBehavior] Description (Modification: New option GTD5 TBCT.) Bit-field used to determine several general CC behavior options. To select the options, click the arrow button, and then for each required option, select 1 to enable. The default is 0 (i.e., disable). [2] = data calls with interworking indication use 64 kbps B-channels (physical only). [8] REVERSE CHAN ALLOC ALGO = Channel ID allocation algorithm. [16] = The device clears down the call if it receives a NOTIFY message specifying 'User-Suspended'. A NOTIFY (User- Suspended) message is used by some networks (e.g., in Italy or Denmark) to indicate that the remote user has cleared the call, especially in the case of a long distance voice call. [32] CHAN ID 16 ALLOWED = Applies only to ETSI E1 lines (30B+D). Enables handling the differences between the newer QSIG standard (ETS 300-172) and other ETSI-based standards (ETS 300-102 and ETS 300-403) in the conversion of B-channel ID values into timeslot values: 1) In 'regular ETSI' standards, the timeslot is identical to the B- channel ID value, and the range for both is 1 to 15 and 17 to 31. The D-channel is identified as channel-id #16 and carried into the timeslot #16. 2) In newer QSIG standards, the channel-id range is 1 to 30, but the timeslot range is still 1 to 15 and 17 to 31. The D- channel is not identified as channel-id #16, but is still carried into the timeslot #16. When this bit is set, the channel ID #16 is considered as a valid B-channel ID, but timeslot values are converted to reflect the range 1 to 15 and 17 to 31. This is the new QSIG mode of operation. When this bit is not set (default), the channel_id #16 is not allowed, as for all ETSI-like standards. [64] USE T1 PRI = PRI interface type is forced to T1. [128] USE E1 PRI = PRI interface type is forced to E1. [256] START WITH B CHAN OOS = B-channels start in the Out- Of-Service state (OOS). [512] CHAN ALLOC LOWEST = CC allocates B-channels starting from the lowest available B-channel id. [1024] CHAN ALLOC HIGHEST = CC allocates B-channels starting from the highest available B-channel id. [16384] CC_TRANSPARENT_UUI bit: The UUI-protocol implementation of CC is disabled allowing the application to freely send UUI elements in any primitive, regardless of the UUI-protocol requirements (UUI Implicit Service 1). This allows more flexible application control on the UUI. When this bit is not set (default SIP Release Notes 96 Document #: LTRT-69017

SIP Release Notes 1. What's New in Release 6.0 Parameter Description behavior), CC implements the UUI-protocol as specified in the ETS 300-403 standards for Implicit Service 1. [65536] GTD5 TBCT = CC implements the VERIZON-GTD-5 Switch variant of the TBCT Supplementary Service, as specified in FSD 01-02-40AG Feature Specification Document from Verizon. Otherwise, TBCT is implemented as specified in GR-2865-CORE specification (default behavior). Note: When using the ini file to configure the device to support several ISDNGeneralCCBehavior features, add the individual feature values. For example, to support both [16] and [32] features, set ISDNGeneralCCBehavior = 48 (i.e., 16 + 32). Version 6.0 97 February 2010

Mediant 2000 & Mediant 3000 1.12 Obsolete Parameters The table below lists parameters from the previous release that are now obsolete in Release 6.0. Table 1-10: Obsolete Parameters Parameter [IPSec_SPD_Table] [IPSec_IKEDB_Table] [CoderName] [IsUseToHeaderAsCalledNumber] Description This parameter has been replaced by the new ini file parameter tables IPsecSATable and IPsecProposalTable. This parameter has been replaced by the new ini file parameter tables IPsecSATable and IPsecProposalTable. This parameter is now obsolete and has been replaced by the new ini file parameter CodersGroup. This parameter has been replaced by the new ini file parameter SelectSourceHeaderForCalledNumber. SIP Release Notes 98 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 2 Supported Features 2.1 SIP Features 2.1.1 Supported SIP Features The device supports the following main SIP features: Reliable User Datagram Protocol (UDP) transport, with retransmissions. Transmission Control Protocol (TCP) Transport layer. SIPS using TLS. T.38 real time Fax (using SIP). Note: If the remote side includes the fax maximum rate parameter in the SDP body of the INVITE message, the device returns the same rate in the response SDP. Operates with Proxy or without Proxy, using an internal routing table. Fallback to internal routing table if Proxy is not responding. Supports up to 15 Proxy servers. If the primary Proxy fails, the device automatically switches to a redundant Proxy. Supports domain name resolving using DNS NAPTR and SRV records for Proxy, Registrar and domain names that appear in the Contact and Record-Route headers. Supports Load Balancing over Proxy servers using Round Robin or Random Weights. Proxy or Registrar Registration, such as: REGISTER sip:servername SIP/2.0 VIA: SIP/2.0/UDP 212.179.22.229;branch=z9hG4bRaC7AU234 From: <sip:gwregistrationname@sipgatewayname>;tag=1c29347 To: <sip:gwregistrationname@sipgatewayname> Call-ID: 10453@212.179.22.229 Seq: 1 REGISTER Expires: 3600 Contact: sip:gwregistrationname@212.179.22.229 Content-Length: 0 The "servername" string is defined according to the following rules: The "servername" is equal to "RegistrarName" if configured. The "RegistrarName" can be any string. Otherwise, the "servername" is equal to "RegistrarIP" (either FQDN or numerical IP address), if configured. Otherwise the "servername" is equal to "ProxyName" if configured. The "ProxyName" can be any string. Otherwise the "servername" is equal to "ProxyIP" (either FQDN or numerical IP address). Version 6.0 99 February 2010

Mediant 2000 & Mediant 3000 The parameter GWRegistrationName can be any string. This parameter is used only if registration is Per Gateway. If the parameter is not defined, the parameter UserName is used instead. If the registration is per endpoint, the endpoint phone number is used. The 'sipgatewayname' parameter (defined in the ini file or set from the Web browser), can be any string. Some Proxy servers require that the 'sipgatewayname' (in REGISTER messages) is set equal to the Registrar / Proxy IP address or to the Registrar / Proxy domain name. The 'sipgatewayname' parameter can be overwritten by the TrunkGroupSettings_GatewayName value if the TrunkGroupSettings_RegistrationMode is set to Per Endpoint. REGISTER messages are sent to the Registrar's IP address (if configured) or to the Proxy's IP address. A single message is sent once per device, or messages are sent per B-channel according to the parameter AuthenticationMode. There is also an option to configure registration mode per Trunk Group using the TrunkGroupSettings table. The registration request is resent according to the parameter RegistrationTimeDivider. For example, if RegistrationTimeDivider = 70 (%) and Registration Expires time = 3600, the device resends its registration request after 3600 x 70% = 2520 sec. The default value of RegistrationTimeDivider is 50%. If registration per B-channel is selected, on device startup, the device sends REGISTER requests according to the maximum number of allowed SIP dialogs (configured by the parameter NumberOfActiveDialogs). After each received response, the subsequent REGISTER request is sent. Proxy and Registrar Authentication (handling 401 and 407 responses) using Digest method. Accepted challenges are kept for future requests to reduce the network traffic. Single device Registration or multiple Registration of all device endpoints. Supported methods: INVITE, CANCEL, BYE, ACK, REGISTER, OPTIONS, INFO, REFER, UPDATE, NOTIFY, PRACK, SUBSCRIBE and PUBLISH. Modifying connection parameters for an already established call (re-invite). Working with Redirect server and handling 3xx responses. Early media (supporting 183 Session Progress). PRACK reliable provisional responses (RFC 3262). Call Hold and Transfer Supplementary services using REFER, Refer-To, Referred-By, Replaces and NOTIFY messages. Supports RFC 3711, Secured RTP and Key Exchange, according to RFC 4568. Supports RFC 3489, Simple Traversal of UDP Through NATs (STUN). Supports RFC 3327, Adding 'Path' to Supported header. Supports RFC 3581, Symmetric Response Routing. Supports RFC 3605, RTCP Attribute in SDP. Supports RFC 3326, Reason header. Supports RFC 4028, Session Timers in SIP. Supports network asserted identity and privacy (RFC 3325 and RFC 3323). Support RFC 3903, SIP Extension for Event State Publication. Support RFC 3953, The Early Disposition Type for SIP. Support for RFC 3966, The tel URI for Telephone Numbers. Support RFC 4244, An Extension to SIP for Request History Information. SIP Release Notes 100 Document #: LTRT-69017

SIP Release Notes 2. Supported Features Supports Tel URI (Uniform Resource Identifier) according to RFC 2806 bis. Supports ITU V.152 - Procedures for supporting Voice-Band Data over IP Networks. Remote party ID <draft-ietf-sip-privacy-04.txt>. Supports obtaining Proxy Domain Name(s) from DHCP (Dynamic Host Control Protocol) according to RFC 3361. Supports handling forking proxy multiple responses. RFC 2833 Relay for DTMF Digits, including payload type negotiation. DTMF out-of-band transfer using: INFO method <draft-choudhuri-sip-info-digit-00.txt> INFO method, compatible with Cisco gateways NOTIFY method <draft-mahy-sipping-signaled-digits-01.txt> INFO method, compatible with Korea Telecom format SIP URL: sip: phone number @IP address (such as 1225556@10.1.2.4, where 122556 is the phone number of the source or destination) or sip: phone_number @ domain name, such as 122556@myproxy.com. Note that the SIP URI host name can be configured differently per called number. Supports RFC 4040, RTP payload format for a 64 kbit/s transparent data. Can negotiate coder from a list of given coders. Supports negotiation of dynamic payload types. Supports multiple ptime values per coder. Supports RFC 3389, RTP Payload for Comfort Noise. Supports RFC 3824, Using E.164 numbers with SIP (ENUM). Supports receipt and DNS resolution of FQDNs received in SDP. Supports <draft-ietf-sip-gruu-09>, Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in SIP Supports RTCP-XR reports publishing according to RFC 3611 and draft-johnstonsipping-rtcp-summary-07. Represents trunk groups in tel/sip Uniform Resource Identifiers (URIs) according to <draft-ietf-iptel-trunk-group-04>. Responds to OPTIONS messages both outside a SIP dialog and in mid-call. Generates SIP OPTIONS messages as Proxy keep-alive mechanism. Publishes the total number of free Tel channels in a 200 OK response to an OPTIONS requests. Support RFC 3310, HTTP Digest Authentication Using Authentication and Key Agreement (AKA). Supports receipt of a REFER method outside of a dialog. Support RFC 4458, SIP URIs for Applications such as voice mail and Interactive Voice Response (IVR). Support RFC 3608, SIP Extension Header Field for Service Route Discovery During Registration. Version 6.0 101 February 2010

Mediant 2000 & Mediant 3000 Support RFC 3911, The SIP Join Header (Partial). Support RFC 4730, A SIP Event Package for Key Press Stimulus (KPML) (Partial). Support RFC 5079, Rejecting Anonymous Requests in SIP. Support RFC 3455, Private Header (P-Header) Extensions to SIP for the 3rd- Generation Partnership Project (3GPP) [Partial]. Support RFC 4235, An INVITE-Initiated Dialog Event Package for SIP [Partial]. Support RFC 3680, A SIP Event Package for Registrations. 2.1.2 Unsupported SIP Features The following SIP features are not supported: MESSAGE method Preconditions (RFC 3312) SDP - Simple Capability Declaration (RFC 3407) S/MIME SIP Release Notes 102 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 2.1.3 SIP Compliance Tables The SIP device complies with RFC 3261, as shown in the following subsections. 2.1.3.1 SIP Functions The device supports the following SIP Functions: Table 2-1: Supported SIP Functions Function User Agent Client (UAC) User Agent Server (UAS) Proxy Server Redirect Server Registrar Server Supported The device supports working with third-party Proxy Servers such as Nortel CS1K/CS2K, Avaya, Microsoft OCS, Alcatel, 3Com, BroadSoft, Snom, Cisco and many others The device supports working with third-party Redirection servers The device supports working with third-party Registration servers 2.1.3.2 SIP Methods The device supports the following SIP Methods: Table 2-2: Supported SIP Methods Method Supported Comments INVITE ACK BYE CANCEL REGISTER Send only REFER Inside and outside of a dialog NOTIFY INFO OPTIONS PRACK UPDATE PUBLISH Send only SUBSCRIBE Version 6.0 103 February 2010

Mediant 2000 & Mediant 3000 2.1.3.3 SIP Headers The device supports the following SIP Headers: Table 2-3: Supported SIP Headers Header Field Accept Accept Encoding Alert-Info Allow Also Asserted-Identity Authorization Call-ID Call-Info Contact Content-Disposition Content-Encoding Content-Length Content-Type Cseq Date Diversion Encryption Expires Fax From History-Info Join Max-Forwards Messages-Waiting MIN-SE Organization P-Associated-URI P-Asserted-Identity P-Charging-Vector P-Preferred-Identity Priority Proxy- Authenticate Supported No No (Receive Only) SIP Release Notes 104 Document #: LTRT-69017

SIP Release Notes 2. Supported Features Header Field Proxy- Authorization Proxy- Require Prack Reason Record- Route Refer-To Referred-By Replaces Require Remote-Party-ID Response- Key Retry-After Route Rseq Session-Expires Server Service-Route SIP-If-Match Subject Supported Target-Dialog Timestamp To Unsupported User- Agent Via Voicemail Warning WWW- Authenticate Supported Version 6.0 105 February 2010

Mediant 2000 & Mediant 3000 2.1.3.4 SDP Headers The device supports the following SDP Headers: Table 2-4: Supported SDP Headers SDP Header Element v - Protocol version o - Owner/ creator and session identifier a - Attribute information c - Connection information d - Digit m - Media name and transport address s - Session information t - Time alive header b - Bandwidth header u - Uri Description Header e - Email Address header i - Session Info Header p - Phone number header y - Year Supported 2.1.3.5 SIP Responses The device supports the following SIP responses: 1xx Response - Information Responses 2xx Response - Successful Responses 3xx Response - Redirection Responses 4xx Response - Client Failure Responses 5xx Response - Server Failure Responses 6xx Response - Global Responses SIP Release Notes 106 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 2.1.3.5.1 1xx Response Information Responses Table 2-5: Supported 1xx SIP Responses 1xx Response Supported Comments 100 Trying The device generates this response upon receiving a Proceeding message from ISDN or immediately after placing a call for CAS signaling. 180 Ringing The device generates this response for an incoming INVITE message. Upon receiving this response, the device waits for a 200 OK response. 181 Call is Being Forwarded The device doesn't generate these responses. However, the device does receive them. The device processes these responses the same way that it processes the 100 Trying response. 182 Queued The device generates this response in Call Waiting service. When the SIP device receives a 182 response, it plays a special waiting Ringback tone to the telephone side. 183 Session Progress The device generates this response if the Early Media feature is enabled and if the device plays a Ringback tone to IP 2.1.3.5.2 2xx Response Successful Responses Table 2-6: Supported 2xx SIP Responses 2xx Response Supported Comments 200 OK - 202 Accepted - Version 6.0 107 February 2010

Mediant 2000 & Mediant 3000 2.1.3.5.3 3xx Response Redirection Responses Table 2-7: Supported 3xx SIP Responses 3xx Response Supported Comments 300 Multiple Choice 301 Moved Permanently 302 Moved Temporarily The device responds with an ACK, and then resends the request to the first new address in the contact list. The device responds with an ACK, and then resends the request to the new address. The device generates this response when call forward is used to redirect the call to another destination. If such a response is received, the calling device initiates an INVITE message to the new destination. 305 Use Proxy The device responds with an ACK, and then resends the request to a new address. 380 Alternate Service The device responds with an ACK, and then resends the request to a new address. 2.1.3.5.4 4xx Response Client Failure Responses Table 2-8: Supported 4xx SIP Responses 4xx Response Supported Comments 400 Bad Request The device doesn't generate this response. Upon receipt of this message, and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 401 Unauthorized Authentication support for Basic and Digest. Upon receiving this message, the device issues a new request according to the scheme received on this response. 402 Payment Required The device doesn't generate this response. Upon receipt of this message, and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 403 Forbidden The device doesn't generate this response. Upon receipt of this message, and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 404 Not Found The device generates this response if it is unable to locate the callee. Upon receiving this response, the device notifies the User with a Reorder Tone. 405 Method Not Allowed The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 406 Not Acceptable The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 407 Proxy Authentication Required Authentication support for Basic and Digest. Upon receiving this message, the device issues a new request according to the scheme received on this response. SIP Release Notes 108 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 4xx Response Supported Comments 408 Request Timeout The device generates this response if the no-answer timer expires. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 409 Conflict The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 410 Gone The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 411 Length Required 413 Request Entity Too Large 415 Unsupported Media The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. If the device receives a 415 Unsupported Media response, it notifies the User with a Reorder Tone. The device generates this response in case of SDP mismatch. 420 Bad Extension The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 423 Interval Too Brief 433 Anonymity Disallowed 480 Temporarily Unavailable 481 Call Leg/Transaction Does Not Exist The device does not generate this response. On reception of this message the device uses the value received in the Min-Expires header as the registration time. If the device receives a 433 Anonymity Disallowed, it sends a DISCONNECT message to the PSTN with a cause value of 21 (Call Rejected). In addition, the device can be configured, using the Release Reason Mapping, to generate a 433 response when any cause is received from the PSTN side. If the device receives a 480 Temporarily Unavailable response, it notifies the User with a Reorder Tone. This response is issued if there is no response from remote. The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 482 Loop Detected The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 483 Too Many Hops The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 484 Address Incomplete The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. Version 6.0 109 February 2010

Mediant 2000 & Mediant 3000 4xx Response Supported Comments 485 Ambiguous The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 486 Busy Here The SIP device generates this response if the called party is off-hook and the call cannot be presented as a call waiting call. Upon receipt of this response, the device notifies the User and generates a busy tone. 487 Request Canceled This response indicates that the initial request is terminated with a BYE or CANCEL request. 488 Not Acceptable The device doesn't generate this response. Upon receipt of this message and before a 200 OK has been received, the device responds with an ACK and disconnects the call. 491 Request Pending When acting as a UAS: the device sent a re-invite on an established session and is still in progress. If it receives a re-invite on the same dialog, it returns a 491 response to the received INVITE. When acting as a UAC: If the device receives a 491 response to a re-invite, it starts a timer. After the timer expires, the UAC tries to send the re-invite again. 2.1.3.5.5 5xx Response Server Failure Responses Table 2-9: Supported 5xx SIP Responses 5xx Response 500 Internal Server Error 501 Not Implemented 502 Bad gateway 503 Service Unavailable 504 Gateway Timeout 505 Version Not Supported Comments Upon receipt of any of these Responses, the device releases the call, sending an appropriate release cause to the PSTN side. The device generates a 5xx response according to the PSTN release cause coming from the PSTN. 2.1.3.5.6 6xx Response Global Responses Table 2-10: Supported 6xx SIP Responses 6xx Response 600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable Comments Upon receipt of any of these Responses, the device releases the call, sending an appropriate release cause to the PSTN side. SIP Release Notes 110 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 2.2 PSTN to SIP Interworking The SIP device supports various ISDN PRI protocols such as EuroISDN, North American NI2, Lucent 4/5ESS, Nortel DMS100, Meridian1 DMS100, Japan J1, as well as QSIG. PRI support includes User Termination or Network Termination side. ISDN-PRI protocols can be defined on an E1/T1 basis (i.e., different variants of PRI are allowed on different E1/T1 spans). The device also supports numerous variants of CAS protocols for E1 and T1 spans, including MFCR2, E&M wink start, E&M immediate start, E&M delay dial/start, loop-start, and ground start. CAS protocols can be defined on an E1/T1 basis (i.e., different variants of CAS are allowed on different E1/T1 spans). The device simultaneously supports different variants of CAS and PRI protocols on different E1/T1 spans (no more than four simultaneous PRI variants). PSTN-to-SIP and SIP-to-PSTN Called and Calling numbers can be optionally modified according to rules defined using the device's configuration parameters. 2.2.1 Supported Interworking Features The device supports the following PSTN-SIP interworking features: Definition and use of Trunk Groups for routing IP-to-PSTN calls. B-channel negotiation for PRI spans. ISDN Non Facility Associated Signaling (NFAS). PRI-to-SIP interworking according to RFC 4497 or ISO/IEC 17343. PRI-to-SIP Interworking of Q.931 Display (Calling Name) information element (IE). PRI (NI-2, 5ESS)/EURO ISDN/QSIG to SIP interworking of Calling Name using Facility IE in Setup and Facility messages. Configuration of Numbering Plan and Type for IP-to-ISDN calls. Interworking and flexible mapping of PSTN-to-SIP release causes. Interworking of ISDN redirect number to SIP Diversion header (according to IETF <draft-levy-sip-diversion-05.txt>) or to History-Info header (RFC 4244). Optional change of redirect number to called number for ISDN-to-IP calls. Interworking of ISDN calling line Presentation & Screening indicators using RPID header <draft-ietf-sip-privacy-04.txt>. Interworking of Q.931 Called and Calling Number Type and Number Plan values using the RPID header or using the phone-context parameter (RFC 4904). Interworking of Calling and Called Subaddress values for SIP-to-ISDN calls (RFC 4715). ISDN en-block or overlap dialing for incoming Tel-to-IP calls. ISDN to SIP interworking of ISDN Overlap Dialing according to RFC 3578. Digit map pattern to reduce the dialing period when Overlap dialing is used. Routing of IP-to-Tel calls to predefined trunk groups. Configurable channel-select mode per trunk group. Version 6.0 111 February 2010

Mediant 2000 & Mediant 3000 Various number manipulation rules for IP-to-Tel and Tel-to-IP, called and calling numbers. Option to configure ISDN Transfer Capability per trunk. Transfer of User-to-User Information Element (UUIE) between SIP and PRI. ISDN Transfer using TBCT / RLT / ECT. QSIG messages tunneling over SIP according to ECMA-355(ISO/IEC 22535). ISDN PRI messages tunneling over SIP messages according to RFC 3372 - SIP-T. Interworking of Hold/Retrieve supplementary services from QSIG/EuroISDN to SIP and vice versa. QSIG and EURO ISDN Deflection (Rerouting), interworking of Call Rerouting Facility to SIP 302 response in both IP-to-Tel and Tel-to IP directions. QSIG MWI Notifications and QSIG MWI Interrogation. QSIG Single Step Transfer from QSIG to SIP, and vice versa. QSIG Path Replacement from SIP to QSIG. Multi-Level Precedence & Preemption (MLPP) using NI-2. Calling Party Category interworking between PRI and SIP according to <draft-mahyiptel-cpc-05>. E911 Generic Information IE (according to Telcordia GR-2968-CORE) from SIP to NI-2. 2.2.2 Interworking Features Not Supported The following interworking features are not supported: QSIG Completion of Calls to Busy Subscribers and on No Reply. QSIG BRI Suspend/Resume. 2.3 DSP Firmware Templates The device supports the following DSP firmware templates: Notes: Installation and use of vocoders is subject to obtaining the appropriate license and to royalty payments. The number of channels refers to the device's maximum channel capacity. For Mediant 2000, DSP templates 1 and 2 are not supported on reduced hardware assemblies (i.e., one or two trunks). For other DSP template configurations, please contact AudioCodes. SIP Release Notes 112 Document #: LTRT-69017

SIP Release Notes 2. Supported Features Table 2-11: DSP Firmware Templates for Mediant 2000 DSP Template 0 1 2 4 5 Number of Channels Default Setting 480 320 240 400 240 With 128-msec EC 400 320 240 400 240 With SRTP 400-240 320 240 With IPM Detectors 400 320 240 400 240 With IPM Detectors & SRTP 320-240 320 240 Voice Coder Transparent G.711 A/Mu-law PCM G.726 ADPCM G.727 ADPCM G.723.1 - - - - G.729 A, B - - GSM FR - - - MS GSM - - - EVRC - - - - QCELP - - - - AMR - - - - GSM EFR - - - - ilbc - - - - EG.711 - - - Version 6.0 113 February 2010

Mediant 2000 & Mediant 3000 Table 2-12: DSP Firmware Templates for Mediant 3000 DSP Template 0 1 2 4 5 7 9 10 Number of Channels Default Settings 2016 2016 1764 1260 1260 1638 1008 1512 With SRTP 1764 - - - - 1638 1008 - Voice Coders AMR - - - - - - AMR-WB - - - - - - - EVRC - - - - - - EVRC-B - - - - - - - G.711 A/Mu-law PCM G.722 - - - - - - - G.723.1 - - - - - - - G.726 ADPCM - - G.727 ADPCM - - G.729 A, B GSM EFR - - - - - - GSM FR - - - - - ilbc - - - - - - - MS GSM - - - - - EG.711 - - - - - - - MS RTA (NB) - - - - - - - T.38 Version 3* - - - - - - - * T.38 Version 3 will be supported in the next applicable release. SIP Release Notes 114 Document #: LTRT-69017

SIP Release Notes 2. Supported Features Table 2-13: DSP Firmware Templates for Mediant 3000 16 E1 /21 T1 DSP Template 0 1 2 4 5 7 9 10 Number of Channels Default Settings 480 480 480 360 360 468 288 432 With SRTP 480 - - - - 468 288 - Voice Coder AMR - - - - - - AMR-WB - - - - - - - EVRC - - - - - - EVRC-B - - - - - - - G.711 A/Mu-law PCM G.722 - - - - - - - G.723.1 - - - - - - - G.726 ADPCM - - G.727 ADPCM - - G.729 A, B GSM EFR - - - - - - GSM FR - - - - - ilbc - - - - - - - MS GSM - - - - - EG.711 - - - - - - - MS-RTA (NB) - - - - - - - T.38 Version 3* - - - - - - - Note: T.38 Version 3 will be supported in the next applicable release. Version 6.0 115 February 2010

Mediant 2000 & Mediant 3000 2.4 Template Mix Feature The device can operate (and be loaded) with up to two DSP templates. The channel capacity per DSP template is approximately 50%, with alignment to the number of DSP's present in the device. Table 2-14: Template Mix Feature Channel Capacity DSP Template Mix 1 (AMR) / 2 (EVRC) 1 (AMR) / 5 (EVRCB) 1 (AMR) / 7 (ilbc) Number of Channels Mediant 3000 960/924 768/780 864/936 SIP Release Notes 116 Document #: LTRT-69017

SIP Release Notes 2. Supported Features 2.5 Product Capability Comparison The table below provides a comparison of the capabilities between the Mediant 2000 and Mediant 3000 devices. Table 2-15: Capability Comparison between Devices Feature Mediant 2000 Mediant 3000 G.711 * ptime 120 msec ptime 40 msec Enhanced G.711 ptime = 10, 20, 30 msec ptime = 10, 20 msec G.726 10 msec ptime 120 msec ptime 80 msec on 32 kbps ptime 60 msec on 40 kbps G.722 Not supported Supported AMR IF2 AMR WB EVRC EVRC B MS RTA QCELP Supported Not supported DTX is not supported Not supported Not supported Supported Not supported Supported DTX is supported Supported Supported Not supported GSM MS ptime 40 msec ptime 80 msec Transparent ptime 120 msec ptime 40 msec WB Transcoding Not supported Supported T.38 V.34 Fax Transport Type V.34 Fax Transport Type parameter is parameter is not supported. supported. Fax/Modem Bypass Fax/Modem TWE Caller ID TTY DTMF ptime 120 msec ptime 40 msec If coder is PCM or ADPCM, cannot configure different ptime for voice and bypass packets. Supported Supported Supported on EVRC Detector DTMF Twist = 4 db Events are not fully synchronized. FSK DID is not supported. Supported on EVRC, EVRCB, AMR, GSM EFR, and Bypass. DTMF Erasure sensitivity is not supported. Detector DTMF Twist = 8 db. R1.5 Supports both detection and Supports only detection generation Echo Canceler Up to 128 msec. Default is 64 msec. Max Echo Canceler parameter is not supported. Default is 128 msec. Version 6.0 117 February 2010

Mediant 2000 & Mediant 3000 Feature Mediant 2000 Mediant 3000 Jitter Buffer SRTP RTCP RTCP XR Up to 285 msec. Does not work with M Factor greater than 1 and RTP Redundancy greater than 0. CNAME = 256 bytes. Max Interval = 0xEFFFFFFF msec. Supported Up to 300 msec on the regular (0), CDMA (2), CDMA\EVRCB (5), and G.729.1 (6) DSP templates. Up to 200 msec on the UMTS (1), Cable (3), and Wideband (4) DSP templates. Reduces the ptime capabilities on G.711 to a maximum of 30 msec. CNAME = 64 bytes. RTCP Extension is not supported. Call statistics does not include Round Trip average. Max Interval = 0xFFFF msec. RTCP packets are not sent at all if the RTCP Interval is set above this value. Not supported RFC 2833 RTP CN Broken Connection CAS RTP Multiplexing SNMP Supports DTMF, MF, CAS, Analog, and Fax. Supports the parameter NTEMaxDuration. Supports G711, G726, and a workaround for decoder G.729. Up to approximately 3 days. Silence period is regarded as a valid connection. Up to 50 CAS changes in one CAS string Supported Supported Supports DTMF and MF. No support for the NTEMaxDuration parameter. Supports G.711 and G.726. Up to approximately 21 minutes. Silence period is regarded as a valid connection unless the No-Op feature is enabled. Up to 10 CAS changes in one CAS string. Raw CAS is not supported Not supported Online parameters needs to be applied using the acsysactionsetonlinechangesapply SNMP parameter. *Note: ptime = packetization time. SIP Release Notes 118 Document #: LTRT-69017

SIP Release Notes 3. Known Constraints 3 Known Constraints This section lists known constraints in Release 6.0. Note: Due to the improved ini file format for tables, it's not possible to load an ini file that was used by a device running software version 5.2 or later to a device using an earlier version (e.g. 5.0). This can result in an invalid configuration. For additional information, contact AudioCodes. Note: Software version 4.6 and later cannot be loaded to Mediant 2000 with an 8- span TPM operating with a 64-MByte RAM. 3.1 Voice, RTP and RTCP Constraints This release includes the following known voice, RTP and RTCP constraints: 1. RFC 2198 Redundancy mode with RFC 2833 is not supported (i.e., if a complete DTMF digit is lost, it is not reconstructed). The current RFC 2833 implementation supports Redundancy for lost inter-digit information. Since the channel can construct the entire digit from a single RFC 2833 end packet, the probability of such inter-digit information loss is very low. 2. 3. 4. 5. 6. 7. 8. 9. 10. The G.729 coder with a ptime of 50 is not supported. Instead, the user should use either 40 msec or 60 msec ptime. If a voice prompt is used before a silence in a Voice Prompt Sequence, the end of the voice prompt is cut off by up to 80 msec. To avoid this, a silence period of 80 msec should be added to the end of the specific voice prompt. : the Voice Prompt file needs be reloaded to the device after the Hitless software upgrade has been completed. Mediant 2000: When using IP-to-IP mediation, the channel capacity may be reduced. EVRC Interleaving according to RFC 3558 is supported only on the receiving side. Supporting this mode on the transmitting side is not mandatory according to this RFC. Mediant 3000: Announcements and streaming cannot be performed on IP-to-IP Wideband calls. Mediant 3000: When performing an IP-to-IP call with a wideband (WB) coder on each leg, if the Fax/Modem Transport type for one of the legs is not Transparent, the interconnection is made using a Narrowband coder, therefore, the wideband quality of the call is not maintained. Therefore, the user should avoid setting any Fax/Modem enhanced capabilities on WB IP-to-IP calls for which the user wants to maintain the wideband quality. Mediant 3000: 30 msec RTP frames using the EG.711 coder is not supported. To change the DSP template, the user can either use the Mixed Template table or the DSP Template single values. 11. The duration resolution of the On and Off time digits when dialing to the network using RFC 2833 relay is dependent on the basic frame size of the coder being used. Version 6.0 119 February 2010

Mediant 2000 & Mediant 3000 12. NTT Caller ID Type 2 constraints: The NTT standard describes the Caller ID Type 2 generation as a sequence of an incoming-call signal, "C" and "D" DTMFs and FSK modulated Data. Generation of the incoming call signal remains the responsibility of the application, but "C", "D" and the FSK are generated by the supplied service. The signal can be generated using the UDT signal generation mechanism. Prior to the detection of an NTT Caller ID Type 2, there are two DTMF ("C" and "D") detections which remain unscreened. 3.2 Infrastructure Constraints This release includes the following known infrastructure constraints: 1. The following parameters do not return to their default values when attempting to restore them to defaults using the Web or SNMP interfaces, or when loading a new ini file using BootP/TFTP: VLANMode VLANNativeVLANID RoutingTableDestinationsColumn RoutingTableDestinationPrefixLensColumn RoutingTableInterfacesColumn RoutingTableGatewaysColumn RoutingTableHopsCountColumn RoutingTableDestinationMasksColumn EnableDHCPLeaseRenewal RoutingTableDestinationMasksColumn IPSecMode CASProtocolEnable EnableSecureStartup UseRProductName LogoWidth WebLogoText UseWeblogo UseProductName 2. The Multiple Interface table does not return to default values when attempting to restore it to defaults using the Web or SNMP interfaces, or when loading a new ini file using BootP/TFTP. 3. Files loaded to the device must not contain spaces in their file name. Including spaces in the name prevents the file from being saved to the device's flash memory or copied to the redundant blade (in HA systems). 4. Mediant 3000: When using BITS with line-synch mode, only APS protected mode is supported. SIP Release Notes 120 Document #: LTRT-69017

SIP Release Notes 3. Known Constraints 3.3 Networking Constraints This release includes the following known networking constraints: 1. 2. 3. 4. Mediant 3000: NTP does not function when operating with multiple interfaces. In certain cases, when the Spanning-Tree algorithm is enabled on the external Ethernet switch port that is connected to the device, the external switch blocks all traffic from entering and leaving the device for some time after the device is reset. This may result in the loss of important packets such as BootP and TFTP requests, which in turn, may cause a failure in device start-up. A possible workaround is to set the ini file parameter BootPRetries to 5, causing the device to issue 20 BootP requests for 60 seconds. Another workaround is to disable the spanning tree on the port of the external switch that is connected to the device. Configuring the device to auto-negotiate mode while the opposite port is set manually to full-duplex (either 10BaseT or 100BaseTX) is invalid. It is also invalid to set the device to one of the manual modes while the opposite port is configured differently. The user is encouraged to always prefer full-duplex connections over half-duplex, and 100BaseTX over 10BaseT (due to the larger bandwidth). PPPoE is not supported. 5. Debug Recording: Only one IP target is allowed. Maximum of 50 trace rules are allowed simultaneously. Maximum of 5 media stream recordings are allowed simultaneously. 6. Enabling the UDP checksum calculation is not applied to CALEA and IP-to-IP connections without transcoding. The UDP checksum field is set to zero in these cases. 3.4 Security Constraints This release includes the following known security constraint: 1. The value of the Active IPSec SAS Performance Monitoring element is not supported. 3.5 High Availability Constraints This release includes the following known Mediant 3000 High Availability (HA) constraints: 1. When using IPSec for control protocol transport, the device may experience a large bulk of Syslog error messages during switchover. These messages can be ignored as the switchover should succeed and the connection with the SSW is restored. 2. Mediant 3000/TP-6310 HA: During HA switchover, the APS active interface status (e.g., PSTN-B is currently Active and PSTN-A is Inactive ) is not transferred to the redundant blade. As a result, if the PSTN-B interface was active before switchover, PSTN-A can be active after switchover. The information regarding which interface is active is not maintained after switchover. 3. Enabling system diagnostics (through ini file, Web, or EMS) is not supported. Version 6.0 121 February 2010

Mediant 2000 & Mediant 3000 3.6 PSTN Constraints This release includes the following known PSTN constraints: 1. 2. 3. 4. 5. 6. 7. 8. 9. All the device's trunks must belong to the same Trunk Type (i.e., either E1 or T1). After changing the trunk configurations from the initial factory default (i.e., trunks are of Protocol Type 'None'), a device reset is required (i.e., the change cannot be made onthe-fly). When configuring the framing method to 'Extended Super Frame' (0) or 'Super Frame' (1), the framing method is converted to another framing method. The correct value that is updated in the device is displayed in the Web interface: For E1: 'Extended Super Frame' (0) and 'Super Frame' (1) are converted to 'E1 FRAMING MFF CRC4 EXT' (c). For T1: 'Extended Super Frame' (0) is converted to 'T1 FRAMING ESF CRC6' (D). In addition, 'Super Frame' (1) is converted to 'T1 FRAMING F12' (B). : When configuring the device (with E1 trunks), negotiation of CRC4 (for either EXTENDED_SUPER_FRAME or E1_FRAMING_MFF_CRC4_EXT framing methods) should not be used. The framing method other than EXTENDED_SUPER_FRAME and E1_FRAMING_MFF_CRC4_EXT must be selected. DS3 constraints (Mediant 3000/TP-6310): The BIT voice path can fail when using the DS3 interface. When the DS3 interface is not connected, a trunk under this DS3 interface can appear in either LOF or AIS alarm state. The DS3 External clock is not relevant for Asynchronous mapping of DS3 in OC3. SDH constraints (Mediant 3000/TP-6310): TU-11 Byte Synchronous mapping is not supported. For SDH/SONET and DS3 interfaces, if a trunk was in LOF alarm and the alarm was then cleared, the trunk tends to revert to the RAI alarm for a short period before moving to no alarm state. In STM-1 and OC3 configurations, path alarms do not show the real state if the higher level is not synchronized. For example, if there is no LOS on both PSTN Port A and Port B, the path level displays "No Alarm". Mediant 2000: SS7 is not supported. Up to two different Alias Point Codes can be configured per Signaling Node (SN). SS7 capacity limitations: Up to 2 signaling nodes can be configured per device. Up to 2 Alias Point Codes can be configured per signaling node, but only 1 signaling node can be configured with Alias Point Codes. Up to 64 signaling links can be configured per device. Up to 32 link-sets can be configured per signaling node. Up to 8 links can be configured per link-set. Up to 30 route-sets can be configured per signaling node. Up to 4 link-sets can be configured per route-set (routes per route-set). SIP Release Notes 122 Document #: LTRT-69017

SIP Release Notes 3. Known Constraints 10. SS7 MTP3 Signaling Node (SN) Redundancy Limitations: Up to two blades can be configured as Shared Point Code. Blade redundancy parameters cannot be changed on-the-fly (except for SS7MTP3RdcyTblSyncInterval). The Add & Delete commands can be performed on the SN-Blade Table Configuration when the SN is set to Offline. ini file configurations after reset are not relayed to remote devices. SN operations (InService/Start/Stop) are local to the device they are performed on. On-the-fly configurations that are performed on one device are passed only to the remote devices that established a TCP connection with that device. (For this reason, redundancy SN-Blade table configurations are not passed between the new device that is configured and the other device.) SS7 operations that are performed on one device are passed only to the remote devices that have an InService x-link to that device. SS7 and UAL configuration must be the same on devices that share the same Point Code. On-the-fly configuration of a link (Create/InService/Offline/Delete) must be performed from the device that the link physically belongs to. 3.7 Web Constraints This release includes the following known Web constraints: 1. The fax counters (Attempted Fax Calls Counter and Successful Fax Calls Counter) in the 'Status & Diagnostics' page do not function correctly. 2. If the Home button is clicked when the Scenario mode is active, the Scenario mode is not exited. 3. Scrolling errors appear on the Home page when reducing the size of the browser's window (i.e. window not maximized). 4. When adding a port name in the Home page, the actual port name may not appear on the 'Trunk and Channel Status' page. 5. On the 'Software Upgrade Wizard' page, the software upgrade process must be completed prior to clicking the Back button. Clicking the Back button before the wizard completes causes a display distortion. 6. 7. 8. 9. When using the Software Upgrade Wizard, if the Voice Prompt (VP) file is loaded and the Next button is clicked while the progress bar is displayed, the file is not loaded to the device. Despite this failure, the user receives a message that the file has been successfully downloaded. When using the Trunk Scroll Bar on the 'Trunk Settings' page, some trunks may not be displayed on the Trunks panel when scrolling too fast. The AnalogSignalTransportType parameter still appears. Sometimes, clicking the Submit button in the 'CAS State Machines' page causes a Page Not Found" error. Version 6.0 123 February 2010

Mediant 2000 & Mediant 3000 10. 11. On the Configuration > SS7 Configuration > SN > Linkset > Linkset-link > View link, an incorrect link appears. Sometimes a non-configured link is displayed or a link that is connected to another linkset is displayed. On some SS7 Web pages, all available buttons become visible for a split second while the page is loaded, even though they should not appear. 12. On the 'IP Interface Status' page (under the Status & Diagnostics menu), the IP addresses may not be fully displayed if the address is greater than 25 characters. 13. On the 'IP Settings' page, adding an interface with invalid characters (e.g., <, >, ", and ') may result in a corrupted Web page. Submitting the corrupted Web page may result in an unexpected behavior such as no response from the device. 14. The following RTCP XR fields are missing from the 'RTP/RTCP Settings' page: RTCP XR Report Mode RTCP XR Packet Interval Disable RTCP XR Interval Randomization RTCP XR Collection Server RTCP XR Collection Server Transport Type 3.8 SNMP Constraints This release includes the following known SNMP constraints: 1. When configuring acsysinterfacetable using SNMP or the Web interface, validation is performed only after device reset. 2. When defining or deleting SNMPv3 users, the v3 trap user must not be the first to be defined or the last to be deleted. If there are no non-default v2c users, this results in a loss of SNMP contact with the device. 3. 4. 5. 6. 7. 8. Mediant 3000/TP-6310: The DS3 ifadmin-state field cannot be changed in the IF- Table, using SNMP. Mediant 3000/TP-6310: In the DS3/E3 Current Table, the following objects are not supported: dsx3currentsefss and dsx3currentuass. Mediant 3000/TP-6310: In the DS3/E3 Interval Table, the following objects are not supported: dsx3intervalpsess and dsx3intervalsefss. Mediant 3000/TP-6310: The dsx3total Table is not supported. : When setting snmptargetaddrtaglist to NULL (by removing a row in the snmptargetaddrtable) without changing the corresponding entry in the snmpcommunitytable, an inconsistency occurs when a switchover occurs between the Active and Redundant blades. In the Active blade, the object appears with a NULL value; in the Redundant blade, a non-null value appears. : The Admin State does not change to Redundant. 3.9 CLI Constraints This release includes the following known command-line interface (CLI) constraints: 1. When connecting to the device using Telnet (CLI), Syslog messages do not appear by default. The Show Log command can be used to enable this feature. SIP Release Notes 124 Document #: LTRT-69017

SIP Release Notes 4. Resolved Constraints 4 Resolved Constraints This section lists constraints from previous releases that have been resolved in Release 6.0. 4.1 Voice, RTP and RTCP Resolved Constraints The following voice, RTP and RTCP constraints from previous releases have now been resolved in Release 6.0: 1. 2. 3. Setting the parameter V.21 Transport Type to Bypass and the Fax Transport Type to Relay results in entering the Fax Relay mode at the 2,100 Hz signal. Only at the end of this signal does the channel enter Bypass mode if V.21 Modem is detected. To avoid this, the use should either switch the Fax setting to Bypass or the V.21 setting to Transparent. The number of RTP payloads packed in a single G.729 packet (M channel parameter) is limited to 5. The NetCoder vocoder is not supported. 4.2 Web Resolved Constraints The following Web constraints from previous releases have now been resolved in Release 6.0: 1. Mediant 3000: The 'APS Direction Mode' parameter does not appear on the 'Transmission Settings' page. 2. If the Home button is clicked when a device is loaded in Scenario mode, the Scenario mode is not closed. 4.3 SNMP Resolved Constraints The following SNMP constraints from previous releases have now been resolved in Release 6.0: 1. SNMP configuration for the Access List table is not activated when using CreateAndGo for the row status MIB object. Instead, CreateAndWait followed by Active should be used. 2. The PM acpmtrunkutilizationtimeabovehighthreshold field is not updated and remains set at 0 instead of a higher number. 3. Action Result for the following file types, describes the file download to the blade but not the related application s parsing results. The file types are: Voice prompt Xml User info Version 6.0 125 February 2010

Mediant 2000 & Mediant 3000 Reader s Notes SIP Release Notes 126 Document #: LTRT-69017

SIP Release Notes 5. Earlier Releases 5 Earlier Releases Details of previous releases can be found in the Release Notes of Version 5.8, published by AudioCodes on 21 June 2009. Version 6.0 127 February 2010

Release Notes Version 6.0 www.audiocodes.com