cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
231
Views
4
Helpful
5
Replies

DTMF issue

1620415
Level 1
Level 1

there is no CUBE between the telco and CUCM Could you provide some guidance on how to resolve this issue?

* this call flow work on another telco.

*Works for landline calls but not for mobile calls

 

Screenshot 2024-09-19 170057.png

 

 

5 Replies 5

Jonathan Schulenberg
Hall of Fame
Hall of Fame

What DTMF method is negotiated in the SIP/SDP dialog in the working and non-working scenarios? What’s different? Impossible to offer a solution when we don’t know what’s actually going wrong.

And CUCM is not designed to be the edge device; it lacks a lot of the interop capabilities of CUBE or any other SIP SBC. Don’t be surprised if the answer ends up being “you need a real SBC.”

 

 

The current method for DTMF is RFC 2833, utilized by both the ISP and the
other party's telephony system, both working an non-working.

Which dynamic payload type are both sides using - and does that change between working/non-working?

Does the issue occur if CUCM immediately redirects an incoming call out the second carrier via a Translation Pattern or only after CUC transfers the call?

Is an MTP being invoked in either scenario?

The issue only occurs when CUC transfers the call. However, when I redirect the call using a translation pattern, the DTMF works correctly on the second carrier. 


I currently have MTP enabled on the SIP trunks from the Telco to CUCM,
CUCM > CUC not enable MTP
CUCM to second carrier enable MTP

MTPs are usually a bad idea. They're not scalable. Most of the time they are a workaround instead of a proper solution to whatever is wrong. Sometimes they cause issues of their own.

You need to look at the log files to see what is different in the SDP between working & non-working scenarios.