What questions do you have about the W3C and its WebRTC Working Group?

Hi everyone!

I have worked with the W3C in standards since 2011-12, initially, contributing to the WebRTC WG forming charter, then the getUserMedia (aka. media-capture) and peer-connection specifications, and later as the co-editor of the webrtc-stats specification. I started my journey with standards in 2007 with the IETF and 3GPP (System and Service Aspects, SA4 WG), the early contributions were extensions to RTP, typically to RTCP -- as my day-to-day work involved optimising media delivery (real-time and in variable network conditions).

Typically, when we talk about standards, it is a group of people from various organisations that cover a large swath of implementers and users, for-profit and not-for-profit organisations (such as, academics, policy makers, etc), and sometimes geographic regions, which come together to contribute and collaboratively solve a specific problem, together.

Oftentimes, the implementation and test deployments precede the standards document, as much of the standard follows the learnings from those early implementations and deployments. So there is a lot of-back and-forth, rollbacks, breakouts and merges that occur as a consequence to building a robust standard.

Open standards -- this is an interesting topic and depending on the community and the problem being solved, it can mean different things. Open can mean open cooperation (anyone can contribute), open process (considerations from various interested parties, not dominated by one interest group, broad consensus), or a permissive license (licensed globally in a permissive and non-discriminatory manner). IETF tries to adhere to most of the above descriptions of openness, however, emphasises on the open process, while W3C tries to make sure that the technology is more freely available without encumbrance.

IPR -- Intellectual Property Rights, IANAL, and this is my interpretation, which may differ from someone with legal training. The IETF is slightly different, it allows patent holders to impose "(fair), reasonable and non-discriminatory licensing" royalty fees (two acronyms: RAND, FRAND), which means all is well until competing companies sue each other. In the case of W3C,  W3C ensures that its specifications can be implemented on a royalty-free basis, and that the all working group members waive IPR claims against the specification that they produce. As a consequence, anyone can implement the specification, without any restriction or making a payment, thus licensing the IPR to everyone without any conditions.

Ask me anything, and I will try to answer it to the best to my knowledge. I pre-emptively covered the open aspects, happy to talk more about it.

Typically, the company signs up to the W3C, which requires paying an annual membership fee. By signing up, the company agrees with the IPR licensing terms. In addition, the company appoints an Advisory Committee Representative (AC Rep for short), the AC Rep represents the company's interest (voices concern or support) within the W3C.

Individuals from the company can then sign up to join various W3C Working Groups, the AC Rep acknowledges each request and confirms that the individuals understand the IPR terms.

Within a Working Group, a typical member needs to contribute:

• Reading the specifications that are produced by the working group, especially the ones that are of interest to you and your organisation
• Commenting and providing feedback on the API, especially, if it is feedback gained by implementation or by field trials.
• Respond to Call for Consensus, i.e., agree or disagree with the contents of the specification. If you disagree, one needs to point to an open issues (typically, either create the discussion or point to the open discussion).
• Respond to Call for IPR exclusion, by indicating to the AC Rep that there are no IPR encumbrance.
• By providing substantial input in terms of specification text (in the form of pull requests) or by volunteering time to be an editor/co-editor.

In an existing specification work, ideas are developed in various ways.

• Big or substantial changes to an existing spec will take effort. Both in writing it up and also socialising the idea. Typically, people need enough time to understand the context i.e., the proponent will make an Issue and corresponding Pull Request to the spec, create a slidedeck that explains the idea, the underlying requirements, and layer the solution, lastly present the idea in one or more meetings. Larger ideas take time to percolate and build consensus, people will counterpoints may make counter proposals, typically, compromises are made along the way, solutions can end up cherrypicking parts of different proposal solution. Typically, the editors will work with the proponents on finding initial consensus and the WG chairs will work with the community to find broader consensus
• improvements or iterations typically require creating an Issue and Pull Request and discussing within the PR. The editors will merge the idea once they have enough confidence in the solution.

However, sometimes the proposal can remain in a discussion state and not find consensus to move ahead and be merged. In this case, the editors typically need more input from various stakeholders (browser vendors, other misc vendors, and the larger developer community ). For example, we as a co-editors of webrtc-stats use: a) Submitters input needed, b) Community input needed, c) Implementation input needed, d) Icebox as ways to signal what needs to happen to unblock the proposal. The definitions of these states are below:

• Submitter input usually means the author of the issue and the PR need to discuss because the solution may not necessarily solve the problems stated in the original issue.
• Community input means that it needs wider discussion or sign-off from various other stake holders.
• Implementation input typically means that the idea and the solution sound correct, we'd need to implement to see if the APIs work correctly and are not missing something important that would require a change in design of the API.
• If editor's do not get good solutions or feel that the solutions may be premature and we as a community need to have more experience and context with the problem or solution. In these cases, editors may choose to icebox the idea/solution until a future moment in time when we have more insight to make the decision.

Planning of APIs features falls into a couple of buckets: a) new apis, b) substantial changes to an existing API. New APIs are typically dealt during chartering or rechartering of a working group. A working group charter dictates what problems it can solve and what the intended solution is scoped to do. Sometimes at the time of the WG chartering, it may not be clear which problems are relevant, in those cases, a use-case document/deliverable serves as a proxy for work that needs to be done.

Substantial changes to an existing API can occur typically through implementation experience, which results in reassessing the current solution and replacing it with new APIs as a consequence. This can break web-compatibility and requires additional care when documented and when considering deprecation of the old API.

These are just some of my thoughts on the topic of collaboration and responsibilities within the W3C. Like with many things, YMMV applies here.

@karl very good question. The answer here may skew very much towards the working groups that I have worked with. Different WGs behave differently. Tl;dr is that backtracking an earlier decision usually require data or feedback from implementation, some level of backing (breaks security, breaks webcompat, breaks usability, quirky design, etc), and a fair amount of socializing the counter idea

For example —

Anything that requires browser detection is a bad idea. The webrtc community created adapter.js to hide the browser compatibility issues and the idea was to to by webrtc v1.0, the adapter shim would not be needed

Another example -

Take the usecase perspective, does the api satisfy the agreed upon usecase? , which two solutions or option exist — should the API offer flexibility for choosing between the two option or should the proposal pick one of the options.

Overall, if there is running code or results from field trials, it presents a stronger case

For backtracking an idea or a new ideas, I generally always recommend starting by socializing the proposal with individuals, or core groups of people and working through their comments before presenting the proposal to a wider audience. In essence if you want the community to backtrack on a major earlier decision, you’ll need to put in the effort.

This can sometimes feel tedious, but we are doing this in service of developers.

@Lazer great question, you’re on the right track on things we’d do.

More holistically, my thoughts are:

For the existing specs, we as a company are striving for stability in spec and being the voice of the developer community, things we learn from our experience of building with our customers and their usecases. We are going to run into situations where more flexibility within the webrtc APIs may be warranted, we’d champion that work. Concretely, we’d either end up proposing or endorsing that feature addition to the existing spec, the main emphasis would that it benefits a particular usecase.

For new specs that will either change or evolve the way we build real-time apps (webcodecs, webtransport, encode transform, webrtc 2.0, device APIs) — we will take a more hands-on approach in contributing: writing sample apps, being part of field trials, review and specify changes to existing proposals or make new proposals, as the case may be.

Related to voice of developer, we are part of the webrtc-nu initiative that we would like to foster and support. The emphasis here is learning from within our install base and more broadly listening to developer feedback about webrtc and related APIs and taking these insights to the W3C.

Lastly, Daily has several webrtc pioneers amongst us — @kwindla, @sventy, @daginge and it’s an opportunity for more Dailynistas to be part of the ever evolving story of the real-time web.

libwebrtc is Google's free and open-source contribution that provides real-time communication capabilities to browsers, mobile apps, and low-powered IoT devices. Since it is open-source, several companies and individuals contribute to it.

How does this relate to the W3C process? I believe it contributes to two parts:

1. Playground for new ideas
2. Validates the W3C/IETF standard(s).

Sincelibwebrtc is opensource, if you have an idea for a small feature or enhancement, you can build and experiment without writing all of the webrtc APIs and protocols.

The chromium project directly uses libwebrtc and Google's webrtc apps perform experiments to improve Meet, Chromecast, and Duo, which eventually leads to improvements in the API. In addition, other chromum-based browsers are running their own improvements, for example, Brave's mission to improve privacy and security, Edge and Safari to better support their operating systems capabilities, these companies are pushing the core browser features.

In addition, many mobile applications directly use the native bindings exposed by libwebrtc, for example, all major apps from Facebook, Microsoft, Tiktok, Netflix, Twitch, Discord, Bumble, Slack, Hopin use libwebrtc, these teams make enhancements to libwebrtc for their use-case and some of those enhancements make it back into the library and from there in to the relevant specifications.

It demonstrates that several companies are building, extending, repurposing parts oflibwebrtc. When these experiments succeed, they may need to add or change the API.

Switching gears and talking about validating the standard. Every IETF and W3C standard needs 2 standards compliant implementations to graduate to a Proposed Standard or Proposed Recommendation. A proposed standard typically signals that the proposal is now stable and no significant changes will happen, especially no breaking changes. In this case, libwebrtc is one of the implementations that satisfies the criteria for W3C. The other W3C implementations are Safari and Firefox.

libwebrtc also satisfies the criteria for the IETF, as it implement the underlying protocols as well: RTP (simulcast, svc, rtp-mux), SDP (unified plan), networking (ICE, STUN, TURN, DataChannels, SCTP over UDP), security (DTLS).