WHITEPAPER
Concepts of SIP Trunking
A series of tutorials on the Session Initiation Protocol
Mark A. Miller, P.E.
President
DigiNet Corporation
®Volume 4, August 2009
Table of Contents
1.
The SIP Trunking Environment
2.
SIPconnect: A Standards-based Implementation
3.
Smoothstone SIP Trunking Case Study
4.
Looking Ahead
Executive Summary
As interest in the Session Initiation Protocol (SIP) has grown, new and innovative applications have been developed. One of these is the SIP trunk, which can be used to connect IP PBX systems with service provider networks, and more effectively replace traditional trunks that are based on Time Division
Multiplexing (TDM) technologies. The SIPconnect Technical Recommendation, developed by an industry organization known as the SIP Forum, provides implementation recommendations for these SIP trunks. A case study, demonstrating the benefits of SIP trunking that have been realized for a Smoothstone customer, will be presented to illustrate these concepts.
1. The SIP 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 1.544 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 SIP 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, IP). As the communications industry has evolved toward converged networks based solely on IP, the architectural model has changed as well. For example, a
customer might replace an older TDM-based PBX with an IP-PBX, thus converging all of the communications within the enterprise into a common platform based on IP. In other words, the existing data traffic would be carried by IP (as it had been for many years), but now the voice traffic would also be transported via IP.
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 IP 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 IP is converted to TDM for WAN transport, and is then converted back to IP at the
destination LAN. Each of these conversions requires signal processing, which introduces undesirable delay and distortion into the end-to-end communications path.
ITSPs: The SIP 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 IP (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 IP and is compatible with SIP call signaling, and you then eliminate the need for all of the protocol conversions between IP and TDM systems. An end-to-end IP 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 SIP 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
SIP-compatible 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 SIP trunk provides both Internet and voice connectivity, further leveraging
economies of scale, since you get two network connections with one service.
SIP Trunking Benefits
In brief, the concept of SIP 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 IP-based (or Internet-IP-based), it also becomes independent of location and
geography, making moves and rearrangements much easier. Gateways between the IP PBX and the WAN are not required, thus reducing installation and
administration time, but also eliminating one more potential point of network failure. The IP 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—IP—rather than trying to meet the needs of a varied class of customers. Plus, the ITSPs position their customers to leverage future IP and SIP enhancements and technologies, and in turn position themselves for a long-term business relationship.
But end-to-end IP infrastructures are not implemented without some serious engineering work, especially given the fact that scores of standards now
document SIP 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. SIPconnect: A Standards-based Implementation
The standard for SIP was developed by the Internet Engineering Task Force (IETF) and published as RFC 3261 (see
ftp://ftp.rfc-editor.org/in-notes/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 SIP Forum, which comprises both equipment vendors and next generation carriers, has risen to that challenge.
The SIP Forum: An Industry Behind SIP
The SIP Forum (see http://sipforum.com/) 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 SIP-related technologies; building awareness regarding the benefits of SIP through educational seminars and events; and acting as a central information
clearinghouse for the SIP-related industry.
However, the SIP Forum is not a standards-setting body—that is the role of the IETF. Think of the SIP Forum as the organization that takes up the baton once the
IETF standard is complete; the SIP 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.
SIPconnect: An Interoperability Framework
One of the most recent technical contributions from the SIP Forum is called SIPconnect, an interface specification to enable connections between SIP-enabled IP PBXs and VoIP service provider networks. The SIPconnect initiative and Technical Recommendation provides a well-defined approach for direct IP 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 SIP trunking. IP 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 IP PBX users’ requirements.
SIPconnect Reference Architecture
SIPconnect, as defined in the SIP Forum’s Technical Recommendation titled IP PBX/Service Provider Interoperability, is based on a reference architecture that encompasses both the service provider and enterprise networks (see Figure 1).
Figure 1. SIPconnect Reference Architecture Source: SIPconnect Technical Recommendation Copyright 2008, SIP Forum, Used with Permission
The functions required for this architecture to operate include SIP servers and gateways to the Public Switched Telephone Network (PSTN) and Signaling System 7 (SS7) networks on the service provider side, and SIP servers, IP PBX, and IP phones on the enterprise side. Four different protocols and systems are involved: SIP; 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.
SIPconnect Interface Specification
The SIPconnect recommendation describes an interface specification that includes the protocol support, implementation rules, and features required to make the SIP 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
http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.164-200502-I!!PDF-E&type=items ); RFC 2246 (the Transport Layer Security (TLS) protocol, see
http://www.rfc-editor.org/rfc/rfc2246.txt ); RFC 3261 (the SIP standard, see
http://www.rfc-editor.org/rfc/rfc3261.txt ); RFC 3264 (an Offer/Answer model
with Session Description Protocol (SDP), see http://www.rfc
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 SIP 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: SIP Proxy Servers must support TLS, and all SIP
signaling exchanged between the service provider and the enterprise SIP Proxy Servers must be secured using TLS.
Firewall and NAT Transversal: All IP addresses contained within the
headers and message bodies of the SIP messages that are exchanged between the service provider and the enterprise networks must be publicly routable addresses.
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 SIP Universal Resource Identifiers (URIs) on the enterprise.
URI Formatting and Addressing Rules: Specifies how the addressing
fields within the SIP message are formatted for transmission between the IP PBX and the service provider’s SIP Application Server.
Quality of Service: IP packets containing SIP 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 SIP response codes, such as Ringing, Busy, and so on. While this section has only provided a brief summary of the SIPconnect
Technical Recommendation, it should be clear that this document provides a comprehensive roadmap for SIP trunking implementations—at both sides of the interface, the IP PBX and the service provider. Readers wanting to dig deeper into this important topic are encouraged to study the entire document from the SIP Forum’s technical documentation repository at
http://www.sipforum.org/component/option,com_docman/Itemid,164/.
3. Smoothstone SIP 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 (http://www.masergy.com), 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.
LD PSTNLocal 2801 Router PRIs PRIs Masergy MPLS Network Local PSTN Cisco Unified Communications Manager Primary Location Remote Locations Cisco 2801 Router Cisco LAN Switches IP IP Cusco Router w/ UCM Express Cisco LAN Switches IP IP Cisco Unity Voice Mail Server PRI
Figure 2. SIP 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 SIP 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 IP 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.
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 SIP 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. Local PSTN Cisco Unified Communications Manager Masergy MPLS Network Primary Location Remote Locations Cisco 2801 Router Cisco LAN Switches IP IP Cusco Router w/ UCM Express Cisco LAN Switches IP IP Cisco Unity Voice Mail Server Smoothstone MPLS Network IP Gateway (Dial Peer) PSTN LD Network NNI NNI POTS
Figure 3. SIP Trunking case study example, with Smoothstone
By using Smoothstone for SIP 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
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 SIP trunking solutions, visit
http://smoothstone.com/voice/ip_trunking.php.
4. Looking Ahead
This is the fourth in a series of tutorials produced by DigiNet Corporation and Smoothstone IP Communications. Titles of other tutorials include:
SIP 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 SIP: Explores the key concepts and components of the
SIP protocol, such as user agents, clients, servers, etc., and also looks at some of the industry initiatives, such as the SIP Forum and SIP Connect, that are furthering this technology.
Components of a SIP-based Architecture: Considers the migration that
has occurred in the last few years from the TDM world to IP, and the operation of the various devices that comprise a SIP-based network, including IP-PBXs, softswitches, and session border controllers.
Managing the SIP Network: Discusses the deployment, configuration,
implementation and longer-term issues surrounding a next-generation telephony system, including the importance of built-in network
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 IP 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 SIP 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 VoIP Voice over Internet Protocol WAN Wide Area Network
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 www.diginet.com or call 303.682.5244.
Smoothstone IP Communications is a nationwide provider of unified IP communications services to mid-sized enterprises. Smoothstone delivers Voice over Internet Protocol (VoIP), IP 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 IP communications as their business requirements dictate. For more information, visit www.smoothstone.com or call 800.773.3037.
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 IP Communications Corporation from sources believed to be reliable. However, neither the author, nor DigiNet Corporation, nor Smoothstone IP Communications Corporation guarantee the accuracy or completeness published herein, and neither the author, nor DigiNet Corporation, nor Smoothstone IP 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 IP 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 IP 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 IP 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 IP Communications Corporation or its subsidiaries. All other registered and
