This is a cross post from the cisco-voip mailing list. Just trying to broaden my viewer base. That means you aokanlawon You're awesome! But seriously, anyone who can help out, I am grateful for it.
I am troubleshooting a complex call flow with multiple clusters all connected via Non-Gatekeeper Controlled H.323 ICT's, and have narrowed down the failure to a region misconfiguration between a trunk and its transcoder.
My question to the group is about the H.245 MasterSlaveDetermination process, and how CUCM handles this between two CUCM's. Because, as you might see below, it seems to be broken, or at least unpredictable. Or maybe my lack of understanding is blinding me to the obvious answer.
First, let me start with a graphic of the H.225/H.245 messaging between two clusters. What you will see here is that TCS is sent in both directions, and the the initiating side sends an H.245 endSession to the receiving side, before the MasterSlaveDetermination is sent or received by either party.
What the graphic doesn't show, are the details within the messages, but as you may know, the H.225 messaging is littered with customer specific details, so it's a bit of a challenge to simply just post it all to this mailing list. Below are some of the details to help you understand the flow. Please let me know if you need more specific details.
We'll start with the TCS message sent by the .9 host to the .13 host
However, in the CUCM traces, between the Outgoing TCS ACK and the Incoming TCS ACK, we see CUCM Media Resource Manager comparing codecs and regions, and deciding it needs to invoke a transcoder. Even though MasterSlaveDetermination has not yet happen.
The timing in the logs, and unfortunately I do not have a PCAP to compare against, is such that the transcoder fails to be invoked due to a region misconfiguration between the ICT and the transcoder. The classic mixup: "We need to transcode between g711 and g729, but the transcoder region to the g711 device is set for 8kbps."
However, it invoked the transcoder successfully, and since the transcoder is 64kbps to UCCX and 8kbps to the ICT, this is why we'll see another TCS sent from the .13 host with g729 as its capabilities.
Which from my experience, would tell me that the .13 host would have won the MasterSlaveDetermination, making the codec of choice be g711 and forcing the .9 host to resolve the mismatch with a transcoder. However, each side tried to fix the codec mismatch, all before MasterSlaveDetermination even happened.
Did each side jump the gun, and begin invoking the transcoders too early? Are the logs out of sequence from what actually happened on the wire? Why would both sides attempt to resolve the codec mismatch?
For comparison, here is the same message flow from the perspective of the .13 host logs.
And in summary, I know what is needed to fix this: fix the region relationship from the transcoder to the g711 device so that it's 64kbps.
I would like to understand what determines which side sends and subsequently wins MasterSlaveDetermination on ICTs? I know it's based on terminalType value and which is higher, and then a tie breaker is the statusDeterminationNumber value. Is this a random election? Is it controllable? I.e., Can I adjust the terminalType such that it forces Master or Slave by setting a very High or Low value respectively?
If you've made it this far in my email, thank you! I realize I have questions littered throughout. It's just the casual tone of my email. If the email doesn't flow very eloquently, I do apologize. It's long and I was going back and forth making edits to different sections.
Over on the mailing list, Jason Aarons pointed me to an ipexpert blog post, which says that if both terminal types are the same, then the election of Master is random. That's good to know, but in my scenario above, the call never got as far as H.245 MasterSlaveDetermination before both sides took action to resolve the codec mismatch.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
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 ...