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

[Christer Holmberg <[e-mail]>]

Hi,

It’s a while since we discussed this, but I have now created a PR which talks about moving m- sections between BUNDLE groups, and how it affects the BUNDLE address.

https://github.com/cdh4u/draft-sdp-bundle/pull/43

Regards,

Christer

From: rtcweb [mailto:[e-mail]] On Behalf Of Christer Holmberg
Sent: 01 September 2017 18:58
To: Byron Campen <[e-mail]>; Taylor Brandstetter <[e-mail]>; RTCWeb IETF <[e-mail]>
Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE?

Hi,

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.

    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.


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

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…


    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