DTMF doesn't work for outbound call

Unanswered Question
Sep 9th, 2009
User Badges:

We currently using UC520 and having strange problem.  When we call through SIP for outbound call DTMF tone is not transmitting.  and if I press multiple numbers with longer duration, It makes continuous tone on the other hand.

My current dialpeer uses DTMF relay RTP- NTE.  I will attach sh run and debug ccsip message file.  please help me this is being quite critical.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jestowe Wed, 09/09/2009 - 18:16
User Badges:

Thank you for posting your concern, however in more urgent matters, I would suggest a call to our Technical Assistance Center.  At this time, please call 800-553-2447.


Thank you.

kimjin Thu, 09/10/2009 - 09:29
User Badges:

I tried removing that CLI before and it did not work.

Thanks anyway.

Maulik Shah Wed, 09/09/2009 - 22:42
User Badges:
  • Silver, 250 points or more

Your config looks ok - the UC520 is setup for DTMF using RFC2833 (rtp-nte). I see that the provider also responds with RFC2833 in the 200 OK using the same payload type as the UC520 so nothing wrong with the signaling. Can you also gather the below debug in addition to what you already got:


deb ccsip message

deb voip ccapi inout

deb voip rtp session named-event


The last one shows the actual RFC2833 packets being sent. It does seem like the other end is not interpreting the RFC2833 events correctly.


FYI no need to remove the "voice-class sip dtmf-relay force rtp-nte" as the other post was a different issue.

kimjin Thu, 09/10/2009 - 09:27
User Badges:

Thanks for all your reply.

I have tried removing "voice-class sip dtmf-relay force rtp-nte" before and it didn't do any good.  I am attaching debug information. Anyhelp will be appreciated.

Maulik Shah Thu, 09/10/2009 - 10:29
User Badges:
  • Silver, 250 points or more

Seems like your SIP Trunk Service provider is not getting the RFC2833 packets or not interpreting them correctly.


I see on the log that you pressed 1, 2 & 3 and the UC520 sends all these digits out (each digit will have 7 packets - this post explains how to read this debug - https://www.myciscocommunity.com/message/14045#14045). So I know its not the UC520 - below is a snip for digit 1


Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B86 timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:04 00 00  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B87 timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:04 00 00  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B88 timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:04 00 00  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B89 timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:04 01 90  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B8A timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:84 03 20  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B8B timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:84 03 20  >>
Sep 10 16:26:26.114:          s=DSP d=VoIP payload 0x65 ssrc 0x15FE9166 sequence 0x4B8C timestamp 0xBCB7190A
Sep 10 16:26:26.114:          Pt:101    Evt:1       Pkt:84 03 20  >>


In terms of next steps:


- Is there any router or NAT or firewall device between the UC520 WAN interface and the SIP Trunk service provider? If so maybe good to check if you can bypass this device or if this device blocks RFC2833 packets


- Ask the SIP Trunk SP what they see on their end for the RFC2833 packets - you can send them a wireshark capture off the UC500 WAN port if that is more convincing than a debug log. Who is the SP by the way?

kimjin Mon, 11/30/2009 - 15:56
User Badges:

It looks like they are using Inband DTMF.  They brought me another phone to test out which is Linksys SPA 941. When I was testing it, it was sending DTMF tone.

Is it possible to change DTMF transmitting method to inband

Steven Smith Tue, 12/01/2009 - 08:44
User Badges:
  • Gold, 750 points or more

Currently, the UC500 cannot do inband DTMF outbound.  It looks like in the traces that they should be accepting RFC2833.  Any reason why they aren't doing this?

kimjin Tue, 12/01/2009 - 09:37
User Badges:

Thanks for reply.  We are still in myth.  According to them the other customer who is using UC520 which is same as our, don't have any problem using touch tone.  What they are saying our DTMF delays too much and his server drop and ignores it.  So when I test DTMF from our ends and press the the key multiple time, the other end sometimes hear the tone sound but, it is very irregular.  Can it be problem with our UC520.

Steven Smith Tue, 12/01/2009 - 13:03
User Badges:
  • Gold, 750 points or more

While it is possible it is a problem with the UC500, I don't think that it is.  Could you get some more detail on what they are saying the problem is?

Maulik Shah Thu, 12/03/2009 - 13:14
User Badges:
  • Silver, 250 points or more

As Steven mentioned - its hard to say where the issue is without the data or logs. The best option for you maybe to gather a wireshark capture off the UC500 WAN port for a call you make out the SIP trunk and see DTMF issues. Once you have that we can take a look and you sould ask your ITSP to do the same. To look at the wireshark will need the WAN IP address of the UC500, the calling / called number for the call, time you made the call at and also the exact digits you pressed on the IP Phone.


Are there any other devices between the UC500 and your SP such as a firewall?

Jin, Hi Bob here,


I just wanted to add that I have been trying to help here as well. We use the same ITSP without an issue, so I'm not sure what is going on with Jin's connection.


Just as a note, Jin you said that the ITSP provided you with a SIP phone automatically configured to " call home" to them, and when you connected it; it worked fine right? The UC is connected directly to the Internet. Is there a special Inspect required for SIP trunks? The sniffer trace needs to be captured outside the UC so we can see what it is actually sending and receiving from the ITSP.


Any deny messages when debugging the firewall?


Let's us know.

kimjin Fri, 12/04/2009 - 09:34
User Badges:

Hi Bob thank you for trying to help me.  I didn't expect to meet you here.  Anyway, Let me tell you what I have done.

As you mentioned from email, I noticed that my IOS and CUE CME seemed to be out of date, so went to cisco site and downloaded UC software pack 8.0.0.  With CCA 2.2 I was successfully upgrade my UC520.  Then I noticed that our 7942 IP phone is getting Authentication Fail something like this


2:30:26p SEP002290BAB3DE.cnf.xml
9:22:04a No DNS Server IP
9:22:04a File Not Found : CTLFile.tlv
9:22:04a No CTL installed
9:22:04a SEP002290BAB3DE.cnf.xml
9:22:25a No DNS Server IP
9:22:27a File Not Found : CTLFile.tlv
9:22:27a No CTL installed
9:22:27a SEP002290BAB3DE.cnf.xml
9:22:28a Load Authenication Failed SCCP42.8-5-3S



And I google around to find the solution, and found that my phone may need to be factory reset.  I followed instruction to reset by unplug and plug back the CAT5 cable while holding # key then I press 123456789*0# to reset.  After that my another nightmare has begun.  That phone started to continously reboot and it looks like it tried to load term42.default.loads instead of SCCP42.8-5-3s.  Now, the phone is only displaying Cisco Logo.


I know this is different issue than what I have posted which is DTMF related.  Does any one know anything about this?

I also will connect one hub and try to capture wireshack data in between UC520 WAN port and Cable modem.

Thanks

Attachment: 
kimjin Fri, 12/04/2009 - 11:04
User Badges:

Thanks James

The phone problem is solved.  I had to upgrade to 8.4.2 first to go up.  Anyway, the phone is alive now and I will capture the data little later.  Thanks all for your help.

Steven Smith Fri, 12/04/2009 - 11:04
User Badges:
  • Gold, 750 points or more

I think you have to be on 8.5.1 or 8.5.2 before going to 8.5.3.  PM me, and I can provide more details.

kimjin Fri, 12/04/2009 - 11:34
User Badges:

Hi all Cisco Helper and James. I have captured call out.  Capture was done between Shaw Cable modem and UC520 WAN interface by putting HUB.  I hope anyone can help me to solve DTMF outbound issue.

During call I said few words and press few digits for testing.

Thanks

Maulik Shah Fri, 12/04/2009 - 11:45
User Badges:
  • Silver, 250 points or more

Please provide the below info so we can read this capture correctly:


- what is the WAN IP address of the UC500

- What digits did you press - which did not work?

kimjin Fri, 12/04/2009 - 12:21
User Badges:

The WAN IP address is 70.79.10.202.

I have pressed digit 1 to 5 sequencially, none of digits were not heard from the other end

Maulik Shah Fri, 12/04/2009 - 12:32
User Badges:
  • Silver, 250 points or more

Thanks


I filtered the wireshark by using "rtpevent" in the Filter window and I see the UC500 sends all 5 digits correctly per RFC2833. The details are below:


- SIP messages showed the SP is negotating RFC2833 with the UC500 using RTP payload type 101.


- UC500 sends the digits as below - note each digit is sent as 7 packets in RFC2833. The Pkt number is the number in the wireshark trace

Digit 1 Pkt 4474 to 4480

Digit 2 Pkt 4610 to 4616

Digit 3 Pkt 4752 to 4758

Digit 4 Pkt 4903 to 4909

Digit 5 Pkt 5065 to 5071


I recommend you take this to your SP and ask them why the digits are not being interpreted by them as there is nothing wrong from the wireshark on the UC500 side. I understand that dealing with your SP is not simple but this wireshark is ample proof that everything is OK on your end.

kimjin Fri, 12/04/2009 - 12:41
User Badges:

We have been dealing with this issue for almost 4 month.  And I have captured and checked wireshark data and saw it myself the RTP DTMF packet is going through.  However, for some reason the tone is not heard from the other end and SIP provider and We can't determine the issue.  And more myth is one of Cisco partner who has been helping me is using same UC520 device with same SIP provider.  And he doesn't have any problem with DTMF issue.  So I am not SURE why ours is having this problem.  Can it be phone?  We are using 7942 phone which I just upgraded firmware because I assumed the Phone firmware is too old.  That didn't help though.

Steven Smith Fri, 12/04/2009 - 12:47
User Badges:
  • Gold, 750 points or more

Who is the provider?  Does this happen with every number that you dial?


In SCCP mode, the digit is actually converted on the UC500 into RFC2833.  The phone load, could cause a problem, but not likely to in this case.

kimjin Fri, 12/04/2009 - 13:02
User Badges:

Our SIP provider is Bizphone.  And I didn't think the phone load would cause issue.  I have sent out the capture file.  But i still don't understand why the other UC520 user doesn't have problem.  Can it be cause by uploading speed.  Our uploading speed is about 700kbps.

kimjin Fri, 12/04/2009 - 13:04
User Badges:

No we don't use Shaw cable phone service.  The thing is we used to be on Telus for ISP.  We added another isp(SHAW) just for the phone system because I tought the problem was caused by telus instable line condition or slow network

Steven Smith Fri, 12/04/2009 - 13:06
User Badges:
  • Gold, 750 points or more

It could be upload speed.  I can't say for sure, but would need to see what the other side is receiving.  The DTMF is being sent, and it is correct.  I think the best option is to see what the provider can tell you.

kimjin Fri, 12/04/2009 - 13:22
User Badges:

I just increased uploading speed to 1mbps with Shaw cable which is our Internet Service Provider.  But, DTMF tones still not transmitting.  It is just like before.  If i press the digita continously press more than 10 to 20 times, the other end sometime hears tone.

Maulik Shah Fri, 12/04/2009 - 13:35
User Badges:
  • Silver, 250 points or more

Kim

  Understand your frustration that this is not working after 4+ months of looking at the issue. Looking at the logs you presented thus far - there is no indication of an issue on the UC500 - why the SIP Trunk provider does not recognize the digits is hard to say from the UC500 end at this time.There is no issue with the phone load or any dependency on how long you press the digit on the IP phone - the UC500 is the device that generates the RFC2833 packets and they are always set to 100ms duration which is standard, regardless of how long you press the digit down on the phone.


Have you sent this wireshark to your SP - have they got any comments on why this does not work other than saying someone else's UC500 works as that is not a very good explanation. I would strongly recommend you either escalate this with your SP (and if you want us to help we can be on a call - private message me any info) or if your SIP trunk provider cannot fix this issue, it maybe worth moving to somebody else.

kimjin Fri, 12/04/2009 - 13:48
User Badges:

Thank you very much.

We have been thinking of switching the SIP provider for a while.  We just wanted to solve with them.  So first step we have done was adding another sip provider just for the VOIP.  We ended up having 2 ISP one for DATA and the other one for VOIP.  And I tried to upgrade software to 8.0.0 software pack, which had caused me whole lot of problem with Phone load and everything.  Anyway, that has been resolved.  Then 10 min ago, we paid extra bucks to increase the Uploading speed from 700k to 1M.  And it didn't work out well.

I guess I have to seriously consider switching the SIP provider.  However, I have been searching the SIP providers but, I am not sure who are reliable and good in quality and pricing to.  Is it possible for you to give us  some listing or recommend one who I can go for.  You can email me if you don't want to leave at this community site.  I don't think calling current SIP provider would help since I have tried for 4 monthes.  He seems to be very busy and tired of supporting this issue from us.  

Maulik Shah Fri, 12/04/2009 - 14:04
User Badges:
  • Silver, 250 points or more

I doubt the upload speed would have an impact as the SP would see drops of all VOIP packets, not just DTMF digits. I do not think you had a voice quality issue so this may not be related.


Like Bob mentioned if there is anything that Shaw does with RTP packets in the middle then this could be the problem - we have had cases where the data ISP blocked RTP packets that were not the standard codec payload type (which would be the case for RFC2833 DTMF packets) so make sure of this before you go to Bizphone.


If you do want a list of tested SIP trunk providers, here is the info:

https://supportforums.cisco.com/docs/DOC-9830


Only other thing we saw internally was that some SP GWs look at the timestamp and reject RTP packets - not sure if this is the case with Bizphone but worth asking.

OK in looking at the traces the RTP DTMF seems to be out of sequence. In checking some asteriks forums they stated "some" Cisco phones interleave voice packets with the rfc2833 packets, which causes issues. This is in part because all of the packets in a dtmf event have the same timestamp, but the voice packets each have an unique timestamp.


The fix was to increase the DTMF timeout.


Does this make sense?

Maulik Shah Sat, 12/05/2009 - 16:30
User Badges:
  • Silver, 250 points or more

The ISP's claim that the RFC2833 packets sent by UC500 are dropped because they arrive too  late is similar to something we are hearing from another SP. The RFC2833 timestamp per the spec does not have to be tied to the audio RTP stream so this is one of the grey areas. I have our team internally looking at this to see if there is anything that can be done. One comment was to try the below CLI:


voice service voip

  dtmf-interworking rtp-nte


https://www.cisco.com/en/US/docs/ios/voice/command/reference/vr_d2.html#wp1457082


Not sure if you have answered this before but did this issue occur with UC500 7.0.x SW Pack as well?

kimjin Mon, 12/07/2009 - 09:19
User Badges:

I have tried the CLI command you have provided DTMF-interworking rtp-nte.  But, not luck.  It still does same thing.  No digits are heard from the other end.  But if you press 2 digits simultaneously (1 and 2) the other end can hear tone of 2.

Yes this issue was caused in earlier version of Software pack as well.

kimjin Mon, 12/07/2009 - 11:43
User Badges:

I have got this information from SIP provider who has similar issue regarding DTMF.  I think this is something to do with TIME STAMP which I am not sure exactly what it is.

https://issues.asterisk.org/view.php?id=13209







go right to bottom bad time stamps sending inband and rfc2833 at same timedropped packets.

Maulik Shah Mon, 12/07/2009 - 12:30
User Badges:
  • Silver, 250 points or more

It does look similar however as they point out the RFC does not mandate behavior one way or the other. As mentioned earlier, our engineering team is looking at this to see what we can do to help resolve the interop issue. Will keep you posted on this.

kimjin Mon, 12/07/2009 - 13:15
User Badges:

Thank you very much.  I am looking foward to see the anwer.  And I am really realived by this issue is handled by good hands.

NYCiscoTech_2 Thu, 12/10/2009 - 06:50
User Badges:

I know you tested with a Linksys phone that the ITSP provided, but wondering if you tested with an analogue phone connected to one of the FXS ports?


I'm having a similar problem with our SIP provider.  Wireshark captures show the RFC2833 packets transmitted with the correct payloads and timestamps (7 packets total) from a 7970 phone the far end does not hear/interpret the DTMF tones.


When I plugged an analogue phone into a FXS port, DTMF tones work flawlessly over the same SIP trunk (wireshark captures show 8 packets vs the 7 from the SCCP phone).

kimjin Thu, 12/10/2009 - 09:19
User Badges:

Thanks for your input. 

I tested this morning from Analog phone in FXS port.  Yes the DTMF works fine.  I guess I am not the only one who has this issue.  Then I guess this is not the problem with SIP provider. 

As I stated before, other forums are saying this issue is with certain Cisco phones. They wouldn't say whihc ones, but I am tending to beleive them. I have seen my own 7970 where just getting voicemail the DMTF is not sustained enough for the UC to get the digits and I have to re-enter them.


I am anxious to hear Cisco's response.

NYCiscoTech_2 Fri, 12/11/2009 - 06:39
User Badges:

On our side we were able to isolate the issue to the 15.0(XA) release.    When running 12.4(24)SB, the original load on the UC540, DTMF was working fine.


Different loads on the 79xx phones did not seem to make any difference (8-5-3S vs 8-4-2S).

kimjin Mon, 12/14/2009 - 14:03
User Badges:

Some how I can't get access to that Link. 

How can I get access to it

kimjin Mon, 12/14/2009 - 14:51
User Badges:

I can't get access to that link either.  It said I am guest account.  We purchased this unit last year.  Is there anything I have to do for me to have more access

kimjin Tue, 12/15/2009 - 09:15
User Badges:

Maulik this is Jin who originally posted this issue on Early september.  I guess I don't have access to this bug tool since my warranty is over by now.  As you know this DTMF issue was causing issue from the beginning and hasn't been solved yet, is there any way I can get extended access to this bug tool site?  I am keep getting that my account is guest and not able to access to the link that you have provided. 

Thanks

Maulik Shah Tue, 12/15/2009 - 09:18
User Badges:
  • Silver, 250 points or more

Unfortunately there is no way to allow guest access to this tool - it is for partners / customers with warranty or valid support contracts. I understand you were the person who brought up this issue but I have no way to give you tracking access without you having the right access level. I will update this thread with info on the fix as soon as its available.

kimjin Wed, 12/30/2009 - 10:19
User Badges:

Hi all,

Is there any resolution for this DTMF issue?

Here is the last post from Bugtracker; I'm not sure about their fix and/or it looks like it was for a particular ITSP so I think Cisco needs to look further into this:



Timestamp not accurate in the DTMF sent by CME
Symptom:
Outbound DTMF may fail intermittently over a SIP Trunk from UC500

Conditions:
- Using IOS 12.4.22YB4 or 15.0.1XA on UC500 AND
- SIP Trunk uses RFC2833 for DTMF AND
- Call is outbound from Cisco IP Phone to PSTN over SIP Trunk
- SIP Trunk provider GW is Sonus GXS (v6.4)

Workaround:
- Use IOS 12.4(11)XW10 on UC500 if possible OR
- SIP trunk provider Sonus GXS GW should upgrade to v6.5.5 or higher


Steven Smith Sun, 01/03/2010 - 13:15
User Badges:
  • Gold, 750 points or more

It isn't for a particular ITSP, but was found with a few ITSPs using the Sonus gateway running a particular version.  We have seen this with multiple ITSPs.  We are working on a fix for this.  I don't have a timeframe, but this is a high priority for us.

kimjin Mon, 01/04/2010 - 09:25
User Badges:

We are currently using Version 15.0(1)XA. According to bug tool, I have to downgrade the IOS.  Will there be any impact on setting and usage?   Where can I download 12.4(11)XW10 IOS?

Actions

This Discussion

Related Content