v143 · webrtc

WebRTC RTP header extension behavior change

Users of https://chromestatus.com/feature/5680189201711104 found that the API as specified was not ergonomic for subsequent offer/answer. The WG has adopted a revised behavior, merged to spec in https://github.com/w3c/webrtc-extensions/pull/238, that ensures that subsequent offer/answer does not permute the header extensions negotiated unless the user wants

concepts

  1. RTP Header Extension

    Real RTCPeerConnection: toggle which header extensions to negotiate, run two offer/answer rounds, and inspect what each round actually negotiates.

  2. L4S disable flow

    The bug that prompted the spec revision: an L4S implementation turns a header extension off, the second SDP round re-enables it. v143 makes the disable sticky.

  3. SDP diff tool

    Live RTCPeerConnection: tick six extension preferences, run two offer/answer rounds, watch both SDPs and the diff. The verdict box tells you whether your build implements the sticky-disable v143 behaviour.

  4. Extension Timeline

    A live loopback RTCPeerConnection offer SDP generation (with pre-filled fallback) shows an extmap parser with ID, direction, encrypted flag, and URI per extension. A four-step negotiation stepper (Offer → Answer → Negotiated → Active) with a timeline grid highlights the Chrome 143 behavior-change for each extension, and an offer-vs-answer diff panel shows exactly which lines changed.

why it shipped

During development of the L4S congestion control feature, which is the first time we've tried to use this API to turn off a feature, it was discovered that the current definition was very unergonomic for this case.

references