Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

["GUBALLA, JENS (JENS)" <[e-mail]>]

Hi,

[...]
> Another big question how would current browser implementations handle a DTLS
> connection without "use_srtp" extension. I have a strong suspicion that DTLS
> session setup will fail without this extension present. I think, WebRTC
> enabled browsers currently export SRTP key material during session setup 
> even
> if no SRTP traffic is ever sent or received by this connection and fail the
> entire connection if key export fails. This, most likely, can be modified to
> only export SRTP key material when SRTP session is actually created and
> defining some sort of fall back procedure when a media track is actually 
> added
> to a connection without "use_srtp" (either failure or require renegotiation
> with new transport).
>
> To conclude, the group can either decide that all DTLS sessions in bundle
> should be setup with "use_srtp" extension and keep the current 
> implementations
> working as they are currently coded, or allow not to include this extension
> and fix the implementations.
[JG] I see the following potential inter-op issues between DTLS 
implementations
when relying on renegotiation:
  - Support for renegotiation is optional (RFC5246, D.4: "While renegotiation
    is an optional feature, supporting it is highly recommended."), on the
    other hand adding support for SRTP to an existing DTLS connection will
    require renegotiation.
  - Even if renegotiation would be used to add SRTP support: The initial DTLS
    session s1 has been negotiated without "use_srtp". For the renegotiation,
    would it be allowed to resume DTLS session s1, but now adding "use_srtp"?
    Even if that would be allowed from the standards (I am not quite sure 
here),
    would that be supported by implementations? If not, a full handshake would
    be required and a new DTLS session s2 would be negotiated.

Best regards,
Jens
> _____________
> Roman Shpount
>