[asterisk-biz] Solving DTMF issue

[Michael Jerris]

On Apr 3, 2008, at 11:09 AM, Trixter aka Bret McDanel wrote:

> <snip>
> But take heart, freeswitch has the same problem, and they are also
> unwilling to fix the same issue because "it goes the wrong direction",
> although my thoughts at the time that was said was they didnt  
> understand
> nor care to understand what the problem was.  Why if you look at the
> freeswitch rtp stack, you will see a high number of similarities to  
> the
> asterisk one, and its odd that the same bugs were replicated across,
> almost as if someone just copied the code, did some clean up, changed
> some names of variables and such and called it their own work.  I am  
> not
> saying that is what happened, but it sure seems like it - why would a
> "from scratch" work have the same errors in it?
>

Just to note, I personally witnessed the creation of the freeswitch  
rtp code and can say for sure that none of it was taken from  
asterisk.  Anyone looking to confirm this for themselves can feel free  
to look at the code history and make their own decision.

Freeswitch: http://fisheye.freeswitch.org/browse/FreeSWITCH/src/switch_rtp.c
Asterisk: http://svn.digium.com/view/asterisk/trunk/main/rtp.c?view=log

As far as I know, freeswitch has all its outstanding rfc 2833  
compliance issues resolved as of our 1.0.rc2 release.  Most notably,  
there are some strange cases related to time-stamps that need very  
careful attention, especially when handling things like the 8 second  
rollover in dtmf duration.  Also, the rules relating to SSRC and never  
starting timestamp offset at 0 are good ones to go over.  On the  
detection side the issue is often worse, with many broken devices out  
there, making it very tricky to follow the old adage, "be liberal in  
what you accept, strict in what you send".


Mike


> So you arent alone in this issue.  And there are still  
> incompatibilities
> with really strict gateways, to the point that it does not work at all
> with those gateways.  It could be worse right?  Could be metaswitch
> where you can DoS it (hose the DSPs, cause resets, destabilize the
> switch) with bad 2833 data :)