Media/WebRTC

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

• Firefox Release Schedule Calendar
• Firefox WebRTC & Web Audio Release Notes

Triage Guidelines

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

Contributor Engagement

• 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

libwebrtc Updates

• 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.

Up-streaming Changes

• One can find instructions for up-streaming changes here.

libsrtp Updates

Maintained by Cisco, libsrtp needs to be vendored periodically. A description of that process can be found here.

Project Status

• 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
• Debugging WebRTC Calls
• IETF Draft: "Using Multicast DNS to protect privacy when exposing ICE candidates" (AKA mDNS; Interactive Connectivity Establishment (ICE) [RFC 5245] protocol)
• Media/WebRTC/Privacy
• Media/WebRTC/Architecture
• etc.

Meetings

• 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

Archived

Notes

• Archived notes