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.

[View full width]
 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

Command	Description
global trigger-name	Specifies the global resources on the gateway. The trigger-name arguments are as follows: cpu-5secCPU utilization in the last 5 seconds. cpu-avgAverage CPU utilization. io-memI/O memory utilization. proc-memProcessor memory utilization. total-callsTotal number of calls. The valid range is from 1 to 10,000. total-memTotal memory utilization.
interface interface-name interface-number	Specifies the gateway. The types of interfaces and their numbers depend on the configured interfaces.
int-calls	Number of calls through the interface. The valid range is from 1 to 10,000 calls.
low value	Value of low threshold. The valid range is from 1 to 100 percent for the utilization triggers.
high value	Value of high threshold. The valid range is from 1 to 100 percent for the utilization triggers.
busyout	(Optional: global only) Automatically busies out the T1/E1 channels if the resource is not available.
treatment	(Optional: global only) Applies call treatment from session application if the resource is not available.

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

Command	Description
call-number	Incoming call numbers for spiking threshold; valid range is from 1 to 2,147,483,647
steps number-of-steps	(Optional) Number of steps; valid range is from 3 to 10
size milliseconds	(Optional) Step size in milliseconds; valid range is from 100 to 2000

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

Command	Description
on	Enables call treatment from the default session application.
action action	Action to take when call treatment is triggered. The action argument has the following possible values: hairpinHairpin playmsgSpecifies the URL of the audio file to play rejectDisconnects the call and pass down cause code
cause-code cause-code	Specifies reason for disconnect to caller. The cause-code argument can have the following values: busyIndicates that gateway is busy no-QoSIndicates that the gateway cannot provide QoS no-resourceIndicates that the gateway has no resources available
isdn-reject value	Selects the ISDN rejection cause code.

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

Cause No.	Description	Function
34	No circuit available (circuit/channel congestion)	Indicates that there is no channel available to handle the call
38	Net out of order	Indicates that the network is not functioning properly and the malfunction is likely to last a long time. Re-attempting the call is not likely to be successful
41	Net problem, redial (temporary failure)	Indicates that the network is not functioning properly and the malfunction is not going to last a long time. Re-attempting the call is likely to be successful
42	Net busy, redial (switching equipment congestion)	Indicates that the switching equipment is experiencing high traffic load
43	Access/user information discarded	Indicates that the network is unable to deliver user information to the remote users as was requested
44	No channel available (requested circuit/channel not available)	Indicates that the circuit or channel indicated by the requesting side cannot be used by the other side of the interface
47	Resource unavailable/new destination	Indicates a resource unavailable event only when no other cause in the resource unavailable class applies

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

Command	Description
trigger-name	Can be one of the following: cpu-5secCPU utilization in the last 5 seconds cpu-avgAverage CPU utilization io-memI/O memory utilization proc-memProcessor memory utilization total-callsTotal number of calls total-memTotal memory utilization
low value	Value of low threshold; range is from 1 to 100 percent for utilization triggers and from 1 to 10,000 for total calls
high value	Value of high threshold; range is from 1 to 100 percent for utilization triggers and from 1 to 10,000 for total calls
busyout	(Optional) Busies out the T1 or E1 channels if the resource is not available
treatment	(Optional) Applies call treatment from the session application if the resource is not available

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.

Table 7-9. call treatment Commands

Command	Description
on	Enables call treatment from the default session application.
action action	Specifies the action to be taken when call treatment is triggered. The action argument can be one of the following: hairpinSpecifies the hairpinning action. playmsgSpecifies that the gateway play the selected message. The optional value argument specifies the audio file to play, in URL format. rejectSpecifies whether the call should be disconnected and the ISDN cause code passed.
cause-code cause-code	Specifies the reason for disconnection to the caller. The cause-code argument can be one of the following: busyIndicates that the gateway is busy. no-qosIndicates that the gateway cannot provide QoS. no-resourceIndicates that the gateway has no resources available.
isdn-reject value	Applies to ISDN interfaces only and specifies the ISDN reject cause code. The value argument ranges from 34 through 47 (ISDN cause code for rejection).

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-10. call threshold interface Commands

Command	Description
interface-name	Specifies the interface used in making call admission decisions. Types of interfaces and their numbers depend on the configured interfaces.
interface-number	Specifies the number of calls through the interface that triggers a call admission decision.
int-calls	Configures the gateway to use the number of calls through the interface as a threshold.
low value	Enables the specified call treatment until the number of calls through the interface drops below the configured low value. The value argument specifies the number of calls used to make call admission decisions. The range is from 1 to 10,000 calls.
high value	Enables the specified call treatment until the number of calls through the interface exceeds the configured high value. The value argument specifies the number of calls used to make call admission decisions. The range is from 1 to 10,000 calls.

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

Command	Description
trigger-name	Can be one of the following: cpu-5secCPU utilization in the last 5 seconds cpu-avgAverage CPU utilization io-memI/O memory utilization proc-memProcessor memory utilization total-callsTotal number of calls total-memTotal memory utilization
low value	Value of low threshold; range is from 1 to 100 percent for utilization triggers and from 1 to 10,000 for total calls
high value	Value of high threshold; range is from 1 to 100 percent for utilization triggers and from 1 to 10,000 for total calls
treatment	(Optional) Applies call treatment from the session application if the resource is not available

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

Command	Description
interface-kbps	(Optional) Maximum amount of bandwidth, in kilobits per second, that might be allocated by RSVP flows. The range is from 1 to 10,000,000. This parameter should be configured for the maximum amount of voice bandwidth that this interface is limited to for all calls.
single-flow-kbps	(Optional) Maximum amount of bandwidth, in kilobits per second, that might be allocated to a single flow. The range is from 1 to 10,000,000. This parameter should be configured for the amount of bandwidth for one call.

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.