<div dir="ltr"><div>Heads up my collab people.  I was troubleshooting an MTP config, and I was seeing the "wrong" MTP being invoked based on how I designed the MRGL.</div><div><br></div><div>Here you can see the order of the resources across 2 MRGs in my MRGL.  Note that MT_DUDE is my target, and MTP_2, 3, and 4 are just backups for testing this scenario.</div><div><br></div><div><div><font face="monospace">MediaResourceCdpc(142660)::createDevicePidTable - Entries copied in the Device Table = 4</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_DUDE Cepn=65de78dd-7e27-0133-5a5d-e3f6a1a75445 Weight=0 Group=1 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_2 Cepn=487e27a2-64a1-4283-9352-9798f51817ac Weight=0 Group=2 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_3 Cepn=7a5007bb-120b-4ee0-953b-9ffdac723ea9 Weight=0 Group=2 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_4 Cepn=7f5dac9e-9b3a-4276-a8fa-d114123b5939 Weight=0 Group=2 Counter=0</font></div></div><div><br></div><div>Eventually no MTP gets allocated in that first round, because CUCM is asking for an MTP which supports RTCP Pass-through (PT), which none of these apparently do.</div><div><br></div><div>So it goes in for a second round of asking, this time dropping the RTCP PT cap, and asking only for Codec PT.</div><div><br></div><div><div><font face="monospace">MediaResourceCdpc(142660)::goThroughDeviceTblAgain - goThruCount=2</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_2 Cepn=487e27a2-64a1-4283-9352-9798f51817ac Weight=1061 Group=2 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_3 Cepn=7a5007bb-120b-4ee0-953b-9ffdac723ea9 Weight=1061 Group=2 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_4 Cepn=7f5dac9e-9b3a-4276-a8fa-d114123b5939 Weight=1061 Group=2 Counter=0</font></div><div><font face="monospace">MediaResourceCdpc(142660)::createLookupTbl Name=MTP_DUDE Cepn=65de78dd-7e27-0133-5a5d-e3f6a1a75445 Weight=461 Group=1 Counter=0</font></div></div><div><br></div><div>Note the order is now different from the first round, and the weights are adjusted so that my target MTP is lower than the others.  This is because my IOS based MTP has codec g711ulaw configured on it, and not codec pass-through.</div><div><br></div><div>At first this through me for a loop, and I thought it was a bug, possibly with alphabetical ordering, or like that one from 5 years ago case sensitivity in resource names.</div><div><br></div><div>However, I did find two defects which cover my scenario exactly, and close the case for me.  I thought I would share with the group in case your MTP allocation has seemed "weird" lately.  Now you might know why.</div><div><br></div><div>For what it's worth, I did switch my IOS MTP to codec pass-through, and the weight did not change for the IOS MTP, and the software MTP on CUCM still won the selection process.  I did not disable pass-through on the CUCM side, per the defect, however, so I don't know at this moment how that might impact the order.</div><div><br></div><div>Added RTCP PT and refers to Documentation, but doesn't mention the order changing</div><div><br></div><div><a href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf63182/" target="_blank">https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf63182/</a><br></div><div><br></div><div>Mentions the order changing due to preference for MTPs with Codec Pass-through over MTPs without it</div><div><br></div><div><a href="https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc84953" target="_blank">https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc84953</a><br></div><div><br></div><div>*I was using PT and Pass-through interchangeably in this email.  I never meant PT to be Payload Type, just to be clear.</div></div>