[cisco-voip] CUCM MTP Selection Order Has Changed in 10.5(2)+

[Anthony Holloway]

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.

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.

MediaResourceCdpc(142660)::createDevicePidTable - Entries copied in the
Device Table = 4
MediaResourceCdpc(142660)::createLookupTbl
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_DUDE
Cepn=65de78dd-7e27-0133-5a5d-e3f6a1a75445 Weight=0 Group=1 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_2
Cepn=487e27a2-64a1-4283-9352-9798f51817ac Weight=0 Group=2 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_3
Cepn=7a5007bb-120b-4ee0-953b-9ffdac723ea9 Weight=0 Group=2 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_4
Cepn=7f5dac9e-9b3a-4276-a8fa-d114123b5939 Weight=0 Group=2 Counter=0

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.

So it goes in for a second round of asking, this time dropping the RTCP PT
cap, and asking only for Codec PT.

MediaResourceCdpc(142660)::goThroughDeviceTblAgain - goThruCount=2
MediaResourceCdpc(142660)::createLookupTbl
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_2
Cepn=487e27a2-64a1-4283-9352-9798f51817ac Weight=1061 Group=2 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_3
Cepn=7a5007bb-120b-4ee0-953b-9ffdac723ea9 Weight=1061 Group=2 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_4
Cepn=7f5dac9e-9b3a-4276-a8fa-d114123b5939 Weight=1061 Group=2 Counter=0
MediaResourceCdpc(142660)::createLookupTbl Name=MTP_DUDE
Cepn=65de78dd-7e27-0133-5a5d-e3f6a1a75445 Weight=461 Group=1 Counter=0

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.

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.

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.

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.

Added RTCP PT and refers to Documentation, but doesn't mention the order
changing

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf63182/

Mentions the order changing due to preference for MTPs with Codec
Pass-through over MTPs without it

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvc84953

*I was using PT and Pass-through interchangeably in this email.  I never
meant PT to be Payload Type, just to be clear.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180321/643a0093/attachment.html>