W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2017

[webrtc-pc] Ambiguities with BUNDLE and ICE

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Tue, 29 Aug 2017 00:02:08 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-253491069-1503964917-sysbot+gh@w3.org>
taylor-b has just created a new issue for https://github.com/w3c/webrtc-pc:

== Ambiguities with BUNDLE and ICE ==
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=ice-ufrag:foo
a=ice-pwd:bar
a=mid:audio
...
m=video 9 ...
a=ice-ufrag:foo
a=ice-pwd:bar
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](https://github.com/cdh4u/draft-sdp-bundle/issues/22), 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".

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1563 using your GitHub account
Received on Tuesday, 29 August 2017 00:02:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:51 UTC