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

[Emil Ivov <[e-mail]>]

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


-- 
https://jitsi.org