demo · v143 · webrtc
RTP header extension timeline
Create a real loopback RTCPeerConnection and watch its SDP evolve from offer → negotiated → active. Parse any SDP to extract a=extmap: lines, see which extensions Chrome 143's behavior change affects, compare offer vs answer, and explore the common extension dictionary.
1 — Loopback RTCPeerConnection
Creates a real audio+video loopback to generate authentic SDP with real extension maps. The media is immediately discarded — this is just to show the SDP.
Extracted a=extmap lines
| ID | Direction | Encrypted | URI | v143 affected? |
|---|
2 — Negotiation timeline
Step through the signaling flow. Each step reveals how extensions transition from offered to negotiated to active in the RTP session.
3 — Chrome 143 behavior change
What changed in Chrome 143
Prior to Chrome 143, encrypted RTP header extensions (negotiated via a=extmap-allow-mixed or per-extension encryption) could be inadvertently negotiated or applied to media sections where they were not explicitly offered. Chrome 143 tightens this: extensions are only forwarded in the negotiated set if they appear in both offer and answer. This is a correctness fix aligned with RFC 6904 and can affect peers that rely on the old implicit extension inheritance behavior.
4 — Compare offer vs answer
Offer extmap lines
Paste SDP and click Parse above.
Answer extmap lines (simulated)
Paste SDP and click Parse above.