Intent to Ship: Unprefixed RTCPeerConnection

[Philip Jägenstedt]

Spec

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

Summary

Drop [NoInterfaceObject] in RTCPeerConnection.idl, so that new RTCPeerConnection() can be used. Currently one has to use new webkitRTCPeerConnection({iceServers:[]}).

Making the first argument optional is https://codereview.chromium.org/2442763002/ and in my mind is a prerequisite for shipping the unprefixed constructor.

Link to “Intent to Implement” blink-dev discussion

webkitRTCPeerConnection was implemented and shipped before the current process.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Interoperability and Compatibility Risk

Interop is the motivation, Firefox and Edge already have this.

Compat-wise, it's possible to write code that breaks if both RTCPeerConnection and webkitRTCPeerConnection are available but not if only one is, but there's no reason to suspect it.

OWP launch tracking bug

https://crbug.com/658423

Entry on the feature dashboard

https://www.chromestatus.com/feature/5312661013135360

[Chris Harrelson]

LGTM1

--
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+unsubscribe@chromium.org.

[PhistucK]

It is not really relevant at this point, but have you checked that Edge actually ships it?

WebRTC 1.0 is in development and this API is not included in ORTC API.

I know its reference already mentions it, but I suspect the reference creation tool just spits out everything in their internal development version, regardless of being enabled by default. Jacob, is this correct and if so, is this planned to be fixed?

☆PhistucK

[Rick Byers]

LGTM2

[Philip Jägenstedt]

Oops, I misremembered, https://crbug.com/649343 lists the window.*RTC* in Edge 14, and RTCPeerConnection is not one of them. In an unrelated GitHub issue I learned that Edge would support "WebRTC 1.0" but I can't find any announcement or a preview edition of Edge to test with.

Shinjun, will Edge's RTCPeerConnection constructor match the spec, or did you find it necessary to add many of the quirks that aren't in the spec? All of these are being measured in Blink, and I don't think that exposing RTCPeerConnection will make a difference to the prospects of getting rid of such quirks.

I am writing web-platform-tests for the constructor, so being able to test a preview release of Edge would be quite helpful.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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.

[Shijun Sun]

Hi Philip,

 

To check out the (still) limited WebRTC 1.0 support in Edge, you should join the Windows Insider Program to get the latest preview build of Windows 10.  Make sure you select the Fast Ring option.  Once you have that, you can turn on the API by checking the WebRTC 1.0 option in the Edge about:flags page.

 

Due to requirements of some existing solutions on the web, we had to implement some legacy interfaces.  Don't be surprised if you see things from the 2013 working draft, or even webkit prefix.

 

FWIW, we plan to encourage developers to use adapter.js for building new solutions, not the limited WebRTC 1.0 in Edge.  It’d be a better chance for developers to code against the spec, before all major browsers catch up and converge.

 

Please feel free to ping me in private if any further question.

 

Best, Shijun

 

Sent from my Windows 10 phone

[TAMURA, Kent]

LGTM3

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

Thanks Shinjun. After ~3 failed attempts with virtual machines, with a real machine I could upgrade to and test Edge 39.14951.1000.0 (EdgeHTML 15.14951) and filed this issue for test failures:

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9512925/

API owners, after looking closer there are a few changes I think are wise to couple with the unprefixing:

• Support RTCConfiguration iceTransportPolicy. This is the name in Gecko, and it would be bad if iceTransportPolicy can't be assumed to work with the unprefixed constructor.
  
• Make RTCConfiguration certificates non-nullable, as they already are in Gecko.
• Change the kinds of exceptions thrown in some cases to match the spec.

I'll add a chromestatus.com entry for iceTransportPolicy and use the same launch bug, the rest are trivial.

This will leave these differences with spec IDL, measured with use counters where possible:

• RTCIceServer dict still has a url member, and Gecko does too.
• RTCIceServer dict credentialType member not supported. Gecko has it while not supporting "token", which doesn't seem great.
• RTCIceTransports enum "none" value is supported, as it is in Gecko, at least in the IDL.
  
• RTCConfiguration dict iceTransports member remains as a fallback for iceTransportPolicy until usage is known.
  
• RTCConfiguration dict rtcpMuxPolicy member defaults to "negotiate" instead of "require". https://crbug.com/659035 (Not supported by Gecko.)
  
• RTCConfiguration dict peerIdentity and iceCandidatePoolSize members aren't supported, because they're connected to features not implemented.
  

None of these are big risks I think, not worth blocking unprefixing RTCPeerConnection. If anyone disagrees, please shout.

[Shijun Sun]

Thanks Philip for filing the issue to Edge.