VoIP Ebook PDF

Do You See What Im Saying?
Managing VoIP Quality of Experience on Your Network

Jeff Hicks, VoIP Architect, NetQoS, Inc.
VoIP:
2008 NetQoS, Inc.
VoIP: Do You See What Im Saying?
Prologue
Network convergence offers the vision of a single network, carrying traffic from many different types of applications (voice, video, and data, to name a few). Many have been enticed by this vision. A large and increasing number of organizations have a voice over IP (VoIP) pilot or a full deployment project, either ongoing or planned for a future date. And its almost impossible to buy a non-VoIP enabled phone system these days. In many cases, VoIP is just the entry point for rolling out new unified communications applications, such as real-time dashboards, video, and presence. Therefore, success is doubly critical for organizations deploying VoIP. Not only is phone service vital to the success of most enterprises, but if VoIP doesnt work well, the results are delays when deploying other, related applications, as well as long-term ramifications that are harder to predict. A performance-first approach to network management is never more important than when deploying VoIP. In the early days of VoIP technology development, concern centered around call server uptime. Today, VoIP systems have matured to the level that you can move beyond making them work to making them work well. Now the focus has shifted to making VoIP perform well. The task of making VoIP perform to the highest possible standard increasingly falls to youthe converged network manager. In the past, the network manager was responsible for the network only, and didnt need specialized application expertise. Convergence is changing all of that.
www.netqos.com
And network managers find that making the VoIP application perform well can be a challenge. Users have very high standards for VoIP performance. Enterprises deploying VoIP need to be able to see how their users quality of experience relates to the quality of service provided by their network. The key question is raised in the title of this book: Do You See What Im Saying? Or, in other words do you have the visibility into the key performance metrics relevant to VoIP and the quality of experience seen by your users? This book equips you, the network manager, with the knowledge you need to be successful in managing VoIP quality of experience on your networkthe first step down the path toward truly unified communications. Understanding how VoIP works and whats important to ensure the performance of VoIP is a crucial part of this journey. This book therefore begins with a discussion of the protocols that are used for VoIP communications, then moves on to show you how those protocols affect performance. Once you understand some of the basic facts about VoIP and how it behaves on the network, well show you how you can use your knowledge of VoIP to keep it performing at the highest possible level as you prepare for and deploy exciting new unified communications applications.
877.835.9575
How This Book Is Organized

VoIP: Do You See What Im Saying?: Managing VoIP Quality of Experience on Your Network provides a comprehensive look at a complicated set of technologies. Keeping in mind the complexities you face as you prepare to deploy VoIP, complete a VoIP rollout, or fine-tune your deployment, well present the information in a structure that lets you build on the knowledge you already have.
www.netqos.com
Here is what each chapter covers: Chapter 1

Introduction to VoIP Protocols
Basic VoIP hardware and terminology. What are the key VoIP call setup protocols? What are the key VoIP conversation protocols? VoIP traffic and how it differs from traditional networked applications. VoIP bandwidth considerations.
Chapter 2
VoIP Call Setup Performance
Key call setup metrics that you should be interested in. Call setup protocol details that affect performance. Network requirements for call setup. Troubleshooting call setup problems.
Chapter 3
VoIP Call Quality Performance
Call quality standards and why they are important. Key call quality metrics that you should be interested in. What impairments affect call quality? Where are quality problems likely to occur?
Chapter 4
The Road to Unified Communications
VoIP is a foundation for other communications technologies What are the new Unified Communications applications? How will Unified Communications affect network performance?
877.835.9575
Chapter 1
Introduction to VoIP Protocols
VoIP has a unique set of performance requirements that make it a challenge for any data network. Understanding the operation of core VoIP protocols is a first step in understanding the performance requirements that VoIP places on your network.
A VoIP phone call occurs in two stages:

Call setup.
This stage is required to set up everything needed to make the telephone connection between the person making the call (the caller) and the person receiving the call (the called party).
The call itself.
The audio conversation needs to be encoded and transmitted across the network. The hardware required to make a VoIP phone call varies by vendor, but there are several common components that you will see on your network. Lets discuss some of these devices and terminology before diving into the protocols that they use to communicate.
Do you know this already?

Many of you may have already deployed VoIP and are working with it every day. If you already have a good grasp on the basic components and protocols, you may want to skip to ahead to VoIP and Network Performance on page 19.
www.netqos.com
VoIP Hardware
A large number of new devices must be added to your network to support VoIP. Each of these devices will need an IP address and will communicate with other devices on the network. In terms of sheer numbers, IP phones will make up the largest group of new devices on your network.
IP Phones
IP phones connect to the network via an Ethernet interface. Many IP phones receive their power over the Ethernet connection from LAN switches that support the power over Ethernet (POE) protocols. This is similar to the way that Plain Old Telephony Service (POTS) phones can draw power from the Public Switched Telephone Network (PSTN) wiring and still function in the event of a power failure. Some higher-end IP phones have a single-port switch built into the phone, which allows a PC to be connected through the phone switch to the network. IP phones typically run an embedded operating system with its own TCP/IP stack for communications. And IP phones contain the software called a codec that is necessary to convert a voice conversation to IP packets. Many IP phones can also run applications. Web services and protocols such as XML are used to turn IP phones into mini-computing devices. In addition to hard IP phones, there are also soft phones, which consist of an application running on your desktop or laptop computer. Using an attached headset or the computers own microphone and speakers, the softphone provides similar functionality to a traditional phone. Both hard and soft IP phones register with a call server that provides the call setup functionality needed to make a phone call.
Call Servers
The call server serves as the core of a VoIP system. Its primary function is to provide call processing. Using a number of different protocols, a call server communicates with IP phones, voice gateways, and with other application servers. Sometimes called an IP PBX, the call server provides telephony features similar to a traditional PBX features like hold and resume or
877.835.9575
transfer. IP phones register with their call server and communicate with it during the call setup phase of the phone call. The call server runs an operating system such as Microsoft Windows, Linux, or, in some cases, an embedded operating system, and it typically manages the configuration necessary to form the dial-plan for an enterprise. Call servers may be grouped or clustered together to provide increased fault-tolerance and load-balancing capabilities. All the major VoIP vendors have different classes of call servers. Some are tailored to the needs of large enterprises, while others work well in SMB environments. Cisco CallManager is a popular example of an enterprise class call server.
Voice Gateways
The primary function of the voice gateway is to connect the IP network and the PSTN. Voice gateways must be able to communicate using many different protocols to route phone calls between the IP network and the PSTN. Gateways provide many different connection types to the PSTN, including analog and digital PRI. A T1 PRI connection is one of the most commonly deployed solutions. The basic T1 PRI configuration provides for 23 voice channels or connections to the PSTN. These channels are grouped together to form trunks. A single voice gateway can support multiple T1 PRI connections. Voice gateways may provide translation between the PSTN and the IP network. This translation, called transcoding, is the conversion between different encoding algorithms. The PSTN uses Pulse Code Modulation or PCMU encoding. This type of encoding, which is also known as G.711, is often used on VoIP networks as well. But if a different type of encoding is used, the gateway must transcode the communications. Now that weve covered some of the basic VoIP hardware components, lets discuss the protocols that they use to send data across the network. Well begin by looking at some of the protocols that are used in the call setup portion of a VoIP call.
www.netqos.com
Call Setup Protocols

The call setup stage of the VoIP call requires protocols that enable dial tone, number lookup, ringing, and busy signals. In other words, a lot has to happen before the call even occurs. Call setup protocols also handle things that happen after the call, including resource cleanup and statistical reporting. Call setup protocols use either the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) to transfer data during the setup, call processing, and resource cleanup phases of a telephone call. Each protocol uses a well-known port or ports for communication. Some call setup protocols are used primarily for communication between endpoints (IP phones) and call servers, while others allow for communication between call servers and voice gateways handling calls to and from the PSTN. Call setup messages are sent back and forth between the caller, called party, call server, and/ or voice gateway. For calls that travel between the VoIP network and the PSTN, the call server converses with a voice gateway using the appropriate call setup protocol. These messages, which vary in size and number, handle functions like the mapping of phone numbers to IP addresses, generating dial tones and busy signals, ringing the called party, and hanging up. Figure 1-1 shows a typical VoIP configuration with call setup flows among the different components.
Figure 1-1 Call setup protocols are used between endpoints, call servers, and voice gateways.
877.835.9575
Many different call setup protocols, some standardized and some proprietary, are in widespread use in VoIP deployments. Well describe some of the most popular call setup protocols below:
H.323
The call setup protocol H.323 is standardized by the International Telecommunications Union (ITU). H.323 is somewhat of a legacy. It has been widely deployed and, was among the first call setup protocols used for VoIP calls. In a VoIP environment, H.323 is commonly used by voice gateways to connect the IP network to the PSTN. However, H.323 is actually a family of telephony-based standards that can be used by endpoints for both voice and video conferencing. H.225 and H.245 are two of the protocols in the H.323 family that are involved in call setup. H.225 uses TCP and port 1720 for communications. H.245 uses TCP as well, but the ports used are dynamically negotiated during the H.225 phase of the setup. Setting up a call with H.323 can require many TCP flows and handshakes. Some implementations of the protocol provide a fast start capability to bypass some of the normal handshaking in an effort to speed up call setup performance. Be aware of this fact if you are investigating network performance issues during call setup. Some additional configuration on the voice gateway is required for H.323 because the gateway maintains the information about how calls are routed. H.323 is a peer-to-peer protocol that lacks centralized configuration.
MGCP
The Media Gateway Control Protocol (MGCP) is another popular call setup protocol. It is standardized by the IETF in RFC 3435. MGCP differs from some of the other call setup protocols in that the endpoints typically do not use MGCP to control the phone call (although this is not prohibited by the protocol). Instead, MGCP is most often used to allow a call server to control a voice gateway connection to the PSTN. MGCP sends messages between the gateway and call server over UDP port 2427. Because the call server is controlling the gateway, most of the call control intelligence and configuration resides in the call server. With MGCP, the call routing information is configured in the call server instead of in the gateway.
10
www.netqos.com
Q.931
The Q.931 protocol is not a canonical call setup protocol, but it supports call setup by defining Layer 3 signaling information for ISDN PRI interfaces. These interfaces are commonly installed in voice gateways to provide connectivity to the PSTN. In an ISDN PRI, a separate TCP session is used to communicate additional information between the voice gateway and call server. This connection is often referred to as PRI Backhaul. Using the TCP protocol and port 2428, the PRI Backhaul connection provides the ISDN channel signaling information to the call server where the gateway is registered.
SIP
Session Initiation Protocol (SIP) is a call setup protocol developed by the IETF in RFC 3261 (and in many other RFCs too numerous to mention). SIP represents typical data-networking protocols: lightweight, relatively easy to understand and implement, ASCII-based. Many industry observers see it as the future standard for call setup, as vendors such as Cisco, Nortel, and Avaya are providing SIP phone/endpoint support. In addition, Microsofts Office Communications Server uses SIP as the protocol to support a number of unified communications applications. Although SIP can be carried over TCP or UDP, most implementations use TCP and port 5060. Secure SIP uses TCP and port 5061. SIP messages resemble HTTP: they are text-based and generally follow a request-response structure. Another interesting aspect of SIP is its ability to connect IP networks to the PSTN or other IP networks. Carriers are offering SIP trunking packages to enable an enterprise to connect by means of a session border controller (SBC) device to the PSTN or to another IP network. Our view is that SIP is a key enabler of unified communications. SIP can be used not only for voice call setup, but also as the protocol for video and instant messaging setup.
Proprietary Call Setup Protocols

In addition to the standardized call setup protocols discussed above, vendors have developed their own proprietary protocols. Heres a list of some of the top proprietary protocols that you may encounter:
877.835.9575
11
Cisco Skinny Client Control Protocol (SCCP)

Cisco phones typically use the Skinny Client Control Protocol (SCCP) for call setup. SCCP, called Skinny, provides a simple, lightweight call setup protocol for endpoints controlled by Cisco Unified CallManager (now being called Cisco Unified Communications Manager). Skinny passes messages using TCP and port 2000. It can be secured using Transport Layer Security (TLS). The secure version uses TCP and port 2443.
Nortel UNIStim
Nortel phones typically use the UNIStim protocol to communicate with call servers. UNIStim is a UDP-based request/ response protocol and has reliability built in at the application level. UNIStim uses port 5000 for communications.
Call Setup Ports

If you are looking at network traffic for diagnostic or monitoring purposes, or if you are maintaining firewall settings, it might be useful to identify the various VoIP call setup protocols by port number. Table 1-1 lists common call setup protocols and the transport protocol and port number that they use.
Call Setup Protocol Transport Protocol Port Number
SCCP MGCP Q.931/Q.921 (PRI Backhaul) H.323 SIP UNIStim
TCP UDP TCP TCP TCP or UDP UDP
2000 2443 (Secure) 2427 2428 1720, Multiple dynamic 5060 5061 (Secure) 5000
Table 1-1 Call setup transport protocols and ports.
12
www.netqos.com
No single call setup protocol dominates the present VoIP market. The protocols discussed here (H.323, MGCP, Q.931, SIP, SCCP, and UNIStim) are all used by VoIP equipment in varying degrees. However, the trend is definitely moving toward SIP as the call setup protocol of choice for endpoints and gateway devices.
VoIP Conversation
To be heard by the called party, the conversation portion of a VoIP phone call needs to be converted into packet format, sent across the network, reassembled, and then converted from packet format back to voice. A number of different standards and protocols are available to enable the VoIP traffic to travel across the data network.
Codecs
Codecs encode and decode both ends of the phone conversation to allow the audio signal to be sent and received across the network. Different codecs are in common use, and they have different bandwidth requirements and different characteristics that can impact network performance. Two of the commonly used codecs have been standardized by the ITU and use the names G.711 and G.729. The codecs job is to take the speech audio signal and transform it into a digital payload that can be sent across the data network. Some codecs, like the G.729 codec, for example, compress the data and require less bandwidth to send the conversation packets between the two phones involved in the conversation. However, the compression is usually lossy, meaning that some degradation in quality occurs as a result of the compression process. Other codecs, like G.711, do not employ any compression schemes. The upside to the lack of compression is that no additional data loss occurs, but the tradeoff is a requirement for more network bandwidth. Once the codec has the payload ready, its up to another protocol, the Real-time Transport Protocol (RTP) to transfer the data to the receiver.
RTP
Unlike call setup protocols, where there is no dominant player, the single protocol that is used almost exclusively for the transfer of VoIP conversations is RTP. (Perhaps the only really notable exception is Skype, which uses proprietary protocols that are beyond the scope of this book.)
877.835.9575
13
RTP is a protocol that is defined by the IETF in RFC 1889. An application protocol that rides on top of UDP, RTP is widely used for streaming audio and video. Applications that need realtime performance use RTP to send data in one direction with no acknowledgements. Because a VoIP call is bidirectional, involving two talkers, two RTP streams carry the conversation, one traveling in each direction between the caller and called party. These two unicast streams are referred to as call legs. Quality statistics are provided for each call leg and represent the quality of the RTP audio steam at the receiving end. RTP uses even-numbered UDP port numbers above 16384. Each unidirectional RTP stream typically uses the same destination port. The actual port number used is determined during the call setup exchange between the IP phones. The path that these RTP streams take through the network and the impairments encountered along the way are important factors in determining the quality of the voice conversations. Figure 1-2 shows the two RTP streams that make up a VoIP call.
Figure 1-2 Two unicast RTP streams make up a typical VoIP phone call.
RTP is a connectionless protocol like UDP, meaning the datagram is sent without acknowledgement and is not retransmitted if lost. RTP datagrams are composed of a payload and header information. The codec on the IP phone creates these datagrams by placing a 12-byte header inside the UDP datagram with a payload containing data produced by the codec. RTP datagrams are typically small relative to other data packets. For some codecs, the payload may be as little as 20 bytes. Several fields in the RTP header are used by the IP phone to help determine quality statistics. It is helpful to understand the structure of the RTP datagrams, which transport the encoded voice information. Figure 1-3 shows the composition of the RTP datagram and header information.
14
www.netqos.com
Figure 1-3 RTP Header Format.
As IP phones exchange data during a VoIP phone conversation, the sending phone fills in each datagram header, which contains several important fields:
RTP Payload Type
Specifies the codec that is used. The codec is important so that the receiver knows to apply the same codec to decode the data payload.
Sequence Number
The receiving side uses this field to aid in the reassembly of the data stream. The sequence number is also useful to help determine quality metrics, such as lost, out-of-order, and duplicate RTP datagrams.
Time Stamp
The RTP sender normally sends datagrams at a constant rate; for VoIP, this is usually every 20 or 30 milliseconds. Network delays and congestion can cause variations in the arrival time of datagrams in the same stream, a condition referred to as jitter. The timestamp is set by the sender of the datagram, and the receiver can use this information to determine the jitter. If the jitter is too great, the receiver may have to discard the datagram.
877.835.9575
15
RTP has an optional profile called Secure RTP (SRTP). SRTP was defined in RFC3711 and provides data encryption and message authentication. Anytime encryption is used, its important to understand the performance impact. With recent advances in phone hardware and firmware, encryption overhead is now minimalsometimes, its even measured in microseconds. However, for devices like gateways that are terminating a large number of media streams, the performance degradation can be high. Usually, there is a tradeoff in the number of simultaneous streams with encryption vs. without encryption. The number may be lower with encryption enabled because of the processing overhead associated with the encrypted streams.
RTCP
The Real-time Transport Control Protocol (RTCP) is a companion protocol to RTP that provides statistics about the RTP flow for a given call. Originally defined in RFC1889 along with RTP, the latest definition of RTCP is provided in RFC3550. RTCP defines sender and receiver packet types. In most cases, a VoIP phone would use the sender report because it performs both sending and receiving functions during the two-way conversation. RTCP uses odd-numbered UDP ports. Often a value of 1 is added to the port number of the RTP stream to get the RTCP port number. For example, if the RTP stream is using port 16384, RTCP would use port 16385. The statistics that RTCP provides are important to help determine the quality of the call and any underlying network metrics that contributed to the quality rating. Figure 1-4 shows the quality information available in the RTCP packet.
RTCP Metrics (condensed)
Jitter
Lost packets (fraction and cumulative number)
NTP timestamp
Figure 1-4 The RTCP packet contains a limited amount of quality information.
The RTCP packet contains quality statistics for packet loss (fraction and cumulative number), jitter, and a timestamp. You can use the NTP timestamp to compute a round-trip delay value between the sender and receiver. The jitter value is calculated according to RFC1889. This
16
www.netqos.com
calculation is based on the packet delay variation (D): D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) The jitter value ( J) is then calculated as follows: J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16 This calculation has the potential to hide jitter problems because it is an average derived from the last 16 packets. As an example, lets say that you see 14 packets with 0 ms of delay variation, followed by 2 packets with 80 ms of delay variation. The above calculation would yield:
J (for packet 15) = 0 ms + (80 ms 0 ms) /16 = 5 ms J (for packet 16) = 5 ms + (80 ms 5 ms)/16 = 9.7 ms
After 16 packets, the average jitter value is 9.7 ms, which seems like a very low amount of jitter; however, 2 packets actually had very high delay variation and were likely discarded by the jitter buffer. Additional work has been done to address some of the limitations in the quality metrics provided by RTCP. The RTCP-XR standard was created for this purpose.
RTCP-XR
RTCP-XR, defined in RFC3611, extends the RTCP report to provide additional quality metrics that are important in understanding the users experience with a phone call. RTCP-XR defines the VoIP Metrics block, which contains the additional information. Figure 1-5 shows a condensed version of VoIP Metrics with some of the key quality metrics.
RTCP-XR Metrics (condensed)
Loss rate Gap density/duration Signal/noise level
Discard rate Round-trip delay Echo return loss
Burst density/duration End system delay R-factor and MOS
Figure 1-5 The RTCP-XR packet contains much more quality information than RTCP.
As youll notice, the RTCP-XR specification contains many more quality-related metrics than RTCP reports. Some of the key metrics and their definitions:
877.835.9575
17
Loss rate
The percentage of packets that are lost by the network. This is the traditional network packet loss metric.
Discard rate
The percentage of packets that are received, but discarded due to early or late arrival. This is the jitter buffer loss metric. Well explain jitter and jitter buffers more in Chapter 3, where we discuss call quality metrics.
Burst/gap density/duration
These metrics provide an indication of the burstiness of the data loss. This is important because bursts have a greater impact on quality than random packet loss.
Signal/noise level/echo return loss
These metrics provide some quality data for calls that go through a voice gateway to the PSTN.
R factor and MOS
Provides an indication of the quality of experience for the call. The R factor is defined in ITU-T G.107. MOS is the mean opinion score, an estimation of the audio quality of the RTP stream. In RTCP-XR, the MOS is provided in terms of listening quality (LQ) and conversational quality (CQ). MOS-CQ takes into account delay that could impact the conversation quality, whereas MOS-LQ does not factor in delay. Well discuss all of the above metrics in more depth later in this book.
Proprietary Call Quality Reporting

In addition to the RTCP standards for reporting quality metrics, some vendors may send metrics back as part of the proprietary call setup protocols that they use. These metrics could be as basic as packet loss and jitter, or they could contain enhanced quality of experience information, such as a MOS value. We wont cover these methods in this book, but be aware that vendor-proprietary call setup protocols have ways of returning metrics related to the quality of the call.
18
www.netqos.com
Now that weve covered the key protocols used by VoIP, lets talk about how VoIP relates to network performance.
VoIP and Network Performance

Because phone calls have traditionally traveled over a separate network, the PSTN, the term convergence is often used to describe the process of putting VoIP traffic on the data network, allowing the two types of networks to come together. You are probably well aware that anytime you add a new application to the network, unexpected results often ensue. In this section, well discuss the many reasons why VoIP is likely to affect the performance of your existing applications, how those applications behave in comparison to VoIP, and the unique characteristics of VoIP that place new demands on the network. Lets first talk about some characteristics of non-VoIP applications that can affect their performance on the network.
Traditional Networked Application Performance

Theres a group of applications running on your network that can be termed traditional networked applications. These applications are usually critical to your business: email, ERP, Web, and database. Many of these applications are client-server based, and others are multi-tiered. They have some common qualities when it comes to their network performance requirements:
Traditional networked applications use the TCP protocol.
They use the TCP protocol because it is reliable and connection-oriented. TCP guarantees that any lost packets get retransmitted, and that you receive the data that you sent in the order in which you sent it. A key characteristic of TCP applications is that they are adaptive, meaning they adapt to changing network conditions. TCP provides a data window that can expand to allow more data to be sent, and contract to throttle back the amount of data that can be sent.
Traditional networked applications can tolerate packet loss and delay.
If a packet is lost, it is retransmitted. The application slows down, but for the most part, it is still usable. And if a packet is delayed, you may not even notice it. Consider email: If an email message gets delayed by 30 seconds, do you even know about the delay? Delay, or latency, is a
877.835.9575
19
key network performance metric for all types of networked applications. Its important to realize the impact that latency can have on performance. A latency of 100 milliseconds may seem insignificant, but if a transaction is composed of 100 requests/responses, thats 10 seconds of delay.
Traditional networked applications have a client-server structure and are transaction-oriented.
A Web browser client requests a page from a Web server. A database financial application updates a record on the finance database server. Theres an inherent many-to-1 (many clients to one server) traffic flow model here. The application transactions are made up of requests and responses. A simple transaction could be a single request and response, similar to those mentioned above. A more complex transaction could contain many short request-and-response flows, or, in the case of a file transfer, a transaction could consist of a single transmission of a large amount of data. The amount of time it takes to perform a transaction is known as the transaction time. The transaction time metric gives the end user some indication of how responsive the application feels.
Traditional networked applications are often written by programmers who arent networking experts.
Why does this matter? Networked applications can be optimized or de-optimized to transfer data. For example, a word-processing application can generate hundreds or even thousands of network flows for a simple File Open operation. If you are performing this operation over a network with high latency, you will be waiting for the file to load for a long time. Networked application programmers may not be up on the latest workings of the TCP Nagle or delayedACK algorithms. Adding to this optimization problem is the release of new operating systems like Windows Vista, with their corresponding tweaks to the TCP stack. So how do you measure the performance of a traditional networked application? You can look at several key performance measurements that are common to all the TCP applications discussed above. Table 1-2 lists performance metrics for traditional networked applications.
20
www.netqos.com

Performance Metric Description
Transaction Time or Response Time
Time from when a client sends a request and when the client receives the response. A reflection of the user experience for this particular application or network. Measured in milliseconds. Time it takes for a packet to travel between client and server on a network. Measured in milliseconds. Time it takes a client to confirm a servers connection acknowledgement. For applications that use many, short-lived connections, this metric can be an important indicator of latency (and thus, of application performance). Measured in milliseconds. The delay in network round-trip time caused by retransmissions. Measured in milliseconds. Throughput is the number of bytes transmitted divided by the amount of time required to transmit. Goodput is the same calculation, but it subtracts the retransmissions. Goodput provides a good indication of the client experience and is an important metric for applications that need to transfer a lot of data. Measured in kilobits or megabits per second.
Network round-trip time Network connection time
Retransmission delay Throughput/ Goodput
Table 1-2 Traditional networked application performance metrics.
Underlying these high-level application metrics are the basic network performance metrics of packet loss and latency. If your network has high packet loss, applications will have to retransmit data, thus affecting performance and adding delay. Under conditions of high latency, applications that use many transactions are the most severely impacted. Many times, network administrators attempt to throw more bandwidth at network performance problems, only to find out that the underlying issue was latency which the bandwidth doesnt necessarily address. Over a decade ago, Stuart Cheshire wrote an interesting article titled, Its the
877.835.9575
21
Latency, Stupid. (http://www.stuartcheshire.org/rants/Latency.html) Cheshire points out the problem with latency using the modem technology of the time. The networking technology has changed since then, but the latency problem still exists. As mentioned earlier, 100 ms of latency may not sound like much; however, couple that with hundreds of back-and-forth transactions and it can add up to many seconds of delay. Networks have been tuned over the years to handle traditional networked applications like email, Web, and other business-critical applications with excellent performance. These and other transaction-oriented applications rely on TCP to handle any network issues like congestion, delay, or lost or out-of-order packets. Unfortunately, this type of handling is radically ill-suited for the real-time performance characteristics of VoIP. If an email message is delayed by a few seconds, it is likely that no one will notice. However, if part of your voice conversation is delayed by a few seconds, you may hang up the phone. Lets take a look at why VoIP traffic has different performance requirements.
What Makes VoIP Traffic Different?

VoIP comprises a diverse collection of often new technologies that are helping transform the way we communicate, at work and at home. And it has a unique set of performance requirements that make it a challenge for the infrastructure supporting any data network. Understanding what makes VoIP different from the other traffic running on your network is the first step in understanding whats needed for optimal network performance when VoIP traffic is added to the mix on your data network.
Real-time VoIP Characteristics

Unlike the data traffic generated by traditional TCP-based network applications, VoIP traffic has real-time characteristics.
VoIP applications use the RTP protocol.
VoIP applications must send data immediately and dont have time to wait for retransmissions. Thats why they use RTP. As we explained above, RTP rides on top of UDP. UDP is a connectionless protocol, which means that it doesnt include a mechanism for retransmission or reordering of data. Instead of sending a packet and waiting to make sure it was received before sending
22
www.netqos.com
another packet, RTP applications typically send packets at a fixed rate to avoid congestion. Not only do they not resend data when loss occursthey dont even slow down. If an RTP packet is lost, its lost, and theres no chance to retransmit it. And if a group of consecutive packets is lost, entire portions of the conversation can be wiped out.
VoIP applications send small data packets.
VoIP data packets are typically small in comparison to other types of data packets. As explained earlier in this chapter, VoIP codecs are tasked with producing data packets from a voice conversation. The payload size for these packets can be anywhere from 20 bytes (for G.729) at the low end up to 160 bytes (for G.711) at the high end. Using fixed data rates, the codec typically sends these packets out every 20 milliseconds. Without proper quality of service (QoS) mechanisms active on the network, these small VoIP packets may get blocked behind a larger data packet waiting to be sent on a slower-speed WAN link.
VoIP applications have strict delay requirements.
Because voice conversations are interactive in nature, they are not at all tolerant of long delays. If delay is significant enough (usually more than 150 milliseconds), the phone conversation may feel as if you are talking over walkie-talkies. A VoIP packet may be delayed for several reasons: acketization delay occurs when the speech is encoded by the codec and P the packet is created. etwork delay includes time to transmit the packets, buffer and queue them if needed, and N move the packets from hop to hop through the network. itter buffer delay is added by the receiver when buffering packets to reduce the impact of J variations in packet arrival times. When these factors are combined, delay can easily become significant. As a result, minimizing the overall delay is an important consideration for maximizing the quality of interactive VoIP calls.
VoIP applications require QoS.
The PSTN did a great job of guaranteeing the resources needed for a call and maintaining them throughout that call. After the initial signaling, a path through the PSTN and all associated resources is reserved for each call. By contrast, an IP network does not usually operate this way. In an IP network, the resources are shared by many different users. Congestion at a router
877.835.9575
23
caused by another users large file download can impair the quality of your VoIP call. There is a QoS mechanism known as RSVP that can provide guaranteed resource reservation, but the result is such high overhead that it is not widely implemented. Nevertheless, a QoS scheme that provides prioritization for VoIP traffic is required for every VoIP deployment. The underlying network metrics that affect VoIP call quality are packet loss, jitter, and latency. We will discuss these metrics in Chapter 3. Because of the unique characteristics of VoIP traffic, a new set of demands is placed on data networks. Realize that, if you have good network performance for traditional networked applications, it is not a guarantee that performance will be good for VoIP applications. The real-time characteristics of voice create very strict requirements for network performance. There is some balance required of the network. An inappropriately configured network could very easily cause VoIP phone calls to have poor quality: calls could be delayed, dropped, or they could just plain sound bad. These call quality issues would quickly affect the end-user experience because telephone usage is very userintensive. You could end up getting a lot of calls to the help desk to fix the problemor at least, you would if the phones were working. However, you would not want to make your VoIP traffic perform great at the expense of other applications that are just as critical to your business. When deploying VoIP, you also need to consider the impact that VoIP can have on other applications.
The Impact of VoIP on Other Applications

Just as with any new application deployment, when you add VoIP traffic to the network, you need to take a careful look at the performance, and not only the performance of the VoIP traffic. You need to carefully measure the impact the VoIP traffic is having on your other enterprise applications. And as cool new, integrated Unified Communications applications roll out, providing such services as instant messaging, voice mail, video, and conferencing, you have to consider the network performance characteristics of those applications as well. Good QoS policies must be in place to give priority to VoIP traffic over the TCP applications, which arent very delay-sensitive. Jim McQuaid (Sr. Product Manager at NetQoS), recently did an interesting video blog post titled Nice Guys Finish Last The impact of voice/video on data applications. (http://www.netqos.com/niceguys) In this video whiteboard session, Jim explains a key point:
24
www.netqos.com
That the differences in the UDP and TCP protocols can have an interesting impact on the performance of all applications when VoIP traffic is added to the network mix. Specifically, the adaptive nature of TCP can result in cases where TCP application performance degrades when faced with additional UDP traffic. Within conditions of congestion, TCP plays nice and backs off: the window sizes shrink, and less data is sent and received. But UDP, and VoIP in particular, continue to send data with no regard to congestion. Even though VoIP applications send data at a fixed, relatively slow rate, if enough calls are present, each with two unidirectional streams, the VoIP UDP traffic might create congestion and crowd out the TCP application traffic, creating longer transaction times and impairing the performance of TCP applications. The goal in managing a converged network is to tune it so that many types of application data traffic can coexist and perform well. QoS mechanisms are necessary, as well as visibility into the underlying metrics that affect end-user quality of experience. And taking a step back from those metrics, knowledge of overall network performance is another significant factor in the success of a VoIP deployment. Figure 1-6 shows an example of how key metrics like transaction time can be baselined.
Figure 1-6 Baseline transaction time for critical applications.
877.835.9575
25
Comparing these baseline measurements before and after QoS is important, but you shouldnt ignore the possibility that congestion might become an issue. VoIP traffic is going to consume additional bandwidthmaybe more than you expect. Despite the smaller packet size, a VoIP call using the G.711 codec requires ~87 kbps of bandwidth. This is due to header overhead, which belies the fact that the data rate for G.711 is 64 kbps. And every call has two call legs. Its therefore important to consider the bandwidth usage of VoIP, especially if you have VoIP traffic traversing WAN links.
VoIP Bandwidth Considerations

How much bandwidth is consumed by VoIP? How much is consumed by other applications? Those are good questions to answer. Lets start with VoIP. Earlier in this chapter, we discussed the RTP protocol and the contents of the RTP header. While the RTP header is required to support the real-time nature of the protocol, the accumulation of RTP headers can add a lot of overhead, especially considering the relatively small size of VoIP codec payloads. Heres an example of the header overhead of RTP, UDP, and IP headers on each VoIP packet: RTP (12 bytes) + UDP (8 bytes) + IP (20 bytes) = 40 bytes The typical payload size for G.711 is 160 bytes, which means that RTP, UDP, and IP headers are adding 25% overhead. When you add in layer 2 headers dependent on the physical media, this overhead increases even more.
Real Bandwidth Required by Each Codec
Codec advancements have led to a new generation of codecs. G.711 and G.729 are still the most widely used codecs, but some of the newcomers tout better quality for less bandwidth. Some of the new codecs, such as RTAudio, provided with Microsoft Office Communications Server, are variable-rate codecs, meaning they can adjust the data rate based on underlying network conditions. With variable-rate codecs, more bandwidth is used to achieve better quality. In conditions of network congestion, the codec may throttle back the sending rate to use less bandwidth. The Bandwidth Usage column in Table 1-3 shows the actual bandwidth usage you can expect for some common codecs.
26
www.netqos.com
Codec
Data Rate
Bandwidth Usage
G.711u G.711a G.729 RTAudio
64.0 kbps 64.0 kbps 8.0 kbps 29.0 kbps
87.2 kbps 87.2 kbps 31.2 kbps 45.0 - 74.0 kbps
Table 1-3 Bandwidth required by different codecs.
Its not too difficult to do the math and calculate the approximate amount of bandwith consumed by VoIP, but this number could be ever-changing as calls come and go. Is there a way to determine this from the network? Yes! Theres a technology called Cisco IOS NetFlow, or more generally, IPFIX, which allows network devices (routers and switches) to collect information about protocol usage and bandwidth consumption. Figure 1-7 shows an example of the protocol data available from NetFlow.
Figure 1-7 Bandwidth breakout by protocol, including VoIP traffic.
NetFlow plays a key part of the management picture by providing the data to perform link traffic analysis. You can see whether, for example, the VoIP traffic is being crowded out by the Web traffic, or the opposite case as well. NetFlow can also provide information about the QoS markings for different protocols. This information is useful in troubleshooting cases where the VoIP traffic is not marked with the correct QoS bit settings. VoIP bandwidth is something to consider as part of any performance management strategy.
877.835.9575
27
VoIP Network Performance Visibility

Technology enables a lot of the things we do every day of our lives, and it also adds a little fun. You can get away to a far-off place in a matter of hours as long as it has an airport. But technology always has limitations. Take flying, for example: Visibility is a key requirement for operating an airplane. No planes can take off if the pilot cant see well enough. Even in a high-tech airport, you still need to be able to see whats going on around you. If you cant see, you cant fly. The same analogy applies to network performance, and to VoIP performance especially. If you dont have good visibility into what is happening on your network, you are likely to be grounded before your deployment really takes off. On a converged network, visibility into VoIP network performance is a key requirement for effective network management. Do you see what Im saying? At the end of the day, VoIP will provide a strong test for the underlying network. Even if you have a high-performing network, some tuning will almost certainly be needed to support VoIP at the level required for high-quality calls.
28
www.netqos.com
Chapter Summary
In this chapter, weve introduced the VoIP protocols and the basics of VoIP network performance. Most of the time, we dont think too much about the underlying protocols when we use traditional TCP network applications, but in the case of VoIP, the protocols themselves have some interesting characteristics that can affect the performance. Lets briefly summarize a recommendation for how to handle VoIP traffic on your network. You cant treat voice traffic the same as traditional networked applications. Why? ifferent protocols RTP vs. TCP D ifferent packet sizes small VoIP vs. large data D ifferent QoS requirements delay sensitive for VoIP D ifferent data rates relatively low, constant for VoIP; elastic for TCP D ifferent user expectations PSTN-shaped, high quality for voice, vs. data, where delays D might not be noticeable The quality of experience that your users perceive from a VoIP system is largely shaped by their perception of the availability and call quality that the system provides. In terms of the phone system, availability can be summarized with the following basic criteria: o you get a dial tone when you pick up the phone? D oes the call connect within a reasonable amount of time? D In the next chapter of this book, well examine these questions and how they are related to VoIP call setup performance.
877.835.9575
29
Chapter 2
VoIP Call Setup Performance
Your experience with any phone system begins when you pick up the handset. You may then press a button to talk or take some other step to get a dial tone. Or you may skip the dial tone altogether and go directly to dialing the phone number you want to call. As new unified communications dashboard applications roll out, you may just click on an icon to place a call to another person. But regardless of the actions you take to place a call, the quality of experience that you have with that phone system is largely shaped by your perception of the availability and call quality that the system provides. From a users perspective, phone system availability can be summarized with the following basic criteria: o you get a dial tone when you pick up the phone? D oes the call connect successfully? D f so, does it connect within a reasonable amount of time? I If you pick up the phone and dont receive a dial tone within several seconds, then youll likely hang up, thinking the phone system is down. If you dial a phone number and dont hear ringing or a busy signal within several seconds, then your perception is that you cant make calls. If the call fails to connect and you hear a fast busy signal, then youll likely think that the call did not go through and that you have to try again. All of these experiences getting a dial tone, connecting the call, ringing the other party are dependent on the performance of the call setup protocols in a VoIP system. The PSTN has done a good job of shaping our expectations for call setup performance. In fact, over the years, call setup time has steadily decreased. Eyers and Schulzrinne point out that call setup time has dropped steadily over the last 80 years, from a high of 4 minutes in 1923, to 1.2 minutes in 1928, down to 10.9 seconds in 1978, and to less than 2.5 seconds in 1998 [1]. So as weve come to expect high performance for call setup from the PSTN, what happens on a VoIP network? Can this same level of call setup performance be obtained? Should it even be a goal?
30
www.netqos.com
The answer is yes, but it takes a certain amount of both attention and management. In the previous chapter, we introduced some of the key call setup protocols like SIP, MGCP, H.323, and SCCP. If you are not familiar with the basics of these protocols, we encourage you to take a look at Chapter 1. In the present chapter, we will discuss the performance characteristics of the call setup protocols and how you can tune them to ensure optimal user experience. First, its important to understand that in any VoIP system, there are a couple of different call types that involve different components and protocols. The interaction of calls of a certain type with your components and the protocols they speak can affect the call setup performance that users experience, for better or worse.
OnNet Calls
An OnNet call is a call that takes place between two IP phones on the same logical network. In this scenario, the IP phones use call setup protocols like SIP or SCCP to interact with a call server that sets up and takes down each phone call. These calls are typically all IP, meaning they are carried on the IP network and do not have to go out to the PSTN. For an OnNet call, several events have to take place during the call setup phase to provide good call performance. The simplest scenario is when a call is made between two IP phones that are known by the same call server or by a single cluster of call servers (intracluster calls).
Intracluster Calls
To enable a successful intracluster call, the phone and its call server need to communicate with each other via a call setup protocol. In the case of a Cisco IP phone, as soon as it starts up, the phone establishes a TCP connection with the call server, a phase thats often referred to as the registration process. The connection between phone and call server will be long-lived, and it will be kept active by a periodic exchange of messages, every 30 seconds or so. If network connectivity is lost or intermittent, the connection may be broken, and the keep-alive messages may not be received. In this case, the phone is said to have unregistered with the call server. If the network is unstable, with links coming up and going down frequently, the phones may have to
877.835.9575
31
constantly re-register with the call server. And anytime a phone is not registered with the call server, it cannot originate or receive a phone call. Figure 2-1 shows the call setup message flow between an IP phone and call server.
Figure 2-1 Call setup messages in a Cisco system.
When a user picks up the handset, the phone sends a message to the call server, which responds with a message that tells the phone to play the dial tone. If the call server is busy when the request is made, or if the network round-trip time is high, this message could be delayed. And if the delay is considerable, the user experience with the phone system is affected. After getting the dial tone, the users next step would be to dial the number. As the user dials the phone number, a series of setup message flows occur between the calling IP phone, the call server, and the called IP phone: 1. Calling phone sends dialed digits to call server. 2. Call server determines location of called phone. 3. Call server sends setup messages to called phone, telling it to ring. 4. Call server sends setup messages back to calling phone, telling it that the called phone is ringing.
32
www.netqos.com
At numerous points, call setup performance can be impacted by interruptions in these flows. First, if the call server is busy, it may take some extra time to look up the called phone information. If the round-trip time between calling phone and call server or between called phone and call server is high, then the overall delay will also be high. Figure 2-2 shows the high-level concepts that must occur for the call to go through.
Figure 2-2 Call setup exchanges that occur when a call is made.
With any intracluster call, it is important to understand the network path between the call server and the IP phones. If the phones and clustered call servers are on the same LAN, the potential areas of concern are substantially reduced. However, if the phones are in a branch office connected by a WAN to the data center where the call server cluster resides, call setup performance may be an issue.
877.835.9575
33
In a Cisco environment, the call servers in a cluster can be geographically distributed, adding another layer of complexity to call setup procedures. Cisco network design requirements are rather strict for these scenarios: network round-trip time cannot exceed 40 ms, and at least 1.544 Mbps of bandwidth must be reserved for communications between the call servers. In a distributed environment, you also need to be aware of which call servers your phones are registered with. In a failover case, phones at one site may fail over to a call server in a different geographical site. Call setup performance may be affected while the calls are using this backup server as call setup messages are routed over the network links to this other site.
Intercluster Calls
An intercluster call takes place between two IP phones that are registered with different call server clusters. In this case, a connection between the clusters known as an intercluster trunk allows the call servers to communicate with each other using H.323 or SIP. In this scenario, a kind of mini-call setup occurs between the two clusters whenever an intercluster call is made. Figure 2-3 shows an example of an intercluster call.
Figure 2-3 A call setup process must occur between clusters to enable an intercluster call.
In the intercluster scenario, performance issues could occur between each IP phone and its call server, as well as between the two call server clusters. Depending on the composition of the network connecting the two clusters, bandwidth and QoS may be an issue.
34
www.netqos.com
Weve discussed some examples of calls that typically stay on the IP network. Now lets look at the procedures used to set up calls that travel outside the IP network.
OffNet Calls
An OffNet call is a call that travels from the IP network to the PSTN. This type of call would typically pass through a voice gateway and could originate either from the IP phone or from a phone in the PSTN. As soon as a voice gateway gets involved, call setup complexity and the potential for performance problems increase; you now have a situation where the call server communicates with the gateway, which in turn communicates with a separate network (the PSTN). Figure 2-4 shows an example gateway configuration for OffNet calls.
Figure 2-4 OffNet calls involve a gateway to handle routing to the PSTN.
OffNet calls could be local, long distance, or even international. To stay on top of call setup performance in a VoIP deployment, its important to understand some of the call setup performance requirements for OffNet calls and the role that the voice gateway plays in enabling them.
877.835.9575
35
Gateways and Call Setup
To take a closer look at call setup for an OffNet call, lets discuss an example involving a typical PRI connection in a gateway using the MGCP protocol. With respect to call setup performance, what issues should you be concerned about? One of the first things to consider is that call setup through an MGCP PRI gateway will typically use both UDP and TCP flows. The MGCP protocol itself uses UDP with application-layer reliability built in. And a PRI connection uses a TCP channel thats established between the gateway and call server. In order to set up a call, the network must handle the UDP and TCP flows in a timely manner. Figure 2-5 shows a typical inbound call setup procedure using an MGCP PRI gateway.
Figure 2-5 Gateway example showing MGCP call setup flows.
36
www.netqos.com
The network components between the gateway and call server need to handle the TCP and UDP call setup packets with low latency. These call setup packets should therefore use a QoS marking to ensure proper prioritization. The DSCP setting of Class Selector 3 or CS3 is used to mark MGCP packets. QoS settings for call setup are typically different than those used for the VoIP call data. Different queues and classes allow for different levels of prioritization and the VoIP data traffic is usually given priority over the call setup traffic. Another common gateway call setup protocol, H.323, uses a lot of TCP flows to set up OffNet calls. This chatty protocol requires a number of back-and-forth flows among gateway, call server, and phone. In the previous chapter, we mentioned the impact that latency can have on protocols that require many flows. The latency adds up for each round trip, and it can easily affect the user experience with the VoIP phone system. H.323 actually consists of two protocols that handle the call setup tasks: H.225 and H.245. Figure 2-6 shows an example of H.323 call setup with the underlying H.225 and H.245 flows.
Figure 2-6 Gateway call setup example using H.323 flows.
877.835.9575
37
The large number of H.323 flows required for call setup has resulted in new implementations that offer an option called Fast Start. H.323 call setup using Fast Start provides a way to include the H.245 information within the H.225 flows, which reduces the total number of flows required to set up the call. Not all gateways support Fast Start, so be aware of this possible limitation when investigating issues related to H.323 performance. The gateway has a lot of decisions to make when connecting the IP side of the network with the PSTN. For starters, it must pick the appropriate port or channel by which to send the call out to the PSTN. If a channel is not available, the gateway must provide a failure indication to the party that is trying to set up the call. All of this has to happen within a few seconds, or the user may assume that there is a problem. Because the user experience is really what quality VoIP performance is all about, lets consider how you can measure VoIP performance from the perspective of call setup. Several key metrics are relevant for understanding the user experience with the call setup portion of a VoIP call.
Key Call Setup Metrics

Just as with any network application, the underlying network performance will have a direct effect on user perceptions of call setup performance. Metrics like transaction time and network round-trip time are often used to measure TCP application performance and can be helpful when you need to tune network components. However, these metrics may be difficult to relate to the user experience with the phone system for several reasons. The network specific metrics are not application - or protocol - aware. Transaction time could be skewed by many keep-alive requests sent from the phone to its call server. Network round trip time is a good indicator of latency, but what if the call server processing speed is the problem? A more VoIP-specific focus is required when tuning the network to carry high-quality phone calls. As a result, IP telephony experts instead rely on several metrics that relate directly to call setup performance to help them measure the likely user experience when interacting with the system. Lets discuss these key metrics individually.
38
www.netqos.com
Delay to Dial Tone
The first user experience with a phone is likely the audible presence of a dial tone. To produce a dial tone, the IP phone sends a message to the call server letting it know that the phone is now off hook. And the call server sends a message back to the phone instructing it to play the dial tone. The time it takes for the off-hook message to be sent and the call-server response to be received is called the delay to dial tone. Figure 2-7 shows an example of the delay to dial tone calculation for an IP phone running the SIP protocol.
Figure 2-7 The SIP phone sends a Notify and gets a response before playing a dial tone.
The components involved in the delay to dial tone metric are the network round trip time (NRTT) and some amount of server processing time required to receive the off hook message and send the response. Network congestion and/or server congestion can both be culprits when delay to dial tone values are excessive. An overloaded call server can be slow to respond with the message telling the phone to play a dial tone. How much delay is too much when waiting for a dial tone? A reasonable time is 2 to 4 seconds. Any delay beyond 4 seconds may cause the user to think that the phone system is down. The delay to dial tone metric usually only applies to outbound IP call legs. By contrast, an inbound, voice gateway call leg would not have a delay to dial tone metric because the dial tone for the PSTN phone is nearly instantaneous. And there are other cases where a delay to dial tone metric may not be applicable. For example, if you dial a number by pressing a Dial or Redial softkey, you may not get a dial tone; the call is dialed immediately.
877.835.9575
39
Post-Dial Delay
After the user dials a phone number, the next thing he or she expects is to hear a ringing or busy tone. The time between when the last digit of the phone number is dialed and when the user hears the call indication (ringing or busy) is called the post-dial delay metric. The PSTN has set the bar for post-dial delay quite high (or low, as the case may be). Calls on the PSTN usually connect in a very short period of time. In a VoIP network, this same level of performance can be achieved, with some careful tuning and management. Some guidelines have been established for the post-dial delay metric and are accepted industrywide. The ITU E.721 standard defines target values for different call types. Table 2-1 shows the target post-dial delay values.
Call Type Post-Dial Delay Target (Normal Load)
Local connection Toll connection International connection

Table 2-1 Post-dial delay guidelines from ITU E.721.
3 seconds 5 seconds 8 seconds
The post-dial delay metric depends on the protocol flows that occur after the user has entered the last digit of the phone number. Figure 2-8 on the next page shows an example of post-dial delay, calculated for the SIP protocol. When examining the post dial delay metric, you should not factor in user time. For example, a caller may start dialing a number and then pause to look up the rest of the number. Post-dial delay calculation begins after the last digit in the number is pressed, or in some cases after the entire number is sent in a single flow. Perhaps the first thing to look at more closely when investigating a performance issue with excessive post-dial delay is the configuration of the dial plan in the phone system. The dial plan is configured at the call server and/or gateway. It contains the information needed to route calls
40
www.netqos.com
to their destination. The way the dial plan is structured can actually introduce an unnecessary delay in call processing. In a variable-length dial plan, the call server or gateway must wait to make sure that the user will not enter more digits. For example, you might have a dial plan that allows numbers like 42xx or 42xxx. If a user dialed the number 4203, it could match either one of the two patterns: 42xx or 42xxx. Anytime a number is dialed, the call server or gateway must therefore wait to make sure that the user is not going to enter another digit. This delay is often called the interdigit timeout and it is usually a configurable parameter on the call server and gateway. The default value may be as high as 10-15 seconds. This means that a user could enter the last digit of a phone number, but the phone would not ring until 10-15 seconds later, when the interdigit timeout expired and the call server or gateway let the call proceed.
Figure 2-8 Simple SIP example showing post-dial delay calculation.
877.835.9575
41
Call Setup Failures
In addition to delay to dial tone and post-dial delay, the final aspect of call setup performance that requires VoIP-specific measurements is whether the calls are actually connecting successfully. When a call fails during the setup phase, often a fast busy tone is played by the phone. A call can fail to connect for many reasons. Cisco has a lengthy list of call failure cause codes in Cisco Unified CallManager Call Detail Record Definitions. [2] Table 2-2 lists some of the more common call setup failure codes and their causes.
Call Setup Failure Code
Description
Cause
1 3
Unassigned number No route to destination
The number that was dialed does not exist or has not been assigned. The number dialed is in the routing plan, but the called party cannot be reached through the network by which the call has been routed. The number dialed is valid, but there was a physical or data link layer failure at the remote party. There are no bearer channels available for this call. Could indicate a capacity problem with a need for additional channels. The network is not functioning and may be down for an extended period of time. Call admission control has denied this call due to lack of bandwidth. Could indicate a capacity issue with a need for additional bandwidth at this location.
27 34
Destination out of order No circuit/channel available Network out of order Out of bandwidth
38 125
Table 2-2 Common call setup failure codes.
42
www.netqos.com
A call setup failure in some cases may be expected. Access lines to the PSTN are a valuable, limited resourcea fixed cost for any organization. Because it is too cost-prohibitive and inefficient to provide a dedicated PSTN line for each employee, most enterprises operate on the assumption that not all users are on the phone at any given time. Depending on the calling patterns and volume at your enterprise, this is probably a good assumption. Traditional telecom professionals have a set of established metrics for tracking the percentage of time that a telephone user attempts to make a call and cannot get an outbound line (call setup failure code = 34). For a given phone system, the probability that an attempted call will be blocked is called the Grade of Service (GoS). One way of calculating GoS is shown by the following equation: GoS = number of setup failures / number of call attempts A common metric used in telecom SLAs, GoS is expressed as a decimal fraction. A GoS of <= 0.01 is the typical benchmark. This value means that 1% or less of the call attempts failed. Proactive monitoring of the key user experience metrics for call setupdelay to dial tone, post dial delay, and call setup failuresis an important part of any management plan. If you see degradation in any of these metrics, a closer look may be necessary to troubleshoot the problem.
Troubleshooting Call Setup Performance

Identifying the problem is the first step in tackling a call setup issue. Looking in the right place is a good second step. To identify the problem, you first need to understand which call setup performance metric is impacted. There are a couple of ways to find out. One method is to simulate call setup protocol flows and measure the results. This is the general approach taken by the Cisco IPSLA function that is a part of almost all Cisco routing and switching devices. Another way to identify the target call setup metric is by continually monitoring the call setup metrics for your phones as users make real calls. Both approaches provide value to a proactive management solution. In either case, when you are monitoring call setup metrics, you need to be able to quickly see which users are affected and which metrics are impacted. A good troubleshooting process must therefore include a step-by-step approach to isolating the problem. Figure 2-9 on the next page outlines a troubleshooting process for call setup performance issues.
877.835.9575
43
Which phone or group of phones is affected?
Identify Phones/Users
Is the problem isolated to a single (or few) users or is it more widespread?
Delay to dialtone
Identify Impacted Metrics
Post dial delay Call Setup failure Which call servers are involved? Which gateways are involved?
Identify Affected Network Gateway and/or Call Server
Is the problem between phone and call server? Is the problem between gateway and call server?
Figure 2-9 Step-by-step call setup problem identification.
Once you know the phone, the server or voice gateway, and the performance metric involved, you can take a look at the devices and network segments involved to determine whether a given problem is device or network related. Knowing which metrics are impacted can help you look in the right place from the outset. Lets take a look at each metric and discuss some procedures for troubleshooting.
Delay to Dial Tone
As we explained above, the delay to dial tone metric is associated with flows between the IP phone and its call server. With this in mind, we can immediately narrow our focus to either the network between the phone and call server, or to the call server itself. The following questions
44
www.netqos.com
can help you narrow the focus of troubleshooting efforts when delay to dial tone values are higher than normal: 1) Which phone or group of phones is affected? Is the problem isolated to a single user, to a few users, or is it more widespread? 2) Which call server is handling call setup processing for the affected phone(s)? 3) What does the network path between phone and call server include? 4) Has the network path changed recently? 5) What is the associated latency for each hop in the path? 6) Do the latency statistics point to a single hop as the source of the problem? 7) Is the call server so heavily loaded that it cant respond to requests in a timely manner? One rule of thumb that should serve as a starting point: With delay to dial tone performance issues, the network between phone and call server is the primary suspect.
Post-Dial Delay
A problem with post-dial delay can be more complicated than a delay to dial tone issue. The post-dial delay metric involves more interactions between phone, call server, gateway, and PSTN than the delay to dial tone metric. In addition, the post-dial delay problem may be on another network, the network where the called phone resides. Answer the following questions to begin isolating the problem: 1) Which phone or group of phones is affected? Is the problem isolated to a single user, to a few users, or is it more widespread? 2) Which call server is handling call setup processing for the affected phone(s)? 3) There are at least two potential problem networks for the post-dial delay metric. What is the composition of the expected network path between phone and call server? What is the composition of the network path between gateway and call server?
877.835.9575
45
4) Has either network path changed recently? Or could the call setup traffic be using an unexpected path? 5) What is the associated latency for each hop in the paths? Do the latency statistics point to a single hop as the source of the problem? 6) The call server or the voice gateway (or both) could be slow in responding due to resource utilization issues. Is the call server or gateway so heavily loaded that it cant respond to requests in a timely manner? 7) Is the dial plan configured correctly? 8) Are the affected calls using shared lines? Shared lines require setup flows to ring all phones that are sharing the line. 9) Does the call traverse an intercluster trunk? This type of call requires additional setup flows between call servers. Post-dial delay issues involve more components and networks than delay to dial tone issues do. To address user complaints about post-dial delay, you have to look at the entire call setup flow between phone, call server, and possibly gateway to determine the likely cause.
Call Setup Failures
A spike in failures of call setup could be linked to any number of components involved in processing the call. The reasons for a call setup failure could be as simple as the number dialed was not a valid phone number, or they could be more complex, as when a PSTN trunk is temporarily down. The following questions should put you on a path toward resolving the underlying issues: 1) What is the breakdown of the failure cause codes that are being returned? Does one particular cause code represent the majority of the call setup failures that are occurring? 2) Do the cause codes and their descriptions offer any clues? 3) What call servers and/or gateways are involved in the calls that are failing? 4) Are the failures always related to inbound calls? To outbound calls? Are the failed calls being made to a specific extension?
46
www.netqos.com
5) Are the failures related to calls into or out of a specific voice interface? What is the voice interface, and is the channel known? 6) Which phone or group of phones is affected? Is the problem isolated to a single user, to a few users, or is it more widespread? 7) Does the cause code point to a call server or gateway configuration problem? 8) Does the cause code point to a capacity issue? (For example, it may indicate that not enough channels are available for the call volume.) Call setup failures can be limited to a very specific area of the system, or they can be quite widespread. The failure code itself is the key piece of information to unraveling these types of problems.
Performance Incidents
Applying thresholds to the call setup metrics weve discussed in the previous sections is a good way to take a proactive approach to managing call setup performance. Multi-tier thresholds provide a way to alert the network manager when performance is deteriorating and before the problem becomes acute. By setting up good thresholds, you can be alerted to performance problems before getting complaints from irate users. But what are good thresholds? Are they industry-standard, or network-specific? Besides the GoS metric discussed earlier, is there an equivalent to a MOS for call setup? Because we are dealing with the likely user experience when we attempt to manage the performance of a VoIP system, the subject of thresholds will necessarily be a little subjective. However, earlier in this chapter we discussed the typical numbers expected from the PSTN and the ITU guidelines for call setup metrics. From these sources, we can come up with some best practice thresholds for call setup metrics. Figure 2-10 on the next page lists default thresholds for consideration.
877.835.9575
47
Figure 2-10 Guidelines for call setup performance thresholds.
For any type of call monitoring, look at a set of calls for a given time period - lets say 15 minutes. During this time period a number of calls are completed. Monitoring systems are notorious for generating tons of alerts, so you may want to filter some of the noise by choosing a reasonable value for the Minimum Calls Originated, a minimum number of calls that must be placed, or at least attempted, by phones in the monitored system before any alerts can be raised. In the threshold guidelines above we selected 5 calls originated as the minimum threshold. For a proactive monitoring solution, youd like to know if the metrics for the calls were rated Normal, Degraded, or Excessive. A performance incident or alert should include information to help you quickly identify the location of the problem. Information such as the phone location (network subnet) and call server or gateway that handled the call setup should be included. Network performance is variable, and the same factors that affect network latency and packet loss will likely affect VoIP call setup performance. As you configure thresholds and alerting for performance issues, consider the possibility that certain network locations are going to have worse call setup performance. For example, a group of Wi-Fi phones are likely to receive below-average call setup performance due to the higher latency in the wireless access network. For these phones, apply a set of threshold values that allow for routinely higher latency metrics at the specific wireless location. Otherwise, youll keep seeing the same alerts each time someone uses those phones to place a call.
48
www.netqos.com
Network Considerations
When addressing call setup performance problems, you certainly cant rule out general network issues. The network plays a key role in call setup performance, so bandwidth usage and QoS consistency are important parts of the network management equation that must be considered when troubleshooting VoIP call setup. Understanding these two items often requires network traffic analysis, with visibility into the composition and volume of network data flow. This type of analysis, best performed after maximum visibility into that data flow is achieved, is a critical component for a smooth and successful VoIP deployment and will help you far into the future as you plan for upgrades and the inevitable expansion of the VoIP system. NetFlow is an example of a data source that provides information needed to effectively manage call setup performance. NetFlow is built into most Cisco network routers and switches. Statistics are kept about the protocol bandwidth usage and QoS markings for call setup (and all other) flows. You can then use a third-party monitoring package to collect, parse, and report on the NetFlow data.
Bandwidth Usage
Once you have the required tools in place to help you analyze and understand the traffic thats flowing over your network links, you are better poised to avoid capacity and utilization issues that could potentially affect the VoIP system. We discussed the bandwidth usage associated with the most popular VoIP codecs in the previous chapter, but codecs handle VoIP conversation, not call setup, traffic. Do you have any idea how much bandwidth is used by call setup protocols? Do you understand the percentage of usage traceable to VoIP when compared to the mix of other protocols? These are good questions that can be answered by looking more closely at bandwidth consumption on your network. Figure 2-11 on the next page shows a breakdown of protocol bandwidth usage for a single router interface.
877.835.9575
49
Figure 2-11 Call setup protocol (SCCP) bandwidth usage on a particular interface.
In most cases, bandwidth usage should not be an issue for call setup protocols. Relative to the amount of bandwidth required for call traffic, the call setup bandwidth usage is minimal per call. The call setup packets are typically very small (100-500 bytes). As we stated earlier, some IP phones send keep-alive messages, but these packets are small and only sent periodically. Overall bandwidth consumption per call for setup is relatively low. However, in some environments, call setup might consume more bandwidth than you would expect. Consider the case of shared lines. A shared line is a phone number that is assigned to multiple physical phones. If the number is called, then all the phones that are sharing the line ring simultaneously. When a shared line is called, the call server must send setup flows to every phone in that shares the line. If you have several shared lines over a slower speed WAN link, this can lead to additional flows and more bandwidth consumption than you might expect. Another scenario where bandwidth visibility is important is for calls over intercluster trunks. In this case there may be hundreds or thousands of call setups traversing the intercluster trunk link. Bandwidth usage could fluctuate greatly. Knowing how much bandwidth is used for these setups and being able to alert on rapid increases or degradations is important for call setup performance management.
50
www.netqos.com
In a Cisco environment, you can use the visibility provided by NetFlow to determine the mix of protocols and their bandwidth usage on particular links. You may find that call setup traffic is using more bandwidth or is going over an interface that you didnt expect.
QoS Mismatch
QoS consistency for call setup packets is another item that can be determined via NetFlow analysis. IP phones and gateways will mark each packet with the desired QoS setting (e.g., CS3). As the packet traverses the network, routers along the way may alter the marking of the packets. This is particularly true of MPLS networks, where a packet entering a carrier network with one type of QoS marking may leave the network with a different QoS marking. QoS is only as good as its weakest link, and the configuration of any router can impact the prioritization that the packet receives along the network path. VoIP packets are relatively small, and call setup packets may be tiny, making them likely candidates for queuing behind larger application packets if they dont have the correct prioritization bit settings. NetFlow information can be used to show the breakdown of QoS packet markings for packets passing through a router interface. The TOS byte in the IP header contains the QoS marking. This byte is also known as the DiffServ Code Point (DSCP). The bits within the DSCP byte represent different QoS levels. The value of the byte is usually included in common DiffServ naming conventions. For example, a value of 24 in the TOS byte field would be known as DSCP24. Using the TOS byte values from NetFlow, a breakdown of the different QoS values can be reported. Figure 2-12 on the next page illustrates this concept.
877.835.9575
51
Figure 2-12 Use QoS marking information to look for mismatches.
In addition to bandwidth allocation and QoS configuration, the manner in which you deploy phones, gateways, and call servers can also greatly impact the performance. Lets discuss some of the deployment models and considerations.
Network Deployment Considerations
A number of different network deployment models are valid for a VoIP system and can deliver excellent performance. But whenever possible, its best to plan carefully and select optimal placement for critical components. For example, the locations of the IP phones with respect to the call servers, and of the call servers with respect to the voice gateways, can easily have an impact on call setup performance.
52
www.netqos.com
A common enterprise deployment model is multiple sites with centralized call processing. Call servers are centralized and phones may be local or remote. For the case where phones are located in remote or branch offices, the call setup packets may have to traverse the WAN. Many enterprises are moving to MPLS networks which can provide QoS mechanisms for the VoIP traffic. When planning the network aspect of a VoIP deployment, you can use the further away principle when considering phone, call server and gateway location. Translated to network terminology further away means more network hops. This principle states:
The further away a phone or voice gateway is from its call server, the more likely you are to encounter call setup performance issues.
As you add network hops between the phone and call server or call server and gateway, you inevitably introduce additional latency. Processing at each device along the way adds up and dont forget the propagation delay which is related directly to the physical distance that the packets must travel: they cant go faster than the speed of light. Some network scenarios that have the most potential for call setup performance issues: hones or gateways located at the end of slow-speed links or links with high latency. P wireless phone accessing the network via high-latency wireless network. A hones or gateways with a WAN link (or links) connection to the call server. P hones that fail over or load balance to a different call server across a lengthy network path. P hones that must traverse a carrier network (that you dont own) to get to the call server. P eographically distributed call server clusters. G ateways located in different datacenter from where the call server is located. G Good network design principles are critical for ensuring optimal call setup performance. Include QoS early, or you will have to add it at a later date when it might not be as easy.
877.835.9575
53
WAN Optimization
Many enterprises are centralizing data center resources. As this occurs, a relatively new technique known as WAN optimization is being used to improve performance of critical customer applications and remote locations. WAN optimization is an umbrella term for many different techniques, including: TCP optimization, application protocol optimization, and data caching. The goal is to reduce network flows in an effort to decrease application latency and provide more available bandwidth. Should you consider using WAN optimization techniques with VoIP in an attempt to improve call setup performance? Lets discuss the key points: AN optimization would not help UDP based call setup protocols. Most WAN W Optimization technology is focused on TCP applications. This would eliminate MGCP, and, in some cases SIP from consideration, but for other TCP based call setup protocols like SCCP, there are other issues. AN optimization techniques do not work well with protocols that have small packet sizes. W A quick test with a call using SCCP shows that 80% of the packets are less than 127 bytes and 97% of the packets are less than 255 bytes. AN optimization data caching techniques would not help call setup protocols. Data W caching is used for cases where large amounts of the same data are frequently requested by client applications on the WAN side. Call setup protocols do not send large amounts of data and frequent keep-alive messages are needed for the protocol to have awareness of the phone or call server connectivity. It is likely that WAN optimization techniques would have a negative direct impact on call setup performance - if an attempt was made to optimize the call setup protocols. However, this doesnt mean that WAN optimization could not offer indirect help. By using WAN optimization techniques, other application traffic could be reduced. This would effectively provide more bandwidth and less contention for the VoIP call setup traffic thus improving the overall performance for the call setup traffic.
54
www.netqos.com
Chapter Summary
In this chapter, weve discussed the concepts that are important for ensuring optimal call setup performance. Why should you be concerned about call setup performance? The reason is that the users first perception of the availability of a phone system is typically based on the call setup performance. In order to understand this aspect of user experience, you need some additional metrics beyond those used for traditional networked applications, metrics such as: elay to dial tone D ost-dial delay P all setup failures C Once you have the call setup performance optimized, the next area of focus should be on call quality performance. Good or bad call quality goes a long way toward shaping user perceptions of a VoIP system. Here are some questions to consider when it comes to call quality: hat is the key quality of experience metric, and how is it measured? W ow do quality of experience metrics like MOS relate to the traditional network H QoS for each call? hat are the considerations for call quality when calls traverse the WAN? W hat are the considerations for call quality when calls go through a voice gateway to the PSTN? W In the next chapter of this book, well examine these questions and find out how they are related to VoIP call quality performance.
References
1. Eyers, Tony, and Henning Schulzrinne. Predicting Internet Telephony Call Setup Delay. 1999. http://www.cs.columbia.edu/~hgs/papers/Eyer0004_Predicting.pdf 2. Cisco Systems, Inc. Cisco Unified CallManager Call Detail Record Definitions (for Cisco Unified CallManager version 5.0). http://www.cisco.com/en/US/products/sw/voicesw/ps556/
products_programming_usage_guide09186a00806c22b5.html#wp144513
877.835.9575
55
Chapter 3
VoIP Call Quality Performance
Once a call is connected successfully, you can begin an interactive conversation. Just as the speed of call setup affected your opinion of VoIP system performance, the audio quality of the conversation plays a key role in your perception of the overall user experience for the call. In the past, some phone companies advertised the fact that the quality of their calls was superior to that of other companies. But the differences among them were actually quite minor; in fact, weve become accustomed to the very high level of quality achieved through decades of innovation in the PSTN. The PSTN took advantage of the fact that once a call was connected, the resources needed for that call were reserved for the duration of the conversation. In the world of VoIP, as calls are added to an IP-based network, the necessary resources are most often shared by all network users. Quality cannot be guaranteed and must be carefully managed from the network performance perspective to provide a high level of network quality of service (QoS). The rise of the cellular or mobile phone has somewhat prepared us for sub-PSTN call quality, but the reduced quality associated with cell phones comes with the significant advantage of mobility. For business communications, reduced call quality can have a direct impact on the bottom line. If you cant talk to your business partners and customers, revenue will likely suffer. As more workers become mobile and need the capability of high-quality business communications wherever they may be, a new premium is being placed on VoIP call quality. The quality of experience that you and your users have with the phone system is closely related to the perceived quality of each call. Call quality is not a completely objective measurement, and thus it is important to understand some of the different standards for voice quality and the methods used to evaluate it.
56
www.netqos.com
Call Quality Standards

Call quality has always been a somewhat subjective measurement. You can ask a group of volunteers to listen to the quality of the voice signal during a call and rate it based on the same set of criteria, but everyones opinion is slightly different. That being said, standards are in place to provide highly accurate predictions of user opinions of call quality. The industry standard for subjective measurement of voice quality is the mean opinion score, or MOS. The MOS is defined in the International Telecommunications Union (ITU) recommendation P.800.
MOS
The mean opinion score is just what the name implies: its a score derived from users opinions. A sentence is read aloud over the telephone to a number of listeners. (For example, a commonly used sentence for this type of testing is You will have to be very quiet.) After hearing the sentence, the listeners score the conversation based on their opinion of how it sounded. The scores are averaged to come up with the mean opinion score. After years of testing, the ITU used data from listener opinions to codify a scoring standard. The MOS can range on a scale from 5 to 1, with 5 being the best and 1 being the worst rating. Table 3-1 shows the MOS values and associated quality rating. MOS
5 4 3 2 1
Quality Rating
Excellent Good Fair Poor Bad
Listening Effort
No effort required No appreciable effort required Moderate effort required Considerable effort required No meaning understood with any feasible effort
Table 3-1 Mean Opinion Score Scale (from ITU P.800 specification).
877.835.9575
57
MOS is the de facto standard for call quality and provides a good, high-level comparison for the quality among different phone calls. A MOS value of 4 or higher is generally considered toll quality, or equivalent to typical PSTN quality. As you can imagine, this approach is pretty difficult to sustain for an ongoing VoIP monitoring and management system; you cant add a team of call-quality evaluators to your payroll and allow them to listen in on phone conversations to provide quality ratings. However, a large amount of research has been done to correlate how people rate calls in the presence of common network impairments like latency and packet loss. Using this information, other standards have evolved that can take impairment information and map it to a MOS. Different types of MOS are currently being used to rate call quality, depending on the factors that are included in the measurement. The most commonly referenced type of MOS is listening quality (MOS-LQ). Another type of MOS that you may encounter is conversational quality (MOS-CQ). The main difference is that MOS-LQ does not account for factors that can affect the conversational (or two-way) nature of the call, such as latency. MOS-LQ focuses on the quality from the perspective of the listener and only takes into account the loss impairments, like network packet loss and jitter buffer loss. Lets take a look at some of the other standards that can provide call quality mapped to MOS.
PESQ
The Perceptual Evaluation of Speech Quality (PESQ) is a method that involves active testing to determine call quality. Defined in the ITU P.862 standard, PESQ is the successor to some older quality standards known as PSQM and PAMS. Using PESQ, a reference signal is played through the system, and the received version is compared to the original reference version. Any degradation that occurred is measured, and a quality score is computed. The resulting score is often mapped to a MOS-LQ value. Because PESQ is an active, or intrusive, monitoring approach, it may not be ideal for networks that are already near capacity.
58
www.netqos.com
E-Model
The E-Model is defined in ITU recommendation G.107. The E-Model is useful for VoIP call quality measurement and monitoring because it takes into account a whole range of specific data-network impairments, like packet loss and latency. The E-Model was developed by performing many subjective MOS tests with different codecs and varying degrees of network impairments. The E-Model takes the information about codec, packet loss, and latency and derives an R-value. The R-value can be mapped to a MOS. The E-Model begins the calculation with a theoretical reference R-value that is free from any impairment. The associated impairments are then subtracted from the reference value to derive the perceived quality value. Table 3-2 shows how the E-Model provides a mapping of R-values and MOS to user satisfaction.
User Satisfaction
Very satisfied Satisfied Some users dissatisfied Many users dissatisfied Nearly all users dissatisfied
R-value
90 80 70 60 50
MOS
4.34 4.03 3.60 3.10 2.58
Table 3-2 Relationship between User Satisfaction, R-value, and MOS (from ITU G.107).
The E-Model was originally designed for network planning exercises and provides a good way to estimate call quality as it is affected by underlying network impairments.
877.835.9575
59
P.VTQ
The ITU P.VTQ standard defines an endpoint MOS algorithm based on PESQ. A passive type of monitoring approach, P.VTQ looks at the call quality of real phone calls as they progress, and is usually implemented in the IP phone or gateway. The P.VTQ standard defines a quality value called the K-factor. Like the R-value, the K-factor is mapped to the MOS. More precisely, the K-factor is a MOS-LQ value because it includes impairments such as packet loss and jitter discards, but it does not include delay-related impairments. The K-factor is usually calculated over 8-second samples of the audio for a given call. IP phones and gateways from Cisco Systems implement the P.VTQ standard as a means of calculating a MOS for VoIP phone calls. At the end of a call, the phones and gateways can provide the quality information for that call. Our discussion of the standards used to calculate call quality mentioned several network-related factors that can impair that quality and lower the quality score, however it is calculated. Now lets look at some of the key call quality metrics in greater detail and discuss how they can impact call quality.
Key Call Quality Metrics

Just as with any network application, the underlying network performance will have a direct effect on user perceptions of call quality. Metrics like transaction time and network round-trip time are often used to measure TCP application performance and can be helpful when you need to tune network components. However, these metrics are not directly related to call quality. A more VoIP-specific focus is required when tuning the network to carry high-quality phone calls. As a result, IP telephony experts instead rely on several metrics that relate directly to call quality to help them measure the likely user experience when interacting with the VoIP system. Lets discuss these key metrics individually.
60
www.netqos.com
Latency
The time it takes for a VoIP packet to travel from the speaker to the listener is called the delay, or latency, of the system. VoIP traffic is extremely sensitive to latency. The ITU G.114 standard includes research showing that 150 ms of one-way latency is the point where call quality begins to degrade. Delays greater than 150 ms can make conversing difficult and result in a degraded user experience. Latency is something that needs to be accounted for end-to-endfrom the speakers mouth to the listeners ear. Often, the round-trip delay in the network is used and divided by 2 to get a one-way latency value. As a VoIP packet traverses the network, latency can be introduced in a number of different ways:
Packetization The time it takes for a codec to encode and decode a packet for transmission or
reception.
Queuing The time spent in router queues along the path through the network. The more congestion, the greater the queuing delay. Serialization The time it takes to put a packet on a network link interface. This value increases as the packet size increases and as the link speed decreases. Propagation The time it takes to travel from one point to another in the network. This time is a fixed value thats directly related to geographical distance. A good rule of thumb is 10 microseconds per mile. Jitter buffer Each VoIP phone and each voice gateway provides a jitter buffer to smooth out
the effects of network jitter, or variations in delay among packets in the same stream. This buffer adds delay as the packet is held for playout. Most of the components introducing delay for a given VoIP call are not related to bandwidth. The one exception is the queuing delay, which could be alleviated by extra bandwidth. So if you have a call performance problem due to delay, additional bandwidth probably wont fix the problem. Well discuss what types of quality issues bandwidth can help and what types of issues that bandwidth does not help, later on in this chapter. Figure 3-1 on the next page shows the components and areas of the network where latency can be introduced.
877.835.9575
61
Figure 3-1 Latency can be introduced at a number of different locations in the network.
Latency is a key component of conversational quality because the higher the latency, the more difficulty you have determining whose turn it is to speak. If both parties in a phone call begin to speak at the same time, not only will you not be able to hear everything the other person is saying, but you also may start to feel that you are talking on walkie-talkies and need some protocol to allow for a party to start and stop talking (Over and Out). As the latency increases, the likelihood of encountering other quality impairments like echo increases as well. Echo is often present in PSTN phone calls, but due to low latency, it is usually inaudible. In a VoIP network, higher latency values can reveal this normally dormant impairment. Well discuss it again below, when we introduce the ACOM metric.
62
www.netqos.com
Packet Loss
VoIP packets are sent using RTP, so they dont get retransmitted if they are lost. The impact of lost packets varies depending on the number of packets lost and the manner in which they are lost. Packet loss is another key network performance metric that affects the call quality. There are two types of packet loss:
Network packet loss
The receiver did not receive the packet because it was discarded somewhere between sender and receiver. Network packet loss has numerous causes, but the two most common are: Network congestion: Anytime there is too much traffic on a link or queue, a router must make the decision to discard some of the packets. Packets are dropped by the router according to a variety of different QoS mechanisms. Network errors: Link errors caused by physical media can lead to packet loss. If a packet is corrupted and cant be reconstructed after transmission, it will be discarded and thus lost. Duplex errors between network cards and switches is a leading cause of packet loss.
Jitter buffer loss
The receiver received the packet, but it was too early or too late to be accommodated by the jitter buffer and was therefore discarded. Concealment issues are also created when packets are lost, either through the network or by the jitter buffer. When a packet is either not received by or is discarded by the phone, many codecs use concealment algorithms to try to preserve as much of the call quality as they can. These concealment algorithms range from simple just play the last known audio sample to complex try to interpolate what the next audio sample might be. The goal is to conceal the lost packet. The resulting audio doesnt always sound better, however. Packet loss occurs in different profiles. Random loss occurs when a packet is occasionally dropped, either by the network or jitter buffer. This loss pattern can impair the call quality, but in most cases, it is not very noticeable. By contrast, a more detrimental type of packet loss is bursty packet loss. This loss pattern describes what happens when a number of consecutive
877.835.9575
63
packets are lost in bursts. Because the packets are carrying audio information, bursty loss can cause entire syllables or words to be missing from the conversation. The impact of packet loss on the call quality is also determined to some extent by the codec. The codec defines the packet size that is transmitted and fills the packet with audio samples. As we mentioned in a previous chapter, packet sizes range from 20 bytes for the G.729 codec up to 240 bytes for the G.711 codec. Larger packets typically contain more audio information; thus, their loss has a greater impact on quality. In addition, codecs may compress the audio information to fit more data into each packet. If a high compression setting is used, losing a packet can result in the loss of more audio information. Codecs are making steady improvements in handling packet loss. Newer codecs, such as Microsofts RTAudio, can operate with good quality in Internet-type conditions where packet loss may be 10% or higher.
Jitter
Jitter, often referred to as delay variation, is a measure of the differences in arrival times among all VoIP packets sent during a call. When a phone sends a VoIP packet, it sets the timestamp value in the RTP header. When the packet is received, the receiver generates a timestamp and compares it with the senders timestamp. The timestamps are used to calculate the packets delay variation or jitter value, which can then be reported by the IP phone or by other monitoring equipment. Too much jitter can cause packets to arrive too early or too late to be processed by the jitter buffer. When this happens, the phone discards the packets a form of packet loss. IP phones send data packets at constant rate. The time between packets depends on the codec. For example, G.711 typically sends a data packet every 20 milliseconds. You can think of this process as similar to loading a truck. The truck waits 20 ms for the packet to fill up with audio information and then departs for the destination. The codec outputs the packets to the network at constant intervals, with no variation. Figure 3-2 shows how the network can affect packet arrival times and create jitter.
64
www.netqos.com
Figure 3-2 Variable delays in the network creates jitter.
To reduce the impact of jitter, the receiver employs a jitter buffer to receive the incoming packets. You may have seen audio or video applications that report that they are buffering data for playback. They are actually buffering data in a jitter buffer. Most jitter buffers in IP phones and voice gateways hold at least two VoIP packets. They are adaptive and can adjust, becoming larger or smaller depending on network conditions. As packets are received, they are placed in the jitter buffer, which holds them in order to supply a constant stream of packets to the receiving codec. The jitter buffer may have to account for early- or late-arriving packets and may have to re-order any packets that arrive out of order. Packets that dont fit into the jitter buffer are discarded, resulting in packet loss. So, why not just make the jitter buffer large enough to handle all possible variations? The reason is that every millisecond increase to the jitter buffer results in a millisecond of additional latency for the VoIP packet. Jitter buffer delay must be factored into the overall latency budget for VoIP.
877.835.9575
65
Combined Echo Return Loss (ACOM)
An impairment to call quality that almost everyone has encountered at some point is echo. Its very distracting to hear your words, or those of the person you are talking with, repeated. Echo is a function of delay. When the delay is less than 25 ms, echo is not perceptible to the human ear. This is usually the case in the PSTN, with its dedicated circuits. However, in VoIP environments, delay is often greater: up to 150 ms, which is a good limit in a well-designed system. With additional delays and PSTN connections through voice gateways, the likelihood of hearing echo on VoIP calls increases. For this reason, voice gateways include echo cancellation components to help reduce, or cancel, the echo on VoIP calls to the PSTN. Echo cancellation works by comparing the signal pattern entering the PSTN tail circuit with the signal pattern that returns. Variations in echo strength and the time period during which the echo canceller looks for the echo can affect the efficiency of the cancellation process. Theres not a specific metric that tells you how much echo is present in a call. However, some VoIP monitoring equipment can report a metric that gives you a sense for how well echo cancellation is working: the standard known as Combined Echo Return Loss, or ACOM. ACOM is defined in the ITU G.168 standard and measured in decibels (dB). It represents the combined echo return loss through the system the attenuation of echo from all possible means (Echo Return Loss (ERL) + Echo Return Loss Enhancement (ERLE)). ACOM is measured on the IP side of the echo cancellation device and includes all sources of echo loss, providing a good gauge of the remaining echo strength. Figure 3-3 shows the measurement of ACOM in relation to the voice gateway, PSTN, and echo canceller.
66
www.netqos.com
Figure 3-3 Echo measurement and echo cancellation.
Since ACOM measures the loss volume between the original signal and the echo, you want the ACOM values for voice gateway calls to be high. In other words, the greater the ACOM value, the lower the level of echo. For example, an ACOM value of 45 dB means that the echo heard is 45 dB lower than the original conversation sounds. ACOM values of 15 dB or higher are usually considered good. If the ACOM drops below 6 dB, the echo canceller usually cannot suppress the echo. ACOM is measured within the voice gateway and does not apply to phone calls directly between two IP phones. In the previous sections, weve introduced some of the key call quality metrics:
MOS The de facto standard for call quality. Latency The delay of packets between talker and listener. Packet Loss Packets that are lost in the network. Jitter Buffer Loss Packets that are received by the listener, but that arrive too early or late for the
jitter buffer to handle, and are therefore discarded.
ACOM The combined echo return loss, which gives an indication of the effectiveness of echo cancellation.
Now lets consider an approach to troubleshooting call quality performance issues that uses these metrics in the process.
877.835.9575
67
Troubleshooting Call Quality Performance

Just as with any network or application performance issue, identifying the problem is the first step in tackling a call quality issue. Looking in the right place is a good second step. Now that you understand the key VoIP call-quality metrics, you can begin to identify the problem by finding out which call quality performance metric is impacted. You have a couple of options for gaining the required visibility into call quality metrics. One method is to simulate phone calls and measure the results. This is the general approach taken by the Cisco IP SLA function that is a part of almost all Cisco routing and switching devices. This approach actively generates RTP packets and sends them through the network. The receiving router or switch calculates call quality metrics for the simulated call. Another way to identify potential call quality problems is by deploying a hardware or software monitoring tool to passively monitor the call quality metrics reported by your phones as users make real calls, and receiving notifications when the call-quality metrics signal trouble. Both approaches provide value to a proactive management solution. The rest of our discussion of troubleshooting is going to assume that you are using a performance management and monitoring tool. A good hardware- or software-based monitoring system is essential if you want to provide high-quality VoIP to your network users. And then you need to develop a smart approach to configuring and using your monitoring tool. VoIP call quality issues are most likely to occur in two areas of the network: alls that are traversing a WAN link or links C alls to the PSTN through a voice gateway C Paying close attention to these areas can help you troubleshoot call quality issues as they arise. When you are monitoring call-quality metrics, you need to be able to quickly see which users are affected and which metrics are showing the impact of the underlying problem. A good troubleshooting process must therefore include a step-by-step approach to isolating the problem. Figure 3-4 outlines a troubleshooting process for call-quality performance issues.
68
www.netqos.com
Which phone or group of phones is affected?
Is the problem isolated to a single (or few) users, or is it more widespread? Is the problem related to calls going through a gateway? MOS Latency ACOM
Identify Impacted Metrics
Packet Loss Jitter Buffer Loss Which network path is affected?
Identify Affected Network Path
What are key network elements in the affected path? Is the problem bi-directional, or one-way?
Figure 3-4 Step-by-step call quality problem identification.
Once you know the affected users or phones, performance metric, and the network path involved, you can take a look at the devices and network segments to determine whether a given problem is device- or network-related. Knowing which metrics are affected can help you look in the right place from the outset. In the sections to follow, well outline an approach to identifying call quality issues that will put you well on your way toward resolving them.
Performance Incidents
Applying thresholds to the call quality metrics weve discussed in the previous sections is a good way to take a proactive approach to managing call quality performance. Multi-tier thresholds provide a way to alert the network manager when performance is deteriorating, before the problem becomes acute. By setting up good thresholds, you can be alerted to performance problems before you get complaints from irate users. But what are good threshold settings? Are they industry-standard, or network-specific?
877.835.9575
69
Most VoIP systems would benefit from a combination of standard threshold values and values specifically tailored to unique network conditions. On a busy network, where potentially thousands of calls could be running simultaneously, your monitoring tool needs a mechanism for avoiding duplicate notifications in response to degraded call performance. And you need the flexibility of granular thresholds that alert you to changes in all the key metrics that affect call quality. Since the MOS is the widely accepted standard for call quality measurement, you should consider setting thresholds to alert you to degraded MOS values. In addition, the underlying performance metrics like latency, packet loss, jitter buffer loss, and ACOM have either standards-based thresholds or generally accepted best-practices thresholds. Because we are dealing with the likely user experience when we attempt to manage the performance of a VoIP system, the subject of thresholds will necessarily be a little subjective. However, industry guidelines are in place and offer a starting point. For example, we discussed earlier the ITU G.107 mapping of user satisfaction to MOS. From this standard, good thresholds can be derived that help alert you when user satisfaction with the call quality is most likely declining. Figure 3-5 lists default thresholds derived from industry standards and best practices.
Figure 3-5 Guidelines for call quality performance thresholds.
For any type of call monitoring, look at a set of calls for a given time period15 minutes, for example. During this time period, a number of calls are completed. Monitoring systems are notorious for generating tons of alerts, so you may want to filter some of the noise by choosing a reasonable value for a minimum number of call minutes that must be completed by phones in the monitored system before any alerts can be raised (see the Minimum Call Minutes column in the above image). In the threshold guidelines shown above, we selected 15 call minutes as the minimum threshold.
70
www.netqos.com
For a proactive monitoring solution, youd like to know if the metrics for the calls were rated Normal, Degraded, or Excessive. These can be color coded Normal=Green, Degraded=Yellow, and Excessive=Orange, to help easily spot performance degradations. A performance incident or alert should include information to help you quickly identify the location of the problem. Information such as the phone location (network subnet) and the call server or gateway that handled the call setup should be included. Network performance is variable, and the same factors that affect network latency, packet loss, and jitter will affect VoIP call quality performance. As you configure thresholds and alerting for performance issues, consider the possibility that certain network locations may consistently have worse call quality performance. For example, a group of phones in a remote location at the other end of a slow-speed WAN link is likely to receive below-average call quality performance due to the higher latency in the WAN. For these phones, apply a set of threshold values that allow for routinely higher latency metrics at the specific remote location. Otherwise, youll keep seeing the same alerts each time someone uses those phones to place a call. Once you have good metric thresholds defined, then you can begin the process of analyzing call quality metrics and take a proactive approach to troubleshooting.
The first step in troubleshooting a VoIP call-quality issue is to identify phones and users that are experiencing degraded call quality performance. This identification process is made easier by mapping the network and organizing subnets into groups and using those groups to configure reporting options in your VoIP monitoring tool. Grouping phones that are expected to achieve similar performance into distinct locations is a good first step. A VoIP location definition might contain a subnet or group of subnets. Phones within those subnets would be grouped for reporting purposes based on the VoIP equipment and links that they all access. They might all access the same call server, for example. Looking at the measured quality of calls to and from the locations in your organization will allow you to spot potential quality problems and assess their impact. For example, you need to know whether the problem is widespread, across multiple network locations, or whether it is confined to one or two locations.
877.835.9575
71
Figure 3-6 shows a report from our VoIP monitoring system. It contains a listing of locations where calls were made, with three locations that are experiencing quality issues during the last day (indicated on the graph, where the quality was rated as Excessive).
Figure 3-6 View of call performance for each location in the enterprise.
From this type of report, organized by network location, you can quickly spot the places that need further investigation. To determine whether the problem within a location is widespread or isolated to particular phones or users, you also need information about the calls that are occurring within that location. Reporting quality information on a per-call basis, can help you spot problems that may be isolated to individual users or phones. The next troubleshooting step to take is to identify the call-quality metrics that are showing signs of performance degradation.
Identify the Affected Metrics
Above, we discussed the key metrics that directly impact VoIP call quality. After determining the network locations that are experiencing quality issues, we need to identify the specific metrics that are affectedthe ones that contributed to the Excessive call quality ratings. In the above example, the locations Austin-1, Raleigh, and Chicago were reported to be experiencing some call quality issues. As a logical next step, we would like to drill down to the Austin-1 location and see the call quality metrics for calls to/from this location. Figure 3-7 shows an example of the performance ratings for calls to and from the Austin location.
72
www.netqos.com
Figure 3-7 Identify the call quality metrics that are contributing to degraded user experience.
The MOS metric is rated as Excessive, which is indicated on the graph. Looking at the other metrics, we see that the Packet Loss performance metric is also rated as Excessive and is likely the contributing factor to the low MOS. The other metrics, Jitter Buffer Loss and Latency, are normal, as indicated on the graph. To further aid your troubleshooting, its important to take a look at the actual metric values for the time period when the call quality issue occurred. Looking at the metric values can help you understand the specifics of a given time period: Is the packet loss 1% or 5%? Is the latency 10 ms or 100 ms? In addition, the metric value details can point out times where the MOS declined due to other contributing performance metrics. So far, the approach weve taken for troubleshooting call quality issues has allowed us to determine that we have a call quality issue in a particular network location. We know the metric or metrics that were degraded, the actual values of the metrics during the time period in question, and any correlation between the metric values, such as which performance metric lowered the MOS value. The next step is to identify the network path or paths that were carrying the calls affected by the underlying problem that caused the quality issue.
Identify Affected Network Path(s)
As we pointed out in a previous chapter, each VoIP call consists of two media streams that do not have to traverse the network over the same path. In the example above, users in the Austin-1 location were experiencing degraded MOS values caused by packet loss. If we look at the RTP media streams
877.835.9575
73
that were received by phones in the Austin-I location, we can see which location has been sending the data that was lost. Figure 3-8 shows an example of the Austin-1 location and performance ratings for all other locations that were parties to calls with phones at Austin-1. In the following chart, we can see that the Raleigh location is the only other location that was impacted.
Figure 3-8 Identify the affected network path(s).
We have now determined that the affected network path is Raleigh Y Austin. Calls between our Raleigh and Austin-1 locations are experiencing significant packet loss somewhere along this path. The network path provides useful information in troubleshooting call quality issues because a device or link in that network path is probably causing the problem. Using other network performance data sources, such as NetFlow, SNMP, and IP SLA, can help further pinpoint the root cause of the packet loss in this scenario. A consolidated view of network performance information is a useful part of a proactive call quality management strategy. However, there are times when the overall network performance looks good, and the call quality problem is isolated to a specific call or phone. In these cases, there is another layer of detailed information that can be helpful for troubleshooting.
Troubleshooting Information for Specific Calls
A call quality problem with a single phone or user may be more difficult to troubleshoot than an issue that is affecting an entire network location. For any VoIP call, data will be sent in two RTP streams between the IP phones or between an IP phone and a gateway. In these cases, you need as much information about the two sides involved (the phone or the gateway) and more granular quality information quality metrics while the call is in progress. Getting this level of quality
74
www.netqos.com
information for every single call in your enterprise will likely result in data overload youll have so much data that you wont be able to make sense of it. But for specific cases, this type of visibility is invaluable to getting to the core of the problem.
IP Phone and Gateway Information
IP phone and voice gateway information (both configuration and runtime) can be very useful when debugging call quality problems for specific calls. Table 3-3 lists the information for IP phones that you should collect. Phone Information Comment
Name Phone Number IP Address Port Location Model Call Server Codec Firmware Version Serial Number Switch IP Address The unique name for the phone. Often this name may include the phone hardware or MAC address. The directory number or phone number for this phone. The IP address for this phone. The UDP port number used for the RTP stream. Useful information for firewall traversal issues. The network location for this phone. May be a name given to a subnet or group of subnets. The model or type of phone. All phone models are not created equal. Some have more features, some have less features. The call server the phone is registered with. The codec used for the call. Useful for troubleshooting issues where different codecs are used for the same call. The version of firmware running on the phone. Newer versions of firmware may have bug fixes that you need. The serial number for the phone. Useful for inventory tracking purposes. The management IP address of the network switch that the phone is connected to. Knowing the switch that the phone is connected to is useful for troubleshooting issues like duplex mismatch, power-overEthernet problems, and VLAN configuration. The DNS name for the switch where the phone is connected. The switch port where the phone is connected. Useful for troubleshooting port specific issues.
Switch Name Switch Port
Table 3-3 Useful phone information for troubleshooting.
877.835.9575
75
Likewise, for calls that go through a voice gateway (coming from the PSTN to the IP network, or the reverse), information for the gateway and the individual voice interface on that gateway is very useful for troubleshooting purposes. Table 3-4 lists the gateway information that you should collect. Voice Gateway Information
Name Phone Number IP Address Call Server Codec Voice Interface
Comment
The DNS name for the gateway. The calling or called PSTN phone number. The IP address for this gateway. The call server which the gateway is communicating with for call setup purposes. The codec used for the call. Useful for troubleshooting issues where different codecs are used for the same call. The interface that the call is using to connect to the PSTN. Often this will be the PRI, with information about the slot, subunit, and port used for the call. Useful for troubleshooting problems with connections to a particular carrier. The channel the call is using to connect to the PSTN. Useful for troubleshooting problems with a specific interface channel.
Voice Channel
Table 3-4 Useful phone information for troubleshooting.
The gateway provides a number of voice interfaces and channels for connection to the PSTN. Different interfaces may be connected to different carriers or providers. The interfaces may be plugged into different hardware slots and subunits within the gateway. Understanding which call used which interface can be useful for debugging, even if your only role in this part of the process is calling the equipment vendor or service provider and outlining the issues.
Transient Quality Issues
Some call quality issues can be very transient and difficult to track down. A faulty switch port that doesnt negotiate parameters correctly with the phone network interface card can lead to
76
www.netqos.com
sporadic packet loss. For these types of quality issues, monitoring the call quality metric values as the call is in progress is important. If you are monitoring the metrics while the end user is still on the phone, you can see variations over time as network conditions change. Correlating this performance information with metrics from other network performance data sources can provide insight into the root cause of a call-quality problem. An important aspect of any call quality troubleshooting process is taking a look at the familiar network factors, like bandwidth, protocol usage, QoS, and WAN optimization, all of which affect the performance of all your network applications along with VoIP. Lets discuss a VoIPspecific approach to these ever-present threats to optimal performance.
Network Considerations
When addressing call quality performance problems, you certainly cant rule out general network issues. The network plays a key role in call quality performance, so bandwidth usage and QoS consistency are important parts of the network management equation that must be considered when troubleshooting VoIP call quality. Understanding these two items requires network traffic analysis, with visibility into the composition and volume of network data flow. This type of analysis, best performed after maximum visibility into that data flow is achieved, is a critical component for a smooth and successful VoIP deployment and will help you far into the future as you plan for upgrades and the inevitable expansion of the VoIP system. NetFlow is an example of a data source that provides information needed to effectively manage call quality performance. NetFlow is built into most Cisco network routers and switches. Statistics are kept about the protocol bandwidth usage and QoS markings for voice call traffic (and all other) flows. You can then use a third-party monitoring package to collect, parse, and report on the NetFlow data. The NetFlow reporting package will nicely supplement VoIP-specific monitoring and management tools.
Bandwidth Usage
Once you have the required tools in place to help you analyze and understand the traffic thats flowing over your network links, you are better poised to avoid capacity and utilization issues that could potentially affect the VoIP system. We discussed the bandwidth usage associated with
877.835.9575
77
the most popular VoIP codecs in the first chapter. Do you have any idea how much bandwidth is consumed by VoIP calls on key WAN links? Do you understand the percentage of usage traceable to VoIP when compared to the mix of other application traffic? These are good questions that can be answered by looking more closely at bandwidth consumption on your network. Figure 3-9 shows a breakdown of protocol bandwidth usage for a single router interface. This report was taken from a NetFlow reporting tool.
Figure 3-9 Voice traffic bandwidth usage on a particular interface.
Bandwidth consumption for VoIP traffic can be deceptive. Protocol headers add overhead, and two bi-directional streams are required per call. On the example network being monitored for the above report, voice traffic was 89.03% of the protocol mix for a particular router interface. If call traffic had grown heavier, the link might have become overburdened, resulting in packet discards. In a Cisco environment, you can use the visibility provided by NetFlow to determine the typical mix of protocols and their bandwidth usage on particular links in your network. You may find that VoIP call traffic is using more bandwidth than you had allocated for it in your planning, or that it is going over an interface that you didnt expect.
78
www.netqos.com
QoS Mismatch
QoS consistency for call packets is another item that can be determined via NetFlow analysis. Good VoIP call quality requires QoS mechanisms to prioritize the voice traffic and provide low-latency queuing. IP phones and gateways will mark each packet sent with the desired QoS setting. The TOS byte in the IP header is commonly used to contain the priority information. As the packet traverses the network, routers along the way may alter the marking of the packets. This is particularly true of MPLS networks, where a packet entering a carrier network with one type of QoS marking may leave the network with a different QoS marking. QoS is only as good as its weakest link, and the configuration of any router can impact the prioritization that the packet receives along the network path. VoIP packets are relatively small, making them likely candidates for queuing behind larger application packets if they dont have the correct prioritization bit settings. NetFlow information can be used to show the breakdown of QoS packet markings for packets passing through a router interface. The TOS byte in the IP header contains the QoS marking. This byte is also known as the DiffServ Code Point (DSCP). The bits within the DSCP byte represent different QoS levels, and the value of the byte is usually included in common DiffServ naming conventions. For example, a value of 46 in the DSCP portion (first 6 bits) of the TOS byte field would be known as DSCP46. Just as the field has multiple names (TOS and DiffServ), the values have different names as well. For voice traffic, you are likely to see a value of Expedited Flow (EF) which is also known by its DiffServ name as DSCP46. Using the TOS byte values from NetFlow, a breakdown of the different QoS values can be reported. Figure 3-10 on the next page illustrates this concept with a report from a NetFlow reporting tool.
877.835.9575
79
Figure 3-10 Use QoS marking information to look for mismatches.
In addition to bandwidth allocation and QoS configuration, the manner in which you deploy phones, gateways, and call servers can also greatly impact call quality. Lets discuss some of the deployment models and considerations.
Network Deployment Considerations
A number of different network deployment models are valid for a VoIP system and can deliver excellent performance. But whenever possible, its best to plan carefully and select optimal placement for critical components. For example, the locations of the IP phones with respect to other IP phones and voice gateways can easily have an impact on call quality performance. A common enterprise deployment model is multiple sites with centralized call processing. Call servers are centralized, and phones may be local or remote. For the case where phones are located in remote or branch offices, the calls between sites may have to traverse a WAN. For these reasons, many enterprises are moving to MPLS networks, which can provide QoS mechanisms for the VoIP traffic.
80
www.netqos.com
Class-based QoS is commonly used to provide separate queues for VoIP call traffic. With class-based QoS, you typically define a policy that controls the amount of traffic allowed for each traffic class. Each traffic class is provided with a queue for its traffic. A separate queue is important to minimize latency and queuing delays for the VoIP traffic. As you add network hops between the phones or between phones and voice gateway, you inevitably introduce additional latency. Processing at each device along the way adds up, and dont forget the propagation delay, which is related directly to the physical distance that the packets must travel: they cant go faster than the speed of light. Some network scenarios that have the highest potential for creating or exacerbating call-quality performance issues: hones or gateways located at the end of slow-speed links, or links with high latency. P wireless phone accessing the network via a high-latency wireless network. A all traffic that must traverse a carrier network (that you dont own). C hones or gateways using a WAN link (or links) to connect to other phones. P ateways located far from the IP phones that are making calls through them. G Good network design principles are critical for ensuring optimal call quality performance. Include QoS early, or you will have to add it at a later date when it might not be as easy.
WAN Optimization
Many enterprises are centralizing data-center resources. As this occurs, a relatively new technique known as WAN optimization is being used to improve the performance of critical customer applications and the LANs at remote locations. WAN optimization is an umbrella term for many different techniques, including TCP optimization, application protocol optimization, and data caching. The goal of optimization is to reduce network flows in an effort to decrease application latency and make more bandwidth available. Should you consider using WAN optimization techniques with VoIP in an attempt to improve call performance? Lets discuss the key points: AN optimization does not help UDP-based protocols. Most WAN Optimization W technology is focused on TCP applications. The VoIP call traffic uses RTP over UDP. AN optimization techniques do not work well with protocols that have small packet sizes. W VoIP media packets range from 20 bytes to 160 bytes, depending on the codec.
877.835.9575
81
AN optimization data-caching techniques would not help VoIP call traffic. Data caching W is used for cases where large amounts of the same data are frequently requested by client applications on the WAN side. A VoIP call consists of encoded audio data, which is changing constantly over time. It is likely that WAN optimization techniques would have a negative, direct impact on call performancebut only if an attempt was made to optimize the RTP protocol. This doesnt mean that WAN optimization could not offer indirect help. By applying WAN optimization techniques, other application traffic bandwidth consumption could be reduced. This would effectively provide more bandwidth and less resource contention for the VoIP call trafficthus reducing the likelihood of queuing delays and improving the overall performance conditions for the VoIP calls. Weve discussed several network conditions that can affect call quality performance. Now well broaden the scope of our discussion and take a look at some other factors that can reduce VoIP call quality.
Other Considerations
In addition to the network considerations, other components in your VoIP system can affect the call quality. Some areas to watch for are usage of voice activity detection, voice gateway translations, and faulty end stations which can affect call quality.
Voice Activity Detection (VAD)
Voice Activity Detection, sometimes referred to as silence suppression, is a feature available in most VoIP systems. It is primarily used for bandwidth savings. The idea is that during many portions of a conversation, the parties are not talking at the same time. During most conversations, at any given moment, one party is talking and the other listening. VAD is an algorithm in the IP phone or gateway that detects when one party is not talking and instructs the phone or gateway codec to stop sending data, thus reducing the bandwidth required for the call. VAD can create quality issues such as clipping and audio loss because the silence detection algorithms are not perfect. For example, many telephone conversations are very interactive, with both parties interjecting during the conversation. VAD may clip the beginning or ending portions of the conversation. The tradeoff you need to consider with VAD is whether to exchange quality for bandwidth savings.
82
www.netqos.com
Voice Gateway Translation
Before convergence, all network managers had to worry about was typically the IP network. But the PSTN is not going away anytime soon. Anytime you have a place in the network where translation between protocols occurs, such as the voice gateway, where analog calls are translated to digital, there is always the potential for call quality performance issues. The voice gateway acts as the interface between the IP network and the PSTN. When you make a call that goes through the gateway, the bidirectional RTP streams travel between IP phone and gateway. The gateway terminates the RTP stream and translates the packets to information that can be transferred to the PSTN. In some cases, the gateway may need to translate between different codecs. For example, you may use a G.729 codec with reduced bandwidth requirements for calls over certain WAN links. The gateway may have to translate between phones using G.711 on one side and G.729 on the other side. The voice gateway contains digital signal processors (DSPs) that provide the codec translation in the hardware. The DSPs take the incoming PSTN audio and generate packets to transmit to the IP phone. The quality and speed of this process can have a direct impact on the quality of the call.
Endpoint Characteristics
Other factors that can play a role in call quality reside within the IP endpoint, be it a softphone or a regular, hard phone. If the endpoint is a softphone, consider the kind of microphone and speakers that are being used. Computers running a softphone quite often do not have very sophisticated microphones or speakers. What about volume levels? Does the user have the volume set on the phone correctly? Are other user errors in play here? Environmental factors can play a role as well. Is a speaker phone being used for the call? If so, is a large amount of background noise interfering with the reception? If a particular phone is continually reporting low MOS values, begin by taking a look at the underlying network metrics, as we suggested above. But if the network metrics look good, the problem may be attributable to the specific phone; or to the surrounding environment where the call is being placed or received.
877.835.9575
83
Increase the Bandwidth to Improve the Quality?
When call quality performance problems occur, what steps can you take to solve the problem? Can you solve VoIP performance issues by throwing more bandwidth at them? Some in the industry seem to think so. Yet engineering a data network to provide the same level of VoIP call quality performance that we are accustomed to in the PSTN is a complex undertaking with many elements to consider besides bandwidth.
Bandwidth Helps With Additional Calls
The amount of bandwidth required by a VoIP call can be deceptive. The codecs send data at relatively slow data rates. G.711 typically consumes the most bandwidth, operating at 64 kbps. Although this is the nominal data rate, there is more to the story. For every VoIP packet that is sent, an RTP, UDP, and IP header are added. These headers add 12, 8, and 20 bytes respectively. So while G.711 sends data at 64 kbps, the actual amount of bandwidth required is more like 87 kbps due to the additional headers. When deploying VoIP, its a good idea to understand the call volume in your network. For example, whats the busy hour call traffic between two office locations? Once you determine your typical usage levels, you can calculate the amount of bandwidth required to run VoIP traffic over your network links. If specific links are trying to support too many calls, congestion will occur, which will lead to call performance issues. So adding bandwidth to a specific network link can enable those links to support more VoIP calls with higher call quality.
Bandwidth Helps to Alleviate Congestion
Congestion is one of the leading causes of lost packets and jitter, two network impairments that can lead to poor application performance and can be deadly to the quality of a VoIP call. Congestion is a fairly simple concept: there are too many users for a given resource. Rush hour on busy freeway provides a good illustration. In a network, congestion might occur on a given link because too much traffic is flowing over that link; VoIP is often combined with traditional data-networked applications like email, ERP, and Web. TCP has congestion control built into the protocol, but for UDP-based applications, like VoIP, theres nothing in the protocol to help. In fact, when faced with congestion, the TCP applications will actually back off and slow down or stop sending data (creating potential performance issues for the TCP application users), while the VoIP phones will just keep on sending it.
84
www.netqos.com
Adding bandwidth to a link can allow for more calls and for more application traffic to traverse the link without that links becoming congested. Adding more bandwidth than will be utilized is typically called oversubscribing a link. Oversubscription can help prevent congestion, but its usually expensive.
Bandwidth Helps Enable YouTube Browsing
Adding bandwidth might actually enable applications like YouTube video viewers to run on your network. Without the additional bandwidth, video viewing might not have been possible or the quality might have been so bad that no one would try it. With additional bandwidth, your users may start to enjoy watching videos from their desk. This is an interesting twist on VoIP call quality problems. You add the bandwidth to fix the quality issues, but in doing so, you actually enable new bandwidth-hungry applications, which consume all the additional bandwidth; leaving you with the same call quality problems, which still must be addressed!
Bandwidth Doesnt Help Reduce Delay or Latency
Because VoIP traffic is extremely sensitive to delay, slowing down a VoIP packet by more than 150 ms can cause serious quality problems. Earlier in Key Call Quality Metrics, we discussed the different components of the network that can create delays for a VoIP packet. Most of the components introducing delay for a given VoIP call, such as jitter buffers, are not affected by additional bandwidth. The one exception is the queuing delay, which could be reduced by the extra bandwidth. So if you have a call quality problem due to delay, additional bandwidth may not fix the problem.
Bandwidth Doesnt Help Avoid Echo or PSTN-to-IP Conversion Issues
Whenever a call crosses from the IP network to the PSTN, there is always a chance for quality issues to be introduced. For example, echo is one of the most annoying quality issues that can occur on VoIP-to-PSTN calls. The IP portion of the call is not the direct cause of the echo, but it can be indirectly related. In many cases, the echo may already be located in the analog portion of the call, but it is imperceptible until the packets hit the data network. Additional delays added when traversing the IP network and any gateways doing analog-to-digital translation can cause the echo to be audible by the phone users. As weve stated earlier, additional bandwidth is usually not a good solution for solving VoIP quality issues caused by delay.
877.835.9575
85
Bandwidth Doesnt Help Improper QoS Mechanisms
VoIP is one of the applications that can take advantage of the move to MPLS-based networks. Many companies are migrating to MPLS-based networks, and at the same time, or shortly thereafter, considering rolling out VoIP. QoS mechanisms are critically important for VoIP traffic, but the QoS policies must be applied end-to-end to be effective. One link in the path with improper QoS is equivalent to no QoS for the VoIP call. As VoIP traffic traverses an MPLS network, it may enter and exit the Enterprise and Carrier networks at different points. If the QoS marking is different at these ingress and egress points, the quality of the call is likely to suffer. This is typically a configuration problem that would not be solved by additional bandwidth.
Bandwidth Doesnt Help Network Architecture: A Weak, Slow Link is Still a Weak, Slow Link
If you decided to add bandwidth to improve VoIP call quality, where would you add it? VoIP calls will be traveling from location to location, through gateways, potentially over VPNs, and even through wireless networks. You might upgrade some of the WAN links, but if there is still even one weak, slow link in the path, you could still have quality problems. In addition, the upgraded links could produce new bottlenecks within the network; any place where higherspeed links converge into an area of the network serviced by a slower-speed link is a potential traffic jam. So while additional bandwidth might help with calls traversing a certain path, the question is: Does it also introduce new problem areas, where slower links are still traversed for part of the VoIP call path?
Bandwidth Doesnt Help Your IT Budget
Additional bandwidth can be a costly solution to a VoIP call quality issue, especially if it doesnt solve the problem. Its important to proactively manage VoIP call performance, understand the causes of any quality issues, and know the composition of the traffic thats flowing over your network. With better visibility and knowledge, youll know when additional bandwidth might be an appropriate solution and when it wont be!
86
www.netqos.com
Chapter Summary
In this chapter, weve discussed the concepts that are important for ensuring optimal call quality. Why should you be concerned about call quality performance? The reason is that call quality performance can have a dramatic impact on your overall business. If you cant talk to customers and partners, then it will affect your business. The overall user experience of the phone system is tied closely to the quality of the calls. In order to understand this aspect of user experience, you need to monitor certain call quality metrics very closely: OS M atency L
acket Loss P COM A
itter Buffer Loss J Managing call quality performance can go a long way in providing for a successful VoIP deployment. Many enterprises are considering VoIP as the stepping stone for other Unified Communications applications like video, presence, and instant messaging. Getting VoIP right is a crucial first step down the road to true unified communications. In the next chapter of this book, well examine the path to Unified Communications and consider: hat is Unified Communications? W hat are the new Unified Communications applications? W ow will Unified Communications affect network performance? H ow can you manage Unified Communications applications? H Unified Communications offers the vision of great productivity gains as integrated multi-modal communications are built into our most commonly used business applications. But any time new applications are added to the network, its always good to take a step back and analyze the potential impact on network performance.
877.835.9575
87
Chapter 4
Unified Communications
In previous chapters weve discussed how you can manage the VoIP quality of experience on your network. Weve provided strategies and advice to help you estimate the levels of quality that users experience in their interactions with the VoIP phone system and continually deliver a high level of quality. But VoIP is just the beginning. It provides a great starting point on the path to Unified Communications. The network requirements for VoIP, call setup performance, and call quality management are important foundational concepts to build on as you expand the capabilities of your network. Deploy VoIP and get it right; then, you are ready to move on to other Unified Communications applications like video, presence, and unified messaging. Many enterprises are beginning to take a close look at the substance behind the hype surrounding Unified Communications, or UC. A recent survey showed that nearly 30% of enterprises had a Unified Communications strategy, and more than 31% viewed Unified Communications as one of their top three IT initiatives. [1] Software heavyweights such as Microsoft and IBM have entered the UC market, which was previously owned by the IP PBX vendors, such as Cisco and Avaya. As the solutions evolve over the next several years, expect business applications and integrated soft phones to play a greater role and to find much broader acceptance. This chapter explores the topic of network management for Unified Communications. As these new communications applications are added to the network, what are the key network performance considerations, and how can you manage them? UC adoption is usually a slow, staged process and not a forklift upgrade. In this chapter, well examine the path toward Unified Communications and consider the following: hat is Unified Communications? W hat are some of the new Unified Communications applications? W ow can you manage Unified Communications applications? H
ow will a Unified Communications deployment affect network performance? H
88
www.netqos.com
Unified Communications offers the vision of great productivity gains as integrated, multi-modal communications interfaces are built into our most commonly used business applications. But anytime new applications are added to the network, its always good to take a step back and analyze the potential impact on network performance. Before we do that, lets take a look at exactly what we mean by the catch-all term Unified Communications.
The term Unified Communications is often abbreviated as UC. Well use UC and Unified Communications interchangeably throughout the rest of this chapter.
Defining Unified Communications

Ask the question What is Unified Communications?, and you are likely to get many different answers. We thought it would be interesting to take a look at the Websites of several Unified Communications vendors and see how they define the term.
Cisco
Cisco is known for robust IP communications solutions. Their version of UC adds applications beyond VoIP. Heres how Cisco defines UC on their Website: Besides helping organizations integrate their communications more closely with business processes, unified communications ensures that information reaches recipients quickly, through the most appropriate medium, no matter where they may be working or what device they may be using. Unified communications allows businesses to collaborate in real time using advanced applications from an integrated, easy-to-use interface. These applications include: video conferencing, integrated voice and web conferencing, mobile IP soft phones, and voicemail. [2]
877.835.9575
89
Avaya
Avaya has an excellent primer available on their Website titled Unified Communications for Dummies. That sounds like a good place to find a definition for Unified Communications. Heres what it says: Unified Communications is an evolving approach to communications that solves countless issues in the modern, mobile work environment, or, more accurately, wherever youre doing business these days. UC simplifies your communications by logically blending and combining previously separate services and features so that communications by any means with anyone is possible over any of your devices. [3]
Microsoft
Microsoft made a huge, market-altering splash with its entry into the Unified Communications sector. You may have heard the buzz surrounding their stated aim of killing off the IP PBX. Microsoft is leveraging its strength in enterprise messaging to enable other UC applications. Their collateral defines Unified Communications as follows: Microsoft unified communications technologies offer customers choices in how their communications and collaboration software is delivered, managed, and maintained [b]y uniting your existing communication systems and tools [w]ith the productivity tools your people use every day[, u]sing integrated servers plus services and client applications [t]o deliver complete communications tools . . . across multiple convenient applications and devices. [4]
Unified Definitions
After sorting through all the marketing messages from the major vendors, how should we define Unified Communications? Lets start by pointing out what UC is not. Unified Communications is NOT:
VoIP only. VoIP-based call processing is a building block for UC, but VoIP alone is not enough to provide UC.
90
www.netqos.com
Unified Messaging. The idea of getting all your messages email, voicemail, fax in a single interface has been around for some time now. While UM simplifies message access and is generally part of a UC strategy, it is not, by itself, UC. Closed, proprietary systems. UC depends on interoperability between applications and infrastructure. If you cant communicate with a colleague because she is using a different vendors communication system, theres not much point in being unified in other areas. Rip and replace. You likely have a communications infrastructure in place already. UC should
work side-by-side with your existing infrastructure to enable new applications, not force the replacement of existing infrastructure.
About big cost savings. UC may not save you money. It requires deployment and management
of new components and applications. UC vendors often tout user productivity benefits as a cost justification. While we think these benefits can be substantial, its difficult to put a hard dollar value on soft benefits like these. (Of course, you can always hire an expensive consultant to analyze productivity gains from a UC deployment, but that supports our point about the cost).
Now lets define UC from a performance-first perspective:
Unified Communications is the integration of multiple modes of communication within applications and infrastructure that allows people, teams, and organizations to communicate more effectively. The IP network provides the unifying factor for UC, and network performance is a critical enabler.
Theres one common factor when discussing Unified Communications applications: they all make use of a converged IP network. In order to provide benefits from the real-time presence status, point-to-click calling, video conferencing on demand, and other features built into UC applications, the network must be managed and tuned for optimal performance. From the perspective of user experience, UC applications will place greater demands on your network than any other networked applications to date. Unified Communications solutions provide applications that allow for communications in a variety of different modes. Lets discuss some of these applications and their impact on network performance.
877.835.9575
91
Unified Communications Applications

Unified Communications applications are designed to streamline business processes. Communications are a key part of any business, and ineffective or unavailable communications media can directly affect the bottom line. Think about the flow of information through your company. Your business has processes in place to route information to appropriate parties who act on the information and often, in turn, create additional information that must be acted on. These processes are prone to inefficiencies.
The Business Problem

UC applications strive to improve end-user productivity by addressing the business problem of communications inefficiency. Communications inefficiencies are created in a number of ways: or in a meeting, so you call and leave a voicemail message. Then that person calls you back, but doesnt realize that youre now out of the office so they leave another voicemail. Phone tag results in wasted time. If you knew the current availability information for a contact, you might try a different method of communication based on their status.
Phone Tag. Weve all participated in this little game. You dont know that someone is unavailable
a call. Unless you have freakish memory recall, its a good bet that youll have to look up the colleagues phone number. Hopefully, your contact information is up-to-date and accessible. Wouldnt it be nice to just click on the username in the email message to call that person back immediately?
Switching Applications. Youre working with a business application and need to communicate with a colleague about a report you are viewing. Switching out of the business application and launching an email program takes time and loses the context of your working environment. If you can instead communicate from within the application, you save time and maintain the context for the communication.
Number Lookup. You get an urgent email from a colleague, and you need to quickly give him
92
www.netqos.com
Human Latency. We all know the effect that network latency can have on application perfor-
mance. Human latency actually has a comparable impact on your business. Gartner states that the largest single value of UC is its ability to reduce human latency in business processes.[5] Consider this example: You are working on a project and need immediate input from a supervisor to move to the next step. Unfortunately, she is out of the office, meeting with a client. The time it takes for you to communicate with that supervisor and get a response could be considered human latency. Reducing this lag time can directly improve productivity.
Working on a team that is geographically distributed with team members in multiple global locations requires excellent communications. Collaboration over a long distance requires superior-quality communications, such as high-definition videoconferencing, extremely frequent communications using several methods, or both. Applications that can make these communications more effective and more closely integrated with other collaboration tools enable the team to be more productive. UC applications are geared toward addressing these efficiency issues and providing more effective communications for the enterprise.
Globalization. The workplace is growing more and more global in nature each and every day.
UC Solutions
In many cases, UC applications have other common features as well. For example, many of these applications can be accessed via a communicator client program that provides a single interface for multi-mode communications. These lightweight applications may run on a PC, a mobile device, or a desktop phone, providing users with a common interface for most of their daily communications. In the next few sections, well extend our definition of UC to the components that can usually be found in a solution labeled as Unified Communications by a given vendor.
877.835.9575
93
Communicator
Star Trek made the idea of personal communicators famous. Many of us look forward to the day when we can say Beam me up, Scottie into our own communicator devices. Todays UC communicators may not be able to physically transport you, but they do provide an integration platform for a number of different communications applications. The communicator application is software that runs on a computer, phone, or other mobile device. It keeps an organized list of the people with whom you communicate on a frequent (or infrequent) basis: your contact list. Figure 4-1 shows screen shots of Cisco Unified Personal Communicator 1.2.2 and Microsoft Office Communicator 2007.
Figure 4-1 Communicator applications provide contact lists and presence indication.
94
www.netqos.com
The contact list provides important information about those you communicate with. You can see their presence their current status and/or availability for communications. From your contact list, you can launch different modes of communication to interact with a given contact. You might need Instant Messaging (IM) to send a message to a co-worker with a quick question. Once the IM session is started, you may need to escalate to a phone call to clarify certain points. Adding video or Web conferencing to an IM session for enhanced collaboration might be a one-click option in a true UC implementation. Communicator applications often integrate email and the relatively newer IM capabilities that have recently become very popular in the typical enterprise. But they also recognize that audio is still an important means of communicating, which leads us to the next UC application: voice.
Voice (VoIP)
Voice is always a key part of any communications strategy, and UC is no exception. Many enterprises have found that VoIP plays a key role in enabling other UC applications. This is true for a number of reasons, primarily because VoIP places real-time communications requirements on the network with its strict latency and jitter thresholds. By tuning your network to support VoIP well, you are preparing it for other UC applications. A VoIP deployment also provides key infrastructure for UC. The IP PBX or communications server handles VoIP call control, and this function is needed for UC voice applications as well. Unified messaging solutions, which can, for example, send voicemail as an email message, have flourished in VoIP environments and play a key role in UC. The communicator applications discussed above can usually act as soft phones, meaning that they are capable of making and receiving phone calls. A click on a contact name shows the available methods for calling that person. The call you make from the communicator application could be PC to PC, PC to desktop phone, PC to PSTN, or PC to mobile.
Video
Ever since the Jetsons started using their visaphone in the early 1960s, the idea of video conferencing has been appealing, especially if you spend a lot of time on conference calls or on airplanes traveling to meetings. The advantages of videoconferencing are well defined: You get to
877.835.9575
95
see the body language and read the lips of the people you are talking to; theres an opportunity for visual aids, such as the ubiquitous corporate whiteboard; and youre likely to pay closer attention to a video call than you do to an audio-only call. However, the usage of video conferencing has varied greatly. In most cases, it has been reserved for executives or isolated in conference rooms. Now, UC applications enable easier video capability by integrating it with other communications applications. In some systems, you can call a colleague and then decide to add video by clicking an icon. But users are not going to take the trouble to learn how to use video-conferencing equipment, which is often wholly unfamiliar, if the quality is poor, or if all they see is an image the size of a postage stamp. UC applications now offer desktop video capability with high-definition quality. Cisco provides a rich Telepresence solution that creates a specialized environment for users and creates an experience that is close to being there in person.
Presence
Presence has come a long way from the days of AOL Instant Messengers announcement that a user has logged on or off. Now presence has many states and can reflect not only availability, but willingness to communicate as well. Users can set their presence state and control multiple levels of access, controlling who can contact them and how they can be contacted. In the Microsoft Office Communications Server (OCS) solution, Outlook and even previously nonintegrated applications like Word can convey user presence information. Users may be logged in to multiple devices; presence data must therefore be aggregated to determine status accurately. And for a really useful system, presence information is integrated with call routing so that if someone is present on his mobile phone, incoming calls for him arent routed to the telephone on his desktop 500 miles away. Presence updates need to happen in near real time if they are to provide a true representation of a contacts status. But the inclusion of contact and calendar information can make presence update messages quite large. Some planning is needed to mitigate potential network performance issues associated with potentially voluminous presence updates.
96
www.netqos.com
Instant Messaging
Instant messaging (IM) has now become a staple business application and a popular way to communicate. For quick questions or discussions, IM is often the preferred mode of communications, even over email. IM requires less overhead and is easy to use. Theres no Inbox to clean out periodically. IM usually has basic features, like sending and receiving text, changing fonts and colors, basic file transfer, and multi-party chat. With Unified Communications, a core feature is the ability to escalate an IM session to audio, video, and conference/collaboration as the communication needs dictate. The performance characteristics of IM are likely not at the top of every network managers hot list. However, as users grow more and more accustomed to the quick response that is part of the nature of IM, network performance becomes more important. If messages are delayed or do not make it through the network due to performance issues, users are left with a poor IM experience.
Email and Unified Messaging
Email is a foundational UC application because such a large percentage of daily communication is accomplished via email nowadays. Unified messaging applications provide the capability to access voicemail, email, and fax, all from a single interface. Frequently, email systems are used to store the voicemail data as email attachments that can be played back on a computer. In UC applications, email clients may be integrated with other UC applications to allow calls or other communications to be routed to the users who sent the email. Presence information can show you the current status of the email sender, giving you valuable information about how best to respond.
Web-Based Conferencing and Collaboration
Collaboration is a big part of any UC solution. We mentioned earlier that globalization was a driver of UC development and adoption. Team members separated by geography need easy to-use communications applications that enable collaboration. A whiteboard interface, plus the ability to share presentations, notes, and other documents are essential to effective teamwork.
877.835.9575
97
Youve probably used Web-based collaboration applications like Ciscos WebEx Citrixs , GoToMeeting, or Microsofts LiveMeeting. These applications allow presentations to be shared with clients in Web sessions that previously required a face-to-face meeting. These applications can provide audio, video, and collaboration via a single Web-based interface. As you can see, UC applications offer a vast array of integrated, streamlined communications features for users. The converged IP network provides the foundation for all of these applications and features.
The Network Foundation

A good network foundation is required to prepare for current and future UC deployments. Enterprises will follow different timelines as they begin this journey. But no matter how slowly or how rapidly the deployment proceeds, the need for a sound network management strategy increases as Unified Communications applications are rolled out beyond the initial pilot phase. The 2007 Yankee Group Research report titled A Guide to Managing Enterprise Unified Communications offers a look at the migration path from VoIP to Unified Communications and various management considerations along the way as seen in Figure 4-2. [6]
98
www.netqos.com
Figure 4-2 Management needs increase on the path to Unified Communications.
Its interesting to note that network management plays a key role in every stage of the overall UC deployment cycle. It begins with Lab Testing and continues through Pilot and Production phases all in preparation for deployment of Unified Communications applications. At each step along the way, its also important to look at key metrics for your existing applications to ensure that the changes havent harmed their performance. Network performance is always an important component of end-user satisfaction with application delivery, but as weve pointed out in previous sections discussing VoIP performance, the network directly impacts the user experience with UC applications. According to Zeus Kerravala, Senior Vice President of Enterprise and Enabling Technologies at Yankee Group Research, When UC applications encounter performance issues, they dont just slow down, they become unusable. The complexity of presence, voice, and video on your IP network demands that network management tools present a unified view of the performance of these applications.
Copyright 1997-2008. Yankee Group Research, Inc. All rights reserved.
877.835.9575
99
With that advice in mind, lets take a closer look at the impact that UC applications can have on network performance.
Unified Communications Impact on Network Performance

Any UC solution comprises lots of moving parts. Plenty of new applications, new endpoints, and new infrastructure must be added to your network. As Unified Communications applications are purchased, installed, and configured, prepare yourself for the inevitable changes by finding preliminary answers to several important questions: ow will the new UC applications affect the performance of my existing networked H applications? ow will the new UC applications themselves perform? H f performance is sub-par, will the user experience be good enough to make deployment I worth the effort and expense? To answer these questions, its worth considering the kinds of requirements that typical UC applications can place on the network in terms of bandwidth, packet loss, jitter, and latency. Understanding how the new applications work is important as well. The Session Initiation Protocol (SIP) is the key network protocol that enables communication for almost all UC applications. In the following sections, well provide a quick refresher on SIP.
SIP The Enabler

SIP was defined by the IETF in RFC 3261 and in many other follow-on RFCs. SIP can operate over both TCP and UDP, making use of port 5060 for non-secure communications and port 5061 for secure communications. SIP can use Transport Layer Security (TLS) to provide secure, encrypted communications. Encryption is important for SIP because it is a text-based, ASCII protocol, meaning that if you capture unencrypted SIP packets, you can easily read their contents. SIP uses an addressing format called a Uniform Resource Identifier (URI). The URI format resembles an email address, but is prefixed by sip:. For example:
100
www.netqos.com
sip:user@netqos.com sip:user2@10.10.10.1
or
The URI is used to set up a SIP session with another user. Whenever you make a call, start up a conference, or IM another user, SIP looks up and contacts the other user(s) based on their URI. The SIP addressing format means that instead of memorizing someones phone number, now you can contact them via the more user-friendly URI. Figure 4-3 shows a snippet from a SIP INVITE packet. This INVITE was sent in order to establish a voice call from a user with extension 6101 to a user with extension 6110.
Figure 4-3 SIP messages are text-based and contain URI addressing information.
Many SIP messages contain eXtensible Markup Language (XML) content. A generic standard for structuring and communicating data, XML is often used by Web-based applications to transfer data between a client and a server. SIP uses XML content to transfer information like presence status between endpoints. An embedded, XML-like protocol called Key Press Markup Language (KPML) is also used by SIP to transfer messages related to keys that a user presses. The call server subscribes to key press events, and each time the user presses a key, the digit information is sent by means of a SIP NOTIFY message to the call server.
877.835.9575
101
SIP is not just a voice call setup protocol. It was designed to be more than that; in many current solutions, it enables real-time communications for audio, video, IM, and presence. Table 4-1 shows how SIP is used for the main applications typically present in a UC solution. UC Application
Voice Video Instant Messaging Presence
SIP Usage
Set up and take down voice calls Set up and take down video sessions Establish IM session between users and send/receive user text messages Used to allow endpoints to subscribe to presence status and receive presence change notifications.
Table 4-1 SIP is a key enabler protocol for UC applications.
Because SIP is practically ubiquitous when it comes to UC applications, it is important to understand its performance characteristics. For example, one of the advantages of SIP is that its a text-based protocol, easy to parse and read. But this advantage can also cause network performance issues: being ASCII-based means that many required SIP messages are quite verbose, consuming more bandwidth. Weve observed from packet analysis of a standard phone call that the call signaling information from a SIP phone can consume up to four times more bandwidth than a phone using Cisco-proprietary SCCP. Call signaling is not a large bandwidth consumer in general, but when you deploy thousands of endpoints, the extra bytes can add up. Another set of performance issues is inherent in the networking architectures that carry SIP data. As more and more UC applications that use SIP are deployed in the enterprise, organizations will need to communicate with other organizations outside their domain. In the past, the PSTN network functioned like glue to tie everything together. Islands of VoIP existed within enterprises, but PSTN connectivity was still required to call other users outside the enterprise. More recently, service providers have begun offering SIP trunks that can connect the SIP islands together and allow SIP-based communications between different domains.
102
www.netqos.com
A SIP trunk is basically a network connection to transfer SIP packets and data traffic up to an allocated amount of bandwidth. A service provider provides the network connection using a device called a session border controller (SBC) or border element. The session border controller acts as a proxy for SIP connections between the enterprise and the service provider network. Anytime boundaries are introduced between networks, and anytime proxies are involved, the potential exists for performance issues. Calls may travel exclusively on the IP network to other SIP-connected entities, or they may be routed out to the PSTN. As the migration from PSTN-connected VoIP islands to interconnected SIP networks progresses, new performance issues can arise. Calls may traverse other IP networks that you do not control, and end-to-end QoS may be difficult to achieve. Anytime you have a hand-off between networks, the potential for performance problems arises. A best practice is to monitor your SIP trunk connections to see how many sessions are traversing them at a given time, and to measure the performance and quality of those SIP sessions. A good metric to watch is bandwidth utilization on the trunk are you at capacity, approaching capacity, or not even close? QoS metrics are always important for SIP-controlled sessions. Be sure to monitor packet loss, jitter, and latency. Weve touched on some performance considerations for SIP. Now lets look at the performance of the UC applications.
UC Performance Considerations
Deploying UC applications can raise a whole host of new network performance issues above and beyond those associated with the SIP protocol and system architecture. One feature that makes UC attractive is the real-time nature of the communications it fits the model of how humans like to communicate. But in order for unified communications to fit the real-time model, you need a network thats ready to provide optimal real-time performance. Each of the typical UC applications we discussed earlier entails some specific ramifications for network performance.
877.835.9575
103
Communicator
The communicator application, which is typically very lightweight, is a key enabler for Unified Communications because it ties the contact information and presence status information together. In most implementations, it opens in a very small, nonintrusive window, and can take only a few seconds to install on a client system. However, its small portion of desktop real estate belies its rather substantial network footprint. The first thing to consider is what happens when the communicator application starts.
Initialization
How many contacts do you have in your contact list? 10? 20? 50? The cool thing about the unified contacts in the communicator application is you dont just see the persons name and phone number. You can see all kinds of information about each person in your enterprise, such as their physical address, their department and title, their calendar, even a photo of the person. All of this information must be downloaded to your client when the application first starts up at login so that you have the latest information. To get an idea of the potential problem, we looked at the data transfers to download contact information for one of the leading communicator applications.
Contacts
The amount of bandwidth required for initial download is directly proportional to the number of contacts defined. We took a reasonable number of contacts10and started up one of the communicator applications. The amount of data transferred was approximately 75,000 bytes. Now imagine 100 users logging in and starting the day at 8:00 AM. Perhaps they are all at a remote site, with a slow-speed WAN link separating them from the server at company headquarters. Without traffic shaping mechanisms, the WAN link could be completely saturated while the UC applications download contact and presence information. Large corporate directories can provide additional challenges, as most communicator applications allow you to search for a user in the directory. This information must either be queried on demand or cached locally by the application. Network flows associated with either of these actions could be significant.
104
www.netqos.com
Presence
When your communicator starts up, it has to register with the presence server in order to receive presence notifications. In a SIP environment, presence information is disseminated by means of SUBSCRIBE and NOTIFY messages. Your client must SUBSCRIBE to the contacts that you are interested in (the ones you have added to your list), and the presence server will NOTIFY you when their presence status changes. Figure 4-4 shows how presence updates work with Microsoft OCS. [7]
Figure 4-4 Clients subscribe for presence updates, which may be aggregated.
The more contacts you have in your contact list, the more presence updates the server will need to send, and the more presence updates that you will need to receive. When the status of a contact changes, the server must relay that change to each user who has subscribed for that contact. It can become quite a large mesh of bidirectional updates as more users are added. Presence updates are also pretty frequent. They need to be sent and received in near real time; otherwise the information you are using to make decisions about whom to contact and by which method wont be up-to-date.
877.835.9575
105
Voice
VoIP technology is an underlying building block for UC applications. Weve covered VoIP network performance extensively in Chapters 1-3 of this book. Wed encourage you to review these if you are considering rolling out, are actually rolling out, or have already deployed VoIP. The same network performance issues that are present with VoIP phones are also applicable to UC applications. The Quality of Experience (QoE) for voice calls is very important from a management perspective, along with the ability to map that QoE to the underlying Quality of Service (QoS) that the network provides.
Video
Bandwidth, bandwidth, and more bandwidth. UC desktop video conferencing now enables point-to-point video streams between the endpoints. Communicator applications allow users to easily participate in video conferences from their own computer. No longer is the video conferencing solution confined to a conference room with dedicated equipment, a dedicated expert on staff to help users activate it, or even dedicated network connections. Is your network ready for point-to-point video? Do you at least know how much bandwidth is already being used on the same links, and who is using it? A single video stream takes anywhere from 300 to 400 kbps of the available bandwidth in each direction. Add in the audio component, and youve got over 800 kbps for combined video and audio streams. Voice packets are usually relatively small, while video packets are usually crammed with as much information as they can contain. Proper QoS mechanisms (see the QoS section later in this chapter for more details) are required so that the video doesnt crowd out the voice (and everything else). Like voice, video is carried using RTP and is sensitive to packet loss, jitter, and latency. Packet loss can create missing blocks in the video image, or if severe enough, can cause the image to freeze for a few seconds. Too much jitter can have the same impact as packet loss as the packets arrive too early or too late to be contained in the jitter buffer. Latency can result in lag time, making quick interaction very difficult.
106
www.netqos.com
Ensuring user Quality of Experience (QoE) is immensely challenging for video applications. For one thing, its hard to measure your success in delivering high-quality video. Theres not a widely accepted video quality standard thats equivalent to the MOS for audio. Video quality is an even more subjective category than call quality because at least the MOS has been mapped to a set of metrics with defined value ranges. Video formats can vary, from low-resolution all the way to high-definition (HD) quality. Determining the user-perceived video quality is a big challenge, especially as more users become accustomed to watching HD programming on their televisions the lower-resolution video just doesnt look as good anymore. However, despite the lack of a generally accepted quality standard for video over IP, network performance metrics like packet loss, jitter, and latency can give you a good indication of the quality of service being provided by the underlying network. In addition, more video-specific metrics are usually measured by the video endpoints themselves. These include frame rate, frame loss, and frozen video and can provide some insight into the user experience with the video application. Most UC solutions enable a couple of different types of video calls, with different requirements that can affect network performance. Lets consider them.
Point-to-Point
Adding desktop video presents an entirely new challenge to the network. Most networks are tuned for client-to-server business communications. VoIP has changed that somewhat as calls can traverse many different paths to get to the end-user. Now, with the addition of video calls, a lot more bandwidth may be required in places you didnt expect. What if Jim in Raleigh makes a video call to Steve in Austin? Is bandwidth sufficient at each hop along the path between Raleigh and Austin? You now have to consider capacity issues, such as: I can make X calls over this link now. If I add video, then I can make Y audio only calls, or Z calls with audio and video, or some number of both. Traffic shaping or rate-limiting techniques may be required to ensure optimal quality for all users.
877.835.9575
107
And dont forget your remote workers who may connect to the network via a VPN connection. If they are participating in point-to-point video sessions, they may be consuming bandwidth in additional places where you were not expecting to see a bandwidth shortage. Depending on the VPN that is accessed, these users may or may not be near other users to whom they are talking via desktop video. Unless your network links are tremendously oversubscribed, you will need more bandwidth tomorrow for every place where you can make a VoIP call today when you enable UC desktop video.
Conferencing
Most UC communicator applications allow video calls to be placed that involve more than two participants. In the case of a multi-party conference call, a conference server is usually involved. Users establish connections to the conference server, which multiplexes the audio and video and sends dedicated streams to each of the participants. In this scenario, the network between each client and the conference server must be able to support the audio and video streams. If you have a large number of clients in the same remote location participating in the conference, you could face performance issues as separate unicast streams are sent to each client. However, this type of conferencing solution is not your only option. Many video streaming applications provide a multicast option or other features to reduce the network bandwidth required for video conferencing. You should consider the likely usage scenarios when you evaluate different UC video conferencing solutions.
QoS
As with VoIP, QoS mechanisms are required to enable UC applications to run with acceptable quality. The real-time nature of UC applications and their strict latency and jitter requirements dictate the usage of QoS. Due to differences in the protocols and bandwidth consumption, you will need multiple classes to represent SIP, audio, and video flows. Ciscos Class Based QoS (CBQoS) is an ideal mechanism for UC applications. CBQoS allows a network administrator to define application traffic classes that should receive different handling in the network. Policies can be applied to the traffic classes to control bandwidth and provide low-latency queuing, with the ability to create separate queues for
108
www.netqos.com
different traffic classes if needed. In a UC environment, you could define separate voice, video, and SIP traffic classes. Each of these classes would be prioritized appropriately by intermediate network devices that carry the UC traffic. UC applications mark the traffic flows with different bit settings in the DiffServ codepoint. Network devices can use the different bit settings to map the traffic to the appropriate class. Different queues can be used for each class so that the voice, video, or SIP traffic does not become stuck behind other data traffic. UC is all about the user experience. A poorly performing network can make that experience a bad one. UC applications introduce a number of network performance issues. Earlier we mentioned the need for a unified approach to managing the performance of UC applications. Lets discuss such an approach.
Managing Unified Communications

Managing the performance of Unified Communications applications presents a challenge to the traditional organizational hierarchies at many enterprises, where separate teams of trained staff have responsibility for different communications components. In the past, a typical enterprise had a group to manage their PBX, another group to manage the network, a different group to manage servers, and possibly even another group to manage specialized infrastructure like video conferencing. The transition to VoIP has initiated the convergence of not only the networks, but also the management groups. Many telecom and data management groups are becoming a single entity. Now with the addition of UC, we see the further convergence and blurring of traditional boundaries. Successful delivery of UC applications will require a performance-first proactive quantifying of network and application performance mentality, applied to the management of the applications and infrastructure. Its not enough to know whether the server is running, or the router is up. UC will cross all the boundaries of application, voice, server, and network management and demands a unified approach to management.
877.835.9575
109
Managing Unified Communications starts with understanding the components that create a better QoE for your users. You need tools to provide the visibility into the QoE metrics and the ability to map those metrics to underlying network quality of service. Perhaps most importantly, you have to do away with the finger-pointing traditionally associated with the separate IT and Telecom teams of the past. Keeping users happy as you roll out not only new applications, but new ways of communicating with coworkers, both distant and close by, requires a cooperative and comprehensive mindset. Lets consider a unified approach to UC management that prioritizes performance.
UC Management Methodology
Since UC applications span a broad spectrum in terms of network performance, to manage them all, its useful to look at a number of different performance data sources and pull them into a single UC Performance Dashboard-type report. A performance-first UC management strategy should include performance characteristics for all of the UC applications, always bearing in mind that they have the potential to drag each other down. Each application will have one or more performance metrics associated with it that is best suited for the approach outlined here. As the performance information from the data-gathering tools is synthesized in a single report, it should present a comprehensive management view of the UC environment. Figure 4-5 demonstrates some of the items that should be part of UC performance management.
110
www.netqos.com
Figure 4-5 A comprehensive approach to UC performance management.
UC performance management begins with the Quality of Experience. What is the QoE for the user audio and video calls? What is the underlying QoS that supports that QoE? These are key questions that should be answered by UC performance monitoring tools. For voice, the QoE is best measured by the call setup and call quality performance. For call setup, look at metrics like delay to dial tone, post-dial delay, and call setup failures. For call quality, begin with MOS, but also understand the relevant network metrics like packet loss, jitter, and latency. Weve discussed call setup and call quality management extensively in Chapters 2 and 3 of this book.
877.835.9575
111
For video, quality standards are not as well defined as they are for voice. Its hard to use software to quantify something like lip-sync delay, for example, even though a viewer most certainly notices the effect when the image and audio are poorly synchronized. In the absence of a de-facto quality standard for video, a more user-friendly approach to video quality monitoring relies heavily on metrics that are measured by the video components themselves, such as video frame loss and frozen video. You can then correlate spikes in these values with the underlying network metrics for packet loss, jitter, and latency. Keeping all of these metrics is as important to video quality as it is for VoIP call quality. Moving from user experience to bandwidth analysis of UC applications is a logical progression. We identified some of the performance concerns around bandwidth for UC applications like video and presence. The data collection tools you use to manage UC performance need to provide enough visibility into traffic composition on network links so that you gain the necessary visibility to understand: how much bandwidth is being used by each of the UC applications, and who is using that bandwidth We mentioned earlier the potential that desktop video has for consuming bandwidth in places you dont expect. If a specific user is making video calls all day long to other users and saturating your WAN link, you need to know about it right away. You also need microscopic visibility into every network link where QoS is being applied. A QoS misconfiguration at any point in a communication flow between two users can make VoIP and video nearly unusable as the tiny VoIP packets get queued behind the huge video packets, or as video traffic is queued with other data traffic. Finally, we touched on the fact that SIP was the underlying enabler for all UC applications. It only makes sense that we should keep an eye on the performance of SIP signaling and message flows. Within the SIP messaging performance, its important to understand what kind of Network Round Trip Time (NRTT) is typical between client UC applications and your UC servers. What is the server response time, and is it degrading over time?
112
www.netqos.com
A network performance product like NetQoS Performance Center can help answer these questions and report on underlying metrics that affect UC application performance. In Figure 4-6, weve created a Unified Communications Dashboard using the NetQoS Performance Center. The dashboard shows at a quick glance the UC Quality of Experience, a UC Bandwidth Analysis, and a view of SIP Messaging Performance.
Figure 4-6 A Unified Communications dashboard provides comprehensive view of UC performance.
The different views on the dashboard report provide insight into UC performance. The Call Quality Breakdown view provides a breakdown of audio calls and the user experience based on the MOS for those calls. The Call Performance by Location view shows ratings for audio and video performance metrics for calls in specific network locations. Selecting a location allows you to drill in and see the metric details, including key call-quality and call-setup metrics, measured on specific subnets. The Performance by Application view provides ratings for performance metrics associated with SIP messaging. Selecting the SIP Messaging applications allows you to drill in to see the details of salient metrics such as transaction time and network round trip time.
877.835.9575
113
Bandwidth analysis is provided by the Top Enterprise Protocols by Volume and Top Enterprise Hosts by Volume data views. With these views, we can see how much bandwidth is consumed by voice, video, and SIP. In addition, we can see who is consuming the bandwidth so that we can make performance-enhancing adjustments. For example, if video conferencing is using up a lot more bandwidth on two or three key links, we might need to move the conferencing server to another location.
Chapter Summary
Unified Communications is another in a long line of new applications that offer compelling features, all of which are accompanied by network performance ramifications. We always recommend that before you deploy a new networked application, first, understand its network performance requirements, and second, understand the potential impact on your existing applications. As applications like UC have increased user interaction, understanding the users quality of experience and being able to map that quality to performance levels for management and troubleshooting are crucial. Use monitoring tools to gain the visibility that you need to provide an excellent unified communications experience for your users.
114
www.netqos.com
References
1. Kelly, Brent. Do You See What I See in UC? Business Communications Review, November 2007. Posted on: http://www.nojitter.com/showArticle.jhtml?articleID=205901063 2. Cisco Website.
http://www.cisco.com/en/US/products/sw/voicesw/products_category_technologies_overview.html
3. Gregory, Peter. Unified Communications for Dummies, Avaya Custom Edition. Wiley Publishing, 2007. https://www1.avaya.com/forms/premcontent/us/index.html?cid=AVPC97D&urlc
ode=1336&revisit=0
4. Microsoft Website. http://www.microsoft.com/uc/what.mspx 5. Gartner. Magic Quadrant for Unified Communications, August 20, 2007. 6. Yankee Group Research, Inc. A Guide to Managing Enterprise Unified Communications, January 2007. 7. Ramanathan, Rajesh. How Presence Powers Microsoft OCS. Microsoft TechNet.
http://www.microsoft.com/technet/technetmag/issues/2008/02/OCSIM/default.aspx.
877.835.9575
115

VoIP Ebook PDF

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VoIP Ebook PDF

Загружено:

Авторское право:

Доступные форматы

Do You See What Im Saying?

Managing VoIP Quality of Experience on Your Network

2008 NetQoS, Inc.

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

How This Book Is Organized

VoIP: Do You See What Im Saying?

Here is what each chapter covers: Chapter 1

VoIP: Do You See What Im Saying?

A VoIP phone call occurs in two stages:

Do you know this already?

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

Call Setup Protocols

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

Proprietary Call Setup Protocols

VoIP: Do You See What Im Saying?

Cisco Skinny Client Control Protocol (SCCP)

Call Setup Ports

SCCP MGCP Q.931/Q.921 (PRI Backhaul) H.323 SIP UNIStim

TCP UDP TCP TCP TCP or UDP UDP

Table 1-1 Call setup transport protocols and ports.

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

Figure 1-3 RTP Header Format.

VoIP: Do You See What Im Saying?

Lost packets (fraction and cumulative number)

VoIP: Do You See What Im Saying?

Loss rate Gap density/duration Signal/noise level

Discard rate Round-trip delay Echo return loss

Burst density/duration End system delay R-factor and MOS

VoIP: Do You See What Im Saying?

Proprietary Call Quality Reporting

VoIP: Do You See What Im Saying?

VoIP and Network Performance

Traditional Networked Application Performance

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

Transaction Time or Response Time

Network round-trip time Network connection time

Retransmission delay Throughput/ Goodput

Table 1-2 Traditional networked application performance metrics.

VoIP: Do You See What Im Saying?

What Makes VoIP Traffic Different?

Real-time VoIP Characteristics

VoIP: Do You See What Im Saying?

VoIP: Do You See What Im Saying?

The Impact of VoIP on Other Applications

VoIP: Do You See What Im Saying?

Figure 1-6 Baseline transaction time for critical applications.

VoIP: Do You See What Im Saying?

VoIP Bandwidth Considerations

VoIP: Do You See What Im Saying?

G.711u G.711a G.729 RTAudio

64.0 kbps 64.0 kbps 8.0 kbps 29.0 kbps

87.2 kbps 87.2 kbps 31.2 kbps 45.0 - 74.0 kbps

Table 1-3 Bandwidth required by different codecs.

Figure 1-7 Bandwidth breakout by protocol, including VoIP traffic.