From nobody Tue Nov 3 22:49:34 2015 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 DA6C51ACEE6 for ; Tue, 3 Nov 2015 22:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 l0HdFwFLJwF5 for ; Tue, 3 Nov 2015 22:49:32 -0800 (PST) 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 7854F1ACEDA for ; Tue, 3 Nov 2015 22:49:31 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-73-5639aa79cc86 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.C6.29154.97AA9365; Wed, 4 Nov 2015 07:49:29 +0100 (CET) Received: from nomadiclab.lmf.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.248.2; Wed, 4 Nov 2015 07:49:28 +0100 Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1945F4EA62; Wed, 4 Nov 2015 08:49:40 +0200 (EET) Received: from dhcp-28-52.meeting.ietf94.jp (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 60A8D4E97E; Wed, 4 Nov 2015 08:49:38 +0200 (EET) To: Christer Holmberg , Jonathan Lennox References: <56263154.9080204@ericsson.com> <34B14ADE-78FA-4A21-8202-F5D65D5AEFD9@vidyo.com> <56264E3F.8050807@ericsson.com> <5630CBF0.6030604@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37B96AD4@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B9951F@ESESSMB209.ericsson.se> From: =?UTF-8?Q?Ari_Ker=c3=a4nen?= Message-ID: <5639AA74.9020104@ericsson.com> Date: Wed, 4 Nov 2015 15:49:24 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B9951F@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+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW7lKsswg38bFSy+Xai12L/4PLMD k8eSJT+ZPNqe3WEPYIrisklJzcksSy3St0vgyni0ZSZ7wRq5inkHf7M3MP4S72Lk4JAQMJGY tZmji5ETyBSTuHBvPVsXIxeHkMARRonVvdsZIZytjBJfps5mgnDWMkosmzadHcJZzyhxbhmI w8khLGArcb/xGCOILSIQJ3H/wB5WiKK7TBL/F31nAtnHLKAo8XKvGkgNG1D97/Y9TCA2r4C2 ROf+w2C9LAIqEh3TV7OB2KICaRKHr31ghagRlDg58wkLiM0p4CdxaeUHRoiR9hIPtpaBhJkF 5CWat85mhnhHTeLquU1gtpCAqsTVf68YJzCKzEIyaRZC9ywk3QsYmVcxihanFhfnphsZ6aUW ZSYXF+fn6eWllmxiBAb9wS2/rXYwHnzueIhRgINRiYfXgMUyTIg1say4MvcQowQHs5IIb9MS oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeZqYHoUIC6YklqdmpqQWpRTBZJg5OqQZGmRnTjz7w 2pS43L7UncGukcvNduU1vvArN3RfW69YzBWY9GdawdGTDfl1l0J2cc7Z25C05unTSW/4FFec KJnULNAjmlp7TX7XJ38h8c/67qf/8x9pn3/9a+dKb/8L5gns++ddn2K8KYP92q5c5x9tr6d7 98xjCzM+GTxjj8mDd3ul/k/ZplR3V4mlOCPRUIu5qDgRAIYrQ012AgAA Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] RTCP multiplexing clarification to ICE bis 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: Wed, 04 Nov 2015 06:49:34 -0000 Thanks Christer! Looks good to me. If no one objects, I'll change this to the next revision. Cheers, Ari On 30/10/15 15:53, Christer Holmberg wrote: > Hi, > > Here is some suggested text from myself: > > "Each component has an ID assigned to it, called the component ID. > For RTP-based media streams, unless RTP and RTCP are multiplexed on > the same port (RTP/RTCP multiplexing), the RTP has a component ID > of 1 and RTCP a component ID of 2. In case of RTP/RTCP multiplexing, a > component ID of 1 is used for both RTP and RTCP. > > When candidates are obtained, unless the agent knows for sure that > RTP/RTCP multiplexing will be used (i.e. the agent knows that the other > agent also supports, and is willing to use, RTP/RTCP multiplexing), > the agent MUST obtain a separate candidate for RTCP. If an agent has obtained a > candidate for RTCP, and end up using RTP/RTCP multiplexing, the agent > does not need to perform connectivity checks on the RTCP candidate. > > If an agent is using separate candidates for RTP and RTCP, it > will end up with 2*K host candidates if the agent has K IP addresses. > > NOTE: The responding agent, when obtaining its candidates, will typically > know whether the other agent supports RTP/RTCP multiplexing, in which > case it will not need to obtain a separate candidate for RTCP." > > Regards, > > Christer > > > -----Original Message----- > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 28 October 2015 15:30 > To: Ari Keränen ; Jonathan Lennox > Cc: ice@ietf.org > Subject: Re: [Ice] RTCP multiplexing clarification to ICE bis > > Hi, > > ... > >> Here's a new paragraph based on your proposal, using the new terminology: >> >> Each component has an ID assigned to it, called the component ID. >> For RTP-based media streams, unless it is known for sure that RTP and >> RTCP will be multiplexed on the same UDP port, the RTP itself has a >> component ID of 1, and RTCP a component ID of 2. If an agent is >> using RTCP without multiplexing, it MUST obtain a candidate for it. >> If an agent is using separate candidate IDs for RTP and RTCP, it >> would end up with 2*K host candidates if an agent has K IP addresses. >> Note that if RTCP multiplexing is being used in a way that allows the >> Initiating Agent to fall back to a non-multiplexing mode, the >> Initiating Agent MUST gather candidates also for RTCP, but the >> Responding Agent need not to, if it wishes to use multiplexing; in >> this case, connectivity checks will not be done on the component ID 2 >> candidates. >> >> Is that OK? > > I think the text is a little confusing. I'll try to come up with a suggestion in order to (hopefully) make it a little more clear. > > Regards, > > Christer > > > >>>> Thus, for proper fallback, an offerer needs to obtain candidates for >>>> both components, but an answerer can obtain only component 1 if the >>>> offerer offered multiplexing and it wants to use it. >>>> >>>> Thus, I think ice-sip-sdp needs to say that offers MUST obtain >>>> candidates for both RTP and RTCP, for backward compatibility. >>>> ICE-bis proper can make this conditional, though. >>> >>> Makes sense to me. This also relates to the discussion Christer >>> started at the MMUSIC list. > > If the proposed text works for everyone, we'll make the change across the document and update sip-sdp draft too according to the proposal above. > > > Cheers, > Ari > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Tue Nov 3 22:51:33 2015 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 C203F1ACEAB for ; Tue, 3 Nov 2015 22:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8rIO8NxASRy8 for ; Tue, 3 Nov 2015 22:43:19 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA91ACEA8 for ; Tue, 3 Nov 2015 22:43:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 0E9C01E5A26 for ; Tue, 3 Nov 2015 22:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eChyVajRiHr for ; Tue, 3 Nov 2015 22:42:40 -0800 (PST) Received: from t20010c4000003024c477d45ae53775ca.v6.meeting.ietf94.jp (t20010c4000003024c477d45ae53775ca.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:c477:d45a:e537:75ca]) by c8a.amsl.com (Postfix) with ESMTPA id A3DEA1E5A25 for ; Tue, 3 Nov 2015 22:42:40 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2015 22:43:18 -0800 Message-Id: <46503516-6CC1-4920-9A92-11D216911914@amsl.com> To: ice@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Tue, 3 Nov 2015 22:43:18 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Tue, 03 Nov 2015 22:51:32 -0800 Subject: [Ice] Queue for ICE Remote Attendees 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: Wed, 04 Nov 2015 06:43:20 -0000 If you are planning to participate in the ICE session here at IETF 94 = Thursday =97 either locally in Yokohama or as a remote participant =97 = we want to make sure that you are aware that the IETF is providing = remote participants with a fairly new way to ask questions or make = comments. In addition to using the Jabber room, for the ICE session = there is also the opportunity for remote participants to enter a virtual = queue and ask questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the ICE session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Wed Nov 4 14:49:03 2015 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 D45871B35D1 for ; Wed, 4 Nov 2015 14:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 qf91nniwEANj for ; Wed, 4 Nov 2015 14:49:00 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE8E1B35BE for ; Wed, 4 Nov 2015 14:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3784; q=dns/txt; s=iport; t=1446677340; x=1447886940; h=from:to:subject:date:message-id:mime-version; bh=Xmjruo4AyQxkTfRzteGss6s6kM7k4aicQ7pMyxu0vIU=; b=X5B1YmdhHpSiVaMfggikNdgA2psfqgakY40fe5O2r4wFzPONgiicuKAz HTe95LMGLPlp37jwFrn4AXKpBqRpZmN58oToMQRM692jmkheXxTsgd1Hf NJXksyf2AVqfmuQHLirVL6Tn9gFCKYJAH94DQVAfsPQ/l9oWdwObCMSaX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AZAgB8ijpW/40NJK1egztTdbtTghoBDYFeHYYTgSE4FAEBAQEBAQF/C4Q8I2gBDD4CBDAnBByIJaE4j3CRBAEBAQEGAQEBAQEBAQEbhlSCEIcwgzMvfxUFlkgBimuCN4Fvkw2HRAEfAQFChASFH4EHAQEB X-IronPort-AV: E=Sophos; i="5.20,245,1444694400"; d="scan'208,217"; a="41894415" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 04 Nov 2015 22:48:59 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA4Mmx0p016738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Nov 2015 22:48:59 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:48:58 -0500 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:48:58 -0500 From: "Pal Martinsen (palmarti)" To: "ice@ietf.org" Thread-Topic: ICE at the IETF Hackathon Thread-Index: AQHRF1L+ugky9g5BEESwnqCA7ysFhw== Date: Wed, 4 Nov 2015 22:48:58 +0000 Message-ID: <541D925B-4372-4B40-8B9B-ACBFCF78A1B8@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.185] Content-Type: multipart/alternative; boundary="_000_541D925B43724B408B9BACBFCF78A1B8ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Ice] ICE at the IETF Hackathon 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: Wed, 04 Nov 2015 22:49:02 -0000 --_000_541D925B43724B408B9BACBFCF78A1B8ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZXJlIHdhcyBhIHNtYWxsIElDRSBlZmZvcnQgZHVyaW5nIHRoZSBJRVRGIGhhY2th dGhvbi4NCg0KVGhlIGFpbSB3YXMgdG8gYnVpbGQgYSBzaW1wbGUgdGVzdCBmcmFtZXdvcmsgZm9y IElDRSBsaWJyYXJpZXMuDQoNCktleXdvcmRzOg0KLSBOb3RpY2UsIGEgc2ltcGxlIHJlbmRlenZv dXMgc2VydmVyIChUaGluayBTSVAgUmVnaXN0ZXIgYW5kIEludml0ZSkNCi0gSWNlYm94IHRoZSB0 ZXN0IGFwcGxpY2F0aW9uIHRoYXQgdXNlcyB0aGUgSUNFIGxpYnJhcnkNCi0gSlNPTiBmb3JtYXR0 ZWQgY2FuZGlkYXRlIGV4Y2hhbmdlDQoNClNvbWVvbmUgcHJvcG9zZWQgdG8gdXNlIG5vZGUgdG8g cmVpbXBsZW1lbnQgdGhlIGljZWJveCBmdW5jdGlvbmFsaXR5LCBhbmQgdGhlcmUgd2UgZ290IHN0 dWNrLi4gOi0pDQpCdXQgb25jZSB3ZSBnZXQgdGhhdCByb2xsaW5nIHRoZXJlIHNob3VsZCBiZSBw b3NzaWJsZSB0byB3cml0ZSBjKysvYyBiaW5kaW5nIHRvIGFueSBJQ0UgbGlicmFyeS4gKEkga25v dyBpdCBpcyBhIGJpdCBvdmVybHkgb3B0aW1pc3RpYyBmcm9tIGFuIEFQSSBwb2ludCBvZiB2aWV3 KS4NCg0KQ29kZSBzdG9yZWQgaW4gZ2l0aHViLCB3aWxsIHNoYXJlIGlmIHNvbWVvbmUgYWN0dWFs bHkgYXJlIGludGVyZXN0ZWQuIChSZWFsbHkgbm90aGluZyB0byBzZWUgeWV0LCBtYXliZSBuZXh0 IGhhY2thdGhvbj8pLg0KDQpBdCBsZWFzdCBhIG5pY2UgSUNFIHBpY3R1cmUgaW4gdGhlIElFVEYg Y2hhaXIgYmxvZzogaHR0cDovL3d3dy5pZXRmLm9yZy9ibG9nLw0KDQouLS4NClDDpWwtRXJpaw0K DQoNCg0K --_000_541D925B43724B408B9BACBFCF78A1B8ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <604BA6AA5F8C9E449A2017A4A9A55925@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSB3YXMgYSBzbWFsbCBJQ0Ug ZWZmb3J0IGR1cmluZyB0aGUgSUVURiBoYWNrYXRob24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgYWltIHdhcyB0byBidWlsZCBh IHNpbXBsZSB0ZXN0IGZyYW1ld29yayBmb3IgSUNFIGxpYnJhcmllcy48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPktleXdvcmRzOjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4tIE5vdGljZSwgYSBzaW1wbGUgcmVuZGV6dm91cyBzZXJ2ZXIgKFRo aW5rIFNJUCBSZWdpc3RlciBhbmQgSW52aXRlKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIEljZWJv eCB0aGUgdGVzdCBhcHBsaWNhdGlvbiB0aGF0IHVzZXMgdGhlIElDRSBsaWJyYXJ5PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi0gSlNPTiBmb3JtYXR0ZWQgY2FuZGlkYXRlIGV4Y2hhbmdlPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Tb21lb25l IHByb3Bvc2VkIHRvIHVzZSBub2RlIHRvIHJlaW1wbGVtZW50IHRoZSBpY2Vib3ggZnVuY3Rpb25h bGl0eSwgYW5kIHRoZXJlIHdlIGdvdCBzdHVjay4uIDotKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5C dXQgb25jZSB3ZSBnZXQgdGhhdCByb2xsaW5nIHRoZXJlIHNob3VsZCBiZSBwb3NzaWJsZSB0byB3 cml0ZSBjJiM0MzsmIzQzOy9jIGJpbmRpbmcgdG8gYW55IElDRSBsaWJyYXJ5LiAoSSBrbm93IGl0 IGlzIGEgYml0IG92ZXJseSBvcHRpbWlzdGljIGZyb20gYW4gQVBJIHBvaW50IG9mIHZpZXcpLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ Q29kZSBzdG9yZWQgaW4gZ2l0aHViLCB3aWxsIHNoYXJlIGlmIHNvbWVvbmUgYWN0dWFsbHkgYXJl IGludGVyZXN0ZWQuIChSZWFsbHkgbm90aGluZyB0byBzZWUgeWV0LCBtYXliZSBuZXh0IGhhY2th dGhvbj8pLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+QXQgbGVhc3QgYSBuaWNlIElDRSBwaWN0dXJlIGluIHRoZSBJRVRGIGNoYWlyIGJs b2c6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9ibG9nLyIgY2xhc3M9IiI+aHR0 cDovL3d3dy5pZXRmLm9yZy9ibG9nLzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi4tLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qw6Vs LUVyaWs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_541D925B43724B408B9BACBFCF78A1B8ciscocom_-- From nobody Wed Nov 4 15:57:23 2015 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 AB9E51A8747 for ; Wed, 4 Nov 2015 15:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Ur_8uQOx4Vw0 for ; Wed, 4 Nov 2015 15:57:20 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 CC6991A87C0 for ; Wed, 4 Nov 2015 15:57:18 -0800 (PST) Received: by obbza9 with SMTP id za9so53365221obb.1 for ; Wed, 04 Nov 2015 15:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi_org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=zZVjZuQs/rxP0kuFtDCme4pRzfd00nVsKYRJaltkxnc=; b=mbIr8yOpHif6/NG0VxBMt6Hd78nrYOEBYQs7UHmjVqnVyjY1b9KnsjMw+NiX0k8hOz 8SuYL+39Z2q3Rw8/J0MoQrjCG2ZfG+BQ0cMXo6/sIuMQoUyxH72y+5SMi/bZTEVmnnMO mDM+KmfXXJHHIJYhsf6DY4qXJWoT6xsbjJJbzkEu/KpHie9CcGevienVQd+8VA16CFrV 4Oawwe1lFH7ccIPkA3EXuxgdXbxI0nmNPqKJ6KY4wAKeZdX+bhLvEm+iKtjfo1r9hV5I cgkYbXsWPik4aHAiyGkx5Ho+1Jnn9G4KTR1U4F4jP7qNcgZYuEUu0SGIv75Xab8QuVGN 4ppw== 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:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=zZVjZuQs/rxP0kuFtDCme4pRzfd00nVsKYRJaltkxnc=; b=JWIGj7NB6ppWf+bbhG4YPdHdZ2KX93Ns2Xal1jCA1CkOXVIptg+HzVkqbqJT+9kmIo 0zn9iGafo/RT0YQMt+hWqV627x+HEIdR6C0OI99fkJUL+6C+gXmn1OaX7nU9k0QjckPP azQNXpiDAzFOnqJQKLflwYZvjxuNJMlmXFkVDu2rI8iU06Yyad/rp9+l9WLQSG99ysRk 3WkAfb2ConeV4sW2YQr2/m65FqdOHgdgkcan4NEGo+GR+s4AMrQDHmRJDVYvSOuNESL7 Fw0+MtsAR/WE9nuWa1glo7nQOo4lCPW+BgrdHb2xNqhBy32nyevTuqYUMb422aW+b89w v8WQ== X-Gm-Message-State: ALoCoQnWwZR64HyMor5yPRfJJHLH+PCjA8XfTwtk7mz5pu/4NdXY87HQLQCMyCRYlW15o/CmmrF2 X-Received: by 10.60.220.135 with SMTP id pw7mr2650773oec.51.1446681437865; Wed, 04 Nov 2015 15:57:17 -0800 (PST) Received: from camionet.local ([104.189.168.253]) by smtp.googlemail.com with ESMTPSA id i207sm1482576oib.1.2015.11.04.15.57.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2015 15:57:17 -0800 (PST) To: Jonathan Lennox , "ice@ietf.org" References: From: Emil Ivov Message-ID: <563A9B5C.3080808@jitsi.org> Date: Wed, 4 Nov 2015 17:57:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ice] Trickle ICE comments 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: Wed, 04 Nov 2015 23:57:22 -0000 Hey Jonathan, On 31.10.15 Đł. 17:39, Jonathan Lennox wrote: > Hey all, some comments on Trickle ICE. > > Substantive / protocol: > > I’m concerned that trickle's unfreezing algorithm doesn’t work > correctly if a particular component doesn’t have a candidate with a > given foundation. (The primary use case I have in mind is > distributed media, where different connections have different host > addresses; but this can also occur if, e.g., one component’s TURN > allocation fails.) > > Vanilla ICE says that a candidate pair is unfrozen if it is the first > instance of that pair, which isn’t necessarily the first component of > the first connection. I am a bit confused by your use of connection here. What do you mean exactly? > I think in order to handle this case, there needs to be a way for > trickle to indicate “no candidate with this foundation will be > forthcoming on this component.” This would need to be sent for every > component prior to the first one where the foundation will appear. > It can either be sent up front (if the agent knows a priori the > foundations won’t be used, as in the distributed media case), or > trickled later (for the case where gathering fails). > End-of-candidates would also implicitly indicate “no candidate > forthcoming,” of course, but I think it’s necessary to indicate this > sooner. > > I think introducing this would also eliminate the need for the > constraint in section 8 about what order candidates are trickled in; > instead, it can be the receiver’s responsibility to figure out when > things can be unfrozen. Currently the draft says: you must trickle in the order of signalling. This basically means that if you send a candidate with a specific foundation then no candidates with the same foundation and lower component IDs will be trickled. Isn't this sort of the same thing as the message you suggest? Emil > > > Editorial: > > Section 5 now uses 0.0.0.0 for the “no candidates yet” c= line, but > nonetheless still gives a justification for using ::. > > > _______________________________________________ Ice mailing list > Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice > -- https://jitsi.org From nobody Wed Nov 4 17:57:16 2015 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 45CD91B366F for ; Wed, 4 Nov 2015 17:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 wTchj6vAa16C for ; Wed, 4 Nov 2015 17:57:04 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 6B5741B3699 for ; Wed, 4 Nov 2015 17:57:04 -0800 (PST) Received: by ykdv3 with SMTP id v3so17209423ykd.0 for ; Wed, 04 Nov 2015 17:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J55a+U4xeLFTV69+S1mVdpn9mbQA7JaLEVuyvpjmBYo=; b=tpq5Q/eInqML5aot56FCInyGhg3EX39VHb5ShCtFKsZ01avj0M4mWxEcu258uX9PPT LgcYOA84j2GGHnKUOGZ2xqjCARYifeuXZ5yY58NxyUNdq5CM9lLYypXGRUISF2s+kvv6 vbxaxCzDlPniXNurZMk8CQsidsqIaOpIZqOFcyQUfwn5IHunILQHs1HtqL6NreILLoXo SygBxLJ8QB30ka4VtpN31xOCD4xgcsBdA1+bOROFMgM+lfdsKtFsn81CO4EmU25JFQ3a X/e3TYYeHaBlCu+8pIIbA4RF1Eg4wfuCCZBYZw5K72CFH5dbGLeOCXh5JlMhyRxR4AJd kAAQ== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr4497129ywd.98.1446688623812; Wed, 04 Nov 2015 17:57:03 -0800 (PST) Received: by 10.129.132.145 with HTTP; Wed, 4 Nov 2015 17:57:03 -0800 (PST) Date: Thu, 5 Nov 2015 10:57:03 +0900 Message-ID: From: Martin Thomson To: ice@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Ice] Mozilla's current token bucket sizes 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: Thu, 05 Nov 2015 01:57:09 -0000 I believe that we originally had a smaller number for the second: 8k/sec for one second 7.2k/sec over twenty seconds https://dxr.mozilla.org/mozilla-central/rev/6077f51254c69a1e14e1b61acba4af451bf1783e/media/mtransport/nr_socket_prsock.cpp#708-711 From nobody Wed Nov 4 20:19:40 2015 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 4399E1B2E20 for ; Wed, 4 Nov 2015 20:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TWOqTj_3smq2 for ; Wed, 4 Nov 2015 20:19:37 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (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 E44D31B2D86 for ; Wed, 4 Nov 2015 20:19:36 -0800 (PST) Received: by ykek133 with SMTP id k133so111719940yke.2 for ; Wed, 04 Nov 2015 20:19:36 -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:content-type; bh=5UB4PAGweI81lwVWT0Xjsk2IeEpE9Vci08nKqbqWJFg=; b=OQvfZs6Ee0A37WzM9EJCRKWzk0EISC00eoomwE8QaRVpTJY3N5kyAuUn6HiczGA1EK RLyPO41o7IFpBPhH1nx2UEWWnGhz2GOXkg8OYGypzUADegQET41/jVXEHuEfzQCTGmXn JmIuxprVuXQxCJvb/i/z1sXw/GWEVUVDetvIW0KVSQ5mC4+iJaGLQ0UFQkINEwcFcJhv xNzkQ9MZSBf3KOO6wLtbiDjwBzu+rcealpwe6p8ngbrfDYvp2+Lh/KLhtYJlGKyPRHtF oUg3KjGxW7NwVme5fhD5vEvfLzrocM1nykoGNGKunjUbfUu57OwLfdExW71cNihZFNoC 4bTw== 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:content-type; bh=5UB4PAGweI81lwVWT0Xjsk2IeEpE9Vci08nKqbqWJFg=; b=c8mVgPHZD1LhzzpCO67/JuN/Y8FNaq/viqC3UwXVxpXJwVMU8LfBsdG2N8ioNeexXW vrL4LcXfjHevDDjPemj+OIIiiZdD87n7miMyNoiMFyGbagZWc0zoFgD+yPGVUEACy4nl F339swHw4wjeqyMTU4oJ6qcGKFoAUcHGdwS0TzA8tWeT/++GLN1r9HNM8T8FPo8meU4N aJrevtOB17Cy5ovFxQPN8Hzl9muCruG8I5uJnpgA+kn6OU99ZVIn98ZA04G8QMcggwcp Tg/iPcOesiv7V3PxLUJ35m+hPVwolxc/ioUq7NNE0oXeywy+1OGDN9gK3VfPtnAM+kYE KQHw== X-Gm-Message-State: ALoCoQnONTBa/MqDmrxzUEP4vdyO5YVScIFQjDIgSzJmrdSsQ4cx5dJcR/ePjmyyxI5Wxcz4qa9k X-Received: by 10.31.41.149 with SMTP id p143mr5046066vkp.4.1446697176038; Wed, 04 Nov 2015 20:19:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.69.84 with HTTP; Wed, 4 Nov 2015 20:19:16 -0800 (PST) In-Reply-To: References: From: Justin Uberti Date: Thu, 5 Nov 2015 13:19:16 +0900 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113ee6a446c7c00523c36f6f Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Mozilla's current token bucket sizes 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: Thu, 05 Nov 2015 04:19:38 -0000 --001a113ee6a446c7c00523c36f6f Content-Type: text/plain; charset=UTF-8 Chrome's limit is 32k/sec for one second. https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/renderer_host/p2p/socket_host_throttler.cc On Thu, Nov 5, 2015 at 10:57 AM, Martin Thomson wrote: > I believe that we originally had a smaller number for the second: > > 8k/sec for one second > 7.2k/sec over twenty seconds > > > https://dxr.mozilla.org/mozilla-central/rev/6077f51254c69a1e14e1b61acba4af451bf1783e/media/mtransport/nr_socket_prsock.cpp#708-711 > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --001a113ee6a446c7c00523c36f6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chrome's limit is 32k/sec for one second.

https://code.= google.com/p/chromium/codesearch#chromium/src/content/browser/renderer_host= /p2p/socket_host_throttler.cc

On Thu, Nov 5, 2015 at 10:57 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I beli= eve that we originally had a smaller number for the second:

8k/sec for one second
7.2k/sec over twenty seconds

https://dxr.mozilla.org/mozilla-central/rev/6= 077f51254c69a1e14e1b61acba4af451bf1783e/media/mtransport/nr_socket_prsock.c= pp#708-711

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

--001a113ee6a446c7c00523c36f6f-- From nobody Wed Nov 4 20:34:14 2015 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 E572F1B38EE for ; Wed, 4 Nov 2015 20:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Ai-YTZCAoR_e for ; Wed, 4 Nov 2015 20:34:08 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::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 A4FB01B38EB for ; Wed, 4 Nov 2015 20:34:08 -0800 (PST) Received: by ykek133 with SMTP id k133so112114375yke.2 for ; Wed, 04 Nov 2015 20:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=6r0OMIts0XIp+Q76ouHO38jI6oZ/N8kFh4oUFYRxDKw=; b=MYNlFA0qH1lvYZ6gYAsk8y4xwwGAqjv7UmHSWkfch1m3irHGJ/SWDHc769+g+d4v9p GqK4b7xFPDEV1CUPG39Jx316eesQ/2VYGPMV2jpUesiRXZbEwrr0xr5N3zezOh8bzVMH iw5nZInwebv4YNr+ROx5sQT/V4EwjE83xwXIJIx2UfuDmPojjTwdgOz6Zj8KKGnEGnL3 6pG4kovsN35MQ1x8yMf3lE7ZJDUOFVhooNfz9hJV8qDLR58+RLFbAJyPOm7i0pfg+MiD gsZseZn3EUR1hfdYEWbCBaRI0YSkJZT9ee++qNwqtMgUeLS+EciG9RojcAdlIo7A1ugj 3j4Q== 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 :content-type; bh=6r0OMIts0XIp+Q76ouHO38jI6oZ/N8kFh4oUFYRxDKw=; b=kQ2TtSSX5lR5U1MeLsYhPKnUR7IH2A4VXrN+RaMC1jVieK0Q8RPhv7CdxShHLnObzv WCtC0/bgRj8FFwmM4Jai8voltKr/ySLEYTlwBYEGYF86MTWHIISXQe7E50zWGfhUxE4B aVENmSMRvM+L1uaz0Xi+PnifZMdwivB7i2kByqVQBND8l7blMrpxji3I1StUGI4BaqpO 5e62ENnXIcJ65+plw6nFuoAFEPd3uqinj3n5SXlUcfcUnrWiLBQlmCMEnMLGt8zN/9TQ VMId2DVUulRh1CrL0pFmnKflmCs1aFdtxKoZ5GFe8UllyJGqzX/ZYmvrnblW2qneDoEm 9g8Q== X-Gm-Message-State: ALoCoQk6fcWaKLVOKMEL7M/wcgJpCvrUwExvsLt1eIBy/v2BwnPYFawpTN/6q1WJ3nzXRA/968aK X-Received: by 10.31.41.149 with SMTP id p143mr5075646vkp.4.1446698047872; Wed, 04 Nov 2015 20:34:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.69.84 with HTTP; Wed, 4 Nov 2015 20:33:48 -0800 (PST) From: Justin Uberti Date: Thu, 5 Nov 2015 13:33:48 +0900 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a113ee6a43de4bd0523c3a314 Archived-At: Subject: [Ice] ICE minimum packet sizes 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: Thu, 05 Nov 2015 04:34:10 -0000 --001a113ee6a43de4bd0523c3a314 Content-Type: text/plain; charset=UTF-8 Martin mentioned this today, so while we're thinking about this I wanted to document the potential savings by doing some surgery. The current minimum possible STUN check size is 116 bytes (including IPv4 and UDP headers), which, when sent at a 10 ms interval, results in a 93 kbps send rate. I believe it is possible to reduce the minimum size to 60 bytes, while still maintaining 5389 compatibility, which works out to a 48 kbps send rate @ 10 ms. Details in https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8ZXHLJJpadBE/edit#slide=id.gc34db0b92_0_12 . --001a113ee6a43de4bd0523c3a314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin mentioned this today, so while we're thinking a= bout this I wanted to document the potential savings by doing some surgery.=

The current minimum possible STUN check size is 116 byt= es (including IPv4 and UDP headers), which, when sent at a 10 ms interval, = results in a 93 kbps send rate.

I believe it is po= ssible to reduce the minimum size to 60 bytes, while still maintaining 5389= compatibility, which works out to a 48 kbps send rate @ 10 ms.
<= br>

<= div>
--001a113ee6a43de4bd0523c3a314-- From nobody Sun Nov 15 15:57:39 2015 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 1B9101ACE6B; Sun, 15 Nov 2015 15:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mf83yC8ozYxf; Sun, 15 Nov 2015 15:57:35 -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 53B651ACE66; Sun, 15 Nov 2015 15:57:34 -0800 (PST) X-AuditID: c1b4fb30-f79626d000006adf-f3-56491becc090 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.2F.27359.CEB19465; Mon, 16 Nov 2015 00:57:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 16 Nov 2015 00:57:31 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux. Thread-Index: AdEfK4BAJnqr+40+QtGjMsJ85p/MlQ== Date: Sun, 15 Nov 2015 23:57:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C36C32@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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C36C32ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3VveNtGeYwcZOEYtvF2otpi5/zOLA 5LFkyU+mAMYoLpuU1JzMstQifbsErowpH/uZCybuYKxYc+oXUwPj9nmMXYycHBICJhJn1t5i hrDFJC7cW8/WxcjFISRwhFHizfQdjBDOEkaJSW93snYxcnCwCVhIdP/TBmkQEXCTuPr6ENgg ZgFbibmXLrCC2MIClRIXWhuZIGrqJB5/3cAGYetJfD7WyQ5iswioSryY8ZMFxOYV8JU4sPo4 WA0j0BHfT61hgpgpLnHryXwmiOMEJJbsOQ91qKjEy8f/WCFsJYkV2y9B3ZAvcampixFipqDE yZlPWCYwCs9CMmoWkrJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRtHi1OKk 3HQjI73Uoszk4uL8PL281JJNjMC4Objlt8EOxpfPHQ8xCnAwKvHwGnx1DxNiTSwrrsw9xCjB wawkwvuDxTNMiDclsbIqtSg/vqg0J7X4EKM0B4uSOG8z04NQIYH0xJLU7NTUgtQimCwTB6dU A2Na0uo50ZU2OdVrK2q1/HRWcJdffmWpMCPev4HprtmBvr0bdvgW2R7jPPTWLpdRmXWN9p1M IX5lP+XLRgx2x7TeTnp27dJs3/ksl6QrmMzOnK01LGKdIFG/7+xiqctrHsSGyNgt+Px45v3G vSVbPh3scNn54sei/se8BrO+88t9+Se81TKj1UqJpTgj0VCLuag4EQAW7MHRlwIAAA== Archived-At: Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux. 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: Sun, 15 Nov 2015 23:57:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C36C32ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I went through draft-ietf-mmusic-rfc5245bis-05, and identified the followin= g paragraphs that need to be modified in order to support the ICE solution = for exclusive support of RTP/RTCP-mux. Also, I assume the discussion regarding the ICE solution should move to the= ICE WG, while the discussion on the mux-exclusive draft will stay in MMUSI= C. Section 3: ------------- OLD TEXT: Component: A component is a piece of a media stream requiring a single transport address; a media stream may require multiple components, each of which has to work for the media stream as a whole to work. For media streams based on RTP, there are two components per media stream -- one for RTP, and one for RTCP. NEW TEXT: Component: A component is a piece of a media stream requiring a single transport address; a media stream may require multiple components, each of which has to work for the media stream as a whole to work. For media streams based on RTP, unless RTP and R= TCP are multiplexed on the same port, there are two components per media stream -- one for RTP, and one for RTCP. Section 4.1.1.1: -------------------- OLD TEXT: Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP, it MUST obtain a candidate for it. If an agent is using both RTP and RTCP, it would end up with 2*K host candidates if an agent has K IP addresses. NEW TEXT (based on e-mail discussion): Each component has an ID assigned to it, called the component ID. For RTP-based media streams, unless RTP and RTCP are multiplexed on the same port (RTP/RTCP multiplexing), the RTP has a component ID of 1 and RTCP a component ID of 2. In case of RTP/RTCP multiplexing, a component ID of 1 is used for both RTP and RTCP. When candidates are obtained, unless the agent knows for sure that RTP/RTCP multiplexing will be used (i.e. the agent knows that the other agent also supports, and is willing to use, RTP/RTCP multiplexing), or unless the agent only supports RTP/RTCP multiplexing, the agent MUST obtain a separate candidate for RTCP. If an agent has obtained a candidate for RTCP, and end up using RTP/RTCP multiplexing, the agent does not need to perform connectivity checks on the RTCP candidat= e. If an agent is using separate candidates for RTP and RTCP, it will end up with 2*K host candidates if the agent has K IP addresses. NOTE: The responding agent, when obtaining its candidates, will typically k= now whether the other agent supports RTP/RTCP multiplexing, in which case it wi= ll not need to obtain a separate candidate for RTCP. Section 4.2: --------------- OLD TEXT: Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP, it MUST obtain candidates for it. NEW TEXT: Each component has an ID assigned to it, called the component ID. For RTP-based media streams, the RTP itself has a component ID of 1, and RTCP a component ID of 2. If an agent is using RTCP, it MUST obtain candidates for it, unless the agent only supports multipl= exing of RTP and RTCP on the same port. Section 5.6.1: ----------------- OLD TEXT: In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the offerer can multiplex RTP and RTCP on the same port and signals that it can do that in the SDP through an SDP attribute [RFC5761]. However, since the offerer doesn't know if the answerer can perform such multiplexing, the offerer includes candidates for RTP and RTCP on separate ports, so that the offer has two components per media stream. If the answerer can perform such multiplexing, it would include just a single component for each candidate -- for the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate. NEW TEXT: In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the offerer can multiplex RTP and RTCP on the same port and signals that it can do that in the SDP through an SDP attribute [RFC5761]. However, since the offerer doesn't know if the answerer can perform such multiplexing, and unless the offerer only supports multiplexin= g of RTP and RTCP on the same port, the offerer includes candidates = for RTP and RTCP on separate ports, so that the offer has two components per media stream. If the answerer can perform such multiplexing, it would include just a single component for each candidate -- for the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate.If the offerer only supports multiplexing of RTP and RTCP on the same port, the offerer only includes candidates for RTP. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C36C32ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

I went through draft-ietf-mmusic-rfc5245bis-05, and = identified the following paragraphs that need to be modified in order to su= pport the ICE solution for exclusive support of RTP/RTCP-mux.

 

Also, I assume the discussion regarding the ICE solu= tion should move to the ICE WG, while the discussion on the mux-exclusive d= raft will stay in MMUSIC.

 

 

Section 3:

-------------

 

OLD TEXT:

 

Component:  A component is a piece of = a media stream requiring a

      single transport address; a media stream = may require multiple

      components, each of which has to work for= the media stream as a

      whole to work.  For media streams ba= sed on RTP, there are two

      components per media stream -- one for RT= P, and one for RTCP.

 

 

NEW TEXT:

 

Component:  A component is a piece of = a media stream requiring a

      single transport address; a media stream = may require multiple

      components, each of which has to work for= the media stream as a

      whole to work.  For media streams ba= sed on RTP, <new>unless RTP and RTCP

are multiplexed on the same port,</new&g= t; there are two

      components per media stream -- one for RT= P, and one for RTCP.

 

Section 4.1.1.1:

--------------------

 

OLD TEXT:

 

   Each component has an ID assigned to it, called the compone= nt ID.

   For RTP-based media streams, the RTP itself has a component= ID of 1,

   and RTCP a component ID of 2.  If an agent is using RT= CP, it MUST

   obtain a candidate for it.  If an agent is using both = RTP and RTCP,

   it would end up with 2*K host candidates if an agent has K = IP

   addresses.

 

 

NEW TEXT (based on e-mail discussion):

 

Each component has a= n ID assigned to it, called the component ID.

For RTP-based media = streams, unless RTP and RTCP are multiplexed on

the same port (RTP/R= TCP multiplexing), the RTP has a component ID of 1

and RTCP a component= ID of 2. In case of RTP/RTCP multiplexing, a

component ID of 1 is= used for both RTP and RTCP.

 

When candidates are = obtained, unless the agent knows for sure that

RTP/RTCP multiplexin= g will be used (i.e. the agent knows that the

other agent also sup= ports, and is willing to use, RTP/RTCP multiplexing),

or unless the agent = only supports RTP/RTCP multiplexing,

the agent MUST obtai= n a separate candidate for RTCP. If an agent has

obtained a candidate= for RTCP, and end up using RTP/RTCP multiplexing,

the agent does not n= eed to perform connectivity checks on the RTCP candidate.

 

If an agent is using= separate candidates for RTP and RTCP, it will end up

with 2*K host candid= ates if the agent has K IP addresses.

 

NOTE: The responding= agent, when obtaining its candidates, will typically know

whether the other ag= ent supports RTP/RTCP multiplexing, in which case it will

not need to obtain a= separate candidate for RTCP.

 

 

 

 

Section 4.2:

---------------

 

OLD TEXT:

 

Each component has an ID assigned to it, ca= lled the component ID.

      For RTP-based media streams, the RTP itself ha= s a component ID of 1,

      and RTCP a component ID of 2.  If an agen= t is using RTCP, it MUST

      obtain candidates for it.

 

NEW TEXT:

 

Each component has an ID assigned to it, ca= lled the component ID.

      For RTP-based media streams, the RTP itself ha= s a component ID of 1,

      and RTCP a component ID of 2.  If an agen= t is using RTCP, it MUST

      obtain candidates for it<new>, unless th= e agent only supports multiplexing

      of RTP and RTCP on the same port</new&= gt;.

 

 

 

Section 5.6.1:

-----------------

 

OLD TEXT:

 

   In the case of RTP, this would happen when one agent provid= es

   candidates for RTCP, and the other does not.  As anoth= er example, the

   offerer can multiplex RTP and RTCP on the same port and sig= nals that

   it can do that in the SDP through an SDP attribute [RFC5761= ].

   However, since the offerer doesn't know if the answerer can= perform

   such multiplexing, the offerer includes candidates for RTP = and RTCP

   on separate ports, so that the offer has two components per= media

   stream.  If the answerer can perform such multiplexing= , it would

   include just a single component for each candidate -- for t= he

   combined RTP/RTCP mux.  ICE would end up acting as if = there was just

   a single component for this candidate.

 

 

NEW TEXT:

 

   In the case of RTP, this would happen when one agent provid= es

   candidates for RTCP, and the other does not.  As anoth= er example, the

   offerer can multiplex RTP and RTCP on the same port and sig= nals that

   it can do that in the SDP through an SDP attribute [RFC5761= ].

   However, since the offerer doesn't know if the answerer can= perform

   such multiplexing, <new>and unless the offerer only s= upports multiplexing

   of RTP and RTCP on the same port,</new> the offerer i= ncludes candidates for RTP and RTCP

   on separate ports, so that the offer has two components per= media

   stream.  If the answerer can perform such multiplexing= , it would

   include just a single component for each candidate -- for t= he

   combined RTP/RTCP mux.  ICE would end up acting as if = there was just

   a single component for this candidate.<new>If the off= erer only supports

   multiplexing of RTP and RTCP on the same port, the offerer = only includes

   candidates for RTP.</new>

 

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37C36C32ESESSMB209erics_-- From nobody Sun Nov 22 10:15:43 2015 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 8B82D1B32EA for ; Sun, 22 Nov 2015 10:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 T_shrJFpt7Ew for ; Sun, 22 Nov 2015 10:15:40 -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 19F4A1B32E9 for ; Sun, 22 Nov 2015 10:15:39 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-d7-565206493c88 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C9.21.04914.94602565; Sun, 22 Nov 2015 19:15:37 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.29]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Sun, 22 Nov 2015 19:15:36 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: ICE WG Thread-Topic: Draft ICE WG meeting minutes from IETF 94 Thread-Index: AQHRJVHII+tV0vfkW0WvfKY54a1MrQ== Date: Sun, 22 Nov 2015 18:15:35 +0000 Message-ID: <0853B3D4-99DF-48A4-8D16-90BF6CE89C93@ericsson.com> 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: <10B3DD0BB981EA448AA7FEEF2DE6688E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdTteTLSjM4OM8YYtvF2otri1/zerA 5LFgU6nHkiU/mQKYorhsUlJzMstSi/TtErgyLuw6yFKwiqnizeblzA2M7xm7GDk5JARMJKb1 HWeFsMUkLtxbz9bFyMUhJHCYUeLLrMVQzmJGiQN3/4B1sAnYS0xe8xHMFhGQlGj5sxGsm1lA U+L+yYXsILawgJFE88NzLBA15hI//n9kg7D1JJav+w8WZxFQlWj5tIS5i5GDgxdo5r/jriBh RqAjvp9awwQxUlzi1pP5TBDHCUgs2XOeGcIWlXj5+B/U0UoSjUueQJ2gJ3Fj6hQ2CNtaYs7T p4wQtrbEsoWvwXp5BQQlTs58wjKBUXQWkhWzkLTPQtI+C0n7LCTtCxhZVzGKFqcWF+emGxnr pRZlJhcX5+fp5aWWbGIExs7BLb91dzCufu14iFGAg1GJh3eDfmCYEGtiWXFl7iFGCQ5mJRHe v9+BQrwpiZVVqUX58UWlOanFhxilOViUxHlbmB6ECgmkJ5akZqemFqQWwWSZODilGhjLlA6o tR2Nklbet2Pbs/fV63NPlDS+vLb9rnjn5bUbj072Vl8XOK1ekam30iwlU6fXeF6xBVfb7yZZ Z7tIu+7P/Y0+ITKMxflBP1fEzs2/9W/hJ84zb7UN5y6/0Mf+65fBwwmrE1a+Lv59SHvbo0kn OKKa0747vF/JXFr8iUvfbUuybDPHoXIlluKMREMt5qLiRADqxuXLmQIAAA== Archived-At: Cc: Peter Thatcher Subject: [Ice] Draft ICE WG meeting minutes from IETF 94 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: Sun, 22 Nov 2015 18:15:41 -0000 Hi all, Draft meeting minutes from the Yokohama ICE WG meeting are now available: https://www.ietf.org/proceedings/94/minutes/minutes-94-ice Please review the minutes and let us know if you have any questions, commen= ts, or corrections. Thanks, Ari & Peter (ICE WG co-chairs)= From nobody Mon Nov 30 18:04:42 2015 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 93B291B367E for ; Mon, 30 Nov 2015 18:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3b_VYou_9Ekm for ; Mon, 30 Nov 2015 18:04:35 -0800 (PST) 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 3B8451B36C6 for ; Mon, 30 Nov 2015 18:04:35 -0800 (PST) Received: by oiww189 with SMTP id w189so107710040oiw.3 for ; Mon, 30 Nov 2015 18:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=F66eJWKzDlj1HAMBRGNZtxVIVz0LqVtlFxL81TJAegI=; b=fpUrCJzU7ZM5jlhL8AAybq0T/uPK2F3DbMjULQD9pP4+aiXaXyY7jkPx9wMRpU3nzq ONvWD44KuGKuxb041dnxk1Jtdwk57AnNzUWq62KL1srHo1HEAQHHeufMzbIVbKPraUMM D3ka6gy+2uDcXc/JZS6R/QTpDuuEhYBx+0bqtBCxa9yZ4FBYO0g64LzwvpdGA8+tFS6s kRbF15V+mutJ3cYsrYgUWjYRS+/gxo9wbH5mtotFZiXr8v281QEl0rUMUEh/bIwLylhp t5Kb+xgdUb777dA+oPRk8HHQsvi7hOpbn1mFuHPSetKE4s4qqx8Qt+8Wwib4GEjnlTrh 87Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=F66eJWKzDlj1HAMBRGNZtxVIVz0LqVtlFxL81TJAegI=; b=BIu7CCne2678EfY8+r3b+6zxJNeWSoaDiXYrh0m/sOcRjWcDeb3m8kvjOWubaCjpWQ iV5UE0qQHz2vFCmQfT/+UkKQf/A3xYPpcIJINmJ0tlwmfbkrQT/LMu+NKiS+xSPj2KaT 4XW/9pT7kwj9J346oaNe1mJNv0xArLNuVMuM/B2rGZJLrQfQywAVrjReQ0gYVMdHrID7 hmDb5e0qhbXh1jHubYYEndbiK4JqVPUMea1uZL5k3cGl3FHS3vAXIXJhsmWnAJhBVuyW Su0zbBr3MYZtA77snC4cqt5Bh8JX6rLf4l2osYW9y5IOzYo1q6DUrVjKp0NFSYRg+zUV EgoA== X-Gm-Message-State: ALoCoQlFDQGy0OONK1bILzBP4ZHEDTEreI2HeY3jOMA84SISZhJvEge/AP9ii8hAfRv8UVb10ZtV X-Received: by 10.202.207.12 with SMTP id f12mr45656519oig.101.1448935474376; Mon, 30 Nov 2015 18:04:34 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by smtp.googlemail.com with ESMTPSA id of1sm22521760obb.18.2015.11.30.18.04.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 18:04:32 -0800 (PST) To: ice@ietf.org From: Peter Saint-Andre Message-ID: <565D002F.1010201@andyet.net> Date: Mon, 30 Nov 2015 19:04:31 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ice] "waiting-for-candidates" state in 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, 01 Dec 2015 02:04:40 -0000 Hi all, I've started to work on fixes to draft-ietf-ice-trickle for the open issues and the IETF 94 discussion items. One such item was the addition of a "waiting-for-candidates" state to handle the situation when a checklist is empty and no candidate pairs have been sent or received. Looking again at RFC 5245 and draft-ietf-ice-rfc5245bis, I'd say that in ICE core the concept of state applies to a candidate pair, not to a checklist. Therefore I suggest that we not attempt to define this new state for checklists in trickle-ice. However, I think it would be appropriate to add a few words about this situation (without formally calling it a state). Peter