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

[tim panton <[e-mail]>]

On 5 Mar 2014, at 14:41, Cullen Jennings (fluffy) <[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)
> I’m fine with yes
> 
>> 2) MUST the implementation use encrypted header extensions? (i.e. mandatory-to-use)
> I think this needs to be No. Never mind my current use case - if the far end does not negotiate RFC 6094 with the browser, the media and headers should not fail. 
> 
>> 3) MUST the implementation expose an API to control this? (i.e. no SDP munging needed)
> I prefer control surfaces to SDP munging but as you say, I could live with SDP munging in 1.0 
> 
>> 
>> 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.
>> 
> 
> 
> seems workable 

For the record, I still don’t like the idea that the far end can bid-down encryption on this header, but I suppose if my app cares it will have to not offer to do that header extension at all. (Hopefully it is a malleable SDP field).

Tim.