Re: [rtcweb] Proposal to break the ICE impasse

Adam Roach <adam@nostrum.com> Thu, 24 January 2019 21:02 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58E9128CE4 for <rtcweb@ietfa.amsl.com>; Thu, 24 Jan 2019 13:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 cwQG7VdKChhP for <rtcweb@ietfa.amsl.com>; Thu, 24 Jan 2019 13:02:09 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8A4CF12875B for <rtcweb@ietf.org>; Thu, 24 Jan 2019 13:02:09 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OL26L2079637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 24 Jan 2019 15:02:08 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548363729; bh=S9CKrsmuW5xa3fGhFQ1Y6lS4Hx4kQ6oNJ0QSQBornAs=; h=From:Subject:To:References:Date:In-Reply-To; b=fycLZpbOc9ZqBEd4jS06YWxVyUWzFIH/ehX2gGk+JfEM0RI/K0+nrOtTnBtIV8OBm w/7i2a1aNsmJD6Uvrlf0LBk7TonpebVj2Aws20+IWmYsoExLHnA/0EF/6yOY16CkdY 7rLaq+nGRqxLo85sXAsBzV2Mm1vb2RE1ESnqpX1Y=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
From: Adam Roach <adam@nostrum.com>
To: Roman Shpount <roman@telurix.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <CAD5OKxserd+XKm-6a1kCZ1tMbm4imF+OasgO7CHXgoF-gmFTsA@mail.gmail.com>
Message-ID: <8a06e138-964a-251d-43bf-7eee3a2e67dc@nostrum.com>
Date: Thu, 24 Jan 2019 15:02:01 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <CAD5OKxserd+XKm-6a1kCZ1tMbm4imF+OasgO7CHXgoF-gmFTsA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/ORkSUdAuWpTNyMFnsS_GqwK_VTg>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2019 21:02:11 -0000

On 1/24/19 1:39 PM, Roman Shpount wrote:
> Would you prefer to reply to you directly with my comments or as a 
> comment on the Github?


Here for discussion, there for specific text change proposals.


>
> The text you are proposing is slightly ambiguous due to trickle-ice. 
> Theoretically, during trickle ICE candidate collection SDP might 
> contain only TCP candidates but UDP candidates can be added at some 
> point in the future. Based on the proposed text proto will start of as 
> TCP/DTLS/RTP/SAVP and then change when UDP candidates are collected.


I don't think that's true -- the way JSEP specifies trickle ice, offers 
for trickle ice will always start with zero candidates, and so the 
trickling will always use UDP/DTLS/RTP/SAVPF from the start.


> Also, for consistency, the next paragraph, which is talking about 
> UDP/DTLS/SCTP should be updated as well to use TCP/DTLS/SCTP when 
> offer does not initiate ICE restart and only TCP candidates are present.


I'm okay if we require applications that use WebRTC data channels to 
have to do things the WebRTC way.

/a