Research, analysis, and thought leadership for enterprise communications.

Die SIP Die

by in Telecom
If you have installed VOIP systems you know that the bane of their existence is the miserable SIP protocol.
One-way connections are almost the norm. Zero-way connections abound. And, it takes either a genius or a magician to make SIP work in complex networks with VPN.
There are two big problems with SIP:
  1. It has too many useless options and settings.
  2. Media uses RTP and there is no reliable way of ensuring that RTP is working.
It is often pointed out that SIP is simply a protocol for setting up calls, not for transporting them. This explanation always comes up when we’re having one-way audio problems. When I hear this I just glare at the person and say: “And, why is that a good thing when it causes so many problems?”
Take DTMF signaling. Do you want it in-band or out-of-band using RFC2822, or perhaps as SIP info, or perhaps a combination of these that might cause doubled up digits?
How can something as simple and as basic as transmitting digits have so much unnecessary complexity? Never mind that in-band DTMF tones over many codecs like G729 doesn’t even work.
When you call a number do you want the near end or the far end to provide ringback?
But the greatest problem of all are those one-way audio connections. They happen because the SIP protocol has no way of knowing if the audio is being delivered, and the clients have no way to communicate with the SIP controller that audio is getting through.
Now, try to get VOIP working through a VPN and you can spend endless time fiddling settings without success.
SIP has become an implementation disaster.
SIP could be cleaned up with better negotiation. Clients could be asked if they can generate ring-back tones locally. An inquiry could be made of whether media is being delivered. It would be possible to create a new well-thought-through version of SIP where things are tightly nailed down. But I am not seeing anybody step up to the plate to doing that.
Connecting a SIP phone to a PBX or VOIP service should be as simple as pressing a configure button and then keying in the IP address of the server, plus maybe a provisioning ID number. Everything else should be negotiated. And, connections should be verified by the clients and be confirmed back to the SIP server.
When a call is set up, the media path should be part of the negotiation process. The clients should pass peer-to-peer messages with each other and see if they can directly communicate. If they can, that is best because a SIP extension in Tokyo can then just send audio to a SIP client in Tokyo without having to be back-hauled twice to the PBX in the US.
Why is this a problem in the year 2015? Am I the only one out there that just hates all of the SIP settings and complexity and “personality” of getting things to work?
The first version of a SIP-like protocol that I am aware of was running on a switch in Bell Laboratories in the late 1970s. That was 35 years ago. In 35 years we should have been able to figure this out.


Spread the word:

  • Chris Vitek


    In order to overcome the limitations of analog and some digital communication there was a push in the early 90s to separate signaling from transport. Sip was originally designed as a true P2P solution; however, the telcos would not buy it because it cut them out of the loop. So, the only way that the telcos would buy it was to force a proxy architecture that is today euphemistically called a “SIP switch.” The guys that invented SIP had to eat so they had to create these wacky proxies that invoke all sorts of policy oriented requirements that manifest themselves as configuration parameters. There is hope with WebRTC. We will see in the next year or two. Hang in there.


  • adevx5

    Amen to that! What a disaster it is. But are there any alternatives ? IAX2 doesn’t seem to get of the ground either. I’m afraid we will have to stick with it and hope ipv6 will do away with NAT. Even thought NAT will probably linger around as a security feature.

Telecom in Your Inbox

About this Post


Colin Berkshire is a highly technical HR executive in the Pulp and Paper Industry. Colin has an engineering and voice background, and is currently on assignment in Asia. NOTE: Colin does not respond to comments, and does not Tweet.