Re: [MMUSIC] IETF#89: BUNDLE: Q12: Scope of non-RTP media de-mux procedures in BUNDLE?

[Christer Holmberg <[e-mail]>]

Hi,

>>> One of the open issues is what we, in the BUNDLE spec, are going to 
>>> say about de-multiplexing about different media types, and for which 
>>> (if any) media types we are going to specify how the de-multiplexing 
>>> is done.
>>> We have previously agreed that we are NOT going to describe all 
>>> different possibilities in BUNDLE, and that separate specifications 
>>> how to perform (and, indicate support of) de-multiplexing will have 
>>> to be written. However, we haven't really agreed on the details.
>>> I intend to suggest the following in London.
>>> In the BUNDLE spec we:
>>> 1)Reference to RFC 5764 for how to de-multiplex DTLS/SRTP/STUN; and 
>>> 2)Separate specifications are required to describe how to 
>>> de-mulitplex other media types, and any type of information that 
>>> needs to be exchanged between peers in order to perform the de-multiplexing.
>>
>> In addition to this, I think BUNDLE should say explicitly that: You 
>> MUST NOT send an offer or answer with a bundle you don't know how to 
>> de-multiplex (or multiplex).  If you receive an offer for a bundle you 
>> don't know how to mux or de-mux, you MUST unbundle or reject m-lines 
>> so you know how to mux and demux the remaining bundle, or reject the offer.
>>
>> I'm uncertain how explicitly this should define "know how to", i.e. if 
>> the procedure has to be a normative spec.  I could imagine a scenario 
>> where there are multiple possibilities as to how to mix or de-mux two 
>> protocols (e.g., by restricting some field in one or the other 
>> protocol to a subset of its valid values, and there are multiple ways 
>> to pick the subsets), and if two endpoints have different approaches 
>> to muxing/de-muxing you would have interop failures.
>
> This is my concern too.
>
> For things to work, I must mux things consistently with the way you demux them, and visa versa.
>
> For instance, suppose the individual m-lines had attributes declaring both SSRCs and AppIDs. (This > sounds like a bad idea, but unless somebody writes a spec that says to not do this it is possible.) As > sender I might intend that each m-line correspond to an AppID, but you decide to demux them 
> based on SSRC. Makes a mess.
>
> OTOH, if somebody wrote a spec that said rtp m-lines may be distinguished by unique a=AppIds,
> or, if lacking that, then unique a=SSRCs, then everyone could agree to that.

If there are different ways things could be done, the peers need to agree (using whatever attributes, option-tags, etc) on which one to use, and the spec will have to describe that. I think that is all we can say in BUNDLE. Or, do you have another suggestion?

We are obviously not going to cover all multiplexing variants in BUNDLE, and I don't think we want to FORBID other variants in BUNDLE either.

Regards,

Christer