Research, analysis, and thought leadership for enterprise communications.

Time to ReThink SIP

by in Telecom

One true lacking of the SIP design is that it has a rather unfortunate division of labor between the phone and the switch that it is registered to.

As a result, some features are partially implemented in the phone (like Call Forwarding or DND) and other features are implemented wholly within the switch. Some are half implemented on both ends (like DSS buttons that need to understand how to do Directed Call pickup, etc.)

Im a big proponent of clean design and elegance, and this morass that we have now doesn’t cut it. The phone doesn’t really talk to the switch and visa versa. So you can’t have a lot of intelligent features. Take “Visual Voice Mail” for example: You just can’t build it with SIP. (And, we keep talking about unified messaging and still can’t display a list of voice mail messages on the phone LCD display??)

I think the right model is the one that we had 30 years ago where the phones are largely dumb. The PBX defines the features. The hone is more of a terminal than an owner of a call.

So when a user presses a feature button on the phone there should be a code sent (probably via RFC2822) to the PBX that simply represents the key, as in K17 for “Key #17”. The phone doesn’t know what Key 17 is, or what it does. But it dutifully reports its pressing to the PBX, just like a DTMF button.

The PBX, in turn, can send messages to turn indicators on and off for keys. This is very much like sending a ring tone to the phone, I suppose. It could specify a color, cadence, and perhaps text label. The PBX would have to understand enough about a phone to know what its capabilities were, and perhaps there could be a query command after registration that defines the key’s display abilities. (LED, LCD-Text, LCD-Graphics, etc.)

I feel that a lot of functionality that would help users is lost in the current SIP implementation. This is easily fixed.

So, if we wanted to create some entirely new function, such as a “Clock-In” timecard feature it could be crafted. (Just dial your department chargeback code and press “Clock-In” and the light illuminates green. Press the button again and it turns out.) Surely you have wanted a DND button that would actually tell you with a light which mode it is in. Or, how about an LCD menu where you can reject but redirect calls (Voice Mail, Secretary, Special Message.) Or, possibly you would like an LED on your phone that would show whether your company’s stock is up or down. (Green for Up or Red for down, unless you are in China, in which case it is Red for up and Green for Down…seriously.)

The SIP protocol is strangling the telephony industry.

Fix it.


Spread the word:

  • tsahil


    I agree. I think the solution today to some extent is WebRTC – it runs “everything” on the client/browser – but that “everything” piece is something that the server downloaded to the client. So control is central again.

    It has the beauty of not being defined or standardized, so everyone can enrich it where necessary. While it means no interoperability across devices when it comes to signaling, I don’t really see an issue here if products are designed and thought of properly.

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.