Re: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use]

Hi Harald,

Thanks for the link.  From JSEP proposal section, I understand that Jingle has different signaling mechanism than SIP and the exact text is as follows:

“In protocols that decouple session descriptions from transport, such as Jingle, the transport information can be sent separately; in protocols that don't, such as SIP, the information can be easily aggregated and recombined. Sending transport information separately can allow for faster ICE and DTLS startup, since the necessary roundtrips can occur while waiting for the remote side to accept the session.”

I’ll go through this mechanism in detail and provide further comments.

Thanks
Partha

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Thursday, January 12, 2012 2:49 PM
To: Ravindran, Parthasarathi
Cc: Justin Uberti; rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use]

On 01/12/2012 02:05 AM, Ravindran, Parthasarathi wrote:
Hi Justin,

Sorry,  I have trouble in accessing JSEP draft at IETF RTCWeb site (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any draft. Could you please forward me JSEP draft to see how DTLS keys are negotiated in JSEP proposal even  before the answer is received from the remote WebRTC client.

A copy of the JSEP proposal is archived in the W3C WebRTC archives:

http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0002.html

It has not yet been submitted as an internet-draft; indeed, one of the things we have to decide is whether it should be an internet-draft or a part of the W3C API spec.

Thanks
Partha

From: rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Thursday, January 12, 2012 4:48 AM
To: Roman Shpount
Cc: Randell Jesup; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Subject: Re: [rtcweb] SRTP not mandatory-to-use

On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <randell-ietf@jesup.org<mailto:randell-ietf@jesup.org>> wrote:

I'd like to explore the possibility of making sure there's a workable DTLS-SRTP implementation openly available, and locking WebRTC down to that only.

I should note that while libsrtp 1.4.2 (last official release) doesn't have DTLS-SRTP support, there are DTLS-SRTP support functions and test code in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS support already.

Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP?

The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation?

When used with JSEP, DTLS should not require any additional roundtrips for connection setup, since DTLS can be brought up as part of transport establishment. In fact, connection setup should occur faster than when using SDES, since the keys can be negotiated before the answer arrives. This prevents clipping of the answerer's media from occurring.

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org<mailto:rtcweb@ietf.org>

https://www.ietf.org/mailman/listinfo/rtcweb