September 10, 2014 archive

Sep 10

How Do We Define ‘SIP’ For Telecom In 2014?

Sip question"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:

Sip architecture

but rather a much more complex reality:

Sip architecture 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?

SIPconnect sipforumThe 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!)

An audio commentary on this post is also available:

If you found this post interesting or useful, please consider either:

Sep 10

TDYR #174 – How Do We Define ‘SIP’ For Telecom In 2014

How do we define what it is to be "SIP-compliant" in 2014? Can we even do so? How can we make it easier for companies and vendors to make their systems work with SIP?

Sep 10

TDYR #173 – Apple’s iPhone6 and AppleWatch: Some Initial Thoughts

Some initial thoughts on today's Apple event where the iPhone 6 and AppleWatch were announced...

Sep 10

Any Ideas For A Better Color Scheme For Our DNSSEC Deployment Maps?

Do any of you have any suggestions for a better palette of colors for us to use for our DNSSEC deployment maps?  We generate them every Monday morning and send them out to a public mailing list (to which any of you are welcome to subscribe).  Here is a recent global view (click/tap to see larger image):

2014-09-02-2014-09-02

My issue (and maybe this is just me) is that I’m not entirely fond of the colors used in the “early” stages of a TLD’s deployment.  As we note on the deployment maps page, we track a TLD through five stages of DNSSEC deployment:

  • Experimental – Internal experimentation announced or observed
  • Announced – Public commitment to deploy
  • Partial – Zone is signed but not in operation (no DS in root)
  • DS in Root – Zone is signed and its DS has been published
  • Operational – Accepting signed delegations and DS in root

The most important states are the final two when DNSSEC for the TLD is “working”.  I like the existing green colors for those two states, although the “DS in Root” green is perhaps a bit brighter than I would want.  The point is that we want to use green to show the “good” states of DNSSEC deployment – and over time we’d like to see the whole map go to that darker shade of green.

It is the first three states that bother me a bit.  There is a progression between those three states as it often goes like this:

  • Someone from a TLD says at a conference or on a mailing list that they are experimenting with DNSSEC.  We can then flag them as “Experimental”.
  • Perhaps next someone from that TLD issues a formal statement, publishes a blog post or these days sends out a tweet or posts another social media update saying that they are going to deploy DNSSEC.  We can then flag them as “Announced”.
  • Then at some point the TLD’s zone is actually signed with DNSSEC, but the DS key hasn’t been uploaded to the root.  Now we can put them as “Partial” in the database.

In my ideal world I’d have some color progression that shows the movement along this path.  The orange, yellow and blue we currently use don’t really show a progression.   I’ve tried using different shades of yellow or orange but you also want it to be easy to determine what state a given TLD is in – and for that the current set of colors does work.

Anyway… if anyone has ideas I’d be open to hearing them.  The software we’re using can set the colors to be any of the typical hex-encoded colors used in web pages.  It can’t do shading or lines or anything like that, just colors.

Please feel free to leave suggestions here – or contact me directly at york@isoc.org.  Thanks!

P.S. And if you would like to help get more domains signed with DNSSEC, please see our “Start Here” page to find resources targeted at your type of organization!