Re: [rtcweb] Proposal to break the ICE impasse

Roman Shpount <> Tue, 29 January 2019 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2772130FE9 for <>; Tue, 29 Jan 2019 11:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Status: No, score=-2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] 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 wRpcSwBSesnl for <>; Tue, 29 Jan 2019 11:28:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B973130FE6 for <>; Tue, 29 Jan 2019 11:28:24 -0800 (PST)
Received: by with SMTP id a14so9774302plm.12 for <>; Tue, 29 Jan 2019 11:28:24 -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; bh=VIqeXymov9x6jzez3TF/KJisP08yk1vRQFcSCu9uIYw=; b=zDKgbyW4oW04V21+li4wOoUYhQ+0GmOfthIWWWBWuFmzlHPvRolz/FcyZzZf/Rwzpg jUsS3p9l4GqM6Z4R9g+U4uImsb14fEp1LdyCxOPrF4zvJvjL5vfHPWJSihX3jHWVkBkU EYJyk18bPsfqMqb+DzDX8rvqm8v0Nix8E7tYHFy9a2iFLI0/NGT8q8/xjt5b86c40SfD Z6ptGQtj6BgCrmIa+n71yMWbknanQ3kYAx/EV1UG0wiJVDDA7EGsVh8oMw4cRqPQKW+T IoW0nUunwRHgEZ8I2J4xdIibxkPG75P3v8Uh0lODW6rn10csYOp0UOVyYup+/LuuNJv8 MOOA==
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=VIqeXymov9x6jzez3TF/KJisP08yk1vRQFcSCu9uIYw=; b=U3CyYeDzMqPMxiiWVEN4a9HS6ZonML53Hkrc+WuupCf9ix7yM14/t8cPkyOOphHcmR VDoraFteeDB0dkxKEhIbSuZpEXZ9Vh5ZRQQvesGJt5Rpqt1vQ/szrvWM614/HLw3vSNt wThZh/c9pg5VHcyT/8JX3B9SzhUPkueJHgJH/vwgtiEPCBMRp71e39iyumzF8TeD9j62 +XnxTSqQY559QYiKcXrjWAARV9E3IcjcVpVX6DFH1aPJYgKk5+EqtxvmfTwKQkitA8Dr g4U8SndeRJHOT6v87dVxBcJwh+necpId0hRNDy8R6fyj395TRFsE7uQulDTlkm/KB9qn 2KBQ==
X-Gm-Message-State: AJcUukfS0dj8qWdCYjQXKcf9VsM8yP6NCV9s1Zuh8VX7UGzxyGT2+AiJ ygyF+M5DYeO/Fq3M/hfMrHHRqV80BRc=
X-Google-Smtp-Source: ALg8bN51vDVWJY+BJf0KkPJVZ3OERdBVe4poCZyty3NOyx3hE0bswq/D7OlB/BNq1R1XqhELvKDCqQ==
X-Received: by 2002:a17:902:142:: with SMTP id 60mr28136992plb.330.1548790103593; Tue, 29 Jan 2019 11:28:23 -0800 (PST)
Received: from ( []) by with ESMTPSA id q199sm69403136pfc.97.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 11:28:22 -0800 (PST)
Received: by with SMTP id p8so9794339plo.2 for <>; Tue, 29 Jan 2019 11:28:22 -0800 (PST)
X-Received: by 2002:a17:902:6909:: with SMTP id j9mr26459856plk.196.1548790102402; Tue, 29 Jan 2019 11:28:22 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Roman Shpount <>
Date: Tue, 29 Jan 2019 14:28:11 -0500
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Cc: Nils Ohlmeier <>, RTCWeb IETF <>
Content-Type: multipart/alternative; boundary="000000000000e2ace305809dcb42"
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 19:28:26 -0000

On Tue, Jan 29, 2019 at 2:05 PM Iñaki Baz Castillo <> wrote:

> I understand your point. But still I don't understand the purpose of the
> new draft (set TCP/DTLS/etc in proto line if there are just TCP candidates
> in the offer).

The purpose is standard compliance. If nominated candidate is UDP, proto
line should be UDP. If nominated candidate is TCP, proto line should be
TCP. If you do not care about the c= and m= line, put the dummy values and
UDP there, but this breaks legacy interop by causing ICE mismatch. Putting
UDP proto and address from TCP candidate breaks legacy interop as well, but
it is typically localized to provider managed server, so it is possible to
patch around this either in JS client or on the server to treat WebRTC
clients differently. Alternatively, WebRTC clients can add a couple lines
of code and become compliant with the RFC they decided to implement and
remove the need for patching.

Of course, if browser follow the ICE spec and set the selected candidate in
> the c/m lines, they must also indicate whether that is over UDP or TCP. The
> problem here is what such a proto line is intended to mean when there is
> ICE candidates of UDP and TCP. But ok, let's assume that browser do update
> c/m lines in the trigger with the selected candidate, and they JUST change
> the proto line to TCP/DTLS if there are just TCP candidates. Now thing
> about this scenario:
> 1) Client initial offer with UDP and TCP candidates.
> 2) Server answers with both UDP and TCP candidates.
> 3.1) UDP is selected. Re-offer is created with just UDP candidates (as per
> spec).
> 3.2) or TCP is selected. Re-offer is created with just TCP candidates (as
> per specs).
> In both 3.1 and 3.2 the "monitoring Node" doesn't need to inspect the
> proto line. It can just check the protocol (UDP or TCP) of *any* candidate
> in the offer to know whether UDP or TCP was selected.
> Am I wrong?

You are correct. Checking c= and m= line is simply to avoid checking and
parsing ICE candidates. If monitoring client would handle ICE candidates,
then the monitoring client would still need to figure out which candidate
is default to record client media IP. Keeping c= and m= line in sync with
default candidate on the client seemed to cause the least amount of
problems which is why it was left in ice-sip-sdp.

Roman Shpount