ORTC is not the “Other” RTC: Q&A with ORTC CG Chair Robin Raymond

Biggie vs. Tupac. Gates vs. Jobs. Apple vs. Samsung.  Nothing catches people’s attention for no legitimate reason like a feud. Unfortunately this isn’t just a celebrity phenomenon. Feuds have been endemic even to real communications as well. From the very beginning, Elisha Gray’s dispute with Alexander Graham Bell over the original telephone patent showed the industry has a propensity for squabbles. Unfortunately we have become so accustomed to feuds that we sometimes fabricate battles that do not really exist. I fear that this is often the case with one of the most important, but misunderstood efforts affecting WebRTC’s future – Object Real Time Communications (ORTC).

We first covered ORTC more than a year ago with our interview with Iñaki Baz and Tim Panton further highlighted the pain of SDP in his post. You can navigate some of the complexities of SDP yourself using our interactive SDP tool. So, has anything really happened with the efforts to remove SDP from WebRTC, or SDP the way it will be forever?

To get the most direct truth possible,  I asked W3C ORTC Community Group (CG) Chair, Robin Raymond to set the record straight in an interview. In addition to chairing the ORTC CG, Robin is Chief Architect at Hookflash and has had a full career as a developer, architect, CTO, and CEO.

{“intro-by”, “chad“}

---

webrtcHacks: Before we dig in, can you give our readers some background on ORTC – Object Real-Time Communications – and how it came about?  

Robin Raymond: Ideas for ORTC began at Hookflash, where all 3 stakeholders came from a SIP-centric background and knew that we wanted a more adaptable protocol for our next project. There really wasn’t one that fit our needs. We began work on a P2P communications model called Open Peer. While building Open Peer, we realized that this new model was easier if it was not required to conform to the constraints of old. It widened our gaze considerably.

Based on previous experiences in the SIP world, we were concerned that an SDP offer/answer model used as the exclusive API surface for WebRTC would not only make our lives at Hookflash more difficult but would slow the industry as a whole. I don’t really want to re-iterate the reasonings as it would be redundant, but suffice it to say we felt very strongly about conveying our thoughts on how Real-time Communication on the Web might evolve. So, we got involved in the WebRTC standards discussions. One can read some of the background on that here.

webrtcHacks: So how is this effort manifested today?

Robin Raymond:  At the heart of ORTC is a JavaScript API for performing real time communications on a browser, mobile or even on a server.The ORTC API was designed within the ORTC W3C Community Group originally founded by Hookflash. This group now has more than 70 members, including many large corporations.

The Community Group published the ORTC API Public Draft on August 20, 2014. Microsoft published a blog post publicly supporting the draft. Hookflash also issued a blog post of our own with quotes from Google and Microsoft, showing an initial glimpse of solidarity.

webrtcHacks: So why do some think that ORTC is a Microsoft initiative?

Robin Raymond:  That is a common misconception and it is completely incorrect. Microsoft was an early supporter of ORTC and participated to help refine ORTC, as have other companies such as Google, who also actively participate in the WebRTC Working Group.

The previous CU-RTC-Web alternative proposal fiasco left some to believe Microsoft was only interested in providing “their” alternative. When Hookflash posted our concerns with the current API approach to the WebRTC API, Microsoft and others shared similar concerns.

Instead of trying to force an alternative strategy upon others – which we have no power to do anyway – Hookflash formed a W3C Community Group of companies and individuals who shared a common belief that we could help progress the WebRTC technology along orthogonally without disrupting the current WebRTC efforts. I’m happy that Microsoft decided to join such an open effort and has been actively supportive, but by no means do they “own” ORTC.

There is no conspiracy here... This isn't Betamax vs. VHS

webrtcHacks: Is ORTC similar to Microsoft’s former CU-RTC-Web prototype? Is ORTC just a continuation of CU-RTC-Web under a different name?

Robin Raymond: Although it has no direct relationship to CU-RTC-Web or Microsoft, ORTC API is also Object oriented, which means web developers would feel right at home, which is what it seems like Microsoft was shooting for with CU-RTC-Web.

However, many had serious concerns about CU-RTC-Web because in many ways it was far too low level and allowed JavaScript developers to fully take control over the browser’s RTC engine. This sounds good in theory, and as much as I personally liked their API, in practice CU-RTC-Web could have been a nightmare to secure and lock down.

ORTC took a different approach by exposing the “pipelining” of the objects that already must exist under the current WebRTC API hood. The goal was to allow a “do as I say” API with lower object level knobs for the RTC engine, but still allow the current WebRTC SDP Offer/Answer based API to be layered on top as a shim. With this approach ORTC provides raw control for those who need it while still enabling the current more familiar WebRTC API.

webrtcHacks: Google can afford to push WebRTC because of Chrome and expanding the functionality of the web is core to supporting its massive advertising business. Other behemoths like Microsoft and even Mozilla have similar motivations related to promoting the web.

What’s in this for you guys? Hookflash isn’t a big company. How can you afford to drive this effort? Why shouldn’t the WebRTC development community be concerned about your motives?

Robin Raymond: The motivation behind us starting and continuing to support the ORTC movement is simple, we want to reduce our own headaches later. Interoperating with hard-coded elements in browsers that cannot be readily tested or modified without significant market delay is costly. Facilitating interoperation between WebRTC browsers and our own offering at Hookflash was motivation enough for us to try and encourage a better methodology.

We are passionate about the future of web communication and feel strongly that this is the right path, it’s really that simple, there is nothing sinister about it. Personally, I’ve put in countless hours of my own time because I love technology and I believe our efforts will have ground changing impacts when everyone has universal access to WebRTC technology.

We are indeed a small company, and frankly it has been a challenge juggling our responsibilities between Hookflash and the W3C ORTC CG – both have required plenty of work. Thankfully we’ve had the support of Microsoft, Google, Versatica, Jitsi and others in CG which has made it possible to move the mountains of work required. If anything there’s even more of a need for help at the point, now we have to go from API design to implementable library.

webrtcHacks: So ORTC is a different API than the current W3C WebRTC specifications. Does that make ORTC a competitor to WebRTC? Many believe ORTC is some kind of conspiracy to overturn the existing API specification.

Robin Raymond: There is no conspiracy here. ORTC is not a competitor to WebRTC. Success of this work should be measured by how well ORTC allows the current WebRTC 1.0 specification to evolve without disrupting the current progress being made while adding real value to the WebRTC ecosystem.

This isn’t Betamax vs. VHS. In the words of our esteemed colleague Justin Uberti from Google “ORTC / WebRTC 1.1 is an evolution of WebRTC 1.0, not a French revolution with guillotines and all that…” (source below)

webrtcHacks: So how does the ORTC API fit with the current WebRTC API?

Robin Raymond: Adopting the ORTC API is effectively supporting the WebRTC 1.0 API. It’s not an “either / or” scenario. For those that like the current API, ORTC allows for a shim enabling the current SDP based WebRTC API. Plus ORTC allows for a pipeline “do as I say” primitives for those who needs more raw control than SDP offer / answer allows. The API is designed to be wire compatible from day 1 and bugs are filed if the API would cause incompatibilities.

webrtcHacks: No one gets excited about having to rewrite something that already works. Can explain this “shim” a bit more? Are developers going to have to rewrite their code to make their existing applications work in the future? Will this just be another js src= they need to include without any other code changes?

Robin Raymond: Compatibility with the WebRTC 1.0 API should be easier to achieve as an SDP based JavaScript shim on top of ORTC. JS developers point to a common WebRTC 1.0 JS “SRC” shim library whose SDP parsing/negotiating characteristics will be identical and work on top ORTC API primitives, proven compatible via unit testing.

webrtcHacks: Does that mean the shim does not exist yet? Is this something you have prototyped? Are you sure it is going to work?

Robin Raymond: No, the shims do not exist yet. As I said above, we need more help than ever. The spec just recently saw its first public draft; that needed to come to fruition before any libraries could be completed. There has been some very early Node.js work on some of this, but to be honest that was very early in the history of ORTC. Since then, there have been plenty of very capable eyes on this, we are all convinced that the shims will work just fine.

The ORTC to WebRTC 1.0 JS shim (Downshim) will surrender some of the more advanced ORTC capabilities eg. SVC, since those features are not supported in WebRTC 1.0. The WebRTC 1.0 to ORTC shim (Upshim) should give ORTC vendors exactly the same functionality as that one would find in the WebRTC 1.0 API. That is a stated goal for ORTC.

webrtcHacks: If I am a WebRTC developer that doesn’t directly deal with SDP today, why should I care about ORTC? Isn’t decomposing the existing APIs and adding new ones just making WebRTC more complicated?

Robin Raymond: One reason why ORTC is so important is interoperability. Unit testing much simpler primitives makes getting compatibility right. In many ways, the ORTC API is about exposing the objects that already must exist below the WebRTC 1.0 API surface. ORTC should improve interoperability across all WebRTC implementations.

Another reason to want an API like ORTC is to have access to more advanced functionality like SVC (Scalable Video Coding) and Simulcast. Eventually this will become more commonplace in the industry anyways, it will become a requirement and less of a luxury item.

There are many signalling and other scenarios that are complicated to do with an SDP offer/answer API. The offer/answer model was designed to work in particular methodologies and those expected scenarios can work just fine. However, moving beyond that point a more flexible API will enable JS developers to do unanticipated things and explore new models of how to setup, exchange and negotiate media.

webrtcHacks: Do you have any code samples of what this might look like vs. WebRTC today?

Robin Raymond: Aside from what exists in the ORTC specification itself, no; but that work is undergoing scope and design now so it shouldn’t be long. We are also calling upon developers and sponsors to get involved and help out as well.

webrtcHacks: Chrome is already implementing RTCSender and RTCReceiver API’s. Are these ORTC compliant?

Robin Raymond: They certainly should be and we expect that they will be but we still need to test those components against the ORTC Lib (when its far enough along) to be sure. There’s no reason at this point why they wouldn’t be compatible, after all, the goal is to maintain compatibility.

webrtcHacks: 1.0, 1.1, 2.0 – can you help explain the various version numbers being thrown around out there and how they relate to ORTC?

Robin Raymond: The WebRTC 2.0 reference was used by some to describe the work being done in the W3C ORTC CG before an actual designation on the ORTC API was attributed. In an effort to reduce potential confusion, the ORTC CG adopted a 1.1 designation instead of 1.0 for the initial API during a CG meeting in April 2014. Choosing a 2.0 designation did not make sense since this would be the first public draft of ORTC and the desire to maintain compatibility with WebRTC 1.0. From this point forward we have been referring to first ORTC public draft as 1.1. You can hear the W3C ORTC CG discussion yourself here:

Since the ultimate goal here is to unify the WebRTC 1.0 work and ORTC 1.1 work, the translation manifested itself as such:  ORTC 1.1 = WebRTC 1.1.

webrtcHacks: Is “ORTC 1.1 = WebRTC 1.1” a view that is also shared by the WebRTC WG? Is that still something ORTC needs to make a case for, or is that already done?

Robin Raymond: I’m not sure if this subject has been broached within the WG or not. We decided not to discuss ORTC in the WebRTC WG quite some time ago. We keep those discussions off the WG list as to not distract the WebRTC WG’s focus on 1.0. I still think there is plenty of debate going on for what exactly 1.0 consists of now so 1.0 could in fact morph into 1.1 in some ways, but that is up to the WebRTC WG to decide.

ORTC / WebRTC 1.1 is a term the public draft editors (Hookflash, Google & Microsoft) have been using for a while now. How this eventually manifests itself in the WebRTC WG is something we cannot predict but I see no reason why it couldn’t become the same version.

webrtcHacks: So what’s next for ORTC? The ORTC spec editors now feel that the API is in far enough along to implement.

Robin Raymond: The next step is to implement a version of ORTC as a library to prove out the technology. With that in mind we have created a ORTC Lib introduction presentation that outlines the goals, uses and merits of this library implementation, that presentation follows below.

webrtcHacks: How can our readers get involved?

Robin Raymond: Want to help? Excellent! Send an email to [email protected] with your ideas and we will respond with next steps. We are also open to sponsored work. If you would like to contract the maintainers to do work that would be contributed back to the open source project under BSD license, please email your project ideas to [email protected]

webrtcHacks: Where should developers go to learn more?

Robin Raymond: Here are some useful links:

• Codebase: https://github.com/openpeer/ortc-lib
• Dev Forum: https://groups.google.com/a/ortc.org/forum/#!forum/discuss-ortc
• W3C CG: http://www.w3.org/community/ortc/
• Current API Specification: http://ortc.org/
• Contribute: [email protected]
• Sponsor: [email protected]

 

{“interviewer”, “chad“}

{“interviewee”, “Robin Raymond“}