While implementing E2EE frame encryption for a P2P (non-SFU) application, I hit a cross-engine divergence.
Setup: one RTCPeerConnection per peer, a single sendrecv transceiver carrying both an encrypt transform on the sender and a decrypt transform on the receiver, via RTCRtpScriptTransform with one worker handling both directions. This is the pattern MDN documents as intended.
What I see in Chromium 151 (stable 151.0.7922.76 and the Playwright-bundled build): the receiver-side transform is silently ignored on sendrecv transceivers. onrtctransform fires with the receiver options, but the transform function is never invoked (0 calls), and media flows to the decoder untransformed. No error, no warning. On sendonly to recvonly the same code invokes the receive transform on every frame.
Safari 26.6 (WebKit 605.1.15), identical code, sendrecv topology: receive transform invoked on every frame, 238/238 decoded, 0 PLI, and a full encrypt/decrypt round trip works.
Repro, fully self-contained (canvas source so no camera permission, passthrough transforms that only count invocations, no crypto involved): https://gist.github.com/arnon-shub/ead3e262e94e8dc8a1e3271f32e8296e
One topology per page load, results shown on-page.
A possible reason this went unnoticed: as far as I can tell, the WPT webrtc-encoded-transform suite has no test combining a sender transform and a receiver transform on the same connection. All tests are unidirectional, and SFU-based products use sendonly/recvonly topologies, so P2P sendrecv applications may be the only ones hitting this path.
Two questions: is the Chromium behavior a known implementation gap, and would a WPT test for the bidirectional case be welcome? Happy to help shape one based on the repro.
For reference, a similar symptom class exists in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1969603
While implementing E2EE frame encryption for a P2P (non-SFU) application, I hit a cross-engine divergence.
Setup: one RTCPeerConnection per peer, a single sendrecv transceiver carrying both an encrypt transform on the sender and a decrypt transform on the receiver, via RTCRtpScriptTransform with one worker handling both directions. This is the pattern MDN documents as intended.
What I see in Chromium 151 (stable 151.0.7922.76 and the Playwright-bundled build): the receiver-side transform is silently ignored on sendrecv transceivers. onrtctransform fires with the receiver options, but the transform function is never invoked (0 calls), and media flows to the decoder untransformed. No error, no warning. On sendonly to recvonly the same code invokes the receive transform on every frame.
Safari 26.6 (WebKit 605.1.15), identical code, sendrecv topology: receive transform invoked on every frame, 238/238 decoded, 0 PLI, and a full encrypt/decrypt round trip works.
Repro, fully self-contained (canvas source so no camera permission, passthrough transforms that only count invocations, no crypto involved): https://gist.github.com/arnon-shub/ead3e262e94e8dc8a1e3271f32e8296e
One topology per page load, results shown on-page.
A possible reason this went unnoticed: as far as I can tell, the WPT webrtc-encoded-transform suite has no test combining a sender transform and a receiver transform on the same connection. All tests are unidirectional, and SFU-based products use sendonly/recvonly topologies, so P2P sendrecv applications may be the only ones hitting this path.
Two questions: is the Chromium behavior a known implementation gap, and would a WPT test for the bidirectional case be welcome? Happy to help shape one based on the repro.
For reference, a similar symptom class exists in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1969603