Mediant Media Gateways. SIP Mediant 1000, Mediant 2000 & Mediant 3000. Application Note. IP-to-IP SIP Call Routing. Ver. 5.6

Mediant Media Gateways SIP Mediant 1000, Mediant 2000 & Mediant 3000 Application Note IP-to-IP SIP Call Routing Ver. 5.6 Document #: LTRT-40002 January 2009

Application Note Contents Table of Contents 1 Introduction... 7 1.1 Theory of Operation... 8 1.2 IP-to-IP Configuration Tables... 13 1.2.1 SBC Settings Page... 13 1.2.2 MediaChannels ini File Parameter... 13 1.2.3 IP Group Table... 14 1.2.4 Proxy Set Table... 17 1.2.5 Outbound IP Routing Table (Tel to IP)... 19 1.2.6 Inbound IP Routing Table (IP to Tel)... 20 1.2.7 Account Table... 21 2 Case Study... 23 3 Configuring AudioCodes Gateway... 25 3.1 Step 1: Enable the IP-to-IP Capabilities... 25 3.2 Step 2: Configure the Number of Media Channels... 26 3.3 Step 3: Define a Trunk Group for the Local PSTN... 27 3.4 Step 4: Configure the Proxy Sets... 28 3.5 Step 5: Configure the IP Groups... 30 3.6 Step 6: Configure the Account Table... 32 3.7 Step 7: Configure IP Profiles for Voice Coders... 33 3.8 Step 8: Configure Inbound IP Routing... 35 3.9 Step 9: Configure Outbound IP Routing... 36 3.10 Step 10: Configure Destination Phone Number Manipulation... 38 IP-to-IP Trunking 3 January 2009

IP-to-IP Call Routing List of Figures Figure 1-1: Basic Schema of the Gateway s IP-to-IP Call Handling... 8 Figure 1-2: Example of IP-to-IP Routing/Registration/Authentication of Remote IP-PBX Users... 10 Figure 1-3: Example of IP-to-IP Routing for IP-PBX Remote Users in Survivability Mode... 11 Figure 1-4: Gateway Registration with Multiple ITSP s on behalf of IP-PBX... 12 Figure 2-1: SIP Trunking Setup Example... 24 Figure 3-1: SBC Settings Page... 25 Figure 3-2: Admin Page for IP Media Channels Settings... 26 Figure 3-3: Trunk Group Table Page... 27 Figure 3-4: Proxy Set ID #1 for ITSP-A... 28 Figure 3-5: Proxy Set ID #2 for ITSP-B... 29 Figure 3-6: Proxy Set ID #3 for the IP-PBX... 30 Figure 3-7: IP Group Table Page... 31 Figure 3-8: Account Table Page... 32 Figure 3-9: Coder Group ID #1 in the Coder Group Settings Page... 33 Figure 3-10: Inbound IP Routing Table Page... 35 Figure 3-11: Outbound IP Routing Table Page... 36 Figure 3-12: Destination Phone Number Manipulation Page... 38 Mediant Media Gateways 4 Document #: LTRT-40002

Application Note Notices Notice This document describes AudioCodes IP-to-IP call routing feature for its SIP-based, Voice over IP (VoIP) media gateways. 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 the 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 2009 AudioCodes Ltd. All rights reserved. This document is subject to change without notice. Date Published: January-07-2009 Tip: When viewing this manual on CD, Web site or on any other electronic copy, all cross-references are hyperlinked. Click on the page or section numbers (shown in blue) to reach the individual cross-referenced item directly. To return back to the point from where you accessed the cross-reference, press the ALT and keys. Trademarks AC logo, Ardito, AudioCoded, AudioCodes, AudioCodes logo, CTI², CTI Squared, InTouch, IPmedia, Mediant, MediaPack, MP-MLQ, NetCoder, Netrake, Nuera, Open Solutions Network, OSN, Stretto, 3GX, TrunkPack, VoicePacketizer, VoIPerfect, What's Inside Matters, Your Gateway To VoIP, are trademarks or registered trademarks of AudioCodes Limited. All other products or trademarks are property of their respective owners. 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, and only Industry standard terms are used throughout this manual. IP-to-IP Trunking 5 January 2009

IP-to-IP Call Routing Typographical Conventions The typographical convention used throughout this guide is described in the table below: Table 1-1: Typographical Conventions Items Convention Used Example Screen, field, and parameter names Path to pages Enclosed by single quotation marks. Open the 'Coders' page. Bold font with the path given as: Menu name > submenu name > command. Access the 'Coders' page (Protocol Management menu > Protocol Definition submenu > Coders). Command buttons Bold font. Click the OK button. Values entered by typing Enclosed by double quotation marks. In the 'Gateway Name' field, enter "10.0.0.10". Related Documentation Document # LTRT-833xx LTRT-688xx LTRT-897xx Manual Name Mediant 1000 and Mediant 600 SIP User's Manual Mediant 2000 SIP User's Manual Mediant 3000, TP-8410 and TP-6310 SIP User's Manual Mediant Media Gateways 6 Document #: LTRT-40002

Application Note 1. Introduction 1 Introduction The AudioCodes SIP-based, VoIP media gateways support IP-to-IP Voice over IP (VoIP) call routing (or SIP Trunking). The IP-to-IP call routing feature enables Enterprises to seamlessly connect their IP-based PBX (IP-PBX) to SIP trunks, typically provided by an Internet Telephony Service Provider (ITSP). Enterprises can then communicate (using AudioCodes gateway) with PSTN networks (local and overseas) through ITSP s, which interface directly with the PSTN. Therefore, AudioCodes IP-to-IP feature enables Enterprises to replace the bundles of physical PSTN wires with SIP trunks provided by ITSP's and use VoIP to communicate within and outside the Enterprise network using its standard Internet connection. At the same time, AudioCodes gateways can also provide an interface with the traditional PSTN network, enabling PSTN fallback in case of IP connection failure with the ITSP s. The gateways also support multiple SIP Trunking. This can be useful in scenarios where if a connection to one ITSP goes down, the call can immediately be transferred to another ITSP. In addition, by allowing multiple SIP trunks, where each trunk is designated a specific ITSP, the gateway can route calls to an ITSP based on call destination (e.g., country code). Therefore, in addition to providing VoIP communication within an Enterprise s LAN, the gateway allows the Enterprise to communicate outside of the corporate LAN, using SIP Trunking. This includes remote (roaming) IP-PBX users (for example, employees using their laptops to communicate with one another from anywhere in the world such as airports etc.). AudioCodes gateways IP-to-IP feature can be implemented by Enterprises in the following example scenarios: VoIP between an Enterprise s headquarters and remote branch offices VoIP between an Enterprise and the PSTN via an ITSP. AudioCodes IP-to-IP call routing capability is feature-rich, allowing interoperability with different ITSP's or service providers: Easy and smooth integration with multiple ITSP SIP trunks. Supports SIP registration and authentication with ITSP servers (on behalf of the Enterprise's IP telephony system) even if the Enterprise's IP telephony system does no support registration and authentication. Supports transport protocols SIP over UDP, SIP over TCP, and SIP over TLS, one of which is generally required by the ITSP. Provides alternative routing to different destinations (another ITSP or the PSTN) when the connection with an ITSP network is down. Provides fallback to the legacy PSTN telephone network upon Internet connection failure. Provides Transcoding from G.711 to G.729 coder with the ITSP for bandwidth reduction. Supports SRTP, providing voice traffic security toward the ITSP. The IP-to-IP routing can be used in combination with regular media gateway applications. For example, an incoming IP call can be sent to an E1/T1 span or it can be forwarded to an IP destination. Therefore, AudioCodes gateways provide the ideal interface between Enterprises IP-PBX s and ITSP SIP trunks. To facilitate the understanding of the IP-to-IP feature, this document provides a configuration example scenario, described in Section 2 on page 23. IP-to-IP Trunking 7 January 2009

IP-to-IP Call Routing 1.1 Theory of Operation The gateway s IP-to-IP SIP session is performed by implementing Back-to-Back User Agent (B2BUA). The gateway acts as a user agent for both ends (legs) of the SIP call (from call establishment to termination). The session negotiation is performed independently for each call leg, using global gateway parameters such as coders, or using IP Profiles associated with each call leg. The IP Profiles can be used in the Inbound IP Routing (i.e., IP-to-Tel leg) and Outbound IP Routing (i.e., Tel-to-IP leg) tables to assign different configuration behaviors for these two IPto-IP call legs. The gateway also supports Network Address Translation (NAT) traversal for the SIP clients that are behind NAT. In this case, the gateway is defined with a global IP address. The figure below provides a simplified illustration of the gateway s handling of IP-to-IP call routing: Figure 1-1: Basic Schema of the Gateway s IP-to-IP Call Handling AudioCodes Gateway Inbound Call Outbound Call IP Group A Incoming IP Call Identified Source IP Group Identified Destination IP Group Outgoing IP Call IP Group B IP-to-Tel Tel-to-IP Source/Destination Source/Destination Number Manipulations Number Manipulations (Optional) (Optional) The basic IP-to-IP call handling process can be summarized as follows: 1. Incoming IP calls are identified as belonging to a specific logical entity in the network (referred to as a Source IP Group), according to the settings in the Inbound IP Routing table. 2. The Source IP Group is associated with a specific IP Group (Destination IP Group), and then sent to the appropriate destination address (defined by a Proxy Set) associated with this Destination IP Group. Number manipulation can be performed at both legs - inbound and outbound. The following subsections discuss the various terms used for configuring the gateway s IP-to-IP feature, using the gateway s Web interface. Proxy Sets: A Proxy Set is a group of Proxy servers, defined by IP address or fully qualified domain name (FQDN). You can define up to six Proxy Sets, each having a unique ID number and each containing up to five Proxy server addresses. The Proxy Sets are defined in the Proxy Set table (for a description of the table s parameters, refer to Section 1.2.4 on page 17). For each Proxy server address, you can define the transport type (i.e., UDP, TCP, or TLS). In addition, Proxy load balancing and redundancy mechanisms can be applied per Proxy Set (if a Proxy Set contains more than one Proxy address). Proxy Sets can later be assigned to IP Groups (of type SERVER only), described below. When the gateway sends an INVITE message to an IP Group, it is sent to the IP address/domain name defined for the Proxy Set that is associated with the specific IP Group. In other words, the Proxy Set represents the destination of the call. Typically, for IP-to-IP call routing, two Proxy Sets are defined for call destination one for each leg (IP Group) of the call (i.e., both directions). Mediant Media Gateways 8 Document #: LTRT-40002

Application Note 1. Introduction IP Groups: An IP Group represents a logical SIP entity in the gateway's network environment such as an ITSP SIP trunk, ITSP Proxy/Registrar server, IP-PBX, and remote IP-PBX users. An IP Group can be assigned various attributes such as a Proxy Set depicting the destination address of the IP Group, a host name, and other parameters that reflect parameters sent in SIP Request From\To messages. IP Groups are configured in the IP Group table (refer to Section 1.2.1 on page 13). The relationship between two communicating IP Groups on opposite legs of the call can be defined by either being a Serving or Served IP Group: Serving IP Group: an IP Group (e.g., ITSP) that provides service ( serves ) to another IP Group. This is the IP Group to where the gateway sends INVITE messages received from the Served IP Group as well as REGISTER messages for registering on behalf of the Served IP Group (e.g., IP-PBX). Served IP Group: an IP Group (e.g., IP-PBX) that is served by another IP Group (i.e., Serving IP Group), e.g., ITSP. The IP Groups can be configured to one of the following types: SERVER: represents IP Groups where the destination address (defined by the Proxy Set) is known, for example, ITSP or IP-PBX. USER: represents IP Groups for groups of users whose location is dynamically obtained by the gateway when REGISTER requests and responses traverse (or are terminated) by the gateway. Generally, these are remote IP-PBX users, for example, IP phones and soft phones. Typically, a USER IP Group is associated with a Serving IP Group that represents an IP-PBX, or an Application or Proxy server. Each SIP request sent by a user of this IP Group is proxied to the Serving IP Group by the gateway. For registrations, the gateway updates its internal database with the AOR and Contacts of the users. (Refer to Figure 1-2.) Digest authentication using SIP 401/407 responses (if needed) is performed by the Serving IP Group (e.g., IP-PBX). The gateway forwards these responses directly to the SIP users. A call to a registered user pertaining to a USER IP Group is routed using the Outbound IP Routing table (discussed later). The gateway searches the dynamic database (by using the Request URI) for an entry that matches a registered AOR or Contact. Once an entry is found, the IP destination is obtained from this entry, and a SIP request is then sent to this user. IP-to-IP Trunking 9 January 2009

IP-to-IP Call Routing Figure 1-2: Example of IP-to-IP Routing/Registration/Authentication of Remote IP-PBX Users Enterprise LAN WAN Firewall & Router IP Network DMZ PSTN DATABASE User s AOR/ Contact AudioCodes VoIP Gateway IP-PBX (Serving IP Group) INVITE Remote IP-PBX Users (USER IP Group) Mediant Media Gateways 10 Document #: LTRT-40002

Application Note 1. Introduction Survivability Mode (Refer to Figure 1-3): If enabled, the gateway records (in its database) the REGISTER messages sent by the clients belonging to the USER IP Group. If communication with the Serving IP Group (e.g., IP-PBX) fails, the USER IP Group enters into Survivability mode, in which the gateway uses its database for routing calls between the IP phones/soft phones belonging to the USER IP Group. The RTP packets between the IP phones in Survivability mode always traverse through the gateway. In addition, in Survivability mode, the gateway is capable of receiving new registrations. When the Serving IP Group is available again, the gateway returns to normal mode, sending INVITE and REGISTER messages to the Serving IP Group. Figure 1-3: Example of IP-to-IP Routing for IP-PBX Remote Users in Survivability Mode Enterprise LAN WAN Firewall & Router IP Network DMZ AudioCodes VoIP Gateway PSTN DATABASE User s AOR/ Contact Survivability Mode Upon IP-PBX connection loss, the gateway uses its DB to route calls IP-PBX (Serving IP Group) INVITE INVITE & REGISTER Remote IP-PBX Users (USER IP Group) Once defined, IP Groups can later be used in the following IP-to-IP routing tables: Inbound IP Routing, Outbound IP Routing, and Account. In addition, the IP Group can also be used within the IP Group table as a Serving IP Group, where calls originating from the IP Group are sent to the Serving IP Group, unless there is a different configuration in the Outbound IP Routing table and PreferRouteTable is set to 1. IP-to-IP Trunking 11 January 2009

IP-to-IP Call Routing Inbound and Outbound IP Routing: The gateway's IP-to-IP call routing capabilities is performed in two stages: 1. Inbound IP Routing: Recognizes the received call as an IP-to-IP call, based on various attributes such as the call's source IP address and assigns it to an IP Group. This stage is configured in the 'Inbound IP Routing Table' (for a description of the table s parameters, refer to Section 1.2.6 on page 20). The IP Group can be used as a source IP Group to identify and classify the IP Group from where the INVITE (i.e., call) is received. This IP Group can later be used in the Outbound IP Routing table. Destination host prefix (request URI hostname prefix) and source host prefix (From URI hostname prefix) of the inbound INVITE message can also be configured in this table for routing rules. In addition, the source IP address of the incoming INVITE can also be used for routing decisions. The source IP address can be derived either from the hostname in the Contact header (parameter SourceIPAddressInput is set to 0 - default) or from the received INVITE IP packet (parameter SourceIPAddressInput is set to 1). 2. Outbound IP Routing: Once recognized as an IP-to-IP call in the first stage and associated with a source IP Group (see above), the call is routed to the appropriate destination (i.e., IP address), configured in the Outbound IP Routing table (for a description of the table s parameters, refer to Section 1.2.5 on page 19). Accounts: Source host prefix (From URI hostname prefix) and destination host prefix (request URI hostname prefix) of the inbound INVITE message can also be configured in this table for routing rules. If the Destination IP Group is of type USER, the gateway searches for a match between the request URI (of the received INVITE) to an AOR registration record in the gateway s internal database. If a match is found, the INVITE is sent to the IP address of the registered contact Accounts are used by the gateway to register to a Serving IP Group (e.g., an ITSP) on behalf of a Served IP Group (e.g., IP-PBX). This is necessary for ITSP s that require registration to provide services. Accounts are also used for defining user name/password for digest authentication (with or without registration) if required by the ITSP. Multiple Accounts per Served IP Group can be configured for registration to more than one Serving IP Group (e.g., an IP-PBX that requires registering to multiple ITSP s). The Accounts are defined in the Account table (for a description of the Accounts table parameters, refer to Section 1.2.7 on page 21). Figure 1-4: Gateway Registration with Multiple ITSP s on behalf of IP-PBX REGISTER User1@Hostname1 ITSP A Serving IP Group 1 AudioCodes Gateway IP-PBX Served IP Group 4 Account Table AOR/Contact User & Hostname and/or Authentication UN/PWD REGISTER User2@Hostname2 ITSP B Serving IP Group 2 REGISTER User3@Hostname3 ITSP C Serving IP Group 3 Mediant Media Gateways 12 Document #: LTRT-40002

Application Note 1. Introduction 1.2 IP-to-IP Configuration Tables The configuration in the gateway s Web interface relating to IP-to-IP call routing is described in the subsections below. 1.2.1 SBC Settings Page The 'SBC Settings' page (Configuration tab > Protocol Configuration menu > SIP Advanced Parameters submenu > SBC Settings page item) allows you to enable the IP-to-IP feature. Note: To enable IP-to-IP capabilities on AudioCodes gateway, the following prerequisites must be met: The gateway must be loaded with the Feature Key that includes the SBC feature. The gateway must be running SIP version 5.4 or later. Table 1-1: SBC Settings Description Parameter Description Enable SBC [EnableSBC] SBC Registration Time [SBCRegistrationTim e] Enables or disables SBC. [1] Enable = Enables the IP-to-IP feature. [0] Disable Configures the value in (in sec) sent in the "expires" when the gateway replies with SIP 200 OK in response to Registration requests. Note: This parameter is applicable only to clients belonging to IP groups of type "USER". 1.2.2 MediaChannels ini File Parameter The ini file parameter MediaChannels defines the number of available media channels for IP-to-IP calls. Table 1-2: MediaChannels Parameter Description Parameter [MediaChannels] Description Determines the number of DSP channels that are allocated for IP-to-IP sessions (other DSP channels can be used for PSTN interface). Currently, the RTP streams for IP-to-IP calls always transverse through the gateway, and two DSP channels are allocated per IP-to-IP session. Therefore, the maximum number of Media channels for IP-to-IP calls for Mediant 1000, Mediant 2000, and Mediant 3000 is 120, 240, and 2016 respectively, corresponding to 60, 120, and 1008 IP-to-IP calls. IP-to-IP Trunking 13 January 2009

IP-to-IP Call Routing 1.2.3 IP Group Table The description of the parameters in the Web interface s IP Group table are described in the table below. Alternatively, the IP groups can be defined using the ini file parameter IPGroup. Table 1-3: IP Group Table Description Parameter IP Group ID Type Description Proxy Set ID SIP Group Name Description The unique identifying number (1-9) of the IP Group. The IP Group can be defined as one of the following types: SERVER = used when the destination address (configured by the Proxy Set) of the IP Group is known such as an ITSP, Proxy, IP-PBX, or Application server. USER = represents a group of users (such as IP Phones and Soft Phones) where their location is dynamically obtained by the gateway when REGISTER requests and responses traverse (or are terminated) by the gateway. These users are considered remote (far-end) users. Typically, this IP Group is configured with a Serving IP Group that represents an IP-PBX, Application or Proxy server that serves this USER-type IP Group. Each SIP request sent by a user of this IP Group is proxied to the Serving IP Group. For registrations, the gateway updates its internal database with the AOR and contacts of the users. Digest authentication using SIP 401/407 responses (if needed) is performed by the Serving IP Group. The gateway forwards these responses directly to the SIP users. To route a call to a registered user, a rule must be configured in the Outbound IP Routing table. The gateway searches the dynamic database (by using the request URI) for an entry that matches a registered AOR or Contact. Once an entry is found, the IP destination is obtained from this entry, and a SIP request is sent to the destination. The gateway also supports NAT traversal for the SIP clients that are behind NAT. In this case, the gateway must be defined with a global IP address. Mediant 1000 and Mediant 2000 support up to 100 registered users; Mediant 3000 supports up to 250 registered users. Brief string description of the IP Group. The value range is a string of up to 29 characters. The default is an empty field. The Proxy Set ID associated with the IP Group. All INVITE messages that are configured to be 'sent' to the specific IP Group are physically sent to the IP address defined in the Proxy Set. The range is 0-5, where 0 is the default Proxy Set. Note: The Proxy Set is only defined for SERVER type IP Groups. The request URI host name used in INVITE and REGISTER messages that are sent to this IP Group, or the host name in the From header of INVITE messages received from this IP Group. If not specified, the value of the global parameter ProxyName is used instead. The value range is a string of up to 49 characters. The default is an empty field. Note: If the IP Group is of type USER, this parameter is used internally as a hostname in the request URI for TDM-to-IP initiated calls. For example, if an incoming call from the gateway s T1 trunk is routed to a USER-type IP Group, the gateway first forms the request URI (destination_number@sipgroupname), and then it searches the User s internal database for a match. Mediant Media Gateways 14 Document #: LTRT-40002

Application Note 1. Introduction Parameter Contact User Serving IP Group ID Enable Survivability Routing Mode Description Defines the user part for the SIP From, To, and Contact headers of REGISTER messages, and the user part for the Contact header of INVITE messages that are received from this IP Group and forwarded by the gateway to another IP Group. Notes: This parameter is applicable only for USER-type IP Groups. This parameter is overridden by the Contact User parameter (if configured) in the Account table. If configured, INVITE messages initiated from the IP Group are sent to this Serving IP Group. In other words, the INVITEs are sent to the address defined for the Proxy Set that is associated with this Serving IP Group. The Request URI host name in these INVITE messages are set to the value of the parameter SIP Group Name defined for the Serving IP Group. Range 1 to 9. Notes: If the parameter PreferRouteTable is set to 1, the routing rules in the Outbound IP Routing table takes precedence over this Serving IP Group ID parameter. If this parameter is not configured, the INVITE messages are sent to the default Proxy or according to the Outbound IP Routing table. Determines whether Survivability mode is enabled for USER-type IP Groups. Disable (default). Enable = Survivability mode is enabled. If enabled, the gateway records in its local database the registration messages sent by the clients belonging to the USER-type IP Group. If communication with the Serving IP Group (e.g., IP-PBX) fails, the USER-type IP Group enters into Survivability mode in which the gateway uses its database for routing calls between the clients (e.g., IP phones) of the USER-type IP Group. The RTP packets between the IP phones in Survivability mode always traverse through the gateway. In Survivability mode, the gateway is capable of receiving new registrations. When the Serving IP Group is available again, the gateway returns to normal mode, sending INVITE and REGISTER messages to the Serving IP Group. Note: This parameter is applicable only to USER-type IP Groups. Defines the routing mode for outgoing SIP INVITE messages. [-1] Not Configured = The routing is done according to the selected Serving IP Group. If no Serving IP Group is selected, the gateway routes the call according to the 'Outbound IP Routing' table. (default) [0] Routing Table = The gateway routes the call according to the 'Outbound IP Routing' table. [1] Serving IP Group = The gateway sends the SIP INVITE to the selected Serving IP Group. If no Serving IP Group is selected, the default IP Group is used. If the Proxy server(s) associated with the destination IP Group is not alive, the gateway uses the 'Outbound IP Routing' table (if the parameter IsFallbackUsed is set 1, i.e., fallback enabled). [2] Request-URI = The gateway sends the SIP INVITE to the IP address according to the received SIP Request-URI host name. IP-to-IP Trunking 15 January 2009

IP-to-IP Call Routing Parameter Description SIP Re-Routing Mode Determines the routing mode after a call redirection (i.e., a 3xx SIP response is received) or transfer (i.e., a SIP REFER request is received). Always Use Route Table [0] Standard = INVITE messages that are generated as a result of Transfer or Redirect are sent directly to the URI, according to the Refer-To header in the REFER message or Contact header in the 3xx response (default). [1] Proxy = Sends a new INVITE to the Proxy. Note: Applicable only if a Proxy server is used and the parameter AlwaysSendtoProxy is set to 0. [2] Routing Table = Uses the Routing table to locate the destination and then sends a new INVITE to this destination. Notes: When this parameter is set to [1] and the INVITE sent to the Proxy fails, the device re-routes the call according to the Standard mode [0]. When this parameter is set to [2] and the INVITE fails, the device re-routes the call according to the Standard mode [0]. If DNS resolution fails, the device attempts to route the call to the Proxy. If routing to the Proxy also fails, the Redirect / Transfer request is rejected. When this parameter is set to [2], the XferPrefix parameter can be used to define different routing rules for redirected calls. This parameter is disregarded if the parameter AlwaysSendToProxy is set to 1. Determines the Request URI host name in outgoing INVITE messages. Disable (default). Enable = The gateway uses the IP address (or domain name) defined in the 'Outbound IP Routing' table as the Request URI host name in outgoing INVITE messages, instead of the value entered in the 'SIP Group Name' field. Mediant Media Gateways 16 Document #: LTRT-40002

Application Note 1. Introduction 1.2.4 Proxy Set Table The description of the parameters in the Web interface s Proxy Sets table are described in the table below. Alternatively, the Proxy Sets can be defined using the ini file parameter ProxySet. Table 1-4: Proxy Sets Table Description Parameter Proxy Set ID Proxy Address Transport Type Description The Proxy Set identification number. The valid range is 0 to 5 (i.e., up to 6 Proxy Set ID's can be configured). The Proxy Set ID #0 is used as the default Proxy Set, and if defined is backward compatible to the list of Proxies from earlier releases. You can define up to five IP addresses per Proxy Set and per IP address define the transport type (UDP, TCP or TLS). Note: Typically, when IP Groups are used, there is no need to use the default Proxy, and all routing and registration rules can be configured using the IP Group and Account tables. The IP address (and optionally port number) of the Proxy server. Up to five IP addresses can be configured per Proxy Set. Enter the IP address as an FQDN or in dotted-decimal notation (e.g., 201.10.8.1). You can also specify the selected port in the format: <IP Address>:<port>. If you enable Proxy Redundancy (by setting the parameter EnableProxyKeepAlive to 1 or 2), the device can operate with multiple Proxy servers. If there is no response from the first (primary) Proxy defined in the list, the device attempts to communicate with the other (redundant) Proxies in the list. When a redundant Proxy is located, the device either continues operating with it until the next failure occurs, or reverts to the primary Proxy (refer to the parameter ProxyRedundancyMode). If none of the Proxy servers respond, the device goes over the list again. The device also provides real-time switching (Hot-Swap mode) between the primary and redundant proxies (refer to the parameter IsProxyHotSwap). If the first Proxy doesn't respond to the INVITE message, the same INVITE message is immediately sent to the next Proxy in the list. The same logic applies to REGISTER messages (if RegistrarIP is not defined). Notes: If EnableProxyKeepAlive is set to 1 or 2, the device monitors the connection with the Proxies by using keep-alive messages (OPTIONS or REGISTER). To use Proxy Redundancy, you must specify one or more redundant Proxies. When a port number is specified (e.g., domain.com:5080), DNS NAPTR/SRV queries aren't performed, even if ProxyDNSQueryType is set to 1 or 2. The transport type per Proxy server. [0] UDP [1] TCP [2] TLS [-1] = Undefined Note: If no transport type is selected, the value of the global parameter SIPTransportType is used. IP-to-IP Trunking 17 January 2009

IP-to-IP Call Routing Parameter Proxy Load Balancing Method Enable Proxy Keep Alive Description Enables the Proxy Load Balancing mechanism per Proxy Set ID. [0] Disable = Load Balancing is disabled (default). [1] Round Robin = Round Robin. [2] Random Weights = Random Weights. When the Round Robin algorithm is used, a list of all possible Proxy IP addresses is compiled. This list includes all IP addresses per Proxy Set, after necessary DNS resolutions (including NAPTR and SRV, if configured). After this list is compiled, the Proxy Keep-Alive mechanism (according to parameters EnableProxyKeepAlive and ProxyKeepAliveTime) tags each entry as 'offline' or 'online'. Load balancing is only performed on Proxy servers that are tagged as 'online'. All outgoing messages are equally distributed across the list of IP addresses. REGISTER messages are also distributed unless a RegistrarIP is configured. The IP addresses list is refreshed according to ProxyIPListRefreshTime. If a change in the order of the entries in the list occurs, all load statistics are erased and balancing starts over again. When the Random Weights algorithm is used, the outgoing requests are not distributed equally among the Proxies. The weights are received from the DNS server by using SRV records. The device sends the requests in such a fashion that each Proxy receives a percentage of the requests according to its' assigned weight. A single FQDN should be configured as a Proxy IP address. The Random Weights Load Balancing is not used in the following scenarios: The Proxy Set includes more than one Proxy IP address. The only Proxy defined is an IP address and not an FQDN. SRV is not enabled (DNSQueryType). The SRV response includes several records with a different Priority value. Determines whether Keep-Alive with the Proxy is enabled or disabled. This parameter is configured per Proxy Set. [0] Disable = Disable (default). [1] Using OPTIONS = Enables Keep-Alive with Proxy using OPTIONS. [2] Using REGISTER = Enable Keep-Alive with Proxy using REGISTER. If set to 'Using OPTIONS', the SIP OPTIONS message is sent every user-defined interval, as configured by the parameter ProxyKeepAliveTime. If set to 'Using REGISTER', the SIP REGISTER message is sent every user-defined interval, as configured by the parameter RegistrationTime. Any response from the Proxy, either success (200 OK) or failure (4xx response) is considered as if the Proxy is communicating correctly. Notes: For Survivability mode for USER-type IP Groups, this parameter must be enabled (1 or 2). This parameter must be set to 'Using OPTIONS' when Proxy redundancy is used. When this parameter is set to 'Using REGISTER', the homing redundancy mode is disabled. When the active proxy doesn't respond to INVITE messages sent by the device, the proxy is tagged as 'offline'. The behavior is similar to a Keep-Alive (OPTIONS or REGISTER) failure. Mediant Media Gateways 18 Document #: LTRT-40002

Application Note 1. Introduction Parameter Description Proxy Keep Alive Time Defines the Proxy keep-alive time interval (in seconds) between Keep-Alive messages. This parameter is configured per Proxy Set. The valid range is 5 to 2,000,000. The default value is 60. Is Proxy Hot-Swap Note: This parameter is applicable only if the parameter EnableProxyKeepAlive is set to 1 (OPTIONS). When the parameter EnableProxyKeepAlive is set to 2 (REGISTER), the time interval between Keep-Alive messages is determined by the parameter RegistrationTime. Enables the Proxy Hot-Swap redundancy mode per Proxy Set. [0] No = Disabled (default). [1] Yes = Proxy Hot-Swap mode is enabled. If Proxy Hot-Swap is enabled, the SIP INVITE/REGISTER message is initially sent to the first Proxy/Registrar server. If there is no response from the first Proxy/Registrar server after a specific number of retransmissions (configured by the parameter HotSwapRtx), the INVITE/REGISTER message is resent to the next redundant Proxy/Registrar server. 1.2.5 Outbound IP Routing Table (Tel to IP) The description of the parameters in the Web interface s Outbound IP Routing table are described in the table below. Alternatively, outbound (Tel to IP) IP routing can be defined using the ini file parameter Prefix. Table 1-5: Outbound IP Routing Table Description Parameter Src IP Group ID Src Host prefix Dest Host Prefix Src. Trunk Group ID Dest. Phone Prefix Source Phone Prefix Description The ID of the IP Group from where the IP-to-IP call originated. Typically, this IP Group of an incoming INVITE is determined/classified using the Inbound IP Routing table. If not used (i.e., any IP Group), simply leave the field empty. Note: If this Source IP Group has a Serving IP Group, then all calls originating from this Source IP Group is sent to the Serving IP Group. In this scenario, this table is used only if the parameter PreferRouteTable is set to 1. The prefix of the SIP URI host name in the From header of the incoming INVITE. If configured, the gateway uses it for routing decisions. If not used simply leave the field empty. To denote any prefix, use the asterisk (*) symbol. The request SIP URI host name prefix of the incoming INVITE. If configured, the gateway uses it for routing decisions. If not used simply leave the field empty. To denote any prefix, use the asterisk (*) symbol. The source Trunk Group (1-99) for Tel-to-IP calls. For IP-to-IP calls, this parameter is not required (i.e., leave the field empty). To denote any Trunk Group, leave this field empty. Represents a called telephone number prefix. The prefix can be 1 to 19 digits long. An asterisk (*) represents all numbers. Represents a calling telephone number prefix. The prefix can be 1 to 19 digits long. An asterisk (*) represents all numbers. IP-to-IP Trunking 19 January 2009

IP-to-IP Call Routing Parameter Dest. IP Address Port Transport Type Dest IP Group ID IP Profile ID Description The IP address (and optionally port number) assigned to the prefix. For example, <IP address>:<port>. Domain names such as domain.com can be used instead of IP addresses. To discard outgoing IP calls, enter 0.0.0.0. The IP address 127.0.0.1 can be used when the IP address of the device itself is unknown (for example, when DHCP is used). Note: When using domain names, you must enter a DNS server IP address or alternatively, define these names in the 'Internal DNS Table'. Destination port. The transport layer type for sending the outbound SIP IP calls: [-1] Not Configured [0] UDP [1] TCP [2] TLS Note: When 'Not Configured' is selected, the transport type defined by the parameter SIPTransportType. The IP Group (1 to 9) to where you want to route the IP-to-IP call. The INVITE messages are sent to the IP address(es) defined for the Proxy Set that is associated with this IP Group. Typically, if you select an IP Group, it is unnecessary to configure a destination IP address (in the 'Dest IP Address' field). However, if both parameters are configured, the INVITE message is sent only to the IP Group. If the parameter AlwaysUseRouteTable is set to 1 (in the IP Group table), the request SIP URI host name in the INVITE message is set to the value of the parameter 'Dest IP Address' (if defined); otherwise, it is set to the value of the parameter 'SIP Group Name' (defined in the IP Group table). If this destination IP Group is of type USER, the gateway searches for a match between the request URI (of the received INVITE) to an AOR registration record in the gateway s internal database. The INVITE is then sent to the IP address of the registered contact. Note: The Dest IP Group ID parameter is also used as the Serving IP Group in the Account table for acquiring authentication user/password for this call. IP Profile ID for this destination IP Group. This allows you to assign different configuration attributes (e.g., voice coders) per IP Group, by using IP Profiles. 1.2.6 Inbound IP Routing Table (IP to Tel) The description of the parameters in the Web interface s Inbound IP Routing table are described in the table below. Alternatively, inbound (IP to Tel) IP routing can be defined using the ini file parameter PSTNPrefix. Table 1-6: Inbound IP Routing Table Description Parameter Dest. Host Prefix Source Host Prefix Description The Request URI host name prefix of the incoming INVITE message. If configured, the device uses it for IP-to-IP routing. If not used, it must be left empty. The asterisk (*) symbol can be used to depict any destination host prefix. The From header URI host name prefix of the incoming INVITE message. If configured, the device uses it for IP-to-IP routing. If not used, it must be left empty. The asterisk (*) symbol can be used to depict any source host prefix. Mediant Media Gateways 20 Document #: LTRT-40002

Application Note 1. Introduction Parameter Description Dest. Phone Prefix Source Phone Prefix Source IP Address Represents a called telephone number prefix. The prefix can be 1 to 49 digits long. An asterisk (*) represents all numbers. Represents a calling telephone number prefix. The prefix can be 1 to 49 digits long. An asterisk (*) represents all numbers. The source IP address of an IP-to-IP call (obtained from the Contact header in the incoming INVITE message) that can be used for routing decisions. Notes: You can configure from where the source IP address is taken, using the ini file parameter SourceIPAddressInput. If it is set to 0 (default), the source IP address is taken from host name in the Contact header. If it is set to 1, the source IP address is taken from the received INVITE IP packet. The source IP address can include the x wildcard to represent single digits. For example: 10.8.8.xx represents all the addresses between 10.8.8.10 to 10.8.8.99. The source IP address can include the asterisk (*) wildcard to represent any number between 0 and 255. For example, 10.8.8.* represents all addresses between 10.8.8.0 and 10.8.8.255. Trunk Group ID For IP-to-IP call routing, this must be set to -1. IP Profile ID Source IP Group ID IP Profile assigned to the routing rule. Assigns (classifies) an IP Group (1-9) to this incoming IP-to-IP call. This defines the IP Group (configured in the IP Group table) from where the INVITE message is received. This IP Group can later be used in the Outbound IP Routing table and as the Serving IP Group in the Account table for obtaining authentication user name/password for this call. 1.2.7 Account Table The description of the parameters in the Web interface s Account table are described in the table below. Alternatively, Accounts can be defined using the ini file parameter Account. Table 1-7: Account Table Description Parameter Description Served Trunk Group The Trunk Group ID for which the device performs registration and/or authentication to a destination IP Group (i.e., Serving IP Group). For IP-to-IP call routing, this parameter must be set to -1. Served IP Group The Source IP Group (e.g., IP-PBX) to which this account (registration / authentication) is applied. Serving IP Group Username Password The destination IP Group to where the REGISTER requests (if enabled in the Register field) are sent or Authentication is performed. The actual destination to where the REGISTER requests are sent is the IP address defined for the Proxy Set associated with this IP Group. In addition, for a SIP call that is identified by both the Served IP Group and Serving IP Group, the username and password for digest authentication defined in this table is used. Note: If there is no match for incoming or outgoing calls in the Account table, the received 401/407 response with credentials is relayed to the party that sent the SIP request message. Digest MD5 Authentication user name (up to 50 characters). Digest MD5 Authentication password (up to 50 characters). IP-to-IP Trunking 21 January 2009

IP-to-IP Call Routing Parameter HostName Register Contact User Description Defines the Address of Record (AOR) host name. It appears in REGISTER From/To headers as ContactUser@HostName. For successful registrations, this HostName is also included in the INVITE request's From header URI. If not configured or if registration fails, the 'SIP Group Name' parameter from the IP Group table is used instead. This parameter can be up to 49 characters. Enables registration. 0 = Disable. 1 = Enable. When enabled, the device sends REGISTER requests to the Serving IP Group. The registration HostName (host name in From/To headers) and ContactUser (user part in From/To and Contact headers) are taken from this 'Account' table. See the example below: REGISTER sip:audiocodes SIP/2.0 Via: SIP/2.0/UDP 10.33.37.78;branch=z9hG4bKac1397582418 From: <sip:contactuser@hostname>;tag=1c1397576231 To: <sip: ContactUser@HostName > Call-ID: 1397568957261200022256@10.33.37.78 CSeq: 1 REGISTER Contact: <sip:contactuser@10.33.37.78>;expires=3600 Expires: 3600 Content-Length: 0 Notes: Account registration is not affected by the parameter IsRegisterNeeded. You can define several rows in the Account table containing the same Served IP Group, but with different Serving IP Groups, user/password, HostName and ContactUser parameters. Therefore, this provides the capability to register a specific IP Group to multiple ITSP s. Defines the AOR user name. It appears in REGISTER From/To headers as ContactUser@HostName, and in INVITE/200 OK Contact headers as ContactUser@<device's IP address>. If not configured, the 'Contact User' parameter in the 'IP Group' table is used instead. Note: If registration fails, then the userpart in the INVITE Contact header contains the source party number. Mediant Media Gateways 22 Document #: LTRT-40002

Application Note 2. Case Study 2 Case Study This section provides an example setup for IP-to-IP call routing. In this example, AudioCodes gateway serves as the communication interface between an Enterprise s IP-PBX (located on the LAN) and the following network entities: ITSP SIP trunks (located on the WAN) Remote IP-PBX users (located on the WAN) Local PSTN network Calls from the Enterprise are routed according to destination. This example assumes the following: AudioCodes IP-to-IP gateway has a global IP address 212.25.125.136 is connected to the Enterprise s firewall/nat demilitarized zone (DMZ) network, providing the interface between the IP-PBX, and two ITSP s and the local PSTN. An Enterprise with an IP-PBX located behind a Firewall/NAT: IP-PBX IP address: 10.15.4.211 Transport protocol: UDP Voice coder: G.711 IP-PBX users: 4-digit length extension number and served by two ITSPs. The Enterprise also includes remote IP-PBX users that communicate with the IP-PBX via the gateway. All dialed calls from the IP-PBX consisting of four digits starting with digit 4 are routed to the remote IP-PBX users. Using SIP trunks, the IP-PBX connects (via AudioCodes gateway) to two different ITSP s: ITSP-A: ITSP-B: Implements Proxy servers with fully qualified domain names (FQDN): Proxy1.ITSP-A and Proxy2.ITSP-B, using TLS. Allocates a range of PSTN numbers beginning with +1919, which is assigned to a range of IP-PBX users. Uses voice coder G.723. Implements Proxy servers with IP addresses 216.182.224.202 and 216.182.225.202, using TCP. Allocates a range of PSTN numbers beginning with 0200, which is assigned to a range of IP-PBX users. Uses voice coder G.723. Registration and authentication is required by both ITSP s, which is performed by the gateway on behalf of the IP-PBX. The SIP REGISTER messages use different URI's (Host name and Contact user) in the From, To, and Contact headers per ITSP as well as username and password authentication. IP-to-IP Trunking 23 January 2009

IP-to-IP Call Routing Outgoing calls from IP-PBX users are routed according to destination: If the calls are dialed with the prefix +81, they are routed to ITSP-A (Region A). If the calls are dialed with the prefix 9, they are routed to the local PSTN network. For all other destinations, the calls are routed to ITSP-B. AudioCodes gateway is also connected to the PSTN through a traditional T1 ISDN trunk for local incoming and outgoing calls. Calls dialed from the Enterprise s IP-PBX with prefix '9' are sent to the local PSTN. In addition, in case of Internet interruption and loss of connection with the ITSP trunks, all calls are rerouted to the PSTN The figure below provides an illustration of this case study setup: Figure 2-1: SIP Trunking Setup Example Region A PSTN Network Enterprise IP-PBX IP Group 3 Proxy Set 3 (10.15.4.211) Firewall & Router ITSP-A IP Group 1 Proxy Set 1: (Proxy1.TelIP) (Proxy2.TelIP) Account 1 Registration to IP Group 1 SIP Trunk Remote IP-PBX Users IP Group 4 (USER) LAN IP Phones AudioCodes VoIP Gateway (212.25.125.136) DMZ Trunk Group ID 1 Account 2 Registration to IP Group 2 IP Network SIP Trunk ITSP-B IP Group 2 Proxy Set 2: (216.182.224.202) (216.182.225.202) Local PSTN Network PSTN Network Region B Mediant Media Gateways 24 Document #: LTRT-40002

Application Note 3. Configuring AudioCodes Gateway 3 Configuring AudioCodes Gateway This section provides step-by-step procedures for configuring AudioCodes' gateway. These procedures are based on the setup example described in Section 2 on page 23. The steps for configuring the gateway can be summarized as follows: Enable the IP-to-IP feature (refer to Section 3.1 on page 25). Configure the number of media channels (refer to Section 3.2 on page 26). Configure a Trunk Group for interfacing with the local PSTN (refer to Section 3.3 on page 27) Configure the Proxy Sets (refer to Section 3.4 on page 28). Configure the IP Groups (refer to Section 3.5 on page 30). Configure the Accounts (refer to Section 3.6 on page 32). Configure the IP Profiles (refer to Section 3.7 on page 33). Configure inbound and outbound IP routing (refer to Section 3.8 on page 34). Configure destination phone number manipulation (refer to Section 3.10 on page 38). 3.1 Step 1: Enable the IP-to-IP Capabilities This step describes how to enable the gateway's IP-to-IP capabilities (SBC). To enable IP-to-IP capabilities: 1. Open the SBC Configuration page (Protocol Configuration menu -> SIP Advanced Parameters submenu -> SBC Configuration). Figure 3-1: SBC Settings Page 2 2. From the Enable SBC drop-down list, select Enable. Note: To enable the IP-to-IP capabilities on AudioCodes gateway, your gateway must be loaded with the feature key that includes the SBC feature and the gateway must be running SIP version 5.4 or later. IP-to-IP Trunking 25 January 2009

3.2 Step 2: Configure the Number of Media Channels IP-to-IP Call Routing The number of media channels represents the number of digital signaling processors (DSP) channels that the gateway allocates to IP-to-IP calls (the remaining DSP channels can be used for PSTN calls). Two IP media channels are used per IP-to-IP call. Therefore, the maximum number of media channels (for IP-to-IP calls) available on the Mediant 1000 and Mediant 2000 gateways is 120 and 240 channels respectively corresponding to 60 and 120 IP-to-IP calls respectively. To configure the number of the media channels: 1. Open the 'Admin" page, by appending the case-sensitive suffix AdminPage to the gateway's IP address in your Web browser's URL field (e.g., http://10.15.4.15/adminpage). Figure 3-2: Admin Page for IP Media Channels Settings 4 5 3 2. In the Admin Page, on the left pane, click ini Parameters. 3. From the 'Parameter Name' drop-down list, select the parameter "MEDIACHANNELS". 4. In the 'Enter Value' field, enter 120 to enable up to 60 IP-to-IP calls. 5. Click Apply New Value. Mediant Media Gateways 26 Document #: LTRT-40002