So we have discussed the use of a single transport mechanism for all forms of communications and how that, in of itself, has advantages and disadvantages. I have also stated that Convergence is about a lot more than just VoIP, so where else can we converge above with cable and with LAN/WAN?

 

Call Control in a traditional PBX was hidden deep within the giant cabinets on processors running embedded code programs. The operating system for these processors are typically stripped down UNIX derivatives such as WindRiver's VXWorks. The beauty of these operating systems is that they do so little; they do not need to support a large array of applications as you would typically expect to see for a commercial server or workstation OS such as Windows, Linux or Mac OS X. This lack of flexibility allows the number of states and state changes that the application can incur to be finite and can be very precisely tested; this gives rise to highly reliable operation. Embedded code operating systems also tend to be hardware specific and so embedded code processors do not experience the continuous performance increases that you would typically experience in a sever or workstation; embedded code processors tend to stay stable for years and even decades. When processors can no longer be manufactured, the cost to the embedded product developer can be huge and product stability can be affected. The result of this is that the product developers have to be very efficient in the use of these resources and very precise in the impact of new code on resource utilisation. Some of the quirks of the function of devices such as the commercial PBX extension are derived from the need for engineering efficiency. 

 

The emergence of server based call controllers, most notably Cisco's Call Manager, changed the philosophy of how communications systems could be designed. Rather than limiting the functionality to suit the static nature of the hardware, servers enable far greater extensibility of functions and can use the inherent ability of servers to recover from failures through methods such as clustering. When Cisco first launched Call Manager the philosophy was that a server would be much cheaper than the large cabinets full of proprietary hardware and so they would be able to produce a cheaper, more functional phone system. A recurring theme in the Convergence debate is the trade off between increased functionality and reduced reliability. In the early releases of Call Manager, extensibility - the ability to extend functionality - did not equate to a better user experience. Where Cisco miss-estimated the value of the product is in the many years of development that had gone into the development of the PBX user interface; they simply got some basic features of the phone wrong. Whilst the user interface of the phone is far from perfect, it is something that people have grown used to over many years and so can now use intuitively. Given that VoIP was a relatively emerging technology at the time, Call Manager suffered user dissatisfaction as well as reliability problems. Call Manager did succeed where engineers appreciated the potential of the product and it's ability to deploy in a converged environment.

 

The reaction by the incumbent PBX providers to the emergence of server based products was to develop hybrid and dual technology (both TDM and VoIP) solutions. In the same way that Cisco marketed heavily to IP technologists in the elegence of their solution and denigrated the differences is user interface, the traditional PBX vendors used these hybrid solutions to show that they were capable of producing IP, server based solutions. In reality, the majority of the early hybrid solutions were 'marchitecture'; design for brochures and not for deployment. They were technically inelegant, ineffective and unreliable. The mistakes that Cisco made with the user interface and these hybrid solutions gave the PBX vendors enough of an opportunity to reconsider their product development strategies. With Cisco clearly improving the quality of their products, the PBX vendors could not afford to develop software that must run and be reliable on two hardware platforms and so they rapidly stopped software development for the embedded code switches and, soon after, began to end-of-life (EOL) the embedded code processors. This competitive process rather than any genuine user value proposition is what has driven the development of converged communication solutions to it's present position.