[hydra-dev] RTP Stack Choice
Joshua Colp
jcolp at digium.com
Wed Aug 11 09:57:05 CDT 2010
----- Original Message -----
> Le 10-08-11 10:33, Tim Panton a écrit :
> >>
> >> There are not many RTP "stacks" out there. Seems like people
> >> generally think "this is simple
> >> so I can hack this together".
> >
> > That was _exactly_ what I was thinking :-)
> > Actually I think it _is_ simple enough to be worth the advantages of
> > rolling our own.
> > RTP is going to be the most performance sensitive part of Hydra (and
> > remember we
> > want it to scale massively).
> > I imagine ICE will put some interesting threading requirements in
> > the mix, so
> > it might actually be useful to have this in our own hands.
> >
> >>
> >> I need to check pjmedia rtcp support before I say anything about
> >> it. For the rest of RTP, I fully trust the
> >> decision of the RTP master, Mr Colp. I had some issues with RTCP
> >> with PJsip phones and they all
> >> blamed pjmedia when I contacted them...
> >
> > Also it may be easier to instrument a ground-up stack than to
> > enhance an old one.
> >
>
> <playing devil's advocate>
>
> well, RTP is very important for a VoIP product, but RTP by itself is
> not
> the feature that makes hydra new/special/different.
>
> one way would be:
> - use pjmedia or else for now. that brings hydra faster to the market.
> - if in the process, find major issues, think of replacing it or
> rewriting one from scratch.
>
> </playing devil's advocate>
I totally agree with you Marc. Until we actual implement and deploy we don't *really*
know how it will fair. We can certainly hypothesize based on the architecture, but that's
not reality. Using pjmedia now gets us there quicker, and if it does turn out to be
a bad decision then we will have learned from it and we can know what *not* to do. On the
other hand if it works great then we'll have wasted no time.
--
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
More information about the asterisk-scf-dev
mailing list