Two weeks ago Microsoft’s Bernard Aboba (and former webrtcHack’s interviewee) gave an update on Edge’s ORTC and WebRTC at the Microsoft Build conference. He covered some big topics including VP8 and WebRTC 1.0 support. You can see the update video at the link above or read the follow-up post for details. Then last week Microsoft announced plug-in free Skype on the Edge browser.

I had some questions; Fippo had some questions; so we asked Bernard if he could publicly respond here. It turned out Bernard and his teammate on the Edge Browser team, Shijun Sun, were building a running list of questions they wanted to address too. Here it is.

{“editor”, “chad hart“}

Contents

Since we cover a lot here, below is a clickable table of contents in case you want to jump to a specific item:

Feature support

Interpreting the Edge Platform Status website

Q: How do I interpret the Edge Platform Status website (e.g. meaning of “in preview”, “in development”, “under consideration”)

A: Here are some guidelines:

1. Under Consideration means on backlog for implementation in a future release. Priorities have the following explanations:
   • Low — We are still evaluating this technology. There may be significant spec stabilization, foundational work, or additional community input required before we can begin development.
   • Medium — Development is likely for a future release.
   • High — We intend to begin development soon.
2. In Development means we have developers writing code actively on the feature.
3. In Preview means available in latest Windows Insider build.

Note that you can vote for features that are “under consideration”!

If you have additional questions on our web platform, you can first check out our FAQ page.  Please send us feedback if you could not find answers to your questions there.

Stream & Port handling

Multiple Streams & Unified Plan

Q: The iswebrtready says Edge does not support multiple streams.  Do you support this in ORTC?  Will you support it in WebRTC 1.0?

A: Edge ORTC enables multiple streams to be carried over a single DtlsTransport.  However, the WebRTC 1.0 work item in development does not include support for multiple streams within PeerConnection, via “unified plan”.

Multiplexing

Q: Does Edge support A/V multiplexing?  RTP/RTCP multiplexing?

A: Edge supports both A/V multiplexing and RTP/RTCP multiplexing.  RTP/RTCP multiplexing is required by the DtlsTransport, but RTP/RTCP non-mux is supported for use with the SrtpSdesTransport.

DataChannel

Q: What is the status of the WebRTC data channel?

A: The WebRTC data channel is currently listed as under consideration with a low priority on the Edge Platform Status site.

As part of a potential WebRTC data channel work item, the interaction of data channel congestion control with A/V congestion control needs to be considered. The current data channel implementations in Skype and Skype for Business were based on unified congestion control handling for both A/V and data,  taking into account both delay and packet loss, which ensures that data transfer does not adversely impact A/V quality.   However, in WebRTC, the data channel and A/V congestion control algorithms operate independently, and can compete with each other.  For example, if the data channel utilizes loss-based congestion control, queues can build, causing a delay-based A/V congestion control scheme to back off, yielding more bandwidth to the data channel and a video quality death spiral.  To understand the right congestion control algorithms to use for A/V as well as data channel congestion control, more research is needed.

Media Recorder plans

Q: What formats are you considering support for in Media Recorder?

A: Media Recorder is “under consideration” with low priority. We haven’t started the design process yet.  For video it is likely that H.264 (MP4) will be the preferred format due to the broad support on hardware platforms and devices.

Security & Encryption

No HTTPS requirement

Q: Is Edge considering following Chrome’s HTTPS requirement for getUserMedia()?

A: We currently allow both HTTP and HTTPS origins to access capture devices through getUserMedia(), although we apply more restricted user permission rules in the HTTP case.  Meanwhile, we are actively tracking usage of the API.  When the majority of websites have migrated to HTTPS when using getUserMedia(), we will consider making a change.

“IP Leakage” prevention

Q: How do you handle IP address privacy?

A: We provided an option for Microsoft Edge users to not expose local IP addresses. You can manually turn on the option in the about:flags. For enterprise customers, you can enable the Group Policy mapped to the same functionality.

Screen sharing security

Q: Are you considering using extensions to address some of the security issues in Screen Sharing?

A: Screen Capture is “under consideration” with priority medium.  While design work is still in progress, ideally, we would like to have the user experience and permission control seamlessly integrated with the Windows platform, so Edge browser users don’t have to take extra steps in enabling the feature.

ECDSA Support

Q: What is the status of elliptic curve cipher suites?  Are there potential interoperability issues a developer needs to be aware of?

A: Currently, support for DTLS 1.2 and elliptic curve cipher suites is in development.  Once this work item is complete, Edge will be able to validate elliptic curve certificates, but will still generate RSA certificates by default.  Since the certificate management API is not part of the DTLS 1.2 work item, it will not be possible to generate elliptic curve certificates.

The Edge team is currently examining backward compatibility issues understand how to best support developers. Potential issues include legacy mobile applications based on WebRTC that only support DTLS 1.0 and RSA ciphersuites and applications that do not utilize the certificate management API.

Device Fingerprinting

Q: How do you prevent device fingerprinting?

A: We currently don’t support persistent user permission yet for media capture devices. So, based on the W3C spec, we don’t persist the deviceId across browsing sessions. We also don’t reveal the device “label” when the webpage enumerates the capture devices unless the user has granted permission to the specific device type.

Codec & Video Support

ORTC & 1.0 Parity

Q: When the WebRTC 1.0 API work is done, will all supported codecs be available within both the ORTC and WebRTC 1.0 APIs?

A: Support for H.264/AVC and VP8 will be available within the WebRTC 1.0 API, as will support for G.711, G.722, Opus, Comfort Noise and DTMF.

Audio

Opus Support

Q: Why is Opus listed on the platform site as not yet supported?   Didn’t you ship this already?

A: Opus is currently supported within the Edge RTC platform.  The “Opus Audio Playback” work item on the platform site that is “in development” refers to playback of Opus in streaming scenarios.

FEC

Q: Does Edge support Opus internal FEC?   What about DTX?

A: In the TH2 release (in November 2015), Opus internal FEC and discontinuous operation are not supported. However, if Comfort Noise (CN) is added to the list of audio codecs, voice activity detection can be supported with Opus.

RED

Q: Do you support use of RED with Opus?

A: It is possible to use RED with Opus.  However, we have not tested interoperability with other browsers.

G.729

Q: Does Edge support G.729?

A: Currently Edge supports G.711, G.722, Opus, SILK, DTMF and CN audio codecs, but not G.729.

Video

VP8

Q: What is the status of VP8?

A: “VP8 for RTC”  is “under consideration” with priority “high”.  This means that the Edge team intends to begin development of VP8 support within the Edge RTC platform, once the work on H.264/AVC has completed.

We also talked about this in a recent blog post on our RTC roadmap.

VP9

Q: What is the status of VP9 in Edge?  What does “playback” mean?

A: “VP9 Video Playback” is now “In Preview”, which means that it is available in Windows Insider Preview Build 14291+ by enabling in about:flags  “Video Playback” means that Edge can play back VP9 video with the HTML5 video tag, but VP9 is not currently supported within the Edge RTC platform.

SVC & Simulcast

Q: I heard that Edge ORTC supports scalable video coding and simulcast.   Is this general (e.g. any codec) or is it codec-specific?

Currently Edge ORTC only supports encoding and decoding of simulcast and scalable video coding within the H.264UC video codec, which implements H.264/SVC (RFC 6190) with Skype extensions.

Q: Does the H.264/AVC work item include support for simulcast?

A: General support for simulcast is not included within the H.264/AVC and VP8 work items listed on the Edge platform site.

Q: Are you considering support for encoding or decoding of temporal scalability within VP8?

A: The VP8 specification requires that the decoder be able to decode any valid VP8 encoding. Therefore, the Edge VP8 decoder will be able to decode temporal scalability.  However, as part of the VP8 work item, we are not including support for encoding of temporal scalability.

FEC, ULPFEC, RED

Q: Is Edge planning to support retransmission?  flexible FEC?  Ulpfec?

A: Support for retransmission and RED + ulpfec  is under consideration with medium probability.  Currently support for flexible FEC is not under consideration.

PLI, NACK

Q: What feedback messages will Edge RTC support?

A: Support for PLI is in development.  Support for Generic NACK is under consideration with high probability.

Video Interop

Q: What additional work is being done relating to video interoperability?

A: In addition to work items relating to the H.264/AVC and VP8 video codecs, changes are being made to the Edge RTP stack, such as adding support for feedback messages (RTP/SAVPF), congestion control and robustness.  This work will occur in parallel to the H.264/AVC and VP8 codec development.

ICE & TURN

Trickle-ICE Support

Q: Are there plans to support Trickle ICE?

A: Trickle ICE is under consideration with priority medium.

TURN Variations

Q: Does Edge support TURN? TURN/TCP? TURN/TLS?

A: Edge TH2 supports TURN (RFC 5766), TURN IPv6 (RFC 6156) and ICE TCP (RFC 6544). Allocation of TCP candidates within TURN is not supported (RFC 6062).  Support for TURN over TCP/TLS is under consideration with medium priority.

WebRTC 1.0 & API Interop

What’s in 1.0?

Q: Can you elaborate a bit more on your WebRTC 1.0 implementation? You mentioned “Advanced functionality like multi-stream support, provisional answers, or the WebRTC 1.0 object model, are currently out of scope for our implementation”. If adapter.js is proving to provide interoperability between Edge ORTC and WebRTC 1.0, why are you implementing it? Why such limited support of your planned implementation?

A: Currently adapter.js provides the ability to run interoperable WebRTC 1.0 audio applications on Edge as well as Chrome, FF and other WebRTC browsers.  The Edge Test Drive site as well as webrtc examples on github provide examples of applications running on multiple WebRTC browsers, using adapter.js (or an equivalent adaptation layer).  So this approach works, and the Edge RTC roadmap items should enable adapter.js to be used for WebRTC 1.0 video applications as well.  We expect developers who are already using an adaptation layer to continue to prefer this approach, even after we have released WebRTC 1.0 support.

However, we have had some feedback from developers who have written applications without utilizing an adaptation layer that it would also be desirable for Edge to support WebRTC 1.0.  We did not include support for advanced video scenarios in the WebRTC 1.0 work item, since there is additional Edge RTP stack work necessary to support them, and interoperability between browsers in those use cases is still a work-in-progress.

It remains to be seen whether adapter.js will be upgraded to support advanced video scenarios as well, and if so, what would be involved in making those scenarios also work on Edge.  Once we have WebRTC 1.0 in preview, we will carefully track the response from developers as well as developments in video interoperability to understand the next steps.

1.0 Today?

Q: Is the WebRTC 1.0 API supported in the current preview build?

A: No.  An experimental flag for supporting the WebRTC 1.0 API was exposed in recent preview builds, but the Edge RTC platform does not yet support the WebRTC 1.0 API, so the API cannot actually be used today.  To decrease confusion, we have removed the flag in the latest preview build, and will check-in the flag again when we have made enough progress in implementation.

adapter.js

Q: Why doesn’t apprtc work on Edge with adapter.js?

A: The Edge RTC platform currently does not support interoperation with the H.264/AVC or VP8 video codecs, so that it is currently not possible to find a common video codec when  using apprtc on Edge to talk to Chrome or Firefox.

Q: Are you using adapter.js for any of your planned WebRTC 1.0 support?

A: The WebRTC 1.0 work item that is “in development” refers to built-in support for the WebRTC 1.0 API, rather than an adaptation library.

Q: Do you do any tests against adapter.js?

A: We have quite extensive coverage in our internal test automation, meanwhile we do use adapter.js for quick manual tests.  Once the adapter.js and test cases become more complete, we hope to include them within our automated testing.  Given the complexity of more advanced scenarios such as multi-stream, simulcast and scalable video coding, we would be particularly interested in seeing tests developed for those features.

Q:  Are there plans to help maintain adapter.js for those who want to use the 1.0 API’s until those are supported?

A: We have worked closely with Philipp Hancke to provide technical support for adapter.js on Edge ORTC.  Currently, only audio interoperability is supported with Edge ORTC, but the work on our roadmap should make it possible to run basic applications using video (such as apprtc) on Edge ORTC.  The attractiveness of adapter.js to developers might increase even further if support extends to more advanced video use cases not covered by our WebRTC 1.0 work, such as multi-stream video, simulcast, etc.   So we believe it is important to continue to support adapter.js.

Developing with Edge

Getting the developer previews

Q: How can I obtain Windows Preview Builds?

A: Go to https://insider.windows.com/ and sign up for Window Insider builds.  You can also try Virtual Machines or the upcoming RemoteEdge.

Bug reporting

Q: How do I submit bugs?

A: Microsoft Edge is an evergreen browser and we will continue to evolve both the web platform and the user interface with regular updates. If you are a web developer or designer and have feature requests for the web platform, we encourage you to share your feedback at the Microsoft Edge Platform UserVoice. If you are a web developer or designer and have a bug report, please file an issue at the Microsoft Edge Platform Issues site.

To send feedback on user experience, broken or malicious sites, use the “Send Feedback” menu item in Microsoft Edge.

Open sourcing the Edge Engine?

Q: Will any of the Edge ORTC engine be open sourced?

The Edge Javascript Engine (Chakra) is now open-source and an open-source implementation of ORTC is available from Hookflash (ORTC Lib).  Also, an open-source H.264/SVC encoder/decoder is available from Polycom, and the source code for the Skype SILK codec has been published.  However, the Edge RTC stack is based on the Skype media library, and is not available in open source.

Release Notes

Q: Do you plan to have a ORTC/WebRTC release notes for every release like Firefox and Chrome have?

A: The API specification for the TH2 release of Edge ORTC is available here.  We will update the Edge ORTC API specification as new features are added.

Browser-Debug tools

Q: Do you plan to add any RTC debugging tools like about:webrtc and chrome://webrtc-internals?

A: The Edge RTC platform supports the Statistics API as well as extensive session summary statistics within the msStats API.  In addition, ORTC objects such as the IceTransport and DtlsTransport provide information on the state of individual transports.  General plans for F12 are discussed here; currently this does not include RTC-specific debugging tools.

Hookflash ORTC Lib includes support for Event Tracing for Windows (ETW), which is very helpful for advanced debugging of real-time communications applications. ETW is a kernel-level tracing  facility that lets you log kernel or application-defined events to a log file, which tools can  analyze.

Demos & references

Q: Will the demos on https://developer.microsoft.com/en-us/microsoft-edge/testdrive/ be updated and maintained? Will there be more? If a developer has a good ORTC demo, how do they get it put up there?

A: Demos on the testdrive page will be updated based on our progress with Edge RTC.  We will add more demos when new scenarios become possible.  We currently have two RTC demos from developers outside of Microsoft, one from Twilio, and one from &Yet.  If you’d like to have your RTC demo included on our testdrive page, please contact us directly (at [email protected]).

apprtc support

Q: When H.264/AVC is supported in Edge will apprtc work between browsers?

A: Once the H.264/AVC and VP8 roadmap items are completed, it should be possible for apprtc to run on Edge using adapter.js.

Windows Mobile Support

Q: Can you clarify your support for Edge with ORTC on various mobile devices? WebRTC 1.0 plans for the same?

A: We currently don’t provide ORTC support on Windows Phone devices.  WebRTC 1.0 support will also be limited to non-mobile devices.  We will consider supporting the Windows Phone platform down the road when we have achieved reasonable interop with other WebRTC browsers.

Skype for Web on ORTC

Skype for Web on ORTC

Q: Does Skype for Web use ORTC in Edge?

A: Yes, the plugin-free Skype for Web preview on Edge is based on the ORTC API. To provide A/V quality comparable to existing Skype clients, it takes advantage of the SILK codec, as well as the H.264UC video codec and advanced session statistics.

Q: Why does the new Skype for Web require non-Edge browser users to have the latest version?

A: Edge browser users may be prompted to install a plugin if the remote participant doesn’t use the latest version of the Skype client on desktop or mobile.  The plugin allows use of legacy protocols compatible with older versions of the Skype client.  However, we’d strongly encourage Skype users to update their Skype apps to get the best experience based on the latest Skype client.

{
  “Q&A”:{
    “interviewer”: [“chad hart“, “philipp hancke“].
    “interviewee”: [“Bernard Aboba“, “Shijun Sun“]
  }
}