Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt

[Jonathan Lennox <[e-mail]>]

The intention is that from the point of view of an answerer that doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is just another unknown header extension element URI, so it will negotiate not to use it using the standard RFC 5285 mechanisms.

It's thus also possible to offer encrypted and non-encrypted versions of the same header extension element, if that's acceptable for security reasons.

I can add some explicit text explaining this in the next revision of the draft.

On Jul 12, 2011, at 4:27 AM, Roni Even wrote:

> Hi,
> I read the draft, some comments:
> 
> 1. I think it needs an offer answer section. We need to specify the behavior
> when an offer to encrypt the header is sent and the answerer do not support
> the encryption header extension. Can alternatives, one with encryption and
> one without be offered. 
> 
> 2. Extmap can be a session level attribute. What about encryption, is it
> only a media level.
> 
> In general are the offer answer rules from RFC 5285 applicable here and how.
> 
> 
> Regards
> Roni Even
> 

--
Jonathan Lennox
[e-mail]