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

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 11:29:10 +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
>>>>>>>
>>>>>>>        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
>>>>>       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.
>>>> I think this is covered in section 8.5.2 (Adding a media description
>>>>to
>>>> a
>>>> BUNDLE group) of BUNDLE.
>>>>
>>>> Assuming you are not 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).
>>>      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).
>> 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?
>
>     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.

The BUNDLE groups can not use the same transport, so if someone is trying
to offer such thing the answerer should reject the offer, or at least not
accept the offered transports.

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

I guess I still have some problems to understand what the problem is.

Let’s take the following example:

Initial offer/answer exchange:

a=group:BUNDLE mid1 mid2 mid3
a=group:BUNDLE mid4 mid5 mid6

Now, you have two transports: one “owned” by mid1 and one “owned" by mid4.

Re-offer:

a=group:BUNDLE mid4 mid2 mid3
a=group:BUNDLE mid1 mid5 mid6

In the re-offer, the offerer does not change the transports of mid1 and
mid4 - they are still the same. The different is that mid2 and mid3 will
now start using the transport of mid4, and mid5 and mid6 will start using
the transport of mid1.

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Fri, 1 Sep 2017 08:37:01 -0500

> now start using the transport of mid4, and mid5 and mid6 will start using

     Right, but as far as I can tell the bundle spec does not forbid this:

a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555
a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666
...
m=audio 5555 ...
a=mid:mid1
...
m=video 6666 ...
a=mid:mid4

and then in a reoffer:

a=group:BUNDLE *mid4* mid2 mid3 <--- mid4 and mid1 have swapped...
a=group:BUNDLE *mid1* mid5 mid6
...
m=audio *6666* ... <--- but the offerer has explicitly indicated that 
6666 is attached to mid1 now
a=mid:mid1
...
m=video *5555* ...
a=mid:mid4

     If the bundle spec allows this, "transport follows m-section" is 
not part of the spec; the fundamental rule is "transport is signaled 
explicitly every time", which is impossible with ICE unless ufrag is 
taken into account.

Best regards,
Byron Campen

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 1 Sep 2017 07:51:14 -0600

I'm lost on what the problem is. That might be because the IETF email server does not send me all the email to this list but more inline ...

> a=group:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped...
> m=audio 6666 ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now
> a=mid:mid1
> ...
> m=video 5555 ...
> a=mid:mid4
> 
>     If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account.
> 
> Best regards,
> Byron Campen

Ok, the above helps me understand but now take it to the next level, what is the problem when we move to ICE. I'd like to point out that with no ICE, the above is very unlikely to be valid SDP bec because during the reoffer you have to be able to receive both audio and video on port 5555.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 14:44:34 +0000

Hi,

a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4

and in a reoffer

a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1

Regards,

Christer

a=group:BUNDLE mid2 mid3

and in a reoffer

a=group mid1 mid2 mid3

Re-offer:

and then in a reoffer:

Maybe “transport follows m-section” is wrong wording. Transport is whatever the first mid in the a=group:BUNDLE attribute indicates it to be, and if that transport already exists there is no need to do an ICE restart.

So, in your example, i the reoffer you are suggesting that mid4, mid2 and mid3 uses the "5555 transport". Since this transport already exists (it was previously used by mid1, mid2 and mid3), you don’t have to do an ICE restart.

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Fri, 1 Sep 2017 09:51:45 -0500

On 9/1/17 9:44 AM, Christer Holmberg wrote:
> Maybe “transport follows m-section” is wrong wording. Transport is 
> whatever the first mid in the a=group:BUNDLE attribute indicates it to 
> be, and if that transport already exists there is no need to do an ICE 
> restart.
>
> So, in your example, i the reoffer you are suggesting that mid4, mid2 
> and mid3 uses the "5555 transport". Since this transport already 
> exists (it was previously used by mid1, mid2 and mid3), you don’t have 
> to do an ICE restart.
>
> Regards,
>
> Christer
>
>
     Right. The offerer explicitly indicated what it wants to do, and 
nothing is ambiguous. I like this way of doing things. Which is why I 
prefer clarifying the spec to say that this explicit signaling is used 
in the ICE case too, rather than specifying restrictions like "transport 
follows m-section" to handle the ICE case.

Best regards,

Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 16:21:12 +0000

Hi,

Hi,

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

is

BUNDLE

Regards,

Christer

placed

a=group:BUNDLE mid2 mid3

...

a=mid: mid2

...

a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

the

be

added to a bundle.

to

a

BUNDLE group) of BUNDLE.

are

section

8.5.2).

or

retaining (eg; ufrag).

of

of

specific,

Re-offer:

the transport of mid1.

and then in a reoffer:

Regards,

Christer

    Right. The offerer explicitly indicated what it wants to do, and nothing is ambiguous. I like this way of doing things. Which is why I prefer clarifying the spec to say that this explicit signaling is used in the ICE case too, rather than specifying restrictions like "transport follows m-section" to handle the ICE case.
I totally agree – the transport has to be explicitly indicated. But, don’t the ICE SDP attributes already explicitly indicate the transport?

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Fri, 1 Sep 2017 11:34:22 -0500

On 9/1/17 11:21 AM, Christer Holmberg wrote:
>     m=audio *6666* ... <--- but the offerer has explicitly indicated
>     that 6666 is attached to mid1 now
>     a=mid:mid1
>     ...
>     m=video *5555* ...
>     a=mid:mid4
>
>         If the bundle spec allows this, "transport follows m-section"
>     is not part of the spec; the fundamental rule is "transport is
>     signaled explicitly every time", which is impossible with ICE
>     unless ufrag is taken into account.
>
>     whatever the first mid in the a=group:BUNDLE attribute indicates
>     it to be, and if that transport already exists there is no need to
>     do an ICE restart.
>
>     So, in your example, i the reoffer you are suggesting that mid4,
>     mid2 and mid3 uses the "5555 transport". Since this transport
>     already exists (it was previously used by mid1, mid2 and mid3),
>     you don’t have to do an ICE restart.
>
>     Regards,
>
>     Christer
>
> in the ICE case too, rather than specifying restrictions like 
> "transport follows m-section" to handle the ICE case.
>
> I totally agree – the transport has to be explicitly indicated. But, 
> don’t the ICE SDP attributes already explicitly indicate the transport?
>
     Sadly, not quite, because there's no clear requirement right now 
that the ufrag is different for each transport (and indeed it has not 
been implemented that way by Chrome or Firefox). That's what I'm 
advocating fixing, instead of adding a bunch of new rules for bundle 
with ICE.

Best regards,
Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 16:41:46 +0000

Hi,

Hi,

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

is

BUNDLE

Regards,

Christer

placed

a=group:BUNDLE mid2 mid3

...

a=mid: mid2

...

a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

the

be

added to a bundle.

to

a

BUNDLE group) of BUNDLE.

are

section

8.5.2).

or

retaining (eg; ufrag).

of

of

specific,

Re-offer:

the transport of mid1.

and then in a reoffer:

Regards,

Christer

    Sadly, not quite, because there's no clear requirement right now that the ufrag is different for each transport (and indeed it has not been implemented that way by Chrome or Firefox). That's what I'm advocating fixing, instead of adding a bunch of new rules for bundle with ICE.

As I wrote in my e-mail on Thursday, my understanding of RFC 5245 is that the ufrag must be different for each transport, if you do an ICE restart you must change ufrag, and a change of ufrag will trigger an ICE restart..

If implementations don’t follow the specs it doesn’t really matter what we specify…

Regards,

Christer

---

From: Byron Campen <[email-masked]>
Date: Fri, 1 Sep 2017 11:47:00 -0500

On 9/1/17 11:41 AM, Christer Holmberg wrote:
> As I wrote in my e-mail on Thursday, my understanding of RFC 5245 is 
> that the ufrag must be different for each transport, if you do an ICE 
> restart you must change ufrag, and a change of ufrag will trigger an 
> ICE restart..
>

     That changing the ufrag causes a transport change is clear, but 
there is presently no language saying that you cannot start out with the 
same ufrag for every m-section, and this is further confused by the fact 
that ice-ufrag is allowed to be session level.

Best regards,
Byron Campen

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Sep 2017 16:58:11 +0000

Hi,

Hi,

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

is

BUNDLE

Regards,

Christer

placed

a=group:BUNDLE mid2 mid3

...

a=mid: mid2

...

a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

the

be

added to a bundle.

to

a

BUNDLE group) of BUNDLE.

are

section

8.5.2).

or

retaining (eg; ufrag).

of

of

specific,

Re-offer:

the transport of mid1.

and then in a reoffer:

Regards,

Christer

    That changing the ufrag causes a transport change is clear, but there is presently no language saying that you cannot start out with the same ufrag for every m-section, and this is further confused by the fact that ice-ufrag is allowed to be session level.

Ok, I hear what you are saying. We can always mandate unique ufrag values in BUNDLE, and maybe also in 5245bis (that discussion belongs to the ICE WG, though).

Regards,

Christer