Implementation is all in the details, right? We formulate a broad overview of the goals we want to accomplish, and then work out the nitty-gritty to get it implemented. When it comes to signaling protocols for IP-PBXs, what makes vendors standardize, and then "soup-up" the standard protocol suite into something that can support an enterprise feature set?
I think that it's evident that the major vendors (Avaya, Nortel, Cisco, etc.) have been able to deliver ample feature sets when moving their legacy systems to IP, but it concerns me of just HOW they are doing it.
As an example, think of all of the proprietary IP-based signaling protocols are alive today. A few stand out in my mind: SCCP (Cisco), UNISTIM (Nortel), "modified" versions of H.323 and SIP (Avaya), and MiNET (Mitel). I still don't know if I
can find a major vendor, except for open-source solutions like Asterisk, that is completely non-proprietary.
What's my point? Unless we're deploying for major companies that will simply install one vendor across the board, it is very possible that our infrastructures at different geographic locations simply use different vendors for their PBXs - IP or not! This, along with a sometimes significant invested cost in these existing systems, make it hard to integrate and network systems of different vendors together. Simply imagine trying to interconnect voice platforms from Avaya, Cisco, Nortel, and Digium Asterisk, all together. Without a lot of "hacks" on each system, we won't be seeing a seamless dialplan. I just don't believe it will work (well, that is).
The Internet is littered with excerpts of panicked implementers trying to tie together their CallManager in Boston and their Avaya MultiVantage in Seattle using what should be a standards-based trunking protocol, for example. So, can vendors' claims of "standards-based" compliance be trusted?
So, here's my question. Should we as customers be demanding truly interoperable products from our VoIP vendors? As the vendors' feature sets become more complex, and their proprietary protocols are developed further away from standards, should we be alarmed? Frankly, as most VoIP platforms are still quite new, this seems to be the time to encourage standards-based development. Why not resolve the question now, instead of waiting another 10 years?
Secondly, I'll take a devil's advocate position. We NEED modifications to protocols like SIP, because the simply don't deliver the feature set that implementers need, and users demand. For example, shared and bridged line appearances, support for switchboard-type call handling, etc.
What do you think? Functionality or standards and ensured compatibility?
Nickasch has been very involved in IT since he was just 13. His current and previous consulting experience includes systems architecture, virtualization, and converged networks for the financial, education, and healthcare industries. Matthew currently attends the University of Wisconsin-Platteville, where he also works as a network management assistant. While his interests include directory services and routing protocols, Nickasch's focus is on converged networks and voice over IP.
|
|
Baseline Standards
I don't think that we can ever really expect any single standard to fulfill all of the expectations from users for the features that they want. Vendors that want to distinguish themselves from open-source platforms are therefore going to have to step outside the scope of the standards in order to meet their customer's needs. SIP was originally meant to be simple, but is now trailing a long list of RFC's and even more semi-proprietary iterations. Simplicity is getting thrown out the window in favor of demand for features.
The best we can hope for is a reasonable general agreement on baseline standards and just accept that 100% interoperability of extended features probably isn't going to happen. We may be able to SIP trunk multi-vendor systems together but full cross-platform feature functionality is likely to be limited.
Integrated enterpise telephony
As a matter of fact, large enterprises, particularly those in financial services and those running call centers, are already starting to deploy SIP as a way of tying together their disparate PBXs. Not only that, but the major carriers are now starting to roll out SIP trunking services to these very same enterprises.
While there are differences in the dialects of SIP supported between the various brands of PBX, there is generally sufficient commonality for trunk-side interoperability at least. (Line-side features tend to be a different matter, as this is where the vendors add their special sauce.)
Deployment of SIP trunking, both between PBXs and to the service provider, gives rise to two sets of requirements:
1. You need a Session Border Controller to provide border security for VoIP and other real-time traffic (including video and IM), as conventional firewalls can't handle the real-time traffic.
2. You need a SIP Session Manager to do call routing between the various systems, dial-plan management and any necessary protocol fixup that remains. And that's just a start; a good Session Manager can:
(You will not be surprised to learn that Covergence makes a SIP Session Manager that addresses both these sets of requirements.)
The reason enterprises are deploying SIP trunking is that there are huge cost savings to be made by keeping calls off the PSTN, particularly with call centers. In a call center, a call typically hits an IVR and is subsequently transferred to a live agent, who may be located in a different city or even country. The cost of taking back and transferring the call is high -- certainly higher than that of making a regular long distance call. If such transferred calls can be moved off the PSTN to the corporate network, the savings are significant.
However, doing trunk-side integration is just the first stage. What we're seeing corporate voice architects moving towards is in effect adopting an enterprise version of IMS. In this architecture SIP endpoints gain access to the network through a Call Session Control Function (CSCF, aka the SIP Session Manager), which provides security, policy control over access and call routing. In turn the CSCF relies on information provided by corporate directory servers and other systems. PBXs become application servers, running alongside call center software, IVRs, IM & Presence servers and other communications-enabled applications. The glue holding all this together will be a combination of SIP and Web Services (SOAP/XML).
So my answer to you is that in the short term current IP PBXs from different vendors can certainly be integrated, using SIP. Do we need additional SIP-based standards? Well, they come along all the time through the IETF and the 3GPP/3GPP2/TISPAN projects. Some take hold, while others gain little traction in the market. However, a bigger question is how enterprise communications will be architected in future, and how it will mesh with carriers' mobile offerings.
Rob Welbourn
Senior Product Manager
Covergence, Inc.
Maynard, MA