WebRTC is a free, open project that brings peer-to-peer real-time audio, video and data to the web without plugins, using open web standards. Checkout the WebRTC project page set up by Google for interesting links and details.
Releases & Notes
The Product Backlog is continually maintained to ensure relative priorities are understood.
- Priorities follow the Firefox Desktop Standard:
Go to WebRTC bugs to search for all open WebRTC bugs (including untriaged and unconfirmed bugs).
- Priority 1 - Blocker, must-fix before shipping. Almost by definition of P1, the "affected" flags and "tracking" flags for the bug should be set when it's triaged.
- Priority 2 - High priority backlog (bugs we are currently working on or will be working on next)
- Priority 3 - Lower priority backlog
- Priority 4 - Bugs we will accept patches for
- Priority 5 - Parking lot (Bugs we do not plan to spend any time on)
- RANK: The Rank field lets us prioritize bugs within a priority bucket (P2, P3, etc) in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - the triager will default to mid-range value.
- P1 Rank options=0-9, default 5
- P2 Rank options=10-19, default 15
- P3 Rank options=20-29, default 25
- P4 Rank options=30-39, default 35
- P5 Rank options=40-49, default 45
- Note: P5 and "parking-lot"-labelled bugs are treated identically. We no longer use "parking-lot"; it is a legacy classification.
- QE-Verify is a flag that developers should be setting. QE uses to filter which bugs they check.
- "+" means that QE should look at the bug and it can be verified with human eyes
- "-" means QE should not look at
- Typically QE-verify"-" goes with "in-testsuite" being set to "+", to show testing via another method.
Filing a bug
- Open a bug under Product:"Core" || Component: "WebRTC, WebRTC:Audio, WebRTC:Network or WebRTC:Signaling"
- After triage, bugs will be marked "firefox-blocking", with a Priority, and a Rank
- If there is a bug that should be considered for taking ASAP - you can mark "firefox-backlog"+
- Before it can be given a Rank it should:
- be in an actionable state
- for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
- for feature requests or enhancements, it means that there's a clear problem statement or suggestion
- has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
- Before it can be given a Rank it should:
- Add Whiteboard tag of [well filed] to the well filed bugs to acknowledge that we appreciate the effort and thoroughness
- Add Whiteboard tag of [good first bug] for contributors to pick up
- One can find documentation on the current libwebrtc fast-forward update process here.
- The research and history on developing the fast-forward update process is documented here
- The 2H2020 transition process is documented here.
- The old libwebrtc update process is documented here.
Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found here.
- Detailed Roadmap, noting that the further out the more lose the targets are]
Contacts and Useful Links
- Click here to try WebRTC features in the Firefox browser
- Contacts for WebRTC
- Useful Links for WebRTC
- Running tests for WebRTC in Firefox
- Getting WebRTC logs in Firefox
- IETF Draft: "Using Multicast DNS to protect privacy when exposing ICE candidates" (AKA mDNS; Interactive Connectivity Establishment (ICE) [RFC 5245] protocol)
|Meeting||Day of week||Pacific Time||Eastern Time||Central European Time||Vidyo Room||Notes|
|"Weekly Stand-up"||Wednesday||6:00AM - 6:30AM & 1:30 - 2:00 PM||9:00AM - 9:30PM & 4:30 - 5:00 PM||3:00PM - 3:30PM & - 10:30PM-11:00PM||webRTC-Apps||etherpad|
- Stand-up = 2 minutes on what have you been working on, planning to work on, and are you blocked. Bring-up topics for longer Discussion at end if needed.
- Developers and active contributors only need to attend one of the two sessions each week. We have 2 sessions due to the number of very different time zones throughout the team.
- please update the Stand-up Notes etherpad if you cannot make the meeting (even if it's just to say you're on PTO)
- IETF Standards Meetings