The backstory on ORTC (Object RTC) and why we thought WebRTC needed an Object interface

Early in 2013, Robin and I were becoming growingly concerned about the direction the WebRTC WG in the W3C and the RTCWEB WG in the IETF were taking, specifically with respect to mandating SDP and not taking into consideration those who might want an Object interface versus a C++ / SDP O/A interface.

Robin writes…
Do we need SDP ”blob” format in the exchange in the first place? All media

can be done without SDP given an intelligent stream API. An API already
exists to create these streams (albeit somewhat lacking if we remove the
SDP ’blob’). This API helps “simplify” creating this blob for later
exchange. But the blob is truly not needed. Each side could in fact create
the desired streams, pass in the appropriate media information such as
codecs and ICE candidates and chose the socket pair to multiplex upon.
Yes, it’s a bit more low level but it certainly can be done (and cleanly).


Read the rest here..


ORTC API – Editors Draft Update, includes layering/simulcast and more 

15.1 Changes since 12 April 2014

  1. Fixes for error handling, as described in Issue 26
  2. Support for contributing sources removed (re-classified as a 1.2 feature), as described in Issue 27
  3. Cleanup of DataChannel construction, as described in Issue 60
  4. Separate proposal on simulcast/layering, as described in Issue 61
  5. Separate proposal on quality, as described in Issue 62
  6. Fix for TCP candidate type, as described in Issue 63
  7. Fix to the fingerprint attribute, as described in Issue 64
  8. Fix to RTCRtpFeatures, as described in Issue 65
  9. Support for retrieval of remote certificates, as described in Issue 67
  10. Support for ICE error handling, described in Issue 68
  11. Support for Data Channel send rate control, as described in Issue 69
  12. Support for capabilities and settings, as described in Issue 70
  13. Removal of duplicate RTCRtpListener functionality, as described in Issue 71
  14. ICE gathering state added, as described in Issue 72
  15. Removed ICE role from the ICE transport constructor, as described in Issue 73

H.264 has won the WebRTC codec debate

H.264 AVC for WebRTC
A few things have happened that lead me to believe that H.264 has already won the WebRTC codec debate, regardless of what was not decided in the IETF RTCWEB or W3C WGs…


– Cisco delivers Open Source H.264 Codec via

– Google and Cisco demonstrate H.264 interop in Chrome

– WebRTC Source Code for H.264 implementation surfaces in the WebRTC Developer mail list

So it looks like Chrome will end up supporting H.264 = they will support both VP8 & 264

Mozilla / Firefox already said they will support both.

Apple seems to be getting more involved, my guess is that they will announce some level of WebRTC support for Safari at WWDC. If they do, they will also favor H.264.

Since ORTC will be compatible with WebRTC to some degree,  IE modern APIs group has indicated that ORTC is “under consideration”. Microsoft also seems to favor H.264.

That covers all the major browsers.

It feels like the MTI Video codec issue is a non-issue.

ORTC, WebRTC & Doohickeys

The ORTC CG is making great progress on many fronts and it looks like the conversation around RTPSenders & Receivers (formerly known as Doohickeys) is taking more shape in the WebRTC WG. They even have a name there now: RTCRTPSenders / Receivers. The WebRTC WG teleconference call today was far less controversial than I am used to, it felt like everyone is trying harder to get things done.

I am not convinced we need Constraints at all in 1.0, by the rumblings on the calls it seems as though I am not alone. You can see that conversation taking shape in the Working Group here:

Here is a decent summary on the recent ORTC API update.

Recent Comments
    Privacy Settings
    We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
    Consent to display content from Youtube
    Consent to display content from Vimeo
    Google Maps
    Consent to display content from Google
    Consent to display content from Spotify
    Sound Cloud
    Consent to display content from Sound