Cisco Voice over IP (CVoice) (Authorized Self-Study Guide) (2nd Edition)

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.

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.

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.

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.

[View full width]

Table 7.4 shows the call threshold command options.

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.

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.

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

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.

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.

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.

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.

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

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.