Time to ReThink SIP
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.
Look ma, no ads!
Admit it! You just can’t look away. Yet, there’s so much more.
Become a subscriber to TalkingPointz for access to reports and premium posts.
There are several ways to stay informed:
- Visit this site regularly.
- Receive new posts in your email once a week.
- Become an Insider or All Access Subscriber for alerts and access to uncensored content.
TalkingHeadz Podcast
The TalkingHeadz podcasts are @DaveMichels and @EvanKirstel chatting with interesting guests. These are unsponsored and unscripted for your enjoyment. You can subscribe on most podcast apps including iTunes.
TalkingHeadz with Brad Hintze of Crestron
Multi-camera video is best demonstrated in large conference rooms, and that can be a challenge in an expo hall. Crestron solved it: We’re going to need a bigger booth. I experienced Crestron’s 1 Beyond experience in an expo booth with…
Colin,
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.