Subject: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jun 2013 11:16:10 +0000

Hi,

There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional - IF there would be cases where it's not needed.

We haven't had that much discussion about it yet, so I will not ask a DECISION question at this point, but I would really like to get some input from people who have opinions about this :)

Note that this issue is NOT about HOW to map data to m- lines (there will be a separate question about how to map RTP to m- lines etc), or whether we should allow usage of the same PT value (for the same codec configuration) in multiple m- lines, but more about a general rule.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 08:51:43 -0400

I started this issue, so I'll make my case again.

There must be a reason to have multiple m-lines in the bundle. (If there 
isn't, leave them out, and then maybe you won't need bundle at all.)

I assert that in all cases that reason can't be realized without being 
able to associate packets with the corresponding m-line.

The exception to this are those packets that deal only with those 
aspects of the bundle that are common. The most obvious example of this 
is ICE. But if *all* packets are common to all the m-lines then there is 
no reason for the bundle.

	Thanks,
	Paul

On 6/25/13 7:16 AM, Christer Holmberg wrote:
> Hi,
>
> There has been some discussions about whether BUNDLE should mandate that
> users are mandated to *always* (no matter what transport protocols are
> used in the BUNDLE group) have a mechanism to map received data to an m-
> line, or whether it from a generic BUNDLE perspective should be optional
> – IF there would be cases where it’s not needed.
>
> We haven’t had that much discussion about it yet, so I will not ask a
> DECISION question at this point, but I would really like to get some
> input from people who have opinions about this :)
>
> Note that this issue is NOT about HOW to map data to m- lines (there
> will be a separate question about how to map RTP to m- lines etc), or
> whether we should allow usage of the same PT value (for the same codec
> configuration) in multiple m- lines, but more about a general rule.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Jun 2013 14:48:33 +0000

Hi,

> There must be a reason to have multiple m-lines in the bundle. (If there isn't, leave them out, and then maybe you won't need bundle at all.)
>
> I assert that in all cases that reason can't be realized without being able to associate packets with the corresponding m-line.

The reason for having m- lines could be because different characteristics (bandwidth, priority etc) is requested from the NETWORK, while the endpoint application that receive the data might not care which m- line it belongs to.

> The exception to this are those packets that deal only with those aspects of the bundle that are common. The most obvious example 
> of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle.

Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group.

Regards,

Christer

On 6/25/13 7:16 AM, Christer Holmberg wrote:
> Hi,
>
> There has been some discussions about whether BUNDLE should mandate 
> that users are mandated to *always* (no matter what transport 
> protocols are used in the BUNDLE group) have a mechanism to map 
> received data to an m- line, or whether it from a generic BUNDLE 
> perspective should be optional - IF there would be cases where it's not needed.
>
> We haven't had that much discussion about it yet, so I will not ask a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jun 2013 11:13:45 -0400

> The reason for having m- lines could be because different characteristics (bandwidth, priority etc) is requested from the NETWORK, while the endpoint application that receive the data might not car…

Can you be specific?

Note that if you are requesting different characteristics from the 
NETWORK, then the NETWORK must be able to distinguish the packets in 
order to apply those characteristics properly. So then *it* will need a 
way to distinguish. If so, then the endpoints can too.

If you are just requesting characteristics for the entire bundle, then 
it should be possible to do it with fewer m-lines, that you can then 
associate with.

> Correct. For ICE we explicitly say that the STUN messages apply to the whole BUNDLE group.

It can in principle apply to more than just ICE.

Somewhere I commented that the <proto> field describes more than just 
the low level transport protocol. It often describes a whole protocol 
stack with many layers. When we bundle multiple m-lines with different 
<proto> fields, they have different stacks. For the bundle to be valid, 
at least the bottom level of each stack must be the same. (E.g., UDP.) 
There may be more layers in common among some or all of the stacks. When 
some of the m-lines have multiple layers in common, then there may be 
some packets that pertain to housekeeping of the layer, and so need not 
be associated with one particular m-line.

For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines 
together. Then there could be some SCTP housekeeping packets that can't 
be associated with a single m-line, but for this to work, SCTP payload 
packets would need to be distinguishable, probably by SCTP port. (Note, 
I'm not sure if there are any SCTP packets that don't have an SCTP port, 
so this might not be a good example. And of course for this example to 
work there would need to be a way to specify the SCTP port in SDP for 
DTLS/SCTP.)

AFAIK, for stuff *currently* under discussion only ICE falls into this 
category. But if we are going to define bundle so it can be applied to 
future cases then we need to phrase the constraint properly.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Jun 2013 06:58:40 +0000

Hi,

>>> There must be a reason to have multiple m-lines in the bundle. (If 
>>> there isn't, leave them out, and then maybe you won't need bundle at 
>>> all.)
>>>

I'm afraid not - I was just speculating :)

> Note that if you are requesting different characteristics from the NETWORK, then the NETWORK must be able to distinguish the packets in order to 
> apply those characteristics properly. So then *it* will need a way to distinguish. If so, then the endpoints can too.

True.

What about the direction attributes? The network may use the information e.g. for bandwidth calculation purpose, but it does not need to distinguish the packets.

Anyway, I personally don't have any strong preference, so I'd like to hear from people who DO have an opinion :)

> If you are just requesting characteristics for the entire bundle, then it should be possible to do it with fewer m-lines, that you can then associate with.
>
>>> aspects of the bundle that are common. The most obvious example of this is ICE. But if *all* packets are common to all the m-lines then there is no reason for the bundle.
>>
> Somewhere I commented that the <proto> field describes more than just the low level transport protocol. It often describes a whole protocol stack 
> with many layers. When we bundle multiple m-lines with different <proto> fields, they have different stacks. For the bundle to be valid, at least the 
> bottom level of each stack must be the same. (E.g., UDP.) 

I think we should use whatever "stack" is referenced in the 5-tuple definition.

> There may be more layers in common among some or all of the stacks. When some of the m-lines have multiple layers in common, then there 
> may be some packets that pertain to housekeeping of the layer, and so need not be associated with one particular m-line.
>
> For instance, *in principle* one could bundle multiple DTLS/SCTP m-lines together. Then there could be some SCTP housekeeping packets that can't 
> be associated with a single m-line, but for this to work, SCTP payload packets would need to be distinguishable, probably by SCTP port. (Note, I'm not 
> sure if there are any SCTP packets that don't have an SCTP port, so this might not be a good example. And of course for this example to work there 
> would need to be a way to specify the SCTP port in SDP for DTLS/SCTP.)
>
> AFAIK, for stuff *currently* under discussion only ICE falls into this category. But if we are going to define bundle so it can be 
> applied to future cases then we need to phrase the constraint properly.

Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mapped to m- lines for all kind of transport protocols. 

We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply task), but should we?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jun 2013 09:39:47 -0400

Inline, near end.

> Sure, but it is not (I hope) the task of BUNDLE to define HOW data is mapped to m- lines for all kind of transport protocols.

No, Bundle can't define this for all possible m-lines.

But it can call out the requirement that this must be possible for a 
bundle to be valid, and that it is the responsibility of the answerer to 
ensure that.

Part of that is for the answerer to ensure that the *offerer* will be 
able to do it, and that both ends agree about *how* it will be done. (So 
that the sender and receiver of each packet agree on which m-line it is 
associated with.)

I am not sure if there is ever a need to *explicitly* signal what 
mechanism(s) are to be used, or if it can always be inferred from the 
presence in the SDP of the data needed for the association.

The place where this is an issue is if there is data in the answer that 
would allow the offerer to do the association, but the answerer is not 
certain if the offerer is prepared to use that data for that purpose.

> We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply t…

We had this discussion already. IIUC there was consensus that the SDP 
for DTLS/SCTP would *not* include a way to convey the SCTP port, so that 
only a single default port can be used. This implies that one can't 
bundle two m-lines for this together. While I didn't agree  with this 
decision, I can live with it until (if ever) a need arises.

But I do think it needs to specify how to demux a bundle including a 
DTLS/SCTP and some RTP m-lines.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Jun 2013 11:06:15 +0000

Hi,

>>> stack with many layers. When we bundle multiple m-lines with 
>>> different <proto> fields, they have different stacks. For the bundle 
>>> to be valid, at least the bottom level of each stack must be the 
>>> same. (E.g., UDP.)
>>
>>> There may be more layers in common among some or all of the stacks. 
>>> When some of the m-lines have multiple layers in common, then there may be some packets that pertain to housekeeping of the layer, and so need not be associated with one particular m-line.
>>>
>>> For instance, *in principle* one could bundle multiple DTLS/SCTP 
>>> m-lines together. Then there could be some SCTP housekeeping packets 
>>> that can't be associated with a single m-line, but for this to work, 
>>> SCTP payload packets would need to be distinguishable, probably by 
>>> SCTP port. (Note, I'm not sure if there are any SCTP packets that 
>>> don't have an SCTP port, so this might not be a good example. And of 
>>> course for this example to work there would need to be a way to 
>>> specify the SCTP port in SDP for DTLS/SCTP.)
>>>
>>> AFAIK, for stuff *currently* under discussion only ICE falls into 
>>> this category. But if we are going to define bundle so it can be applied to future cases then we need to phrase the constraint properly.
>>
> But it can call out the requirement that this must be possible for a bundle to be valid, and that it is the responsibility of the answerer to ensure that.
>
> Part of that is for the answerer to ensure that the *offerer* will be able to do it, and that both ends agree about *how* it will be done. (So that the sender and receiver of each packet agree on which m-line it is associated with.)
>
> mechanism(s) are to be used, or if it can always be inferred from the presence in the SDP of the data needed for the association.

Assuming we do mandate mapping to m- lines, the Offer should only place m- lines in a BUNDLE group in a way that allows it to do the mapping.

The same goes for the Answerer. If it's not able to do mapping (e.g. because it does not support an extension which would be required to do the mapping), it should either remove m- line(s) from the BUNDLE group, or reject m- line(s).

Exactly HOW the mapping is done, and what SDP information it may require, is out of the scope of BUNDLE - perhaps with the exception of mapping between DTLS/SCTP and RTP (see below).

> The place where this is an issue is if there is data in the answer that would allow the offerer to do the association, but the answerer is not certain if the offerer is prepared to use that data for that purpose.

Well, as the Offerer has assigned the m- lines to the BUNDLE group, it needs to be able to do the mapping using *A* mechanism. SDP attributes etc can then be used to provide more information and data associated with such mechanisms.

>> We are going to specify/reference something for RTP, but do you think BUNDLE should also e.g. define a mechanism 
>> for transporting SCTP ports in SDP? We COULD (I assume it would be a rather simply task), but should we?
>
> We had this discussion already. IIUC there was consensus that the SDP for DTLS/SCTP would *not* include a way to convey the 
> SCTP port, so that only a single default port can be used. This implies that one can't bundle two m-lines for this together. 
> While I didn't agree with this decision, I can live with it until (if ever) a need arises.

But, I guess BUNDLE doesn't need to explicitly forbid the usage of multiple DTLS/SCTP m- lines, as there in future might be a mechanism which allows to map DTLS/SCTP data to the correct DTLS/SCTP m- line. It would go under a general "if-you-can't-demux-it-don't-put-it-in-the-bundle-group" rule.

> But I do think it needs to specify how to demux a bundle including a DTLS/SCTP and some RTP m-lines.

I personally agree with that. There are basically two things:

1) How to demux between DTLS/SCTP and RTP.

2) With multiple RTP m- lines, how to map data to the correct one.

Regards,

Christer

PS. I will leave for my summer vacation today, so I will not read my e-mail on a daily basis during that time.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jun 2013 11:34:49 -0400

Christer,

I think we are mostly in agreement here. I've put one question inline.

Have a good vacation. Don't work too hard while on vacation.
(But do at least check your email every 5 minutes! :-)
See you in Berlin.

> Well, as the Offerer has assigned the m- lines to the BUNDLE group, it needs to be able to do the mapping using *A* mechanism. SDP attributes etc can then be used to provide more information and da…

I think this will usually be sufficient.
But I haven't convinced myself that there aren't some possible exceptions.

So I would like others to think about this - try to find exceptions, and 
report if you find one.

---

From: Colin Perkins <[email-masked]>
Date: Sat, 29 Jun 2013 13:50:36 +0100

Christer,

On 25 Jun 2013, at 12:16, Christer Holmberg wrote:
> There has been some discussions about whether BUNDLE should mandate that users are mandated to always (no matter what transport protocols are used in the BUNDLE group) have a mechanism to map received data to an m- line, or whether it from a generic BUNDLE perspective should be optional – IF there would be cases where it’s not needed.
>  
> We haven’t had that much discussion about it yet, so I will not ask a DECISION question at this point, but I would really like to get some input from people who have opinions about this :)

My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applications need to care.

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Jun 2013 12:12:24 -0400

> My opinion: BUNDLE needs to mandate a single algorithm for mapping from RTP flows to m= lines, for those applications that care about such a mapping. I don't think it should mandate that all applic…

I just replied elsewhere on this.
My opinion turns out to be the exact opposite of yours: we need to 
support multiple algorithms, and that all applications should care.

I won't repeat the stuff about multiple algorithms.

I will repeat what I have said about the need for being able to associate:

There must have been *some* reason that two m-lines were used, rather 
than just one. Each m-line heads a media section of the SDP that 
contains a bunch of declarations. Something must be different in those 
two media sections, or else a single media section would have been 
enough. Presumably whatever it is that is different is intended to 
affect how received packets are processed or interpreted. (If not, again 
there is no need for it to be there.) If you can't associate the packet 
with the m-line, then you don't know which of the multiple 
interpretations to apply to the packet.

Maybe there is some exception to this, though I haven't come up with 
anything. If there is, then I hope someone will call it out. If so, then 
the constraint can be tightened.

	Thanks,
	Paul

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 1 Jul 2013 03:32:58 +0000

Informative descriptions of possible mappings are fine, but nothing normative, please. Some applications won't care about the mapping, and others may care but use a different mapping from those described. The only normative statement you could make is something like: "If you care about the mapping, you MUST have a mapping mechanism. You MAY use the mechanism(s) described here, or some other mechanism." But why mandate such a tautology?

The assumption below that multiple m-lines always require different m-line-specific processing of the packets also assumes Plan B, i.e. that multiple streams with similar processing should always be signaled with a single m-line (for example, using a=ssrc or max-ssrc). Plan A purists would use multiple m-lines even for multiple streams with the same processing. I don't think we want to force bundle to pick a plan.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, June 29, 2013 12:12 PM
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE DISCUSION: Always mandate mechanism to map received data to m- line?

	Thanks,
	Paul