DTMF doesn't work for outbound call - Page 6

kimjin · ‎09-09-2009

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.

Steven Smith · ‎02-05-2010

You should have an email in about 30 minutes.

kimjin · ‎02-08-2010

I have just updated IOS with beta version.

Cisco IOS Software, UC500 Software (UC500-ADVIPSERVICESK9-M), Experimental Version 15.0(20100104:073656) [shek-V150_1_XA_CSCtd68173 108]
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Mon 04-Jan-10 18:54 by shek

However, the DTMF doesn't seem to be working yet.

I guess I have to wait little more

Thanks

dharig · ‎02-08-2010

Strange, it worked for me, solved the issue 100% so far.

Maulik Shah · ‎02-08-2010

Kim

The DTMF issues as we had seen reported earlier in UC500 8.0.0 SW Pack (IOS 15.0.1XA) have been resolved (gotten multiple confirmations on this). If this is still not working for you - please provide exact details as there maybe more to this than the issue that was worked on. With this new image:

- Is DTMF failures only on outbound calls or for inbound calls as well

- Is DTMF failure intermittent or consistent for all calls

- Can you get a wireshark capture of the entire SIP & RTP packets for one call on the UC500 WAN port that fails and send us the trace. Please clearly state what is the IP address of the UC500 on the WAN, what is the calling / called numbers, what digits were pressed and which digits failed. You could call the Cisco Webex number (14085256800) as that replays the digits you press back to you.

kimjin · ‎02-08-2010

Hi

DTMF failed on outbound call only.

It failes consistently.

I am subimitting Wireshark capture. WAN interfcae ip address is 70.79.10.202/22.

call was made from Cisco IP phone 7942 extension 222. called number is 6044210675 and calling number was 6048398693. During the capture, I have press digit 1,2, and 3.

Thanks

- Is DTMF failures only on outbound calls or for inbound calls as well

- Is DTMF failure intermittent or consistent for all calls

- Can you get a wireshark capture of the entire SIP & RTP packets for one call on the UC500 WAN port that fails and send us the trace. Please clearly state what is the IP address of the UC500 on the WAN, what is the calling / called numbers, what digits were pressed and which digits failed. You could call the Cisco Webex number (14085256800) as that replays the digits you press back to you.

Maulik Shah · ‎02-08-2010

So in your case - every digit failed for outbound call?

When you say failed does that mean the called party did not hear the digit or mis interpreted the digit (i.e. you press 1, the other end thinks its 2)

I looked through the sniffer capture:

- RTP payload type is 101 for DTMF which matches what was negotiated in the SIP call setup

- each digit has 7 RFC2833 RTP packets (3 start,1 duration, 3 end) which is exactly how the digit should show up per the RFC

- the RTP timestamp is in sync between the audio stream & the RFC2833 RTP packets (check the RTP sequence number, it should be 160 higher on the 1st RFC2833 packet than the previous audio RTP packet)

Try this CLI to see if this helps any:
voice service voip

dtmf-interworking rtp-nte

Nothing stands out as incorrect on the UC500 (even the defect we fixed, it was specific to some GWs, others worked fine so its hard to track down) - not pointing fingers but can you ask your ITSP (are you still with Bizphone??) what they see on their end? Why is the DTMF not being recognized? Surely saying somebody else's box works is not good enough. I am more than happy to fix a UC500 issue but we need info on why this is being rejected by the ITSP.

kimjin · ‎02-08-2010

Hi

Yes, the called party can't hear DTMF tone. I am not sure if you remember, but if you press digit 1 and 2 at the same time from calling party, called party hear digit 2 tone. I can't explain why but that is what happen on our side.

As you noticed from last year september which I have posted this issue, We have been talking with SIP provider as well as cisco rep trying fix this issue. As far as I remember that bad time stamp was causing DTMF packet from called party was rejected from Asterk SIP server. However, another customer who is Cisco Partner and also customer of Bizphone has same unit as we do which is UC520, they don't seem to have problem with DTMF.

I have just tried CLI which you have provided, and it didn't work.

We have been getting Cisco Support when this issue was arised beginning of last year. But during that time without solving the issue our warranty got expired, now we can't get support. This issue basically began when we first purchased the box. We just didn't realized since we were using POT for primary line back then.

Is there any help you can provide to resolve this problem.

Maulik Shah · ‎02-08-2010

Kim - as far as we can see nothing incorrect is sent from the UC500. I am more than happy to help but there has to be something incorrect seen on the UC500 wireshark first. As an option, I can get on a call with Bizphone support if you can arrange for this (private message me the details) even though your UC500 is not under warranty.

All DTMF issues we have seen have been resolved since the latest fix was provided which does lead me to believe there is something unique about your ITSP.

kimjin · ‎02-09-2010

Thanks Maulik. Can you email me your private email address. I don't seem to have your Email and can't find it from Cisco Communitiry. Once I have your email, I will try to arrange with Bizphone. Thanks. Please email me at jkim@hiscocanada.com.

kimjin · ‎02-09-2010

I have some feedback from our SIP provider.

1. Hisco's equipment is not programmed correctly as they try 5,000 times every day to register the individual extensions (rather than the main SIP trunks). I bet this is the real reason they have problems and it is not set up right

2. When I capture the packets from Hisco the DTMF packets are delayed but not the Voice packets ... so the sequence stamps on all the DTMF's are out of order or delayed, so we drop them (some of the time)

3. I also noticed today in the old logs that Hisco's equipment was advertising it self as (Which will fail from our end when we do a dns

lookup)

6046781297-xxxxxxx.bizphone.ca

I am submitting running config and sh tech.

Maulik Shah · ‎02-09-2010

Are you sure their information is after you tried the new IOS sent to you? To answer their questions:

1. Please get "show sip register status" to see which extensions are trying to register. From the config (all extensions are ephone-dns) - only main number is setup for registration (does not have the no-reg primary CLI):

ephone-dn 52 dual-line
number C001 no-reg primary <<<<<<< disallowed
conference ad-hoc
no huntstop
!
!
ephone-dn 53
number 6046781297 <<< allowed
description SIP Main Number registration
preference 10

This should have no affect on DTMF to be honest

2. This was exactly what was fixed in the issue we sent you the image for - have you sent them the latest wireshark. It clearly shows the RFC2833 dtmf timestamps are in sync with the audio. Also, if this were the case the issue would be intermittent - however you state it fails consistently which leads me to believe that we are not talking about the same issue.

3. What should the domain name be - again this is not what we advertise on the SIP Contact header so doubt this is an issue.

My suggestion - setup a wireshark on the UC500 WAN port and have Bizphone doing captures on their side for the SAME SIP trunk call - then we can compare the traces and see where there is an issue. I can be on the same call to show what to look for on the wireshark on the UC500 side.

FYI given the amount of time spent on such issues, it maybe best to try another SIP trunk provider if support is not forthcoming from Bizphone.

kimjin · ‎02-10-2010

HI

I have spoked with my SIP provider and he helped me capturing packet from his side while we were on the phone. Below is his explaination.

Hi Jin,

I had told Bob this morning that I had found a new problem and that is with the UC500 trying to tell us to negotiate with it for RTPMAP. We do not do this. Look for the SIP/SDP frame. I have printed your out request (in red) and another (successful one from a Linksys phone in green). It is a little difficult to explain, so I will not bother. I see many Cisco post with the same problem and there is a solution

E-A&&V`#INVITE sip:6046285655@216.86.96.236 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.92:5072;branch=z9hG4bK-57b11c51

From: "Anonymous" <6046385892-1>;tag=1b901f961b369b09o2

To: <6046285655>

Call-ID: 2793e05a-c8663115@localhost

CSeq: 101 INVITE

Max-Forwards: 70

Contact: "Anonymous" <6046385892-1>;+sip.instance="<00000000-0000-0000-0000-000E08DFFDEC>"

Expires: 240

User-Agent: Linksys/SPA942-5.1.18

Content-Length: 397

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE

Allow-Events: dialog

Supported: replaces

Content-Type: application/sdp

v=0

o=- 1045288 1045288 IN IP4 192.168.1.92

s=-

c=IN IP4 192.168.1.92

t=0 0

m=audio 16468 RTP/AVP 0 2 4 8 18 96 97 98 101

a=rtpmap:0 PCMU/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:4 G723/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729a/8000

a=rtpmap:96 G726-40/8000

a=rtpmap:97 G726-24/8000

a=rtpmap:98 G726-16/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=ptime:30

a=sendrecv)

<;INVITE sip:6046385892@204.244.60.194:5060 SIP/2.0

Via: SIP/2.0/UDP 70.79.10.202:5060;branch=z9hG4bK76E82

From: "Jin Kim" <6046781297>;tag=AE0B868-1F12

To: <6046385892>

Date: Wed, 10 Feb 2010 21:33:02 GMT

Call-ID: B3BEDFCA-15C211DF-8FB2B3B7-F044DA7E@70.79.10.202

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 2993470871-0365040095-2410525623-4031044222

User-Agent: Cisco-SIPGateway/IOS-12.x

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1265837582

Contact: <sip:6046781297@70.79.10.202:5060>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 247

v=0

o=CiscoSystemsSIP-GW-UserAgent 4847 6620 IN IP4 70.79.10.202

s=SIP Call

c=IN IP4 70.79.10.202

t=0 0

m=audio 18624 RTP/AVP 0 101

c=IN IP4 70.79.10.202

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=ptime:20

Maulik Shah · ‎02-10-2010

I apologize but am a little ignorant here - can he please provide his long explanation? Both the INVITEs have RTPMAP except the Linksys SPA phone supports more codecs in the offer. See below for what I mean:

SPA

m=audio 16468 RTP/AVP 0 2 4 8 18 96 97 98 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

UC500

m=audio 18624 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

Only difference is SPA advertises a host of different codecs and SPA has FMTP map as 0-15 instead of 0-16 on the UC500.

All the other RTPMAP statements are the same or am I misreading something.

Lets assume the UC500 is asking them to negotiate something in the SDP (which is how the RFC3264 mandates SDP be used) and they do not support it - how come they send back the same RTPMAP in the 183 Session Progress in response to the UC500 INVITE. Also, inbound DTMF works as well so am not sure where this all ties together. Did you get my private message - can you please respond and setup a quick call?

bjames · ‎02-10-2010

Jin,

Jay has setup a test IP for you to use and he can trace on. He did say the following:

Also we only support ULAW (G711U) so please turn off G729 & G711A

Please contact him IP to test against. I would suggest you setup a conference call between Cisco and Jay so you can get the problem resolved once and for all.

Bob

Maulik Shah · ‎02-10-2010

UC500 is setup to only send G711ulaw (per the trace that Jin uploaded) - ironically the SPA phone sends a host of codecs to Bizphone but that seems to not matter as DTMF works :).

Am up for a conference call to end the back and forth.

Does your UC500 work with Bizphone - if so can you private message me your config?