DTMF fails towards the telco using SIP trunk

[Eivind Jonassen]

Hi,

I´ve having some difficulties with a telco who uses Sonus GW. DTMF doesn´t work. The telco is reffering to this document;

http://supportwiki.cisco.com/ViewWiki/index.php/The_DTMF-relay_of_the_Cisco_CallManager_SIP_trunk_fails_to_work_with_the_SIP_VoIP_Telco_because_the_terminating_side_does_not_receive_the_DTMF_digits

I see that this is related to version 4.1 of the callmanager and don´t know if this is in any way related to UC500 ver 7.0.3

Any help or suggetions on how to relsolv this would be great.

Thanks,

Eivind

[Maulik Shah · Accepted solution]

When you say fails - is it:

- cannot dial DTMF outbound  or inbound etc

- DTMF entered is duplicate digits

What DTMF method does the SIP provider claim to support - RFC2833? Few posts that were on similar issues:

https://www.myciscocommunity.com/message/13715#13715

https://www.myciscocommunity.com/message/10380#10380

The post about CUCM does not apply as that is a different platform compared to UC520

[Eivind Jonassen]

Maulik,

Thanks for your input. The DTMF is for outbound calls. Whenever a caller (on the UC) calls a number which has a menu (like an AA), it´s not possible to dial the digits in that menu.

The telco claims that the problem is with the UC500 (of course) and not on their GW. They claim that this is a known problem with UC500 and relay DTMF from endpoint towards a SIP GW which is not from Cisco, and in their case Sonus. They were also the ones that provided the link with the CUCM issue.

The DTMF has worked in the past though, but then the telco used a cisco GW, they have now moved the cisco GW to the sonus, and that´s when the issue started.

I´ll check with them tomorrow regarding the RFC.

Thanks

Eivind

[Maulik Shah · Accepted solution]

Sure - if you want to prove the case assuming this is DTMF using RFC2833 - you can do one or two things:

- deb ccsip message / deb voip rtp session named-events which will show the digits OR

- wireshark capture which will show the same

If they do not use RFC2833 but plain inband DTMF in the voice stream (which is an unreliable method) - then this will not work outbound as you describe. Most SPs do support RFC2833 to ensure reliable DTMF.

[Eivind Jonassen]

Maulik,

Got the respons from the telco, they use RFC 2833. I did the debug and got the following output when I pressed "1";

014467: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x163C timestamp 0x8308AEB4

014468: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:04 00 00  >>

014469: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x163D timestamp 0x8308AEB4

014470: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:04 00 00  >>

014471: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x163E timestamp 0x8308AEB4

014472: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:04 00 00  >>

014473: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x163F timestamp 0x8308AEB4

014474: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:04 01 90  >>

014475: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x1640 timestamp 0x8308AEB4

014476: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:84 03 20  >>

014477: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x1641 timestamp 0x8308AEB4

014478: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:84 03 20  >>

014479: Aug 12 23:30:07.361:          s=DSP d=VoIP payload 0x65 ssrc 0xE1F97B48 sequence 0x1642 timestamp 0x8308AEB4

014480: Aug 12 23:30:07.361:          Pt:101    Evt:1       Pkt:84 03 20  >>

Is this correct behavior?

Thanks

Eivind

[Maulik Shah · Accepted solution]

The below output is correct - each digit will have 7 packets sent - here is an example for digit 5 (Evt:5) and the corresponding decode in English:

Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:04 01 90  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  >>
Apr 13 19:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  >>

The first packet says that it is the start of a new NTE digit because it does not have the endbit set (04).  The second and third
packets are repeats of the first packet for redundancy.

The fourth packet is a refresh packet with a duration of 50ms (0x0190 = 400 samples * 1sec / 8000 samples). 

The fifth packet is the endbit packet (84) with a duration of 100ms (0x0320 = 800 samples * 1sec / 8000 samples).  The sixth and
seventh packets are redundant packets for packet five.

We see that the reserved bit and volume settings are constant at 4 = 0100, which means that we have a volume of 4 and a reserved bit
value of 0.

[Eivind Jonassen]

Thanks for your info Maulik,

What is your recommandation that I should do regarding the next step towards the telco?

Thanks,

Eivind

[Maulik Shah · Accepted solution]

The debug proves if you press 1 on IP phone - the digit is being sent out (you can get a wireshark for the same). You could now take this up with your SP stating:

- You can prove 1 is sent on the SIP trunk from the UC500 to SP - what does SP see? Do they even get this packet?

- Is there a payload type mismatch in that the SP wants the RTP payload type for RFC2833 to be different - UC500 by default uses 101

Its all about fault isolation at this point & based on what you sent, the UC500 does not appear to be at fault.

[Eivind Jonassen]

Maulik,

Well, I think the telco gave up on trying to resolve the issue with the sonus, and they are now implementing a cisco IOS gw to fix the problem.

Thanks for your prompt statements ;) It always help to have good arguments whenever issues are sent towards a telco.

Thanks

Eivind

[Maulik Shah]

Thanks for the update Eivind - go cisco :)

[Eivind Jonassen]

Maulik,

Is it possible to change the payload from 101 to 100??

Thanks,

Eivind

Found this document;

https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/1574-102-1-1937/Paetec-UC520-SIPTrunking-v1-110308.pdf

page 45 :)

Cisco RULES, lol

Message was edited by: Eivind Jonassen

[Maulik Shah · Accepted solution]

Hi Eivind

  Yes you can - see section 4.4.11 on doc below:

https://www.myciscocommunity.com/servlet/JiveServlet/previewBody/1560-102-1-1933/UC500-SIPTrunking-Wiki-062008.pdf

Example CLI:

dial-peer voice 11001 voip
description ** Outgoing Local call to SIP trunk **
dtmf-relay rtp-nte
rtp payload-type nse 104
rtp payload-type nte 100

[Eivind Jonassen]

Hi Maulik,

The telco is experiencing a strange issue. From the telco

We are trying to set the RTP payload type for rtp nte (RFC2833 DTMF)
to 101 according to docs:

On 19. aug.. 2009, at 13.11, Eivind Jonassen wrote:

> dial-peer voice XX voip
> description ** Outgoing Local call to SIP trunk **
> dtmf-relay rtp-nte
> rtp payload-type nse 104
> rtp payload-type nte 100

Which means we want this in the SDP:

a=rtpmap:8 PCMA/8000.
a=rtpmap:100 telephone-event/8000.
a=fmtp:100 0-15.

However, when we set "rtp payload-type nte 100", the line:

a=rtpmap:100 telephone-event/8000.

is removed altogether, which makes the upstream gateway thinks this
the UC500 is unable to handle RFC 2833 DTMF events.

If we keep the default settings, we do get:

a=rtpmap:101 telephone-event/8000.

We have also tried setting "dtmf-relay rtp-nte force" to no avail.

Any idea what´s up?

Thanks

Eivind

[Maulik Shah]

Hi Eivind

  Not sure what the difference is on your setup - here is my dialpeer:

dial-peer voice 1029 voip
corlist outgoing call-national
description **CCA*North American*Long Distance**
translation-profile outgoing PSTN_Outgoing
preference 1
destination-pattern 91[2-9]..[2-9]......
rtp payload-type nse 104
rtp payload-type nte 100
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
ip qos dscp cs3 signaling
no vad

and here is the SIP INVITE:

Aug 21 23:12:57.580: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:14085251000@sip.skype.net:5060 SIP/2.0
....

m=audio 18834 RTP/AVP 18 100
c=IN IP4 100.1.1.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=ptime:20

I see the right payload type in there. Are you sure the call is matching the right VOIP dial peer that has these changes?

[Eivind Jonassen]

Maulik,

After they made the changes on their demo box, they seem to conclude with the following;

The problem is that Cisco doesn't know how to do inband to G.711 and at the same time it doesn't agree with Sonus to use RFC2833. We are working also with Sonus on this and we expect a solution soon (we already seen some progress with DTMF in a similar problem).

Any ideas?

Thanks,

Eivind