Re: New release of ccRTP? :)

[David Sugar]

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.

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.

Federico Montesino Pouzols wrote:

> On Mon, Aug 27, 2001 at 08:07:25AM -0400, David Sugar wrote:
>
> > I originally had hoped to see you at the LSM.  I just put out 0.5.1 of ccRTP,
>
>         Oh, you cannot imagine how I would have loved to be there but
> I had serious problems by that time... I will not miss the next :).
>
>
> > but that mostly involved making the existing packet structure visible for 
> > derived classes to manipulate arriving packets before they hit the queue (for 
> > example, to intercept RFC 5833 style telephony events in RTP bearer streams 
> > and post them to a seperate telephony event system rather than the audio 
> > packet queue).
>
>         Yes, in order to implement several profiles one or more
> virtuals are needed to intercept and make payload dependant
> processing. I see ccRTP both as a framework/library for general
> applications and a framework for payload specific extensions that
> eventually could be partially integrated in ccRTP itself.
>
>         There was already `virtual bool RTPQueue::gotPacket' that for
> the moment I think is the perfect place to intercept and handle these
> kind of events.
>
> > These changes you have are good news, for it should make ccRTP much more 
> > useful now.
>
>         Well, I go on testing and beautifying the test applications
> and I am starting to add a robust iteration mechanism for sources, as
> well as organizing the membership control stuff. 
>
>         Depending on the plans for new releases, I could send it now
> or wait for a few days and complete it as much as I can.
>         
>         I ENCOURAGE ANYONE INTERESTED IN RTP TO MAKE PETITIONS AND
> SUGGESTIONS, so it will be more useful.
>
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp