On september 9 and 10, a join interim meeting of the W3C Webrtc and Device API  groups took place at Microsoft HQ in Redmond.

Interim meetings, also called face-to-face meetings (when they are not happening in china ….), are smaller, more focussed meeting that take place between large all hands meetings with a specify agenda to make things happen faster. IETF meetings (3 a year) are long and can be draining. W3C meetings, well, “meeting” without an ‘s’ actually since only the TPAC is technical, are also long, but more importantly, they only happen once a year, and one might want to take decision faster than that, especially when the plate is full with webrtc 1.0 wanted features. Those interim meetings allow for feedback and decisions that are difficult if not impossible to make by e-mail.

Earlier this year, the webRTC working group came to the end of its allocated time, and requested an extension to the W3C. The extension was granted, under the condition that the convergence between the webrtc working group work, and the ORTC community group works becomes more of a reality. Erik L. (hook flash) became a chair of the new WebRTC group, and the convergence between the specs was accelerated. 

This particular meeting was dedicated to refresh the list of features that we should get on 1.0 or leave for later, and have a clear view before TPAC (end of october in Japan), so that the meeting during TPAC could just be validation of decisions, and we could end up with a stable list of features for 1.0.

Lots of new APIs had been experimented with within the ORTC group (which was comprised of many webrtc group members anyway), and peter T. from Google for example had come up with many proposal about how to design those new APIs. Those were not really controversial, where reasonably small, and things went well. Most of the topics and corresponding presentations are now accessible here.

Then we spoke about simulcast.

Simulcast was … an interesting discussion. How to simulcast on the wire was not so much a problem, almost everybody would agree to what needs to be done (even if MS and Cisco went at it a bit). What the ultimate goal should be was also not really a subject of discussion, everybody would agree that we should aim for a JS API that would allow not only for simulcast but for SVC later, and that the new APIs approved a little bit earlier would do the job. The major concern was the time and amount of effort to be done to get this in for webrtc 1.0 without delaying the already overdue release. 

There were two aspects of this. One, as simulcast touches on almost every layer from the wire to the signaling, the amount of work to test and debug it would be bigger than usual, and Google was concerned about being able to do it before the end of the year. Second, but related, was the discussion about how to signal simulcast.

Here, we were not discussing about Plan B vs Unified plan, which touches on how to signal multiple streams in a single peer connection, but discussing simulcast, which is a sub case of multiple streams where the streams are not independent from each other but a variation (different resolution, different frame rate) of the same source.  The key point here is that you do not want the browser to treat those streams independently. For example you do NOT want the browser’s bandwidth congestion control or the codec’s bandwidth adaptation algorithm to separately modify the stream resolution. You want the highest resolution to be fully dropped to accommodate bandwidth first, or e.g. the video to be switched off while the audio remains. This is to possible with multiple independent stream, this is possible (conceptually) with simulcast as you know the dependency between the streams.

The main question about simulcast was wether webrtc should re-use the work done within the IETF MMUSIC group. That group is in charge of SDP format, and his currently working on a draft specifically for simulcast. For some, it would seem odd not to use this, and to duplicate the work. Especially, mozilla who would have implemented that already in Firefox, was a big supporter of using it. For others, given the history of the MMUSIC group, that draft might still take too long to mature into a spec. Google was especially reluctant to add an additional normative dependency to the webrtc spec without having control or even visibility on the potential delay that would result from doing it. Focus on the 1.0 deadline and do not postpone it, especially by an undefined delay. The fact that the next IETF meeting is to happen AFTER the w3c TPAC was bringing the likelihood of this issue to be addressed in time for 1.0 down to zero.

As everybody agreed on what the right thing to do is, and as the only remaining unknown was related to the capacity of the IETF group to deliver, two members of the W3C werbtc working group also chairs of the IETF rtcweb group, namely Cullen J, from Cisco and Peter H. from Google reached out to their pendant at MMUSIC to probe interest of MMUSIC to have an interim meeting early enough to allow for this specific spec to surface and remove that concern from the table. As of today, the answer from MMUSIC is positive, and they committed to accelerate the process on the SDP simulcast spec (here).

The road to having simulcast in webrtc 1.0 is still perilous. First the MMUSIC need to converge on the sdp-multicast specs, hopefully with feedback from the webrtc group. Next, the w3c webrtc group had agreed on having a virtual meeting before TPAC (last week of october), with feedback from MMUSIC in hand to decide if simulcast is a go for 1.0. Finally, TPAC should be the place for first implementation feedback and final decision about inclusion in webrtc 1.0. All that in 5 weeks. 😉

 

This work by Dr. Alexandre Gouaillard is licensed under a Creative Commons Attribution 4.0 International License.

This blog is not about any commercial product or company, even if some might be mentioned or be the object of a post in the context of their usage of the technology. Most of the opinions expressed here are those of the author, and not of any corporate or organizational affiliation.