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

[Paul Kyzivat <[e-mail]>]

On 3/2/14 10:46 PM, Jonathan Lennox wrote:
>
>
> On Mar 2, 2014, at 4:03 PM, Christer Holmberg
> <[e-mail] <mailto:[e-mail]>>
> wrote:
>
>> 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.

	Thanks,
	Paul