Can you try removing this command from your VOIP peers:

voice-class sip dtmf-relay force rtp-nte

Some more information on:

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

Let us know,

Marcos

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

Thanks anyway.

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.

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?

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

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?

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.

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?

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.

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

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

Give up on 8.0.0 and load 7.1.3-EA and try again, there seems to be a few issues with 8.