Re: [MMUSIC] Proposal for what bundle should say about demux

["Cullen Jennings (fluffy)" <[e-mail]>]

On May 23, 2013, at 2:49 PM, Emil Ivov <[e-mail]> wrote:

> Hey all,
> 
> So first of all, I'd like to say that I like the approach and think this
> is the way to go.
> 
> I have just one concern here. I already mentioned it in the call but I
> am not quite sure what the answer was. So here I go:
> 
> On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote:
>> 
>> Here's is my proposal for roughly what the bundle draft should say about this demux topic 
>> 
>> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows:
>> 
>> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping 
> 
> So my problem with having the above as number one is that while it would
> work perfectly with protocols like XMPP that have good discovery
> support, it would be a problem for SDP O/A based ones like SIP and WebRTC.
> 
> The reason is that even when demuxing RFCs like that exist, an offerer
> won't know if the remote party supports them. They would hence always
> need to construct an offer where a fallback to another mechanism could
> be possible (like for example falling back to uniquely allocated PTs).
> 
> Now, if the offerer does indeed know in advance that the fancy demuxing
> RFC will be supported, and only then, they would be able to rely on it
> and be careless about PT allocation.
> 
> I believe we've built bundle port allocation and trickle ICE (and a
> number of other O/A mechanisms) around the same model.
> 
> Emil
> 

What I had in mind was something along the lines of the following 

A is sending an offer that forks to B and C. A and B support the new mechanisms but C does not. A has no idea if the things it is talking to support the new thing. 

A constructs an offer that in the SDP has an indication it can receive the header extension. Perhaps something like "a=new-hdr-ext=123456". The new header extension allows one to embed an identifer in the RTP packets and this SDP indicates that the identifier should be 123456 for RTP with this mapping. 

A sends the offer and it arrives at both B and C. C does not understand it and just ignores it. B understands it and inserts a TP header extension with the identifier 123456. 

Imagine the RTP packets from B and C arrive at A before any SDP answer. A looks at the RTP packet from B, and see the header exertion and reads out the identifier 123456 and now knows the mapping. A looks at the RTP packet from C and does not see the RTP header extension so it carries on to try other things. 

So yes, as you point out, for the packets from C where it can't use PT, it needs to fall back to SSRC which means A can't really process the packets from C until the answer arrives. But that is fine - if you are using something that does not support the new stuff, the behavior you get is the best we can do with the old stuff yet at the same time you get the faster behavior with things that do the new stuff. C is as fast as it can be and B is as fast as it can be. 

That seems like the type of design we want.