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

[Sergio Garcia Murillo <[e-mail]>]

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