tree 09ac2dce4b3532cf7a3e3a41a018c6298b5cbe74
parent 84ba1643c28341bc6282bd853b9e8cb6c7fe3091
author Lennart Grahl <lennart.grahl@gmail.com> 1617998706 +0200
committer Commit Bot <commit-bot@chromium.org> 1618390425 +0000

Fix RTP header extension encryption

Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.

In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.

Further changes:

- If RTP header encryption enabled, prefer encrypted extensions over
  non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
  is not supported for that extension

Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.

Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}