Voxbone looks at the work being done to formalize SIP standards
Session initiation protocol, the most popular voice over Internet protocol telephony protocol, saw daylight for the first time in 1999. The new signaling standard defined by the Internet Engineering Task Force was written with a focus on flexibility and extensibility, and it was further extended by 3GPP. Over the years, many SIP extensions have been defined; some of them were developed to add new features on top of basic SIP, e.g. SIP REFER was added to support call transfer, and other extensions like P-headers (used to carry identity information) were created for implementing networks like IP multimedia subsystem.
During the first years of the 21st century, the number of extensions ratified by the IETF was limited. Network equipment vendors and telecom operators regularly met at SIP interoperability events. As a result of these industry standardization efforts, SIP specifications improved and the margin for incorrect interpretation of the standard decreased. In the second half of the first decade, setting up a SIP interconnect was pretty simple.
Now we see the number of extensions has substantially grown, creating multiple ways to optimize the same functions in SIP. Take call forwarding as an example: history-info or diversion are headers that, despite the different name, do the same thing. There are also different headers to present called party ID and those headers are defined in different extensions like from, P-asserted-identity and remote-party-ID. Today, there exist hundreds of SIP specifications defined by IETF and 3GPP, which are subject to interpretation and can often be a source of ambiguity.
The upshot is that every SIP provider has its own flavor of SIP, which means interconnections between different service providers need to be engineered and different configuration profiles need to be defined. This often requires a session border controller to be added at the edge of the network for protocol normalization, resulting in increased cost and complexity of SIP interconnects. Interoperability is one of the major bottlenecks in delivering a range of new IP based services. Over the past few years, industry players have been trying hard to fix the interoperability issues. SIP Forum, an association of IP communication companies, has been hosting the SIPIt SIP interoperability event, which provides the opportunity for various SIP developers to check the interoperability of their implementation.
The good news is that recent events hint industry efforts to solve this problem are finally bearing some fruit. With a sense of joy and optimism, I want to draw your attention to the following developments in the world of SIP interoperability.
The Alliance for Telecommunications Industry Solutions in collaboration with SIP Forum recently published phase one specifications for IP based network-to-network interfaces. It provides guidelines and recommendations for setting up an interconnect between two SIP service providers. With the consensus of North American service providers, this lays the groundwork for the switch to full IP interconnects between service providers. The goal of the specification is to define a common set of implementation rules for SIP service providers willing to interconnect with other service providers. For the moment, the specification limits itself to voice services only, but a standardized interconnect profile opens up the doors for delivering next generation IP-based services such as video. The first phase of specification is laid out in the following documents:
–IP interconnection profile: This specification defines a baseline set of features, which should be common to all IP NNI implementations. It provides recommendations on what the SIP signaling and media should look like on the wire when it flows between two different service providers, with the objective to minimize the risk of interoperability issues when setting up a new IP interconnect. Some of the issues addressed in this specification are typical call scenarios like basic call establishment, call hold, call forwarding, SDP requirements and, on the media level, it defines guidelines for DTMF transmission, codec negotiation, etc.
–IP interconnection routing: This specification explores various options for facilitating the routing of IP traffic across different service providers. It provides the guidelines for identifying an IP service provider for a phone number, and explores various options like NPAC, ENUM registry, etc.
SIP Forum also announced that work on SIPConnect 2.0 has begun. SIP Forum has been actively working on SIPConnect since 2005, and industry leaders like Acme, Avaya, Genband, Dialogic and many others already support SIPConnect. The focus is on standardizing the direct IP peering between SIP-based PBX and VoIP service providers. SIP trunking continues to grow in importance, but as with most other SIP implementations, it also suffers from lack of standardization. SIPConnect defines a minimal set of IETF and ITU-T features which must be supported for setting up SIP trunking. It also provides guidelines and recommendations in areas where standards are subject to interpretation and could cause ambiguity and potentially interoperability issues. It defines a profile of SIP signaling and related media aspects needed for connectivity between SIP service providers and SIP enabled enterprise network, and it has been compiled with a focus on interoperability and quality of service. A clearly defined profile for signaling and media should make it easier for service providers to roll out new features readily and offer its customers a high quality of service.
SIPConnect 1.1 was ratified in 2011, and defines the guidelines for signaling and media for basic VoIP services. The program also recently announced a SIPConnect certification program, which is set to allow companies to test the conformance of their implementation with SIPConnect specification. Hopefully, this certification can evolve as the de-facto certification for SIP trunking services. SIPConnect 2.0 intends to upgrade the standards based on the learnings from 1.1 and define new services. Here are some of the key items being addressed by SIPConnect 2.0 working group:
–IPv4/IPv6 dual stack
–Secure RTP
–Video
–Emergency calling
It is certainly an encouraging sign that the industry is finally establishing these subcategories in response to the increasing number of interoperability issues. For an enterprise looking for SIP trunking services, it would be handy if they could call up any service provider and ask one simple question: “Are you SIPConnect compliant?” If the answer is yes, they can rest assured that there will be little risk of interoperability issues. The same applies to SIP service providers; they can build interconnects supporting new services without having to worry about interoperability issues.
While I am optimistic, we are still far from that point. Standards have no significance if they are not widely adopted by the industry. While traditional telcos and service providers have not had much success beyond voice services, we have companies like Facebook, Skype and WhatsApp offering more varied services over IP. Their success can be partially credited to the fact these services exist in their private ecosystem, where there are no interoperability issues, which leaves room to focus on building new services. To have truly ubiquitous IP communication services that go beyond voice calling in the future, we need these standards and we need industry leaders to adopt them.
Nitesh Bansal has eight years of telecom industry experience and started as a VoIP developer at Voxbone in 2012. He works with the research and development, and product management teams, where his main focus is to drive the new product ideas from a technical standpoint.
Editor’s Note: In an attempt to broaden our interaction with our readers we have created this Reader Forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
