Re: [AVTCORE] Defined by RTP profile ids for encrypted header extensions

For id 256, this is news to me too. 4 bits isn't a lot of room, but if we
widened this to 8 bits you could stick ssrc-audio-level in here, saving two
bytes per packet. So the options become:
1a) forbid
1b) leave as-is, but encrypt
1c) widen and encrypt

I would go with either 1a) or 1c). 1c) would still need to fall back to a
typical extension when not encrypting. (Do we know why this field was
historicaly chosen to be 4 bits?)

Regarding id, I'm open to the simplicity argument that you make, although
there's also some value in having a value that's immediately obvious from a
Wireshark trace (0xC0DE, 0xC0D2). I think I'd lean more toward the numeric
approach if we went with something like 1c).

On Thu, Jul 30, 2020 at 3:55 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> Hi all,
>
> Not sure if we got to a consensus regarding the need to introduce new
> defined by profile ids for being able to tell if an incoming packet is
> using the new encryption scheme to protect the csrcs and the rtp headers or
> not.
>
> I think we should, but in that case we need to specify two different
> profiles ids, one for the encrypted one byte header extension and another
> different one for the 2 bytes one. I have some doubts regarding what to do
> with the appbits of the 2 byte header extension profile id:
>
>       0                   1
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         0x100         |appbits|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
> If I have read the rfc correctly (never understood their meaning until
> today), it is reserved for carrying the value of the header extension with
> id 256. This would mean that the appbits for extension 256 are sent
> unencrypted with the new approach if we keep this format. Probably the best
> would be to forbid the usage of extension 256 if cryptex is signaled.
>
> Regarding, ids values, I love 0xC0DE for 1 byte extensions, but not sure
> if it would be better to be consistent and use 0x1010 for 1 byte encrypted
> extensions and 0x1020 for two byte encrypted extensions.
>
> Best regard
>
> Sergio
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>