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

Inline, near end.

On 6/26/13 2:58 AM, Christer Holmberg wrote:
> Hi,
>
>>>> 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 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.
>>
>> Can you be specific?
>
> 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.
>>
>>>> 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.
>>
>> 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.)
>
> 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.

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 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 do think it needs to specify how to demux a bundle including a 
DTLS/SCTP and some RTP m-lines.

	Thanks,
	Paul

> 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
>>> 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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>