Re: [rtcweb] Proposal to break the ICE impasse

Justin Uberti <> Sun, 27 January 2019 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56AB712896A for <>; Sat, 26 Jan 2019 17:45:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.642
X-Spam-Status: No, score=-17.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, 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, 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 ouGVkqdxEsKh for <>; Sat, 26 Jan 2019 17:45:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8A1B1288BD for <>; Sat, 26 Jan 2019 17:45:31 -0800 (PST)
Received: by with SMTP id f4so10744559ion.2 for <>; Sat, 26 Jan 2019 17:45:31 -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=81GfJHQrZSkyEC9kobI9SuGuozXsuIFPt25QTdFUERE=; b=fXe0hU5q/oHfM3+ff7ceBmgZ4wks9ss+wrBnOS0jyFTBNYWfLnD+nICJI3PQll2OkT 8l91DWJ1S9gPGzGAt5QiosdIughBNkI9Uw0agkNIG5sKkM0t1uRKPH351xQSiQmJ2K5K PhdAwFMO2Vw+cdRNVUF2UAqNzob3jSeNnENQYMmRyto8qhlIMvoiXrU5xQ7u8uOS98F+ NdD6yHH25ccBLcYc2Xtu/fkrGH5wpeh+D+xQASl9KXAU/f3PO5NuJ5pgMxPFJE7Clq7U WWY7gt3Z1g5AKUh1Vv3zrLLHvkmL7ojKKuZhq/GINHIsV5EN21c9vvRHrD5DG/mHOvIm 9lrA==
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=81GfJHQrZSkyEC9kobI9SuGuozXsuIFPt25QTdFUERE=; b=qqvry4iVRk/IgAPlKlmsR9cKitf8BGqpm4n8yTOlSZMDLQfam/gJwrt8rvbbgNgysZ l0jb7+0bC8T4SURuhdCyCRBeUayVWNFN9wA2hShrkBN3q808ck/FYEWqEL88aaGAgAH7 mwcb18YVQH0hnuKCNheYyzGOFVL4OqNDEzAB3aKbdItrb3BIH+wPlGnQDnWy9UUMrT5o MvUUz7yRKSfrJIUVYIEmUNZZZOkoFzCiNzEidUrbCU53+Tvc287bN8C781UHZvNCRuLf EscZtFLsi9pRRJLOCVEFMjMkDVuHqaTQ+esI+cozo8qqhqus+bUkws1ZURA6c/BnF0Rg 4K8Q==
X-Gm-Message-State: AJcUukdN4Obu4Oxl2lu3qQc2jglc9UcjKIxXP3ZNgaXd3o7pVfSlXSo0 oSl5892OsebZ5vBhKh2cMt+IWZltGbRXJEWhlM2Evw==
X-Google-Smtp-Source: ALg8bN4v/uZZ41zqCd+Ck6imp/fYSHDMyTJHCtKQ1pn+8CTdBHwNy2MePsJxk594cMutQxqa2MJaTEEH/MjrpBj+hfE=
X-Received: by 2002:a6b:da10:: with SMTP id x16mr9640511iob.101.1548553530746; Sat, 26 Jan 2019 17:45:30 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Sat, 26 Jan 2019 17:45:17 -0800
Message-ID: <>
To: Eric Rescorla <>
Cc: Adam Roach <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000001e0b29058066b7f8"
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: Sun, 27 Jan 2019 01:45:34 -0000

I agree with Eric, but in the interest of moving forward, I am willing to
live with the relatively straightforward solution of using TCP in the m=
line when the default candidate is a TCP candidate.

On Sat, Jan 26, 2019 at 9:23 AM Eric Rescorla <> wrote:

> I'm not yet persuaded this is needed. The alleged need here is that there
> are some ICE-implementing endpoints which will choke if they see a profile
> that doesn't match any actual candidate. I recognize that this is required
> by 5245, but that doesn't mean anyone ever did it. Can you please point me
> to a client which would interoperate with a WebRTC endpoint with this
> change that would not if you just always sent the same profile as JSEP
> currently requires.
> -Ekr
> 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
> _______________________________________________
> rtcweb mailing list