Enterprise Communications

SIP 2.0 (AKA SIPconnect 1.1)

by Dave Michels

With surprisingly little fanfare, the SIPForum ratified SIPconnect 1.1. This is one giant leap forward for the SIPForum, and potentially a giant leap forward for SIP trunking.


SIP has been, in my opinion, a catastrophe. That may be a bit harsh, after all SIP is a highly successful standard enabling VoIP communications. But it’s been a disaster in terms of interoperability. The IETF created this vague notion of a SIP standard. So vague, that perfectly compliant implementations are completely incompatible. As an industry consortium, the SIPForum set out to create a best practice recommendation, dubbed SIPconnect 1.0.


The SIP Forum’s mission is to advance the adoption of products and services based on the Session Initiation Protocol. It is not a standards organization, but as compliance is so loose, the forum spearheaded interoperability by holding live interoperability test events. This approach does not scale. If SIP wasn’t so technically and financially compelling, it would be long dead and abandoned.


Carriers and equipment tend to enforce supported pairings. Most equipment has a handful of supported SIP providers. This is a far cry from the T1 or PRI standards where compatibility is never questioned.


SIPconnect 1.0 was ratified in January 2008. It was intended to reduce the variation in SIP trunk implementations. While it did improve the situation, variation continued curtailing SIP’s adoption. SIP 1.1 is the continuation of this effort. There is a good summary written by Russell Bennett on NoJitter (Finally, A SIP Trunking Standard that Makes Sense)


Note: SIPconnect 1.1 has no impact to endpoints, its focus is trunking. Also, SIPconnect 1.1 is not a standard, it is a “technical recommendation” that provides a improved set of guidelines for “seamless”, end-to-end interoperability between SIP-enabled IP-PBXs and service provider networks. It is a voluntary recommendation that equipment makers and service providers are encouraged (expected) to adopt.


The SIPconnect 1.1 technical recommendation features an array of enhancements from Version 1.0, such as more comprehensive guidelines about security and SIP end-point and media endpoint functionality. Highlights include: 

  • Standards-based support for both Static (DNS-based) and Registration (SIP REGISTER-based) modes of operation incorporating the newly approved RFC 6140 
  • Description of SIP endpoint functionality required for interworking, with detailed discussion of various error conditions and appropriate responses to those errors 
  • Description of media endpoint functionality required for interworking 
  • Focus on Phone number (i.e., E-164) based SIP Address of Record 
  • Additional voice services using SIP techniques 
  • A detailed description of transaction layer security (TLS) usage 
  • A roadmap on what implementers can expect in subsequent SIPconnect revisions (IPv6, emergency services, etc.) 
A few thoughts. 
  • As Russell pointed out, very few “traditional” service providers participated in creating SIPConnect 1.1. Is SIP the disruption that will change the carrier establishment? The contributing companies included Acme Packet, AT&T;, Avaya, Bandwidth.com, Boeing, Broadsoft, CableLabs, Cablevision, Cbeyond, Cisco, Columbia University, Comcast Cable, Cox Communications, Digium, Encore Software, GENBAND, Global Crossing, Huawei, Ingate Systems, MetaSwitch, Microsoft, NeuStar, Nokia, Nortel, PAETEC, Panasonic, Pbxnsip, Polycom, Radvision, Samsung, Siemens Enterprise Communications, Sonus Networks, Tekelec, Tele2 Nederland, Voxeo, and XO Communications.
  • The progress in 1.1 gets us to where we should have been years ago. Unfortunately, it did not address more recent issues around video calling or wideband audio which are difficult to interoperate over carrier trunks. The absence of wideband audio is particularly disappointing since the equipment required is so prevalent at each end. Effectively, dialing 9 activates a time machine and we go back to narrowband communications. Video calls suffer as well from SIP interoperability. What we have here is a failure to richly communicate (externally).
  • One big change in 1.1. is standardization on TCP over UDP, a slightly more complex solution, but the benefits outweigh the costs… I for one am happy to know that my voice will get better than best effort treatment.
  • As critical as I may appear, I applaud the SIPForum’s effort to make lemonade out of yellow snow.