01-05-2016 02:03 PM - edited 03-17-2019 05:25 AM
I am currently having a problem where DTMF relay is not working correctly from a new SIP ITSP.
My topology is ISTP<-->CUBE<-->CUCM.
I was not involved in the inital planning session with the carrier however I am of course assuming that they are supporting RFC 2833/RFC 4733.
I have configured both the incoming dial-peer from the ITSP and SIP dial peer pointing to CUCM
"dtmf-relay rtp-nte"
My problem is when calling into unity connection, dtmf is not working. There is a SCCP integration with CUCM however another SIP ITSP has no problems.
I did a debug voip rtp session named-event, and did not receive any output.
I did a side by side comparison and noticed that in my initial invite from the carrier I see a=rtpmap:100 telephone-event/8000 in the initial invite.
However with the trunk that is currently having the DTMF issue I do not.
I am guessing the carrier is not properly advertising DTMF-Relay to us and that is why it is not working.
I do not see any another DTMF methods being advertised but I may be wrong.
Also does anyone know if the "voice-class sip dtmf-relay force rtp-nte" command needs to be used if the carrier does not send the a=rtpmap:100 telephone-event/8000 in the initial SDP.
Below is a sanitized configuration of the debug ccsip command showing the initial invite.
Received:
INVITE sip:callednumber@IP:5060 SIP/2.0
Via: SIP/2.0/UDP IP:5060;branch=
From: "Unavailable" <sip:+Callingnumber@publicip:5060>;tag=gK007b9488
To: <sip:+callednumber@gatewayaddr:5060>
Call-ID: 302011365_133986445@publicip
CSeq: 1114215033 INVITE
Max-Forwards: 53
Allow: INVITE,ACK,CANCEL,BYE,PRACK,UPDATE
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: "Unavailable" <sip:+CallingNumber@publicip:5060>
Supported: 100rel
Content-Length: 218
Content-Disposition: session; handling=required
Content-Type: application/sdp
v=0
o=Sonus_UAC 8 IN IP4 publicip
s=SIP Media Capabilities
c=IN IP4 Public IP
t=0 0
m=audio 15558 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv
a=maxptime:20
Solved! Go to Solution.
01-06-2016 01:46 AM
First of all you need to get in touch with your ITSP. This INVITE has no DTMF capabilities advertised. You need to sort their side out first before proceeding further.
For DTMF to work, your m-line needs to have DTMF event advertised atleast for rfc2833..Example below
Here payload 101 is used for telephone-event (DTMF). In your SDP we dont see any of this.
m=audio 28050 RTP/AVP 18 100 101
c=IN IP4 10.10.20.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
01-05-2016 09:18 PM
Hi,
Since your CUC is using SCCP integration then RTP-NTE won't work by default. To get it working:
1. Configuration MTP resources on the CUBE (software or hardware)
2. Register the MTP with CUCM
3. Assign MTP to MRG > MRGL > VoicePorts
4. Make sure that MTP is configured for the same codec used between CUC --- CUBE
For the other ITSP which is working, I believe they are using out-of-band DTMF relay which will work with CUC and this is the reason why you don't see the telephony-event header in the INVITE message.
Also, for precautions enable asymmetric payload-type in CUBE under voice service voip --> SIP
01-06-2016 04:46 AM
Mohammad,
The other carrier is actually sending the following SDP.
I did not fully debug the other carrier to see if I saw the digits being sent with a debug voip rtp session named-event.
To me this looks like RFC 2833 or RFC 4733.
See below for the SDP invite from the carrier.
t=0 0
m=audio 18262 RTP/AVP 18 0 100
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
a=maxptime:30
I don't understand the difference between the 100 code however as compared to the sip leg to the CUCM which has a a=rtpmap:101 telephone-event/8000?
01-06-2016 06:09 AM
Greg,
RFC2833 uses a set of dynamic payload from 96-127. This means that different carriers can use any payload from 96 -127. Cisco typically uses 101 for rtp-nte. In your case your provider is using 100. This in itself could cause you some issues because on cisco gateways payload 100 is assigned to modem pass-through..
01-06-2016 06:13 AM
Interesting so the a=rtpmap:100 telephone-event/8000 was seen on the working SIP trunk configuration. Maybe the fact that it was present was not the true different that was making the old SIP trunk DTMF work where as the new SIP Trunk was not. I will still contact the carrier to make sure I am on the same page first.
Thanks once again.
01-19-2016 01:24 PM
Hi Ayo,
I also have same type of issue.
Call flow
Ayava session manger----SIP Trunk ---CUCM---SiP Phone---SCCP----Cisco Unity
DTMF is not working when the call goes to unity voicemail.
On Inital invite from avaya to CUCM we do see RTP NTE being relayed.
===============================
Contact: < sip:6125007811@172.19.56.150:5060;transport=tcp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: application/media_control+xml, application/sdp, multipart/mixed
Content-Type: application/sdp
Content-Length: 207
P-Asserted-Identity: < sip:6125007811@tel.rbc.com>
Supported:
Remote-Party-ID: < sip:6125007811@tel.rbc.com> ;party=calling;screen=no;privacy=off
Route: < sip:10.70.120.144;transport=tcp;lr;phase=terminating>
P-Location: SM;origlocname=" nysbc" ;termlocname=" Cisco_Sub_1"
Max-Forwards: 64
User-Agent: AVAYA-SM-6.1.7.0.617012
v=0
o=BroadWorks 465437392 1 IN IP4 172.19.56.150
s=-
c=IN IP4 172.19.56.150
t=0 0
m=audio 53558 RTP/AVP 18 0 8 101
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000>>>>>>>>>>>>>>>
a=fmtp:101 0-15
a=ptime:20
=============================================
I also see 487 from Phone towards CUCM probaly because i disconnected after no DTMF was recognized.
SIP/2.0 487 Request Cancelled
Via: SIP/2.0/TCP 10.70.120.144:5060;branch=z9hG4bK56b341b6efc3
From: < sip:6125007811@10.70.120.144> ;tag=91346~eb300add-893a-4e1a-a3da-3f1f5b5d9e20-38100925
To: < sip:2128479139@rbcuscucmsub1.rns.fg.rbc.com> ;tag=b000b4ba18af153a0f412308-6acd734e
Call-ID: 5ce4ac80-69e1a6c6-5308-9078460a@10.70.120.144
Date: Tue, 19 Jan 2016 21:12:57 GMT
CSeq: 101 INVITE
Server: Cisco-CP8861/10.3.1
Contact: < sip:4d6963c8-943a-24ee-e373-d4773668d2ff@10.70.44.90:52766;transport=tcp>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: " Deepak-318113024" < sip:2128479139@rbcuscucmsub1.rns.fg.rbc.com> ;party=called;id-type=subscriber;privacy=off;screen=yes
Allow-Events: kpml,dialog>>>>>>>>
Content-Length: 0
++++++++++++++++++++++++++++++++++++++++++++++
DTMF works fine when we call from another cisco phoen which is on Same CUCM but not from outside over SIP trunk
Please let me know what more we can check on this.
01-19-2016 06:40 PM
Hi,
You need to insert mtp between unity connection and avaya to translate from inband to outband dtmf signalling. Configure software or hardware mtp with the same codec used for the call. Assign the mtp to mrg and mrgl. Finally assign the mrgl to voice mail ports
01-20-2016 02:28 AM
As Mohammed mentioned, you will need an MTP for this scenario. This is because unity connection sccp ports do not support inband DTMF method. Your other option is to change your unity integration to sip and then everything should work smoothly. Personally I believe using a sip integration would be your best solution here.
01-06-2016 01:46 AM
First of all you need to get in touch with your ITSP. This INVITE has no DTMF capabilities advertised. You need to sort their side out first before proceeding further.
For DTMF to work, your m-line needs to have DTMF event advertised atleast for rfc2833..Example below
Here payload 101 is used for telephone-event (DTMF). In your SDP we dont see any of this.
m=audio 28050 RTP/AVP 18 100 101
c=IN IP4 10.10.20.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
01-06-2016 04:48 AM
Thank you Ayodeji
I will reach out to the carrier before moving forward.
01-08-2016 12:14 PM
Just got off with the Telco they enabled rtp-nte and all worked as it should.
Thanks!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide