IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP

Roman Shpount <roman@telurix.com> Mon, 18 April 2016 15:00 UTC

Return-Path: <roman@telurix.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454612D8FA for <mmusic@ietfa.amsl.com>; Mon, 18 Apr 2016 08:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nT_ELRPdxCYq for <mmusic@ietfa.amsl.com>; Mon, 18 Apr 2016 07:59:58 -0700 (PDT)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674D312D7E5 for <mmusic@ietf.org>; Mon, 18 Apr 2016 07:59:58 -0700 (PDT)
Received: by mail-ig0-x233.google.com with SMTP id gy3so74956754igb.0 for <mmusic@ietf.org>; Mon, 18 Apr 2016 07:59:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=zxFIcrIyBwDTqUO8NSUocuMoS0Vf/IH3vUy6E/+ozeJ6MsxjK7t3PkyyKvvrjVZinC jE+pL97SnQ0fpGs46VMsSo5dQfPMeZvZUpeTqbNBZHvlnQWEHjJetLbOmXBSvQPZd9Wm MtC9hON9/IZgL22/ylvRX1/F3rmQMsiOU/FvFBxctbBKgyvOAuKb6TnSA4zaHSsU4K7p YZ7cNirOrsW9pqLUQkNpuDTT+0p37Z6fCWyukH9nKKKMTnOpMQFJL3mkBMLNehqDPQvw G54TYeYBCCymXIldPOWJvivHVZdw+tF+LS4Lm5to0E65MpL2qqjSL+wfqw1JCwF7qccG zAcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/2X85TYujLShjb8N9f4zk7/Wakys+Nwa6CAx2DBtLLY=; b=BJYRl3bioLXGqwITNGGHt7V5pQShcdD3we4gRLIiHoWnXDW3fXVrjKVSoFNWhLrW6i kRkudfGnNOOp1CJF/fVodomiRSRe38Fuk8Ehd2mwQHdr15NzoPXXNQ0vS8+SqhOETqpE t2jo0mp1YXo7RWdaVHD3sFoaoTdu695C/7pYu6SonASsjNQkGRsfcd0q6yc9ykWj24O+ UMZOhFqlNmgIWc2RLUEA29tvbYsbHwayhhmSvig2zg/bUAPpcIP9ZHplfJVMFC9dxaOD L+DfVQu4BX7+8DlWgyxHGJTmfjiSupsuubqIICHLsJHdFrc1Ii7Vs0ePKxShgBo2drox a13A==
X-Gm-Message-State: AOPr4FWUdd1aqUgK5ygQMozuET+vhIfSGbKtezTjYNs554gPtxx/XMuQVs5CGs8Lme05AQ==
X-Received: by 10.50.118.225 with SMTP id kp1mr20644844igb.9.1460991597612; Mon, 18 Apr 2016 07:59:57 -0700 (PDT)
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id ke5sm3660185igb.17.2016.04.18.07.59.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
Received: by mail-io0-f169.google.com with SMTP id g185so197162200ioa.2; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.160.141 with SMTP id j135mr42233717ioe.171.1460991596536; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
Received: by 10.36.144.69 with HTTP; Mon, 18 Apr 2016 07:59:56 -0700 (PDT)
In-Reply-To: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
References: <CABcZeBOM1KoXpXFhvjS753EVpsMENWVen3CCdFj8ry36vPH0dg@mail.gmail.com>
Date: Mon, 18 Apr 2016 10:59:56 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt2+YAJfR1q4qyhv_0D7AqMmrsTENTGNw-_vo9Dzr-ejA@mail.gmail.com>
Message-ID: <CAD5OKxt2+YAJfR1q4qyhv_0D7AqMmrsTENTGNw-_vo9Dzr-ejA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="001a1140a2b621b1a00530c39d18"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/5efr6gMqn3JPzAc3fLbBGtDax_8>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Tunnelling DTLS in SDP
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2016 15:00:00 -0000

On Mon, Apr 4, 2016 at 9:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> I wanted to call your attention to a draft I just published with a
> possibly stupid
> idea.
>
> https://tools.ietf.org/html/draft-rescorla-dtls-in-sdp-00
>
> A nontrivial fraction of call setup time in WebRTC is the DTLS handshake.
> This document describes how to piggyback the first few handshake messages
> in the SDP offer/answer exchange, thus reducing latency.
>
> Comments welcome.
>
>
One other issue I thought off was that with DTLS SDP either offerer or
answerer can start a new DTLS association. When answerer starts a new
session it will have exactly the same problems as forking, since this will
create multiple DTLS sessions with the same client random. This can be
solved with some sort of fallback mechanism to either regular DTLS setup or
to sending a ClientHello in the answer.

Regards,
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email