commit 0d0ed76ac133cd9006c8a0266306f0c687f40024
author Lennart Grahl <lennart.grahl@gmail.com> Mon May 17 14:06:37 2021
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed May 26 09:42:09 2021
tree 9c09b232eccc76ab18318f2cb020110bcb9db8ce
parent 4a54be71188f63a1648004b8002cd9658cd67954

Fix RTP header extension encryption

Reland of commit a743303211b89bbcf4cea438ee797bbbc7b59e80

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
- Mark FindHeaderExtensionByUri without filter argument as deprecated

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