Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Hi,

Here is the GitHub issue where me and Taylor discussed this:

https://github.com/cdh4u/draft-sdp-bundle/issues/26

The outcome was that we need to say "something", but there is not more than that, so feel free to suggest :)

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 30 August 2017 16:27
To: Byron Campen <bcampen@mozilla.com>; Taylor Brandstetter <deadbeef@google.com>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Hi,

>>>      Alright, if we want to write a rule that the transport follows 
>>> the bundle, what about this?
>>>
>>> a=group:BUNDLE mid1 mid2
>>> a=group:BUNDLE mid3 mid4
>>>
>>> and in a reoffer
>>>
>>> a=group:BUNDLE mid2 mid3
>>> a=group:BUNDLE mid4 mid1
>>>
>>>      What transport goes where?
>>
>> I think Taylor raised this issue earlier. What you are doing above is 
>> moving streams from one BUNDLE group to another, and mixing the 
>> BUNDLE groups up, and I don’t think that’s a good idea.
>
> If you want to classify this as a bad idea, we need normative language 
> forbidding it. For instance, a rule that once a mid is placed in a bundle, the only way to remove it is to disable it, as well as a rule to handle the following:
>
> a=group:BUNDLE mid2 mid3
> a=mid: mid1 <--- not bundled
>...
>a=mid: mid2
>...
>a=mid: mid3
>
>and in a reoffer
>
>a=group mid1 mid2 mid3
>
>  We would need to define which transport is retained; mid1's, or the bundle's. Or perhaps a rule forbidding previously unbundled mids to be added to a bundle.

Me and Taylor did discuss some restriction text. I'll dig in my achieve.

>There are lots of corner cases here that simply aren't specified right 
>now. In the non-trickle-ICE case, this is ok, because the offerer unambiguously signals what transports it uses where in the c= line.

I think that's a separate problem.

I do agree that the BUNDLE group transport is currently bound to the c/m- line. If ICE is used, we should probably use candidate information instead.

Regards,

Christer

>> Best regards,
>> Byron Campen
>>
>> On 8/30/17 5:18 AM, Christer Holmberg wrote:
>>> Hi,
>>>
>>> Maybe I¹m missing something, but I fail to see what the problem is.
>>>
>>> If the BUNDLE-tag section is changed (e.g., because the current 
>>> BUNDLE-tag section m- line is rejected) you simply include the 
>>> TRANSPORT/IDENTICAL category attributes in the new BUNDLE-tag 
>>> section m- line.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> On 29/08/17 19:45, "rtcweb on behalf of Byron Campen"
>>> <rtcweb-bounces@ietf.org on behalf of bcampen@mozilla.com> wrote:
>>>
>>>> On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
>>>>> Some ideas for how to resolve it:
>>>>>
>>>>> 1. Require ufrags to be unique for different ICE sessions (JSEP 
>>>>> already requires this), and use the ufrag as the unique identifier.
>>>>> Then the BUNDLE semantics could be used as-is, with "unique/shared 
>>>>> ufrag" replacing "unique/shared address".
>>>>       I think this is our best option. It should allow trickle ICE 
>>>> to work as well as anything else. We might still want to do some of 
>>>> the below in addition.
>>>>
>>>>> 2. For ICE, instead of using a "shared address" to mean 
>>>>> "guaranteed to use the existing BUNDLE transport", use 
>>>>> "a=bundle-only" in subsequent offers. If we were to do this, we 
>>>>> may also need to allow the offerer BUNDLE-tag section to be 
>>>>> rejected; that's currently not supported (https://github.com/cdh4u/draft-sdp-bundle/issues/22).
>>>>       This does not help clarify things when the offerer changes 
>>>> the BUNDLE tag (disable, remove from BUNDLE, make something else 
>>>> the BUNDLE-tag, etc).
>>>>
>>>>> 3. Since the "shared address" rules say "don't associate 
>>>>> TRANSPORT/IDENTICAL category attributes with m= sections other 
>>>>> than the offerer BUNDLE-tag section", we could interpret "m= 
>>>>> section has no transport attributes of its own" as "using shared address".
>>>>       I don't think this helps when the offerer changes the 
>>>> BUNDLE-tag either.
>>>>
>>>> Best regards,
>>>> Byron Campen
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb