[minutes] Jan 20 meeting

Hi,

The minutes of the WebRTC WG meeting held last week (Jan 20), based on 
notes provided by Youenn and Guido, are available at:
   https://www.w3.org/2026/01/20-webrtc-minutes.html

and copied as text below.

Dom

                       WebRTC January 2026 meeting

    [2]Agenda.

       [2] https://www.w3.org/2011/04/webrtc/wiki/January_20_2026

Attendees

    Present
           -

    Regrets
           -

    Chair
           Guido, Jan-Ivar, Youenn

    Scribe
           scribe

Contents

     1. [3]PEPC for camera & microphone
          1. [4]Overview of PEPC for Camera and Microphone
          2. [5]Analysis of the Geolocation Element API Shape
          3. [6]Usermedia elements
          4. [7]Future Collaboration and Roadmap
     2. [8]RTC prefix
     3. [9]dropped frame counter for MSTP
     4. [10]Summary of resolutions

Meeting minutes

    Slideset: [11]https://docs.google.com/presentation/d/
    1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/ ([12]archived PDF
    copy)

      [11] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/

   PEPC for camera & microphone

     Overview of PEPC for Camera and Microphone

    [13][Slide 10]

      [13] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#10

    [14][Slide 11]

      [14] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#11

    [Jan-Ivar Bruaroey provided an overview of PEPC (Page Embedded
    Permission Control), which proposes a new user experience (UX)
    for camera and microphone access. The working group had
    previously resolved to use Media Capture Streams or its
    extension to anchor discussions on PEPC integration, requiring
    decisions on the API shape and content. This overview aimed to
    present a vision for using camera and microphone through PEPC,
    starting with an analysis of the geolocation API.]

    [The existing PEPC implementation for WebRTC and
    camera/microphone access requires multiple button pushes (up to
    three) to activate the camera, which Jan-Ivar Bruaroey
    suggested makes the process less user-friendly than the current
    standard two-click process. The PEPC button is often shown as a
    website prompt rather than being properly embedded in the page
    layout, causing an extra layer of user interaction. A mock-up
    was presented showing how a PEPC button could be embedded
    directly into the page layout, potentially replacing an
    existing button.]

     Analysis of the Geolocation Element API Shape

    [15][Slide 12]

      [15] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#12

    [The geolocation element, shipped in Chrome 144, provides a
    basic "Use location" button that initiates resource
    acquisition, functioning as a page-embedded powerful feature
    control button. The user initiates the resource acquisition by
    clicking the button, which fires an event that returns
    information such as latitude, longitude, and accuracy upon
    success. Mike West confirmed that clicking the button gives the
    user a choice to grant location access temporarily or
    persistently, with an option to request continuous access using
    a 'watch' attribute.]

    [16][Slide 13]

      [16] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#13

    [Interaction between Legacy and PEPC Geolocation APIs: The
    legacy Geolocation API's `getCurrentPosition` method and the
    new PEPC geolocation element were compared, demonstrating that
    once permission is granted via PEPC, the page gains access
    through the legacy API for the duration of the session.
    However, if a user chooses "allow this time only," future
    visits result in "prompt fatigue," which PEPC aims to improve.
    The "allow always" option allows the website to decide when to
    turn on the feature in the future, which is considered a
    privacy trade-off.]

    [17][Slide 14]

      [17] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#14

    [Proposal for "Allow on Button Push" Persistence: A new
    persistence level, "Allow on button push," was proposed as a
    middle ground that simplifies feature usage by the user without
    permanent privacy compromise. With this option, the user
    receives a granted permission only until the tab is closed, but
    on future visits, they will not be prompted as long as they use
    the PEPC button first. This persistence level is not currently
    exposed via the Permissions API, meaning the web page cannot
    tell ahead of time what will happen when the button is pushed.]

    [18][Slide 15]

      [18] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#15

    [19][Slide 16]

      [19] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#16

    [Discussion on UX and Persistence of PEPC Buttons: There was a
    discussion about the wording of permission choices, with
    Jan-Ivar Bruaroey noting that the exact phrasing ("Allow on
    button push," "Allow while visiting the site") is a UX question
    for individual browsers, and they represent concepts rather
    than required terminology. Tim Panton raised a concern that if
    a user chooses "allow on button push," they need to be able to
    recognize the PEPC button on future visits, even with website
    style changes. Mike West responded that core elements of the
    button, like the icon and text, are largely browser-controlled
    to ensure legibility and comprehensibility regardless of the
    surrounding presentation.]

     Usermedia elements

    [20][Slide 17]

      [20] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#17

    [Proposed Microphone Element API Shape: Jan-Ivar Bruaroey
    proposed a simple HTML microphone element following the
    geolocation model, intended to be a toggle button that stays on
    the page. When clicked, it would call `getUserMedia` with set
    constraints and fire a `stream` event upon user allowance. The
    proposal suggested that the browser would fire a source-level
    mute/unmute event on the single audio track when the button is
    toggled off and on, though Youenn Fablet argued for
    source-level muting to prevent conflicts with cloned tracks.]

    [21][Slide 18]

      [21] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#18

    [Proposed Camera Element and Muting Strategy: A similar
    proposal was made for a camera element with a "Turn on camera"
    toggle button and the ability to set video constraints. The
    discussion reiterated that if the button only mutes a single
    track, as proposed, it allows advanced applications to clone
    the track for self-view (e.g., a "comb check") while simple
    applications benefit from default behavior. It was acknowledged
    that web developers may choose to remove the built-in button if
    it is too restrictive, necessitating a design that encourages
    developers to keep the button visible.]

    [22][Slide 19]

      [22] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#19

    [UserMedia Element and Constraints Discussion: A third element,
    `usermedia`, was proposed for cases where a website might want
    to ask for both microphone and camera permissions
    simultaneously. Youenn Fablet questioned the need for this
    element in a minimum viable product (MVP), citing concerns
    about the complexity and the difficulty in designing an
    appropriate icon that conveys both capabilities. Jan-Ivar
    Bruaroey agreed that `usermedia` was the "least interesting
    button" but noted that the Chrome team had expressed interest
    in it because it allows for single-prompt acquisition of both
    capabilities, reducing friction.]

    [23][Slide 20]

      [23] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#20

    [24][Slide 21]

      [24] 
https://docs.google.com/presentation/d/1PtncyEK9WFPQlhtS2iOlx4vIbXqhEOMp3MQCfXZC5OQ/#21

    [User Media Element and Constraints Discussion: A third
    element, `user-media`, was proposed for cases where a website
    might want to ask for both microphone and camera permissions
    simultaneously. Youenn Fablet questioned the need for this
    element in a minimum viable product (MVP), citing concerns
    about the complexity and the difficulty in designing an
    appropriate icon that conveys both capabilities. Jan-Ivar
    Bruaroey agreed that `user-media` was the "least interesting
    button" but noted that the Chrome team had expressed interest
    in it because it allows for single-prompt acquisition of both
    capabilities, reducing friction.]

     Future Collaboration and Roadmap

    [The speaker announced plans for an editor's meeting during the
    current week to meet with the PEPC team to get a status update
    and agree on a minimum feature set for a Version 1 and a future
    roadmap. They also plan to discuss developer feedback from the
    origin trial, which was used by several major video
    conferencing applications, and decide on plans for periodic
    follow-up meetings. Jan-Ivar Bruaroey stressed the importance
    of these meetings being public and having minutes.]

    [Review of PEPC Button Details and API Shape: A meeting
    scheduled for Thursday will be used to sort out details
    regarding the PEPC (permissions, elements, presentation,
    storage, and identity) discussion points. The main questions
    revolve around the mute/unmute functionality, the API shape for
    the user media element (and whether it is an MVP), styling, and
    constraints. Mike West confirmed that the listed topics cover
    the main points and that they are open to collaboration, though
    consensus on all points is not guaranteed.]

    [Discussion on PEPC Button Longevity and Geolocation: youenn
    fablet raised a question about the expected lifespan of the
    PEPC button for geolocation, noting that the design being
    pushed for microphone and camera permissions suggests a long
    duration. Mike West indicated that different capability
    controls can reasonably have different expected developer paths
    and that they are open to feedback on the decisions made for
    the geolocation version shipping in 144. The current design
    intent is for the geolocation button to remain on the page to
    provide control, for example, over location attachment to a
    search.]

    [Constraining APIs to Promote Better Developer Patterns: Mike
    West noted that making durable changes to the access level
    associated with a button would be difficult as long as the API
    exists. They suggested a collaborative effort to find good
    patterns for developers and then collaborate on ways to
    constrain the APIs to help developers find those agreed-upon
    patterns. The PEPC discussions for the day concluded, and Mike
    West excused themself from the remainder of the meeting.]

    Need further discussion on MVP scope and long term goal

    RESOLUTION: Continue camera/microphone button design
    discussions between WebRTC WG and PEPC, open to all WG members,
    slot will be webrtc editor’s meeting.

   [25]RTC prefix

      [25] https://github.com/w3c/webrtc-encoded-transform/pull/291

    RESOLUTION: Move on with a PR for adding RTC prefix.

   [26]dropped frame counter for MSTP

      [26] https://github.com/w3c/mediacapture-transform/issues/122

    RESOLUTION: Consensus on ready for PR. Might need further
    technical discussion/design on whether to allow the stat to
    identify when frames were dropped (how many frames are dropped
    between two video frames exposed).

Summary of resolutions

     1. [27]Continue camera/microphone button design discussions
        between WebRTC WG and PEPC, open to all WG members, slot
        will be webrtc editor’s meeting.
     2. [28]Move on with a PR for adding RTC prefix.
     3. [29]Consensus on ready for PR. Might need further technical
        discussion/design on whether to allow the stat to identify
        when frames were dropped (how many frames are dropped
        between two video frames exposed).

Received on Tuesday, 27 January 2026 10:12:04 UTC