For those of you playing the home game (and anyone in the future that finds this thread because they are having a similar problem and Googled it), the problem appears to be a configuration mis-match between my Polycom phones and/or sipXecs server and the ITSP, since DTMF works fine using a test account set up with another ITSP.
Our ITSP is working with me now to pin it down. They are currently setting up a 2nd account for us on a non-production server so we can try things without disrupting service to other Customers. Mike Burden Lynk Systems, Inc e-mail: m...@lynk.com <mailto:m...@lynk.com> Phone: 616-532-4985 From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Burden, Mike Sent: Wednesday, March 10, 2010 10:39 AM To: Eric Varsanyi; Tony Graziano Cc: sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] DTMF Issues Revisited What would be really interesting trace wise is the SDP headers showing the offer/response for telephony events (from the invite and the ack). If the ITSP is accepting these, at 101 even, and then not acting on them on it sure seems like they're broken. If it were me I would take the trace of a single failed call outside the firewall using a packet sniffer just to narrow the problem down to something on the sipxecs side or the itsp side. The extra internal chatter in the sipxecs traces is only interesting if something bad is happening between the ITSP and whatever is closest to them at the customer site. Eric, The Wireshark trace that I posted the snippet of was taken outside the firewall. I can send the full trace to anyone that might be able to help. Mike Burden Lynk Systems, Inc e-mail: m...@lynk.com Phone: 616-532-4985 From: Eric Varsanyi [mailto:sip...@eljv.com] Sent: Wednesday, March 10, 2010 10:35 AM To: Tony Graziano Cc: Burden, Mike; sipx-users@list.sipfoundry.org Subject: Re: [sipx-users] DTMF Issues Revisited I am somewhat doubtful that the DTMF setting are at issue here. I say that because whether through an Ingate, PRI or sipxbridge I have never seen this. All the above does is indicate someone pressed a key a bunch of times. Is a siptrace available? Tony Tony, His trace is actually showing him holding down the 9 key once. The RTP event for dtmf is sent many times for a single keypress, each time it goes out it extends DTMF on that tone for N more MS, presumably this is to allow to packet loss. A single digit dialed will usually have a bunch of these events then when the user releases the key you get a burst of the same event with the 'end' bit set. In the trace he sent he's hitting the key for about 250ms (it doesn't show the duration extension in his decode, I think it was 50ms using polycom defaults). What would be really interesting trace wise is the SDP headers showing the offer/response for telephony events (from the invite and the ack). If the ITSP is accepting these, at 101 even, and then not acting on them on it sure seems like they're broken. If it were me I would take the trace of a single failed call outside the firewall using a packet sniffer just to narrow the problem down to something on the sipxecs side or the itsp side. The extra internal chatter in the sipxecs traces is only interesting if something bad is happening between the ITSP and whatever is closest to them at the customer site. -Eric _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
<<image001.jpg>>
<<image002.gif>>
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
