Re: [rtcweb] Proposal to break the ICE impasse

Roman Shpount <roman@telurix.com> Tue, 29 January 2019 18:05 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D119D130F3B for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 10:05:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.031
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6RpfEYFg_6X for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 10:05:53 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875CC130EC9 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:05:53 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id b85so10029767pfc.3 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:05:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JcgcPXnyVtclB+5zevpqQ+UXCO5HjbbxSMnMDBJ83ns=; b=A1c5vEk0yXK8EclUtzM4LdJkgnvQ1mJ5pqbA+vewsoE629+6GLialn6LECjUIbqRpw zfZz5f5/SpPTs2oqsds351gP+KT9qQYWlwXs4ttELZ8Q4Cwpwj/w4X97S3/agbZpy2Om hFQCikqibWknB9zQqW+c78K02Qbg6gkaQbnyHTPRmzH7Vc9rQakd0CejmlSGoMA1QHpY anWm08DfVU9IqIq2gXmFO74tckXlheEr4PGy+69Y3M2re3+TGDckfXeaXcO/ND3qB/HT CIezSZY9r3rE5hZkm1D4WNjwwvUSX5C2Sic+mwBlqCORHMRCT53KcAlu5JLzJCGZG5+F ycog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JcgcPXnyVtclB+5zevpqQ+UXCO5HjbbxSMnMDBJ83ns=; b=hVRrB5lxPRvfTX9f4HKK9gB9/+uN/ziegI5UcpSuidNfwnCy7ynMrcgcchgG8KkOsN ufWYe/BOOeOOcozY3PMLSmPhpLPBBWclC6yPCKqw+GC3t3CNcNq8c3gUjmWL5aD4GAxo 5TBtvT00LCPC4zAHrCNoPZ6tOXHgsbZo5eVQpiksPcPJUf5qkcVS1N5G/SEUVrBZNa3e wK/78hqMKrp8EM5S8ZiwEuAV2/ttHxE7KHx0oX+gzqvsOkfQcU88T16mTKUrPb9HeePI fOCfGXKnhcIWlabP3Hwi1nTho06PQgYfL0rrBAM0iq96xqXezvh1D+ie229kqzZz+6kh dBFA==
X-Gm-Message-State: AJcUukdZgHsxSvb/l/gWpXIt2M/ntesh2ZOx9rzlyKafSDRujwambpM3 cvP871eZFpYrlz5opI8A/wV56pbIG0g=
X-Google-Smtp-Source: ALg8bN7KWDGiXrwA2tF3eB9axx+emq0W5Hj0JpwM01gUqGu4AZVs/zDmJxn+gQjUz5v9d+3JKyMQJA==
X-Received: by 2002:a63:dd15:: with SMTP id t21mr23554723pgg.347.1548785152711; Tue, 29 Jan 2019 10:05:52 -0800 (PST)
Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com. [209.85.214.180]) by smtp.gmail.com with ESMTPSA id y6sm42421504pfl.187.2019.01.29.10.05.51 for <rtcweb@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:05:51 -0800 (PST)
Received: by mail-pl1-f180.google.com with SMTP id u6so9692154plm.8 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 10:05:51 -0800 (PST)
X-Received: by 2002:a17:902:8b88:: with SMTP id ay8mr27404846plb.55.1548785151426; Tue, 29 Jan 2019 10:05:51 -0800 (PST)
MIME-Version: 1.0
References: <97ed2641-8a7e-19a9-be38-a3458ca9212e@nostrum.com> <CABcZeBP9t0SgsHAuENo99D6ffKd7Mw0Xs1vzUCOzSS=WJN5z8A@mail.gmail.com> <HE1PR07MB3161B0F1D2B5AC9DA72DDFAD93950@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAOJ7v-3KHi0TUDsQvG6qq-qeNGBsqLxg+NC1c+Nxvgy0ks0d0g@mail.gmail.com> <CABcZeBNL=sWFfh=zwiuib80HPsno=GzF18gU+z3DrCZTK_PquA@mail.gmail.com> <CA+9kkMDh56CeXRGNSk_r-HrLkDNT5DnYc_FguXOdeccfq=LEMA@mail.gmail.com> <CABcZeBPboLf0bLUDTyJArxsPYSnUrULArmsZ9YshQCX+rEvexA@mail.gmail.com> <CA+9kkMCwCBHWEEADxVHT2ZbvWEi=bUBJ22icKHpA2p8Kg1fF9A@mail.gmail.com> <CALiegfnpj+Pu0Hg05iqHXCwhTefxn_Em7gTnzOXK897fzcyuwg@mail.gmail.com> <CAD5OKxvmQHT3TAt_=xCd_JKnPzXfnc=Mej-mr6KMsaKVoBkuSg@mail.gmail.com> <CALiegfm_jtv1bV3Ok6j20hkim8e6QxMYPrbbHejqoHnCHjMXpA@mail.gmail.com> <CAD5OKxsMWEE39O6hSc+UFjwTAa=z1A+XD5X2BY=Q7PEUdYE4UA@mail.gmail.com> <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com>
In-Reply-To: <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com>
From: Roman Shpount <roman@telurix.com>
Date: Tue, 29 Jan 2019 13:05:40 -0500
X-Gmail-Original-Message-ID: <CAD5OKxuwhmAPvonV1rX1rN6yi08-4NPH1BOzVuJPUMEntnpRkw@mail.gmail.com>
Message-ID: <CAD5OKxuwhmAPvonV1rX1rN6yi08-4NPH1BOzVuJPUMEntnpRkw@mail.gmail.com>
To: Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>, RTCWeb IETF <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8c4ea05809ca4e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/e25VJeBBAbOoKJxyLyb6WK7fypI>
Subject: Re: [rtcweb] Proposal to break the ICE impasse
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jan 2019 18:05:56 -0000

On Tue, Jan 29, 2019 at 12:46 PM Nils Ohlmeier <nohlmeier@mozilla.com>
wrote:

> What I don’t quite understand here: 1-4 with the initial connection will
> use UDP in the protocol field. Only the subsequent re-offer from step 5 on
> would use TCP in the protocol field. How come that 1-4 works, but 5 does
> not?
>
>
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 (
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-24#section-3.4.1.2.2).
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.

There is literally one call scenario here which is affected. TCP candidates
should not be used as default candidates or TCP based proto should not be
used in the m= line in the offer in any other scenario.

If you do not understand this scenario, please ask questions before
commenting.

Thank You,
_____________
Roman Shpount