Re: [MEDIACTRL] <encryption> support

["Roni Even" <[e-mail]>]

Hi,
I am not happy and would have liked to see also SDES maybe define two values
for the <encryption> element. Note that encryption is specified also in
other sections for the client and mixer so the definition should be
consistent.
The IMTC defined a security profile for video conference end points with
both SDES (used by current systems) and DTLS for new systems.
I will not object  to just having DTLS.
Roni

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Eric Burger
Sent: 13 December, 2012 11:55 PM
To: [e-mail]
Subject: [MEDIACTRL] <encryption> support

Section 5.1.5.21 of
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-mrb/ describes an
indicator, <encryption>, as to whether or not a Media Server supports SRTP.

We were thinking there could be some opaque string that would describe the
keying mechanism.  However, as numerous ADs have pointed out, there is no
IANA registry for such mechanisms.

I would offer we be pragmatic, and I would like to hear from manufacturers
principally but others with skin in the game. Specifically, what if we said
there is one and only one official, supported keying mechanism, namely
DTLS-SRTP?  While it is true that today most SIP SRTP implementations are
SDES, the user community is demanding a move to DTLS-SRTP and DTLS-SRTP will
also be the only keying mechanism for RTCWEB.

So, the proposed text would be:

5.1.5.21.  <encryption>

   The <encryption> element allows a Media Server to declare support for
   encrypting RTP media streams using RFC 3711 [RFC3711].  The element
   MAY be present.  If the element is present, then the Media Server
supports
   DTLS-SRTP [RFC 5763].

   The <encryption> element has no attributes.


Anyone want to see something different?