Re: [rtcweb] Proposal to break the ICE impasse

Ted Hardie <> Thu, 24 January 2019 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A57A12DDA3 for <>; Thu, 24 Jan 2019 12:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wR0F_sVxe4qf for <>; Thu, 24 Jan 2019 12:59:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D6D212875B for <>; Thu, 24 Jan 2019 12:59:05 -0800 (PST)
Received: by with SMTP id g16so2534832otg.11 for <>; Thu, 24 Jan 2019 12:59:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t8I5Ec0f9yGbWt01KnMJiW13THdX9MKlgvmWFFOUb5Y=; b=FSgVIM2qgakDwYuZmMuv20RG47XwjhYg2pep8edVgFgEZJs88crQUUD707of+E+6fa 2VBGzZRoIEdeBIgWWnM7YliDGys4dpTkWsM1rD7s2ONSaPHYG6xt4dVFLemQDuH05sI8 Wbkj/fAekmxugBKVz85orvGOFaOebYkWxjMyDR17E9fW46eHzzlBIqL1z9H/F6yDzIcz 1hd/6vqrozJ6NGgSxawqjJfi8U8nvgKhZpz5y4JJn7YVxj66aNA7v9S8wZg3tQWtnuKt E37RyQpPVKmhFpVq95TsVopxa36peCuLflXQHK1F2RvR3MAPbUnAn3bje2f6VEQJqXn7 Q+8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t8I5Ec0f9yGbWt01KnMJiW13THdX9MKlgvmWFFOUb5Y=; b=okM6dOIE+64WKOY06SD5R4BinWJslr50uzBCnTiHKgiFYyAFE2A30v763OYXDn+NR8 OmYZ7w7CQMN9FixX/xMcQuiN107ynGbAYwlblTq9okf+zvnU7O0PViyHtPZn6RQcTXOp XXBcqhDnKTNthriaIojAynRcBUBhZuYalwmHd33xYjM74OkDS7r2jv4Qv+TIO/jpfjWS nFT1VDGXxvD4SMXcCKI27oKJNKORbCs7xx7EZemoEJNfl1DxGk7ZCesLnC4ZstPhuJUo ZUsE1UwfA2iGa0ewrN5b4rpJILsoUMA80HkqKvY2PUUACo2jyDhojsoGPdyYVx74C1Hs SR+w==
X-Gm-Message-State: AJcUukfLSMwtecV24zNywP7SYi259w6H0jSkS2v2RdbZP6HRJjIzjPDC odNh/3wM8w4vbi/ITpwj6pnh5cxwS7E5LVpe4+kAGg==
X-Google-Smtp-Source: ALg8bN4m3nM5gGhZuTT9NJUIZa7kY7UuPV5vWFkbVucN0sRE7dGSjf74RFI3SEtfiQ7fSEnaqT4OsZf4tslsMd13Q/g=
X-Received: by 2002:a9d:27e3:: with SMTP id c90mr5296789otb.21.1548363544299; Thu, 24 Jan 2019 12:59:04 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Thu, 24 Jan 2019 12:58:38 -0800
Message-ID: <>
To: Adam Roach <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000a8d3f05803a7b1c"
Archived-At: <>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Jan 2019 20:59:08 -0000

For what it is worth, I think this way forward should work reasonably
well.  It doesn't create a conflict for the current implementations, but
does leave the breadcrumbs needed so that any implementations in the future
that do add support for this will do so interoperably.

If folks can review the PR (it's quite short) and comment, I would
appreciate it.  Assuming we get consensus, I think a quick re-spin is all
that's necessary to move forward.



On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <> wrote:

> 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
> offers).
> 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.
> /a
> _______________________________________________
> rtcweb mailing list