<br><br><div><span class="gmail_quote">On 4/23/06, <b class="gmail_sendername">Vahan Yerkanian</b> <<a href="mailto:vahan@arminco.com">vahan@arminco.com</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Areas to be improved are configurable DTMF tone duration(vldtmf<br>branch?), better rfc2833 compliance and more flexible detection code.<br>I'm sure that there are lots of people who have spent hours trying to<br>find the sweet spot and can contribute to this thread.
<br><br>Currently these are the related open tickets:<br><a href="http://bugs.digium.com/view.php?id=5970">http://bugs.digium.com/view.php?id=5970</a><br><a href="http://bugs.digium.com/view.php?id=6667">http://bugs.digium.com/view.php?id=6667
</a><br><a href="http://bugs.digium.com/view.php?id=6027">http://bugs.digium.com/view.php?id=6027</a><br><br>Please reply to this thread if you think you can help with anything.</blockquote><div><br>I spent much of the last week looking at this problem. I decided to start testing the most pathological case I could think of with the tools at hand, with the AST_JB, PLC and DTX turned on
<br><br>SIP INFO/ulaw ->Asterisk->IAX/speex->unreliable internet->IAX/speex->Asterisk/IVR<br>which resulted in some packet traces in: <a href="http://bugs.digium.com/view.php?id=6993">http://bugs.digium.com/view.php?id=6993
</a><br><br>see also my misplaced entry in<br><br><a href="http://bugs.digium.com/view.php?id=3854">http://bugs.digium.com/view.php?id=3854</a><br><br>Conclusion. It's a mess, and this is even in the case of entirely out of band dtmf. I don't even want to think about inband and RFC2833 at this point... Pure out of band should be easy, shouldn't it?
<br><br>Brainstorming for possible solutions...<br><br>some small things that would help are that dtmf could be handled end to end better if SIP info actually parsed and kept around the Duration part of the dtmf message. (and then something useful done with it higher up) Similarly there's room in the IAX2 spec for a Duration component in the dtmf message's currently undefined data field (you could make an argument for a start dtmf -> end dtmf message in iax2 as well, but that would break iax as specified)
<br><br>a nice tool would be cheops-like packet recogniser tool that could poke a sip product and determine how it sent/received rfc2833 to feed back into settings in sip.conf<br></div><br>I can contribute access to test server that's on the internet that can run a packet sniffer full time and have a few other resources to bring to bear, but (like most) not a lot of time to spare.
<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks for your time,<br>Vahan<br>_______________________________________________<br>
--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mike Taht<br>PostCards From the Bleeding Edge<br><a href="http://the-edge.blogspot.com">http://the-edge.blogspot.com
</a>