Re: [rtcweb] Proposal to break the ICE impasse

Iñaki Baz Castillo <> Tue, 29 January 2019 01:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C1EC1277BB for <>; Mon, 28 Jan 2019 17:26:49 -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 u_00gwa548q9 for <>; Mon, 28 Jan 2019 17:26:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 890DB126CB6 for <>; Mon, 28 Jan 2019 17:26:46 -0800 (PST)
Received: by with SMTP id y27so11044182vsi.1 for <>; Mon, 28 Jan 2019 17:26:46 -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=vqEz/LKi69YAVrskwRHiVpMMU6N5NDl99xOGnqRuUuc=; b=q/1sRiozr3Zj+lezYfPp1ODnzH2H1HdMhbb7bVVt7Opr4ipehPFpy46kiydJ8mND0n 3H7S28GowUhdPkOLt/CFHFHWRhB5kYCsXgmvl2HspTX8R+Quichgjswo6F62fMiDUsfi uwUTHMJNKCtLXa8WfaAQrls09DYUZBMQvBtW0uyCmhST/S2SdyBGFQ3JVK5wpmmXSosl Kn3+Ye4HCQxFbpRfj3kcX+pYzrW7G8UT3Azos6dxitLS3PD1CBAChz9tasnUeIaQHTM5 OM/I2AR5XEIozvQWmawCdgiNPtMN6LwTa/HwTkiEHlCLdR3Q1AiRbba7gI8ydD73S7fO JB7w==
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=vqEz/LKi69YAVrskwRHiVpMMU6N5NDl99xOGnqRuUuc=; b=swwFO8PWarf10YKIxN6kmILpBTvel1S/OOqrKMQmCAY+fDGty/MFVM9bBGv56bZsoi 1yrZjbanX0xgLMxEz0nn+Igr/lgG1XZV2b5jtGy72kJ8+wdTSq7lVnIWA0v5Te3WLvaA PmOwr+K4ybH6RaLSwIQUJrXrdFOKMu4ruy3HKiz9Pz+bU/jOyO2g9hNYwyuRCv9S5opl wZTNb9fRkuK5qv9Ny1J+zRqnvA2jGg5gVGCprjdmUBp9tYKRAFmUel0Zkzwe3ZvZMqvI 7Z5lDV3Iqx1+Eors+PFkJzf30ZQg3XWQzl6xHZ9E2GOKw4VgM96k+pS7ZClgaFy1pwTm pluQ==
X-Gm-Message-State: AJcUukd00LDv5Lq/5HWFpHlhYfJi3Df4QDgOEgPflTNtXq5617aZtQoy g7ybORj27d/MiU4XAwiVW2D1zd/bPtmW2GC5Y/8wDA==
X-Google-Smtp-Source: ALg8bN6eQ2sIb/nZmUN2pDKXpNopyYfBaBbOPWeP6ff4XWqEVaugSVC2zf5HpPa4zXG6dXQW1NFrY3d/mdOzpn1/MCI=
X-Received: by 2002:a67:7106:: with SMTP id m6mr10388752vsc.67.1548725205494; Mon, 28 Jan 2019 17:26:45 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Tue, 29 Jan 2019 02:26:33 +0100
Message-ID: <>
To: Ted Hardie <>
Cc: Eric Rescorla <>, "" <>
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 01:26:49 -0000

On Tue, 29 Jan 2019 at 02:10, Ted Hardie <> wrote:

> That consensus was limited to JSEP; other related uses of SIP/SDP do not treat it as meaningless.
> The additional complexity added to a system is, of course, always a concern.  But  I interpret your statement "If it's necessary, then I'm willing to live with it." as agreeing that this solution will work if the additional domain of interoperability which results is not empty.

The summary is basically that it adds extra complexity to WebRTC
without absolutely any advantage or added feature. Anyway:

> Implementations MUST indicate this profile for each media m= line they
produce in an offer unless the media section contains only TCP candidates;
if all candidates use TCP as a transport, implementations MUST indicate
"TCP/DTLS/RTP/SAVPF," to allow for compatibility with non-WebRTC

Some concerns:

1) Browser and WebRTC "clients" will always offer UDP candidates, so
the above is not likely to happen.

2) If it happens (there are just TCP candidates) this is probably
because the server mandates TCP, so the "service monitoring system"
already knows that.

3) The browser offers UDP and TCP candidates so will place
"UDP/TLS/RTP/SAVPF" in the transport. Then the server replies with
just TCP candidates. I assume that the server would also use
"UDP/TLS/RTP/SAVPF" in the answer (because it must match the transport
value in the offer) but, do we expect that the browser will "send a
re-offer with TCP/DTLS/RTP/SAVPF" to conform to this spec? That won't
happen. So how is this useful at all for the service monitoring

Instead of all this folklore, couldn't the "phone" just send a
multi-purpose OPTIONS somewhere once it knows the selected ICE tuple
and we are done? That can be easily implemented in flexible SIP and
WebRTC stacks.

Iñaki Baz Castillo