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

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

The issue is that it may not be clear whether the offerer intended for the
same ICE session to be used, or a new ICE session that happens to use the
same attributes (ufrag/password).

Another option might be to define an "a=ice-id" just like we have an
> "a=dtls-id".

Or it could be a generic "a=transport-id", so it would work with any other
protocol that may have this problem with BUNDLE.

On Wed, Aug 30, 2017 at 7:36 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

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