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

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 29 Aug 2017 09:35:27 -0700

Spawned from this thread on [email-masked]:
https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

And raised as an issue on webrtc-pc's github page here:
https://github.com/w3c/webrtc-pc/issues/1563

The main issue, as I interpret it, is that BUNDLE is written with the
assumption that a transport can be identified by an address (the "BUNDLE
address"). An offer has a different meaning depending on whether a "shared
address" or "unique address" is used for the m= sections in the BUNDLE
group. But for ICE (and specifically trickle ICE), this assumption doesn't
hold. The address used by an ICE session may change from one offer to the
next, and if no candidates have been gathered yet, it may just be "0.0.0.0:9".
So there's no piece of information that can be used authoritatively to
match an ICE transport in one blob of SDP to an ICE transport in another
blob.

So, current implementations (at least Chrome/Firefox) follow a simplified
model of "transport follows m= section".  However, this behavior isn't
covered explicitly by the standard, and it has its downsides. It means if
the m= section associated with the current ICE transport is rejected, a new
ICE transport needs to be set up (or worse, things just stop working
completely).

Example:

*Offer (for already-established BUNDLE group)*

a=group:BUNDLE audio video
m=audio 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:video

*Answer*

a=group:BUNDLE video
m=audio 0 ...
c=IN IP4 0.0.0.0
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:baz
a=ice-pwd:buz
a=mid:video

Does this mean the existing "audio" ICE session continues to be used, or is
a new "video" one created? There's no established way for the offerer to
indicate what it desires, since there's no way to provide a "unique/shared
address" distinction. Where "unique" means "can fall back to using a
different transport," and "shared" means "will use the existing transport"
(assuming I've interpreted BUNDLE correctly; I may be reading between the
lines too much).

There are other ambiguous situations, but this is the one that started the
recent discussion.

Is this a real issue, or have I missed something? Given that there's now an
API for rejecting "m=" sections, it's no longer just a corner case, but
something possible with basic usage of the PeerConnection API. So it seems
worth addressing.

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

---

From: Byron Campen <[email-masked]>
Date: Tue, 29 Aug 2017 11:45:51 -0500

On 8/29/17 11:35 AM, Taylor Brandstetter wrote:
> 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).

> TRANSPORT/IDENTICAL category attributes with m= sections other than 
> the offerer BUNDLE-tag section", we could interpret "m= section has no 

     I don't think this helps when the offerer changes the BUNDLE-tag 
either.

Best regards,
Byron Campen

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 06:10:59 +0000

On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter <[email-masked]>
wrote:

> next, and if no candidates have been gathered yet, it may just be "
> 0.0.0.0:9". So there's no piece of information that can be used
> authoritatively to match an ICE transport in one blob of SDP to an ICE
> transport in another blob.
>

It does seem like a serious oversight that BUNDLE is written in terms of
using addresses as identifiers when such addresses don't exist when doing
trickle ICE.  That means (BUNDLE + trickle ICE) may have lots of things
undefined.

It seems like we need to define an ID for (BUNDLE + trickle ICE), either by
saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE by
saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes more
sense.

> Does this mean the existing "audio" ICE session continues to be used, or
> is a new "video" one created? There's no established way for the offerer to
So let me see if I understand this...  First, it's only for re-offer cases,
right?
In that case, the re-offer would like to say one of the following?

1.  (Shared) "We're currently sending contents CA and CB over transport TA;
let's keep doing that;  but if you want to stop sending CA, let's keep
sending CB over TA".

or

2.  (Unique) "We're currently sending contents CA and CB over transport TA;
let's keep doing that;  but if you want to stop sending CA, throw away TA
and let's make a new TB and send CB over that".

But right now all the re-offerer can say is "We're currently sending
contents CA and CB over transport TA; let's keep doing that;  if you reject
CA ... I don't know; please don't do that".

> recent discussion.
>
> Is this a real issue, or have I missed something? Given that there's now
> an API for rejecting "m=" sections, it's no longer just a corner case, but

> semantics could be used as-is, with "unique/shared ufrag" replacing

This seems like a good approach.  We're already using ufrag as an ICE
session identifier in trickle ICE to handle ICE restart edge cases.   And
there might be lots of edge cases around the problem of not being able to
identify transports with addresses.

> transport attributes of its own" as "using shared address".

Another option might be to define an "a=ice-id" just like we have an
"a=dtls-id".   When using ICE, that can function as the ID instead of the
address.  Or we could go with "a=transport-id" and just have an ID for the
transport that works for ICE and non-ICE and we could rewrite everything in
BUNDLE that relies on addresses for IDs and use the a=transport-id
instead.  Would that work?

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 09:51:56 +0000

Hi,

Before I go deeper into this, a question for clarification:

You talk about “audio” ICE session and “video” ICE session.

Once the BUNDLE group has been established, you only have one ICE session (let’s call it the “bundle” ICE session), don’t you?

So, when the audio is rejected (see your example) you would continue using the “bundle” ICE session for video, since the video is still part of the BUNDLE group. Or?

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Taylor Brandstetter <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 29 August 2017 at 19:35
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Spawned from this thread on [email-masked]<mailto:[email-masked]>: https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

And raised as an issue on webrtc-pc's github page here: https://github.com/w3c/webrtc-pc/issues/1563

The main issue, as I interpret it, is that BUNDLE is written with the assumption that a transport can be identified by an address (the "BUNDLE address"). An offer has a different meaning depending on whether a "shared address" or "unique address" is used for the m= sections in the BUNDLE group. But for ICE (and specifically trickle ICE), this assumption doesn't hold. The address used by an ICE session may change from one offer to the next, and if no candidates have been gathered yet, it may just be "0.0.0.0:9<http://0.0.0.0:9>". So there's no piece of information that can be used authoritatively to match an ICE transport in one blob of SDP to an ICE transport in another blob.

So, current implementations (at least Chrome/Firefox) follow a simplified model of "transport follows m= section".  However, this behavior isn't covered explicitly by the standard, and it has its downsides. It means if the m= section associated with the current ICE transport is rejected, a new ICE transport needs to be set up (or worse, things just stop working completely).

Example:

Offer (for already-established BUNDLE group)

Answer

a=group:BUNDLE video
m=audio 0 ...
c=IN IP4 0.0.0.0
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:baz
a=ice-pwd:buz
a=mid:video

Does this mean the existing "audio" ICE session continues to be used, or is a new "video" one created? There's no established way for the offerer to indicate what it desires, since there's no way to provide a "unique/shared address" distinction. Where "unique" means "can fall back to using a different transport," and "shared" means "will use the existing transport" (assuming I've interpreted BUNDLE correctly; I may be reading between the lines too much).

There are other ambiguous situations, but this is the one that started the recent discussion.

Is this a real issue, or have I missed something? Given that there's now an API for rejecting "m=" sections, it's no longer just a corner case, but something possible with basic usage of the PeerConnection API. So it seems worth addressing.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 10:18:20 +0000

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

---

From: Byron Campen <[email-masked]>
Date: Wed, 30 Aug 2017 07:52:41 -0500

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?

Best regards,
Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 13:28:57 +0000

Hi,

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

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Wed, 30 Aug 2017 08:46:36 -0500

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

     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.

Best regards,
Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 14:27:24 +0000

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 14:36:13 +0000

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:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30 August 2017 16:27
To: Byron Campen <[email-masked]>; Taylor Brandstetter <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Hi,

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

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

Regards,

Christer

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 30 Aug 2017 11:44:44 -0700

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

> "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 <
[email-masked]> wrote:

> To: Byron Campen <[email-masked]>; Taylor Brandstetter <
> [email-masked]>; RTCWeb IETF <[email-masked]>
> > 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
> >now. In the non-trickle-ICE case, this is ok, because the offerer
> 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
> >>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Aug 2017 19:59:07 +0000

Hi,

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

Well, then you need another way to indicate that you need a new ICE session, because removing/rejecting a media stream from a BUNDLE group does not trigger a new ICE session by itself.

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

Couldn't we specify that a new ufrag triggers an ICE restart?

Regards,

Christer

On Wed, Aug 30, 2017 at 7:36 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

Regards,

Christer

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30 August 2017 16:27
To: Byron Campen <[email-masked]>; Taylor Brandstetter <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Hi,

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Wed, 30 Aug 2017 14:09:56 -0700

On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher <[email-masked]>
wrote:

> It seems like we need to define an ID for (BUNDLE + trickle ICE), either
> by saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE
> by saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes
> more sense.
>
>
>>
> So let me see if I understand this...  First, it's only for re-offer
> cases, right?
> 1.  (Shared) "We're currently sending contents CA and CB over transport
> TA; let's keep doing that;  but if you want to stop sending CA, let's keep
> sending CB over TA".
>
> or
>
> 2.  (Unique) "We're currently sending contents CA and CB over transport
> TA; let's keep doing that;  but if you want to stop sending CA, throw away
> TA and let's make a new TB and send CB over that".
>
>
>> BUNDLE-tag section to be rejected; that's currently not supported (

We're starting to accumulate a lot of IDs in SDP. If we can make ufrag work
as an identifier for the ICE session in BUNDLE, I think we should do so; as
you note, we're already using it as such elsewhere.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 30 Aug 2017 23:16:31 +0200

+1

El 30/8/2017 23:10, "Justin Uberti" <[email-masked]> escribió:

>
> We're starting to accumulate a lot of IDs in SDP. If we can make ufrag
> work as an identifier for the ICE session in BUNDLE, I think we should do
> so; as you note, we're already using it as such elsewhere.
>
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 30 Aug 2017 21:53:41 +0000

Yes, I prefer ufrag as the ID, assuming it works.

On Wed, Aug 30, 2017 at 2:10 PM Justin Uberti <[email-masked]> wrote:

>>> So, current implementations (at least Chrome/Firefox) follow a
>>> simplified model of "transport follows m= section".  However, this behavior
>>> isn't covered explicitly by the standard, and it has its downsides. It
>>> means if the m= section associated with the current ICE transport is
>>> rejected, a new ICE transport needs to be set up (or worse, things just
>>> stop working completely).
>>>
>>> Example:
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 06:29:07 +0000

Hi,

Doesn’t RFC 5245 specify that a ufrag change requires an ICE restart?

Section 9.1.1.1. Says:

   "To restart ICE, an agent MUST change both the ice-pwd and the ice-
   ufrag for the media stream in an offer."

Now, in my reading it is a little clear whether that text means that a change in ufrag triggers an ICE restart, or whether an ICE restart triggered by something else require a change in ufrag.

Section 9.1.2. says:

   "The username fragments, password, and implementation level MUST
   remain the same as used previously.  If an agent needs to change one
   of these, it MUST restart ICE for that media stream."

I think that text implicitly says that a change in ufrag requires an ICE restart.

I  guess we could clarify the text in ICEbis, but the requirement already seems to be there. So, an implementation doing an ICE restart WITHOUT changing the ufrag is not standard compliant – at least that’s my understanding.

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday 31 August 2017 at 00:53
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

On Wed, Aug 30, 2017 at 2:10 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Aug 29, 2017 at 11:10 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Aug 29, 2017 at 9:35 AM Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:
Spawned from this thread on [email-masked]<mailto:[email-masked]>: https://lists.w3.org/Archives/Public/public-webrtc/2017Aug/0076.html

It does seem like a serious oversight that BUNDLE is written in terms of using addresses as identifiers when such addresses don't exist when doing trickle ICE.  That means (BUNDLE + trickle ICE) may have lots of things undefined.

It seems like we need to define an ID for (BUNDLE + trickle ICE), either by saying in BUNDLE "when using trickle ICE, the ID is X" or in trickle ICE by saying "when BUNDLing, the ID is "X.  I think putting in BUNDLE makes more sense.

Example:

Answer

a=group:BUNDLE video
m=audio 0 ...
c=IN IP4 0.0.0.0
a=mid:audio
...
m=video 9 ...
c=IN IP4 0.0.0.0
a=ice-ufrag:baz
a=ice-pwd:buz
a=mid:video

So let me see if I understand this...  First, it's only for re-offer cases, right?
In that case, the re-offer would like to say one of the following?

1.  (Shared) "We're currently sending contents CA and CB over transport TA; let's keep doing that;  but if you want to stop sending CA, let's keep sending CB over TA".

or

2.  (Unique) "We're currently sending contents CA and CB over transport TA; let's keep doing that;  but if you want to stop sending CA, throw away TA and let's make a new TB and send CB over that".

But right now all the re-offerer can say is "We're currently sending contents CA and CB over transport TA; let's keep doing that;  if you reject CA ... I don't know; please don't do that".

This seems like a good approach.  We're already using ufrag as an ICE session identifier in trickle ICE to handle ICE restart edge cases.   And there might be lots of edge cases around the problem of not being able to identify transports with addresses.

Another option might be to define an "a=ice-id" just like we have an "a=dtls-id".   When using ICE, that can function as the ID instead of the address.  Or we could go with "a=transport-id" and just have an ID for the transport that works for ICE and non-ICE and we could rewrite everything in BUNDLE that relies on addresses for IDs and use the a=transport-id instead.  Would that work?

We're starting to accumulate a lot of IDs in SDP. If we can make ufrag work as an identifier for the ICE session in BUNDLE, I think we should do so; as you note, we're already using it as such elsewhere.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 13:03:00 +0000

Hi,

>bundle's. Or perhaps a rule forbidding previously unbundled mids to be

I think this is covered in section 8.5.2 (Adding a media description to a
BUNDLE group) of BUNDLE.

Assuming you are changing the transport of the mid1 m-line, you are
suggesting a new transport for the BUNDLE group (first bullet in section
8.5.2).

Regards,

Christer

>>>> BUNDLE-tag
>>>>>BUNDLE-tag

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 13:05:10 +0000

Assuming you are NOT changing the transport of the mid1 m- line, that is.

On 31/08/17 16:03, "rtcweb on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>>>>>>to

---

From: Byron Campen <[email-masked]>
Date: Thu, 31 Aug 2017 08:23:45 -0500

> suggesting a new transport for the BUNDLE group (first bullet in section

     Right, the offerer has the choice of retaining mid1's transport, or 
keeping the old bundle transport, according to 8.5.2. If we don't do 
something like adding ufrag to the transport comparison rules, 8.5.2 
would have to be tightened significantly. Again, our two choices here:

1. Find a way to allow an ICE offerer to indicate what transports it is 
retaining (eg; ufrag).

or

2. Tighten the rules so that there is no ambiguity in the first place.

     The point I'm trying to make is option 2 would entail lots of 
changes to the spec, and it might be tricky to cover all of the 
corner-cases. I think option 1 is more viable.

Best regards,
Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 Aug 2017 13:34:22 +0000

Hi,

>>>> groups up, and I don¹t think that¹s a good idea.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>> Assuming you are not changing the transport of the mid1 m-line, you are

You do that using the a=group attribute.

a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport of
mid1 (read: you are suggesting a new transport for the BUNDLE group)

a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport of
mid2 (read: keep the existing BUNDLE group transport).

Now, if you IN ADDITION to that wants to indicate something ICE specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don¹t think that is BUNDLE specific, is it?

>corner-cases. I think option 1 is more viable.

I think what we should do is to forbid some of the ambiguous use-cases you
presented earlier (and can also be found in Taylor¹s GitHub issue). I
think those are mostly related to ³mixing² mids between different BUNDLE
groups.

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Thu, 31 Aug 2017 10:58:06 -0500

> But, I don¹t think that is BUNDLE specific, is it?

     Ok, so what you are describing is "transport follows m-section". 
But the bundle spec doesn't _quite_ guarantee this right now, and it 
probably shouldn't try to guarantee it either. For instance, 8.5.1 
describes how the offerer can suggest a new transport for the bundle, 
any time it wants (and it could potentially be a pre-existing transport 
"stolen" from some other bundle/m-section!); without taking something 
like ufrag into account, this is impossible to detect in the ICE case. 
However, you would be completely right in saying "Well, duh, that is 
true for non-BUNDLE also!", which is why I like the idea of fixing this 
with ufrag, since that's how we make this work in the non-BUNDLE case.

Best regards,
Byron Campen