DTMF fails towards the telco using SIP trunk

Answered Question
Aug 11th, 2009

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

Correct Answer by Maulik Shah about 7 years 6 months ago

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

Correct Answer by Maulik Shah about 7 years 6 months ago

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.

Correct Answer by Maulik Shah about 7 years 6 months ago

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.


Correct Answer by Maulik Shah about 7 years 6 months ago

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.

Correct Answer by Maulik Shah about 7 years 6 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
Loading.
Correct Answer
Maulik Shah Tue, 08/11/2009 - 10:44

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 Tue, 08/11/2009 - 11:26

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

Correct Answer
Maulik Shah Tue, 08/11/2009 - 12:00

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 Wed, 08/12/2009 - 07:37

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

Correct Answer
Maulik Shah Wed, 08/12/2009 - 12:02

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 Wed, 08/12/2009 - 12:08

Thanks for your info Maulik,

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

Thanks,

Eivind

Correct Answer
Maulik Shah Wed, 08/12/2009 - 12:28

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 Fri, 08/14/2009 - 10:09

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

Eivind Jonassen Fri, 08/21/2009 - 01:39

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 Fri, 08/21/2009 - 16:10

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:[email protected]: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 Tue, 08/25/2009 - 07:36

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

Maulik Shah Tue, 08/25/2009 - 09:40

Hi Eivind

   When they say it fails to agree with Sonus on RFC2833 - what is the exact behavior? Do you traces etc? I think I showed in my previous post that changing the payload type works fine for me as long as the right dial peer is chosen. Also, we have tested internally with various SPs in the drop down that use Sonus and RFC2833 and seen no issues there. Seems to me like there is a config issue on Sonus or UC500 but unless I can get some detailed info its hard to nail this down.

Eivind Jonassen Tue, 08/25/2009 - 10:30

Maulik,

I'm not allowed by the SP to post the debugs here. Could you please provide your email in a PM??

Thanks

Eivind

Message was edited by: Eivind Jonassen

Eivind Jonassen Tue, 08/25/2009 - 14:20

Update from Maulik,

The log shows this:

//212/0984D90280E7/SIP/Media/sipSPIAddSDPMediaPayload:                                                     

Preferred method of dtmf relay is: 6 but the payload value 100 is already used for NSE, so DTMF-RELAY method will not be advertised

which implies the NSE payload type was not moved from 100 to 105 in the UC500 config. What IOS is this? Can they send a capture of when they configure this on the UC500 if any errors show up and the complete show run after they have configured the box. I have this working on my UC500 as mentioned before so its puzzling to me.

Thanks

Maulik

Eivind Jonassen Thu, 08/27/2009 - 13:46

Maulik,

The telco has provided a workaround on the Sonus. So problem solved.

One thing I noticed is that they used ver4.2 IOS (a XW version, can´t quite remember which one) and 7.0.3 for the phone loads, I asked them to do the upgrade on the IOS and CUE so that they had a complete 7.0.3 version, but they made a workaround instead.

Thanks,

Eivind