Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?

Roman Shpount <roman@telurix.com> Fri, 26 April 2019 21:33 UTC

Return-Path: <roman@telurix.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77308120121 for <ice@ietfa.amsl.com>; Fri, 26 Apr 2019 14:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 ycBqc6yCg7y3 for <ice@ietfa.amsl.com>; Fri, 26 Apr 2019 14:33:43 -0700 (PDT)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 908E71200F4 for <ice@ietf.org>; Fri, 26 Apr 2019 14:33:43 -0700 (PDT)
Received: by mail-pg1-x52b.google.com with SMTP id l18so2194860pgj.6 for <ice@ietf.org>; Fri, 26 Apr 2019 14:33:43 -0700 (PDT)
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=8D8dGPVahC933EtSUSG2lBaYZuGOQACRA1HQqfPN7G0=; b=t/Gy4ATY/OafAL/Tx+bqmn5Klp06R287Dtdj86YS5f1S16HQnqXVqHIngTPjnTQ/9/ /NW8CxqV85PqBUbd027UNOl4yesbyFRrCtjva0kkfwB/o+hNGTli4cH/byxTCrOBi8ap gNbIeCDmq2O2rtHLzBYnPjoYSCvSmoyyYjM/lLvTG9LXj5+bqbRm61SUM2qtoa4gOQ+5 WTF2B4iplw9IRKYpzokQF/sUibtll5+Enc1aXS07Xwqg/ZU6TLdC79ujMSGVUdjpcHy8 VqmI2MOmLh+uEef57siDNwQSzKdYnTsZ8TGrMp51WRkJ3JC9kgpfaF06eKxOMYqCJw8Y V85g==
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=8D8dGPVahC933EtSUSG2lBaYZuGOQACRA1HQqfPN7G0=; b=SYrj+8zhqzCZSWgSFrizhJ2KSu9AXxW/lfbHiyt41aj41lt55+8cAaXhcCJALKRFyZ qaieHrlZXirtNgytKU3tjV5p12IgrfVl/KRgMjtofRaPyPJ2ViamZQCETi/SM3MIFt7u Zd+hmi9gYuVcFKgqxJKRI8xvkxLbkM7UqShTSbcEGxAcYP2RQfN4cJF9KnQENXur0XnW PUPzeJk2kr4To7nyiyI8pLOnzko6M3cNEWJm91E50q6c4RYobngtQeJeD+0E0XD5F/bs LCGcNQuebnhXNYgW/wO4HVhHSvXbCg0tx33yUQk8a4xECZEZxfX9AKBAhqoch9yFmtke 5Hsg==
X-Gm-Message-State: APjAAAWuE02khEhcsBtczqhbFiuWdeF4+8n4IHa6Xcg+SahDMUvftIFF ug9cpZoqDu8of8L4608FQniAQZi4sZM=
X-Google-Smtp-Source: APXvYqwOLoC4Sr4WT+oWSSJRE9vTAuMhxX4dKxd43zF6wj5lUdrknMTFYj+BWRl0hF2ucPLYZqeruA==
X-Received: by 2002:a63:d84a:: with SMTP id k10mr45380940pgj.441.1556314422660; Fri, 26 Apr 2019 14:33:42 -0700 (PDT)
Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com. [209.85.215.169]) by smtp.gmail.com with ESMTPSA id h20sm67643404pfj.40.2019.04.26.14.33.41 for <ice@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 14:33:42 -0700 (PDT)
Received: by mail-pg1-f169.google.com with SMTP id n2so2175817pgg.13 for <ice@ietf.org>; Fri, 26 Apr 2019 14:33:41 -0700 (PDT)
X-Received: by 2002:a65:6110:: with SMTP id z16mr37471304pgu.131.1556314421615; Fri, 26 Apr 2019 14:33:41 -0700 (PDT)
MIME-Version: 1.0
References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <CAD5OKxsMgNTQPNP4Ni72H+yD4iUeyNK+x6CSvdBApGnPTpr_vg@mail.gmail.com> <A4EC3C01-4D7D-45DF-876D-E58706F74866@ericsson.com> <CAD5OKxt8tDemkK=v4X1gjwJGLYrxcd95S7uV53_fsga6grZ_rA@mail.gmail.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <CAD5OKxvmRK8Xzu4FSRv3Lgdg-VrrufzGhjAdSmfcLLkrm-jtjw@mail.gmail.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <CAD5OKxsgpf7Hv_nxFOZFwfNk7-_xNRzmoPTA2bZCqZo3wzudKQ@mail.gmail.com> <HE1PR07MB316172053751D307F83DE0EB933E0@HE1PR07MB3161.eurprd07.prod.outlook.com> <CAD5OKxu332E8vzdc4dt09NxXGf9Cr2izwECDAQjc7V_YDx3r5w@mail.gmail.com> <AAC20A8E-D3D5-4DB9-9ADC-2AAD2194EF79@mozilla.com>
In-Reply-To: <AAC20A8E-D3D5-4DB9-9ADC-2AAD2194EF79@mozilla.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 26 Apr 2019 17:33:32 -0400
X-Gmail-Original-Message-ID: <CAD5OKxucO9TNoZOE=AGPwZ8V4cN58n_CRraBJBDVvQR=DW+KFA@mail.gmail.com>
Message-ID: <CAD5OKxucO9TNoZOE=AGPwZ8V4cN58n_CRraBJBDVvQR=DW+KFA@mail.gmail.com>
To: Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "ice@ietf.org" <ice@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004263df058775b0f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/X_pw9G7_vPeNRSkkk5veh6A40qw>
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates?
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 21:33:47 -0000

On Fri, Apr 26, 2019 at 5:18 PM Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

>
> On Apr 26, 2019, at 13:46, Roman Shpount <roman@telurix.com> wrote:
>
> Hi Christer,
>
> On Fri, Apr 26, 2019 at 4:28 PM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>> In a non-trickle case, I think it would be very strange if the agent
>> didn’t get any candidates front the peer agent.
>>
>>
> I have just sent a message to the mmusic list regarding ice-sip-sdp and
> offers with no candidates. There is nothing that technically prohibits it
> in RFC 5245, so I thought it makes sense to add a note which explicitly
> allows it in ice-sip-sdp.
>
> There is a valid use case for this, when client is behind NAT and it would
> only communicate with a server on public address. In such cases, client
> does not need to collect any candidates and simply send the offer. Once it
> gets the answer from the server with the public address, client can send a
> STUN bind request to server address using a local socket not bound to any
> address, which will use default route. There are multiple benefits for
> implementing it this way, one of which would be client privacy.
>
>
> Intersting idea. I think this actually works more generally in case the
> other side indicates to be ice-lite, or if it’s know to be ice-lite.
> In other words: this should also work the client being the SDP answerer.
> But in any of these cases you would need to know that the other side
> supports ICE PAC, or?
>

Currently this works very well with ice-lite server for both offer and
answer. We actually have this deployed with ice-lite server and slightly
"lobotomized" client (i.e. client which starts trickle but never sends
collected candidates to the server). Once we get ICE PAC done, this would
be consistently usable with full ICE on the server side as well.

One thing I was considering is that we should make ICE PAC mandatory for
anything that includes ice-options: ice2. I think it is already implied
with my latest pull request to ice-sip-sdp.

Regards,
_____________
Roman Shpount