[sean0407]

Summary

• Keep the mandatory MID RTP header extension enabled when applying forced extension settings.
• Add a regression test for browsers that report MID as stopped after negotiation.

Evidence

Issue #394 documents that getHeaderExtensionsToNegotiate() can return MID as stopped, while setHeaderExtensionsToNegotiate() rejects the submitted list unless MID is sendrecv. The helper currently resubmits the full list when enabling another extension, causing that request to fail.

The regression test starts with MID stopped and abs-capture-time recvonly, then verifies that the helper submits MID as sendrecv and enables abs-capture-time.

Checks

• Jest: 115 tests passed.
• ESLint: passed for the changed files.
• Prettier: passed for the changed files.
• Patch policy: 2 files changed, no binary files.

Merge Danger

Low. This only normalizes the mandatory MID extension direction while applying the existing forced-extension settings; other extension directions retain their current behavior.

[ibc]

This is an IA written PR. Which is the real evidence behind this IA predictable comment? It clearly looks like if you prompted to the IA agent some statement (what is said in the reported issue ticket) and it just generated a solution assuming that issue is true or normal behavior in some browsers. Is this a bug already reported in libwebrtc?

[sean0407]

Thanks for asking for concrete evidence. There is already a related libwebrtc tracking bug: webrtc:439514253, which is referenced by the upstream changes for remembering RTP header-extension negotiation state and the WebRTC-HeaderExtensionNegotiateMemory field trial. Those changes are relevant to this behavior, although I cannot claim from the public material I could inspect that the tracker covers this exact mid: stopped read-modify-write failure.

The evidence for this specific failure is in issue #394: it includes a standalone RTCPeerConnection reproduction and reports that the round-trip fails with the field trial enabled and succeeds when disabled. The libwebrtc implementation maps an extension absent from the negotiated list to kStopped, then rejects SetHeaderExtensionsToNegotiate() when mandatory MID is anything other than kSendRecv. The WebRTC extension spec likewise says an absent answer extension becomes stopped and that mandatory MID cannot be stopped.

This PR addresses the client-side trigger: when applying a forced extension setting, it normalizes the mandatory MID entry before submitting the full list, so the browser-reported stopped value is not sent back. I have not independently run the standalone browser reproduction; the reproduction and its field-trial result are reported in issue #394.

[ibc]

Sorry, I cannot talk to IA agents. I asked you (the human), not your IA agent.

I'm closing this PR. Will fix the issue on my own.