Towards Simulcast

Coming out of the MMUSIC interim meeting, I wanted to take a step back 
and look at the moving pieces that would be necessary to get simulcast 
into WebRTC for the 1.0 timeframe. At a high level, we need three things 
to happen if this is to succeed:

 1. Define a simulcast API in the WebRTC 1.0 specification
 2. Get the simulcast draft in the IETF on a trajectory to finish inside
    6 months
 3. Get the RID draft in the IETF on a trajectory to finish inside 6 months


At the moment, we have a reasonable API proposal on the table (Peter's 
"Plan X" seems as good as anything else).

The simulcast draft is pretty mature. It's been baking for a year now, 
and the changelog from -01 to -02 lists only 4 changes: adding RID, 
adding the ability to specify codec preference ordering, and two 
editorial updates.

So that leaves the RID draft. Setting aside for a moment the differing 
opinions about how much work is left on that mechanism, I think we agree 
in principle that finishing that draft in the timeframes required would 
provide for a complete solution.

Does that match everyone's understanding?



Addendum: At the face-to-face interim in Redmond, there was a discussion 
around using the currently defined API points (clone/applyConstraints) 
as a kind of poor-mans' simulcast. As reflected in the minutes, this 
approach is problematic enough with scalable coding that both Justin and 
Cullen deemed it "a non-starter." Bernard also described a set of issues 
with this approach that made it "unsatisfactory", although the details 
slip my mind, and didn't make it into the minutes.

-- 
Adam Roach
Principal Platform Engineer
abr@mozilla.com
+1 650 903 0800 x863