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.

Sure, there would be text describing that.

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.

If e.g. some information needs to be exchanged between the endpoints, or if there are some media plane level parameter values that need to be set in certain way, the spec would have to describe that.

We do need to work out good text describing that.

Regards,

Christer