FRAFOS ABC-SBC Generic SIP Trunk Integration Guide for ShoreTel 14.2

Transcription

1 FRAFOS ABC-SBC Generic SIP Trunk Integration Guide for ShoreTel 14.2 FRAFOS GmbH FRAFOS GmbH Windscheidstr Berlin Germany WWW: IN # 15023

2 Table of Contents 1 General Information FRAFOS GmbH FRAFOS ABC SBC Features A Typical ABC SBC Configuration Example Identifying Network topology Describing ABC SBC Realms and Call Agents Configuring Registration Cache and Throttling SIP Routing Configuring NAT Handling and Media Anchoring Summary of Rules ShoreTel Configuration Call Control Options: Site Settings ShoreTel Switch Configuration ShoreTel System Settings Trunk Groups Remove leading + from Outbound INVITEs ShoreTel System Settings Individual Trunks ABC SBC Configuration ABC-SBC Interface Configuration - ShoreTel ABC- SBC Interface Configuration SIP Carrier ABC- SBC Realms and Call Agents Enabling RTP Anchoring ABC- SBC Routing Rules Troubleshooting Non- Default SIP Signalling Interface... 48

3 1 General Information This documents provides an overview of the FRAFOS ABC SBC/WebRTC gateway and provides a quick reference for using ShoreTel and FRAFOS ABC SBC products. The following product versions were used: ShoreTel version: 14.2, build ABC- SBC Version: We tested this configuration on ABC- SBC version and have confirmed its successful operation. Carrier configuration is provided as an example and will vary depending on network deployment, SIP carrier, or other factors. This is NOT a guide for connecting to any particular carrier s SIP trunking services. ABC- SBC is a very flexible platform and can connect to a carrier in many different ways, The ABC SBC supports connection to carriers with a variety of methods (behind NAT LAN only, WAN- LAN, LAN- DMZ, etc.). Carrier configuration will require an understanding of SIP networking, NAT traversal, and general computer networking. Basic knowledge of Linux operating systems and the SEMS service will also be helpful, but are not necessarily required. More information on the configuration of the ABC SBC is provided under

4 2 FRAFOS GmbH FRAFOS was started in Germany by VOIP industry veterans and offers SIP session management, WebRTC and security solutions of the latest generation. The FRAFOS solutions come either as a standalone solution or as a cloud ready implementation. The ABC SBC enables VoIP operators to simplify their service infrastructure and prepares them for future challenges. Contact information: FRAFOS GmbH Windscheid Str. 18 c/o Ahoi Berlin Germany mail@frafos.com Phone: Web:

5 3 FRAFOS ABC SBC Features The ABC SBC acts as a Back2Back UA (B2BUA) offering the following features: Topology hiding Per source/destination routing and security policies Call limitation SIP message mediation Transport level mediation Management GUI Monitoring and call tracing PCAP collection SNMP V2 alarms and status information NAT traversal TLS, SRTP Media control Registration offloading and throttling. Load balancing and route failover Support for multiple network interfaces Active/Standby configuration with call handover after hardware/software failure Support (parsing and caching) of PATH header Caching of the IMS related headers P-Associated-Identities and Service-Path. In addition FRAFOS offers a number of extension packages: 1. Transcoding package: The ABC SBC platform offers software based transcoding with support of G711u/a, G726, GSM, ilbc, L16, G722, Speex, G729, G729a/b and AMR codecs. Codecs G729, G729a/b and AMR are subject to patent licenses. 2. Media server package: The ABC SBC offers a comprehensive media server platform. The media server package enables the operator to integrate announcement or recording services into the call control process. Further, the open interfaces of the media server platform enable the rapid development of novel applications as well as the seamless integration of the ABC SBC media capabilities with the operator s media service infrastructure. As part of the ABC SBC media package, FRAFOS offers the following features: o Announcement and ring-tone services o Call recording o Open programming interfaces

6 3. WebRTC Gateway: The WebRTC package enables the operator to seamlessly integrate WebRTC users into the SIP network. With support for SIP over Websockets, OPUS and SRTP the ABC SBC acts as a gateway between the WebRTC users and the SIP infrastructure. 4. Central Monitoring: The FRAFOS monitoring solution enables service providers to control and monitor multiple instances of the ABC SBC and display usage and performance statistics including call traces, message details, QoS information and system performance statistics.

7 4 A Typical ABC SBC Configuration Example Many SBC deployments, especially in smaller networks, follow a simple schema, which is given through the network structure. In this typical network, the SBC bridges between an internal network, where the home proxies, PBXs and other servers like conference and application servers are located, and the public network, where the user agents reside. Typically, in such a network the main motivations for deploying an SBC are network separation for security reasons foolproof and always-working NAT handling protection of the core network from high registration load protection against fraud by enforcing call limits possibility for monitoring and tracing for troubleshooting This chapter presents step by step how to address these network aspects using the ABC SBC. The configuration presented here also corresponds to the sample configuration pre-configured in the virtual machine version of the ABC SBC which is provided under It assumes an SBC sitting between two networks, a public one with user telephones and a private protected one with operator s infrastructure. 4.1 Identifying Network topology Simple as it is in this case, the network topology is shown in Sample network Topology. Figure 1 Sample network Topology What administrator needs to do in this step is configuration of the physical network interfaces and of the SBC-level interfaces. The ABC SBC has two physical interfaces, one public connecting to the public networks, here with IP address , and one private connecting to the private network, here with IP address The physical interfaces are configured using procedures described in Section Physical and System Interfaces. User agents are located in the public network and have IP addresses from any network, and they are configured to use the public interface of the SBC with the address as proxy (in a real world

8 deployment, this address would not be a private RFC1918 address, but a public one). A proxy (or PBX) and a conference (or other application) server are located in the internal network. The ABC SBC can communicate with the entities in the internal network through its interface in the private network which has the IP address The detailed procedure for setting up SBC interfaces is described in Section SBC Interfaces. It links media processing, signaling and administration with physical interfaces, IP addresses and port ranges. 4.2 Describing ABC SBC Realms and Call Agents The network topology is described in the ABC-SBC configuration by Realms and Call Agents. Call Agents are typically consumer or operator SIP devices identified by their IP addresses or DNS names. They are grouped in networks called Realms whose processing rules they share. In our example two Realms are created in the SBC: public and internal_network. Figure 2: Creation of Realm Figure 3: Public and private Realms In the Realm public, the call agent public_users is created with IP address /0, which means that public_users can have any IP address, or: requests received from any IP address on the public interface will be identified as coming from the Call Agent public_users. The address list can include multiple addresses that are used for routing (See section Determination of the IP destination and Next-hop Load- Balancing). Also a backup call agent can be defined here which can be used as alternate destination if

9 forwarding to the primary destination fails. The CA definition further specifies interfaces used for sending and receiving signaling and media and availability management information see Section IP Blacklisting: Adaptive Availability Management for more information. Figure 4: Create public-users Call Agent As we have neither defined a specific IP:port for the Call Agent nor a hostname, requests can be routed to that Call Agent only by Request URI, or by setting the destination IP explicitly in the routing rule.

10 Figure 5: Public Call Agents list For the internal realm, the call agents proxy and conference are created with IP addresses and :5080 respectively. Figure 6: Internal Call Agents list 4.3 Configuring Registration Cache and Throttling REGISTER processing accommodates several goals: off-loading servers behind the SBC, enforcing frequent re-registration load to keep NAT bindings alive and dealing with REGISTER avalanches caused by different sorts of outages. For REGISTER requests coming from the public side, the ABC SBC is configured to cache the registrations using the Enable REGISTER caching action. The cache works as follows: For every new registration, it creates an alias, a special unique one-time identifier. It saves the original contact along with the alias in the local registrar cache. To facilitate NAT traversal, it also saves the IP address, port and transport with which the

11 REGISTER was received. It may re-adjust re-registration period so that it is frequent towards client for NAT keep-alives and less frequent downstream for better performance. It replaces the Contact in the REGISTER with a combination of the alias and the SBCs IP address: alias@sbc_ip:sbc_port. This way, the aliased contact propagated downstream hides details of NAT-related address translation performed at the SBC and manipulates re-registration period as needed. The cache entry becomes effective once the REGISTER request is positively confirmed by the downstream SIP element. Thus, when the REGISTER request is then routed to the registrar (the home proxy, here Call Agent proxy), the alias@sbc_ip:sbc_port is saved as he registered contact address of the user at the registrar. We define this rule in the A rules of the public Realm, so that it is executed for REGISTER requests coming from any user agent defined under the Realm. Figure 7: Rule A Definition for caching REGISTERs coming from public realm In order to protect the home proxy from the bulk of the registration load, the action REGISTER throttling

12 is enabled with a Minimum registrar expiration, i.e., the re-register interval used upstream to the home proxy, set to the default of 3600 (one hour), while the Maximum UA expiration, i.e., the re-register period for the user agents, is set to 30 seconds. 4.4 SIP Routing The SIP routing tables (B tables) define to which Call Agent a call is forwarded. In our example, there are two cases: calls from the UAs towards the proxy server and calls from the internal network towards the UAs. Calls from the User Agents are routed towards the proxy with a simple rule. Here we route all calls from the public realm to the proxy - we might also set a filter on Source Call Agent, which would be equivalent in our case. We route by setting the next_hop (the destination IP address) directly. Figure 8: Rule B Definition for the sample network The next rule specifies routing of all calls from the internal network towards the registered UAs. If the home proxy wants to send a call to a user, it finds in its registrar database the alias@sbc_ip:sbc_port

13 as contact for the user, thus it sends the call to the SBC with the alias in the request URI like this: INVITE In the SBC, we use the action Retarget R-URI from cache (alias) to look up the UAs IP and port values and set the request-uri to it. We also use the Enable NAT handling and Enable sticky transport options to handle NATs properly. Using these options the SBC will send the request to the IP and port where the REGISTER request was received from and using the same transport protocol it was received on. Figure 9: Rule A Definition for internal CAs We can then use the R-URI to determine request s destination. For simplicity, in this example we define a catch-all routing rule for the complete internal network, which includes all call agents defined there. (We may also define special routing rules for the different call agents in the internal network if they would have to be treated separately, e.g. if some calls need to be sent to a peering partner.)

14 Figure 10: Rule B Definition for internal-network Realm 4.5 Configuring NAT Handling and Media Anchoring We have already used the NAT option in the Retarget R-URI from cache (alias) action above. In order to route in-dialog requests to the caller properly even if the UA is behind NAT, we use the Enable dialog NAT handling action. This will make the SBC remember the source address of the caller for the dialog and use that to send in-dialog requests.

15 Figure 11: Rule A Definition for NAT handling For the RTP to flow properly through different NATed users - and also from the internal network to the public network for calls to conference bridge server - we Enable RTP anchoring with the Force symmetric RTP for UAC option enabled. To anchor the RTP of all calls at the SBC, we leave the Enable intelligent relay option unchecked; if we want to reduce bandwidth consumption and latency (total mouth-to-ear delay), we can also enable the intelligent relay option if we are sure that no users are behind double NATs.

16 Figure 12: RTP Anchoring Rule Definition (A) We enable this for calls in both directions - from and to the UAs. Figure 13: RTP Anchoring Rule Definition (C)

17 4.6 Summary of Rules The rules we have created so far can be seen in the Overview screen. The rules implement so far routing from the external to the private network and vice versa, NAT handling and registration caching. Figure 14: Rule list for sample network

18 5 ShoreTel Configuration 5.1 Call Control Options: ShoreTel System Settings General: The first settings to address within the ShoreTel system are the general system settings. These configurations include the Call Control, the site and the Switch Settings. If these items have already been configured on the system, skip this section and go on to the ShoreTel System Settings Trunk Groups section below. Call Control Settings: The first settings to configure within ShoreTel Director are the Call Control Options. To configure these settings for the ShoreTel system, log into ShoreTel Director and select Administration then Call Control followed by Options (Figure 1). Figure 1 Administration Call Control Options

19 The Call Control Options screen will then appear (Figure 2). Figure 2 Call Control Options In the General parameters, the DTMF Payload Type (96 127) defaults to a value of 102, this parameter may need to be changed to correctly interconnect with your SIP carrier. Consult your SIP carrier for the payload type if you experience DTMF issues. Within the SIP parameters; confirm that the appropriate settings are made for the Realm Enable SIP Session Timer and Always Use Port 5004 for RTP parameters. The next settings to verify are the Voice Encoding and Quality of Service, specifically the Media Encryption parameter, make sure this parameter is set to None, otherwise you may experience one- way audio issues. Please refer to ShoreTel s Administration Guide for additional details on media encryption and the other parameters in the Voice Encoding and Quality of Service area. The ShoreTel legacy parameter Always Use Port 5004 for RTP should be disabled by default, if it s enabled you will need to disable it. It is required for implementing SIP on the ShoreTel system. For SIP configurations, Dynamic User Datagram Protocol (UDP) must be used for RTP Traffic. If the parameter is disabled, Media Gateway Control Protocol (MGCP) will no longer use UDP port 5004;

20 MGCP and SIP traffic will use dynamic UDP ports. Once this parameter is disabled (unchecked), make sure that everything (IP Phones, ShoreGear Switches, ShoreTel Server, Distributed Voice Mail Servers / Remote Servers, Conference Bridges and Contact Centers) is fully rebooted this is a one time only item. By not performing a full system reboot, one- way audio will probably occur during initial testing. 5.2 Site Settings The next settings to address are the administration of sites. These settings are modified under the ShoreTel Director by selecting Administration then Sites (Figure 3). Figure 3 Site Administration This selection brings up the Sites screen. Within the Sites screen select the name of the site to configure. The Edit Site screen will then appear. The only changes required to the Edit Site screen are to the Admission Control Bandwidth and Intra- Site / Inter- Site Calls parameters (Figure 4).

21 Figure 4 Site Bandwidth settings Note: Bandwidth of 2048 is just an example. Please refer to the ShoreTel Planning and Installation Guide for additional information on setting Admission Control Bandwidth. Sites Edit screen Admission Control Bandwidth The Admission Control Bandwidth defines the bandwidth available to and from the site. This is important as SIP trunk calls may be counted against the site bandwidth. Bandwidth needs to be set appropriately based on site setup and configuration with your SIP provider. Please refer to the ShoreTel Planning and Installation Guide for additional information. Sites Edit screen Intra / Inter- Site Calls By default, ShoreTel 14.x has 12 built- in codecs; these codecs can be grouped as Codec Lists and defined in the sites page for Inter- site and Intra- site calls. Configure the "Intra- Site Calls" option to a Codec List that contains the desired codecs and save the change. Please consult your SIP carrier for a list of supported codecs, based on that information select the best codec list or create a new list that contains the supported codecs. ABC- SBC can transcode codecs if needed, but by default passes codec negotiation from ShoreTel directly to the carrier. Please refer to the ShoreTel Planning and Installation Guide for additional information. 5.3 ShoreTel Switch Configuration The final general settings to configure are the ShoreGear switch settings. These changes are modified by selecting Administration then Platform Hardware, then Voice Switches / Service Appliances followed by Primary in ShoreTel Director (Figure 6).

22 Figure 6 Administration Switches This action brings up the Primary Voice Switches / Service Appliances screen. From that screen simply select the name of the switch to configure. The Edit ShoreGear Switch screen will be displayed. Within the Edit ShoreGear Switch screen, select the desired number of SIP Trunks from the ports available (Figure 7).

23 Figure 7 ShoreGear Switch Settings Each port designated as a SIP Trunk enables the support for 5 individual trunks. Note: If you would like Jack based Music On Hold (MOH) to be played when calls are on hold, then the MOH source needs to be the same ShoreGear switch as the SIP Trunks. This is only applicable for ShoreTel Physical Switches. Starting with ShoreTel 13, the additional option of Port Type was added for half- width ShoreGear switches. The new selection is called SIP Trunk with Media Proxy. It ensures that the ShoreTel system that is being used for SIP Trunks will provide feature parity similar to PRI trunks. These feature include RFC 2833 DTMF detection for Office Anywhere, External or Simultaneous Ring calls, three party Mesh Conferencing (without needing to configure MakeMe conference ports), Call Recording, Silent Monitoring, Barge- In, Whisper Page, Invites with no SDP and when there s no common codec between ITSP and the local extension. By default, ShoreTel Virtual Trunk Switches include SIP Media Proxy resources; therefore, no configuration is required.

24 For further information on SIP Trunk with Media Proxy please refer to Chapter 18 of the ShoreTel 14.x System Administration Guide. 5.4 ShoreTel System Settings Trunk Groups ShoreTel Trunk Groups only support Static IP Addresses for Individual Trunks. In trunk planning, the following needs to be considered. - ABC SBC LAN interface should always be configured to use a Static IP Address. The settings for Trunk Groups are changed by selecting Administration, then Trunks followed by Trunk Groups within ShoreTel Director (Figure 8). Figure 8 Administration Trunk Groups This selection brings up the Trunk Groups screen (Figure 9). Figure 9 Trunk Group Settings From the pull down menus on the Trunk Groups screen, select the site desired and select the SIP trunk type to configure. Then click on the Go link from Add new trunk group at site. The Edit SIP Trunk Group screen will appear (Figure 10).

25 Figure 10 SIP Trunk Group Settings The Enable SIP Info for G.711 DTMF Signalling parameter should not be enabled (unchecked). Enabling SIP info is currently only used with SIP tie trunks between ShoreTel systems. The Profile: parameter should be set to Default ITSP, this profile will work with most SIP carriers. The Enable Digest Authentication parameter defaults to <None> and modification is not required when connecting to ABC SBC. The next item to change in the Edit SIP Trunks Group screen is to make the appropriate settings for the Inbound: parameters. (Figure 11). Figure 11 Inbound

26 Within the Inbound: settings, ensure the Number of Digits from CO: is configured to match the number of inbound digits sent by your SIP carrier. If you are unsure of how many digits are being sent please consult your SIP carrier. Enable (check) the DNIS or DID parameters as needed. It is no longer needed to enable the Extension and Tandem Trunking parameter. For additional information on these parameters please refer to the ShoreTel Administration Guide. The following section is configured in the same way as any normal Trunk Group. Figure 12 Outbound and Trunk Services Enable (check) the Outbound parameter and define a Trunk Access Code and Local Area Code as appropriate. In the Billing Telephone Number: be sure to specify the main telephone number provided by your SIP Carrier. In the Trunk Services: area, make sure the appropriate services are enabled or disabled based on what your SIP carrier supports and what features are needed from this Trunk Group. You will need to enable (check) the Enable Original Called Information parameter. This allows the ShoreTel system to include the called telephone number as part of a SIP Diversion header for forwarded calls. The parameter Caller ID not blocked by default determines if the call is sent out as <unknown> or with caller information (Caller ID), be sure to enable (check) this parameter. User DID will impact how information is passed out to the SIP Trunk group.

27 After these settings are made to the Edit SIP Trunk Group screen, select the Save button to input the changes. The final parameters for configuration in the Trunk Group are Trunk Digit Manipulation (Figure 13): Figure 13 Trunk Digit Manipulation The settings in Figure 13 will work with most North American SIP carriers. If you run into outbound call issues please consult your SIP carrier to see if outbound digit manipulation is required and update the parameters here accordingly. 5.5 Remove leading + from Outbound INVITEs Some SIP carriers will encounter routing issues if INVITEs from ShoreTel contain the + leading the dialled number. It is recommended add a custom dial string to remove this leading +, follow instructions below to configure this.

28 Figure 14 ShoreTel Director Support Entry Go to ShoreTel Director login page and on your keyboard, hold down the <CTRL> and <Shift> keys and with the mouse pointer click on the U of the Username: field. This will enable the Support Entry mode of the ShoreTel Director, as referenced above in (Figure 14).Log into ShoreTel Director with your normal administration user credentials. Navigate to the Edit SIP Trunk Group page, by selecting Administration followed by Trunks, then Trunk Groups, then in the Trunk Groups page, select the Trunk Group you created for ABC- SBC.This action brings up the Edit SIP Trunk Group page. Scroll down to the bottom of the page, in the Trunk Group Dialing Rules: parameter section, to the right of the Custom: parameter click on the Edit button as noted below Figure 15 Trunk Group Dialling Rules Custom This action brings up the Trunk Groups Dialing Rules Webpage Dialog as noted below:

29 Figure 16 Trunk Group Dialling Rules Webpage Dialog In the blank area of the Webpage Dialog, enter ;16E and then click on the Save button. Be sure to enter the exact syntax, this includes the semicolon. This syntax is case sensitive, verify that with above given figure. This custom Dial Plan will cause outbound digits to be sent without a leading +, this may be required by your SIP carrier. If your carrier requires a leading + then remove this parameter by simply blanking out this dialog box. This completes the settings needed to set up the trunk groups on the ShoreTel system. 5.6 ShoreTel System Settings Individual Trunks This section covers the configuration of the individual trunks. Select Administration, then Trunks followed by Individual Trunks to configure the individual trunks (Figure 17). Figure 17 Administration Individual Trunks

30 The Trunks by Group screen is used to change the individual trunks settings that appear (Figure 18). Figure 18 Trunks by Group Select the site for the new individual trunk(s) to be added and select the appropriate trunk group from the pull down menu in the Add new trunk at site area. In this example, the site is Headquarters and the trunk group is ABC- SBC, as created above, see Figure 18. Click on the Go button to bring up the Edit Trunk screen (Figure 19). Figure 19 Edit Trunks Screen for Individual Trunks From the individual trunks Edit Trunk screen, input a name for the individual trunks, select the appropriate switch, select the SIP Trunk type and input the number of trunks. When selecting a name, the recommendation is to name the individual trunks the same as the name of the trunk group so that the trunk type can easily be tracked. Select the switch upon which the individual trunk will be created. For the IP Address, define the IP address of the Internal Interface of the ABC- SBC (refer to Sec 6.1). The last step is to select the number of individual trunks desired (each one supports one audio path example if 10 is configured, then 10 audio paths can be established at one time). Once these changes are complete, select the Save button to commit changes. Note: Individual SIP Trunks cannot span networks. SIP Trunks can only terminate on the switch selected. There is no failover to another switch. For redundancy two trunk groups will be needed with each pointing to another ABC- SBC Interface or System just the same as if PRI were being used. After setting up the trunk groups and individual trunks, refer to the ShoreTel Planning and Installation Guide to make the appropriate changes for the User Group settings. This completes the settings for the ShoreTel system side.

31 6 ABC SBC Configuration This guide assumes you have installed ABC- SBC with the correct network deployment for your environment. Please view the installation instructions in the ABC SBC handbook 1. Please ensure the basic networking is configured correctly on the ABC- SBC s host operating system before continuing with this guide. In this guide we will be deploying ABC- SBC with two physical interfaces, with one interface plugged into a switch on our local network, and the other plugged into a WAN port with no hardware firewall. This is the most typical deployment scenario. 6.1 ABC-SBC Interface Configuration - ShoreTel Regardless of how your ABC- SBC has been deployed (WAN- LAN, WAN- DMZ, LAN only, etc.) the configuration for ShoreTel remains the same. The only requirement is that you have an interface (System- >Interfaces in ABC- SBC GUI), then create a new interface (Figure 20) in SBC configured on the same local network (or a local network that is routable without NAT) as your SIP trunk ShoreGear and the Public IP Address parameter is not configured on that interface (Figure 21). Figure 20 ABC- SBC System Interfaces 1 See

32 Please use the following parameters: Figure 21 ABC- SBC Internal Signalling Interface Interface Name Identifiable Name for this Interface Interface Type Chose Signalling for this interface Interface Description Short Description of this Interface System Interface Corresponding physical interface on ABC- SBC OS IP Address This is the same IP you entered in the Individual Trunks section earlier in this guide, it should be an internal IP that is accessible by the ShoreGear without NAT and is assigned to the corresponding physical interface selected above. Public IP Address Select the IP you would like to use that corresponds to the System Interface setting used for NAT scenarios, leave blank for this interface. Port This will be port used for SIP signalling, recommended value: See Sec. 6.7 if you wish to use a different port Interface options Leave blank. Press Save.

33 You can also use another port for this interface besides 5060 if you wish, see Sec. 6.7 on how to set up the correct ShoreTel SIP profile for using a non- default port. Next we will set up the internal media interface. This will be set up the exact same as the signalling interface, except Interface Type will be Media, Ports will now be a range that defines RTP port range, and the name/description should match this as well. See Figure 22 for example configuration. Figure 22 ABC- SBC Internal Media Interface The media interface will define the RTP settings used between ShoreTel and ABC- SBC. Ensure your Ports parameter includes a range big enough to support the number of individual trunks you set up in ShoreTel. Press Save. 6.2 ABC- SBC Interface Configuration SIP Carrier You configuration for this section may vary depending on your deployment. In this example we will be setting up a carrier that is on a separate physical interface with its own dedicated IP. It will be connecting to our carrier without NAT. For more configuration examples please visit: A_Typical_SBC_Configuration_Example.html Please consult your SIP carrier for more information on interconnection. There may be additional configuration needed that will not be shown in this guide. First, create a new interface to use for signalling to your carrier. (Figure 20 shows how to do this). Configure the Parameters for the carrier interface as shown in Figure 23

34 Figure 23 ABC- SBC Carrier Signalling Interface Note: This is only an example configuration and may not apply to your environment. You may have to configure NAT or use a different port for your carrier. Please contact your SIP carrier for the correct information. After you have entered the correct settings press Save Next we will setup a Media Interface for our Carrier. This will be similar to the media interface we created in Sec. 6.1, see Figure 24 for example configuration.

35 Figure 24 ABC- SBC Carrier Media Interface Once you have entered the correct setting press Save. Confirm that all interfaces are set correctly and select activate to confirm changes and restart ABC- SBC service (Figure 25). Figure 25 ABC- SBC Confirm Changes 6.3 ABC- SBC Realms and Call Agents Now we will create 2 realms, one for ShoreTel and one for our carrier. We will also create 1 call agent in each realm, which will be used to identify devices/peers in each realm. In the ABC- SBC GUI navigate to Relams and select Insert new Realm (Figure 26)

36 Figure 26 ABC- SBC new Realm Give the Relam an identifying name, in this example we will name it ShoreTel (Figure 27) Figure 27 ABC- SBC ShoreTel Realm Press Save. Now create a second realm called Carrier (Figure 28) Press Save Figure 28 ABC- SBC Carrier Realm Now we must create a call agent in each realm. We will start with the ShoreTel Realm. In the Realms page on ABC- SBC select call agents for the ShoreTel realm (Figure 29) Figure 29 Call Agents for ShoreTel Realm Select Insert new Call Agent and enter the following parameters:

37 Name Identifiable name, in my example we will name this CA Signaling Interface Select the internal interface we created in Sec. 6.2 Media Interface Select the internal interface we created in Sec. 6.2 Backup call agent Optional, not needed in this example Identified by IP Address IP Address Enter the IP address of the ShoreGear you configured SIP trunks for in Sec. 5.6 Port Enter 5060 Priority Enter 10 Weight Enter 10 All other settings can be left at their default values. See Figure 30 for configuration example Figure 30 ABC- SBC ShoreTel Call Agent Example

38 Once you have entered the correct settings, press Save. Now for the carrier realm. Navigate back to the Realms page and select call agents for the Carrier realm (Fig 31) Select Insert new Call Agent Figure 31 ABC- SBC New Carrier Realm CA NOTE: This is only an example configuration. Please consult your SIP carrier for correct parameters. Enter the following parameters: Name Identifiable name, usually the name of the carrier (we are just going to call them Carrier in this example) Signalling Interface Select the carrier interface we created in Sec. 6.3 Media Interface Select the carrier interface we created in Sec. 6.3 Backup call agent Optional, not needed in this example Identified by IP Address (in this example, you may identify the SIP carrier however you wish, refer to the ABC- SBC handbook for more information) IP Address Enter the IP address your SIP Carrier is using for Signalling. You may add multiple IPs by selecting Add destination (optional) Port Enter the SIP port provided by your SIP carrier (5060 in this example) Priority Enter 10 Weight Enter 10 See Figure 32 for an example carrier call agent.

39 Figure 32 ABC- SBC Carrier Call Agent Once you have confirmed all parameters are correct press Save 6.4 Enabling RTP Anchoring Now we will enable the RTP anchoring feature on both of the call agents we created in Sec The RTP anchoring feature will help with media traversal and will prevent one- way audio issues if your carrier is setup correctly. RTP anchoring may be optional on the carrier side, but is required on the ShoreTel call agent. To enable RTP anchoring Navigate to Realms - > ShoreTel - > Call Agents - > Shoregear CA - > Inbound (A) Rules in the ABC- SBC GUI.

40 Figure 33 Inbound rule for ShoreGear Call Agent Select Insert new Rule, enter the rule as follows (Figure 34) Conditions: Match on: Method Operator: == Value: INVITE Actions Select Enable RTP Anchoring from the drop down and press Add Force symmetric RTP for UAC: Unchecked Enable Intelligent Relay: Unchecked Source- IP Header field: P- ABC- Source- IP (default) Office ICE- lite: Unchecked Offer RTCP Feedback: Unchecked Keepalive: global value Keepalive method: global value Timeout: global value Change SSRC: Unchecked

41 Figure 34- ShoreTel Call Agent Inbound (A) Rule Optional: You can also enable logging on this interface for troubleshooting purposes if needed. To do this simply select Log Received Traffic in the New Action drop- down and hit Add. You can chose between capturing SIP, RTP, or both. Captured events will show up under Monitoring - > Events in the ABC- SBC GUI. Press Save. Go back to Realms - > ShoreTel - > Call Agents - > ShoreGear CA - > Outbound (C) Rules. Select Insert new Rule and configure the outbound rule the exact same way we created the inbound (A) rule (see Figure 35)

42 Figure 35 ShoreTel Call Agent Outbound (C) Rule Optional: You can also enable logging on this interface for troubleshooting purposes if needed. To do this simply select Log Received Traffic in the New Action drop- down and hit Add. You can chose between capturing SIP, RTP, or both. Captured events will show up under Monitoring - > Events in the ABC- SBC GUI. Press Save. Now you must create rules for your carrier call agent as well. Depending on your SIP Carrier, network configuration, and other factors these rules may vary. Although enabling RTP anchoring the same way we did for the ShoreTel call agent above is not a bad idea when first testing a new carrier. For more information please consult your SIP carrier and the ABC- SBC handbook.

43 6.5 ABC- SBC Routing Rules The final step we must take before our SIP trunks are live is to add routing rules so ABC- SBC knows where to route our calls. First we will create a rule for the carrier dialling into ShoreTel (inbound call). Navigate to Routing in the ABC- SBC GUI and select Insert new Rule (Figure 36) Figure 36- New Routing Rule Fill out the rule as follows (Figure 37): Conditions: Match on: Source Call Agent Operator: == Value: Carrier Route To: Route using: Static route Realm: Shoretel Call Agent: ShoreGearCA Routing Method: Set next hop Update R- URI Host: Checked Replace DNS name in R- URI through the resolved IP address: Checked All other settings can be left default.

44 Figure 37 Inbound Route Once you have confirmed all the settings are correct press Save. Now we will create the outbound rule, navigate to Routing in the ABC- SBC GUI and select Insert new Rule (Figure 36). Fill out the rule as follows (Figure 38): Conditions: Match on: Source Call Agent Operator: == Value: ShoreGearCA

45 Route To: Route using: Static route Realm: Carrier Call Agent: Carrier Routing Method: Set next hop NOTE: This setup will work for most carriers, but not all. Consult your SIP carrier to confirm if any additional configuration is needed. Figure 38 SIP Carrier Outbound Rule Press Save once you have confirmed the correct settings have been entered.

46 This is all that is required to start making and taking calls. Press activate in the warning box (Figure 39) to apply changes, and then start making calls! Figure 39 Activate new configuration 6.6 Troubleshooting Before troubleshooting an issue it is highly recommended to enable logging on all call agents involved in the problematic call flow. You can enable SIP and RTP logging via the instructions on page 26. Enable this log on both the inbound and outbound rules for every call agent. The PCAPS generated by this logging service will be very helpful for both you and your carrier. You can view the captured messaged under Monitoring - > Events in the ABC- SBC GUI. An example of a rule that has logging enabled: You may want to consider install Wireshark on a workstation that will be accessing these pcaps, although it is not necessarily required. The ABC- SBC GUI can view SIP flow information right from the browser by selecting Details on an entry (see below):

47 Example of a packet capture viewed in ABC- SBC GUI, this call shows an unsolicited INVITE being rejected by ABC- SBC. Provide these captures to your SIP carrier for troubleshooting outbound or inbound caller issues. The raw PCAP file can also be downloaded from the ABC- SBC GUI by selecting PCAP next to a trouble call in the Monitoring - > Events page.

48 6.7 Non- Default SIP Signalling Interface To use a non- default SIP signalling Interface port, first set the port setting on the ABC- SBC internal signalling interface: In this example we will use port 5070 In ShoreTel Director navigate to Trunks- >SIP Profiles and select Default ITSP, then select Copy to create a new profile, give the new profile an identifiable name, and enter Port=xxxx under Custom Parameters where xxxx is the port number you assigned to your internal signaling interface, then press Save.

49 Use this new SIP profile when setting up the SIP trunks in ShoreTel director to connect to the corresponding interface in ABC- SBC.