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

[Paul Kyzivat <[e-mail]>]

On 5/23/13 4:49 PM, Emil Ivov 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.

It will work for CLUE, because CLUE won't start using it on the first 
O/A. It will only do so after it knows that it makes sense. And in clue 
it can potentially take precedence over PT. *In theory* we could have 
one switched capture that sometimes gets an H.264 RTP stream, and other 
times gets a VP8 RTP stream. (I don't know if that is likely to happen 
in practice. Jonathan might have more to say about that.)

IMO the "before the O/A completes" issues are separate from the "after 
the O/A completes" issues. I'm still not convinced that the "before the 
O/A completes" issues are important. (We have reliable 183 responses to 
deal with it.) But I'm ok with Cullen using PT to solve that problem if 
he thinks he needs to.

I'm more concerned with having a well defined way of associating packets 
with m-lines in the bundle after the O/A is complete.

	Thanks,
	Paul

> I believe we've built bundle port allocation and trickle ICE (and a
> number of other O/A mechanisms) around the same model.
>
> Emil
>
>