> 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.
>
That is what I made my comments based on, the same bugs exist in both,
the structure is highly similar. Bugs dont just invent themselves in
the same way in 2 totally independant stacks, now if they were different
bugs, or if the structure of the code was highly different I wouldnt
have thought that, but upon reading both it sure looks like it was
copied and cleaned a bit.
Why even some of the unused functions at one point in the FS rtp stack
coresponded to functions in the asterisk rtp stack, those are now
removed from the code, but they were there at one point.
> As far as I know, freeswitch has all its outstanding rfc 2833
> compliance issues resolved as of our 1.0.rc2 release.
no it doesnt, you personally commented that compliance is "going in the
wrong direction" when you spent that month trying to break my patch to
make it more compliant.
> 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.
which you arent compliant with, but this isnt the forum to discuss
freeswitch now is it?
> Also, the rules relating to SSRC and never
> starting timestamp offset at 0 are good ones to go over.
it doesnt say to not start it at 0 it suggests it more so for SRTP but
that is a different issue.
> 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".
>
Yes, by quoting that it makes me wonder why "strict in what you send"
was specifically rejected by you personally for "going in the wrong
direction". But this isnt the place.
--
Trixter http://www.0xdecafbad.com
Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
Posts
No comments:
Post a Comment