Re: [rtcweb] Proposal to break the ICE impasse

Iñaki Baz Castillo <> Tue, 29 January 2019 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4306130FB4 for <>; Tue, 29 Jan 2019 10:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.043
X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 xmZyDVfqKkYh for <>; Tue, 29 Jan 2019 10:33:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::936]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 86521130FB2 for <>; Tue, 29 Jan 2019 10:33:30 -0800 (PST)
Received: by with SMTP id d21so7180819uap.9 for <>; Tue, 29 Jan 2019 10:33:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+eC9gKSrMgjVu3rdbPjAhTLlKo4raCVuUdd/rEhkN68=; b=ELIPb1JTgO3wbXTcg9oXD38q77LtLSjtLdI/xIKbdFoCi44l3ZX0XnANocmZdte793 N/nzpJSQUt6quEDrtH+s+pKIl/vqg++8wm1B5hiISna0vxvpb9Yb8ehMCipur3QZmNLN KaIoAlzxlUamrt4a0UIbT3cZJrR3IfnQBJeYpJ1k9uelQ3EdlYhV97449M3wcg4Exjvp wy9yeVHiRzoyhUzjKnW9e2Wx9/RcZd++jL36vzfNK5IdIxofEpD4HVqApCPhU4EFdgGQ qTYIPclsC/X+DL3ajUi/lKgeKW5bpSfpS2pWTILchZomJ2ZwTbYXaK6Wdj0thsUG+u+G kRAQ==
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:content-transfer-encoding; bh=+eC9gKSrMgjVu3rdbPjAhTLlKo4raCVuUdd/rEhkN68=; b=VyNFTksGOc3L1n1bSK35RLICV46yoL13Wf5AuUt+a6eROHga6NgxvntiYLcm/cPhhZ /umQ2RBqij/sf4+ZFIfYJIrm5OAgHIZLOIcQVsH2is06i8aJXAkYUI2exLjX+tM1Ltec pGO58yOLCyiHcnVrQCc6o5spsYZJug6gMecijEEYi4tc8zprtTgs6fG/naFZA6D4xGee 1wV1Qcd8b1LqDTvqDNNgwci3+H6PR7zDeHhCyuI4e9X47MfnTgSqNlwg10/rXANpuMmx oUkOOj9p4ECD84bMYxWKIgM37vFDR/QJyxM1+nd1ec2S5ZhU7IixS5AzqEqMC28DGNnT B8FA==
X-Gm-Message-State: AJcUukcHsiL2X33geoQkfxB806zV3aj0uWr6teNrO3+5cs9TmjhJA3qp kDmFUgVv6apBT4R9hefOy/oqWNfYprvo/drB0qMMWGTJ+xk=
X-Google-Smtp-Source: ALg8bN4wHZwta71Rp5oKmN+ebpzzYNA+okD8grbqifjA8MgHM8txOUPN5LrjwXfkHwRYuwt4um8NOGNcmJsIIlXSrfU=
X-Received: by 2002:ab0:7048:: with SMTP id v8mr11490092ual.84.1548786809394; Tue, 29 Jan 2019 10:33:29 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Tue, 29 Jan 2019 19:33:18 +0100
Message-ID: <>
To: Roman Shpount <>
Cc: Nils Ohlmeier <>, RTCWeb IETF <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 29 Jan 2019 18:33:33 -0000

On Tue, 29 Jan 2019 at 19:05, Roman Shpount <> wrote:

> During steps 1-4, browser client sends an offer which includes both UDP and TCP candidates. It is using one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Server, also responds with UDP and TCP candidates. It also uses one of the UDP candidates as a default candidate in c= and m= line (proto is UDP/... something). Since client location blocks everything except TCP, only the connectivity check for TCP candidate pair succeeds and TCP candidate gets nominated. Once ICE nomination process is completed, new offer is generated from the client without ICE restart (for instance to add a codec or initiate "fix up" offer). This offer must include locally nominated candidate pair and no other candidates ( This means this offer will only have TCP candidates present. This TCP candidate is the default candidate and will be used in c= and m= line resulting in TCP/... proto in the m= line.

This is a very good point:

> This (re)offer must include locally nominated candidate pair and no other candidates

But how is the draft above useful at all if browsers do not set the
selected candidate into c=/m= lines during a re-offer? Imagine browser
do implement the draft above and, indeed, they set "TCP/DTLS/..." in
the proto line of the re-offer with just TCP candidates. Assuming that
they do NOT set the selected candidate pair in the m=/c= line, this is
just valid to know whether UDP or TCP has been selected, nothing else.
Am I wrong?

In the other side, and assuming this is about JavaScript SIP+WebRTC
clients, wouldn't it work if they mangle the SDP re-offer? By checking
the peerconnection stats you can know the selected candidate and so

Iñaki Baz Castillo