Re: [MMUSIC] Query: Usage of enrypted vs unencrypted RTP extensions

As far as I know this is for exclusively backwards compatibility with
endpoints that do not implement encrypted RTP extensions or cases of best
effort SRTP ( https://tools.ietf.org/html/rfc6904#section-4.1). The
specification already says that both encrypted and unencrypted RTP
extensions should only be offered if it is unclear if remote supports
encrypted extensions, and MUST not be offered otherwise. There are
definitely some valid use cases for offering both encrypted and
un-encrypted audio level extensions if mixer capabilities are not known in
advance.
_____________
Roman Shpount

On Fri, Feb 21, 2020 at 8:28 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

> I recently encountered an interesting piece of code with regard to
> encrypted RTP header extensions.
>
> It seemed to say that "if you enable encryption, every header extension
> will be offered in an encrypted and unencrypted variant, and the
> answerer can choose which ones to use".
>
> 1) does anyone want that?
>
> 2) does anyone depend on that?
>
> It would seem more logical that the initiator of a call would have a
> strong opinion on whether encryption should be on or off, and only the
> version preferred should be offered.
>
> This also saves some numbers, in case one wants to use 1-byte header
> extension numbering.
>
> The context it came up in may end up in designing an API for controlling
> header extension encryption in WebRTC - so it's important to cover the
> use cases that are, in fact, in use.
>
> Inquiring minds want to know....
>
>
> Harald
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>