[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] SymmetricRTPSession

From: Federico Montesino Pouzols
Subject: Re: [Ccrtp-devel] SymmetricRTPSession
Date: Thu, 11 May 2006 11:16:12 +0200
User-agent: Mutt/1.5.11+cvs20060403


On Wed, May 10, 2006 at 02:29:59PM -0400, Glenn MacGregor wrote:
> Federico,
> Thanks! So say I create an RTPThread class which derives from Thread and
> contains one RTPSession object.
> Is it correct to assume that in the run method I want to continuaslly call
> rtpsession->getData and rtpsession->putData?
> This is the only way I can see to implement both a sender and a receiver in 
> one
> RTPSession. Or is the preferred way to derive from RTPSession instead? If so
> what advantages do I get from that?

You can do whichever you prefer. The demos rtplisten/rtpsend and
rtphello give simple examples (but you are not restricted to those
models).  As far as you have one RTPSession object and call getData
and putData on that object, you will be sending and receiving through
the same RTP session. The idea is that ccRTP should impose as less
restrictions as possible on the design of your application.

If you derive a class form RTPSession, you will be able to redefine
some virtual methods and to use some protected methods/members, which
can be an advantage if you are interested in some of these
methods. The rtplisten/rtpsend demos work like that in order to
process some types of RTCP packets. This is a way of extending and
redefining important functionality in ccRTP.

You can also create new classes of your own derived from RTPSession
-with specialized RTP functionality- and use them inside another
thread/whatever class that performs the main send/receive loop.

I think it is best to plan a design for your application and then
looking at how to implement that with ccRTP. If you come up with a
design that is somehow precluded by ccRTP, then we should modify it in
order to make it compatible with that kind of design :)

>  Thanks
>   Glenn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]