[Live-devel] Multiple Payload Types on RTP (DTMF Support)

[Dan Weber]

Here is my current course of plan for implementation.

Add an additional getNextFrame function to the RTP hierarchy... 
it will have an additional parameter for the payload type.  
The current getNextFrame will be modified to point to the new 
function with the payload type being the default as set on construction.  

An additional function will allow you to associate payload types
with Media input sources will be added.

For RTPSinks, buildAndPack functions will have an additional 
parameter for payload type.


I've had some questions if I should reuse the same jitter/reordering 
buffer implementation or associate a new one for each payload type.  
For rfc2833 dtmf, it should reuse the same timestamp calculations, 
so it has made me wonder if I should reuse the jitter buffer.  
Since rfc2833 uses its own distinct timestamps and incremented
sequence numbers different from the audio stream, I think there
should be a jitter buffer for each payload type.

Dan


On Tue, May 08, 2007 at 06:45:24AM -0400, Dan Weber wrote:
> 
> I'm considering implementing it myself.  Is there any recommended strategy I should take?  
> I will make the patches available afterward.
> 
> Dan
> 
> On Mon, May 07, 2007 at 07:54:31PM -0400, Ross Finlayson wrote:
> > >Is there anyway to have the rtp stack accept multiple payload types 
> > >for DTMF (rfc2833) and Audio?
> > 
> > No, not right now.  This is on my 'to do list', however.
> > -- 
> > 
> > Ross Finlayson
> > Live Networks, Inc.
> > http://www.live555.com/
> > _______________________________________________
> > live-devel mailing list
> > live-devel at lists.live555.com
> > http://lists.live555.com/mailman/listinfo/live-devel
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel