<br><br><div><span class="gmail_quote">On 4/23/06, <b class="gmail_sendername">Steve Underwood</b> <<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>> wrote:<br>>On 4/23/06, Mike Taht <<a href="mailto:mike.taht@gmail.com">
mike.taht@gmail.com</a>> wrote:<br></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> some small things that would help are that dtmf could be handled end
<br>> to end better if SIP info actually parsed and kept around the Duration<br>> part of the dtmf message. (and then something useful done with it<br>> higher up) Similarly there's room in the IAX2 spec for a Duration
<br>> component in the dtmf message's currently undefined data field (you<br>> could make an argument for a start dtmf -> end dtmf message in iax2 as<br>> well, but that would break iax as specified)<br><br>Adding duration to IAX2 DTMF messges is a bad idea. RFC2833 is brain
<br>dead for having it (actually RFC2833 is just rather brain dead). The<br>length of DTMF has no relevance, as long as it meet the minimum required<br>length for the DTMF specs. I think the problem in some parts of the<br>
system is the minimum is not being enforced.</blockquote><div><br>I agree that rfc2833 is brain damaged. But it exists. A lot of implementations exist. <br><br>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?
<br><br>Keeping the duration information around might provide a useful hint to both the overlying jitterbuffer<br>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)<br><br>Asterisk should strive as much as possible towards perfect interoperation, towards, even, a full rfc1149 compliant implementation.<br></div><br></div>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)
<br><br>Originatory Apparent Duration: 16 bits<br>My Duration: 16 bits<br>BDF: 32 bits<br><br>The lowest octet of The BDF, or "Brain Damage Field" would have values of<br>0 Source is unknown<br>1 Source Inband<br>
2 Source SIP INFO<br>3 Source IAX<br>4 Source RFC2833 (old asterisk)<br>5 Source RFC2833 (newer asterisk)<br>6) Source RFC2833 (some other implementation)<br>...<br><br>Additional values for broken/weird devices would be assigned on a per manufacturer basis.
<br><br>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.
<br><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>