[rtcweb] Proposal to break the ICE impasse

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

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DC0C21313A4 for <rtcweb@ietfa.amsl.com>; Thu, 24 Jan 2019 11:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Yrelu5aVO94U for <rtcweb@ietfa.amsl.com>; Thu, 24 Jan 2019 11:12:16 -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 46B5D1313A3 for <rtcweb@ietf.org>; Thu, 24 Jan 2019 11:12:16 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0OJCDiu061426 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <rtcweb@ietf.org>; Thu, 24 Jan 2019 13:12:15 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1548357135; bh=2viefE1rMVVFVFw/BeREflV2Mz/98EekDHfP3bVcKfU=; h=To:From:Subject:Date; b=ES20z8rg5BHkrKyY7QziY6yT89+EeLs94IkxDH2DdpBpU/enXCWeb0tZPLOD6w81M 3GBaofAYSl+uiZVi8EMvTeSY89ZSMgKi8534s9wkH+VJUME870XEJf7LuwAdm/+sm3 aw1dO8a40AAzYjYmw4SgWcyNsWhCZ/waejILmpJk=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [] claimed to be Svantevit.local
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com>
Date: Thu, 24 Jan 2019 13:12:08 -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
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/-88DBrw4_mJomHHlx3MdhyhdWUQ>
Subject: [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 19:12:18 -0000

Based on conversations in MMUSIC, as well as several offline 
conversations with interested parties, I've put together a proposed 
change to JSEP that, if accepted, will allow publication of the Cluster 
238 documents to move forward.

Note that this new text has no impact on existing implementations (at 
least, as far as I am able to discern), which do not currently have the 
capability of producing media sections consisting of exclusively TCP 
candidates. From that perspective, the change makes existing 
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future 
compatibility between WebRTC implementations once they finalize TCP 
candidate handling (and candidate handling in general for mid-session 


The key insight here is that JSEP's use of ICE completely discards any 
meaning associated with the transport parameter, while SIP's use of ICE 
does not. The trivial change that I propose, which bears only on future 
WebRTC implementations -- that is, which has no as-built specification 
to point to -- allows JSEP to continue to ignore the value of the 
transport parameter, while specifying that it says the right thing for 
SIP implementations to function properly.