ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

Business Telephony - IP Centrex Up In The Clouds

Updated on January 10, 2020
wizwizo profile image

Alan Spencer is a telecommunications consultant with over 40 year’s experience. For the past 23 years, he has been an independent consultant

Cloud Telephony is a rehash of old ideas

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 and Cloud Telephony

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 Centrex

So What is Cloud Telephony

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

IP 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

“What has been is what will be, and what has been done is what will be done; there is nothing new under the sun.”

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.

Here We Go Around The Mulberry Bush

It all started...

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

Telephony Technology Roadmap

1993 onwards

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!

Switching From Switching to Switching...

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, SIP and H.323

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.

UDP IP Stack

Diagram Description

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.

Codecs (Coders-Decoders)

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.

Mean Opinion Score

Best Quality Voice

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.

G.729

Codec Choice

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:

Codec Table

MOS Values

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.

Scenarios

ETSI

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).

Quality of Service

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.

Service Classes

Conclusion

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.

This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.

© 2020 wizwizo

Comments

    0 of 8192 characters used
    Post Comment

    No comments yet.

    working

    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://corp.maven.io/privacy-policy

    Show Details
    Necessary
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
    Features
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Marketing
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Statistics
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)
    ClickscoThis is a data management platform studying reader behavior (Privacy Policy)