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]

@Vaijanath Sonvane and @aalejo - I am aware of transrating. And, as far as I'm aware, CUCM uses a software MTP for this purpose. Something has to unwrap-rewrap the packets and don't think the CallManager Service does this. That's why I was asking Vaijanath if a software MTP was available on the node that was processing the call. The call by the Media Resource Manager to a local MTP would not show on a TranslatorX diagram, but would appear in the trace file.

The c= line on the first of the two screen grabs clearly shows that the RTP stream is flowing through the 107.253 node, implying that an MTP is in use. But your post mentions that you don't have one. So, I'd love to see the trace file.

Maren

[Vaijanath Sonvane]

@Maren Mahoney 107.253 is CUBE router. 

[Maren Mahoney]

@Vaijanath Sonvane Ah. Now that makes sense. @aalejo wrote in his original post that CUCM does not invoke a transcoder so I assumed that node was a server and not a CUBE.

@aalejo - Do you have transcode resources (LTI) registered to the CUBE process? If the node connecting the two call legs is a CUBE, then CUCM would not 'know' that an MTP is required and would not allocate one. If the CUBE is connecting the call legs then the CUBE process itself would need to be able to allocate the resource.

As @Vaijanath Sonvane pointed out, and as I mentioned before, without trace files from CUCM and a debug from the CUBE it is unlikely that we can troubleshoot further. If you do provide trace/debug files, please attach them to a post (rather than pasting the output into the post itself which makes things super-hard to read.)

Maren

[aalejo]

@Maren Mahoney I also tried with LTI with similar results.
CUCM does know:  One side advertised 20ms (On the SIP Invite) and the other responds with 10ms (on then 200 OK). Then CUCM does know..

[aalejo]

I understand your point.

[Vaijanath Sonvane]

Hi @Maren Mahoney The IP Media Services are disabled on all my CUCM Nodes and there are no hardware MTP registered to CUCMs. This setup is all without any media resources. 

[Steven L]

you ABSOLUTELY require an MTP for this scenario.

I think you need to figure out how to isolate this traffic and create a separate trunk and check "MTP Required"

the issue here is that ptime mismatch does not trigger the "if needed" setting

[aalejo]

Yea, trying to avoid MTP required solution by having CUCM negotiate.

Using required MTP is my last resort.

[Steven L]

i have run into this before and that was the solution. i hate using "MTP Required". usually it just masks the real issue.

in this case, it is the only way i have been able to resolve. but i did create a new trunk using a different port for this.

[aalejo]

I know. Same here. Pain in the neck. Looking for a more optimal solution every few years but looks there is none (yet). Believe it of not i have similar issue more than 15-17 years back.

[Vaijanath Sonvane]

Hi @aalejo 

1. What is your scenario?
2. Which devices are involved (calling and called parties as well)?
3. What audio codec are you using on both ends and can you please post the log files? 

[aalejo]

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

[Vaijanath Sonvane]

Hi @aalejo.,

Thank you for this information but this is not enough to help you and troubleshoot the issue. Without logs, without any information of setup, without knowing which device is sending disconnect message or disconnect cause code, it is hard to troubleshoot and provide you any help. As many have suggested to enable "MTP", this did not resolve your issue. If it it not possible to post logs or other information then please open Cisco TAC case.

[aalejo]

Hey @Vaijanath Sonvane 

Thank you for your input on this case. appreciate it.

As i said to Maren, i am not looking for help on troubleshooting this issue, only on the theoretical side of it.

Thanks again to @Maren Mahoney, Yourself and @Steven L .

Alex

[Vaijanath Sonvane]

Hi @aalejo, Hope you find a better solution and share your findings here. Would be interested to know other options to address this issue.