demo · v143

L4S disable flow

The exact bug the v143 behaviour change fixes: a congestion-control feature (L4S) flips a header extension off via setHeaderExtensionsToNegotiate, then re-negotiates. Pre-v143 the renegotiation re-permutes; v143 preserves intent.

step 1

App calls sender.setHeaderExtensionsToNegotiate([{ uri: "abs-send-time", direction: "stopped" }, …]) to turn off L4S.

step 2

App triggers a second SDP offer/answer round (e.g. adding a track).

step 3 — the behaviour difference

pre-v143

second negotiation re-permutes the extension list.
abs-send-time is back to direction:"sendrecv".
L4S quietly re-enables — the disable was a one-shot.

v143

second negotiation preserves prior intent.
abs-send-time stays direction:"stopped" until app
explicitly opts it back in.

the call

const pc = new RTCPeerConnection();
const tr = pc.addTransceiver("video", { direction: "sendrecv" });

await tr.sender.setHeaderExtensionsToNegotiate([
  { uri: ".../transport-wide-cc-extensions-01",
    direction: "stopped" }
]);

// v143: this disable survives subsequent offer/answer rounds
// pre-v143: the next round reset it to sendrecv

why this angle

The other concept toggles extensions abstractly. This one walks through the exact L4S use case the WG identified — the bug that prompted the spec revision in webrtc-extensions PR #238.