I’m at the IIT RTC Conference this week in Chicago which is an excellent, no-BS conference that featured many WebRTC luminaries and one of best events I have attended in a long time.
On Tuesday I moderated a panel with WebRTC contributors and ORTC promoters, Robin Raymond of Hookflash, Bernard Aboba of Microsoft, and Peter Thatcher of Google, asking many of the same questions I did on the ORTC Q&A several weeks ago.
Dan Burnett was in the room, asking a lot of questions. If you don’t know Dan, he is a long time W3C author and editor. He is also one of the Godfathers of WebRTC who was there right at the beginning. He also has a highly regarded book on WebRTC coauthored with Alan Johnston.
Toward the end of the session, after the panelists had made it clear they were positioning ORTC as an evolutionary, layered approach to WebRTC 1.0, Dan came up and said:
I am very pleased that this group has come around to this way of thinking.. I love this, I think this is beautiful..
Now the W3C is based on community consensus, so no one individual – even a highly influential one like Dan – can speak definitively on what the community thinks, but I saw this is an extremely positive sign that the ORTC and mainline WebRTC groups may indeed coalesce as the ORTC proponents had been saying. Formerly I had only heard statements from the ORTC members to this end – not so much from those outside of this side group. Dan’s comments were a good initial indication that the ORTC Community Group would not just be summarily dismissed upon presenting their proposal.
I then proceeded to try to quickly tweet about this in the middle of moderating and failed to give this issue all the nuance it deserved in 140 characters. Fortunately I was able to pull Dan away for a few minutes to get a deeper dive on his thoughts about ORTC, the general progress of WebRTC, and what we can expect next.
Please see below for what he had to say.
{“intro-by”, “chad“}
webrtcHacks: What is your role in WebRTC?
Dan: I am one of the original editors of W3C 1.0 specification
webrtcHacks: Weren’t you the one who authored the original draft?
Dan: As the copyright states in the W3C specification, the initial text was from Ian Hickson’s WHATWG spec, but I was the one who pulled it into the first W3C draft and have been editing ever since.
webrtcHacks: In the interest of transparency can you clarify your employment affiliations? Who is currently paying your bills?
Dan: I’m an independent consultant representing Aspect in respect to my WebRTC standards work. This means I will not take another client in WebRTC at this time.
webrtcHacks: So, does this impact your objectivity on WebRTC?
Dan: Aspect would like to see WebRTC be successful in the marketplace, so anything that helps that is a good thing from their perspective.
webrtcHacks: Great, now that we established you are not a secret agent for an anti-WebRTC faction, can you summarize the current status of WebRTC 1.0?
Dan: There are 2 main parts to WebRTC:
- The media capture piece with getUserMedia and
- the media transmission piece with peerConnection
The focus recently has been on the media capture piece since the peerConnection piece depends on it.
There has been very good progress on the media capture piece. We expect to be able to give more attention to the peerConnection piece shortly.
Dan: The media capture specification is very close to being technically stable.
webrtcHacks: Can you define “technically stable”?
Dan: We’re not expecting any new functionality to come in – with one possible exception; There is discussion about switching both the specs to use JavaScript promises instead of callbacks. It is important to note that no decision has been made on this yet.
webrtcHacks: What about DataChannel?
Dan: That is defined in the WebRTC specification which is where the PeerConnection is defined.
webrtcHacks: What can you say about timing of all of this? When do you think WebRTC will be a formal standard?
Dan: All timing estimates with respect to standards are guesses at best. Because I am very experienced at doing this, you can trust my opinion by about 30%. (laughs)
Given that, if we don’t deep-end on the promise discussion – which is a new thing that just came up – the mediaCapture spec should be very stable in 3 to 6 months.
webrtcHacks: There were some who said that the WebRTC specs would be stable state 3 to 6 months ago.
Dan: Yes, and we may be saying it again in 3 to 6 months. But short deadlines keep the pressure on.
Everyone wants this to wrap up as soon as possible.
webrtcHacks: OK, back to status question – what’s happening with the peerConnections piece?
Dan: There is some editorial catch-up work to decisions that have already been made that could take 3 months to be fully reflected in the specification. There are also topics that are still being worked on, including things like the identity proxy mechanism and exactly how track-level controls will work.
Because there is still real technical work to do, for the WebRTC specification we are at least 6 months beyond the media capture specification in terms of timing.
webrtcHacks: So where does that leave developers today?
Dan: None of this means that WebRTC as a technology isn’t usable today. The browser vendors are working very actively on this and are in some cases ahead of the specification.
The good news about this – is that the normally lengthy W3C implementation report process during which implementations are requested to demonstrate that the specification is stable, should go much faster.
webrtcHacks: How will these changes impact developers and those who have existing applications? Do think this means a lot of potential re-work?
Dan: The change in the peerConnection specification from a stream focus to a track focus will cause a change in how people have to write their applications. Adapter libraries like adapter.js may help to mitigate this.
The other changes I mentioned are largely functionality that people are not yet using today. Of course, if we change to use promises, that will definitely change how applications have to be written. It is not yet clear how much of this can be hidden by the browsers or adapter libraries.
This is one of the items that will be considered as the working group discusses whether to switch to using promises.
webrtcHacks: It sounds like we need to have another discussion about what promises are and why they are being considered?
Dan: Yeah, that is a lengthy topic we should cover separately. We – as in the working group – will have our first discussion on this topic this week, so I may know more after that.
webrtcHacks: Now that we have a baseline status, let’s talk about some of the more controversial aspects. The first is ORTC. What are your thoughts there?
Dan: ORTC was originally positioned as a competitor to WebRTC. Over the past 6 months there appears to have been a commitment for the work to play better with the existing WebRTC 1.0.
Specifically, ORTC is attempting more now to provide capabilities that are add-ons beyond 1.0 rather than changes to it. I believe this is a very significant and positive turn of events for the success of WebRTC as a technology.
The industry that is building up applications around WebRTC does not want to have doubts about the investment they have put into using it today.
ORTC was originally positioned as a competitor to WebRTC. Over the past 6 months there appears to have been a commitment for the work to play better with the existing WebRTC 1.0
webrtcHacks: How much if at all has ORTC and ORTC-like concepts been discussed in the Working Group (WG)?
Dan: Officially, there has not been any discussion of ORTC in the WebRTC WG and there likely will not be until the existing 1.0 specifications have stabilized, because it is risky to redirect a group’s efforts toward a next version before they have finished the first version. At that point, the WG will consider any suggestions for a next version or additional work in general.
ORTC, or perhaps even pieces of it, will definitely be considered for inclusion in the next version if submitted into the consensus process.
Interestingly, some of the track control capabilities from ORTC were already discussed as possible additions into 1.0 and the working group has agreed to do so.
webrtcHacks: so is it fair to say that there is already some ORTC in the 1.0 spec?
Dan: It is more accurate to say that features originally developed in the ORTC group were considered of enough value to try adding into 1.0 in some form. They may initially look very much as they do in ORTC, but could of course change as the WG discusses them, or not.
webrtcHacks: Since you have been doing this for a while, how often has this process with the Community Group been used? How often do these contributions make their way into the specification?
Dan: There is no official relationship between the 2 groups. However, some people involved in both groups created a proposal inspired by the ORTC features and presented it within the working group. [More on this here and here]
webrtcHacks: And how was the reception to that proposal?
Dan: After a reasonable discussion, the working group decided to adopt the proposal, understanding that there may be details that still need to be worked out. This could of course result in changes in the final form.
I personally think it is likely these track level controls will end up in the final specification in some form because they are very useful.
Officially, there has NOT been any discussion of ORTC in the WebRTC WG and there likely will not be until the existing 1.0 specifications have stabilized
webrtcHacks: Do you see this as an end to the contention and controversy over this topic?
Dan: As I mentioned earlier, ORTC was originally presented as a competitor to WebRTC. Their change in focus may allow for a convergence of the 2 camps down the road. These new track-level controls and the way they were proposed to the WG could perhaps be a model for how this convergence could occur.
As long as proposed contributions to WebRTC continue to be constructive, as opposed to destructive, I think worries about major contention in this space will decay naturally.
Individual topics could always be controversial, but as long as they are in the spirit of adding on to what we have, then users of the technology don’t have to worry that their investments in this space will turn out to have been wasted.
webrtcHacks: So, other than the new promises proposal, are there any other major or contentious items that could derail your desired timelines?
Dan: There is nothing I can predict at this time, but surprises can always occur.
webrtcHacks: what should those who outside of the W3C standardization community make of all of this? Is all this typical?
Dan: The process of building consensus can sometimes take a while. It is normal for individuals, groups, industries, to disagree initially. If they eventually find common ground, then the path they took to get there doesn’t turn out to matter that much. This is why the change in focus toward convergence is more important to the overall success of WebRTC than the specific technical outcomes, although the technology itself is of course important.
webrtcHacks: What would be cause for alarm then?
Dan: Attempts by the two groups to diverge again would definitely delay things. I am more optimistic today than a year ago that we are on the constructive path.
webrtcHacks: if our readers what to get involved with any of this, what should they do?
Dan: I am always happy to chat with anyone on this topic. My contact details are on my website at standardsplay.com.
I am also doing a training session with your fellow webrtcHacks colleagues, Victor and Tsahi in Paris this December for those interested in a live session.
You can also participate in the WebRTC Working Group directly. Visit the WebRTC charter page for details on how to join.
{“interviewer”, “chad“}
{“interviewee”, “Dan Burnett“}
Leave a Reply