Intent to Ship: RTCIceCandidate url and relayProtocol attributes

[Philipp Hancke]

Contact emails

pha...@microsoft.com

Explainer

None

Specification

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

Summary

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

gets implementations for two new properties for RTCIceCandidate objects emitted from the 'icecandidate' event.

https://github.com/w3c/webrtc-pc/pull/2773

added the url of the STUN or TURN server a local ICE candidate of type 'srflx' or 'relay' was gathered from.

https://github.com/w3c/webrtc-pc/pull/2763

added the relay protocol (i.e. whether the candidate was gathered via TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidate of type 'relay' was gathered from.

These properties are already available in the getStats API as  RTCIceCandidateStats.

Blink component

Blink>WebRTC

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: No official signal yet but positive (https://github.com/mozilla/standards-positions/issues/976)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/310)

Web developers: No signals

Other signals:

WebView application risks

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

Not testable in WPT due to lack of STUN/TURN servers

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1354626

Estimated milestones

Shipping on desktop

123

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5170426198360064

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Monday, February 12, 2024 at 7:52:17 PM UTC+1 philipp...@googlemail.com wrote:

Contact emails

pha...@microsoft.com

Explainer

None

I think it would be useful to write a few sentences on what you want to ship, what's the motivation for shipping it and how we expect web developers to make use of it.

 

Specification

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

Summary 

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

gets implementations for two new properties for RTCIceCandidate objects emitted from the 'icecandidate' event.

https://github.com/w3c/webrtc-pc/pull/2773

added the url of the STUN or TURN server a local ICE candidate of type 'srflx' or 'relay' was gathered from.

https://github.com/w3c/webrtc-pc/pull/2763

added the relay protocol (i.e. whether the candidate was gathered via TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidate of type 'relay' was gathered from.

These properties are already available in the getStats API as  RTCIceCandidateStats.

OK, so I'm guessing the motivation here is ergonomics?

Any reason why we want to expose the same data from multiple APIs?

[Philipp Hancke]

Am Mi., 14. Feb. 2024 um 16:09 Uhr schrieb Yoav Weiss (@Shopify) <yoav...@chromium.org>:

On Monday, February 12, 2024 at 7:52:17 PM UTC+1 philipp...@googlemail.com wrote:

Contact emails

pha...@microsoft.com

Explainer

None

I think it would be useful to write a few sentences on what you want to ship, what's the motivation for shipping it and how we expect web developers to make use of it.

Will add. There are two small use-cases:

1/ "which server did I gather this ICE candidate from", as shown on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

2/ answering the "Is my call now getting relayed via a TURN server" in the selectedcandidatepairchange event. Which sometimes leads to the question 

  "why is my call being relayed through a server in another part of the world and doing it over TCP makes things terrible?"

Both of these were possible to obtain by asking the getStats API and then traversing the stats graph but that is rather cumbersome (and that still requires a lot of backward compat code for the second case)

In the case of relayProtocol it was also possible by looking at the upper 8 bits of the "priority" field already exposed but that was/is implementation-specific.

Specification

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

Summary 

https://w3c.github.io/webrtc-pc/#rtcicecandidate-interface

gets implementations for two new properties for RTCIceCandidate objects emitted from the 'icecandidate' event.

https://github.com/w3c/webrtc-pc/pull/2773

added the url of the STUN or TURN server a local ICE candidate of type 'srflx' or 'relay' was gathered from.

https://github.com/w3c/webrtc-pc/pull/2763

added the relay protocol (i.e. whether the candidate was gathered via TURN/UDP, TURN/TCP or TURN/TLS) a local ice candidate of type 'relay' was gathered from.

These properties are already available in the getStats API as  RTCIceCandidateStats.

OK, so I'm guessing the motivation here is ergonomics?

Any reason why we want to expose the same data from multiple APIs?

Ergonomics and consistency, this makes both APIs return the same information for the ICE candidates.

[Yoav Weiss (@Shopify)]

LGTM1

[Mike Taylor]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJNDLuO5rKoURr9QM5ZdN2fWipc5pt7WCnUYVzP%2Bz%3DecQ%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ec6745-5bfc-4b74-9080-44f65e99136e%40chromium.org.