[asterisk-dev] DTMF detection and generation code

[Steve Underwood]

Mike Taht wrote:

>
>
> On 4/23/06, *Vahan Yerkanian* <vahan at arminco.com 
> <mailto:vahan at arminco.com>> wrote:
>
>     Areas to be improved are configurable DTMF tone duration(vldtmf
>     branch?), better rfc2833  compliance and more flexible detection code.
>     I'm sure that there are lots of people who have spent hours trying to
>     find the sweet spot and can contribute to this thread.
>
>     Currently these are the related open tickets:
>     http://bugs.digium.com/view.php?id=5970
>     http://bugs.digium.com/view.php?id=6667
>     <http://bugs.digium.com/view.php?id=6667>
>     http://bugs.digium.com/view.php?id=6027
>
>     Please reply to this thread if you think you can help with anything.
>
>
> 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
>
> SIP INFO/ulaw ->Asterisk->IAX/speex->unreliable 
> internet->IAX/speex->Asterisk/IVR
> which resulted in some packet traces in: 
> http://bugs.digium.com/view.php?id=6993 
> <http://bugs.digium.com/view.php?id=6993>
>
> see also my misplaced entry in
>
> http://bugs.digium.com/view.php?id=3854
>
> 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?
>
> Brainstorming for possible solutions...
>
> 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)

Adding duration to IAX2 DTMF messges is a bad idea. RFC2833 is brain 
dead for having it (actually RFC2833 is just rather brain dead). The 
length of DTMF has no relevance, as long as it meet the minimum required 
length for the DTMF specs. I think the problem in some parts of the 
system is the minimum is not being enforced.

Many many things in the telephone network - cellular systems, key 
systems, many large PBXes with digital telephones - change the length of 
DTMF so what is sent is completely unrelated to what it pressed. 
Anything which cares about the length of a DTMF digit, other than 
meeting the requred minimum, is badly broken.

> 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
>
> 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.

Regards,
Steve