Re: New release of ccRTP? :)

[Federico Montesino Pouzols]

On Tue, Aug 28, 2001 at 11:18:18AM -0400, David Sugar wrote:
> The problem with gotPacket is that originally all the rtp packet data 
> structures were in a secret header that wasnot installed.  So it would 
> get a pointer to an object it had no idea how to manipulate!  This is 
> what I fixed in 1.5.1.
> 
> But yes, you are absolutely correct, that gotPacket is meant to 
> intercept packets between arrival and posting to the receive queue, and 
> can then filter what gets posted.  This should be the same in 0.6.0, 
> even if there is now a Packet class object being passed rather than that 
> struct pointer.

        Yes, I have keep it the same while modifying ccRTP, although I
have not really use it yet. Now RTPPacket is named IncomingRTPPkt,
because there is also an OutgoingRTPPkt, but is more or less the same,
aside from some silly inlines to get several fields, a pointer to its
source and some new control info.

        Perhaps, a new public header, for instance <c++/rtpext.h>
could be created containing these kind of structures (RTP header and
such), just to make it clear that these are not there for general use
but for protocol extensions. The idea is that if person A (or demo app
A) just wants to use RTP to send some audio packets, per includes
rtp.h (that only contains the strictly necessary declarations), but if
person B (or advanced demo app B) wants to make "advanced" use of
ccRTP (that will require some knowledge about its internal structure)
per includes rtp.h and rtpext.h. If you [and some other people] agree,
I will make that change.

        Ideally, rtpext.h (and possibly rtpext.cpp) will eventually
contain facilities for specific processing of payload formats. And the
structures required to use the header extension mechanism (which is
defined as an experimental method of trying new and provisionary
things, but not aimed to general applications) would also be defined
in rtpext.h.

        Well, in fact, if things go well, rtpext.h can become so huge
that it will have to be splitted.

> 
> I think we should try to coordinate for an end of week or early next 
> week release of 0.6.0.  Lets get it as ready as it can be.

        Since I won't have good or even any connection from friday to
sunday, if you agree I could send you the files on next monday in the
early morning (spanish hour), which means that you will have it there
when you wake up :) (or even before you go to bed, if you are wildly
debugging all night long :) ).