”What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?”

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don’t know.

It turns out to be a challenging question to answer… and it led me to ask:

• How do we define what “SIP” is for telecommunications in 2014?
• How do we help vendors move their products/services to be based on SIP?
• As we talk about “turning off the PSTN” and “moving all telecom to IP”, how can we make it easier for companies to switch to using SIP?

The reality is that being “SIP-compliant” does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

1. a SIP client, in terms of a “hard” phone, a softphone, or other application that is seeking to connect to a SIP server?
2. a SIP server seeking to connect to a SIP “service provider” to have connectivity out to the PSTN and other SIP networks?
3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be “SIP-compliant” really means you need to figure out what amount of “SIP” you need to implement to play your part in the larger picture. Particularly when the SIP “architecture” we describe isn’t the pretty little picture we use but rather a much more complex reality.

Unfortunately, the “Session Initiation Protocol” (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications… it was “HTTP for voice”... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It’s a remarkable document and set of ideas.

However, there were two factors that started to complicate “SIP”:

• the “Internet” community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and
• the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn’t have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what “SIP” was.

Back around 2008/2009, Jonathan Rosenberg tried with his “Hitchiker’s Guide to SIP” that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced… and this was back in 2009! In the 5 years since, the “Realtime Applications and Infrastructure (RAI)” area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

The good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any “SIPconnect-compliant” IP-PBX or other SIP server can connect to any “SIPconnect-compliant” SIP service provider. It should “just work” with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever… or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be “SIP-compliant”.

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get “SIP” products to work together? What should they specify beyond the vague statement that a product should support “SIP”?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it’s hard to understand what really links back to SIP—and many of the ITU recommendations are only available to members and so you can’t easily view them.

Which brings me back to these questions:

• Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps “profiles” of what would be needed for different roles?
• Is this something the SIP Forum or some other organization should take on?
• Has someone else already created a concise list/document/specification and I just haven’t yet found it?

And perhaps the even larger question:

• Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I’d love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)

Note: This post was originally published on Disruptive Telephony.

* * *

An audio commentary on this post is also available: