[asterisk-dev] Asterisk V 1.6.2.12-rc1 Broke in-call DTMF with L3 and Broadvox

[Bryant Zimmerman]

We did packet traces with Broadvox and this is what they came back with.

Per our phone conversation I have attached our signaling capture. The issue 
is that after we receive a RTP packet, the RTP event that follows needs to 
be sent within 100 ms. Anything greater than 100 ms will not be received.

So what would cause this difference between 1.6.2.11 and 1.6.2.12 rc-1 not? 
What ever is causing this renders Grandstream and SNOM phones usless for 
RFC2833 in-call dtmf when calls are terminated on Broadvox and it appears 
to affect some calls on Level 3 as well.

Any One?

Thanks
Bryant

I am trying to get Broadvox to do a live call trap with me so we can see 
what asterisk is sending out that they don't like. Does anyone have any 
idea of setttings I could try while I have them working with me that would 
bring the DTMF back in line with the 1.6.2.11 build. 

   Also note: We have reproduced this with Grandstream GXP, SNOM and 
Linksys phones. Our Unidata WPU-7700 test phone seems to work. This is the 
exact same behavior as what we had under 1.6.1.20

Hi all.

I moved to asterisk version 1.6.2.11 to fix an issue that 1.6.1.20 had with 
properly sending in-call rfc2833 DTMF with Level 3 and Broadvox.  1.6.2.11 
worked grate with the DTMF but I needed the call pickup fix in 
1.6.2.12-rc1. Now the in-call DTMF issues is back. What changed between 
these version with DTMF handling that would cause issues. What we are 
seeing is that when you dial 22  we are only getting a single 2 and some 
times other keys are lost as well. This did not happen with 1.6.2.11.

Any ideas?
Bryant


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100826/a6cd07d4/attachment.htm