Open Bug 1648467 Opened 6 years ago

Support RTP header extension encryption

Categories

(Core :: WebRTC: Signaling, enhancement)

enhancement

Tracking

()

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.