Call Admissions Control (CAC) prevents over-subscription of the VoIP network by counting the number of calls on a network. Acting like a network traffic cop, CAC disallows VoIP calls to traverse a network when the network has reached its maximum number of VoIP calls allowed. CAC mechanisms complement the capabilities of Quality of Service (QoS) tools to protect voice traffic from the negative effects of too many voice streams on an oversubscribed network.
Consider a WAN (Wide Area Network) that is capable of handling eight VoIP calls. If the control device put nine calls on the WAN, all nine would be affected by quality of control issues due to the use of shared bandwidth.
Within the Cisco VoIP network there are two devices that can perform the CAC job:
- Gatekeeper – This is a router that is using H.323 protocol to perform the job as gatekeeper. A gatekeeper is used when you have a distributed call controlled network, such as multiple Communications Manager clusters on the same network.
- Communications Manager (Formally CallManager or CM for short) – The CM can perform the function of CAC when there is only one CM cluster on the network (centralized call control), this is known as Location Based Call Admission Control (LBCAC).
No matter which device is used to perform CAC, it is necessary to tell the device how much bandwidth to allow on each network. And, as with most things in the world of networks, it is not as simple as typing in the total amount of bandwidth on the WAN link. It is necessary to perform some math calculations that I refer to as “Fudge Math” to come up with the amount of bandwidth to configure in the CAC device.
The CAC device simply counts calls to perform its job. Life would be simple if during the configuration we told the device to allow five calls on WAN A and eight calls on WAN B. But if this was the case I would not have to write this post, so here is the rest of the story.
How CAC devices count calls
First of all, it is necessary to know how the two different devices described above count calls. Both devices count calls by notating each call on a network with a certain amount of bandwidth. The bandwidth used to notate each call in no way represents the bandwidth of each packet. The “fudge math” is performed to determine how much bandwidth should be configured on the CAC device. The two devices use a different notation for each call, as shown in the chart below.
|Codec Type||Communications Manager||Gatekeeper|
For example, the Communications Manager would count three G.729 calls as 72K; therefore, 72K would be entered in to allow three G.729 calls between two locations.
The first step is to understand how to calculate VoIP bandwidth. To do these calculations, please see my Calculating VoIP Bandwidth post. Once you understand how to calculate the bandwidth of each RTP packet, you can use fudge math to come up with the bandwidth needed to configure on the CAC device.
(Total WAN Bandwidth / per packet bandwidth with layer 2) * CAC Bandwidth
For this example: the WAN in question is a 756K WAN Link, G.729, 20ms sample rate, PPP layer two, and CM control CAC.
The first half of the equation works out to: 756K / 26.8K = 28.125 calls (you cannot have .125 calls so round down to 28 calls)
28 calls * 24K = 672K
672k is the number you will configure when setting up locations with this WAN on the Communications Manager. The 24K came from the chart above that notates how much bandwidth CM counts for each G.729 call.
As another example: 128K WAN, G.729, 30ms sample rate, Frame Relay layer two, and Gatekeeper controlled CAC
128K / 20.27 = 6.134 calls (you cannot have .134 calls so round down to 6 calls)
6 calls * 16K = 96000 is the number you will configure when setting up bandwidth on the GK.
If you need six G.711 calls you would enter the following bandwidth in the CM or GK.
|G.711 – 6 Calls|
In closing, one of the main things to remember is to include Layer 2 when calculating the per packet bandwidth. This simple step will help you avoid one of the biggest mistakes most people make.
Author: Paul Stryer