Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
Christer Holmberg <christer.holmberg@ericsson.com> Mon, 28 August 2017 07:10 UTC
Return-Path: <christer.holmberg@ericsson.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 7C87A132C60 for <mmusic@ietfa.amsl.com>; Mon, 28 Aug 2017 00:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ZZQVHzNo23oe for <mmusic@ietfa.amsl.com>; Mon, 28 Aug 2017 00:10:42 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D82D132C5F for <mmusic@ietf.org>; Mon, 28 Aug 2017 00:10:42 -0700 (PDT)
X-AuditID: c1b4fb3a-5ffff700000051a3-a2-59a3c1f094bd
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.B7.20899.0F1C3A95; Mon, 28 Aug 2017 09:10:40 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Mon, 28 Aug 2017 09:10:39 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Taylor Brandstetter <deadbeef@google.com>, Adam Roach <adam@nostrum.com>
CC: "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] DTLS-SDP and JSEP Conflicts
Thread-Index: AQHTHeD9eWXjhOvP60up2QfAnU62xaKVd/KAgAATAICAAAn9AIAAAXqAgAABDACAA9hHAA==
Date: Mon, 28 Aug 2017 07:10:39 +0000
Message-ID: <D5C99C71.205D6%christer.holmberg@ericsson.com>
References: <f353ad39-4ee5-4661-8e99-7fab6e394e91@nostrum.com> <CAD5OKxu3HCThdqTjJ=jz_ZsceX0bVXW+FoRWsEB-N-nbmjEC4g@mail.gmail.com> <3be5cdc3-b191-d3be-4097-2b17d5a78b7c@nostrum.com> <CAD5OKxtqJGYZJwiS=w1M+qRenoxqi7gDX3K6Tc-dMPXB_E3-Tw@mail.gmail.com> <cb7405da-5907-e600-c62b-c57531b36b00@nostrum.com> <CAK35n0YwXhaGcwRcrSO+_LGtSv_EzVcN6u85oF77KiSWWe23ag@mail.gmail.com>
In-Reply-To: <CAK35n0YwXhaGcwRcrSO+_LGtSv_EzVcN6u85oF77KiSWWe23ag@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3B8B4813428CEB4CB0A72701F6DFEF5B@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7ou6Hg4sjDTq+yljs+buI3eLyioes FlOXP2ZxYPZYsKnUY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK6D9zi7XgvFzFtIZe5gbG oxJdjJwcEgImEnOnLmLpYuTiEBI4wihx+eFEZghnCaPE4WPXmboYOTjYBCwkuv9pgzSICPhI rLx3BCzMLKAucXVxEIgpLGAoceIMC0SFkcTl4w+YIewwiV33Z4DFWQRUJc5cPsoKYvMKWEtM 7fvBBrHpL5NE29v9YEWcAoESc3tngxUxCohJfD+1hgnEZhYQl7j1ZD4TxM0CEkv2nGeGsEUl Xj7+xwpyg6iAnsS7/Z4QYSWJHxsusUC06kncmDqFDcK2ltj8ZgrUSG2JZQtfM0PcIyhxcuYT lgmM4rOQbJuFpH0WkvZZSNpnIWlfwMi6ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw+g5u +W21g/Hgc8dDjAIcjEo8vBprFkcKsSaWFVfmHmKU4GBWEuG13Q8U4k1JrKxKLcqPLyrNSS0+ xCjNwaIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgTH73s/w+dt/fNavnnFb9s7p9wXrPwuJ Sz008owp2c+r+yjga87ydz0r8su+WE3coXvK/WV3+flVcYxnXryIU/ToNdsaoCbW2nm4i9Ek 7O5Jnk2W3oUCWzYnBH6r3dL9zUbimp50tPKX0o037Hc+U92962v1929NRerLZbIq237vnDn1 2v1npfZKLMUZiYZazEXFiQDwlM75ugIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/WVVFKy_vbdEJ5zGfXe_Vzaw8R0s>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Aug 2017 07:10:44 -0000
Hi, So, does anyone *OBJECT* to the remove-ufrag-from-section-4 proposal? I assume Justin and Cullen would be ok with it, since it is what JSEP does, but it would still be nice to hear them say that :) I assume we could still keep section 3.3, but we should remove the ³(see Section 4)² part. Because, section 3.3 does not say that a ufrag change triggers a new DTLS association, it simply says that if one changes the ufrag AND wants to create a new DTLS association, the tls-id must be changed. We could also clarify section 3.3: "If an endpoint uses ICE, and modifies a local ufrag value, and if the modification requires a new DTLS association, the endpoint MUST change its local SDP 'tls-id' attribute value, <new> as a modification of the local ufrag value does not itself trigger a new DTLS association </new>" Regards, Christer From: mmusic <mmusic-bounces@ietf.org> on behalf of Taylor Brandstetter <deadbeef@google.com> Date: Saturday 26 August 2017 at 02:32 To: "adam@nostrum.com" <adam@nostrum.com> Cc: "mmusic@ietf.org" <mmusic@ietf.org> Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts I think I'm just echoing Roman at this point, but might as well send the email since I already wrote it. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to restart? The primary rationale outlined in RFC5245 for restarting ICE is changing the destination (IP address or port) of an ongoing media stream -- which would commonly involve changing to a different physical device. The purpose of section 4 is to describe what should happen for an "existing implementation that has not been updated to support the 'tls-id' attribute", correct? And existing WebRTC implementations do not create a new DTLS association upon ICE restarts. In my experience, ICE restarts are mostly used to restore connectivity when network interfaces change, not to transfer a call to a new endpoint. So I'd say the "ICE ufrag value" bullet in section 4 should be removed. I hate to throw new engineering into the document at this point, but shouldn't it be possible to distinguish between these two circumstances by examining the candidates and determining whether they're completely new (versus having at least one in common with the existing connection)? This means that you won't know whether to restart DTLS until trickling has ended (for trickle), but you can solve that by not doing aggressive (or passive-aggressive) nomination -- just wait until you have all the candidates before you start connecting. Does that sound like it would work? If I understand correctly, you're saying "wait until trickling has ended, and use a new DTLS association if the list of candidates is completely new, and old association if it contains an old candidate"? That doesn't work for a couple reasons: 1. The list may be completely new, but the endpoint may still want to use the existing DTLS association. This is what existing WebRTC implementations do. They continue sending media over the old candidate pair while they're doing an ICE restart, but they don't trickle the old candidate again. 2. It could take a long time to tell that trickling ended, which would delay media. It would defeat a large part of the benefit of trickle ICE. On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach <adam@nostrum.com> wrote: On 8/25/17 6:23 PM, Roman Shpount wrote: More importantly this is not how existing implementations work. They simply do not start new DTLS association on ufrag change. This is for legacy interop only, so we might as well do what legacy end points do and ignore ufrag. This seems pretty compelling, as arguments go. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Taylor Brandstetter
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Adam Roach
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Bernard Aboba
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Paul Kyzivat
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Eric Rescorla
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Roman Shpount
- Re: [MMUSIC] DTLS-SDP and JSEP Conflicts Christer Holmberg