SIP Trunking Configuration with

SIP Trunking Configuration with Microsoft Office Communication Server 2007 R2 A Dell Technical White Paper End-to-End Solutions Team Dell Product Group - Enterprise

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND. Dell, the DELL logo, the DELL badge, PowerEdge, PowerVault, and Dell EqualLogic are trademarks of Dell, Inc.; Microsoft is a registered trademark of Microsoft Corporation in the United States and/or other countries. Sipera is a registered trademark of Sipera Systems. Wireshark is a registered trademark of the Wireshark Foundation. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others. 2009 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

CONTENTS INTRODUCTION... 4 SIP TRUNKING REQUIREMENTS... 5 OCS R2 TELEPHONY/VOICE ROUTING INFRASTRUCTURE... 5 SECURITY AND PERIMETER NETWORK COMPONENTS... 5 SIP TRUNK SERVICE PROVIDER... 7 END-TO-END CONSIDERATIONS... 8 SIP TRUNKING CONFIGURATION EXAMPLE WITH OCS 2007 R2... 9 EDGE DEVICE COMMUNICATION... 9 MEDIATION SERVER SETUP... 13 END-TO-END COMMUNICATION... 14 TESTING THE CONFIGURATION... 15 OUTBOUND CALL VERIFICATION... 15 INBOUND CALL VERIFICATION... 16 CONCLUSION... 17

Introduction Microsoft Office Communication Server 2007 Release 2 (OCS R2) introduces many new features and server roles to Unified Communication (UC) enterprise users. One of the new features provides enterprises with direct connectivity to PSTN and Voice-over-IP (VoIP) network without deploying PBX and IP-PSTN gateways in their environments. The connectivity to the PSTN users and external VoIP users is provided by Internet Telephony Service Providers (ITSP) using Session Initiation Protocol (SIP) Trunking technology. This enables internal and external calling to public telephone numbers and reduces the complexity of the end to end deployment. SIP Trunking technology offers a cost-effective means of voice communication by offloading the Time Division Multiplexing (TDM) integration requirements of PSTN to a SIP service provider without a loss of end-user functionality when compared with traditional TDM-based deployment. OCS 2007 R2 is configured with dial plans that achieve the desired level of internal and external routing. It uses a defined set of transport protocols for SIP signaling and media traffic. For such a deployment, the SIP trunk service provider selected should be able to support the same protocols or should have a very minimal number of intermediate components for interoperability requirements. Traffic routing and security, component integration, and consideration of ports between the service provider and the OCS infrastructure play important roles in SIP trunking deployment and successful communication. This white paper defines the SIP trunking deployment and configuration requirements with OCS 2007 R2 infrastructure. It also briefly steps through an example of testing deployment to provide an understanding of the procedures involved in a basic setup. Sip trunk service providers that are certified to operate with OCS R2 are listed here ( http://technet.microsoft.com/en-us/office/bb735838.aspx#trunking).

SIP Trunking Requirements SIP Trunking setup requirements vary depending on the types of protocols involved and the communication methods provisioned by the SIP trunk service provider. Usually, service providers follow a standard format of SIP trunking that is widely accepted in the VoIP and telecom industry. The underlying transport protocols may be different based on their provisioning and deployment methodologies. OCS R2 also uses a defined set of protocols for internal SIP communication. When provisioning a SIP trunking solution for an OCS 2007 R2 environment, you must ensure that the underlying protocols and ports are accepted by both parties and that security mechanisms are in place. The interoperability factors and security concerns between OCS R2 and service provider may lead to additional components in the deployment path. Therefore, the SIP trunking requirements for an OCS R2 deployment can be categorized into three segments: OCS 2007 R2 telephony infrastructure, SIP trunk service provider, and Interface components to provide security and interoperability. OCS R2 telephony/voice Routing Infrastructure In addition to instant messaging, live-meeting, and conferencing components, OCS R2 contains enterprise voicerouting functionality that you can configure to provide connectivity between internal-uc and external-telephony devices. The Front-End Communication Server pool in OCS 2007 R2 takes much of the responsibility for defining and processing inbound and outbound rules, similar to a PBX deployment. The Mediation Server provides gating functionality and isolates the OCS infrastructure within an external telecom environment. It also translates SIP signals and RTP media between the communication server and SIP trunk setup. In SIP trunking topology, when an enterprise voice user initiates a call from an Office Communicator client to an external SIP or PSTN user, the appropriate rules are invoked and phone normalization occurs. The call is then forwarded through the Mediation Server to SIP trunk connectivity for completion. As mentioned earlier, the routing functionality for Enterprise Voice is configured through rules and policies defined in the Global Voice Configuration. These rules are set up with the following administrative parameters: Location Profiles: These profiles specify how OCS 2007 R2 front-end servers route calls that are dialed by the user. They include normalization rules that convert the number dialed in OCS to E.164 format. Policy: A policy specifies the calling privileges that apply to users. Default policy can be setup that enables simultaneous ringing, meaning that incoming calls are simultaneously routed to a user s internal desk phone and Communicator devices. Policies are also used to implement class of service to control what number ranges users are allowed to dial. Routes: A route allows defined location profile users with outside dialing privileges to call external phones and pass through defined mediation servers and an SIP trunk service provider. This configuration allows internal users to call phone numbers outside of the organization. Security and Perimeter Network Components Using the Internet for telephony drives cost savings in terms of both operating and capital expenditures. However, the deployment of SIP trunks means that voice is sent and received over TCP/IP as packets instead of routing through traditional circuit-switched networks. This configuration creates new security concerns, since the

enterprise network is now exposed to VoIP threats from the Internet. VoIP technology is susceptible to viruses, Denial of Service (DoS) attacks, spoofing, eavesdropping, VoIP spam, session hijacking, and many other issues just like any other Internet-packet communication. Traditional firewalls only ensure protection against standard security and Quality of Service (QoS) threats from the Internet. For VoIP-specific threats, SIP-aware security measures are required in the perimeter network joining the Mediation Server to the SIP trunk circuit. If the SIP trunk service provider can provision the same transport protocols used by the Mediation Server and is capable of communicating SIP signals over TLS or TCP and media packets with RTP or SRTP, then a Virtual Private network (VPN) connection between the enterprise edge site and the service provider is sufficient to fulfill security requirements. In such a deployment, the Session Border Controller (SBC) at the service provider and the Mediation server at the enterprise site manage the VoIP sessions, as shown in Figure-1. Figure 1 SIP trunking with OCS 2007 R2 using a VPN connection between routers at both sites If the service provider does not use TLS or TCP transport in other words, UDP is the only option for SIP communication then some additional edge device(s) may be required at the enterprise perimeter site for protocol handling and SBC functions. Most service providers address security requirements for SIP signaling using IPSec (Secure Internet protocol) or secure tunnels. One or more additional edge device(s) may be required at the enterprise site to perform the following functions: Secure link/tunnel termination SBC functions for SIP session management and termination Secure UC access NAT (Network Address Translation) traversal and signal/media encryption (if still required) Transport protocol translation from UDP to TCP or TLS E.164 format conversion applicable if the service provider is using a non-e.164 format; note that Mediation Server in OCS 2007 R2 is also capable of providing the E.164 format conversion

There are devices available from SIP security vendors that provide all of the requirements (listed above) built into one box. These functions must comply with enterprise policies and should be performed efficiently without impairing QoS. Figure-2 shows a SIP trunking implementation that uses an IPSec tunnel for signaling between the ITSP and the UC enterprise. Additional edge devices in the demilitarized zone (DMZ) are required, depending upon the protocols and methods provisioned by the service provider. Figure 2 SIP trunking with OCS 2007 R2 using IPSec tunnel and additional Edge device at Enterprise site In addition to setup, signaling and media ports for listening and transmission are enabled on device interfaces for proper relay of messages. The media ports are usually configured with a large range which allows random allocation of ports for each call thereby adding another level of security for RTP traffic. SIP Trunk Service Provider The SIP trunk service provider consists of a Session Border Controller (SBC), IP-PSTN gateways, and other intermediary components. The SBC provides SIP services across NAT and firewall devices located at the enterprise site. It communicates with the enterprise edge device or Mediation Server to manage all VoIP sessions. The PSTN gateways and switches are responsible for handling calls that are eventually routed to the PSTN network.

The SIP trunk customer supplies the provider with the number of users allowed external phone connectivity in the OCS R2 infrastructure and rerouted through the SIP trunk. The service provider leases the required number of unique Direct Inward Dialing (DID) phone numbers for that OCS setup. Typically the ITSP can provide DID numbers from a number of regions/countries via one SIP Trunk. End-to-End Considerations Important considerations that should be planned for when implementing end-to-end communication of SIP trunking are: 1. The signaling and media ports on the interfaces of sending and receiving devices in the communication path should match or coordinate. Any mismatch or restrictions on receiving ports will block traffic from the sending device. 2. The firewalls on enterprise and service-provider premises should allow only the specific IP addresses, SIP signaling, and media ports of edge devices or routers, as agreed by both parties in the communication. 3. The IP addresses on the external edge of terminal routers should be publicly routable. 4. If the service provider is capable of provisioning TLS protocol in complete end- to-end communication, then the process requires installation of authentication certificates on the devices involved in the setup. Such a scenario may not require deployment of edge security devices on the enterprise side, as shown in Figure-1. 5. If the Service provider is provisioning a secure tunnel like IPSec for SIP signaling then extra security considerations are required for media traffic that is routed outside the IPSec tunnel. One reason a service provider may not use IPSec for RTP traffic is to avoid overloading the channel. In such a scenario, SRTP should be used for media security.

SIP Trunking Configuration Example with OCS 2007 R2 This section briefly provides the configuration steps for an example deployment of SIP trunking with OCS 2007 R2. The setup for this test environment is shown in Figure-3. The SIP service provider in this example provisions SIP over UDP using an IPSec connection that is terminated at the enterprise side on a terminal router. This can be any basic router capable of handling layer-3 services and IPSec termination. An edge device behind the router acts as an SBC, providing NAT traversal, security, and protocol interoperability with OCS 2007 R2 Mediation Server setup. Figure 3 Dell Test environment of SIP trunking with OCS 2007 R2 using IPSec tunnel Edge Device Communication This setup uses a Sipera IPCS 310 as a sample edge device that lies in the DMZ and is configured to receive SIP/RTP traffic from the router and send it to the Mediation Server after processing. Figures 4 through 9 show basic configuration steps for a Sipera device (using its management console). 1. The interfaces of the Sipera device linking the internal side to the Mediation Server and the external side to the trunk service provider are configured with respective domain IP addresses along with the transport protocol and listening ports. In this setup, the SIP signaling from the service provider is received on UDP transport and repackaged on TCP for the Mediation Server side.

Figure 4 Screenshot showing the SIP signaling interfaces and ports of Sipera device 2. The media ports range for RTP traffic are also defined on these interfaces. Figure 5 Screenshot showing the Media interfaces and ports

3. The routing profile is configured for SIP packet routing with next-hop IP location. It basically ensures that the packets originating from the SIP trunk provider will be relayed to the Mediation server and vice versa. Figure 6 Screenshot showing the next-hop routing location and transport 4. Server configuration defines the virtual entities assigned to the internal and external interfaces that are responsible for executing routing profiles. Figure 7 Screenshot showing the Server Configuration entity for Mediation side

Figure 8 Screenshot showing the Server Configuration for Service provider side 5. Some rules can also be applied to server interworking to define the phone number patterns that are allowed to pass. Converting phone numbers into E.164 format also occurs in this step. Figure 9 Screenshot showing the Server interworking and phone pattern policy

Note that the steps defined above are for basic configurations only. For more advanced configurations including security settings refer to the Sipera IPCS deployment guides. Mediation Server Setup The Mediation Server acts as the gateway for the OCS infrastructure. Microsoft highly recommends having two Ethernet interfaces on a Mediation Server for complete network isolation: The external edge interface to communicate with the Sipera device and the internal edge interface to link to OCS internal infrastructure. You can configure the Mediation Server and activate it using the OCS 2007 R2 administration console. 1. The General tab in Mediation Server properties is configured with the internal edge interface IP address and external edge IP address, along with the SIP listening port. The location profile is part of the Enterprise Voice configuration defined in the Global Voice Configuration. For a detailed configuration of location profile and OCS R2 telephony routing, refer to the Microsoft OCS R2 Deployment Guide. The media ports range is defined for RTP/SRTP traffic. Figure 10 Screenshot showing the General setting on Mediation Server properties 2. The Next Hop Connections tab is configured with the OCS R2 Front-End Server/pool address and PSTN gateway address (which is Sipera IPCS in this case), along with the SIP port. The Mediation Server can be configured to use either TLS or TCP transport with Sipera. Usually the connection between SIpera and

Mediation is secure and dedicated, therefore extra security with TLS may not be required. But if TLS option is considered, the security certificates are required on both devices for mutual handshake and authentication process. With TLS based option, the encryption level can also be defined for media packets to use SRTP. Figure 11 Screenshot showing the Next hop Connections setting on Mediation Server properties End-to-End Communication As previously mentioned, OCS R2 Enterprise Voice routing is configured with a location profile and policies that use DID phone numbers assigned by the service provider. Defined outbound routing traffic is sent to the Mediation Server, which communicates with the Sipera edge device in the DMZ. In turn, the edge device communicates with the terminal router, which relays traffic through the external firewall to the service provider. The process happens in reverse for inbound traffic routed from the PSTN user to the enterprise site user. In case of inbound communication failure from the service provider to the enterprise site, you can troubleshoot the problem by first verifying the connection between the firewalls and terminal routers at both ends. If you determine that the IPSec (or VPN) termination points are pinging and required ports are open, then you should analyze the SIP traffic logs on the terminal router, edge device, Mediation server and OCS R2 internal receiving point. If the reports show that SIP signals are successfully received on these devices, then you should analyze media traffic along the same path for errors. Use the same troubleshooting steps in reverse order for outbound calls originating from the OCS R2 enterprise user to the PSTN user.

Testing the Configuration This section discusses two basic testing scenarios for the sample deployment outlined in the previous section. These scenarios verify inbound and outbound call flows as routed through the deployment path. Outbound Call Verification The outbound call test involves initiating a phone or communicator call from the OCS 2007 R2 infrastructure to an external (PSTN) phone number. When the call is initiated from an OCS R2 registered end-point, the call is normalized through the applied location profile and routed to the next-hop (if the user is allowed to use that route) the OCS location profile verifies that it is destined for an outbound route. The SIP signal verifies the path by establishing a session through the Mediation Server to the Sipera device, which performs the transport transformation. The signal is then routed outside of the corporate network through the firewall, and received at the service provider site. The service provider processes the signal and initiates a discovery on the destination to determine whether the signal should be routed through the PSTN gateway or to the Internet for VoIP and SIP users. When the service provider completes the discovery, it sends an acknowledgement signal back to the OCS user and establishes a session. Media traffic then flows, using RTP packets. Figure-12 shows the SIP and RTP trace (captured using the Wireshark network protocol analyzer) between the Sipera edge device and the service provider for an outbound call. The SBC-SIP IP and SBC-RTP IP represents the separate IP addresses for SIP and RTP traffic used by the service provider in this configuration. The SIP listening port is 5103 on the service provider side and 5060 on the Sipera side (as shown in the following figure). Figure 12 Screenshot showing the Outbound Call sequence

Inbound Call Verification The inbound call test involves initiating a phone call from and external (PSTN) phone number to the OCS 2007 R2 user. The service provider routes the SIP signal through its SBC and router to the enterprise site, where the Sipera edge device receives the session after passing though the terminal router. The edge device then routes the SIP signal on TCP or TLS to the Mediation Server and then to the OCS R2 internal infrastructure. The SIP session is established between OCS R2 user and PSTN user after verification and media traffic is allowed to flow. Figure-13 shows SIP and RTP traces (captured using Wireshark) between the Sipera edge device and the service provider for an inbound call. Figure 13 Screenshot showing the Inbound Call sequence

Conclusion SIP trunking deployment provides a cost-effective solution with OCS 2007 R2. The configuration requires careful planning and consideration with the types of transport protocols and communication methods supported by the SIP trunk service provider. You should also take the security factors into account to avoid any VoIP threats from the Internet. In addition to SIP trunking configuration support, the OCS 2007 R2 infrastructure offers a complete set of unified communications with advanced features such as enhanced instant messaging, A/V conferencing, Live Meeting, and much more. PowerEdge servers and Dell PowerVault, Dell EqualLogic, and Dell/EMC storage provide suitable platforms for deploying the OCS 2007 R2 infrastructure. Dell offers Microsoft SQL Server solutions for hosting OCS 2007 R2 back-end databases and also offers complementary Microsoft Exchange Server solutions for hosting e- mail. These solutions provide a comprehensive platform for implementing an OCS 2007 R2 infrastructure with required availability features. Dell Services include assessment, design, and implementation tailored to UC and messaging deployments. More information about Dell Unified Communications is available at www.dell.com/unified.