Call Admission Control (CAC) is often times included as part of the same topic as Quality of Service (QoS), when in actuality CAC is a separate and complete topic itself.
QoS is defined as traffic engineering on a packet switched network. This definition means moving the IP Packets on to the wire and across the network in the fastest time possible, with the least amount of dropped packets. QoS manages this process by prioritizing different data flows. Packets with high sensitivity to the amount of time it takes to traverse the network receive a higher priority; such as voice and video packets.
CAC prevents over-subscription of VoIP networks. It is used in the call set-up phase and applies to Real-Time Transport Protocol traffic also known as the media portion of a call. CAC compliments QoS, however, it’s mechanisms of operation are very different from those of QoS operations. CAC protects voice traffic from the negative effects of excess voice traffic on the VoIP network, by ensuring there is enough bandwidth for all authorized flows.
In most cases CAC is done on Wide Area Networks (WAN) where there is typically only enough bandwidth to support a small volume of calls. For example, if a WAN can only support five G.729 calls and six or more calls come in on that WAN there would be degraded call quality for all calls on the WAN, not just for calls six and above. The reason call quality suffers for all calls is because of shared bandwidth. Generally, without any device to provide CAC, the system would continue to allow calls on the WAN circuit and exceed the bandwidth specifications of the WAN. With the insertion of a CAC device, the number of calls on the VoIP networks is counted with a limit set to how many calls can be placed on each WAN network. The CAC device would start rejecting call set-up messages when the limit is reached. It would be up to the initiating system to reroute the call onto another network, such as the Public Switched Telephony Network (PSTN).
Within Cisco’s IP Telephony systems there are two main types of topology unaware CAC. Topology unaware CAC is defined as any mechanism that is based on a static configuration within a call processing agent or IP-Based PBX, aimed at limiting the number of simultaneous calls to or from a remote site connected via the IP WAN. Due to the reliance on static configurations, topology unaware CAC mechanisms must be designed in a simple hub-and-spoke topology.
Location Based Call Admission Control
Cisco Unified Communications Manager (CUCM) provides a simple mechanism known as static locations for implementing CAC in the centralized call processing deployment. When you configure a device in CUCM, the device can be assigned to a location. A certain amount of bandwidth will be allocated for calls to or from each location. CUCM can define a voice and video bandwidth pool for each location. If the location’s audio and video bandwidths are configured as “Unlimited”, there will be unlimited bandwidth available for that location and every audio or video call to or from that location will be permitted by CUCM. On the other hand, if the bandwidth values are set to a finite number of kilobits per second (kbps), CUCM will allow calls in and out of that location as long as the aggregate bandwidth used by all active calls is less than or equal to the configured values.
When an inter-site call is denied by CAC, CUCM can automatically reroute the call to the destination via the PSTN connection by means of the Automated Alternate Routing (AAR) feature. AAR is invoked only when the locations-based CAC denies the call due to a lack of network bandwidth. AAR is not invoked when the IP WAN is unavailable or other connectivity issues cause the called device to become unregistered with CUCM. In such cases, the calls are redirected to the target specified in the Call Forward No Answer field of the called device.
Gatekeeper Based Call Admission Control
A Cisco IOS gatekeeper can provide call routing and CAC between devices such as CUCM, Cisco Unified Communications Manager Express (CME), or H.323 gateways connected to a legacy PBX. The gatekeeper uses the H.323 Registration Admission Status (RAS) protocol to communicate with these devices and route calls across the network.
Gatekeeper CAC is a policy-based scheme requiring static configuration of available resources. The gatekeeper is not aware of the network topology, so it is limited to simple hub-and-spoke topologies.
The CAC capabilities of a Cisco IOS gatekeeper are based on the concept of gatekeeper zones. A zone is a collection of H.323 devices, such as endpoints, gateways, or Multipoint Control Units (MCUs) that register with a gatekeeper.
The bandwidth command is used to manage the number of calls that the gatekeeper will allow, thus providing call admission control functionality. This command has several options, but the most relevant are the following:
- The interzone option controls the amount of bandwidth for all calls into or out of a given local zone.
- The total option controls the amount of bandwidth for all calls into, out of, or within a given local zone.
- The session option controls the amount of bandwidth per call for a given local zone.
- The remote option controls the total amount of bandwidth to or from all remote zones.
The bandwidth value deducted by the gatekeeper for every active call is double the bit-rate of the call, excluding Layer 2, IP, and RTP overhead.
Resource Reservation Protocol – Topology Aware CAC
CUCM Release 5.0 introduces a topology aware CAC mechanism based on the Resource Reservation Protocol (RSVP). Topology aware CAC is applicable to any network topology and eases the restriction of a traditional hub-and-spoke topology. The Cisco RSVP Agent is a Cisco IOS feature that enables CUCM to perform the RSVP-based CAC. The Cisco RSVP Agent feature has been introduced into Cisco IOS Release 12.4(6)T and is available on the Cisco 2800 Series and 3800 Series Integrated Services Routers platforms.
The Cisco RSVP Agent registers with Unified CM as either a media termination point (MTP) or a transcoder device with RSVP support. When an endpoint device makes a call in need of a bandwidth reservation, CUCM invokes a Cisco RSVP Agent to act as a proxy for the endpoint to make the bandwidth reservation.
Calculating Bandwidth for CAC
In both cases of topology unaware CAC you will have to inform the CAC mechanism how much bandwidth is available on each WAN link. You can do this by reading two of my previous posts:
Fudge Math of CAC
Calculating VoIP Bandwidth
SRND for CUCM 7.x
Author: Paul Stryer