CUCM SIP Trunks not matching ptime

[aalejo]

I have CUCM that connect two SIP trunks with not matching ptime: Calling support pt=20ms only and the other (called) support 10ms. On Invite, Calling SIP trunks sends pt=20ms and receiver responds with 200 OK pt=10ms. Calling disconnects call since does not support pt=10ms. 

CUCM does not invoke transcoders/transraters even when both advertised non matching ptime.
Any idea?

[Maren Mahoney]

---

@aalejo wrote:

Hey Vaijanath

This is all the information you need:

        - Both side agree and support  711ulaw codec

         - One side support ptime=10ms ONLY and the other support ptime=20ms ONLY

         - Both are connected  over SIP trunk to CUCM

Sorry, can not post logs here.
Alex

---

So it seems I was correct that your scenario and the one that Vaijanath posted were different. His used a CUBE to connect the two call legs, and yours connects the two call legs via CUCM. Do I have that right?

Which brings me back to my original questions about whether an MRGL that includes an MTP is configured on one or both trunks, whether the SIP Profile allows an MTP to be used, and whether the IP Voice Media Streaming App service is available.

If the answers to all three questions are "Yes", and if you can't post a trace file, then we cannot help and you will need to contact TAC.

Maren

[aalejo]

In general terms, yes. He is using a end point (Cisco) phone that can negotiate ptime 10ms/20ms (or both): then he will see no issue.

Yes, there are MRG / MRGL that includes transcoders as needed.

Thats OK. My question (here) was not for purpose of troubleshooting. More like a provide a solution (or a concept of). As @Steven L  mentioned this is an old problem

[Maren Mahoney]

Other than the suggestions already made, without a trace file to determine the exact nature of the messaging and failure there is nothing more I can do here. Contact TAC.

Maren

[Steven L]

i dont think he said checking "MTP Required" did not solve his issue. he said he did not want to do that.

My guess is that it does "fix" it, but is generally not really a fix.

[aalejo]

MTP required "fix" the issue indeed but i don't want to follow that path. As you said is more like masking the issue.