From nobody Tue Feb 16 07:32:20 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 9F1A41ACDB3 for ; Tue, 16 Feb 2016 07:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] 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 jSBdovM2F0Ts for ; Tue, 16 Feb 2016 07:32:17 -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 E83081ACE03 for ; Tue, 16 Feb 2016 07:32:16 -0800 (PST) X-AuditID: c1b4fb2d-f794c6d000006f31-82-56c340fe6162 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 81.23.28465.EF043C65; Tue, 16 Feb 2016 16:32:15 +0100 (CET) Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.248.2; Tue, 16 Feb 2016 16:32:13 +0100 To: "ice@ietf.org" From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: <56C340FD.9070307@ericsson.com> Date: Tue, 16 Feb 2016 17:32:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM2K7ge5/h8NhBi/PMFp8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MHUvOsRbcZqz42XWWqYFxDWMXIweHhICJRH+/ZhcjJ5ApJnHh 3nq2LkYuDiGBw4wSd3b9YYVw1jFKzLzdzQJSJSKgKDGz5RkziM0sYCZx6dYJsDibgK3E7/Y9 TCBDhQVkJabMzwcJ8wpoSxyYsYgNxGYRUJVYfPwZI4gtKpAmsX/2byaIGkGJkzOfsECMtJCY Of88I4QtL7H97RywVUJAvVf/vWKcwMg/C0nLLCQts5C0LGBkXsUoWpxaXJybbmSsl1qUmVxc nJ+nl5dasokRGGYHt/zW3cG4+rXjIUYBDkYlHt6CiENhQqyJZcWVuYcYJTiYlUR4/70CCvGm JFZWpRblxxeV5qQWH2KU5mBREudd47w+TEggPbEkNTs1tSC1CCbLxMEp1cDo4JKj0qXzX0Y5 5M79/2zCv46+LimvVDgesc5n4xJO/yRN9ocn9r37unby+gXlUV/ya4s0yo5v15WomhZ1rvaq +9o5ckZecxt3rLzxOHr6savzLLTnm3jzXF4vdTGy8Iry41xD/smyzBLHOi/9n+b2662y+V4e fbb96t4zqgL33fFliV5qc6dLiaU4I9FQi7moOBEAaZHqfC8CAAA= Archived-At: Cc: Christer Holmberg Subject: [Ice] RFC5245bis at GitHub 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: Tue, 16 Feb 2016 15:32:18 -0000 Folks, FYI, the ICE bis draft editor's copy is now at GitHub: https://github.com/ice-wg/rfc5245bis Also, Christer Holmberg is the new editor of the draft and will be driving the discussions. Cheers, Ari From nobody Mon Feb 22 01:18:30 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 007A71B2DA4 for ; Mon, 22 Feb 2016 01:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 j9hfmaEuQp3Z for ; Mon, 22 Feb 2016 01:18:28 -0800 (PST) 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 EC7B41AD34E for ; Mon, 22 Feb 2016 01:18:27 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-5e-56cad2618833 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.BB.02707.162DAC65; Mon, 22 Feb 2016 10:18:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 10:18:25 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE-bis: Status of connectivity check pacing Thread-Index: AdFtUbSxKL0POW4kTIKhiJKufwAd9A== Date: Mon, 22 Feb 2016 09:18:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E2E3C8@ESESSMB209.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B37E2E3C8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7q27SpVNhBqd28Vh8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6MRevesxZ8kKy417WHuYHxklgXIweHhICJxOMP1V2MnECmmMSF e+vZuhi5OIQEDjNK/L/9jAXCWcwo0fx5NwtIA5uAhUT3P22QBhEBRYmZLc+YQWxhAVOJrkWv mCHiVhJdqzvYIGw9iZaj95hAWlkEVCXunxUGMXkFfCXenPcFqWAEWvv91BomEJtZQFzi1pP5 TBDnCEgs2XOeGcIWlXj5+B8rhK0ksfbwdhaI+nyJW5cWgNXzCghKnJz5hGUCo9AsJKNmISmb haQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tTspNNzLSSy3KTC4uzs/Ty0st 2cQIjIWDW34b7GB8+dzxEKMAB6MSD68B56kwIdbEsuLK3EOMEhzMSiK8W48ChXhTEiurUovy 44tKc1KLDzFKc7AoifOudl4fJiSQnliSmp2aWpBaBJNl4uCUamCcWLGl4NHWb00T6itEtrUw ejzTXKR5NmDz8tvP99yIYxD0fXD0rkVhQ6Ku9RnhPac/H9Ffem990v8VzGG5/0N3Ci05fo4p 54HFxxWu7g2/eTba/ihpnma6Vv5woE9LUJ3wsnomHin9l8t8f/68xey2sMrcnv2tcvyBk37J Pof+GdV/ulbfbNauxFKckWioxVxUnAgATHV8mYECAAA= Archived-At: Subject: [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: Mon, 22 Feb 2016 09:18:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E2E3C8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I know the "deadline" is the summer IETF, but I wonder whether someone is a= ctually planning to bring some network measurement results in order to clos= e 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 --_000_7594FB04B1934943A5C02806D1A2204B37E2E3C8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I know the “deadline” is the summer IETF= , but I wonder whether someone is actually planning to bring some network m= easurement 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

--_000_7594FB04B1934943A5C02806D1A2204B37E2E3C8ESESSMB209erics_-- From nobody Mon Feb 22 02:31:09 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 1491D1B2AF2 for ; Mon, 22 Feb 2016 02:31:08 -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 Xe1YcywsFdau for ; Mon, 22 Feb 2016 02:31:06 -0800 (PST) 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 BF0EC1AD0A9 for ; Mon, 22 Feb 2016 02:31:05 -0800 (PST) X-AuditID: c1b4fb30-f79a76d000000a93-00-56cae367082b Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.6D.02707.763EAC65; Mon, 22 Feb 2016 11:31:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 11:31:03 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE-bis: Question for clarification on frozen candidates and multiple media streams Thread-Index: AdFtXCIJt5xH/YB1RXq3OtlcIsCoxg== Date: Mon, 22 Feb 2016 10:31:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E30643@ESESSMB209.ericsson.se> 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_7594FB04B1934943A5C02806D1A2204B37E30643ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7q27641NhBuvfGlp8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6Mx1vmMBU0qFV8WbWQpYHxmUIXIyeHhICJRP/nA4wQtpjEhXvr 2boYuTiEBA4zSmx9/YcFwlnMKHFgdgNzFyMHB5uAhUT3P22QBhEBRYmZLc+YQWxhgTiJD98O s0LEkyVO/T/ICGHrScx7doAJxGYRUJVYc+IeC4jNK+Ar8evwBHYQmxFo8fdTa8BqmAXEJW49 mc8EcZCAxJI955khbFGJl4//sULYShJrD29ngajPl3h/fQUrxExBiZMzn7BMYBSahWTULCRl s5CUQcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmp JZsYgRFxcMtvgx2ML587HmIU4GBU4uE14DwVJsSaWFZcmXuIUYKDWUmEt+0BUIg3JbGyKrUo P76oNCe1+BCjNAeLkjjvauf1YUIC6YklqdmpqQWpRTBZJg5OqQZG0Tc7X780Plg2bdvXn/zV O34fWzCvT71v+Q7bug3ZXqc0Kp6qvnh/eHu1wh7O04oHOkMy5uRsnL3G/FLPsy8HTt/U5gx5 nKPyxKKfoeW214pDt1hO3BUKmFWrL7Lj1JHpkzom8tk2cVXIP3I74dn38C7rEk6R6gd2Wrar +JwnSC79XMQ+vaA1VomlOCPRUIu5qDgRABidMqCEAgAA Archived-At: Subject: [Ice] ICE-bis: Question for clarification on frozen candidates and multiple media streams 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: Mon, 22 Feb 2016 10:31:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E30643ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2.4 (Frozen Candidates) of draft-5245bis, talking about establishin= g multiple flows, says: "The network properties are likely to be very similar for each component (especially because RTP and RTCP are sent and recei= ved 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, whic= h does not have to be the case. It could mean that RTP and RTCP is sent from the same IP address as the ass= ociated STUN requests. While that is true, I don't understand what it has t= o do with multiple flows. It could mean that, for a given flow, RTP and RTCP are sent from the same I= P address. Is that always true? And, even if it is, I don't understand what= it has to do with multiple flows. Please explain :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37E30643ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

Section 2.4 (Frozen Candidates) of draft-5245bis, ta= lking about establishing multiple flows, says:

 

“The network prop= erties are likely to be very similar for each

         &nb= sp;    component (especially because RTP and RTCP are sent a= nd received from

         &nb= sp;    the same IP address).”

 

I think this text is unclear.

 

It could mean that the same IP address is used for a= ll RTP/RTCP flows, which does not have to be the case.

 

It could mean that RTP and RTCP is sent from the sam= e IP address as the associated STUN requests. While that is true, I donR= 17;t understand what it has to do with multiple flows.

 

It could mean that, for a given flow, RTP and RTCP a= re 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.<= /p>

 

Please explain :)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E30643ESESSMB209erics_-- From nobody Mon Feb 22 08:05:59 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 5223E1AD0D1 for ; Mon, 22 Feb 2016 08:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, 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 TotQMrwwfpHX for ; Mon, 22 Feb 2016 08:05:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E93151A6F7A for ; Mon, 22 Feb 2016 08:05:55 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F042541454; Mon, 22 Feb 2016 09:10:37 -0700 (MST) References: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> To: "ice@ietf.org" From: Peter Saint-Andre X-Forwarded-Message-Id: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> Message-ID: <56CB31E2.8080503@stpeter.im> Date: Mon, 22 Feb 2016 09:05:54 -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: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> Content-Type: multipart/mixed; boundary="------------060308080206050909070505" Archived-At: Subject: [Ice] Fwd: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis 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: Mon, 22 Feb 2016 16:05:57 -0000 This is a multi-part message in MIME format. --------------060308080206050909070505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Actually it applies even more directly to ICE. :-) My impression w.r.t. trickle specifically is that its milestone is earlier than 5245bis, so the chairs might have wanted it to not have a dependency on the latter. Personally I'm open to argument either way (and making sure that trickle and 5245bis are in sync seems like a good thing). Chairs, what is your opinion? Peter -------- Forwarded Message -------- Subject: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis Date: Mon, 22 Feb 2016 09:00:25 +0000 From: Christer Holmberg To: mmusic@ietf.org , rtcweb@ietf.org (Sorry for the cross-posting, but this applies to both MMUSIC and RTCWEB) Hi, draft-bundle currently references RFC 5245. draft-bundle also references draft-ice-sip-sdp, which references draft-5245bis. draft-bundle also references draft-trickle-ice-sip, which references RFC 5245 JSEP references RFC 5245. JSEP also references draft-bundle. My intention is to update the reference in draft-bundle to draft-5245bis – and I REALLY think we should do the same thing in draft-trickle-ice-sip and draft-jsep. Otherwise we will end up with references (explicit or implicit) to both RFC 5245 and draft-5245bis all over, which could end up being REALLY confusing. I KNOW the reason people want to reference RFC 5245, is because they don’t want to create a dependency on draft-5245bis. Well, I think we REALLY shall create such dependency, and then make sure we get draft-5245bis ready (more on that in a separate draft). Regards, Christer So, my intention is to reference draft-5245bis also in BUNDLE. --------------060308080206050909070505 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------060308080206050909070505-- From nobody Mon Feb 22 10:59:16 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 89C751ACE2F for ; Mon, 22 Feb 2016 10:59:14 -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, RCVD_IN_DNSWL_MED=-2.3] 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 6yWI-wcfFhjN for ; Mon, 22 Feb 2016 10:59:13 -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 942971ACDF7 for ; Mon, 22 Feb 2016 10:59:12 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-a3-56cb5a7e610e Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.27.15637.E7A5BC65; Mon, 22 Feb 2016 19:59:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 22 Feb 2016 19:59:10 +0100 From: Christer Holmberg To: Peter Saint-Andre , "ice@ietf.org" Thread-Topic: [Ice] Fwd: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis Thread-Index: AQHRbYrs52HElN3zkkWbZwaQLTVnNp84agpQ Date: Mon, 22 Feb 2016 18:59:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E34DE4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> <56CB31E2.8080503@stpeter.im> In-Reply-To: <56CB31E2.8080503@stpeter.im> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7uG5d1Okwg68LdS2+Xai1OLann9mB yWPJkp9MHnP3vGAOYIrisklJzcksSy3St0vgyjj9aT17wV3Biq+3wxsY5/B1MXJySAiYSPyd u5UJwhaTuHBvPVsXIxeHkMBhRomf3b2sEM5iRonN/+YAVXFwsAlYSHT/0wZpEBHwlLj4eyUb iC0sECWxav1TZoh4tMTtf+8YIWwjiadHv4LFWQRUJfqfnmAFsXkFfCVaO1+D9QoJ5EosuX4H rJ5TQEui9+92MJsR6KDvp9aAHccsIC5x68l8qEMFJJbsOc8MYYtKvHz8jxXCVpJoXPKEFaJe R2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz1 Uosyk4uL8/P08lJLNjECY+Tglt+qOxgvv3E8xCjAwajEw2vAeSpMiDWxrLgy9xCjBAezkghv ndTpMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8a5zXhwkJpCeWpGanphakFsFkmTg4pRoYZb64 JFbMX1Qg9tiP0f5gwNWJl55smTTxLTNPco70j47aZQ//bpmYV7SR/SKbRJd5cu0fm8u/Ij/n xyxR23rvsqN3Z4L99HjZiVtuCzF3LPez/H74V+aRmdMn8Ccop132uOf01OHXpEVFJacEVjcy XZnO8pt767KTay3vJD+yk2fc/0AjSKM/XomlOCPRUIu5qDgRAOL0LX2NAgAA Archived-At: Subject: Re: [Ice] Fwd: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis 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: Mon, 22 Feb 2016 18:59:14 -0000 Hi, > Actually it applies even more directly to ICE. :-) > > My impression w.r.t. trickle specifically is that its milestone is earlie= r than 5245bis, so the chairs might have wanted it to not have a dependency= on > the latter. Personally I'm open to argument either way (and making sure t= hat trickle and 5245bis are in sync seems like a good thing). Milestones can change, and my intention is to try to get 5245bis finalized.= There aren't too many technical open issues, so I don't think trickle woul= d "suffer". It seems to be held up mainly while we wait for the network me= asurement results, but I have asked whether someone is actually working on = providing them... If we don't align the references we are going to end up with a mess. As far as trickle is concerned, my understanding is that 5245bis is more or= less needed in order to make it work. Regards, Christer -------- Forwarded Message -------- Subject: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis Date: Mon, 22 Feb 2016 09:00:25 +0000 From: Christer Holmberg To: mmusic@ietf.org , rtcweb@ietf.org (Sorry for the cross-posting, but this applies to both MMUSIC and RTCWEB) Hi, draft-bundle currently references RFC 5245. draft-bundle also references draft-ice-sip-sdp, which references draft-5245= bis. draft-bundle also references draft-trickle-ice-sip, which references RFC 5245 JSEP references RFC 5245. JSEP also references draft-bundle. My intention is to update the reference in draft-bundle to draft-5245bis - = and I REALLY think we should do the same thing in draft-trickle-ice-sip and= draft-jsep. Otherwise we will end up with references (explicit or implicit= ) to both RFC 5245 and draft-5245bis all over, which could end up being REA= LLY confusing. I KNOW the reason people want to reference RFC 5245, is because they don't = want to create a dependency on draft-5245bis. Well, I think we REALLY shall= create such dependency, and then make sure we get draft-5245bis ready (mor= e on that in a separate draft). Regards, Christer So, my intention is to reference draft-5245bis also in BUNDLE. From nobody Mon Feb 22 19:37:29 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 7708D1B3E54 for ; Mon, 22 Feb 2016 19:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, 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 dZIv27tkdFdL for ; Mon, 22 Feb 2016 19:37:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6BA1B3E53 for ; Mon, 22 Feb 2016 19:37:27 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 16E9E41454; Mon, 22 Feb 2016 20:42:11 -0700 (MST) To: Christer Holmberg , "ice@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37E2D311@ESESSMB209.ericsson.se> <56CB31E2.8080503@stpeter.im> <7594FB04B1934943A5C02806D1A2204B37E34DE4@ESESSMB209.ericsson.se> From: Peter Saint-Andre Message-ID: <56CBD3F5.20708@stpeter.im> Date: Mon, 22 Feb 2016 20:37:25 -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: <7594FB04B1934943A5C02806D1A2204B37E34DE4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] Fwd: [MMUSIC] Confusion with references to RFC 5245 and draft-5245bis 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: Tue, 23 Feb 2016 03:37:28 -0000 On 2/22/16 11:59 AM, Christer Holmberg wrote: > Hi, > >> Actually it applies even more directly to ICE. :-) >> >> My impression w.r.t. trickle specifically is that its milestone is >> earlier than 5245bis, so the chairs might have wanted it to not >> have a dependency on the latter. Personally I'm open to argument >> either way (and making sure that trickle and 5245bis are in sync >> seems like a good thing). > > Milestones can change, and my intention is to try to get 5245bis > finalized. There aren't too many technical open issues, so I don't > think trickle would "suffer". It seems to be held up mainly while we > wait for the network measurement results, but I have asked whether > someone is actually working on providing them... > > If we don't align the references we are going to end up with a mess. Agreed. > As far as trickle is concerned, my understanding is that 5245bis is > more or less needed in order to make it work. Well, trickle has worked for 10 years now. :-) However, making sure that the specifications are consistent is a great idea and I'm happy to help with that from the trickle side. Peter From nobody Mon Feb 22 20:05:26 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 69C931A0021 for ; Mon, 22 Feb 2016 20:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, 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 GdlVViXXIxcS for ; Mon, 22 Feb 2016 20:05:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 707391A000B for ; Mon, 22 Feb 2016 20:05:22 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89CD141454; Mon, 22 Feb 2016 21:10:06 -0700 (MST) To: Jonathan Lennox , Dan Wing References: <568C301B.2080102@stpeter.im> <22561E98-0B4E-4447-A1A6-42D281BC22DA@vidyo.com> <3D14A69E-4385-44D4-9AC9-F0293C664EE1@cisco.com> <75DB3094-E077-4B96-9B7E-97EDF28BAA62@vidyo.com> <99E1780C-2F8E-49F4-BE70-3867E1098562@vidyo.com> From: Peter Saint-Andre Message-ID: <56CBDA81.7040705@stpeter.im> Date: Mon, 22 Feb 2016 21:05:21 -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: <99E1780C-2F8E-49F4-BE70-3867E1098562@vidyo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Google-Peter Thatcher , "ice@ietf.org" Subject: Re: [Ice] Trickle ICE and ICE restarts 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: Tue, 23 Feb 2016 04:05:25 -0000 On 1/6/16 9:38 AM, Jonathan Lennox wrote: > >> On Jan 6, 2016, at 11:21 AM, 🔓Dan Wing wrote: >> >> >> On 06-Jan-2016 06:51 am, Jonathan Lennox wrote: >>> >>>> >>>> On Jan 5, 2016, at 6:29 PM, 🔓Dan Wing wrote: >>>> >>>> >>>> On 05-Jan-2016 01:38 pm, Jonathan Lennox wrote: >>>>> >>>>>> On Jan 5, 2016, at 4:05 PM, Peter Saint-Andre wrote: >>>>>> >>>>>> A few months ago, Emil Ivov and I chatted off-list about how to specify the handling of ICE restarts in the context of Trickle ICE. As I recall the conversation, we thought that one possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange. This should be OK because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. Although there is an SDP dependency because of the syntax of the a= line, we have disengaged Trickle ICE from SDP, so that shouldn't be a deciding factor, either. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway. >>>>>> >>>>>> Do WG participants feel this is something we should cover in one of our documents? If so, does it belong in the Trickle spec or in ICEbis? >>>>> >>>>> As I mentioned in Yokohama, one issue that'll need to be addressed if we support this is how the protocol ensures that the two ICE agents agree on how the agents’ respective ICE restart “generations” (i.e., ufrag / password sets) correspond to each other. Offer / answer guarantees this, but other protocols don’t. (This is in fact a problem that we’ve seen in practice, when torture-testing ICE restarts on Jingle.) >>>>> >>>>> This is an issue for “base ICE”, and I think we vaguely said it was a problem for the Using protocol, but it becomes much more concrete a problem with Trickle. >>>>> >>>>> One solution (that Justin proposed, I think) would be to not *require* that the generations match up — allow checks to be done against multiple generations at once. This is a pretty big conceptual change to ICE’s model, though. >>>>> >>>>> To recap, the problem we saw was: >>>>> >>>>> * Agent A sends ICE restart A1, with a new ufrag and password compared to its previous messaging, and some candidates. >>>>> * Agent A sends *another* ICE restart A2, with another new ufrag, password, and candidates. >>>>> * Agent A receives an ICE message B1, with a previously-unseen ufrag and password, and a set of candidates. >>>>> >>>>> Should A expect to receive the ufrag it found out about in B1 on the candidates it put in A1, or on those in A2? Should it send checks to the B1 candidates from its A1 candidates, or from its A2 candidates? >>>> >>>> I like Justin's approach, to not require the generations to match up. A refinement is that when Agent A decided to send its second restart, A2, it move all of the candidates it had from A1 to a lower priority (below all of its A2 candidates) in its internal ICE priority list. It does that de-prioritization whenever it does a restart. That allows B to respond to previous ICE starts/restarts/re-restarts, so connectivity can be established. But if connectivity can be established over higher-priority paths (belonging to more recent restarts), those more recent paths are preferred. This also provides an answer to your final question, which is that A should send its checks from its A2 candidates, as the A1 candidates are very low priority. >>> >>> The difficulty with this is that at the time Agent B sent B1, it presumably hadn’t yet received A2 — it sent B1 in response to A1. So it won’t know the B2 ufrag or password, and won’t start opening pinholes toward the B2 candidates. >>> >>> If you knew explicitly that B1 was in response to A1, there wouldn’t be any ambiguity. This is what offer/answer gives you. Is there any way we can achieve that property without having the other limitations of offer/answer? >> >> Would introducing a new STUN attribute (and SDP) for Generation Number (as Peter described in his email), but keeping the ufrag and password the same for the duration of the session, get us to a happy place? I mean today we're using a new ufrag (and password) to indicate "ICE restart", but we're really trying to do something that is not a full ICE restart (that is, the previous candidates may well still be working fine and media flowing, but we are trying to see if new candidates work better). > > Generation number would be useful (and Jingle has it), but it’s not sufficient for this problem. What you really need is something like “remote generation number”, giving the peer’s generation that your generation is paired with (if any). This is the semantic that offer/answer transactions give you implicitly — the SDP in the INVITE and the SDP in the 200/1xx are naturally associated. I'd always thought that was the intent of generation: a method for keeping the parties in sync about which version of the candidate (or candidate-set) is in play right now. My reading of your remark is that the parties could get out of sync regarding generations, which seems avoidable if generation is signaled as Peter Thatcher described. Sorry about the delayed reply. Peter From nobody Mon Feb 22 20:13:11 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 EBD131A1B25; Mon, 22 Feb 2016 20:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-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 u6BHFtHtnjOF; Mon, 22 Feb 2016 20:13:08 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6691A1B11; Mon, 22 Feb 2016 20:13:08 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 37A0F41454; Mon, 22 Feb 2016 21:17:52 -0700 (MST) To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4FC90@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> From: Peter Saint-Andre Message-ID: <56CBDC52.2020200@stpeter.im> Date: Mon, 22 Feb 2016 21:13:06 -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: <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: =?UTF-8?Q?Ari_Ker=c3=a4nen?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?UTF-8?B?8J+Uk0RhbiBXaW5n?= , "snandaku@cisco.com" Subject: Re: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE 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: Tue, 23 Feb 2016 04:13:09 -0000 On 1/20/16 1:12 PM, Christer Holmberg wrote: > Another, more administrative issue, is that we also would need to get this change into JSEP and trickle ICE. Unless I remember wrong, both of those specs currently references RFC 5245. draft-ietf-ice-trickle references icebis. > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 20 January 2016 22:10 > To: Roman Shpount > Cc: Ari Keränen ; mmusic@ietf.org; Marc Petit-Huguenin ; ice@ietf.org; 🔓Dan Wing ; snandaku@cisco.com > Subject: Re: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE > > Hi Roman, > >>> Your suggested text looks ok, but it does not solve my issue :) I >>> think it should be clear that, if there is no RTCP candidate, the spec does not define usage of the SDP rtcp attribute. >> >> Well, in my proposed text "if RTCP candidate is present and not equal >> to the same address and the next higher port number of the RTP candidate, the agent MUST encode the RTCP candidate using the a=rtcp attribute". >> Do you also want text saying that a=rtcp attribute MUST not be present of no RTCP candidates are present and rtcp-mux is not used? > > I am not sure we need to say anything about mux. > > When reading your text again, I now agree that it covers my case. I just hope it is clear enough :) > > Perhaps, in the trickle ICE document, we could have a note somewhere clarifying that the RTCP candidate is not used when the RTP port is 9. We removed all of the SDP-related text from draft-ietf-ice-trickle because we were supposed to write a trickle-sdp or trickle-sip specification. Right now we don't have that text about the RTP port in draft-ietf-ice-trickle... Peter From nobody Mon Feb 22 20:34:21 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 4F9981A88E8 for ; Mon, 22 Feb 2016 20:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, 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 NwmLJKH9duyT for ; Mon, 22 Feb 2016 20:34:19 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 256591A893E for ; Mon, 22 Feb 2016 20:34:17 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 84D4B41454; Mon, 22 Feb 2016 21:39:01 -0700 (MST) To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <56CBE148.9050100@stpeter.im> Date: Mon, 22 Feb 2016 21:34:16 -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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] unfreezing with disparate foundations 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: Tue, 23 Feb 2016 04:34:20 -0000 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. ### From nobody Tue Feb 23 00:21:57 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 128D41A892E; Tue, 23 Feb 2016 00:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3] 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 sDovv0dcU9QY; Tue, 23 Feb 2016 00:21:54 -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 AD9D91A6F6D; Tue, 23 Feb 2016 00:21:53 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-8c-56cc169fbf44 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.AF.15637.F961CC65; Tue, 23 Feb 2016 09:21:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 09:21:30 +0100 From: Christer Holmberg To: Peter Saint-Andre , Roman Shpount Thread-Topic: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE Thread-Index: AQHRbfCBy6kW0xkla0e/dxDRHc8GdZ85SebA Date: Tue, 23 Feb 2016 08:21:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E388FC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37D14ACB@ESESSMB209.ericsson.se> <5415326E-30B8-4BE3-8B1B-CB03C569DFA3@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D169C5@ESESSMB209.ericsson.se> <49B611F7-18D1-479F-AC80-B893A8ED4823@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16A3F@ESESSMB209.ericsson.se> <62BD13CF-1D03-46B0-A7C9-F794792D58DA@cisco.com> <7594FB04B1934943A5C02806D1A2204B37D16AE3@ESESSMB209.ericsson.se> <6F63B37E-6746-48FD-AF45-CEE8D58FF994@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37D4C4FD@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4FC90@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37D4FCFD@ESESSMB209.ericsson.se> <56CBDC52.2020200@stpeter.im> In-Reply-To: <56CBDC52.2020200@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7iu58sTNhBm2/zC0uXnvIZPHtQq3F 2uM3GS2mLn/MYjHjwlRmi8UH7rNaHNvTz+zA7jHl90ZWjyVLfjJ5HD99ndVj7p4XzB63phQE sEZx2aSk5mSWpRbp2yVwZXxY94C54IVYxa0rZxkbGOeIdTFyckgImEhcvvWCGcIWk7hwbz1b FyMXh5DAYUaJvce3MUE4ixklJr+bCpTh4GATsJDo/qcN0iAi4Ctxsm87M0gNs0A/k0T31PeM IAlhAXuJcz+fsUIUOUjM+3OQDcI2krh78Q5YDYuAqsT8xplMIDYv0KDl206wg9hCAivZJc7+ BKvnFNCS2HfjKtgcRqDrvp9aA1bPLCAucevJfCaIqwUkluw5D/WBqMTLx/9YIWwliRXbLzGC 3MwsoCmxfpc+RKuixJTuh+wQawUlTs58wjKBUWwWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0 I2O91KLM5OLi/Dy9vNSSTYzASDy45bfqDsbLbxwPMQpwMCrx8G6IOh0mxJpYVlyZe4hRgoNZ SYTXge9MmBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeNc7rw4QE0hNLUrNTUwtSi2CyTBycUg2M zqcuhW9iDKrjUptvmRzKkD1V8/Ap+ZDZWnfZ5ByceLWmfypxTvlZEuQbHnJi/rqcpB+vWv48 17ujmbNlwmG9ILtUU55buvJdWRan83SjnPtnOK6vzW666KZhzGi66vwn38TgfCG75tdyJaUn pj2rXNmy1+IBe/qMtd7O/yJPb1/BJXb2xh0lluKMREMt5qLiRADsmQkcwAIAAA== Archived-At: Cc: =?utf-8?B?QXJpIEtlcsOkbmVu?= , "mmusic@ietf.org" , Marc Petit-Huguenin , "ice@ietf.org" , =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "snandaku@cisco.com" Subject: Re: [Ice] [MMUSIC] SDP rtcp attribute with trickle ICE 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: Tue, 23 Feb 2016 08:21:56 -0000 SGksDQoNCj4+IEFub3RoZXIsIG1vcmUgYWRtaW5pc3RyYXRpdmUgaXNzdWUsIGlzIHRoYXQgd2Ug YWxzbyB3b3VsZCBuZWVkIHRvIGdldCB0aGlzIGNoYW5nZSBpbnRvIEpTRVAgYW5kIHRyaWNrbGUg SUNFLiBVbmxlc3MgSSByZW1lbWJlciB3cm9uZywgYm90aCBvZiB0aG9zZSBzcGVjcyBjdXJyZW50 bHkgcmVmZXJlbmNlcyBSRkMgNTI0NS4NCj4NCj4gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSByZWZl cmVuY2VzIGljZWJpcy4NCg0KU29ycnksIEkgbWVhbiBkcmFmdC1pZXRmLW1tdXNpYy10cmlja2xl LWljZS1zaXAuDQoNCi4uLi53aGljaCBvZiBjb3Vyc2UgcmVmZXJlbmNlcyBkcmFmdC1pZXRmLWlj ZS10cmlja2xlLCBhbmQgdGhlcmVmb3IgaW1wbGljaXRseSA1MjQ1YmlzIDopDQoNClNvLCB1bmxl c3Mgc29tZW9uZSBoYXMgYSB0ZWNobmljYWwgcmVhc29uIHdoeSBKU0VQLCB0cmlja2xlLWljZS1z aXAgZXRjIHNob3VsZCByZWZlcmVuY2UgUkZDIDUyNDUsIEkgcmVhbGx5IHRoaW5rIHdlIHNob3Vs ZCBjaGFuZ2UgYW5kIHJlZmVyZW5jZSA1MjQ1YmlzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEljZSBbbWFpbHRvOmljZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU2VudDog MjAgSmFudWFyeSAyMDE2IDIyOjEwDQo+IFRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbT4NCj4gQ2M6IEFyaSBLZXLDpG5lbiA8YXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tPjsgbW11 c2ljQGlldGYub3JnOyBNYXJjIA0KPiBQZXRpdC1IdWd1ZW5pbiA8bWFyY0BwZXRpdC1odWd1ZW5p bi5vcmc+OyBpY2VAaWV0Zi5vcmc7IPCflJNEYW4gV2luZyANCj4gPGR3aW5nQGNpc2NvLmNvbT47 IHNuYW5kYWt1QGNpc2NvLmNvbQ0KPiBTdWJqZWN0OiBSZTogW0ljZV0gW01NVVNJQ10gU0RQIHJ0 Y3AgYXR0cmlidXRlIHdpdGggdHJpY2tsZSBJQ0UNCj4NCj4gSGkgUm9tYW4sDQo+DQo+Pj4gWW91 ciBzdWdnZXN0ZWQgdGV4dCBsb29rcyBvaywgYnV0IGl0IGRvZXMgbm90IHNvbHZlIG15IGlzc3Vl IDopIEkgDQo+Pj4gdGhpbmsgaXQgc2hvdWxkIGJlIGNsZWFyIHRoYXQsIGlmIHRoZXJlIGlzIG5v IFJUQ1AgY2FuZGlkYXRlLCB0aGUgc3BlYyBkb2VzIG5vdCBkZWZpbmUgdXNhZ2Ugb2YgdGhlIFNE UCBydGNwIGF0dHJpYnV0ZS4NCj4+DQo+PiBXZWxsLCBpbiBteSBwcm9wb3NlZCB0ZXh0ICJpZiBS VENQIGNhbmRpZGF0ZSBpcyBwcmVzZW50IGFuZCBub3QgZXF1YWwgDQo+PiB0byB0aGUgc2FtZSBh ZGRyZXNzIGFuZCB0aGUgbmV4dCBoaWdoZXIgcG9ydCBudW1iZXIgb2YgdGhlIFJUUCBjYW5kaWRh dGUsIHRoZSBhZ2VudCBNVVNUIGVuY29kZSB0aGUgUlRDUCBjYW5kaWRhdGUgdXNpbmcgdGhlIGE9 cnRjcCBhdHRyaWJ1dGUiLg0KPj4gRG8geW91IGFsc28gd2FudCB0ZXh0IHNheWluZyB0aGF0IGE9 cnRjcCBhdHRyaWJ1dGUgTVVTVCBub3QgYmUgcHJlc2VudCBvZiBubyBSVENQIGNhbmRpZGF0ZXMg YXJlIHByZXNlbnQgYW5kIHJ0Y3AtbXV4IGlzIG5vdCB1c2VkPw0KPg0KPiBJIGFtIG5vdCBzdXJl IHdlIG5lZWQgdG8gc2F5IGFueXRoaW5nIGFib3V0IG11eC4NCj4NCj4gV2hlbiByZWFkaW5nIHlv dXIgdGV4dCBhZ2FpbiwgSSBub3cgYWdyZWUgdGhhdCBpdCBjb3ZlcnMgbXkgY2FzZS4gSSANCj4g anVzdCBob3BlIGl0IGlzIGNsZWFyIGVub3VnaCA6KQ0KPg0KPiBQZXJoYXBzLCBpbiB0aGUgdHJp Y2tsZSBJQ0UgZG9jdW1lbnQsIHdlIGNvdWxkIGhhdmUgYSBub3RlIHNvbWV3aGVyZSBjbGFyaWZ5 aW5nIHRoYXQgdGhlIFJUQ1AgY2FuZGlkYXRlIGlzIG5vdCB1c2VkIHdoZW4gdGhlIFJUUCBwb3J0 IGlzIDkuDQoNCldlIHJlbW92ZWQgYWxsIG9mIHRoZSBTRFAtcmVsYXRlZCB0ZXh0IGZyb20gZHJh ZnQtaWV0Zi1pY2UtdHJpY2tsZSBiZWNhdXNlIHdlIHdlcmUgc3VwcG9zZWQgdG8gd3JpdGUgYSB0 cmlja2xlLXNkcCBvciB0cmlja2xlLXNpcCBzcGVjaWZpY2F0aW9uLiBSaWdodCBub3cgd2UgZG9u J3QgaGF2ZSB0aGF0IHRleHQgYWJvdXQgdGhlIFJUUCBwb3J0IGluIGRyYWZ0LWlldGYtaWNlLXRy aWNrbGUuLi4NCg0KUGV0ZXINCg0KDQo= From nobody Mon Feb 29 00:07:26 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 F0CCA1B2D9F for ; Mon, 29 Feb 2016 00:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 QcqeLzd1Wf6H for ; Mon, 29 Feb 2016 00:07:22 -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 DE27E1B2D9D for ; Mon, 29 Feb 2016 00:07:21 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-f3-56d3fc370853 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.83.25494.73CF3D65; Mon, 29 Feb 2016 09:07:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 09:07:18 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE-bis: Status of connectivity check pacing Thread-Index: AdFtUbSxKL0POW4kTIKhiJKufwAd9AFdnsWw Date: Mon, 29 Feb 2016 08:07:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37E4B2D0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37E2E3C8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37E2E3C8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37E4B2D0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdSdf8z+Uwgwl/lSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGlvZvjAWXVSrm/NjI3MC4Q6GLkZNDQsBEYv+iz2wQtpjEhXvr gWwuDiGBw4wSn//+Y4RwFjNKnF54g72LkYODTcBCovufNkiDiICixMyWZ8wgtrCApUT/hCes EHEria7VHWwg5SICRhLfjgqChFkEVCWWn//OAmLzCvhKHFh9E8wWArLvLbwNNp1TwE9ifX8y SJgR6Jzvp9YwgdjMAuISt57MZ4I4U0BiyZ7zzBC2qMTLx/9YIWxFiZ1n25kh6vMldl49xgix SlDi5MwnLBMYRWYhGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpx cW66kbFealFmcnFxfp5eXmrJJkZg9Bzc8lt3B+Pq146HGAU4GJV4eDc4Xw4TYk0sK67MPcQo wcGsJMK77CpQiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/bJ6CUQHpiSWp2ampBahFMlomDU6qB MeTDcVdNof+z7Cwe+uVKvD0pvPoYe8EpNVfr2g07th34Wrj/gn9whcmlH/G6+yzvLddv+/qw 2XXJOZ2mWXP2vkjLzjoqoN1udDRPdOPC8pPbPy/wX3/HV1ht+tQJwn56hYtFg2d3xyjxlTnm RP//o34gMHMPl3fHxndPuqyvPQ81XV0yJ+lCvxJLcUaioRZzUXEiAFkptQCaAgAA Archived-At: 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: Mon, 29 Feb 2016 08:07:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37E4B2D0ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PING. From: Ice [mailto:ice-bounces@ietf.org] On Behalf 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 "deadline" is the summer IETF, but I wonder whether someone is a= ctually planning to bring some network measurement results in order to clos= e 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 --_000_7594FB04B1934943A5C02806D1A2204B37E4B2D0ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PING.

 

Ice [= mailto:ice-bounces@ietf.org] On Behalf 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 “deadline̶= 1; 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 defi= ning the min value in another way. No need to wait until summer for that, i= f nobody is going to provide measurements results to begin with.=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37E4B2D0ESESSMB209erics_--