Re: [webrtc-extensions] RTP Header Extension Encryption (#47)

Since this is an extension, we need to consider what happens if the extension is not implemented at one end, and the extension is implemented but defaulted on the other end - also when there are middle boxes like SDP mungers that know / don't know about the extension.

In particular, the scenario:

- Application doesn't care
- Source and destination UAs implement a=cryptex
- Middle box (SFU, for instance) doesn't know about a=cryptex, passes all unknown SDP options blindly
- Middle box depends on reading RTP header extensions (like audio volume)

If the default is "negotiate", header extensions will be encrypted, and hidden from the SFU, despite neither app desiring to hide them.

I think the default (the interpretation when no configuration is given) needs to be "off", unfortunately.

GitHub Notification of comment by alvestrand
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Friday, 7 January 2022 10:26:59 UTC