LGTM1 On Wed, Feb 14, 2024 at 7:29 PM Philipp Hancke < philipp.han...@googlemail.com> wrote:
> Am Mi., 14. Feb. 2024 um 16:09 Uhr schrieb Yoav Weiss (@Shopify) < > yoavwe...@chromium.org>: > >> >> >> On Monday, February 12, 2024 at 7:52:17 PM UTC+1 >> philipp...@googlemail.com wrote: >> >> Contact emails >> >> phan...@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 > <https://w3c.github.io/webrtc-pc/#dom-rtcicetransport-onselectedcandidatepairchange>. > 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 > <https://github.com/webrtc/samples/blob/gh-pages/src/content/peerconnection/constraints/js/main.js#L229> > 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. > > >> Blink component >> >> Blink>WebRTC >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC> >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >> ? >> >> 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 >> <https://chromestatus.com/>. >> >> -- 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+unsubscr...@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.
