Decoding WebRTC with Erik Lagerway
When I have questions about codecs and IETF standards, I turn to Erik Lagerway. I caught him in the midst of packing for his trip to the upcoming IETF 88 meeting. Erik was a co-founder of Xten Networks (now a part of CounterPath). His current endeavor, Hookflash, is right in the center of WebRTC. Erik co-wrote WEBRTC Object API, an IETF Informational Draft, and the Draft Report W3C ORTC.
The IETF 88 meeting (agenda) takes place in Vancouver November 3-8 where, among other topics, the video codec for WebRTC will be discussed and likely resolved.
DM: Tell me how you think Cisco’s offer of free H.264 was received?
EL: I think generally it was received quite well, I mean who doesn’t like free software? Although, there is a misconception that this is completely free, which it is certainly not. MPEG LA will still take their pound of flesh regardless of what Cisco does but it does remove a barrier in the implementation process which is great. At least developers will not have to pay a fee on top of the MPEG LA royalties.
DM: What’s the next step for H.264 and VP8 regarding the mandatory standard for WebRTC?
EL: On Thursday of next week we will hear each side (H.264 and VP8) present their arguments and then there will likely be a “hum” call. In IETF land, when there is a decision to be made, members physically “hum” when they are in favor and are silent when they are not in favor. If there are more apparent hums for one over the other, that is what will become the MTI video codec (for version 1 at least) and the debate will be over, for now.
DM: Since the “humming” is largely done by industry incumbents which favor H.264, isn’t that the likely outcome?
EL: That would seem to make sense, but if we look at the the activity on the IETF RTCWEB mail list of late it is still not clear which way this will go. There is quite a bit of activity around mobile, specifically iOS, where the newly open sourced Cisco code does not fit. There would be quite a bit of work required to make that implementation function for iOS. In essence, this new Cisco code drop does not help those looking to build an iOS app with today’s WebRTC interoperability.
Another argument that favors VP8 is that its been the default codec for WebRTC developers since the API code first dropped. To change to H.264 now would create more work for apps that have deployed today. Not sure if that matters frankly, but it is a concern nonetheless.
DM: After we get past this codec issue, what are the other big hurdles to clear?
EL: For me the MTI [Mandatory To Implement] video codec debate is not the biggest issue we face when talking about the future of WebRTC. The current API is a mess and most of the larger service providers who are trying to implement around it are not happy. I know this because they tell me so.
We feel quite strongly that there was a material misstep when the original WebRTC API design was tabled, so much in fact that Robin Raymond and I created a new Community Group in the W3C where a new Object RTC API draft was published just a few weeks ago [recent revision].
This new API is much more web-centric, using JavaScript where the current WebRTC API proposes C++ in the browser/endpoint. This new Object API is called ORTC. We have already captured the attention of all the WebRTC stakeholders and feedback has been generally very positive. The only negatives we are hearing comes from those who want to see the spec stay the same as it is today.
The main argument seems to be “We are too far along now, we can’t retool everything, it’s too late.” Which in my humble opinion, is a rather blatant cop-out. We have not even reached v1 yet so if it’s broken why not take this opportunity it fix it before it gets deployed everywhere?
Weather H.264 becomes the MTI or not, many vendors will deploy it and there are real issues around SVC in the current API. Also, the lack of flexibility in the current API for web developers looking to leverage JavaScript is problematic and we completely get around the current “SDP bundle” problem altogether with ORTC.
If everyone in the WebRTC community was to look at WebRTC and ORTC with the open web in mind, ORTC would appeal to more developers, hands down.
DM: Why is there a need for ORTC?
EL: ORTC solves a rather large market problem: Microsoft’s buy in. Right now WebRTC’s reach includes Chrome and Firefox. Microsoft has openly said that they are not happy with the current API and will not deploy it. The fact that Microsoft is publicly supporting ORTC is a good indication that they would include it in a future version of Internet Explorer. This means broad support from users of Chrome, Firefox, and IE. Apple’s likelihood of getting involved increases greatly if ORTC is adopted by Microsoft.
What some people clearly don’t understand is that if IE has ORTC in it, IE can talk directly to Chrome and Firefox, and visa versa. Chrome and Firefox need not invest in ORTC initially for this to work, but it would obviously be better if they did in the long run.
We would obviosuly like to see ORTC go all the way and make it into all the browsers. Today at Hookflash we get around that with what we call a ORTC shim, which is not ideal but it does work. The best scenario is to have ORTC be the standard and have all the browsers/endpoints use it instead of the current WebRTC API. Ultimately, this is the goal of the ORCA W3C Community Group.
To that end we are holding a ORTC Walkthough this Sunday Nov 3rd alongside the IETF meeting in Vancouver. The event will be streamed live and we will have live chat available as well. The event is being attended by some of the largest names in the business.
DM: Thanks Erik. It sounds like it will be a constructive week for WebRTC. I am sure the participants will be representing the community’s interests well – or at least humming a few bars while faking it.
For more of Erik’s views, check out his blog at: http://webrtc.is