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

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

Hi Christer!

Thank you for your review, Bernard already has opened an issue to track the
resolution of the points raised:

https://github.com/juberti/cryptex/issues/52

Some answers below

On Fri, Jun 10, 2022 at 3:16 PM Christer Holmberg <christer.holmberg=
[e-mail]> wrote:

> Q1:
>
> I suggest to change the Section 4 name from "Signaling" to "SDP
> Considerations", "SDP cryptex attrbute", or something like that.
>

Changed.

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.


>
> 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



> ---
>
> Q6:
>
> I suggest to rename Section 9.1 to "SDP cryptex Attribute".
>
> ---
>
> Changed.

Best regards
Sergio