[hydra-dev] RTP Stack Choice

[Olle E. Johansson]

11 aug 2010 kl. 16.33 skrev Tim Panton:

> 
> On 11 Aug 2010, at 15:22, Olle E. Johansson wrote:
> 
>> 
>> 11 aug 2010 kl. 16.10 skrev Joshua Colp:
>> 
>>> Hello all,
>>> 
>>> It's approaching the time where we need to choose an RTP stack for Hydra. As was previously
>>> mentioned in response to comments about the SIP stack this is simply the one that will be
>>> included and that resources will be put against. Since we have our defined interfaces there will
>>> be nothing to stop others from replacing it.
>>> 
>>> To help facilitate this I've done some more research into using pjmedia for RTP and transport.
>>> After comparing it against the other RTP stacks I think it is our best option from a features,
>>> licensing, and future development perspective so I'd like to put forward the recommendation
>>> to use it.
>>> 
>>> Does anyone have any qualms with it?
>> 
>> 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.
> 
You need to consider DTLS, SRTP et al here, as well as RTCP XR. 

It's not so easy any more. But having our own can give a lot of extra features. 
What are the issues really with the Asterisk RTP stack? If someone knows, it's Josh. 
Enlighten us why you don't want to reuse this.

/O