Ambiguities with BUNDLE and ICE

[taylor-b]

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

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 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 (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 ...
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:audio
...
m=video 9 ...
a=ice-ufrag:foo
a=ice-pwd:bar
a=mid:video

Answer

a=group:BUNDLE video
m=audio 0 ...
a=mid:audio
...
m=video 9 ...
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".

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

I'm raising this issue here so we can discuss it at the upcoming virtual interim, if time allows, and decide on a course of action we can propose to the MMUSIC working group. Some ideas:

1. Require ufrags to be unique for different ICE sessions, 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, which would be an issue if anyone uses RTCRtpTransceiver.stop.
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".

[stefhak]

Has a similar issue been filed at IETF rtcweb? From my initial reading, this seems to be mostly an IETF matter as the main issue seems to be the relation between BUNDLE and ICE.

[taylor-b]

I'll raise the issue on the rtcweb mailing list as well.

[alvestrand]

Using addresses as identifiers in SDP became stupid the day ICE was introduced. If that works for all cases, I'd support using the UFRAG as the identifier of the transport, and saying "if ICE is in use, UFRAG is the thing that identifies the transport". That's a statement that belongs in ICE, though. Is anyone saying such a thing there?

[taylor-b]

The reason I think it doesn't belong in ICE is that, with just ICE and not BUNDLE, you can use the SDP m= section's index as the identifier. The third m= section in one offer describes the same ICE session as the third m= section of a subsequent offer (unless it was recycled somewhere in the middle). That's why I'd suggest putting this in the "ICE considerations" section of BUNDLE. But I don't feel strongly about this at all; it's just what seemed most "correct".

[alvestrand]

I was looking at 5245bis' terminology section for language - it seems that an "ICE session" is anything going on between two ICE agents, while a "component" is the thing that requires a single transport address. (This might be a bug - I think it requires a single source/destination address pair, not a single address.) When we use BUNDLE (where I think RTCP bundling was mandatory last time I looked at it), is all the media going inside an ICE "component"?

[taylor-b]

Yes; when non-bundled, each "m=" section is a "media stream" in the terminology of ICEbis. And when not RTCP muxing, RTP and RTCP are separate "components".

In which case, I may have used the term "ICE session" incorrectly above; maybe "ICE media stream" would have been more accurate?

[taylor-b]

I think this PR will clear up the ambiguities, putting things in terms of m= sections rather than addresses. Similar to what I tried to do earlier. A relevant excerpt:

When an answerer generates the answer, if the answerer wants to move a bundled "m=" section out of the negotiated BUNDLE group, the answerer MUST first check the following criteria:

• In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group; and
• In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute.

If either criterium above is fulfilled the answerer can not move the "m=" section out of the BUNDLE group in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is moved out of the BUNDLE group.

NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section can not be moved out of the BUNDLE group in an answer. Instead an offer is needed.

So, once something is bundled, only an offer can remove it. There's no way to allow the answer to choose whether to keep something bundled, like there previously was.

Also:

When an answerer wants to reject a bundled "m=" section in an answer, it MUST first check the following criterium:

• In the corresponding offer, the "m=" section is the offerer tagged "m=" section.

If the criterium above is fulfilled the answerer can not reject the "m=" section in the answer. The answerer can either reject the whole offer, reject each bundled "m=" section within the BUNDLE group, or keep the "m=" section within the BUNDLE group in the answer and later create an offer where the "m=" section is disabled within the BUNDLE group.

So, there's no way to do what's described in the original example above. The answerer can choose to reject the "video" section, or reject all of them, but it can't reject just the "audio" section, and it can't remove either from the BUNDLE group without rejecting.

[taylor-b]

Closing since the BUNDLE changes have been made.