Concepts of SIP Trunking A series of tutorials on the Session Initiation Protocol

Transcription

1 WHITEPAPER Concepts of S Trunking A series of tutorials on the Session Initiation Protocol Mark A. Miller, P.E. President DigiNet Corporation Volume 4, August

2 Table of Contents 1. The S Trunking Environment 2. Sconnect: A Standards-based Implementation 3. Smoothstone S Trunking Case Study 4. Looking Ahead 5. Acronyms and Abbreviations 1

3 Executive Summary As interest in the Session Initiation Protocol (S) has grown, new and innovative applications have been developed. One of these is the S trunk, which can be used to connect PBX systems with service provider networks, and more effectively replace traditional trunks that are based on Time Division Multiplexing (TDM) technologies. The Sconnect Technical Recommendation, developed by an industry organization known as the S Forum, provides implementation recommendations for these S trunks. A case study, demonstrating the benefits of S trunking that have been realized for a Smoothstone customer, will be presented to illustrate these concepts. 2

4 1. The S Trunking Environment Unless your enterprise network is completely wireless, you need some type of hardwired connection into the Public Switched Telephone Network (PSTN) to provide connectivity between the various locations. With traditional Time Division Multiplexing (TDM)-based architectures, high speed circuits such as T-1 circuits or ISDN Primary Rate Interface (PRI) circuits (both operating at Mbps) are typically used to connect the switching systems, such as PBXs, to the service provider. Those circuits are called trunks, as they provide a direct pipe from the enterprise to the outside world. The technical characteristics of the trunks, such as their speed and channel capacity, are determined based on call statistics, such as the number of end user stations (or lines) to be served, the typical call duration (holding times), calling patterns (such as seasonal variations), and so on. The S trunk provides these connectivity functions, but does it much more effectively. Let s dig into this interesting technology and examine its benefits. Legacy Network Architectures With legacy architectures, the entire system was based on TDM technology from the originating system (e.g. a PBX in New York) through the carrier circuits (e.g. AT&T, Verizon, Sprint, etc.) to the terminating system (e.g. a PBX in Los Angeles). In addition, this created the requirement for two distinct networks: one for voice (based on TDM) and one for data (based on the Internet Protocol, ). As the communications industry has evolved toward converged networks based solely on, the architectural model has changed as well. For example, a customer might replace an older TDM-based PBX with an -PBX, thus converging all of the communications within the enterprise into a common platform based on. In other words, the existing data traffic would be carried by (as it had been for many years), but now the voice traffic would also be transported via. That architecture works fine when all your communication is within your premises, but if you want to communicate with the outside world, trunks from a service provider are still required. If those trunks are based on TDM (such as a T- 1 or ISDN line), you must install some type of gateway between your PBX and the carrier circuit that provides functions such as data protocol and transmission rate conversions. The result is an end-to-end system that includes multiple protocols and conversions: a signal on the LAN that originates with is converted to TDM for WAN transport, and is then converted back to at the 3

5 destination LAN. Each of these conversions requires signal processing, which introduces undesirable delay and distortion into the end-to-end communications path. ITSPs: The S Trunking Providers These signal distortions that ensue from the multiple protocol conversions prove to be particularly challenging for real-time communication such as voice and video, which are especially sensitive to delay. This problem is addressed by the new breed of carrier, the Internet Telephony Service Provider, or ITSP, that has also embraced (instead of legacy TDM) as the backbone architecture of their network. The ITSPs present a clear value proposition: provide the customer with a trunk that is based on and is compatible with S call signaling, and you then eliminate the need for all of the protocol conversions between and TDM systems. An end-to-end infrastructure is then possible, solving multiple problems all at once. Capabilities for Growth Each of the traditional T-1 or ISDN PRI trunks provides 24 channels, one for signaling and 23 for end user voice or data traffic. This brings up one of the biggest challenges to network growth. When you use all of the capacity of one T-1 or ISDN PRI, you have to order up another one even if you only need one more channel. This means that you may end up paying for more network bandwidth than you actually need. But S trunks are provisioned separately, so that if you need five channels you end up paying for only five trunks and not the extra 18 that you would have if you had to order another T-1 or ISDN PRI circuit. However if no gateway is required because the ITSP hands you a Scompatible trunk, and takes care of any required PSTN connections on their end of the network then you save the cost of the gateway hardware. Plus, that S trunk provides both Internet and voice connectivity, further leveraging economies of scale, since you get two network connections with one service. S Trunking Benefits In brief, the concept of S trunking provides a number of benefits to the enterprise. Separate voice and data networks, with the associated circuits and systems, converge into a single system, yielding economies of scale and improved Quality of Service management. Since this architecture is now based (or Internet-based), it also becomes independent of location and geography, making moves and rearrangements much easier. Gateways between the PBX and the WAN are not required, thus reducing installation and 4

6 administration time, but also eliminating one more potential point of network failure. The PBX, which is predominantly software-based, is no longer constrained by the processing overhead of protocol conversions, or the expense of a hardware interface supporting a T-1 or ISDN interface. These resources can then be re-allocated for other bandwidth- and processing-intensive functions such as video conferencing. The carriers realize benefits as well, as they can concentrate their business and expertise on one technology rather than trying to meet the needs of a varied class of customers. Plus, the ITSPs position their customers to leverage future and S enhancements and technologies, and in turn position themselves for a long-term business relationship. But end-to-end infrastructures are not implemented without some serious engineering work, especially given the fact that scores of standards now document S practices and procedures. In the next section we will examine the implementation side of this equation, looking at an industry initiative designed to reduce interoperability challenges. 2. Sconnect: A Standards-based Implementation The standard for S was developed by the Internet Engineering Task Force (IETF) and published as RFC 3261 (see ftp://ftp.rfc-editor.org/innotes/rfc3261.txt). But just publishing a standard does not iron out all of the fine details that are required for successful implementations. Fortunately, an industry group known as the S Forum, which comprises both equipment vendors and next generation carriers, has risen to that challenge. The S Forum: An Industry Behind S The S Forum (see has a very straightforward mission advancing the adoption of products and services that are based on the Session Initiation Protocol. The organization goes about this in five ways: organizing interoperability and testing events; developing industry-wide best-practices implementation guides that address issues that fall outside of the published IETF specifications; creating documentation that supports the deployment of Srelated technologies; building awareness regarding the benefits of S through educational seminars and events; and acting as a central information clearinghouse for the S-related industry. However, the S Forum is not a standards-setting body that is the role of the IETF. Think of the S Forum as the organization that takes up the baton once the 5

7 IETF standard is complete; the S Forum clarifies and works towards a resolution of any technical issues that the standard may have left open for vendor interpretation, thus improving the likelihood that products from multiple, independent vendors can interoperate. Sconnect: An Interoperability Framework One of the most recent technical contributions from the S Forum is called Sconnect, an interface specification to enable connections between S-enabled PBXs and Vo service provider networks. The Sconnect initiative and Technical Recommendation provides a well-defined approach for direct peering, with some clear guidelines to the PBX vendors and service providers regarding how these peering relationships should be implemented. Such a consensus approach should minimize the interoperability challenges that frequently accompany new technologies such as S trunking. PBX vendors gain a standard interface that addresses quality of service and network security concerns, while the service provider community can develop specific services that are tailored to the PBX users requirements. Sconnect Reference Architecture Sconnect, as defined in the S Forum s Technical Recommendation titled PBX/Service Provider Interoperability, is based on a reference architecture that encompasses both the service provider and enterprise networks (see Figure 1). Figure 1. Sconnect Reference Architecture Source: Sconnect Technical Recommendation Copyright 2008, S Forum, Used with Permission 6

8 The functions required for this architecture to operate include S servers and gateways to the Public Switched Telephone Network (PSTN) and Signaling System 7 (SS7) networks on the service provider side, and S servers, PBX, and phones on the enterprise side. Four different protocols and systems are involved: S; the Real Time Protocol (RTP), which carries the voice samples; TDM, which provides the framing format required by the PSTN; and SS7, which enables call setup on the PSTN network. Sconnect Interface Specification The Sconnect recommendation describes an interface specification that includes the protocol support, implementation rules, and features required to make the S trunking scenarios successfully interoperable. First, the implementation document lists the networking standards, published by the International Telecommunications Union Telecommunications Standard Sector (ITU-T) and the Internet Engineering Task Force (IETF), which must be supported. These include ITU-T E.164 (the international numbering plan, see E&type=items ); RFC 2246 (the Transport Layer Security (TLS) protocol, see ); RFC 3261 (the S standard, see ); RFC 3264 (an Offer/Answer model with Session Description Protocol (SDP), see editor.org/rfc/rfc3264.txt ); and others. Next, specific requirements are noted that apply to the enterprise, the service provider, or both. These include: Locating S Servers: The enterprise must ensure the existence of a publicly accessible DNS server that is authoritative for its domain, and the service provider must operate a DNS server that is authoritative for its domain. This enables the servers to be correctly associated with the service provider s and enterprise s respective domain names. Signaling Security: S Proxy Servers must support TLS, and all S signaling exchanged between the service provider and the enterprise S Proxy Servers must be secured using TLS. Firewall and NAT Transversal: All addresses contained within the headers and message bodies of the S messages that are exchanged between the service provider and the enterprise networks must be publicly routable addresses. 7

9 Authentication and Accounting: Authentication of the enterprise by the service provider must be implemented, and authentication of the service provider by the enterprise is recommended. Enterprise PSTN Identities: Defines how the PBX will identify each call and translate the E.164 address on the PSTN and S Universal Resource Identifiers (URIs) on the enterprise. URI Formatting and Addressing Rules: Specifies how the addressing fields within the S message are formatted for transmission between the PBX and the service provider s S Application Server. Quality of Service: packets containing S signaling or Real Time Protocol (RTP) voice samples must be marked with a predefined value in their packet header before being sent to their peer network, thus assuring a standard mechanism for identifying and prioritizing voice-related packets. Media Attributes: Defines the requirements for media capability negotiation, codec support, media transport, echo cancellation, plus support for fax and modem calls. PSTN Interactions: Defines how the call progress tones from the PBX map into specific S response codes, such as Ringing, Busy, and so on. While this section has only provided a brief summary of the Sconnect Technical Recommendation, it should be clear that this document provides a comprehensive roadmap for S trunking implementations at both sides of the interface, the PBX and the service provider. Readers wanting to dig deeper into this important topic are encouraged to study the entire document from the S Forum s technical documentation repository at 3. Smoothstone S Trunking Case Study A large financial institution with multiple branches across the country had purchased and installed a Cisco Unified Communications Manager platform at all locations prior to working with Smoothstone. They had a solid MPLS WAN in place through Masergy ( but needed to rethink how voice services were handled (see Figure 2). However, they were utilizing PRI circuits at each of the branch locations for local inbound and outbound call traffic, which were proving to be quite costly. They were also routing long distance traffic through the headquarters location, where they had several PRIs to their long distance carrier. 8

10 Primary Location Cisco Unity Voice Mail Server Cisco 2801 Router Cisco LAN Switches Cisco Unified Communications Manager 2801 Router PRIs PRIs LD Local PSTN Masergy MPLS Network Cisco LAN Switches PRI Local PSTN Cusco Router w/ UCM Express Remote Locations Figure 2. S Trunking case study example, prior to Smoothstone While the phone system itself functioned to their liking, the customer recognized that there were network efficiencies and cost savings that could be gained by streamlining their telecommunications services. As they investigated S trunking, they consulted with Masergy, who introduced Smoothstone as their trusted business partner to deliver voice services over the existing Masergy MPLS network. Smoothstone already had multiple redundant Network-to- Network Interface (NNI) connections in place with Masergy, providing the customer access to Smoothstone s full suite of Communications solutions. Through the sales and implementation process, Smoothstone engineers completed a thorough assessment of the customer s voice trunk needs and designed a solution that called for the removal of the branch-level PRI circuits and the long distance PRIs at the headquarters (see Figure 3). They maintained a small number of individual local lines at each branch for Survivable Remote Site Telephony (SRST), Cisco s mechanism for fail-over, to allow for calling should the master system be unavailable. 9

11 Smoothstone ported all of the customer s DID and toll-free numbers to their network and configured the primary dial peer so that all inbound and outbound calls, both local and long distance, would now be delivered over S trunks, centrally terminated on Smoothstone s backbone. Smoothstone also configured a secondary dial peer that allows for inbound calls to be rerouted through the PSTN to the SRST lines at the branches, as a fail-over should the primary route become unavailable. Primary Location Cisco Unity Voice Mail Server Cisco 2801 Router Cisco LAN Switches Cisco Unified Communications Manager Smoothstone MPLS Network NNI NNI Masergy MPLS Network PSTN Gateway (Dial Peer) LD Network Cisco LAN Switches Cusco Router w/ UCM Express POTS Local PSTN Remote Locations Figure 3. S Trunking case study example, with Smoothstone By using Smoothstone for S Trunking, the customer was able to realize the following benefits compared to their previous solution: Shared, centralized trunk resources, which provide greater availability and a more streamlined overall design A voice network that scales quickly and dynamically to meet their growth and expansion needs Disaster recovery and business continuity in times of emergency, through the use of SRST and the backup dial peer options Overall cost savings of nearly 40% of their monthly bill 10

12 Numerous telecom carriers were reduced to a single service provider for all of their voice needs Real-time call reporting from Smoothstone s centralized, web-based interface Access to Smoothstone s 24x7 Network Operation Center For further details on the Smoothstone S trunking solutions, visit 4. Looking Ahead This is the fourth in a series of tutorials produced by DigiNet Corporation and Smoothstone Communications. Titles of other tutorials include: S in the Larger Context of the Internet Protocol Suite: Explores the development history of the Internet protocols, shows why these protocols by themselves are not adequate to support real-time applications, such as voice and video, and then describes the additional protocols that have been devised to address these challenges. Understanding S: Explores the key concepts and components of the S protocol, such as user agents, clients, servers, etc., and also looks at some of the industry initiatives, such as the S Forum and S Connect, that are furthering this technology. Components of a S-based Architecture: Considers the migration that has occurred in the last few years from the TDM world to, and the operation of the various devices that comprise a S-based network, including -PBXs, softswitches, and session border controllers. Managing the S Network: Discusses the deployment, configuration, implementation and longer-term issues surrounding a next-generation telephony system, including the importance of built-in network management tools. 11

13 5. Acronyms and Abbreviations ATM Asynchronous Transfer Mode C.O. Central Office FT1 Fractional T-1 HTTP Hypertext Transport Protocol IETF Internet Engineering Task Force Internet Protocol ISDN Integrated Services Digital Network ITU-T International Telecommunications Union Telecommunications Standards Sector KTS Key Telephone System LAN Local Area Network MGCP Media Gateway Control Protocol NAT Network Address Translation PBX Private Branch Exchange PRI Primary Rate Interface PSTN Public Switched Telephone Network QoS Quality of Service RFC Request for Comments RSVP Resource Reservation Protocol RTP Real-time Transport Protocol SAP Session Announcement Protocol SBC Session Border Controller SDP Session Description Protocol S Session Initiation Protocol SLA Service Level Agreement SS7 Signaling System Number 7 TCP Transmission Control Protocol TDM Time Division Multiplexing TLS Transport Layer Security UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol URI Uniform Resource Identifier Vo Voice over Internet Protocol WAN Wide Area Network 12

14 About the Author and Sponsor Mark A. Miller, P.E., is President of DigiNet Corporation, a Denver-based consulting engineering firm providing services in internetwork design, strategic planning, network management and new product development. Mr. Miller is the author of twenty books on network analysis, design, and management, and is a frequent presenter at industry events. He holds B.S. and M.S. degrees in electrical engineering, and is a registered professional engineer in four states. For more information, visit or call Smoothstone Communications is a nationwide provider of unified communications services to mid-sized enterprises. Smoothstone delivers Voice over Internet Protocol (Vo), trunking, unified threat management, MPLS networking, contact center solutions, messaging and advanced collaboration tools as a unified suite of managed services and cloud based applications. Smoothstone s scalable, on-demand applications and services can be integrated with a customer s existing network and telecommunications infrastructure, operational processes and employee activities, enabling a customer to migrate to unified communications as their business requirements dictate. For more information, visit or call Copyright This paper is copyright 2009 DigiNet Corporation. All rights reserved. Limit of Liability/Disclaimer of Warranty Information contained in this work has been obtained by the author, DigiNet Corporation and Smoothstone Communications Corporation from sources believed to be reliable. However, neither the author, nor DigiNet Corporation, nor Smoothstone Communications Corporation guarantee the accuracy or completeness published herein, and neither the author, nor DigiNet Corporation, nor Smoothstone Communications Corporation shall be responsible for any errors, omissions, or damages arising out of the use of this information. The author, DigiNet Corporation and Smoothstone Communications Corporation specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. Neither the author, nor DigiNet Corporation, nor Smoothstone Communications Corporation shall be liable for any loss of profits or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. This work is published with the understanding that the author, DigiNet Corporation and Smoothstone Communications Corporation are supplying information but are not attempting to render engineering or other professional services, advice or strategies. If such services are required, the assistance of an appropriate professional should be sought. Trademarks DigiNet is a registered trademark of Digital Network Corporation. The names, logos, and taglines identifying Smoothstone or Smoothstone's products and services are proprietary marks of Smoothstone Communications Corporation or its subsidiaries. All other registered and unregistered trademarks in this document are the sole property of their respective owners. 13