LGTM3 On Mon, Feb 19, 2024 at 10:13 AM Mike Taylor <[email protected]> wrote:
> LGTM2 > On 2/19/24 11:34 AM, Yoav Weiss (@Shopify) wrote: > > LGTM1 > > On Wed, Feb 14, 2024 at 7:29 PM Philipp Hancke < > [email protected]> wrote: > >> Am Mi., 14. Feb. 2024 um 16:09 Uhr schrieb Yoav Weiss (@Shopify) < >> [email protected]>: >> >>> >>> >>> On Monday, February 12, 2024 at 7:52:17 PM UTC+1 >>> [email protected] wrote: >>> >>> Contact emails >>> >>> [email protected] >>> >>> 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJNDLuO5rKoURr9QM5ZdN2fWipc5pt7WCnUYVzP%2Bz%3DecQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f0ec6745-5bfc-4b74-9080-44f65e99136e%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-OTS9f_Oyt%3DJrYDwzgEw48zCm3YHxjf_s9VbRh2t3uDw%40mail.gmail.com.
