Re: [rtcweb] draft-ietf-rtcweb-rtp-usage-12 Client-to-Mixer Audio Level

[Justin Uberti <[e-mail]>]

On Wed, Mar 5, 2014 at 3:45 PM, Jonathan Lennox <[e-mail]> wrote:

>
>  On Mar 5, 2014, at 2:25 PM, Justin Uberti <[e-mail]> wrote:
>
>  So there are three things here:
> 1) MUST the implementation offer encrypted header extensions? (i.e.
> mandatory-to-implement)
> 2) MUST the implementation use encrypted header extensions? (i.e.
> mandatory-to-use)
> 3) MUST the implementation expose an API to control this? (i.e. no SDP
> munging needed)
>
>  I think we want yes for #1, no for #2, and #3 is potentially interesting
> but out of scope for 1.0.
> That gives encrypted headers for audio on by default, but remote parties
> can negotiate this off using RFC 6904 mechanisms.
>
>
>  Note that in 6904’s procedures, an offerer has to explicitly offer both
> encrypted and unencrypted versions of a header extension if it wants to
> allow the answerer to choose between them.
>
>  To support this use case, in RTCWeb terms, this would mean that a
> browser would a) have to offer both the encrypted and unencrypted versions
> of the header extension, and b) answer an offer that offered only the
> unencrypted header by agreeing to use it.
>

That is a good point, and implies that for any header extension that
recommends encryption (e.g. RFC 6464 for audio level), we have the
following choices:
a) Implementations MUST offer only the encrypted version, and MUST accept
only the encrypted version
b) Implementations MUST offer both the encrypted and unencrypted versions,
and MUST accept both

Of these, a) is the less complicated option.