Introduction
This document covers the Configuration procedures with deployment examples to Implement Call Admission Control (CAC) on Cisco Unified Border Element (CUBE). Call Admission Control plays a major role in the network to control the number of calls based on the available resources and bandwidth.
What is CAC and Why it is required ?
CAC is nothing but Call Admission Control which
- Controls number of calls based on resources & bandwidth
- Proactively reserve resources for good quality video calls
- Ensure traffic adheres to QoS policies within each network
CUBE can provide six different CAC mechanisms based on,
- Total calls
- CPU
- Memory
- IP call capacity
- Max-connections
- Call Spike detection
- Dial-peer / Interface bandwidth
- RSVP
CAC mechanisms ensure good QoS for video and voice calls and help meet the SLA
CAC Implementation
1. CAC Based on Total Calls, CPU or Memory
Configuration Example
call threshold global [total/mem/cpu] calls low xx high yy call treatment on
Global Command
call threshold global [total-calls | cpu-5sec | cpu-avg | total-mem | low <low-threshold> high <high-threshold>
call treatment on
call treatment cause-code ?
busy Insert cause code indicating the GW is busy (17) no-QoS Insert cause code indicating the GW can't provide QOS (49) no-resource Insert cause code indicating the GW has no resource (47) |
- Call threshold values for total concurrent calls or CPU or memory to be handled by CUBE can be defined
- Call treatment can be turned on to handle the call once the CAC limit is reached
2. CAC Based on IP Call Capacity
Configuration Example
gatekeeper# endpoint circuit-id h323id CUBE1 AA max-calls 500
CUBE#
voice service voip allow-connections h323 to h323 h323 ip circuit max-calls 1500 ip circuit carrier-id AA reserved-calls 1000 <Note Number is twice because of 2 call legs> |
- IP call capacity on CUBE works in conjunction with the Cisco Gatekeeper (GK)
- Call counting mechanism does not take into account the codec type used – this is taken into account by enabling bandwidth management on the Cisco GK
- This only works if at least 1 call leg on CUBE is using H.323
3. CAC Based on Max Connections per destination
Configuration Example
CUBE# dial-peer voice 1 voip max-conn 2 |
- Restricting the number of concurrent calls that can be active on a VoIP dial peer
- Max-Conn works on individual dial-peers, does not provide CAC for the entire gateway
4. CAC based on Call Spike detection
CUBE rejects calls if call spike is detected
Configuration Example
call spike call-number [steps number-of-steps size milliseconds] call spike 10 steps 5 size 200 |
5. CAC based Dial-peer or interface bandwidth
Configuration Example
dial-peer voice 1 voip max-bandwidth 160 |
6. CAC based on RSVP
Configuration Example
interface FastEthernet0/0 ip rsvp bandwidth 1000 1000
dial-peer voice 10 voip destination-pattern 2... session target ras req-qos guaranteed-delay audio req-qos guaranteed-delay video acc-qos guaranteed-delay audio acc-qos guaranteed-delay video |
- Synchronization of RSVP with H.323 signaling to ensure that the bandwidth reservation is established
- RSVP ensures that bandwidth is reserved before the far end phone rings
