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

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Mar 2014 16:03:43 +0000

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.

I think that DTLS/SRTP/STUN is going to be the main use-case (not only for WebRTC) in the near future, so I think it's a good approach.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Mar 2014 20:14:37 +0000

On 3/2/14 4:03 PM, Christer Holmberg 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.
>
> 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.
>
> I think that DTLS/SRTP/STUN is going to be the main use-case (not only
> for WebRTC) in the near future, so I think it’s a good approach.

Note that 5764 is sufficient to demux SRTP traffic from DTLS payload 
messages. It doesn't say anything about what those payload messages are 
used for.

It will take another reference to specify that when using proto 
DTLS/SCTP those payload messages are used exclusively for SCTP.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Mar 2014 20:21:44 +0000

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.
>>
>> 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.
>>
>> for WebRTC) in the near future, so I think it's a good approach.
>
> Note that 5764 is sufficient to demux SRTP traffic from DTLS payload messages. It doesn't say 
> anything about what those payload messages are used for.
>
> It will take another reference to specify that when using proto DTLS/SCTP those payload messages > are used exclusively for SCTP.

I am fully aware of that. But, my proposal remains :)

If you want to transport different things (e.g. data channel and something else) over DTLS, you need a specification that describes how the separation is done.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 Mar 2014 21:30:33 +0000

Christer,

I'm not necessarily opposed to going in the direction you suggest.
(I'm still listening to what others have to say before deciding.)

But if we go that way then I think the bundle draft needs a big warning 
or implementers note explaining the issues involved in this.

And then I expect that there ought to be an rtcweb document that 
specifies how to do this for the common rtcweb cases.

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Sun, 2 Mar 2014 22:46:52 +0000

On Mar 2, 2014, at 4:03 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

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.

In the BUNDLE spec we:

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.

I think that DTLS/SRTP/STUN is going to be the main use-case (not only for WebRTC) in the near future, so I think it’s a good approach.

Regards,

Christer
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Mar 2014 00:27:25 +0000

On 3/2/14 10:46 PM, Jonathan Lennox wrote:
>
>
> On Mar 2, 2014, at 4:03 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>> Hi,
>> be written. However, we haven’t really agreed on the details.
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 05:48:26 +0000

Hi,

In the BUNDLE spec we:

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 05:50:41 +0000

Hi,

> But if we go that way then I think the bundle draft needs a big warning or implementers note 
> explaining the issues involved in this.

Yes.

> And then I expect that there ought to be an rtcweb document that specifies how to do this for the 
> common rtcweb cases.

Isn't DTLS/SRTP/STUN, which we will cover in the BUNDLE spec, the common rtcweb case?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 3 Mar 2014 05:57:03 +0000

Hi,

>>> how to perform (and, indicate support of) de-multiplexing will have 
>>> to be written. However, we haven't really agreed on the details.
>>> 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 
>> 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 
>> 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