• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer
webrtcHacks

webrtcHacks

Guides and information for WebRTC developers

  • Home
  • About
    • Chad Hart
    • Philipp Hancke
  • Subscribe
  • Contact
  • Show Search
Hide Search

Reverse-Engineering adapter.js, Brief, Edge, interop, SDP Philipp Hancke · October 15, 2015

Hello Chrome and Firefox, this is Edge calling

Chrome, Firefox, and Edge are all on the same party line. Image from Pillow Talk (1959)

For the first time, Chrome, Firefox and Edge can “talk” to each other via WebRTC and ORTC. Check the demo on Microsoft’s modern.ie testdrive.

tl;dr: don’t worry, audio works. codec interop issue…

Feature Interoperability Notes
ICE yes Edge requires end-of-candidate signaling
DTLS yes  
audio yes using G.722, Opus or G.711 codecs
video no standard H.264 is not supported in Edge yet
DataChannels no Edge does not support dataChannels

As a reader of this blog, you probably know what WebRTC is but let me quote this:

WebRTC is a new set of technologies that brings clear crisp voice, sharp high-definition (HD) video and low-delay communication to the web browser.

In order to succeed, a web-based communications platform needs to work across browsers. Thanks to the work and participation of the W3C and IETF communities in developing the platform, Chrome and Firefox can now communicate by using standard technologies such as the Opus and VP8 codecs for audio and video, DTLS-SRTP for encryption, and ICE for networking.

This description is taken from the early-2013 Chromium blog post that announced interoperability between Chrome and Firefox. And now Edge?

Codecs…

So we have interoperability – for audio calls.  It is just audio. No video interoperability yet. Now this is just an issue of all vendors implementing at least one common video codec:

  • Edge currently implements a Microsoft variant of H264 called H264UC which adds some features like SVC
    • Adding H264 is work in progress
    • While there is a VP9 decoder for playing videos, that is not usable for ORTC so don’t get too excited
    • See Bernard’s comments for more information
  • Chrome implements VP8; H264 is work in progress
  • Firefox implements VP8 and H264

Audio interoperability is currently using G.722 instead of Opus because Edge still prefers Silk and G.722 over Opus.

APIs

But wait, how can those browsers talk if they do not agree on APIs?

Well, I implemented the PeerConnection API on top of ORTC. The gory details can be found here as part of a pull request for adapter.js. It has undergone a quite critical review and improved as a result of that. This process also showed some issues in the ORTC specification. While there has always been the assumption that it would be possible to implement the PeerConnection API using the lower-level ORTC API, nobody had actually done it.

The functionality provided is limited. More than a single audio and video track has not been tested and, since this is using an SDP similar to what is specified in the Unified Plan draft would likely not be interoperable with Chrome. But this is sufficient for quite a number of applications that are simple enough not to benefit from ORTC natively.

SDP!

Using this Javascript implementation, Edge will generate something that is close enough to the SDP used by the PeerConnection API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
v=0
o=thisisadapterortc 8169639915646943137 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 104 9 106 0 103 8 97 13 118 101
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=rtpmap:104 SILK/16000
a=rtcp-fb:104 x-message app send:dsh recv:dsh
a=rtpmap:9 G722/8000
a=rtcp-fb:9 x-message app send:dsh recv:dsh
a=rtpmap:106 OPUS/48000/2
a=rtcp-fb:106 x-message app send:dsh recv:dsh
a=rtpmap:0 PCMU/8000
a=rtcp-fb:0 x-message app send:dsh recv:dsh
a=rtpmap:103 SILK/8000
a=rtcp-fb:103 x-message app send:dsh recv:dsh
a=rtpmap:8 PCMA/8000
a=rtcp-fb:8 x-message app send:dsh recv:dsh
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=rtcp-mux
a=ice-ufrag:lMRF
a=ice-pwd:NR15fT4U6wHaOKa0ivn64MtQ
a=setup:actpass
a=fingerprint:sha-256 6A:D8:7D:05:1A:ED:DB:BD:6A:60:1A:BC:15:70:D1:6C:A1:D9:00:79:E5:5C:56:15:73:80:E2:82:9D:B9:FB:69
a=mid:nbiwo5l60z
a=sendrecv
a=msid:7E4272C7-2B6C-49BD-BF7A-A3E7B8DD44F5 D2945771-D7B4-4915-AC29-CEA9EC51EC9E
a=ssrc:1001 msid:7E4272C7-2B6C-49BD-BF7A-A3E7B8DD44F5 D2945771-D7B4-4915-AC29-CEA9EC51EC9E
a=ssrc:1001 cname:3s6hzpz1jj

Check the anatomy of a WebRTC SDP post to find out what each of these lines mean.

This allows quite a number of the WebRTC PeerConnection samples to work in Edge, just like many of the getUserMedia samples already work.

With that working, the next big challenge was browser interoperability. Would this underspecified blob of text be good enough to be accepted by Chrome and Firefox?

It turned out to be good enough. After adding ICE candidates on both sides the ice connection and DTLS states soon changed to completed and connected. Yay. In Chrome at least.
Firefox did not work because of trivial mistakes that took a while to figure out. But then, it just worked as well.

As far as I am concerned this shows the hard part, making ICE and DTLS interoperable, is solved. The rest is something for codec folks to work out. Not my area of interest 😉

{“author”: “Philipp Hancke“}

Reverse-Engineering adapter.js, Brief, Edge, interop, SDP

Related Posts

  • SDP: The worst of all worlds or why compromise can be a bad idea (Tim Panton)SDP: The worst of all worlds or why compromise can be a bad idea (Tim Panton)
  • Updated: Why the WebRTC API has it wrong – Interview with WebRTC Object API (ORTC) co-author Iñaki BazUpdated: Why the WebRTC API has it wrong – Interview with WebRTC Object API (ORTC) co-author Iñaki Baz
  • How does the new Azure Communication Services implement WebRTC? (Gustavo Garcia)How does the new Azure Communication Services implement WebRTC? (Gustavo Garcia)
  • RED: Improving Audio Quality with RedundancyRED: Improving Audio Quality with Redundancy

RSS Feed

Reader Interactions

Comments

  1. Gustavo Garcia says

    October 15, 2015 at 8:39 am

    Philipp, I’m very disappointed you didn’t implement the transcoding part (aka the “easy part” based on your comment) 😛

    Reply
  2. Satish says

    February 6, 2018 at 5:48 am

    Phillip, is the video support now available for cross-browser webRTC connection including Edge as one of the participants?

    Reply
    • Philipp Hancke says

      February 6, 2018 at 5:57 am

      Yes, the Windows 10 creators update in spring 2017 has shipped with both the VP8 and H264 codecs, allowing interoperable video calls.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

  • Sponsored. Become a webtcHacks sponsor

Email Subscription

Subscribe to our mailing list

* indicates required

Twittering

Tweets by @webRTChacks
webrtcHacksguides and information for WebRTC developers

Footer

SITE

  • Post List
  • About
  • Contact

Categories

  • Guide
  • Other
  • Reverse-Engineering
  • Standards
  • Technology

Tags

apple Blackbox Exploration Brief camera Chrome code computer vision DataChannel debug e2ee Edge extension gateway getUserMedia ICE ims insertable streams ios ip leakage janus jitsi MCU Microsoft NAT opensource Opus ORTC Promo Q&A raspberry pi Safari SDES SDP sfu signaling simulcast standards TensorFlow TURN video vp8 Walkthrough Web Audio webrtc-internals wireshark

Follow

  • Twitter
  • YouTube
  • GitHub
  • RSS

webrtcHacks · copyright © 2023