The history of humankind is overflowing with truths, that later proved not to be true after all. In hindsight, it is a wonder how people could be so stupid not to see the benefit of a specific technology or application.
In 1895, Lord Kelvin, chairman of the British Academy of Science, declared that flying machines were a technical impossibility, yet years later the Wright brothers were able to build a machine that disproved that claim entirely.
Do SIP devices work? Yes, SIP devices do work and in most cases they work very well. Why then, is it necessary to discuss whether a VOIP specification for regulation of SIP terminals within SA will ever happen? It should, after all, be very easy to compile a specification for regulation ensuring the end-user is provided with equipment that always works and is independent from the SIP application with which it is normally certified.
The reality is that it is very difficult to compile a practical VOIP specification that could be used for regulation of SIP devices. To understand the above statement, one needs to understand the history of the Internet.
History lesson
The world's first packet switching network and the predecessor of the global Internet was created by ARPA of the United States Department of Defence, during the Cold War. Request for comments (RFCs) were invented by Steve Crocker to help provide a record of the Network Working Group's design of the Arpanet. Over time, the work that was done for Arpanet created the basis for the Word Wide Web as it is known today. I don't think the individuals working on Arpanet at the time, in 1969, ever thought their work would become the basis for mainstream telco specifications.
RFCs provide a convenient, useful vehicle for documentation and distribution of the research performed by the developers of the Internet.
Although they remained titled "request for comments", by consensus, they are the Internet documents of record, and often include very detailed technical information.
The problem, however, with RFCs comes with implementation. RFCs are open to interpretation, and therefore it is possible for equipment vendors to only incorporate the basic SIP RFCs, depending on the application.
In addition, various RFCs exist and no minimum requirement is specified for the implementation of the various RFCs that exist per SIP application. The net result is that not all SIP terminals support all possible published SIP RFCs.
Is it SIP?
The other challenge with putting a VOIP specification forward for regulation is provided by the scope of what is deemed a SIP terminal. SIP terminals could consist of desktop telephones, DECT phones, a SIP client on a notebook or a PC desktop or an application on a mobile telephone that is able to connect via broadband, WiFi, DECT etc. A SIP client could be an application that is integrated into various other devices and software applications. The scope of what could be deemed a SIP client is almost limitless.
It is very difficult to compile a practical VOIP specification that could be used for regulation of SIP devices.
Hercules Schoombee is MD of Aastra Telecom SA.
The major difference between a SIP terminal and an analogue terminal is that an analogue terminal is designed to terminate an analogue line with specific characteristics: a SIP client connects to a SIP server via a connection medium, with characteristics that could be unpredictable due to best effort service provided by broadband. It is, therefore, difficult to create a technical specification for a SIP client that is similar to an analogue telephone specification, which consists of acoustic performance parameters, etc. A SIP client could be loaded on a multitude of devices. SIP clients are redefining the rules that have been part of the TDM world.
With an analogue phone, the telco ensures quality of service. The connecting parameters are defined; therefore, a specification could be created since the network parameters to some extent are fixed.
With SIP clients, this is not necessarily the case. Depending on the SIP operator, a broadband service could be used to connect the end-user to the SIP application server using the best effort service of a broadband connection; quality of service is therefore not guaranteed. So, why even try and regulate SIP devices? The networks they connect to could actually be variables in themselves. Because it was done in the past? Because telcos want to protect consumers? Or are companies only going to regulate devices that connect to MPLS networks providing QOS only?
Currently, no clear indications exist in terms of putting a specification forward for SIP terminals, other then ensuring EMC and safety tests are still performed. However, to put a specification together that will ensure interoperability, transmission levels, etc, are adhered to, is presenting a huge challenge and one that is not going to be solved easily.
* Hercules Schoombee is MD of Aastra Telecom SA.
Share