"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:
and even more unfortunately:
I don't know.
It turns out to be a challenging question to answer… and it led me to ask:
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:
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":
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:
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:
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:
And perhaps the even larger question:
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.
* * *
By Dan York, Author and Speaker on Internet technologies - and on staff of Internet Society. Dan is employed as a Senior Content Strategist with the Internet Society but opinions posted on CircleID are entirely his own. Visit the blog maintained by Dan York here.
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»
Afilias - Mobile & Web Services