Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Analyzing CUCM SDi traces

Hi,

is there a doco anywhere that helps analyze SDI traces eg Codec capabilities of transcroders , endpoints etc

eg trying to debug below and not sure what Device Caps are available represented by 4 2 11 12 etc to help troubleshoot what is going on and why only MTP from PUB is being used. maybe the famous pass-thru bug i suspect in 8.5 CUCM possibly

12:24:01.324 |MediaTerminationPointControl(50)::waiting_AllocateMtpResourceReq - (capCount,region),A(4,Brisbane Region),B(3,Canberra Region), reqDevCap=0x19, reqMandatoryCaps=0x0, supDevCap=0x129, passthru=0, resourceCount=1|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::waiting_AllocateMtpResourceReq - (not an error) DeviceCap Mismatch|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- DeviceName=MTPHW-NR3845-1 Ci=26429444 ResourceCount=1|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- Logging RegionA=Brisbane Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 4 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not allocated|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- match1=1 match2=0|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- allocateErrBitset=0x41|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=26429444, errBitset=0x45|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::waiting_AllocateMtpResourceReq - (capCount,region),A(4,Brisbane Region),B(3,Canberra Region), reqDevCap=0x19, reqMandatoryCaps=0x0, supDevCap=0x12d, passthru=0, resourceCount=1|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::waiting_AllocateMtpResourceReq - (not an error) DeviceCap Mismatch|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- DeviceName=MTPHW-NR3845-2 Ci=26429444 ResourceCount=1|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- Logging RegionA=Brisbane Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- Device Caps = 4 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not allocated|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- match1=1 match2=0|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- allocateErrBitset=0x41|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=26429444, errBitset=0x45|2,100,230,1.89025^10.66.4

2 ACCEPTED SOLUTIONS

Accepted Solutions

Analyzing CUCM SDi traces

Hi dino,

As far as i know there is no such single document where you can get the idea of understanding sdi traces. It will generally come by experience and study.

Regarding your query please refer below link wher you will get which value is for which capabilities.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/7_0_1/cdr-defs/cdrcodes.html

Regards,

Nishant Savalia

Regards, Nishant Savalia
VIP Super Bronze

Re: Analyzing CUCM SDi traces

Dino,

Having looked at the trace, The reas0n why the PUB MTP is allocated is down to the exact reason I stated earlier...

The question then is this why does it choose the PUB MTP. I believe  strongly that the answer is this. CUCM software MTP support both  G711alaw and G711ulaw...Hence you are most likely to find that the  device cap for the MTP looks like this:

MTP/XCoder Device Caps = 4 2 257 259 261


OK..Lets dive in to the trace and prove this...

+++Here is the call flow+++

Call comes in to 2404 and then cti_port_29 was selected (extension 8529) So RTP will be connected between CUBE and this CTI_Port

Question 1, why is MTP needed..As mentioned earlier..DTMF mismatch

++++DTMF needed due to DTMF mismatch++++

23:46:04.749  |DET-MediaManager-(20733)::isMTPNeededForMismatchOrConfig,  MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1  dtmfMTPSide=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

Question 2, Why is PUB-MTP selected

To understand this we need to look at the two devices in the call here..CUBE and CTI_Port

The invite from CUBE shows that you have the ff: codecs configured: G711a and G729..

++++Device Caps from Trace+++++++++

Confirms that SideA(CUBE supports G711alaw, G729), sideB(CTI_Port supports G711a and G711u)

23:46:04.749 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=2|*^*^*

23:46:04.749  |DET-MediaManager-(20733)::checkAudioPassThru, param(0,1),  capCount(3,2), mtpPT=1,  aPT=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.749  |DET-MediaManager-(20733)::preCheckCapabilities, region1=Head Office  Region, region2=Head Office Region, Pty1 capCount=3 (Cap,ptime)= (2,20)  (11,20) (12,20), Pty2 capCount=2 (Cap,ptime)= (4,30)  (2,30)|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

+++MTP selection failed+++++

Now lets look at the MTP selection. Why did the preferred one fail...

From  the caps  and as explained earlier we can see that CUBE on SIDEA doesnt  support G711ulaw and the MTP selected here is configured for G711ulaw.  So we see CUCM spit out an Error

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  DeviceName=MTPHW-NR3845-2 Ci=43281075  ResourceCount=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- Logging  RegionA=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 2 257 259 261 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- Logging  RegionB=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- MTP/XCoder  Device Caps = 2 257 259 261  |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- Device Caps  = 4 2 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |RegionsServer::MatchCapabilities -- kbps=64, capACount=2, capBCount=4|*^*^*

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- match1=1  match2=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  DeviceName=MTPHW-NR3845-2 Ci=43281075  ResourceAllocated=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  allocateErrBitset=0x1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed --

++++MTP selection succesfull+++

Now lets look at why the MTP-PUB was used..

The caps advertised by this MTP is as follows:MTP/XCoder Device Caps = 25 4 2 257 259 (wideband, G711u, G711alaw)

The Device Caps = 2 11 12 (CUBE)

Now here is the difference...There is a match in the caps of this MTP and the CUBE..and bingo this gets selected.

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  DeviceName=MTP_PUB Ci=43281075  ResourceCount=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- Logging  RegionA=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 25 4 2 257 259 258 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- Device Caps  = 2 11 12 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=6|*^*^*

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- Logging  RegionB=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- MTP/XCoder  Device Caps = 25 4 2 257 259 258  |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- Device Caps =  4 2 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |RegionsServer::MatchCapabilities -- kbps=64, capACount=2, capBCount=6|*^*^*

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- match1=1  match2=2|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  DeviceName=MTP_PUB Ci=43281075  ResourceAllocated=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  allocateErrBitset=0x0|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::handleMtpDeviceFound|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logResourceStatusinTrace -- Device  Name=MTP_PUB ResourceAvailable=24  ResourceUsed=0|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::handleMtpDeviceFound ConversationId=33681952 CI=43281075 Allocated resource

++++What to do to allow CUCM select your IOS MTP++++

Change the codec to G711alaw

I can also confirm that G711alaw is used for the call...

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
25 REPLIES

Analyzing CUCM SDi traces

Hi dino,

As far as i know there is no such single document where you can get the idea of understanding sdi traces. It will generally come by experience and study.

Regarding your query please refer below link wher you will get which value is for which capabilities.

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/7_0_1/cdr-defs/cdrcodes.html

Regards,

Nishant Savalia

Regards, Nishant Savalia
Hall of Fame Super Silver

Analyzing CUCM SDi traces

Translator X is a handy tool that makes it much easier to read them:

http://translatorx.cisco.com

Chris

VIP Super Bronze

Re: Analyzing CUCM SDi traces

There is a book, it is old but its still very relevant. Its titled troubleshooting IP Telephony, by Paul giralt. Thats what I used to learn how to read traces...Any Cisco voice guy serious about his trade must have it!

Back to the trace..Since you only posted a snapshot of the whole trace, its difficult to know why the particular MTP was selected...But looking at the logs, CUCM has selected this MTP: MTPHW-NR3845-2...The region between the two endpoints involve Reg A= Brisbane and the MTP = 64kbps, the region between region =Canberra Region and the MTP =64kbps, but CUCM still complaint that :

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not allocated|2,100,230,1.89025^10.66.41.1^*

The trace however showed that the MTP is configured for G711ulaw

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Analyzing CUCM SDi traces

Hi aokan,

Trace shows that MTP device capabilites is matched but the device capabilities is not matched.

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 4 2 11 12|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 2 11 12|2,100,230,1.89025^10.66.41.1^*

@Aokan:- please correct me if i am wrong.

Regards,

Nishant Savalia

Regards, Nishant Savalia
VIP Super Bronze

Analyzing CUCM SDi traces

Nishant,

You have brouhg a valid point. However becuase of the difficulties in interpreting what the caps value stand for, I usually use the output of the RegionServer:Matchcapabilites to determine what is configured between the regions and in this case here is what I see..

The two regions are configured with 64kbps to the MTP/Xcoder region.

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not ..

Now looking at the capabilites for the xcoder...

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

It looks as though it is configured for G711ulaw...Thats where it all becomes strange...To solve this mystery we will need to know why is the MTP been invoked in the first place? and what the configuration of the MTP is...

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Re: Analyzing CUCM SDi traces

Hi Aokan,

I'm trying to cross reference Paul's book and your various other posts to understand the logic of the following syntax:

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

Logically - it is easy to understand your explanation that the two regions are configured for 64kpbs to the MTP/XCoder region as follows:

BRISBANE REGION << G711 >> XCODE REGION << G711>> CANBERRA REGIO

But what exactly does, in the first line, capACount=4 mean?  What does capACount=3 in the second line mean?

TIA,

Amir


New Member

Re: Analyzing CUCM SDi traces

So TAC gave me the codes for this before but I have to dig them out. I do know 4 tho.

When we decode "4" we could see that it maps to 711u  - Media_Payload_G711Ulaw64k = 4. That are their capabilities for that region to region.

So the common codec is 711u. And the region allows for 64k. I'll try to find the rest of them.

New Member

Analyzing CUCM SDi traces

Thank you very much Jay.

Regards,

Amir

VIP Super Bronze

Analyzing CUCM SDi traces

Amir,

After digging deep, I have found what those lines mean..So lets go back to this trace and I will explain it from here..its quite simple

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- Logging RegionA=Brisbane Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 4 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

12:24:01.324 |MediaTerminationPointControl(50)::getResourcesAllocated -- Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

Each side of the call is evaluated for their capabilites. The first side evaluated here is Region A and the Xcoder Region.

Here we see that the Region setting = 64Kbps and that ff:

MTP/XCoder Device Caps = 4 257 259 261 ----sideB

Device Caps = 4 2 11 12 ----side A

So for this side capAcount = 4 (total number of capabilites supported by this device) and capBcount  = 4 too.

Usually the Xcoder is sideB and the device is side A..So if we apply this then we look at the second device and the xcoder

Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.324 |MediaTerminationPointControl(50)::logCapabilitiesinTrace --

MTP/XCoder Device Caps = 4 257 259 261

Device Caps = 2 11 12

Hence CapAcount=3 and capB count =4

In this case the second device only supports 3 capabilites (G711alaw, G729, G729a)

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Analyzing CUCM SDi traces

Thank you very much Aokan!

Your explanation is perfect  and allows me to understand:

Calling Party (capA)   < >  MTP/XCODE (capB)

Called Party  (capA)   < >  MTP/XCODE (capB)

I was confused by the fact that I was seeing two sets of capACount / capBCount.  I was expecting that since there are 3 entities that one might see capA / capB / capC!  I couldn't piece it together until your great explanation.

The community owes you great thanks! 

Amir


VIP Super Bronze

Analyzing CUCM SDi traces

Dino,

Your post has attracted a lot of interests and I think I have figured out why the IOS MTP was not selected...Here is my analysis of the traces...

First of all I will like to define what the codec caps are so it is clear when we look at the logs..

1...2 = G711alaw, 4 = G711ulaw, 11 = G729, 12 = G729a

Now back to the trace..

+++CUCM selects an MTP:MTPHW-NR3845-2 a+++++++

12:24:01.325 |MediaTerminationPointControl(51)::waiting_AllocateMtpResourceReq - (capCount,region),A(4,Brisbane Region),B(3,Canberra Region), reqDevCap=0x19, reqMandatoryCaps=0x0, supDevCap=0x12d, passthru=0, resourceCount=1|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::waiting_AllocateMtpResourceReq - (not an error) DeviceCap Mismatch|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- DeviceName=MTPHW-NR3845-2 Ci=26429444 ResourceCount=1|2,100,230,1.89025^10.66.41.1^*

+++++CUCM them perform a capabilites check between MTP and the two devices involved in the call++++

++++++SIDE A+++++++

Region setting between Region A and Xcoder Region = 64kbps, the capabilites of each device is then analyzed..

Xcoder was configured with G711ulaw, hence we see this

MTP/XCoder Device Caps = 4 257 259 261 (4=G711ulaw, 257, 259, 261 is automatically added for G711)

Device it self supports the ff:

Device Caps = 4 2 11 12 (G711u, G711a, G729, G729a)

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- Logging RegionA=Brisbane Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- Device Caps = 4 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=4, capBCount=4|*^*^*

++++++SIDE B+++++++

Region setting between Region B and Xcoder Region = 64kbps, the capabilites of each device is then analyzed..

Xcoder was configured with G711ulaw, hence we see this

MTP/XCoder Device Caps = 4 257 259 261 (4=G711ulaw, 257, 259, 261 is automatically added for G711)

Device it self supports the ff:

Device Caps = 2 11 12 (, G711a, G729, G729a)

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- Logging RegionB=Canberra Region Caps and MTP/XCoder Region=Canberra Region Caps|2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 259 261 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |MediaTerminationPointControl(51)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,100,230,1.89025^10.66.41.1^*

12:24:01.325 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

12:24:01.325 |MediaTerminationPointControl(51)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not allocated|2,100,230,1.89025^10.66.41.1^*

So what we see is that SIDEB device doesnt support the codec that the MTP is configured with which is G711ulaw, Hence you get the error MTP allocation failure..

The question then is this why does it choose the PUB MTP. I believe strongly that the answer is this. CUCM software MTP support both G711alaw and G711ulaw...Hence you are most likely to find that the device cap for the MTP looks like this:

MTP/XCoder Device Caps = 4 2 257 259 261

Since the codec supported by the endpoint is present, the MTP is used...

There are two ways to confirm this...

1. Send us the log for the MTP that was selected and we will see in the trace the advertised device caps

2; Configure your IOS MTP to use G711alaw

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Analyzing CUCM SDi traces

Also the reason behind selection of PUB MTP always may be the device that invokes MTP has MRGL in which PUB MTP MRG may be in priority.

Please check your MRG & MRGL configuration.

Regards,

Nishant Savalia

Regards, Nishant Savalia
New Member

Analyzing CUCM SDi traces

hi Nishant,

no the PUB and SUB MTPs are in the last MRG in both devices (SIP Ttunk and CTI port) MRGL. The HW and SW router resources are ordered in the higher MRG from the router below:

sccp local Loopback0

sccp ccm 10.66.22.20 identifier 2 version 7.0

sccp ccm 10.66.21.20 identifier 1 version 7.0

sccp ip precedence 3

sccp

!

sccp ccm group 988

bind interface Loopback0

associate ccm 2 priority 1

associate ccm 1 priority 2

associate profile 8 register MTPHW-NR3845-2

associate profile 10 register CFB-NR3845-2

associate profile 6 register XCODE-NR3845-2

associate profile 7 register MTPiOS-NR3845-2

keepalive retries 5

switchover method immediate

switchback method immediate

switchback interval 15

!

dspfarm profile 6 transcode 

codec g729abr8

codec g729ar8

codec g711alaw

codec g711ulaw

maximum sessions 16

associate application SCCP

!

dspfarm profile 10 conference 

codec g729br8

codec g729r8

codec g729abr8

codec g729ar8

codec g711alaw

codec g711ulaw

maximum conference-participants 16

maximum sessions 6

associate application SCCP

!

dspfarm profile 7 mtp 

codec g711ulaw

maximum sessions software 24

associate application SCCP

!

dspfarm profile 8 mtp 

codec g711ulaw

maximum sessions hardware 24

associate application SCCP

!        

!

VIP Super Bronze

Analyzing CUCM SDi traces

Dino,

Have you tried my suggestions..??

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Analyzing CUCM SDi traces

Hi,

Thanks for your tips  so far and that fantastic book. I wonder why they never released a new one...! it is so good.

Anyhow, in the above response i showed the dsp and sccp config that MTP resources are in that are being selected,

You are correct about G711 but the incoming call is G711a from ITSP and we are negotiating G711a with CUCM wcih then hands off to a CTI route point. This is where I am not sure if G711a is being selected all the way thru. I expect MTP to be invoked for DTMF as we have rtp-nte on dial peer for incoming call to CUCM and the CTI Port I believe does not support rtp-nte/2833... ?

Also another question, can CUCM accept over a SIP trunk pure inband thru the G711 audio stream (not NTE but in audio stream)?

VIP Super Bronze

Analyzing CUCM SDi traces

Dino,

It is difficult to know what codec is used for the call since we dont have the traces for that. I am not sure how G711alaw will be used because from the traces, one of the devices doesnt seem to have that in its device caps.

I agree that MTP will be needed for DTMF mismatch here as I dont think CTI ports support rtp-nte..Again the full log will confirm this..

I doubt if CUCM will do pure inband for MTP. Usually you have three options on the sip trunk..OOB, RFC2833 or no preference. Pure inband is most times only applicable with ISDN. Although if you do not configure any DTMF method on a gateway, it defaults to pure inband...and that itself may create issues because endpoints on cucm may not support this.

Do you want to send a full trace for a call and we can answer the ff questions:

1. Why MTP is needed

2. Why PUB MTP is selected

3. WHat codec is used for calls

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Analyzing CUCM SDi traces

OK I will send u CUCM SDi trtace. Also you mentioned the log from the MTP that was selected. What debug would that be?

VIP Super Bronze

Analyzing CUCM SDi traces

It will be part of the CUCM SDI traces

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Analyzing CUCM SDi traces

Hi dino,

How you can say PUB MTP is always being used because from your logs the MTP which CUCM selecting is

MTPHW-NR3845-2 which is not your PUB MTP and infact it's your hardware IOS MTP.

And also let us know which MTP is this MTPHW-NR3845-1? I mean where is this MTP configured and registered?

Also while sending full trace please do mention the exact issue you are facing because so far you have not mentioned what's the exact issue you are facing.

Regards,

Nishant Savalia


Regards, Nishant Savalia
New Member

Re: Analyzing CUCM SDi traces

Setup:

iTSP--SIP Trunk-- MyCUBE--SIP Trunk--CUCM[Pub and Sub]--IVRContactCentre(CTI Ports and RPs)

                                                                        |

                                                                 7900 Type A sccp Handsets

Please find attached trace.

We have 2 issues:

1) Not sure why MTPs on PUB or being selected evn though they are in the lowest priority MRG in the Canberra MRGL (HW and SW iOS MTPs and XCODERs from routers 10.66.41.1 and 10.66.41.210 are preferred). MTPs required for dtmf

2) Sometimes when call comes into IVR we are getting double digits being sent to system. IN trace file we press "2" twice but we go to the third level when the second 2 is pressed (ie when 2nd "2" is pressed by outside caller 00204002244 the IVR system interprets 2 "2"s being pressed and caller lands on 8640 "Account Rec" queue

On iTSP side, they only support G711a and no dtmf (inband AUDIO). ON CUCM side I have rtp-nte and g711a via the cube.

Thanks gents

Dino

VIP Super Bronze

Re: Analyzing CUCM SDi traces

Dino,

Having looked at the trace, The reas0n why the PUB MTP is allocated is down to the exact reason I stated earlier...

The question then is this why does it choose the PUB MTP. I believe  strongly that the answer is this. CUCM software MTP support both  G711alaw and G711ulaw...Hence you are most likely to find that the  device cap for the MTP looks like this:

MTP/XCoder Device Caps = 4 2 257 259 261


OK..Lets dive in to the trace and prove this...

+++Here is the call flow+++

Call comes in to 2404 and then cti_port_29 was selected (extension 8529) So RTP will be connected between CUBE and this CTI_Port

Question 1, why is MTP needed..As mentioned earlier..DTMF mismatch

++++DTMF needed due to DTMF mismatch++++

23:46:04.749  |DET-MediaManager-(20733)::isMTPNeededForMismatchOrConfig,  MTPNeededDueToDTMFCapMismatch(2833/OOB) mtpinsertionReason=1  dtmfMTPSide=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

Question 2, Why is PUB-MTP selected

To understand this we need to look at the two devices in the call here..CUBE and CTI_Port

The invite from CUBE shows that you have the ff: codecs configured: G711a and G729..

++++Device Caps from Trace+++++++++

Confirms that SideA(CUBE supports G711alaw, G729), sideB(CTI_Port supports G711a and G711u)

23:46:04.749 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=2|*^*^*

23:46:04.749  |DET-MediaManager-(20733)::checkAudioPassThru, param(0,1),  capCount(3,2), mtpPT=1,  aPT=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.749  |DET-MediaManager-(20733)::preCheckCapabilities, region1=Head Office  Region, region2=Head Office Region, Pty1 capCount=3 (Cap,ptime)= (2,20)  (11,20) (12,20), Pty2 capCount=2 (Cap,ptime)= (4,30)  (2,30)|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

+++MTP selection failed+++++

Now lets look at the MTP selection. Why did the preferred one fail...

From  the caps  and as explained earlier we can see that CUBE on SIDEA doesnt  support G711ulaw and the MTP selected here is configured for G711ulaw.  So we see CUCM spit out an Error

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  DeviceName=MTPHW-NR3845-2 Ci=43281075  ResourceCount=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- Logging  RegionA=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 2 257 259 261 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- Device Caps = 2 11 12 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=4|*^*^*

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- Logging  RegionB=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- MTP/XCoder  Device Caps = 2 257 259 261  |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::logCapabilitiesinTrace -- Device Caps  = 4 2 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |RegionsServer::MatchCapabilities -- kbps=64, capACount=2, capBCount=4|*^*^*

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated -- match1=1  match2=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  DeviceName=MTPHW-NR3845-2 Ci=43281075  ResourceAllocated=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750  |MediaTerminationPointControl(58)::getResourcesAllocated --  allocateErrBitset=0x1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.750 |MediaTerminationPointControl(58)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed --

++++MTP selection succesfull+++

Now lets look at why the MTP-PUB was used..

The caps advertised by this MTP is as follows:MTP/XCoder Device Caps = 25 4 2 257 259 (wideband, G711u, G711alaw)

The Device Caps = 2 11 12 (CUBE)

Now here is the difference...There is a match in the caps of this MTP and the CUBE..and bingo this gets selected.

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  DeviceName=MTP_PUB Ci=43281075  ResourceCount=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- Logging  RegionA=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 25 4 2 257 259 258 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- Device Caps  = 2 11 12 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |RegionsServer::MatchCapabilities -- kbps=64, capACount=3, capBCount=6|*^*^*

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- Logging  RegionB=Head Office Region Caps and MTP/XCoder Region=Head Office Region  Caps|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- MTP/XCoder  Device Caps = 25 4 2 257 259 258  |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logCapabilitiesinTrace -- Device Caps =  4 2 |2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |RegionsServer::MatchCapabilities -- kbps=64, capACount=2, capBCount=6|*^*^*

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated -- match1=1  match2=2|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  DeviceName=MTP_PUB Ci=43281075  ResourceAllocated=1|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::getResourcesAllocated --  allocateErrBitset=0x0|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::handleMtpDeviceFound|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751  |MediaTerminationPointControl(1)::logResourceStatusinTrace -- Device  Name=MTP_PUB ResourceAvailable=24  ResourceUsed=0|2,200,21,1.131403^10.66.22.30^ContactCentre-Port-29

23:46:04.751 |MediaTerminationPointControl(1)::handleMtpDeviceFound ConversationId=33681952 CI=43281075 Allocated resource

++++What to do to allow CUCM select your IOS MTP++++

Change the codec to G711alaw

I can also confirm that G711alaw is used for the call...

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Re: Analyzing CUCM SDi traces

Yep, +5 Aokanlawon

Regards,

Nishant Savalia

Regards, Nishant Savalia
New Member

Analyzing CUCM SDi traces

Wow Great job explaining by aokanlawon! 5 * indeed. That took a lot of time. For my minor contribution was able to dig out the codec mapping table. Hopefully will save you some time from having to dig and find these in the future.

    // Media_Payload_NonStandard = 1,

    Media_Payload_G711Alaw64k = 2,

    Media_Payload_G711Alaw56k = 3,      // "restricted"

    Media_Payload_G711Ulaw64k = 4,

    Media_Payload_G711Ulaw56k = 5,      // "restricted"

    Media_Payload_G722_64k = 6,

    Media_Payload_G722_56k = 7,

    Media_Payload_G722_48k = 8,

    Media_Payload_G7231 = 9,

    Media_Payload_G728 = 10,

    Media_Payload_G729 = 11,

    Media_Payload_G729AnnexA = 12,

    // Media_Payload_Is11172AudioCap = 13,

    // Media_Payload_Is13818AudioCap = 14,

    Media_Payload_G729AnnexB = 15,

    Media_Payload_G729AnnexAwAnnexB = 16,

/*lji GSM codec support*/

    Media_Payload_GSM_Full_Rate = 18,

    Media_Payload_GSM_Half_Rate = 19,

    Media_Payload_GSM_Enhanced_Full_Rate = 20,

/*lji GSM codec support*/

    Media_Payload_Wide_Band_256k = 25,

    Media_Payload_Data64 = 32,

    Media_Payload_Data56 = 33,

    Media_Payload_G7221_32K = 40,

    Media_Payload_G7221_24K = 41,

    Media_Payload_AAC = 42,

    Media_Payload_GSM = 80,

    // Media_Payload_ActiveVoice = 81,

    Media_Payload_G726_32K = 82,

    Media_Payload_G726_24K = 83,

    Media_Payload_G726_16K = 84,

//  Media_Payload_G729_B = 85,

//  Media_Payload_G729_B_LOW_COMPLEXITY = 86

    Media_Payload_ILBC = 86,

    Media_Payload_ISAC = 89,

    Media_Payload_H261 = 100,

    Media_Payload_H263 = 101,

    Media_Payload_Vieo = 102,

    Media_Payload_H264 = 103,   // Skate Video - H264

    Media_Payload_H264_SVC = 104,

    Media_Payload_T120 = 105,

    Media_Payload_H224 = 106,

    Media_Payload_T38Fax = 107,

    Media_Payload_TOTE   = 108,

    Media_Payload_XV150_MR_711U = 111,

    Media_Payload_NSE_VBD_711U = 112,

    Media_Payload_XV150_MR_729A = 113,

    Media_Payload_NSE_VBD_729A = 114,

    Media_Payload_Clear_Chan = 120,

    Media_Payload_RFC2833_DynPayload = 257,     // This is an extended payload type to indicate RFC2833 support

    Media_Payload_PassThrough = 258,    //For Audio\video\data\T38 streams pass thru. This includes dynamic Payloadtype passthru for 263 streams.

    Media_Payload_Dynamic_Payload_PassThru = 259,       //Can be used for any dynamic Payload type but is mainly being used for 2833 in SD GA release

    Media_Payload_DTMF_OOB = 260,

    Media_Payload_Inband_DTMF_RFC2833 = 261,

    Media_Payload_Max           // Please leave this so we won't get compile errors.

VIP Super Bronze

Analyzing CUCM SDi traces

Jay thanks for this...Hey! You didnt rate the post! Sure you meant to

Please rate all useful posts

"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
New Member

Analyzing CUCM SDi traces

Oppss! Now it is

3011
Views
35
Helpful
25
Replies
CreatePlease to create content