Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15).

Justin Uberti <> Wed, 13 February 2019 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BCDC1200B3 for <>; Wed, 13 Feb 2019 11:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Cn9_iz_45kwF for <>; Wed, 13 Feb 2019 11:38:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56C5812E036 for <>; Wed, 13 Feb 2019 11:38:36 -0800 (PST)
Received: by with SMTP id h6so7218691itl.1 for <>; Wed, 13 Feb 2019 11:38:36 -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=0IrHFWxNEWMyyvUPeyxK1Yq2040dMR8lBMOGFu0gaKs=; b=WmU6COzFGgvGwai03LxMzthBEKNszCUmo41EJUj7z41D6sFZy243YMXfiX7VhcJ91b 4hztxrkNl1ZTiz4myrumpleijHHa3OYX15GrdrOLWTdBt/BITzBYEWSIo+gtLILdPNoL E+pluBW2jEjez6tEjmauZhDm33HpiigteSCYzoh1NLFQPyIiiajAMgmjpgldb2Dr7q2U SuyxVCZ0CGQ+PQDxXa+YX8JpuaF9YO2blQXijSI4CfR065hFzroCb0l7BaFVxDtELVeC Kc+4Q30ISN5MYj1X6mDZs32d5dO4REgEGGfka3SwpISJj7Zhu6sQevSWGCJbd49HivSe IHMA==
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=0IrHFWxNEWMyyvUPeyxK1Yq2040dMR8lBMOGFu0gaKs=; b=BTgsb4GGT13Y0v6k1WwFSAuFfPbgfegutItkroH42JodnsK9VBQ0mNythhseV5v6sU eaZZyaJ2ZwI6RXJi+f2TgSRrZCjmKlBxrZ8wL49rBek3GZZF1PhVB+b9pWLM+ik3ZBHs PuHvBLVm12201Rtpbi10QnNXsjq851f6XSMLTNxQq/vhz0jXE/KdArey685rQFp13Oiv DHsgI5dv6KmaMZ4xgBckgW449tKVmoNdGohcpeC7ROYq81syocUwocbFgfqS8QZnjD+8 tzGFgcBagL0zDd2Gs4Z3Ev/UHaGof+L/E0ZRM47ROXt7ORhPk+HeH5bG/9l9u3km9CgA SVgg==
X-Gm-Message-State: AHQUAuanCSogIY16lOxvRh2yd0OXWYRRGb2JGZu/NOB6Wxtq7WWxiZ/B S5nE8+dMzynVlFBGrPnoYfuaNHCuGIcTUPeQk1Q0Rw==
X-Google-Smtp-Source: AHgI3IZacPO/sAPj8Y2owVcH9SEVxbIk6+a6irdqDMSyQT4iP/zqjLPPJ7CKi1HtyS9kk17Drxs4AOtKHvcN/z6nkfg=
X-Received: by 2002:a6b:ef02:: with SMTP id k2mr1245199ioh.95.1550086714526; Wed, 13 Feb 2019 11:38:34 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Wed, 13 Feb 2019 11:38:23 -0800
Message-ID: <>
To: Ted Hardie <>
Cc: RTCWeb IETF <>, Sean Turner <>, Adam Roach <>
Content-Type: multipart/alternative; boundary="000000000000fe01a10581cbaf35"
Archived-At: <>
Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15).
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: Wed, 13 Feb 2019 19:38:40 -0000

I support this change, solely to avoid confusion for implementers caused by
different guidance from JSEP and ice-sip-sdp.

On Wed, Feb 13, 2019 at 10:53 AM Ted Hardie <> wrote:

> As an individual, I support this change.  While I agree that the benefit
> is currently theoretical, I think having the breadcrumbs for what to do
> when it ceases to be theoretical is worth the effort.
> Ted
> On Fri, Feb 8, 2019 at 10:42 AM Ted Hardie <> wrote:
>> Over the the past few weeks, the working group has discussed whether to
>> adopt a change to JSEP which would adjust how the ICE proto line transport
>> parameters are populated in certain mid-session offers where the final
>> candidate is a TCP candidate.  Outside of the extensive working group
>> discussion on the mailing list, participants may also wish to review the
>> follow issue:
>> and the conversations related to these two pull requests:
>> and
>> The chairs believe that there is technical consensus that this proposed
>> change would not materially affect JSEP-only exchanges, since this
>> parameter is ignored in those.
>> The remaining technical issues are:
>> * whether making one of these changes would improve interoperability
>> between WebRTC and non-WebRTC clients which use SIP/SDP.
>> * whether the additional complexity in tracking the use of UDP vs. TCP
>> and populating the parameter accordingly is onerous or unwarranted for
>> WebRTC implementations.
>> After reviewing the discussion to date, the chairs believe that there is
>> rough consensus for the first point, though there is also broad agreement
>> that the benefit of this change is currently theoretical, since no existing
>> WebRTC browser implementation has relevant code.
>> On the second point, the chairs believe that there is no consensus yet
>> demonstrated.  Because we believe that this is in part because the actual
>> proposal has not been entirely clear, and the complexity is therefore
>> somewhat hard to gauge, the chairs wish to make a specific call for
>> consensus.
>> Does the working group approve the change in the following PR:
>> ?
>> Working group participants who have objections to the change are asked to
>> specify whether they believe it has a technical fault, whether they object
>> on the basis of its complexity, or whether they have other issues related
>> to the change they need to raise.
>> The chairs are already aware of the objection of Eric Rescorla on the
>> basis of complexity, and will factor it into the review.
>> Please send comments by February 15th, 2019.
>> regards,
>> Ted Hardie and Sean Turner
>> _______________________________________________
> rtcweb mailing list