CallManager 4.1(3) - Inter-cluster Trunk (ICT) behaviour and config
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.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...