[asterisk-dev] DTMF detection and generation code

Mike Taht mike.taht at gmail.com
Sun Apr 23 10:40:53 MST 2006


On 4/23/06, Steve Underwood <steveu at coppice.org> wrote:
>On 4/23/06, Mike Taht <mike.taht at gmail.com> wrote:

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


I agree that rfc2833 is brain damaged. But it exists. A lot of
implementations exist.

Would it be better to try and change the world and make SIP INFO and inband
be the defaults for DTMF, or try to interoperate as best as possible with as
much as as possible?

Keeping the duration information around might provide a useful hint to both
the overlying jitterbuffer
implementation, and the codec's sound reception/generation routine. (and it
should always be force dto a valid minimum - at least 60ms long... 500ms
would be fine... I don't care, so long as it's freaking 99.9999% reliable)

Asterisk should strive as much as possible towards perfect interoperation,
towards, even, a full rfc1149 compliant implementation.

So, while I'm arbitrarily (and humorously) breaking protocols this morning,
how about three fields in IAX's DTMF (and/or some new control frame)

Originatory Apparent Duration: 16 bits
My Duration: 16 bits
BDF: 32 bits

The lowest octet of The BDF, or "Brain Damage Field" would have values of
0 Source is unknown
1 Source Inband
2 Source SIP INFO
3 Source IAX
4 Source RFC2833 (old asterisk)
5 Source RFC2833 (newer asterisk)
6) Source RFC2833 (some other implementation)
...

Additional values for broken/weird devices would be assigned on a per
manufacturer basis.

The DTMF ACK from iax would also get a BDF added, indicating the remote
server's best guess at how brain damaged the other side of the connection
is, and these hints used to try and tidy up the codecs and jitterbuffer
appropriately.



--
Mike Taht
PostCards From the Bleeding Edge
http://the-edge.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060423/8905ddd3/attachment.htm


More information about the asterisk-dev mailing list