Mike, Did they say what header fields they thought were causing the trouble? It sure looked like a 'normal' negotiation except for that weirdness with the qualifier (limiting to events 0-15) being missing from you to them. Did they suggest that might be the issue?
-Eric On Mar 17, 2010, at 3:11 PM, Burden, Mike wrote: > 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. > > <image001.jpg> > Mike Burden > <image002.gif> > Lynk Systems, Inc > e-mail: [email protected] > Phone: 616-532-4985 > > > > > > > From: [email protected] > [mailto:[email protected]] On Behalf Of Burden, Mike > Sent: Wednesday, March 10, 2010 10:39 AM > To: Eric Varsanyi; Tony Graziano > Cc: [email protected] > 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: [email protected] > Phone: 616-532-4985 > > > From: Eric Varsanyi [mailto:[email protected]] > Sent: Wednesday, March 10, 2010 10:35 AM > To: Tony Graziano > Cc: Burden, Mike; [email protected] > 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 [email protected] > 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/ > > _______________________________________________ > sipx-users mailing list [email protected] > 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/
_______________________________________________ sipx-users mailing list [email protected] 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/
