Home / Blogs

How Do We Define 'SIP' for Telecom In 2014?

Dan York

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

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.

Related topics: Networks, Telecom, VoIP

 
   

Don't miss a thing – get the Weekly Wrap delivered to your inbox.

Comments

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper

Cybersecurity

Sponsored by Verisign

IP Addressing

Sponsored by Avenue4 LLC

Mobile Internet

Sponsored by Afilias Mobile & Web Services

DNS Security

Sponsored by Afilias

Promoted Posts

Buying or Selling IPv4 Addresses?

Watch this video to discover how ACCELR/8, a transformative trading platform developed by industry veterans Marc Lindsey and Janine Goodman, enables organizations to buy or sell IPv4 blocks as small as /20s. more»

Industry Updates – Sponsored Posts

Attacks Decrease by 23 Precent in 1st Quarter While Peak Attack Sizes Increase: DDoS Trends Report

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year

Mobile Web Intelligence Report: Bots and Crawlers May Represent up to 50% of Web Traffic

Data Volumes and Network Stress to Be Top IoT Concerns

Verisign Mitigates More Attack Activity in Q3 2015 Than Any Other Quarter During Last Two Years

Dyn Evolves Internet Performance Space with Launch of Internet Intelligence

Verisign's Q2'15 DDoS Trends: DDoS for Bitcoin Increasingly Targets Financial Industry

Protect Your Network From BYOD Malware Threats With The Verisign DNS Firewall

Influential Law Firms Have Become Early Adopters of '.law' TLD

Verisign iDefense 2015 Cyber-Threats and Trends

3 Questions to Ask Your DNS Host About DDoS

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Neustar to Build Multiple Tbps DDoS Mitigation Platform

Nominum Announces Future Ready DNS

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Tips to Address New FFIEC DDoS Requirements

Is Your Organization Prepared for a Cyberattack?

24 Million Home Routers Expose ISPs to Massive DNS-Based DDoS Attacks

Why Managed DNS Means Secure DNS