cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
570
Views
10
Helpful
3
Replies

CUBE DTMF payload 110

b_ferguson
Beginner
Beginner

CUBE configured with dial-peer pointing to IVR system, calls originating from outside users that don't have the same carrier as the provider for this SIP trunk work just fine and their payload is showing as 101.  only calls originating from the same carrier that providers the SIP trunk show as a 110 and DTMF doesn't work.  I've tried asymmetric payload full and dtmf-internetworking rtp-nte among others but nothing seems to work.  debug ccsip messages comparison difference is the the following lines, a working call looks identical except where there is a 110, there is a 101.  No CUCM is involved with this.  

 
m=audio 10348 RTP/AVP 0 110
a=sendrecv
a=bsoft: 1 image udptl t38
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
3 Replies 3

You do not want asymmetric full as it instructs CUBE to leave the dynamic payload types untouched, ie not to interwork back to 101. I have seen carriers use 100 but not 110. Unless others have a clever idea, this is probably a TAC case once you remove the asymmetric command.

FYI- CSCwa92734 has been causing DTMF interop issues but does not appear to be what you’re seeing; that defect is for RFC2833 to KPML.

b.winter
VIP Advocate VIP Advocate
VIP Advocate

Have you tried with the command "rtp payload-type nte <nr>" command, to set the RTP-NTE payload type manually?
Could you post the full debug of such a call?

Sorry for the delayed response.  yes I've tried that command, still no change.  I ended up configuring "no notify redirect ip2ip" directly on the dial-peer and after that, the calls started working properly.  

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers