1 of 40

W3C WebRTC

WG Meeting

July 15, 2025

8 AM - 10 AM

1

Chairs: Jan-Ivar Bruaroey

Youenn Fablet

Guido Urdaneta

2 of 40

W3C WG IPR Policy

2

3 of 40

Welcome!

  • Welcome to the July 2025 interim meeting of the W3C WebRTC WG�
  • Future meetings:
    • No meeting in August
    • September meeting date to be decided
    • October meeting date to be decided
    • TPAC 2025 is in November (WebRTC is Tuesday 11th & Thursday 13th)

3

4 of 40

About this Virtual Meeting

4

5 of 40

W3C Code of Conduct

  • This meeting operates under W3C Code of Ethics and Professional Conduct
  • We're all passionate about improving WebRTC and the Web, but let's all keep the conversations cordial and professional

5

6 of 40

Virtual Interim Meeting Tips

This session is (still) being recorded

  • Click to get into the speaker queue.
  • Click to get out of the speaker queue.
  • Please wait for microphone access to be granted before speaking.
  • If you jump the speaker queue, you will be muted.
  • Please use headphones when speaking to avoid echo.
  • Please state your full name before speaking.
  • Poll mechanism may be used to gauge the “sense of the room”.

6

7 of 40

Understanding Document Status

  • Hosting within the W3C repo does not imply adoption by the WG.
    • WG adoption requires a Call for Adoption (CfA) on the mailing list.
  • Editor’s drafts do not represent WG consensus.
    • WG drafts do imply consensus, once they’re confirmed by a Call for Consensus (CfC) on the mailing list.
    • Possible to merge PRs that may lack consensus, if a note is attached indicating controversy.

7

8 of 40

Issues for Discussion Today

  • 08:10 - 08:25 AM Header extensions (Harald)
  • 08:25 - 09:00 AM RtpTransport (Peter)
  • 09:00 - 09:30 AM DataChannel Transfer (Jan-Ivar)
  • 09:30 - 09:55 AM Grab Bag (Jan-Ivar)
  • 09:55 - 10:00 AM Wrapup and Next Steps (Chairs)

Time control:

  • A warning will be given 2 minutes before time is up.
  • Once time has elapsed we will move on to the next item.

8

9 of 40

Header Extension Control to MainSpec

Start Time: 08:10 AM

End Time: 08:25 AM

9

10 of 40

  • RTP Header Extension control has been deployed in Chrome for a while
  • There’s an implementation, there’s positive signals from other vendors, it satisfies the criteria for inclusion (as a Proposed Amendment).

10

11 of 40

But really - Why?

The language in the spec around header extensions exposed on senders and receivers is unclear (#3056).

It should be defined in terms of internal slots, but this should be based on [[NegotiatedHeaderExtensions]] from the control spec (in webrtc-extensions)

Moving the control spec to the main spec is the easiest way to get to reference them.

11

12 of 40

Discussion (End Time: 08:25)

12

13 of 40

RtpTransport (Peter)

Start Time: 08:25 AM

End Time: 09:00 AM

13

14 of 40

Reminder about goals

  • Custom payloads, packetization, metadata FEC, RTX, …
  • Custom jitter buffers
  • Custom congestion control, rate control
  • Forwarding
  • The developer will never have to come back to the browser vendor again

15 of 40

Progress so far: Piecemeal RtpTransport

  • Good progress on specs/docs
  • But turns out that the implementation is… complex

16 of 40

New Proposal: SimpleRtcTransport

  • Like PeerConnection
    • Real-time
    • P2p
    • Encrypted
    • Consent-checked
  • Unlike PeerConnection
    • Packet-based
    • Developer can control the contents of the packet
    • Developer can control pacing/bwe (with some "circuit breaker")
    • No SDP (guardrails)

17 of 40

What we lose (vs Piecemeal RtpTransport)

The transition from PeerConnection to SimpleRtcTransport is hard

18 of 40

Making the transition easier

In the spirit of webrtc-samples,

We will write example apps of how to use SimpleRtcTransport, as replacement for PeerConnection

From there, the developer change everything.

Your imagination is the limit.

19 of 40

Future conversation

Web Developer: I need PeerConnection to do X

Browser Vender: You can do that with SimpleRtcTransport

Web Developer: It looks hard moving from PeerConnection to SimpleTransport

Browser Vendor: Try this example app

Web Developer: Oh, that does everything I need to transition, and gives me all of the control I need to do X.

Browser Vender (quietly): I'm glad I didn't have to discuss this in the WebRTC WG for 3 years.

20 of 40

What network protocol?

  • The API should be agnostic to the protocol
  • We can start with simplified ICE+SRTP
  • And later use QUIC
  • Or come up with something else (ask Peter for details)

21 of 40

What kind of API (Send and Receive Packets)?

const transport = new SimpleRtcTransport()

const remoteParameters = await doCustomSignalingSwap(transport.localParameters);

// … TODO: some p2p ICE-candidate-like exchange …

await transport.connect(remoteParameters);

transport.sendPacket(customPayload);

const receivedPackets = [new SimpleRtcTransportReceivedPacket(), …];

transport.onpacketsreceived = () => {

transport.readReceivedPackets(receivedPackets);

// … handle packet.payload for each packet

};

22 of 40

What kind of API (Custom Pacing and BWE)?

// … Same setup as before

const estimator = createCustomBandwidthEstimator();

const pacer = createCustomPacer();

transport.onreceivedfeedback = () => {

for (const ack in transport.readAcks()) {

estimator.processReceivedAcks(rtpAck);

}

// … use new BWE to control send rate (or use transport.bwe)

};

const [customPayload, sendTime] = await pacer.dequeue();

const sent = transport.sendPacket(customPayload, {sendTime});

pacer.handleSent(sent)

23 of 40

Questions for WebRTC WG

  • Should we pursue SimpleRtcTransport?
  • If so, should SimpleRtcTransport be done within the WebRTC WG?
  • If so, should it use ICE+SRTP, QUIC, or something new?

24 of 40

Discussion (End Time: 09:00)

24

25 of 40

DataChannel Transfer (Jan-Ivar)

Start Time: 09:00 AM

End Time: 09:30 AM

25

26 of 40

DataChannel transfer issues

  • webrtc-pc
    • Issue 3063: Data channels in workers get initialized on wrong thread
    • Issue 3062: Prevent GC of non-closed RTCDataChannels in workers
    • Issue 3058: Avoid losing data channel events during transfer

26

27 of 40

Issue 3063: Data channels in workers get initialized on wrong thread

When SCTP connects, it queues a main-thread task to fire statechange with ALL* datachannel IDs initialized… (*but what about ones in workers?) Fiddle:

const channel = pc.createDataChannel("");

worker.postMessage({channel}, [channel]);

await pc.setLocalDescription();

pc.sctp.onstatechange =

() => console.log(channel.id); // 1 in Chrome, null in Safari

await remainingNegotiation(pc);�

// worker.js

onmessage = ({data: {channel}}) => {

console.log(channel.id); // 1 in Chrome, null in Safari

channel.onopen = () => console.log(channel.id); // 1 in both

};

Proposal: align with Safari

27

28 of 40

Issue 3062: Prevent GC of non-closed RTCDataChannels in workers

connection.[[DataChannels]] holds a strong reference to all (main-thread) data channels.

Proposal: extend this to workers somehow

Workers have their own GC, so maybe something like

  • "After transfer, user agents MUST keep a strong reference from the Window or WorkerGlobalScope object that the RTCDataChannel object's constructor was invoked from to that RTCDataChannel object for as long as the original detached object that was the source of its transfer is kept alive"�
  • Note: This allows connection.[[DataChannels]]�to keep data channels in workers alive.

28

29 of 40

Issue 3058: Avoid losing data channel events during transfer

Can it happen? The create an RTCDataChannel algorithm ends with this prose:

Inherently racy createDataChannel("seven", {negotiated: true, id: 7});

29

30 of 40

Title Goes Here

  • Content goes here

30

31 of 40

Discussion (End Time: 09:30)

31

32 of 40

Grab bag (Jan-Ivar)

Start Time: 09:30 AM

End Time: 09:55 AM

32

33 of 40

Grab bag for discussion today

  • webrtc-pc
    • Issue 3052: RTCPeerConnectionIceErrorEvent should not expose STUN reason phrase to JS
    • Issue 3064: RTCError constructor fails the copy constructor pattern�
  • webrtc-stats
    • Issue 800: Can we delete webrtc-provisional-stats spec?

33

34 of 40

Issue 3052: RTCPeerConnectionIceErrorEvent should not expose STUN reason phrase to JS

errorText exposes unauthenticated packet from the network to Javascript

Proposal:

change errorText

to anything BUT

the STUN reason,

or remove it?

34

35 of 40

Issue 3064 / PR 3066: RTCError constructor fails the copy constructor pattern

const err = new RTCError({errorDetail: "data-channel-failure"}, "foo");

const cpy = new RTCError(err, err.message);�

assert_equals(cpy.sdpLineNumber, err.sdpLineNumber); // Expected null, got 0

Easily fixed in

dictionary RTCErrorInit {

35

36 of 40

Issue 800: Can we delete webrtc-provisional-stats spec?

36

37 of 40

Discussion (End Time: 09:55)

37

38 of 40

Wrapup and Next Steps

Start Time: 09:55 AM

End Time: 10:00 AM

38

39 of 40

Next Steps

  • Content goes here

39

40 of 40

Thank you

Special thanks to:

WG Participants, Editors & Chairs

40