Re: [AVTCORE] [MMUSIC] SDP Directorate review: draft-ietf-avtcore-cryptex

[Christer Holmberg <[e-mail]>]

Hi,

... 

Q4:

>> Section 4 says:
>>
>>   "If BUNDLE is in use and the a=cryptex attribute is present for a
>>   media line, it MUST be present for all media lines belonging to the
>>   same bundle group.  This ensures that the encrypted MID header
>>   extensions used to demux BUNDLE can be processed correctly.  When
>>   used with BUNDLE, this attribute is assigned to the TRANSPORT
>>   category [RFC8859]."
>>
>> First, as the usage of Cryptex is optional, why mandate it on all media lines? Could you explain the MID header processing justficiation?
>
> If ssrc info is not exchanged in the SDP O/A, then the only way to assign a packet to an m-line is by the mid value which is encrypted if cryptex is in use. So if the peer signals that it supports receiving cryptex in one m-line, it must support it on all of them.
 
Sure, but if you only indicate cryptex support for m- line X, then the peer is only allowed to use cryptex for the RTP packets associated with X. 

But, the peer is not allowed to use cryptex for RTP packets associated with m- line Y. 

But, in general I think it would be good to add some more text on the BUNDLE impacts, e.g., that intermediary nodes might not be able to distinguish/process bundled media if the MID is encrypted.

For example, in some networks there are intermediaries that "un-BUNDLE" media into individual 5-tuples, and that won't work unless such nodes have access to the MIDs.

>Second, if mandated on all media lines, it will apply also to non-RTP media lines (e.g., a WebRTC data channel), and then I think you need to have some explicit text about that.
>
>What would be the best term for a "media m-line"?
>
>- media m-line
>- media m line
>- media "m=" line

My suggestion would be to say "m- lines for RTP transported media", or something like that, because technically you could transport media also using non-RTP mechanisms.

Regards,

Christer