IETF Logo Mail Archive

Re: [rtcweb] Proposal to break the ICE impasse

Nils Ohlmeier <nohlmeier@mozilla.com> Tue, 29 January 2019 17:46 UTC

Return-Path: <nohlmeier@mozilla.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 1DDC6130EA2 for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 09:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 o4eL8ziQ34-4 for <rtcweb@ietfa.amsl.com>; Tue, 29 Jan 2019 09:46:14 -0800 (PST)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 46B11130E58 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 09:46:14 -0800 (PST)
Received: by mail-pl1-x62c.google.com with SMTP id w4so9690770plz.1 for <rtcweb@ietf.org>; Tue, 29 Jan 2019 09:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Hj4Btkwr8/VKeKJoPDspFyOtJX/4wwsZ6EuzgfwTXdc=; b=HXhlP1OBIDiJArDRrKB7zrMixWdaer48cvK+xNzkYQSL3Xm2fz5axlYrHA7C3Oxq9E HL/tUn8HyJo0d6w7bcrz88w69ljgzSJryRcdqu4NHBcSVDYYx8KbGF9iqMFdIL1b6sXa ORXBGr8LJBwc2VFf5J81QPcvN3q+CX8X/d0d0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Hj4Btkwr8/VKeKJoPDspFyOtJX/4wwsZ6EuzgfwTXdc=; b=Xdq9ypJ9+vfeqZcjyLk3n1cTViOh8CtaAzkgo5RjGWVZu3j+obxSCv9SfFw0b5M/Rk PcgJ2hk+EV+abjSZ7p9S+590MfK0muENQszDgeO3nXrRlKJ6Vh/9dOlqbaoEfNzkHJqQ /wcz6RUKd6WHeUlI1HidV4a4GB3Rx+xYjr7Sfr+nd8K4hqta0w0KaZ79hD2vQNjmSP9m NuPENLhvyhAFPCdQHb+oiYsqLpFP1yf2MYHyn0w/9VvjTAWXPgYTAuYdrrpKgJ/9Z+mr QMTsXXtnj4Ja+0U5Cxj9evAEsJ1Lq0zKrX5eNJ4ESYFpkIFoH9qZnnYKcefFLT9NwGf0 3INA==
X-Gm-Message-State: AJcUukc/cjEZvIuIS0iplLuahuoblxFgY9xbHRw7FOnabupfRxWbP32+ 685MnI7gtZ3SiSgIPsuqdlkfvd66JJGuWQs4
X-Google-Smtp-Source: ALg8bN5rlApkCOw40+Dq+lniWC88wJA0HAL1nyTuFqL84GTDPYnyMBHIXE3nmaSrZJiBr1gpltETuQ==
X-Received: by 2002:a17:902:f20d:: with SMTP id gn13mr25838377plb.11.1548783973556; Tue, 29 Jan 2019 09:46:13 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:b94e:c0f3:356d:3836? ([2620:101:80fc:224:b94e:c0f3:356d:3836]) by smtp.gmail.com with ESMTPSA id b10sm52207939pfj.183.2019.01.29.09.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 09:46:12 -0800 (PST)
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Message-Id: <961E55AE-2072-4145-8BCF-62D67C6D150F@mozilla.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35885C8D-5726-4C56-AC09-8B1C17A445AC"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 29 Jan 2019 09:46:10 -0800
In-Reply-To: <CAD5OKxsMWEE39O6hSc+UFjwTAa=z1A+XD5X2BY=Q7PEUdYE4UA@mail.gmail.com>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, RTCWeb IETF <rtcweb@ietf.org>
To: Roman Shpount <roman@telurix.com>
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>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/sRfPh5FIoOkkuynhp00L6WkFZgg>
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 17:46:17 -0000

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?

Best
  Nils Ohlmeier

> On 29Jan, 2019, at 05:36, Roman Shpount <roman@telurix.com> wrote:
> 
> 1-4 are for initial connection. 5 is for the new offer. It can be a "fix up" offer or simply an offer which happened not to change transport parameters and is simply adding a codec.
> 
> I can write this up in more detail if you need.
> 
> Roman Shpount
> 
> On Tue, Jan 29, 2019, 7:02 AM Iñaki Baz Castillo <ibc@aliax.net <mailto:ibc@aliax.net> wrote:
> Hi, Roman.
> 
> In SIP world (and in many others) 5 will happen before 3, so I don't understand. Do I miss something?
> 
> El mar., 29 ene. 2019 10:10, Roman Shpount <roman@telurix.com <mailto:roman@telurix.com>> escribió:
> Iñaki,
> 
> Please consider the following:
> 
> 1. Browser client is placed behind the firewall which only allows TCP connections
> 
> 2. No TURN servers are configured
> 
> 3. Client establishes connection to a server which supports ICE TCP
> 
> 4. ICE nomination completes
> 
> 5. Client browser app calls createOffer with no options (ICE restart option is not present)
> 
> Based on the current set of specifications, in this case ICE nomination is complete and the TCP candidate is nominated. No other candidates should be present in the offer.
> 
> Roman Shpount
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email