[asterisk-dev] sip/rtp jitterbuffer in 1.4?

[Alexander Lopez]

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of Steve Underwood
> Sent: Monday, May 29, 2006 11:23 AM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] sip/rtp jitterbuffer in 1.4?
> 
> Russell Bryant wrote:
> 
> >Roy Sigurd Karlsbakk wrote:
> >
> >
> >>the sip/rtp jitterbuffer from
http://bugs.digium.com/view.php?id=3854
> >>has been in the works for more than a year, and has been in testing
from
> >>the last patch since 1.2.1 or so. My testing shows it makes G.711A
work
> >>well with crystal-clear audio even on an overloaded 704/128kbps
link.
> >>since asterisk is quite unusable for large-scale itsp rollouts
without a
> >>jitterbuffer for RTP-based protocols, SIP in particular, it would be
> >>really nice to get slav's code into 1.4.
> >>
> >>
> >
> >Yes, it would be very nice.  But, have you even tested the code that
is
> >the candidate for 1.4?  While testing the 1.2 branch of this code may
be
> >useful to you, it does nothing for the project to help get it into
1.4.
> >
> >When Joshua Colp and I started testing this last week, we ran into
> >serious problems immediately.  When we tried the 1.2 version,
everything
> >worked great.  If the trunk version gets into shape in the next few
> >days, it is going in for 1.4.
> >
> >It's like Kevin said in another thread about this, "An unreliable,
buggy
> >or unmaintainable jitter buffer is worse than none at all."
> >
> >
> A feature that doesn't get into the trunk is never going to get
tested.
> Its as simple as that. If you won't put it in there before it is
> polished it will stay out forever. If the jitter buffer had sanely
been
> stuck into the trunk, along with T.38 and other important stuff, just
> after 1.2 was released it would all have been shaken out by now. As it
> is, these important features have been sidelined into half baked
alleys
> to rot.
> 
> I tried testing OEJ's test-this-branch last week, and had to get
through
> about 20 obstacles to get it to run at all. Then it crashed at the
least
> provocation. How many potential testers have the competance to get
> anywhere with a mess like that?
> 
> Regards,
> Steve
> 
> 

I was under the impression that SVN trunk was always going to be
'unstable' that was the logic behind the regular releases. Since moving
to SVN the development of Asterisk has gone from trees to bushes. I
agree with Steve on this fact, compiling different branches instead of
trunk makes things become difficult to test and debug. 

I understand the importance of sandboxes to allow developers to
play/experiment within, but a group of 10's of sandboxes does not make a
good playground. I think we (community) should take a look at what has
worked with SVN since 1.2.0 and what has not worked and rework it for
1.6.

I for one used to run CVS-HEAD but now I run only 'released' versions.
I run SVN on my test boxes but I cannot have 10 different versions
(developer branches) and constantly switch between them, even if I could
get them to compile.