Business Telephony - IP Centrex Up In The Clouds

Telephony for businesses and enterprises is changing again from IP Telephony and IP Centrex to something that sounds very different – Cloud Telephony. Cloud Telephony might sound new, but just like Cloud Computing, Cloud Telephony is a rehash of old ideas – again – and yet again!

Cloud Computing is running applications in the Cloud. The Cloud is generally a site on the Internet or Intranet where the applications are run. This makes a lot of sense as the modern PC is being slowed down by lots of internal application software and a continual amount of updates and new releases – but Cloud Computing is not new. Way back in the beginning, Big Blue introduced the same thing – except the PC was called a terminal and the applications ran on a central (and often remote) mainframe.

So, what is Cloud Telephony? It is a new name for old-fashioned Centrex services, IP Centrex and Virtual/Hosted PBX Telephony. For the original Centrex service, the operators generally used their own carrier-grade switches or special Centrex switches to provide the features and service, whereas for all the later IP-based Centrex services, a hosted PBX or a Call Server system (with Media Gateways) has been used.

For all the Centrex services, the fancy features and external telephony network connections are in the Cloud (or service provider’s network) with the telephones (could be fixed-line type or mobiles) being connected by a TDM or IP connection. This is the same whether it is for IP Centrex, Virtual/Hosted IP Telephony or just plain Centrex.

IP Centrex is now very common in today’s portfolio of services with many service providers offering such services at the basic level or with bells and whistles.

Cloud Telephony is a renaming of IP Centrex to take advantage of the new Cloud Computing buzzword. The famous old quote from the Book of Ecclesiastes: “What has been is what will be, and what has been done is what will be done; there is nothing new under the sun.” seems to say it all. What we have is the ever turning circle of new old ideas.

It all started with the invention of telephony way back in the 19^th Century. In 1960, Centrex was introduced in New York so that businesses did not need to invest in their own PBX switch equipment.

With the introduction of the Commercial Internet and IP Technology in 1993, the IP companies started pushing for an IP version of telephony and this came about with the introduction of IP Centrex and Virtual/Hosted Telephony in 1995. Now, in 2006 Cloud Computing raised its head (thanks to Amazon) and so the new big idea of Cloud Telephony popped up in 2009 as an add-on to Cloud Computing so that everything can be in the Cloud. It can be assumed that some new technology will be introduced in the next six or seven years and Cloud Telephony will be renamed something else!

In 1987, Gandalf Technologies (now integrated into Mitel) introduced a data switch called Starmaster. This switch allowed the first PCs and Macs, together with dumb terminals, to be connected to a mainframe computer and other shared resources using circuit switched technology (based on statistical multiplexing) or using X.25 packet protocol. This concept was virtually identical to today’s Ethernet switches where PCs and printers share server or Internet resources. Starmaster ended up being withdrawn as it was being over-shadowed by Ethernet (10Base2 and 10Base5 technology) which was the new kid on the block in the 1980s. So the industry switched from switching to the shared medium of Ethernet LANs.

Just as in the case of Cloud Telephony, this is another example of regurgitation as today’s Ethernet switches are in-effect statistical multiplexers based on very similar principles to that of Gandalf’s Stamaster. Ethernet switches were first launched just three years after Starmaster’s introduction. So we switched from switching to shared media Ethernet LANs and then back to switching.

The original idea of Local Area Network (LAN) convergence was to run voice and data over the same Ethernet or IP infrastructure and to use addressing and Quality of Service (QoS) markings to distinguish voice from data. With the introduction of Ethernet switches the concept of convergence became more viable and as such reasonable quality voice could be achieved over such networks. Where voice quality is of prime importance, companies are having separate Ethernet switches installed for data and for voice, although when Wide Area Network (WAN) connections are used the separation of voice and data is not always possible, although in some networks MPLS paths can be reserved or set up especially for voice.

IP Telephony and IP Centrex have their places in today’s communication networks but only when they are correctly designed and the resulting quality of the voice is somewhere near that of traditional fixed-line telephony.

IP Telephony networks tend to be designed based on two different standards (although in reality neither are actual standards). These two standards are as follows:

• H.323: This is an ITU-T Recommendation for audio-visual communication over an IP networks. H.323 is an umbrella recommendation that defines the protocols to provide audio-visual communication sessions. Most often H.323 is used in the design of Hybrid and IP PBXs.

• SIP: This is a collection of IETF RFCs (Request For Comments) and some Internet Standards. The Session Initiation Protocol is a signalling protocol used for establishing sessions in an IP network. A session could be a simple two-way telephone call or it could be a collaborative multimedia conference session.

For both of these standards, the IP Datagram and UDP segment that carries the voice is the same, although IP is a very inefficient mechanism for carrying voice as it was originally designed for data only. For the 64 bytes shown in the diagram below, only 20 bytes represents the voice (payload) – this is approximately 31% overall for the whole packet. The old, but now fading method of carrying voice was approximately 94% efficient, but in these days of supposed unlimited bandwidth this factor is not considered to be of relevance.

In the above diagram, the Real-time Transport Protocol (RTP) defines a standardised packet format for delivering audio and video over an IP network. RTP is used extensively in communication systems that involve streaming media, such as telephony, video teleconference applications and web-based push-to-talk features. For these it carries media streams controlled by H.323, MGCP, MEGACO, SCCP or SIP signalling protocols. RTP is usually used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g. audio and video) or out-of-band signalling (DTMF), RTCP is used to monitor transmission statistics and QoS information.

There is now a proliferation of voice codecs (COders and DECoderS). There are the original PCM waveform codecs (such as G.711 and G.726) plus newer voice coding codecs (such as G.729) and these latter types are also being used as the basis for mobile air interface codecs (such as GSM-EFR which is a second-generation digital GSM cellular system utilising ACELP coding at a net bit rate of 12.2 kbit/s plus 10.6 kbit/s forward error correction).

When our networks were based solely on TDM techniques, such things as delay, jitter (meaning delay variation) and packet loss were extremely insignificant or did not occur at all. With voice being transported over IP and Ethernet networks, these factors have become extremely important as unacceptable voice quality can be the result.

The measure of voice quality is called Mean Opinion Score (MOS) and perfect voice is 5.0 on the MOS scale. The MOS reflects the quality of the voice as perceived by a number of human beings all marking the voice quality on a scale from zero to five with the MOS value being the average (or mean) of all the scores. MOS values are more scientific today, as test instruments are able to give values without having to herd together many people to listed to the voice.

The other factor that comes into play with modern codec standards is that the cleverer the encoding method, the more digital signal processing is required and hence more delay is introduced.

It can also be seen from the following table that the required bit rate (in kbit/s) is lower for some of the codec types. The codec G.729, which is very common for IP voice services, runs at 8 kbit/s compared to 64 kbit/s for current PSTN quality voice (i.e. G.711). However, G.729 introduces an extra 10ms delay when ever coding or decoding takes place.

The best quality voice is G.722 64 kbit/s which encodes voice in the range 50 Hz to 7 kHz. This is increasingly being used by finance industry companies and is supported by such suppliers as Avaya. Standard voice is G.711 (as used in the PSTN) and is of acceptable quality for most people. G.729 (full complexity version) is widely used in IP networks as it uses low bandwidth and has a high MOS value. The low complexity version (G.729a) is widely used in Internet telephony but has a lower MOS value but is cheaper to implement in telephone equipment due to the lower complexity required in digital signal processing as compared to the full G.729 version. Both versions of G.729 add delay to the conversation which is not normally noticeable, although when additional delay, jitter and packet loss occurs, the MOS value (and the quality of the voice) will plummet.

There are other considerations when choosing a codec for internal use and use over a WAN. The main area of concern is normally when a speech path is subjected to more than one change of codec. As an example, the following table shows how G.729 suffers in MOS value when codec changes take place along a route.

To keep the voice quality at an acceptable level for the user, only one section of G.729 (or G.729a) should be included in a call path.

When considering codec choice, important factors on the bandwidth requirements, packet size and packets per second need to be considered. These are shown in the following table:

It can be seen that G.711 requires almost three times the IP bandwidth as G.729 which in itself does not represent a problem on the LAN but would be very costly to implement over a WAN connection.

The following table shows the MOS values for normal everyday calls (with the possible exception of the VoIP connection). It can be seen that with just a 2% packet loss, the MOS score of G.729 can deteriorate from 3.7 to 2.7.

The European Telecommunications Standards Institute (ETSI) has issued guidelines on the use of codecs in a call. These are adhered to by the public operators (such as BT and C&W) but tend to get overlooked by enterprises although they are easy to implement. In effect, keep delay, jitter and packet loss to a minimum and keep codec changes to a minimum (as well as not having more than one section of G.729/G.729a in a call).

The quality of the voice and MOS is adversely affected when the voice packets suffer delay, jitter or packet loss. It is the marking and treatment of the voice packets that is important so that they have priority over other data packets. Voice packets should be allocated the highest Class of Service (CoS) in order to achieve the best Quality of Service (QoS).

To ensure that all traffic gets its appropriate CoS, the packets are marked using Differentiated Services Code Point (DSCP) values or IP Precedence values. Differentiated Services (DiffServ) provides a framework for delivering QoS by packet classification (and marking the packets) and per-hop behaviour (PHB). The markings partition network traffic into multiple priority levels, or classes of service, so that each service belonging to a particular service class and receives the same per-hop behaviour forwarding treatment.

The following table provides the mapping of services with packet classification (DSCP) and forwarding treatment (PHB). Services here are listed in descending order from highest priority, or most critical (e.g. VoIP), to lowest priority, or least critical (e.g. DNS). Though the values listed below are recommended QoS queues, multiple types of traffic are often assigned a specific PHB. This scheme (or a similar scheme) should be implemented in all IP networks to ensure best voice quality for internal users and external users/customers alike.

IP telephony in the form of IP Centrex is here to stay. Whether it is called Cloud Telephony or any other name, if the system is not designed correctly, the resulting effects could be comparable to speaking over a bad Skype® connection. This White Paper has outlined some of the factors that should be considered when planning to implement such a system.