CallManager 4.1(3) - Inter-cluster Trunk (ICT) behaviour and config

Question

Hi Guys,
Trying to get some clarification on this. Currently chasing a few different avenues. If anyone knows of some good detailed docco on this (have tried the standard stuff). Or if anyone has any best practice advice, otherwise any one have any comments or insight on the following conversation:
Stage 1 describes the impact of the device pool setting, which is basically how the local CallManager is selected to process the call.
Stage 2 describes how the local callmanager selects the remote destination callmanager
Stage 1 - Phone on side A attempts to make a call to phone on cluster B
If the source phone is in the same device pool as the ICT on cluster A, then the call will be processed by the primary ccm for that device pool. (assuming it is available)
- It will be processed by the Call Manager is homed to rather than the primary Call Manager.
If the source phone is in a different device pool than the ICT on cluster A, then a random ccm in the ICT config will be selected. (Have asked for clarification here)
- Yep, the docs actually say "Selection of Cisco CallManager nodes occurs in a random order"
Stage 2 - One of the Callmanagers in cluster A now has the call to send to the remote cluster B. This is where your ICT config of the 3 callmanagers comes in. The Callmanager will use a round robin basis to select the destination callmanager.
I am still running with this, but initial thoughts are that if your phones are in the same DP as the ICT, then you are basically going to end up with the primary ccm in that DP processing all the calls. In this instance the primary CCM still selects the remote destination callmanager via round robin basis, so the calls will be distributed fairly evenly to the 3 destination servers.
- Not sourced from primary as stated above
- A key point is for them to understand is that all the Call Managers configured in Cluster A ICT must be in the same device pool in the remote cluster B, and the ICT must also be a member of that device pool. So, if they configure CMgr 4 to be a target device within the ICT configuration, yet CMgr 4 isn't a member of the remote ends ICT device pool they will get failing calls. This is because CMgr 4 will receive an H323 call (H225 signalling) from a source IP address that it knows nothing about and hence the H225 daemon will reject the call. Not sure how the local call Mgr handles the rejection of call.
If you wanted to balance the call processing on the local side. I.e. instead of always selecting the primary CCM in the device pool and therefore splitting the call processing amongst the 3 local ccm's in a random fashion. Then you would want to put your phones into a different device pool than the ICT. This will mean that the local callmanager is selected at random.
- Well maybe, random may not mean truely random so they'd just have to give it a go and monitor it. However, it's unclear at this time if the monitoring tools tell us how many outgoing vs incoming calls are processed, and you need to understand this to determine the outgoing loading of each Call Manager. The CallsActive counter registers both incoming and outgoing calls hence you can't really tell. To monitor it for sure they could set up two ICTs, one for incoming calls on for outgoing then at least the loading would be a little clearer. I think the only overhead here is the config effort which shouldn't be too tricky.
The interesting thing is the "random" part. It doesnt make a lot of sense considering device pools are the perfect place to manually distribute the load evenly. I.e. if I had 3 device pools for the end phones, each of them using a different callmanager as it's primary call processor in the CallManager groups.
- Agreed although I would say the usual top down and circular algorithms should be available.

Answer 1

Trunk configuration in Cisco CallManager Administration depends on the network design and call control protocols that are used in the IP WAN. All protocols require that either a signaling interface (trunk) or a gateway must be created to accept and originate calls. For some IP protocols, such as MGCP, you configure trunk signaling on the gateway. You specify the type of signaling interface when you configure the gateway in Cisco CallManager. For example, to configure QSIG connections to Cisco CallManager, you must add an MGCP voice gateway that supports QSIG protocol to the network. You then configure the T1 PRI or E1 PRI trunk interface to use the QSIG protocol type
This URL should help you:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a00801ec5ce.html