RFC 3261, The Session Initiation Protocol, was published in 2002, six years after the initial work on SIP. Wikipedia writes

“SIP was originally designed by Henning Schulzrinne and Mark Handley in 1996. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in cellular systems. The latest version of the specification is RFC 3261 from the IETF Network Working Group published in June 2002.

The SIP 2012 Realtime Communication Framework - a specification that we need!The problem here is that SIP 2.0 has changed a lot. It’s been formally updated by  a number of RFCs: 3265, 3853, 4320, 4916, 5393, 56215626, 5630, 5922, 5954, 6026, 6141 (according to tools.ietf.org). And that’s the updates that changes the core protocol. In addition, there is a lot of extensions and additions to what now could be called The SIP 2012 Realtime Communication Framework. The core protocol is now just one piece of the puzzle.

Customers need to change requirements

I’ve seen too many public tenders and requirements that refer to “SIP according to RFC 3261″. This is like buying a PC referring to Windows 95 as the base requirement for compatibility. So what should be referred to? Here’s the core of the problem. There’s no simple document or reference profile to refer to. And there is a huge gap between the IETF and the current implementations, something that we see every year at SIPit events. Only customer requirements can push vendors to move forward.

An example: The SipConnect specification from the SIP forum

The SIP Forum SIP Connect 1,1 specification is a good example of a reference profile that customers can use. It focuses on the SIP trunk – the connection between a PSTN gateway provider (ITSP) and an enterprise PBX. SIP connect makes it possible for customers not to refer to RFC 3261, but a more complete specification that builds a framework on top of the specifications. During the work with SIP connect, it was revealed that many PBXs used SIP in a way that was actually not supported by the current set of RFCs. The SIP forum took this issue back to the IETF and the result is GIN – a way to register for many E.164 phone numbers (RFC 6140). Building a reference framework with customer focus actually added to the standard framework, based on the use in the current implementations.

There are more frameworks built on SIP – IP Multimedia System (IMS) from 3gPP is another example, but not for business users or vendors selling SIP solutions to consumers. The 3gpp is active in the IETF, trying to make sure that changes and additions are documented in RFCs and made compatible with the rest of the SIP framework.

Wanted: A reference profile for SIP phones and servers

If you look at the original set of SIP RFCs, there was a lack of solutions for NAT handling. In the current SIP framework the IETF have added new standards like ICE/TURN/STUN and SIP outbound. There are also standard frameworks for configuration update notifications, registration management and TLS certificate management – something that most vendors implement in a proprietary way. We see more implementations of these additions at every SIPit test event, but most phones on the market (and most servers) are still not supporting these new standards. We need a reference profile (maybe from the SIP Forum?) that customers can refer to in order to put pressure on vendors to update their implementations.  SIP implementations that is based on more current work will lead to better products, more NAT and IPv6 friendly solutions and improved security. Standardization in configuration and security management will lead to lower costs and less vendor lock-ins.

The question is who starts the work specifying the new reference profile?