IP Telephony Deployment Considerations

Two factors make telephony successful: high speech quality and high service availability. Take away the speech quality and make the service unpredictable, and telephony falls apart as an effective business communications tool. Speech quality tends to be subjective, whereas service availability is more readily subject to measurement. International standards in the form of ITU-T recommendations define methods to quantify the voice quality of a telephone call because service availability without speech quality is not enough for any telephony solution to be successful.

ITU-T recommendations P.800 (Methods for subjective determination of transmission quality) and P.800.1 (Mean Opinion Score [MOS] terminology) include a definition of the concept of toll quality speech, which is represented numerically via an MOS value of 4 or higher on the scale from 1 to 5. Given the almost built-in expectation on the part of most telephony users for immediate (effectively, on-demand) availability of toll quality phone service in business environments, addressing the issues of high voice quality and service availability is of paramount importance when designing IP Telephony solutions for SMBs.

Choice of coders-decoders (codecs) and a judicious deployment of quality of service (QoS) techniques can assist you in creating a toll quality telephony solution over an IP network. Note, however, that delivering voice quality is more likely to be an issue in the long-distance (carrier/ISP) deployments than in the LAN-based SMB and enterprise branch deployments.

With bandwidth at a premium on a WAN, codecs that facilitate greater compression (G.723r53 or G.723ar53) might be required. Higher compression codecs usually require additional digital signal processing (DSP) resources, the lack of which can lead to voice quality degradation and longer delays associated with a complete call. In the LAN-based SMB networks, bandwidth is not an issue (at least, it should not be!), and voice can be transmitted without compression using G.711 codec.

To ensure the desired level of phone service availability on a packet-switched network, you have to consider all of the tools associated with building robust networks, including the following:

• Power protection for critical system components

• Use of redundant systems

• Level of hardware and software reliability

• Reliability of any links within the system provided by third parties and outside of an SMB's direct control

• Operational procedures related to system use and system failures

If the issues of voice quality and network availability can be addressed effectively through design, procedures, and user training, there are plenty of sound operational reasons (which translate into economic reasons) for IP Telephony deployments to proceed.

Consider the following when designing any kind of an IP Telephony solution:

• QoS factors

• Use of a single communications infrastructure for voice and data

• Open standards protocols

• Common operating system (OS) hardware platforms

QoS Factors

The concept of a high QoS invites almost an intuitive understanding on the part of telephony users and designers alike. A service that is readily available and that allows users to hear the other person without delay, echo, or jitter is generally expected and taken for granted in business telephone communications.

Many technologies and techniques are deployed within Public Switched Telephone Networks (PSTNs) and the traditional circuit-switched SMBs and enterprises to accommodate these seemingly simple requirements because when these requirements are not met, telephony users can react negatively. The challenge for you as an IP Telephony solutions designer is to match the circuit-switched toll quality and system availability to an equal or better quality and availability, but on a packet-switched IP network. Doing so is getting easier by the day!

Traditional circuit-switched telephony relies on the establishment of a dedicated circuit between the communicating parties. Voice traffic flows over the established path until the circuit is torn down through a normal termination (hanging up) or an abnormal condition (equipment failure or a cut wire). With a dedicated circuit between the communicating endpoints, there is no overhead associated with the addressing of those points during the data (voice) transmission phase. A dedicated circuit also implies a predictable level of performance and delay.

In IP Telephony, the voice traffic is encapsulated into IP packets, each carrying a data payload (elements of your conversation) and a header with the IP source/destination addressing and additional parameters. As a protocol, IP is considered “unreliable” in the sense that it is connectionless and does not offer guaranteed delivery. It sounds like a communications nightmare when you consider the potential problems: voice carrying packets arriving out of order (words transposed!), some packets never arriving (words missing!), experiencing unpredictable transmission delays (waiting, waiting, waiting for that sentence to finish!), or being subjected to variable packet delays that result in hearing the other party in slow motion or on fast forward. In fact, with all of their theoretical potential for being a nightmarish platform for voice, IP networks are currently the platform of choice for telephony solutions. What is it that in practice makes IP networks so reliable and desirable for telephony?

The ever-increasing robustness of IP networks to support telephony solutions is derived from multiple sources:

• The availability of dedicated high bandwidth (as opposed to shared), which is now the norm in LANs thanks to the ongoing work of the 802 IEEE committees and industry forums, coupled with product implementations by networking companies.

  - A primary example of high-capacity bandwidth capability in LANs is the deployment of 10 Gbps Ethernet products.

  - 10 Gbps Ethernet is also extending its reach into metropolitan-area networks (MANs) and WANs.

  - A single IP phone is not likely to require a dedicated 10 Gbps or even 1 Gbps connection, but a 10/1 Gbps capacity might be required for an uplink between IP Telephony LAN switches or to connect a hardware platform with a call processing agent to a LAN switch.

• The improving reliability of the transmission media (fiber, Cat 5e, Cat 6, Cat 7) and lower equipment failure rates, which have steadily increased the overall network availability

• The availability of high-performance multiservice routers, voice gateways, gatekeepers, and dedicated communication platforms for LAN-based SMB and enterprise telephony solutions

Combine these factors with the proper design, especially in the areas of redundancy and QoS, and any theoretical shortcomings of the “unreliable” IP networks vanish.

In IP networks, QoS is used as a generic expression that maps to specific mechanisms that facilitate different streams of traffic to be conditioned according to their needs. Elements of QoS include queuing techniques and link efficiency management, such as link fragmentation and interleaving (LFI). Note that QoS is most useful when transient congestion occurs. No QoS is required in an overprovisioned network. If the design allows for greater bandwidth capacity than any anticipated maximum call volume, QoS becomes a moot point. On the other hand, in a mixed traffic environment, where it is statistically possible to maximize bandwidth usage, QoS deployment is a must for voice traffic.

With the introduction of AutoQoS for VoIP, Cisco gives you the option of deploying QoS with minimal configuration requirements. Simply put, this is a sound policy for IP Telephony installations.

Overcoming Unacceptable Round-Trip Delay

Voice is a real-time application that demands a consistent and low transmission delay between communicating endpoints. If, on the way to their final destination, e-mail packets are delayed from their normal transit time by 2 seconds, those engaging in that e-mail exchange would probably not notice any difference from the norm. On the other hand, a delay of 2 seconds along the transmission path of voice traffic (not a pause by one of the speakers) would probably lead to a quick conclusion of the conversation by one or both of the participants hanging up (preceding that act, perhaps, with some frustrated mutterings).

Opinions on the subject vary, but a round-trip delay of 250 milliseconds (ms) in a telephone conversation begins to make itself noticeable to human hearing. Longer delays might still be (and often must be) acceptable, as long as the communicating parties receive training on how to carry on a conversation with those kinds of delays. However, with round-trip delays of 600 ms or more, the average call length is likely to be extremely short because the communicating parties will perceive the quality of the call as unacceptable. In other words, one or both parties will hang up quickly.

Maintaining a consistent and low level of delay for voice traffic is critical for IP Telephony deployments. Multiple factors contribute to the composite end-to-end delay. They begin with codec processing, which can introduce delays from less than 1 ms to 10 ms or more. Lower bit-rate codecs introduce longer delays. Next comes the formation of packets that must be sent out of a gateway interface into the IP cloud. It's best if there is no congestion and the packet does not have to wait in a queue to be serialized for transmission over the physical media.

In congested environments, traffic prioritization implemented through QoS configuration can help. After a packet enters the IP WAN, each router (hop) that a packet (now carrying voice) must go through introduces queuing and serialization delays. The packet must then exit the WAN and be decoded for the communicating party to hear its contents.

You can perform a detailed analysis of the anticipated path that voice traffic will take and add up the individual delays to see if the sum is within the acceptable range. If it's not, there's not one silver bullet to fix the problem. To minimize delay, try the following where possible and appropriate:

• Reduce the number of hops that voice traffic must go through on the IP WAN.

• Change to higher bit-rate codes. (However, this might cause bandwidth to suffer.)

• Implement QoS to always give voice traffic the highest priority.

• Avoid mixing voice with applications that produce large packets.

• Introduce high-performance routers and gateways as necessary to deal with the issue of composite delay.

In LAN-based IP Telephony deployments, delay should not be a big issue unless the SMB is geographically dispersed and/or relies on the Internet or lower-capacity WAN links to transmit voice traffic between the LANs. However, proactively minimizing delay becomes a critical success factor in ISP/carrier voice deployments.

Echo and Jitter

Anyone who has traveled to a remote region that has a less-developed communications infrastructure has likely experienced a variety of challenges relating to voice communications. Extremely high attenuation might require raising one's voice to be heard at the other end, and significant delays are always a factor, especially if part of the communication path is through a satellite link. When you add to these problems hearing your own voice echoing back to you and hearing a garbled sound from the person at the other end (resulting from variable delays between the packets that compose the voice stream), the overall communication experience becomes less than pleasant.

PSTNs have implemented echo cancellers to minimize the impact of the amplification and reflection of your own voice traveling back to you. Echo is not as much of an issue in pure IP Telephony deployments. However, wherever IP and PSTN interface, there is the potential for problems with echo.

Jitter comes about as a result of lack of synchronous end-to-end transmission on packet-based networks, meaning that there is the potential for variable (as opposed to constant) delays between the individual packets carrying voice traffic. For example, if some packets in a voice stream get stuck in a queue and others do not, jitter occurs.

The extent to which jitter is detectable by the end users depends, of course, on the level of variability itself. But just as echo is inherent in circuit-switched networks, jitter is inherent in packet-switched networks. Jitter can be minimized via QoS (traffic prioritization) and not mixing voice traffic with large packets on the same links (especially slower WAN links). The LFI feature, which breaks larger packets into smaller ones and interleaves them with real-time traffic like voice, reduces jitter on slower links.

Within an SMB or an enterprise where the entire IP Telephony solution operates over a high-speed LAN with only a single gateway for PSTN calls, jitter, echo, and delay are normally not a problem, provided that the IP network works well to begin with. Jitter and echo can become more of a problem in carrier/ISP deployments that combine multiple IP WANs, portions of different PSTNs, and equipment from multiple vendors. Numerous SMBs operate these kinds of networks around the world.

Network Availability

One aspect of voice communications that requires serious consideration during the design stage is a high service availability expectation on the part of telephony users. You need to obtain answers to the following questions:

• How high an availability expectation is reasonable?

• What price does an SMB need to pay to push the availability as close to the 100 percent mark as possible?

Most telephone companies (telcos) pride themselves on offering five 9s (99.999 percent) or six 9s (99.9999 percent) reliability for their central office (CO) switches or PBX products. That level of equipment reliability translates into approximately 5.25 minutes of downtime per year for the five 9s and 31 seconds of downtime for the six 9s reliability levels. These are statistical numbers, however. Despite their value, statistics can be deceiving.

From the end-user perspective, what is the meaning of this level of reliability for a singular piece of equipment in the context of an entire communications solution? Multiple components and pieces of equipment are involved in any telephony solution. The factors in total network availability calculations must include the following:

• Mean time between failures (MTBF) for all of the relevant equipment and/or communications links that make up the collective infrastructure to support the act of making a phone call

• Mean time to repair (MTTR) for all of the relevant equipment and/or communications links that compose the collective infrastructure to support the act of making a phone call

• Software reliability

• Required time for scheduled maintenance and upgrades

• Power availability

Assume, for example, that the probability of being functional through the course of a year has been calculated for every piece of hardware and software required for making phone calls. Equipment and software upgrades have been reduced to a component of the entire solution and assigned a level of probability as well.

The product resulting from the multiplication of all of the individual probabilities translated into time would give the end users a perspective of the level of service availability that they could expect.

Assume that the product of all of the individual probabilities is 0.995, or a 99.5 percent probability of the IP Telephony network being available for use. Conversely, this translates into 0.005 or 0.5 percent probability of the network not being available. Translating 0.5 percent unavailability into time over the course of the year (365.25 days × 24 hours/day × 0.005) results in approximately 44 hours (43.83 hours, to be exact) of downtime per year, or less than 2 days.

Two days per year of service unavailability in no way implies that any single piece of equipment would have this kind of downtime, because the individual components have not even been specifically identified in this calculation. The number serves only as an example of what an end user might expect. And when you put it in the context of a typical work schedule, it's not that drastic. Most SMB employees take vacations that are longer than 2 days per year.

Geographical location of the solution deployment might accentuate the factors that affect service availability. Not all telcos around the world offer five 9s or six 9s levels of reliability for their equipment, mobile phone users have traded a degree of service availability and quality for the convenience of mobility, and there is no way to tell what level of availability exists within individual networks that rely on a PBX-based system.

When approaching an IP Telephony design, the level of availability expectation on the part of the customer should be ascertained beforehand in the context of the existing and proposed solutions. This means that you need to identify solution components, assign to each a level of probability of being functional throughout the year, and translate the final product into time. It's not a bulletproof calculation, but it's a mechanism that can give a realistic perspective to the customer and avoid bad feelings following deployment.

Figure 8-1 summarizes and maps from the user perspective the QoS requirements in any type of telephony deployment with the tools that are available to you to implement a robust IP Telephony solution that meets those requirements.

Single Communications Infrastructure for Voice and Data

The idea of a single communications infrastructure for all SMB communications needs might be appealing from the operations perspective. A single IP network implies greater installation/upgrade/maintenance uniformity over separate data, voice, and video networks. That, in turn, can lead to lower deployment costs and less diverse training requirements for support personnel.

Consider also the potential downsides of a single communications infrastructure:

• Does it make sense from the performance perspective to lump traffic from drastically different types of applications onto the same network? In the context of bandwidth and transmission delay requirements, the combined data/audio/video applications can be extremely bandwidth intensive but hardly time sensitive, and vice versa.

• How about the built-in separation between different types of application traffic that allows the telephone network to function even if there is a problem with the data network? In the presence of two separate networks for data and telephony, the outage of one normally does not affect the other.

The issue of redundancy and built-in high availability expectation on the part of voice users always needs serious consideration when making the commitment to a single IP-based network for all communication needs. Network availability and, consequently, service availability need not be adversely affected by a single infrastructure, as long as the components of the infrastructure are identified, along with their level of reliability. That allows for an approximate determination of the probability of the service being available during a certain time frame. You then need to match this level of probability with the SMB's expectation for service availability.

From the perspective of performance, a single communications infrastructure for data, voice, and video does not mean that every link within that infrastructure accommodates all categories of traffic. It means that the protocols, transmission media, and switching equipment are of a similar nature rather than representing different technologies, such as circuit and packet switching.

It is possible to have portions of an IP network that are dedicated to voice only or a network that shares all types of traffic. You can make decisions regarding traffic types based on anticipated traffic levels, bandwidth capacity, and switching equipment performance. QoS techniques can assist with ensuring an optimal level of performance for voice in scenarios where bandwidth needs to be shared among varied types of traffic.

Open Standards Protocols

A general trend away from Time Division Multiplexing (TDM) and toward IP-based Telephony necessitates the use of open standards protocols for multivendor interoperability. Protocol standards can be categorized as follows:

• Open— Open standards are widely available. Open Internet standards in the form of RFCs are available for free, but some standards from bodies such as IEEE or ITU-T carry a price tag.

• Proprietary— Although a vendor might share details of proprietary protocols with third-party developers, those protocols are still proprietary to the vendor.

• De facto— De facto protocol standards are accepted by the industry but are not approved by standards organizations.

If you consider telephony in its totality (including its history), its operations are governed by all three categories of standards, whereas IP Telephony standards mostly fall into the open category from Internet Engineering Task Force (IETF) and ITU-T.

You are strongly encouraged to examine products and solutions from vendors to see if they use proprietary standards, which tend to make a product more efficient but can lock an SMB into a single-vendor environment. You need to decide on a single-vendor versus a multivendor environment for an IP Telephony solution based on user requirements and product availability from a single vendor. Single-vendor solutions are normally easier to support but might not have all of the desired features. Consequently, the ideal situation might be a mostly single-vendor solution that is open standards-based so it can be easily supplemented with products from other vendors.

Common OS Hardware Platforms

The use of common OS and hardware platforms for IP Telephony solutions is still elusive as compared to the special-purpose computers, which is what PBXes effectively are. However, the trend toward the use of common platforms for IP Telephony is growing. CallManager, which is the heart of the Media Convergence Server (MCS) 7800 series and Integrated Communications System (ICS) 7750 solutions, runs under a Windows version on hardware platforms utilizing Intel processors. Cisco's H.323 gatekeepers can operate on several router models as long as the appropriate IOS and the sufficient amount of memory are present. Given the specialized nature of the call-processing software, it's still best to go with a vendor-approved list of hardware, but the choices in this situation are certainly more diverse than they are for a single special-purpose computer.