Open
Bug 1648467
Opened 6 years ago
Support RTP header extension encryption
Categories
(Core :: WebRTC: Signaling, enhancement)
Core
WebRTC: Signaling
Tracking
()
NEW
People
(Reporter: lgrahl, Unassigned)
Details
I propose to fully commit to the encryption aspiration of WebRTC and encrypt all RTP header extensions, too. :)
libwebrtc supports RTP header extension for a while now (even though it's mostly unused and is currently buggy - there's a CL to fix it).
Basically, it requires adding support for RFC 6904 in the signalling stack. The way it works in libwebrtc (with the above linked patch) is this:
- Add each header extension twice (one as usual, one encrypted) to the SDP. Note that they need separate IDs of course.
- When answering, if an encrypted variant of a header extension is found, it is being preferred over the plain-text variant (independent of the ordering in the SDP).
I'm not entirely sure if this is defined by a specific standard but it seems like a moderately sane way to do it. Furthermore, for interop, we still need to convince the Chromium folks to enable it in the browser. Right now, it's only available in libwebrtc but not in Chromium itself.
You need to log in
before you can comment on or make changes to this bug.
Description
•