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

[Paul Kyzivat <[e-mail]>]

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.

On 6/28/13 7:06 AM, Christer Holmberg wrote:
> Hi,
>
>>>>>> 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.
>
> 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.

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.

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