Real Time Communications Featured Article

End the WebRTC and ORTC Divide

March 07, 2016

One of the great WebRTC accomplishments of 2016 would be to get a single unified standard on the books. No more of this vendor-camp forking between WebRTC and ORTC, causing headaches for developers and service providers alike.   Multiple working groups and paths slow adoption, cost developers time and money trying to pick a path, and cause confusing for everyone involved.




ORTC (Object RTC) emerged in 2013 as an alternative path to WebRTC, with advocates not happy with WebRTC's mandate of a session description protocol (SDP) as part of the interface to negotiate capabilities when setting up multimedia communications in an RTC session. 

SDP is often described as an unnecessary "blob" of text. ORTC proponents say you don't need the complexities of SDP and the SIP protocol and can handle media with a smarter stream API that handles communications at a lower level.   SDP also is a signaling protocol, forcing communications in an offer/answer mode.  SIP causes problems for WebRTC because there is a lot of junk in SIP that causes compatibility headaches.  Get rid of SIP, get rid of some headaches.

The call for ditching SDP in the middle of trying to formalize a WebRTC 1.0 specification resulting in unhappiness, underlined by a perception that Microsoft was trying to derail WebRTC by supporting ORTC, but ultimately Google and others join the ORTC W3C community group.

It doesn't hurt that Object RTC is mandated to be compatible with WebRTC and people seem to sit on the working groups of both WebRTC and ORTC.  Sometimes ORTC is described as WebRTC 1.1, but there are bits and pieces of ORTC that have being channeled back into the evolving WebRTC 1.0 specifications.

ORTC's main benefit is that it provides a group of lower level JavaScript APIs that provides greater flexibility over the WebRTC SDP interface while providing the same components.  In addition, ORTC allows a shim to provide the same functionality of stock WebRTC 1.0 APIs. You get the functionality of WebRTC 1.0 with increased access.

Microsoft says the ORTC API is better for a mobile and video-based world because it supports advanced video features such as scalable video coding and simulcast, things that are a pain to support within SDP and WebRTC 1.0. 

Currently, the path I've heard discussed for WebRTC and ORTC is called WebRTC NV (Next Version).  It will merge WebRTC 1.0 and ORTC, with applications able to use both WebRTC 1.0 or object APIs, with developers having the option to skip using SDP if they don't want/need the capabilities. 

More importantly, WebRTC NV should provide a standardized way through the assimilated ORTC API to support multiparty and simulcast video along with scalable video coding.  WebRTC 1.0 is great for straight up peer-to-peer video sessions, but move beyond that and life gets complicated for everyone involved.

But the problem in the meantime is ORTC isn't a standard at the moment, but a working group.  The ORTC gang needs to formally move its work into the W3C WebRTC working group and everyone needs to have consensus to lock down standards. Until that happens, there are a significant number of people that are working on two different projects, with the older one (WebRTC) cribbing from the new guy (ORTC).   A unified path and timetable forward for WebRTC NV would be good for the entire community.




Edited by Stefania Viscusi

Article comments powered by Disqus


Home
  Subscribe here for RTCW eNews