Skip to main content

Real-Time Communication in WEB-browsers

The information below is for an older proposed charter
Document Proposed charter Real-Time Communication in WEB-browsers WG (rtcweb) Snapshot
Title Real-Time Communication in WEB-browsers
Last updated 2021-02-02
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering
WG State Proposed
IESG Responsible AD Murray Kucherawy
Charter edit AD Murray Kucherawy
Send notices to (None)

The RTCWEB working group was originally chartered to standardize mechanisms
that provide direct interactive rich communication using audio, video,
collaboration, games, etc. between two peers' web-browsers, without
requiring non-standard extensions or proprietary plug-ins.  The result was a
set of RFCs from RTCWEB, in addition to many other RFCs from other working
groups, all of which are interrelated and had to be published together in what
the RFC Editor refers to as a “cluster”.  In the end, that cluster comprised
more than 40 RFCs and was finally published in January 2021.

During the run-up to publication of the cluster, a contradiction was identified
between what became RFCs 8829 and 8843.  A description of this contradiction
was added to both documents to highlight the problem, and state our intention
to proceed with publication but quickly initiate an effort to publish updates
to the affected documents.

The key part of the added text was as follows:

“The specific issue involves the handling of "m=" sections that are
designated as bundle-only, as discussed in Section 4.1.1 of [RFC 8829]. 
Currently, there is divergence between JSEP and BUNDLE, as well as between
these specifications and existing browser implementations …”

The working group is being reconstituted to take up this contradiction, come to
consensus on a resolution, and issue Standards Track updates for those two
documents.  Specifically, the goal of this work is to address only the
contradictions regarding "bundle-only" between BUNDLE and JSEP.  The
resulting aligned solution should avoid impacting the interoperability with SDP
Offer/Answer.  Finally, the impact on existing implementations that are
affected by any change is to be considered.

The working group will produce updates to those two documents, and update
draft-ietf-rtcweb-sdp accordingly.  Updating any other document, or taking up
any other issue, is out of scope and will require IESG approval via

Coordination with the MMUSIC working group to develop this solution will be