Solved: SIP ITSP DTMF Issue

Gregory Brunn · ‎01-05-2016

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

Ayodeji Okanlawon · ‎01-06-2016

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

Please rate all useful posts

View solution in original post

Mohammed al Baqari · ‎01-05-2016

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

Gregory Brunn · ‎01-06-2016

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?

Ayodeji Okanlawon · ‎01-06-2016

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..

Please rate all useful posts

Gregory Brunn · ‎01-06-2016

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.

Deepak Mehta · ‎01-19-2016

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.

Mohammed al Baqari · ‎01-19-2016

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

Ayodeji Okanlawon · ‎01-20-2016

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.

Please rate all useful posts

Ayodeji Okanlawon · ‎01-06-2016

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

Please rate all useful posts

Gregory Brunn · ‎01-06-2016

Thank you Ayodeji

I will reach out to the carrier before moving forward.

Gregory Brunn · ‎01-08-2016

Just got off with the Telco they enabled rtp-nte and all worked as it should.

Thanks!