cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays

Call Admission Control (CAC) implementation on CUBE

16513
Views
45
Helpful
12
Comments

 

 

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

  1. Controls number of calls  based on resources & bandwidth
  2. Proactively reserve resources  for good quality video calls
  3. 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

 

cac-6.png

 

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

 

cac-1.bmp

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

 

 

cac-2.bmp

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

 

cac-4.png

 

 

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

 

cac-7.png

 

Configuration Example

 

dial-peer voice 1 voip

   max-bandwidth 160

 

 

 

6. CAC based on RSVP

 

 

cac-3.bmp

 

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

 

 

Related Information

Comments
VIP Mentor

Excellent Doc! Well done.

Ayodeji

Thank you very much.

Beginner

Is there any show command for see how many calls has rejected?

Regards

Beginner

Behavior - For CAC based on Total Calls.

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.

I have this configuration:

call treatment cause-code busy
call treatment on
call threshold global total-calls low 2 high 3

 

 


////Zero Calls

R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
Avail   N/A                     total-calls     0       2       3       busy&treat

R_ISOL_HQ_7.06_36#

 

 


////One Call - Ok

R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
Avail   N/A                     total-calls     1       2       3       busy&treat

R_ISOL_HQ_7.06_36#

 

 

////Two Calls - Ok

R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
Avail   N/A                     total-calls     2       2       3       busy&treat

R_ISOL_HQ_7.06_36#

 

 

////Three Calls - Ok

R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
Avail   N/A                     total-calls     3       2       3       busy&treat

R_ISOL_HQ_7.06_36#

 

 

 

////Four Calls - We have Fast Busy on the IP Phone.
                 Under Status under the command "show call threshold status" we have NonAv
                
R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
NonAv   N/A                     total-calls     3       2       3       busy&treat

R_ISOL_HQ_7.06_36#

In the console router we have

Feb 24 22:11:17.512: %CALLTREAT-3-HIGH_TOTAL_CALLS: High call volume.  Processing for callID(53874) is rejected.


On SIP Level, the CUBE send, back to the CUCM.


Feb 24 22:11:17.516: //53874/B01796000000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 486 Busy here
Via: SIP/2.0/TCP 177.56.25.10:5060;branch=z9hG4bK16d798bab89
From: <sip:67952@177.56.25.10>;tag=11644~afccc525-5442-4756-a44e-24c835482eb3-33492681
To: <sip:0082213224@177.56.25.4>;tag=8B736658-12FD
Date: Tue, 24 Feb 2015 22:11:17 GMT
Call-ID: b0179600-4ec1f9c5-b1-a1938b1@177.56.25.10
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Reason: Q.850;cause=17
Content-Length: 0

 

////Drop one call of three, the status still in NonAv, because the value is not under the Low Threshold. The new calls will be droped.


R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
NonAv   N/A                     total-calls     2       2       3       busy&treat

R_ISOL_HQ_7.06_36#


////Drop one call of two, the status now is Avail, because the value is under the Low Threshold, and we can reach the High Threshold again.

R_ISOL_HQ_7.06_36#show call threshold status

Status  IF                      Type            Value   Low     High    Enable
------  ---                     ------          -----   ----    ----    ------
Avail   N/A             total-calls     1       2       3       busy&treat

R_ISOL_HQ_7.06_36#

 

 

***** If we change the cause code "R_ISOL_HQ_7.06_36(config)#call treatment cause-code no-QoS " we have the next Cause Code Error on SIP, send to the CUCM, on the fourth call.

Feb 24 22:23:14.918: //53881/5B751A800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 580 Precondition Failed
Via: SIP/2.0/TCP 177.56.25.10:5060;branch=z9hG4bK1812367926d
From: <sip:67952@177.56.25.10>;tag=11661~afccc525-5442-4756-a44e-24c835482eb3-33492692
To: <sip:0082213224@177.56.25.4>;tag=8B7E58B8-13A9
Date: Tue, 24 Feb 2015 22:23:14 GMT
Call-ID: 5b751a80-4ec1fc92-b5-a1938b1@177.56.25.10
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Reason: Q.850;cause=49
Content-Length: 0


***** If we change the cause code "R_ISOL_HQ_7.06_36(config)#call treatment cause-code no-resource " we have the next Cause Code Error on SIP, send to the CUCM, on the fourth call.

Feb 24 22:28:39.335: //53890/1C9394800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 177.56.25.10:5060;branch=z9hG4bK197162fe198
From: <sip:67952@177.56.25.10>;tag=11683~afccc525-5442-4756-a44e-24c835482eb3-33492707
To: <sip:0082213224@177.56.25.4>;tag=8B834BFC-1061
Date: Tue, 24 Feb 2015 22:28:39 GMT
Call-ID: 1c939480-4ec1fdd6-bb-a1938b1@177.56.25.10
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M7
Reason: Q.850;cause=47
Content-Length: 0

 

 

VIP Mentor

Waldoto,

Excellent!! Thank you for sharing this..Really good.

Hi Waldoto,

I really appreciate you for sharing this information. It will be highly helpful for everyone to read it with examples.

Thank you for all the great work you are doing on CSC.

Regards

Lavanya

CSC Moderator

Community Member

Great information. Thank you for the post. I have one issue with the call threshold setting and I was wondering if anyone has experienced the same. When using the following config (on inbound calls to the router):

call treatment cause-code busy
call treatment on
call threshold global total-calls low 4 high 4

or

call threshold global total-calls low 3 high 4 

Once the router reaches the high watermark (in this case 4), only the 1st call after 4 concurrent calls receives a busy (486) response from the router. In the same session, if you make a 6th, 7th 8th.. call to the router, the calling party receives a Service Unavailable (503) message. This cycle doesn't reset until the call threshold falls below the low watermark. I would expect the when all 4 lines are full, every call after should receive a busy signal until the call threshold falls below the low watermark but I'm finding that this is not the case.

Please let me know if anyone has discovered this.

Thanks.

Community Member

If anyone runs in to this same issue, here is an example of the fix.

call treatment cause-code busy
call treatment on
call threshold global total-calls low 4 high 4 treatment
call treatment action reject

Beginner

How to enforce the CUBE session license on the router? Is "CAC" is the way to limit their sessions or is there any other way to enforce the CUBE session license?

Community Member

Good one.

Beginner

One thing I just ran across (on 15.3(3)M7 at least) is that the call treatment cause-code command has no impact if you use the call threshold interface command to limit calls instead of call threshold global.

My scenario was that the carrier wanted a 486 back on the 101st call on a SIP trunk in order to fail over to the other data center.  Using call threshold global total-calls low 95 high 100, and adding the call treatment commands Michael Socher identified above, I was able to get the 486 to be sent back on the 101st call.  

My dilemma was that I have a UCCE/CVP environment, and calls to CVP consume 2 legs per the global total-calls tracking.  FWIW, forking calls to MediaSense also adds another leg.  Because I had normal user calls as well as contact calls ingressing on this SIP trunk, I could not accurately state what the total-calls would be at a global level, because there was no way to determine how many would go to CVP with 2 legs, and how many will be recorded.  

I thought I could do this on the WAN interface for the SIP trunk instead, so I used the command "call threshold interface GigabitEthernet0/1 int-calls low 95 high 100 midcall-exceed".  This accurately counted only the calls on the carrier interface.  However, this only sent back a 580 Precondition Failed message, it would not send back the 486 specified using the call treatment commands.  I could not find any way to change what was being generated back. (is this possible in SIP Profiles?)

The way around this that I found was to use the int-bandwidth command instead of the int-calls command.  For whatever reason, the int-bandwidth command at the interface level sends a 486 busy back when the high bandwidth number is hit. This is my working solution:

call threshold on

call threshold interface GigabitEthernet0/1 int-bandwidth low 7840 high 8001

It is interesting to note that you must set the high bandwidth mark to just above the exact bandwidth needed (I had g711 calls coming in, it counts them as 80kbps per call - needed 100 calls, so 80*100=8000).  If I left that to 8000, it would trigger the 486 on the 100th call.  

Beginner

This solved my issue.   Thank you for the assistance.

Content for Community-Ad