Chapter 7: Improving and Maintaining Voice Quality

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