- From: Philipp Hancke via GitHub <noreply@w3.org>
- Date: Sun, 19 Apr 2026 07:01:15 +0000
- To: public-webrtc-logs@w3.org
> Mozilla has been pushing for WebRTC in [Interop 2024 and Interop 2025](https://github.com/web-platform-tests/interop/issues?q=is%3Aissue%20webrtc%20author%3Ajgraham), but vendor agreement is needed. 2024: despite E2EE being a focus both Firefox and [Safari](https://github.com/WebKit/WebKit/commit/275cc71ab49a9e77631f34a8c7c2bdd5fd1b4695) missed mimeType, requiring developers to painfully transfer SDP to workers and [parse it to create a payload type -> codec map](https://github.com/livekit/client-sdk-js/blob/e9babb197fb76faae0f1431f9a4c32749758de80/src/e2ee/worker/FrameCryptor.ts) 2025: transferable datachannels in Chromium had already shipped in [Chrome (because actual users asked) in 2024](https://groups.google.com/a/chromium.org/g/blink-dev/c/8CZbYcvQJAY/m/BIiCgLNmAQAJ). But yes, in that light pushing Chrome to fix the remote track label seems like an "appropriate goal" to take on. > The interop problem is users expecting to correlate remote track IDs with local ones. Can you provide pointers for users still doing that? This is https://github.com/w3c/webrtc-pc/issues/1128 from 2017 where the conclusion by everyone I know (including Twilio who had to change their SDK) was that you can not rely on remote track ids to match the local ones and if you correlate it must be on stream id. libWebRTC ended up somewhere in the middle by taking the remote track id unless there is a conflict but again, please provide pointers that this is an actual interop problem. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3100#issuecomment-4275386421 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 19 April 2026 07:01:16 UTC