Chapter 7: Improving and Maintaining Voice Quality

• Identify problems presented by IP networks that affect voice and describe the QoS mechanisms used to address those problems.

• Set up basic QoS configurations, on both Cisco IOS-based Catalyst switches and routers, using Cisco’s AutoQoS feature.

• Implement call control on the network using CAC tools and mechanisms.

When human speech is converted to analog electrical signals and then digitized and compressed, some of the qualitative components are lost. This chapter explores the components of voice quality that you must maintain, the methods that you can use to measure voice quality, and quality of service (QoS) tools that you can implement in a network to improve voice quality.

Optimizing Voice Quality

Because of the inherent characteristics of a converged voice and data IP network, administrators face certain challenges in delivering voice traffic correctly. This section describes these challenges and offers solutions for avoiding and overcoming them when designing a VoIP network for optimal voice quality.

Factors that Affect Voice Quality

Because of the nature of IP networking, voice packets sent via IP are subject to certain transmission problems. Conditions present in the network might introduce problems such as echo, jitter, or delay. These problems must be addressed with QoS mechanisms.

The clarity, or cleanliness and crispness, of the audio signal is of utmost importance. The listener must be able to recognize the speaker’s identity and sense the mood of the speaker. These factors can affect clarity:

• Fidelity—The degree to which a system, or a portion of a system, accurately reproduces, at its output, the essential characteristics of the signal impressed upon its input or the result of a prescribed operation on the signal impressed upon its input (definition from the Alliance for Telecommunications Industry Solutions [ATIS]). The bandwidth of the transmission medium almost always limits the total bandwidth of the spoken voice. Human speech typically requires a bandwidth from 100 to 10,000 Hz, although 90 percent of speech intelligence is contained between 100 and 3000 Hz.

• Echo—A result of electrical impedance mismatches in the transmission path. Echo is always present, even in traditional telephony networks, but at a level that cannot be detected by the human ear. The two components that affect echo are amplitude (that is, loudness of the echo) and delay (that is, the time between the spoken voice and the echoed sound). You can control echo using echo suppressors or echo cancellers.

• Jitter—Variation in the arrival of coded speech packets at the far end of a VoIP network. The varying arrival time of the packets can cause gaps in the re-creation and playback of the voice signal. These gaps are undesirable and annoy the listener. Delay is induced in the network by variation in the routes of individual packets, contention, or congestion. You can often resolve variable delay by using dejitter buffers.

• Packet drops—The discarding of voice packets. Typically, when a VoIP packet is dropped from a network, 20 ms of audio is lost.

• Delay—The time between the spoken voice and the arrival of the electronically delivered voice at the far end. Delay results from multiple factors, including distance (that is, propagation delay), coding, compression, serialization, and buffering.

• Sidetone—The purposeful design of the telephone that allows the speaker to hear the spoken audio in the earpiece. Without sidetone, the speaker is left with the impression that the telephone instrument is not working.

• Background noise—The low-volume audio that is heard from the far-end connection. Certain bandwidth-saving technologies can eliminate background noise altogether, such as voice activity detection (VAD). When this technology is implemented, the speaker audio path is open to the listener, while the listener audio path is closed to the speaker. The effect of VAD is often that speakers think that the connection is broken, because they hear nothing from the other end.

Although each of the preceding factors affects audio clarity, factors that present the greatest challenges to VoIP networks include jitter, delay, and packet drops. A lack of network bandwidth is usually the underlying cause for these issues, which are addressed in the following sections.

Jitter

Jitter is defined as a variation in the delay of received packets, as illustrated in Figure 7-1. On the sending side, packets are sent in a continuous stream with the packets spaced evenly. Because of network congestion, improper queuing, or configuration errors, this steady stream can become uneven, because the delay between each packet varies instead of remaining constant.

When a router receives a VoIP audio stream, it must compensate for the jitter that is encountered. The mechanism that handles this function is the playout delay buffer, or dejitter buffer. The playout delay buffer must buffer these packets and then play them out in a steady stream to the digital signal processors (DSPs) to be converted back to an analog audio stream. The playout delay buffer, however, affects the overall absolute delay.

When a conversation is subjected to jitter, the results can be clearly heard. If the talker says, “Watson, come here. I want you,” the listener might hear “Wat….s…on…….come here, I……wa……nt……..y……ou.” The variable arrival of the packets at the receiving end causes the speech to be delayed and garbled.

Figure 7-1

Jitter in IP Networks

Delay

Overall or absolute delay can affect VoIP. You might have experienced delay in a telephone conversation with someone on a different continent. The delays can cause entire words in the conversation to be cut off, and can therefore be very frustrating.

When you design a network that transports voice over packet, frame, or cell infrastructures, it is important to understand and account for the predictable delay components in the network. You must also correctly account for all potential delays to ensure that overall network performance is acceptable. Overall voice quality is a function of many factors, including the compression algorithm, errors and frame loss, echo cancellation, and delay.

Figure 7-2 shows various sources and types of delay. Notice that there are two distinct types of delay:

• Fixed delay components are predictable and add directly to overall delay on the connection. Fixed delay components include the following:

• — Coding—The time it takes to translate the audio signal into a digital signal

  — Packetization—The time it takes to put digital voice information into packets and remove the information from packets

  — Serialization—The insertion of bits onto a link

  — Propagation—The time it takes a packet to traverse a link

• Variable delays arise from queuing delays in the egress trunk buffers that are located on the serial port connected to the WAN. These buffers create variable delays (that is, jitter) across the network.

Figure 7-2

Sources of Delay

Acceptable Delay

The ITU specifies network delay for voice applications in Recommendation G.114. This recommendation defines three bands of one-way delay, as shown in Table 7-1.

Table 7-1  Components and Services

---

Note – This recommendation is for connections where echo is adequately controlled, implying that echo cancellers are used. Echo cancellers are required when one-way delay exceeds 25 ms (G.131).

---

This G.114 recommendation is oriented toward national telecommunications administrations and therefore is more stringent than recommendations that would normally be applied in private voice networks. When the location and business needs of end users are well known to a network designer, more delay might prove acceptable. For private networks, a 200 ms delay is a reasonable goal and a 250 ms delay is a limit. This goal is what Cisco proposes as reasonable, as long as excessive jitter does not impact voice quality. However, all networks must be engineered so that the maximum expected voice connection delay is known and minimized.

The G.114 recommendation is for one-way delay only and does not account for round-trip delay. Network design engineers must consider both variable and fixed delays in their design. Variable delays include queuing and network delays, while fixed delays include coding, packetization, serialization, and dejitter buffer delays. Table 7-2 provides an example of a delay budget calculation.

Table 7-2 Sample Delay Budget

Packet Loss

Lost data packets, as depicted in Figure 7-3 are recoverable if the endpoints can request retransmission. However, lost voice packets are not recoverable, because the audio must be played out in real time and retransmission is not an option.

Figure 7-3

Packet Loss

Voice packets might be dropped under the following conditions:

• The network is unstable (flapping links).

• The network is congested.

• There is too much variable delay in the network.

Packet loss causes voice clipping and skips. As a result, the listener hears gaps in the conversation. The industry-standard coder-decoder (CODEC) algorithms used in Cisco DSPs correct for 20–50 ms of lost voice through the use of Packet Loss Concealment (PLC) algorithms. PLC intelligently analyzes missing packets and generates a reasonable replacement packet to improve the voice quality. Cisco VoIP technology uses 20 ms samples of voice payload per VoIP packet by default. Effective CODEC correction algorithms require that only a single packet can be lost at any given time. If more packets are lost, the listener experiences gaps.

If a conversation experiences packet loss, the effect is immediately heard. If the talker says, “Watson, come here. I want you,” the listener might hear, “Wat…., come here, ……you.”

Quality Metrics

Quality must be measurable in order to be manageable. Three quality metrics include the Mean Opinion Score (MOS), the Perceptual Speech Quality Measurement (PSQM), and the Perceptual Evaluation of Speech Quality (PESQ).

MOS

MOS is a scoring system for voice quality. An MOS score is generated when listeners evaluate prerecorded sentences that are subject to varying conditions, such as compression algorithms. Listeners then assign the sentences values, based on a scale from 1 to 5, where 1 is the worst and 5 is the best. The sentence used for English language MOS testing is, “Nowadays, a chicken leg is a rare dish.” This sentence is used because it contains a wide range of sounds found in human speech, such as long vowels, short vowels, hard sounds, and soft sounds.

The test scores are then averaged to a composite score. The test results are subjective because they are based on the opinions of the listeners. The tests are also relative, because a score of 3.8 from one test cannot be directly compared to a score of 3.8 from another test. Therefore, a baseline needs to be established for all tests, such as G.711, so that the scores can be normalized and compared directly.

PSQM

PSQM is an automated method of measuring speech quality “in service,” or as the speech happens. PSQM software usually resides with IP call-management systems, which are sometimes integrated into Simple Network Management Protocol (SNMP) systems.

Equipment and software that can measure PSQM is available through third-party vendors but is not implemented in Cisco devices. The PSQM measurement is made by comparing the original transmitted speech to the resulting speech at the far end of the transmission channel. PSQM systems are deployed as in-service components. The PSQM measurements are made during real conversation on the network. This automated testing algorithm has over 90 percent accuracy compared to subjective listening tests, such as MOS. Scoring is based on a scale from 0 to 6.5, where 0 is the best and 6.5 is the worst. Because it was originally designed for circuit-switched voice, PSQM does not take into account the jitter or delay problems that are experienced in packet-switched voice systems.

PESQ

MOS and PSQM are not recommended for present-day VoIP networks. Both were originally designed before the emergence of VoIP technologies and do not measure typical VoIP problems such as jitter and delay. For example, it is possible to obtain an MOS score of 3.8 on a VoIP network when the one-way delay exceeds 500 ms, because the MOS evaluator has no concept of a two-way conversation and listens only to audio quality. The one-way delay is not evaluated.

PESQ, whose operation is illustrated in Figure 7-4, was originally developed by British Telecom, Psytechnics, and KPN Research of the Netherlands. It has evolved into ITU Standard P.862, which is considered the current standard for voice quality measurement. PESQ can take into account CODEC errors, filtering errors, jitter problems, and delay problems that are typical in a VoIP network. PESQ combines the best of the PSQM method along with a method called Perceptual Analysis Measurement System (PAMS). PESQ scores range from 1 (worst) to 4.5 (best), with 3.8 considered “toll quality” (that is, acceptable quality in a traditional telephony network). PESQ is meant to measure only one aspect of voice quality. The effects of two-way communication, such as loudness loss, delay, echo, and sidetone, are not reflected in PESQ scores.

Figure 7-4

PESQ

Many equipment vendors offer PESQ measurement systems. Such systems are either stand-alone or they plug into existing network management systems. PESQ was designed to mirror the MOS measurement system. So, if a score of 3.2 is measured by PESQ, a score of 3.2 should be achieved using MOS methods.

Quality Measurement Comparison

Early quality measurement methods, such as MOS and PSQM, were designed before widespread acceptance of VoIP technology. PESQ was designed to address the shortcomings of MOS and PSQM.

MOS uses subjective testing where the average opinion of a group of test users is calculated to create the MOS score. This method is both time-consuming and expensive, and might not provide consistent results between groups of testers.

PSQM and PESQ use objective testing where an original reference file sent into the system is compared with the impaired signal that came out. This testing method provides an automated test mechanism that does not rely on human interpretation for result calculations. However, PSQM was originally designed for circuit-switched networks and does not take into account the effects of jitter and packet loss.

PESQ measures the effect of end-to-end network conditions, including CODEC processing, jitter, and packet loss. Therefore, PESQ is the preferred method of testing voice quality in an IP network. Table 7-3 offers a comparison of the various quality metrics.

Table 7-3 Voice Quality Measurement Comparison

Objectives of QoS

To ensure that VoIP is an acceptable replacement for standard public switched telephone network (PSTN) telephony services, customers must receive the same consistently high quality of voice transmission that they receive with basic telephone services.

Like other real-time applications, VoIP is extremely sensitive to issues related to bandwidth and delay. To ensure that VoIP transmissions are intelligible to the receiver, voice packets cannot be dropped, excessively delayed, or subjected to variations in delay (that is, jitter).

VoIP guarantees high-quality voice transmission only if the signaling and audio channel packets have priority over other kinds of network traffic. A successful VoIP deployment must provide an acceptable level of voice quality by meeting VoIP traffic requirements for issues related to bandwidth, latency, and jitter. QoS provides better, more predictable network service by performing the following:

• Supporting dedicated bandwidth—Designing the network such that the necessary bandwidth is always available to support voice and data traffic

• Improving loss characteristics—Designing a Frame Relay network such that discard eligibility is not a factor for frames containing voice, keeping voice below the committed information rate (CIR)

• Avoiding and managing network congestion—Ensuring that the LAN and WAN infrastructure can support the volume of data traffic and voice calls

• Shaping network traffic—Using Cisco traffic-shaping tools to ensure smooth and consistent delivery of frames to the WAN

• Setting traffic priorities across the network—Marking the voice traffic as priority traffic and queuing it first

Cisco routers support multiple QoS mechanisms that can be leveraged to accomplish the objectives listed in the preceding bullet points. The following sections detail specific QoS mechanisms and caution against poor design characteristics.

Using QoS to Improve Voice Quality

Voice features that provide QoS are deployed at different points in the network and are designed for use with other QoS features to achieve specific goals, such as minimization of jitter and delay. Cisco IOS includes a complete set of features for delivering QoS throughout the network. Following are a few examples of Cisco IOS features that address the voice packet delivery requirements of end-to-end QoS and service differentiation:

• The output queue of the router can use the following QoS mechanisms:

• — Class-based weighted fair queuing (CBWFQ)—Extends the standard Weighted Fair Queuing (WFQ) functionality by providing support for user-defined traffic classes. You can create a specific class for voice traffic by using CBWFQ.

  — Low latency queuing (LLQ)—Provides strict priority queuing in conjunction with CBWFQ. LLQ configures the priority status for a class within CBWFQ, in which voice packets receive priority over all other traffic. LLQ is considered a “best practice” by the Cisco Enterprise Solutions Engineering (ESE) group for delivering voice QoS services over a WAN.

  — Weighted fair queuing (WFQ)—Segregates traffic into flows and then schedules traffic to meet specified bandwidth allocation or delay bounds.

  — Weighted random early detection (WRED)—Provides differentiated performance characteristics for different classes of service. Specifically, WRED drops lower-priority traffic more aggressively than higher-priority traffic, as an interface’s output queue begins to become congested.

• The WAN or WAN protocol can use the following QoS mechanisms:

• — Class-based policing —Provides a rate-limiting feature for allocating bandwidth commitments and bandwidth limitations to traffic sources and destinations. At the same time, it specifies policies for handling the traffic that might exceed bandwidth allocation.

  ---

  Note – Class-based policing typically replaces the rate-limiting feature previously provided by the committed access rate (CAR) feature.

  ---

  — Traffic shaping—Delays excess traffic by using a buffer or queuing mechanism to hold packets and shape the flow when the data rate of the source is higher than expected.

  — Frame Relay Forum 12 (FRF.12)—Ensures predictability for voice traffic by providing better throughput on low-speed Frame Relay links (that is, link speeds less than 768 kbps). FRF.12 interleaves delay-sensitive voice traffic with fragments of a long frame.

  — Multilink PPP (MLP)—Allows large packets to be multilink encapsulated, fragmented, and interleaved so that they are small enough to satisfy the delay requirements of real-time traffic.

VoIP traffic can use the following QoS mechanisms:

— Compressed Real-Time Transport Protocol (cRTP)—The Real-Time Transport Protocol (RTP) is a protocol for the transport of real-time traffic, including voice. RTP uses extensive headers that incorporate time stamps for individual packets. The cRTP feature compresses the extensive RTP header. The result is decreased consumption of available bandwidth for voice traffic and a corresponding reduction in delay.

— Resource Reservation Protocol (RSVP)—RSVP supports the reservation of resources across an IP network, allowing end systems to request QoS guarantees from the network. For networks that support VoIP, RSVP—in conjunction with features that provide queuing, traffic shaping, and voice call signaling—provides Call Admission Control (CAC) for voice traffic.

Recognizing Common Design Faults

Successful implementations of delay-sensitive applications such as VoIP require a network that is carefully engineered with QoS from end to end. Fine-tuning the network to adequately support VoIP involves a series of protocols and features geared toward improving voice quality.

QoS is the ability of a network to provide better service levels to selected network traffic over various underlying technologies. However, QoS is not inherent in a network infrastructure. Instead, QoS is implemented by strategically enabling appropriate QoS features throughout the network.

Poor design is characterized by the following issues:

• Ignoring Layer 2 QoS requirements—QoS technologies such as priority Layer 2 congestion management, FRF.12, Link Fragmentation and Interleaving (LFI), and traffic shaping must be correctly configured.

• Ignoring other QoS requirements—QoS technologies such as LLQ, RTP, congestion management, and congestion avoidance must be enabled.

• Ignoring bandwidth considerations—Planning for the total number of calls and their effect on data bandwidth is critical to all users of the network.

• Simply adding VoIP to an existing IP network—When considering VoIP, network administrators might need to insist on a complete network redesign for a comprehensive end-to-end solution.

Many people believe that the fastest way to fix network performance is simply to add a lot of bandwidth. That approach might work well in certain situations like campus networks, in which upgrading from 10 Mbps to 100 Mbps or even 1 GB links might be possible. However, it is not always feasible to add bandwidth in a WAN. Upgrading a WAN circuit from 56 kbps to T1 might be cost prohibitive and might not be possible for certain locations on the network. To provide effective performance in a voice network, you should configure QoS throughout the network, not just on the devices running VoIP. Not all QoS techniques are appropriate for all network routers. Edge routers and backbone routers in a network do not necessarily perform the same operations. The QoS tasks these routers perform might differ as well. To configure an IP network for real-time voice traffic, you should consider the functions of both edge and backbone routers and select the appropriate QoS tools accordingly.

AutoQoS

Cisco AutoQoS minimizes the complexity, time, and operating cost of QoS deployment. Cisco AutoQoS incorporates value-added intelligence into Cisco IOS software and Cisco Catalyst Operating System software to provision and manage large-scale QoS deployments. This section focuses on the Cisco IOS implementation of AutoQoS, on both router and Catalyst switch platforms.

AutoQoS Features

To expedite QoS deployment, the user interface must be simplified. Cisco AutoQoS addresses this issue by automating the following five main aspects of QoS deployment while maintaining a tunable solution:

• Application classification—Cisco AutoQoS identifies VoIP control and bearer traffic. Cisco AutoQoS uses Cisco Discovery Protocol (CDP) to ensure that the device attached to the LAN is really an IP phone.

• Policy generation—Cisco AutoQoS evaluates the network environment and automatically generates an initial policy on a given interface, port, or permanent virtual circuit (PVC).

• Configuration—With one command, Cisco AutoQoS configures a port to prioritize voice traffic without affecting other network traffic, while still offering the flexibility to adjust QoS settings for unique network environments. QoS settings are automatically disabled when a Cisco IP phone is relocated or moved.

• Monitoring and reporting—Cisco AutoQoS provides visibility into the classes of service deployed via system logging and SNMP traps.

• Consistency—Cisco AutoQoS policies are designed to work in harmony with each other across Cisco devices, ensuring consistent end-to-end QoS.

The increased deployment of delay-sensitive applications in networks (for example, voice, video, and other multimedia applications) requires proper QoS configuration to ensure application performance.

Before the availability of Cisco AutoQoS, proper QoS configuration of a network required a deep understanding of various QoS features (that is, queuing, dropping, traffic conditioning, queue depth, drop thresholds, burst parameters, LFI, and RTP). The use of Cisco AutoQoS helps minimize the complexity of configuring a network correctly for QoS by automatically configuring a device with the correct QoS parameters. Cisco AutoQoS automates consistent deployment of QoS features across Cisco routers and switches. It enables various Cisco QoS components based on the network environment and Cisco best-practice recommendations.

Users can subsequently tune parameters generated by Cisco AutoQoS to suit their particular application needs.

Cisco AutoQoS can perform the following functions on WAN interfaces:

• Automatically classifies RTP payload and VoIP control packets (H.323, H.225 Unicast, Skinny Client Control Protocol [SCCP], session initiation protocol [SIP], and Media Gateway Control Protocol [MGCP])

• Builds service policies for VoIP traffic that are based on Cisco’s Modular QoS Command-Line Interface (MQC) configuration approach

• Provisions LLQ priority queuing for VoIP bearer and bandwidth guarantees for control traffic

• Enables WAN traffic shaping that adheres to Cisco best practices, where required

• Enables link efficiency mechanisms, such as LFI and RTP header compression (cRTP), where required

• Provides SNMP and syslog alerts for VoIP packet drops

Cisco AutoQoS can perform the following functions on LAN interfaces:

• Enforce the trust boundary on Cisco Catalyst switch access ports, uplinks, and downlinks

• Enable Cisco Catalyst strict priority queuing (also known as expedite queuing) with weighted round-robin (WRR) scheduling for voice and data traffic, where appropriate

• Configure queue admission criteria (that is, maps Layer 2 CoS priority markings in incoming packets to the appropriate queues)

• Modify queue sizes and weights where required

---

Note – Cisco AutoQoS is available in the following Cisco IOS software releases—Cisco IOS Software Release 12.1E or later for the Cisco Catalyst 2950 and 3550 Series switches; Cisco IOS Software Release 12.2T or later for the Cisco 2600, 2600XM, 3600, 3700, and 7200 Series routers; Cisco IOS Software Release 12.1E or later for the Cisco Catalyst 4500 Series switches; and Cisco Catalyst Operating System 7.5.1 or later for the Cisco Catalyst 6500 Series switches. For current information concerning AutoQoS platform support, check Cisco’s Feature Navigator at https://www.cisco.com/go/fn.

---

Configuring AutoQoS on a Router

On a router platform, the following command enables AutoQoS from either interface configuration mode or from DLCI configuration mode (for a Frame Relay circuit):

Router(config-if)#auto qos voip [trust] [fr-atm]

The trust option indicates that AutoQos should classify voice traffic based on Layer 3 Differentiated Services Code Point (DSCP) priority markings, instead of using Network-Based Application Recognition (NBAR). The fr-atm option enables the AutoQoS feature for Frame Relay-to-ATM links and is issued from DLCI configuration mode.

Before enabling AutoQoS on a router interface, consider the following prerequisites:

• Cisco Express Forwarding (CEF) must be enabled, because AutoQoS uses NBAR, which requires the CEF feature.

• A QoS policy must not be currently attached to the interface.

• The correct bandwidth should be configured on the interface, using the bandwidth command.

• An IP address must be configured on an interface if its speed is less than 768 kbps.

• The interface must not be administratively shut down.

Note that the interface’s bandwidth determines which AutoQoS features are enabled. If an interface’s bandwidth is less than 768 kbps, it is considered a low-speed interface. On a low-speed interface, AutoQoS configures Multilink PPP (MLP), which requires an IP address on the physical interface. AutoQoS takes the IP address from the physical interface and uses it for the virtual multilink interface that it creates.

To verify that AutoQoS is configured for a router interface, use the following command:

Router#show auto qos [interface interface-identifier]

To illustrate some of the configuration changes that AutoQoS can perform, consider the configuration of a serial interface shown in Example 7-1, without AutoQoS enabled.

Example 7-1  Router Configuration Without AutoQoS

interface Serial0/0
 bandwidth 128
 ip address 10.1.1.1 255.255.255.0
 encapsulation ppp

Example 7-2 illustrates the configuration changes after entering the auto qos voip command for interface Serial 0/0.

Example 7-2 Router Configuration with AutoQoS

class-map match-any AutoQoS-VoIP-Remark
class-map match-any AutoQoS-VoIP-Remark
 match ip dscp ef 
 match ip dscp cs3 
 match ip dscp af31 
class-map match-any AutoQoS-VoIP-Control-UnTrust
 match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
 match protocol rtp audio 
 match access-group name AutoQoS-VoIP-RTCP
!
policy-map AutoQoS-Policy-UnTrust
 class AutoQoS-VoIP-RTP-UnTrust
  priority percent 70
  set dscp ef
 class AutoQoS-VoIP-Control-UnTrust
  bandwidth percent 5
  set dscp af31
 class AutoQoS-VoIP-Remark
  set dscp default
 class class-default
  fair-queue
!
interface Multilink2001100114
 bandwidth 128
 ip address 10.1.1.1 255.255.255.0
 service-policy output AutoQoS-Policy-UnTrust
 ip tcp header-compression iphc-format
 ppp multilink
 ppp multilink fragment delay 10
 ppp multilink interleave
 ppp multilink group 2001100114
 ip rtp header-compression iphc-format
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation ppp
 auto qos voip 
 clockrate 128000
 no fair-queue
 ppp multilink
 ppp multilink group 2001100114
!
ip access-list extended AutoQoS-VoIP-Control
 permit tcp any any eq 1720
 permit tcp any any range 11000 11999
 permit udp any any eq 2427
 permit tcp any any eq 2428
 permit tcp any any range 2000 2002
 permit udp any any eq 1719
 permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
 permit udp any any range 16384 32767
!
rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Drops" 
owner AutoQoS
rmon alarm 33333 cbQosCMDropBitRate.1081.1083 30 absolute rising-threshold 1 33333
falling-threshold 0 owner AutoQoS

The bandwidth configured for interface Serial 0/0 was set to 128 kbps. Therefore, AutoQoS determined that certain link efficiency mechanisms (for example, Multilink PPP, RTP Header Compression, and TCP Header Compression) were appropriate. AutoQoS, therefore, automatically configured these link efficiency mechanisms in addition to multiple other QoS mechanisms, including classification, marking, LLQ, and Remote Monitoring (RMON) traps to alert administrators if packet drops are excessive.

AutoQoS for Enterprise

Introduced in Cisco IOS Software Release 12.3(7)T, AutoQoS for Enterprise extends the capabilities of AutoQoS on a Cisco router platform. Specifically, AutoQoS for Enterprise allows a router to recognize multiple protocols traversing an interface and recommends a customized policy, based on learned traffic patterns.

To configure a router’s interface to begin learning traffic patterns, enter the following command in interface configuration mode:

Router(config-if)#auto discovery qos

After entering the previous command, wait for a period of time for the router to learn the traffic patterns crossing the interface. The ability to dynamically learn these patterns is made possible by the Cisco IOS software’s NBAR feature.

After waiting a period of time (for example, 30 minutes to an hour in a time period representative of peak network usage) during which the router is learning the traffic patterns of the network, enter the following command to view the router’s findings and to see the recommended policy for the interface:

Router#show auto discovery qos

Example 7-3 offers an example of the output received after issuing the show auto discovery qos command.

Example 7-3 Output from the show auto discovery qos Command

R4#show auto discovery qos
Serial0/0       
 AutoQoS Discovery enabled for applications
 Discovery up time—46 seconds
 AutoQoS Class information:
 Class Voice—
 Recommended Minimum Bandwidth—40 Kbps/31% (PeakRate)
 Detected applications and data:
 Application/    AverageRate    PeakRate      Total       
 Protocol        (kbps/%)       (kbps/%)      (bytes)      
 -----------     -----------    --------      ------------   
 rtp audio       28/21          40/31          161160      
 Class Interactive Video—
 No data found.
 Class Signaling—
 Recommended Minimum Bandwidth—0 Kbps/0% (AverageRate)
 Detected applications and data:
 Application/   AverageRate    PeakRate      Total       
 Protocol       (kbps/%)       (kbps/%)      (bytes)      
 -----------    -----------    --------      ------------   
 skinny         0/0            0/0           3648       
 Class Streaming Video—
  No data found.
 Class Transactional—
  No data found.
 Class Bulk—
  No data found.
 Class Scavenger—
  No data found.
 Class Management—
  No data found.
 Class Routing—
  Recommended Minimum Bandwidth—0 Kbps/0% (AverageRate)
  Detected applications and data:
  Application/    AverageRate    PeakRate      Total       
  Protocol        (kbps/%)       (kbps/%)      (bytes)      
  -----------     -----------    --------      ------------   
  eigrp           0/0            0/0           640        
  icmp            0/0            0/0           120        
 Class Best Effort—
  Current Bandwidth Estimation—77 Kbps/60% (AverageRate)
  Detected applications and data:
  Application/    AverageRate    PeakRate      Total       
  Protocol        (kbps/%)       (kbps/%)      (bytes)  
  -----------     -----------    --------      ------------      
  http            77/60          110/85        446413      
  unknowns        0/0            0/0           104        
  
Suggested AutoQoS Policy for the current uptime:
 !
 class-map match-any AutoQoS-Voice-Se0/0
 match protocol rtp audio
 !
 policy-map AutoQoS-Policy-Se0/0
 class AutoQoS-Voice-Se0/0
  priority percent 31
  set dscp ef
 class class-default
fair-queue

If you find the suggested policy acceptable and wish to apply the dynamically created policy, go into interface configuration mode for the monitored interface and enter the following command:

Router(config-if)#auto qos

This auto qos command applies the recommended policy to the router.

Configuring AutoQoS on a Catalyst Switch

The QoS mechanisms on a Catalyst switch differ from those QoS mechanisms found on a router. For example, while a router uses LLQ as a priority queuing strategy, a Catalyst switch might use weighted round-robin (WRR) as a priority queuing strategy. Fortunately, the AutoQoS feature available on some Catalyst switch models (for example, the Cisco Catalyst 2950(EI) and 3550 Series) apply voice-specific QoS features globally to a Catalyst switch and also at the port level.

To configure AutoQoS on supported Catalyst switch platforms (running the Native IOS), issue the following command from interface configuration mode:

Switch(config-if)#auto qos voip [trust | cisco-phone]

If the trust option is used in the previous command, the Catalyst switch makes queuing decisions based on Layer 2 Class of Service (CoS) markings. However, if the cisco-phone option is used, the Catalyst switch makes queuing decisions based on CoS markings originating from a Cisco IP phone. The switch detects the presence of a Cisco IP phone via the CDP.

To illustrate the configuration changes made by a Catalyst switch’s AutoQoS feature, consider Example 7-4, which shows the initial configuration of interface Gigabit 0/1 on a Catalyst 3550 switch.

Example 7-4 Catalyst Switch Configuration Without AutoQoS

interface GigabitEthernet0/1
 no ip address

Example 7-5 illustrates the configuration changes after entering the auto qos voip cisco-phone command for interface Gigabit 0/1.

Example 7-5 Catalyst Configuration with AutoQoS

mls qos map cos-dscp 0 8 16 26 32 46 48 56
mls qos
!
interface GigabitEthernet0/1
 no ip address
 mls qos trust device cisco-phone
 mls qos trust cos
 auto qos voip cisco-phone 
 wrr-queue bandwidth 20 1 80 1
 wrr-queue queue-limit 80 1 20 1
 wrr-queue cos-map 1 0 1 2 4
 wrr-queue cos-map 3 3 6 7
 wrr-queue cos-map 4 5
 priority-queue out

Example 7-5 demonstrates that the AutoQoS feature configured the Catalyst switch to enable QoS globally (with the mls qos command) and remark Layer 2 CoS markings to Layer 3 Differentiated Services Code Point (DSCP) markings (with the mls qos map cos-dscp command). Also, AutoQoS configured WRR for interface Gigabit 0/1 and placed traffic with a CoS value of 5 (that is, voice traffic) in a priority queue, which is emptied ahead of other queues.

Implementing Call Admission Control

To prevent oversubscription of VoIP networks, the number of voice calls allowed on the network must be limited. This section describes the configuration parameters for implementing CAC, which can prevent oversubscription of WAN resources.

Effects of Bandwidth Oversubscription

QoS tools such as queuing ensure that voice traffic receives priority over data traffic. However, if a network link is oversubscribed with too much voice traffic, data packets are dropped, and the remaining voice calls suffer because they must compete for bandwidth available to the low-latency queue.

Figure 7-5 illustrates the effect of voice oversubscription. Using LLQ, voice traffic is directed into a priority queue (PQ) while all other traffic is directed into various CBWFQ queues. Note that the priority queue forwards packets while the data packets, destined for the CBWFQ queues, are denied entry to the queue and are dropped. In the case shown in Figure 7-5, even the priority queue buffer is full. Therefore, the voice packets are competing with other voice packets for access to the network link. This situation results in a degradation of all voice calls on this link.

Figure 7-5

Effect of Oversubscription

CAC Operation

CAC can function on the outgoing gateway and base its decision on nodal information, such as the state of the outgoing LAN or WAN link. For example, if the local IP network link is down, there is no point in executing complex decision logic based on the state of the rest of the network, because the network is unreachable.

As another example, if the network designer already knows that bandwidth limitations allow no more than two calls across the outgoing WAN link, as illustrated in Figure 7-6, then the local node can be configured to allow no more than two calls. You can configure this type of CAC on outgoing dial peers.

Figure 7-6

The Need for CAC

RSVP

RSVP is the only CAC mechanism that makes actual bandwidth reservations for calls. RSVP offers the unique advantage of not only providing CAC for voice but also guarantees the QoS against changing network conditions for the duration of the call. The RSVP reservation is made in both directions because a voice call requires a two-way speech path. Therefore, bandwidth is reserved in both directions, as depicted in Figure 7-7.

Figure 7-7

RSVP

The terminating gateway ultimately makes the CAC decision based on whether both reservations succeed. At that point, H.323 continues with either an H.225 Alerting/Connect (the call is allowed and proceeds), or with an H.225 Reject/Release (the call is denied). The RSVP reservation is in place by the time the destination phone starts ringing and the caller hears ringback.

RSVP has the following important differences from other CAC methods discussed in this section:

• RSVP can maintain QoS for the duration of the call.

• RSVP is aware of topology. In theory, the RSVP reservation is installed on every interface that the call passes through as it traverses the network. RSVP ensures bandwidth over every segment without any requirement to know the actual bandwidth provisioning on each interface or the path on which the routing protocols direct the packets. RSVP, therefore, adjusts automatically to network configuration changes, and no manual calculations are necessary to keep different aspects of the configuration synchronized.

• To function correctly, RSVP is dependent on the correct configuration of all devices in the network. However, RSVP might introduce a scaling issue depending on how the network is designed.

• RSVP provides end-to-end reservations per call and has visibility for that call only. RSVP is unaware of how many other calls are active from a site or across an interface, or the source or destination of any other call.

Configuring RSVP in Cisco routers allows the administrator to limit the amount of bandwidth requested per call and the total amount of bandwidth allowed for all calls. This configuration is entered directly against the interface that will permit or deny the calls. The configuration also requires RSVP to be configured on the dial peers for the calls that will be managed by RSVP.

CAC Tools

As the various aspects of CAC on IP networks have been considered, several different solutions have come into prominence. None of them solves the entire problem, but they all are useful to address a particular aspect of CAC. Unlike circuit-based networks, which reserve a free digital service level zero (DS0) time slot on every leg of the path that the call will take, determining whether an IP network has the resources to carry a voice call is not a simple undertaking.

There are four areas in which CAC can be implemented:

• H.323 CAC

• Session initiation protocol (SIP) CAC

• Media Gateway Control Protocol (MGCP) CAC

• Cisco Unified CallManager CAC

H.323 CAC

The CAC for the H.323 VoIP gateways feature allows you to configure thresholds for local resources, memory, and CPU resources. With the call threshold command, you can configure two thresholds, high and low, for each resource. Call treatment is triggered when the current value of a resource exceeds the configured high. The call treatment remains in effect until the current resource value falls below the configured low. Having high and low thresholds prevents call admission flapping and provides hysteresis in call admission decision making. Hysteresis is a phenomenon in which the response of a physical system to an external influence depends not only on the present magnitude of that influence but also on the previous history of the system.

With the call spike command, you can configure the limit for incoming calls during a specified time period. A call spike occurs when a large number of incoming calls arrive from the public switched telephone network (PSTN) in a very short period of time (for example, 100 incoming calls in 10 ms).

With the call treatment command, you can select how the call should be treated when local resources are not available to handle the call. For example, when the current resource value for any one of the configured triggers for call threshold has exceeded the configured threshold, the call treatment choices are as follows:

• Time-division multiplexing (TDM) hairpinning—Hairpins the calls through the plain old telephone service (POTS) dial peer

• Reject—Disconnects the call

• Play message or tone—Plays a configured message or tone to the user

To enable the global resources of this gateway, use the call threshold command in global configuration mode. To disable this command, use the no form of this command.

call threshold {global trigger-name | interface interface-name interface-number 
int-
calls} low value high value [busyout | treatment] 
no call threshold {global trigger-name | interface interface-name int-calls}

Table 7-4 shows the call threshold command options.

Table 7-4 call threshold Commands

To configure the limit of incoming calls in a short period of time, use the call spike command in global configuration mode. To disable this command, use the no form of this command. The call spike command uses a sliding window to determine the period in which the spike is limited. The sliding window period is defined using the size command, with valid ranges from 100 to 250 ms. If a longer spike period is desired, the steps command is used as a multiplier for the size command. For example, if the steps were set to 2 and the size was set to 250, the spike period would be 500 ms.

call spike call-number [steps number-of-steps size milliseconds] 
no call spike

Table 7-5 details the call spike command options.

Table 7-5 call spike Commands

To configure how calls should be processed when local resources are unavailable, use the call treatment global configuration mode command. To disable the call treatment triggers, use the no form of this command.

call treatment {on | action action [value] | cause-code cause-code | isdn-reject 
value} 
no call treatment {on | action action [value] | cause-code cause-code | isdn-reject value}

Table 7-6 shows the call treatment command options.

Table 7-6 call treatment Commands

ISDN cause codes that can be used in the isdn-reject value command are presented in Table 7-7.

Table 7-7  ISDN Cause Codes

Consider a few examples of H.323 CAC commands:

• The following example busies out the total-calls resource if 5 (low) or 5000 (high) is reached:

• call threshold global total-calls low 5 high 5000 busyout
  

• The following example enables thresholds of 5 (low) and 2500 (high) for interface calls on interface Ethernet 0:

• call threshold interface Ethernet 0 int-calls low 5 high 2500
  

• The following example busies out the average CPU utilization if 5 percent (low) or 65 percent (high) is reached:

• call threshold global cpu-avg low 5 high 65 busyout
  

• The following configuration of the call spike command has a call number of 30, 10 steps, and a step size of 2000 ms:

• call spike 30 steps 10 size 2000
  

• The following example enables the call treatment feature with a hairpin action:

• call treatment on
  call treatment action hairpin
  

• The following example displays the proper formatting of the playmsg action keyword:

• call treatment action playmsg tftp://keyer/prompts/conjestion.au
  

  ---

  Note – The congestion.au file plays when local resources are not available to handle the call.

  ---

• The following example configures a call treatment cause code to display “no QoS” when local resources are unavailable to process a call:

• call treatment cause-code no-qos
  

SIP CAC

Measurement-based CAC for SIP can monitor IP network capacity and reject or redirect calls based on congestion detection. This feature does the following:

• Verifies that adequate resources are available to carry a successful VoIP session

• Implements a mechanism to prevent calls arriving from the IP network from entering the gateway when required resources are not available to process the call

• Supports measurement-based CAC processes

The following sections illustrate the configuration of CAC for a SIP environment. Specifically, configurations for the following CAC mechanisms are addressed: SAA RTR Responder, PSTN Fallback, and Resource Availability Check.

Configuring SAA RTR Responder

Service Assurance Agent (SAA) is a generic network management feature that provides a mechanism for network congestion analysis. SAA determines latency, delay, and jitter and provides real-time ITU Calculated Planning Impairment Factor (ICPIF) calculations before establishing a call across an IP infrastructure. The SAA Responder feature uses SAA probes to traverse the network to a given IP destination and measure the loss and delay characteristics of the network along the path traveled. These values are returned to the outgoing gateway to use in making a decision on the condition of the network and its ability to carry a call. Threshold values for rejecting a call are configured at the outgoing gateway.

Each probe consists of multiple packets, a configurable parameter of this feature. SAA packets can emulate voice packets and therefore receive the same priority as voice throughout the entire network. The delay, loss, and ICPIF values entered into the cache for the IP destination are averaged from all the responses. If the call uses G.729 and G.711 coder-decoders (CODECs), the probe packet sizes mimic those of a voice packet for that CODEC. Other CODECs use G.711-like probes. In Cisco IOS software releases later than Release 12.1(3)T, other CODEC choices might also be supported with their own specific probes.

The IP Precedence (that is, a Layer 3 priority marking) of the probe packets can also be configured to simulate the priority of a voice packet more closely. This parameter should be set equal to the IP Precedence used for other voice media packets in the network. Typically, voice packets have an IP Precedence value of 5.

SAA probes used for CAC go out randomly on ports selected from within the top end of the audio User Datagram Protocol (UDP), defined port range (16,384 through 32,767). Probes use a packet size based on the CODEC that the call will use. IP Precedence can be set if desired, and full RTP, UDP, and IP headers are used, just as a real voice packet would carry. The SAA Responder feature was called Response Time Reporter (RTR) in earlier releases of Cisco IOS software. You can use the rtr responder command to enable SAA Responder functionality on the destination node.

Configuring PSTN Fallback

The measurement-based CAC for SIP feature supports PSTN Fallback, which monitors congestion in the IP network and either redirects calls to the PSTN or rejects calls based on network congestion. Calls can be rerouted to an alternate IP destination or to the PSTN if the IP network is found unsuitable for voice traffic at that time. You can define congestion thresholds based on the configured network. This functionality allows the service provider to give a reasonable guarantee about the quality of the conversation to VoIP users at the time of call admission.

---

Note – PSTN Fallback does not provide assurances that a VoIP call that proceeds over the IP network is protected from the effects of congestion. This is the function of the other QoS mechanisms, such as LLQ.

---

PSTN Fallback includes the following capabilities:

• Provides the ability to define the congestion thresholds based on the network.

• — Defines a threshold based on ICPIF, which is derived as part of ITU G.113

  — Defines a threshold based solely on packet delay and loss measurements

• Uses SAA probes to provide packet delay, jitter, and loss information for the relevant IP addresses. Based on the packet loss, delay, and jitter encountered by these probes, an ICPIF or delay or loss value is calculated. Typically, an ICPIF value of 10 or lower is considered acceptable.

• Supports calls of any CODEC. Only G.729 and G.711 have accurately simulated probes. Calls of all other CODECs are emulated by a G.711 probe.

The call fallback subsystem has a network traffic cache that maintains the ICPIF or delay or loss values for various destinations. This capability helps performance because each new call to a well-known destination need not wait for a probe to be admitted, as the value is usually cached from a previous call.

Once the ICPIF or delay or loss value is calculated, it is stored in a fallback cache where it remains until the cache ages out or overflows. Until an entry ages out, probes are sent periodically for that particular destination. This time interval is configurable.

To configure PSTN Fallback, use the following global configuration mode command:

call fallback active

This command enables a call request to fallback to alternate dial peers in case of network congestion. The active keyword enables a call request to fall back to alternate dial peers in case of network congestion.

Configuring Resource Availability Check

User-selected thresholds allow you to configure call admission thresholds for local resources and end-to-end memory and CPU resources. You can configure two thresholds, high and low, for each global or interface-related resource. The specified call treatment is triggered when the current value of a resource goes beyond the configured high and remains in effect until the current resource value falls below the configured low.

You can select how the call should be treated when local resources are not available to handle the call. For example, when the current resource value for any one of the configured triggers for call threshold exceeds the configured threshold, you have the following call treatment choices:

• TDM hairpinning—Hairpins (that is, redirects) the calls through the POTS dial peer

• Reject—Disconnects the call

• Play message or tone—Plays a configured message or tone to the user

To configure resource availability checking, use the following global configuration mode command:

call threshold global trigger-name low value high value [busyout][treatment]

This command enables a trigger and defines associated parameters to allow or disallow new calls on the router. Action is enabled when the trigger value exceeds the value specified by the high keyword and is disabled when the trigger value drops below the value specified by the low keyword.

Table 7-8 shows the call threshold command options.

Table 7-8 call threshold Commands

To configure call treatment, use the following global configuration mode command:

call treatment {on | action action [value]| cause-code cause-code | isdn-reject
value}

This command configures how calls should be processed when local resources are unavailable.

Table 7-9 shows the call treatment command options.

To configure resource availability checking for interface resources, enter the following global configuration mode command:

call threshold interface interface-name interface number int-calls low value high 
value

This command allows threshold values to be configured for total numbers of voice calls placed through a particular interface. This command is used to allow or disallow admission for new calls on the router.

Table 7-10 shows the call threshold interface command options.

Table 7-9 call treatment Commands

Table 7-10 call threshold interface Commands

Consider the following examples of the SIP CAC commands:

• SAA RTR Responder:

• Router(config)#rtr responder
  

• PSTN Fallback

• Router(config)#call fallback active
  

• Resource availability checking

• Router(config)#call threshold global total-calls low 5 high 1000 busyout
  Router(config)#call treatment action cause-code 17
  Router(config)#call threshold interface ethernet 0 int-calls low 5 high 2500
  

MGCP CAC

The MGCP VoIP CAC feature enables certain Cisco CAC capabilities on VoIP networks that are managed by MGCP call agents. These capabilities permit a gateway to identify and gracefully refuse calls that are susceptible to poor voice quality.

Poor voice quality on an MGCP voice network can result from transmission artifacts such as echo, from the use of low-quality CODECs, from network congestion and delay, or from overloaded gateways. You can overcome the first two causes of echo by using echo cancellation and better CODEC selection. You can address network congestion, delay, and overloaded gateways by using MGCP VoIP CAC.

Before the release of MGCP VoIP CAC, MGCP voice calls were often established regardless of the availability of resources for those calls in the gateway and the network. MGCP VoIP CAC ensures resource availability by disallowing calls when gateway and network resources are below configured thresholds and by reserving guaranteed bandwidth throughout the network for each completed call.

MGCP VoIP CAC has three components for improving voice quality and reliability:

• System Resource Check (SRC) CAC evaluates memory and call resources local to the gateway. It is supported in MGCP 1.0 and MGCP 0.1.

• RSVP CAC allocates bandwidth on the network. RSVP is supported in MGCP 1.0 and MGCP 0.1.

• Cisco SAA CAC appraises network congestion conditions on the network. It is supported only in MGCP 1.0.

To set thresholds and enable MGCP SRC CAC, use the following command in global configuration mode:

call threshold global trigger-name low value high value treatment

This command enables a resource and defines its parameters. Treatment of attempted calls is enabled when the resource cost goes beyond the high value. Treatment is not disabled until the resource cost drops below the low value. The arguments and keywords are shown in Table 7-11.

Table 7-11 call threshold global Commands

If network conditions rise above the high threshold value, SRC rejects the call by sending the call agent an MGCP error message with the return code 403. The call agent applies a treatment to the rejected call.

The following sections illustrate the configuration of CAC for an MGCP environment. Specifically, configurations for the following CAC mechanisms are addressed: RSVP CAC, Cisco SAA CAC, and Cisco Unified CallManager CAC.

Configuring RSVP CAC

To configure MGCP RSVP CAC on a media gateway, use the following command in global configuration mode:

ip rsvp bandwidth (interface-kbps [single-flow-kbps])

This command enables RSVP for IP on an interface. RSVP is disabled by default. It should be noted that, in order for RSVP to operate correctly end to end, it must be configured on all routers in the network. The arguments are shown in Table 7-12.

Table 7-12 ip rsvp Bandwidth Commands

Configuring Cisco SAA CAC

Cisco SAA is an application-aware synthetic operation agent that monitors network performance by measuring response time, network resource availability, application performance, jitter (interpacket delay variance), connect time, throughput, and packet loss. Performance can be measured between any Cisco device that supports this feature and any remote IP host (server), Cisco routing device, or mainframe host. Performance measurement statistics provided by this feature can be used for troubleshooting, problem analysis, and designing network topologies.

The SAA Responder, enabled using the rtr responder command, is a component embedded in the target Cisco routing device that allows the system to anticipate and respond to SAA request packets. The SAA Responder can listen on any user-defined port for UDP and TCP protocol messages. In client/server terminology, the SAA Responder is a concurrent multiservice server.

The global configuration mode commands to configure Cisco SAA CAC are as follows:

• call fallback active—Enables a call request to fall back to alternate dial peers in case of network congestion

• mgcp rtrcac—Enables MGCP SAA CAC

• rtr responder—Enables the SAA Responder functionality on a Cisco device

The configuration shown in Example 7-6 enables all three types of MGCP VoIP CAC: SRC, RSVP, and SAA. Notice that CAC configuration commands are highlighted in the output. Comments are provided in the example in the lines preceding the CAC commands to help you identify the commands needed for a particular CAC type.

Example 7-6 MGCP CAC Configuration

version 12.2
!
! Output omitted for brevity
!

! The following command is used in MGCP SA Agent CAC.
call fallback active
! The following command is used in MGCP RSVP CAC.
call rsvp-sync
! The following six commands are used in MGCP SRC CAC.
call threshold global cpu-5sec low 55 high 70 treatment
call threshold global cpu-avg low 70 high 80 treatment
call threshold global total-mem low 70 high 80 treatment
call threshold global io-mem low 70 high 80 treatment
call threshold global proc-mem low 70 high 80 treatment
call threshold global total-calls low 10 high 12 treatment
!
! Output omitted for brevity


!
interface FastEthernet0/0
ip address 192.168.1.61 255.255.255.0
duplex auto
speed auto
! The following command is used in MGCP RSVP CAC to configure the bandwidth allocated.
! for VoIP calls through the interface.
ip rsvp bandwidth 512 512
!

! Output omitted for brevity
!
mgcp
mgcp call-agent 10.13.57.88 service-type mgcp version 1.0
mgcp modem passthrough voip mode nse
mgcp modem passthrough voaal2 mode
mgcp package-capability trunk-package
! The following command is used for MGCP SA Agent CAC.
mgcp rtrcac
! The following command is used in MGCP SRC CAC.
mgcp src-cac
no mgcp timer receive-rtcp
!
mgcp profile default
!
dial-peer voice 1 pots
application mgcpapp
port 3/0:1
!
dial-peer voice 2 pots
application mgcpapp
port 3/0:2
!
dial-peer voice 3 pots
application mgcpapp
port 3/1:1
!
dial-peer voice 4 pots
application mgcpapp
port 3/1:2
!
! The following command is used in MGCP SA Agent CAC.
rtr responder
!
! Output omitted for brevity
!
end

Cisco Unified CallManager CAC

While Cisco supports a variety of CAC mechanisms, most of these mechanisms are router-centric. However, in environments containing multiple Cisco Unified CallManager (CCM) clusters, other CAC approaches might be more appropriate. With CCMs, two types of call admission are possible:

• Locations CAC—The locations feature provides CAC for centralized call-processing systems. A centralized system uses a single CCM cluster to control all of the locations. CCM’s locations feature allows you to specify the maximum amount of bandwidth available for calls to and from each location, thereby limiting the number of active calls and preventing oversubscription of the bandwidth on the IP WAN links.

• Gatekeeper zone CAC—A gatekeeper device provides CAC for distributed call-processing systems. In a distributed system, each site contains its own call-processing capability. Calls are limited between zones in this configuration.

Summary

This chapter introduced the need for quality of service (QoS) in a converged network environment (that is, a network that simultaneously transports voice, data, and/or video). In the absence of QoS mechanisms, voice packets might suffer from packet loss, packet delay, and variable delay (that is, jitter). QoS mechanisms help mitigate such challenges through tools such as classification, marking, low latency queuing (LLQ), RTP Header Compression (cRTP), and Link Fragmentation and Interleaving (LFI).

Even with its relatively high-speed connectivity, local area networks (LANs) also need QoS. For example, an interface speed mismatch for traffic entering (for example, on a 1 Gbps link) and exiting (for example, on a 100 Mbps link) a switch could cause a switch interface queue to fill to capacity and overflow. On the LAN, many Cisco Catalyst switches can use QoS mechanisms, such as weighted round-robin (WRR) and CoS to DSCP remarking.

While the study of how to configure the various aspects of QoS mechanisms is beyond the scope of this book, this chapter did introduce a way to configure QoS on both IOS router platforms and IOS-based Catalyst switch platforms, through a feature called AutoQoS.

In the voice arena, most QoS mechanisms are aimed at protecting voice from data. However, too many simultaneous voice calls can also oversubscribe available WAN bandwidth. Therefore, Call Admission Control (CAC) mechanisms help protect voice from voice. This chapter discussed the configuration of H.323, SIP, MGCP, and Cisco Unified CallManager CAC approaches.

Chapter Review Questions

The following questions test your knowledge of topics explained in this chapter. You can find the answers to the questions in Appendix A, “Answers to Chapter Review Questions.”

1. Which two factors affect voice clarity?

2. 1. Fidelity

   2. Echo

   3. Sidetone

   4. Background noise

   5. Distance

3. Identify two broad categories of delay under which more specific types of delay are categorized?

4. 1. Variable delay

   2. Serialization delayfixed delay

   3. FIFO delay

   4. Processing delay

5. According to ITU-T Recommendation G.114, how much delay is acceptable for most user applications?

6. 1. 0 to 150 ms

   2. 200 to 250 ms

   3. 150 to 400 ms

   4. Above 400 ms

7. Which of the following QoS mechanisms does the AutoQoS feature enable on a Catalyst switch port?

8. 1. LFI

   2. cRTP

   3. WRR

   4. LLQ

9. What Cisco IOS software feature allows AutoQoS for Enterprise to dynamically discover an interface’s traffic patterns?

10. 1. NBAR

    2. ACLs

    3. CEF

    4. CBAC

11. Which of the following interface configuration mode commands enables AutoQoS on an interface and instructs the interface to trust Layer 2 CoS priority markings only if those CoS markings came from a Cisco IP phone?

12. 1. auto qos voip device cisco-phone

    2. auto qos voip cisco-phone

    3. auto qos voip trust cos

    4. auto qos voip trust cisco-phone

13. If CAC and LLQ are enabled on a link, which traffic will be transmitted first?

14. 1. Small data packets

    2. Large data packets

    3. Voice packets

    4. Packets that arrived first

15. At what location in the network are CAC call control services configured?

16. 1. Incoming gateway

    2. Outgoing gateway

    3. Incoming gatekeeper

    4. Outgoing gatekeeper

    5. Entire network

17. With the _______________________ command, you can configure two thresholds, high and low, for each resource.

18. 1. call spike

    2. call threshold

    3. call treatment

    4. rtr responder

19. Which feature of Cisco Unified CallManager allows you to specify the maximum bandwidth available for calls to and from each location?

20. 1. Set bandwidth

    2. Locations

    3. Gatekeeper zone

    4. Active calls

Lab Exercise: Router AutoQoS

In this lab, you will configure AutoQoS on two different router interfaces. One interface runs at a speed of 128 kbps, and the other interface runs at a speed of 2 Mbps. You will see that AutoQoS treats these interfaces differently, based on their available bandwidth.

Specifically, you will configure router R2, as shown in Figure 7-8. The interface speeds were configured in the “Initial Configuration” task of the lab exercise in Chapter 2, “Analog and Digital Voice Connections.”

Figure 7-8

Lab Topology

Task 1: Configure AutoQoS on the Slower Interface

In this task, you will configure AutoQoS on router R2’s slower serial interface.

Complete these steps:

Step 1. Enter interface configuration mode on router R2 for the interface that connects R2 to router R1 (for example, interface Serial 0/0 in Figure 7-8).

Step 2. Enable AutoQoS for this interface with the auto qos voip command.

Task 2: Configure AutoQoS on the Faster Interface

In this task, you will configure AutoQoS on router R2’s faster serial interface.

Complete these steps:

Step 1. Enter interface configuration mode on router R2 for the interface that connects R2 to router R3 (for example, interface Serial 0/1 in Figure 7-8).

Step 2. Enable AutoQoS for this interface with the auto qos voip command.

Task 3: Exercise Verification

In this task, you will verify the configuration of AutoQoS on router R2’s serial interfaces.

Complete these steps:

Step 1. From router R2’s privileged mode, enter the show auto qos command to view the commands entered by AutoQoS globally, for the slower serial interface, and for the faster serial interface.

Step 2. Notice that for the slower serial interface, AutoQoS configured Multilink PPP (MLP) and enabled RTP Header Compression (cRTP) because these are link efficiency mechanisms designed to optimize bandwidth usage on slower-speed serial interfaces (that is, interfaces with interface speeds less than 768 kbps).

---

Note – The purpose of this lab is to illustrate how AutoQoS intelligently applies appropriate QoS mechanisms to interfaces, based on interface characteristics. In order to be able to place a phone call across the lab topology after completing this lab, you should also configure AutoQoS on router R1’s serial interface that connects back to router R2, because MLP must be configured on both ends of a link.

---

Suggested Solution

Although your physical hardware might differ, Example 7-7 shows the output of the show auto qos command on R2 after entering the auto qos voip command for interfaces Serial 0/0 and Serial 0/1. Notice that cRTP and MLP are enabled only for interface Serial 0/0 since these link efficiency mechanisms are appropriate for slower link speeds (that is, link speeds less than 768 kbps), such as Serial 0/0’s link speed of 128 kbps. However, these link efficiency mechanisms are not appropriate for higher-speed links (that is, link speeds equal to or greater than 768 kbps), such as Serial 0/1’s link speed of 2 Mbps.

Example 7-7 Output from the show auto qos Command on R2

R2#show auto qos 
 !
 ip access-list extended AutoQoS-VoIP-RTCP
  permit udp any any range 16384 32767
 !
 ip access-list extended AutoQoS-VoIP-Control
  permit tcp any any eq 1720 
  permit tcp any any range 11000 11999 
  permit udp any any eq 2427 
  permit tcp any any eq 2428 
  permit tcp any any range 2000 2002 
  permit udp any any eq 1719 
  permit udp any any eq 5060
 !
 class-map match-any AutoQoS-VoIP-RTP-UnTrust 
  match protocol rtp audio 
  match access-group name AutoQoS-VoIP-RTCP 
 !
 class-map match-any AutoQoS-VoIP-Control-UnTrust 
  match access-group name AutoQoS-VoIP-Control 
 !
 class-map match-any AutoQoS-VoIP-Remark 
  match ip dscp ef 
  match ip dscp cs3 
  match ip dscp af31 
 !
  policy-map AutoQoS-Policy-UnTrust 
  class AutoQoS-VoIP-RTP-UnTrust 
   priority percent 70 
   set dscp ef 
  class AutoQoS-VoIP-Control-UnTrust 
   bandwidth percent 5 
   set dscp af31 
  class AutoQoS-VoIP-Remark 
   set dscp default 
  class class-default 
   fair-queue 

 Serial0/0 -
 !
 interface Serial0/0 
  no ip address 
  encapsulation ppp
  no fair-queue 
  ppp multilink
  ppp multilink group 2001100114
 ! 
 interface Multilink2001100114
  bandwidth 128
  ip address 10.1.1.1 255.255.255.0
  service-policy output AutoQoS-Policy-UnTrust
  ppp multilink
  ppp multilink fragment delay 10
  ppp multilink interleave
  ppp multilink group 2001100114
  ip rtp header-compression iphc-format

 Serial0/1 -
 !
  interface Serial0/1
  service-policy output AutoQoS-Policy-UnTrust
 !
 rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Dr 
ops" owner AutoQoS
 rmon alarm 33333 cbQosCMDropBitRate.1081.1083 30 absolute rising-threshold 1 3  
3333 falling-threshold 0 owner AutoQoS
 rmon alarm 33334 cbQosCMDropBitRate.1137.1139 30 absolute rising-threshold 1 3
3333 falling-threshold 0 owner AutoQoS

---

Note – LLQ is appropriate for all interface speeds and is configured for both interfaces.

---

Copyright © 2007 Pearson Education. All rights reserved.