Call admission controll in Trunks

Unanswered Question
Jun 7th, 2010
User Badges:

I have an issue with call admission control Trunks with SIP protocol. I have two IVR systems for which I have built 2 SIP Trunks from the CUCM servers. I have configured the trunks with a Route Group Circular call distribution. I was thinking the call admission controll will kick in case one of the server goes down.


This is isn't happening when I bring one of the servers down. Am I wrong in assuming the route group is supposed to perfrom call admission control and if the server does not respond move to the next available trunk in the route group.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jonathan Schulenberg Mon, 06/07/2010 - 14:40
User Badges:
  • Super Bronze, 10000 points or more
  • Cisco Designated VIP,

    2017 IP Telephony

Call Admission Control has nothing to do with this. CAC is a bandwidth management tool, not an HA tool.


You are correct that UCM will move on to a subsiquant candidate in the route group; however, you must be mindful of some timers. By default, the next route group member will be attempted after three seconds of no 1xx reply from the SIP-connected IVR system. You should start by doing some trace collection to understand exactly what traffic is being exchanged. For example, if the IVR sends a 100 Trying, UCM will stop the route hunt.


If the three second per route candidate is too long of a dealy, you can lower a service parameter: Retry Count for SIP Invite. Change it to something lower such as two (2). Use caution though as this will be a cluster-wide change!

Jaime Valencia Mon, 06/07/2010 - 14:44
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    2011

Your concept of CAC is wrong. CUCM CAC is based on locations and regions, when not enough BW is available to call, it either prevents the call from happening or uses AAR.

But it's not a method for failover of SIP trunks.


Try changing this parameters:


- Retry Count for SIP Invite : This parameter specifies the number of times
that Cisco CallManager will re-send the INVITE message.

- SIP Expire Timer : This parameter specifies the maximum time that an
INVITE message remains valid. If Cisco CallManager has not received an
answer before this timer expires, Cisco CallManager tears down the call.


HTH


java


If this helps, please rate


www.cisco.com/go/pdihelpdesk

LogicalTRC TRC Tue, 06/08/2010 - 10:24
User Badges:

Thanks to Jonathan Schulenberg and Javalenc for answering my post. I didn't know the correct word to use and instead used "CAC" to explain the "unable to proceed call and hence hunt the next available in the hunt group."


The SIP Invite timing you are refering to, is it Service Paramater > Cisco Call Manager > Clustwide Parameters (Device - SIP) > Retry Count for SIP Invite. The value is currently set to 6.

SIP Expires Timer is set to 180000.

Default:                  180000
Minimum:                  60000
Maximum:                  300000

We do use Presence which uses SIP. I am not sure if that is affected in any way.


Thank you for your help.

Actions

This Discussion

Related Content