Since breaking the dominance of the Cisco 7960 about 20 years ago, Polycom has been a leader for open-SIP-standards SIP phones. Now named Poly, they have newer CCX phones are now available supporting standard SIP to provide compatibility with SIP-standard providers like RingCentral and Zoom phone, as well as Cisco BroadWorks, Microsoft-Metaswitch, and others operated by large enterprise and Service Providers. I've been watching the CCX line for a while, as ECG's practice includes innovating Voice Service Providers running standard SIP platforms. CCX was first announced as available outside the Microsoft Teams ecosystem.
Poly's approach with the CCX is savvy and intelligent...
The CCX phones are Android-based touch screen phones. Typically, when a proven vendor -- even Poly -- releases a new model, we're interested to see the new offering on the market. But often the work of maturing the SIP software can take some time when a vendor starts from scratch. And until the software is matured, service providers and major enterprises will be reluctant to incorporate it into their product lineup. Therefore, the engineering strategy used to deploy successful software for a new physical product can make a huge impact on the sales and usability of the product.
Poly's approach with the CCX is savvy and intelligent because it runs the Poly UC software that Polycom/Poly service providers have been relying on for years. This is a great design to maximize the reuse of a mature system rather than to start all over again.
According to released licensing information, the Polycom/Poly VVX phones ran some form of Linux under the hood, and the new CCX is based on Android, and Android is based on Linux. So it makes a lot of sense that Poly engineers would be able to maximize reuse.
Poly's open SIP phones are embedded in enterprises, healthcare, government, and are supported by Service Providers around the world, so when they roll out a new model, industries have every reason to expect it's been well thought-out.
You might wonder: beyond basic SIP, what is it that needs to be tested and proven with BroadWorks, Metaswitch, and others? Here are some if the items a SIP phone needs to prove out to be a Service-Provider grade device:
- Remote Management. Updating configurations, collecting statistics, distributing software updates, TLS Client Authentication, RTCP-XR
- Busy Lamp Field / Line State Monitoring including INVITE with Replaces to support the attendant-monitoring case of answering someone else's call.
- NAT Traversal Compatibility. Service Providers use Session Border Controllers (like the Oracle Communications SBC, Sansay, and Metaswitch Perimeta) and SIP phones have to behave in particular ways to make compatibility with them easy.
- Add-On Conferencing Support. Adding someone else on to a conference call should make it easy to join a group of people together, and the SIP signaling to do so needs to be customized to the environment.
Beyond these, developers are looking at the next generation of VoIP networking, including support for ICE, STUN, and native IPv6. ICE is widely supported on Microsoft Teams compatible phones.
--
CCX Phone Photo: Josh Blalock