Current SIP Phones Limit Asterisk
There are multiple kinds of PBX buyers, but primarily two. Enterprise buyers are mostly interested in application breadth, support, manageability, and interoperability. SMB buyers tend to be less technical and seek simplicity, features but to a lesser level than the enterprise, and low initial and ongoing costs. That was pretty much the way the telecom world worked until Asterisk upset things.
Asterisk created a new category; the geek buyer. The Asterisk solution, coupled with low cost hardware and SIP phones created a very strong value proposition – low cost and robust features. The Enterprise largely resists the temptation due to support and manageability concerns. But Asterisk evolves; Switchvox in particular eliminates concerns of supportability with their locked down configuration files while simultaneously addressing manageability with an intuitive user interface.
But even after Asterisk’s recent 9th birthday, it struggles to free itself from its nerdy heritage. The reason is the SIP phones. In a traditional PBX, the phones are managed and controlled from the PBX. The administrator can set specific features such as speed dials, call forward buttons, 2nd box vmail indicators, intercom, BLF, even the time – easily and remotely. Proprietary phones offer headset jacks that don’t require handset lifters, and LCD displays that can provide context sensitive soft keys, and an organizational directory.
In Asterisk environments, the phones tend to be fairly simple, and the advanced features are accessed from a desktop computer. And while various hacks exist to create things like BLF on a SIP phone, they can’t be programmed from the PBX itself. SIP phones are typically programmed in esoteric configuration files and downloaded to each phone. To update the phone, simply edit the files and reboot the phone. Polycom even offers advanced software options to enable features such as LDAP integration, but they still bypass the PBX.
The Asterisk community is not about to embrace proprietary phone control, but how the PBX interacts with the phones desperately needs an overhaul with a solution that puts the control back at the PBX. I believe this to be the primary barrier to greater adoption of SIP based PBX solutions. Although, this could be done with smoke and mirrors with the current SIP phones, a totally new phone architecture is due; and I think Digium could drive it.
Whether Digium manufacturers the phones or licenses software to phone manufacturers is irrelevant. My research (read guessing) indicates the vast majority of SIP phones (deployed in SIP modes) are in Asterisk environments. Digium controls Asterisk and could offer a far more robust solution to the handset than the current offerings. I think it would be even better if the phone OS itself was open source and the user community could drive new innovative applications. I am not proposing an end to SIP, as a communications protocol it does fine, but a stronger management/control solution is needed to enhance it.
Switcvhox made an attempt to clear this problem with their aptly named “phone tokens”. This solution allowed the PBX to set up the phone without a separate server. It is reasonable for really simple phones, but really locks the door on more advanced options. Ironically, this is one of their only “features” they charge separately for. I want more than a “token” solution though. This will likely require modifications to the phone’s firmware, which is what I am suggesting.
Apple with their Iphone and Google with Android have clearly demonstrated that a powerful OS on a phone leads to powerful applications. Digium did the same 9 years ago with a powerful phone system. But the industry is stuck in 3rd gear. The desktop VoIP phones – even the proprietary ones – don’t do anything of real interest that they didn’t do years ago. An always on IP device with keyboard and a display should be so much more a critical component in our technology infrastructure.
The current SIP phones are holding back Asterisk, who is going to fix it?
Leave a Comment