From nobody Fri Mar 4 17:06:33 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BAA1ACEFE for ; Fri, 4 Mar 2016 17:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 Zu7RHi9x8iIb for ; Fri, 4 Mar 2016 17:06:30 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 3AD7F1A0372 for ; Fri, 4 Mar 2016 17:06:30 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id d205so49183832oia.0 for ; Fri, 04 Mar 2016 17:06:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z7C4IMn9BNuncEcOntZFZpvJrQc5wrqRaO/teaofDCo=; b=Q85mWu/mshzlABoWMCfKB3zSG6Bpw1UDYqIb4pwBRKopsTUSq/bCq8syIdR5+ZsIWf inAqZak2t1PTW47JdIQTbrQCCD+xqyAZduNqWZ/xca0LTeshTUA9NkfJOW5VoQVmPTRz IMfv5FUiPUDLYBwgseCkLEgpCnEP2y2c2c6IkadqdGlT9YNg859jWnmuS7oI3jY+1+xj N2Zbia0o2PkQ+chMvT13PQh7TNDvCfNfWBCTJDJcJTKuVvCIHKzhDKZgdZR7IPeA/8fL Cul4qr2MoO6gGc+N4ZlYNAuIN61f/sxe1uCWrb7XeXoPMFACbNOTlWcxyEPA4YZClpZn y5bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z7C4IMn9BNuncEcOntZFZpvJrQc5wrqRaO/teaofDCo=; b=HCNOqDYSLr9ABPUYdImbVf1r+Ti0DjnahUS9255JaVgASuK0b5oBnW1x8bIwbYuok1 xko6rPRpeP3Z54G1+Az6Lr/uLCBei5o2z7pOtzEBCRzvirTpZZHVxHbVXA1Em+V8dpUU 9/qA4Y2/nk9++ckvMW63fuV+/C5HpuoyC1P6uJAB4zESlXU6nX99Kvreaf47/GWx4n3F pdDWAf80uL+etCg9BTR4MCnLntXTyZFUJ3JBxw9CTuYw5SJnZ80FtddCahKweIXGaIed 9EquPNyFjSwBeDIzAB/FOkGRciTh/WfgvrYga2L2vQuW2QwOIjJfJ1dF5dKLLEfZ1O9x K8xQ== X-Gm-Message-State: AD7BkJL0jsi6zGlvyCxDTUBxQJsCI6mCHEG+CeXQAT2Eerh4OcssU+V3qSoIR2ptATeSwwBSgmJRthX6ePou5LJ7 X-Received: by 10.202.170.70 with SMTP id t67mr6729933oie.60.1457139989592; Fri, 04 Mar 2016 17:06:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.104.99 with HTTP; Fri, 4 Mar 2016 17:05:50 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E4B2D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E2E3C8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E4B2D0@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Fri, 4 Mar 2016 17:05:50 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113c48b0780ae7052d42d73c Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] ICE-bis: Status of connectivity check pacing X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 01:06:31 -0000 --001a113c48b0780ae7052d42d73c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm afraid that we don't have any more measurements ready yet, and most likely won't for Buenos Aires. On Mon, Feb 29, 2016 at 12:07 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > PING. > > > > *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Christer Holmber= g > *Sent:* 22. helmikuuta 2016 11:18 > *To:* ice@ietf.org > *Subject:* [Ice] ICE-bis: Status of connectivity check pacing > > > > Hi, > > > > I know the =E2=80=9Cdeadline=E2=80=9D is the summer IETF, but I wonder wh= ether someone is > actually planning to bring some network measurement results in order to > close the connectivity check pacing issue? > > > > If not, we should focus on defining the min value in another way. No need > to wait until summer for that, if nobody is going to provide measurements > results to begin with. > > > > Regards, > > > > Christer > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a113c48b0780ae7052d42d73c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm afraid that we don't have any more measurem= ents ready yet, and most likely won't for Buenos Aires.

On Mon, Feb 29, 2016 = at 12:07 AM, Christer Holmberg <christer.holmberg@ericsson.co= m> wrote:

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


--001a113c48b0780ae7052d42d73c-- From nobody Fri Mar 4 21:49:41 2016 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44191B3367 for ; Fri, 4 Mar 2016 21:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 kDARgzq3JsWh for ; Fri, 4 Mar 2016 21:49:38 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D781B3366 for ; Fri, 4 Mar 2016 21:49:37 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-3d-56da736edd72 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9D.6A.25494.E637AD65; Sat, 5 Mar 2016 06:49:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Sat, 5 Mar 2016 06:49:34 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [Ice] ICE-bis: Status of connectivity check pacing Thread-Index: AdFtUbSxKL0POW4kTIKhiJKufwAd9AFdnsWwAOqlsgAADAE2Ag== Date: Sat, 5 Mar 2016 05:49:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E69F01@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E2E3C8@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37E4B2D0@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E69F01ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7gW5+8a0wg9X/2S2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKWL/1IWvBNaOKHT9vsjUwftfpYuTkkBAwkfgz 7xQThC0mceHeerYuRi4OIYHDjBJtX5eyQziLGSVOHP0H5HBwsAlYSHT/0wZpEBHQlJg8uZkV JMwsoCjxcq8aSFhYwF5iz7TZrBAlDhLX+6ZB2U4Sx69vZQSxWQRUJBbe/s0GYvMK+Eo879nG CrHqGqPEn64tYEWcAoESTyetAbMZgY77fmoN2KHMAuISTV9WskIcLSCxZM95ZghbVOLl43+s EDX5Ei0TmlghFghKnJz5hGUCo8gsJO2zkJTNQlIGETeQ+PL+NpStLbFs4WtmCFtfovv9aSZk 8QWM7KsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAmPq4JbfujsYV792PMQowMGoxMNbIHwr TIg1say4MvcQowQHs5II79pooBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFetk+Xw4QE0hNLUrNT UwtSi2CyTBycUg2M9R+j5USNf862Xr956f3Jji22q68/8pi0XvmTzkum2IMKk20+zZON+P7L bcbai9Lr/ludNg4o5r190k/wf1XWfd0uzUX/Eq/VfUyTnKkR6JK8cMW3WTU9p9e8Ubj7IpX3 94xLl4K6/q2o7zXZnHIj+d8un7LqW70haX2vZ9W+mNsWeqGFYbtDvxJLcUaioRZzUXEiAItO 3hmlAgAA Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] ICE-bis: Status of connectivity check pacing X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 05:49:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E69F01ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Thanks for the information, Peter! So, can we choose a value? Regards, Christer Sent from my Windows Phone ________________________________ From: Peter Thatcher Sent: =FD05/=FD03/=FD2016 03:06 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] ICE-bis: Status of connectivity check pacing I'm afraid that we don't have any more measurements ready yet, and most lik= ely won't for Buenos Aires. On Mon, Feb 29, 2016 at 12:07 AM, Christer Holmberg > wrote: PING. From: Ice [mailto:ice-bounces@ietf.org] On Beh= alf Of Christer Holmberg Sent: 22. helmikuuta 2016 11:18 To: ice@ietf.org Subject: [Ice] ICE-bis: Status of connectivity check pacing Hi, I know the =93deadline=94 is the summer IETF, but I wonder whether someone = is actually planning to bring some network measurement results in order to = close the connectivity check pacing issue? If not, we should focus on defining the min value in another way. No need t= o wait until summer for that, if nobody is going to provide measurements re= sults to begin with. Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_7594FB04B1934943A5C02806D1A2204B37E69F01ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks for th= e information, Peter!

So, can we choose a value?

Regards,

Christer



Sent from my Windows Phone
From: Peter Thatcher
Sent: =FD05= /=FD03/=FD2016 03:06
To: Christer Holmberg Cc: ice@ietf.org
Subject: Re: [= Ice] ICE-bis: Status of connectivity check pacing

I'm afraid that we don't have any more measurements ready yet, and most = likely won't for Buenos Aires.

On Mon, Feb 29, 2016 at 12:07 AM, Christer Holmb= erg <chr= ister.holmberg@ericsson.com> wrote:

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


--_000_7594FB04B1934943A5C02806D1A2204B37E69F01ESESSMB209erics_-- From nobody Tue Mar 8 00:11:38 2016 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 B14E912D528 for ; Tue, 8 Mar 2016 00:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPX1mRr7bhAs for ; Tue, 8 Mar 2016 00:11:33 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A765912D52F for ; Tue, 8 Mar 2016 00:11:32 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-35-56de8932b1b2 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.C1.15637.2398ED65; Tue, 8 Mar 2016 09:11:31 +0100 (CET) Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.248.2; Tue, 8 Mar 2016 09:11:30 +0100 From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= To: "ice@ietf.org" Message-ID: <56DE8932.20304@ericsson.com> Date: Tue, 8 Mar 2016 10:11:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2J7oK5x570wgzkP2Cy+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKODf/IFPBcraKWV8mszYw/mPpYuTgkBAwkTg6 R6CLkRPIFJO4cG89WxcjF4eQwGFGiYcbGtghnLWMEjfmbmcGqWITsJX43b6HCcQWFtCTeNf3 kxXEZhbQlLh/ciE7iC0ioCgxs+UZWD0vUHzXuw0sIDaLgIpE8+F1YPWiAmkSs/omsEDUCEqc nPmEBWKOhcTM+ecZIWx5ie1v54DNERJQlbj67xXjBEb+WUhaZiFpmYWkZQEj8ypG0eLU4qTc dCNjvdSizOTi4vw8vbzUkk2MwNA7uOW36g7Gy28cDzEKcDAq8fB+YL8XJsSaWFZcmXuIUYKD WUmEl78FKMSbklhZlVqUH19UmpNafIhRmoNFSZyX9dPlMCGB9MSS1OzU1ILUIpgsEwenVANj zLMj5w/xsx57mJBlLvNA9UhZVrTHfHP/l7b/OXo0v38+YlR2ZumpnNePt8z4cmr5mcULth04 FTZhYbXBKW5uF4nbcn1ss2NM076rFe6dKuH+OVR8WfeTyjcmR9yVbrNL+DPOTP5vsCDxhfmV ZRzc3h5rfHatn61+eqPNe1OBQ2zh7OmvZy50VWIpzkg01GIuKk4EAKp8ABo5AgAA Archived-At: Cc: Peter Thatcher Subject: [Ice] Agenda requests for ICE WG at IETF 95 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 08:11:34 -0000 ICE WG, In the preliminary agenda we have a 2-hour session on Thursday, April 7th at the IETF 95: https://datatracker.ietf.org/meeting/95/agenda.html If you would like to have a presentation slot at the ICE WG meeting, please let the chairs know as soon as possible, but latest Thursday 17th of March. In the face-to-face meeting we will prioritize work that has been already discussed on the mailing list, so please raise open issues on the ICE list already well before the meeting. In your agenda request e-mail please specify the following: - name of the draft and the presenter - how much time you would like to have - outline of major open issues; what needs to be discussed at the meeting - dependencies to your draft (if any) Thanks, Ari & Peter (ICE WG co-chairs) From nobody Wed Mar 9 11:26:03 2016 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 0B49D12D957 for ; Wed, 9 Mar 2016 11:26:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkn_2bxi75SO for ; Wed, 9 Mar 2016 11:25:59 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 9124012D8AB for ; Wed, 9 Mar 2016 11:25:59 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e185so68418504vkb.1 for ; Wed, 09 Mar 2016 11:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lLLcgHutLOlunyN0WPetCM3kTvAfauJBlowzNB/WRpE=; b=A1nl+TbTwHkYb/AunspHL1TQPkpK1Sl7Dzb3VmNEpP6bdB4r2nlYBkhdMZuJjPCJfe 1zT03409SOZNR7yQHRQwvMCgs9hErkcUqKR2/40MwwJumdim+a4lfGbwO2ePcKFZuXtq GaDlgsV0V20zIPttipttqFIJNjs/WinSM+YgxQqCcWJ4UD/UfOzTF5K15HfQ1zFwF671 EzDVhWtZBNGsg3EjH4TWgn3OFcSp/vc+hZnA83ZMP8KdaZAEPYpkYZM/BVbdgFOlNbbp qIRngUGVn3hu6OJNrziI2mRtYm7wd4kFly933R6g3f+/8xKMZqWrPMceAj+eQW++30zF fDZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lLLcgHutLOlunyN0WPetCM3kTvAfauJBlowzNB/WRpE=; b=YGs7EFD6i4bycgmrVEAqjv3BDocZ+vayNLbRe/blZOokgky37RGRRM0ejeuLr25Iqy 2VDmktbEGFop63X9o1dP1MyYNj/sZsQFX3VMj4xNsx2Vnjw8eJ9rSCZZyZ68RWQ0mrYv 4Y95oM22yTcawJwGFkN/xfpqCTnsqWaQTM89hjdZVimMmvaU0T17w3BiA2VGPmeeyySh jHPLWpk12raQDhAc4KKYISILLP+aDrrZ8XCdxmNS5gUoZmssAKiRns3mWqKVZz45VBuM ycj5SobgZ1CvFWEEemfvNpBfHWrb0xmJ0IVe+ZbmzUkvsCKDV0XK+r4M6kLj5sOYoFVK iNQg== X-Gm-Message-State: AD7BkJLvUW89UBvuUrULNwBcQZlM5TRLlZijFBKlXs3YFLnS/LTUBn/LYK8lJqtT8R6OOpHO5TCvv7wNQbeXX0vn X-Received: by 10.31.8.205 with SMTP id 196mr34045580vki.144.1457551558635; Wed, 09 Mar 2016 11:25:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.35.137 with HTTP; Wed, 9 Mar 2016 11:25:19 -0800 (PST) In-Reply-To: <56CBE148.9050100@stpeter.im> References: <56CBE148.9050100@stpeter.im> From: Peter Thatcher Date: Wed, 9 Mar 2016 11:25:19 -0800 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1144f912e56767052da2aa13 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 19:26:02 -0000 --001a1144f912e56767052da2aa13 Content-Type: text/plain; charset=UTF-8 Can we just say that trickle-ice must be used with rtcp-mux? Then we don't need to worry about this. Non-muxed RTCP is becoming increasingly rare, especially for WebRTC, where browsers will likely stop supporting it soon. And what endpoint is going to implement trickle-ice but not rtcp-mux? On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre wrote: > At IETF 94 we discussed potential changes to the unfreezing procedures for > trickle when two components have different foundations. We didn't come up > with a solution and redirected discussion to the list. Does anyone have a > proposal to solve this impasse? > > Peter > > P.S. Here are the relevant notes from the IETF 94 minutes... > > ### > > If one component doesn't have the same foundation as another component, > unfreezing logic doesn't work. > > Jonathan Lennox commented that trickle rules could enforce order, by > providing components in order and maintain order. > > Emil Ivov: We shouldn't design at the mic. We already agreed that we > trickle candidates in the order they'd be signaled, but if we want to > change that, I'd be open. > > Jonathan: Trickling earlier doesn't gain anything if those pairs stay > frozen. It just changes where the implementation burden is. > > Emil: Adding new states for components would make things complicated, so > I'd prefer we keep the order. > > Peter (as individual): I think it's more burden on the sender side and > less on the receiver side. It would also slow things down if signaling is > slow. Plus, in WebRTC, we already have to deal with Javascript handing down > remote candidates in the wrong order. > > Jonathan: We need signaling that means there are no candidates. > > Justin: How do we detect this? > > Jonathan: TURN allocation timed out, etc. > > Peter: Can we change the freezing algorithm to be more lax? > > Conclusion: Should take this to the mailing list what to do with > unfreezing when one component doesn't have the same foundation as another. > Signalling "no candidates for this component" is problematic. Delaying the > signalling of other candidates is problematic. Still looking for a solution. > > ### > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a1144f912e56767052da2aa13 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can we just say that trickle-ice must be used with rtcp= -mux?=C2=A0 Then we don't need to worry about this. =C2=A0 Non-muxed RT= CP is becoming increasingly rare, especially for WebRTC, where browsers wil= l likely stop supporting it soon.=C2=A0

And what endpo= int is going to implement trickle-ice but not rtcp-mux? =C2=A0
=




On Mon, Feb 22, 2016 at 8:34 PM, Pete= r Saint-Andre <stpeter@stpeter.im> wrote:
At IETF 94 we discussed potential changes to the unfreezin= g procedures for trickle when two components have different foundations. We= didn't come up with a solution and redirected discussion to the list. = Does anyone have a proposal to solve this impasse?

Peter

P.S. Here are the relevant notes from the IETF 94 minutes...

###

If one component doesn't have the same foundation as another component,= unfreezing logic doesn't work.

Jonathan Lennox commented that trickle rules could enforce order, by provid= ing components in order and maintain order.

Emil Ivov: We shouldn't design at the mic. We already agreed that we tr= ickle candidates in the order they'd be signaled, but if we want to cha= nge that, I'd be open.

Jonathan: Trickling earlier doesn't gain anything if those pairs stay f= rozen. It just changes where the implementation burden is.

Emil: Adding new states for components would make things complicated, so I&= #39;d prefer we keep the order.

Peter (as individual): I think it's more burden on the sender side and = less on the receiver side. It would also slow things down if signaling is s= low. Plus, in WebRTC, we already have to deal with Javascript handing down = remote candidates in the wrong order.

Jonathan: We need signaling that means there are no candidates.

Justin: How do we detect this?

Jonathan: TURN allocation timed out, etc.

Peter: Can we change the freezing algorithm to be more lax?

Conclusion: Should take this to the mailing list what to do with unfreezing= when one component doesn't have the same foundation as another. Signal= ling "no candidates for this component" is problematic. Delaying = the signalling of other candidates is problematic. Still looking for a solu= tion.

###

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

--001a1144f912e56767052da2aa13-- From nobody Fri Mar 11 18:50:44 2016 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 1712112DC7D for ; Fri, 11 Mar 2016 18:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 p1qktXGPmrcm for ; Fri, 11 Mar 2016 18:50:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1692012DC41 for ; Fri, 11 Mar 2016 18:50:40 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 40E0D415FD; Fri, 11 Mar 2016 19:56:36 -0700 (MST) To: Peter Thatcher References: <56CBE148.9050100@stpeter.im> From: Peter Saint-Andre Message-ID: <56E383FC.6090504@stpeter.im> Date: Fri, 11 Mar 2016 19:50:36 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 02:50:43 -0000 On 3/9/16 12:25 PM, Peter Thatcher wrote: > Can we just say that trickle-ice must be used with rtcp-mux? Then we > don't need to worry about this. Non-muxed RTCP is becoming > increasingly rare, especially for WebRTC, where browsers will likely > stop supporting it soon. > > And what endpoint is going to implement trickle-ice but not rtcp-mux? Not because those two features are necessarily related, but because modern endpoints tend to implement both - correct? Peter > > > > > > On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre > wrote: > > At IETF 94 we discussed potential changes to the unfreezing > procedures for trickle when two components have different > foundations. We didn't come up with a solution and redirected > discussion to the list. Does anyone have a proposal to solve this > impasse? > > Peter > > P.S. Here are the relevant notes from the IETF 94 minutes... > > ### > > If one component doesn't have the same foundation as another > component, unfreezing logic doesn't work. > > Jonathan Lennox commented that trickle rules could enforce order, by > providing components in order and maintain order. > > Emil Ivov: We shouldn't design at the mic. We already agreed that we > trickle candidates in the order they'd be signaled, but if we want > to change that, I'd be open. > > Jonathan: Trickling earlier doesn't gain anything if those pairs > stay frozen. It just changes where the implementation burden is. > > Emil: Adding new states for components would make things > complicated, so I'd prefer we keep the order. > > Peter (as individual): I think it's more burden on the sender side > and less on the receiver side. It would also slow things down if > signaling is slow. Plus, in WebRTC, we already have to deal with > Javascript handing down remote candidates in the wrong order. > > Jonathan: We need signaling that means there are no candidates. > > Justin: How do we detect this? > > Jonathan: TURN allocation timed out, etc. > > Peter: Can we change the freezing algorithm to be more lax? > > Conclusion: Should take this to the mailing list what to do with > unfreezing when one component doesn't have the same foundation as > another. Signalling "no candidates for this component" is > problematic. Delaying the signalling of other candidates is > problematic. Still looking for a solution. > > ### > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > From nobody Sat Mar 12 10:59:07 2016 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 13D0A12DF29; Fri, 11 Mar 2016 15:05:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230546.15028.73169.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:46 -0800 Archived-At: X-Mailman-Approved-At: Sat, 12 Mar 2016 10:59:05 -0800 Cc: ben@nostrum.com, ice@ietf.org Subject: [Ice] ice - Requested session has been scheduled for IETF 95 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:46 -0000 Dear Ari Keranen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ice Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Buen Ayre A size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Ari Keranen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch Second Priority: netvc rmcat httpbis perc Third Priority: xrblock clue lwig 6lo ace Special Requests: Not on Monday. --------------------------------------------------------- From nobody Sun Mar 13 19:19:21 2016 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 8E42212D8F0 for ; Sun, 13 Mar 2016 19:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VVIS2PJ67TsW for ; Sun, 13 Mar 2016 19:19:18 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA52512D570 for ; Sun, 13 Mar 2016 19:19:17 -0700 (PDT) X-AuditID: c1b4fb30-f79d26d000006389-6f-56e61fa3a2b9 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F3.A1.25481.3AF16E65; Mon, 14 Mar 2016 03:19:15 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.248.2; Mon, 14 Mar 2016 03:19:14 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 72A914E9FC; Mon, 14 Mar 2016 04:22:18 +0200 (EET) Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 947304E9B6; Mon, 14 Mar 2016 04:22:16 +0200 (EET) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37E30643@ESESSMB209.ericsson.se> From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: <56E5CF84.30000@ericsson.com> Date: Sun, 13 Mar 2016 13:37:24 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E30643@ESESSMB209.ericsson.se> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2J7oO5i+WdhBpN3mFl8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6M1t1dbAVt3BUb5x9mbGDcxNHFyMkhIWAisWz1F1YIW0ziwr31 bF2MXBxCAocZJdo77rBDONsYJWZdX80C4axllJi5+iMbSIuQwHJGieOrmEBsYYEMiXfPusBs EYFwiTsvb0LV+Er8O7YazGYTsJX43b4HrIZXQFOi/8hGRhCbRUBV4taNj8wgtqhAmsSsvgks EDWCEidnPgGzOQX8JJ787AI6lYODWcBe4sHWMpAws4C8RPPW2cwQH6hJXD23iRlirarE1X+v GCcwCs9CMmkWQvcsJN0LGJlXMYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgQG8sEtvw12ML58 7niIUYCDUYmHd8OOp2FCrIllxZW5hxglOJiVRHgzpJ+FCfGmJFZWpRblxxeV5qQWH2KU5mBR Eudl/XQ5TEggPbEkNTs1tSC1CCbLxMEp1cC49OiR/3wbn6zWDA49oue6ffHe/yK3S0uf8/iq Odb9sPp/MKrRdqP8Y7dSXu0754NmT15RHmm2nW9Tw+QLhmbGQdKx9cZpG6c3hLNnz/C8+ezV Ibnb2uKcTFtkJVPcU7NmSSw8PbGD4eTkf5pWSUK//ZjTr0y9aBQzdY+zWa6rEZM76wXvFYVK LMUZiYZazEXFiQDUFuo+YAIAAA== Archived-At: Subject: Re: [Ice] ICE-bis: Question for clarification on frozen candidates and multiple media streams X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 02:19:19 -0000 Hi, I didn't see answer to this e-mail, so let me try to clarify. On 22/02/16 02:31, Christer Holmberg wrote: > Section 2.4 (Frozen Candidates) of draft-5245bis, talking about > establishing multiple flows, says: > > “The network properties are likely to be very similar for each > > component (especially because RTP and RTCP are sent and > received from > > the same IP address).” > > I think this text is unclear. > > It could mean that the same IP address is used for all RTP/RTCP flows, > which does not have to be the case. That is indeed not the case. Maybe it should say "for each component of a media stream" to make it more clear. > It could mean that RTP and RTCP is sent from the same IP address as the > associated STUN requests. While that is true, I don’t understand what it > has to do with multiple flows. Which flow do you refer to? I assume multiple components (not media streams). > It could mean that, for a given flow, RTP and RTCP are sent from the > same IP address. Is that always true? And, even if it is, I don’t > understand what it has to do with multiple flows. Since RTP and RTCP use different ports but same IP addresses (for the same RTP media stream), these two components are most likely treated by middleboxes in identical way. Hence, if the first one works, the second does too. Cheers, Ari From nobody Mon Mar 14 09:36:28 2016 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 70F7812D536 for ; Mon, 14 Mar 2016 09:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 12Tnb_Us-ety for ; Mon, 14 Mar 2016 09:36:19 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 8B66512D63E for ; Mon, 14 Mar 2016 09:36:18 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id e185so215633293vkb.1 for ; Mon, 14 Mar 2016 09:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IyzPCiQyIAbO9K5YZQo+WSR2LgK2dxGEhqHju+CRN9o=; b=DjnZFBdX0Do95H8Q+EEsHSvjjehW/IymiEUldT7GpW0fH28oKLfiKf946RL4IOMoxM VoKG5I/jRsnbWqghYLtUbOh5DbS7RI8POf49FK3saNRAtbEreIcS3fE7HwCsPVNBntAD uwzPxEmF/25vaV5lZKtcUjkBdd/J2D2EEI5DYkKkT8cDk71hQlXQgGDcMsc6HDCv1T+L arEBYVBQEAVzF6ciOzD1fFiWcTS3bdy8dw2pX9Br5yqmr4iP3hK3X7btt9rACd2RBbqk Evv7A1bt3Dar9oJ9sU318v+4k5H+nKk3hFojSbVsrDbnxcNtNp1wHHS7r1hkHxbQGIyI LhCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IyzPCiQyIAbO9K5YZQo+WSR2LgK2dxGEhqHju+CRN9o=; b=CE03ulAkKA25CX6VQuEtfM3wcWSn3/gH2GSWZ4Hxz2J9tHR1B6oaXIHUNvycsbtLLd dzDXmmC3/qrxjQHfKlDXTb1L6Pu/JqNR1JwJ47G4TLPkSoUEvLSb46sb44O8t5IVvLwh 8JoTpAdk3hY7DyUoTT/9eVq5UatDsiUpiNoH3X4mVFHAeO8qsMGVOGh9hdW691zJqgQK C5/mUl68BNauaDQFHq17jbBtEL5ksh3UkNwhHXW4WqsGNWCoAT6cI+iYncVvnp0GXIk3 AjXz2sxcdq2SSqCt+QDNaHPm7oKKoc4wu1eeEPRx9wUx7iZ4qt8h/zRAxDKdAU9gW+5L itCA== X-Gm-Message-State: AD7BkJI3tgTyM5hCfsEDsxHCjWV6w+aH6nWUQlvwNQU73gmMHiP4+KnHB8oHF8awwH6HpDjWwRG9b4ZP4qPrxKHn X-Received: by 10.31.7.140 with SMTP id 134mr26532111vkh.155.1457973377590; Mon, 14 Mar 2016 09:36:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.35.137 with HTTP; Mon, 14 Mar 2016 09:35:38 -0700 (PDT) In-Reply-To: <56E383FC.6090504@stpeter.im> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> From: Peter Thatcher Date: Mon, 14 Mar 2016 09:35:38 -0700 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a1143f25243a3f0052e04e111 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 16:36:26 -0000 --001a1143f25243a3f0052e04e111 Content-Type: text/plain; charset=UTF-8 Correct. On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre wrote: > On 3/9/16 12:25 PM, Peter Thatcher wrote: > >> Can we just say that trickle-ice must be used with rtcp-mux? Then we >> don't need to worry about this. Non-muxed RTCP is becoming >> increasingly rare, especially for WebRTC, where browsers will likely >> stop supporting it soon. >> >> And what endpoint is going to implement trickle-ice but not rtcp-mux? >> > > Not because those two features are necessarily related, but because modern > endpoints tend to implement both - correct? > > Peter > > >> >> >> >> >> On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre > > wrote: >> >> At IETF 94 we discussed potential changes to the unfreezing >> procedures for trickle when two components have different >> foundations. We didn't come up with a solution and redirected >> discussion to the list. Does anyone have a proposal to solve this >> impasse? >> >> Peter >> >> P.S. Here are the relevant notes from the IETF 94 minutes... >> >> ### >> >> If one component doesn't have the same foundation as another >> component, unfreezing logic doesn't work. >> >> Jonathan Lennox commented that trickle rules could enforce order, by >> providing components in order and maintain order. >> >> Emil Ivov: We shouldn't design at the mic. We already agreed that we >> trickle candidates in the order they'd be signaled, but if we want >> to change that, I'd be open. >> >> Jonathan: Trickling earlier doesn't gain anything if those pairs >> stay frozen. It just changes where the implementation burden is. >> >> Emil: Adding new states for components would make things >> complicated, so I'd prefer we keep the order. >> >> Peter (as individual): I think it's more burden on the sender side >> and less on the receiver side. It would also slow things down if >> signaling is slow. Plus, in WebRTC, we already have to deal with >> Javascript handing down remote candidates in the wrong order. >> >> Jonathan: We need signaling that means there are no candidates. >> >> Justin: How do we detect this? >> >> Jonathan: TURN allocation timed out, etc. >> >> Peter: Can we change the freezing algorithm to be more lax? >> >> Conclusion: Should take this to the mailing list what to do with >> unfreezing when one component doesn't have the same foundation as >> another. Signalling "no candidates for this component" is >> problematic. Delaying the signalling of other candidates is >> problematic. Still looking for a solution. >> >> ### >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> >> > --001a1143f25243a3f0052e04e111 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre <stpe= ter@stpeter.im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?=C2=A0 Then we<= br> don't need to worry about this.=C2=A0 =C2=A0Non-muxed RTCP is becoming<= br> increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because modern = endpoints tend to implement both - correct?

Peter






On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<= div class=3D"h5"> <mailto:stpeter@= stpeter.im>> wrote:

=C2=A0 =C2=A0 At IETF 94 we discussed potential changes to the unfreezing =C2=A0 =C2=A0 procedures for trickle when two components have different
=C2=A0 =C2=A0 foundations. We didn't come up with a solution and redire= cted
=C2=A0 =C2=A0 discussion to the list. Does anyone have a proposal to solve = this
=C2=A0 =C2=A0 impasse?

=C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 If one component doesn't have the same foundation as anot= her
=C2=A0 =C2=A0 component, unfreezing logic doesn't work.

=C2=A0 =C2=A0 Jonathan Lennox commented that trickle rules could enforce or= der, by
=C2=A0 =C2=A0 providing components in order and maintain order.

=C2=A0 =C2=A0 Emil Ivov: We shouldn't design at the mic. We already agr= eed that we
=C2=A0 =C2=A0 trickle candidates in the order they'd be signaled, but i= f we want
=C2=A0 =C2=A0 to change that, I'd be open.

=C2=A0 =C2=A0 Jonathan: Trickling earlier doesn't gain anything if thos= e pairs
=C2=A0 =C2=A0 stay frozen. It just changes where the implementation burden = is.

=C2=A0 =C2=A0 Emil: Adding new states for components would make things
=C2=A0 =C2=A0 complicated, so I'd prefer we keep the order.

=C2=A0 =C2=A0 Peter (as individual): I think it's more burden on the se= nder side
=C2=A0 =C2=A0 and less on the receiver side. It would also slow things down= if
=C2=A0 =C2=A0 signaling is slow. Plus, in WebRTC, we already have to deal w= ith
=C2=A0 =C2=A0 Javascript handing down remote candidates in the wrong order.=

=C2=A0 =C2=A0 Jonathan: We need signaling that means there are no candidate= s.

=C2=A0 =C2=A0 Justin: How do we detect this?

=C2=A0 =C2=A0 Jonathan: TURN allocation timed out, etc.

=C2=A0 =C2=A0 Peter: Can we change the freezing algorithm to be more lax?
=C2=A0 =C2=A0 Conclusion: Should take this to the mailing list what to do w= ith
=C2=A0 =C2=A0 unfreezing when one component doesn't have the same found= ation as
=C2=A0 =C2=A0 another. Signalling "no candidates for this component&qu= ot; is
=C2=A0 =C2=A0 problematic. Delaying the signalling of other candidates is =C2=A0 =C2=A0 problematic. Still looking for a solution.

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Ice mailing list
=C2=A0 =C2=A0 Ice@ietf.or= g <mailto:Ice@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ice=




--001a1143f25243a3f0052e04e111-- From nobody Thu Mar 17 07:52:21 2016 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 1AD6B12D906 for ; Thu, 17 Mar 2016 07:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cR6eAf1YMRgb for ; Thu, 17 Mar 2016 07:52:18 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A49612DC01 for ; Thu, 17 Mar 2016 07:52:14 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-15-56eac49d0bae Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.F7.30858.D94CAE65; Thu, 17 Mar 2016 15:52:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 15:52:09 +0100 From: Christer Holmberg To: Peter Thatcher , Peter Saint-Andre Thread-Topic: [Ice] unfreezing with disparate foundations Thread-Index: AQHRbfN5jcf89bd2VEi7ZKjq2k0vOJ9RhiqAgAOhEwCABAstAIAEu5oA Date: Thu, 17 Mar 2016 14:52:09 +0000 Message-ID: References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_D3108FD65D4Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7t+7cI6/CDPZ8UrT4dqHW4try16wW x/b0MzsweyzYVOqxZMlPJo+5e14wBzBHcdmkpOZklqUW6dslcGWce/uHvWB/YMXOI+ENjBtc uhg5OSQETCR2/57CDGGLSVy4t56ti5GLQ0jgMKPE75ZjUM4SRondl1cxdTFycLAJWEh0/9MG aRARCJa4duAJI0iYWUBR4uVeNZCwMFDFiwXLmSFKLCXuTvnGBGG7Saw4PpkFxGYRUJVY0HaM EcTmFbCS+LnzABPEquuMEvdv/wZr4BQIlNi8/yfYIEag476fWgMWZxYQl7j1ZD4TxNECEkv2 nId6QFTi5eN/rCC2qICexI5zELaEgJLEotufoXrjJSb1r2OBWCwocXLmE5YJjGKzkIydhaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48BuoFBYW1xPFbbshKFjByrGIULU4tTspNNzLSSy3K TC4uzs/Ty0st2cQIjNWDW34b7GB8+dzxEKMAB6MSD2/B05dhQqyJZcWVuYcYJTiYlUR42Q69 ChPiTUmsrEotyo8vKs1JLT7EKM3BoiTOy/rpcpiQQHpiSWp2ampBahFMlomDU6qBcYrANyO2 25YFFZlfThqflL1872HlH3ODD5/6v7j/exFxaFZ6EvPJZiOLkmmHpryNXXLqpdyHw0uadNuS zn1na2N8/8JWmMlNx33x7mmKj26FZ8QfqvjreoRti8HFS48jdZ+eVL/+hK/ojnHGu4LX38w3 pvDeOidddpS13+fsXRWhi+1277fNOq3EUpyRaKjFXFScCACbkaQ/0QIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 14:52:20 -0000 --_000_D3108FD65D4Achristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Stupid question: if the assumption is that implementers will move more and = more towards rtcp-mux, do we need the freezing mechanism to begin with? Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Monday 14 March 2016 at 18:35 To: "stpeter@stpeter.im" > Cc: "ice@ietf.org" > Subject: Re: [Ice] unfreezing with disparate foundations Correct. On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre > wrote: On 3/9/16 12:25 PM, Peter Thatcher wrote: Can we just say that trickle-ice must be used with rtcp-mux? Then we don't need to worry about this. Non-muxed RTCP is becoming increasingly rare, especially for WebRTC, where browsers will likely stop supporting it soon. And what endpoint is going to implement trickle-ice but not rtcp-mux? Not because those two features are necessarily related, but because modern = endpoints tend to implement both - correct? Peter On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre >> wrote: At IETF 94 we discussed potential changes to the unfreezing procedures for trickle when two components have different foundations. We didn't come up with a solution and redirected discussion to the list. Does anyone have a proposal to solve this impasse? Peter P.S. Here are the relevant notes from the IETF 94 minutes... ### If one component doesn't have the same foundation as another component, unfreezing logic doesn't work. Jonathan Lennox commented that trickle rules could enforce order, by providing components in order and maintain order. Emil Ivov: We shouldn't design at the mic. We already agreed that we trickle candidates in the order they'd be signaled, but if we want to change that, I'd be open. Jonathan: Trickling earlier doesn't gain anything if those pairs stay frozen. It just changes where the implementation burden is. Emil: Adding new states for components would make things complicated, so I'd prefer we keep the order. Peter (as individual): I think it's more burden on the sender side and less on the receiver side. It would also slow things down if signaling is slow. Plus, in WebRTC, we already have to deal with Javascript handing down remote candidates in the wrong order. Jonathan: We need signaling that means there are no candidates. Justin: How do we detect this? Jonathan: TURN allocation timed out, etc. Peter: Can we change the freezing algorithm to be more lax? Conclusion: Should take this to the mailing list what to do with unfreezing when one component doesn't have the same foundation as another. Signalling "no candidates for this component" is problematic. Delaying the signalling of other candidates is problematic. Still looking for a solution. ### _______________________________________________ Ice mailing list Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --_000_D3108FD65D4Achristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <506B95E6F6021E498EE5685212D6F311@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Stupid question: if the assumption is that implementers will move more= and more towards rtcp-mux, do we need the freezing mechanism to begin with= ?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of "pthatcher@google.com" <pthatcher@google.com>
Date: Monday 14 March 2016 at 18:35=
To: "stpeter@stpeter.im" <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.= org>
Subject: Re: [Ice] unfreezing with = disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-And= re <stpeter@stpeter= .im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?  Then we<= br> don't need to worry about this.   Non-muxed RTCP is becoming
increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because = modern endpoints tend to implement both - correct?

Peter






On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@stpeter.im>> wrote:

    At IETF 94 we discussed potential changes to the unfreezing     procedures for trickle when two components have different
    foundations. We didn't come up with a solution and redirected=
    discussion to the list. Does anyone have a proposal to solve = this
    impasse?

    Peter

    P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
    ###

    If one component doesn't have the same foundation as another<= br>     component, unfreezing logic doesn't work.

    Jonathan Lennox commented that trickle rules could enforce or= der, by
    providing components in order and maintain order.

    Emil Ivov: We shouldn't design at the mic. We already agreed = that we
    trickle candidates in the order they'd be signaled, but if we= want
    to change that, I'd be open.

    Jonathan: Trickling earlier doesn't gain anything if those pa= irs
    stay frozen. It just changes where the implementation burden = is.

    Emil: Adding new states for components would make things
    complicated, so I'd prefer we keep the order.

    Peter (as individual): I think it's more burden on the sender= side
    and less on the receiver side. It would also slow things down= if
    signaling is slow. Plus, in WebRTC, we already have to deal w= ith
    Javascript handing down remote candidates in the wrong order.=

    Jonathan: We need signaling that means there are no candidate= s.

    Justin: How do we detect this?

    Jonathan: TURN allocation timed out, etc.

    Peter: Can we change the freezing algorithm to be more lax?
    Conclusion: Should take this to the mailing list what to do w= ith
    unfreezing when one component doesn't have the same foundatio= n as
    another. Signalling "no candidates for this component&qu= ot; is
    problematic. Delaying the signalling of other candidates is     problematic. Still looking for a solution.

    ###

    _______________________________________________
    Ice mailing list
    Ice@ietf.or= g <mailto:Ice@ietf= .org>
    https://www.ietf.org/mailman/listinfo/ice




 --_000_D3108FD65D4Achristerholmbergericssoncom_-- From nobody Thu Mar 17 09:54:43 2016 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 CE32F12DC0C for ; Thu, 17 Mar 2016 09:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 nv3xIUpLTnpq for ; Thu, 17 Mar 2016 09:54:39 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 2BD9F12D874 for ; Thu, 17 Mar 2016 09:54:14 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id e185so109624761vkb.1 for ; Thu, 17 Mar 2016 09:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w7Qry6sXWVEDbWgSdM4JBAYtpnIWCR/c+nYIJAbYeis=; b=dTgqWLBqHC0DZGaiz67CSTI8gs3MgAR07HqW+nz+g+oIMC7kV39EWoh5QOQcb5IICe dfmZNiEROuvhbSoXMz8lG1QM/Qzsz41qC1jQz9uWHmglBsIPpPhLr4HvBgKCJ1bqlG4E lWtibBQeAVbUmwrffUnm1601Y7zDA0Hdkj+lf9PYYjTwhjCHYRKMVw+PSSGZcuU2DJwQ bMVN8ZCnfpnKlU7cw7I6oafIDRu4NtKGzdf1fY+hcO0Vw5lRwTCSpYTS/NubQFC0SNl0 tLCJhe9aY/fACCmwD+qwTsmu1TQNiY09W2kmZPTv9lsj4/ryMKVlULspGHSK9oWkvfm8 XL3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w7Qry6sXWVEDbWgSdM4JBAYtpnIWCR/c+nYIJAbYeis=; b=b4S3UUsJT4CJnR0JOQq12hjnLdIkWJVfy2PyQz9i59cDOC/sago0GXf8ZMJ91H2o3u UoqCWBvzUlni85mFck/I/tIkESuN2/Ymo05l8y7nDeORAa0GW3FOgCJMBoU7kHrFD/s2 tedz7+L1eTuYmmGxVDbLRKiM8I7mvtmwnyzw6WExYOtDHAhqUt7YBsa/f/RnW0A+5pFF vK4tqU6ZcKZ8kRBka+It6nSmwXnuFeEx1wcOuMuXKkKAh8dZY4LHxduanYigzD2HmsXd k19rSgxGbvZXNlXVT6ONxXcGaWAw7LxIrc18o2Cwzkvkh/ZnLf2NlQ+MmhLjl+jCXRLF RKbA== X-Gm-Message-State: AD7BkJKeZaS3fsMxTYXVW3YHxxxxcY5J/rQ54xGAGAu/jjUKmEgip6+ehBcwqSuRcrDc3LOn/PkWPW0fLFbaVMGB X-Received: by 10.31.44.77 with SMTP id s74mr12349885vks.4.1458233653148; Thu, 17 Mar 2016 09:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 17 Mar 2016 09:53:33 -0700 (PDT) In-Reply-To: References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> From: Peter Thatcher Date: Thu, 17 Mar 2016 09:53:33 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c075a2e5906f052e417ae7 Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 16:54:41 -0000 --001a11c075a2e5906f052e417ae7 Content-Type: text/plain; charset=UTF-8 Are you suggesting that we just drop non-muxed RTCP from 5245bis altogether, or are you suggested that we just leave non-muxed RTCP less specified (and so it won't work as well, but oh well, use rtcp-mux if you want things to work well) or something else? On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > Stupid question: if the assumption is that implementers will move more and > more towards rtcp-mux, do we need the freezing mechanism to begin with? > > Regards, > > Christer > > From: Ice on behalf of "pthatcher@google.com" < > pthatcher@google.com> > Date: Monday 14 March 2016 at 18:35 > To: "stpeter@stpeter.im" > Cc: "ice@ietf.org" > Subject: Re: [Ice] unfreezing with disparate foundations > > Correct. > > On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre > wrote: > >> On 3/9/16 12:25 PM, Peter Thatcher wrote: >> >>> Can we just say that trickle-ice must be used with rtcp-mux? Then we >>> don't need to worry about this. Non-muxed RTCP is becoming >>> increasingly rare, especially for WebRTC, where browsers will likely >>> stop supporting it soon. >>> >>> And what endpoint is going to implement trickle-ice but not rtcp-mux? >>> >> >> Not because those two features are necessarily related, but because >> modern endpoints tend to implement both - correct? >> >> Peter >> >> >>> >>> >>> >>> >>> On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre >> > wrote: >>> >>> At IETF 94 we discussed potential changes to the unfreezing >>> procedures for trickle when two components have different >>> foundations. We didn't come up with a solution and redirected >>> discussion to the list. Does anyone have a proposal to solve this >>> impasse? >>> >>> Peter >>> >>> P.S. Here are the relevant notes from the IETF 94 minutes... >>> >>> ### >>> >>> If one component doesn't have the same foundation as another >>> component, unfreezing logic doesn't work. >>> >>> Jonathan Lennox commented that trickle rules could enforce order, by >>> providing components in order and maintain order. >>> >>> Emil Ivov: We shouldn't design at the mic. We already agreed that we >>> trickle candidates in the order they'd be signaled, but if we want >>> to change that, I'd be open. >>> >>> Jonathan: Trickling earlier doesn't gain anything if those pairs >>> stay frozen. It just changes where the implementation burden is. >>> >>> Emil: Adding new states for components would make things >>> complicated, so I'd prefer we keep the order. >>> >>> Peter (as individual): I think it's more burden on the sender side >>> and less on the receiver side. It would also slow things down if >>> signaling is slow. Plus, in WebRTC, we already have to deal with >>> Javascript handing down remote candidates in the wrong order. >>> >>> Jonathan: We need signaling that means there are no candidates. >>> >>> Justin: How do we detect this? >>> >>> Jonathan: TURN allocation timed out, etc. >>> >>> Peter: Can we change the freezing algorithm to be more lax? >>> >>> Conclusion: Should take this to the mailing list what to do with >>> unfreezing when one component doesn't have the same foundation as >>> another. Signalling "no candidates for this component" is >>> problematic. Delaying the signalling of other candidates is >>> problematic. Still looking for a solution. >>> >>> ### >>> >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >>> >>> >>> >> > --001a11c075a2e5906f052e417ae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Are you suggesting that we just drop non-muxed RTCP fro= m 5245bis altogether, or are you suggested that we just leave non-muxed RTC= P less specified (and so it won't work as well, but oh well, use rtcp-m= ux if you want things to work well) or something else?



On Thu= , Mar 17, 2016 at 7:52 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi,

Stupid question: if the assumption is that implementers will move more= and more towards rtcp-mux, do we need the freezing mechanism to begin with= ?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Monday 14 March 2016 at 18:35=
To: "stpeter@stpeter.im" <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] unfreezing with = disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-And= re <stpeter@stpeter= .im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?=C2=A0 Then we<= br> don't need to worry about this.=C2=A0 =C2=A0Non-muxed RTCP is becoming<= br> increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because = modern endpoints tend to implement both - correct?

Peter






On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stp= eter@stpeter.im>> wrote:

=C2=A0 =C2=A0 At IETF 94 we discussed potential changes to the unfreezing =C2=A0 =C2=A0 procedures for trickle when two components have different
=C2=A0 =C2=A0 foundations. We didn't come up with a solution and redire= cted
=C2=A0 =C2=A0 discussion to the list. Does anyone have a proposal to solve = this
=C2=A0 =C2=A0 impasse?

=C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 If one component doesn't have the same foundation as anot= her
=C2=A0 =C2=A0 component, unfreezing logic doesn't work.

=C2=A0 =C2=A0 Jonathan Lennox commented that trickle rules could enforce or= der, by
=C2=A0 =C2=A0 providing components in order and maintain order.

=C2=A0 =C2=A0 Emil Ivov: We shouldn't design at the mic. We already agr= eed that we
=C2=A0 =C2=A0 trickle candidates in the order they'd be signaled, but i= f we want
=C2=A0 =C2=A0 to change that, I'd be open.

=C2=A0 =C2=A0 Jonathan: Trickling earlier doesn't gain anything if thos= e pairs
=C2=A0 =C2=A0 stay frozen. It just changes where the implementation burden = is.

=C2=A0 =C2=A0 Emil: Adding new states for components would make things
=C2=A0 =C2=A0 complicated, so I'd prefer we keep the order.

=C2=A0 =C2=A0 Peter (as individual): I think it's more burden on the se= nder side
=C2=A0 =C2=A0 and less on the receiver side. It would also slow things down= if
=C2=A0 =C2=A0 signaling is slow. Plus, in WebRTC, we already have to deal w= ith
=C2=A0 =C2=A0 Javascript handing down remote candidates in the wrong order.=

=C2=A0 =C2=A0 Jonathan: We need signaling that means there are no candidate= s.

=C2=A0 =C2=A0 Justin: How do we detect this?

=C2=A0 =C2=A0 Jonathan: TURN allocation timed out, etc.

=C2=A0 =C2=A0 Peter: Can we change the freezing algorithm to be more lax?
=C2=A0 =C2=A0 Conclusion: Should take this to the mailing list what to do w= ith
=C2=A0 =C2=A0 unfreezing when one component doesn't have the same found= ation as
=C2=A0 =C2=A0 another. Signalling "no candidates for this component&qu= ot; is
=C2=A0 =C2=A0 problematic. Delaying the signalling of other candidates is =C2=A0 =C2=A0 problematic. Still looking for a solution.

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Ice mailing list
=C2=A0 =C2=A0 Ice@ietf.or= g <mailto:Ice@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ice

--001a11c075a2e5906f052e417ae7-- From nobody Thu Mar 17 10:10:29 2016 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 735C912DC98 for ; Thu, 17 Mar 2016 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 H029lJKvYU2a for ; Thu, 17 Mar 2016 10:10:25 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD74812DC36 for ; Thu, 17 Mar 2016 10:09:27 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-c2-56eae4c5914a Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.BE.30858.5C4EAE65; Thu, 17 Mar 2016 18:09:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 18:08:57 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [Ice] unfreezing with disparate foundations Thread-Index: AQHRbfN5jcf89bd2VEi7ZKjq2k0vOJ9RhiqAgAOhEwCABAstAIAEu5oAgAAAZoCAABUQBA== Date: Thu, 17 Mar 2016 17:08:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37EBF6CDESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7me7RJ6/CDNauk7D4dqHW4try16wW x/b0MzsweyzYVOqxZMlPJo+5e14wBzBHcdmkpOZklqUW6dslcGVMObOcpWB2fsXM/v8sDYyL 4roYOTkkBEwknq9rYoOwxSQu3FsPZHNxCAkcZpT4emMRlLOEUaL/+AnGLkYODjYBC4nuf9og DSICmhKTJzezgtjMAp4Sj4/vYgKxhYFKVjzYzw5RYylxd8o3Jgg7TOL/yRvMIDaLgKrE4sWn wWp4BXwlji3fAXaEkMBZJom5j/VBbE6BQIkp0xaAzWcEOu77qTVMELvEJZq+rGSFOFpAYsme 88wQtqjEy8f/oO7Jl9iw+S4jxHxBiZMzn7BMYBSZhaR9FpKyWUjKIOIGEl/e34aytSWWLXzN DGHrS3S/P82ELL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCcHdzy22AH48vnjocY BTgYlXh4C56+DBNiTSwrrsw9xCjBwawkwtv++FWYEG9KYmVValF+fFFpTmrxIUZpDhYlcV7W T5fDhATSE0tSs1NTC1KLYLJMHJxSDYwaru0VvbMm81wv2vW6SPDKq3b92MsznhvKxrzb9LZz xoODS5bYuL06HXFqnW1B0Z8DnxPsFlqkOK/x/fz6aOtzrf+X60SuOd6Ma76RvFYtT02+cldc 3brSH8L3/OR/S37iv/65z/3LT/nvaQ2hnlf9jt56MltbcmM/H2ffBjaGByF3PCe9XJaoxFKc kWioxVxUnAgAKCmIwa8CAAA= Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:10:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37EBF6CDESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I was thinking that we wouldn't care if candidates share the same foundatio= n or not - we deal with all candidates in the same way. Based on what the browser folks say, browsers will anyway only support rtcp= -mux, no matter if it's mandated by 5245bis or not. Regards, Christer Sent from my Windows Phone ________________________________ From: Peter Thatcher Sent: =FD17/=FD03/=FD2016 18:54 To: Christer Holmberg Cc: Peter Saint-Andre; ice@ietf.org Subject: Re: [Ice] unfreezing with disparate foundations Are you suggesting that we just drop non-muxed RTCP from 5245bis altogether= , or are you suggested that we just leave non-muxed RTCP less specified (an= d so it won't work as well, but oh well, use rtcp-mux if you want things to= work well) or something else? On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg > wrote: Hi, Stupid question: if the assumption is that implementers will move more and = more towards rtcp-mux, do we need the freezing mechanism to begin with? Regards, Christer From: Ice > on behalf of = "pthatcher@google.com" > Date: Monday 14 March 2016 at 18:35 To: "stpeter@stpeter.im" > Cc: "ice@ietf.org" > Subject: Re: [Ice] unfreezing with disparate foundations Correct. On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre > wrote: On 3/9/16 12:25 PM, Peter Thatcher wrote: Can we just say that trickle-ice must be used with rtcp-mux? Then we don't need to worry about this. Non-muxed RTCP is becoming increasingly rare, especially for WebRTC, where browsers will likely stop supporting it soon. And what endpoint is going to implement trickle-ice but not rtcp-mux? Not because those two features are necessarily related, but because modern = endpoints tend to implement both - correct? Peter On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre >> wrote: At IETF 94 we discussed potential changes to the unfreezing procedures for trickle when two components have different foundations. We didn't come up with a solution and redirected discussion to the list. Does anyone have a proposal to solve this impasse? Peter P.S. Here are the relevant notes from the IETF 94 minutes... ### If one component doesn't have the same foundation as another component, unfreezing logic doesn't work. Jonathan Lennox commented that trickle rules could enforce order, by providing components in order and maintain order. Emil Ivov: We shouldn't design at the mic. We already agreed that we trickle candidates in the order they'd be signaled, but if we want to change that, I'd be open. Jonathan: Trickling earlier doesn't gain anything if those pairs stay frozen. It just changes where the implementation burden is. Emil: Adding new states for components would make things complicated, so I'd prefer we keep the order. Peter (as individual): I think it's more burden on the sender side and less on the receiver side. It would also slow things down if signaling is slow. Plus, in WebRTC, we already have to deal with Javascript handing down remote candidates in the wrong order. Jonathan: We need signaling that means there are no candidates. Justin: How do we detect this? Jonathan: TURN allocation timed out, etc. Peter: Can we change the freezing algorithm to be more lax? Conclusion: Should take this to the mailing list what to do with unfreezing when one component doesn't have the same foundation as another. Signalling "no candidates for this component" is problematic. Delaying the signalling of other candidates is problematic. Still looking for a solution. ### _______________________________________________ Ice mailing list Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --_000_7594FB04B1934943A5C02806D1A2204B37EBF6CDESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I was thinking that we wouldn't care if candidates share the same foundatio= n or not - we deal with all candidates in the same way.

Based on what the browser folks say, browsers will anyway only support rtcp= -mux, no matter if it's mandated by 5245bis or not.

Regards,

Christer



Sent from my Windows Phone
From: Peter Thatcher
Sent: =FD17= /=FD03/=FD2016 18:54
To: Christer Holmberg Cc: Peter Saint-Andre; ice@ietf.org
Subject: Re: [= Ice] unfreezing with disparate foundations

Are you suggesting that we just drop non-muxed RTCP from 5245bis altoget= her, or are you suggested that we just leave non-muxed RTCP less specified = (and so it won't work as well, but oh well, use rtcp-mux if you want things to work well) or something else?



On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Stupid question: if the assumption is that implementers will move more= and more towards rtcp-mux, do we need the freezing mechanism to begin with= ?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Monday 14 March 2016 at 18:35=
To: "stpeter@stpeter.im" <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] unfreezing with = disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-And= re <stpeter@stpeter= .im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?  Then we<= br> don't need to worry about this.   Non-muxed RTCP is becoming
increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because = modern endpoints tend to implement both - correct?

Peter






On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stp= eter@stpeter.im>> wrote:

    At IETF 94 we discussed potential changes to the unfreezing     procedures for trickle when two components have different
    foundations. We didn't come up with a solution and redirected=
    discussion to the list. Does anyone have a proposal to solve = this
    impasse?

    Peter

    P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
    ###

    If one component doesn't have the same foundation as another<= br>     component, unfreezing logic doesn't work.

    Jonathan Lennox commented that trickle rules could enforce or= der, by
    providing components in order and maintain order.

    Emil Ivov: We shouldn't design at the mic. We already agreed = that we
    trickle candidates in the order they'd be signaled, but if we= want
    to change that, I'd be open.

    Jonathan: Trickling earlier doesn't gain anything if those pa= irs
    stay frozen. It just changes where the implementation burden = is.

    Emil: Adding new states for components would make things
    complicated, so I'd prefer we keep the order.

    Peter (as individual): I think it's more burden on the sender= side
    and less on the receiver side. It would also slow things down= if
    signaling is slow. Plus, in WebRTC, we already have to deal w= ith
    Javascript handing down remote candidates in the wrong order.=

    Jonathan: We need signaling that means there are no candidate= s.

    Justin: How do we detect this?

    Jonathan: TURN allocation timed out, etc.

    Peter: Can we change the freezing algorithm to be more lax?
    Conclusion: Should take this to the mailing list what to do w= ith
    unfreezing when one component doesn't have the same foundatio= n as
    another. Signalling "no candidates for this component&qu= ot; is
    problematic. Delaying the signalling of other candidates is     problematic. Still looking for a solution.

    ###

    _______________________________________________
    Ice mailing list
    Ice@ietf.or= g <mailto:Ice@ietf= .org>
    https://www.ietf.org/mailman/listinfo/ice





--_000_7594FB04B1934943A5C02806D1A2204B37EBF6CDESESSMB209erics_-- From nobody Thu Mar 17 11:10:10 2016 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 02D9012D9D2 for ; Thu, 17 Mar 2016 11:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 9Q1p6-yaPlZ8 for ; Thu, 17 Mar 2016 11:10:01 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 16AF212D536 for ; Thu, 17 Mar 2016 11:10:00 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id q138so20524468vkb.3 for ; Thu, 17 Mar 2016 11:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RJ7COoZ3kDPTeLY+mZT35uASwpdpV1wu0TMguyYHHg0=; b=S2qUyRF6jrDykOAtTuGIH7SapFVnA3Wy+WpWkaWpDgEiVxzl015XNev6yjkIulDFaL kVsY8dZFECZklDn46UnRQUB53L+52M5PUWtPbkqY53Xow5G2GIX4QCWezBhyfFC10HOI ochiVeOWAoJGyohIkBrKkJ0jq5XdDrCYsl9s91VGgdOPbaStDVVsB15eXv/B4TPdF8Gb z9qFavL6PMG3ZaAOiFqEY6kIWAvRhcloHKjtEhGxBVe40tR1Gj4CI9RIw8OPOC6Z3FJb H7WdKSQYYIf5VEYNxhej2yApAZNvndPEB8rTviMLkW9guub0sM0rj0CJRxVroloS+010 V0cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RJ7COoZ3kDPTeLY+mZT35uASwpdpV1wu0TMguyYHHg0=; b=TrjNuubFLf0D7y2sHy25eO5LlrOWj7wKLtor3AODixD/I1MRlN2sSAosKWco/Wa35R 3+DoeV8Qc+2LFOBYx6ONXcv2WWb9jpIXBLZYJIXeAXnTg7bDdw0Ywyit2dqDbaRQq7TR opMD+6Oi+3y97oCad35BpnY2urFgh35HOf6duMnwYAAjoN7gSGgkES04XtowekSU4/YU qnY0SsumpykWZB/tb1u8dj3iMbalitYwOch0yoIru6Ft9gIx28uLB9MN6x40pF0eoxhT AMuiWmcjt9DtIWcjgIT7iylsqDaZrfaC5JW+R/FibMWTOkW4roqSBgdch4gddRq+F1tC KgDg== X-Gm-Message-State: AD7BkJK3/UVyAS87Lm7wWLAXKKDHTsTF82k+RNx+U4amYaenDqNg0tM1aQxM+DXDelYBSDl+LiIHSZrCAwCtI4ux X-Received: by 10.31.8.68 with SMTP id 65mr12845653vki.150.1458238199932; Thu, 17 Mar 2016 11:09:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 17 Mar 2016 11:09:20 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Thu, 17 Mar 2016 11:09:20 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11440f62e8002f052e4289f8 Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 18:10:05 -0000 --001a11440f62e8002f052e4289f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 17, 2016 at 10:08 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I was thinking that we wouldn't care if candidates share the same > foundation or not - we deal with all candidates in the same way. > For trickle ICE specifically or for 5245bis? =E2=80=8B I'm all for simplification and removing things we don't need. I just want to understand the scope of which you are proposing we do so. > > Based on what the browser folks say, browsers will anyway only support > rtcp-mux, no matter if it's mandated by 5245bis or not. > > Regards, > > Christer > > > > Sent from my Windows Phone > ------------------------------ > From: Peter Thatcher > Sent: =E2=80=8E17/=E2=80=8E03/=E2=80=8E2016 18:54 > To: Christer Holmberg > Cc: Peter Saint-Andre ; ice@ietf.org > > Subject: Re: [Ice] unfreezing with disparate foundations > > Are you suggesting that we just drop non-muxed RTCP from 5245bis > altogether, or are you suggested that we just leave non-muxed RTCP less > specified (and so it won't work as well, but oh well, use rtcp-mux if you > want things to work well) or something else? > > > > On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> Stupid question: if the assumption is that implementers will move more >> and more towards rtcp-mux, do we need the freezing mechanism to begin wi= th? >> >> Regards, >> >> Christer >> >> From: Ice on behalf of "pthatcher@google.com" < >> pthatcher@google.com> >> Date: Monday 14 March 2016 at 18:35 >> To: "stpeter@stpeter.im" >> Cc: "ice@ietf.org" >> Subject: Re: [Ice] unfreezing with disparate foundations >> >> Correct. >> >> On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre >> wrote: >> >>> On 3/9/16 12:25 PM, Peter Thatcher wrote: >>> >>>> Can we just say that trickle-ice must be used with rtcp-mux? Then we >>>> don't need to worry about this. Non-muxed RTCP is becoming >>>> increasingly rare, especially for WebRTC, where browsers will likely >>>> stop supporting it soon. >>>> >>>> And what endpoint is going to implement trickle-ice but not rtcp-mux? >>>> >>> >>> Not because those two features are necessarily related, but because >>> modern endpoints tend to implement both - correct? >>> >>> Peter >>> >>> >>>> >>>> >>>> >>>> >>>> On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre >>> > wrote: >>>> >>>> At IETF 94 we discussed potential changes to the unfreezing >>>> procedures for trickle when two components have different >>>> foundations. We didn't come up with a solution and redirected >>>> discussion to the list. Does anyone have a proposal to solve this >>>> impasse? >>>> >>>> Peter >>>> >>>> P.S. Here are the relevant notes from the IETF 94 minutes... >>>> >>>> ### >>>> >>>> If one component doesn't have the same foundation as another >>>> component, unfreezing logic doesn't work. >>>> >>>> Jonathan Lennox commented that trickle rules could enforce order, = by >>>> providing components in order and maintain order. >>>> >>>> Emil Ivov: We shouldn't design at the mic. We already agreed that = we >>>> trickle candidates in the order they'd be signaled, but if we want >>>> to change that, I'd be open. >>>> >>>> Jonathan: Trickling earlier doesn't gain anything if those pairs >>>> stay frozen. It just changes where the implementation burden is. >>>> >>>> Emil: Adding new states for components would make things >>>> complicated, so I'd prefer we keep the order. >>>> >>>> Peter (as individual): I think it's more burden on the sender side >>>> and less on the receiver side. It would also slow things down if >>>> signaling is slow. Plus, in WebRTC, we already have to deal with >>>> Javascript handing down remote candidates in the wrong order. >>>> >>>> Jonathan: We need signaling that means there are no candidates. >>>> >>>> Justin: How do we detect this? >>>> >>>> Jonathan: TURN allocation timed out, etc. >>>> >>>> Peter: Can we change the freezing algorithm to be more lax? >>>> >>>> Conclusion: Should take this to the mailing list what to do with >>>> unfreezing when one component doesn't have the same foundation as >>>> another. Signalling "no candidates for this component" is >>>> problematic. Delaying the signalling of other candidates is >>>> problematic. Still looking for a solution. >>>> >>>> ### >>>> >>>> _______________________________________________ >>>> Ice mailing list >>>> Ice@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ice >>>> >>>> >>>> >>> >> > --001a11440f62e8002f052e4289f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 17, 2016 at 10:08 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I was thinking that we wouldn't care if candidates share the same found= ation or not - we deal with all candidates in the same way.
=

For trickle ICE specifically or for 5245bis? = =C2=A0=E2=80=8B

I'm all for simplification and rem= oving things we don't need.=C2=A0 I just want to understand the scope o= f which you are proposing we do so.

=C2=A0

Based on what the browser folks say, browsers will anyway only support rtcp= -mux, no matter if it's mandated by 5245bis or not.

Regards,

Christer



Sent from my Windows Phone
From: Peter Thatcher
Sent: =E2=80= =8E17/=E2=80=8E03/=E2=80=8E2016 18:54
To: Christer Holm= berg
Cc: Peter Saint-Andre; ice@ietf.org

Subject: Re: [I= ce] unfreezing with disparate foundations

Are you suggesting th= at we just drop non-muxed RTCP from 5245bis altogether, or are you suggeste= d that we just leave non-muxed RTCP less specified (and so it won't wor= k as well, but oh well, use rtcp-mux if you want things to work well) or something else?



On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

Stupid question: if the assumption is that implementers will move more= and more towards rtcp-mux, do we need the freezing mechanism to begin with= ?

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Monday 14 March 2016 at 18:35=
To: "stpeter@stpeter.im" <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] unfreezing with = disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-And= re <stpeter@stpeter= .im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?=C2=A0 Then we<= br> don't need to worry about this.=C2=A0 =C2=A0Non-muxed RTCP is becoming<= br> increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because = modern endpoints tend to implement both - correct?

Peter






On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stp= eter@stpeter.im>> wrote:

=C2=A0 =C2=A0 At IETF 94 we discussed potential changes to the unfreezing =C2=A0 =C2=A0 procedures for trickle when two components have different
=C2=A0 =C2=A0 foundations. We didn't come up with a solution and redire= cted
=C2=A0 =C2=A0 discussion to the list. Does anyone have a proposal to solve = this
=C2=A0 =C2=A0 impasse?

=C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 If one component doesn't have the same foundation as anot= her
=C2=A0 =C2=A0 component, unfreezing logic doesn't work.

=C2=A0 =C2=A0 Jonathan Lennox commented that trickle rules could enforce or= der, by
=C2=A0 =C2=A0 providing components in order and maintain order.

=C2=A0 =C2=A0 Emil Ivov: We shouldn't design at the mic. We already agr= eed that we
=C2=A0 =C2=A0 trickle candidates in the order they'd be signaled, but i= f we want
=C2=A0 =C2=A0 to change that, I'd be open.

=C2=A0 =C2=A0 Jonathan: Trickling earlier doesn't gain anything if thos= e pairs
=C2=A0 =C2=A0 stay frozen. It just changes where the implementation burden = is.

=C2=A0 =C2=A0 Emil: Adding new states for components would make things
=C2=A0 =C2=A0 complicated, so I'd prefer we keep the order.

=C2=A0 =C2=A0 Peter (as individual): I think it's more burden on the se= nder side
=C2=A0 =C2=A0 and less on the receiver side. It would also slow things down= if
=C2=A0 =C2=A0 signaling is slow. Plus, in WebRTC, we already have to deal w= ith
=C2=A0 =C2=A0 Javascript handing down remote candidates in the wrong order.=

=C2=A0 =C2=A0 Jonathan: We need signaling that means there are no candidate= s.

=C2=A0 =C2=A0 Justin: How do we detect this?

=C2=A0 =C2=A0 Jonathan: TURN allocation timed out, etc.

=C2=A0 =C2=A0 Peter: Can we change the freezing algorithm to be more lax?
=C2=A0 =C2=A0 Conclusion: Should take this to the mailing list what to do w= ith
=C2=A0 =C2=A0 unfreezing when one component doesn't have the same found= ation as
=C2=A0 =C2=A0 another. Signalling "no candidates for this component&qu= ot; is
=C2=A0 =C2=A0 problematic. Delaying the signalling of other candidates is =C2=A0 =C2=A0 problematic. Still looking for a solution.

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Ice mailing list
=C2=A0 =C2=A0 Ice@ietf.or= g <mailto:Ice@ietf= .org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ice






--001a11440f62e8002f052e4289f8-- From nobody Thu Mar 17 12:22:18 2016 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 C08DF12D663 for ; Thu, 17 Mar 2016 12:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Gk6MbHit3qoB for ; Thu, 17 Mar 2016 12:22:14 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E4C12D79A for ; Thu, 17 Mar 2016 12:22:14 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-a6-56eb03e4c849 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 17.F1.16394.4E30BE65; Thu, 17 Mar 2016 20:22:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 20:22:11 +0100 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [Ice] unfreezing with disparate foundations Thread-Index: AQHRbfN5jcf89bd2VEi7ZKjq2k0vOJ9RhiqAgAOhEwCABAstAIAEu5oAgAAAZoCAABUQBIAAABwAgAAktUA= Date: Thu, 17 Mar 2016 19:22:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdS/cJ8+swgxsdUhbfLtRaXFv+mtXi 2J5+ZgdmjwWbSj2WLPnJ5DF3zwvmAOYoLpuU1JzMstQifbsErowzvy6zFuzSq1i0q7iBcYFu FyMnh4SAicS6CY/YIGwxiQv31oPZQgKHGSWWtWpB2EsYJW7tU+pi5OBgE7CQ6P6nDRIWEdCU mDy5mRXEZhbwlHh8fBcTiC0MVLLiwX52iBpLibtTvjFB2EkST6ZvABvPIqAqcfDQcjCbV8BX Yl7DHcYuRi6gVbeYJZYt7ARLcAoEStzavg9sECPQbd9PrWGCWCYucevJfCaImwUkluw5zwxh i0q8fPyPFcJWkmhc8oQV5GZmoEPX79KHaFWUmNL9kB1ir6DEyZlPWCYwis1CMnUWQscsJB2z kHQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYRwe3/FbdwXj5jeMhRgEORiUe3oKn L8OEWBPLiitzDzFKcDArifDKf3oVJsSbklhZlVqUH19UmpNafIhRmoNFSZyX9dPlMCGB9MSS 1OzU1ILUIpgsEwenVAOjS7OZ4YSl/knzf/47s8jyK6e8YN8i7jeM3iJ3fcvfeFQ9etOyeB2H U8P+HRx344KDj116y/ZSTKQyzynmVYzclYr/aTscbzXua/2ddoFpeQWL742Suknnzlesz/IP 7muZcuVNqa7STY4fkx9cminDEnXppt5HxoXVyS0z/3xrZBdXDL/6Uu+fEktxRqKhFnNRcSIA WBUzY58CAAA= Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 19:22:17 -0000 SGksDQoNCj4+IEkgd2FzIHRoaW5raW5nIHRoYXQgd2Ugd291bGRuJ3QgY2FyZSBpZiBjYW5kaWRh dGVzIHNoYXJlIHRoZSBzYW1lIGZvdW5kYXRpb24gb3Igbm90IC0gd2UgZGVhbCB3aXRoIGFsbCBj YW5kaWRhdGVzIGluIHRoZSBzYW1lIHdheS4NCj4NCj4gRm9yIHRyaWNrbGUgSUNFIHNwZWNpZmlj YWxseSBvciBmb3IgNTI0NWJpcz8gwqDigIsNCj4NCj4gSSdtIGFsbCBmb3Igc2ltcGxpZmljYXRp b24gYW5kIHJlbW92aW5nIHRoaW5ncyB3ZSBkb24ndCBuZWVkLsKgIEkganVzdCB3YW50IHRvIHVu ZGVyc3RhbmQgdGhlIHNjb3BlIG9mIHdoaWNoIHlvdSBhcmUgcHJvcG9zaW5nIHdlIGRvIHNvLg0K DQpJIHdhcyB0aGlua2luZyA1MjQ1YmlzOiByZW1vdmUgZXZlcnl0aGluZyB0aGF0IHRhbGtzIGFi b3V0IGZyb3plbiBjYW5kaWRhdGVzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoN ClNlbnQgZnJvbSBteSBXaW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBQZXRlciBUaGF0Y2hlcg0KU2VudDog4oCOMTcv4oCOMDMv4oCO MjAxNiAxODo1NA0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogUGV0ZXIgU2FpbnQtQW5kcmU7 IGljZUBpZXRmLm9yZw0KDQpTdWJqZWN0OiBSZTogW0ljZV0gdW5mcmVlemluZyB3aXRoIGRpc3Bh cmF0ZSBmb3VuZGF0aW9ucw0KQXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgd2UganVzdCBkcm9wIG5v bi1tdXhlZCBSVENQIGZyb20gNTI0NWJpcyBhbHRvZ2V0aGVyLCBvciBhcmUgeW91IHN1Z2dlc3Rl ZCB0aGF0IHdlIGp1c3QgbGVhdmUgbm9uLW11eGVkIFJUQ1AgbGVzcyBzcGVjaWZpZWQgKGFuZCBz byBpdCB3b24ndCB3b3JrIGFzIHdlbGwsIGJ1dCBvaCB3ZWxsLCB1c2UgcnRjcC1tdXggaWYgeW91 IHdhbnQgdGhpbmdzIHRvIHdvcmsgd2VsbCkgb3Igc29tZXRoaW5nIGVsc2U/DQoNCg0KDQpPbiBU aHUsIE1hciAxNywgMjAxNiBhdCA3OjUyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCkhpLA0KDQpTdHVwaWQgcXVlc3Rpb246IGlm IHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgaW1wbGVtZW50ZXJzIHdpbGwgbW92ZSBtb3JlIGFuZCBt b3JlIHRvd2FyZHMgcnRjcC1tdXgsIGRvIHdlIG5lZWQgdGhlIGZyZWV6aW5nIG1lY2hhbmlzbSB0 byBiZWdpbiB3aXRoPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBJY2UgPGljZS1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgInB0aGF0Y2hlckBnb29nbGUuY29tIiA8cHRo YXRjaGVyQGdvb2dsZS5jb20+DQpEYXRlOiBNb25kYXkgMTQgTWFyY2ggMjAxNiBhdCAxODozNQ0K VG86ICJzdHBldGVyQHN0cGV0ZXIuaW0iIDxzdHBldGVyQHN0cGV0ZXIuaW0+DQpDYzogImljZUBp ZXRmLm9yZyIgPGljZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWNlXSB1bmZyZWV6aW5nIHdp dGggZGlzcGFyYXRlIGZvdW5kYXRpb25zDQoNCkNvcnJlY3QuDQoNCk9uIEZyaSwgTWFyIDExLCAy MDE2IGF0IDY6NTAgUE0sIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+IHdy b3RlOg0KT24gMy85LzE2IDEyOjI1IFBNLCBQZXRlciBUaGF0Y2hlciB3cm90ZToNCkNhbiB3ZSBq dXN0IHNheSB0aGF0IHRyaWNrbGUtaWNlIG11c3QgYmUgdXNlZCB3aXRoIHJ0Y3AtbXV4P8KgIFRo ZW4gd2UNCmRvbid0IG5lZWQgdG8gd29ycnkgYWJvdXQgdGhpcy7CoCDCoE5vbi1tdXhlZCBSVENQ IGlzIGJlY29taW5nDQppbmNyZWFzaW5nbHkgcmFyZSwgZXNwZWNpYWxseSBmb3IgV2ViUlRDLCB3 aGVyZSBicm93c2VycyB3aWxsIGxpa2VseQ0Kc3RvcCBzdXBwb3J0aW5nIGl0IHNvb24uDQoNCkFu ZCB3aGF0IGVuZHBvaW50IGlzIGdvaW5nIHRvIGltcGxlbWVudCB0cmlja2xlLWljZSBidXQgbm90 IHJ0Y3AtbXV4Pw0KDQpOb3QgYmVjYXVzZSB0aG9zZSB0d28gZmVhdHVyZXMgYXJlIG5lY2Vzc2Fy aWx5IHJlbGF0ZWQsIGJ1dCBiZWNhdXNlIG1vZGVybiBlbmRwb2ludHMgdGVuZCB0byBpbXBsZW1l bnQgYm90aCAtIGNvcnJlY3Q/DQoNClBldGVyDQoNCg0KDQoNCg0KT24gTW9uLCBGZWIgMjIsIDIw MTYgYXQgODozNCBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJAc3RwZXRlci5pbQ0KPG1h aWx0bzpzdHBldGVyQHN0cGV0ZXIuaW0+PiB3cm90ZToNCg0KwqAgwqAgQXQgSUVURiA5NCB3ZSBk aXNjdXNzZWQgcG90ZW50aWFsIGNoYW5nZXMgdG8gdGhlIHVuZnJlZXppbmcNCsKgIMKgIHByb2Nl ZHVyZXMgZm9yIHRyaWNrbGUgd2hlbiB0d28gY29tcG9uZW50cyBoYXZlIGRpZmZlcmVudA0KwqAg wqAgZm91bmRhdGlvbnMuIFdlIGRpZG4ndCBjb21lIHVwIHdpdGggYSBzb2x1dGlvbiBhbmQgcmVk aXJlY3RlZA0KwqAgwqAgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdC4gRG9lcyBhbnlvbmUgaGF2ZSBh IHByb3Bvc2FsIHRvIHNvbHZlIHRoaXMNCsKgIMKgIGltcGFzc2U/DQoNCsKgIMKgIFBldGVyDQoN CsKgIMKgIFAuUy4gSGVyZSBhcmUgdGhlIHJlbGV2YW50IG5vdGVzIGZyb20gdGhlIElFVEYgOTQg bWludXRlcy4uLg0KDQrCoCDCoCAjIyMNCg0KwqAgwqAgSWYgb25lIGNvbXBvbmVudCBkb2Vzbid0 IGhhdmUgdGhlIHNhbWUgZm91bmRhdGlvbiBhcyBhbm90aGVyDQrCoCDCoCBjb21wb25lbnQsIHVu ZnJlZXppbmcgbG9naWMgZG9lc24ndCB3b3JrLg0KDQrCoCDCoCBKb25hdGhhbiBMZW5ub3ggY29t bWVudGVkIHRoYXQgdHJpY2tsZSBydWxlcyBjb3VsZCBlbmZvcmNlIG9yZGVyLCBieQ0KwqAgwqAg cHJvdmlkaW5nIGNvbXBvbmVudHMgaW4gb3JkZXIgYW5kIG1haW50YWluIG9yZGVyLg0KDQrCoCDC oCBFbWlsIEl2b3Y6IFdlIHNob3VsZG4ndCBkZXNpZ24gYXQgdGhlIG1pYy4gV2UgYWxyZWFkeSBh Z3JlZWQgdGhhdCB3ZQ0KwqAgwqAgdHJpY2tsZSBjYW5kaWRhdGVzIGluIHRoZSBvcmRlciB0aGV5 J2QgYmUgc2lnbmFsZWQsIGJ1dCBpZiB3ZSB3YW50DQrCoCDCoCB0byBjaGFuZ2UgdGhhdCwgSSdk IGJlIG9wZW4uDQoNCsKgIMKgIEpvbmF0aGFuOiBUcmlja2xpbmcgZWFybGllciBkb2Vzbid0IGdh aW4gYW55dGhpbmcgaWYgdGhvc2UgcGFpcnMNCsKgIMKgIHN0YXkgZnJvemVuLiBJdCBqdXN0IGNo YW5nZXMgd2hlcmUgdGhlIGltcGxlbWVudGF0aW9uIGJ1cmRlbiBpcy4NCg0KwqAgwqAgRW1pbDog QWRkaW5nIG5ldyBzdGF0ZXMgZm9yIGNvbXBvbmVudHMgd291bGQgbWFrZSB0aGluZ3MNCsKgIMKg IGNvbXBsaWNhdGVkLCBzbyBJJ2QgcHJlZmVyIHdlIGtlZXAgdGhlIG9yZGVyLg0KDQrCoCDCoCBQ ZXRlciAoYXMgaW5kaXZpZHVhbCk6IEkgdGhpbmsgaXQncyBtb3JlIGJ1cmRlbiBvbiB0aGUgc2Vu ZGVyIHNpZGUNCsKgIMKgIGFuZCBsZXNzIG9uIHRoZSByZWNlaXZlciBzaWRlLiBJdCB3b3VsZCBh bHNvIHNsb3cgdGhpbmdzIGRvd24gaWYNCsKgIMKgIHNpZ25hbGluZyBpcyBzbG93LiBQbHVzLCBp biBXZWJSVEMsIHdlIGFscmVhZHkgaGF2ZSB0byBkZWFsIHdpdGgNCsKgIMKgIEphdmFzY3JpcHQg aGFuZGluZyBkb3duIHJlbW90ZSBjYW5kaWRhdGVzIGluIHRoZSB3cm9uZyBvcmRlci4NCg0KwqAg wqAgSm9uYXRoYW46IFdlIG5lZWQgc2lnbmFsaW5nIHRoYXQgbWVhbnMgdGhlcmUgYXJlIG5vIGNh bmRpZGF0ZXMuDQoNCsKgIMKgIEp1c3RpbjogSG93IGRvIHdlIGRldGVjdCB0aGlzPw0KDQrCoCDC oCBKb25hdGhhbjogVFVSTiBhbGxvY2F0aW9uIHRpbWVkIG91dCwgZXRjLg0KDQrCoCDCoCBQZXRl cjogQ2FuIHdlIGNoYW5nZSB0aGUgZnJlZXppbmcgYWxnb3JpdGhtIHRvIGJlIG1vcmUgbGF4Pw0K DQrCoCDCoCBDb25jbHVzaW9uOiBTaG91bGQgdGFrZSB0aGlzIHRvIHRoZSBtYWlsaW5nIGxpc3Qg d2hhdCB0byBkbyB3aXRoDQrCoCDCoCB1bmZyZWV6aW5nIHdoZW4gb25lIGNvbXBvbmVudCBkb2Vz bid0IGhhdmUgdGhlIHNhbWUgZm91bmRhdGlvbiBhcw0KwqAgwqAgYW5vdGhlci4gU2lnbmFsbGlu ZyAibm8gY2FuZGlkYXRlcyBmb3IgdGhpcyBjb21wb25lbnQiIGlzDQrCoCDCoCBwcm9ibGVtYXRp Yy4gRGVsYXlpbmcgdGhlIHNpZ25hbGxpbmcgb2Ygb3RoZXIgY2FuZGlkYXRlcyBpcw0KwqAgwqAg cHJvYmxlbWF0aWMuIFN0aWxsIGxvb2tpbmcgZm9yIGEgc29sdXRpb24uDQoNCsKgIMKgICMjIw0K DQrCoCDCoCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K wqAgwqAgSWNlIG1haWxpbmcgbGlzdA0KwqAgwqAgSWNlQGlldGYub3JnIDxtYWlsdG86SWNlQGll dGYub3JnPg0KwqAgwqAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UN Cg0KDQoNCg0KDQo= From nobody Thu Mar 17 12:33:43 2016 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 B439E12D734 for ; Thu, 17 Mar 2016 12:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Z7s0XG9eeuhO for ; Thu, 17 Mar 2016 12:33:39 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 C4FF712D644 for ; Thu, 17 Mar 2016 12:33:38 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e185so115355356vkb.1 for ; Thu, 17 Mar 2016 12:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TvRxRVBPdZSFyqXh3cbdXlxKFoKKTlCHC09tFug139Y=; b=Q1zWutAoR5dgNPprn1y4kW9UmbPfOCUGj5W4lWnDDld+SepaMADzYWMO818BO7HvrV nWk230+jYYMW5vr09JwYrr9tDHvOR3SmUXoFyVmEhkdb17j+lflc1z9cGAw6s2WiaGwI Yx8vGh6260XZ7+6LYCBrulziAWZYjjrS/HZS9S/BEDf8BcMRJVpyn/U79GkVnvD5wIf/ yavVMySZSZDhkh/xKBWyPCq18yPruFT4gMgqnC1D4xOSA65BtNKgctXVevgFE0lFzW+P hjynMaU1he8DZFkktL5bSeDfpGo/bsGgG939Rw05Qse8FEnwFhIZLAZImAjyPxzc0Oo9 5oMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TvRxRVBPdZSFyqXh3cbdXlxKFoKKTlCHC09tFug139Y=; b=WolvAyC+a2jNh1ial7TJpQiGNne2+2vRe1UcBmgiRq6I5Ho5SdLIKKrI51syCbuhqT DRyI0zEiIL4bdihA2R0RNMxLRCbh9oOwnc38yQky5Q+rl8ND3cGWHwU7D7UVCiKyENlk lWusQGft1uhJTZvUcYv56GwQtpEU39doLLWsMO+NW2U6/HsjvS4invfN+E44QbrPIAn7 vGV0Ha2MSw5c13qURt4tmSq5SpJiJRsncz32CvBBSf3R7WWbgKTEk5LxUzD7CQQLK2oR rW5g7awl8YKz/EQs33bqJGA66p3X5ikslZM5p6aaKaxlDORIT/30kQ2stHcWdYLova1K w9qQ== X-Gm-Message-State: AD7BkJKhrjoOa/ZSoW32vYaiE3NDL+h8RhkGLWzniuyk7HGx81+lDEA4U4uhq/bVrmtVLsb1T6PuNx2XOdJ3XnRw X-Received: by 10.31.58.193 with SMTP id h184mr13363377vka.111.1458243217769; Thu, 17 Mar 2016 12:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 17 Mar 2016 12:32:58 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> References: <56CBE148.9050100@stpeter.im> <56E383FC.6090504@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37EBF6CD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EBF9E2@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Thu, 17 Mar 2016 12:32:58 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1143ff70fe1404052e43b4e1 Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [Ice] unfreezing with disparate foundations X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 19:33:41 -0000 --001a1143ff70fe1404052e43b4e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> I was thinking that we wouldn't care if candidates share the same > foundation or not - we deal with all candidates in the same way. > > > > For trickle ICE specifically or for 5245bis? =E2=80=8B > > > > I'm all for simplification and removing things we don't need. I just > want to understand the scope of which you are proposing we do so. > > I was thinking 5245bis: remove everything that talks about frozen > candidates. > > Sounds good to me, if we feel like the downsides of not having freezing are such that we can simply say "if you care about these downsides, use rtcp-mux". I'd like to hear from everyone else if feels the same.=E2=80=8B =E2=80=8B > Regards, > > Christer > > > > > > Sent from my Windows Phone > ________________________________________ > From: Peter Thatcher > Sent: =E2=80=8E17/=E2=80=8E03/=E2=80=8E2016 18:54 > To: Christer Holmberg > Cc: Peter Saint-Andre; ice@ietf.org > > Subject: Re: [Ice] unfreezing with disparate foundations > Are you suggesting that we just drop non-muxed RTCP from 5245bis > altogether, or are you suggested that we just leave non-muxed RTCP less > specified (and so it won't work as well, but oh well, use rtcp-mux if you > want things to work well) or something else? > > > > On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > Hi, > > Stupid question: if the assumption is that implementers will move more an= d > more towards rtcp-mux, do we need the freezing mechanism to begin with? > > Regards, > > Christer > > From: Ice on behalf of "pthatcher@google.com" < > pthatcher@google.com> > Date: Monday 14 March 2016 at 18:35 > To: "stpeter@stpeter.im" > Cc: "ice@ietf.org" > Subject: Re: [Ice] unfreezing with disparate foundations > > Correct. > > On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre > wrote: > On 3/9/16 12:25 PM, Peter Thatcher wrote: > Can we just say that trickle-ice must be used with rtcp-mux? Then we > don't need to worry about this. Non-muxed RTCP is becoming > increasingly rare, especially for WebRTC, where browsers will likely > stop supporting it soon. > > And what endpoint is going to implement trickle-ice but not rtcp-mux? > > Not because those two features are necessarily related, but because moder= n > endpoints tend to implement both - correct? > > Peter > > > > > > On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre > wrote: > > At IETF 94 we discussed potential changes to the unfreezing > procedures for trickle when two components have different > foundations. We didn't come up with a solution and redirected > discussion to the list. Does anyone have a proposal to solve this > impasse? > > Peter > > P.S. Here are the relevant notes from the IETF 94 minutes... > > ### > > If one component doesn't have the same foundation as another > component, unfreezing logic doesn't work. > > Jonathan Lennox commented that trickle rules could enforce order, by > providing components in order and maintain order. > > Emil Ivov: We shouldn't design at the mic. We already agreed that we > trickle candidates in the order they'd be signaled, but if we want > to change that, I'd be open. > > Jonathan: Trickling earlier doesn't gain anything if those pairs > stay frozen. It just changes where the implementation burden is. > > Emil: Adding new states for components would make things > complicated, so I'd prefer we keep the order. > > Peter (as individual): I think it's more burden on the sender side > and less on the receiver side. It would also slow things down if > signaling is slow. Plus, in WebRTC, we already have to deal with > Javascript handing down remote candidates in the wrong order. > > Jonathan: We need signaling that means there are no candidates. > > Justin: How do we detect this? > > Jonathan: TURN allocation timed out, etc. > > Peter: Can we change the freezing algorithm to be more lax? > > Conclusion: Should take this to the mailing list what to do with > unfreezing when one component doesn't have the same foundation as > another. Signalling "no candidates for this component" is > problematic. Delaying the signalling of other candidates is > problematic. Still looking for a solution. > > ### > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > > > > --001a1143ff70fe1404052e43b4e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 17, 2016 at 12:22 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>> I was thinking that we wouldn't care if candidates share the s= ame foundation or not - we deal with all candidates in the same way.
>
> For trickle ICE specifically or for 5245bis? =C2=A0=E2=80=8B
>
> I'm all for simplification and removing things we don't need.= =C2=A0 I just want to understand the scope of which you are proposing we do= so.

I was thinking 5245bis: remove everything that talks about frozen ca= ndidates.


<= /div>
Sounds good to me, if we feel like the downside= s of not having freezing are such that we can simply say "if you care = about these downsides, use rtcp-mux".=C2=A0 I'd like to hear from = everyone else if feels the same.=E2=80=8B
=E2=80=8B

= =C2=A0
Regards,

Christer





Sent from my Windows Phone
________________________________________
From: Peter Thatcher
Sent: =E2=80=8E17/=E2=80=8E03/=E2=80=8E2016 18:54
To: Christer Holmberg
Cc: Peter Saint-Andre; ice@ietf.org

Subject: Re: [Ice] unfreezing with disparate foundations
Are you suggesting that we just drop non-muxed RTCP from 5245bis altogether= , or are you suggested that we just leave non-muxed RTCP less specified (an= d so it won't work as well, but oh well, use rtcp-mux if you want thing= s to work well) or something else?



On Thu, Mar 17, 2016 at 7:52 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:=
Hi,

Stupid question: if the assumption is that implementers will move more and = more towards rtcp-mux, do we need the freezing mechanism to begin with?

Regards,

Christer

From: Ice <ice-bounces@ietf.org<= /a>> on behalf of "pthatche= r@google.com" <pthatche= r@google.com>
Date: Monday 14 March 2016 at 18:35
To: "stpeter@stpeter.im"= ; <stpeter@stpeter.im>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] unfreezing with disparate foundations

Correct.

On Fri, Mar 11, 2016 at 6:50 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
On 3/9/16 12:25 PM, Peter Thatcher wrote:
Can we just say that trickle-ice must be used with rtcp-mux?=C2=A0 Then we<= br> don't need to worry about this.=C2=A0 =C2=A0Non-muxed RTCP is becoming<= br> increasingly rare, especially for WebRTC, where browsers will likely
stop supporting it soon.

And what endpoint is going to implement trickle-ice but not rtcp-mux?

Not because those two features are necessarily related, but because modern = endpoints tend to implement both - correct?

Peter





On Mon, Feb 22, 2016 at 8:34 PM, Peter Saint-Andre <stpeter@stpeter.im
<mailto:stpeter@stpeter.im>= > wrote:

=C2=A0 =C2=A0 At IETF 94 we discussed potential changes to the unfreezing =C2=A0 =C2=A0 procedures for trickle when two components have different
=C2=A0 =C2=A0 foundations. We didn't come up with a solution and redire= cted
=C2=A0 =C2=A0 discussion to the list. Does anyone have a proposal to solve = this
=C2=A0 =C2=A0 impasse?

=C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 P.S. Here are the relevant notes from the IETF 94 minutes...<= br>
=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 If one component doesn't have the same foundation as anot= her
=C2=A0 =C2=A0 component, unfreezing logic doesn't work.

=C2=A0 =C2=A0 Jonathan Lennox commented that trickle rules could enforce or= der, by
=C2=A0 =C2=A0 providing components in order and maintain order.

=C2=A0 =C2=A0 Emil Ivov: We shouldn't design at the mic. We already agr= eed that we
=C2=A0 =C2=A0 trickle candidates in the order they'd be signaled, but i= f we want
=C2=A0 =C2=A0 to change that, I'd be open.

=C2=A0 =C2=A0 Jonathan: Trickling earlier doesn't gain anything if thos= e pairs
=C2=A0 =C2=A0 stay frozen. It just changes where the implementation burden = is.

=C2=A0 =C2=A0 Emil: Adding new states for components would make things
=C2=A0 =C2=A0 complicated, so I'd prefer we keep the order.

=C2=A0 =C2=A0 Peter (as individual): I think it's more burden on the se= nder side
=C2=A0 =C2=A0 and less on the receiver side. It would also slow things down= if
=C2=A0 =C2=A0 signaling is slow. Plus, in WebRTC, we already have to deal w= ith
=C2=A0 =C2=A0 Javascript handing down remote candidates in the wrong order.=

=C2=A0 =C2=A0 Jonathan: We need signaling that means there are no candidate= s.

=C2=A0 =C2=A0 Justin: How do we detect this?

=C2=A0 =C2=A0 Jonathan: TURN allocation timed out, etc.

=C2=A0 =C2=A0 Peter: Can we change the freezing algorithm to be more lax?
=C2=A0 =C2=A0 Conclusion: Should take this to the mailing list what to do w= ith
=C2=A0 =C2=A0 unfreezing when one component doesn't have the same found= ation as
=C2=A0 =C2=A0 another. Signalling "no candidates for this component&qu= ot; is
=C2=A0 =C2=A0 problematic. Delaying the signalling of other candidates is =C2=A0 =C2=A0 problematic. Still looking for a solution.

=C2=A0 =C2=A0 ###

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Ice mailing list
=C2=A0 =C2=A0 Ice@ietf.org <mailto:<= a href=3D"mailto:Ice@ietf.org">Ice@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ice=






--001a1143ff70fe1404052e43b4e1-- From nobody Thu Mar 17 22:16:44 2016 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 6D64D12D619 for ; Thu, 17 Mar 2016 22:16: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 RKIvxzVy0eiX for ; Thu, 17 Mar 2016 22:16:41 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 14EB112D5AF for ; Thu, 17 Mar 2016 22:16:41 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id e185so128618813vkb.1 for ; Thu, 17 Mar 2016 22:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=uottE58yc98OUC0lx4NFWR4/GyrR1J/uGU0fLcDvcRc=; b=Opy4fEu1WAk5GQJg6evFAxmd/Rhd5kkuhbySTzZ5YXyRPLpGprkbVoJ5pRLPue5NcW D/1I2gK4zkd9Whgq3/OT3lqX0YZq+8PSPI+2ji0yRmiUAV6qmMaIu0kMWKKtkLpIetSf IUm8w2thtK0iZz7SkagdhEIf3zlPqd4YgrdlJxvxc2p8J3PE35zbXScpduhQbD4LhJiK SmWnJau3yY6Sj5ImruHAK9Z2H4zMPeMeNSAtFIpUBBp9NvjPDf2bTE9j4/GardTDI90T dyxboJJaBTacRRxIyp/mhWa0Xp4lAnKIFcJ+A0Lu+iBEv1lA92O8Bw9ysxQwFekd6rCB TmEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uottE58yc98OUC0lx4NFWR4/GyrR1J/uGU0fLcDvcRc=; b=LZ7TiR6vMTc+uWnKuIGNPSvYPDiTH3yZSmCcu9HbkATPbvG/zsvwbywNhlTUzroyzY 4+np0qaSLNc65vSnhpxp1gsizksOUiY4CUZXqVTVV5w2WRocPdpGjRu7qlY55eKA2Ic/ yjril6+7gM7hpy/UblrUJ+/HEA3qp7PxR6JN1TWY94NiaIHnLKeKJWPk3PQKKb+8T/44 9gJcr2Lal6G3xyto374v9GDNcizVlZZq1tECifaIwjdKmmWaCN4w2xT3NjVSS9lkKhMM YitCd2JJFjf+YrYKpzFcHhgCjAC7oN0IgifKtKQnOvJUDREDiZWuuDktIpMRdvqfvasD 2Agg== X-Gm-Message-State: AD7BkJJbF8fwywb41RQ+5G0Tfw8WIjwKOlHK4F5NYVXsWkdkwz9xGQX2lCTSaIfXSMENGxxwD7eD8p+uePAec7Pu X-Received: by 10.31.8.68 with SMTP id 65mr15183367vki.150.1458278199970; Thu, 17 Mar 2016 22:16:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 17 Mar 2016 22:16:00 -0700 (PDT) From: Peter Thatcher Date: Thu, 17 Mar 2016 22:16:00 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11440f62180dce052e4bda34 Archived-At: Subject: [Ice] Some thoughts on Ta value for 5245bis X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 05:16:43 -0000 --001a11440f62180dce052e4bda34 Content-Type: text/plain; charset=UTF-8 (As an individual, not a chair) The big question for a long time for 5245bis has been: what's the Ta value? Here are some of my thoughts/proposals on what we can do: 1. Since the value can be negotiated, we're really defining two different things: a minimum and a default. 2. For both minimum and default, let's drop the distinction between RTP and non-RTP and have the values for both. Many endpoints have, for a long time, been ignoring the formula/value in 5245 anyway (all the WebRTC data channels, for example, I believe). 3. I propose a minimum of 5ms. For two reasons: first, there's really no reason to make it less than 5ms, since even with 100 candidate pairs, one could check all of them in less than 500ms, meaning going lower than 5ms doesn't help much (and typically you have much fewer than 100 candidate pairs. Second, from the measurements that we have, it appears that it's safe to go down to 5ms, except for concerns over bandwidth. 4. I propose a default of 50ms. It's a decently low value that we know is safe because there are lots of endpoints that are using a value at least that low and it seems to be working well. There isn't any reason to make it bigger, and there isn't a strong reason (yes) to make it lower. For typical situations with say, 10-20 candidate pairs, that's still only 500-1000ms to do a full round of checks. If that's still not fast enough, endpoints can alway negotiate lower. And, we can update the value later if future measurements indicate it's safe. 5. I propose that we continue doing measurements, and if we find that a default lower than 50ms is safe, then publish a new draft saying "the new default is Xms". But 5245bis is still valuable even with a value of "only" 50ms. As for measurements, in Chrome we plan to roll out lower Ta values and see the impact they have (so far it's good, but we'd to make the STUN messages smaller before rolling out more widely). We've also provided a command line tool that allows anyone to test even a Ta == 1 and 350 bindings (or more!) and see what percentage succeed (tool source here: https://chromium.googlesource.com/external/webrtc/+/master/webrtc/p2p/stunprober/; we can also provide some binaries if that's more convenient). 6. I think a rule bandwidth-limiting rule such as "should not send more than 40kbps" might make sense, but obviously implementations would be free to to above that if they have some reasonable expectation that the actual bandwidth available is higher. 7. I propose we investigate how to reduce the size of initial ICE checks to allow more checks without worrying about bandwidth limitations. For example, perhaps by making 4-byte ufrags recommended, or by sending many fewer STUN attributes in the initial ICE check and then only sending the large attributes later once a candidate pair is know to work. OK, that's probably enough about Ta for one email :). --001a11440f62180dce052e4bda34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(As an individual, not a chair)

Th= e big question for a long time for 5245bis has been: what's the Ta valu= e? =C2=A0

Here are some of my thoughts/proposals on wh= at we can do:


1.=C2=A0 Since the value ca= n be negotiated, we're really defining two different things: a minimum = and a default. =C2=A0

2.=C2=A0 For both minimum and d= efault, let's drop the distinction between RTP and non-RTP and have the= values for both.=C2=A0 Many endpoints have, for a long time, been ignoring= the formula/value in 5245 anyway (all the WebRTC data channels, for exampl= e, I believe).

3.=C2=A0 I propose a minimum of 5ms. = =C2=A0 For two reasons: =C2=A0first, there's really no reason to make i= t less than 5ms, since even with 100 candidate pairs, one could check all o= f them in less than 500ms, meaning going lower than 5ms doesn't help mu= ch (and typically you have much fewer than 100 candidate pairs.=C2=A0 Secon= d, from the measurements that we have, it appears that it's safe to go = down to 5ms, except for concerns over bandwidth.

4.=C2= =A0 I propose a default of 50ms.=C2=A0 It's a decently low value that w= e know is safe because there are lots of endpoints that are using a value a= t least that low and it seems to be working well.=C2=A0 There isn't any= reason to make it bigger, and there isn't a strong reason (yes) to mak= e it lower.=C2=A0 For typical situations with say, 10-20 candidate pairs, t= hat's still only 500-1000ms to do a full round of checks.=C2=A0 If that= 's still not fast enough, endpoints can alway negotiate lower.=C2=A0 An= d, we can update the value later if future measurements indicate it's s= afe.

5.=C2=A0 I propose that we continue doing measure= ments, and if we find that a default lower than 50ms is safe, then publish = a new draft saying "the new default is Xms".=C2=A0 But 5245bis is= still valuable even with a value of "only" 50ms.

As for measurements, in Chrome we plan t= o roll out lower Ta values and see the impact they have (so far it's go= od, but we'd to make the STUN messages smaller before rolling out more = widely).=C2=A0 We've also provided a command line tool that allows anyo= ne to test even a Ta =3D=3D 1 and 350 bindings (or more!) and see what perc= entage succeed (tool source here:=C2=A0https://chromium.= googlesource.com/external/webrtc/+/master/webrtc/p2p/stunprober/; we ca= n also provide some binaries if that's more convenient). =C2=A0

6.=C2=A0 I think a rule bandwidth-limiting rule s= uch as "should not send more than 40kbps" might make sense, but o= bviously implementations would be free to to above that if they have some r= easonable expectation that the actual bandwidth available is higher. =C2=A0=

7.=C2=A0 I propose we investigate how to reduce the s= ize of initial ICE checks to allow more checks without worrying about bandw= idth limitations.=C2=A0 For example, perhaps by making 4-byte ufrags recomm= ended, or by sending many fewer STUN attributes in the initial ICE check an= d then only sending the large attributes later once a candidate pair is kno= w to work.


OK, that's probably enough= about Ta for one email :).



--001a11440f62180dce052e4bda34-- From nobody Thu Mar 17 22:21:18 2016 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 AC09E12DA08 for ; Thu, 17 Mar 2016 22:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 B0gT4hzM3qGR for ; Thu, 17 Mar 2016 22:21:15 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 9F12F12D7CB for ; Thu, 17 Mar 2016 22:21:15 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id k1so129099677vkb.0 for ; Thu, 17 Mar 2016 22:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=B+KsTz3U4ujriSJCQFvRL4R1vp77ODv+RuNiWTjYofM=; b=HY3jr6pfQx8IAHROn9vAWQduhSYC8/NY7DjGaA0mjtern+5u5qFlYEb0GJYEf/7CcX bdIXsSLuQXmJkGQDYBEtKPHwXUkNclxieDY6cFD5PEv8mt0Hy52CVkE+F5lxVzspwF/L XmKh+aSpLatiU9JVIYmnx1M5VzJrG0m2hhssnEs9C5FUuz9xldhKEtbSxWq0rbDv/Tp7 QbrOd2tU3luYCeUQOveQTKqyTmfwI+m7JHoC5aU32U1RRSOgu7QMMfDHvkuMlVHPh5b7 DT9cs0GRZvi32BT4LpYxCO45WlsRK0GsW4fQf8Unbfj+obdbp6OBc20CzzBeFwyrh/Gn DHyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=B+KsTz3U4ujriSJCQFvRL4R1vp77ODv+RuNiWTjYofM=; b=jfwOXOe/kbBhJLlyFn+2RLNl2KGzvfTkXMoW2b1Cndz4Lph4g1vELrgEvFH+/irPtG 39JiVLd+E9gisLYOGevdAtb5rErYoxXk9Zd4U+C+8jtRyPYqaYf6iZQLQOdaIRjKnHmr ajtuGARjbeWD9IAUoTE8JPNh9BLqtwqyUQnlGzIG+1QMQmna7NaF9SEvjUUXOld/u7cl 0f4UL05qc2Hl2Kq+uOY4oedz3JdOyg6085QxqNfpK8ho9T2W85QAv7GufJZLmtqYhBoH YwMq3dBK4H5VuPRQ4eGmndWW53IyLVmPwMEMlpOi0TlHcggib0bX0rUxcOXtZIF+1Uoa bFvw== X-Gm-Message-State: AD7BkJKucMKl7snTrtrHKgPtTU27+0VksqoZ8swZORWXGEQ5Ti3bt9RiwSgQK2KWmaUOQmVdCxtso0T4qOxroRAM X-Received: by 10.31.8.68 with SMTP id 65mr15194848vki.150.1458278474688; Thu, 17 Mar 2016 22:21:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 17 Mar 2016 22:20:35 -0700 (PDT) From: Peter Thatcher Date: Thu, 17 Mar 2016 22:20:35 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11440f6277e958052e4bea4a Archived-At: Subject: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 05:21:17 -0000 --001a11440f6277e958052e4bea4a Content-Type: text/plain; charset=UTF-8 (As an individual, not a chair) Earlier, we had some discussion around adding the ufrag to the trickled candidate so that when one receives the a trickled candidate after an ICE restart, it's clear if the candidate applies to the ICE ufrag/pwd from before or after the ICE restart. I have a few thoughts/questions about this: 1. We saw applications where this was a real-world issue. 2. We implemented the addition of the ufrag to candidates in Chrome, and it fixed the issues observed. Further, it was a very easy fix. 3. Do we have consensus in the group that we should standardize this solution? 4. If so, should we simply add it to the trickle-ice draft? Or should it be a separate draft? Thanks, Peter --001a11440f6277e958052e4bea4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(As an individual, not a chair)

Ea= rlier, we had some discussion around adding the ufrag to the trickled candi= date so that when one receives the a trickled candidate after an ICE restar= t, it's clear if the candidate applies to the ICE ufrag/pwd from before= or after the ICE restart.

I have a few thoughts/quest= ions about this:

1.=C2=A0 We saw applications where th= is was a real-world issue.=C2=A0

2.=C2=A0 We implement= ed the addition of the ufrag to candidates in Chrome, and it fixed the issu= es observed.=C2=A0 Further, it was a very easy fix.

3.= =C2=A0 Do we have consensus in the group that we should standardize this so= lution?

4.=C2=A0 If so, should we simply add it to the= trickle-ice draft?=C2=A0 Or should it be a separate draft?

Thanks,
Peter
--001a11440f6277e958052e4bea4a-- From nobody Sun Mar 20 04:17:27 2016 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 D752912D6B1 for ; Sun, 20 Mar 2016 04:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 41jy54Dgc1vN for ; Sun, 20 Mar 2016 04:17:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD9312D6A7 for ; Sun, 20 Mar 2016 04:17:23 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-50-56ee86c123d4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.6B.16394.1C68EE65; Sun, 20 Mar 2016 12:17:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Sun, 20 Mar 2016 12:17:21 +0100 From: Christer Holmberg To: Peter Thatcher , "ice@ietf.org" Thread-Topic: [Ice] Some thoughts on trickling the ufrag Thread-Index: AQHRgNYCzcAdo41R9Eafau+GBkHs2p9iMqxQ Date: Sun, 20 Mar 2016 11:17:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37EDB483ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7h+7BtndhBh8WWlh8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVcXjKSaaCS/4Vr+cdZm1g3OHbxcjBISFgItGx 3KmLkRPIFJO4cG89WxcjF4eQwGFGiTUHV7BCOIsZJTZtn8YO0sAmYCHR/U8bpEFEwENi85vl bCC2sIC5xIGF15gg4hYSj5v+s0HYRhI3tx5kB7FZBFQlJtztA4vzCvhK/HjwlgXEFhIIkHh3 6xtYL6dAoMSLzd1g9YxAB30/tQYsziwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpJoXPKE FaI+X+LCnG4WiF2CEidnPmGZwCgyC8moWUjKZiEpmwX0JbOApsT6XfoQJYoSU7ofskPYGhKt c+ayI4svYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYTwe3/FbdwXj5jeMhRgEORiUe XgOhd2FCrIllxZW5hxglOJiVRHgX5gOFeFMSK6tSi/Lji0pzUosPMUpzsCiJ87J+uhwmJJCe WJKanZpakFoEk2Xi4JRqYPSVaayKOeC492BQls9Dy4xnu+W7HzX3Hd1lMbfp0DrJVKUnM5l3 M/NPmuh37SGrQ0pB4PU3W52S2rIaFXec+VtdX8VxLS5j6yqp4Loz1TYiZytSg8/pljpG7d/3 49WTliyr0uc3Y3Ut1qaeOvzya/DuC3EdST/L+s/skLi7VKyO/+ibatf4g0osxRmJhlrMRcWJ AIB3L0mjAgAA Archived-At: Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 11:17:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37EDB483ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXQgcmVhc29uIHdvdWxkIHRoZXJlIGJlIGZvciBwdXR0aW5nIGl0IGluIGEgc2Vw YXJhdGUgZHJhZnQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEljZSBbbWFpbHRv OmljZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGV0ZXIgVGhhdGNoZXINClNlbnQ6 IDE4IE1hcmNoIDIwMTYgMDc6MjENClRvOiBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFtJY2VdIFNv bWUgdGhvdWdodHMgb24gdHJpY2tsaW5nIHRoZSB1ZnJhZw0KDQooQXMgYW4gaW5kaXZpZHVhbCwg bm90IGEgY2hhaXIpDQoNCkVhcmxpZXIsIHdlIGhhZCBzb21lIGRpc2N1c3Npb24gYXJvdW5kIGFk ZGluZyB0aGUgdWZyYWcgdG8gdGhlIHRyaWNrbGVkIGNhbmRpZGF0ZSBzbyB0aGF0IHdoZW4gb25l IHJlY2VpdmVzIHRoZSBhIHRyaWNrbGVkIGNhbmRpZGF0ZSBhZnRlciBhbiBJQ0UgcmVzdGFydCwg aXQncyBjbGVhciBpZiB0aGUgY2FuZGlkYXRlIGFwcGxpZXMgdG8gdGhlIElDRSB1ZnJhZy9wd2Qg ZnJvbSBiZWZvcmUgb3IgYWZ0ZXIgdGhlIElDRSByZXN0YXJ0Lg0KDQpJIGhhdmUgYSBmZXcgdGhv dWdodHMvcXVlc3Rpb25zIGFib3V0IHRoaXM6DQoNCjEuICBXZSBzYXcgYXBwbGljYXRpb25zIHdo ZXJlIHRoaXMgd2FzIGEgcmVhbC13b3JsZCBpc3N1ZS4NCg0KMi4gIFdlIGltcGxlbWVudGVkIHRo ZSBhZGRpdGlvbiBvZiB0aGUgdWZyYWcgdG8gY2FuZGlkYXRlcyBpbiBDaHJvbWUsIGFuZCBpdCBm aXhlZCB0aGUgaXNzdWVzIG9ic2VydmVkLiAgRnVydGhlciwgaXQgd2FzIGEgdmVyeSBlYXN5IGZp eC4NCg0KMy4gIERvIHdlIGhhdmUgY29uc2Vuc3VzIGluIHRoZSBncm91cCB0aGF0IHdlIHNob3Vs ZCBzdGFuZGFyZGl6ZSB0aGlzIHNvbHV0aW9uPw0KDQo0LiAgSWYgc28sIHNob3VsZCB3ZSBzaW1w bHkgYWRkIGl0IHRvIHRoZSB0cmlja2xlLWljZSBkcmFmdD8gIE9yIHNob3VsZCBpdCBiZSBhIHNl cGFyYXRlIGRyYWZ0Pw0KDQpUaGFua3MsDQpQZXRlcg0K --_000_7594FB04B1934943A5C02806D1A2204B37EDB483ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCByZWFzb24gd291bGQgdGhlcmUg YmUgZm9yIHB1dHRpbmcgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IEljZSBbbWFpbHRvOmljZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Q ZXRlciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBNYXJjaCAyMDE2IDA3OjIxPGJyPg0K PGI+VG86PC9iPiBpY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0ljZV0gU29tZSB0 aG91Z2h0cyBvbiB0cmlja2xpbmcgdGhlIHVmcmFnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj4oQXMgYW4gaW5kaXZpZHVhbCwgbm90IGEgY2hhaXIpPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5F YXJsaWVyLCB3ZSBoYWQgc29tZSBkaXNjdXNzaW9uIGFyb3VuZCBhZGRpbmcgdGhlIHVmcmFnIHRv IHRoZSB0cmlja2xlZCBjYW5kaWRhdGUgc28gdGhhdCB3aGVuIG9uZSByZWNlaXZlcyB0aGUgYSB0 cmlja2xlZCBjYW5kaWRhdGUgYWZ0ZXIgYW4gSUNFIHJlc3RhcnQsIGl0J3MgY2xlYXIgaWYgdGhl IGNhbmRpZGF0ZSBhcHBsaWVzDQogdG8gdGhlIElDRSB1ZnJhZy9wd2QgZnJvbSBiZWZvcmUgb3Ig YWZ0ZXIgdGhlIElDRSByZXN0YXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGEgZmV3IHRob3VnaHRzL3F1ZXN0 aW9ucyBhYm91dCB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+MS4mbmJzcDsgV2Ugc2F3IGFwcGxpY2F0aW9ucyB3aGVy ZSB0aGlzIHdhcyBhIHJlYWwtd29ybGQgaXNzdWUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4yLiZuYnNwOyBXZSBp bXBsZW1lbnRlZCB0aGUgYWRkaXRpb24gb2YgdGhlIHVmcmFnIHRvIGNhbmRpZGF0ZXMgaW4gQ2hy b21lLCBhbmQgaXQgZml4ZWQgdGhlIGlzc3VlcyBvYnNlcnZlZC4mbmJzcDsgRnVydGhlciwgaXQg d2FzIGEgdmVyeSBlYXN5IGZpeC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjMuJm5ic3A7IERvIHdlIGhhdmUgY29uc2Vuc3Vz IGluIHRoZSBncm91cCB0aGF0IHdlIHNob3VsZCBzdGFuZGFyZGl6ZSB0aGlzIHNvbHV0aW9uPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+NC4mbmJzcDsgSWYgc28sIHNob3VsZCB3ZSBzaW1wbHkgYWRkIGl0IHRvIHRoZSB0cmlj a2xlLWljZSBkcmFmdD8mbmJzcDsgT3Igc2hvdWxkIGl0IGJlIGEgc2VwYXJhdGUgZHJhZnQ/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlBldGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37EDB483ESESSMB209erics_-- From nobody Sun Mar 20 04:25:47 2016 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 909D212D654 for ; Sun, 20 Mar 2016 04:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 7UlwcgmJRFX6 for ; Sun, 20 Mar 2016 04:25:44 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 4BB7612D53B for ; Sun, 20 Mar 2016 04:25:44 -0700 (PDT) Received: by mail-ob0-x235.google.com with SMTP id m7so153401978obh.3 for ; Sun, 20 Mar 2016 04:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=otl+DVBlqutTbpb56wn91ImXsujwtPmLevEMRi0U/a4=; b=KRuXFhm/0Y9HE/drYzoQiQS1tK8JDOs/Us3GYNpZvsZg1946h3cZ2Z72LwDD/VKn0k 4Whw+h87e1kPXZ93HwsKy+n+yMOBmwUCsF/rVVbWTwvcJA7ZJthLlZdYakVmrGRRisJu ryiWVtmYtDCgV7rYVVMGKg8OmTHN5ZVwuyon3geHBhCIH++luGoe9dly5oyDBDXPJkbH K850L5jIhjtgOe5/xdqULfb2Ddfx754252mcd/1wv3+YoF93YjrNxVuKs/41OF0edYsf ofoXko4NFmFVBfikMTPBpRKsk8zdT6bGJAZ5KTi1+bLhq16W5mII6g3qAPNtALi3c6jS QQ9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=otl+DVBlqutTbpb56wn91ImXsujwtPmLevEMRi0U/a4=; b=NWvwJMRxN1o6uApfbNfp4ioONwKUWazTQIK6Z2rUbv+7qCqwstrn+DVp5A8PNqL/1T euJTCg1g1Y6fg+iRV2c9caMY+Xhi0QVA7GQ/wU87P6Dt1zVXb6gO4LhulZnMTzi3LFLa /y2Gh/jsBRrFXe2l0q43CNU4syNkFq6mLn3EWICN5GUKCvwhr09E2yw8pbVQZEZDZ15O PAXt4WOvbAHIXRxJkFIZtqCRS7YtNR9H3iMPAcR6iVKYkELLBBJOlxZuDqdYFN1w7APX p4IMp8FgTdhsUn+qi1PYNZFqsDheNH5eU9oeKo/00IsTTLJzNtwVizyUP17IFaG1FRF9 I+fg== X-Gm-Message-State: AD7BkJJyyExJMAUtWIYsxRUENv1uB3FIldBufI1WoKKuI9rDzYzB+8/eZBRcKi5XTxKoGQ== X-Received: by 10.60.67.231 with SMTP id q7mr14409456oet.41.1458473143627; Sun, 20 Mar 2016 04:25:43 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com. [209.85.218.41]) by smtp.gmail.com with ESMTPSA id dg3sm9842998oeb.12.2016.03.20.04.25.42 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2016 04:25:43 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id r187so120968687oih.3 for ; Sun, 20 Mar 2016 04:25:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.217.136 with SMTP id q130mr14353818oig.127.1458473142444; Sun, 20 Mar 2016 04:25:42 -0700 (PDT) Received: by 10.76.98.226 with HTTP; Sun, 20 Mar 2016 04:25:42 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> Date: Sun, 20 Mar 2016 06:25:42 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11496c54920665052e793d0d Archived-At: Cc: Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 11:25:46 -0000 --001a11496c54920665052e793d0d Content-Type: text/plain; charset=UTF-8 Well because it's a signaling issue. IIRC it is something that we agreed trickle ice for sip would Include. I guess it's more of a question if and how it should be in trickle ice for sip. The tricky part there is that this is a purely signalling issue and trickle ice is meant to be signalling agnostic. A headsup to implementors may therefore be more appropriate. Emil On Sunday, 20 March 2016, Christer Holmberg wrote: > Hi, > > > > What reason would there be for putting it in a separate draft? > > > > Regards, > > > > Christer > > > > *From:* Ice [mailto:ice-bounces@ietf.org > ] *On Behalf Of *Peter > Thatcher > *Sent:* 18 March 2016 07:21 > *To:* ice@ietf.org > *Subject:* [Ice] Some thoughts on trickling the ufrag > > > > (As an individual, not a chair) > > > > Earlier, we had some discussion around adding the ufrag to the trickled > candidate so that when one receives the a trickled candidate after an ICE > restart, it's clear if the candidate applies to the ICE ufrag/pwd from > before or after the ICE restart. > > > > I have a few thoughts/questions about this: > > > > 1. We saw applications where this was a real-world issue. > > > > 2. We implemented the addition of the ufrag to candidates in Chrome, and > it fixed the issues observed. Further, it was a very easy fix. > > > > 3. Do we have consensus in the group that we should standardize this > solution? > > > > 4. If so, should we simply add it to the trickle-ice draft? Or should it > be a separate draft? > > > > Thanks, > > Peter > -- sent from my mobile --001a11496c54920665052e793d0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well because it's a signaling issue. IIRC it is something that we agree= d trickle ice for sip would=C2=A0
Include.

I guess it= 's more of a question if and how it should be in trickle ice for sip.

The tricky part there is that this is a purely sign= alling issue and trickle ice is meant to be signalling agnostic. A headsup = to implementors may therefore be more appropriate.
Emil

On Sunday, 20 March 2016, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

What reason would there be for puttin= g it in a separate draft?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Peter Thatcher
Sent: 18 March 2016 07:21
To: ice@ietf.org
Subject: [Ice] Some thoughts on trickling the ufrag

=C2=A0

(As an individual, not a chair)

=C2=A0

Earlier, we had some discussion around adding the ufrag to the trickle= d candidate so that when one receives the a trickled candidate after an ICE= restart, it's clear if the candidate applies to the ICE ufrag/pwd from before or after the ICE restart.

=C2=A0

I have a few thoughts/questions about this:

=C2=A0

1.=C2=A0 We saw applications where this was a real-world issue.=C2=A0<= u>

=C2=A0

2.=C2=A0 We implemented the addition of the ufrag to candidates in Chr= ome, and it fixed the issues observed.=C2=A0 Further, it was a very easy fi= x.

=C2=A0

3.=C2=A0 Do we have consensus in the group that we should standardize = this solution?

=C2=A0

4.=C2=A0 If so, should we simply add it to the trickle-ice draft?=C2= =A0 Or should it be a separate draft?

=C2=A0

Thanks,

Peter



--
sent from my mobile
--001a11496c54920665052e793d0d-- From nobody Mon Mar 21 10:37:58 2016 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 B023412D9CF for ; Mon, 21 Mar 2016 10:37:56 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 mGhtnLBRjaAg for ; Mon, 21 Mar 2016 10:37:54 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 510FA12D996 for ; Mon, 21 Mar 2016 10:37:02 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id q138so131295676vkb.3 for ; Mon, 21 Mar 2016 10:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V0S/cVEW0kzTIHi+W4ypyQRyNM4JG7oakk8rpJlCcZA=; b=BNx8Rx8eOXFglp+Y+udW+i4cjO+t5D6U/z+odQd9q898LJ3QTyJjb8N1s3xYcd1YvE a3iV3paRahLKayK4c+J3jTFnGfTavizxfLPFNn0v5jiArCvzjuYvxne6AF5SghH/Cknl DNzBUukns67AsR8ZNbev7qsjWYsJo5Sp4pIq/qhyrivDkPQuIRfm1dHB1keusQk9bHkR G3E/QzNBPvrsDgPMyy7pIwV7FPGMHug3vzKs7TiwFrri1l8k/o/J/CcZbUHOoTbo+lup 5sy4Wr9IyNLV85+PBkqvrBp8JfwuXDgXR+nUkDyXdniyU/w4olaQnhb5gSPbwA/XpK76 qnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V0S/cVEW0kzTIHi+W4ypyQRyNM4JG7oakk8rpJlCcZA=; b=muQgBNaXF5HOPiuKvUdK69XLyOwJssl73Nm+lHp73bNcpp6s4xlRcDxE+pHkF80yLn sAgx1kZHCfkgOGOWzCw1WIC9X+SY/BGy1uWj96+vhApIfO6niNH52YKb+9lEIHuf+Lgl LfzNPxbAkWOLdrqT2DSvLLkNn3w+LGHTF0cyodOEVXYa4473o6pTXB6kNLCqxAZSi5LH zkVqeaBvigWjbJaoTBKKrHVo/vVM+buJTAaIAyZYNUMe94Bvf1dCKWxKB0HtA+w2hYAx mxeddt3fVjHOdZagKBhAXBHt7ytQtaInMNVyPLczipusxiCUstnI44RuYEQddtikDCaN ipRA== X-Gm-Message-State: AD7BkJJqEoI3a+lrsimuqLfV7gkj0PaRlJp1zlvR9p4nz6w2k+qXsKSbh2nxI4YNfKg1e89d2lerz/XkdzJsl8/D X-Received: by 10.31.44.77 with SMTP id s74mr32268186vks.4.1458581821331; Mon, 21 Mar 2016 10:37:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 21 Mar 2016 10:36:21 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> From: Peter Thatcher Date: Mon, 21 Mar 2016 10:36:21 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a11c075a25663ab052e928bfa Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:37:57 -0000 --001a11c075a25663ab052e928bfa Content-Type: text/plain; charset=UTF-8 Would it make sense to have a "SHOULD signal ufrag on a trickled candidate"? On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov wrote: > Well because it's a signaling issue. IIRC it is something that we agreed > trickle ice for sip would > Include. > > I guess it's more of a question if and how it should be in trickle ice for > sip. > > The tricky part there is that this is a purely signalling issue and > trickle ice is meant to be signalling agnostic. A headsup to implementors > may therefore be more appropriate. > Emil > > On Sunday, 20 March 2016, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> What reason would there be for putting it in a separate draft? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *From:* Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter Thatcher >> *Sent:* 18 March 2016 07:21 >> *To:* ice@ietf.org >> *Subject:* [Ice] Some thoughts on trickling the ufrag >> >> >> >> (As an individual, not a chair) >> >> >> >> Earlier, we had some discussion around adding the ufrag to the trickled >> candidate so that when one receives the a trickled candidate after an ICE >> restart, it's clear if the candidate applies to the ICE ufrag/pwd from >> before or after the ICE restart. >> >> >> >> I have a few thoughts/questions about this: >> >> >> >> 1. We saw applications where this was a real-world issue. >> >> >> >> 2. We implemented the addition of the ufrag to candidates in Chrome, and >> it fixed the issues observed. Further, it was a very easy fix. >> >> >> >> 3. Do we have consensus in the group that we should standardize this >> solution? >> >> >> >> 4. If so, should we simply add it to the trickle-ice draft? Or should >> it be a separate draft? >> >> >> >> Thanks, >> >> Peter >> > > > -- > sent from my mobile > --001a11c075a25663ab052e928bfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would it make sense to have a "SHOULD signal ufrag= on a trickled candidate"?

<= div class=3D"gmail_quote">On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <emcho@= jitsi.org> wrote:
Well bec= ause it's a signaling issue. IIRC it is something that we agreed trickl= e ice for sip would=C2=A0
Include.

I guess it's m= ore of a question if and how it should be in trickle ice for sip.

The tricky part there is that this is a purely signalling i= ssue and trickle ice is meant to be signalling agnostic. A headsup to imple= mentors may therefore be more appropriate.
Emil

On Sunday, 20 March 201= 6, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

What reason would there be for puttin= g it in a separate draft?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Peter Thatcher
Sent: 18 March 2016 07:21
To: ice@ietf.org
Subject: [Ice] Some thoughts on trickling the ufrag

=C2=A0

(As an individual, not a chair)

=C2=A0

Earlier, we had some discussion around adding the ufrag to the trickle= d candidate so that when one receives the a trickled candidate after an ICE= restart, it's clear if the candidate applies to the ICE ufrag/pwd from before or after the ICE restart.

=C2=A0

I have a few thoughts/questions about this:

=C2=A0

1.=C2=A0 We saw applications where this was a real-world issue.=C2=A0<= u>

=C2=A0

2.=C2=A0 We implemented the addition of the ufrag to candidates in Chr= ome, and it fixed the issues observed.=C2=A0 Further, it was a very easy fi= x.

=C2=A0

3.=C2=A0 Do we have consensus in the group that we should standardize = this solution?

=C2=A0

4.=C2=A0 If so, should we simply add it to the trickle-ice draft?=C2= =A0 Or should it be a separate draft?

=C2=A0

Thanks,

Peter



--
sent from my mobile

--001a11c075a25663ab052e928bfa-- From nobody Mon Mar 21 11:09:55 2016 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 05EC112D7E7 for ; Mon, 21 Mar 2016 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ytZOkIO4Hg6p for ; Mon, 21 Mar 2016 11:09:47 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3DC12D94D for ; Mon, 21 Mar 2016 11:09:46 -0700 (PDT) X-AuditID: c1b4fb2d-f79c06d000005960-0b-56f038e8c629 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DE.2D.22880.8E830F65; Mon, 21 Mar 2016 19:09:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 19:09:35 +0100 From: Christer Holmberg To: Peter Thatcher , Emil Ivov Thread-Topic: [Ice] Some thoughts on trickling the ufrag Thread-Index: AQHRgNYCzcAdo41R9Eafau+GBkHs2p9iMqxQ///xXQCAAfnkgIAAGiNw Date: Mon, 21 Mar 2016 18:09:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37EF8E18ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tO4Liw9hBv3t/BZrdk5gsfh2odbi 2vLXrA7MHgs2lXosWfKTyeP/m8AA5igum5TUnMyy1CJ9uwSujPPdP5gKWqYxVnQs/cfewNgy ibGLkZNDQsBEYtWlfmYIW0ziwr31bF2MHBxCAocZJVqVuhi5gMzFjBLvZzcxgsTZBCwkuv9p g5SLCLhJTHs2hxUkzCygKPFyrxpIWFjAXOLAwmtMECUWEo+b/oNNBCnfdC0FJMwioCox6dFr sKW8Ar4Su189Z4LYtIhJYt27rewgCU6BQImJyxrAbEagy76fWgM2k1lAXOLWk/lMEBcLSCzZ cx7qelGJl4//sULYShJrD29ngajPl/i0aDcLxDJBiZMzn7BMYBSdhWTULCRls5CUzQL7TFNi /S59iBJFiSndD9khbA2J1jlz2ZHFFzCyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjLyD W37r7mBc/drxEKMAB6MSD6/BlfdhQqyJZcWVuYcYJTiYlUR4a00/hAnxpiRWVqUW5ccXleak Fh9ilOZgURLnZft0OUxIID2xJDU7NbUgtQgmy8TBKdXAWPV62qS1djoqRdWzFawtprQHSAZt mzhlMs8tkZk63/ZNumxXuXeTeHBLY2D7FEGhtd+Nk3aLVmi+eV79PP17TRVvdkNFgZlOmcwF k0N9J+ZpF8a8KHvm+336+4aK1WdE586oyZG+/fmWO/vKR99Mq81yn5SueyIanj3nz+Jb/wRu 8/1SWn5/lRJLcUaioRZzUXEiAGIcZhm4AgAA Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:09:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37EF8E18ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCklzIHRoZXJlIGEgcmVhc29uIGZvciBub3QgaGF2aW5nIE1VU1Q/DQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCkZyb206IFBldGVyIFRoYXRjaGVyIFttYWlsdG86cHRoYXRjaGVyQGdv b2dsZS5jb21dDQpTZW50OiAyMSBNYXJjaCAyMDE2IDE5OjM2DQpUbzogRW1pbCBJdm92IDxlbWNo b0BqaXRzaS5vcmc+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT47IGljZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJY2VdIFNvbWUgdGhvdWdo dHMgb24gdHJpY2tsaW5nIHRoZSB1ZnJhZw0KDQpXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIGhhdmUg YSAiU0hPVUxEIHNpZ25hbCB1ZnJhZyBvbiBhIHRyaWNrbGVkIGNhbmRpZGF0ZSI/DQoNCk9uIFN1 biwgTWFyIDIwLCAyMDE2IGF0IDQ6MjUgQU0sIEVtaWwgSXZvdiA8ZW1jaG9Aaml0c2kub3JnPG1h aWx0bzplbWNob0BqaXRzaS5vcmc+PiB3cm90ZToNCldlbGwgYmVjYXVzZSBpdCdzIGEgc2lnbmFs aW5nIGlzc3VlLiBJSVJDIGl0IGlzIHNvbWV0aGluZyB0aGF0IHdlIGFncmVlZCB0cmlja2xlIGlj ZSBmb3Igc2lwIHdvdWxkDQpJbmNsdWRlLg0KDQpJIGd1ZXNzIGl0J3MgbW9yZSBvZiBhIHF1ZXN0 aW9uIGlmIGFuZCBob3cgaXQgc2hvdWxkIGJlIGluIHRyaWNrbGUgaWNlIGZvciBzaXAuDQoNClRo ZSB0cmlja3kgcGFydCB0aGVyZSBpcyB0aGF0IHRoaXMgaXMgYSBwdXJlbHkgc2lnbmFsbGluZyBp c3N1ZSBhbmQgdHJpY2tsZSBpY2UgaXMgbWVhbnQgdG8gYmUgc2lnbmFsbGluZyBhZ25vc3RpYy4g QSBoZWFkc3VwIHRvIGltcGxlbWVudG9ycyBtYXkgdGhlcmVmb3JlIGJlIG1vcmUgYXBwcm9wcmlh dGUuDQpFbWlsDQoNCk9uIFN1bmRheSwgMjAgTWFyY2ggMjAxNiwgQ2hyaXN0ZXIgSG9sbWJlcmcg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KV2hhdCByZWFzb24gd291bGQgdGhlcmUgYmUg Zm9yIHB1dHRpbmcgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdD8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KRnJvbTogSWNlIFttYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBQZXRlciBUaGF0Y2hlcg0KU2VudDogMTggTWFyY2ggMjAxNiAwNzoyMQ0KVG86IGljZUBpZXRm Lm9yZzxtYWlsdG86aWNlQGlldGYub3JnPg0KU3ViamVjdDogW0ljZV0gU29tZSB0aG91Z2h0cyBv biB0cmlja2xpbmcgdGhlIHVmcmFnDQoNCihBcyBhbiBpbmRpdmlkdWFsLCBub3QgYSBjaGFpcikN Cg0KRWFybGllciwgd2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBhcm91bmQgYWRkaW5nIHRoZSB1ZnJh ZyB0byB0aGUgdHJpY2tsZWQgY2FuZGlkYXRlIHNvIHRoYXQgd2hlbiBvbmUgcmVjZWl2ZXMgdGhl IGEgdHJpY2tsZWQgY2FuZGlkYXRlIGFmdGVyIGFuIElDRSByZXN0YXJ0LCBpdCdzIGNsZWFyIGlm IHRoZSBjYW5kaWRhdGUgYXBwbGllcyB0byB0aGUgSUNFIHVmcmFnL3B3ZCBmcm9tIGJlZm9yZSBv ciBhZnRlciB0aGUgSUNFIHJlc3RhcnQuDQoNCkkgaGF2ZSBhIGZldyB0aG91Z2h0cy9xdWVzdGlv bnMgYWJvdXQgdGhpczoNCg0KMS4gIFdlIHNhdyBhcHBsaWNhdGlvbnMgd2hlcmUgdGhpcyB3YXMg YSByZWFsLXdvcmxkIGlzc3VlLg0KDQoyLiAgV2UgaW1wbGVtZW50ZWQgdGhlIGFkZGl0aW9uIG9m IHRoZSB1ZnJhZyB0byBjYW5kaWRhdGVzIGluIENocm9tZSwgYW5kIGl0IGZpeGVkIHRoZSBpc3N1 ZXMgb2JzZXJ2ZWQuICBGdXJ0aGVyLCBpdCB3YXMgYSB2ZXJ5IGVhc3kgZml4Lg0KDQozLiAgRG8g d2UgaGF2ZSBjb25zZW5zdXMgaW4gdGhlIGdyb3VwIHRoYXQgd2Ugc2hvdWxkIHN0YW5kYXJkaXpl IHRoaXMgc29sdXRpb24/DQoNCjQuICBJZiBzbywgc2hvdWxkIHdlIHNpbXBseSBhZGQgaXQgdG8g dGhlIHRyaWNrbGUtaWNlIGRyYWZ0PyAgT3Igc2hvdWxkIGl0IGJlIGEgc2VwYXJhdGUgZHJhZnQ/ DQoNClRoYW5rcywNClBldGVyDQoNCi0tDQpzZW50IGZyb20gbXkgbW9iaWxlDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B37EF8E18ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SXMgdGhlcmUgYSByZWFzb24gZm9yIG5vdCBoYXZpbmcgTVVTVD8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gUGV0ZXIgVGhhdGNoZXIgW21haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiAyMSBNYXJjaCAyMDE2IDE5OjM2PGJyPg0KPGI+VG86PC9iPiBFbWlsIEl2b3Yg Jmx0O2VtY2hvQGppdHNpLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IENocmlzdGVyIEhvbG1iZXJn ICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7OyBpY2VAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJY2VdIFNvbWUgdGhvdWdodHMgb24gdHJpY2tsaW5nIHRo ZSB1ZnJhZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+V291bGQg aXQgbWFrZSBzZW5zZSB0byBoYXZlIGEgJnF1b3Q7U0hPVUxEIHNpZ25hbCB1ZnJhZyBvbiBhIHRy aWNrbGVkIGNhbmRpZGF0ZSZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgTWFyIDIwLCAyMDE2IGF0IDQ6MjUg QU0sIEVtaWwgSXZvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtY2hvQGppdHNpLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmVtY2hvQGppdHNpLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlbGwgYmVjYXVzZSBpdCdzIGEgc2ln bmFsaW5nIGlzc3VlLiBJSVJDIGl0IGlzIHNvbWV0aGluZyB0aGF0IHdlIGFncmVlZCB0cmlja2xl IGljZSBmb3Igc2lwIHdvdWxkJm5ic3A7PGJyPg0KSW5jbHVkZS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgaXQncyBtb3JlIG9mIGEgcXVlc3Rp b24gaWYgYW5kIGhvdyBpdCBzaG91bGQgYmUgaW4gdHJpY2tsZSBpY2UgZm9yIHNpcC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRyaWNr eSBwYXJ0IHRoZXJlIGlzIHRoYXQgdGhpcyBpcyBhIHB1cmVseSBzaWduYWxsaW5nIGlzc3VlIGFu ZCB0cmlja2xlIGljZSBpcyBtZWFudCB0byBiZSBzaWduYWxsaW5nIGFnbm9zdGljLiBBIGhlYWRz dXAgdG8gaW1wbGVtZW50b3JzIG1heSB0aGVyZWZvcmUgYmUgbW9yZSBhcHByb3ByaWF0ZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVtaWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KT24gU3VuZGF5LCAyMCBNYXJjaCAyMDE2LCBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hhdCByZWFzb24gd291bGQgdGhlcmUg YmUgZm9yIHB1dHRpbmcgaXQgaW4gYSBzZXBhcmF0ZSBkcmFmdD88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSItNTA5NTc2NDE0NjI5NjU0ODMyM18t NjA3Mzc3MDcyNzMzNDE1ODM3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBJY2UNCiBbPGEgaHJlZj0ibWFpbHRvOmljZS1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86aWNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5QZXRlciBUaGF0Y2hlcjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBNYXJjaCAyMDE2IDA3OjIxPGJy Pg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIj5pY2VAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJY2VdIFNvbWUgdGhvdWdodHMgb24gdHJpY2tsaW5n IHRoZSB1ZnJhZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PihBcyBhbiBpbmRpdmlkdWFsLCBub3QgYSBjaGFpcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5FYXJsaWVyLCB3ZSBo YWQgc29tZSBkaXNjdXNzaW9uIGFyb3VuZCBhZGRpbmcgdGhlIHVmcmFnIHRvIHRoZSB0cmlja2xl ZCBjYW5kaWRhdGUgc28gdGhhdCB3aGVuIG9uZSByZWNlaXZlcyB0aGUgYSB0cmlja2xlZCBjYW5k aWRhdGUNCiBhZnRlciBhbiBJQ0UgcmVzdGFydCwgaXQncyBjbGVhciBpZiB0aGUgY2FuZGlkYXRl IGFwcGxpZXMgdG8gdGhlIElDRSB1ZnJhZy9wd2QgZnJvbSBiZWZvcmUgb3IgYWZ0ZXIgdGhlIElD RSByZXN0YXJ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBhIGZldyB0aG91Z2h0cy9xdWVzdGlvbnMgYWJv dXQgdGhpczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj4xLiZuYnNwOyBXZSBzYXcgYXBwbGljYXRpb25zIHdoZXJlIHRo aXMgd2FzIGEgcmVhbC13b3JsZCBpc3N1ZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4yLiZuYnNwOyBXZSBp bXBsZW1lbnRlZCB0aGUgYWRkaXRpb24gb2YgdGhlIHVmcmFnIHRvIGNhbmRpZGF0ZXMgaW4gQ2hy b21lLCBhbmQgaXQgZml4ZWQgdGhlIGlzc3VlcyBvYnNlcnZlZC4mbmJzcDsgRnVydGhlciwgaXQg d2FzIGEgdmVyeSBlYXN5DQogZml4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjMuJm5ic3A7IERvIHdlIGhhdmUgY29u c2Vuc3VzIGluIHRoZSBncm91cCB0aGF0IHdlIHNob3VsZCBzdGFuZGFyZGl6ZSB0aGlzIHNvbHV0 aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjQuJm5ic3A7IElmIHNvLCBzaG91bGQgd2Ugc2ltcGx5IGFkZCBpdCB0 byB0aGUgdHJpY2tsZS1pY2UgZHJhZnQ/Jm5ic3A7IE9yIHNob3VsZCBpdCBiZSBhIHNlcGFyYXRl IGRyYWZ0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5QZXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tLSA8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpi Ij5zZW50IGZyb20gbXkgbW9iaWxlPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37EF8E18ESESSMB209erics_-- From nobody Mon Mar 21 17:05:02 2016 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 9A9C712D1BF for ; Mon, 21 Mar 2016 17:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 kr9XfNNDmkDD for ; Mon, 21 Mar 2016 17:04:59 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 7D50012D1A1 for ; Mon, 21 Mar 2016 17:04:55 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id q138so142191176vkb.3 for ; Mon, 21 Mar 2016 17:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UFARH5JYkjPkeL0TUNK+QW4L6yKw7NoYzkIZhoKscz8=; b=pY9J+U03EIJ94+rYVRX1nsEFTfa0NWeQ3gtt1xOqXtnQvbPFveQkghdks8VLmcUVyC 5S522T6E9VFMqrL3B1HlKmoAu9/GqsUjy/1JYxbdp4LN6x32gme7JIF7Rkbh8ZiodyBV hMbm2FGNY2JXmeH2i3AesLCTg0FCndQueCI6peE+Saxt+9qgQeJ9+1NgOlCPSa5eeEgX CJ6izrRD2RLxySwUbUpKI6B8b2j0nd9AHGoO5CTSEe+TjKStgwij21NdWjId/WZJaqP3 6z8c+/OvdqKGm/EcQRdemqvtaCd0CbRLNUDwG8PtjTk47tkk04xpAAYHOGMBwZRJY+tr Xc8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UFARH5JYkjPkeL0TUNK+QW4L6yKw7NoYzkIZhoKscz8=; b=GXq0dxUez2TBo6BRo/8zyVaj28C8/koV7FK1lUM6/6uH9Oq5hUayFcv4ZxC2Fs4/R4 gJaWjIfDNqUoVbSzvQo8FNlW23Qjri9xfuHdQhZz4+8iGPcXXSwIDFbooPjN2pw1HKak qnlofby9iNzhYaMxk4exDxyruyK1cERoiZxfrGiNIzV8eEvFzjW1/qQgTgxWC57DUqy+ pCU3oo07UiPYwfGaE8bhICW8YRVi9sit7mRirC8jrMWBVwUUfTVpoo0nAZVn1SGy89BJ 0YJL6ZVNeObonuVWQpUBq3XNmPmqg1vRLK8KI+2+C/qgRBdz4z0wGwwYg7zud12aYw/E D6BA== X-Gm-Message-State: AD7BkJLjQ5lPC6yLDd/f+61QfWsdOm9UGhadmukEqNO0lenOrWAFVvHtZJXnKydXEyGtgr6B9UJspk7Lp0LN9FYv X-Received: by 10.31.44.77 with SMTP id s74mr33457526vks.4.1458605094470; Mon, 21 Mar 2016 17:04:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 21 Mar 2016 17:04:15 -0700 (PDT) From: Peter Thatcher Date: Mon, 21 Mar 2016 17:04:15 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11c075a286748e052e97f68c Archived-At: Subject: [Ice] Proposal for ICE "renomination" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:05:00 -0000 --001a11c075a286748e052e97f68c Content-Type: text/plain; charset=UTF-8 As an author (not a chair), I just submitted a draft for an idea I'd like to propose for ICE: renomination. Here's the draft: https://datatracker.ietf.org/doc/draft-thatcher-ice-renomination/ The idea is basically to allow the controlling side to nomination more than once, and have the last one win. This would allow candidate pairs to be switched over time as network conditions change. Please let me know what you think. In particular: 1. Would you find this capability valuable? 2. Do we need the ICE option? 3. Do we need the STUN attribute? Thanks, Peter --001a11c075a286748e052e97f68c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an author (not a chair), I just submitted a draft fo= r an idea I'd like to propose for ICE: renomination. =C2=A0
Here's the draft:

https://datat= racker.ietf.org/doc/draft-thatcher-ice-renomination/


The idea is bas= ically to allow the controlling side to nomination more than once, and have= the last one win.=C2=A0 This would allow candidate pairs to be switched ov= er time as network conditions change.

Please let me know what you think.=C2=A0 In particular:

1.=C2=A0 Would you find this capabili= ty valuable?
2.=C2=A0 Do we need the=C2=A0ICE option?
<= div class=3D"gmail_default" style=3D"">3.=C2=A0 Do we need the STUN attribute?

Thanks,
Peter
--001a11c075a286748e052e97f68c-- From nobody Mon Mar 21 17:08:54 2016 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 9D8FD12D531 for ; Mon, 21 Mar 2016 17:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 7bxFg41NWOpS for ; Mon, 21 Mar 2016 17:08:34 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 12D6B12D515 for ; Mon, 21 Mar 2016 17:08:34 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id k1so234682691vkb.0 for ; Mon, 21 Mar 2016 17:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=22f0QXAM2PrZT98gory06+81k57eL6/Ezl9QOCA8vx8=; b=ZkW9nsdhjvQSzPU/6LH3KS1aLkK6Jn64z/XxYEekNNFsXtzVbDx2oHntcGlbURwScC 6IA5q1eUX2rddqIqCdyBpYwBJ3dMCQ2oJ+1HGiIo4vHKMEXZ11SFvGy3b7prIK3d3dJQ X94knev3R9Vsb13Vah0cPJGBCYNCfYs2QDmyiPPFY2d9kkynSIK8+EYgUFcNlsNa7B3e YT1D5TM9pQ+hUf8EzTFDbuqypq7uwdqQn1y1ju2Qkcjki8eIIVodcG7Hbx/Vq5c8cWNN 4dgT7RQnoy8XOGwFhJRfSI9GTrqMa7C8d8JwZM87bWBrxbYNA+paExoqZRgbdknRgaZF 1Q4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=22f0QXAM2PrZT98gory06+81k57eL6/Ezl9QOCA8vx8=; b=k8v06MMLrS9plbcmKTmRiRG2rbqxo9pD4H+8Y2WBUH7YHswgiK9DC9yKHCiKyPGHVW AnOkNGlob2dSgS0mdK1tuXxen7kmV5TwiUXVAJPaWoVbYPoYQX9zuKKq2tmHhxP+7JLy rkawOPyQOQRD8x2U5TJBB1Ou0EErU+PoyhQkd8Hv96aPUyg2jPyN3G90iNqd8NzXOeAZ I/pQI6HyTQoK2+WLm3ZGWwQ8nJMguwg7F8C76NhO9KwdxUIx4bdB3N9qmRozVzuMeURX s3Tn2SeSDJbuROD5L9yW06stqoTA+i+FN6vFP6OsiFvzItdUvdOD8pUMC1YcaRjk0RCv cwOw== X-Gm-Message-State: AD7BkJLBNo9ZhlmmVRTyb8voN2EADVaIYb77TKWnvJP7NYoB/+M+pufyGXFZXn4k9aKws1T/+z+1WLDrb12MTlFK X-Received: by 10.31.11.201 with SMTP id 192mr33001911vkl.135.1458605313163; Mon, 21 Mar 2016 17:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 21 Mar 2016 17:07:53 -0700 (PDT) From: Peter Thatcher Date: Mon, 21 Mar 2016 17:07:53 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a114551528f7283052e980345 Archived-At: Subject: [Ice] Proposal for ICE "network cost" X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 00:08:35 -0000 --001a114551528f7283052e980345 Content-Type: text/plain; charset=UTF-8 As an author (not a chair), I just submitted a draft for an idea I'd like to propose for ICE: network cost. Here's the draft: https://datatracker.ietf.org/doc/draft-thatcher-ice-network-cost/ The idea is basically to allow the controlled side to tell the controlling side which candidates "cost" more than others (such as cellular costing more than Wi-Fi). This is different than candidate priority for reasons explained in the draft. Thanks, Peter --001a114551528f7283052e980345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As an author (not a chair)= , I just submitted a draft for an idea I'd like to propose for ICE: net= work cost.=C2=A0

Here's the draft:

=
<= font face=3D"arial, helvetica, sans-serif">https://datatracker.ietf.org/= doc/draft-thatcher-ice-network-cost/

The idea is basically t= o allow the controlled side to tell the controlling side which candidates &= quot;cost" more than others (such as cellular costing more than Wi-Fi)= .=C2=A0 This is different than candidate priority for reasons explained in = the draft. =C2=A0

Thank= s,
Peter
--001a114551528f7283052e980345-- From nobody Wed Mar 23 00:30:24 2016 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 6122C12D603 for ; Wed, 23 Mar 2016 00:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NE4uxNq6AVcR for ; Wed, 23 Mar 2016 00:30:21 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FE412D5CF for ; Wed, 23 Mar 2016 00:30:20 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-05-56f2460a6c88 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.D8.23401.A0642F65; Wed, 23 Mar 2016 08:30:18 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 08:29:45 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG Thread-Topic: ICE WG draft agenda for IETF #95 Thread-Index: AQHRhNXFkg8IMR2CNEuLbf/mLcpZjQ== Date: Wed, 23 Mar 2016 07:29:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9C5623F30BB7F64991E4F9FD98146F9F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdXpfL7VOYweWXZhbfLtRaXFv+mtWB yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBlLOzuZiqYxVRxtX8GcwPjfcYuRk4OCQETiU9t 19ggbDGJC/fWg9lCAocZJVYfUepi5AKylzBKzJj5BSzBJmAvMXnNR7BmEQFJiZY/G1lBbGYB TYn7Jxeyg9jCQPa6L/vZIGr0JNY+mMUOY69fPYkJxGYRUJW4fv0ZWJwXaObaHdvA4oxAR3w/ tYYJYqa4xK0n85kgjhOQWLLnPDOELSrx8vE/VghbSaJxyROoG/QkbkydwgZhW0v8O32CHcLW lli28DUzxC5BiZMzn7BMYBSdhWTFLCTts5C0z0LSPgtJ+wJG1lWMosWpxcW56UZGeqlFmcnF xfl5enmpJZsYgbFzcMtvqx2MB587HmIU4GBU4uEtOPcxTIg1say4MvcQowQHs5IIb5TqpzAh 3pTEyqrUovz4otKc1OJDjNIcLErivGyfLocJCaQnlqRmp6YWpBbBZJk4OKUaGL3X7vzUc/th 48ue9dvTH70ROdbxnYWZ61Gx/YqPRpKfu4/6rmdp/MnY+7qYOZpzkkFFSPkSddXLL6XfJIj+ 29xStd/31mMx7RMtP3Lkr72cYnVt9q+8301Vj6LqJbo/6f2uFJ3JeDriyguz6PUOKhFveDx6 GLayzVT1+BGWHfO02TNsYa8FuxJLcUaioRZzUXEiADwXMmaZAgAA Archived-At: Cc: Peter Thatcher Subject: [Ice] ICE WG draft agenda for IETF #95 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 07:30:23 -0000 Hi all, Draft agenda for the ICE WG meeting at the IETF #95 is available here: https://www.ietf.org/proceedings/95/agenda/agenda-95-ice Please have a look at the agenda and let us know if you have any questions = or comments. Thanks, Ari & Peter (ICE WG co-chairs)= From nobody Thu Mar 24 05:26:37 2016 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 1526712DB51 for ; Thu, 24 Mar 2016 05:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zVr76d6NYCst for ; Thu, 24 Mar 2016 05:26:29 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DA612DAF5 for ; Thu, 24 Mar 2016 05:26:23 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-11-56f3dced1603 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8B.AD.30858.DECD3F65; Thu, 24 Mar 2016 13:26:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Thu, 24 Mar 2016 13:26:03 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICEbis: RTP no-op keep-alives Thread-Index: AQHRhchVN78Cvx6LjU+nHpKB2nsDAw== Date: Thu, 24 Mar 2016 12:26:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D319A9826491christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdVPftnc9hBtuO81p8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MBw+msBSc46vYeHg+cwPjap4uRk4OCQETiRevv7BD2GISF+6t ZwOxhQQOM0pMPF7ZxcgFZC9mlLiy7gRQgoODTcBCovufNkiNiICixMyWZ8wgYWEBNYm9E90h wtoSc149ZYSw9SRm7l0MNp5FQFXi0c4zYOW8AlYSt/+mgoQZgbZ+P7WGCcRmFhCXuPVkPhPE NQISS/acZ4awRSVePv7HCmKLAo3ccQ7ClgC64Or05VC98RIXJ3wDi/MKCEqcnPmEZQKj8Cwk Y2chKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+heq0l5m56yYysZgEjxypG0eLU4qTcdCMj vdSizOTi4vw8vbzUkk2MwNg5uOW3wQ7Gl88dDzEKcDAq8fB+kP8cJsSaWFZcmXuIUYKDWUmE N+U2UIg3JbGyKrUoP76oNCe1+BCjNAeLkjgv66fLYUIC6YklqdmpqQWpRTBZJg5OqQZG9lO3 liYUCnMqVmUdj2L1Ylnc6jHZZIfhy00cuW9XvjlxQ0mJ68S51xZxX5jeTr4+5Z950LaMAxvE o3e3zuBWYxZ69Xui6NV0tZwVSc95w4Vbb19OvLtATdu8PH/X5MPajFrBn2ZEyk+urTRNLKtL fFouVsDzlyvRNl8xTXyFlip38qIpKZeVWIozEg21mIuKEwF5z2azmQIAAA== Archived-At: Subject: [Ice] ICEbis: RTP no-op keep-alives X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 12:26:36 -0000 --_000_D319A9826491christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 5245bis still defines RTP no-op as a mechanism for doing keep-alives. Howev= er, AFAIK, the work on no-op has stopped, and the associated draft will not= be published as an RFC. So, we need to remove the reference from 5245bis. The question is whether we want to replace it with something else, or wheth= er STUN is the only defined mechanism for doing keep-alives. My suggestion is that 5245bis only defines the usage of STUN for keep-alive= s. Regards, Christer --_000_D319A9826491christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <32B68006BD51784B9BB00A0A15FE4827@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

5245bis still defines RTP no-op as a mechanism for doing keep-alives. = However, AFAIK, the work on no-op has stopped, and the associated draft wil= l not be published as an RFC.

So, we need to remove the reference from 5245bis.

The question is whether we want to replace it with something else, or = whether STUN is the only defined mechanism for doing keep-alives.

My suggestion is that 5245bis only defines the usage of STUN for keep-= alives.

Regards,

Christer
--_000_D319A9826491christerholmbergericssoncom_-- From nobody Thu Mar 24 07:08:32 2016 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 8A69D12DCBA for ; Thu, 24 Mar 2016 07:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-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 b05_iKxZQpUZ for ; Thu, 24 Mar 2016 07:08:27 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (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 32A4512DB9D for ; Thu, 24 Mar 2016 07:00:50 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id nk17so112690110igb.1 for ; Thu, 24 Mar 2016 07:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+tqSS1gGnpOo8hF6xQqo8c00/TzIeBaWFEaF3AgOseI=; b=kYXV0T+3zePwtGWi9+bCgOs0MJaIkI0HWSdPvQWHUCiYZ45IvbcSr87C16xI9Mp62Z 6ZJ+i2N/oDqM8x6a/iiW05uXvRVc659Wr/6nAKIb87U1Xnexi6F+5SVC9ES1y/+yKyFT T020kMhNBPQwKkxjOe+O0VDaziRcvc6YKDopFU3JVgV6++i+WW3cN5MXWhrNMiYfYb/h 57XdNt+mGIGc1R+uPpTnGmfRy+KgvunuXuyZGydtJ/V4hz3yhnRc6vByuIlfZYgGRFDw a5C4AsSUnw63WrLQxhXBVli9IYmh7y7IASyTjlLJ3BXqEaqigpL0+QaYJmpKF/WuQKOD wFaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+tqSS1gGnpOo8hF6xQqo8c00/TzIeBaWFEaF3AgOseI=; b=kMHA23y3/RV9U0fNcWH8PX3PMDkAgLE/UqEHa11hp5mPRoXCw6fn4T/9ACn9NIIxH7 MSfyrKwGx/xOd5kMSWTOaDhRSZxrQOhBokz7hzD2DMzdaDCWcF6F5gHd36HkYAFRfMk/ xiCrp/P66LV6ylpEJxpdFmPvvRgsZTwbs/8u7JqWTpEq3Ue894+htBMu/3cIEJrTDZ9Y zZvDfiJ8sit3F2YSVXa9PRGY4+BGbtqS+AtJ8q8BbZayJYyZQCeX+accrB+ZB8bKssVc +f1UnBIGu/XWHvybStVpgT9QxS1eFHew2xre/7F+KLM5kNrZC7a7BdrmQBM/2r8ePp/Q CT3w== X-Gm-Message-State: AD7BkJLIcnUrYhLREdGwI7QGrNdyvUJjS7gf5Vn29kGOG+/8heJoMcUcx8HgpgZ4NnipNw== X-Received: by 10.50.43.129 with SMTP id w1mr9177797igl.47.1458828049375; Thu, 24 Mar 2016 07:00:49 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by smtp.gmail.com with ESMTPSA id g68sm3128261ioj.29.2016.03.24.07.00.47 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2016 07:00:47 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id ig19so122838442igb.0 for ; Thu, 24 Mar 2016 07:00:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.20.161 with SMTP id o1mr27485705ige.2.1458828047212; Thu, 24 Mar 2016 07:00:47 -0700 (PDT) Received: by 10.36.106.194 with HTTP; Thu, 24 Mar 2016 07:00:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Mar 2016 10:00:47 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bd757088aea0e052ecbdf6c Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] ICEbis: RTP no-op keep-alives X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 14:08:31 -0000 --047d7bd757088aea0e052ecbdf6c Content-Type: text/plain; charset=UTF-8 On Thu, Mar 24, 2016 at 8:26 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > 5245bis still defines RTP no-op as a mechanism for doing keep-alives. > However, AFAIK, the work on no-op has stopped, and the associated draft > will not be published as an RFC. > > So, we need to remove the reference from 5245bis. > > The question is whether we want to replace it with something else, or > whether STUN is the only defined mechanism for doing keep-alives. > > My suggestion is that 5245bis only defines the usage of STUN for > keep-alives. > > I agree that RTP no-op should be removed as a keep-alive mechanism and only STUN should be left. We should also reference draft-ietf-rtcweb-stun-consent-freshness in conjunction with STUN keep-alives. _____________ Roman Shpount --047d7bd757088aea0e052ecbdf6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 24, 2016 at 8:26 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

5245bis still defines RTP no-op as a mechanism for doing keep-alives. = However, AFAIK, the work on no-op has stopped, and the associated draft wil= l not be published as an RFC.

So, we need to remove the reference from 5245bis.

The question is whether we want to replace it with something else, or = whether STUN is the only defined mechanism for doing keep-alives.

My suggestion is that 5245bis only defines the usage of STUN for keep-= alives.


I agree that RTP no-o= p should be removed as a keep-alive mechanism and only STUN should be left.= We should also reference draft-ietf-rtcweb-stun-consent-freshness in conju= nction with STUN=C2=A0keep-alives.
_____________
Roman Shpount
=C2= =A0
--047d7bd757088aea0e052ecbdf6c-- From nobody Wed Mar 30 15:20:48 2016 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 F35B612D532 for ; Wed, 30 Mar 2016 15:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 Mup0k3Qc2QUi for ; Wed, 30 Mar 2016 15:20:44 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 8F11D12D51A for ; Wed, 30 Mar 2016 15:20:44 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id r187so35402646oih.3 for ; Wed, 30 Mar 2016 15:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OWnHWAQ0lQYPkOnxZx0ccyoGtYp3lNizHjxHCyxqXoM=; b=cauk98q5zr5Zgc/LBkCSB9c6U8EqTmwLbOeEd0tgn+wVhN34VOOwQS2s8LiV3I8abR 9Xqb8pC8KgqncA6iqKT9tJHxAMSWG8HdBoCs6M0AcUK6pKhqypBhkt8Wyb+y6QHbNi0F xIKNgE8ky1Y4BWPeyjfrqiwCglcCgjfyDKhnThEhpSyrmyK6Hdyi126DWXMTJK0OKfPP 8CS5HDZotrx4b4kq9Rzz4EB5SlrR2s8JA8tyBnSaUFmqmbTbumFx3hZ3ioGMoZQ8Wl+I tpWeZwGne69B5Pn+5+RslPc+6hcwMxOsPwwJorNeIZVZtfb7kM0IrAJq7/Dpp9U3/Fzu tXqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OWnHWAQ0lQYPkOnxZx0ccyoGtYp3lNizHjxHCyxqXoM=; b=On2xLgoItpD/woA33NtJEOvj187/t4RRVAD9OV0uqEJNqIpfFuc0z4I3ts+rPxSLkL acd08nFRjr7lczaCn6ZfYVOpTr0zjfphiEyF4sv57P9G6roxj8/8qY/ew3k8qvL1lmal wTnpAivkXXx3FwZV74im0V1JHjvsL6ZW9/360uYhzV70nLK83g/+SIT1Q4QyARXZVSF6 XaWVmL6bP/xTv0gz8UqqDmoNfeQi297QXlxBRrnQLYBJiy4TzXSBwBDqq3S06kHUGdjJ mmn9HSB07CLjqrXnRS3X1PVrmcsejV6tNzQECtv6M1yAxc8YZ0FYyB/IaUL890ZGw1tc kYdw== X-Gm-Message-State: AD7BkJI7jmEspKWLN0dL5Yoh84LsQMkmTQLquTu6d9afmaFsWy3IJZRjbn3MW1yQuhtf7g== X-Received: by 10.202.95.68 with SMTP id t65mr6122660oib.7.1459376443974; Wed, 30 Mar 2016 15:20:43 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id yy7sm1815760obb.26.2016.03.30.15.20.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 15:20:43 -0700 (PDT) To: Christer Holmberg , Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> From: Emil Ivov Message-ID: <56FC513A.7080100@jitsi.org> Date: Wed, 30 Mar 2016 17:20:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 22:20:47 -0000 My concern is that Trickle ICE is supposed to be signalling agnostic. The whole part with the a= lines was only meant to be a convenience but addressing over the wire issues are supposed to be handled by other specs like Trickle ICE for SIP. Whether or not the generation needs to be signalled depends entirely on the transport. SIP for example does allow for out of order messages so it absolutely needs it and that's why that draft says: All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" attributes that would allow mapping them to a specific ICE generation. A WebRTC browser, when signalling candidates through the API does NOT need that at all because it can guarantee that candidates it trickles will be mappable to an SLD/SRD round. So, as I said, a recommendation for extending specs and implementors sounds like the best path here. Normative language sounds like going out of scope for this draft. Emil On 21.03.16 г. 13:09, Christer Holmberg wrote: > Hi, > > Is there a reason for not having MUST? > > Regards, > > Christer > > *From:*Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* 21 March 2016 19:36 > *To:* Emil Ivov > *Cc:* Christer Holmberg ; ice@ietf.org > *Subject:* Re: [Ice] Some thoughts on trickling the ufrag > > Would it make sense to have a "SHOULD signal ufrag on a trickled candidate"? > > On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov > wrote: > > Well because it's a signaling issue. IIRC it is something that we > agreed trickle ice for sip would > Include. > > I guess it's more of a question if and how it should be in trickle > ice for sip. > > The tricky part there is that this is a purely signalling issue and > trickle ice is meant to be signalling agnostic. A headsup to > implementors may therefore be more appropriate. > > Emil > > > On Sunday, 20 March 2016, Christer Holmberg > > wrote: > > Hi, > > What reason would there be for putting it in a separate draft? > > Regards, > > Christer > > *From:*Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter > Thatcher > *Sent:* 18 March 2016 07:21 > *To:* ice@ietf.org > *Subject:* [Ice] Some thoughts on trickling the ufrag > > (As an individual, not a chair) > > Earlier, we had some discussion around adding the ufrag to the > trickled candidate so that when one receives the a trickled > candidate after an ICE restart, it's clear if the candidate > applies to the ICE ufrag/pwd from before or after the ICE restart. > > I have a few thoughts/questions about this: > > 1. We saw applications where this was a real-world issue. > > 2. We implemented the addition of the ufrag to candidates in > Chrome, and it fixed the issues observed. Further, it was a > very easy fix. > > 3. Do we have consensus in the group that we should standardize > this solution? > > 4. If so, should we simply add it to the trickle-ice draft? Or > should it be a separate draft? > > Thanks, > > Peter > > -- > sent from my mobile > -- https://jitsi.org From nobody Wed Mar 30 16:16:34 2016 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 DAB9F12D1C9 for ; Wed, 30 Mar 2016 16:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vKxfyBXJ5AN7 for ; Wed, 30 Mar 2016 16:16:31 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 156E312D1CD for ; Wed, 30 Mar 2016 16:16:31 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id e185so81704850vkb.1 for ; Wed, 30 Mar 2016 16:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v9ZpKBLOdQGbOOry+aHLz6iXhM+Cq7Fhz7UbHiPaWJE=; b=loQHWQzK24GA9bcUEpXS3RHrR3zxerbfWcCtw0HS+1BeKdEkUN1S6nnvZWpjeVpO3V qW8AWfIpPjTviadvU9DAnlsjDd/LTDtM9ybzLu33aRlmZ0wr4jFFRwKFj+asVx29zwa9 tRiSb6vni8y7Gt23X4JacdYTqQKEQArhVAVfNura6jR9ZnGgVlNSfobnqU2TZQnSantG 6W7Jd1zcBK1bFa0xdsT/VPwnHUxMt2S9MpORPeF5CFRQp/gFTSCGGBjQQGJR2a9b0hw+ KOZ3/Wc5fDrs7Oj7rsOGEYzlxKGdGbGc34+nH/fJMdzsxFhx9Eahl/rKaOCYZz+AXRcT Mi1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v9ZpKBLOdQGbOOry+aHLz6iXhM+Cq7Fhz7UbHiPaWJE=; b=evSA744lq1CCBGsb6fPL7K4rWcht9Mqy3kmNV/N4i+VdY+JWcro6cEYstvKxYA+W7v ckUXJU+RWwDgA2dHn1CirGlkwWkNwuqcstA8X2HQnnRoG7jF+pWfhfcWsNAvh+YR4pm+ xThOR0OZjEu1EeqQ+q1qnPPzC77zmHvb/X2GWi9QkfJ3W/5DCWoiQrG6nwDJRHspG6Vx /kVzMjkI3Ipn2h8Tc5squrb0sPkrEgNrLXfmNrElfq/KVztS9RZSMo12kfAWI6Hd1quY L10SkA8cXbgc7CameEFB6Gad+iObBn7QqmAYtauCQHqgpULtD8WFJSBLCeMfdbcGG+1o dyQw== X-Gm-Message-State: AD7BkJLgflaYdnnHP3XDStot5sqJeogTiI9kNbpyhg9+ti+JXVID2st3UUZlj4yxkbyDynFepb5UW5Wvud23+gn6 X-Received: by 10.176.1.197 with SMTP id 63mr2649864ual.77.1459379790045; Wed, 30 Mar 2016 16:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Wed, 30 Mar 2016 16:15:50 -0700 (PDT) In-Reply-To: <56FC513A.7080100@jitsi.org> References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> From: Peter Thatcher Date: Wed, 30 Mar 2016 16:15:50 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a113dda98faa5e3052f4c555c Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 23:16:34 -0000 --001a113dda98faa5e3052f4c555c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov wrote: > My concern is that Trickle ICE is supposed to be signalling agnostic. > > The whole part with the a=3D lines was only meant to be a convenience but > addressing over the wire issues are supposed to be handled by other specs > like Trickle ICE for SIP. > > Whether or not the generation needs to be signalled depends entirely on > the transport. > > =E2=80=8BI agree that generation doesn't need to be signalled, but the ufra= g does, as I'll explain further down. > SIP for example does allow for out of order messages so it absolutely > needs it and that's why that draft says: > > All INFO requests MUST carry the "a=3Dice-pwd:" and "a=3Dice-ufrag:" > attributes that would allow mapping them to a specific ICE > generation. > > A WebRTC browser, when signalling candidates through the API does NOT nee= d > that at all because it can guarantee that candidates it trickles will be > mappable to an SLD/SRD round. > > =E2=80=8BIf there are multiple candidate gathering phases happening at the = same time right after an ICE restart, the WebRTC API does need to tell the application =E2=80=8Bwhich ufrag the candidate applies to so that the appli= cation can signal that (via whatever signalling, not just SDP), so that the remote side can know which pwd/ufrag to use when sending STUN messages. Either that or you say that after an ICE restart, you can't gather any more candidates from the previous ufrag/pwd, which I don't think is reasonable. Assuming you do allow more candidates to be gathered after an ICE restart, then you need to be able to tell if the candidate is for the ufrag/pwd before or after the restart. In other words, this isn't just a matter of message ordering or signalling transport. In a WebRTC 1.0 API, that means putting something like "ufrag foo" on the a=3Dcandidate line. In an ORTC-ish API, that means putting a .ufrag on the IceCandidate object. > So, as I said, a recommendation for extending specs and implementors > sounds like the best path here. Normative language sounds like going out = of > scope for this draft. > =E2=80=8B =E2=80=8BI think this doc should at least say "the ufrag of the candidate M= UST be signalled if the ufrag of the trickled candidate does match the ufrag since the last ICE restart" or something along those lines.=E2=80=8B > > Emil > > > On 21.03.16 =D0=B3. 13:09, Christer Holmberg wrote: > >> Hi, >> >> Is there a reason for not having MUST? >> >> Regards, >> >> Christer >> >> *From:*Peter Thatcher [mailto:pthatcher@google.com] >> *Sent:* 21 March 2016 19:36 >> *To:* Emil Ivov >> *Cc:* Christer Holmberg ; ice@ietf.org >> *Subject:* Re: [Ice] Some thoughts on trickling the ufrag >> >> Would it make sense to have a "SHOULD signal ufrag on a trickled >> candidate"? >> >> On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov > > wrote: >> >> Well because it's a signaling issue. IIRC it is something that we >> agreed trickle ice for sip would >> Include. >> >> I guess it's more of a question if and how it should be in trickle >> ice for sip. >> >> The tricky part there is that this is a purely signalling issue and >> trickle ice is meant to be signalling agnostic. A headsup to >> implementors may therefore be more appropriate. >> >> Emil >> >> >> On Sunday, 20 March 2016, Christer Holmberg >> > > wrote: >> >> Hi, >> >> What reason would there be for putting it in a separate draft? >> >> Regards, >> >> Christer >> >> *From:*Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Peter >> Thatcher >> *Sent:* 18 March 2016 07:21 >> *To:* ice@ietf.org >> *Subject:* [Ice] Some thoughts on trickling the ufrag >> >> (As an individual, not a chair) >> >> Earlier, we had some discussion around adding the ufrag to the >> trickled candidate so that when one receives the a trickled >> candidate after an ICE restart, it's clear if the candidate >> applies to the ICE ufrag/pwd from before or after the ICE restar= t. >> >> I have a few thoughts/questions about this: >> >> 1. We saw applications where this was a real-world issue. >> >> 2. We implemented the addition of the ufrag to candidates in >> Chrome, and it fixed the issues observed. Further, it was a >> very easy fix. >> >> 3. Do we have consensus in the group that we should standardize >> this solution? >> >> 4. If so, should we simply add it to the trickle-ice draft? Or >> should it be a separate draft? >> >> Thanks, >> >> Peter >> >> -- >> sent from my mobile >> >> > -- > https://jitsi.org > --001a113dda98faa5e3052f4c555c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov <emcho@jitsi.org> wrote:
My concern is that Trickle ICE is supp= osed to be signalling agnostic.

The whole part with the a=3D lines was only meant to be a convenience but a= ddressing over the wire issues are supposed to be handled by other specs li= ke Trickle ICE for SIP.

Whether or not the generation needs to be signalled depends entirely on the= transport.


=E2=80=8BI agree that generation does= n't need to be signalled, but the ufrag does, as I'll explain furth= er down.
=C2=A0
SIP for example does allow for out of order messages so it absolutely needs= it and that's why that draft says:

=C2=A0 =C2=A0All INFO requests MUST carry the "a=3Dice-pwd:" and = "a=3Dice-ufrag:"
=C2=A0 =C2=A0attributes that would allow mapping them to a specific ICE
=C2=A0 =C2=A0generation.

A WebRTC browser, when signalling candidates through the API does NOT need = that at all because it can guarantee that candidates it trickles will be ma= ppable to an SLD/SRD round.


=E2=80=8BIf there are multiple cand= idate gathering phases happening at the same time right after an ICE restar= t, the WebRTC API does need to tell the application =E2=80=8Bwhich ufrag th= e candidate applies to so that the application can signal that (via whateve= r signalling, not just SDP), so that the remote side can know which pwd/ufr= ag to use when sending STUN messages.=C2=A0 Either that or you say that aft= er an ICE restart, you can't gather any more candidates from the previo= us ufrag/pwd, which I don't think is reasonable. =C2=A0 Assuming you do= allow more candidates to be gathered after an ICE restart, then you need t= o be able to tell if the candidate is for the ufrag/pwd before or after the= restart.

In other words, this isn't just a matter= of message ordering or signalling transport.

In a We= bRTC 1.0 API, that means putting something like "ufrag foo" on th= e a=3Dcandidate line.=C2=A0 In an ORTC-ish API, that means putting a .ufrag= on the IceCandidate object.

=C2=A0
So, as I said, a recommendation for extending specs and implementors sounds= like the best path here. Normative language sounds like going out of scope= for this draft.
=E2=80=8B
=E2= =80=8BI think this doc should at least say "the ufrag of the candidate= MUST be signalled if the ufrag of the trickled candidate does match the uf= rag since the last ICE restart" or something along those lines.=E2=80= =8B

=C2=A0

Emil


On 21.03.16 =D0=B3. 13:09, Christer Holmberg wrote:
Hi,

Is there a reason for not having MUST?

Regards,

Christer

 *From:*Peter Thatcher [mailto:pthatcher@google.com]
*Sent:* 21 March 2016 19:36
*To:* Emil Ivov <em= cho@jitsi.org>
*Cc:* Christer Holmberg <christer.holmberg@ericsson.com>; ice@ietf.org
*Subject:* Re: [Ice] Some thoughts on trickling the ufrag<= br>
Would it make sense to have a "SHOULD signal ufrag on a trickled candi= date"?

On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <emcho@jitsi.org
 <mailto:emcho@jitsi= .org>> wrote:

=C2=A0 =C2=A0 Well because it's a signaling issue. IIRC it is something= that we
=C2=A0 =C2=A0 agreed trickle ice for sip would
=C2=A0 =C2=A0 Include.

=C2=A0 =C2=A0 I guess it's more of a question if and how it should be i= n trickle
=C2=A0 =C2=A0 ice for sip.

=C2=A0 =C2=A0 The tricky part there is that this is a purely signalling iss= ue and
=C2=A0 =C2=A0 trickle ice is meant to be signalling agnostic. A headsup to<= br> =C2=A0 =C2=A0 implementors may therefore be more appropriate.

=C2=A0 =C2=A0 Emil


=C2=A0 =C2=A0 On Sunday, 20 March 2016, Christer Holmberg
=C2=A0 =C2=A0 <christer.holmberg@ericsson.com
 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What reason would there be for putting it in a = separate draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*Ice [mailto:ice-bounces@ietf.org] *On Behalf Of *Pete= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thatcher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:* 18 March 2016 07:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:* ice@ietf.org <mailto:ice@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject:* [Ice] Some thoughts on trickling the= ufrag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (As an individual, not a chair)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Earlier, we had some discussion around adding t= he ufrag to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trickled candidate so that when one receives th= e a trickled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate after an ICE restart, it's clear = if the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 applies to the ICE ufrag/pwd from before or aft= er the ICE restart.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I have a few thoughts/questions about this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 1.=C2=A0 We saw applications where this was a r= eal-world issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2.=C2=A0 We implemented the addition of the ufr= ag to candidates in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Chrome, and it fixed the issues observed.=C2=A0= Further, it was a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 very easy fix.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.=C2=A0 Do we have consensus in the group that= we should standardize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 this solution?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 4.=C2=A0 If so, should we simply add it to the = trickle-ice draft?=C2=A0 Or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 should it be a separate draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 sent from my mobile


--
https://= jitsi.org

--001a113dda98faa5e3052f4c555c-- From nobody Wed Mar 30 19:11:47 2016 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 6EF7112D1E3 for ; Wed, 30 Mar 2016 19:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 2V5NbAT8L7aV for ; Wed, 30 Mar 2016 19:11:43 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (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 D0BFC12D54E for ; Wed, 30 Mar 2016 19:04:48 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id nk17so116452520igb.1 for ; Wed, 30 Mar 2016 19:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=bR1QoKTYf61fzu9dwEYZliNnmo0ZF+sy0vaSK8G+tg8=; b=MoYsDcMTZcG9geouhuOMt5bCsnyzOIEvMRX2WCMYlZu1VqU9b9lETyZpGUFB2wxUCw P4cy0OumLKOI5P+8Lx/HCUtsQGM8CPl7k4dPqwpUgftIr3cTCmUPMl/aRPWuRYMUpZZW yLRGOBoIR2Id7U3zOIGjLlBJQL9tQb0DPsSsGHLpv1ptkXPxflDMwkJPS0qRBlhxZ6rv sUxGdzslPdzsbd4LZkql0AmfC0oY8RW/5Rqr4wPIoCgh+cNDZRqGTjbdpci9AugoiKAP No1nvtMhRK1Ms/jkRKLWz4Xs/rHGuKpzDQCvpWimLJ28FFDgl3c6E8XcVTLBVgYvYeAl 9K0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bR1QoKTYf61fzu9dwEYZliNnmo0ZF+sy0vaSK8G+tg8=; b=VpGbtf6PU8MAUv1I6OvMrScrbWMyWYaQE6CmPjej8HOV4ovv8o3wsYvGHItrxueLea Yvfa5ScnzhjXAi47r9K/za78cTdc39p0EyRXUSuD/2W8xIMpbcVb9ksbvwPJ3mssn9hG bFYd84tR1Ke1VLqEJnG22c1MzJrAoC0P7aDKSBxPOW1sq2LAXGyY0Uq7fV6sYEj0/L44 SqpHfqiJV80cLeiAwEHwpsFSOJeE9wi4rF+cqYgn2F/9aPTXdOfo0NrGmi4sf54dA72e fv8kya6hokmlBW73Yd6VO4MGWR4YcAXr/3eqB1y714DBnfCPkr4fltAlqevobc1p/UFY yocw== X-Gm-Message-State: AD7BkJI+m0ikTyz4rKP2Ys8BSpVGPMZcL5Vgl+PAplEgrjIT6HIP3R6Yg44+l/uF/zsNdQ== X-Received: by 10.50.72.82 with SMTP id b18mr434301igv.79.1459389888035; Wed, 30 Mar 2016 19:04:48 -0700 (PDT) Received: from camionet.local ([2602:306:83fc:cd90:29a4:d4ba:fd7:3c97]) by smtp.googlemail.com with ESMTPSA id ip3sm2947369igb.14.2016.03.30.19.04.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 19:04:47 -0700 (PDT) To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> From: Emil Ivov Message-ID: <56FC85BD.7090002@jitsi.org> Date: Wed, 30 Mar 2016 21:04:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 02:11:45 -0000 On 30.03.16 г. 18:15, Peter Thatcher wrote: > > On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov >wrote: > > My concern is that Trickle ICE is supposed to be signalling agnostic. > > The whole part with the a= lines was only meant to be a convenience > but addressing over the wire issues are supposed to be handled by > other specs like Trickle ICE for SIP. > > Whether or not the generation needs to be signalled depends entirely > on the transport. > > > ​I agree that generation doesn't need to be signalled, but the ufrag > does, as I'll explain further down. > > SIP for example does allow for out of order messages so it > absolutely needs it and that's why that draft says: > > All INFO requests MUST carry the "a=ice-pwd:" and "a=ice-ufrag:" > attributes that would allow mapping them to a specific ICE > generation. > > A WebRTC browser, when signalling candidates through the API does > NOT need that at all because it can guarantee that candidates it > trickles will be mappable to an SLD/SRD round. > > > ​If there are multiple candidate gathering phases happening at the same > time right after an ICE restart, I am not sure I understand what this means -> "multiple candidate gathering phases happening at the same time" Do you mean something like several PeerConnection-s restarting simultaneously? Or some ICE concurrent phases that have not been defined yet? > the WebRTC API does need to tell the > application ​which ufrag the candidate applies to so that the > application can signal that (via whatever signalling, not just SDP), so > that the remote side can know which pwd/ufrag to use when sending STUN > messages. Either that or you say that after an ICE restart, you can't > gather any more candidates from the previous ufrag/pwd, which I don't > think is reasonable. Assuming you do allow more candidates to be > gathered after an ICE restart, then you need to be able to tell if the > candidate is for the ufrag/pwd before or after the restart. ICE restarts can obviously yield new candidates and they all have a new ufrag/pwd that a WebRTC client will learn the same way it learned the first one: by getting the offer/answer from the browser. In other words, during an ice restart, all checks have the same ufrag and password even if some or all the candidates are the same as before. This is how 5245 works and there is no reason for trickle ICE to break that rule. In fact it strives to be backward compatible so ... > In other words, this isn't just a matter of message ordering or > signalling transport. > > In a WebRTC 1.0 API, that means putting something like "ufrag foo" on > the a=candidate line. In an ORTC-ish API, that means putting a .ufrag > on the IceCandidate object. > > So, as I said, a recommendation for extending specs and implementors > sounds like the best path here. Normative language sounds like going > out of scope for this draft. > > ​ > ​I think this doc should at least say "the ufrag of the candidate MUST > be signalled if the ufrag of the trickled candidate does match the ufrag > since the last ICE restart" or something along those lines.​ The point is that it would never match the ufrag from before the restart, and yes it must be signalled exactly as the first one, but not on a per-candidate level. Emil > > > Emil > > > On 21.03.16 г. 13:09, Christer Holmberg wrote: > > Hi, > > Is there a reason for not having MUST? > > Regards, > > Christer > > *From:*Peter Thatcher [mailto:pthatcher@google.com > ] > *Sent:* 21 March 2016 19:36 > *To:* Emil Ivov > > *Cc:* Christer Holmberg >; ice@ietf.org > > *Subject:* Re: [Ice] Some thoughts on trickling the ufrag > > Would it make sense to have a "SHOULD signal ufrag on a trickled > candidate"? > > On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov > >> wrote: > > Well because it's a signaling issue. IIRC it is something > that we > agreed trickle ice for sip would > Include. > > I guess it's more of a question if and how it should be in > trickle > ice for sip. > > The tricky part there is that this is a purely signalling > issue and > trickle ice is meant to be signalling agnostic. A headsup to > implementors may therefore be more appropriate. > > Emil > > > On Sunday, 20 March 2016, Christer Holmberg > > >> wrote: > > Hi, > > What reason would there be for putting it in a separate > draft? > > Regards, > > Christer > > *From:*Ice [mailto:ice-bounces@ietf.org > ] *On Behalf Of *Peter > Thatcher > *Sent:* 18 March 2016 07:21 > *To:* ice@ietf.org > > > *Subject:* [Ice] Some thoughts on trickling the ufrag > > (As an individual, not a chair) > > Earlier, we had some discussion around adding the ufrag > to the > trickled candidate so that when one receives the a trickled > candidate after an ICE restart, it's clear if the candidate > applies to the ICE ufrag/pwd from before or after the > ICE restart. > > I have a few thoughts/questions about this: > > 1. We saw applications where this was a real-world issue. > > 2. We implemented the addition of the ufrag to > candidates in > Chrome, and it fixed the issues observed. Further, it > was a > very easy fix. > > 3. Do we have consensus in the group that we should > standardize > this solution? > > 4. If so, should we simply add it to the trickle-ice > draft? Or > should it be a separate draft? > > Thanks, > > Peter > > -- > sent from my mobile > > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Wed Mar 30 19:59:04 2016 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 F109E12D549 for ; Wed, 30 Mar 2016 19:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 sh4Zukpz5d5X for ; Wed, 30 Mar 2016 19:58:59 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 7219812D1EB for ; Wed, 30 Mar 2016 19:58:59 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id k1so87161427vkb.0 for ; Wed, 30 Mar 2016 19:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oA5cR90US849r0IxP7/JGBpykpHHx+Bi6I0YRCuqCAo=; b=StA/9FLXTUoEVinFziXR4IMlHPFUNTDlH8vsIYgz7/D1zVd6KBt7AMdg6yeJEW0bnC R+eO/WMxEfvouE48WQyqvWwZiZ3Na7tPkwci5QFzJ7Usu0WrDFLNYvXSeRAN+kS5nmQm vZOwWWi5lZH9klf+joXy5+b36Fqiojw4JbyucyC2jK6z5OEqwZMOXi6dCVv87A2zdB2I kIhp9Wu5N1lgyHEfs6ATkC3dZm9HO05ZM/5b4Ht+5oFtX9l+Cvzm8DsZLoOVXfudGqz+ fb6JRyataH1mzhALipaOZO6iTcHhzsoPuGRhA/E7d5kUvegE+iSBM9sjABz5CJ/OsTaB mjWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oA5cR90US849r0IxP7/JGBpykpHHx+Bi6I0YRCuqCAo=; b=Jb2KJSdPtcGn6oM194F1R8AlVvKtItt66CCb0GfaPEgK5dMgrq5edvlNk1Fzl+s+VI OBw4PPdHjYI8X9jm/XTsKrrbKd7y6pQPPOl2J/8HQk4jwh7c96cd0VJplwcaHui5mXJl NLYdS+jJDdwAy98IAHfXgumLvBEuzI1PYPVTHIS0UFSfzgOZm9np1fIAYHMG5SX75eOT 8GLR8tDl0XJN5YsdKFHG2AmaXwqzXRJBW7ZKHZlaSujv/YAIfOhdG9+IM3RXds95vIiu +wz1eTav8KjmKQ+l9MA2DV4lCf/yJAsg4VK/BpV6cCJqUlHtyem4PscjTuU1BCezquye 9l2w== X-Gm-Message-State: AD7BkJKlYUTYcm0NWzaRm9HmWxj3xvPXL1ld25vUm4E4DH8GASYtpi0ekfBm9Ij7043F2iHbkQ2kmQa+6L+CeSA3 X-Received: by 10.31.58.193 with SMTP id h184mr7550924vka.111.1459393138369; Wed, 30 Mar 2016 19:58:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Wed, 30 Mar 2016 19:58:18 -0700 (PDT) In-Reply-To: <56FC85BD.7090002@jitsi.org> References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> <56FC85BD.7090002@jitsi.org> From: Peter Thatcher Date: Wed, 30 Mar 2016 19:58:18 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a1143ff7099f4f9052f4f7156 Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 02:59:03 -0000 --001a1143ff7099f4f9052f4f7156 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov wrote: > On 30.03.16 =D0=B3. 18:15, Peter Thatcher wrote: > >> >> On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov > >wrote: >> >> My concern is that Trickle ICE is supposed to be signalling agnostic= . >> >> The whole part with the a=3D lines was only meant to be a convenienc= e >> but addressing over the wire issues are supposed to be handled by >> other specs like Trickle ICE for SIP. >> >> Whether or not the generation needs to be signalled depends entirely >> on the transport. >> >> >> =E2=80=8BI agree that generation doesn't need to be signalled, but the u= frag >> does, as I'll explain further down. >> >> SIP for example does allow for out of order messages so it >> absolutely needs it and that's why that draft says: >> >> All INFO requests MUST carry the "a=3Dice-pwd:" and "a=3Dice-ufr= ag:" >> attributes that would allow mapping them to a specific ICE >> generation. >> >> A WebRTC browser, when signalling candidates through the API does >> NOT need that at all because it can guarantee that candidates it >> trickles will be mappable to an SLD/SRD round. >> >> >> =E2=80=8BIf there are multiple candidate gathering phases happening at t= he same >> time right after an ICE restart, >> > > I am not sure I understand what this means -> "multiple candidate > gathering phases happening at the same time" > > =E2=80=8BA timeline like this: 1. ufrag =3D X 2. candidate 1 (tied to ufrag =3D X) 3. restart to ufrag =3D Y 4. candidate 2 (tied to ufrag =3D X) 5. candidate 3 (tied to ufrag =3D Y) When you receive candidate 2, how do you know which ufrag it's supposed to have?=E2=80=8B This is the issue Lennox brought up in Yokohama. And since then we have observed it in production systems as well. Either you disallow trickling candidate 2 or you indicate somehow that its ufrag is X, not Y. But you can't trickle it without indicating that it has ufrag X. Otherwise, you'd think it was Y and be wrong. > Do you mean something like several PeerConnection-s restarting > simultaneously? Or some ICE concurrent phases that have not been defined > yet? > > the WebRTC API does need to tell the >> application =E2=80=8Bwhich ufrag the candidate applies to so that the >> application can signal that (via whatever signalling, not just SDP), so >> that the remote side can know which pwd/ufrag to use when sending STUN >> messages. Either that or you say that after an ICE restart, you can't >> gather any more candidates from the previous ufrag/pwd, which I don't >> think is reasonable. Assuming you do allow more candidates to be >> gathered after an ICE restart, then you need to be able to tell if the >> candidate is for the ufrag/pwd before or after the restart. >> > > ICE restarts can obviously yield new candidates and they all have a new > ufrag/pwd that a WebRTC client will learn the same way it learned the fir= st > one: by getting the offer/answer from the browser. > In other words, during an ice restart, all checks have the same ufrag and > password even if some or all the candidates are the same as before. > =E2=80=8BYou're assuming you can only send checks to one set of candidates = at the same time. But if ICE wasn't complete when you restarted ICE, then you have two sets of candidates you can send checks to: the ones from before the restart, and the ones for after > > This is how 5245 works and there is no reason for trickle ICE to break > that rule. In fact it strives to be backward compatible so ... =E2=80=8BExcept that if you are sending checks to two different sets of can= didates at the same time, you need to know which set a candidate belongs to. So you either say 5245 disallows sending checks to more than one set of candidates at the same time (which I don't believe it does, and shouldn't), or you disallow trickling candidates to the pre-restart set of candidates (which would be suboptimal) or you indicate which set of candidates the candidate applies to (its ufrag). > > > In other words, this isn't just a matter of message ordering or >> signalling transport. >> >> In a WebRTC 1.0 API, that means putting something like "ufrag foo" on >> the a=3Dcandidate line. In an ORTC-ish API, that means putting a .ufrag >> on the IceCandidate object. >> >> So, as I said, a recommendation for extending specs and implementors >> sounds like the best path here. Normative language sounds like going >> out of scope for this draft. >> >> =E2=80=8B >> =E2=80=8BI think this doc should at least say "the ufrag of the candidat= e MUST >> be signalled if the ufrag of the trickled candidate does match the ufrag >> since the last ICE restart" or something along those lines.=E2=80=8B >> > > The point is that it would never match the ufrag from before the restart, First: why not match the ufrag from before? Are you suggesting is forbidden by the spec or allowed but not a good idea? Secondly: production applications are already matching the ufrag from before the restart. That's why Lennox brought it up, and that's what Chrome (and any mobile app using Chrome's ICE stack) does. That's why we're proposing adding ufrag to the candidate: it's a simple fix to a production problem. > and yes it must be signalled exactly as the first one, but not on a > per-candidate level. > Emil > > >> >> Emil >> >> >> On 21.03.16 =D0=B3. 13:09, Christer Holmberg wrote: >> >> Hi, >> >> Is there a reason for not having MUST? >> >> Regards, >> >> Christer >> >> *From:*Peter Thatcher [mailto:pthatcher@google.com >> ] >> *Sent:* 21 March 2016 19:36 >> *To:* Emil Ivov > >> *Cc:* Christer Holmberg > >; ice@ietf.org >> >> *Subject:* Re: [Ice] Some thoughts on trickling the ufrag >> >> Would it make sense to have a "SHOULD signal ufrag on a trickled >> candidate"? >> >> On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov > >> >> wrote: >> >> Well because it's a signaling issue. IIRC it is something >> that we >> agreed trickle ice for sip would >> Include. >> >> I guess it's more of a question if and how it should be in >> trickle >> ice for sip. >> >> The tricky part there is that this is a purely signalling >> issue and >> trickle ice is meant to be signalling agnostic. A headsup t= o >> implementors may therefore be more appropriate. >> >> Emil >> >> >> On Sunday, 20 March 2016, Christer Holmberg >> > >> > >> wrote: >> >> Hi, >> >> What reason would there be for putting it in a separate >> draft? >> >> Regards, >> >> Christer >> >> *From:*Ice [mailto:ice-bounces@ietf.org >> ] *On Behalf Of *Peter >> Thatcher >> *Sent:* 18 March 2016 07:21 >> *To:* ice@ietf.org >> > >> >> *Subject:* [Ice] Some thoughts on trickling the ufrag >> >> (As an individual, not a chair) >> >> Earlier, we had some discussion around adding the ufrag >> to the >> trickled candidate so that when one receives the a >> trickled >> candidate after an ICE restart, it's clear if the >> candidate >> applies to the ICE ufrag/pwd from before or after the >> ICE restart. >> >> I have a few thoughts/questions about this: >> >> 1. We saw applications where this was a real-world >> issue. >> >> 2. We implemented the addition of the ufrag to >> candidates in >> Chrome, and it fixed the issues observed. Further, it >> was a >> very easy fix. >> >> 3. Do we have consensus in the group that we should >> standardize >> this solution? >> >> 4. If so, should we simply add it to the trickle-ice >> draft? Or >> should it be a separate draft? >> >> Thanks, >> >> Peter >> >> -- >> sent from my mobile >> >> >> -- >> https://jitsi.org >> >> >> > -- > https://jitsi.org > --001a1143ff7099f4f9052f4f7156 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov &= lt;emcho@jitsi.org= > wrote:
On 30= .03.16 =D0=B3. 18:15, Peter Thatcher wrote:

On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov <emcho@jitsi.org
 <mailto:emcho@jitsi= .org>>wrote:

=C2=A0 =C2=A0 My concern is that Trickle ICE is supposed to be signalling a= gnostic.

=C2=A0 =C2=A0 The whole part with the a=3D lines was only meant to be a con= venience
=C2=A0 =C2=A0 but addressing over the wire issues are supposed to be handle= d by
=C2=A0 =C2=A0 other specs like Trickle ICE for SIP.

=C2=A0 =C2=A0 Whether or not the generation needs to be signalled depends e= ntirely
=C2=A0 =C2=A0 on the transport.


=E2=80=8BI agree that generation doesn't need to be signalled, but the = ufrag
does, as I'll explain further down.

=C2=A0 =C2=A0 SIP for example does allow for out of order messages so it =C2=A0 =C2=A0 absolutely needs it and that's why that draft says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 All INFO requests MUST carry the "a=3Dice-= pwd:" and "a=3Dice-ufrag:"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attributes that would allow mapping them to a s= pecific ICE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 generation.

=C2=A0 =C2=A0 A WebRTC browser, when signalling candidates through the API = does
=C2=A0 =C2=A0 NOT need that at all because it can guarantee that candidates= it
=C2=A0 =C2=A0 trickles will be mappable to an SLD/SRD round.


=E2=80=8BIf there are multiple candidate gathering phases happening at the = same
time right after an ICE restart,

I am not sure I understand what this means -> "multiple candidate g= athering phases happening at the same time"


=E2=80=8BA timeline like this:

1. =C2=A0ufrag =3D X
2. =C2=A0candidate 1 (tied to= ufrag =3D X)
3. =C2=A0restart to ufrag =3D Y
4. =C2=A0cand= idate 2 (tied to ufrag =3D X)
5. =C2=A0candidate 3 (tied to ufrag = =3D Y)

When you receive candidate 2, how do you know w= hich ufrag it's supposed to have?=E2=80=8B

Thi= s is the issue Lennox brought up in Yokohama.=C2=A0 And since then we have = observed it in production systems as well.=C2=A0 Either you disallow trickl= ing candidate 2 or you indicate somehow that its ufrag is X, not Y.=C2=A0 B= ut you can't trickle it without indicating that it has ufrag X.=C2=A0 O= therwise, you'd think it was Y and be wrong.

=C2=A0=
Do you mean something like several PeerConnection-s restarting simultaneous= ly? Or some ICE concurrent phases that have not been defined yet?

the WebRTC API does need to tell the
application =E2=80=8Bwhich ufrag the candidate applies to so that the
application can signal that (via whatever signalling, not just SDP), so
that the remote side can know which pwd/ufrag to use when sending STUN
messages.=C2=A0 Either that or you say that after an ICE restart, you can&#= 39;t
gather any more candidates from the previous ufrag/pwd, which I don't think is reasonable.=C2=A0 =C2=A0Assuming you do allow more candidates to b= e
gathered after an ICE restart, then you need to be able to tell if the
candidate is for the ufrag/pwd before or after the restart.

 ICE restarts can obviously yield new candidates and they all have a new ufr= ag/pwd that a WebRTC client will learn the same way it learned the first on= e: by getting the offer/answer from the browser.

In other words, during an ice restart, all checks have the same ufrag and p= assword even if some or all the candidates are the same as before.

=E2=80=8BYou're assuming you can only send checks to one s= et of candidates at the same time.=C2=A0 But if ICE wasn't complete whe= n you restarted ICE, then you have two sets of candidates you can send chec= ks to: the ones from before the restart, and the ones for after
=C2=A0

This is how 5245 works and there is no reason for trickle ICE to break that= rule. In fact it strives to be backward compatible so ...

=E2=80=8BExcept that if you are sending checks to two di= fferent sets of candidates at the same time, you need to know which set a c= andidate belongs to.=C2=A0 So you either say 5245 disallows sending checks = to more than one set of candidates at the same time (which I don't beli= eve it does, and shouldn't), or you disallow trickling candidates to th= e pre-restart set of candidates (which would be suboptimal) or you indicate= which set of candidates the candidate applies to (its ufrag).

=C2=A0


In other words, this isn't just a matter of message ordering or
signalling transport.

In a WebRTC 1.0 API, that means putting something like "ufrag foo"= ; on
the a=3Dcandidate line.=C2=A0 In an ORTC-ish API, that means putting a .ufr= ag
on the IceCandidate object.

=C2=A0 =C2=A0 So, as I said, a recommendation for extending specs and imple= mentors
=C2=A0 =C2=A0 sounds like the best path here. Normative language sounds lik= e going
=C2=A0 =C2=A0 out of scope for this draft.

=E2=80=8B
=E2=80=8BI think this doc should at least say "the ufrag of the candid= ate MUST
be signalled if the ufrag of the trickled candidate does match the ufrag since the last ICE restart" or something along those lines.=E2=80=8B

The point is that it would never match the ufrag from before the restart, <= /blockquote>

First: why not match the ufrag from befo= re?=C2=A0 Are you suggesting is forbidden by the spec or allowed but not a = good idea?

Secondly: production applications are alrea= dy matching the ufrag from before the restart.=C2=A0 That's why Lennox = brought it up, and that's what Chrome (and any mobile app using Chrome&= #39;s ICE stack) does.=C2=A0 That's why we're proposing adding ufra= g to the candidate: it's a simple fix to a production problem.
=C2=A0
and yes it must be s= ignalled exactly as the first one, but not on a per-candidate level.

Emil



=C2=A0 =C2=A0 Emil


=C2=A0 =C2=A0 On 21.03.16 =D0=B3. 13:09, Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is there a reason for not having MUST?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 *From:*Peter Thatcher [mailto:pthatcher@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pthatcher@google.com>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Sent:* 21 March 2016 19:36
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *To:* Emil Ivov <emcho@jitsi.org <mailto:emcho@jitsi.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Cc:* Christer Holmberg <christer.holmberg@ericsson= .com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>>;= ice@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 *Subject:* Re: [Ice] Some thoughts on trickling= the ufrag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Would it make sense to have a "SHOULD sign= al ufrag on a trickled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate"?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov <= emcho@jitsi.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Well because it's a sig= naling issue. IIRC it is something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0agreed trickle ice for sip = would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Include.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I guess it's more of a = question if and how it should be in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trickle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ice for sip.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The tricky part there is th= at this is a purely signalling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 issue and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trickle ice is meant to be = signalling agnostic. A headsup to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementors may therefore = be more appropriate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Emil


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sunday, 20 March 2016, C= hrister Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<christer.holmberg@ericsson.com=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>
<= /span> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:christer.holmberg@erics= son.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>>&= gt; wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What reason w= ould there be for putting it in a separate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From:*Ice [m= ailto:ice-bounces= @ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice-bounces@ietf.org>] *On Behalf Of *Peter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thatcher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Sent:* 18 Ma= rch 2016 07:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To:* ice@ietf.org <mailto:ice@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice@ietf.org <mailto:ice@ietf.org>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject:* [I= ce] Some thoughts on trickling the ufrag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(As an indivi= dual, not a chair)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Earlier, we h= ad some discussion around adding the ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trickled cand= idate so that when one receives the a trickled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidate aft= er an ICE restart, it's clear if the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0applies to th= e ICE ufrag/pwd from before or after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ICE restart.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I have a few = thoughts/questions about this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 We s= aw applications where this was a real-world issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.=C2=A0 We i= mplemented the addition of the ufrag to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidates in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Chrome, and i= t fixed the issues observed.=C2=A0 Further, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 was a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0very easy fix= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.=C2=A0 Do w= e have consensus in the group that we should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standardize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this solution= ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04.=C2=A0 If s= o, should we simply add it to the trickle-ice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft?=C2=A0 Or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should it be = a separate draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Peter

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sent from my mobile


=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 https://jitsi.org



--
https://= jitsi.org

--001a1143ff7099f4f9052f4f7156-- From nobody Wed Mar 30 20:35:37 2016 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 C4F3212D175 for ; Wed, 30 Mar 2016 20:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 9F4BOxMfOdaB for ; Wed, 30 Mar 2016 20:35:33 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 EF07A12D523 for ; Wed, 30 Mar 2016 20:35:32 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 191so110789072wmq.0 for ; Wed, 30 Mar 2016 20:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=pVu7kylYJH0FPzbhdzVji8TSiulhETn4F7OZ94zpr38=; b=BzpBGW1D2L/XwOg9GOq3larN39PbQIJYiHt9mrUIMuJS0g5EyTuYJGRl8fWrgE/BvA wE163k5TiFoExXHH7/FuAPz1+Y2EZ61AL6SBc3C9nsw80TGVHH5SwmzW6sKDeSE3tJBI ef/ubFa109o2O9Ru9DdRwGmUHCVTQ0ACY3b8WemJpiKeZuJNbzu3yW+o5V9i8hUyWpod RPJdc/hncuWfpHyyWofPranifWIWDhuY7uDw5hVHuS179lxd/BaoAwO5/MIiqguGuofm 0eLtMQ+O7BtnkEQiJUV/LIMKuJqfdYp0hbJdvR86b9Bqxe6n1z3sW3KLu/oH+ffFTIcJ Fsow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=pVu7kylYJH0FPzbhdzVji8TSiulhETn4F7OZ94zpr38=; b=WUKXmNKsnPiOl8ezcuUlgehInnH2gh/AUtfH43pvoaqlnRCuO5OXYkA3/iusEHU2eH LtQ+33TjPqiX9UclwdhIDKr34VEvDBlir6CcEIDyZwp7fIZr1lUNL+btO1ALm4OO5SHL K5K0zHDVgjPWQOo4g7/3NXtHIJ8uw0iU/lL5iIJb4lC1NrNI+RoTyPixBDLA9AjBF+ad dl5CBJ2e+/9AdI8dfCUzz9PG2Oa/xs/eRaZtAf8M7cq5MIYp2ebKNyAZHGZ1bgrlN3+M KBF/7n3uJqiT5307/dmX/NKUxCBQeypQ26p41felOillaIvvdV4m/Y+4ptJImvXhBIOb 3hgQ== X-Gm-Message-State: AD7BkJL4acfFOQ4yik6NiStjkynnN51Fku4CyjS+2H6WCEurnR2ZHEb9AVgm27g8yfgmog== X-Received: by 10.28.216.141 with SMTP id p135mr27649097wmg.22.1459395331395; Wed, 30 Mar 2016 20:35:31 -0700 (PDT) Received: from camionet.local ([81.171.75.152]) by smtp.googlemail.com with ESMTPSA id q62sm22650105wmg.12.2016.03.30.20.35.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 20:35:30 -0700 (PDT) To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> <56FC85BD.7090002@jitsi.org> From: Emil Ivov Message-ID: <56FC9AFE.1090002@jitsi.org> Date: Wed, 30 Mar 2016 22:35:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 03:35:36 -0000 On 30.03.16 г. 21:58, Peter Thatcher wrote: > > > On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov > wrote: > > On 30.03.16 г. 18:15, Peter Thatcher wrote: > > > On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov > >>wrote: > > My concern is that Trickle ICE is supposed to be signalling > agnostic. > > The whole part with the a= lines was only meant to be a > convenience > but addressing over the wire issues are supposed to be > handled by > other specs like Trickle ICE for SIP. > > Whether or not the generation needs to be signalled depends > entirely > on the transport. > > > ​I agree that generation doesn't need to be signalled, but the ufrag > does, as I'll explain further down. > > SIP for example does allow for out of order messages so it > absolutely needs it and that's why that draft says: > > All INFO requests MUST carry the "a=ice-pwd:" and > "a=ice-ufrag:" > attributes that would allow mapping them to a specific ICE > generation. > > A WebRTC browser, when signalling candidates through the > API does > NOT need that at all because it can guarantee that > candidates it > trickles will be mappable to an SLD/SRD round. > > > ​If there are multiple candidate gathering phases happening at > the same > time right after an ICE restart, > > > I am not sure I understand what this means -> "multiple candidate > gathering phases happening at the same time" > > > ​A timeline like this: > > 1. ufrag = X > 2. candidate 1 (tied to ufrag = X) > 3. restart to ufrag = Y > 4. candidate 2 (tied to ufrag = X) > 5. candidate 3 (tied to ufrag = Y) > > When you receive candidate 2, how do you know which ufrag it's supposed > to have?​ > > This is the issue Lennox brought up in Yokohama. And since then we have > observed it in production systems as well. Either you disallow > trickling candidate 2 or you indicate somehow that its ufrag is X, not > Y. But you can't trickle it without indicating that it has ufrag X. > Otherwise, you'd think it was Y and be wrong. I think the confusion persists. I never said you shouldn't signal it. In fact in many cases, like SIP, you must or otherwise you get in ambiguous situations. That's why we added this to trickle ICE for SIP. What I did say is that signalling is not always necessary, and I pointed out that the WebRTC API is one case where it is not. > Do you mean something like several PeerConnection-s restarting > simultaneously? Or some ICE concurrent phases that have not been > defined yet? > > the WebRTC API does need to tell the > application ​which ufrag the candidate applies to so that the > application can signal that (via whatever signalling, not just > SDP), so > that the remote side can know which pwd/ufrag to use when > sending STUN > messages. Either that or you say that after an ICE restart, you > can't > gather any more candidates from the previous ufrag/pwd, which I > don't > think is reasonable. Assuming you do allow more candidates to be > gathered after an ICE restart, then you need to be able to tell > if the > candidate is for the ufrag/pwd before or after the restart. > > > ICE restarts can obviously yield new candidates and they all have a > new ufrag/pwd that a WebRTC client will learn the same way it > learned the first one: by getting the offer/answer from the browser. > > > In other words, during an ice restart, all checks have the same > ufrag and password even if some or all the candidates are the same > as before. > > > ​You're assuming you can only send checks to one set of candidates at > the same time. I am assuming no such thing. I think what might have led you to believe I did is my WebRTC example in which I said the browser didn't need to signal ufrag on a per-candidate level. And it doesn't. It should simply signal them in the offer or answer because they are the same for all candidates. > But if ICE wasn't complete when you restarted ICE, then > you have two sets of candidates you can send checks to: the ones from > before the restart, and the ones for after You absolutely do. There is no argument here. > This is how 5245 works and there is no reason for trickle ICE to > break that rule. In fact it strives to be backward compatible so ... > > > ​Except that if you are sending checks to two different sets of > candidates at the same time, you need to know which set a candidate > belongs to. Totally. > So you either say 5245 disallows sending checks to more > than one set of candidates at the same time (which I don't believe it > does, and shouldn't), or you disallow trickling candidates to the > pre-restart set of candidates (which would be suboptimal) or you > indicate which set of candidates the candidate applies to (its ufrag). I am saying neither of those two things. Could it be that you somehow assume that a candidate can only operate with one ufrag/password? That is not the case. After a restart, all of your candidates get a new ufrag. Including the ones that haven't changed at all. In WebRTC that ufrag and password get reported via the offer or answer and *all* candidates the browser reports beyond this point will implicitly have the new ufrag/password. There won't be any need to indicate ufrags. > In other words, this isn't just a matter of message ordering or > signalling transport. > > In a WebRTC 1.0 API, that means putting something like "ufrag > foo" on > the a=candidate line. In an ORTC-ish API, that means putting a > .ufrag > on the IceCandidate object. > > So, as I said, a recommendation for extending specs and > implementors > sounds like the best path here. Normative language sounds > like going > out of scope for this draft. > > ​ > ​I think this doc should at least say "the ufrag of the > candidate MUST > be signalled if the ufrag of the trickled candidate does match > the ufrag > since the last ICE restart" or something along those lines.​ > > > The point is that it would never match the ufrag from before the > restart, > > > First: why not match the ufrag from before? Why not? Because it creates the very problem you are trying to solve here. It also makes it impossible for the receiving agent to understand that a specific check belongs to a certain ICE session and that will break a lot of stuff. > Are you suggesting is > forbidden by the spec or allowed but not a good idea? Yes, as per 5245, ICE restarts mean all candidates get reported again and they *all* have the same/new ufrag and password. > Secondly: production applications are already matching the ufrag from > before the restart. I have yet to see an application that does that. Even if we did find one, we simply can't write specs to match buggy stuff out there.Especially in disruptive cases like this one. If they are reusing ufrag-s they should fix it. > That's why Lennox brought it up, and that's what > Chrome (and any mobile app using Chrome's ICE stack) does. That's why > we're proposing adding ufrag to the candidate: it's a simple fix to a > production problem. Wait ... what? I think I am losing you here. Are you implying that, after an ICE restart, Chrome somehow reports the old ufrag/pwd in the offer/answer but then uses a new one for newly discovered candidates? I have never seen it do that but if it did ... how has that ever worked? How did the new ufrag get reported until now? Emil > > and yes it must be signalled exactly as the first one, but not on a > per-candidate level. > > > Emil > > > > Emil > > > On 21.03.16 г. 13:09, Christer Holmberg wrote: > > Hi, > > Is there a reason for not having MUST? > > Regards, > > Christer > > *From:*Peter Thatcher [mailto:pthatcher@google.com > > >] > *Sent:* 21 March 2016 19:36 > *To:* Emil Ivov >> > *Cc:* Christer Holmberg > >>; ice@ietf.org > > > > *Subject:* Re: [Ice] Some thoughts on trickling the ufrag > > Would it make sense to have a "SHOULD signal ufrag on a > trickled > candidate"? > > On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov > > > > > >>> wrote: > > Well because it's a signaling issue. IIRC it is > something > that we > agreed trickle ice for sip would > Include. > > I guess it's more of a question if and how it > should be in > trickle > ice for sip. > > The tricky part there is that this is a purely > signalling > issue and > trickle ice is meant to be signalling agnostic. A > headsup to > implementors may therefore be more appropriate. > > Emil > > > On Sunday, 20 March 2016, Christer Holmberg > > > > > >>> wrote: > > Hi, > > What reason would there be for putting it in a > separate > draft? > > Regards, > > Christer > > *From:*Ice [mailto:ice-bounces@ietf.org > > >] *On Behalf Of *Peter > Thatcher > *Sent:* 18 March 2016 07:21 > *To:* ice@ietf.org > > > > >> > > *Subject:* [Ice] Some thoughts on trickling > the ufrag > > (As an individual, not a chair) > > Earlier, we had some discussion around adding > the ufrag > to the > trickled candidate so that when one receives > the a trickled > candidate after an ICE restart, it's clear if > the candidate > applies to the ICE ufrag/pwd from before or > after the > ICE restart. > > I have a few thoughts/questions about this: > > 1. We saw applications where this was a > real-world issue. > > 2. We implemented the addition of the ufrag to > candidates in > Chrome, and it fixed the issues observed. > Further, it > was a > very easy fix. > > 3. Do we have consensus in the group that we > should > standardize > this solution? > > 4. If so, should we simply add it to the > trickle-ice > draft? Or > should it be a separate draft? > > Thanks, > > Peter > > -- > sent from my mobile > > > -- > https://jitsi.org > > > > -- > https://jitsi.org > > -- https://jitsi.org From nobody Thu Mar 31 09:44:39 2016 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 1DAD812D67C for ; Thu, 31 Mar 2016 09:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 d54UZO5MBdck for ; Thu, 31 Mar 2016 09:44:35 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 D8F9512D65D for ; Thu, 31 Mar 2016 09:44:34 -0700 (PDT) Received: by mail-ob0-x22b.google.com with SMTP id kf9so102219341obc.1 for ; Thu, 31 Mar 2016 09:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=4NLs0g94y+8KFliFrqWf+xuRxf561LxsVH35O0rWQ1g=; b=NvNStlUw0z3VvrNN7IwmFGKQitElQXNgV0QKth9nvfcbye9J/mYVvnR3YwybPzfU13 v4Fm5+nEtDFRg5XUmoQzw2UuFBmxRvRosyIgyHcxgEzOpHMuqz6wFH4uhiDyz9M6Qwk+ q+Ll6GTVXtrWalNDaqw96NVazCmlw+yvSozPesLBzg1w7V+z8HZYyj5av1PPkiZ+djdH 8kDXeE9rpzTikIziurJKnvNyDRTtQEWRySswirQsOC44/W9tu5F51lXapxFRP+NROPvE Er1UX7hXQsxmXI+a9hoMI4PuZTqLzw4fMxqmP/Xm9FtSqVDFInh4S1BDngfnCOUK5BJG /Srw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4NLs0g94y+8KFliFrqWf+xuRxf561LxsVH35O0rWQ1g=; b=JYEy6cJ7EdfVICy1H5L/gZJ6f9+SvRwj+nDsOF+YUa7QEhtbLePLaO/AL8wD97hVlX GrtQ/FeaEm+31lCsuU1/90xiGIopxrcHhEDlmJS1LRQggzu0jfe4kD3bysQaV4E3ZUxc 6SMxswpKEhKmUV+V5vclqhPVCfqdJDytAN/kVFW8mwyGSrVilAEIUUfxr0x+H8IOQMzo cN/qgx6dPyIrjTWlsYBS0SeCOcfkDuSoGg8KbwhTZBYjE/BFY3rMqXqUO+JNeVuDOd/j pjCj+S/cWjQD3MZGHj6YA8V/LmqOUWFl0MdwBYil+6S0vwklSh9mk+1IgdD75hyzr7Ps Rxyw== X-Gm-Message-State: AD7BkJK11TMy8MA5S8QdFI8OzEh1KNymIQvIq+DE4ba41GxZqZawWAEO5h9wbi8u/Ldlqg== X-Received: by 10.60.40.9 with SMTP id t9mr1490538oek.28.1459442674242; Thu, 31 Mar 2016 09:44:34 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id a10sm2893510obj.21.2016.03.31.09.44.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 09:44:33 -0700 (PDT) To: Peter Thatcher References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> <56FC85BD.7090002@jitsi.org> <56FC9AFE.1090002@jitsi.org> From: Emil Ivov Message-ID: <56FD53F0.9050903@jitsi.org> Date: Thu, 31 Mar 2016 11:44:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FC9AFE.1090002@jitsi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 16:44:38 -0000 More on Chrome supposedly doing ICE restart weirdness: I did play with it in our deployment and here: https://webrtc.github.io/samples/src/content/peerconnection/restart-ice/ And I saw no indication of the behaviour that you are describing: all candidates participate in the restart and they all have the new ufrag and pwd. Am I missing something? Emil On 30.03.16 г. 22:35, Emil Ivov wrote: > On 30.03.16 г. 21:58, Peter Thatcher wrote: >> >> >> On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov > > wrote: >> >> On 30.03.16 г. 18:15, Peter Thatcher wrote: >> >> >> On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov > >> >>wrote: >> >> My concern is that Trickle ICE is supposed to be signalling >> agnostic. >> >> The whole part with the a= lines was only meant to be a >> convenience >> but addressing over the wire issues are supposed to be >> handled by >> other specs like Trickle ICE for SIP. >> >> Whether or not the generation needs to be signalled depends >> entirely >> on the transport. >> >> >> ​I agree that generation doesn't need to be signalled, but the >> ufrag >> does, as I'll explain further down. >> >> SIP for example does allow for out of order messages so it >> absolutely needs it and that's why that draft says: >> >> All INFO requests MUST carry the "a=ice-pwd:" and >> "a=ice-ufrag:" >> attributes that would allow mapping them to a >> specific ICE >> generation. >> >> A WebRTC browser, when signalling candidates through the >> API does >> NOT need that at all because it can guarantee that >> candidates it >> trickles will be mappable to an SLD/SRD round. >> >> >> ​If there are multiple candidate gathering phases happening at >> the same >> time right after an ICE restart, >> >> >> I am not sure I understand what this means -> "multiple candidate >> gathering phases happening at the same time" >> >> >> ​A timeline like this: >> >> 1. ufrag = X >> 2. candidate 1 (tied to ufrag = X) >> 3. restart to ufrag = Y >> 4. candidate 2 (tied to ufrag = X) >> 5. candidate 3 (tied to ufrag = Y) >> >> When you receive candidate 2, how do you know which ufrag it's supposed >> to have?​ >> >> This is the issue Lennox brought up in Yokohama. And since then we have >> observed it in production systems as well. Either you disallow >> trickling candidate 2 or you indicate somehow that its ufrag is X, not >> Y. But you can't trickle it without indicating that it has ufrag X. >> Otherwise, you'd think it was Y and be wrong. > > I think the confusion persists. I never said you shouldn't signal it. In > fact in many cases, like SIP, you must or otherwise you get in ambiguous > situations. That's why we added this to trickle ICE for SIP. > > What I did say is that signalling is not always necessary, and I pointed > out that the WebRTC API is one case where it is not. > >> Do you mean something like several PeerConnection-s restarting >> simultaneously? Or some ICE concurrent phases that have not been >> defined yet? >> >> the WebRTC API does need to tell the >> application ​which ufrag the candidate applies to so that the >> application can signal that (via whatever signalling, not just >> SDP), so >> that the remote side can know which pwd/ufrag to use when >> sending STUN >> messages. Either that or you say that after an ICE restart, you >> can't >> gather any more candidates from the previous ufrag/pwd, which I >> don't >> think is reasonable. Assuming you do allow more candidates >> to be >> gathered after an ICE restart, then you need to be able to tell >> if the >> candidate is for the ufrag/pwd before or after the restart. >> >> >> ICE restarts can obviously yield new candidates and they all have a >> new ufrag/pwd that a WebRTC client will learn the same way it >> learned the first one: by getting the offer/answer from the browser. >> >> >> In other words, during an ice restart, all checks have the same >> ufrag and password even if some or all the candidates are the same >> as before. >> >> >> ​You're assuming you can only send checks to one set of candidates at >> the same time. > > I am assuming no such thing. I think what might have led you to believe > I did is my WebRTC example in which I said the browser didn't need to > signal ufrag on a per-candidate level. And it doesn't. It should simply > signal them in the offer or answer because they are the same for all > candidates. > >> But if ICE wasn't complete when you restarted ICE, then >> you have two sets of candidates you can send checks to: the ones from >> before the restart, and the ones for after > > You absolutely do. There is no argument here. > >> This is how 5245 works and there is no reason for trickle ICE to >> break that rule. In fact it strives to be backward compatible so ... >> >> >> ​Except that if you are sending checks to two different sets of >> candidates at the same time, you need to know which set a candidate >> belongs to. > > Totally. > >> So you either say 5245 disallows sending checks to more >> than one set of candidates at the same time (which I don't believe it >> does, and shouldn't), or you disallow trickling candidates to the >> pre-restart set of candidates (which would be suboptimal) or you >> indicate which set of candidates the candidate applies to (its ufrag). > > I am saying neither of those two things. Could it be that you somehow > assume that a candidate can only operate with one ufrag/password? > > That is not the case. > > After a restart, all of your candidates get a new ufrag. Including the > ones that haven't changed at all. In WebRTC that ufrag and password get > reported via the offer or answer and *all* candidates the browser > reports beyond this point will implicitly have the new ufrag/password. > > There won't be any need to indicate ufrags. > >> In other words, this isn't just a matter of message ordering or >> signalling transport. >> >> In a WebRTC 1.0 API, that means putting something like "ufrag >> foo" on >> the a=candidate line. In an ORTC-ish API, that means putting a >> .ufrag >> on the IceCandidate object. >> >> So, as I said, a recommendation for extending specs and >> implementors >> sounds like the best path here. Normative language sounds >> like going >> out of scope for this draft. >> >> ​ >> ​I think this doc should at least say "the ufrag of the >> candidate MUST >> be signalled if the ufrag of the trickled candidate does match >> the ufrag >> since the last ICE restart" or something along those lines.​ >> >> >> The point is that it would never match the ufrag from before the >> restart, >> >> >> First: why not match the ufrag from before? > > Why not? Because it creates the very problem you are trying to solve here. > > It also makes it impossible for the receiving agent to understand that a > specific check belongs to a certain ICE session and that will break a > lot of stuff. > >> Are you suggesting is >> forbidden by the spec or allowed but not a good idea? > > Yes, as per 5245, ICE restarts mean all candidates get reported again > and they *all* have the same/new ufrag and password. > >> Secondly: production applications are already matching the ufrag from >> before the restart. > > I have yet to see an application that does that. Even if we did find > one, we simply can't write specs to match buggy stuff out > there.Especially in disruptive cases like this one. If they are reusing > ufrag-s they should fix it. > >> That's why Lennox brought it up, and that's what >> Chrome (and any mobile app using Chrome's ICE stack) does. That's why >> we're proposing adding ufrag to the candidate: it's a simple fix to a >> production problem. > > Wait ... what? I think I am losing you here. Are you implying that, > after an ICE restart, Chrome somehow reports the old ufrag/pwd in the > offer/answer but then uses a new one for newly discovered candidates? > > I have never seen it do that but if it did ... how has that ever worked? > How did the new ufrag get reported until now? > > Emil > > >> >> and yes it must be signalled exactly as the first one, but not on a >> per-candidate level. >> >> >> Emil >> >> >> >> Emil >> >> >> On 21.03.16 г. 13:09, Christer Holmberg wrote: >> >> Hi, >> >> Is there a reason for not having MUST? >> >> Regards, >> >> Christer >> >> *From:*Peter Thatcher [mailto:pthatcher@google.com >> >> > >] >> *Sent:* 21 March 2016 19:36 >> *To:* Emil Ivov > > >> >> *Cc:* Christer Holmberg > >> > >>; ice@ietf.org >> >> > >> *Subject:* Re: [Ice] Some thoughts on trickling the >> ufrag >> >> Would it make sense to have a "SHOULD signal ufrag on a >> trickled >> candidate"? >> >> On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov >> >> > >> >> >>> wrote: >> >> Well because it's a signaling issue. IIRC it is >> something >> that we >> agreed trickle ice for sip would >> Include. >> >> I guess it's more of a question if and how it >> should be in >> trickle >> ice for sip. >> >> The tricky part there is that this is a purely >> signalling >> issue and >> trickle ice is meant to be signalling agnostic. A >> headsup to >> implementors may therefore be more appropriate. >> >> Emil >> >> >> On Sunday, 20 March 2016, Christer Holmberg >> > >> > > >> > >> > >>> wrote: >> >> Hi, >> >> What reason would there be for putting it in a >> separate >> draft? >> >> Regards, >> >> Christer >> >> *From:*Ice [mailto:ice-bounces@ietf.org >> >> > >] *On Behalf Of *Peter >> Thatcher >> *Sent:* 18 March 2016 07:21 >> *To:* ice@ietf.org >> > >> >> >> >> >> *Subject:* [Ice] Some thoughts on trickling >> the ufrag >> >> (As an individual, not a chair) >> >> Earlier, we had some discussion around adding >> the ufrag >> to the >> trickled candidate so that when one receives >> the a trickled >> candidate after an ICE restart, it's clear if >> the candidate >> applies to the ICE ufrag/pwd from before or >> after the >> ICE restart. >> >> I have a few thoughts/questions about this: >> >> 1. We saw applications where this was a >> real-world issue. >> >> 2. We implemented the addition of the ufrag to >> candidates in >> Chrome, and it fixed the issues observed. >> Further, it >> was a >> very easy fix. >> >> 3. Do we have consensus in the group that we >> should >> standardize >> this solution? >> >> 4. If so, should we simply add it to the >> trickle-ice >> draft? Or >> should it be a separate draft? >> >> Thanks, >> >> Peter >> >> -- >> sent from my mobile >> >> >> -- >> https://jitsi.org >> >> >> >> -- >> https://jitsi.org >> >> > -- https://jitsi.org From nobody Thu Mar 31 10:33:53 2016 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 713EE12D192 for ; Thu, 31 Mar 2016 10:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 m-niMrL572kU for ; Thu, 31 Mar 2016 10:33:47 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 57C4212D6A7 for ; Thu, 31 Mar 2016 10:33:47 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id e6so112515975vkh.2 for ; Thu, 31 Mar 2016 10:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NBhogYm6GjQ1Ykzi7QGzRnJxxmdEaEj2FKHWluhcFWQ=; b=hSxYEw3ogw+egfKotbT6QKU7TgBUWHIjx26oibm9SNjhZYwJNdEpgqaHvcSzA+rlwE nV0nUQGyFnjm7SPsyghfBapP0FvgHPeBlH5dt+cZoSFHMqKi/RladNj/tO3KfhNCmklG YP0mdFKQhrs//0VHNucOxHfNaeQJr8ihgSyTV/8RmdvFwCBXN0prbC1hNONboNLiJwr+ S3TjVOSIzg2P1tisWWQNeDk+Bfp+OMnhQm3Bh77JqW+xv7SLGWBFSq6Xf8x8t63TQhgU wo8knecIW8iY4Igg5QsNfFQ2FkDvQOLwujjJITNafWWJ4se6mfZbt+1nE1lRRgIRUD1Q TDWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NBhogYm6GjQ1Ykzi7QGzRnJxxmdEaEj2FKHWluhcFWQ=; b=f9apsPveg45Tfz+sOFc0XVcO9wuPjGA2u0TP6q1k061u7nkATB4bSEKAQrN2MZ/Zgd RM+xG21fMN+wXKmEsgMtowRt4OOvSfveGdoYWMhDT8aBOb41T8EGn0HaPzHtzxkMutDQ kc0QC1OWWLmbfqmjNiNw7+0UsFOYGM7oT+Z4Ha89mTtB18Mv0DSlJ72f2bhHL4/Y9/6I BqJwlO6yPWX0aopLQWoU3yedPeguOxMLVmXr2HuV/2HT2F8cdNhJeuBYVuWq7NKM4Fjh tDcd+riQgXMefG2DhvRCz79yDJfTRWhlb3myQ1qPqVG0rDJ5TXw2QUpEoJBJBql1p+Zv yCYQ== X-Gm-Message-State: AD7BkJJ040Jwt1vmRRZ1C5+I+8vIEzucqORjZT1JJI+G8K9/tnDuhRcPKcp11ffrjLdoQ8al76/iWrjeYiRAsa0D X-Received: by 10.31.11.201 with SMTP id 192mr1431656vkl.135.1459445626276; Thu, 31 Mar 2016 10:33:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Thu, 31 Mar 2016 10:33:06 -0700 (PDT) In-Reply-To: <56FC9AFE.1090002@jitsi.org> References: <7594FB04B1934943A5C02806D1A2204B37EDB483@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37EF8E18@ESESSMB209.ericsson.se> <56FC513A.7080100@jitsi.org> <56FC85BD.7090002@jitsi.org> <56FC9AFE.1090002@jitsi.org> From: Peter Thatcher Date: Thu, 31 Mar 2016 10:33:06 -0700 Message-ID: To: Emil Ivov Content-Type: multipart/alternative; boundary=001a114551521fd82d052f5baa4b Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Some thoughts on trickling the ufrag X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 17:33:51 -0000 --001a114551521fd82d052f5baa4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2016 at 8:35 PM, Emil Ivov wrote: > On 30.03.16 =D0=B3. 21:58, Peter Thatcher wrote: > >> >> >> On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov > > wrote: >> >> On 30.03.16 =D0=B3. 18:15, Peter Thatcher wrote: >> >> >> On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov > >> >>wrote: >> >> My concern is that Trickle ICE is supposed to be signalling >> agnostic. >> >> The whole part with the a=3D lines was only meant to be a >> convenience >> but addressing over the wire issues are supposed to be >> handled by >> other specs like Trickle ICE for SIP. >> >> Whether or not the generation needs to be signalled depends >> entirely >> on the transport. >> >> >> =E2=80=8BI agree that generation doesn't need to be signalled, b= ut the >> ufrag >> does, as I'll explain further down. >> >> SIP for example does allow for out of order messages so it >> absolutely needs it and that's why that draft says: >> >> All INFO requests MUST carry the "a=3Dice-pwd:" and >> "a=3Dice-ufrag:" >> attributes that would allow mapping them to a specific >> ICE >> generation. >> >> A WebRTC browser, when signalling candidates through the >> API does >> NOT need that at all because it can guarantee that >> candidates it >> trickles will be mappable to an SLD/SRD round. >> >> >> =E2=80=8BIf there are multiple candidate gathering phases happen= ing at >> the same >> time right after an ICE restart, >> >> >> I am not sure I understand what this means -> "multiple candidate >> gathering phases happening at the same time" >> >> >> =E2=80=8BA timeline like this: >> >> 1. ufrag =3D X >> 2. candidate 1 (tied to ufrag =3D X) >> 3. restart to ufrag =3D Y >> 4. candidate 2 (tied to ufrag =3D X) >> 5. candidate 3 (tied to ufrag =3D Y) >> >> When you receive candidate 2, how do you know which ufrag it's supposed >> to have?=E2=80=8B >> >> This is the issue Lennox brought up in Yokohama. And since then we have >> observed it in production systems as well. Either you disallow >> trickling candidate 2 or you indicate somehow that its ufrag is X, not >> Y. But you can't trickle it without indicating that it has ufrag X. >> Otherwise, you'd think it was Y and be wrong. >> > > I think the confusion persists. I never said you shouldn't signal it. In > fact in many cases, like SIP, you must or otherwise you get in ambiguous > situations. That's why we added this to trickle ICE for SIP. > =E2=80=8BNow I am confused. =E2=80=8B =E2=80=8B =E2=80=8B =E2=80=8B You already adde =E2=80=8Bd what to trickle ICE for SIP? Trickling candidate 2 or including= the ufrag (I'm guessing the former)? > > What I did say is that signalling is not always necessary, and I pointed > out that the WebRTC API is one case where it is not. > > Do you mean something like several PeerConnection-s restarting >> simultaneously? Or some ICE concurrent phases that have not been >> defined yet? >> >> the WebRTC API does need to tell the >> application =E2=80=8Bwhich ufrag the candidate applies to so tha= t the >> application can signal that (via whatever signalling, not just >> SDP), so >> that the remote side can know which pwd/ufrag to use when >> sending STUN >> messages. Either that or you say that after an ICE restart, you >> can't >> gather any more candidates from the previous ufrag/pwd, which I >> don't >> think is reasonable. Assuming you do allow more candidates to = be >> gathered after an ICE restart, then you need to be able to tell >> if the >> candidate is for the ufrag/pwd before or after the restart. >> >> >> ICE restarts can obviously yield new candidates and they all have a >> new ufrag/pwd that a WebRTC client will learn the same way it >> learned the first one: by getting the offer/answer from the browser. >> >> >> In other words, during an ice restart, all checks have the same >> ufrag and password even if some or all the candidates are the same >> as before. >> >> >> =E2=80=8BYou're assuming you can only send checks to one set of candidat= es at >> the same time. >> > > I am assuming no such thing. I think what might have led you to believe I > did is my WebRTC example in which I said the browser didn't need to signa= l > ufrag on a per-candidate level. And it doesn't. It should simply signal > them in the offer or answer because they are the same for all candidates. > > But if ICE wasn't complete when you restarted ICE, then >> you have two sets of candidates you can send checks to: the ones from >> before the restart, and the ones for after >> > > You absolutely do. There is no argument here. > > This is how 5245 works and there is no reason for trickle ICE to >> break that rule. In fact it strives to be backward compatible so ... >> >> >> =E2=80=8BExcept that if you are sending checks to two different sets of >> candidates at the same time, you need to know which set a candidate >> belongs to. >> > > Totally. > > So you either say 5245 disallows sending checks to more >> than one set of candidates at the same time (which I don't believe it >> does, and shouldn't), or you disallow trickling candidates to the >> pre-restart set of candidates (which would be suboptimal) or you >> indicate which set of candidates the candidate applies to (its ufrag). >> > > I am saying neither of those two things. Could it be that you somehow > assume that a candidate can only operate with one ufrag/password? > > That is not the case. > > After a restart, all of your candidates get a new ufrag. Including the > ones that haven't changed at all. In WebRTC that ufrag and password get > reported via the offer or answer and *all* candidates the browser reports > beyond this point will implicitly have the new ufrag/password. > > There won't be any need to indicate ufrags. =E2=80=8BSo you're suggesting that (using my example), =E2=80=8Bcandidate 2= would accept ICE checks from with either ufrag/pwd X or ufrag/pwd Y? Or just ufrag/pwd Y? I had not considered that possibility. It goes counter to what my understanding of "make before break" ICE restart means. My mental model of a candidate is that it's tied to a ufrag/pwd, not that it can change during an ICE restart. Is there text in the RFCs/drafts that clarifies this, or are we just reading our own different meanings into ambiguous text? If this is true, what local ufrag would it use to send ICE checks on the candidate pairs that existed before the ICE restart? Would those suddenly change from ufrag X to ufrag Y as well? If so, when does that happen? After sending the local offer to restart or receiving a remote answer acknowledging the restart? > > In other words, this isn't just a matter of message ordering or >> signalling transport. >> >> In a WebRTC 1.0 API, that means putting something like "ufrag >> foo" on >> the a=3Dcandidate line. In an ORTC-ish API, that means putting = a >> .ufrag >> on the IceCandidate object. >> >> So, as I said, a recommendation for extending specs and >> implementors >> sounds like the best path here. Normative language sounds >> like going >> out of scope for this draft. >> >> =E2=80=8B >> =E2=80=8BI think this doc should at least say "the ufrag of the >> candidate MUST >> be signalled if the ufrag of the trickled candidate does match >> the ufrag >> since the last ICE restart" or something along those lines.=E2= =80=8B >> >> >> The point is that it would never match the ufrag from before the >> restart, >> >> >> First: why not match the ufrag from before? >> > > Why not? Because it creates the very problem you are trying to solve here= . > > It also makes it impossible for the receiving agent to understand that a > specific check belongs to a certain ICE session and that will break a lot > of stuff. > > Are you suggesting is >> forbidden by the spec or allowed but not a good idea? >> > > Yes, as per 5245, ICE restarts mean all candidates get reported again and > they *all* have the same/new ufrag and password. > > Secondly: production applications are already matching the ufrag from >> before the restart. >> > > I have yet to see an application that does that. Even if we did find one, > we simply can't write specs to match buggy stuff out there.Especially in > disruptive cases like this one. If they are reusing ufrag-s they should f= ix > it. > > That's why Lennox brought it up, and that's what >> Chrome (and any mobile app using Chrome's ICE stack) does. That's why >> we're proposing adding ufrag to the candidate: it's a simple fix to a >> production problem. >> > > Wait ... what? I think I am losing you here. Are you implying that, after > an ICE restart, Chrome somehow reports the old ufrag/pwd in the > offer/answer but then uses a new one for newly discovered candidates? > =E2=80=8BThe other way around. It signals the new ufrag/pwd in offer/answe= r, and then it signals the ufrag of the candidate, which may be the old ufrag or the new, depending on if it's a candidate that applies to the set of candidates before or after the ICE restart. > I have never seen it do that but if it did ... how has that ever worked? > How did the new ufrag get reported until now? > Emil > > > >> and yes it must be signalled exactly as the first one, but not on a >> per-candidate level. >> >> >> Emil >> >> >> >> Emil >> >> >> On 21.03.16 =D0=B3. 13:09, Christer Holmberg wrote: >> >> Hi, >> >> Is there a reason for not having MUST? >> >> Regards, >> >> Christer >> >> *From:*Peter Thatcher [mailto:pthatcher@google.com >> >> > >] >> *Sent:* 21 March 2016 19:36 >> *To:* Emil Ivov > > >> >> *Cc:* Christer Holmberg > >> > >>; ice@ietf.org >> >> > >> >> *Subject:* Re: [Ice] Some thoughts on trickling the ufr= ag >> >> Would it make sense to have a "SHOULD signal ufrag on a >> trickled >> candidate"? >> >> On Sun, Mar 20, 2016 at 4:25 AM, Emil Ivov >> >> > >> >> >>> wrote: >> >> Well because it's a signaling issue. IIRC it is >> something >> that we >> agreed trickle ice for sip would >> Include. >> >> I guess it's more of a question if and how it >> should be in >> trickle >> ice for sip. >> >> The tricky part there is that this is a purely >> signalling >> issue and >> trickle ice is meant to be signalling agnostic. A >> headsup to >> implementors may therefore be more appropriate. >> >> Emil >> >> >> On Sunday, 20 March 2016, Christer Holmberg >> > >> > > >> > >> > >>> wrote: >> >> Hi, >> >> What reason would there be for putting it in a >> separate >> draft? >> >> Regards, >> >> Christer >> >> *From:*Ice [mailto:ice-bounces@ietf.org >> >> > >] *On Behalf Of *Peter >> Thatcher >> *Sent:* 18 March 2016 07:21 >> *To:* ice@ietf.org >> > >> >> >> >> >> *Subject:* [Ice] Some thoughts on trickling >> the ufrag >> >> (As an individual, not a chair) >> >> Earlier, we had some discussion around adding >> the ufrag >> to the >> trickled candidate so that when one receives >> the a trickled >> candidate after an ICE restart, it's clear if >> the candidate >> applies to the ICE ufrag/pwd from before or >> after the >> ICE restart. >> >> I have a few thoughts/questions about this: >> >> 1. We saw applications where this was a >> real-world issue. >> >> 2. We implemented the addition of the ufrag t= o >> candidates in >> Chrome, and it fixed the issues observed. >> Further, it >> was a >> very easy fix. >> >> 3. Do we have consensus in the group that we >> should >> standardize >> this solution? >> >> 4. If so, should we simply add it to the >> trickle-ice >> draft? Or >> should it be a separate draft? >> >> Thanks, >> >> Peter >> >> -- >> sent from my mobile >> >> >> -- >> https://jitsi.org >> >> >> >> -- >> https://jitsi.org >> >> >> > -- > https://jitsi.org > --001a114551521fd82d052f5baa4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 8:35 PM, Emil Ivov &= lt;emcho@jitsi.org= > wrote:
On 30= .03.16 =D0=B3. 21:58, Peter Thatcher wrote:


On Wed, Mar 30, 2016 at 7:04 PM, Emil Ivov <emcho@jitsi.org
 <mailto:emcho@jitsi= .org>> wrote:

=C2=A0 =C2=A0 On 30.03.16 =D0=B3. 18:15, Peter Thatcher wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Wed, Mar 30, 2016 at 3:20 PM, Emil Ivov <= emcho@jitsi.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0My concern is that Trickle = ICE is supposed to be signalling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 agnostic.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The whole part with the a= =3D lines was only meant to be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 convenience
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but addressing over the wir= e issues are supposed to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 handled by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0other specs like Trickle IC= E for SIP.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Whether or not the generati= on needs to be signalled depends
=C2=A0 =C2=A0 =C2=A0 =C2=A0 entirely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on the transport.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BI agree that generation doesn't ne= ed to be signalled, but the ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 does, as I'll explain further down.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SIP for example does allow = for out of order messages so it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0absolutely needs it and tha= t's why that draft says:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0All INFO requ= ests MUST carry the "a=3Dice-pwd:" and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "a=3Dice-ufrag:"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attributes th= at would allow mapping them to a specific ICE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0generation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A WebRTC browser, when sign= alling candidates through the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 API does
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NOT need that at all becaus= e it can guarantee that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidates it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trickles will be mappable t= o an SLD/SRD round.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BIf there are multiple candidate gather= ing phases happening at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 time right after an ICE restart,


=C2=A0 =C2=A0 I am not sure I understand what this means -> "multip= le candidate
=C2=A0 =C2=A0 gathering phases happening at the same time"


=E2=80=8BA timeline like this:

1.=C2=A0 ufrag =3D X
2.=C2=A0 candidate 1 (tied to ufrag =3D X)
3.=C2=A0 restart to ufrag =3D Y
4.=C2=A0 candidate 2 (tied to ufrag =3D X)
5.=C2=A0 candidate 3 (tied to ufrag =3D Y)

When you receive candidate 2, how do you know which ufrag it's supposed=
to have?=E2=80=8B

This is the issue Lennox brought up in Yokohama.=C2=A0 And since then we ha= ve
observed it in production systems as well.=C2=A0 Either you disallow
trickling candidate 2 or you indicate somehow that its ufrag is X, not
Y.=C2=A0 But you can't trickle it without indicating that it has ufrag = X.
Otherwise, you'd think it was Y and be wrong.

I think the confusion persists. I never said you shouldn't signal it. I= n fact in many cases, like SIP, you must or otherwise you get in ambiguous = situations. That's why we added this to trickle ICE for SIP.

=E2=80=8BNow I am confused. =C2=A0=E2=80=8B
=E2=80=8B
=E2=80=8B =E2=80=8B
You already adde
=E2=80=8Bd what = to trickle ICE for SIP?=C2=A0 Trickling candidate 2 or including the ufrag = (I'm guessing the former)?
=C2=A0

What I did say is that signalling is not always necessary, and I pointed ou= t that the WebRTC API is one case where it is not.


=C2=A0 =C2=A0 Do you mean something like several PeerConnection-s restartin= g
=C2=A0 =C2=A0 simultaneously? Or some ICE concurrent phases that have not b= een
=C2=A0 =C2=A0 defined yet?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the WebRTC API does need to tell the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application =E2=80=8Bwhich ufrag the candidate = applies to so that the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application can signal that (via whatever signa= lling, not just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP), so
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that the remote side can know which pwd/ufrag t= o use when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sending STUN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 messages.=C2=A0 Either that or you say that aft= er an ICE restart, you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 can't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 gather any more candidates from the previous uf= rag/pwd, which I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 think is reasonable.=C2=A0 =C2=A0Assuming you d= o allow more candidates to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 gathered after an ICE restart, then you need to= be able to tell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate is for the ufrag/pwd before or after = the restart.


=C2=A0 =C2=A0 ICE restarts can obviously yield new candidates and they all = have a
=C2=A0 =C2=A0 new ufrag/pwd that a WebRTC client will learn the same way it=
=C2=A0 =C2=A0 learned the first one: by getting the offer/answer from the b= rowser.


=C2=A0 =C2=A0 In other words, during an ice restart, all checks have the sa= me
=C2=A0 =C2=A0 ufrag and password even if some or all the candidates are the= same
=C2=A0 =C2=A0 as before.


=E2=80=8BYou're assuming you can only send checks to one set of candida= tes at
the same time.

I am assuming no such thing. I think what might have led you to believe I d= id is my WebRTC example in which I said the browser didn't need to sign= al ufrag on a per-candidate level. And it doesn't. It should simply sig= nal them in the offer or answer because they are the same for all candidate= s.=C2=A0


But if ICE wasn't complete when you restarted ICE, then
you have two sets of candidates you can send checks to: the ones from
before the restart, and the ones for after

 You absolutely do. There is no argument here.

=C2=A0 =C2=A0 This is how 5245 works and there is no reason for trickle ICE= to
=C2=A0 =C2=A0 break that rule. In fact it strives to be backward compatible= so ...


=E2=80=8BExcept that if you are sending checks to two different sets of
candidates at the same time, you need to know which set a candidate
belongs to.

 Totally.

So you either say 5245 disallows sending checks to more
than one set of candidates at the same time (which I don't believe it does, and shouldn't), or you disallow trickling candidates to the
pre-restart set of candidates (which would be suboptimal) or you
indicate which set of candidates the candidate applies to (its ufrag).

 I am saying neither of those two things. Could it be that you somehow assum= e that a candidate can only operate with one ufrag/password?

That is not the case.

After a restart, all of your candidates get a new ufrag. Including the ones= that haven't changed at all. In WebRTC that ufrag and password get rep= orted via the offer or answer and *all* candidates the browser reports beyo= nd this point will implicitly have the new ufrag/password.

There won't be any need to indicate ufrags.

=
=E2=80=8BSo you're suggesting that (using my example), =E2=80=8Bcand= idate 2 would accept ICE checks from with either ufrag/pwd X or ufrag/pwd Y= ?=C2=A0 Or just ufrag/pwd Y?

I had not considered that= possibility.=C2=A0 It goes counter to what my understanding of "make = before break" ICE restart means.=C2=A0 My mental model of a candidate = is that it's tied to a ufrag/pwd, not that it can change during an ICE = restart.=C2=A0 Is there text in the RFCs/drafts that clarifies this, or are= we just reading our own different meanings into ambiguous text?
If this is true, what local ufrag would it use to send ICE check= s on the candidate pairs that existed before the ICE restart?=C2=A0 Would t= hose suddenly change from ufrag X to ufrag Y as well?=C2=A0 If so, when doe= s that happen?=C2=A0 After sending the local offer to restart or receiving = a remote answer acknowledging the restart? =C2=A0
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In other words, this isn't just a matter of= message ordering or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signalling transport.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 In a WebRTC 1.0 API, that means putting somethi= ng like "ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 foo" on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the a=3Dcandidate line.=C2=A0 In an ORTC-ish AP= I, that means putting a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 .ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the IceCandidate object.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So, as I said, a recommenda= tion for extending specs and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementors
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sounds like the best path h= ere. Normative language sounds
=C2=A0 =C2=A0 =C2=A0 =C2=A0 like going
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out of scope for this draft= .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8B
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=8BI think this doc should at least say &= quot;the ufrag of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be signalled if the ufrag of the trickled candi= date does match
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 since the last ICE restart" or something a= long those lines.=E2=80=8B


=C2=A0 =C2=A0 The point is that it would never match the ufrag from before = the
=C2=A0 =C2=A0 restart,


First: why not match the ufrag from before?

 Why not? Because it creates the very problem you are trying to solve here.<= br>
It also makes it impossible for the receiving agent to understand that a sp= ecific check belongs to a certain ICE session and that will break a lot of = stuff.

Are you suggesting is
forbidden by the spec or allowed but not a good idea?

 Yes, as per 5245, ICE restarts mean all candidates get reported again and t= hey *all* have the same/new ufrag and password.

Secondly: production applications are already matching the ufrag from
before the restart.

 I have yet to see an application that does that. Even if we did find one, w= e simply can't write specs to match buggy stuff out there.Especially in= disruptive cases like this one. If they are reusing ufrag-s they should fi= x it.

That's why Lennox brought it up, and that's what
Chrome (and any mobile app using Chrome's ICE stack) does.=C2=A0 That&#= 39;s why
we're proposing adding ufrag to the candidate: it's a simple fix to= a
production problem.

 Wait ... what? I think I am losing you here. Are you implying that, after a= n ICE restart, Chrome somehow reports the old ufrag/pwd in the offer/answer= but then uses a new one for newly discovered candidates?
<= div>
=E2=80=8BThe other way around.=C2=A0 It signals the n= ew ufrag/pwd in offer/answer, and then it signals the ufrag of the candidat= e, which may be the old ufrag or the new, depending on if it's a candid= ate that applies to the set of candidates before or after the ICE restart.<= /div>


I have never seen it do that but if it did ... how has that ever worked? Ho= w did the new ufrag get reported until now?

Emil



=C2=A0 =C2=A0 and yes it must be signalled exactly as the first one, but no= t on a
=C2=A0 =C2=A0 per-candidate level.


=C2=A0 =C2=A0 Emil



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Emil


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 21.03.16 =D0=B3. 13:09, = Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Is there a re= ason for not having MUST?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*From:*Peter = Thatcher [mailto:= pthatcher@google.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pthatcher@google.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:pthatcher@google.co= m
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:pthatcher@google.com>>]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Sent:* 21 Ma= rch 2016 19:36
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*To:* Emil Iv= ov <emcho@jitsi.org=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org> <mailto:emcho@jitsi.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org>>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Cc:* Christe= r Holmberg <christer.holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>
<= /span> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:christer.= holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>>&= gt;; ice@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice@ietf.org>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ice@ietf.org <mailto= :ice@ietf.org>>=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*Subject:* Re= : [Ice] Some thoughts on trickling the ufrag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would it make= sense to have a "SHOULD signal ufrag on a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trickled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidate&quo= t;?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sun, Mar 2= 0, 2016 at 4:25 AM, Emil Ivov
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <emcho@jitsi.org <mailto:emcho@jitsi.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:emcho@jitsi.org <= mailto:emcho@jitsi.org= >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:emcho@jitsi.org <= mailto:emcho@jitsi.org= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Well because it's a signaling issue. IIRC it is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 agreed trickle ice for sip would
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Include.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 I guess it's more of a question if and how it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 should be in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0trickle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ice for sip.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 The tricky part there is that this is a purely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signalling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0issue and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 trickle ice is meant to be signalling agnostic. A
=C2=A0 =C2=A0 =C2=A0 =C2=A0 headsup to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 implementors may therefore be more appropriate.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Emil


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 On Sunday, 20 March 2016, Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <christer.holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:christer.= holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>><= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <mailto:christer.holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:christer.= holmberg@ericsson.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:christer.holmberg@ericsson.com>>&= gt;> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 What reason would there be for putting it in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 separate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Christer

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 *From:*Ice [mailto:ice-bounces@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice-bounces@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ice-bounces@ietf.or= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice-bounces@ietf.org>>] *On Behalf Of *Pete= r
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thatcher
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 *Sent:* 18 March 2016 07:21
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 *To:* i= ce@ietf.org <mailto:ice@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice@ietf.org <mailto:ice@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:ice@ietf.org <mailto= :ice@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ice@ietf.org <mailto:ice@ietf.org>>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 *Subject:* [Ice] Some thoughts on trickling
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ufrag

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 (As an individual, not a chair)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Earlier, we had some discussion around adding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the ufrag
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 trickled candidate so that when one receives
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the a trickled
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 candidate after an ICE restart, it's clear if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the candidate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 applies to the ICE ufrag/pwd from before or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 after the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE restart.<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 I have a few thoughts/questions about this:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1.=C2=A0 We saw applications where this was a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 real-world issue.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 2.=C2=A0 We implemented the addition of the ufrag to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0candidates in=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chrome, and it fixed the issues observed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Further, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 very easy fix.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 3.=C2=A0 Do we have consensus in the group that we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standardize =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 this solution?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 4.=C2=A0 If so, should we simply add it to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trickle-ice
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft?=C2=A0 = Or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 should it be a separate draft?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 sent from my mobile


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://jitsi.org



=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 https://jitsi.org



--
https://= jitsi.org

--001a114551521fd82d052f5baa4b--