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

On 6/25/13 10:48 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?

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.

>> 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.) 
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

> 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
>