[asterisk-dev] sip/rtp jitterbuffer in 1.4? (Chicken or the egg?)

[Dan Austin]

> Can you at least please put it in there so people can start testing  
> it? Trunk code usually _is_ buggy, and I somehow doubt this code is  
> unmaintainable. According to zoa/slav the code is very thoroughly  
> tested on 1.2, so it should be no more than porting it to 1.4. They  
> may perhaps even have time to help.

Steve's comments about the difficulty of testing code/features that
have been put in their own branch ring very true.  I was pretty excited
to see the packetization patchset get its own branch, but the reality
set in and eight weeks without a comment or commit.

> I know there was much argument about allowing the jitterbuffer into  
> 1.2 by release or not, and that it was decided against it. PLEASE do  
> not let this happen with 1.4. The PLC and jitterbuffer is is a  
> feature much missed in asterisk, and they're both in these works.

Agreed.

Now for the 'Chicken or the egg'.  I realized I could be doing more to
test this feature, and thought to bring 'Test-This-Branch' up on my
test server.  I didn't get as far as downloading it when I saw posts on
Mantis and the users list about the G729 not loading.  I am aware of the
loader changes, and have avoided trunk while they complete.  Why?  I
need
G729.  I cannot offer much in the way of testing feedback without it, it

is that critical to our environment.

I know that Digium does not want to rework the G729 code multiple times
while the loader changes stabilize, but if the codec cannot at least be
made available privately to select testers, then major features such as
the jitterbuffer will not get tested.  By privately, I do not mean free
from licensing, but instead a new loader friendly version that is not on
the ftp site until the loader changes complete.  Sure it might mean
dipping
into the G729 codec multiple times before all is said and done, but the
only other choice this potential tester has is to wait for 1.4 and then
open bug reports.  I'd much rather contribute now instead of complaining
later....

> best regards

> roy

Dan