TheVoIP Peering Puzzle�Part 20: The SIPconnect Interface Specification
This is the 'fine print' that spells out explicit implementation requirements for enterprises and service providers.
Our previous tutorial discussed the SIPconnect architecture, a joint effort between IP PBX vendors and service providers to enable direct peering between a SIP-enabled service provider network and a SIP-enabled enterprise network, allowing calls to be originated and terminated on the Public Switched Telephone Network. We also considered the interoperability challenges that can accompany such an undertaking, especially when there are multiple standards organizations, multiple vendors, and multiple service providers are all adding their own implementation variants to the mix.
But this challenge exemplifies the purpose of the SIP Forum, an industry organization comprising networking equipment manufacturers and service providers that have banded together to support and promote the SIP standard, and work out these types of challenges along the way. A recent draft publication titled IP PBX/Service Provider Interoperability spells out the SIP trunking challenge in very clear language (see www.sipforum.org/component/option,com_docman/task,doc_download/gid,83/Itemid,75/).
Currently published ITU-T Recommendations and IETF RFCs offer a comprehensive set of building blocks that can be used to achieve direct IP peering between SIP-enabled IP PBX systems and a Service Provider's SIP-enabled network. However, due to the sheer number of these standards documents, Service Providers and equipment manufacturers have no clear "master reference" that outlines which standards they must specifically support in order to ensure success. This has led to a number of interoperability problems and has unnecessarily slowed the migration to SIP as replacement for traditional TDM connections.
This document takes direct aim that that problem by defining the protocol support, implementation rules, and features required to make the SIP trunking scenarios successfully interoperable. Let's see what aspects of that IP-PBX/service provider interface need some attention.
First, the implementation specification lists the networking standards, published by the ITU-T and the IETF, which must be supported. These include ITU-T E.164 (the international numbering plan, RFC 2246 (the Transport Layer Security (TLS) protocol, RFC 3261 (the SIP standard); RFC 3264 (an offer/answer model with Session Description Protocol (SDP)); RFC 3275 (third party call control in SIP), and others.
Next, the document enumerates specific requirements 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 will enable the SIP servers to correctly associate 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 E.164 address on the PSTN and SIP 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 RTP voice samples must be marked with a pre-defined 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 capabilities, and 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.
Remember that old analogy with the two tin cans and a string? Well, it looks like the connection that the "string" makes is a little more complicated that we may have originally thought. Fortunately, this SIPconnect interface specification smooths the complexities and removes some of the attendant uncertainties.
Further details on the interface specification are available at www.sipforum.org/sipconnect/. Our next tutorial will look at some of the telecommunications providers that are offering SIP trunking service.
Copyright Acknowledgement: © 2007 DigiNet Corporation ®, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet Corporation®, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.