From nobody Mon Apr 8 10:28:47 2019 Return-Path: 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 19A3712031E for ; Mon, 8 Apr 2019 10:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 h8_bTGy-XNny for ; Mon, 8 Apr 2019 10:28:43 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 5357912031A for ; Mon, 8 Apr 2019 10:28:43 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id d5so4589402uan.6 for ; Mon, 08 Apr 2019 10:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=AdTfGbo6O4bIhdbzcrD4BPK0yzV1SqRHn+RF5xmwwmk=; b=CgBTDx/gXKgVN8UgOIDxPgkrsFel6GHdpa6lXthMFebbwnSK+wKi4yewzA0h/1KnSh B0/ekWOOrHP7QSyQ2VUTwTKMU+LsgPsoSTe0g2JMOSvKbNtJHarE7H/yvCmso5ghIlGg bANiRIyhplh1uo+T3Bp4HvcZolX1KP/NccxnXN34ii2QzXksG/7fgMqGHjvOiScrEg2r lBLisNjNXzpkJMsi0iNv+DwpDhHUIaAWgNe9GBLScOMqhO6ITUuCci182XoXPQLkkNaW VIXq6uKqO4NA0sYxKrrmVDd8U2B1cE/m31JKhHT0lYC3KC7N9dT2jy4WNQZTOWNJg3p4 NJrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AdTfGbo6O4bIhdbzcrD4BPK0yzV1SqRHn+RF5xmwwmk=; b=Kfzlpmm5bADd8MNcYRDLFC2mKAZx8ymqqDDowm/aMUsGfFPFhdqmNg9PMhTTlgjxCO pM03K50lKqTNVaNn1xPAyFUZHXn2HnrlegDz2kfTmdp/AGhjjtL4VP/0F7CqE9mSBkYf eYJFIUAtzmWSTbfOXIGlxGuvREzo+JPlM2eQ9ritgBxwCn0rbQO7mDM6dhrVeRDcdgEZ OT7tphGX+51QrEO/hnogWD4dfu6j5V63kNp1XyCxhqvKlG06wEZxcMEw2UU/SLCBiISJ zMDzhOVZ02laYmPVlORGESlNtJIpNUMvRGoZZKT/3lRuRSZCjssZVP4tgG4t63nEFIZg n+5w== X-Gm-Message-State: APjAAAVXKtG85Hyw5tgPtWiRdfec7PpocLDpft3abXmANXlI+rTypBRR hSbEOLR89V3p8qP3kT9eYM8VDyxZMOlSkivmKKTutgTq X-Google-Smtp-Source: APXvYqwHeFigsC84kVJIE3Exju/MGuO7niyd0sgiqb8gveVe5IsJrU7lDlGLRt7QSGxEkltft0Rqbj+JzIRaDYDTrj0= X-Received: by 2002:ab0:6783:: with SMTP id v3mr15790724uar.8.1554744521439; Mon, 08 Apr 2019 10:28:41 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Mon, 8 Apr 2019 10:28:31 -0700 Message-ID: To: ICE WG , Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000eabdab0586082a30" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 17:28:46 -0000 --000000000000eabdab0586082a30 Content-Type: text/plain; charset="UTF-8" A question has arisen recently about the behavior with respect to peer reflexive candidates discovered *after* ICE completion: https://github.com/w3c/webrtc-nv-use-cases/issues/10 draft-holmberg-ice-pac doesn't relate to that question, but I'm wondering whether we might also see significant differences in implementation behavior there as well. RFC 8445 appears to require an ICE restart to be able to use a newly discovered peer reflexive candidate after ICE completion because it represents a change in the destination, but I'm wondering if there are implementations that enable a peer reflexive candidate to be used anyway. Christer Holmberg said: "Hi, Doing an ICE restart means you have to collect and exchange candidates again. Of course one can do that once ICE failure has been declared, and nothing prevents one from doing an ICE restart after that if one thinks the result will be different. But, the focus of the draft is not to declare ICE failure while working candidates may still arrive. Having said that, one should of course not wait forever for the peer reflexive candidates. The draft will not mandate a specific time value, but there probably will be a little more text about things to take into consideration when determining how long to wait. Regards, Christer" --000000000000eabdab0586082a30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A question has arisen recently about the behavior wit= h respect to peer reflexive candidates discovered *after* ICE completion:= =C2=A0
=

draft-holmberg-ice-pac doesn't relate to that quest= ion, but I'm wondering whether we might also see significant difference= s in implementation behavior there as well. RFC 8445 appears to require an = ICE restart to be able to use a newly discovered peer reflexive candidate a= fter ICE completion because it represents a change in the destination, but = I'm wondering if there are implementations that enable a peer reflexive= candidate to be used anyway.=C2=A0

Christer Holmberg said:= =C2=A0

"H= i,
Doing an ICE restart means you have to collect and=
 exchange candidates again. Of course one can do that once ICE failure has =
been declared, and nothing prevents one from doing an ICE restart after tha=
t if one thinks the result will be different. But, the focus of the draft i=
s not to declare ICE failure while working candidates may still arrive.

Having said that, one should of course not wait forever for the peer reflex=
ive candidates. The draft will not mandate a specific time value, but there=
 probably will be a little more text about things to take into consideratio=
n when determining how long to wait.

Regards,
=C2=A0
Christer"<= /div>
--000000000000eabdab0586082a30-- From nobody Mon Apr 8 10:55:33 2019 Return-Path: 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 D7F99120318 for ; Mon, 8 Apr 2019 10:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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 wObSZgxyPOVt for ; Mon, 8 Apr 2019 10:55:29 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 C0E7F120220 for ; Mon, 8 Apr 2019 10:55:29 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 85so7745250pgc.3 for ; Mon, 08 Apr 2019 10:55:29 -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=BdJCbOuulslobc+7NHHFCkmxRaSmcvZiMKU+4F5t+QI=; b=re+FzdnTUx9Y4Gh2ReCJSBP2CVFMQEefY2sHIhpESCMlSGbaiDkwMjb16kEpLNBzIF eSbJMiRCn6zeJNFw0VIG+LxWLoUmofk5/9f4+OBZNFWCa75f2Or67JAgwu0SeuqW8X6P rTYxfnt4N4g34mnx3F035Hr0FNjhCS9kk0panhiXFM30iJ/or4rl0DERxJVvuqck4ORb oOVZg4CqOFVJPQXEJZcX+j75u6U4Px4v/vvYFWrbqEJjxsSkogtFg8k79pnK9iSt7y/z OwvYlLjDR7hTbT2I6Jx4GxQOLMt0bnIJ+rm05I0CVYIaY4/ndod1kQDjzjoKjQyyDzuc uGzQ== 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=BdJCbOuulslobc+7NHHFCkmxRaSmcvZiMKU+4F5t+QI=; b=tnFWdP6LUO0Bl9Jbrdd+nLNBkjhdl5tR9WNXsnYNMy3X+Zbqa/fvMPIu9LEYoeogyx Z+itM+UkSQtl+7wyLTaaHNpfjbo/JzVHU5tcXp/MWT7OimatsfDX3NPQ91sezc2f3BSl pAdqiEnWebJ1GP1NbWi+nhSNyV/qjVjJ/uQuWFMTCXI5+H0LmhXMwnH0CApEjGAxYITT JSsR6WN0X1FM42QqG1hB4/Sx7WV35rX7Yk/5iFAxknQaW4JfX9M3+dCpxe0bMVdhGEnp nKvdxvS1sy8YWxruq/km6v2QrBR166L0hnyXc3dVFNz2dPxBJLR9VLOn3ynMetTEPhBt edqA== X-Gm-Message-State: APjAAAX1WaX1JaAyWQDV0sbg8ehwdQK9iyWEvYGabVH/ZHcpoNRH7bCr ETgWQAmugtRLFMsIcPW/yxI/PnbGh2E= X-Google-Smtp-Source: APXvYqypuh6olPOVqZvvH9cOn2LB+7fAbLhHbH02S/9J5MWgwfCkQJvSaqomx6c0R6vLSaZmKQlFJg== X-Received: by 2002:a63:dc50:: with SMTP id f16mr29540911pgj.396.1554746128969; Mon, 08 Apr 2019 10:55:28 -0700 (PDT) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com. [209.85.210.181]) by smtp.gmail.com with ESMTPSA id d75sm62789335pga.66.2019.04.08.10.55.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 10:55:28 -0700 (PDT) Received: by mail-pf1-f181.google.com with SMTP id i17so4931258pfo.6 for ; Mon, 08 Apr 2019 10:55:28 -0700 (PDT) X-Received: by 2002:a62:2a97:: with SMTP id q145mr31345523pfq.22.1554746127775; Mon, 08 Apr 2019 10:55:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 8 Apr 2019 13:55:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Cc: ICE WG , Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000a97e490586088ab3" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 17:55:32 -0000 --000000000000a97e490586088ab3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bernard, The big issue here is when ICE agent can release candidates. Normally, when ICE nomination completes, unused ICE candidates, such as unused local interfaces or TURN candidates are released after a short (3 second) timeout. Because of this, running new ICE connectivity checks without ICE re-start (which means new ufrag and pwd, signaling exchange and allowing remote to gather new candidates) is likely not going to succeed. For instance, one party can move from IPv4 to IPv6 network, but the other party would already release its lPv6 candidate, which will cause all connectivity checks to fail. Also, peer reflexive candidates are not gathered after ICE nomination is complete. Changing this will not be a backwards compatible change. This is completely different from the use case discussed in ice-pac draft, which deals with ICE nomination failing before peer reflexive candidates are discovered. All that ice-pac draft does is specifying a delay for ICE nomination completion in the absence of remote candidates, not collecting remote candidates after nomination is complete. Regards, _____________ Roman Shpount On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba wrote: > A question has arisen recently about the behavior with respect to peer > reflexive candidates discovered *after* ICE completion: > https://github.com/w3c/webrtc-nv-use-cases/issues/10 > > draft-holmberg-ice-pac doesn't relate to that question, but I'm wondering > whether we might also see significant differences in implementation > behavior there as well. RFC 8445 appears to require an ICE restart to be > able to use a newly discovered peer reflexive candidate after ICE > completion because it represents a change in the destination, but I'm > wondering if there are implementations that enable a peer reflexive > candidate to be used anyway. > > Christer Holmberg said: > > "Hi, > > Doing an ICE restart means you have to collect and exchange candidates ag= ain. Of course one can do that once ICE failure has been declared, and noth= ing prevents one from doing an ICE restart after that if one thinks the res= ult will be different. But, the focus of the draft is not to declare ICE fa= ilure while working candidates may still arrive. > > Having said that, one should of course not wait forever for the peer refl= exive candidates. The draft will not mandate a specific time value, but the= re probably will be a little more text about things to take into considerat= ion when determining how long to wait. > > Regards, > > > Christer" > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --000000000000a97e490586088ab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bernard,

The big issue here is when ICE= agent can release candidates. Normally, when ICE nomination completes, unu= sed ICE candidates, such as unused local interfaces or TURN candidates are = released after a short (3 second) timeout. Because of this, running new ICE= connectivity checks without ICE re-start (which means new ufrag and pwd, s= ignaling exchange and allowing remote to gather new candidates) is likely n= ot going to succeed. For instance, one party can move from IPv4 to IPv6 net= work, but the other party would already release its lPv6 candidate, which w= ill cause all connectivity checks to fail.=C2=A0 Also, peer reflexive candi= dates are not gathered after ICE nomination is complete. Changing this will= not be a backwards compatible change. This is completely different from th= e use case discussed in ice-pac draft, which deals with ICE nomination fail= ing before peer reflexive candidates are discovered. All that ice-pac draft= does is specifying a delay for ICE nomination completion in the absence of= remote candidates, not collecting remote candidates after nomination is co= mplete.

Regards,
________= _____
Roman Shpount


On Mon, Apr 8, 2019 at 1:28 PM = Bernard Aboba <bernard.aboba@= gmail.com> wrote:
A question has arisen recently about the b= ehavior with respect to peer reflexive candidates discovered *after* ICE co= mpletion:=C2=A0

draft-holmberg-ice-pac doesn= 't relate to that question, but I'm wondering whether we might also= see significant differences in implementation behavior there as well. RFC = 8445 appears to require an ICE restart to be able to use a newly discovered= peer reflexive candidate after ICE completion because it represents a chan= ge in the destination, but I'm wondering if there are implementations t= hat enable a peer reflexive candidate to be used anyway.=C2=A0

Christer Holmberg said:=C2=A0

"Hi,
Doing an ICE restart means you have to collect and exchange candidates a=
gain. Of course one can do that once ICE failure has been declared, and not=
hing prevents one from doing an ICE restart after that if one thinks the re=
sult will be different. But, the focus of the draft is not to declare ICE f=
ailure while working candidates may still arrive.

Having said that, one should of course not wait forever for the peer reflex=
ive candidates. The draft will not mandate a specific time value, but there=
 probably will be a little more text about things to take into consideratio=
n when determining how long to wait.

Regards,
=C2=A0
Christer"<= /div>
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000a97e490586088ab3-- From nobody Mon Apr 15 02:28:24 2019 Return-Path: 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 E93F412008A for ; Mon, 15 Apr 2019 02:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 NRowx1So7xO9 for ; Mon, 15 Apr 2019 02:28:20 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9E212002F for ; Mon, 15 Apr 2019 02:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eKqzHjrB/Lu8tTFfb6h5ilk58e+Is1y6lBuMS/ZrPTc=; b=K2GEpMJ9+4hTKxZEJjnvvJMqiuRzpOhmNwCrhcMzKVF788CfDdhB3k3VbxV4NCXq4WYFZaGFDarm5LZbk1534r/taEPtcB4UB6I8wNhIAlpP2TJMSeWP4VzlSoVgjb2pWjfHEK+lbbn6gSZufqtMxD2OEf6NnINkLeLJz//A6ZA= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3129.eurprd07.prod.outlook.com (10.170.245.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 09:28:17 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 09:28:16 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: Justin Uberti Thread-Topic: ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 Thread-Index: AQHU822OiTpBjU8taU6/wGWiTR99Xg== Date: Mon, 15 Apr 2019 09:28:16 +0000 Message-ID: <8EB18F6B-DCA7-481F-9EBD-182A26709954@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc2a6f99-f5a4-4054-d5e5-08d6c184b10a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3129; x-ms-traffictypediagnostic: HE1PR07MB3129: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(136003)(39860400002)(346002)(189003)(199004)(86362001)(966005)(14454004)(5660300002)(2616005)(476003)(6436002)(3846002)(6116002)(7736002)(6486002)(486006)(33656002)(2906002)(478600001)(6916009)(66066001)(6506007)(105586002)(2501003)(186003)(26005)(58126008)(316002)(82746002)(106356001)(5640700003)(25786009)(102836004)(53936002)(236005)(6512007)(54896002)(6306002)(99286004)(2351001)(44832011)(4326008)(256004)(1730700003)(36756003)(81166006)(4744005)(8936002)(71190400001)(606006)(68736007)(83716004)(14444005)(8676002)(81156014)(71200400001)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3129; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: p9aM+PNOl/1FE9N926DLmnD6lyT76LoKN8M2fAF+gz7vwqjr2o4psf4jmT3ukoUkkDcAXctqdg8DfkSKnZRo4/TsQTNNQ9GKOGpLeo/15UJDDm0ViQTLrDkqKNWUPDVCd87IG/tjly10ZMTj1dyiox9Ke37v0X5uXz+auu3bw8PyWM9YWIFxCt2jVWwFbuIvlpiN4WxHy8BoMjFAOkIgOmrRCAzjiUfBKExszX6dtpvxXAzN6XL82gUORlJDEpkxank6lxaYqF8nudPLScOkSCI88+7lrdlZ2A1G5Snw4Vvcpg43uB9wnebbsT4D3bHT8ZS/YVFVDZkKPaPG1TYIrI1wmb1wl6Am7NTDdMK3L6kblvBY3lLmxs95QfWIKyk1u+Vbs29TPVsReNCfdEyl5lvfXhgDuxvfpg2G9uEimUo= Content-Type: multipart/alternative; boundary="_000_8EB18F6BDCA7481F9EBD182A26709954ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc2a6f99-f5a4-4054-d5e5-08d6c184b10a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 09:28:16.6042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3129 Archived-At: Subject: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:28:23 -0000 --_000_8EB18F6BDCA7481F9EBD182A26709954ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkRyYWZ0LWljZS1wYWMgdGFsa3MgYWJvdXQg4oCdY29ubmVjdGl2aXR5IGNoZWNrIHRp bWVvdXTigJ0uIEhvd2V2ZXIsIEFyaSBwb2ludGVkIG91dCB0aGF0IHN1Y2ggdGVybWlub2xvZ3kg ZG9lcyBub3QgZXhpc3QgaW4gUkZDIDg0NDUuIDg0NDUgdGFsa3MgYWJvdXQg4oCcQmluZGluZyBy ZXF1ZXN0IHRpbWVvdXTigJ0uDQoNClNvLCBJIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0 aGF0IHJlcGxhY2VzIOKAnGNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V04oCdIHdpdGgg4oCcY29u bmVjdGl2aXR5IGNoZWNrIEJpbmRpbmcgcmVxdWVzdCB0aW1lb3V04oCdLg0KDQpodHRwczovL2dp dGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzMNCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0K --_000_8EB18F6BDCA7481F9EBD182A26709954ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+RHJhZnQtaWNlLXBhYyB0YWxrcyBhYm91dCDigJ1jb25uZWN0aXZp dHkgY2hlY2sgdGltZW91dOKAnS4gSG93ZXZlciwgQXJpIHBvaW50ZWQgb3V0IHRoYXQgc3VjaCB0 ZXJtaW5vbG9neSBkb2VzIG5vdCBleGlzdCBpbiBSRkMgODQ0NS4gODQ0NSB0YWxrcyBhYm91dCDi gJxCaW5kaW5nIHJlcXVlc3QgdGltZW91dOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U28sIEkgaGF2ZSBjcmVh dGVkIGEgcHVsbCByZXF1ZXN0IHRoYXQgcmVwbGFjZXMg4oCcY29ubmVjdGl2aXR5IGNoZWNrIHRp bWVvdXTigJ0gd2l0aCDigJxjb25uZWN0aXZpdHkgY2hlY2sgQmluZGluZyByZXF1ZXN0IHRpbWVv dXTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczov L2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzM8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXN0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8EB18F6BDCA7481F9EBD182A26709954ericssoncom_-- From nobody Mon Apr 15 02:36:26 2019 Return-Path: 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 438D3120162 for ; Mon, 15 Apr 2019 02:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 1IqRQe-1fruF for ; Mon, 15 Apr 2019 02:36:23 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10070.outbound.protection.outlook.com [40.107.1.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852F912015E for ; Mon, 15 Apr 2019 02:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z14R2Jgpy++QzvPtrLcy8s3ZmXrB+19YRS0vvQYhViQ=; b=Q0Jjl1K6VrVKGB/qcMnrIdPN7TGAvMu47+tT7q4MHCxB5tc4/oEhFxoQSM6UDkMG6u4BUjaw2hGC46cZGTLs9kAv0K3nIc5pbf4v1VpvWg5sIVExoQcCx+5C4mZbeVDFVIRiYcmGMup6YzsPDHHcY0cxUxQ1NqdppkOdpYDhs7c= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4362.eurprd07.prod.outlook.com (20.176.167.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 09:36:19 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 09:36:19 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: Justin Uberti Thread-Topic: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 Thread-Index: AQHU826uuESE4dq270eD7Q0Ig37z+Q== Date: Mon, 15 Apr 2019 09:36:19 +0000 Message-ID: <3EAED358-31C2-4C31-87B5-ED508FFB4F6A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4abeb184-873a-4c57-131f-08d6c185d0d4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4362; x-ms-traffictypediagnostic: HE1PR07MB4362: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(366004)(376002)(346002)(189003)(199004)(7736002)(5660300002)(71190400001)(86362001)(6246003)(4326008)(54896002)(26005)(2351001)(66066001)(58126008)(97736004)(25786009)(83716004)(44832011)(5640700003)(6306002)(4744005)(6436002)(236005)(6512007)(36756003)(71200400001)(6916009)(68736007)(99286004)(53936002)(6116002)(3846002)(966005)(256004)(14444005)(6506007)(105586002)(8676002)(186003)(476003)(8936002)(1730700003)(606006)(2616005)(14454004)(102836004)(82746002)(2906002)(486006)(229853002)(6486002)(106356001)(2501003)(478600001)(81156014)(81166006)(316002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4362; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dkfLYfstmUAFFkWfqkrXWXyzPKgQncTE/zpeURm/nkjK/pI6Qd49iAabGpVddf0NjIiqd9vWxTLkEyNs158i9QQ1cyN4W5Nh80jBL+lBTDMyqkiySYYlNEpuAzPI59YjvRh62MnXMsEpzKR9yiUIrEZYnAOLwBIet72M48mVcIJC0gXvV4p8fbBh0AzKpUYMTjuYnsxW+IqIAIe6Ls20eRIllaDOZu8zjmEJcaa1Y1jGGJ1z8Hxu9NI4Mhq0EG5yQgalkoBu+AyzNjmg5qnieeNNyejMn9SxUuoAeJMRD0iaGSq8/lwq618+oVQh5Ml/zvLyNSa6MGM9VcxZiEJjO173OGYro625KTlJ2uCTgFKrrmyNHWSSnknVQY/I2gaqTpuXt/J5Y2fhqkTqxxNTPh4iRrnJeQd+qNdmmP5ZfOk= Content-Type: multipart/alternative; boundary="_000_3EAED35831C24C3187B5ED508FFB4F6Aericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4abeb184-873a-4c57-131f-08d6c185d0d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 09:36:19.6073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4362 Archived-At: Subject: Re: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:36:25 -0000 --_000_3EAED35831C24C3187B5ED508FFB4F6Aericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIEkgaGF2ZSBzb21lIGlzc3VlcyB3aXRoIEdpdEh1Yi4gUGxlYXNlIGlnbm9yZSB0aGUgUFIu IEEgbmV3IHZlcnNpb24gd2lsbCBiZSBzdWJtaXR0ZWQgc2hvcnRseS4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KRnJvbTogSWNlIDxpY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpEYXRl OiBNb25kYXksIDE1IEFwcmlsIDIwMTkgYXQgMTIuMjgNClRvOiAiaWNlQGlldGYub3JnIiA8aWNl QGlldGYub3JnPg0KQ2M6IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4NClN1Ympl Y3Q6IFtJY2VdIElDRS1QQUM6IGNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V0IHRlcm1pbm9sb2d5 IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4NDQ1DQoNCkhpLA0KDQpEcmFmdC1pY2UtcGFjIHRhbGtz IGFib3V0IOKAnWNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V04oCdLiBIb3dldmVyLCBBcmkgcG9p bnRlZCBvdXQgdGhhdCBzdWNoIHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4NDQ1 LiA4NDQ1IHRhbGtzIGFib3V0IOKAnEJpbmRpbmcgcmVxdWVzdCB0aW1lb3V04oCdLg0KDQpTbywg SSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QgdGhhdCByZXBsYWNlcyDigJxjb25uZWN0aXZp dHkgY2hlY2sgdGltZW91dOKAnSB3aXRoIOKAnGNvbm5lY3Rpdml0eSBjaGVjayBCaW5kaW5nIHJl cXVlc3QgdGltZW91dOKAnS4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1w YWMvcHVsbC8zPGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NGQ4M2M2YTMtMTEw OGNkOWMtNGQ4Mzg2MzgtODY4ZjI1NzYxYjcyLTM5ZjgxYzgzMTNjZWVjNjEmdT1odHRwczovL2dp dGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzM+DQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg== --_000_3EAED35831C24C3187B5ED508FFB4F6Aericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2E282CFA0A005845A2AB0257D6B8BDF1@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAy LjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5P aywgSSBoYXZlIHNvbWUgaXNzdWVzIHdpdGggR2l0SHViLiBQbGVhc2UgaWdub3JlIHRoZSBQUi4g QSBuZXcgdmVyc2lvbiB3aWxsIGJlIHN1Ym1pdHRlZCBzaG9ydGx5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWNlICZsdDtpY2UtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMTUgQXBy aWwgMjAxOSBhdCAxMi4yODxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7 ICZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5KdXN0aW4gVWJlcnRpICZsdDtq dWJlcnRpQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJY2VdIElDRS1QQUM6 IGNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V0IHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4aXN0IGlu IFJGQyA4NDQ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRyYWZ0LWljZS1wYWMgdGFsa3MgYWJvdXQg4oCdY29ubmVj dGl2aXR5IGNoZWNrIHRpbWVvdXTigJ0uIEhvd2V2ZXIsIEFyaSBwb2ludGVkIG91dCB0aGF0IHN1 Y2ggdGVybWlub2xvZ3kgZG9lcyBub3QgZXhpc3QgaW4gUkZDIDg0NDUuIDg0NDUgdGFsa3MgYWJv dXQg4oCcQmluZGluZyByZXF1ZXN0IHRpbWVvdXTigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNvLCBJIGhhdmUg Y3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0aGF0IHJlcGxhY2VzIOKAnGNvbm5lY3Rpdml0eSBjaGVj ayB0aW1lb3V04oCdIHdpdGgg4oCcY29ubmVjdGl2aXR5IGNoZWNrIEJpbmRpbmcgcmVxdWVzdCB0 aW1lb3V04oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9wcm90 ZWN0Mi5maXJlZXllLmNvbS91cmw/az00ZDgzYzZhMy0xMTA4Y2Q5Yy00ZDgzODYzOC04NjhmMjU3 NjFiNzItMzlmODFjODMxM2NlZWM2MSZhbXA7dT1odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJh ZnQtaWNlLXBhYy9wdWxsLzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3EAED35831C24C3187B5ED508FFB4F6Aericssoncom_-- From nobody Mon Apr 15 02:54:38 2019 Return-Path: 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 DDDA2120092 for ; Mon, 15 Apr 2019 02:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 5lS9H5hw5wtv for ; Mon, 15 Apr 2019 02:54:33 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130075.outbound.protection.outlook.com [40.107.13.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD59F12003F for ; Mon, 15 Apr 2019 02:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rfytEE8ErAUoInqFkIbsYBxtfWVx3tEGtKVKieEL8Rg=; b=KZVvmf8FTH6VaSy087WtlOtH/BEqRcbkoZiwGD7Pjebc60Oul6KS44kynhmBGI0Gxk/neoO6307+H/BkLpUK1tXftp4KNsLoaX4qby/6LGbnzUcgY6f1o14J/l7o+D/1eArLF0ABlKRb5aEPo7JrMpJP0QwvbBZKZUyFMngeOQY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4330.eurprd07.prod.outlook.com (20.176.167.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 09:54:30 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 09:54:30 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: Justin Uberti Thread-Topic: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 Thread-Index: AQHU826uuESE4dq270eD7Q0Ig37z+aY9LdyA Date: Mon, 15 Apr 2019 09:54:29 +0000 Message-ID: References: <3EAED358-31C2-4C31-87B5-ED508FFB4F6A@ericsson.com> In-Reply-To: <3EAED358-31C2-4C31-87B5-ED508FFB4F6A@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c8e1b948-f6f7-4ec1-c5b5-08d6c1885ab6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB4330; x-ms-traffictypediagnostic: HE1PR07MB4330: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(396003)(136003)(199004)(189003)(966005)(3846002)(106356001)(33656002)(6116002)(2351001)(44832011)(8676002)(105586002)(8936002)(478600001)(81156014)(81166006)(1730700003)(58126008)(476003)(82746002)(2616005)(6916009)(68736007)(11346002)(7736002)(14454004)(486006)(446003)(256004)(102836004)(53936002)(54896002)(6306002)(6512007)(236005)(186003)(71190400001)(2501003)(14444005)(316002)(5640700003)(83716004)(25786009)(6436002)(97736004)(229853002)(26005)(606006)(2906002)(6246003)(5660300002)(86362001)(36756003)(66066001)(99286004)(71200400001)(6506007)(6486002)(4326008)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4330; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IDQn1eDgjK7aM7aZy8E8WjDxndFzlY83a8whmSL34Rd+HOdqosLkOywcDxGBGG/FfOieBCVnB1QntCjRgd4VjDL/tAsMlmRi/oLjyK+eLFb6n1Gb7SyYYBcH7uKZeQLoynNQHVABpSR96PpgL82QGAm0Z4vpccN6XniLJdnL4/nTlyzUiNp7HXty7euYYmOr4OUNCNd17g7b/j+QZrJXwvIYLDWKPZpbuEdAy5IPhb+BURaBfHWa9qMrGZhKaxNCHxbese6jlNY8F9uubbSg5EpcDRodd+9/NmP3VSMQiprWAMhV2Ib/CDXt8zt9Ugo5NvZG0NHEUd8PyCgY3qgmcLXZz4nxD+MX9qXBEKa+54paNVT0489+i595zFDR6GOghyjlRRLgQ33sskzYJnrrUst1Q7wAfb88Owa6gT4Fd00= Content-Type: multipart/alternative; boundary="_000_F997BB6952D74D6A9986113D50D672FBericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c8e1b948-f6f7-4ec1-c5b5-08d6c1885ab6 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 09:54:29.9233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4330 Archived-At: Subject: Re: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 09:54:36 -0000 --_000_F997BB6952D74D6A9986113D50D672FBericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIGhvcGVmdWxseSB0aGUgR2l0SHViIGlzc3VlcyBhcmUgc29sdmVkIG5vdy4gSWYgcGVvcGxl IGhhdmUgY29tbWl0ZWQgc29tZXRoaW5nLCBwbGVhc2UgbWFrZSBzdXJlIGl0IGhhc27igJl0IGdv dCBsb3N0Lg0KDQpBIG5ldyB2ZXJzaW9uIG9mIHRoZSBwdWxsIHJlcXVlc3QgY2FuIGJlIGZvdW5k IGhlcmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL3B1bGwvNA0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBJY2UgPGljZS1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTUgQXByaWwgMjAxOSBhdCAxMi4zNw0KVG86ICJpY2VA aWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQpDYzogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29n bGUuY29tPg0KU3ViamVjdDogUmU6IFtJY2VdIElDRS1QQUM6IGNvbm5lY3Rpdml0eSBjaGVjayB0 aW1lb3V0IHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4NDQ1DQoNCk9rLCBJIGhh dmUgc29tZSBpc3N1ZXMgd2l0aCBHaXRIdWIuIFBsZWFzZSBpZ25vcmUgdGhlIFBSLiBBIG5ldyB2 ZXJzaW9uIHdpbGwgYmUgc3VibWl0dGVkIHNob3J0bHkuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCkZyb206IEljZSA8aWNlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KRGF0ZTogTW9uZGF5 LCAxNSBBcHJpbCAyMDE5IGF0IDEyLjI4DQpUbzogImljZUBpZXRmLm9yZyIgPGljZUBpZXRmLm9y Zz4NCkNjOiBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBbSWNl XSBJQ0UtUEFDOiBjb25uZWN0aXZpdHkgY2hlY2sgdGltZW91dCB0ZXJtaW5vbG9neSBkb2VzIG5v dCBleGlzdCBpbiBSRkMgODQ0NQ0KDQpIaSwNCg0KRHJhZnQtaWNlLXBhYyB0YWxrcyBhYm91dCDi gJ1jb25uZWN0aXZpdHkgY2hlY2sgdGltZW91dOKAnS4gSG93ZXZlciwgQXJpIHBvaW50ZWQgb3V0 IHRoYXQgc3VjaCB0ZXJtaW5vbG9neSBkb2VzIG5vdCBleGlzdCBpbiBSRkMgODQ0NS4gODQ0NSB0 YWxrcyBhYm91dCDigJxCaW5kaW5nIHJlcXVlc3QgdGltZW91dOKAnS4NCg0KU28sIEkgaGF2ZSBj cmVhdGVkIGEgcHVsbCByZXF1ZXN0IHRoYXQgcmVwbGFjZXMg4oCcY29ubmVjdGl2aXR5IGNoZWNr IHRpbWVvdXTigJ0gd2l0aCDigJxjb25uZWN0aXZpdHkgY2hlY2sgQmluZGluZyByZXF1ZXN0IHRp bWVvdXTigJ0uDQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL3B1bGwv MzxodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPTRkODNjNmEzLTExMDhjZDljLTRk ODM4NjM4LTg2OGYyNTc2MWI3Mi0zOWY4MWM4MzEzY2VlYzYxJnU9aHR0cHM6Ly9naXRodWIuY29t L2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC8zPg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_F997BB6952D74D6A9986113D50D672FBericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1 cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk9rLCBob3BlZnVs bHkgdGhlIEdpdEh1YiBpc3N1ZXMgYXJlIHNvbHZlZCBub3cuIElmIHBlb3BsZSBoYXZlIGNvbW1p dGVkIHNvbWV0aGluZywgcGxlYXNlIG1ha2Ugc3VyZSBpdCBoYXNu4oCZdCBnb3QgbG9zdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+QSBuZXcgdmVyc2lvbiBvZiB0aGUgcHVsbCByZXF1ZXN0IGNhbiBiZSBmb3VuZCBo ZXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC80Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9n aXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC80PC9zcGFuPjwvYT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWNlICZsdDtpY2UtYm91bmNlc0BpZXRmLm9y ZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMTUgQXByaWwgMjAx OSBhdCAxMi4zNzxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtp Y2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5KdXN0aW4gVWJlcnRpICZsdDtqdWJlcnRp QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbSWNlXSBJQ0UtUEFDOiBj b25uZWN0aXZpdHkgY2hlY2sgdGltZW91dCB0ZXJtaW5vbG9neSBkb2VzIG5vdCBleGlzdCBpbiBS RkMgODQ0NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T2ssIEkgaGF2ZSBzb21lIGlzc3VlcyB3aXRo IEdpdEh1Yi4gUGxlYXNlIGlnbm9yZSB0aGUgUFIuIEEgbmV3IHZlcnNpb24gd2lsbCBiZSBzdWJt aXR0ZWQgc2hvcnRseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2hyaXN0ZXI8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkljZSAmbHQ7aWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBD aHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDE1IEFwcmlsIDIwMTkgYXQgMTIuMjg8YnI+DQo8Yj5U bzogPC9iPiZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+SnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aUBnb29nbGUuY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5bSWNlXSBJQ0UtUEFDOiBjb25uZWN0aXZpdHkgY2hlY2sgdGltZW91 dCB0ZXJtaW5vbG9neSBkb2VzIG5vdCBleGlzdCBpbiBSRkMgODQ0NTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EcmFm dC1pY2UtcGFjIHRhbGtzIGFib3V0IOKAnWNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V04oCdLiBI b3dldmVyLCBBcmkgcG9pbnRlZCBvdXQgdGhhdCBzdWNoIHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4 aXN0IGluIFJGQyA4NDQ1LiA4NDQ1IHRhbGtzIGFib3V0IOKAnEJpbmRpbmcgcmVxdWVzdCB0aW1l b3V04oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5TbywgSSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QgdGhh dCByZXBsYWNlcyDigJxjb25uZWN0aXZpdHkgY2hlY2sgdGltZW91dOKAnSB3aXRoIOKAnGNvbm5l Y3Rpdml0eSBjaGVjayBCaW5kaW5nIHJlcXVlc3QgdGltZW91dOKAnS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NGQ4 M2M2YTMtMTEwOGNkOWMtNGQ4Mzg2MzgtODY4ZjI1NzYxYjcyLTM5ZjgxYzgzMTNjZWVjNjEmYW1w O3U9aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC8zIj48c3BhbiBs YW5nPSJFTi1VUyI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC8z PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaHJpc3Rlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F997BB6952D74D6A9986113D50D672FBericssoncom_-- From nobody Mon Apr 15 03:28:03 2019 Return-Path: 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 4F7F5120168 for ; Mon, 15 Apr 2019 03:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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=ericsson.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 csQReUM6m9Ir for ; Mon, 15 Apr 2019 03:28:00 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70055.outbound.protection.outlook.com [40.107.7.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D26A12006A for ; Mon, 15 Apr 2019 03:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=idcx9KdPFn1uD9v5rc4g7QrV1/RUd710SmgMd5QP1E0=; b=jX6TshgBIVlg7vkVJ0mxKlSAAE2y/dRVqoa8Ubs3VJHVu2RBwg60WNSyVBUs1x2hYfbcYsYYGc8V0eKGlcT4CjOn2n4DKVps3SwYHRjdSebXinS1oR1CtA/hGUMO9n4X3+V4BE28IflJqwskGgdsWyMW4hlElSPj2RYen9UPxX4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3468.eurprd07.prod.outlook.com (10.170.247.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 10:27:56 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 10:27:56 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: Justin Uberti Thread-Topic: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 Thread-Index: AQHU826uuESE4dq270eD7Q0Ig37z+aY9LdyAgAAJWAA= Date: Mon, 15 Apr 2019 10:27:56 +0000 Message-ID: <69086E69-76B9-4714-B90E-FF6F0F63FD0D@ericsson.com> References: <3EAED358-31C2-4C31-87B5-ED508FFB4F6A@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc101429-c15e-4cb4-0e04-08d6c18d06de x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3468; x-ms-traffictypediagnostic: HE1PR07MB3468: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(189003)(199004)(446003)(99286004)(68736007)(71190400001)(83716004)(5640700003)(71200400001)(25786009)(53936002)(33656002)(14454004)(11346002)(6246003)(478600001)(966005)(7736002)(316002)(4326008)(97736004)(6512007)(58126008)(236005)(2616005)(486006)(6306002)(2906002)(186003)(54896002)(44832011)(8676002)(26005)(476003)(66066001)(6506007)(102836004)(6916009)(36756003)(86362001)(3846002)(8936002)(6116002)(1730700003)(81166006)(606006)(106356001)(5660300002)(2351001)(6486002)(2501003)(81156014)(229853002)(6436002)(256004)(105586002)(14444005)(82746002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3468; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Bf02yvp1aPuYa7TI3sqwxwG38Hp4T8q/fAhFoDRXU7rK1FkrWCLMQVok1atcfUv24gpyeKq2A867fCQswPxvLG1RSMEigsn4R0zxaAHMm6tIasuVHcIKjr07nEZuI/UHn787tFfA+y4Cu7Tw1E4DbjDMG3xI47EW81agrihvLBDnI3Iyqpjq2w4JadDqCq3rLhB//LxVkx/mLTG/9g45jtAt8FwYutJBheKy1FwGBhxAUolUFsXBYbxwxG3AjZAy/9x/qFEvbKbSRmzUgNV04zBAiE78BIbjeW3liwVQJ6AxcIBxKnaJRgxfli6/9jLjCgYCuRWDM8R31A8r1cjCcEg6hAFoMiE/MLTJJDP/Xm7KEbZ462QyB5dl/co3yF/WHEr8/yfRg5DA7c3UsdhJ1BpNe7fJytVKZhqnphJUcmA= Content-Type: multipart/alternative; boundary="_000_69086E6976B94714B90EFF6F0F63FD0Dericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc101429-c15e-4cb4-0e04-08d6c18d06de X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 10:27:56.7538 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3468 Archived-At: Subject: Re: [Ice] ICE-PAC: connectivity check timeout terminology does not exist in RFC 8445 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 10:28:02 -0000 --_000_69086E6976B94714B90EFF6F0F63FD0Dericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VibWl0dGVkIGFuIGFkZGl0aW9uYWwgY29tbWl0LCB0aGF0IGFsaWducyB0aGUg dGVybWlub2xvZ3kgd2l0aCBSRkMgODQ0NS4gSW5zdGVhZCBvZiB0YWxraW5nIGFib3V0IOKAnHJl bW90ZSBlbmRwb2ludOKAnSBpdCBpcyBzdWdnZXN0ZWQgdG8gc2F5IOKAnHBlZXIgYWdlbnTigJ0g ZXRjLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBJY2UgPGljZS1ib3VuY2VzQGll dGYub3JnPiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTUgQXByaWwgMjAxOSBhdCAxMi41NQ0KVG86 ICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQpDYzogSnVzdGluIFViZXJ0aSA8anViZXJ0 aUBnb29nbGUuY29tPg0KU3ViamVjdDogUmU6IFtJY2VdIElDRS1QQUM6IGNvbm5lY3Rpdml0eSBj aGVjayB0aW1lb3V0IHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4NDQ1DQoNCk9r LCBob3BlZnVsbHkgdGhlIEdpdEh1YiBpc3N1ZXMgYXJlIHNvbHZlZCBub3cuIElmIHBlb3BsZSBo YXZlIGNvbW1pdGVkIHNvbWV0aGluZywgcGxlYXNlIG1ha2Ugc3VyZSBpdCBoYXNu4oCZdCBnb3Qg bG9zdC4NCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgcHVsbCByZXF1ZXN0IGNhbiBiZSBmb3VuZCBo ZXJlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQ8aHR0 cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az0xZGRlM2ZkYi00MTU0MWQzMi0xZGRlN2Y0 MC0wY2M0N2FkOTNlMmUtMzg4MGMzMjg1MGUyM2Q4YSZ1PWh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0 dS9kcmFmdC1pY2UtcGFjL3B1bGwvND4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog SWNlIDxpY2UtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpEYXRlOiBNb25kYXksIDE1IEFwcmls IDIwMTkgYXQgMTIuMzcNClRvOiAiaWNlQGlldGYub3JnIiA8aWNlQGlldGYub3JnPg0KQ2M6IEp1 c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbSWNlXSBJQ0Ut UEFDOiBjb25uZWN0aXZpdHkgY2hlY2sgdGltZW91dCB0ZXJtaW5vbG9neSBkb2VzIG5vdCBleGlz dCBpbiBSRkMgODQ0NQ0KDQpPaywgSSBoYXZlIHNvbWUgaXNzdWVzIHdpdGggR2l0SHViLiBQbGVh c2UgaWdub3JlIHRoZSBQUi4gQSBuZXcgdmVyc2lvbiB3aWxsIGJlIHN1Ym1pdHRlZCBzaG9ydGx5 Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBJY2UgPGljZS1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4NCkRhdGU6IE1vbmRheSwgMTUgQXByaWwgMjAxOSBhdCAxMi4yOA0KVG86ICJp Y2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQpDYzogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBn b29nbGUuY29tPg0KU3ViamVjdDogW0ljZV0gSUNFLVBBQzogY29ubmVjdGl2aXR5IGNoZWNrIHRp bWVvdXQgdGVybWlub2xvZ3kgZG9lcyBub3QgZXhpc3QgaW4gUkZDIDg0NDUNCg0KSGksDQoNCkRy YWZ0LWljZS1wYWMgdGFsa3MgYWJvdXQg4oCdY29ubmVjdGl2aXR5IGNoZWNrIHRpbWVvdXTigJ0u IEhvd2V2ZXIsIEFyaSBwb2ludGVkIG91dCB0aGF0IHN1Y2ggdGVybWlub2xvZ3kgZG9lcyBub3Qg ZXhpc3QgaW4gUkZDIDg0NDUuIDg0NDUgdGFsa3MgYWJvdXQg4oCcQmluZGluZyByZXF1ZXN0IHRp bWVvdXTigJ0uDQoNClNvLCBJIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCB0aGF0IHJlcGxh Y2VzIOKAnGNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V04oCdIHdpdGgg4oCcY29ubmVjdGl2aXR5 IGNoZWNrIEJpbmRpbmcgcmVxdWVzdCB0aW1lb3V04oCdLg0KDQpodHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzM8aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91 cmw/az00ZDgzYzZhMy0xMTA4Y2Q5Yy00ZDgzODYzOC04NjhmMjU3NjFiNzItMzlmODFjODMxM2Nl ZWM2MSZ1PWh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL3B1bGwvMz4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K --_000_69086E6976B94714B90EFF6F0F63FD0Dericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHN1Ym1pdHRlZCBhbiBhZGRpdGlvbmFsIGNvbW1p dCwgdGhhdCBhbGlnbnMgdGhlIHRlcm1pbm9sb2d5IHdpdGggUkZDIDg0NDUuIEluc3RlYWQgb2Yg dGFsa2luZyBhYm91dCDigJxyZW1vdGUgZW5kcG9pbnTigJ0gaXQgaXMgc3VnZ2VzdGVkIHRvIHNh eSDigJxwZWVyIGFnZW504oCdIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkljZSAmbHQ7aWNlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJl aGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDE1IEFwcmlsIDIwMTkgYXQgMTIuNTU8 YnI+DQo8Yj5UbzogPC9iPiZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3Jn Jmd0Ozxicj4NCjxiPkNjOiA8L2I+SnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0aUBnb29nbGUuY29t Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0ljZV0gSUNFLVBBQzogY29ubmVjdGl2aXR5 IGNoZWNrIHRpbWVvdXQgdGVybWlub2xvZ3kgZG9lcyBub3QgZXhpc3QgaW4gUkZDIDg0NDU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk9rLCBob3BlZnVsbHkgdGhlIEdpdEh1YiBpc3N1ZXMgYXJlIHNv bHZlZCBub3cuIElmIHBlb3BsZSBoYXZlIGNvbW1pdGVkIHNvbWV0aGluZywgcGxlYXNlIG1ha2Ug c3VyZSBpdCBoYXNu4oCZdCBnb3QgbG9zdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QSBuZXcgdmVyc2lvbiBvZiB0 aGUgcHVsbCByZXF1ZXN0IGNhbiBiZSBmb3VuZCBoZXJlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az0xZGRlM2ZkYi00 MTU0MWQzMi0xZGRlN2Y0MC0wY2M0N2FkOTNlMmUtMzg4MGMzMjg1MGUyM2Q4YSZhbXA7dT1odHRw czovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQiPjxzcGFuIGxhbmc9IkVO LVVTIj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JY2UgJmx0 O2ljZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ TW9uZGF5LCAxNSBBcHJpbCAyMDE5IGF0IDEyLjM3PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtpY2VA aWV0Zi5vcmcmcXVvdDsgJmx0O2ljZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzogPC9iPkp1c3Rp biBVYmVydGkgJmx0O2p1YmVydGlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtJY2VdIElDRS1QQUM6IGNvbm5lY3Rpdml0eSBjaGVjayB0aW1lb3V0IHRlcm1pbm9sb2d5 IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4NDQ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PaywgSSBo YXZlIHNvbWUgaXNzdWVzIHdpdGggR2l0SHViLiBQbGVhc2UgaWdub3JlIHRoZSBQUi4gQSBuZXcg dmVyc2lvbiB3aWxsIGJlIHN1Ym1pdHRlZCBzaG9ydGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWNlICZsdDtpY2UtYm91bmNlc0BpZXRmLm9y ZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgMTUgQXByaWwgMjAx OSBhdCAxMi4yODxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtp Y2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5KdXN0aW4gVWJlcnRpICZsdDtqdWJlcnRp QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJY2VdIElDRS1QQUM6IGNvbm5l Y3Rpdml0eSBjaGVjayB0aW1lb3V0IHRlcm1pbm9sb2d5IGRvZXMgbm90IGV4aXN0IGluIFJGQyA4 NDQ1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkRyYWZ0LWljZS1wYWMgdGFsa3MgYWJvdXQg4oCdY29ubmVjdGl2aXR5 IGNoZWNrIHRpbWVvdXTigJ0uIEhvd2V2ZXIsIEFyaSBwb2ludGVkIG91dCB0aGF0IHN1Y2ggdGVy bWlub2xvZ3kgZG9lcyBub3QgZXhpc3QgaW4gUkZDIDg0NDUuIDg0NDUgdGFsa3MgYWJvdXQg4oCc QmluZGluZyByZXF1ZXN0IHRpbWVvdXTigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNvLCBJIGhhdmUgY3JlYXRl ZCBhIHB1bGwgcmVxdWVzdCB0aGF0IHJlcGxhY2VzIOKAnGNvbm5lY3Rpdml0eSBjaGVjayB0aW1l b3V04oCdIHdpdGgg4oCcY29ubmVjdGl2aXR5IGNoZWNrIEJpbmRpbmcgcmVxdWVzdCB0aW1lb3V0 4oCdLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5m aXJlZXllLmNvbS91cmw/az00ZDgzYzZhMy0xMTA4Y2Q5Yy00ZDgzODYzOC04NjhmMjU3NjFiNzIt MzlmODFjODMxM2NlZWM2MSZhbXA7dT1odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNl LXBhYy9wdWxsLzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUv ZHJhZnQtaWNlLXBhYy9wdWxsLzM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_69086E6976B94714B90EFF6F0F63FD0Dericssoncom_-- From nobody Mon Apr 15 20:33:43 2019 Return-Path: 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 E99021200F9 for ; Mon, 15 Apr 2019 20:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 J4xkDjPusur7 for ; Mon, 15 Apr 2019 20:33:39 -0700 (PDT) Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 1E6AC12004E for ; Mon, 15 Apr 2019 20:33:39 -0700 (PDT) Received: by mail-it1-x12b.google.com with SMTP id v8so1604007itf.0 for ; Mon, 15 Apr 2019 20:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TR/5y8dXtoG1c2SbBV545LflpzB4WPsHoLf3HdM4OrY=; b=rzbPRTItG4whwNvZC4HPeMabO05pKgs8ETihkJAY8E+HLW8vH7AGYXmrDTpqSbAxbE vgth8HLTYgk/Q1qx8fMGuviweo8Mv+3SZ09NWmdbG++vtcKHWWotqTk3nKl8+BiO0yDU p802HUot0KlSJVjSdqhcCS9DEaEUlLXKqeK2IbuuCdXtRMp7fygS+uNzTcREGvuEQCf+ iYClR4jRjGlVOhQ3Leg7Uv6UuM+gz7Y0Pd77lFjZmlAMWerWSBqvLJsCah/K3zq3ANd8 QowfXnUkid5795ESNdZ9IsIPXQKLgkwWdpZjxSRbeOWoQscEIsDrds3hOd0x+N6CHUTB QQcA== 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=TR/5y8dXtoG1c2SbBV545LflpzB4WPsHoLf3HdM4OrY=; b=mrmPrdvJzWzj4MxZikF16EZVw84oYEOa8yajHWaOADfWguZDq1uUHSjuEQniKk/+YG /9spN9n9vhIHMlRRBmqrog+h5I15STgfoYFdVA2vNn+PTDE7zru0O+S51uTJZ661oOYT UOF9AUEZyoHoBTMM4u1p1gfmLeWJy+c4BbgDAPxl9oodNtnw5uSDtxseAJj/c/omhznb ZeDmeKof+CC6kfsCjhNWwfn+dcIPQbZbanaPEpXNkRmszjpIa8UcCn35dD5KbYZHqcKa sAhUArFr+dUCVvjBTKFtRz1GYHIvVNxYWUgFPSDoA4rSJElm3YnR5VJFEXs94fSqmmyT CWFg== X-Gm-Message-State: APjAAAV7qEG6k1zDi+pEbFWYessKSxmIMN0Ij1sbUi7CmpAHzXp0RkM2 r2+8F9JNY6kJvL2WNZf7+b7nOxOLg744eOI/N2xERw== X-Google-Smtp-Source: APXvYqyGEA3o75qQlLJD1/d8J0SCyJsdYarT4c1UVjxsvnDDNu2OlSWF9j0M4YKbSrDCgRpsZqQ7vWtsR/wS2qL5b0U= X-Received: by 2002:a24:a70f:: with SMTP id a15mr12757271itf.117.1555385617848; Mon, 15 Apr 2019 20:33:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Mon, 15 Apr 2019 20:33:25 -0700 Message-ID: To: Roman Shpount Cc: Bernard Aboba , Christer Holmberg , ICE WG Content-Type: multipart/alternative; boundary="0000000000003e12a705869d6f39" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 03:33:42 -0000 --0000000000003e12a705869d6f39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think there's an easy way to use a newly discovered prflx candidate, given the rules about changing the selected pair after ICE has completed, but I think this implies that one shouldn't be too hasty to declare ICE completion either. Since some implementations may malfunction if they don't get a USE-CANDIDATE quickly, I am not sure if we can wait the full STUN timeout interval, but perhaps a somewhat shorter delay (e.g. a few seconds) could be recommended before sending USE-CANDIDATE. On Mon, Apr 8, 2019 at 10:55 AM Roman Shpount wrote: > Bernard, > > The big issue here is when ICE agent can release candidates. Normally, > when ICE nomination completes, unused ICE candidates, such as unused loca= l > interfaces or TURN candidates are released after a short (3 second) > timeout. Because of this, running new ICE connectivity checks without ICE > re-start (which means new ufrag and pwd, signaling exchange and allowing > remote to gather new candidates) is likely not going to succeed. For > instance, one party can move from IPv4 to IPv6 network, but the other par= ty > would already release its lPv6 candidate, which will cause all connectivi= ty > checks to fail. Also, peer reflexive candidates are not gathered after I= CE > nomination is complete. Changing this will not be a backwards compatible > change. This is completely different from the use case discussed in ice-p= ac > draft, which deals with ICE nomination failing before peer reflexive > candidates are discovered. All that ice-pac draft does is specifying a > delay for ICE nomination completion in the absence of remote candidates, > not collecting remote candidates after nomination is complete. > > Regards, > _____________ > Roman Shpount > > > On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba > wrote: > >> A question has arisen recently about the behavior with respect to peer >> reflexive candidates discovered *after* ICE completion: >> https://github.com/w3c/webrtc-nv-use-cases/issues/10 >> >> draft-holmberg-ice-pac doesn't relate to that question, but I'm wonderin= g >> whether we might also see significant differences in implementation >> behavior there as well. RFC 8445 appears to require an ICE restart to be >> able to use a newly discovered peer reflexive candidate after ICE >> completion because it represents a change in the destination, but I'm >> wondering if there are implementations that enable a peer reflexive >> candidate to be used anyway. >> >> Christer Holmberg said: >> >> "Hi, >> >> Doing an ICE restart means you have to collect and exchange candidates a= gain. Of course one can do that once ICE failure has been declared, and not= hing prevents one from doing an ICE restart after that if one thinks the re= sult will be different. But, the focus of the draft is not to declare ICE f= ailure while working candidates may still arrive. >> >> Having said that, one should of course not wait forever for the peer ref= lexive candidates. The draft will not mandate a specific time value, but th= ere probably will be a little more text about things to take into considera= tion when determining how long to wait. >> >> Regards, >> >> >> Christer" >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --0000000000003e12a705869d6f39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think there's an easy way to use a newly d= iscovered prflx candidate, given the rules about changing the selected pair= after ICE has completed, but I think this implies that one shouldn't b= e too hasty to declare ICE completion either.

Since some= implementations may malfunction if they don't get a USE-CANDIDATE quic= kly, I am not sure if we can wait the full STUN timeout interval, but perha= ps a somewhat shorter delay (e.g. a few seconds) could be recommended befor= e sending USE-CANDIDATE.

On Mon, Apr 8, 2019 at 10:55 AM Roman Shpount= <roman@telurix.com> wrote:<= br>
Bernard,

The big issue here is when ICE agent can relea= se candidates. Normally, when ICE nomination completes, unused ICE candidat= es, such as unused local interfaces or TURN candidates are released after a= short (3 second) timeout. Because of this, running new ICE connectivity ch= ecks without ICE re-start (which means new ufrag and pwd, signaling exchang= e and allowing remote to gather new candidates) is likely not going to succ= eed. For instance, one party can move from IPv4 to IPv6 network, but the ot= her party would already release its lPv6 candidate, which will cause all co= nnectivity checks to fail.=C2=A0 Also, peer reflexive candidates are not ga= thered after ICE nomination is complete. Changing this will not be a backwa= rds compatible change. This is completely different from the use case discu= ssed in ice-pac draft, which deals with ICE nomination failing before peer = reflexive candidates are discovered. All that ice-pac draft does is specify= ing a delay for ICE nomination completion in the absence of remote candidat= es, not collecting remote candidates after nomination is complete.

Regards,
_____________
Roman Shpount<= /div>


On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba <bernard.aboba@gmail= .com> wrote:
A question has arisen recently about the behavior= with respect to peer reflexive candidates discovered *after* ICE completio= n:=C2=A0

draft-holmberg-ice-pac doesn't = relate to that question, but I'm wondering whether we might also see si= gnificant differences in implementation behavior there as well. RFC 8445 ap= pears to require an ICE restart to be able to use a newly discovered peer r= eflexive candidate after ICE completion because it represents a change in t= he destination, but I'm wondering if there are implementations that ena= ble a peer reflexive candidate to be used anyway.=C2=A0

Chris= ter Holmberg said:=C2=A0

"Hi,
Doing an ICE restart means you have to collect and e=
xchange candidates again. Of course one can do that once ICE failure has be=
en declared, and nothing prevents one from doing an ICE restart after that =
if one thinks the result will be different. But, the focus of the draft is =
not to declare ICE failure while working candidates may still arrive.

Having said that, one should of course not wait forever for the peer reflex=
ive candidates. The draft will not mandate a specific time value, but there=
 probably will be a little more text about things to take into consideratio=
n when determining how long to wait.

Regards,
=C2=A0
Christer"<= /div>
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--0000000000003e12a705869d6f39-- From nobody Wed Apr 17 03:20:22 2019 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A84120052; Wed, 17 Apr 2019 03:20:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ice@ietf.org Message-ID: <155549641566.29258.4144365382278393127@ietfa.amsl.com> Date: Wed, 17 Apr 2019 03:20:15 -0700 Archived-At: Subject: [Ice] I-D Action: draft-ietf-ice-pac-01.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 10:20:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment WG of the IETF. Title : Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) Authors : Christer Holmberg Justin Uberti Filename : draft-ietf-ice-pac-01.txt Pages : 5 Date : 2019-04-17 Abstract: During the process of creating a peer-to-peer connection, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and proposes a way to avoid premature failure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-pac/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ice-pac-01 https://datatracker.ietf.org/doc/html/draft-ietf-ice-pac-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-pac-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 17 03:28:56 2019 Return-Path: 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 21C0F1200A0; Wed, 17 Apr 2019 03:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 vVusqu5RbHIB; Wed, 17 Apr 2019 03:28:51 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150042.outbound.protection.outlook.com [40.107.15.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83C91120052; Wed, 17 Apr 2019 03:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZiKUfnuvGQ+j3giCL1PcJSkiYGqrKcYNT6D0HECQ294=; b=cmoPsQFjjHN6L0t8Q6V+gwpRqr2xt8vyX5LC6kfikSjWXGVJKnTM1cy6J92sSteGOJ95n+uLbQDQlkIrPcIByE0mpWhg3UKfVS6WDRTroNyTUxMRgjOSYBAeP4kUc1csGH9ny19FkC7NwWbsLf9SyR45XVMWrhaVIzYI6y6RV/4= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3337.eurprd07.prod.outlook.com (10.170.247.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Wed, 17 Apr 2019 10:28:47 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.009; Wed, 17 Apr 2019 10:28:47 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: "ice-chairs@ietf.org" , Justin Uberti Thread-Topic: Draft new version: ice-pac-01 Thread-Index: AQHU9QhXo2vOlQPpl0CTvTIa4Hk1oA== Date: Wed, 17 Apr 2019 10:28:47 +0000 Message-ID: <95FC4DD9-3F0C-48C6-8E16-480FCD8471D1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a46ece39-3955-4f71-02da-08d6c31f7a0e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB3337; x-ms-traffictypediagnostic: HE1PR07MB3337: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(366004)(396003)(199004)(189003)(6306002)(71200400001)(105586002)(54896002)(5640700003)(8936002)(486006)(68736007)(106356001)(71190400001)(2616005)(2351001)(5660300002)(83716004)(44832011)(2501003)(476003)(66066001)(102836004)(186003)(97736004)(26005)(256004)(6506007)(99286004)(82746002)(606006)(33656002)(58126008)(966005)(1730700003)(6436002)(558084003)(6116002)(7736002)(53936002)(236005)(6486002)(478600001)(2906002)(3846002)(81166006)(25786009)(81156014)(316002)(86362001)(6916009)(14454004)(36756003)(4326008)(54906003)(8676002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3337; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WvC7u4TlFKI+wj4wOhNJh6HMma3/Ip7G+6N50QocbuxJMtn+ySihmyLKw4Ji/eY2xPXqwdjdHAJEjB+xpKrgi5cG5bziy0rwB1KmSmje8T+B/CVYNPsX47LaBIa1KgMNI2ONS1HzqSuPuQ0BEWNYOgTpneZXtJ1++z3jsrIhCAkeC41heHo9SczU/v7eXkB/HStfvhpAjhByt0CdA5xtE7rqH4N83dzevK/zodwS9BULOz584fQmVKwr1UsDWI9gbTL7sOYQapo8OlcOqZFxY5p2XwT+rPpcvVsumvCQJVaDuKoBFBczNoTNtF/SYLfSitRO71rZoq8Y+vQB7fHQYDsmzN7I8yK4ZDqr3lIL396/mhpHf3udgiUJNmSTC+C1WsVFk444ke+y9k7HyhaeNPMPo0KKuQ23TQBf+j6RQ3M= Content-Type: multipart/alternative; boundary="_000_95FC4DD93F0C48C68E16480FCD8471D1ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a46ece39-3955-4f71-02da-08d6c31f7a0e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Apr 2019 10:28:47.6994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3337 Archived-At: Subject: [Ice] Draft new version: ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 10:28:54 -0000 --_000_95FC4DD93F0C48C68E16480FCD8471D1ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBtZXJnZWQgdGhlIGZvbGxvd2luZyBwdWxsIHJlcXVlc3RzOg0KDQpodHRw czovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQNCmh0dHBzOi8vZ2l0aHVi LmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL3B1bGwvNQ0KDQrigKZhbmQgc3VibWl0dGVkIGEgbmV3 IHZlcnNpb24gKC0wMSkgb2YgaWNlLXBhYy4NCg0KVGhlcmUgc2hvdWxkIGJlIG5vIG9wZW4gaXNz dWVzLCBzbyBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIHN0YXJ0IHRoZSBXR0xDIHByb2Nlc3Mu DQoNClJlZ2FyZHMNCg0KQ2hyaXN0ZXINCg== --_000_95FC4DD93F0C48C68E16480FCD8471D1ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <64F340D58D5B54419C64F54E3C42E7C7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSBoYXZlIG1lcmdlZCB0aGUgZm9sbG93aW5nIHB1bGwgcmVxdWVz dHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dp dGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzUiPjxzcGFu IGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxs LzU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPuKApmFuZCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTAxKSBv ZiBpY2UtcGFjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGVyZSBzaG91bGQgYmUgbm8gb3BlbiBpc3N1ZXMsIHNv IG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gc3RhcnQgdGhlIFdHTEMgcHJvY2Vzcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_95FC4DD93F0C48C68E16480FCD8471D1ericssoncom_-- From nobody Thu Apr 18 04:16:47 2019 Return-Path: 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 86237120317; Thu, 18 Apr 2019 04:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 UpdOF2BmjObb; Thu, 18 Apr 2019 04:16:34 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60087.outbound.protection.outlook.com [40.107.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BFE12031C; Thu, 18 Apr 2019 04:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W+/yvD/IGr64XLnn7uQjr0h/30tZ3NjpiKbqxojtcm8=; b=AQxjaJjDih1anZParsRtKbZyVvGQej4b/ghyohA+SOkcQHdd5Yqh6Q9l8RsqmmBzhpo6V952XXmq1Rjcwq6pelVX1wogYHTW9l3Tpwe+Mnu2Jtws0ITdh4/VDhayAQXlLuFivStuqkuu9UJ0xCJ6MB31KOMuBA9kc2gsKK6TehA= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB4331.eurprd07.prod.outlook.com (20.176.167.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 11:16:31 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1813.013; Thu, 18 Apr 2019 11:16:31 +0000 From: Christer Holmberg To: "ice@ietf.org" CC: "ice-chairs@ietf.org" , Justin Uberti Thread-Topic: Draft new version: ice-pac-01 Thread-Index: AQHU9QhXo2vOlQPpl0CTvTIa4Hk1oKZB+JEA Date: Thu, 18 Apr 2019 11:16:31 +0000 Message-ID: <56D1D166-20D9-40E2-94C8-2D7058CDBC69@ericsson.com> References: <95FC4DD9-3F0C-48C6-8E16-480FCD8471D1@ericsson.com> In-Reply-To: <95FC4DD9-3F0C-48C6-8E16-480FCD8471D1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2addc15-827c-4126-ec50-08d6c3ef4f62 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR07MB4331; x-ms-traffictypediagnostic: HE1PR07MB4331: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(396003)(346002)(366004)(136003)(39860400002)(199004)(189003)(71200400001)(4326008)(83716004)(606006)(71190400001)(4744005)(256004)(5660300002)(82746002)(7736002)(6506007)(446003)(53936002)(44832011)(102836004)(76176011)(3846002)(236005)(6116002)(186003)(6512007)(486006)(54896002)(86362001)(6306002)(26005)(97736004)(476003)(2906002)(5640700003)(11346002)(2616005)(81156014)(478600001)(54906003)(8936002)(68736007)(966005)(1730700003)(6246003)(2351001)(81166006)(8676002)(36756003)(6486002)(14454004)(66066001)(6436002)(6916009)(2501003)(229853002)(58126008)(316002)(25786009)(99286004)(33656002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4331; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xoFmBx0W5flyjBzyaDNJdsIG5AS5KqO2UkCJnk8RBnXmYdARZGykZa67DSohDZ585tF02Y3IXX8bWOy9UGm5GB9Df3sbntd5UI8eKku7M+dkCdqO8/b9Je8vwp/NVrqp0StzvIv0CuLx/1uQDSISSP61rZZWC4iORuM2rgr74hwOJ4oAOxkbuktymnPBbsaFvg819SWIOsF+8WKZUc9sBlaOMRYOEkNXMpmhxNsFFiXeXqjrNydPr48f81YVQO88XLanpPDXt3DbcVE6mu1SD/LHcsgwmhzCCDR79Cuw2SMkWhZcWOQdy8CZDan+SHDQJ7N+LjEV95VqdsA/INPO5tJmthqGu2R7Rl2zy4ZPiBBaAZ24QnDT0X7C9uRMkMV9P1B5d9pdsfdZrr0+YNREMcXHtFOUQtDwa9ornh6fwBs= Content-Type: multipart/alternative; boundary="_000_56D1D16620D940E294C82D7058CDBC69ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2addc15-827c-4126-ec50-08d6c3ef4f62 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 11:16:31.3985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4331 Archived-At: Subject: Re: [Ice] Draft new version: ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 11:16:46 -0000 --_000_56D1D16620D940E294C82D7058CDBC69ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIHdlcmUgc29tZSBjb21tZW50cyB0aGF0IEkgaGFkIGZvcmdvdCB0byBhZGRy ZXNzLCBzbyB0aGVyZSBpcyBnb2luZyB0byBiZSBhdCBsZWFzdCBvbmUgbW9yZSB2ZXJzaW9uIGJl Zm9yZSB3ZSBhcmUgcmVhZHkgZm9yIFdHTEMuDQoNClNvcnJ5IGZvciB0aGUgY29uZnVzaW9uLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpEYXRlOiBXZWRuZXNkYXksIDE3IEFwcmlsIDIw MTkgYXQgMTMuMjgNClRvOiAiaWNlQGlldGYub3JnIiA8aWNlQGlldGYub3JnPg0KQ2M6ICJpY2Ut Y2hhaXJzQGlldGYub3JnIiA8aWNlLWNoYWlyc0BpZXRmLm9yZz4sIEp1c3RpbiBVYmVydGkgPGp1 YmVydGlAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IERyYWZ0IG5ldyB2ZXJzaW9uOiBpY2UtcGFjLTAx DQoNCkhpLA0KDQpJIGhhdmUgbWVyZ2VkIHRoZSBmb2xsb3dpbmcgcHVsbCByZXF1ZXN0czoNCg0K aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC80DQpodHRwczovL2dp dGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzUNCg0K4oCmYW5kIHN1Ym1pdHRlZCBh IG5ldyB2ZXJzaW9uICgtMDEpIG9mIGljZS1wYWMuDQoNClRoZXJlIHNob3VsZCBiZSBubyBvcGVu IGlzc3Vlcywgc28gbXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBzdGFydCB0aGUgV0dMQyBwcm9j ZXNzLg0KDQpSZWdhcmRzDQoNCkNocmlzdGVyDQo= --_000_56D1D16620D940E294C82D7058CDBC69ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <61735C5610E81D46AB7B0A49A3934B27@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCAy LjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZXJlIHdlcmUg c29tZSBjb21tZW50cyB0aGF0IEkgaGFkIGZvcmdvdCB0byBhZGRyZXNzLCBzbyB0aGVyZSBpcyBn b2luZyB0byBiZSBhdCBsZWFzdCBvbmUgbW9yZSB2ZXJzaW9uIGJlZm9yZSB3ZSBhcmUgcmVhZHkg Zm9yIFdHTEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNvcnJ5IGZvciB0aGUgY29uZnVzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDE3IEFw cmlsIDIwMTkgYXQgMTMuMjg8YnI+DQo8Yj5UbzogPC9iPiZxdW90O2ljZUBpZXRmLm9yZyZxdW90 OyAmbHQ7aWNlQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7aWNlLWNoYWlyc0Bp ZXRmLm9yZyZxdW90OyAmbHQ7aWNlLWNoYWlyc0BpZXRmLm9yZyZndDssIEp1c3RpbiBVYmVydGkg Jmx0O2p1YmVydGlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+RHJhZnQgbmV3 IHZlcnNpb246IGljZS1wYWMtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBoYXZlIG1lcmdlZCB0aGUgZm9sbG93 aW5nIHB1bGwgcmVxdWVzdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQiPjxzcGFuIGxhbmc9IkVO LVVTIj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9wdWxsLzQ8L3NwYW4+ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC81Ij48c3BhbiBsYW5nPSJFTi1V UyI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvcHVsbC81PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij7igKZhbmQgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0wMSkgb2YgaWNlLXBhYy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+VGhlcmUgc2hvdWxkIGJlIG5vIG9wZW4gaXNzdWVzLCBzbyBteSBzdWdnZXN0 aW9uIHdvdWxkIGJlIHRvIHN0YXJ0IHRoZSBXR0xDIHByb2Nlc3MuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2Fy ZHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_56D1D16620D940E294C82D7058CDBC69ericssoncom_-- From nobody Thu Apr 18 14:44:29 2019 Return-Path: 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 38B091203CD for ; Thu, 18 Apr 2019 14:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RHvjnN9wdWzS for ; Thu, 18 Apr 2019 14:44:25 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 6F1F312037E for ; Thu, 18 Apr 2019 14:44:25 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id s7so3054622iom.12 for ; Thu, 18 Apr 2019 14:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wXIMa+rat9aHiq4UkDKMbPNA2tku1KV9k2Mf/dGAhDs=; b=V3Vas1mrgjjEGUUZiw1wO+4JeDZyDC576irNSSNhtS6s9He4PzZ6S9Fx5Hd7doyHl5 unNjHtRGwFnyjY7LJdGB5KXjjk3IX7UOGn1iDWvUw5uIarOz6yv6e3/6B8DnEZ0gB/qS /7Fv2j11mHESlTQkzCyfc++/N/IluAFCDUcei0prD0yKQcAp8KzbJsvgtoeOw1RpX8jQ iHpL8y24SzeCDRPQOEHLJhZVasC8z+6IbQWs4gO0VyBLN8hEjeI1i/eA+eieImx96Snx Gv5tRCAoydNSsEMonofr9ATRAJ477rnQ+Zc8M64CmgCyPmDVXJn2RoysxoPNnZxumAva yt3Q== 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=wXIMa+rat9aHiq4UkDKMbPNA2tku1KV9k2Mf/dGAhDs=; b=pbX7LO1suWyRCwoFuuZVGX7gl8waMbigiG7ihLxB/P0YeNP8DtZ18fStA2fGfsMPcn URFQHUS/AoMWnfgylQ/RpqDiL5G6SMhEX3PVTtC2pRuvY4fr/02paR9D03xFpodMLLLm klR5rAvtUJBSjBX650dKRf/1sb17/Zhx1uIxLCyOJMmi8tpqb68RURT5NyArarm1H6bY fqwUyx56Di5Ngon6bQjJ3GJR0NQ5VBpEp2HoexCMDNEZnKoOByyfL7aHJHiR1R6c2oEj 6shDLSuojMOnfM7pMBv4AG9bU22RSpsGvx8TiGwFMFjOrg5I7oYGpz8HdHFHcU5g2QmC 5DCw== X-Gm-Message-State: APjAAAWARpTZs0Mg4ML/CWz6bZrl/U/1C8rFpCSnFqBpMC3X8x8aQ6Er DbnKVmkjmNboi8XEf6wgNxBllotZTr6QokBcP4VKZA== X-Google-Smtp-Source: APXvYqzjo7U/PbmuOzgMcf4OR7DrlJl2eftXt1kijPxwgLV4/SSPP3gXhEBaqyX2OXej18fOpD8/BGcGwSD5MxJ/Ci0= X-Received: by 2002:a6b:d016:: with SMTP id x22mr339305ioa.181.1555623864230; Thu, 18 Apr 2019 14:44:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 18 Apr 2019 14:44:12 -0700 Message-ID: To: Roman Shpount Cc: Bernard Aboba , Christer Holmberg , ICE WG Content-Type: multipart/alternative; boundary="000000000000d5858d0586d4e744" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:44:28 -0000 --000000000000d5858d0586d4e744 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tracking this in https://github.com/cdh4u/draft-ice-pac/issues/7 On Mon, Apr 15, 2019 at 8:33 PM Justin Uberti wrote: > I don't think there's an easy way to use a newly discovered prflx > candidate, given the rules about changing the selected pair after ICE has > completed, but I think this implies that one shouldn't be too hasty to > declare ICE completion either. > > Since some implementations may malfunction if they don't get a > USE-CANDIDATE quickly, I am not sure if we can wait the full STUN timeout > interval, but perhaps a somewhat shorter delay (e.g. a few seconds) could > be recommended before sending USE-CANDIDATE. > > On Mon, Apr 8, 2019 at 10:55 AM Roman Shpount wrote: > >> Bernard, >> >> The big issue here is when ICE agent can release candidates. Normally, >> when ICE nomination completes, unused ICE candidates, such as unused loc= al >> interfaces or TURN candidates are released after a short (3 second) >> timeout. Because of this, running new ICE connectivity checks without IC= E >> re-start (which means new ufrag and pwd, signaling exchange and allowing >> remote to gather new candidates) is likely not going to succeed. For >> instance, one party can move from IPv4 to IPv6 network, but the other pa= rty >> would already release its lPv6 candidate, which will cause all connectiv= ity >> checks to fail. Also, peer reflexive candidates are not gathered after = ICE >> nomination is complete. Changing this will not be a backwards compatible >> change. This is completely different from the use case discussed in ice-= pac >> draft, which deals with ICE nomination failing before peer reflexive >> candidates are discovered. All that ice-pac draft does is specifying a >> delay for ICE nomination completion in the absence of remote candidates, >> not collecting remote candidates after nomination is complete. >> >> Regards, >> _____________ >> Roman Shpount >> >> >> On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba >> wrote: >> >>> A question has arisen recently about the behavior with respect to peer >>> reflexive candidates discovered *after* ICE completion: >>> https://github.com/w3c/webrtc-nv-use-cases/issues/10 >>> >>> draft-holmberg-ice-pac doesn't relate to that question, but I'm >>> wondering whether we might also see significant differences in >>> implementation behavior there as well. RFC 8445 appears to require an I= CE >>> restart to be able to use a newly discovered peer reflexive candidate a= fter >>> ICE completion because it represents a change in the destination, but I= 'm >>> wondering if there are implementations that enable a peer reflexive >>> candidate to be used anyway. >>> >>> Christer Holmberg said: >>> >>> "Hi, >>> >>> Doing an ICE restart means you have to collect and exchange candidates = again. Of course one can do that once ICE failure has been declared, and no= thing prevents one from doing an ICE restart after that if one thinks the r= esult will be different. But, the focus of the draft is not to declare ICE = failure while working candidates may still arrive. >>> >>> Having said that, one should of course not wait forever for the peer re= flexive candidates. The draft will not mandate a specific time value, but t= here probably will be a little more text about things to take into consider= ation when determining how long to wait. >>> >>> Regards, >>> >>> >>> Christer" >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --000000000000d5858d0586d4e744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, Apr 15, 2019 at 8:33 PM Justin Uberti <juberti@google.com> wrote:
I don't think there&#= 39;s an easy way to use a newly discovered prflx candidate, given the rules= about changing the selected pair after ICE has completed, but I think this= implies that one shouldn't be too hasty to declare ICE completion eith= er.

Since some implementations may malfunction if they d= on't get a USE-CANDIDATE quickly, I am not sure if we can wait the full= STUN timeout interval, but perhaps a somewhat shorter delay (e.g. a few se= conds) could be recommended before sending USE-CANDIDATE.

On Mon, Apr = 8, 2019 at 10:55 AM Roman Shpount <roman@telurix.com> wrote:
Bernard,

=
The big issue here is when ICE agent can release candidates. Normally,= when ICE nomination completes, unused ICE candidates, such as unused local= interfaces or TURN candidates are released after a short (3 second) timeou= t. Because of this, running new ICE connectivity checks without ICE re-star= t (which means new ufrag and pwd, signaling exchange and allowing remote to= gather new candidates) is likely not going to succeed. For instance, one p= arty can move from IPv4 to IPv6 network, but the other party would already = release its lPv6 candidate, which will cause all connectivity checks to fai= l.=C2=A0 Also, peer reflexive candidates are not gathered after ICE nominat= ion is complete. Changing this will not be a backwards compatible change. T= his is completely different from the use case discussed in ice-pac draft, w= hich deals with ICE nomination failing before peer reflexive candidates are= discovered. All that ice-pac draft does is specifying a delay for ICE nomi= nation completion in the absence of remote candidates, not collecting remot= e candidates after nomination is complete.

Regards= ,
_____________
Roman Shpo= unt


On Mon, Apr 8, 2019 at 1:28 PM Bernard Aboba <<= a href=3D"mailto:bernard.aboba@gmail.com" target=3D"_blank">bernard.aboba@g= mail.com> wrote:
A question has arisen recently about the beha= vior with respect to peer reflexive candidates discovered *after* ICE compl= etion:=C2=A0

draft-holmberg-ice-pac doesn= 9;t relate to that question, but I'm wondering whether we might also se= e significant differences in implementation behavior there as well. RFC 844= 5 appears to require an ICE restart to be able to use a newly discovered pe= er reflexive candidate after ICE completion because it represents a change = in the destination, but I'm wondering if there are implementations that= enable a peer reflexive candidate to be used anyway.=C2=A0

C= hrister Holmberg said:=C2=A0

"Hi,
Doing an ICE restart=
 means you have to collect and exchange candidates again. Of course one can=
 do that once ICE failure has been declared, and nothing prevents one from =
doing an ICE restart after that if one thinks the result will be different.=
 But, the focus of the draft is not to declare ICE failure while working ca=
ndidates may still arrive.

Having said that, one should of course not wait forever for the peer reflex=
ive candidates. The draft will not mandate a specific time value, but there=
 probably will be a little more text about things to take into consideratio=
n when determining how long to wait.

Regards,
=C2=A0
Christer"<= /div>
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000d5858d0586d4e744-- From nobody Thu Apr 18 14:45:44 2019 Return-Path: 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 A9F58120435 for ; Thu, 18 Apr 2019 14:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QNpo9-wOVzSY for ; Thu, 18 Apr 2019 14:45:32 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 3CFED1203FA for ; Thu, 18 Apr 2019 14:45:32 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id z17so8968422itc.1 for ; Thu, 18 Apr 2019 14:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AvEHNOh7eVB9a7xJuy0rdqFHTJYg6ehEYM5c36mS0n8=; b=vT5ATfNalYq5JhNpHPeh9SYKlUDIy8KlzHUGOiVR8L2pofwu42M5s0wy1iZMRzOnMz FEYdmv8wz+uOW4bFCZL/GNdeMGHrXlfi1NU/6aDc1NUzYLNAGxDx7YiGiVE/lUcr3btl C0zwNIIXl19rXaB4iRzYqwEC0DI/m2rGRsNVPs8yypDP4hhQaPmKOToDrGguOiXnhS9i Q/CGKPK3R/QYpBoSFiZUrgVhy1CwkRIIgVkz76cAyphZLstEBzcQjOpxceljTlE8Jl2J 5t+vWl/BFihxSgOT/77XqeotKmzZ13TvYr81qY0fgtTtywDFzPstbz7y6ycHW/k0WaP3 fjWA== 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=AvEHNOh7eVB9a7xJuy0rdqFHTJYg6ehEYM5c36mS0n8=; b=bKUKF/rvTBSjoOtpUHaavj6VRVpZ38v0sNtb0m6/omYKx+d9HQgorvsOF3+bIt96QC J2b1UJqrsAATClPtpHYRdOTVszyF8uHiDiarbslMBZMCxWSK7Syhy/sUI4s0S9aI+jKk 1okOtAvt04WKuQoPRj7/Y76BcEHdQMmKhtAvx/WRw10SjoWN8R6zdr0YSGPyqOM5m0A3 YctXNbWZezDN4jIjvDsabNwMuZK1X6LIlBttw9L37v1Ly0Ina+fC+9iRvbxh6LBBOPb/ OHDyVnTrnRD66jMTUisOZ2M3Sd8IaBuKlid5712VZoyPPgYgQIrlGdEFFH+l/c2Oi7yC sB4A== X-Gm-Message-State: APjAAAUZ2QSqWf7cqSwz8ECkH83fWFowsBsTGXVshq3DlddYFKsEvQUm B+DnfTEEM5uL9Kkx5oNuW+ZXhRcNYsWheUKTmOdN5m6lYEE= X-Google-Smtp-Source: APXvYqydgaM73GKcHKbNFOsAuc8tEJx3cdVUJK+u+Opk6F33LcHPSX9r7qe/faaMG76ce+3TFYnr7U4J2mgYyVgI0ek= X-Received: by 2002:a24:381:: with SMTP id e123mr218599ite.8.1555623931083; Thu, 18 Apr 2019 14:45:31 -0700 (PDT) MIME-Version: 1.0 References: <9217809f-b09a-321e-34b6-2cf6fee9c07b@mozilla.com> In-Reply-To: <9217809f-b09a-321e-34b6-2cf6fee9c07b@mozilla.com> From: Justin Uberti Date: Thu, 18 Apr 2019 14:45:19 -0700 Message-ID: To: Byron Campen Cc: ICE WG Content-Type: multipart/alternative; boundary="000000000000d17a8a0586d4eb88" Archived-At: Subject: Re: [Ice] Firefox review of draft-ietf-ice-pac-00 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:45:43 -0000 --000000000000d17a8a0586d4eb88 Content-Type: text/plain; charset="UTF-8" Does this mean that you will wait forever if no candidates are provided? On Tue, Mar 26, 2019 at 6:57 AM Byron Campen wrote: > This looks fine to me. It isn't quite the same as what Firefox does > already, but it will do the trick. (we set the timer when we have both > started ICE, _and_ have a trickle candidate) > > > Best regards, > > Byron Campen > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --000000000000d17a8a0586d4eb88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does this mean that you will wait forever if no candidates= are provided?

On Tue, Mar 26, 2019 at 6:57 AM Byron Campen <bcampen@mozilla.com> wrote:
=C2=A0=C2=A0=C2=A0=C2=A0 Th= is looks fine to me. It isn't quite the same as what Firefox does
already, but it will do the trick. (we set the timer when we have both
started ICE, _and_ have a trickle candidate)


Best regards,

Byron Campen

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000d17a8a0586d4eb88-- From nobody Thu Apr 18 14:50:22 2019 Return-Path: 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 1CBBA1203E1 for ; Thu, 18 Apr 2019 14:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u-GahRXDAuUO for ; Thu, 18 Apr 2019 14:50:19 -0700 (PDT) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 084C512014F for ; Thu, 18 Apr 2019 14:50:19 -0700 (PDT) Received: by mail-it1-x135.google.com with SMTP id v8so8991272itf.0 for ; Thu, 18 Apr 2019 14:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Ic5hCmAbgq6QTSpEJ4bOpTUFrb9zkYEK68uSk/uMck=; b=T8ADQQqRi33MxStahYOciEBmAGvRarC2g7up0Oo4GdaY/qT2TqSQMnFLSiZcSY533Y aZ2W7OpGQxQHCiBz/xf1DfEROpKLSDxuM2p9AJ1iqpo/hsqzc+1hK6JyvLn3Rdf9PEqW Rxo1zwGgTlZ9BeK5WjINCaRoaz5qpGPUHgLQu57MydaOUxEy1TdI9eyP2IET+1F1E0kW FZC2fo8FHC4h8NQThMaip0m3J9I/7Bf6mNGk/kSmsRG7t7MaGlUJes+qew9wu8Ig0R92 N4pZ/7SiDLD15iszcJu7pVbqmsXJzjwNTgwYWciAYV68zdGbF2QvclQrs0x1egsi/pb9 2XtA== 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=8Ic5hCmAbgq6QTSpEJ4bOpTUFrb9zkYEK68uSk/uMck=; b=J6WjdgoP+HFvfxPGDrdHNMUlAMMImVIr7a4FuHNfcy45uNIIXDzKpa9yMtJSq7J0nM PN6d58WF5oSvzKXHgDr7+QUwIVXMRI/NtEBouw8e7a9g0yC7cLREDBbVsTsBfBYZPnoy 7asmh3A6qePNoQsnUCVZbgBLC7oJbDe9eGOD7sd98QwuxQITGuwplhrgyh7mQvLpDkQM ih0S4Za/x/5s6bOYPbQkn4tylb1l66AdNHRVC3HRQ2ZywxvSNg3X0Gv8iy+heV0ej6Kx +ChGXWUqLylgksCfesAZ4YTGaFvJQddasuDUImxtyTuSdsm3ji/nI1DJM6HVmSeV57hN y0oA== X-Gm-Message-State: APjAAAWXgrykph+SX131RqAATVKLfeW3j7u0BK7YJsvYgIS+/hkqkl2g S4ylP3tOA1u6ejzb4WUHuhWEXpRAyYKeRlCE/Q+bpxeL9+k= X-Google-Smtp-Source: APXvYqx0vljs/YzYRAkYyTiX4VEmDf8gepNsD29zeLfIUk9gEZEyGXxK5syVe02+wwyxEOgPHqJgu7moF9L3nJWPb5c= X-Received: by 2002:a24:381:: with SMTP id e123mr233929ite.8.1555624217958; Thu, 18 Apr 2019 14:50:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 18 Apr 2019 14:50:06 -0700 Message-ID: To: Christer Holmberg Cc: Qingsi Wang , "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000eab8480586d4fc61" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:50:21 -0000 --000000000000eab8480586d4fc61 Content-Type: text/plain; charset="UTF-8" Note that the app can always decide to declare failure at any point and invoke an ICE restart. On Sun, Mar 31, 2019 at 1:12 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Doing an ICE restart means you have to collect and exchange candidates > again. Of course one can do that once ICE failure has been declared, and > nothing prevents one from doing an ICE restart after that if one thinks the > result will be different. But, the focus of the draft is not to declare ICE > failure while working candidates may still arrive. > > > > Having said that, one should of course not wait forever for the peer > reflexive candidates. The draft will not mandate a specific time value, but > there probably will be a little more text about things to take into > consideration when determining how long to wait. > > > > Regards, > > > > Christer > > > > *From: *Ice on behalf of Qingsi Wang 40google.com@dmarc.ietf.org> > *Date: *Saturday, 30 March 2019 at 3.05 > *To: *"ice@ietf.org" > *Subject: *[Ice] Review of draft-holmberg-ice-pac-01 > > > > If all available candidate pairs have either performed triggered checks or > sent check response, but have timed out their checks however, should we > cancel the timer and conclude a failure? The rationale is to wait for > inbound checks, but if at least one round of checks are received, it's > unclear to me if the waiting would benefit compared to allowing the app > trigger an ICE restart after firing an failure. > > > > The rest looks good to me. > > > > Best, > > Qingsi > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --000000000000eab8480586d4fc61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Note that the app can always decide to declare failure at = any point and invoke an ICE restart.

On Sun, Mar 31, 2019 at 1:12 AM Christe= r Holmberg <christer.h= olmberg@ericsson.com> wrote:

Hi,

=C2=A0

Doing an ICE restart means you = have to collect and exchange candidates again. Of course one can do that on= ce ICE failure has been declared, and nothing prevents one from doing an IC= E restart after that if one thinks the result will be different. But, the focus of the draft is not to declare IC= E failure while working candidates may still arrive.

=C2=A0

Having said that, one should of= course not wait forever for the peer reflexive candidates. The draft will = not mandate a specific time value, but there probably will be a little more= text about things to take into consideration when determining how long to wait.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice <ice-bounces@ietf.org> o= n behalf of Qingsi Wang <qingsi=3D40google.com@dmarc.ietf.org>
Date: Saturday, 30 March 2019 at 3.05
To: "ice@ietf= .org" <ice@ie= tf.org>
Subject: [Ice] Review of draft-holmberg-ice-pac-01

=C2=A0

If all available candidate pairs have either perform= ed triggered checks or sent check response, but have timed out their checks= however, should we cancel the timer and conclude a failure? The rationale = is to wait for inbound checks, but if at least one round of checks are received, it's unclear to me if th= e waiting would benefit compared to allowing the app trigger an ICE restart= after firing an failure.

=C2=A0

The rest looks good=C2=A0to me.

=C2=A0

Best,

Qingsi

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000eab8480586d4fc61-- From nobody Thu Apr 18 14:51:32 2019 Return-Path: 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 09EF81203E9 for ; Thu, 18 Apr 2019 14:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 vXLB73NP4zeI for ; Thu, 18 Apr 2019 14:51:28 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 B9C75120404 for ; Thu, 18 Apr 2019 14:51:28 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id s7so3066507iom.12 for ; Thu, 18 Apr 2019 14:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ljJFlT5WJivNWfdp12cBQU4KK/pfSY9MEmkj6UdGppE=; b=HzCGPAwK+VamGknlB2ThE8C76wSRBW0tljRElRKD1fxhsbNgnVx9iAwbwz35UWTOcD RXCNw/bNWKQAh5OFN4K63MpE+I3BlpHlV074igcBQcCMEzyRl3NlZGb2uiOJoiRDCgLG Y7tMXmYF463iiAZnvtaUQz3OE9jVXQVTG9ZyuzgDnVkFJm80y+Neo653czwE7GeDtv0e HYL7sxTu69PRrpilvxqFO+OZcWi/nW7Cpy9cqFxFDZAyOnhgVb/EncZGkaG21A0m5ymN BtZoQalXLr77efsGxqmTsBi7L+LGaSiB7RSugvMswG1GFRE9p7MvzK5SO/Nb2KWo/mOS IhKQ== 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=ljJFlT5WJivNWfdp12cBQU4KK/pfSY9MEmkj6UdGppE=; b=ZC6uS+sUx6ZroUTEP9NQBcTPWxv5Wbozh3lDw6hI6cyqNGpMPEDOP07kctXPXO7MsI itxB6btfM335o5I/7H8Y5Lc52MfgJ1nkGgApFSTS1yzFG6vdVdfP9qhRyKSVKiMCatYO HFuOFuV3TuygNFM4fzA4XhSsUeWFL1gxnlXjak8boQbKeGHgkQ7zDzakW80eHMOSBm22 v36i6UQjmMEAgfr/oGF+ZwpAuuFi72QGYAFQJL8JGOgfBrlkS2AXKgpZ5YRgUzb31f/Y vHrQAXwkXA2CNenyIAL/BuJN9hYinf2skPnThbQAjES4wtk/uCK6PWCOUFT5LSMVx9bq 3Hqg== X-Gm-Message-State: APjAAAXAhS2AEgGymeHXp0FJTslvNH8SVKOz1aeYwII2Iyn4UwEcSYgw 9XyoHxDp6uTV8akbKs5blDY4VCkJAXzGVQVlx05Llg== X-Google-Smtp-Source: APXvYqzxdzR9cUR9Kix3JRAo7b4sfuKgVN8lYEAJY2WBGmQEzv8uuUNnUyOM/3tqQpPg56Nay1cCBciQ3f9h5+XtP7A= X-Received: by 2002:a5e:c24c:: with SMTP id w12mr386608iop.101.1555624287560; Thu, 18 Apr 2019 14:51:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 18 Apr 2019 14:51:12 -0700 Message-ID: To: Christer Holmberg Cc: Qingsi Wang , "ice@ietf.org" Content-Type: multipart/alternative; boundary="00000000000010e8320586d501b5" Archived-At: Subject: Re: [Ice] Review of draft-holmberg-ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:51:31 -0000 --00000000000010e8320586d501b5 Content-Type: text/plain; charset="UTF-8" Tracking this in https://github.com/cdh4u/draft-ice-pac/issues/10 On Thu, Apr 18, 2019 at 2:50 PM Justin Uberti wrote: > Note that the app can always decide to declare failure at any point and > invoke an ICE restart. > > On Sun, Mar 31, 2019 at 1:12 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> Doing an ICE restart means you have to collect and exchange candidates >> again. Of course one can do that once ICE failure has been declared, and >> nothing prevents one from doing an ICE restart after that if one thinks the >> result will be different. But, the focus of the draft is not to declare ICE >> failure while working candidates may still arrive. >> >> >> >> Having said that, one should of course not wait forever for the peer >> reflexive candidates. The draft will not mandate a specific time value, but >> there probably will be a little more text about things to take into >> consideration when determining how long to wait. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From: *Ice on behalf of Qingsi Wang > 40google.com@dmarc.ietf.org> >> *Date: *Saturday, 30 March 2019 at 3.05 >> *To: *"ice@ietf.org" >> *Subject: *[Ice] Review of draft-holmberg-ice-pac-01 >> >> >> >> If all available candidate pairs have either performed triggered checks >> or sent check response, but have timed out their checks however, should we >> cancel the timer and conclude a failure? The rationale is to wait for >> inbound checks, but if at least one round of checks are received, it's >> unclear to me if the waiting would benefit compared to allowing the app >> trigger an ICE restart after firing an failure. >> >> >> >> The rest looks good to me. >> >> >> >> Best, >> >> Qingsi >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > --00000000000010e8320586d501b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 18, 2019 at 2:50 PM Justin Uberti <juberti@google.com> wrote:
Note that the app can alw= ays decide to declare failure at any point and invoke an ICE restart.
=
On Sun= , Mar 31, 2019 at 1:12 AM Christer Holmberg <christer.holmberg@ericsson.com= > wrote:

Hi,

=C2=A0

Doing an ICE restart means you = have to collect and exchange candidates again. Of course one can do that on= ce ICE failure has been declared, and nothing prevents one from doing an IC= E restart after that if one thinks the result will be different. But, the focus of the draft is not to declare IC= E failure while working candidates may still arrive.

=C2=A0

Having said that, one should of= course not wait forever for the peer reflexive candidates. The draft will = not mandate a specific time value, but there probably will be a little more= text about things to take into consideration when determining how long to wait.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice <ice-bounces@ietf.org> o= n behalf of Qingsi Wang <qingsi=3D40google.com@dmarc.ietf.org>
Date: Saturday, 30 March 2019 at 3.05
To: "ice@ietf= .org" <ice@ie= tf.org>
Subject: [Ice] Review of draft-holmberg-ice-pac-01

=C2=A0

If all available candidate pairs have either perform= ed triggered checks or sent check response, but have timed out their checks= however, should we cancel the timer and conclude a failure? The rationale = is to wait for inbound checks, but if at least one round of checks are received, it's unclear to me if th= e waiting would benefit compared to allowing the app trigger an ICE restart= after firing an failure.

=C2=A0

The rest looks good=C2=A0to me.

=C2=A0

Best,

Qingsi

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--00000000000010e8320586d501b5-- From nobody Thu Apr 18 14:52:12 2019 Return-Path: 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 A62A81203E9 for ; Thu, 18 Apr 2019 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uQqQNeDV2sQr for ; Thu, 18 Apr 2019 14:52:07 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 3C0D112014F for ; Thu, 18 Apr 2019 14:52:07 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id k64so5630433itb.5 for ; Thu, 18 Apr 2019 14:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qxayuzd725UcEYYLqsDpq+RMtwz/ME9sARDbMbkOjzI=; b=E2qJWN1nj6TWf1eQGDajtjOydjZjlVDObGvg68lfs9pXOI/FblMFjKROddBNtUKkvx rsc3DPzFDACiN40E6mcI88BQMyzZrmOjPUypFSfeIL0224xiy3b7iKI3gzXiTPK7VTkZ 0yLgqxTSQvE43xNPhKUvHius/8JjQryKDpocpuc4SFXdUeLmN9IvTpATiLYWS63OnsoA LmOTo99CjWB5YnHfmbeH5/wxbxE/1hWgJLXYhkeUi/miWuR3n9skgiEvY7pzXnsqxZU2 KQpa9pZSVxuBSEHocONe3AozQq7bkrPChtyZc9qFU7bdY4yFjxvnJGwh6jY+DOAbJqn8 FycQ== 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=Qxayuzd725UcEYYLqsDpq+RMtwz/ME9sARDbMbkOjzI=; b=Do+RlzRdtfVUr8qTChnv6ffFcYs0JmNHrNwC6HtCOMc2Vepet07LcldKQmwsR4mq6X 1qEbfkeGYT8YsJuFEmwtbKCEQBMBoesSxIk1KsQYnA5ZpadsCkzUKHTcTzFVde3Qx8Wo faa6PrXbiz8HyiWewl93AGnu2cBJ+dDJTyu4PAOQSJn5piQB/cdjw/IQwgNz9FBIAar8 K8ZW7g2yLxtYuE4VDnNy7K7vxfnjkaTbzfHDiZodMfiGrFQ2alQvPxVrsGYnfzTKQdwC arHrZqWnEu6Ji0CZkqwFHarvmLzwfr5vt+0FhBT0vQ0LkYIDR8ddGMnhBmaBEYTl6/Aj UzOQ== X-Gm-Message-State: APjAAAUv70fqCFp7Ece14VHG5xb7uuU5Oz18ukOD2cTdm14fKF/n34pN zEvbNEKtjkxcEH4NMcxmA1I7SgiYERkoDmaUZXsVfQ== X-Google-Smtp-Source: APXvYqzSRqxA93FJ0N2CieyX71w3TLEQTzrXZu5Uf2ste8Azfh0hMuzCjzeqSnZMdJHrxwnf4wSGE/Js9txmFN3+06o= X-Received: by 2002:a24:381:: with SMTP id e123mr239112ite.8.1555624326233; Thu, 18 Apr 2019 14:52:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 18 Apr 2019 14:51:54 -0700 Message-ID: To: Christer Holmberg Cc: Peter Thatcher , ICE WG Content-Type: multipart/alternative; boundary="0000000000005ed27a0586d503cc" Archived-At: Subject: Re: [Ice] Thoughts on the "remote side gives 0 candidates" issue X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:52:11 -0000 --0000000000005ed27a0586d503cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Tracking the points raised here in https://github.com/cdh4u/draft-ice-pac/issues/9 and https://github.com/cdh4u/draft-ice-pac/issues/8 On Mon, Mar 11, 2019 at 9:30 AM Justin Uberti wrote: > > > On Mon, Mar 11, 2019 at 9:06 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> > Anyway, here's what I've thought of so far: >> >> > >> >> > 1. Yes, these all are issues (the 3 scenarios described >> in draft-holmberg-ice-premature.xml) for a strict ICE impl that is what = you >> might call "impatient". >> >> >> >> Ice will melt if you wait too long=E2=80=A6 ;) >> >> >> >> > 2. I'm guessing that in practice all ICE impls will have some timeout >> (be "patient"), but I agree that writing that down in an RFC is a good i= dea. >> >> > >> >> > 3. Doing it in the ICE WG makes sense. >> >> > >> >> > 4. I'd prefer to call it "ICE patience" or "Patient ICE" rather than >> "no premature failure". Then it's a virtue rather than a lack of a prob= lem >> :). >> >> >> >> So, just to clarify, you suggest =E2=80=9CInteractive Connectivity Estab= lishment >> (ICE) Patience=E2=80=9D as the title, not only in the draft name? >> >> >> >> Works for me. >> >> >> >> > 5. The current draft says "MUST wait for" and "N SHOULD be X". But >> together, that amounts to "SHOULD wait for X", so the whole >> >> > RFC ends up being a big SHOULD. Is that normal for an RFC to only >> have SHOULDs and not MUSTs? Seems less meaningful because >> >> > you can't rely on the remote side doing the right thing. >> >> >> >> We did not want to mandate a specific duration. An endpoint can determin= e >> the duration value based on many things, including the number of candida= tes >> it provides and/or the number of streams, the reliability of the network >> (see below) etc etc etc. >> > > This is a reasonable point. We could say that the implementation MUST wai= t > for enough time to receive peer-reflexive candidates. This value SHOULD b= e > the local connectivity check timeout. > >> >> >> > 6. The more I think about the timeout should be, the more I think thi= s >> problem is bigger than the issues outlined in the draft. >> >> > If you have very slow signaling, it's possible that you will end up in >> this same situation regardless of how many candidates are >> >> > signaled (since the slow signaling prevents the candidates from >> getting there). For example: >> >> > >> >> > - Caller initiates ICE with no candidates >> >> > - Callee receives offer with no candidates, sets a timer of N seconds, >> and sends back an answer with several candidates >> >> > - Caller receives candidates after N seconds and sends connectivity >> checks >> >> > - Callee times out and goes to failed state >> >> > - Callee receives connectivity checks, but it's too late >> >> > >> >> > To avoid this problem, the timeout the callee uses must be based on th= e >> expected signaling delay. So, I think our "SHOULD be X" should >> incorporate signaling delay" >> > >> >> Absolutely. We can for sure add more guidance regarding things an >> endpoint has to take into consideration when setting the N value. >> > > Maybe, but this number will never be precise. The connectivity check > timeout itself is fairly arbitrary, but large enough to effectively addre= ss > the problem. The existing text has a mention of this. > >> >> >> > 7. I wonder if we should include a suggested workaround for RFC 8445 >> clients that are "impatient". For example, if you trickle, do not >> >> > send "end-of-candidates" to the remote side until after N seconds (to >> prevent it from going to the failed state). >> >> >> >> Note that the draft text only covers the case when an endpoint receives >> candidates, discards all of them, and waits for peer-reflexive candidate= s >> to arrive. These could be initial candidates, or trickled candidates. >> >> >> >> But, when it comes to trickle, and how long an endpoint waits for the >> peer to SIGNAL additional candidates, I think that shall be covered in >> trickle. >> > > TBH, I think it sort of invalidates end-of-candidates, since it's now > clear that you can't start pruning upon receiving end-of-candidates. We > might just want to never send it (and perhaps remove it in a future > revision). > --0000000000005ed27a0586d503cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 11, 2019 at 9:30 AM Justin Ube= rti <juberti@google.com> wr= ote:


On Mon, Mar 11, 2019 at 9:06 AM Christer Holmber= g <c= hrister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

> Anyway, here's what I&= #39;ve thought of so far:

>=C2=A0=

> 1.=C2=A0 Yes, these all are issues (the 3 scena= rios described in=C2=A0draft-holmberg-ice-premature.xml) for a strict ICE i= mpl that is what you might call "impatient".=C2=A0=C2=A0

=C2=A0

Ice will melt if you wait too l= ong=E2=80=A6 ;)

=C2=A0

> 2.=C2=A0 I'm guessing that in practice all = ICE impls will have some timeout (be "patient"), but I agree that= writing that down in an RFC is a good idea.

>=C2=A0

> 3.=C2=A0 Doing it in the ICE WG makes sense.=

>=C2=A0

> 4.=C2=A0 I'd prefer to call it "ICE pa= tience" or "Patient ICE" rather than "no premature fail= ure".=C2=A0 Then it's a virtue rather than a lack of a problem :).=

=C2=A0

So, just to clarify, you sugges= t =E2=80=9CInteractive Connectivity Establishment (ICE) Patience=E2=80=9D a= s the title, not only in the draft name?

=C2=A0

Works for me.

=C2=A0

> 5.=C2=A0 The current draft says "MUST wait= for" and "N SHOULD be X".=C2=A0 But together, that amounts = to "SHOULD wait for X", so the whole

> RFC ends up being a big SHOULD.=C2=A0 Is that normal for an RFC to only have SHOULDs and not MUSTs?=C2=A0 = Seems less meaningful because

> you can't rely on the remote side doing the right thing.

=C2=A0

We did not want to mandate a sp= ecific duration. An endpoint can determine the duration value based on many= things, including the number of candidates it provides and/or the number o= f streams, the reliability of the network (see below) etc etc etc.


This is a reasonable point. We could say that the i= mplementation MUST wait for enough time to receive peer-reflexive candidate= s. This value SHOULD be the local connectivity check timeout.=C2=A0
<= div>

=C2=A0

> 6.=C2=A0 The more I think about the timeout sho= uld be, the more I think this problem is bigger than the issues outlined in= the draft.=C2=A0

> If you have very slow signaling, it's possible that you will end up i= n this same situation regardless of how many candidates are

> signaled (since the slow signaling prevents the candidates from getting t= here).=C2=A0 =C2=A0 For example:

>=C2=A0=

> - Caller initiates ICE wit= h no candidates

> - Callee receives offer wi= th no candidates, sets a timer of N seconds, and sends back an answer with = several candidates

> - Caller receives candidat= es after N seconds and sends connectivity checks

> - Callee times out and goe= s to failed state

> - Callee receives connecti= vity checks, but it's too late

>=C2=A0=

> To avoid this problem, the= timeout the callee uses must be based on the expected signaling delay.=C2= =A0 So, I think our "SHOULD be X" should incorporate signaling= delay"=C2=A0

=C2=A0

Absolutely. We can for sure add= more guidance regarding things an endpoint has to take into consideration = when setting the N value.


Maybe, but this number will never be precise. The c= onnectivity check timeout itself is fairly arbitrary, but large enough to e= ffectively address the problem. The existing text has a mention of this.

=C2=A0

> 7.=C2=A0 I wonder if we should include a sugges= ted workaround for RFC 8445 clients that are "impatient".=C2=A0 F= or example, if you trickle, do not

> send "end-of-candidates" to the remote side until after N secon= ds (to prevent it from going to the failed state).=C2=A0

=C2=A0

Note that the draft text only c= overs the case when an endpoint receives candidates, discards all of them, = and waits for peer-reflexive candidates to arrive. These could be initial c= andidates, or trickled candidates.

=C2=A0

But, when it comes to trickle, = and how long an endpoint waits for the peer to SIGNAL additional candidates= , I think that shall be covered in trickle.


TBH, I think it sort of invalidat= es end-of-candidates, since it's now clear that you can't start pru= ning upon receiving end-of-candidates. We might just want to never send it = (and perhaps remove it in a future revision).
--0000000000005ed27a0586d503cc-- From nobody Thu Apr 18 14:53:01 2019 Return-Path: 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 16B461203E9 for ; Thu, 18 Apr 2019 14:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CgTa4rg0Rm4Y for ; Thu, 18 Apr 2019 14:52:56 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 9D3571203E1 for ; Thu, 18 Apr 2019 14:52:56 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id i21so2542927iol.7 for ; Thu, 18 Apr 2019 14:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HL6Gf4soYmJTrYe3j+au/7DHohWLVknDc0dOZXxN5R8=; b=Nzr8Q72vDRqWuQQwv9m+qtjAY6CAppeVE0WD3BR4i2Kxy7VJMUfMOahnuBWYy2AtJY eCWJst6Rdw7bbzgLpQ6UhT9WgpmVtBHoCesDPxIvBgbuWzZb04VVRzBJenuPpGphcEcw 7xC1AYPAkPViOgUYTixY2rSmhzZUse0lcssfKS8oyHC9s+SaNgVvHFlBleCiGy1DqYJS neRgagYx2vGZc8J4L6RkwSQ876P6gCR6yp5J9h+qLzeTfyo8F0/r+pljGCMeefBay0IF NVNarhXOStbmQwNKV3QVujFQ0WulJkcw6NPz5WC5uFoF3bzsqb3wIPeJcNvO+4BkbMXq h0UQ== 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=HL6Gf4soYmJTrYe3j+au/7DHohWLVknDc0dOZXxN5R8=; b=O3nRkyIAMFlgQxU1BVjOK7Le1JYBG1L9sAWZBRfy9ZLLDoMiUq38MrFeEub2cl6q/0 5jCHbzDRbFRvb0pufVSlxYddNQ4/Vejzyx1uJ15R1NVKN/uefV3xqkSOkyHlBzQxTWsb 3TD1jVdzim5Ja7MyHrqBq1R11qqMyvmCR++SMenXTZ3gSkKvio3U2Yc8WGmubVKYXtsl XWfGs7WMBFBAFgjYdeHuXVkNBOsRyd85nMTwejCvOTJegyvp88jFEsa1wAe2zXDLTPsu 3QpycDS+8haQTR2AwYWWYpAbj/0N8+qtzxPHMZ/Tks1hPIKyryvua4dAHY5F7toyCRMI hqUg== X-Gm-Message-State: APjAAAWA/j20ndMbIVBjmMoBRLLXX7+sV4Bfg9MnEWLPRegLN6PN0POp Rrw461UlbG1WyAN43h0CGDcvmwNb53nj5EZVOwzBFg== X-Google-Smtp-Source: APXvYqyzpL3YMftEZA+a3eG0tPhFcSOPNh1grwKTC5ggTubY4j3fVV0x1MRzpkGwvUKJ3tPUcq1smIlw+xdRmHO+XPs= X-Received: by 2002:a6b:d016:: with SMTP id x22mr361674ioa.181.1555624375532; Thu, 18 Apr 2019 14:52:55 -0700 (PDT) MIME-Version: 1.0 References: <95FC4DD9-3F0C-48C6-8E16-480FCD8471D1@ericsson.com> <56D1D166-20D9-40E2-94C8-2D7058CDBC69@ericsson.com> In-Reply-To: <56D1D166-20D9-40E2-94C8-2D7058CDBC69@ericsson.com> From: Justin Uberti Date: Thu, 18 Apr 2019 14:52:44 -0700 Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , Justin Uberti Content-Type: multipart/alternative; boundary="0000000000004f56da0586d50683" Archived-At: Subject: Re: [Ice] Draft new version: ice-pac-01 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 21:52:59 -0000 --0000000000004f56da0586d50683 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the full set of open issues is now captured in https://github.com/cdh4u/draft-ice-pac/issues. If anything is missing, please file a new issue there. On Thu, Apr 18, 2019 at 4:16 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > There were some comments that I had forgot to address, so there is going > to be at least one more version before we are ready for WGLC. > > > > Sorry for the confusion. > > > > Regards, > > > > Christer > > > > > > *From: *Christer Holmberg > *Date: *Wednesday, 17 April 2019 at 13.28 > *To: *"ice@ietf.org" > *Cc: *"ice-chairs@ietf.org" , Justin Uberti < > juberti@google.com> > *Subject: *Draft new version: ice-pac-01 > > > > Hi, > > > > I have merged the following pull requests: > > > > https://github.com/cdh4u/draft-ice-pac/pull/4 > > https://github.com/cdh4u/draft-ice-pac/pull/5 > > > > =E2=80=A6and submitted a new version (-01) of ice-pac. > > > > There should be no open issues, so my suggestion would be to start the > WGLC process. > > > > Regards > > > > Christer > --0000000000004f56da0586d50683 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the full set of open issues is now captured in= =C2=A0https://git= hub.com/cdh4u/draft-ice-pac/issues. If anything is missing, please file= a new issue there.

On Thu, Apr 18, 2019 at 4:16 AM Christer Holmberg <christer.holmberg@ericsson.= com> wrote:

Hi,

=C2=A0<= /span>

There = were some comments that I had forgot to address, so there is going to be at= least one more version before we are ready for WGLC.<= /p>

=C2=A0

Sorry = for the confusion.

=C2=A0

Regard= s,

=C2=A0

Christ= er

=C2=A0

=C2=A0

From: Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Date: Wednesday, 17 April 2019 at 13.28
To: "ice@ietf= .org" <ice@ie= tf.org>
Cc: "i= ce-chairs@ietf.org" <ice-chairs@ietf.org>, Justin Uberti <juberti@google.com>
Subject: Draft new version: ice-pac-01

=C2=A0<= /span>

Hi,<= /u>

=C2=A0<= u>

I have= merged the following pull requests:

=C2=A0=

https://github.com/cdh4u/draft= -ice-pac/pull/4

https://github.com/cdh4u/draft= -ice-pac/pull/5

=C2=A0=

=E2=80= =A6and submitted a new version (-01) of ice-pac.

=C2=A0=

There = should be no open issues, so my suggestion would be to start the WGLC proce= ss.

=C2=A0=

Regard= s

=C2=A0=

Christ= er

--0000000000004f56da0586d50683-- From nobody Fri Apr 19 12:46:04 2019 Return-Path: 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 923A51200B1 for ; Fri, 19 Apr 2019 12:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 z5mHk4bP2Pxt for ; Fri, 19 Apr 2019 12:46:00 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 9ABB312038F for ; Fri, 19 Apr 2019 12:46:00 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id a6so4673757oie.5 for ; Fri, 19 Apr 2019 12:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ERkRu5c6ktwUJtrscqwtSRdf9Lvtj5SYlj94ra/V14A=; b=BZ/+ODRjE41rsrC23Sd6BOHFhhBy8zk4qN2PwnLC8sIA4/X4rxAUb+sx1wcbCNP1q9 gmaohAarQ3ObrL4FdakZdPEKJznSIjXD3t+X1qqLc2RiwvL5RH57/wN7CDUYtQfZM/Hn erWew8XJg1GMexXlJMjSCxbBkd+0iUBVK5vFs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ERkRu5c6ktwUJtrscqwtSRdf9Lvtj5SYlj94ra/V14A=; b=ihvF4PPJCTP5/HUHZmGQ57QwvzSU/AhNngC0Y57664IJjN9FakD4B3qjhUSauwVMSL VwyIoU8dKtOtsUqdKOTQ65hGL6fP/MbVnkU5GBLE22qCef3U5sn8jfJAi+/JFWC0hitu YrMtCvWg8+WKREil98ispeFJ9LBi3TrrxQ8kj3E8ws8MxX4SAFLeq/4aRrMYr/bVHWjF n6p2qxTqg1kp/paJWvcv6w5Z9CsrnF9p9HAdwI8dhv0Wmlt/aidAVMXiNnBcu06HKG7U UkpYP1IzNYUmFCIf8E2VhFN0+VU4wkVbvFpl814MyYwgVyKx85ZQc1oeXusMt+FpUTua JoXg== X-Gm-Message-State: APjAAAXK5y+zITd3AgmDF73wno7yQpGL9t/gjfMmIHPhnf9hiLRglkvL ttZHBj74AWFwY58y9Q7wII5K84c+++w= X-Google-Smtp-Source: APXvYqw5ttZAKDf9W3XTYUwIUFiHq7g91ggkfaHtZxVjaLmyhuGzFQ4v/YWdIWrfTauvmkWnDuJFng== X-Received: by 2002:aca:abce:: with SMTP id u197mr2987176oie.67.1555703159707; Fri, 19 Apr 2019 12:45:59 -0700 (PDT) Received: from bcampen-fxhtdg.local (rrcs-24-173-40-58.sw.biz.rr.com. [24.173.40.58]) by smtp.googlemail.com with ESMTPSA id r4sm2369789oia.2.2019.04.19.12.45.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Apr 2019 12:45:59 -0700 (PDT) To: Justin Uberti Cc: ICE WG References: <9217809f-b09a-321e-34b6-2cf6fee9c07b@mozilla.com> From: Byron Campen Message-ID: <78981ed9-d272-e7b3-c30b-bf7dab7ccdd6@mozilla.com> Date: Fri, 19 Apr 2019 14:45:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------29334B6E7A93B2D237713098" Content-Language: en-US Archived-At: Subject: Re: [Ice] Firefox review of draft-ietf-ice-pac-00 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 19:46:03 -0000 This is a multi-part message in MIME format. --------------29334B6E7A93B2D237713098 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit     We start this timer when either a remote or local candidate comes along. Best regards, Byron Campen On 4/18/19 4:45 PM, Justin Uberti wrote: > Does this mean that you will wait forever if no candidates are provided? > > On Tue, Mar 26, 2019 at 6:57 AM Byron Campen > wrote: > > This looks fine to me. It isn't quite the same as what Firefox does > already, but it will do the trick. (we set the timer when we have > both > started ICE, _and_ have a trickle candidate) > > > Best regards, > > Byron Campen > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --------------29334B6E7A93B2D237713098 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
    We start this timer when either a remote or local candidate comes along.

Best regards,
Byron Campen

On 4/18/19 4:45 PM, Justin Uberti wrote:
Does this mean that you will wait forever if no candidates are provided?

On Tue, Mar 26, 2019 at 6:57 AM Byron Campen <bcampen@mozilla.com> wrote:
     This looks fine to me. It isn't quite the same as what Firefox does
already, but it will do the trick. (we set the timer when we have both
started ICE, _and_ have a trickle candidate)


Best regards,

Byron Campen

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice


--------------29334B6E7A93B2D237713098-- From nobody Fri Apr 19 13:04:27 2019 Return-Path: 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 EC5CB12036E for ; Fri, 19 Apr 2019 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ClEv5CfLmgTq for ; Fri, 19 Apr 2019 13:04:14 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 B124F1203ED for ; Fri, 19 Apr 2019 13:04:14 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id b6so5249477iog.0 for ; Fri, 19 Apr 2019 13:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZZlg1ph2zgi/fuG9mRL3bQrNsipg3GRk+l8NUiUzUPk=; b=DSmA2Eei9oCfnCahmTBWwE6+de8J9D6KNCCDOp9O5KsLkw6LyJfOYb+9hxYWMnNlQA y1+51xrwakfZhumTbVISKDAy7W5AJMJkJUvl9gI1FmkUZzT/M5OFSn1/udDVHuCXQoDo OpPjqppb5aPPzNzSR6bwvfEWyxp/de6P+/PrOn4O9jMRwwy2THpkMlnWmnjEk6lGoddF uQa2rFNuBoLFTz4Kjs8fLpzRRovTu5l1y1yAhwkNoPbXfo4fE6f8LDXdC9kqxK6pUZTB l/DL8+RfxVjfog1xjL9plzjGUE1O8ariGC3qXMDV4NwpWz9lfA+RhtS776SvjGjOr18j jp+Q== 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=ZZlg1ph2zgi/fuG9mRL3bQrNsipg3GRk+l8NUiUzUPk=; b=fO2tb9lFdC/zbuXjloD39PReMD1NSKfhxvLZ45+3OGTSMITJco1BXmzca/+y3qqZFX Zsv7TKO2RyIP2qozzsgSHRp2tqkyU6woqaCWvCGwZQGx6BV8a2gkWjPRq5si1H7xZG6S 9hroIhN8Au4nRoTryaP0z0Vya4FenblzFx6/a4E/TAwlBl32xvVv8u+mmfwNlZ7bLnaC jrVrYnXasRn8f/2OxDrOxHnT1QhKRzQR3BUquo+XScHXo6fHhbVEJtb76IFCSsvl41sD 9eRA5ceJEzyLyuxM8hHmf2tlbYHmvnUCBkKh389EKC621NyrDtkXXPIfFvYPNAwPatC0 DGpA== X-Gm-Message-State: APjAAAWmeJdfcYIQaM6JMhVYOJnV8d2XNKNTB8CSrks5QjmqSluiz6Cm 46Nqw1iK6Q7uxiGMyXuCtXPvHSDMff7nynnTdIK3rWa1Gcs= X-Google-Smtp-Source: APXvYqyGwkOCBssHnageddV4r9OOKSlfuUsbfqx091RTIdJPZAfedklVSygGEndmSresOtV1r8I3Hhs1Pme0JrhNAsA= X-Received: by 2002:a6b:d016:: with SMTP id x22mr3697830ioa.181.1555704253623; Fri, 19 Apr 2019 13:04:13 -0700 (PDT) MIME-Version: 1.0 References: <9217809f-b09a-321e-34b6-2cf6fee9c07b@mozilla.com> <78981ed9-d272-e7b3-c30b-bf7dab7ccdd6@mozilla.com> In-Reply-To: <78981ed9-d272-e7b3-c30b-bf7dab7ccdd6@mozilla.com> From: Justin Uberti Date: Fri, 19 Apr 2019 13:04:01 -0700 Message-ID: To: Byron Campen Cc: ICE WG Content-Type: multipart/alternative; boundary="0000000000006a35860586e79f7f" Archived-At: Subject: Re: [Ice] Firefox review of draft-ietf-ice-pac-00 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 20:04:17 -0000 --0000000000006a35860586e79f7f Content-Type: text/plain; charset="UTF-8" Got it. Basically, starting the clock as soon as any ICE processing starts, which makes sense. On Fri, Apr 19, 2019 at 12:46 PM Byron Campen wrote: > We start this timer when either a remote or local candidate comes > along. > > Best regards, > Byron Campen > > On 4/18/19 4:45 PM, Justin Uberti wrote: > > Does this mean that you will wait forever if no candidates are provided? > > On Tue, Mar 26, 2019 at 6:57 AM Byron Campen wrote: > >> This looks fine to me. It isn't quite the same as what Firefox does >> already, but it will do the trick. (we set the timer when we have both >> started ICE, _and_ have a trickle candidate) >> >> >> Best regards, >> >> Byron Campen >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> > > --0000000000006a35860586e79f7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it. Basically, starting the clock as soon as any ICE p= rocessing starts, which makes sense.

On Fri, Apr 19, 2019 at 12:46 PM Byron = Campen <bcampen@mozilla.com&g= t; wrote:
=20 =20 =20
=C2=A0=C2=A0= =C2=A0 We start this timer when either a remote or local candidate comes along.

Best regards,=
Byron Campen<= br>

On 4/18/19 4:= 45 PM, Justin Uberti wrote:
=20
Does this mean that you will wait forever if no candidates are provided?

On Tue, Mar 26, 2019 at 6:57 AM Byron Campen <bcampen@mozilla.com> wrote:
=C2=A0=C2=A0=C2= =A0=C2=A0 This looks fine to me. It isn't quite the same as what Firefo= x does
already, but it will do the trick. (we set the timer when we have both
started ICE, _and_ have a trickle candidate)


Best regards,

Byron Campen

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice


--0000000000006a35860586e79f7f-- From nobody Thu Apr 25 01:27:26 2019 Return-Path: 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 8D9921201E8 for ; Thu, 25 Apr 2019 01:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 tlJwsp0XTCMW for ; Thu, 25 Apr 2019 01:27:12 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40084.outbound.protection.outlook.com [40.107.4.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689371201B7 for ; Thu, 25 Apr 2019 01:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fhFfKt2qEw/JNH04QkDyTEa54b5yPjddY/kmxjPftgA=; b=Dh9P3aMnErlOBeKaLYJNG+9Xmz7H8pQtYVVpV51hisKVdUnstxgZO3/V5oZOGTrRWehxRbo2NfGqv0o1NgL+RO22yxcRx77pUXOoxw/shcZUkP9bfp3xhyT4HOywGGfwmNwbH88Zf5zS5jTYA0o5LDqtG1nSS5ru5uvESTXXHpM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3468.eurprd07.prod.outlook.com (10.170.247.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Thu, 25 Apr 2019 08:27:09 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 08:27:09 +0000 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3g== Date: Thu, 25 Apr 2019 08:27:09 +0000 Message-ID: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2920ff7e-9b91-4810-dbaa-08d6c957cf3c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3468; x-ms-traffictypediagnostic: HE1PR07MB3468: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(39860400002)(136003)(199004)(189003)(26005)(44832011)(102836004)(2906002)(3846002)(6506007)(97736004)(8936002)(66066001)(14444005)(64756008)(66556008)(66476007)(81166006)(81156014)(4744005)(6116002)(8676002)(73956011)(256004)(1730700003)(14454004)(5660300002)(66446008)(66946007)(76116006)(83716004)(71200400001)(71190400001)(478600001)(5640700003)(86362001)(2616005)(7736002)(25786009)(6306002)(486006)(36756003)(68736007)(6436002)(6916009)(186003)(99286004)(33656002)(606006)(6486002)(2501003)(6512007)(82746002)(236005)(2351001)(53936002)(54896002)(316002)(476003)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3468; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ejq/p72ROgo8thDCcQvfVlbXv8wzA1ZMrkyA313WguC5z5X5q8BdmpGho4Fkl3ACZtHaZ8Psp9cOntKTM0cbJrwS5HFmTQZ61Yu8MBB7IVs6fiZ3yu715/yG4P1uiwOlHCCHMEDKzywOliRMU2NzVjJr4KPQRQZ13vt0FYB3hxBA2CurijgDh5zDqTCEVg/nMQNTAoluOU4XyaE53dnCZRi2ceQiaIax/lEb3kBY6qahNyzzN8EiBh/kwqrfgZBg0uaXi9w9ZHmkfpgFOztuJ0ZkmWmG90+pQWDPGWVkDBJbUCJ/gZRs5/rXA0APdHIoSld3kuK5ijJAIytmACHlzy+VpT8k0byJXx9XXPIHMhTUKIrGYscY2H9GgnAJhVF3zMrJY/ZYC4QpzOViz1rFUnVQkYrOxvrlXSpuOducmEc= Content-Type: multipart/alternative; boundary="_000_3A66B73503C941FF95AD500B0D469C80ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2920ff7e-9b91-4810-dbaa-08d6c957cf3c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 08:27:09.4362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3468 Archived-At: Subject: [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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 08:27:25 -0000 --_000_3A66B73503C941FF95AD500B0D469C80ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpbmdpbmcgYW4gaXNzdWUgdGhhdCBjYW1lIHVwIGluIEdpdEh1YiAoaHR0cHM6Ly9naXRodWIu Y29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvaXNzdWVzLzgpIHRvIHRoZSBsaXN0Lg0KDQpUaGUgcXVl c3Rpb24gaXM6IHdoZW4gZG9lcyBhbiBhZ2VudCBzdGFydCB0aGUg4oCcUEFDIHRpbWVy4oCdIChw ZXJoYXBzIHdlIHNob3VsZCBnaXZlIHRoZSB0aW1lciBhIG5hbWUpPw0KDQoNCiAgMS4gIFdoZW4g dGhlIGNvbm5lY3Rpdml0eSBjaGVja3Mgc3RhcnQ7IE9SDQogIDIuICBXaGVuIHRoZSBhZ2VudCBo YXMgcGVyZm9ybWVkIGFsbCBjaGVja3MgYW5kIHJlYWNoZXMgYSBzdGF0ZSB3aGVyZSBpdCBub3Jt YWxseSB3b3VsZCBkZWNsYXJlIElDRSBmYWlsdXJlPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCg== --_000_3A66B73503C941FF95AD500B0D469C80ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <31475B92E0EC9745AD27AF95D2DDF4D2@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNt IDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzg4NDU4 OTg5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAw MjY0MTM5NCA2NzY5ODcxMSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCki Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ccmlu Z2luZyBhbiBpc3N1ZSB0aGF0IGNhbWUgdXAgaW4gR2l0SHViICg8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL2lz c3Vlcy84Ij5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9pc3N1ZXMvODwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4pDQog dG8gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBxdWVzdGlvbiBpczogd2hlbiBkb2VzIGFuIGFn ZW50IHN0YXJ0IHRoZSDigJxQQUMgdGltZXLigJ0gKHBlcmhhcHMgd2Ugc2hvdWxkIGdpdmUgdGhl IHRpbWVyIGEgbmFtZSk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIg dHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+V2hlbiB0aGUgY29ubmVjdGl2aXR5IGNoZWNrcyBzdGFydDsgT1IN CjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldoZW4gdGhlIGFnZW50IGhhcyBwZXJmb3Jt ZWQgYWxsIGNoZWNrcyBhbmQgcmVhY2hlcyBhIHN0YXRlIHdoZXJlIGl0IG5vcm1hbGx5IHdvdWxk IGRlY2xhcmUgSUNFIGZhaWx1cmU/PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3A66B73503C941FF95AD500B0D469C80ericssoncom_-- From nobody Thu Apr 25 10:37:02 2019 Return-Path: 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 D2BB21203DC for ; Thu, 25 Apr 2019 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 KkJlHpI5a_fQ for ; Thu, 25 Apr 2019 10:36:46 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 7C83D12025D for ; Thu, 25 Apr 2019 10:36:44 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id e6so196999pgc.4 for ; Thu, 25 Apr 2019 10:36:44 -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=wYMq3TZ7Q1BHoSmVVxQT2hgZUddp10e7GxZUwmTeYYA=; b=w3Tjm1j4qEcLA0+Qa+g6iGUZg3welDkABbX8NVgNK5rapK2N3cNWjyahgVr/pPMzcs WwBE00tp2yB8y/Lo0hDUr2e7zCawWQZce/a4xAV0lQOFY6ytp1oZ15b3MMA6dsNo/dzB q1oQ3mWTH8OoobBjFq2xCBV+W/mJsNpWI+T1QvIMvjProTTOfAyKVApg+Dp2ThmzeRB4 7sc3/gI+AMRQqpaV4wr9lZqBtVDjW0MJ4c/NyN3MKGHKAcBR4dQ6FzcEuTC6WK2l+05g fYoamybg3O3pmqTV/UCf1XIDjuWQNJvMyFPY96ETXe1Yj5j21tix95ji0JTJd5qwbQ/n Fvvw== 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=wYMq3TZ7Q1BHoSmVVxQT2hgZUddp10e7GxZUwmTeYYA=; b=el6A2+QgU0Lo2PD64PcaiRxzw2AmbUHHDXrNeqRq9Nysz0xkUrNxyV0yo+aSrep1O/ 4UBnvyTMa6tr6EBmhgsKFOY3+086doUfwiXvu4DJOzGJbHuA6TTIINdOAbmQq410l8ha KjW0wu+KdVcgPbmcq6S6ITvuWj3AMYna/jwJL9vh6OS4uE+bNCacdJnJMXvhqzMbnH9l bHxIsGLbkfKbyUltzFHxay7XyrxFOIXzslUn1wOn+3dDkqOb935NGM6JfG7xq9trIf2z sYVcWafdpSetlsZitUy7a30/u5CnreK0wa1tLIUzXZ6mvTeiQqT7ZYVtdHJUEXFN49IX Tmzg== X-Gm-Message-State: APjAAAWD/gsioqJTf8hRizj1qk1Y9xYh2S0aF5s2Vnt1doOVmVJ0W5ER S7UsD4MFB990Yn+6pEzf3tifX5iCc/I= X-Google-Smtp-Source: APXvYqz2WrX5KQ+G1Wbn0sK/zDbxouadHyuKK41gwF0B9ywsJ/yLn0K2cdcwkuN7J3MRUxny82NTqw== X-Received: by 2002:a65:62c3:: with SMTP id m3mr11672222pgv.159.1556213803541; Thu, 25 Apr 2019 10:36:43 -0700 (PDT) Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com. [209.85.210.179]) by smtp.gmail.com with ESMTPSA id b63sm64031753pfj.54.2019.04.25.10.36.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 10:36:42 -0700 (PDT) Received: by mail-pf1-f179.google.com with SMTP id e67so247239pfe.10 for ; Thu, 25 Apr 2019 10:36:42 -0700 (PDT) X-Received: by 2002:a63:f503:: with SMTP id w3mr34941631pgh.60.1556213802470; Thu, 25 Apr 2019 10:36:42 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> In-Reply-To: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> From: Roman Shpount Date: Thu, 25 Apr 2019 13:36:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e4153405875e4222" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 17:37:01 -0000 --000000000000e4153405875e4222 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The timer should start when the connectivity checks start by the remote ICE agent. The timer is needed to make sure local candidate addresses continue to accept STUN binding requests for at least some minimal time, so technically timer should start from the time remote ICE agent was informed about candidate addresses and started connectivity checks. There is some signaling delay involved here, so it needs to accounted by the timer value. Regards, _____________ Roman Shpount On Thu, Apr 25, 2019 at 4:27 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Bringing an issue that came up in GitHub ( > https://github.com/cdh4u/draft-ice-pac/issues/8) to the list. > > > > The question is: when does an agent start the =E2=80=9CPAC timer=E2=80=9D= (perhaps we > should give the timer a name)? > > > > 1. When the connectivity checks start; OR > 2. When the agent has performed all checks and reaches a state where > it normally would declare ICE failure? > > > > Regards, > > > > Christer > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --000000000000e4153405875e4222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The timer should start when the connectivity checks start = by the remote ICE agent. The timer is needed to make sure local candidate a= ddresses continue to accept STUN binding requests for at least some minimal= time, so technically timer should start from the time remote ICE agent was= informed about candidate addresses and started connectivity checks. There = is some signaling delay involved here, so it needs to accounted by the time= r value.

Regards,
_____________=
Roman Shpount


On Thu, Apr 25, 2019 at 4:27 AM Chri= ster Holmberg <christe= r.holmberg@ericsson.com> wrote:

Bringi= ng an issue that came up in GitHub (https://= github.com/cdh4u/draft-ice-pac/issues/8) to the list.

=C2=A0

The qu= estion is: when does an agent start the =E2=80=9CPAC timer=E2=80=9D (perhap= s we should give the timer a name)?

=C2=A0

  1. When the connectivi= ty checks start; OR
  2. When the agent has performed all checks and reaches a state where it= normally would declare ICE failure?

=C2=A0

Regard= s,

=C2=A0

Christ= er

=C2=A0

=C2=A0

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--000000000000e4153405875e4222-- From nobody Thu Apr 25 11:17:50 2019 Return-Path: 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 C26A21200F9 for ; Thu, 25 Apr 2019 11:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 YUJ5vRtId82d for ; Thu, 25 Apr 2019 11:17:45 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50081.outbound.protection.outlook.com [40.107.5.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C276120033 for ; Thu, 25 Apr 2019 11:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qVKN6wZFLqPRI9nIQEtcLTaxFweqBz4iXyQ/mwwHypU=; b=ED6oztxA/iPGQ05/TNvOTz3nMqlsHieNwV8Y7avP2nxFfSUykaBBLppopLe0Wv8fTwmiIYrE8EjCG4rk7Z5pTfbwW73lwbszpQ2bcMjEqt3VYMxYUnCtbE9t/haAoTPOvd75QELnCIyBC3jnhE47BXJnVF5l2+1BmuDCr0TZjAI= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1SPR01MB0037.eurprd07.prod.outlook.com (20.176.168.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.12; Thu, 25 Apr 2019 18:17:41 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::747a:900a:3053:2184%2]) with mapi id 15.20.1835.010; Thu, 25 Apr 2019 18:17:41 +0000 From: Christer Holmberg To: Roman Shpount CC: "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAA= Date: Thu, 25 Apr 2019 18:17:41 +0000 Message-ID: References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [176.93.0.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17bfd37a-6f81-4a92-1044-08d6c9aa4e6b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1SPR01MB0037; x-ms-traffictypediagnostic: HE1SPR01MB0037: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 0018A2705B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(376002)(39860400002)(199004)(189003)(58126008)(606006)(66946007)(86362001)(186003)(73956011)(14454004)(66446008)(76116006)(66556008)(478600001)(36756003)(3846002)(966005)(68736007)(97736004)(11346002)(66066001)(6116002)(446003)(486006)(236005)(8676002)(44832011)(476003)(2616005)(6246003)(33656002)(71190400001)(6512007)(53936002)(71200400001)(81166006)(83716004)(6916009)(82746002)(81156014)(7736002)(64756008)(8936002)(66476007)(256004)(6306002)(5070765005)(5660300002)(2906002)(25786009)(316002)(26005)(99286004)(229853002)(6486002)(4326008)(53546011)(76176011)(14444005)(102836004)(6506007)(6436002)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR01MB0037; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZNWv8fkxNPsWhNjn54JDYNNiproWuY7LoX8XqW9tgvOB8hXi0KObKFJfOyLbrUF+ochoXInL10MXDoeqjQcUq+oLXY9Eot0zNf9DSdbdXPZTv1R2Q3ndAZLqAOIGcrrzvYJwJkwmvrg9xaK/cILNAYugKagtO28K1vBGg4nscvb155IZ+Q8/ToCaEXEgbHsSySo/dmqCRSfbsi1moRPJzDkUz1RF+YvZAh5cJ+2B5o9ixjaQxXBiV384AuTRXx11FUMadxyHbKuU7+cD3DmwG6kB9X1pbMFQLzvUiXJrYYMNRrICwwSl0yEyaBE2xCy3cl78bqo7o3nqRRpnciDT5SDbbyQEZZkg03QbDohoCNKPGXzQ4f2vRm7SLvmuBP4e+pXh98JmOb2n1O/IzrXBj0ybniuuC4OUoTpfsWwkBd8= Content-Type: multipart/alternative; boundary="_000_A4EC3C014D7D45DF876DE58706F74866ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17bfd37a-6f81-4a92-1044-08d6c9aa4e6b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 18:17:41.5475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR01MB0037 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 18:17:49 -0000 --_000_A4EC3C014D7D45DF876DE58706F74866ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGUgdGltZXIgc2hvdWxkIHN0YXJ0IHdoZW4gdGhlIGNvbm5lY3Rpdml0eSBjaGVj a3Mgc3RhcnQgYnkgdGhlIHJlbW90ZSBJQ0UgYWdlbnQuIFRoZSB0aW1lciBpcyBuZWVkZWQgdG8g bWFrZSBzdXJlIGxvY2FsIGNhbmRpZGF0ZSBhZGRyZXNzZXMgY29udGludWUNCj50byBhY2NlcHQg U1RVTiBiaW5kaW5nIHJlcXVlc3RzIGZvciBhdCBsZWFzdCBzb21lIG1pbmltYWwgdGltZSwgc28g dGVjaG5pY2FsbHkgdGltZXIgc2hvdWxkIHN0YXJ0IGZyb20gdGhlIHRpbWUgcmVtb3RlIElDRSBh Z2VudCB3YXMgaW5mb3JtZWQgYWJvdXQNCj5jYW5kaWRhdGUgYWRkcmVzc2VzIGFuZCBzdGFydGVk IGNvbm5lY3Rpdml0eSBjaGVja3MuIFRoZXJlIGlzIHNvbWUgc2lnbmFsaW5nIGRlbGF5IGludm9s dmVkIGhlcmUsIHNvIGl0IG5lZWRzIHRvIGFjY291bnRlZCBieSB0aGUgdGltZXIgdmFsdWUuDQoN CkFuIGFnZW50IGRvZXNu4oCZdCBrbm93IHdoZW4gdGhlIHBlZXIgYWdlbnQgd2lsbCBzdGFydCAt IGVzcGVjaWFsbHkgbm90IHRoZSBvZmZlcmVyLiBJZiBpdCBzZW5kcyBhbiBJTlZJVEUgd2l0aCBp dHMgY2FuZGlkYXRlcywgaXQgbWF5IHRha2UgYSB3aGlsZSBiZWZvcmUgdGhlIElOVklURSBldmVu IHJlYWNoZXMgdGhlIHBlZXIgYWdlbnQsIGR1ZSB0byBuZXR3b3JrIHNlcnZpY2VzLCBjYWxsIGZv cndhcmRpbmcgZXRjIGV0YyBldGMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiBU aHUsIEFwciAyNSwgMjAxOSBhdCA0OjI3IEFNIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KQnJpbmdpbmcgYW4gaXNzdWUgdGhhdCBjYW1lIHVwIGluIEdpdEh1YiAoaHR0 cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvaXNzdWVzLzgpIHRvIHRoZSBsaXN0 Lg0KDQpUaGUgcXVlc3Rpb24gaXM6IHdoZW4gZG9lcyBhbiBhZ2VudCBzdGFydCB0aGUg4oCcUEFD IHRpbWVy4oCdIChwZXJoYXBzIHdlIHNob3VsZCBnaXZlIHRoZSB0aW1lciBhIG5hbWUpPw0KDQoN CiAgMS4gIFdoZW4gdGhlIGNvbm5lY3Rpdml0eSBjaGVja3Mgc3RhcnQ7IE9SDQogIDIuICBXaGVu IHRoZSBhZ2VudCBoYXMgcGVyZm9ybWVkIGFsbCBjaGVja3MgYW5kIHJlYWNoZXMgYSBzdGF0ZSB3 aGVyZSBpdCBub3JtYWxseSB3b3VsZCBkZWNsYXJlIElDRSBmYWlsdXJlPw0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJY2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8bWFpbHRvOkljZUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQo= --_000_A4EC3C014D7D45DF876DE58706F74866ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <55AE846BF853114CB3319C3FD3AA39FA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFp bC1tLTY4NzkwODQ5NDA2OTEwMDg3NTBtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTY4Nzkw ODQ5NDA2OTEwMDg3NTBtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS02ODc5MDg0OTQwNjkx MDA4NzUwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy02ODc5MDg0 OTQwNjkxMDA4NzUwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVwdCAyLjBjbTt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE5NDg3MzQ1MTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEwMDMyNTk3NTI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O1RoZSB0aW1lciBzaG91bGQgc3RhcnQgd2hlbiB0aGUgY29u bmVjdGl2aXR5IGNoZWNrcyBzdGFydCBieSB0aGUgcmVtb3RlIElDRSBhZ2VudC4NCjwvc3Bhbj5U aGUgdGltZXIgaXMgbmVlZGVkIHRvIG1ha2Ugc3VyZSBsb2NhbCBjYW5kaWRhdGUgYWRkcmVzc2Vz IGNvbnRpbnVlIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPnRvIGFjY2VwdCBTVFVOIGJp bmRpbmcgcmVxdWVzdHMgZm9yIGF0IGxlYXN0IHNvbWUgbWluaW1hbCB0aW1lLCBzbyB0ZWNobmlj YWxseSB0aW1lciBzaG91bGQgc3RhcnQgZnJvbSB0aGUgdGltZSByZW1vdGUgSUNFIGFnZW50IHdh cyBpbmZvcm1lZCBhYm91dA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtjYW5kaWRhdGUgYWRkcmVzc2VzIGFuZCBzdGFy dGVkIGNvbm5lY3Rpdml0eSBjaGVja3MuDQo8L3NwYW4+VGhlcmUgaXMgc29tZSBzaWduYWxpbmcg ZGVsYXkgaW52b2x2ZWQgaGVyZSwgc28gaXQgbmVlZHMgdG8gYWNjb3VudGVkIGJ5IHRoZSB0aW1l ciB2YWx1ZS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFuIGFnZW50IGRvZXNu4oCZdCBrbm93IHdoZW4gdGhlIHBlZXIgYWdlbnQgd2lsbCBzdGFy dCAtIGVzcGVjaWFsbHkgbm90IHRoZSBvZmZlcmVyLiBJZiBpdCBzZW5kcyBhbiBJTlZJVEUgd2l0 aCBpdHMgY2FuZGlkYXRlcywgaXQgbWF5IHRha2UgYSB3aGlsZSBiZWZvcmUgdGhlIElOVklURSBl dmVuIHJlYWNoZXMgdGhlIHBlZXIgYWdlbnQsIGR1ZSB0byBuZXR3b3JrIHNlcnZpY2VzLA0KIGNh bGwgZm9yd2FyZGluZyBldGMgZXRjIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIg MjUsIDIwMTkgYXQgNDoyNyBBTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkJyaW5naW5nIGFuIGlzc3VlIHRoYXQgY2FtZSB1cCBpbiBHaXRIdWIgKDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1pY2UtcGFjL2lzc3Vlcy84IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWljZS1wYWMvaXNzdWVzLzg8L2E+KQ0K IHRvIHRoZSBsaXN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBxdWVzdGlvbiBpczogd2hl biBkb2VzIGFuIGFnZW50IHN0YXJ0IHRoZSDigJxQQUMgdGltZXLigJ0gKHBlcmhhcHMgd2Ugc2hv dWxkIGdpdmUgdGhlIHRpbWVyIGEgbmFtZSk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iZ21haWwtbS02ODc5 MDg0OTQwNjkxMDA4NzUwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5XaGVuIHRoZSBjb25uZWN0aXZpdHkgY2hlY2tz IHN0YXJ0OyBPUiA8L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbS02ODc5 MDg0OTQwNjkxMDA4NzUwbXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5XaGVuIHRoZSBhZ2VudCBoYXMgcGVyZm9ybWVk IGFsbCBjaGVja3MgYW5kIHJlYWNoZXMgYSBzdGF0ZSB3aGVyZSBpdCBub3JtYWxseSB3b3VsZCBk ZWNsYXJlIElDRSBmYWlsdXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A4EC3C014D7D45DF876DE58706F74866ericssoncom_-- From nobody Thu Apr 25 11:25:19 2019 Return-Path: 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 DF6D41200F6 for ; Thu, 25 Apr 2019 11:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 P1GU1UiB5zQq for ; Thu, 25 Apr 2019 11:25:16 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 16E35120074 for ; Thu, 25 Apr 2019 11:25:16 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id l18so254385pgj.6 for ; Thu, 25 Apr 2019 11:25:16 -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=dpAuiOU1uolaeFsrWd2WIeHkb03zJ71m6B1AHpahhLw=; b=Bb2O+F7JsIhoSQDxsbNzEzz5ynG4RYxK3hxKTohH204Wf5FewhgSnn7Fem4mrMynlN 9ggKbA7A6ACKYT/8AVItKjY3sQlYRkDwplOzHeQnrip9x3x941BwcPFP+wDGEYoYItM8 4lozWWeWs7gcHzrKij2kK9/ANS4YzFZSeWN0mjPHSxvlkE3fq2ayF8zDJb/1BH2ysex6 3Wg5CrfFvFZ78AF6UKo0786Jw4hB83xhABYVIgm6C/6rNr1dFOQ6OxWANADMVihsYU6J Q3h/KMXoOdM35oqnCJEm24H1i0G1i87eBM56z/QPYC0xBS1F4191iDLXTY77mFOTBvYa CM1Q== 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=dpAuiOU1uolaeFsrWd2WIeHkb03zJ71m6B1AHpahhLw=; b=Q6sP9o2Ii3e+KnAe19v+Y8GmWzTTD0S4xTlgio8SWXeBhTRD8Ad4lCr1iiOYByJlmn qp1oKK+F1TKEHeHjgOsNkqbP3N/WHK3jukSoxtfStAAbqQx0j8yDTCQVxyB/+6eEyJKY tjkjS7f+16xL++pCgZDNeag3sy3CMZ7lhaYokjvdFlA5PsFYBekBkDOSEhQV6NAvugBY MddXr7cQU/TtxRNmMvSoJjgnTM0GgK0oadfUX5Decdd/n+Q8daKJGxVweuWydF178k7x ywuNcZVoQvKPu3avv32sn8tbC8x+Js5naMDv9OklfjMCO/qVmzldUoUFTl4aQiOIpCnI 64BA== X-Gm-Message-State: APjAAAXKG4QIuoJpzFUOu8FyMVq27FljosUjfpWzz38lGvSl5s0yNmk1 p24gchS9Ugo4YxacmlpSr10AvMJ6KAA= X-Google-Smtp-Source: APXvYqxbP/RIcmmkzwJHxAGobK6JJ2tTN2R+2NlNHhnNHk+f0fppuj5CkQVhYFxet8KE5lfkvWrVKA== X-Received: by 2002:a63:ef46:: with SMTP id c6mr22588318pgk.392.1556216715361; Thu, 25 Apr 2019 11:25:15 -0700 (PDT) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id m11sm48476956pgd.12.2019.04.25.11.25.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 11:25:14 -0700 (PDT) Received: by mail-pf1-f172.google.com with SMTP id y13so310550pfm.11 for ; Thu, 25 Apr 2019 11:25:14 -0700 (PDT) X-Received: by 2002:a63:8dc8:: with SMTP id z191mr2598037pgd.9.1556216714307; Thu, 25 Apr 2019 11:25:14 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> In-Reply-To: From: Roman Shpount Date: Thu, 25 Apr 2019 14:25:05 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000732ce105875ef0bb" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 18:25:18 -0000 --000000000000732ce105875ef0bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >The timer should start when the connectivity checks start by the remote > ICE agent. The timer is needed to make sure local candidate addresses > continue > > >to accept STUN binding requests for at least some minimal time, so > technically timer should start from the time remote ICE agent was informe= d > about > > >candidate addresses and started connectivity checks. There is some > signaling delay involved here, so it needs to accounted by the timer valu= e. > > > > An agent doesn=E2=80=99t know when the peer agent will start - especially= not the > offerer. If it sends an INVITE with its candidates, it may take a while > before the INVITE even reaches the peer agent, due to network services, > call forwarding etc etc etc. > > > This was actually one of the issues raised related to the timer start. The offerer can start the timer when it got the first remote candidate or end of candidates notification. Answerer is trickier, since there is no signaling indication when offerer actually got the answer. This is why I was thinking that an extra signaling message ( https://github.com/cdh4u/draft-ice-pac/issues/11), indicating end of sending candidate checks might work better then a timer. _____________ Roman Shpount --000000000000732ce105875ef0bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2019 at 2:17 PM C= hrister Holmberg <chri= ster.holmberg@ericsson.com> wrote:

>The timer should start when= the connectivity checks start by the remote ICE agent. The timer is needed to make sure local candidate addresses continue<= br>

>to accept STUN binding requests for at least some minimal time, so technic= ally timer should start from the time remote ICE agent was informed about

>candidate addresses and sta= rted connectivity checks. There is some signaling delay involved here, so it needs to accounte= d by the timer value.

=C2=A0

An agent doesn=E2=80=99t know w= hen the peer agent will start - especially not the offerer. If it sends an = INVITE with its candidates, it may take a while before the INVITE even reac= hes the peer agent, due to network services, call forwarding etc etc etc.


This was actually one of the issues raised related to the time= r start. The offerer can start the timer when it got the first remote candi= date or end of candidates notification. Answerer is trickier, since there i= s no signaling indication when offerer actually got the answer. This is why= I was thinking that an extra signaling message (https://github.com/cdh4u/draft-ice-pac/i= ssues/11), indicating end of sending candidate checks might work better= then a timer.
_____________
Roman Shpount
=C2=A0
--000000000000732ce105875ef0bb-- From nobody Thu Apr 25 12:45:24 2019 Return-Path: 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 0F7DA120607 for ; Thu, 25 Apr 2019 12:45:14 -0700 (PDT) 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 9eWlLrynXs71 for ; Thu, 25 Apr 2019 12:45:10 -0700 (PDT) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 485691205D3 for ; Thu, 25 Apr 2019 12:45:10 -0700 (PDT) Received: by mail-pg1-x542.google.com with SMTP id h1so363956pgs.2 for ; Thu, 25 Apr 2019 12:45:10 -0700 (PDT) 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=Md23DPVaCEwvt8b5qxkaoTcrp6SRcUYDn/IFUINdOu8=; b=Vy73KEzl/5sSDKuXP6JhS/OMZo2ZYNyityrMj1UkdoaYNMfbH+QKtIQ5c5Bh/50GiE 5ieF/OG6Xk4iJMNXVje25NZHymsgc253Bex/Rqzj52N+vGeby4ghxuHMh7IGMcAwABFa rkfBl+wVGI1wIXvcb4J029CKvlpTeO/gwOCds= 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=Md23DPVaCEwvt8b5qxkaoTcrp6SRcUYDn/IFUINdOu8=; b=DhgOPK5C3XTJ2yR/MnhXmHUvNAB5peqXf1WVg9TwF6v/d1ENtqCtQIhZNd5DUdzyvg y74HzCSEewD7Nd5rnlzyfBWPjv5Go9IYpcPqXq6BP03ohnUU1HUdl9mQdZsLx3zXspJ1 3J0XP7TquTAchw5ANSP/qiVelLWwYwtbDpDug35hgS5370GG8fQa3oyWY3iZnMbnWRIZ 1Op1YER8YzSFIMxJIc4vlZ2wY0BgRNu6zNtBtwKBbQ+96GDYFfFbz7Adxm+cHs8wxO5F udl5zfab7ZicYLCqJ/8xBelRatJWASLV218pPoBM+VhMN3kLue47QR9b/xiZgrKeTTSq TjlQ== X-Gm-Message-State: APjAAAWzaclCTwSpeaEWAOkfoTH1v+v2+V3pN7eZHpbO313HycB5OW2z nIoIDeO5rbrX7HmOyGFtwXsJQQ== X-Google-Smtp-Source: APXvYqx1i11+UvSL/3w8MMqV9utJzLVb7DqqW7sOWnZFG4Sxpg62Y5M5F86DDjWx5YnOGRv5EInq5w== X-Received: by 2002:aa7:9627:: with SMTP id r7mr41668175pfg.245.1556221509705; Thu, 25 Apr 2019 12:45:09 -0700 (PDT) Received: from [10.252.34.218] (guest-nat.fw1.untrust.mtv2.mozilla.net. [63.245.221.200]) by smtp.gmail.com with ESMTPSA id w10sm34652661pfi.126.2019.04.25.12.45.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 12:45:08 -0700 (PDT) From: Nils Ohlmeier Message-Id: <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E69C2C05-C8EA-404A-8B1B-9EFE7C77153E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 25 Apr 2019 12:45:03 -0700 In-Reply-To: Cc: Christer Holmberg , "ice@ietf.org" To: Roman Shpount References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 19:45:20 -0000 --Apple-Mail=_E69C2C05-C8EA-404A-8B1B-9EFE7C77153E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 25, 2019, at 11:25, Roman Shpount wrote: >=20 > On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg = > = wrote: > >The timer should start when the connectivity checks start by the = remote ICE agent. The timer is needed to make sure local candidate = addresses continue >=20 >=20 > >to accept STUN binding requests for at least some minimal time, so = technically timer should start from the time remote ICE agent was = informed about >=20 > >candidate addresses and started connectivity checks. There is some = signaling delay involved here, so it needs to accounted by the timer = value. >=20 > =20 >=20 > An agent doesn=E2=80=99t know when the peer agent will start - = especially not the offerer. If it sends an INVITE with its candidates, = it may take a while before the INVITE even reaches the peer agent, due = to network services, call forwarding etc etc etc. >=20 >=20 >=20 >=20 > This was actually one of the issues raised related to the timer start. = The offerer can start the timer when it got the first remote candidate = or end of candidates notification. Answerer is trickier, since there is = no signaling indication when offerer actually got the answer. This is = why I was thinking that an extra signaling message = (https://github.com/cdh4u/draft-ice-pac/issues/11 = ), indicating end of = sending candidate checks might work better then a timer. It=E2=80=99s not a perfect solution, but in Firefox we do start the = timer when we receive the first ICE candidate from the remote peer. Be = it as part of the SDP or separate via trickle ICE. Note: this needs to = happen though for valid and invalid candidates (e.g. if the ICE agent = can=E2=80=99t handle mDNS candidates, but all candidates it receives are = mDNS it needs to start the timer on the first candidate). We can not make this depend on end of candidates, because it=E2=80=99s = quite likely today that an ICE agent will never receive end of = candidates, especially with trickle ICE. I see ICE pac only as a not perfect workaround to cover for some corner = cases. While solving this via an extra signaling message might be the = better solution I think such a proposal should be done via a separate = draft if desired/needed. Best Nils Ohlmeier= --Apple-Mail=_E69C2C05-C8EA-404A-8B1B-9EFE7C77153E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 25, 2019, at 11:25, Roman Shpount <roman@telurix.com> = wrote:

On Thu, Apr 25, 2019 at 2:17 PM = Christer Holmberg <christer.holmberg@ericsson.com> wrote:

>The timer should = start when the connectivity checks start by the remote ICE agent. The timer is needed to make sure local candidate addresses = continue

>to accept STUN = binding requests for at least some minimal time, so technically timer = should start from the time remote ICE agent was informed about

>candidate = addresses and started connectivity checks. There is some signaling delay involved here, so it needs to = accounted by the timer value.

 

An agent doesn=E2=80=99t know when the peer agent will start = - especially not the offerer. If it sends an INVITE with its candidates, = it may take a while before the INVITE even reaches the peer agent, due = to network services, call forwarding etc etc etc.



This was actually one of the issues = raised related to the timer start. The offerer can start the timer when = it got the first remote candidate or end of candidates notification. = Answerer is trickier, since there is no signaling indication when = offerer actually got the answer. This is why I was thinking that an = extra signaling message (https://github.com/cdh4u/draft-ice-pac/issues/11), = indicating end of sending candidate checks might work better then a = timer.

It=E2=80=99s not a perfect solution, but in = Firefox we do start the timer when we receive the first ICE candidate = from the remote peer. Be it as part of the SDP or separate via trickle = ICE. Note: this needs to happen though for valid and invalid candidates = (e.g. if the ICE agent can=E2=80=99t handle mDNS candidates, but all = candidates it receives are mDNS it needs to start the timer on the first = candidate).
We can not make this depend on end of candidates, = because it=E2=80=99s quite likely today that an ICE agent will never = receive end of candidates, especially with trickle ICE.

I see ICE pac only as a not perfect workaround to = cover for some corner cases. While solving this via an extra signaling = message might be the better solution I think such a proposal should be = done via a separate draft if desired/needed.

Best
  Nils = Ohlmeier
= --Apple-Mail=_E69C2C05-C8EA-404A-8B1B-9EFE7C77153E-- From nobody Thu Apr 25 15:26:39 2019 Return-Path: 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 622A1120193 for ; Thu, 25 Apr 2019 15:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 5jFv33Bavr0D for ; Thu, 25 Apr 2019 15:26:34 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 8C6CE1200C5 for ; Thu, 25 Apr 2019 15:26:34 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id t21so632221pfh.2 for ; Thu, 25 Apr 2019 15:26:34 -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=ldsi+tmmmhNq9fiGGnLvuppbSA62n0d9O6z1eMH7EPk=; b=1lqZ9vwDJlS2MObimvjxvY0nKXcR9P8/f5bAoYfhds36t4y8C/WuF5pgNb8uhPEyCW KsiX3ryaA3pvqAGr44Y0eR17Gs8wJcHX1H7wMeuiwgOJKhw6lDw2OSRFa82bH02KROXN Sd1OrhiLsVDRGEZAxDNiYFE1t6FS2UrU0ssOuIqYG54E9HuABarlU+xogOCmzpFJgNNu WaYYDE1ohjnR1A7SyTkihaGwVILYqFRzf5IoDzRl5znTt1ZMG+GVf792FcnzSW6JuV30 Dq98fFFi5E9VKvxwr8hCsRoDVJAqJddFkCwNRnukExnzhPNyTN06IoqURiyEB9kO8zhu T2pg== 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=ldsi+tmmmhNq9fiGGnLvuppbSA62n0d9O6z1eMH7EPk=; b=knUSKx7R+Ir4kCdyXQQvuTx5ulWm7MkV3S7ytSCW6w2RVNC/iyaEarbuRNnTw3gM9g eF0poBsb0edkXXZQNol9hSdc+huaU4Y8WKe+lCZwjlVN3f8cuIeK7CuweXnrtMBL0Fx8 kw91YO6lOWjdCmuSk1gMdpRYqXleAi2Nn61d6wrJFXvjTZYop3MWDpf7sxp5dDPDoJIC +IB5yCz3VXIfbFZC85Gn3m82KlYl6MLKuHK+BAeN63ThIisonGLTbAY6TBfebIjIK4pw 665Gtz3PLziGrrvqk7RGjPI0KfiVDRVsKfuTNrrPzco7qnnj9J0Vd+V42DyxNb+dj0y1 GYhA== X-Gm-Message-State: APjAAAWurqxWRDFJFf2APJyQeRElxAP5i8VB3iNP/MkcQ1HyK2jwxxNV UAga+uKxRZTcnmWkGviiVkIGQodzzNU= X-Google-Smtp-Source: APXvYqzDP9i3SVX6dr4ROJSMvyao7bzOE3w0CWREVsPAHi7ma9aZvYgQmHsGDmjiV9fuPd8pkA4Gjw== X-Received: by 2002:a63:6e09:: with SMTP id j9mr40205193pgc.416.1556231193858; Thu, 25 Apr 2019 15:26:33 -0700 (PDT) Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com. [209.85.214.181]) by smtp.gmail.com with ESMTPSA id h4sm31486683pfo.119.2019.04.25.15.26.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 15:26:32 -0700 (PDT) Received: by mail-pl1-f181.google.com with SMTP id z8so496849pln.4 for ; Thu, 25 Apr 2019 15:26:32 -0700 (PDT) X-Received: by 2002:a17:902:86:: with SMTP id a6mr41572138pla.277.1556231192632; Thu, 25 Apr 2019 15:26:32 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> In-Reply-To: <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> From: Roman Shpount Date: Thu, 25 Apr 2019 18:26:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nils Ohlmeier Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006ce9a80587624f08" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 22:26:37 -0000 --0000000000006ce9a80587624f08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier wrote= : > On Apr 25, 2019, at 11:25, Roman Shpount wrote: > > On Thu, Apr 25, 2019 at 2:17 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >The timer should start when the connectivity checks start by the remote >> ICE agent. The timer is needed to make sure local candidate addresses >> continue >> >> >to accept STUN binding requests for at least some minimal time, so >> technically timer should start from the time remote ICE agent was inform= ed >> about >> >> >candidate addresses and started connectivity checks. There is some >> signaling delay involved here, so it needs to accounted by the timer val= ue. >> >> >> >> An agent doesn=E2=80=99t know when the peer agent will start - especiall= y not the >> offerer. If it sends an INVITE with its candidates, it may take a while >> before the INVITE even reaches the peer agent, due to network services, >> call forwarding etc etc etc. >> >> >> > This was actually one of the issues raised related to the timer start. Th= e > offerer can start the timer when it got the first remote candidate or end > of candidates notification. Answerer is trickier, since there is no > signaling indication when offerer actually got the answer. This is why I > was thinking that an extra signaling message ( > https://github.com/cdh4u/draft-ice-pac/issues/11), indicating end of > sending candidate checks might work better then a timer. > > > It=E2=80=99s not a perfect solution, but in Firefox we do start the timer= when we > receive the first ICE candidate from the remote peer. Be it as part of th= e > SDP or separate via trickle ICE. Note: this needs to happen though for > valid and invalid candidates (e.g. if the ICE agent can=E2=80=99t handle = mDNS > candidates, but all candidates it receives are mDNS it needs to start the > timer on the first candidate). > We can not make this depend on end of candidates, because it=E2=80=99s qu= ite > likely today that an ICE agent will never receive end of candidates, > especially with trickle ICE. > It is possible that agent will never receive any candidates since it is technically legal to never send any candidates to the remote party when doing trickle ICE. I guess timer does not start in this case so ICE will wait before going into the failure state indefinitely. I see ICE pac only as a not perfect workaround to cover for some corner > cases. While solving this via an extra signaling message might be the > better solution I think such a proposal should be done via a separate dra= ft > if desired/needed. > I understand the desire to limit the scope of this draft. From what I can see there are 3 options: 1. Start timer when local ICE candidates collection was complete and at least one ICE candidates was received from the remote via signaling message or STUN bind request (timer starts when both conditions must be satisfied). The problem with this is timer might never start and agent will wait indefinitely. 2. Start timer when ICE candidates collection was complete or an ICE candidates was received from the remote via signaling message or STUN bind request (timer starts when either condition is satisfied). The problem here is that if signaling messages are delivered too slowly, ICE nomination will fail even when working candidate pair is potentially present. 3. Add some sort of extra signaling to indicate when ICE checks were complete. In case of WebRTC this option can be implemented via option 1 and some sort of application specific communications which will stop the indefinite wait. Based on this I would prefer going with option 1. _____________ Roman Shpount --0000000000006ce9a80587624f08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 25, 2019 at 3:45 PM N= ils Ohlmeier <nohlmeier@mozilla= .com> wrote:
On Apr 25, 2019, at 11:25, Ro= man Shpount <roma= n@telurix.com> wrote:

On Thu, Ap= r 25, 2019 at 2:17 PM Christer Holmberg <christer.holmberg@ericsson.com>= wrote:

>The timer should sta= rt when the connectivity checks start by the remote ICE agent. The timer is needed to make sure local candidate addresses continue<= br>

>to accept STUN binding reque= sts for at least some minimal time, so technically timer should start from = the time remote ICE agent was informed about

>ca= ndidate addresses and started connectivity checks. There is some signaling delay involved here, so it needs to accounte= d by the timer value.

=C2=A0

= An agent doesn=E2=80=99t know when the peer agent will= start - especially not the offerer. If it sends an INVITE with its candida= tes, it may take a while before the INVITE even reaches the peer agent, due= to network services, call forwarding etc etc etc.



This was= actually one of the issues raised related to the timer start. The offerer = can start the timer when it got the first remote candidate or end of candid= ates notification. Answerer is trickier, since there is no signaling indica= tion when offerer actually got the answer. This is why I was thinking that = an extra signaling message (https://github.com/cdh4u/draft-ice-pac/issu= es/11), indicating end of sending candidate checks might work better th= en a timer.

It=E2=80=99s= not a perfect solution, but in Firefox we do start the timer when we recei= ve the first ICE candidate from the remote peer. Be it as part of the SDP o= r separate via trickle ICE. Note: this needs to happen though for valid and= invalid candidates (e.g. if the ICE agent can=E2=80=99t handle mDNS candid= ates, but all candidates it receives are mDNS it needs to start the timer o= n the first candidate).
We can not make this depend on end of can= didates, because it=E2=80=99s quite likely today that an ICE agent will nev= er receive end of candidates, especially with trickle ICE.
=C2=A0
It is possible that agent will never receive = any candidates since it is technically legal to never send any candidates t= o the remote party when doing trickle ICE. I guess timer does not start in = this case so ICE will wait before going into the failure state indefinitely= .

I see ICE pac only as a not per= fect workaround to cover for some corner cases. While solving this via an e= xtra signaling message might be the better solution I think such a proposal= should be done via a separate draft if desired/needed.

I understand the desire to limit the scope of = this draft. From what I can see there are 3 options:

1. Start timer when local ICE candidates collection was complete and at = least one ICE candidates was received from the remote via signaling message= or STUN bind request (timer starts when both conditions must be satisfied)= . The problem with this is timer might never start and agent will wait inde= finitely.

2. Start timer when ICE candidates colle= ction was complete or=C2=A0an ICE candidates was received from the remote v= ia signaling message or STUN bind request (timer starts when either conditi= on is satisfied). The problem here is that if signaling messages are delive= red too slowly, ICE nomination will fail even when working candidate pair i= s potentially present.

3. Add some sort of extra s= ignaling to indicate when ICE checks were complete. In case of WebRTC this = option can be implemented via option 1 and some sort of application specifi= c communications which will stop the indefinite wait.

<= div>Based on this I would prefer going with option 1._____________Roman Shpount
=C2=A0
--0000000000006ce9a80587624f08-- From nobody Thu Apr 25 17:37:55 2019 Return-Path: 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 9D73A12035C for ; Thu, 25 Apr 2019 17:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 sZp2cx64KVuJ for ; Thu, 25 Apr 2019 17:37:50 -0700 (PDT) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 19A4B120350 for ; Thu, 25 Apr 2019 17:37:50 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id s4so762936pfh.7 for ; Thu, 25 Apr 2019 17:37:50 -0700 (PDT) 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=ghH0fxvr4DFP00tdRvneyQM7psx7KjwOAk1ECLoLMgs=; b=Y1wHUXqs4pwbtIpv7Mpb7hL30Oyz2YPa3RxxpTGum/b3dzHvDWTB3NAdH1Rm9zPKH4 U54AfjAPgX2sUSHAYjIblW7kfqa2KunG6J8JeGo1QQJfXqHVNAIbRUoXKB3GBjwWt9bP TnzAv98CxWXCOD6/1Kmpf5Afac4YnLyhvMJSg= 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=ghH0fxvr4DFP00tdRvneyQM7psx7KjwOAk1ECLoLMgs=; b=gR5I14VyvYpVH5RxITKo55KIfKDH4bl4LP0odATp6d4BmpACkqLP0eMOUTb9apPYND mj0vFtuidoNfH/9kksmERBXqV9aJCpUOzPlRWbDwRDpzRRBxQ/hwLq+CLncVGlUMhGMx yOB7jpuj75MY9/F6HlyPUTW5tFgFkiWbbm43FktAbNqqbzADTdS+vWgQFMN0h1fTPZVV uKqdImP4H+n2r6e0SR8bH506HTZ5GTF4W73XG4sxlYMxnDghSAbYIhZEQ3xOYctZUnIX veNaW8nLHKH8laGG0aEUoiKbdBus9JdiwEITpbU63FHreSXfQ8MWdIV4qEw9VOr/Hihw 6g+w== X-Gm-Message-State: APjAAAU2DUEHczLGElz/X2uu4x8sNoG7WnNHq/t6hAQCoOLfBzvAa/F2 5qnusns1lvPdTlr7FlKf1mkNpw== X-Google-Smtp-Source: APXvYqw69ArwVg1DXcIJEnS7Rr6vxSNP9RXDGuKtf+u15TO91u4nrZZN2oyUb1I5YoF9wOf/4c2kwQ== X-Received: by 2002:aa7:991b:: with SMTP id z27mr16061288pff.168.1556239069060; Thu, 25 Apr 2019 17:37:49 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:d1c0:5a1a:65d5:b91c? ([2601:647:4600:3f31:d1c0:5a1a:65d5:b91c]) by smtp.gmail.com with ESMTPSA id a129sm37592578pfa.152.2019.04.25.17.37.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 17:37:47 -0700 (PDT) From: Nils Ohlmeier Message-Id: <7E668B7E-F85A-4D4F-8A21-737ABAD524E3@mozilla.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6EA23B8A-B045-48CA-A453-51BE45412C3C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 25 Apr 2019 17:37:46 -0700 In-Reply-To: Cc: Christer Holmberg , "ice@ietf.org" To: Roman Shpount References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 00:37:53 -0000 --Apple-Mail=_6EA23B8A-B045-48CA-A453-51BE45412C3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 25, 2019, at 15:26, Roman Shpount wrote: >=20 > On Thu, Apr 25, 2019 at 3:45 PM Nils Ohlmeier > wrote: >=20 > I see ICE pac only as a not perfect workaround to cover for some = corner cases. While solving this via an extra signaling message might be = the better solution I think such a proposal should be done via a = separate draft if desired/needed. >=20 > I understand the desire to limit the scope of this draft. =46rom what = I can see there are 3 options: >=20 > 1. Start timer when local ICE candidates collection was complete and = at least one ICE candidates was received from the remote via signaling = message or STUN bind request (timer starts when both conditions must be = satisfied). The problem with this is timer might never start and agent = will wait indefinitely. >=20 > 2. Start timer when ICE candidates collection was complete or an ICE = candidates was received from the remote via signaling message or STUN = bind request (timer starts when either condition is satisfied). The = problem here is that if signaling messages are delivered too slowly, ICE = nomination will fail even when working candidate pair is potentially = present. Option 2 is basically what was implemented in Firefox for quite some = time. But we got too many failure reports from the field. So we switched = to something similar to Option 1. Thus I would advice against trying = option 2. Option 1 appears to be the reasonable although not perfect solution. Best Nils Ohlmeier > 3. Add some sort of extra signaling to indicate when ICE checks were = complete. In case of WebRTC this option can be implemented via option 1 = and some sort of application specific communications which will stop the = indefinite wait. >=20 > Based on this I would prefer going with option 1. > _____________ > Roman Shpount --Apple-Mail=_6EA23B8A-B045-48CA-A453-51BE45412C3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 25, 2019, at 15:26, Roman Shpount <roman@telurix.com> = wrote:

On Thu, Apr 25, 2019 at 3:45 PM Nils = Ohlmeier <nohlmeier@mozilla.com> wrote:

I see ICE pac only as a not perfect = workaround to cover for some corner cases. While solving this via an = extra signaling message might be the better solution I think such a = proposal should be done via a separate draft if desired/needed.

I understand the desire to limit the = scope of this draft. =46rom what I can see there are 3 = options:

1. = Start timer when local ICE candidates collection was complete and at = least one ICE candidates was received from the remote via signaling = message or STUN bind request (timer starts when both conditions must be = satisfied). The problem with this is timer might never start and agent = will wait indefinitely.

2. Start timer when ICE candidates collection was complete = or an ICE candidates was received from the remote via signaling = message or STUN bind request (timer starts when either condition is = satisfied). The problem here is that if signaling messages are delivered = too slowly, ICE nomination will fail even when working candidate pair is = potentially present.

Option 2 is basically what was implemented in Firefox = for quite some time. But we got too many failure reports from the field. = So we switched to something similar to Option 1. Thus I would advice = against trying option 2.

Option 1 = appears to be the reasonable although not perfect = solution.

Best
  Nils = Ohlmeier

3. Add some sort of extra signaling to indicate when ICE = checks were complete. In case of WebRTC this option can be implemented = via option 1 and some sort of application specific communications which = will stop the indefinite wait.

Based on this I would prefer going with = option 1.
_____________
Roman = Shpount

= --Apple-Mail=_6EA23B8A-B045-48CA-A453-51BE45412C3C-- From nobody Fri Apr 26 00:06:07 2019 Return-Path: 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 98BC212018B for ; Fri, 26 Apr 2019 00:06:05 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 7ZLkMGysLIDz for ; Fri, 26 Apr 2019 00:06:02 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20041.outbound.protection.outlook.com [40.107.2.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62DC12008C for ; Fri, 26 Apr 2019 00:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OQUgKVYOVj5OD+CUTTkxwW6gxIcD2jl4F/OP+5q1YmU=; b=akqlYccgAXtCFL48RiVZ3efQHBgxSHakJ9g0zDM1RUITy2T/YPfzJ4/lGHrRtePtF1XjpDEk3x5zx3zHo+RQw/MZ2cZZ0UYVy3anMUXskZTOU8yOVJxNP+9sdzqdeKDIp+vnCSq0pHNa5Dxvbfq6VLXvBuZ2b3uZM5isydGunzE= Received: from VI1PR07MB3167.eurprd07.prod.outlook.com (10.175.243.17) by VI1PR07MB5392.eurprd07.prod.outlook.com (20.178.14.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 07:05:57 +0000 Received: from VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706]) by VI1PR07MB3167.eurprd07.prod.outlook.com ([fe80::d925:d8b5:d1df:4706%4]) with mapi id 15.20.1856.004; Fri, 26 Apr 2019 07:05:57 +0000 From: Christer Holmberg To: Roman Shpount , Nils Ohlmeier CC: "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gA== Date: Fri, 26 Apr 2019 07:05:57 +0000 Message-ID: <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67fddca4-1704-4300-3ff6-08d6ca15a1be x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5392; x-ms-traffictypediagnostic: VI1PR07MB5392: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(366004)(396003)(136003)(376002)(199004)(189003)(53546011)(110136005)(3846002)(102836004)(26005)(44832011)(25786009)(81156014)(6506007)(68736007)(14444005)(486006)(81166006)(86362001)(561944003)(8676002)(8936002)(6246003)(33656002)(53936002)(93886005)(229853002)(256004)(6486002)(83716004)(66066001)(6512007)(186003)(236005)(606006)(476003)(54896002)(6306002)(11346002)(5660300002)(446003)(7736002)(82746002)(2616005)(2906002)(4326008)(73956011)(36756003)(76176011)(71200400001)(58126008)(14454004)(97736004)(6436002)(91956017)(316002)(66556008)(64756008)(66476007)(66446008)(478600001)(66946007)(71190400001)(6116002)(76116006)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5392; H:VI1PR07MB3167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kh9hX6JBescL+w8Hl5FvmRPYj5aJclJMm80Mh3VI8YiCEiBCv2GUiVGh9LN31V/u9GfF4q+UAvJPOYgrY1w7neoDytkc7T7WxHcKTraH50pdBaz1i843U3DoYSWjM9mLZg7sFWQumv7eP6Lfoc+LYWtM1OxyQcspM3Vj8Xgj+gpE69/3qZWa1BehILjTyfjffCLdqNcUPO1mPw0P1VvN12zSmghsy3Z0ew2JaaNoKaMqik3YWQqbhMCcMYsKofLHXCEPALIvAl7Fr75/is7iotKUg4N7W8+sbhqOnImDCIJTNKJt5J9XpJ99bRTQRQdHRnY1rk7gY89UG2OkaqsEY2pTkxmhfm2Cgpp/6rgnC0LX1ACS6YjoKIpF2RtVpbPGGiikbGaZbJrif7YzcRVUmAtyph3W62TsYNxaWJ1Chy0= Content-Type: multipart/alternative; boundary="_000_0AD3077C74FA4585942A375B83B3A7A0ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67fddca4-1704-4300-3ff6-08d6ca15a1be X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 07:05:57.4628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5392 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 07:06:06 -0000 --_000_0AD3077C74FA4585942A375B83B3A7A0ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIGlzIG9uZSBtb3JlIG9wdGlvbiAod2hpY2ggaGFzIGJlZW4gbXkgYXNzdW1w dGlvbik6DQoNCjQpIFN0YXJ0IHRoZSB0aW1lciB3aGVuIHRoZSBhZ2VudCB3b3VsZCBvdGhlcndp c2UgZGVjbGFyZSBJQ0UgZmFpbHVyZSwgaS5lLiwgd2hlbiBpdCBoYXMgdGVzdGVkIGFsbCBhdmFp bGFibGUgY2FuZGlkYXRlIHBhaXJzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkRhdGU6IEZyaWRheSwgMjYgQXByaWwg MjAxOSBhdCAxLjI2DQpUbzogTmlscyBPaGxtZWllciA8bm9obG1laWVyQG1vemlsbGEuY29tPg0K Q2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+LCAi aWNlQGlldGYub3JnIiA8aWNlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJY2VdIElDRSBQQUM6 IFdoZW4gdG8gc3RhcnQgdGhlIHRpbWVyIHdhaXRpbmcgZm9yIHBvc3NpYmxlIHBlZXIgcmVmbGV4 aXZlIGNhbmRpZGF0ZXM/DQoNCk9uIFRodSwgQXByIDI1LCAyMDE5IGF0IDM6NDUgUE0gTmlscyBP aGxtZWllciA8bm9obG1laWVyQG1vemlsbGEuY29tPG1haWx0bzpub2hsbWVpZXJAbW96aWxsYS5j b20+PiB3cm90ZToNCk9uIEFwciAyNSwgMjAxOSwgYXQgMTE6MjUsIFJvbWFuIFNocG91bnQgPHJv bWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KDQpPbiBU aHUsIEFwciAyNSwgMjAxOSBhdCAyOjE3IFBNIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KPlRoZSB0aW1lciBzaG91bGQgc3RhcnQgd2hlbiB0aGUgY29ubmVjdGl2aXR5 IGNoZWNrcyBzdGFydCBieSB0aGUgcmVtb3RlIElDRSBhZ2VudC4gVGhlIHRpbWVyIGlzIG5lZWRl ZCB0byBtYWtlIHN1cmUgbG9jYWwgY2FuZGlkYXRlIGFkZHJlc3NlcyBjb250aW51ZQ0KPnRvIGFj Y2VwdCBTVFVOIGJpbmRpbmcgcmVxdWVzdHMgZm9yIGF0IGxlYXN0IHNvbWUgbWluaW1hbCB0aW1l LCBzbyB0ZWNobmljYWxseSB0aW1lciBzaG91bGQgc3RhcnQgZnJvbSB0aGUgdGltZSByZW1vdGUg SUNFIGFnZW50IHdhcyBpbmZvcm1lZCBhYm91dA0KPmNhbmRpZGF0ZSBhZGRyZXNzZXMgYW5kIHN0 YXJ0ZWQgY29ubmVjdGl2aXR5IGNoZWNrcy4gVGhlcmUgaXMgc29tZSBzaWduYWxpbmcgZGVsYXkg aW52b2x2ZWQgaGVyZSwgc28gaXQgbmVlZHMgdG8gYWNjb3VudGVkIGJ5IHRoZSB0aW1lciB2YWx1 ZS4NCg0KQW4gYWdlbnQgZG9lc27igJl0IGtub3cgd2hlbiB0aGUgcGVlciBhZ2VudCB3aWxsIHN0 YXJ0IC0gZXNwZWNpYWxseSBub3QgdGhlIG9mZmVyZXIuIElmIGl0IHNlbmRzIGFuIElOVklURSB3 aXRoIGl0cyBjYW5kaWRhdGVzLCBpdCBtYXkgdGFrZSBhIHdoaWxlIGJlZm9yZSB0aGUgSU5WSVRF IGV2ZW4gcmVhY2hlcyB0aGUgcGVlciBhZ2VudCwgZHVlIHRvIG5ldHdvcmsgc2VydmljZXMsIGNh bGwgZm9yd2FyZGluZyBldGMgZXRjIGV0Yy4NCg0KDQpUaGlzIHdhcyBhY3R1YWxseSBvbmUgb2Yg dGhlIGlzc3VlcyByYWlzZWQgcmVsYXRlZCB0byB0aGUgdGltZXIgc3RhcnQuIFRoZSBvZmZlcmVy IGNhbiBzdGFydCB0aGUgdGltZXIgd2hlbiBpdCBnb3QgdGhlIGZpcnN0IHJlbW90ZSBjYW5kaWRh dGUgb3IgZW5kIG9mIGNhbmRpZGF0ZXMgbm90aWZpY2F0aW9uLiBBbnN3ZXJlciBpcyB0cmlja2ll ciwgc2luY2UgdGhlcmUgaXMgbm8gc2lnbmFsaW5nIGluZGljYXRpb24gd2hlbiBvZmZlcmVyIGFj dHVhbGx5IGdvdCB0aGUgYW5zd2VyLiBUaGlzIGlzIHdoeSBJIHdhcyB0aGlua2luZyB0aGF0IGFu IGV4dHJhIHNpZ25hbGluZyBtZXNzYWdlIChodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQt aWNlLXBhYy9pc3N1ZXMvMTEpLCBpbmRpY2F0aW5nIGVuZCBvZiBzZW5kaW5nIGNhbmRpZGF0ZSBj aGVja3MgbWlnaHQgd29yayBiZXR0ZXIgdGhlbiBhIHRpbWVyLg0KDQpJdOKAmXMgbm90IGEgcGVy ZmVjdCBzb2x1dGlvbiwgYnV0IGluIEZpcmVmb3ggd2UgZG8gc3RhcnQgdGhlIHRpbWVyIHdoZW4g d2UgcmVjZWl2ZSB0aGUgZmlyc3QgSUNFIGNhbmRpZGF0ZSBmcm9tIHRoZSByZW1vdGUgcGVlci4g QmUgaXQgYXMgcGFydCBvZiB0aGUgU0RQIG9yIHNlcGFyYXRlIHZpYSB0cmlja2xlIElDRS4gTm90 ZTogdGhpcyBuZWVkcyB0byBoYXBwZW4gdGhvdWdoIGZvciB2YWxpZCBhbmQgaW52YWxpZCBjYW5k aWRhdGVzIChlLmcuIGlmIHRoZSBJQ0UgYWdlbnQgY2Fu4oCZdCBoYW5kbGUgbUROUyBjYW5kaWRh dGVzLCBidXQgYWxsIGNhbmRpZGF0ZXMgaXQgcmVjZWl2ZXMgYXJlIG1ETlMgaXQgbmVlZHMgdG8g c3RhcnQgdGhlIHRpbWVyIG9uIHRoZSBmaXJzdCBjYW5kaWRhdGUpLg0KV2UgY2FuIG5vdCBtYWtl IHRoaXMgZGVwZW5kIG9uIGVuZCBvZiBjYW5kaWRhdGVzLCBiZWNhdXNlIGl04oCZcyBxdWl0ZSBs aWtlbHkgdG9kYXkgdGhhdCBhbiBJQ0UgYWdlbnQgd2lsbCBuZXZlciByZWNlaXZlIGVuZCBvZiBj YW5kaWRhdGVzLCBlc3BlY2lhbGx5IHdpdGggdHJpY2tsZSBJQ0UuDQoNCkl0IGlzIHBvc3NpYmxl IHRoYXQgYWdlbnQgd2lsbCBuZXZlciByZWNlaXZlIGFueSBjYW5kaWRhdGVzIHNpbmNlIGl0IGlz IHRlY2huaWNhbGx5IGxlZ2FsIHRvIG5ldmVyIHNlbmQgYW55IGNhbmRpZGF0ZXMgdG8gdGhlIHJl bW90ZSBwYXJ0eSB3aGVuIGRvaW5nIHRyaWNrbGUgSUNFLiBJIGd1ZXNzIHRpbWVyIGRvZXMgbm90 IHN0YXJ0IGluIHRoaXMgY2FzZSBzbyBJQ0Ugd2lsbCB3YWl0IGJlZm9yZSBnb2luZyBpbnRvIHRo ZSBmYWlsdXJlIHN0YXRlIGluZGVmaW5pdGVseS4NCg0KSSBzZWUgSUNFIHBhYyBvbmx5IGFzIGEg bm90IHBlcmZlY3Qgd29ya2Fyb3VuZCB0byBjb3ZlciBmb3Igc29tZSBjb3JuZXIgY2FzZXMuIFdo aWxlIHNvbHZpbmcgdGhpcyB2aWEgYW4gZXh0cmEgc2lnbmFsaW5nIG1lc3NhZ2UgbWlnaHQgYmUg dGhlIGJldHRlciBzb2x1dGlvbiBJIHRoaW5rIHN1Y2ggYSBwcm9wb3NhbCBzaG91bGQgYmUgZG9u ZSB2aWEgYSBzZXBhcmF0ZSBkcmFmdCBpZiBkZXNpcmVkL25lZWRlZC4NCg0KSSB1bmRlcnN0YW5k IHRoZSBkZXNpcmUgdG8gbGltaXQgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuIEZyb20gd2hhdCBJ IGNhbiBzZWUgdGhlcmUgYXJlIDMgb3B0aW9uczoNCg0KMS4gU3RhcnQgdGltZXIgd2hlbiBsb2Nh bCBJQ0UgY2FuZGlkYXRlcyBjb2xsZWN0aW9uIHdhcyBjb21wbGV0ZSBhbmQgYXQgbGVhc3Qgb25l IElDRSBjYW5kaWRhdGVzIHdhcyByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgdmlhIHNpZ25hbGlu ZyBtZXNzYWdlIG9yIFNUVU4gYmluZCByZXF1ZXN0ICh0aW1lciBzdGFydHMgd2hlbiBib3RoIGNv bmRpdGlvbnMgbXVzdCBiZSBzYXRpc2ZpZWQpLiBUaGUgcHJvYmxlbSB3aXRoIHRoaXMgaXMgdGlt ZXIgbWlnaHQgbmV2ZXIgc3RhcnQgYW5kIGFnZW50IHdpbGwgd2FpdCBpbmRlZmluaXRlbHkuDQoN CjIuIFN0YXJ0IHRpbWVyIHdoZW4gSUNFIGNhbmRpZGF0ZXMgY29sbGVjdGlvbiB3YXMgY29tcGxl dGUgb3IgYW4gSUNFIGNhbmRpZGF0ZXMgd2FzIHJlY2VpdmVkIGZyb20gdGhlIHJlbW90ZSB2aWEg c2lnbmFsaW5nIG1lc3NhZ2Ugb3IgU1RVTiBiaW5kIHJlcXVlc3QgKHRpbWVyIHN0YXJ0cyB3aGVu IGVpdGhlciBjb25kaXRpb24gaXMgc2F0aXNmaWVkKS4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0 IGlmIHNpZ25hbGluZyBtZXNzYWdlcyBhcmUgZGVsaXZlcmVkIHRvbyBzbG93bHksIElDRSBub21p bmF0aW9uIHdpbGwgZmFpbCBldmVuIHdoZW4gd29ya2luZyBjYW5kaWRhdGUgcGFpciBpcyBwb3Rl bnRpYWxseSBwcmVzZW50Lg0KDQozLiBBZGQgc29tZSBzb3J0IG9mIGV4dHJhIHNpZ25hbGluZyB0 byBpbmRpY2F0ZSB3aGVuIElDRSBjaGVja3Mgd2VyZSBjb21wbGV0ZS4gSW4gY2FzZSBvZiBXZWJS VEMgdGhpcyBvcHRpb24gY2FuIGJlIGltcGxlbWVudGVkIHZpYSBvcHRpb24gMSBhbmQgc29tZSBz b3J0IG9mIGFwcGxpY2F0aW9uIHNwZWNpZmljIGNvbW11bmljYXRpb25zIHdoaWNoIHdpbGwgc3Rv cCB0aGUgaW5kZWZpbml0ZSB3YWl0Lg0KDQpCYXNlZCBvbiB0aGlzIEkgd291bGQgcHJlZmVyIGdv aW5nIHdpdGggb3B0aW9uIDEuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_0AD3077C74FA4585942A375B83B3A7A0ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <85F9CAA83372F74D924C33DB6FF8418F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZXJlIGlzIG9uZSBtb3JlIG9wdGlvbiAod2hpY2ggaGFzIGJlZW4gbXkgYXNzdW1wdGlv bik6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj40KSBTdGFydCB0aGUgdGltZXIgd2hlbiB0aGUgYWdlbnQg d291bGQgb3RoZXJ3aXNlIGRlY2xhcmUgSUNFIGZhaWx1cmUsIGkuZS4sIHdoZW4gaXQgaGFzIHRl c3RlZCBhbGwgYXZhaWxhYmxlIGNhbmRpZGF0ZSBwYWlycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTog PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Um9t YW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZy aWRheSwgMjYgQXByaWwgMjAxOSBhdCAxLjI2PGJyPg0KPGI+VG86IDwvYj5OaWxzIE9obG1laWVy ICZsdDtub2hsbWVpZXJAbW96aWxsYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5DaHJpc3RlciBI b2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywgJnF1b3Q7aWNl QGlldGYub3JnJnF1b3Q7ICZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9i PlJlOiBbSWNlXSBJQ0UgUEFDOiBXaGVuIHRvIHN0YXJ0IHRoZSB0aW1lciB3YWl0aW5nIGZvciBw b3NzaWJsZSBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVGh1LCBBcHIgMjUsIDIwMTkgYXQgMzo0NSBQTSBOaWxzIE9obG1laWVyICZsdDs8YSBo cmVmPSJtYWlsdG86bm9obG1laWVyQG1vemlsbGEuY29tIj5ub2hsbWVpZXJAbW96aWxsYS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBBcHIgMjUsIDIwMTksIGF0IDExOjI1LCBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVm PSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgMjUsIDIwMTkgYXQgMjox NyBQTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtUaGUgdGltZXIgc2hvdWxkIHN0YXJ0IHdoZW4g dGhlIGNvbm5lY3Rpdml0eSBjaGVja3Mgc3RhcnQgYnkgdGhlIHJlbW90ZSBJQ0UgYWdlbnQuDQo8 L3NwYW4+VGhlIHRpbWVyIGlzIG5lZWRlZCB0byBtYWtlIHN1cmUgbG9jYWwgY2FuZGlkYXRlIGFk ZHJlc3NlcyBjb250aW51ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDt0byBhY2NlcHQgU1RVTiBiaW5kaW5nIHJlcXVl c3RzIGZvciBhdCBsZWFzdCBzb21lIG1pbmltYWwgdGltZSwgc28gdGVjaG5pY2FsbHkgdGltZXIg c2hvdWxkIHN0YXJ0IGZyb20gdGhlIHRpbWUgcmVtb3RlIElDRSBhZ2VudCB3YXMgaW5mb3JtZWQg YWJvdXQNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZndDtjYW5kaWRhdGUgYWRkcmVzc2VzIGFuZCBzdGFydGVkIGNvbm5l Y3Rpdml0eSBjaGVja3MuDQo8L3NwYW4+VGhlcmUgaXMgc29tZSBzaWduYWxpbmcgZGVsYXkgaW52 b2x2ZWQgaGVyZSwgc28gaXQgbmVlZHMgdG8gYWNjb3VudGVkIGJ5IHRoZSB0aW1lciB2YWx1ZS4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5B biBhZ2VudCBkb2VzbuKAmXQga25vdyB3aGVuIHRoZSBwZWVyIGFnZW50IHdpbGwgc3RhcnQgLSBl c3BlY2lhbGx5IG5vdCB0aGUgb2ZmZXJlci4gSWYgaXQgc2VuZHMgYW4gSU5WSVRFIHdpdGggaXRz IGNhbmRpZGF0ZXMsIGl0IG1heSB0YWtlIGEgd2hpbGUgYmVmb3JlIHRoZSBJTlZJVEUNCiBldmVu IHJlYWNoZXMgdGhlIHBlZXIgYWdlbnQsIGR1ZSB0byBuZXR3b3JrIHNlcnZpY2VzLCBjYWxsIGZv cndhcmRpbmcgZXRjIGV0YyBldGMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyB3YXMgYWN0dWFsbHkgb25lIG9mIHRoZSBpc3N1ZXMgcmFpc2VkIHJlbGF0ZWQgdG8gdGhlIHRp bWVyIHN0YXJ0LiBUaGUgb2ZmZXJlciBjYW4gc3RhcnQgdGhlIHRpbWVyIHdoZW4gaXQgZ290IHRo ZSBmaXJzdCByZW1vdGUgY2FuZGlkYXRlIG9yIGVuZCBvZiBjYW5kaWRhdGVzIG5vdGlmaWNhdGlv bi4gQW5zd2VyZXIgaXMgdHJpY2tpZXIsIHNpbmNlIHRoZXJlIGlzIG5vIHNpZ25hbGluZyBpbmRp Y2F0aW9uDQogd2hlbiBvZmZlcmVyIGFjdHVhbGx5IGdvdCB0aGUgYW5zd2VyLiBUaGlzIGlzIHdo eSBJIHdhcyB0aGlua2luZyB0aGF0IGFuIGV4dHJhIHNpZ25hbGluZyBtZXNzYWdlICg8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9pc3N1ZXMvMTEiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtaWNlLXBhYy9pc3N1ZXMv MTE8L2E+KSwgaW5kaWNhdGluZyBlbmQgb2Ygc2VuZGluZyBjYW5kaWRhdGUNCiBjaGVja3MgbWln aHQgd29yayBiZXR0ZXIgdGhlbiBhIHRpbWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pkl04oCZcyBub3QgYSBwZXJmZWN0IHNvbHV0aW9uLCBidXQgaW4gRmlyZWZveCB3ZSBkbyBzdGFy dCB0aGUgdGltZXIgd2hlbiB3ZSByZWNlaXZlIHRoZSBmaXJzdCBJQ0UgY2FuZGlkYXRlIGZyb20g dGhlIHJlbW90ZSBwZWVyLiBCZSBpdCBhcyBwYXJ0IG9mIHRoZSBTRFAgb3Igc2VwYXJhdGUgdmlh IHRyaWNrbGUgSUNFLiBOb3RlOiB0aGlzIG5lZWRzIHRvIGhhcHBlbiB0aG91Z2ggZm9yIHZhbGlk IGFuZCBpbnZhbGlkDQogY2FuZGlkYXRlcyAoZS5nLiBpZiB0aGUgSUNFIGFnZW50IGNhbuKAmXQg aGFuZGxlIG1ETlMgY2FuZGlkYXRlcywgYnV0IGFsbCBjYW5kaWRhdGVzIGl0IHJlY2VpdmVzIGFy ZSBtRE5TIGl0IG5lZWRzIHRvIHN0YXJ0IHRoZSB0aW1lciBvbiB0aGUgZmlyc3QgY2FuZGlkYXRl KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldl IGNhbiBub3QgbWFrZSB0aGlzIGRlcGVuZCBvbiBlbmQgb2YgY2FuZGlkYXRlcywgYmVjYXVzZSBp dOKAmXMgcXVpdGUgbGlrZWx5IHRvZGF5IHRoYXQgYW4gSUNFIGFnZW50IHdpbGwgbmV2ZXIgcmVj ZWl2ZSBlbmQgb2YgY2FuZGlkYXRlcywgZXNwZWNpYWxseSB3aXRoIHRyaWNrbGUgSUNFLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGlzIHBvc3NpYmxlIHRoYXQgYWdlbnQgd2lsbCBuZXZlciByZWNl aXZlIGFueSBjYW5kaWRhdGVzIHNpbmNlIGl0IGlzIHRlY2huaWNhbGx5IGxlZ2FsIHRvIG5ldmVy IHNlbmQgYW55IGNhbmRpZGF0ZXMgdG8gdGhlIHJlbW90ZSBwYXJ0eSB3aGVuIGRvaW5nIHRyaWNr bGUgSUNFLiBJIGd1ZXNzIHRpbWVyIGRvZXMgbm90IHN0YXJ0IGluIHRoaXMgY2FzZSBzbyBJQ0Ug d2lsbCB3YWl0IGJlZm9yZSBnb2luZyBpbnRvDQogdGhlIGZhaWx1cmUgc3RhdGUgaW5kZWZpbml0 ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIElDRSBwYWMgb25seSBhcyBhIG5vdCBwZXJmZWN0 IHdvcmthcm91bmQgdG8gY292ZXIgZm9yIHNvbWUgY29ybmVyIGNhc2VzLiBXaGlsZSBzb2x2aW5n IHRoaXMgdmlhIGFuIGV4dHJhIHNpZ25hbGluZyBtZXNzYWdlIG1pZ2h0IGJlIHRoZSBiZXR0ZXIg c29sdXRpb24gSSB0aGluayBzdWNoIGEgcHJvcG9zYWwgc2hvdWxkIGJlIGRvbmUgdmlhIGEgc2Vw YXJhdGUgZHJhZnQgaWYgZGVzaXJlZC9uZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRl cnN0YW5kIHRoZSBkZXNpcmUgdG8gbGltaXQgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQuIEZyb20g d2hhdCBJIGNhbiBzZWUgdGhlcmUgYXJlIDMgb3B0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gU3RhcnQgdGltZXIgd2hlbiBsb2Nh bCBJQ0UgY2FuZGlkYXRlcyBjb2xsZWN0aW9uIHdhcyBjb21wbGV0ZSBhbmQgYXQgbGVhc3Qgb25l IElDRSBjYW5kaWRhdGVzIHdhcyByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgdmlhIHNpZ25hbGlu ZyBtZXNzYWdlIG9yIFNUVU4gYmluZCByZXF1ZXN0ICh0aW1lciBzdGFydHMgd2hlbiBib3RoIGNv bmRpdGlvbnMgbXVzdCBiZSBzYXRpc2ZpZWQpLiBUaGUgcHJvYmxlbQ0KIHdpdGggdGhpcyBpcyB0 aW1lciBtaWdodCBuZXZlciBzdGFydCBhbmQgYWdlbnQgd2lsbCB3YWl0IGluZGVmaW5pdGVseS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4g U3RhcnQgdGltZXIgd2hlbiBJQ0UgY2FuZGlkYXRlcyBjb2xsZWN0aW9uIHdhcyBjb21wbGV0ZSBv ciZuYnNwO2FuIElDRSBjYW5kaWRhdGVzIHdhcyByZWNlaXZlZCBmcm9tIHRoZSByZW1vdGUgdmlh IHNpZ25hbGluZyBtZXNzYWdlIG9yIFNUVU4gYmluZCByZXF1ZXN0ICh0aW1lciBzdGFydHMgd2hl biBlaXRoZXIgY29uZGl0aW9uIGlzIHNhdGlzZmllZCkuIFRoZSBwcm9ibGVtIGhlcmUgaXMgdGhh dCBpZiBzaWduYWxpbmcNCiBtZXNzYWdlcyBhcmUgZGVsaXZlcmVkIHRvbyBzbG93bHksIElDRSBu b21pbmF0aW9uIHdpbGwgZmFpbCBldmVuIHdoZW4gd29ya2luZyBjYW5kaWRhdGUgcGFpciBpcyBw b3RlbnRpYWxseSBwcmVzZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4zLiBBZGQgc29tZSBzb3J0IG9mIGV4dHJhIHNpZ25hbGluZyB0byBp bmRpY2F0ZSB3aGVuIElDRSBjaGVja3Mgd2VyZSBjb21wbGV0ZS4gSW4gY2FzZSBvZiBXZWJSVEMg dGhpcyBvcHRpb24gY2FuIGJlIGltcGxlbWVudGVkIHZpYSBvcHRpb24gMSBhbmQgc29tZSBzb3J0 IG9mIGFwcGxpY2F0aW9uIHNwZWNpZmljIGNvbW11bmljYXRpb25zIHdoaWNoIHdpbGwgc3RvcCB0 aGUgaW5kZWZpbml0ZSB3YWl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CYXNlZCBvbiB0aGlzIEkgd291bGQgcHJlZmVyIGdvaW5nIHdpdGgg b3B0aW9uIDEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0AD3077C74FA4585942A375B83B3A7A0ericssoncom_-- From nobody Fri Apr 26 08:08:20 2019 Return-Path: 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 3D9C41205D5 for ; Fri, 26 Apr 2019 08:08:05 -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 uMv8UzqdD_6A for ; Fri, 26 Apr 2019 08:08:03 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 1FF0C12043E for ; Fri, 26 Apr 2019 08:08:03 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id w25so1867271pfi.9 for ; Fri, 26 Apr 2019 08:08:03 -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=gij4PwWDfLGP7hoR20trF35UpGjnImozNvKVZxCKHo0=; b=ditUZlssm1V4fOwQYTyJ9ZSMuUHsbUTqYAuKhKbJ1ydNZjsgJJuzZ8kWtfc6aBK7Yl wUcb+Kfhjsp4w1Jox2YI5ZOwVRZgB7pOwmFmJ6RP0w7zqCwiMET/CZa0v5DqGeuX/iBn 0g0g1/tCBZIjlVgqL7tPfvu/PNc0ApOUfNW/nkkfVrabvrvO+8H/izQYmLdK0+qGahsZ 7tmv1UvfKANC3boVRf7o1YL/dIP5m4Tv/RZviARLg6w3sFbx8Zvy/ayU0H9BkVIadMKt +bcg2yr7Oc0IaA9Ro+5xcVM3lWNDkyL1QeOixOcWNMOOEQhZzN1vgHs5O5iZthLTbrnJ cX5A== 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=gij4PwWDfLGP7hoR20trF35UpGjnImozNvKVZxCKHo0=; b=hcJLM7BPIyPPuWo9hdtUqGuacWfwrPfdkFTkY/PqPUofKIlP2pr4zDmKwike6LO6OT +he5fq0hSSp8XVn4GxVSG6hUQuYzynMMVUi1jF7WKSSUkNjPGhiwus2CHujOjfGfEwKb 6hv3wgV3UW2VxSGQu/MlS3gDuFIv56g+jcAt92vGS7QydGO4FfBfLgwPoarf8WfWp8a5 Jkl3GJpGU05CQk4GTrOLOEkYRh12INIGyRUhyezfc6HWR5qPkN8QtCNnzL0dMt88NjfB ru98cFn63LFJ1bWDWdBrDQXrrbwWj5I6uBApg7sAbvavNKHjwyRZuD62Cx6NOe59cpME Ckqw== X-Gm-Message-State: APjAAAUL7vLBYlDQgcimstG5hvz0xrv0rWQvMiuha9ujYFjQ7YgvD6VV bzFyx/A+ufY1dru7IP0kj768prdPzik= X-Google-Smtp-Source: APXvYqww+12SlUKtjlWg3fS/znZGpRamTjMFxEri8caYiXQXH6xuTnZkv08m3PgJwQW9KuBApXnTUw== X-Received: by 2002:a63:fd58:: with SMTP id m24mr20427848pgj.298.1556291282200; Fri, 26 Apr 2019 08:08:02 -0700 (PDT) Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com. [209.85.215.171]) by smtp.gmail.com with ESMTPSA id y1sm29130817pgc.29.2019.04.26.08.08.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 08:08:01 -0700 (PDT) Received: by mail-pg1-f171.google.com with SMTP id k19so1786763pgh.0 for ; Fri, 26 Apr 2019 08:08:01 -0700 (PDT) X-Received: by 2002:a65:6110:: with SMTP id z16mr35641010pgu.131.1556291280776; Fri, 26 Apr 2019 08:08:00 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> From: Roman Shpount Date: Fri, 26 Apr 2019 11:07:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f5377b0587704c31" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 15:08:16 -0000 --000000000000f5377b0587704c31 Content-Type: text/plain; charset="UTF-8" Hi Christer, On Fri, Apr 26, 2019 at 3:06 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > There is one more option (which has been my assumption): > > > > 4) Start the timer when the agent would otherwise declare ICE failure, > i.e., when it has tested all available candidate pairs. > > > I think this option does not work quite well. With option 4, when ICE agent has a list of valid remote candidates and all these candidates do not fail immediately with ICMP error, ICE agent will spend enough time trying those candidates before failing for any remote binding attempts to arrive. So, option 4 ends up adding extra time when it is not needed. On the other hand, when ICE agent does not get any remote candidates, it can go into a failed state and start timeout before local candidates collected by this agent were delivered to remote over signaling causing a premature failure. Regards, _____________ Roman Shpount --000000000000f5377b0587704c31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Christer,

On = Fri, Apr 26, 2019 at 3:06 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=

There is one more option (which has been my assump= tion):

=C2=A0

4) Start the timer when the age= nt would otherwise declare ICE failure, i.e., when it has tested all availa= ble candidate pairs.



I think this option does not work quite well. With option 4, when ICE agen= t has a list of valid remote candidates and all these candidates do not fai= l immediately with ICMP error, ICE agent will spend enough time trying thos= e candidates before failing for any remote binding attempts to arrive. So, = option 4 ends up adding extra time when it is not needed.=C2=A0 On the othe= r hand, when ICE agent does not get any remote candidates, it can go into a= failed state and start timeout before local candidates collected by this a= gent were delivered to remote over signaling causing a premature failure.

Regards,
_____________
Roman Shpount
=C2=A0
--000000000000f5377b0587704c31-- From nobody Fri Apr 26 13:28:25 2019 Return-Path: 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 4AB9812001B for ; Fri, 26 Apr 2019 13:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 eteFCfE4E3vY for ; Fri, 26 Apr 2019 13:28:20 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB051201A1 for ; Fri, 26 Apr 2019 13:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WAMhBAJLCpYgYYtdqiM44nHwC30B3MPopj8Yzvf4dgI=; b=LKej0WMzL8bj309IEv1Bwa9LODx0jbzsyjANGI3qK9iEjro6VUTmbcD4MdiB+fZHZ9fYNT7SMCmkPpnW/DNMwh5ZdxRop1mra+xRfqSm6vBSTOs+UXovWkBL/5e6+AevxtSJf4axBYgQiy9MyfGM0utpncdxxsXDp8Z+yeeE+rU= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3449.eurprd07.prod.outlook.com (10.170.247.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 20:28:16 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Fri, 26 Apr 2019 20:28:16 +0000 From: Christer Holmberg To: Roman Shpount CC: Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gIAAVFgAgABZAV0= Date: Fri, 26 Apr 2019 20:28:16 +0000 Message-ID: References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14bb:93:5e2d:3499:b688:5a84:7017] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5414ce97-60ac-4d12-a123-08d6ca85b6e4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3449; x-ms-traffictypediagnostic: HE1PR07MB3449: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(366004)(346002)(376002)(189003)(199004)(54906003)(476003)(14454004)(9686003)(6246003)(102836004)(446003)(6916009)(236005)(11346002)(54896002)(46003)(316002)(53936002)(33656002)(229853002)(478600001)(99286004)(76176011)(5660300002)(53546011)(44832011)(186003)(486006)(6506007)(7696005)(68736007)(55016002)(4326008)(71200400001)(71190400001)(25786009)(52536014)(6436002)(86362001)(97736004)(8676002)(74316002)(93886005)(66446008)(8936002)(66476007)(66556008)(64756008)(81166006)(81156014)(7736002)(6116002)(66946007)(76116006)(73956011)(5070765005)(2906002)(256004)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3449; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gdtRFS8UjF4PDXfRDmwOTzR0HKnk6AXBOo3CWRfGKeOBpYvL8yWCWEbH8i+h3cZxZoweHFO31zKzsG2m2lLS2MUBPYbEwy9k++OWm+Q2kcTEdCeDlJWc0hew6k6LVdEf9cBSVJe2RoCR0u5VtQ0YdZzDX8gL3QlzEzVDkhpmeDbL/RA2GTwsnvfKCZmoW5hp9N6rP34JYBac6Wg5T/N+remSRCp7olbmBENGoAHnA7FAlcVu1T845ZekuMCh+VxC7k9TVTRU5nqieob+Otom4rZj3NSeLt7dWJqyAPlFRF9s0lJl/iOnnDYitOCuXjYd0D543IT2TIUlZsUDOzsX+cZ9m9tn+VQh/pv3V1Jj5uYXg48pNakBxr5d+cpn9lltvv4CZIlMmDFDD/268sMb5mh6bTHa9i1/3Z0dFu4fNJk= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316172053751D307F83DE0EB933E0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5414ce97-60ac-4d12-a123-08d6ca85b6e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 20:28:16.5752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3449 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:28:24 -0000 --_000_HE1PR07MB316172053751D307F83DE0EB933E0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In a non-trickle case, I think it would be very strange if the agent didn= =92t get any candidates front the peer agent. Regards, Christer ________________________________ From: Roman Shpount Sent: Friday, April 26, 2019 6:07:50 PM To: Christer Holmberg Cc: Nils Ohlmeier; ice@ietf.org Subject: Re: [Ice] ICE PAC: When to start the timer waiting for possible pe= er reflexive candidates? Hi Christer, On Fri, Apr 26, 2019 at 3:06 AM Christer Holmberg > wrote: There is one more option (which has been my assumption): 4) Start the timer when the agent would otherwise declare ICE failure, i.e.= , when it has tested all available candidate pairs. I think this option does not work quite well. With option 4, when ICE agent= has a list of valid remote candidates and all these candidates do not fail= immediately with ICMP error, ICE agent will spend enough time trying those= candidates before failing for any remote binding attempts to arrive. So, o= ption 4 ends up adding extra time when it is not needed. On the other hand= , when ICE agent does not get any remote candidates, it can go into a faile= d state and start timeout before local candidates collected by this agent w= ere delivered to remote over signaling causing a premature failure. Regards, _____________ Roman Shpount --_000_HE1PR07MB316172053751D307F83DE0EB933E0HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi,

In a non-trickle case, I think it would be very strange if the agent didn= =92t get any candidates front the peer agent.

Regards,

Christer
From: Roman Shpount <rom= an@telurix.com>
Sent: Friday, April 26, 2019 6:07:50 PM
To: Christer Holmberg
Cc: Nils Ohlmeier; ice@ietf.org
Subject: Re: [Ice] ICE PAC: When to start the timer waiting for poss= ible peer reflexive candidates?
 

Hi Christer,

On Fri, Apr 26, 2019 at 3:06 AM Chr= ister Holmberg <christ= er.holmberg@ericsson.com> wrote:

There is one more option (whi= ch has been my assumption):

 

4) Start the timer when the a= gent would otherwise declare ICE failure, i.e., when it has tested all avai= lable candidate pairs.



I think this option does not work quite well. With option 4, when ICE = agent has a list of valid remote candidates and all these candidates do not= fail immediately with ICMP error, ICE agent will spend enough time trying = those candidates before failing for any remote binding attempts to arrive. So, option 4 ends up adding ext= ra time when it is not needed.  On the other hand, when ICE agent does= not get any remote candidates, it can go into a failed state and start tim= eout before local candidates collected by this agent were delivered to remote over signaling causing a premature = failure.

Regards,
_____________
Roman Shpount
 
--_000_HE1PR07MB316172053751D307F83DE0EB933E0HE1PR07MB3161eurp_-- From nobody Fri Apr 26 13:46:53 2019 Return-Path: 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 EC0E31205FF for ; Fri, 26 Apr 2019 13:46:50 -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 wmqf-pRPVGDY for ; Fri, 26 Apr 2019 13:46:48 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 DE1AF12025B for ; Fri, 26 Apr 2019 13:46:48 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id d9so2093172pls.8 for ; Fri, 26 Apr 2019 13:46:48 -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=IUfGJNmbW9e0p9/1G5T2MqvAFjjkyAV5AEh/J+kvMj8=; b=BVe+cSRW70PQ7HphgqYnLpWvlwL+GMpmeaFdimb48bBL9kO0TLSq/7+2EQRXhHJ2u6 ZZVZ3edbYAJ9Dtc/jtzv1jqTpA1/mKhxVfZ2z1dXjBIm9gkjE3LVx1h3sVFPZuVdNGTV yiOBEB5WbQJDnsQSRJuh4E71BUY59jNgAmkX8L8n3d0kXz+KWz1k/qhvNT802wyAaeGG 04OZgMLmG9NCu6PbWDfH3q61UuTzdnVCOTZ0fhl6O48jUPiOIF7VQdv52idE20Lio398 8QEQHiTJgnk7/599UAzK4VpIc7my245m4ZHUvDed6iizwRMBkil0E0gkgvmTcvfirjeZ 60Xg== 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=IUfGJNmbW9e0p9/1G5T2MqvAFjjkyAV5AEh/J+kvMj8=; b=NGbz4lRt0o694PWZPXjCjKcoTTOcwWtrPa/YzHSqYRzEJcpXA26g4TVMQtf3Q33zab 7GuDO/YpRmMqWBcjqbRRTruH8TtycnrT7gtdK6ZBr88N5QnReSv9w7MPGdLmSLKia8pa /6It8hvb1bH4OhlL1O8kfD170M4Q9QxWiJZVwcIQjx3v0993clZdKggPfH/4AZAyAmrc 6EF7j4BUqu9aEKCW2ks8+Cdq1C1TSHYgTIy8VVc+hca1I4IvasiwLQqE1ts6lZfMwLkX 58YZagxNYIUwAGwORMAssJfp3PY80GXnPwT6sVkOF5LzoP/PyXF2SOxNYpeknzJyR9kh zPPQ== X-Gm-Message-State: APjAAAWPXTgqO52DVAFR2jN2gS935qKduJ1JNIooa2qsII/0HmhZT469 mLog4ealXoZywCoc/Rvq2+e4bDtxua0= X-Google-Smtp-Source: APXvYqw52zCzGEQEPHa3RKVjfHVZn+ziG0xfux+LTPSCSWaFueH1/wgtMUyJEOU4FTNwvcrgq56rAw== X-Received: by 2002:a17:902:70c6:: with SMTP id l6mr46892684plt.95.1556311608209; Fri, 26 Apr 2019 13:46:48 -0700 (PDT) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com. [209.85.210.176]) by smtp.gmail.com with ESMTPSA id p20sm31621768pgh.83.2019.04.26.13.46.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 13:46:47 -0700 (PDT) Received: by mail-pf1-f176.google.com with SMTP id y13so2249887pfm.11 for ; Fri, 26 Apr 2019 13:46:47 -0700 (PDT) X-Received: by 2002:a65:6110:: with SMTP id z16mr37257929pgu.131.1556311607397; Fri, 26 Apr 2019 13:46:47 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: From: Roman Shpount Date: Fri, 26 Apr 2019 16:46:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="00000000000084d65b05877508bc" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 20:46:51 -0000 --00000000000084d65b05877508bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t 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. Regards, _____________ Roman Shpount --00000000000084d65b05877508bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

On Fri, Apr 26, 2019 at 4:28 PM Chr= ister Holmberg <christer.holmberg@ericsson.com> wrote:
In a non-trickle case, I think it would be very strange if the a= gent didn=E2=80=99t get any candidates front the peer agent.

<= /blockquote>

I have just sent a message to the mmusic li= st regarding ice-sip-sdp and offers with no candidates. There is nothing th= at 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 do= es not need to collect any candidates and simply send the offer. Once it ge= ts the answer from the server with the public address, client can send a ST= UN bind request to server address using a local socket not bound to any add= ress, which will use default route. There are multiple benefits for impleme= nting it this way, one of which would be client privacy.

Regards,
_____________
Roman Shpount
=C2=A0
--00000000000084d65b05877508bc-- From nobody Fri Apr 26 14:18:39 2019 Return-Path: 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 5CBC612023D for ; Fri, 26 Apr 2019 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 WuUzTlhPgQqL for ; Fri, 26 Apr 2019 14:18:34 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 93EE7120139 for ; Fri, 26 Apr 2019 14:18:34 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id o5so2112982pls.12 for ; Fri, 26 Apr 2019 14:18:34 -0700 (PDT) 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=1A1g/jchE9Y7cy9tn1cFPcd2pfR/GU5Epns+dOb09cY=; b=Isex4+vY1R1j2sRKomgaDsQPBZA91rH75YnGizGzuGHyVKOZCM266/8utKRS9hUkmA bDDD1lOAngUsI535RvUGyolq40cDlc5Che7/oXo1jCrt/BSphTT/D+s/F/r283KaWRZ9 OnQOQ6ofUKum1XvVjr8lrVRLv/P+JS2TGyg08= 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=1A1g/jchE9Y7cy9tn1cFPcd2pfR/GU5Epns+dOb09cY=; b=IVLhYjAmpjLnnOIvtahwzFBLtOOgCjFee7Y1sppyijDFfZsInI5doyE1G6WUNwJ59l zyzDPDZS/NNnWErVJdbaa5DrA8wxpk8jvP1b52WBJ0f5N9/1wi7pfbPufstRoA+0KChc wqCWyOrtwJsgGJYUsoEtVuwvficvp4mQW5OaqMZlQw/3FcJ5r/rw/KRIo+qGgaTajC7z M0dHESprtdV6OE/1XdUaoSuLwZQYQ/PsZOXWzmlqr40CzV6NZ4wIqxKdk+rhdj9GJFl+ A1nl1/6bFlw5SgkZiGyuZhe3vmnhBxtrRiI1VY32AqBu52FAmsGvhh44m1I76mXhJAlM h0TA== X-Gm-Message-State: APjAAAXJj6FI3A0qml0fUu3krtuKlfZCxHOTiLv2GUo6ghdgFuDUEMTH 1S0juzM2efTIchrykljPpqhG8A== X-Google-Smtp-Source: APXvYqx6h4pCFeepuA5rE5iNQxXb81GGDR36uNvvwEQE5An4XOfQwb4gfjhgimLI52FXKgDMMefeKA== X-Received: by 2002:a17:902:4827:: with SMTP id s36mr49380926pld.296.1556313513887; Fri, 26 Apr 2019 14:18:33 -0700 (PDT) Received: from [10.252.34.218] (guest-nat.fw1.untrust.mtv2.mozilla.net. [63.245.221.200]) by smtp.gmail.com with ESMTPSA id s20sm31585985pgs.39.2019.04.26.14.18.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 14:18:32 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6D40CF07-A0A1-4D6D-BB3D-64A7D71ADEA1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 26 Apr 2019 14:18:28 -0700 In-Reply-To: Cc: Christer Holmberg , "ice@ietf.org" To: Roman Shpount References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 21:18:37 -0000 --Apple-Mail=_6D40CF07-A0A1-4D6D-BB3D-64A7D71ADEA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 26, 2019, at 13:46, Roman Shpount wrote: >=20 > Hi Christer, >=20 > On Fri, Apr 26, 2019 at 4:28 PM Christer Holmberg = > = wrote: > In a non-trickle case, I think it would be very strange if the agent = didn=E2=80=99t get any candidates front the peer agent. >=20 >=20 > 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. >=20 > 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=E2=80=99s 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? Best Nils Ohlmeier --Apple-Mail=_6D40CF07-A0A1-4D6D-BB3D-64A7D71ADEA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99t 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=E2=80=99= 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?

Best
  Nils = Ohlmeier


= --Apple-Mail=_6D40CF07-A0A1-4D6D-BB3D-64A7D71ADEA1-- From nobody Fri Apr 26 14:33:48 2019 Return-Path: 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 ; 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 ; 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 ; Fri, 26 Apr 2019 14:33:43 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id l18so2194860pgj.6 for ; 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 (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 ; 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> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: From: Roman Shpount Date: Fri, 26 Apr 2019 17:33:32 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Nils Ohlmeier Cc: Christer Holmberg , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004263df058775b0f0" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 21:33:47 -0000 --0000000000004263df058775b0f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 26, 2019 at 5:18 PM Nils Ohlmeier wrote= : > > On Apr 26, 2019, at 13:46, Roman Shpount 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=E2=80=99t 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 woul= d > 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 i= t > 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=E2=80=99s know to be ice-li= te. > 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 --0000000000004263df058775b0f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2019 at 5:18 PM N= ils Ohlmeier <nohlmeier@mozilla= .com> wrote:

On Apr 26, 2019, at 13:46= , Roman Shpount <= roman@telurix.com> wrote:

<= div class=3D"gmail-m_1797815781350005375m_4913903664402873974gmail_signatur= e">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 stran= ge if the agent didn=E2=80=99t get any candidates front the peer agent.
=

I have just sent a message to th= e 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 s= ense 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 a= nd 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 ca= n 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 a= ctually works more generally in case the other side indicates to be ice-lit= e, or if it=E2=80=99s know to be ice-lite.
In other words: this s= hould 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 wel= l with ice-lite server for both offer and answer. We actually have this dep= loyed with ice-lite server and slightly "lobotomized" client (i.e= . client which starts trickle but never sends collected candidates to the s= erver). Once we get ICE PAC done, this would be consistently usable with fu= ll ICE on the server side as well.

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

Regards,
____________= _
Roman Shpount
=C2=A0=
--0000000000004263df058775b0f0-- From nobody Sat Apr 27 02:24:15 2019 Return-Path: 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 2494D12014E for ; Sat, 27 Apr 2019 02:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ericsson.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 V2oPyaEpxoaY for ; Sat, 27 Apr 2019 02:24:10 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10046.outbound.protection.outlook.com [40.107.1.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AA61200BA for ; Sat, 27 Apr 2019 02:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P8xHkLyKke6YQEJI3hWwvqEPHyJki7BYz3bnskugTEI=; b=jsWxiotaxuykdPwuP5kUxH7MuxDErU4KJp5bS9G00VaKC82bnrszQtlvGa/FOHtdZarticFC3O8JS31mZ307FkuVKuR+ITRdZ/5WlP0CN43D49IpPkk2/BeSnD67LqyuQip3DEd4WUF1S7sLoGOfiHxq2h8xZ36CBZ499zxNbIU= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3178.eurprd07.prod.outlook.com (10.170.245.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Sat, 27 Apr 2019 09:24:07 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Sat, 27 Apr 2019 09:24:07 +0000 From: Christer Holmberg To: Roman Shpount , Nils Ohlmeier CC: "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gIAAVFgAgABZAV2AAAWpgIAACOQAgAAENQCAAPjTAA== Date: Sat, 27 Apr 2019 09:24:07 +0000 Message-ID: <2CF0DF15-BCDB-46DF-8824-9D1017190649@ericsson.com> References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [2001:14bb:93:38bc:b527:32ec:e20d:66e2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9d085f3-e4db-43ab-0572-08d6caf21955 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3178; x-ms-traffictypediagnostic: HE1PR07MB3178: x-microsoft-antispam-prvs: x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(396003)(376002)(346002)(189003)(199004)(6436002)(81156014)(81166006)(82746002)(68736007)(6486002)(25786009)(2906002)(93886005)(8676002)(486006)(46003)(4326008)(8936002)(229853002)(11346002)(36756003)(86362001)(446003)(97736004)(44832011)(476003)(2616005)(73956011)(76116006)(66946007)(76176011)(66556008)(66476007)(66446008)(64756008)(71200400001)(71190400001)(83716004)(6246003)(110136005)(478600001)(14454004)(6506007)(102836004)(256004)(14444005)(7736002)(305945005)(6512007)(186003)(99286004)(558084003)(33656002)(53936002)(58126008)(316002)(6116002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3178; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Rew04l5NUIlTRRtyMZKJHe/ceGgyovsk2vDAZJn9insQGlT11YAb4VfAI/i+ORK/7OvymAE3BQFS1tzTCjWRI6wnQTYQRy74oOJu3GbMoKhhS3wD7oXgcYW9hwsVwhz2+fF9qxuyFi6s8J2edMd7Pes28lm3Son5tMx/ZnKBCuC+MP638Sa9byXcVEbVjTwlYEjZkmsC7fhfqTUvey3Kua48V4+1wurILEidW6P/rvN8SXNwcLBvMnYiy7eM0Ya7IsnG8wzGUt+aetHavyawT/gUwrdVTYUuV8ziKjlxXkQPdij1F2EfO+k/aZnZCsWaCw6pGc8px9Rji89lxP3cMUM/iLxGjxeW5wY8TRMUvY24NqzzU6czi8ZX+NEs9Se18EmLO3llSbJXe83UxW8xcQJjEQ5aGIzF+gy0E+xcbX0= Content-Type: text/plain; charset="utf-8" Content-ID: <584F6B1587E5544AB3D6C5059539ACDF@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d9d085f3-e4db-43ab-0572-08d6caf21955 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2019 09:24:07.4033 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3178 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 09:24:13 -0000 SGksDQoNCj5PbmUgdGhpbmcgSSB3YXMgY29uc2lkZXJpbmcgaXMgdGhhdCB3ZSBzaG91bGQgbWFr ZSBJQ0UgUEFDIG1hbmRhdG9yeSBmb3IgYW55dGhpbmcgdGhhdCBpbmNsdWRlcyBpY2Utb3B0aW9u czogaWNlMi4gDQo+SSB0aGluayBpdCBpcyBhbHJlYWR5IGltcGxpZWQgd2l0aCBteSBsYXRlc3Qg cHVsbCByZXF1ZXN0IHRvIGljZS1zaXAtc2RwLg0KDQonaWNlMicgaXMgZGVmaW5lZCBieSBSRkMg ODQ0NS4gSXQgaXMgbm90IGljZS1zaXAtc2RwIHNwZWNpZmljLg0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQrCoA0KDQo= From nobody Sat Apr 27 10:42:45 2019 Return-Path: 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 795A612011C for ; Sat, 27 Apr 2019 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 BxK15J34S-vP for ; Sat, 27 Apr 2019 10:42:41 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60050.outbound.protection.outlook.com [40.107.6.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05F812018C for ; Sat, 27 Apr 2019 10:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0aFeapVUw6QrpLLgaoJLU1j3rA046nxD5ui6Vop4ZiM=; b=J8TFfiu4dp2QtqB873Lxq4mZQ6J7E7/n6YFAMfeX8pBL8dAMZeNrvjmOVhn2B5LtY52lDxljoMOqKoScLnaRtQlm44fUR57jpjJIMqYdsjUmb9t/QWKnw4sA80gXmKgj+9V+91c1SlZno+q3ftpPIziwrZbJDm9qgGNrQtGLCu8= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Sat, 27 Apr 2019 17:42:37 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.007; Sat, 27 Apr 2019 17:42:37 +0000 From: Christer Holmberg To: Roman Shpount CC: Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gIAAVFgAgABZAV2AAAWpgIABXUof Date: Sat, 27 Apr 2019 17:42:37 +0000 Message-ID: References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [176.93.0.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 510760ae-fb9b-4da2-bdf4-08d6cb37bd16 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3308; x-ms-traffictypediagnostic: HE1PR07MB3308: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0020414413 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(136003)(346002)(189003)(199004)(14454004)(8936002)(86362001)(52536014)(66446008)(64756008)(66946007)(73956011)(66556008)(66476007)(33656002)(256004)(486006)(76116006)(14444005)(68736007)(44832011)(8676002)(81156014)(81166006)(6506007)(102836004)(97736004)(229853002)(19627405001)(26005)(316002)(6246003)(6916009)(5660300002)(55016002)(54906003)(54896002)(93886005)(53936002)(71190400001)(66066001)(6436002)(7696005)(6606003)(4326008)(9686003)(76176011)(2906002)(71200400001)(3846002)(74316002)(25786009)(7736002)(6116002)(446003)(186003)(476003)(11346002)(478600001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: N/bhcvQHMBdZ3awCW6nOSZZeDZtHKMuayD+byVJR2Mat/dI0lK/Yrmitaoaqa8ROFU5O5UG/mWrFPIgKi8MngSmCV2hOOosM2pI8gllrrKamIkc3HVYM1sZMevg13v16+sGkOgsPtly/MmSplkkvPMIfdg2RDkPxiN5IPa8MvGjTzR7K4+BWQFN40E6D2Se4jYmHpgGIVgaKFAB3U99a3Ri1K8oMG9dsEH64R0HN1QsEx5GtDvydFxsh5bavfR7wk2fzFzbozF8D2A8QHztZR4gac0K2qPvQqqJujlzj0tHUNb8FugKegPy3pj9c9wsW4Y7ETTRPZMCZB5upyzdmiBc7HUz4hd/0juZRgHSeTC/Dp5T1xgwxrYIvqqBRbAPHe/YEiTQBheC82HAokQYg3e2cjjurzAG5ZicJTtcs+Wo= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB316189447ED302BEC5021946933F0HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 510760ae-fb9b-4da2-bdf4-08d6cb37bd16 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2019 17:42:37.4368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 17:42:44 -0000 --_000_HE1PR07MB316189447ED302BEC5021946933F0HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In a non-trickle case, I think it would be very strange if the agent didn= =92t get any candidates front the peer agent. >I have just sent a message to the mmusic list regarding ice-sip-sdp and of= fers 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 allo= ws 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 d= oes 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 im= plementing it this way, one of which >would be client privacy. One option would then be to say that PAC only applies when an agent actuall= y has received some candidates from its peer. If an agent does NOT receive any candidates from the peer, it knows that th= e only candidates it will get are peer reflexive ones, and how long the ag= ent waits for those is an implementation issue. Regards, Christer --_000_HE1PR07MB316189447ED302BEC5021946933F0HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Hi,


In a non-trickle case, I think it wou= ld be very strange if the agent didn=92t get any candidates front the peer = agent.


>I have just sent a message to the mmusic list regarding ice-sip-sd= p and offers with >no candidates. There is nothing that technically proh= ibits it in RFC 5245, so I >thought it makes sense to add a note which e= xplicitly 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 case= s, client does not need >to collect any candidates and simply send the o= ffer. 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 defa= ult >route. There are multiple benefits for implementing it this way, on= e of which >would be client privacy.

One option would then be to say that PAC only applies when an agent ac= tually has received some candidates from its peer.

If an agent does NOT receive any candidates from the peer, it knows that th= e only  candidates it will get are peer reflexive ones, and how long t= he agent waits for those is an implementation issue.

Regards,

Christer

--_000_HE1PR07MB316189447ED302BEC5021946933F0HE1PR07MB3161eurp_-- From nobody Sun Apr 28 19:00:08 2019 Return-Path: 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 23257120257 for ; Sun, 28 Apr 2019 19:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 mAGEn_Ih1-Dn for ; Sun, 28 Apr 2019 19:00:05 -0700 (PDT) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 36CBF12024F for ; Sun, 28 Apr 2019 19:00:05 -0700 (PDT) Received: by mail-it1-x132.google.com with SMTP id z4so14078156itc.3 for ; Sun, 28 Apr 2019 19:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=guB467KLQ29ig8OoD0Ihm2ufZPGhy5AYIxdlj73COvk=; b=r/cjhzpJfX9PVH8URGev3s7fh31yyiw9YO+0qu9+IPXM4DDClx6ehAVZsiCWl6YG3L N8TRJHiFrIs8VXsCkeN/W0mLKpRXzdkLj1Tf1znsB1+SkbQSZpC7ZJg/VARjMTC0WIvA IpLxf3JqCqhzqHXcc2JbGeKgU+Fm0WYJQDk+SQ77BH5r4Zd8cz11pSEN9MMO1iUFsCrZ vfA/g1ZHcPkrv/l3GwYHx9HqzELjD0pKOT4q7I/812dBKv9DNGuifD1Hn8ZEpXg5QIIh MQ6P3v4UcqwPLLpyjmJAMUqN2jHqj83xa9zbhUgEbRSbmnQxO3NPN8TzUffHO9iQVOil w7Yg== 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=guB467KLQ29ig8OoD0Ihm2ufZPGhy5AYIxdlj73COvk=; b=SFcNidyN1RTF5J9+eEFPzU4XtfFCVsqc4OeZikPQ19aWPe02rUj5/z/DXa1RI8VvMJ OcDKV4dzMPZj68eyAu6zeG6CDL/KvzQF/NnVkkIyP99tPaNmzfThnlmYUo31e8UV5xqL d7xnaCaL3slsifgiYTEpU6/ojq3SRxZ29l2lIdDZcdbWOfzaCDJ9DZzITpODpjA79wJo wwHM7ltWo0Ngi2pr5i6JmGInuukgAewrXObDRB71071LXOsWsbqXOkxTArRnwpQdEBPB veTCXTN1Mvci6kSdpdvP7S/UeEEe+rqPPDFIgLqzoc2wXXvzlJCO5sHQM69qDVatYqFg 2DFg== X-Gm-Message-State: APjAAAXFWFzZOKvGaKn9T9fWQBofwwkxsxoyIIbA2zkX8488sRFT+/3W 29pgrumzftix0S+saO+2qudSQrWHGjcONlmouhP2Tg== X-Google-Smtp-Source: APXvYqxt/wTpLDCzClcZvsa9b41r1G5UbwBaCy3gAr/wllgkmzoj5mPlzDr3AmQLAbWfmmUwGirML7RY9Ihsv8UXqdc= X-Received: by 2002:a02:3ecb:: with SMTP id s194mr19811963jas.29.1556503204151; Sun, 28 Apr 2019 19:00:04 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: From: Justin Uberti Date: Sun, 28 Apr 2019 18:59:52 -0700 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="00000000000093c5f00587a1a4a0" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 02:00:07 -0000 --00000000000093c5f00587a1a4a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 27, 2019 at 10:42 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > > In a non-trickle case, I think it would be very strange if the agent > didn=E2=80=99t 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 i= t > 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. > > One option would then be to say that PAC only applies when an agent > actually has received some candidates from its peer. > > If an agent does NOT receive any candidates from the peer, it knows that > the only candidates it will get are peer reflexive ones, and how long th= e > agent waits for those is an implementation issue. > > Not sure that makes sense, that directly contradicts one of the examples in the actual PAC document. Overall I think the Firefox approach makes the most sense - the PAC timer starts when you have either a local or remote candidate. --00000000000093c5f00587a1a4a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 27, 2019 at 10:42 AM Chri= ster Holmberg <christe= r.holmberg@ericsson.com> wrote:


Hi,


In a non-trickle case, I think it would= be very strange if the agent didn=E2=80=99t get any candidates front the p= eer agent.


>I have just sent a message to the mmusic list regarding ice-sip-sd= p and offers with >no candidates. There is nothing that technically proh= ibits it in RFC 5245, so I >thought it makes sense to add a note which e= xplicitly 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 case= s, client does not need >to collect any candidates and simply send the o= ffer. 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 defa= ult >route. There are multiple benefits for implementing it this way, on= e of which >would be client privacy.

One option would then be to say that PAC only applies when an agent ac= tually has received some candidates from its peer.

If an agent does NOT receive any candidates from the peer, it knows that th= e only=C2=A0 candidates it will get are peer reflexive ones, and how long t= he agent waits for those is an implementation issue.

Not su= re that makes sense, that directly contradicts one of the examples in the a= ctual PAC document.=C2=A0

Overall I think the Fire= fox approach makes the most sense - the PAC timer starts when you have eith= er a local or remote candidate.=C2=A0
--00000000000093c5f00587a1a4a0-- From nobody Mon Apr 29 06:01:56 2019 Return-Path: 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 F05E5120314 for ; Mon, 29 Apr 2019 06:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=ericsson.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 NQ151PWlOfqF for ; Mon, 29 Apr 2019 06:01:51 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1422120319 for ; Mon, 29 Apr 2019 06:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lTp/wiO16eJ0O0VdVBd2cTpOBBIi7BT0LLIWcW8/fJk=; b=VDaERX+d0sCPpsk8fWfRXJeA4Z+neB3Qieli0WV31Pa//H4JCtBhg6FyjEJx4HzQapKq1+XPN6L0gwZh04BMpzpU9yN4PE8nLlOg30MDKSDrHN17K54dfXaodllpvrEM9NnVYsqfPoAvdUShpYByDMhwfQfq4Na1kvmaqTzCClM= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3258.eurprd07.prod.outlook.com (10.170.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.4; Mon, 29 Apr 2019 13:01:47 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Mon, 29 Apr 2019 13:01:47 +0000 From: Christer Holmberg To: Justin Uberti CC: Roman Shpount , Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gIAAVFgAgABZAV2AAAWpgIABXUofgAIe4wCAALbUAA== Date: Mon, 29 Apr 2019 13:01:47 +0000 Message-ID: References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df40af8a-b206-41dd-d786-08d6cca2d6a3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3258; x-ms-traffictypediagnostic: HE1PR07MB3258: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(136003)(396003)(199004)(189003)(44832011)(478600001)(68736007)(66066001)(5660300002)(102836004)(14454004)(81156014)(76176011)(71200400001)(71190400001)(6916009)(2906002)(7696005)(99286004)(81166006)(316002)(97736004)(25786009)(74316002)(6246003)(6606003)(33656002)(55016002)(8676002)(4326008)(52536014)(26005)(8936002)(186003)(7736002)(9686003)(93886005)(6436002)(486006)(53936002)(3846002)(86362001)(6116002)(446003)(54896002)(66556008)(229853002)(256004)(476003)(14444005)(66946007)(73956011)(5070765005)(11346002)(6506007)(19627405001)(66446008)(64756008)(76116006)(54906003)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3258; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ciodAdQx6THE2vHEvWOf7xGnyh1UvCjr7OVYh80odlRoih6/YRpHlx/rsiYyPZkL3+7nIrkc4ArORvKjf6KglUT8WEJAh4VkhzB64+LvZTSU65UqNl/FzN+H2xJ+3QY4d3ObfMCdYVKr3do+nNFUGvi4+j4E79bYsXhkwwW+JXF9BaIVSXVWIzsqEP0Y00PJC0MZv6y4oz/V/AVOHVDX5KIbVYS9szdifkpQzHNQcQmMiooeEz+xWrFNZm91sGEgnpHScZ9jgtMWUCjmMBH3cabdtZybWiSVSDiswARhAwFNcJs4s9nFb6Q5mGsJjpV9qj31dy1tqj4672daTVhHdlME7JcIHd/U2i7kioPO1YxdWk/gLPfMKcvIUTBKda8eyf7HC+6mVzgGxCkfsdc+7WAA2ZJZIj2zZx/Vcc96HYA= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB3161E4496E7BDC5FF419CCE793390HE1PR07MB3161eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: df40af8a-b206-41dd-d786-08d6cca2d6a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 13:01:47.5614 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3258 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 13:01:55 -0000 --_000_HE1PR07MB3161E4496E7BDC5FF419CCE793390HE1PR07MB3161eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In a non-trickle case, I think it would be very strange if the agent didn= =92t get any candidates front the peer agent. >I have just sent a message to the mmusic list regarding ice-sip-sdp and of= fers 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 allo= ws 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 d= oes 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 im= plementing it this way, one of which >would be client privacy. One option would then be to say that PAC only applies when an agent actuall= y has received some candidates from its peer. If an agent does NOT receive any candidates from the peer, it knows that th= e only candidates it will get are peer reflexive ones, and how long the ag= ent waits for those is an implementation issue. >Not sure that makes sense, that directly contradicts one of the examples >in the actual PAC document. > >Overall I think the Firefox approach makes the most sense - the PAC timer >starts when you have either a local or remote candidate. That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If th= at's what people want, fine. However, you can have a local candidate long before the remote peer gets it= , so starting the timer once you have a candidate sounds strange to me. I t= hink we should at least wait until the agent has sent the agent to the peer= . Regards, Christer --_000_HE1PR07MB3161E4496E7BDC5FF419CCE793390HE1PR07MB3161eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,


In a non-trickle case, I think it would= be very strange if the agent didn=92t get any candidates front the peer ag= ent.


>I have just sent a message to the mmusic list regarding ice-sip-sd= p and offers with >no candidates. There is nothing that technically proh= ibits it in RFC 5245, so I >thought it makes sense to add a note which e= xplicitly 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 case= s, client does not need >to collect any candidates and simply send the o= ffer. 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 defa= ult >route. There are multiple benefits for implementing it this way, on= e of which >would be client privacy.

One option would then be to say that PAC only applies when an agent ac= tually has received some candidates from its peer.

If an agent does NOT receive any candidates from the peer, it knows that th= e only  candidates it will get are peer reflexive ones, and how long t= he agent waits for those is an implementation issue.

>Not sure that makes sense, that directly contradicts one of the ex= amples 
>in the actual PAC document. 
>
>Overall I think the Firefox approach makes the most sense - the PA= C timer 
>starts when you have either a local or remote candidate. 

That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If th= at's what people want, fine.

However, you can have a local candidate long before the remote peer gets it= , so starting the timer once you have a candidate sounds strange to me. I t= hink we should at least wait until the agent has sent the agent to the peer= . 

Regards,

Christer





--_000_HE1PR07MB3161E4496E7BDC5FF419CCE793390HE1PR07MB3161eurp_-- From nobody Mon Apr 29 11:08:14 2019 Return-Path: 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 BA780120096 for ; Mon, 29 Apr 2019 11:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QiDT9iEfkS50 for ; Mon, 29 Apr 2019 11:08:09 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 E590D1205D3 for ; Mon, 29 Apr 2019 11:08:08 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id r71so9770376iod.11 for ; Mon, 29 Apr 2019 11:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AZFYQbyMFlqDtRGVkOg1sJN8+pkIspVd/N7+RYbIhWk=; b=elStJc5uW0b1G3egCisRhTQ0S2aPj9fyJNGgTadLE4RcdZG1BwvPOpg1CJGHwaQJPO i6y/UrHy7XdSb+5NyW+yPSH+mNjjZ8ZxogpsxJbowLIAzM1V0JJp2nK+gMsMHY6k2OoW 9ei42Vm0xmwT3hwkyL/aspzUQdCuz6DlqVI0RaB/TXsNS/K/nCVBOexvIvtaLdsFIbZP OufRvN9YpKpnaREU62isaFrPHqsELXCg9+m8hBRoQb/XIJT88ZnfWVO+6BpQmqXoavCB THWSZ4Lcaklf3TjCNXdsUAhthm43jf62S8sImaN60j6ORLDMBcixyx/BtcKXfEYgSb7G 3I5g== 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=AZFYQbyMFlqDtRGVkOg1sJN8+pkIspVd/N7+RYbIhWk=; b=Dtg3OHadkJKBufVUQUOxJHHckAMIvz4gkmu+v2pLWw3c07uvGGGrww+U4sNeLDOle3 XM6WC79m2AKU+HQP1a2pqhH3tzOgkURgunLN819o6Za+Dok4wF6EB7GObliFIvK5R2jZ ZtaEdPltNZGASIxGSzuzuqlRhcMv2bxzEYGQiF6bSqz1sR1jqBSrvteGhU7ojtVevdxl VnP6ooyg7j5fmFbn7MDXT4+waNnQQFzFf0IEHJloU371rVpimA7d2p1u1jrtdbROt+5w nKm8Uayujz5pre6DI2NYERYw8YTsIzGVX0HKR/G40NBQjEbltfHz1i5nCikd6EcUurbD Zpmg== X-Gm-Message-State: APjAAAV7SZVNOsZppQuVlbFlM5Gub/tAZIYOzQInPWi7nr1CX8r0+kg/ XLOIlnzWZezO0VO2w4FWSRUnt9FXn0vCuZuoB09wO9TigR8= X-Google-Smtp-Source: APXvYqwIqL5mUglgvCEsIKAlYOi14BVDDnD+4OQvSaf4bHy9zo+JdTGgvphp0+JOcDRJB8PjSyORpcAhJmXWC1q+pMY= X-Received: by 2002:a05:6602:55:: with SMTP id z21mr25709905ioz.101.1556561287694; Mon, 29 Apr 2019 11:08:07 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: From: Justin Uberti Date: Mon, 29 Apr 2019 11:07:56 -0700 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a023660587af2a4c" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 18:08:12 -0000 --000000000000a023660587af2a4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2019 at 6:01 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > In a non-trickle case, I think it would be very strange if the agent > didn=E2=80=99t 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 i= t > 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. > > One option would then be to say that PAC only applies when an agent > actually has received some candidates from its peer. > > If an agent does NOT receive any candidates from the peer, it knows that > the only candidates it will get are peer reflexive ones, and how long th= e > agent waits for those is an implementation issue. > > >Not sure that makes sense, that directly contradicts one of the examples > >in the actual PAC document. > > > >Overall I think the Firefox approach makes the most sense - the PAC time= r > >starts when you have either a local or remote candidate. > > That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If > that's what people want, fine. > Maybe this is what you meant, but I think it's a "minimum-time-to-run-ICE" timer. > > However, you can have a local candidate long before the remote peer gets > it, so starting the timer once you have a candidate sounds strange to me.= I > think we should at least wait until the agent has sent the agent to the > peer. > This is an important observation - we don't want to start the timer until we think both us and the peer agent are running ICE processing (e.g., if we just gathered candidates but didn't send an offer, we shouldn't start the timer). I'm not totally sure what you meant above, but one way to ensure we're in the right state would be to start the timer when both of the below are true: 1) We have sent or received an answer. 2) Local candidate gathering has completed (including the case when zero candidates have been gathered). #2 may not be strictly necessary, but gives us more flexibility in trickle cases if gathering takes a very long time (10+ seconds) for some reason. --000000000000a023660587af2a4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 29, 2019 at 6:01 AM Chris= ter Holmberg <christer= .holmberg@ericsson.com> wrote:

Hi,


In a non-trickle case, I think it would= be very strange if the agent didn=E2=80=99t get any candidates front the p= eer agent.


>I have just sent a message to the mmusic list regarding ice-sip-sd= p and offers with >no candidates. There is nothing that technically proh= ibits it in RFC 5245, so I >thought it makes sense to add a note which e= xplicitly 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 case= s, client does not need >to collect any candidates and simply send the o= ffer. 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 defa= ult >route. There are multiple benefits for implementing it this way, on= e of which >would be client privacy.

One option would then be to say that PAC only applies when an agent ac= tually has received some candidates from its peer.

If an agent does NOT receive any candidates from the peer, it knows that th= e only=C2=A0 candidates it will get are peer reflexive ones, and how long t= he agent waits for those is an implementation issue.

>Not sure that makes sense, that directly contradicts one of the ex= amples=C2=A0
>in the actual PAC document.=C2=A0
>
>Overall I think the Firefox approach makes the most sense - the PA= C timer=C2=A0
>starts when you have either a local or remote candidate.=C2=A0

That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If th= at's what people want, fine.
<= /div>

Maybe this is what you meant, but I t= hink it's a "minimum-time-to-run-ICE" timer.=C2=A0

However, you can have a local candidate long before the remote peer gets it= , so starting the timer once you have a candidate sounds strange to me. I t= hink we should at least wait until the agent has sent the agent to the peer= .=C2=A0
This is an important observation - we don't want to start = the timer until we think both us and the peer agent are running ICE process= ing (e.g., if we just gathered candidates but didn't send an offer, we = shouldn't start the timer). I'm not totally sure what you meant abo= ve, but one way to ensure we're in the right state would be to start th= e timer when both of the below are true:
1) We have sent or r= eceived an answer.
2) Local candidate gathering has completed (in= cluding the case when zero candidates have been gathered).

#2 may not be strictly necessary, but gives us more flexibility in= trickle cases if gathering takes a very long time (10+ seconds) for some r= eason.
--000000000000a023660587af2a4c-- From nobody Mon Apr 29 12:14:56 2019 Return-Path: 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 E3EB71206A6 for ; Mon, 29 Apr 2019 12:14:53 -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 m-RjTNsvYFLq for ; Mon, 29 Apr 2019 12:14:51 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 C13001206A5 for ; Mon, 29 Apr 2019 12:14:51 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id c13so4647798pgt.1 for ; Mon, 29 Apr 2019 12:14:51 -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=kTzn3osVzyGEBVAicjHSttWpakoGBc5x9BDD0KFS1Gc=; b=n8QVIyQLbNK5BZd0yn7xD4hPO0cejw6nPcCSFcsY7gGhZx3wheBy9y9FX3zaZQg2yc lbZSzNb5mWbgsWGP5j0hYDW+VUoKNNIKLKxp1bUQWcrm1NT4laHWTRU+Zgfkb/RRGBLR o5viHuOUrTTosD/L4r8rOX1bv/y/ntN23SYkhtvhxJxm1PfBcI+i9vNbWWW6Nw3q2pE4 fT5MDtVNlvTG1yd7u/8W1EUJgEvWokzXHVSCGo0Vmd2oDoQ332OuFafSurkMMYIcXq36 TfBYMpETHTRq9YVOzVMigZGyM+pCfc2mHK/2RmaQJAKbrs9ysHc+XU+3MTQ+H3Ypt6Rn Dljw== 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=kTzn3osVzyGEBVAicjHSttWpakoGBc5x9BDD0KFS1Gc=; b=myX/mDxK91pVMyMu12g7QU/tggcfq42JN5C8Yqt4R4BE+TX9EOmNfyXTdTNn/qaf1z jY3S+eOqSEwnfxS6gnHk5V36RmpEkqm4+VtIqQlQVv//0n2OpUQY21/SJQ2JgTJQ6Zh7 XLgZAO5mEl2J98M001mwVRkJrsoo2Tqxea7DOwvjqn7iDZbSG87khSVOTaZBihH/Gexb NTQnvWhGSnEMyEhHNFsBYfUypNHH5LBLSiQOtwn+2NTxLIVf19Vh4CyCBodHiIB4Wmyf UGIfrFnPWGfkcJDCnwStYDEbmMQ4KqFQxqgi+U7yVbxqxR2aQf2ePpqGfgFghA1fEeyU 2NjA== X-Gm-Message-State: APjAAAVboLJgAg+e5/8SwydgIBrFTrb3Ep0Mc0bg4AACKe8pPTQbqvOl KVhioC2Xkqmlj0b6eG+IB01ZffTzdLg= X-Google-Smtp-Source: APXvYqyh6Gaxj8Q1aD6nFowVzhkQPswXFDVL2pvM5ho/sSG71Svm3xlijtNKpCMsIxxZmXMNF13rcg== X-Received: by 2002:a63:e10b:: with SMTP id z11mr59958584pgh.46.1556565291251; Mon, 29 Apr 2019 12:14:51 -0700 (PDT) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id b19sm43263743pgb.51.2019.04.29.12.14.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 12:14:50 -0700 (PDT) Received: by mail-pf1-f172.google.com with SMTP id j11so5784242pff.13 for ; Mon, 29 Apr 2019 12:14:50 -0700 (PDT) X-Received: by 2002:a63:8dc8:: with SMTP id z191mr25274811pgd.9.1556565290076; Mon, 29 Apr 2019 12:14:50 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <2CF0DF15-BCDB-46DF-8824-9D1017190649@ericsson.com> In-Reply-To: <2CF0DF15-BCDB-46DF-8824-9D1017190649@ericsson.com> From: Roman Shpount Date: Mon, 29 Apr 2019 15:14:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002f50820587b0199f" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:14:54 -0000 --0000000000002f50820587b0199f Content-Type: text/plain; charset="UTF-8" On Sat, Apr 27, 2019 at 5:24 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >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. > > 'ice2' is defined by RFC 8445. It is not ice-sip-sdp specific. > > You are correct, ice2 is defined in RFC 8445. This being said, anything which implements ice-sip-sdp must include ice-options ice2, which means if ice2 option is negotiated via ice-sip-sdp, all ice-sip-sdp procedures must be used. If ice-sip-sdp will require PAC, then this would be pulled in as well. We can deliberately separate and add another ice extension for PAC or empty candidate lists, but this would be mostly redundant. In any case, anything which implements RFC 8445 would likely need to implement PAC, since PAC is a specification fix/clarification, not some additional functionality. Regards, _____________ Roman Shpount --0000000000002f50820587b0199f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Apr 27, 2019 at 5:24 AM C= hrister Holmberg <chri= ster.holmberg@ericsson.com> wrote:
>One = thing I was considering is that we should make ICE PAC mandatory for anythi= ng that includes ice-options: ice2.
>I think it is already implied with my latest pull request to ice-sip-sd= p.

'ice2' is defined by RFC 8445. It is not ice-sip-sdp specific.
<= br>

You are correct, ice2 is defined in RFC= 8445. This being said, anything which implements ice-sip-sdp must include = ice-options ice2, which means if ice2 option is negotiated via ice-sip-sdp,= all ice-sip-sdp procedures must be used. If ice-sip-sdp will require PAC, = then this would be pulled in as well. We can deliberately separate and add = another ice extension for PAC or empty candidate lists, but this would be= =C2=A0 mostly redundant.=C2=A0

In any case, anythi= ng which=C2=A0 implements RFC 8445 would likely need to implement PAC, sinc= e PAC is a specification fix/clarification, not some additional functionali= ty.

Regards,
_____________
Roman Shpount
=C2=A0
--0000000000002f50820587b0199f-- From nobody Mon Apr 29 12:32:15 2019 Return-Path: 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 90FE51206D9 for ; Mon, 29 Apr 2019 12:32:13 -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 ay9JY1ctCPah for ; Mon, 29 Apr 2019 12:32:11 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 C0C891206E2 for ; Mon, 29 Apr 2019 12:32:03 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id j11so5806042pff.13 for ; Mon, 29 Apr 2019 12:32:03 -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=MaqcKZKGALvvnCUmTT5WpzlJorM1GQE9T+eslc6NUW0=; b=jZWdFVpBgMNP+xlAQLBhHvezcRsxW0v1uqWrW6pmOlV/6cd+asqYRSzluIaS8dRalh PYeCfu1cLaN8WxHDVG36HKChr9cSikwJtBiYIr5+lvb6zQRJTs+wNcKfIBSXADXdxbrL SYP4A+sz4g2rXw9/ZAtqWv68Qvm9iLmh2FDEZVRF0gwhTKivhODfiqkMiDdnWJHkpKBy lKN8j2sVymyemz8XOM3y0haPQJeoeYvS2LZTX8ebe/buK6Y9sa2a780tZrUoxOXvSEZf 2M0RWip77W0M/2fjAmgTrwNDnFc2PdUR7mg/KfgOOlo2rYIrnssx/ginltezrogj4Vu3 z6yQ== 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=MaqcKZKGALvvnCUmTT5WpzlJorM1GQE9T+eslc6NUW0=; b=BZ1Jww/WLUbI7ec9kE/FM2IJczVl51ymoWPnuyY+WVjggqqrHHJ4g3/s4bArQYDyop JMpO1uc/FPTnTxGN33G9GR+xeZuBDnhWjfRnfpG1sJN7ZJiVRiXeYHvUgLxiJfYCmP7B aZRvK4qfFIgjIe2uZYtAhEAdlTcdxg4StCRYUxP+rOP/WjVd+DfT9uA2Tc7vr5BEtzC5 3XvpbqLjb/shLDfP4PX7gT1G0aKFKmnUdWPbwas3sFpePsZJMYjDm4A6/UsZUIx0guJY QfbC5+0yABhOXBxh+dbo3CX7WKG6YxIrSx6eGFXXpkeOb5mmOGFXOiomyb6OQXISxuQ1 tC5Q== X-Gm-Message-State: APjAAAVpCqhEqNXc1VwkRTwjmWBP+2Z7Hgq5GzMy/blF5nRDsyz0k3mm d1z9eyCbMBuQeAMIeVcuVkgpRuZPCbQ= X-Google-Smtp-Source: APXvYqxqcL4mJ7aYneGGrlpGsk81aa9kLxjVfJesrHIQ7zWxmDHHWe+DFmALZ4bRp5YK3Wby6UkEaA== X-Received: by 2002:a62:f24e:: with SMTP id y14mr65387208pfl.209.1556566323007; Mon, 29 Apr 2019 12:32:03 -0700 (PDT) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com. [209.85.215.181]) by smtp.gmail.com with ESMTPSA id e4sm22770340pfn.185.2019.04.29.12.32.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 12:32:01 -0700 (PDT) Received: by mail-pg1-f181.google.com with SMTP id k19so5652883pgh.0 for ; Mon, 29 Apr 2019 12:32:01 -0700 (PDT) X-Received: by 2002:a62:5a42:: with SMTP id o63mr67892441pfb.170.1556566321548; Mon, 29 Apr 2019 12:32:01 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: From: Roman Shpount Date: Mon, 29 Apr 2019 15:31:50 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Christer Holmberg , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="000000000000aa55a30587b0564b" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 19:32:14 -0000 --000000000000aa55a30587b0564b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, On Mon, Apr 29, 2019 at 2:08 PM Justin Uberti wrote: > On Mon, Apr 29, 2019 at 6:01 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> In a non-trickle case, I think it would be very strange if the agent >> didn=E2=80=99t 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 offe= r. >> 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. >> >> One option would then be to say that PAC only applies when an agent >> actually has received some candidates from its peer. >> >> If an agent does NOT receive any candidates from the peer, it knows that >> the only candidates it will get are peer reflexive ones, and how long t= he >> agent waits for those is an implementation issue. >> >> >Not sure that makes sense, that directly contradicts one of the example= s >> >in the actual PAC document. >> > >> >Overall I think the Firefox approach makes the most sense - the PAC >> timer >> >starts when you have either a local or remote candidate. >> >> That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If >> that's what people want, fine. >> > > Maybe this is what you meant, but I think it's a "minimum-time-to-run-ICE= " > timer. > >> >> However, you can have a local candidate long before the remote peer gets >> it, so starting the timer once you have a candidate sounds strange to me= . I >> think we should at least wait until the agent has sent the agent to the >> peer. >> > > This is an important observation - we don't want to start the timer until > we think both us and the peer agent are running ICE processing (e.g., if = we > just gathered candidates but didn't send an offer, we shouldn't start the > timer). I'm not totally sure what you meant above, but one way to ensure > we're in the right state would be to start the timer when both of the bel= ow > are true: > 1) We have sent or received an answer. > 2) Local candidate gathering has completed (including the case when zero > candidates have been gathered). > > #2 may not be strictly necessary, but gives us more flexibility in trickl= e > cases if gathering takes a very long time (10+ seconds) for some reason. > There are two approaches that we can take: First would be "practical" approach. If we assume that number of candidates is reasonable, local candidate collection takes less then 1-2 seconds, TURN candidates are returned in couple of seconds, and signaling delays are less then a second or two, then entire candidate collection and delivery to remote agent should take less then few seconds. In this case, if minimal ice time to run is set to reasonably large time (like STUN bind request timeout, which is 32 sec), then it would give both agents more then enough time to send a several connectivity checks on all potential ICE candidate pairs. In any case, if entire procedure would take much longer caller will hung up and walk away. Another approach would be "formally correct" approach, which would try to make sure that ICE nomination succeeds when a valid candidate pair exists. It will need to deal with large numbers of local candidates (50 candidates with only candidate 40-something having access to public internet), slow TURN candidate allocation which takes tens of seconds, and signaling delays that introduce tens of seconds delays on candidate delivery. If you need to deal with such setups, then ICE nomination should only fail after the last STUN binding request from remote agent have failed. In case of ice-sip-sdp, this will require an additional signaling message. In case of WebRTC this would mean ICE would never fail unless it was explicitly told to stop by an application. We can also try to address something in between and start ICE minimal time-out after last candidate was sent to the remote agent, but, in cases with reasonable assumptions this should not make any difference, and in extreme cases this would not be enough. My preference would be to go with reasonable assumptions and start the timer when the last local candidate (or indication that there are no local candidates) was sent to the remote party. Regards, _____________ Roman Shpount --000000000000aa55a30587b0564b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
On Mon, Apr = 29, 2019 at 2:08 PM Justin Uberti <juberti@google.com> wrote:
=
On Mon, Apr 29, 2019 at 6:01 AM Christer Holmberg <christer.ho= lmberg@ericsson.com> wrote:
In a non-= trickle case, I think it would be very strange if the agent didn=E2=80=99t = get any candidates front the peer agent.


>I have just sent a message to the mmusic list regarding ice-sip-sd= p and offers with >no candidates. There is nothing that technically proh= ibits it in RFC 5245, so I >thought it makes sense to add a note which e= xplicitly 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 case= s, client does not need >to collect any candidates and simply send the o= ffer. 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 defa= ult >route. There are multiple benefits for implementing it this way, on= e of which >would be client privacy.

One option would then be to say that PAC only applies when an agent ac= tually has received some candidates from its peer.

If an agent does NOT receive any candidates from the peer, it knows that th= e only=C2=A0 candidates it will get are peer reflexive ones, and how long t= he agent waits for those is an implementation issue.

>Not sure that makes sense, that directly contradicts one of the ex= amples=C2=A0
>in the actual PAC document.=C2=A0
>
>Overall I think the Firefox approach makes the most sense - the PA= C timer=C2=A0
>starts when you have either a local or remote candidate.=C2=A0

That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. If th= at's what people want, fine.
<= /div>

Maybe this is what you meant, but I t= hink it's a "minimum-time-to-run-ICE" timer.=C2=A0
<= div class=3D"gmail-m_-5598574002771693305gmail-m_7846983149712918481x_gmail= _quote">

However, you can have a local candidate long before the remote peer gets it= , so starting the timer once you have a candidate sounds strange to me. I t= hink we should at least wait until the agent has sent the agent to the peer= .=C2=A0
This is an important observation - we don't want to start = the timer until we think both us and the peer agent are running ICE process= ing (e.g., if we just gathered candidates but didn't send an offer, we = shouldn't start the timer). I'm not totally sure what you meant abo= ve, but one way to ensure we're in the right state would be to start th= e timer when both of the below are true:
1) We have sent or r= eceived an answer.
2) Local candidate gathering has completed (in= cluding the case when zero candidates have been gathered).

#2 may not be strictly necessary, but gives us more flexibility in= trickle cases if gathering takes a very long time (10+ seconds) for some r= eason.

There are two appr= oaches that we can take:

First would be "prac= tical" approach. If we assume that number of candidates is reasonable,= local candidate collection takes less then 1-2 seconds, TURN candidates ar= e returned in couple of seconds, and signaling delays are less then a secon= d or two, then entire candidate collection and delivery to remote agent sho= uld take less then few seconds. In this case, if minimal ice time to run is= set to reasonably large time (like STUN bind request timeout, which is 32 = sec), then it would give both agents more then enough time to send a severa= l connectivity checks on all potential ICE candidate pairs. In any case, if= entire procedure would take much longer caller will hung up and walk away.=

Another approach would be "formally correct&= quot; approach, which would try to make sure that ICE nomination succeeds w= hen a valid candidate pair exists. It will need to deal with large numbers = of local candidates (50 candidates with only candidate 40-something having = access to public internet), slow TURN candidate allocation which takes tens= of seconds, and signaling delays that introduce tens of seconds delays on = candidate delivery. If you need to deal with such setups, then ICE nominati= on should only fail after the last STUN binding request from remote agent h= ave failed. In case of ice-sip-sdp, this will require an additional signali= ng message. In case of WebRTC this would mean ICE would never fail unless i= t was explicitly told to stop by an application.

W= e can also try to address something in between and start ICE minimal time-o= ut after last candidate was sent to the remote agent, but, in cases with re= asonable assumptions this should not make any difference, and in extreme ca= ses this would not be enough.

My preference would = be to go with reasonable assumptions and start the timer when the last loca= l candidate (or indication that there are no local candidates) was sent to = the remote party.

Regards,
_____________
R= oman Shpount
=C2=A0
=
--000000000000aa55a30587b0564b-- From nobody Mon Apr 29 13:31:21 2019 Return-Path: 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 D5C31120151 for ; Mon, 29 Apr 2019 13:31:19 -0700 (PDT) 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 v4nNlIw5tWRZ for ; Mon, 29 Apr 2019 13:31:17 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 2D210120142 for ; Mon, 29 Apr 2019 13:31:17 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id l18so5709497pgj.6 for ; Mon, 29 Apr 2019 13:31:17 -0700 (PDT) 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=Hfp00IRroht5c/SUejFQZcUH/Y6PWnjsr7q06ZJMLEs=; b=MoffZEQ3cmZSxiV9kOqdFBvVjAzv2hS4T6VRcKm2OtJ2DDHXfQZXQ2MKlWom2VSKoE L/09ArbHy/o8IqCmJHcNg2yOX57jIj0BM3XQ492zc4kKkbd9OzbQviKmSyEXKbNF5KtJ HTd3DOnVgpbMe7XdU8sspSa9//cyfiw2tgXbk= 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=Hfp00IRroht5c/SUejFQZcUH/Y6PWnjsr7q06ZJMLEs=; b=gONyee54pTZSsRuH+sMTf8K4ZxE0bRdHJyupAww2N4ca7Ph9aUMeTGs8u2nHyzIMsD YWYysBYKE0EfNkGWOmiEX+Z5yjbT0qJzFE3ORNEI0YEjR5+NvYPxOYrFUHvcrxB/a3JV 7lMMQNC9j2yRUAXgRzwFO+XVdqoSXHHKesQJ+7THTCEQy9CrD1I9ngLTOX22qZN+25jm lsgIAlIksGbWjlfolFAw2s6L8Sc0Ck7WzMLe0TAfttmGRuehv197Yjsmmi8STKTFKFgf CxLCnkewUXhwFYexnO+WYZWDCKOFwlP1ndykjgGFixk5xNq2VlcjlbbuehFDSTgrrf+R kXng== X-Gm-Message-State: APjAAAUeSL3xeoOdFYHx/sDgR0oaOUEbOaxytLl3OicdC0sQ/yDf0mOT PNfdczh85otydA0u2BRkM9xNnA== X-Google-Smtp-Source: APXvYqwcwfnCOY7hZOyqSDLPvMmTJPkBsg40bzRI4YOFV+6ylhIYmapcBf376MVcpqZPtuE6tLc6IQ== X-Received: by 2002:aa7:9a9a:: with SMTP id w26mr28522814pfi.116.1556569875627; Mon, 29 Apr 2019 13:31:15 -0700 (PDT) Received: from [10.252.34.218] (guest-nat.fw1.untrust.mtv2.mozilla.net. [63.245.221.200]) by smtp.gmail.com with ESMTPSA id t24sm45701342pfe.110.2019.04.29.13.31.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2019 13:31:14 -0700 (PDT) From: Nils Ohlmeier Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_756A8B29-6855-44CF-9E00-E765D4B28F7D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 29 Apr 2019 13:31:12 -0700 In-Reply-To: Cc: Christer Holmberg , Roman Shpount , "ice@ietf.org" To: Justin Uberti References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 20:31:20 -0000 --Apple-Mail=_756A8B29-6855-44CF-9E00-E765D4B28F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 29, 2019, at 11:07, Justin Uberti wrote: >=20 > However, you can have a local candidate long before the remote peer = gets it, so starting the timer once you have a candidate sounds strange = to me. I think we should at least wait until the agent has sent the = agent to the peer.=20 >=20 > This is an important observation - we don't want to start the timer = until we think both us and the peer agent are running ICE processing = (e.g., if we just gathered candidates but didn't send an offer, we = shouldn't start the timer). I'm not totally sure what you meant above, = but one way to ensure we're in the right state would be to start the = timer when both of the below are true: > 1) We have sent or received an answer. > 2) Local candidate gathering has completed (including the case when = zero candidates have been gathered). >=20 > #2 may not be strictly necessary, but gives us more flexibility in = trickle cases if gathering takes a very long time (10+ seconds) for some = reason. Just as warning here: the worst case scenario is that a TURN and/or STUN = server was provided/configured which is not reachable. In that case = local gathering will only end after the STUN transactions to these = unreachable servers have timed out, which by default is 32 seconds. Doesn=E2=80=99t it make more sense to have #2 be something like: have = received at least one remote candidate, even it turns out to be in an = locally unsupported format, or an end-of-canditates with no candidates = provided at all. This would result though in situations where you never start the timer = if you receive an answer SDP, but never any ICE candidate or = end-of-candidates. Which to me looks some strange edge case where the = remote agent has crashed or otherwise failed to gather anything = including end-of-candidates. Best Nils Ohlmeier --Apple-Mail=_756A8B29-6855-44CF-9E00-E765D4B28F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Apr 29, 2019, at 11:07, Justin Uberti <juberti@google.com> = wrote:

However, you can = have a local candidate long before the remote peer gets it, so starting = the timer once you have a candidate sounds strange to me. I think we = should at least wait until the agent has sent the agent to the = peer. 

This is an important = observation - we don't want to start the timer until we think both us = and the peer agent are running ICE processing (e.g., if we just gathered = candidates but didn't send an offer, we shouldn't start the timer). I'm = not totally sure what you meant above, but one way to ensure we're in = the right state would be to start the timer when both of the below are = true:
1) We have sent or received an = answer.
2) Local candidate gathering has completed = (including the case when zero candidates have been gathered).

#2 may not be strictly = necessary, but gives us more flexibility in trickle cases if gathering = takes a very long time (10+ seconds) for some = reason.

Just as warning here: the worst case scenario is that a TURN = and/or STUN server was provided/configured which is not reachable. In = that case local gathering will only end after the STUN transactions to = these unreachable servers have timed out, which by default is 32 = seconds.

Doesn=E2=80=99t it make more sense to have #2 be something = like: have received at least one remote candidate, even it turns out to = be in an locally unsupported format, or an end-of-canditates with no = candidates provided at all.

This would result though in situations where you never start = the timer if you receive an answer SDP, but never any ICE candidate or = end-of-candidates. Which to me looks some strange edge case where the = remote agent has crashed or otherwise failed to gather anything = including end-of-candidates.

Best
  Nils = Ohlmeier

= --Apple-Mail=_756A8B29-6855-44CF-9E00-E765D4B28F7D-- From nobody Tue Apr 30 03:31:00 2019 Return-Path: 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 9A35E1202F3 for ; Tue, 30 Apr 2019 03:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=ericsson.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 cdDEZ-yIfyZn for ; Tue, 30 Apr 2019 03:30:54 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0608.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::608]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCA81202E1 for ; Tue, 30 Apr 2019 03:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QsTzT1vseD7p1n+TDibLEoFGVrJLPad0phM7lA3gmPY=; b=akCTIovrSil0ypzUnweMLWIFMBeFTgVAfpmtMlEG0cxpDiw4EpbybXZ0qjggJm5DxFfic5QxExOnFfeyL6NNdsVhpFRI0VVlBceYWrAJa87H8T0iNfPIPCrpgKmbX3OglMal9RnAZqLoAOrtIDSMjpctRl2Z/nhtXIAv9s367iY= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3337.eurprd07.prod.outlook.com (10.170.247.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.8; Tue, 30 Apr 2019 10:30:51 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::c999:f848:9abc:d321%6]) with mapi id 15.20.1856.008; Tue, 30 Apr 2019 10:30:51 +0000 From: Christer Holmberg To: Justin Uberti CC: Roman Shpount , Nils Ohlmeier , "ice@ietf.org" Thread-Topic: [Ice] ICE PAC: When to start the timer waiting for possible peer reflexive candidates? Thread-Index: AQHU+0CsHVyA1kKNxkeJ+j5BwMef3qZNJFeAgAA9yAD//8/IgIAAFleAgAAtFICAAMN1gIAAVFgAgABZAV2AAAWpgIABXUofgAIe4wCAALbUAIAAV6UAgAFE6oA= Date: Tue, 30 Apr 2019 10:30:51 +0000 Message-ID: <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fee162a0-704e-4726-c51d-08d6cd56eb5b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR07MB3337; x-ms-traffictypediagnostic: HE1PR07MB3337: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(76176011)(66446008)(64756008)(478600001)(66556008)(53936002)(54906003)(6512007)(14454004)(99286004)(33656002)(36756003)(66066001)(97736004)(93886005)(316002)(58126008)(66476007)(7736002)(6246003)(305945005)(82746002)(4326008)(14444005)(256004)(486006)(476003)(44832011)(71200400001)(71190400001)(25786009)(6916009)(8676002)(102836004)(2616005)(6116002)(26005)(6436002)(3846002)(6506007)(229853002)(446003)(11346002)(186003)(6486002)(2906002)(81156014)(81166006)(86362001)(68736007)(83716004)(8936002)(76116006)(66946007)(5660300002)(73956011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3337; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hH6DP6e6KCjZx/B+OA8eQScG3wR5CmT076mZfYFkhA5XGtsmylt1NITYvbZ4YFoxmY4LRngJcgI0igbldUo+Utdg4BkUBg/UtFaZOzeADmZCOgWvHoLEh+FRUiDotk1bO4/diLzAGUZhC0hhfPFBas52NNwETyitWHucuvO2PS7ruxz0+0mHepnByw+MF/TCiyNy25LA1Ti2jSQkJJg85BykwqcdrBwXAW+hJuV93eo2ds8T5VJisZ4Fs8PX+MWDf1q/hs0v1xqsay4SQK4myM5h/UMmovR9lH2KDJIBq3dtm/1aSvSOGNtVeCUGv6eBGqRdJsaf4J0YGqzMlUIpR9fxovmsAcqD3K2WrS95wxtnQcaA6Zeye+jdWlYTk3pYvEG0XbCuTWZi/dGWRXGLBq0FZC++UfH4LGA7J0ekHI8= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: fee162a0-704e-4726-c51d-08d6cd56eb5b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2019 10:30:51.7856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3337 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 10:30:58 -0000 SGksDQoNCi4uLg0KDQo+Pj4gT3ZlcmFsbCBJIHRoaW5rIHRoZSBGaXJlZm94IGFwcHJvYWNoIG1h a2VzIHRoZSBtb3N0IHNlbnNlIC0gdGhlIFBBQyB0aW1lcsKgDQo+Pj4gc3RhcnRzIHdoZW4geW91 IGhhdmUgZWl0aGVyIGEgbG9jYWwgb3IgcmVtb3RlIGNhbmRpZGF0ZS7CoA0KPj4NCj4+IFRoYXQg d291bGQgbWVhbiB0aGF0IFBBQyBiZWNvbWVzIGEgdGhlLW1heGltdW0tdGltZS10by1ydW4tSUNF IHRpbWVyLiBJZiB0aGF0J3Mgd2hhdCBwZW9wbGUgd2FudCwgZmluZS4NCj4NCj4gTWF5YmUgdGhp cyBpcyB3aGF0IHlvdSBtZWFudCwgYnV0IEkgdGhpbmsgaXQncyBhICJtaW5pbXVtLXRpbWUtdG8t cnVuLUlDRSIgdGltZXIuwqANCg0KSSBndWVzcyBzbywgeWVzLg0KDQpIb3dldmVyLCBhcyBJIHNh aWQgYmVmb3JlLCBJIHRoaW5rIGFuIGFnZW50IHNoYWxsIHN0aWxsIGJlIGFsbG93ZWQgdG8gc3Rv cCBlYXJsaWVyLCBhbmQgbm90IGJlIHJlcXVpcmVkIHRvIHdhaXQgZm9yIHBlZXIgcmVmbGV4aXZl IGNhbmRpZGF0ZXMsIGlmIGl0IGFscmVhZHkgaGFzIHdvcmtpbmcgcGFpcnMuDQoNCj4+IEhvd2V2 ZXIsIHlvdSBjYW4gaGF2ZSBhIGxvY2FsIGNhbmRpZGF0ZSBsb25nIGJlZm9yZSB0aGUgcmVtb3Rl IHBlZXIgZ2V0cyBpdCwgc28gc3RhcnRpbmcgdGhlIHRpbWVyIG9uY2UgeW91IA0KPj4gaGF2ZSBh IGNhbmRpZGF0ZSBzb3VuZHMgc3RyYW5nZSB0byBtZS4gSSB0aGluayB3ZSBzaG91bGQgYXQgbGVh c3Qgd2FpdCB1bnRpbCB0aGUgYWdlbnQgaGFzIHNlbnQgdGhlIGFnZW50IHRvIHRoZSBwZWVyLsKg DQo+DQo+IFRoaXMgaXMgYW4gaW1wb3J0YW50IG9ic2VydmF0aW9uIC0gd2UgZG9uJ3Qgd2FudCB0 byBzdGFydCB0aGUgdGltZXIgdW50aWwgd2UgdGhpbmsgYm90aCB1cyBhbmQgdGhlIHBlZXIgYWdl bnQgYXJlIHJ1bm5pbmcgDQo+IElDRSBwcm9jZXNzaW5nIChlLmcuLCBpZiB3ZSBqdXN0IGdhdGhl cmVkIGNhbmRpZGF0ZXMgYnV0IGRpZG4ndCBzZW5kIGFuIG9mZmVyLCB3ZSBzaG91bGRuJ3Qgc3Rh cnQgdGhlIHRpbWVyKS4gSSdtIG5vdCB0b3RhbGx5IHN1cmUgDQo+IHdoYXQgeW91IG1lYW50IGFi b3ZlLA0KDQpUaGF0IGlzIG9uZSBleGFtcGxlOiBnYXRoZXIgY2FuZGlkYXRlcyBidXQgZG9uJ3Qg eWV0IHNlbmQgYW4gb2ZmZXIuDQoNCj4gYnV0IG9uZSB3YXkgdG8gZW5zdXJlIHdlJ3JlIGluIHRo ZSByaWdodCBzdGF0ZSB3b3VsZCBiZSB0byBzdGFydCB0aGUgdGltZXIgd2hlbiBib3RoIG9mIHRo ZSBiZWxvdyBhcmUgdHJ1ZToNCj4gMSkgV2UgaGF2ZSBzZW50IG9yIHJlY2VpdmVkIGFuIGFuc3dl ci4NCj4gMikgTG9jYWwgY2FuZGlkYXRlIGdhdGhlcmluZyBoYXMgY29tcGxldGVkIChpbmNsdWRp bmcgdGhlIGNhc2Ugd2hlbiB6ZXJvIGNhbmRpZGF0ZXMgaGF2ZSBiZWVuIGdhdGhlcmVkKS4NCj4N Cj4gIzIgbWF5IG5vdCBiZSBzdHJpY3RseSBuZWNlc3NhcnksIGJ1dCBnaXZlcyB1cyBtb3JlIGZs ZXhpYmlsaXR5IGluIHRyaWNrbGUgY2FzZXMgaWYgZ2F0aGVyaW5nIHRha2VzIGEgdmVyeSBsb25n IHRpbWUgKDEwKyBzZWNvbmRzKSBmb3Igc29tZSByZWFzb24uDQoNCldoYXQgYWJvdXQgc3RhcnRp bmcgdGhlIHRpbWVyIGFmdGVyIHRoZSBhZ2VudCBoYXMgc2VudCBpdHMgbGFzdCBzZXQgb2YgY2Fu ZGlkYXRlcz8gVGhhdCB3b3VsZCBjb3ZlciBib3RoIHRyaWNrbGUgYW5kIG5vbi10cmlja2xlOiBp biBub24tdHJpY2tsZSB0aGVyZSBpcyBvbmx5IG9uZSBzZXQgb2YgY2FuZGlkYXRlcywgYW5kIGlu IHRyaWNrbGUgaXQgZG9lc24ndCBtYXR0ZXIgaG93IGxvbmcgaXQgdGFrZXMgdG8gcHJvdmlkZSBh bGwgY2FuZGlkYXRlcyBzaW5jZSB0aGUgdGltZXIgZG9lc27igJl0IHN0YXJ0IHVudGlsIHRoZSBs YXN0IHNldCBvZiBjYW5kaWRhdGVzIGhhdmUgYmVlbiBzZW50Pw0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCg0KDQo= From nobody Tue Apr 30 10:03:56 2019 Return-Path: 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 54C341202F5 for ; Tue, 30 Apr 2019 10:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 fzQsjQwywimx for ; Tue, 30 Apr 2019 10:03:47 -0700 (PDT) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 7CD5712012C for ; Tue, 30 Apr 2019 10:03:47 -0700 (PDT) Received: by mail-it1-x12d.google.com with SMTP id q14so5890867itk.0 for ; Tue, 30 Apr 2019 10:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=USN0azGcVH9N25n+Hpv8jwpGjiPV7HFvF3lIN5qGS4Y=; b=Y+0boqh5CaR4qujbk+O2PyXLr1IsB3neo6OsJNAoY2ONCKCSRCtiJ0HZtEaL30zmrB hDGMjtuldIHT07vGe+9bWeiFJ3VvPUIjfVjbPf72o3qTIVdd2arJsc44UmrMmqdz4V4N x8ftyprK3RJpUkuengx9XyaUqUZnEPXvBDrq53GM8ISU/Q0tdZithILEGV27I5KUSD5k uG5eSaMGQ4IknQ6n6gGER5sLHfGazlLgmmf+jUCoY2ZCKMi9P5lcyEU1sUUigx5Oc0Mv 3Ehxd5WLVLZwH0gpsYTvO/nPBz+etJ6tSQIh+4ECeSdzB3GVVF7FX1PWIH7siccleSCG xm5w== 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=USN0azGcVH9N25n+Hpv8jwpGjiPV7HFvF3lIN5qGS4Y=; b=QjlVMNrM/7ICxR03ZQKv21jGolQ6Qh90Gx8sIlNnxn+2HPVLgA1P5HV1NrKzI2Dm4S 9VYcR4W8pvf1yJ9pmKNzaYi5qTil9mZbhyR+3g15CfUI+qC6RYyrikvwzhKncqlS6/0W /ho3/SqZy1UwikRibVk3wmPx2CqRIHbjLFsUdrf6z0Lqk3QpR2SksBKlWPrv14ouQZSc GtBO0pd5C0EEUsvjzy8XBW/RC5Vv/8ZOHpWZaZXTye1uuD3BqpJa/9wB0JnOCItRnnzV 9F1FAOK/ch/cwZIsZRrUPUQKqzR5GupYRCenibBTrepax6og6R8rTMBLJ4+Gu/7VbITV I4jg== X-Gm-Message-State: APjAAAXA5jEA5dcDs8ZAIx4eCMb5InKb+0YaXL2xj3R0FkFv5pkHS9Ki Lt3PZxHaC7o7ucpr8iA1pMceshmwnMpsPis7qz4WEA== X-Google-Smtp-Source: APXvYqwfD4GPz90qfKOBD3lQssqbOxUm5fJ3FLNHHk3w5hnwgKApc7Fse/bwfqKSTLIWbInqiruIOnNLRcjEp5yHZXA= X-Received: by 2002:a05:660c:508:: with SMTP id d8mr4515209itk.8.1556643826291; Tue, 30 Apr 2019 10:03:46 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> In-Reply-To: <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> From: Justin Uberti Date: Tue, 30 Apr 2019 10:03:32 -0700 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004f62470587c26210" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:03:50 -0000 --0000000000004f62470587c26210 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2019 at 3:30 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > ... > > >>> Overall I think the Firefox approach makes the most sense - the PAC > timer > >>> starts when you have either a local or remote candidate. > >> > >> That would mean that PAC becomes a the-maximum-time-to-run-ICE timer. > If that's what people want, fine. > > > > Maybe this is what you meant, but I think it's a > "minimum-time-to-run-ICE" timer. > > I guess so, yes. > > However, as I said before, I think an agent shall still be allowed to sto= p > earlier, and not be required to wait for peer reflexive candidates, if it > already has working pairs. > Sure, this is not a point of contention, but a SHOULD-level directive may make sense here. > > >> However, you can have a local candidate long before the remote peer > gets it, so starting the timer once you > >> have a candidate sounds strange to me. I think we should at least wait > until the agent has sent the agent to the peer. > > > > This is an important observation - we don't want to start the timer > until we think both us and the peer agent are running > > ICE processing (e.g., if we just gathered candidates but didn't send an > offer, we shouldn't start the timer). I'm not totally sure > > what you meant above, > > That is one example: gather candidates but don't yet send an offer. > > > but one way to ensure we're in the right state would be to start the > timer when both of the below are true: > > 1) We have sent or received an answer. > > 2) Local candidate gathering has completed (including the case when zer= o > candidates have been gathered). > > > > #2 may not be strictly necessary, but gives us more flexibility in > trickle cases if gathering takes a very long time (10+ seconds) for some > reason. > > What about starting the timer after the agent has sent its last set of > candidates? That would cover both trickle and non-trickle: in non-trickle > there is only one set of candidates, and in trickle it doesn't matter how > long it takes to provide all candidates since the timer doesn=E2=80=99t s= tart until > the last set of candidates have been sent? > > That's basically the same thing I was proposing in 2), with the clarification that the candidates were also actually transmitted. I do think Nils' point is important though, i.e., if we have a bad server it will take a very long time to decide on 'last set of candidates', which is probably not helpful. As such I think the potential positions we can take are: a) Start the timer as soon as we have an answer, regardless of any candidates. b) a) + receipt of at least one remote candidate (or remote EOC). (This is Nils' suggestion). c) a) + sending at least one local candidate (or local EOC). b) has a problem if the remote side doesn't send any candidates, which we want to explicitly allow. I tend to lean towards a) as the simplest option. --0000000000004f62470587c26210 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 30, 2019 at 3:30 AM Chris= ter Holmberg <christer= .holmberg@ericsson.com> wrote:
Hi,

...

>>> Overall I think the Firefox approach makes the most sense - th= e PAC timer=C2=A0
>>> starts when you have either a local or remote candidate.=C2=A0=
>>
>> That would mean that PAC becomes a the-maximum-time-to-run-ICE tim= er. If that's what people want, fine.
>
> Maybe this is what you meant, but I think it's a "minimum-tim= e-to-run-ICE" timer.=C2=A0

I guess so, yes.

However, as I said before, I think an agent shall still be allowed to stop = earlier, and not be required to wait for peer reflexive candidates, if it a= lready has working pairs.

Sure, this is= not a point of contention, but a SHOULD-level directive may make sense her= e.

>> However, you can have a local candidate long before the remote pee= r gets it, so starting the timer once you
>> have a candidate sounds strange to me. I think we should at least = wait until the agent has sent the agent to the peer.=C2=A0
>
> This is an important observation - we don't want to start the time= r until we think both us and the peer agent are running
> ICE processing (e.g., if we just gathered candidates but didn't se= nd an offer, we shouldn't start the timer). I'm not totally sure > what you meant above,

That is one example: gather candidates but don't yet send an offer.

> but one way to ensure we're in the right state would be to start t= he timer when both of the below are true:
> 1) We have sent or received an answer.
> 2) Local candidate gathering has completed (including the case when ze= ro candidates have been gathered).
>
> #2 may not be strictly necessary, but gives us more flexibility in tri= ckle cases if gathering takes a very long time (10+ seconds) for some reaso= n.

What about starting the timer after the agent has sent its last set of cand= idates? That would cover both trickle and non-trickle: in non-trickle there= is only one set of candidates, and in trickle it doesn't matter how lo= ng it takes to provide all candidates since the timer doesn=E2=80=99t start= until the last set of candidates have been sent?

=
That's basically the same thing I was proposing in 2), w= ith the clarification that the candidates were also actually transmitted. I= do think Nils' point is important though, i.e., if we have a bad serve= r it will take a very long time to decide on 'last set of candidates= 9;, which is probably not helpful. As such I think the potential positions = we can take are:
a) Start the timer as soon as we have an answer,= regardless of any candidates.
b) a)=C2=A0+ receipt of at least o= ne remote candidate (or remote EOC). (This is Nils' suggestion).
<= div>c) a)=C2=A0+ sending at least one local candidate (or local EOC).
=

b) has a problem if the remote side doesn't send an= y candidates, which we want to explicitly allow.=C2=A0

=
I tend to lean towards a) as the simplest option.
--0000000000004f62470587c26210-- From nobody Tue Apr 30 10:51:11 2019 Return-Path: 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 6014D120321 for ; Tue, 30 Apr 2019 10:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 a4CuiXGcLEYe for ; Tue, 30 Apr 2019 10:51:08 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 CD87E12031E for ; Tue, 30 Apr 2019 10:51:06 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id y3so6237966plp.0 for ; Tue, 30 Apr 2019 10:51:06 -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=yUN0Y8PDVWb+l5XBJjlriKXfeCv54iDMSX8fVEATulc=; b=hHkfo1Ly7zLp2OdBpH5ZfsJ1VDeowO4G1PyeJYlBwwtqwdHicY36rINwKp+pEhm9mr uVAEVOC5Jwvl1X2j7jW3diS7aekjCaMQvFoFZqUtMEDLVtBg9dQ3ITM/3Mz9ee23zA1X vyil2lsZHCDJkL54nqq6a5FtiXB0E/KAPD2hg10BRIgnPpf8xL5sW4mnYl+/Nb40M1nH 9SdDt/SJuY0ltw++3EF/TORslcorhFUjolAP7XcFWNXr1K9DLvb5L4Mlm5jK8pT2FkNz wps0+vWtrK1jJjllhWbPHvpSDlgQj6Q1sZ2On7Vj67G9KXNbh3KAI7wCuVkCR9uPkWFl EhYQ== 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=yUN0Y8PDVWb+l5XBJjlriKXfeCv54iDMSX8fVEATulc=; b=SETRTcclZi6w8whA3L26qRn/Ik9cHI/WwAyV8oJ6S45WOypdr2WEjfgpD/pikmfIEb 0+HROIy10Xa0+F88mJYn1g4VYiitKpOlWlZcbdrq2+drgRbHX5Sxr7QJQl3VGBaVHAj6 VWg61vWUWsIpf3MzbDy901M2MK9l3kB+0XJjXMWUQwvFYWsoFxK0nWSXYqwP11vvYVRO wYuSEZWBR4Mh+Iqe5KTaNk7XjYhvmkXuBENzvYTHSP/etTFMECslspZ3DBNjYo6IvCqi IC5u8lxDcqkNQ6xQS7znVVzP67sGoW/TBbj81aoExk3hijP9htltsFJWautIV/vNitXf pGAg== X-Gm-Message-State: APjAAAW1utK5NhCH+yBIiEZ1kDbdmjLsP8NVz+PhMsDBta1uyANsTiUR G3TRXhxAzahzuSynqIqSB4Ng52zEG08= X-Google-Smtp-Source: APXvYqwvC1h4PglZqv3knEsutkhmpOWWdeN8pAwTCC+GGbJA5wlNDjb/bHsML/aDipZlIVZ6Q5ZT9Q== X-Received: by 2002:a17:902:7789:: with SMTP id o9mr4744308pll.300.1556646666085; Tue, 30 Apr 2019 10:51:06 -0700 (PDT) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com. [209.85.210.172]) by smtp.gmail.com with ESMTPSA id z7sm68623009pgh.81.2019.04.30.10.51.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 10:51:05 -0700 (PDT) Received: by mail-pf1-f172.google.com with SMTP id j11so7411524pff.13 for ; Tue, 30 Apr 2019 10:51:04 -0700 (PDT) X-Received: by 2002:a62:5a42:: with SMTP id o63mr75344971pfb.170.1556646664474; Tue, 30 Apr 2019 10:51:04 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> In-Reply-To: From: Roman Shpount Date: Tue, 30 Apr 2019 13:50:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Christer Holmberg , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007a17d20587c30bf0" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 17:51:10 -0000 --0000000000007a17d20587c30bf0 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 30, 2019 at 1:03 PM Justin Uberti wrote: > That's basically the same thing I was proposing in 2), with the > clarification that the candidates were also actually transmitted. I do > think Nils' point is important though, i.e., if we have a bad server it > will take a very long time to decide on 'last set of candidates', which is > probably not helpful. As such I think the potential positions we can take > are: > a) Start the timer as soon as we have an answer, regardless of any > candidates. > b) a) + receipt of at least one remote candidate (or remote EOC). (This is > Nils' suggestion). > c) a) + sending at least one local candidate (or local EOC). > > b) has a problem if the remote side doesn't send any candidates, which we > want to explicitly allow. > > I tend to lean towards a) as the simplest option. > What about the answering agent? Does the timer starts as soon as it sends the answer? _____________ Roman Shpount --0000000000007a17d20587c30bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 30, 2019 at 1:03 PM J= ustin Uberti <juberti@google.com> wrote:

_____________
= Roman Shpount
=C2=A0
--0000000000007a17d20587c30bf0-- From nobody Tue Apr 30 11:57:12 2019 Return-Path: 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 0E94D12032A for ; Tue, 30 Apr 2019 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 C-h0rtEmLnX2 for ; Tue, 30 Apr 2019 11:57:04 -0700 (PDT) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 AB133120043 for ; Tue, 30 Apr 2019 11:57:04 -0700 (PDT) Received: by mail-it1-x130.google.com with SMTP id a190so6462207ite.4 for ; Tue, 30 Apr 2019 11:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+NvOQoqYrvsG+bPPrLMLkBG8iizHkoLQcTqXl53WdI=; b=jkESOcMMOsYJHeRQAtuMmGinhj7xaD/sLgIDiyuhAJTEt8THKcK5Duj/lmAe5VPxXz cDmtCVOLNL6P/D5+q6LnKxUheVpGgVqmBPTQvFWeeoWiByjzTPh0LGfVq/SU5N07sGvW +2obj547ndBVaO1Vuess9py/RdU71/RDMXE3d12bc35pWKtwuLKqr4E10sRUCIs/yDwM gsCOuWxR+u3Tj2lBEdhl3MBiqiUkmU7NFdPd4iwO8e9QxGZkpw3rE33Vd6cibZ4+mSs2 sPiFq1zYnAhMjr6j8vUqboicpAl0L3Ig3FJQrm6rLpyzIAh360USXtIoXXBMLdU/Y4cV cZrw== 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=X+NvOQoqYrvsG+bPPrLMLkBG8iizHkoLQcTqXl53WdI=; b=s3k7e136Qf2cq95ILEOsKTnDW3L624M5087y5fMjQk3MJu0DeUpTyEqE+Cx1TLzrBf 3g8Z1L7VPtq/u1wd9dIMxc62MdqoLop1kCjFXcPfKc77iLbDrzFf8uzvjxxjBpcuMvW0 TbQLV9mG8AVdSxJUza3bTKXJLbN5NxToMj3s+rZzXO/RESGwURRqDb25E1omGxysY4eX 1fSdmIfvu/LgAyOrY/gOQwBGCFLow69wruJBDlNlE8GvYqwc9QrZeYW6oUM/23w0XxF9 CHphjnp5yQV562lHtl/M4DZy/ZMm6GxuQRG96BrAIXim2D5X+U8100xqYMbwAQ8JKz6x kQWQ== X-Gm-Message-State: APjAAAXlA2bVicrox+d3aF76JD/OLB8r6UaZfPYRHpLstMvu2W2BvnUl 9qIyWFBq7rNFlWE8RYY4GL1q1GGWNGDxlHddLcnE7w== X-Google-Smtp-Source: APXvYqxbxPfQtYRBz+bpNqegA97GokR5rF368VLwUzCxi5y7j9srcT7O/OfHkqBy/LmhgM3zQO3nSuqxkSJpHLGTu14= X-Received: by 2002:a24:478a:: with SMTP id t132mr4847504itb.123.1556650623429; Tue, 30 Apr 2019 11:57:03 -0700 (PDT) MIME-Version: 1.0 References: <3A66B735-03C9-41FF-95AD-500B0D469C80@ericsson.com> <30518269-CA9D-4F50-8CE3-062A01DBCD7F@mozilla.com> <0AD3077C-74FA-4585-942A-375B83B3A7A0@ericsson.com> <46390078-DE3B-456B-87AC-61AE3C3DF035@ericsson.com> In-Reply-To: From: Justin Uberti Date: Tue, 30 Apr 2019 11:56:51 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , Nils Ohlmeier , "ice@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007384b50587c3f750" Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 18:57:07 -0000 --0000000000007384b50587c3f750 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 30, 2019 at 10:51 AM Roman Shpount wrote: > On Tue, Apr 30, 2019 at 1:03 PM Justin Uberti wrote: > >> That's basically the same thing I was proposing in 2), with the >> clarification that the candidates were also actually transmitted. I do >> think Nils' point is important though, i.e., if we have a bad server it >> will take a very long time to decide on 'last set of candidates', which is >> probably not helpful. As such I think the potential positions we can take >> are: >> a) Start the timer as soon as we have an answer, regardless of any >> candidates. >> b) a) + receipt of at least one remote candidate (or remote EOC). (This >> is Nils' suggestion). >> c) a) + sending at least one local candidate (or local EOC). >> >> b) has a problem if the remote side doesn't send any candidates, which we >> want to explicitly allow. >> >> I tend to lean towards a) as the simplest option. >> > > What about the answering agent? Does the timer starts as soon as it sends > the answer? > I think so; this would be a). The other possibility to consider is c), since it is probably the case that only clients who send candidates will discover prflx candidates from the remote side. --0000000000007384b50587c3f750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 30, 2019 at 10:51 AM Roma= n Shpount <roman@telurix.com>= ; wrote:
On Tue, Apr 30, 2019 at 1:03 PM Justin Uberti &= lt;juberti@google.c= om> wrote:
= That's basically the same thing I was proposing in 2), with the clarifi= cation that the candidates were also actually transmitted. I do think Nils&= #39; point is important though, i.e., if we have a bad server it will take = a very long time to decide on 'last set of candidates', which is pr= obably not helpful. As such I think the potential positions we can take are= :
a) Start the timer as soon as we= have an answer, regardless of any candidates.
b) a)=C2=A0+ recei= pt of at least one remote candidate (or remote EOC). (This is Nils' sug= gestion).
c) a)=C2=A0+ sending at least one local candidate (or l= ocal EOC).

b) has a problem if the remote side doe= sn't send any candidates, which we want to explicitly allow.=C2=A0

I tend to lean towards a) as the simplest option.

What about the answering agen= t? Does the timer starts as soon as it sends the answer?
<= /blockquote>

I think so; this would be a). The other pos= sibility to consider is c), since it is probably the case that only clients= who send candidates will discover prflx candidates from the remote side.
--0000000000007384b50587c3f750--