From nobody Wed Dec 2 04:05:38 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 A48B41A88C6 for ; Wed, 2 Dec 2015 04:05:37 -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 kYWJVz5-shJR for ; Wed, 2 Dec 2015 04:05:35 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0F11A8886 for ; Wed, 2 Dec 2015 04:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7794; q=dns/txt; s=iport; t=1449057935; x=1450267535; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=96t0YC+XDmFAqBvSV/uacPAltYNiXEVrK1DWiREgT9w=; b=PyLQnnq6mCbLW7q5/xr/wZ+u8euCXcJgySKt/v6cmvrNpMeBCnY2lKmP FATBvUTwUYdzx7clGCQHPgAb5XaHtE6YOdkJKoysCn6WkxX/KxAzEuTST ack4NK1zUbHXLyop74STl9RoSSmwrd9gs3Diz2TXUrlWz7+0QdoaSrLqx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgDI3V5W/40NJK1egm5MU28GvgIBD?= =?us-ascii?q?YFuFwEJhW0CHIEtOBQBAQEBAQEBgQqENQEBBAEBASBLCxACAQg/AwICAiULFBE?= =?us-ascii?q?CBA4FiC8NrimRAwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlSCD4Juh3UvgRUFh?= =?us-ascii?q?0qHDogEAY06nGkBHwEBQoQEcoRogQcBAQE?= X-IronPort-AV: E=Sophos; i="5.20,373,1444694400"; d="scan'208,217"; a="49929888" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2015 12:05:34 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tB2C5YSh016191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 12:05:34 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 07:05:33 -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, 2 Dec 2015 07:05:33 -0500 From: "Pal Martinsen (palmarti)" To: Peter Saint-Andre Thread-Topic: [Ice] "waiting-for-candidates" state in trickle-ice Thread-Index: AQHRK9yn2Vs256pR90+Y/AOIaszOXJ6375QA Date: Wed, 2 Dec 2015 12:05:33 +0000 Message-ID: References: <565D002F.1010201@andyet.net> In-Reply-To: <565D002F.1010201@andyet.net> 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.61.215.32] Content-Type: multipart/alternative; boundary="_000_CA04AC155D3E4DBA9F3C4ED8A728E0DBciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" Subject: Re: [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: Wed, 02 Dec 2015 12:05:37 -0000 --_000_CA04AC155D3E4DBA9F3C4ED8A728E0DBciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwMSBEZWMgMjAxNSwgYXQgMDM6MDQsIFBldGVyIFNhaW50LUFuZHJlIDxwZXRlckBhbmR5 ZXQubmV0PG1haWx0bzpwZXRlckBhbmR5ZXQubmV0Pj4gd3JvdGU6DQoNCkhpIGFsbCwNCg0KSSd2 ZSBzdGFydGVkIHRvIHdvcmsgb24gZml4ZXMgdG8gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSBmb3Ig dGhlIG9wZW4gaXNzdWVzIGFuZCB0aGUgSUVURiA5NCBkaXNjdXNzaW9uIGl0ZW1zLg0KDQpPbmUg c3VjaCBpdGVtIHdhcyB0aGUgYWRkaXRpb24gb2YgYSAid2FpdGluZy1mb3ItY2FuZGlkYXRlcyIg c3RhdGUgdG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlbiBhIGNoZWNrbGlzdCBpcyBlbXB0eSBh bmQgbm8gY2FuZGlkYXRlIHBhaXJzIGhhdmUgYmVlbiBzZW50IG9yIHJlY2VpdmVkLg0KDQpMb29r aW5nIGFnYWluIGF0IFJGQyA1MjQ1IGFuZCBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLCBJJ2Qg c2F5IHRoYXQgaW4gSUNFIGNvcmUgdGhlIGNvbmNlcHQgb2Ygc3RhdGUgYXBwbGllcyB0byBhIGNh bmRpZGF0ZSBwYWlyLCBub3QgdG8gYSBjaGVja2xpc3QuIFRoZXJlZm9yZSBJIHN1Z2dlc3QgdGhh dCB3ZSBub3QgYXR0ZW1wdCB0byBkZWZpbmUgdGhpcyBuZXcgc3RhdGUgZm9yIGNoZWNrbGlzdHMg aW4gdHJpY2tsZS1pY2UuIEhvd2V2ZXIsIEkgdGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUg dG8gYWRkIGEgZmV3IHdvcmRzIGFib3V0IHRoaXMgc2l0dWF0aW9uICh3aXRob3V0IGZvcm1hbGx5 IGNhbGxpbmcgaXQgYSBzdGF0ZSkuDQoNCg0KRnJvbSBzZWN0aW9uIDUuNy40Og0KDQpUaGUgY2hl Y2sgbGlzdCBpdHNlbGYgaXMgYXNzb2NpYXRlZCB3aXRoIGEgc3RhdGUsIHdoaWNoIGNhcHR1cmVz IHRoZQ0KICAgc3RhdGUgb2YgSUNFIGNoZWNrcyBmb3IgdGhhdCBtZWRpYSBzdHJlYW0uICBUaGVy ZSBhcmUgdGhyZWUgc3RhdGVzOg0KDQogICBSdW5uaW5nOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNo ZWNrcyBhcmUgc3RpbGwgaW4gcHJvZ3Jlc3MgZm9yIHRoaXMNCiAgICAgIG1lZGlhIHN0cmVhbS4N Cg0KICAgQ29tcGxldGVkOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBoYXZlIHByb2R1Y2Vk IG5vbWluYXRlZCBwYWlycw0KICAgICAgZm9yIGVhY2ggY29tcG9uZW50IG9mIHRoZSBtZWRpYSBz dHJlYW0uICBDb25zZXF1ZW50bHksIElDRSBoYXMNCiAgICAgIHN1Y2NlZWRlZCBhbmQgbWVkaWEg Y2FuIGJlIHNlbnQuDQoNCiAgIEZhaWxlZDogIEluIHRoaXMgc3RhdGUsIHRoZSBJQ0UgY2hlY2tz IGhhdmUgbm90IGNvbXBsZXRlZA0KICAgICAgc3VjY2Vzc2Z1bGx5IGZvciB0aGlzIG1lZGlhIHN0 cmVhbS4NCg0KICAgV2hlbiBhIGNoZWNrIGxpc3QgaXMgZmlyc3QgY29uc3RydWN0ZWQgYXMgdGhl IGNvbnNlcXVlbmNlIG9mIGFuDQogICBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIGl0IGlzIHBsYWNl ZCBpbiB0aGUgUnVubmluZyBzdGF0ZS4NCg0KVGhpcyBpcyB3aGVyZSBJIHRoaW5rIHdlIHdhbnRl ZCB0aGUgd2FpdGluZy1mb3ItY2FuZGlkYXRlcyBzdGF0ZS4gTW9zdGx5IGJlY2F1c2UgdGhhdCB3 b3VsZCBoZWxwIG1lIGltcGxlbWVudCBteSBzdGF0ZSBtYWNoaW5lIGNvcnJlY3RseS4gWW91IGNv dWxkIGJlIGluIHJ1bm5pbmcgYW5kIHNheSB0aGF0IHlvdSBhcmUgd2FpdGluZyBmb3IgY2FuZGlk YXRlcywgYnV0IHRoYXQgd291bGQgc29tZWhvdyBicmVhayB0aGUgbmljZSBzdGF0ZS1tYWNoaW5l IGJ5IGFkZGluZyBmbGFncyBldGMgSSBhbSBpbiBydW5uaW5nLCBidXQgd2FpdGluZyBmb3IgY2Fu ZGlkYXRlcyBldGMuLg0KDQpCdXQgdGhlIGNoZWNrbGlzdCBzdGF0ZXMgYXJlIHNvbWV3aGF0IGhp ZGRlbiBpbiB0aGUgdGV4dCwgbWF5YmUgaXQgd291bGQgYmUgZ29vZCB0byBzb21laG93IGhpZ2hs aWdodCBpdCBhIGJpdCBtb3JlIGluIElDRWJpcz8NCihJIGNhbiBwcm92aWRlIHNvbWUgdGV4dCBl YXJseSBuZXh0IHllYXIuKQ0KDQouLS4NClDDpWwtRXJpaw0KDQoNClBldGVyDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGluZyBsaXN0 DQpJY2VAaWV0Zi5vcmc8bWFpbHRvOkljZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWNlDQoNCg== --_000_CA04AC155D3E4DBA9F3C4ED8A728E0DBciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwMSBE ZWMgMjAxNSwgYXQgMDM6MDQsIFBldGVyIFNhaW50LUFuZHJlICZsdDs8YSBocmVmPSJtYWlsdG86 cGV0ZXJAYW5keWV0Lm5ldCIgY2xhc3M9IiI+cGV0ZXJAYW5keWV0Lm5ldDwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhpIGFsbCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJJ3ZlIHN0YXJ0ZWQgdG8gd29yayBvbiBmaXhlcyB0byBkcmFmdC1pZXRmLWljZS10cmlja2xl IGZvciB0aGUgb3BlbiBpc3N1ZXMgYW5kIHRoZSBJRVRGIDk0IGRpc2N1c3Npb24gaXRlbXMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT25lIHN1Y2ggaXRlbSB3YXMgdGhlIGFkZGl0aW9u IG9mIGEgJnF1b3Q7d2FpdGluZy1mb3ItY2FuZGlkYXRlcyZxdW90OyBzdGF0ZSB0byBoYW5kbGUg dGhlIHNpdHVhdGlvbiB3aGVuIGEgY2hlY2tsaXN0IGlzIGVtcHR5IGFuZCBubyBjYW5kaWRhdGUg cGFpcnMgaGF2ZSBiZWVuIHNlbnQgb3IgcmVjZWl2ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KTG9va2luZyBhZ2FpbiBhdCBSRkMgNTI0NSBhbmQgZHJhZnQtaWV0Zi1pY2UtcmZjNTI0 NWJpcywgSSdkIHNheSB0aGF0IGluIElDRSBjb3JlIHRoZSBjb25jZXB0IG9mIHN0YXRlIGFwcGxp ZXMgdG8gYSBjYW5kaWRhdGUgcGFpciwgbm90IHRvIGEgY2hlY2tsaXN0LiBUaGVyZWZvcmUgSSBz dWdnZXN0IHRoYXQgd2Ugbm90IGF0dGVtcHQgdG8gZGVmaW5lIHRoaXMgbmV3IHN0YXRlIGZvciBj aGVja2xpc3RzIGluIHRyaWNrbGUtaWNlLiBIb3dldmVyLA0KIEkgdGhpbmsgaXQgd291bGQgYmUg YXBwcm9wcmlhdGUgdG8gYWRkIGEgZmV3IHdvcmRzIGFib3V0IHRoaXMgc2l0dWF0aW9uICh3aXRo b3V0IGZvcm1hbGx5IGNhbGxpbmcgaXQgYSBzdGF0ZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PkZyb20gc2VjdGlvbiA1LjcuNDo8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNz PSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxMy4zMzMzcHg7IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyBsaW5lLWhlaWdo dDogbm9ybWFsOyB3aWRvd3M6IDE7Ij5UaGUgY2hlY2sgbGlzdCBpdHNlbGYgaXMgYXNzb2NpYXRl ZCB3aXRoIGEgc3RhdGUsIHdoaWNoIGNhcHR1cmVzIHRoZQ0KICAgc3RhdGUgb2YgSUNFIGNoZWNr cyBmb3IgdGhhdCBtZWRpYSBzdHJlYW0uICBUaGVyZSBhcmUgdGhyZWUgc3RhdGVzOg0KDQogICBS dW5uaW5nOiAgSW4gdGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBhcmUgc3RpbGwgaW4gcHJvZ3Jlc3Mg Zm9yIHRoaXMNCiAgICAgIG1lZGlhIHN0cmVhbS4NCg0KICAgQ29tcGxldGVkOiAgSW4gdGhpcyBz dGF0ZSwgSUNFIGNoZWNrcyBoYXZlIHByb2R1Y2VkIG5vbWluYXRlZCBwYWlycw0KICAgICAgZm9y IGVhY2ggY29tcG9uZW50IG9mIHRoZSBtZWRpYSBzdHJlYW0uICBDb25zZXF1ZW50bHksIElDRSBo YXMNCiAgICAgIHN1Y2NlZWRlZCBhbmQgbWVkaWEgY2FuIGJlIHNlbnQuDQoNCiAgIEZhaWxlZDog IEluIHRoaXMgc3RhdGUsIHRoZSBJQ0UgY2hlY2tzIGhhdmUgbm90IGNvbXBsZXRlZA0KICAgICAg c3VjY2Vzc2Z1bGx5IGZvciB0aGlzIG1lZGlhIHN0cmVhbS4NCg0KICAgV2hlbiBhIGNoZWNrIGxp c3QgaXMgZmlyc3QgY29uc3RydWN0ZWQgYXMgdGhlIGNvbnNlcXVlbmNlIG9mIGFuDQogICBvZmZl ci9hbnN3ZXIgZXhjaGFuZ2UsIGl0IGlzIHBsYWNlZCBpbiB0aGUgUnVubmluZyBzdGF0ZS48L3By ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+VGhp cyBpcyB3aGVyZSBJIHRoaW5rIHdlIHdhbnRlZCB0aGUgd2FpdGluZy1mb3ItY2FuZGlkYXRlcyBz dGF0ZS4gTW9zdGx5IGJlY2F1c2UgdGhhdCB3b3VsZCBoZWxwIG1lIGltcGxlbWVudCBteSBzdGF0 ZSBtYWNoaW5lIGNvcnJlY3RseS4gWW91IGNvdWxkIGJlIGluIHJ1bm5pbmcgYW5kIHNheSB0aGF0 IHlvdSBhcmUgd2FpdGluZyBmb3IgY2FuZGlkYXRlcywgYnV0IHRoYXQgd291bGQgc29tZWhvdyBi cmVhayB0aGUgbmljZSBzdGF0ZS1tYWNoaW5lDQogYnkgYWRkaW5nIGZsYWdzIGV0YyBJIGFtIGlu IHJ1bm5pbmcsIGJ1dCB3YWl0aW5nIGZvciBjYW5kaWRhdGVzIGV0Yy4uPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5CdXQgdGhlIGNoZWNrbGlzdCBzdGF0ZXMgYXJlIHNv bWV3aGF0IGhpZGRlbiBpbiB0aGUgdGV4dCwgbWF5YmUgaXQgd291bGQgYmUgZ29vZCB0byBzb21l aG93IGhpZ2hsaWdodCBpdCBhIGJpdCBtb3JlIGluIElDRWJpcz88L2Rpdj4NCjxkaXY+KEkgY2Fu IHByb3ZpZGUgc29tZSB0ZXh0IGVhcmx5IG5leHQgeWVhci4pPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdj4uLS48L2Rpdj4NCjxkaXY+UMOlbC1FcmlrPC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5QZXRlcjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KSWNlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciIGNsYXNzPSIiPkljZUBpZXRmLm9yZzwv YT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lj ZTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CA04AC155D3E4DBA9F3C4ED8A728E0DBciscocom_-- From nobody Wed Dec 2 04:17:09 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 33DF71A892E for ; Wed, 2 Dec 2015 04:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 62ZmAgCbTOBF for ; Wed, 2 Dec 2015 04:17:00 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC571A890F for ; Wed, 2 Dec 2015 04:17:00 -0800 (PST) Received: by obbbj7 with SMTP id bj7so30847396obb.1 for ; Wed, 02 Dec 2015 04:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51T4Nu6zHyuRAl0Bh7YU2Ok+IooQ57KjaMfFc8xcqMA=; b=fICXdoP7SXIwSmYyTrRcXKP7CPDHEHaYG8zHmSNmm6/71ipmLj4C8ZZmS9Ldtma12l tFuMQP/bb+IbcXzipZ5+klteY0ihoD9HXa0p2GSZFbCcggeDkKu8965CVBloBhFPsOys DUiUErn1kQPbMiKBiDZDgR3uCg2e1CtdpyD94KQmXX2T1m+Gfp14J9FfA4rywrdDj4pW L2Hw1wG1EzpOB7MrVNXEyfpfATd8ze2DA5LpNlzAZqzjgkPhiHBzy61J9jtEY8TIW3rJ Fob+9VbXW3yxBywtH0oczmDavQ3DwljrZYnh1mkr7BmSWfC4b4Vgd5m6YzkgrnExuSZ0 Dejg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=51T4Nu6zHyuRAl0Bh7YU2Ok+IooQ57KjaMfFc8xcqMA=; b=LIaBc4Dyay03A1pwN3kGfL6y4HjYCPVMxJFCRfK7ZIaZSjAgNH7YExEMmj3BqrU+KR 9da21R7MqGD0/aAFc7l74PoteQ3dfIxeXH6X/t+l96Z0rTl+sxaE2WXc7H6ewsymw+TJ mTTIa7pRd75iQ5k+1qyyHTEttIB+MYEkOhvSsvzDErQ5zaV8MP93t+vTd/N59qVLZO3z zXqhlbdckDAgCYKpMXOEbXduTv0xMouP+Om54aC49qH9d/Lsv3dG/ZPRW7FDRe99MJj+ OGfWGH5+Hdnbx4QuHKvCOgJG+3pPlVX85XuKPcrbPpGj2reHPpMegqTX92G38K17bcuq 91Rg== X-Gm-Message-State: ALoCoQk9FHH6/NYi9QQnwMas1Gpt75XL7kcPUwlurJfZQ1g4lYNVJ9Ti8MZx3NH32wwl2fwk3U95 X-Received: by 10.60.115.194 with SMTP id jq2mr2297347oeb.7.1449058619567; Wed, 02 Dec 2015 04:16:59 -0800 (PST) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com. [209.85.218.42]) by smtp.gmail.com with ESMTPSA id m206sm1160826oig.13.2015.12.02.04.16.58 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 04:16:59 -0800 (PST) Received: by oies6 with SMTP id s6so23467141oie.1 for ; Wed, 02 Dec 2015 04:16:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.188.66 with SMTP id m63mr2187356oif.127.1449058618396; Wed, 02 Dec 2015 04:16:58 -0800 (PST) Received: by 10.76.56.138 with HTTP; Wed, 2 Dec 2015 04:16:58 -0800 (PST) In-Reply-To: References: <565D002F.1010201@andyet.net> Date: Wed, 2 Dec 2015 06:16:58 -0600 X-Gmail-Original-Message-ID: Message-ID: From: Emil Ivov To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a113dd6883591730525e94031 Archived-At: Cc: Peter Saint-Andre , "ice@ietf.org" Subject: Re: [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: Wed, 02 Dec 2015 12:17:02 -0000 --001a113dd6883591730525e94031 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I really don't think we need such a state and that having the existing "Wait" is enough. Also easier to implement than adding yet another state. I am currently traveling but I'll try to look into this more by the end of the week. Emil On Wednesday, 2 December 2015, Pal Martinsen (palmarti) wrote: > > On 01 Dec 2015, at 03:04, Peter Saint-Andre > wrote: > > 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 hav= e > 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 sta= te > for checklists in trickle-ice. However, I think it would be appropriate t= o > add a few words about this situation (without formally calling it a state= ). > > > From section 5.7.4: > > The check list itself is associated with a state, which captures the > state of ICE checks for that media stream. There are three states: > > Running: In this state, ICE checks are still in progress for this > media stream. > > Completed: In this state, ICE checks have produced nominated pairs > for each component of the media stream. Consequently, ICE has > succeeded and media can be sent. > > Failed: In this state, the ICE checks have not completed > successfully for this media stream. > > When a check list is first constructed as the consequence of an > offer/answer exchange, it is placed in the Running state. > > > This is where I think we wanted the waiting-for-candidates state. Mostly > because that would help me implement my state machine correctly. You coul= d > be in running and say that you are waiting for candidates, but that would > somehow break the nice state-machine by adding flags etc I am in running, > but waiting for candidates etc.. > > But the checklist states are somewhat hidden in the text, maybe it would > be good to somehow highlight it a bit more in ICEbis? > (I can provide some text early next year.) > > .-. > P=C3=A5l-Erik > > > Peter > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > --=20 sent from my mobile --001a113dd6883591730525e94031 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I really don't think we need such a state and that having the existing = "Wait" is enough. Also easier to implement than adding yet anothe= r state.

I am currently traveling but I'll try to lo= ok into this more by the end of the week.

Emil

On Wedn= esday, 2 December 2015, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:

On 01 Dec 2015, at 03:04, Peter Saint-Andre <pe= ter@andyet.net> wrote:

Hi all,

I've started to work on fixes to draft-ietf-ice-trickle for the open is= sues and the IETF 94 discussion items.

One such item was the addition of a "waiting-for-candidates" stat= e 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 i= n ICE core the concept of state applies to a candidate pair, not to a check= list. 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 (w= ithout formally calling it a state).


From section 5.7.4:
The check list itself is associated with a state, which capture=
s the
   state of ICE checks for that media stream.  There are three states:

   Running:  In this state, ICE checks are still in progress for this
      media stream.

   Completed:  In this state, ICE checks have produced nominated pairs
      for each component of the media stream.  Consequently, ICE has
      succeeded and media can be sent.

   Failed:  In this state, the ICE checks have not completed
      successfully for this media stream.

   When a check list is first constructed as the consequence of an
   offer/answer exchange, it is placed in the Running state.

This is where I think we wanted the waiting-for-candidates state. Most= ly because that would help me implement my state machine correctly. You cou= ld be in running and say that you are waiting for candidates, but that woul= d somehow break the nice state-machine by adding flags etc I am in running, but waiting for candidates etc..

But the checklist states are somewhat hidden in the text, maybe it wou= ld be good to somehow highlight it a bit more in ICEbis?
(I can provide some text early next year.)

.-.
P=C3=A5l-Erik


Peter

_______________________________________________
Ice mailing list
Ice@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ice



--
sent from my mobile
--001a113dd6883591730525e94031-- From nobody Wed Dec 2 06:13:01 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 B9D411A9061; Wed, 2 Dec 2015 06:12:57 -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 Xt5HdCvh4sTR; Wed, 2 Dec 2015 06:12:53 -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 B024A1A9063; Wed, 2 Dec 2015 06:12:52 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-cd-565efc626c2c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.F6.05149.26CFE565; Wed, 2 Dec 2015 15:12:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 2 Dec 2015 15:12:50 +0100 From: Christer Holmberg To: Christer Holmberg , "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/MlQN4A3TA Date: Wed, 2 Dec 2015 14:12:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7A3F5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C36C32@ESESSMB209.ericsson.se> In-Reply-To: <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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7A3F5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7nG7Sn7gwg2NTzS2+Xai1mLr8MYsD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDKe/nrAXrDqEGPF0v8/WBsYDy5n7GLk5JAQMJE4e+wz K4QtJnHh3nq2LkYuDiGBw4wSs05eZIVwFjNK7Lu/nb2LkYODTcBCovufNkiDiECNxMe325lA bGYBW4m5ly6ADRIWqJX4dv4cC0RNncTjrxvYIGwjiRWHu8FsFgEViZkTd4AdwSvgK7HiUiNY vRCQ/a3hJZjNKeAnMXX9TjCbEei476fWQO0Sl7j1ZD4TxNECEkv2nGeGsEUlXj7+B/WMkkTj kiesEPX5EssO7oLaJShxcuYTlgmMorOQjJqFpGwWkjKIuJ7EjalT2CBsbYllC18zQ9i6EjP+ HWJBFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzDODm75bbCD8eVzx0OMAhyMSjy8 BWpxYUKsiWXFlbmHGCU4mJVEeOufAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzNjM9CBUSSE8s Sc1OTS1ILYLJMnFwSjUwerSyC7OutLvjX3HX++ru5zyv/0TxvjMKn5cnfuDSOefUs22JbyYU LuAV3yjy5+ObaUpzg9OPmmbcz1ohs9dxl2fyHtef8ZaWN1jbn8/R7ajpci15fFD5+VQ3Lm0+ e7X5zY+b7KNs3uzwmK9cd/00t+2yhkUlgml6cz5dnfx7Yb28+f0Xa7d/VWIpzkg01GIuKk4E AN00D9qvAgAA Archived-At: Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [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: Wed, 02 Dec 2015 14:12:57 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7A3F5ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any comments on this? From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 16 November 2015 01:58 To: mmusic@ietf.org; ice@ietf.org Cc: Ari Ker=E4nen Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution= for indicating exclusive support of RTP/RTCP-mux. 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_7594FB04B1934943A5C02806D1A2204B37C7A3F5ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Any comments on this?<= o:p>

 

From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 16 November 2015 01:58
To: mmusic@ietf.org; ice@ietf.org
Cc: Ari Ker=E4nen <ari.keranen@ericsson.com>
Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE s= olution for indicating exclusive support of RTP/RTCP-mux.=

 

 

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_7594FB04B1934943A5C02806D1A2204B37C7A3F5ESESSMB209erics_-- From nobody Wed Dec 2 14:30: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 A6D751B2E5A for ; Wed, 2 Dec 2015 14:30:13 -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 VUTZNsuk28fs for ; Wed, 2 Dec 2015 14:30:12 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 E96E01A701E for ; Wed, 2 Dec 2015 14:30:11 -0800 (PST) Received: by oiww189 with SMTP id w189so35247186oiw.3 for ; Wed, 02 Dec 2015 14:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andyet-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Y2rZibWporCyEormq2KDZDvXU48VLndpah+4Ieb5kH4=; b=yzV6DyYJO6Pm4cuqiYvQTxCwTy2pzVnZZKMnapg58XaXWnIy/+8NHxRVzBfknvsOAp o6BqQ6NZsZT4c/IvKqbT5J/0O1NiHAA4Qau6Oh/3ygTAF6a2g+6SmtLRfT0EhHtd975c Ub5XFKVe7vSIIU4n+mnKiuIK0bh/I6oJ1nhjfr094nHSLzcRScXYA69z1XfRZ9dFDL1q 7m7ehiC4YMtQO7MjP+fyp25PyyQqWcW9UcazekOLsH9jUaHYsDAdUKeDuhEH3/22s7lt xX22Flu6X/75ZV/VJj0ksMAL6BS7V/mtlFpPP8JNKVPOR+uIokiy36ruxHbJq8FnXrVY rNUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Y2rZibWporCyEormq2KDZDvXU48VLndpah+4Ieb5kH4=; b=PPwJPukEDcbB/H8HJkAw2bu7OXGxzfWnnu+a/8DMkMkGawcFD4ztMul3C4anUeuv4w kPQSN5eq+9xi0vqckk4zgg5isnLaZKUfNXt/DQmHJcDw8RoJRJW9bL0UVvtJWK8Z3C9H sdxzSB7g4bmRCM6crbKp64Ct8jw9MZ2baSgjO6mbs+NoZCukqp1z2652JvLmg8PGO+Af 87soydFzBrTc1l05GYnLa+kngyRymcSvMzb+tMvZt2dTRXa2LB2fXTOKh38vqy9uUOrH PP+9wZE0zij+bM7muJrKDmwf0zzMtpqMrW/9/FgEMEYG2lF7rypITKTyy+xU6W6TZ5j5 jJXw== X-Gm-Message-State: ALoCoQkw46ZXUrO6MsLBRIiRuHKExVwUDejdFhTZ0sbSQQSsw2cI9qKKAi89EGusI+sEWK8zN3tj X-Received: by 10.202.56.3 with SMTP id f3mr4917966oia.65.1449095411180; Wed, 02 Dec 2015 14:30:11 -0800 (PST) Received: from aither.local ([2601:282:4201:ef5b:7ded:5dbf:8c80:44c9]) by smtp.googlemail.com with ESMTPSA id i8sm2227150obt.3.2015.12.02.14.30.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Dec 2015 14:30:09 -0800 (PST) To: Emil Ivov , "Pal Martinsen (palmarti)" References: <565D002F.1010201@andyet.net> From: Peter Saint-Andre Message-ID: <565F70F0.3070607@andyet.net> Date: Wed, 2 Dec 2015 15:30:08 -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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [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: Wed, 02 Dec 2015 22:30:13 -0000 Although I was wrong about check list not having states, I agree with Emil that we don't need to add more states here. (I found a similar issue last night with potentially adding states for "Active" and "Frozen" at the check list level - see https://github.com/emcho/trickle-ice/issues/11 for my solipsistic ramblings.) Peter On 12/2/15 5:16 AM, Emil Ivov wrote: > I really don't think we need such a state and that having the existing > "Wait" is enough. Also easier to implement than adding yet another state. > > I am currently traveling but I'll try to look into this more by the end > of the week. > > Emil > > On Wednesday, 2 December 2015, Pal Martinsen (palmarti) > > wrote: > > >> On 01 Dec 2015, at 03:04, Peter Saint-Andre > > wrote: >> >> 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). >> > > From section 5.7.4: > > The check list itself is associated with a state, which captures the > state of ICE checks for that media stream. There are three states: > > Running: In this state, ICE checks are still in progress for this > media stream. > > Completed: In this state, ICE checks have produced nominated pairs > for each component of the media stream. Consequently, ICE has > succeeded and media can be sent. > > Failed: In this state, the ICE checks have not completed > successfully for this media stream. > > When a check list is first constructed as the consequence of an > offer/answer exchange, it is placed in the Running state. > > > This is where I think we wanted the waiting-for-candidates state. > Mostly because that would help me implement my state machine > correctly. You could be in running and say that you are waiting for > candidates, but that would somehow break the nice state-machine by > adding flags etc I am in running, but waiting for candidates etc.. > > But the checklist states are somewhat hidden in the text, maybe it > would be good to somehow highlight it a bit more in ICEbis? > (I can provide some text early next year.) > > .-. > Pål-Erik > > >> Peter >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice > > > > -- > sent from my mobile From nobody Wed Dec 2 15:28:19 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 167821A92FD; Wed, 2 Dec 2015 15:28:16 -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 Ntrg-ecy_Qkg; Wed, 2 Dec 2015 15:28:14 -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 9C6F61A92B3; Wed, 2 Dec 2015 15:28:13 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-85-565f7e8ac2d7 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.64.04914.A8E7F565; Thu, 3 Dec 2015 00:28:11 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.149]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 00:28:10 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Christer Holmberg 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/MlQN4A3TAABFKzwA= Date: Wed, 2 Dec 2015 23:28:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37C36C32@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C7A3F5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C7A3F5@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.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2J7iG53XXyYwb1NHBbfLtRaTF3+mMWB yWPJkp9MAYxRXDYpqTmZZalF+nYJXBknD05kLJhqWHHr7E7WBsYjql2MnBwSAiYSU49fYIew xSQu3FvP1sXIxSEkcJhRYl7HcRYIZzGjxI9LS1lAqtgE7CUmr/nICGKLCJhJXP/cywRiMwu4 STTf3AcWFxaolZj+6yArRE2dxOOvG9ggbCuJk19ugsVZBFQkug9MAavnBZp5Ys9KsBohgYmM Es9eaIDYnAJ+Eot3nAG7jhHouu+n1kDtEpe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStJLLr9 GapeT+LG1ClsELa1xJVre9khbG2JZQtfM0PcIChxcuYTlgmM4rOQrJiFpH0WkvZZSNpnIWlf wMi6ilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwyg5u+a27g3H1a8dDjAIcjEo8vB/K48OE WBPLiitzDzFKcDArifCyuwGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ87YwPQgVEkhPLEnNTk0t SC2CyTJxcEo1MNbuPX2b+cyVoCLDgLORrmFrGdTOi32s5ZFb9yIkL0pghfeajw1KUX13sg7+ s5NILIl1vXxvofEi2VXFKovn26cnWnxeck3idXTxEz0jHknxXeaSrvyX8wSMpyR7TLgT13zl p7uDSFlOnU7kt0/vQi9vXZjey2jDtCJZyLyoufrfNqGtq46XKrEUZyQaajEXFScCAN6ajV6u AgAA Archived-At: Cc: "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [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: Wed, 02 Dec 2015 23:28:16 -0000 Hi, These changes look good to me. If no one objects, I'll make the changes for= the next revision. Thanks, Ari > On 02 Dec 2015, at 16:12, Christer Holmberg wrote: >=20 > Any comments on this? > =20 > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 16 November 2015 01:58 > To: mmusic@ietf.org; ice@ietf.org > Cc: Ari Ker=E4nen > Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE soluti= on for indicating exclusive support of RTP/RTCP-mux. > =20 > =20 > Hi, > =20 > I went through draft-ietf-mmusic-rfc5245bis-05, and identified the follow= ing paragraphs that need to be modified in order to support the ICE solutio= n for exclusive support of RTP/RTCP-mux. > =20 > Also, I assume the discussion regarding the ICE solution should move to t= he ICE WG, while the discussion on the mux-exclusive draft will stay in MMU= SIC. > =20 > =20 > Section 3: > ------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT: > =20 > 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= RTCP > are multiplexed on the same port, there are two > components per media stream -- one for RTP, and one for RTCP. > =20 > Section 4.1.1.1: > -------------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT (based on e-mail discussion): > =20 > 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. > =20 > 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 candid= ate. > =20 > 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. > =20 > 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. > =20 > =20 > =20 > =20 > Section 4.2: > --------------- > =20 > OLD TEXT: > =20 > 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. > =20 > NEW TEXT: > =20 > 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 multi= plexing > of RTP and RTCP on the same port. > =20 > =20 > =20 > Section 5.6.1: > ----------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT: > =20 > 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 multiplex= ing > of RTP and RTCP on the same port, the offerer includes candidate= s 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 support= s > multiplexing of RTP and RTCP on the same port, the offerer only includ= es > candidates for RTP. > =20 > =20 > Regards, > =20 > Christer From nobody Thu Dec 3 00:34:32 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 9C5801B32AC; Thu, 3 Dec 2015 00:34:29 -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 Y6bTwWsitQVn; Thu, 3 Dec 2015 00:34:27 -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 E408B1B3239; Thu, 3 Dec 2015 00:34:26 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-4c-565ffe9022fc Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.A3.05149.09EFF565; Thu, 3 Dec 2015 09:34:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 09:34:24 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= 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/MlQN4A3TAABFKzwAAFRPx0A== Date: Thu, 3 Dec 2015 08:34:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7C08F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C36C32@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C7A3F5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdTHfiv/gwg7+HGC2+Xai1mLr8MYsD k8eSJT+ZAhijuGxSUnMyy1KL9O0SuDJufXjGVnDOpOLibrEGxt0aXYycHBICJhK9X14yQthi EhfurWfrYuTiEBI4zCix7/hnsISQwGJGiTufLLoYOTjYBCwkuv9pg4RFBGwl1jVMZAKxmQXc JJpv7gMrFxaolfh2/hwLRE2dxOOvG9ggbCeJmz0HweIsAioS37bOBrN5BXwl9iyZzA6x9zij xP/uOewgCU4BB4mTp+6BNTMCHff91BqoZeISt57MZ4I4WkBiyZ7zzBC2qMTLx/9YQe6UEFCU WN4vB1GuJ3Fj6hQ2CFtbYtnC18wQewUlTs58wjKBUWwWkqmzkLTMQtIyC0nLAkaWVYyixanF SbnpRkZ6qUWZycXF+Xl6eaklmxiB8XJwy2+DHYwvnzseYhTgYFTi4f1QHh8mxJpYVlyZe4hR goNZSYT321qgEG9KYmVValF+fFFpTmrxIUZpDhYlcd5mpgehQgLpiSWp2ampBalFMFkmDk6p BsaljzqeOCiduHON5/eUCwbrmCIXLbrPNsG/OS+2r9/iyR4HZdnibyJJe60iltjIpb7+N/9G sqINUyPfusVs679F32c9XP1QICclsMWqRP3zwRs6DdcO8HZunHRnoku50LE5P7Lj3S7UCtw9 ff/ve+0gRaH7mzqjDI/M+mM+debzhorVT1yeyyopsRRnJBpqMRcVJwIA/vT64ZMCAAA= Archived-At: Cc: "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [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: Thu, 03 Dec 2015 08:34:29 -0000 Hi, Has the Yokohama decision for exclusive support of RTP/RTCP-mux been verifi= ed on the appropriate list? Regards, Christer -----Original Message----- From: Ari Ker=E4nen=20 Sent: 3. joulukuuta 2015 1:28 To: Christer Holmberg Cc: mmusic@ietf.org; ice@ietf.org Subject: Re: draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution f= or indicating exclusive support of RTP/RTCP-mux. Hi, These changes look good to me. If no one objects, I'll make the changes for= the next revision. Thanks, Ari > On 02 Dec 2015, at 16:12, Christer Holmberg wrote: >=20 > Any comments on this? > =20 > From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 16 November 2015 01:58 > To: mmusic@ietf.org; ice@ietf.org > Cc: Ari Ker=E4nen > Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE soluti= on for indicating exclusive support of RTP/RTCP-mux. > =20 > =20 > Hi, > =20 > I went through draft-ietf-mmusic-rfc5245bis-05, and identified the follow= ing paragraphs that need to be modified in order to support the ICE solutio= n for exclusive support of RTP/RTCP-mux. > =20 > Also, I assume the discussion regarding the ICE solution should move to t= he ICE WG, while the discussion on the mux-exclusive draft will stay in MMU= SIC. > =20 > =20 > Section 3: > ------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT: > =20 > 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=20 > and RTCP are multiplexed on the same port, there are two > components per media stream -- one for RTP, and one for RTCP. > =20 > Section 4.1.1.1: > -------------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT (based on e-mail discussion): > =20 > Each component has an ID assigned to it, called the component ID. > For RTP-based media streams, unless RTP and RTCP are multiplexed on=20 > the same port (RTP/RTCP multiplexing), the RTP has a component ID of 1=20 > and RTCP a component ID of 2. In case of RTP/RTCP multiplexing, a=20 > component ID of 1 is used for both RTP and RTCP. > =20 > When candidates are obtained, unless the agent knows for sure that=20 > RTP/RTCP multiplexing will be used (i.e. the agent knows that the=20 > other agent also supports, and is willing to use, RTP/RTCP=20 > multiplexing), or unless the agent only supports RTP/RTCP=20 > multiplexing, the agent MUST obtain a separate candidate for RTCP. If=20 > an agent has obtained a candidate for RTCP, and end up using RTP/RTCP=20 > multiplexing, the agent does not need to perform connectivity checks on t= he RTCP candidate. > =20 > If an agent is using separate candidates for RTP and RTCP, it will end=20 > up with 2*K host candidates if the agent has K IP addresses. > =20 > NOTE: The responding agent, when obtaining its candidates, will=20 > typically know whether the other agent supports RTP/RTCP multiplexing,=20 > in which case it will not need to obtain a separate candidate for RTCP. > =20 > =20 > =20 > =20 > Section 4.2: > --------------- > =20 > OLD TEXT: > =20 > 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. > =20 > NEW TEXT: > =20 > 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 multi= plexing > of RTP and RTCP on the same port. > =20 > =20 > =20 > Section 5.6.1: > ----------------- > =20 > OLD TEXT: > =20 > 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. > =20 > =20 > NEW TEXT: > =20 > 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 multiplex= ing > of RTP and RTCP on the same port, the offerer includes candidate= s 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 support= s > multiplexing of RTP and RTCP on the same port, the offerer only includ= es > candidates for RTP. > =20 > =20 > Regards, > =20 > Christer From nobody Thu Dec 3 05:46:15 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 510581A87BA for ; Thu, 3 Dec 2015 05:46:11 -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 jFHY-wvUc6Wf for ; Thu, 3 Dec 2015 05:46:05 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706841A87BC for ; Thu, 3 Dec 2015 05:46:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25438; q=dns/txt; s=iport; t=1449150365; x=1450359965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WG+2kZF9irhsvvjl49zZ/1ZnVJOQaruHVbpIJ2VrzIc=; b=N4AqkwApS1G1ytNILll7tQApjF6n9MAyUec4QLnb2hZZa8oRS39ckRle 82QBCbrmQqYLVlj15OncLgTcvTZxBDUDTF06oLfY972QendJr0eAIgK0h SloRe8VXgK87m1kWT3ny/Gbmo3R0UbcoWoouhGbsudFbD6XiQJy8rSy26 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgC4RmBW/4gNJK1egm5MU24GvTwBD?= =?us-ascii?q?YFuFwEJhW0CHIEqOBQBAQEBAQEBgQqENQEBBAEBASAERwsQAgEIPwMCAgIlCxQ?= =?us-ascii?q?RAgQOBYgvDbEUkQoBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUgg+CboUIgm8vg?= =?us-ascii?q?RUFh0yHEIgFAYUsiA+BW4dpkygBHwEBQoQEcoRogQcBAQE?= X-IronPort-AV: E=Sophos; i="5.20,378,1444694400"; d="scan'208,217"; a="55991906" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2015 13:46:04 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tB3Dk4mt019078 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 13:46:04 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 3 Dec 2015 08:46:03 -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; Thu, 3 Dec 2015 08:46:03 -0500 From: "Pal Martinsen (palmarti)" To: Peter Saint-Andre Thread-Topic: [Ice] "waiting-for-candidates" state in trickle-ice Thread-Index: AQHRK9yn2Vs256pR90+Y/AOIaszOXJ6375QAgAADMgCAAKtRAIAA/+WA Date: Thu, 3 Dec 2015 13:46:03 +0000 Message-ID: <29D6E3D7-2078-45D0-B527-F9BEEF054498@cisco.com> References: <565D002F.1010201@andyet.net> <565F70F0.3070607@andyet.net> In-Reply-To: <565F70F0.3070607@andyet.net> 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.61.215.32] Content-Type: multipart/alternative; boundary="_000_29D6E3D7207845D0B527F9BEEF054498ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Emil Ivov , "ice@ietf.org" Subject: Re: [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: Thu, 03 Dec 2015 13:46:11 -0000 --_000_29D6E3D7207845D0B527F9BEEF054498ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgSSBoYXZlIG5vdCB5ZXQgc3RhcnRlZCBhbnkgcmVhbCBkZXZlbG9wbWVudCB3b3JrIHdp dGggVHJpY2tsZUlDRSBpdCBpcyBoYXJkIHRvIGJlIOKAnGF1dGhvcml0YXRpdmXigJ0uIEJ1dCBt eSBndXQgZmVlbGluZyBpcyBzdGlsbCB0aGF0IGl0IHdvdWxkIGhhdmUgYmVlbiBuaWNlIHRvIGhh dmUgdGhlIHdhaXRpbmcgZm9yIGNhbmRpZGF0ZXMgc3RhdGUuDQoNCkkgc2VlIG5vIGhhcm0gZG9u ZSBpbiBhZGRpbmcgc3RhdGVzIGZvciBhY3RpdmUgYW5kIGZyb3plbiBlaXRoZXIuIEFzIHRoZSB0 ZXh0IGNsZWFybHkgZGVzY3JpYmVzIGEgY2hlY2tsaXN0IHN0YXRlIChhbGwgY2FuZGlkYXRlcyBh cmUgZnJvemVuIC0+IGNoZWNrbGlzdCBhcmUgZnJvemVuKS4NCg0KSWxsIGd1ZXNzIHRoZSBpbXBv cnRhbnQgdGhpbmcgaXMgdG8gY2xlYW4gaXQgdXAgaW4gYSBjb25zaXN0ZW50IHdheSwgdG9kYXkg SSBmaW5kIGl0IHNvbWV3aGF0IGhhcmQgdG8gcmVhZC4NCg0KLi0uDQpQw6VsLUVyaWsNCk9uIDAy IERlYyAyMDE1LCBhdCAyMzozMCwgUGV0ZXIgU2FpbnQtQW5kcmUgPHBldGVyQGFuZHlldC5uZXQ8 bWFpbHRvOnBldGVyQGFuZHlldC5uZXQ+PiB3cm90ZToNCg0KQWx0aG91Z2ggSSB3YXMgd3Jvbmcg YWJvdXQgY2hlY2sgbGlzdCBub3QgaGF2aW5nIHN0YXRlcywgSSBhZ3JlZSB3aXRoIEVtaWwgdGhh dCB3ZSBkb24ndCBuZWVkIHRvIGFkZCBtb3JlIHN0YXRlcyBoZXJlLg0KDQooSSBmb3VuZCBhIHNp bWlsYXIgaXNzdWUgbGFzdCBuaWdodCB3aXRoIHBvdGVudGlhbGx5IGFkZGluZyBzdGF0ZXMgZm9y ICJBY3RpdmUiIGFuZCAiRnJvemVuIiBhdCB0aGUgY2hlY2sgbGlzdCBsZXZlbCAtIHNlZSBodHRw czovL2dpdGh1Yi5jb20vZW1jaG8vdHJpY2tsZS1pY2UvaXNzdWVzLzExIGZvciBteSBzb2xpcHNp c3RpYyByYW1ibGluZ3MuKQ0KDQpQZXRlcg0KDQpPbiAxMi8yLzE1IDU6MTYgQU0sIEVtaWwgSXZv diB3cm90ZToNCkkgcmVhbGx5IGRvbid0IHRoaW5rIHdlIG5lZWQgc3VjaCBhIHN0YXRlIGFuZCB0 aGF0IGhhdmluZyB0aGUgZXhpc3RpbmcNCiJXYWl0IiBpcyBlbm91Z2guIEFsc28gZWFzaWVyIHRv IGltcGxlbWVudCB0aGFuIGFkZGluZyB5ZXQgYW5vdGhlciBzdGF0ZS4NCg0KSSBhbSBjdXJyZW50 bHkgdHJhdmVsaW5nIGJ1dCBJJ2xsIHRyeSB0byBsb29rIGludG8gdGhpcyBtb3JlIGJ5IHRoZSBl bmQNCm9mIHRoZSB3ZWVrLg0KDQpFbWlsDQoNCk9uIFdlZG5lc2RheSwgMiBEZWNlbWJlciAyMDE1 LCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNCjxwYWxtYXJ0aUBjaXNjby5jb208bWFpbHRvOnBh bG1hcnRpQGNpc2NvLmNvbT4gPG1haWx0bzpwYWxtYXJ0aUBjaXNjby5jb20+PiB3cm90ZToNCg0K DQogICBPbiAwMSBEZWMgMjAxNSwgYXQgMDM6MDQsIFBldGVyIFNhaW50LUFuZHJlIDxwZXRlckBh bmR5ZXQubmV0PG1haWx0bzpwZXRlckBhbmR5ZXQubmV0Pg0KICAgPGphdmFzY3JpcHQ6X2UoJTdC JTdELCdjdm1sJywncGV0ZXJAYW5keWV0Lm5ldDxtYWlsdG86cGV0ZXJAYW5keWV0Lm5ldD4nKTs+ PiB3cm90ZToNCg0KICAgSGkgYWxsLA0KDQogICBJJ3ZlIHN0YXJ0ZWQgdG8gd29yayBvbiBmaXhl cyB0byBkcmFmdC1pZXRmLWljZS10cmlja2xlIGZvciB0aGUNCiAgIG9wZW4gaXNzdWVzIGFuZCB0 aGUgSUVURiA5NCBkaXNjdXNzaW9uIGl0ZW1zLg0KDQogICBPbmUgc3VjaCBpdGVtIHdhcyB0aGUg YWRkaXRpb24gb2YgYSAid2FpdGluZy1mb3ItY2FuZGlkYXRlcyIgc3RhdGUNCiAgIHRvIGhhbmRs ZSB0aGUgc2l0dWF0aW9uIHdoZW4gYSBjaGVja2xpc3QgaXMgZW1wdHkgYW5kIG5vIGNhbmRpZGF0 ZQ0KICAgcGFpcnMgaGF2ZSBiZWVuIHNlbnQgb3IgcmVjZWl2ZWQuDQoNCiAgIExvb2tpbmcgYWdh aW4gYXQgUkZDIDUyNDUgYW5kIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMsIEknZCBzYXkNCiAg IHRoYXQgaW4gSUNFIGNvcmUgdGhlIGNvbmNlcHQgb2Ygc3RhdGUgYXBwbGllcyB0byBhIGNhbmRp ZGF0ZSBwYWlyLA0KICAgbm90IHRvIGEgY2hlY2tsaXN0LiBUaGVyZWZvcmUgSSBzdWdnZXN0IHRo YXQgd2Ugbm90IGF0dGVtcHQgdG8NCiAgIGRlZmluZSB0aGlzIG5ldyBzdGF0ZSBmb3IgY2hlY2ts aXN0cyBpbiB0cmlja2xlLWljZS4gSG93ZXZlciwgSQ0KICAgdGhpbmsgaXQgd291bGQgYmUgYXBw cm9wcmlhdGUgdG8gYWRkIGEgZmV3IHdvcmRzIGFib3V0IHRoaXMNCiAgIHNpdHVhdGlvbiAod2l0 aG91dCBmb3JtYWxseSBjYWxsaW5nIGl0IGEgc3RhdGUpLg0KDQoNCiAgICBGcm9tIHNlY3Rpb24g NS43LjQ6DQoNCiAgIFRoZSBjaGVjayBsaXN0IGl0c2VsZiBpcyBhc3NvY2lhdGVkIHdpdGggYSBz dGF0ZSwgd2hpY2ggY2FwdHVyZXMgdGhlDQogICAgICAgc3RhdGUgb2YgSUNFIGNoZWNrcyBmb3Ig dGhhdCBtZWRpYSBzdHJlYW0uICBUaGVyZSBhcmUgdGhyZWUgc3RhdGVzOg0KDQogICAgICAgUnVu bmluZzogIEluIHRoaXMgc3RhdGUsIElDRSBjaGVja3MgYXJlIHN0aWxsIGluIHByb2dyZXNzIGZv ciB0aGlzDQogICAgICAgICAgbWVkaWEgc3RyZWFtLg0KDQogICAgICAgQ29tcGxldGVkOiAgSW4g dGhpcyBzdGF0ZSwgSUNFIGNoZWNrcyBoYXZlIHByb2R1Y2VkIG5vbWluYXRlZCBwYWlycw0KICAg ICAgICAgIGZvciBlYWNoIGNvbXBvbmVudCBvZiB0aGUgbWVkaWEgc3RyZWFtLiAgQ29uc2VxdWVu dGx5LCBJQ0UgaGFzDQogICAgICAgICAgc3VjY2VlZGVkIGFuZCBtZWRpYSBjYW4gYmUgc2VudC4N Cg0KICAgICAgIEZhaWxlZDogIEluIHRoaXMgc3RhdGUsIHRoZSBJQ0UgY2hlY2tzIGhhdmUgbm90 IGNvbXBsZXRlZA0KICAgICAgICAgIHN1Y2Nlc3NmdWxseSBmb3IgdGhpcyBtZWRpYSBzdHJlYW0u DQoNCiAgICAgICBXaGVuIGEgY2hlY2sgbGlzdCBpcyBmaXJzdCBjb25zdHJ1Y3RlZCBhcyB0aGUg Y29uc2VxdWVuY2Ugb2YgYW4NCiAgICAgICBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UsIGl0IGlzIHBs YWNlZCBpbiB0aGUgUnVubmluZyBzdGF0ZS4NCg0KDQogICBUaGlzIGlzIHdoZXJlIEkgdGhpbmsg d2Ugd2FudGVkIHRoZSB3YWl0aW5nLWZvci1jYW5kaWRhdGVzIHN0YXRlLg0KICAgTW9zdGx5IGJl Y2F1c2UgdGhhdCB3b3VsZCBoZWxwIG1lIGltcGxlbWVudCBteSBzdGF0ZSBtYWNoaW5lDQogICBj b3JyZWN0bHkuIFlvdSBjb3VsZCBiZSBpbiBydW5uaW5nIGFuZCBzYXkgdGhhdCB5b3UgYXJlIHdh aXRpbmcgZm9yDQogICBjYW5kaWRhdGVzLCBidXQgdGhhdCB3b3VsZCBzb21laG93IGJyZWFrIHRo ZSBuaWNlIHN0YXRlLW1hY2hpbmUgYnkNCiAgIGFkZGluZyBmbGFncyBldGMgSSBhbSBpbiBydW5u aW5nLCBidXQgd2FpdGluZyBmb3IgY2FuZGlkYXRlcyBldGMuLg0KDQogICBCdXQgdGhlIGNoZWNr bGlzdCBzdGF0ZXMgYXJlIHNvbWV3aGF0IGhpZGRlbiBpbiB0aGUgdGV4dCwgbWF5YmUgaXQNCiAg IHdvdWxkIGJlIGdvb2QgdG8gc29tZWhvdyBoaWdobGlnaHQgaXQgYSBiaXQgbW9yZSBpbiBJQ0Vi aXM/DQogICAoSSBjYW4gcHJvdmlkZSBzb21lIHRleHQgZWFybHkgbmV4dCB5ZWFyLikNCg0KICAg Li0uDQogICBQw6VsLUVyaWsNCg0KDQogICBQZXRlcg0KDQogICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgSWNlIG1haWxpbmcgbGlzdA0KICAgSWNl QGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+IDxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3Zt bCcsJ0ljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPicpOz4NCiAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQoNCg0KDQotLQ0Kc2VudCBmcm9tIG15IG1v YmlsZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SWNlIG1haWxpbmcgbGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQo= --_000_29D6E3D7207845D0B527F9BEEF054498ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5TaW5jZSBJ IGhhdmUgbm90IHlldCBzdGFydGVkIGFueSByZWFsIGRldmVsb3BtZW50IHdvcmsgd2l0aCBUcmlj a2xlSUNFIGl0IGlzIGhhcmQgdG8gYmUg4oCcYXV0aG9yaXRhdGl2ZeKAnS4gQnV0IG15IGd1dCBm ZWVsaW5nIGlzIHN0aWxsIHRoYXQgaXQgd291bGQgaGF2ZSBiZWVuIG5pY2UgdG8gaGF2ZSB0aGUg d2FpdGluZyBmb3IgY2FuZGlkYXRlcyBzdGF0ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgc2VlIG5vIGhhcm0gZG9uZSBpbiBhZGRp bmcgc3RhdGVzIGZvciBhY3RpdmUgYW5kIGZyb3plbiBlaXRoZXIuIEFzIHRoZSB0ZXh0IGNsZWFy bHkgZGVzY3JpYmVzIGEgY2hlY2tsaXN0IHN0YXRlIChhbGwgY2FuZGlkYXRlcyBhcmUgZnJvemVu IC0mZ3Q7IGNoZWNrbGlzdCBhcmUgZnJvemVuKS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklsbCBndWVzcyB0aGUgaW1wb3J0YW50IHRo aW5nIGlzIHRvIGNsZWFuIGl0IHVwIGluIGEgY29uc2lzdGVudCB3YXksIHRvZGF5IEkgZmluZCBp dCBzb21ld2hhdCBoYXJkIHRvIHJlYWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4uLS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ UMOlbC1FcmlrPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPk9uIDAyIERlYyAyMDE1LCBhdCAyMzozMCwgUGV0ZXIgU2FpbnQtQW5k cmUgJmx0OzxhIGhyZWY9Im1haWx0bzpwZXRlckBhbmR5ZXQubmV0IiBjbGFzcz0iIj5wZXRlckBh bmR5ZXQubmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+QWx0aG91Z2gNCiBJIHdhcyB3 cm9uZyBhYm91dCBjaGVjayBsaXN0IG5vdCBoYXZpbmcgc3RhdGVzLCBJIGFncmVlIHdpdGggRW1p bCB0aGF0IHdlIGRvbid0IG5lZWQgdG8gYWRkIG1vcmUgc3RhdGVzIGhlcmUuPC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ KEkNCiBmb3VuZCBhIHNpbWlsYXIgaXNzdWUgbGFzdCBuaWdodCB3aXRoIHBvdGVudGlhbGx5IGFk ZGluZyBzdGF0ZXMgZm9yICZxdW90O0FjdGl2ZSZxdW90OyBhbmQgJnF1b3Q7RnJvemVuJnF1b3Q7 IGF0IHRoZSBjaGVjayBsaXN0IGxldmVsIC0gc2VlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v ZW1jaG8vdHJpY2tsZS1pY2UvaXNzdWVzLzExIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8v Z2l0aHViLmNvbS9lbWNoby90cmlja2xlLWljZS9pc3N1ZXMvMTE8L2E+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5mb3INCiBteSBzb2xp cHNpc3RpYyByYW1ibGluZ3MuKTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlBldGVyPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czog YXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiAxMi8y LzE1IDU6MTYgQU0sIEVtaWwgSXZvdiB3cm90ZTo8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KSSByZWFs bHkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBzdWNoIGEgc3RhdGUgYW5kIHRoYXQgaGF2aW5nIHRoZSBl eGlzdGluZzxiciBjbGFzcz0iIj4NCiZxdW90O1dhaXQmcXVvdDsgaXMgZW5vdWdoLiBBbHNvIGVh c2llciB0byBpbXBsZW1lbnQgdGhhbiBhZGRpbmcgeWV0IGFub3RoZXIgc3RhdGUuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBhbSBjdXJyZW50bHkgdHJhdmVsaW5nIGJ1dCBJJ2xsIHRy eSB0byBsb29rIGludG8gdGhpcyBtb3JlIGJ5IHRoZSBlbmQ8YnIgY2xhc3M9IiI+DQpvZiB0aGUg d2Vlay48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpFbWlsPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KT24gV2VkbmVzZGF5LCAyIERlY2VtYmVyIDIwMTUsIFBhbCBNYXJ0aW5zZW4g KHBhbG1hcnRpKTxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86cGFsbWFydGlAY2lz Y28uY29tIiBjbGFzcz0iIj5wYWxtYXJ0aUBjaXNjby5jb208L2E+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJtYWlsdG86cGFsbWFy dGlAY2lzY28uY29tIiBjbGFzcz0iIj5tYWlsdG86cGFsbWFydGlAY2lzY28uY29tPC9hPiZndDsm Z3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwO09uIDAxIERl YyAyMDE1LCBhdCAwMzowNCwgUGV0ZXIgU2FpbnQtQW5kcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpw ZXRlckBhbmR5ZXQubmV0IiBjbGFzcz0iIj5wZXRlckBhbmR5ZXQubmV0PC9hPjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZsdDtqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJzxh IGhyZWY9Im1haWx0bzpwZXRlckBhbmR5ZXQubmV0IiBjbGFzcz0iIj5wZXRlckBhbmR5ZXQubmV0 PC9hPicpOyZndDsmZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwO0hpIGFsbCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDtJJ3ZlIHN0YXJ0ZWQgdG8gd29yayBvbiBmaXhlcyB0byBkcmFmdC1pZXRmLWlj ZS10cmlja2xlIGZvciB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtvcGVuIGlz c3VlcyBhbmQgdGhlIElFVEYgOTQgZGlzY3Vzc2lvbiBpdGVtcy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtPbmUgc3VjaCBpdGVtIHdhcyB0aGUgYWRkaXRp b24gb2YgYSAmcXVvdDt3YWl0aW5nLWZvci1jYW5kaWRhdGVzJnF1b3Q7IHN0YXRlPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dG8gaGFuZGxlIHRoZSBzaXR1YXRpb24gd2hlbiBhIGNo ZWNrbGlzdCBpcyBlbXB0eSBhbmQgbm8gY2FuZGlkYXRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7cGFpcnMgaGF2ZSBiZWVuIHNlbnQgb3IgcmVjZWl2ZWQuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7TG9va2luZyBhZ2FpbiBhdCBSRkMgNTI0 NSBhbmQgZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcywgSSdkIHNheTxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwO3RoYXQgaW4gSUNFIGNvcmUgdGhlIGNvbmNlcHQgb2Ygc3RhdGUgYXBw bGllcyB0byBhIGNhbmRpZGF0ZSBwYWlyLDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw O25vdCB0byBhIGNoZWNrbGlzdC4gVGhlcmVmb3JlIEkgc3VnZ2VzdCB0aGF0IHdlIG5vdCBhdHRl bXB0IHRvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ZGVmaW5lIHRoaXMgbmV3IHN0 YXRlIGZvciBjaGVja2xpc3RzIGluIHRyaWNrbGUtaWNlLiBIb3dldmVyLCBJPGJyIGNsYXNzPSIi Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dGhpbmsgaXQgd291bGQgYmUgYXBwcm9wcmlhdGUgdG8gYWRk IGEgZmV3IHdvcmRzIGFib3V0IHRoaXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtz aXR1YXRpb24gKHdpdGhvdXQgZm9ybWFsbHkgY2FsbGluZyBpdCBhIHN0YXRlKS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtGcm9tIHNlY3Rpb24gNS43LjQ6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIGNoZWNrIGxpc3QgaXRzZWxmIGlzIGFzc29j aWF0ZWQgd2l0aCBhIHN0YXRlLCB3aGljaCBjYXB0dXJlcyB0aGU8YnIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtzdGF0ZSBvZiBJQ0UgY2hlY2tz IGZvciB0aGF0IG1lZGlhIHN0cmVhbS4gJm5ic3A7VGhlcmUgYXJlIHRocmVlIHN0YXRlczo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtSdW5uaW5nOiAmbmJzcDtJbiB0aGlzIHN0YXRlLCBJQ0UgY2hlY2tzIGFyZSBz dGlsbCBpbiBwcm9ncmVzcyBmb3IgdGhpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21lZGlhIHN0cmVhbS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtDb21wbGV0ZWQ6ICZuYnNwO0luIHRoaXMgc3RhdGUsIElDRSBjaGVja3Mg aGF2ZSBwcm9kdWNlZCBub21pbmF0ZWQgcGFpcnM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3IgZWFjaCBj b21wb25lbnQgb2YgdGhlIG1lZGlhIHN0cmVhbS4gJm5ic3A7Q29uc2VxdWVudGx5LCBJQ0UgaGFz PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7c3VjY2VlZGVkIGFuZCBtZWRpYSBjYW4gYmUgc2VudC48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtGYWlsZWQ6ICZuYnNwO0luIHRoaXMgc3RhdGUsIHRoZSBJQ0UgY2hlY2tzIGhhdmUg bm90IGNvbXBsZXRlZDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3N1Y2Nlc3NmdWxseSBmb3IgdGhpcyBtZWRp YSBzdHJlYW0uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBhIGNoZWNrIGxpc3QgaXMgZmlyc3QgY29uc3Ry dWN0ZWQgYXMgdGhlIGNvbnNlcXVlbmNlIG9mIGFuPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLCBpdCBp cyBwbGFjZWQgaW4gdGhlIFJ1bm5pbmcgc3RhdGUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBpcyB3aGVyZSBJIHRoaW5r IHdlIHdhbnRlZCB0aGUgd2FpdGluZy1mb3ItY2FuZGlkYXRlcyBzdGF0ZS48YnIgY2xhc3M9IiI+ DQombmJzcDsmbmJzcDsmbmJzcDtNb3N0bHkgYmVjYXVzZSB0aGF0IHdvdWxkIGhlbHAgbWUgaW1w bGVtZW50IG15IHN0YXRlIG1hY2hpbmU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtj b3JyZWN0bHkuIFlvdSBjb3VsZCBiZSBpbiBydW5uaW5nIGFuZCBzYXkgdGhhdCB5b3UgYXJlIHdh aXRpbmcgZm9yPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y2FuZGlkYXRlcywgYnV0 IHRoYXQgd291bGQgc29tZWhvdyBicmVhayB0aGUgbmljZSBzdGF0ZS1tYWNoaW5lIGJ5PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YWRkaW5nIGZsYWdzIGV0YyBJIGFtIGluIHJ1bm5p bmcsIGJ1dCB3YWl0aW5nIGZvciBjYW5kaWRhdGVzIGV0Yy4uPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7QnV0IHRoZSBjaGVja2xpc3Qgc3RhdGVzIGFyZSBz b21ld2hhdCBoaWRkZW4gaW4gdGhlIHRleHQsIG1heWJlIGl0PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7d291bGQgYmUgZ29vZCB0byBzb21laG93IGhpZ2hsaWdodCBpdCBhIGJpdCBt b3JlIGluIElDRWJpcz88YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsoSSBjYW4gcHJv dmlkZSBzb21lIHRleHQgZWFybHkgbmV4dCB5ZWFyLik8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsuLS48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDtQw6VsLUVyaWs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDtQZXRlcjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7SWNlIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu YnNwOzxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciIGNsYXNzPSIiPkljZUBpZXRmLm9yZzwv YT4gJmx0O2phdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnPGEgaHJlZj0ibWFpbHRvOkljZUBp ZXRmLm9yZyIgY2xhc3M9IiI+SWNlQGlldGYub3JnPC9hPicpOyZndDs8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ljZSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pY2U8L2E+PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpzZW50IGZyb20gbXkg bW9iaWxlPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SWNlDQogbWFp bGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv OkljZUBpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5JY2VAaWV0Zi5vcmc8L2E+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ljZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2ljZTwvYT48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_29D6E3D7207845D0B527F9BEEF054498ciscocom_-- From nobody Mon Dec 7 05:59:41 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 C12C61B3753; Mon, 7 Dec 2015 05:59:40 -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=unavailable 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 bF_X6a7yxNBq; Mon, 7 Dec 2015 05:59:39 -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 58FCA1B36F2; Mon, 7 Dec 2015 05:52:24 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-e6-56658f15f4c4 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.9B.05041.51F85665; Mon, 7 Dec 2015 14:52:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 7 Dec 2015 14:52:21 +0100 From: Christer Holmberg To: "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: draft-ietf-ice-rfc5245bis-00: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux. Thread-Index: AdEw9h0T1n2MvyaVQyCQVkwuTjgRDQ== Date: Mon, 7 Dec 2015 13:52:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C89172@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C89172ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbFdWlesPzXM4O1dJotvF2otpi5/zOLA 5LFkyU+mAMYoLpuU1JzMstQifbsEroyZL8+xFqzqYKxY8GMSawPj6fIuRk4OCQETiflfdjFD 2GISF+6tZwOxhQQOM0pMPpDTxcgFZC9mlHh6biJrFyMHB5uAhUT3P22QGhEBN4mrrw8xgtjM ArYScy9dYAWxhQWqJL7tPcUOUVMtsaftDjOErSdxfMdrJhCbRUBFYuvDa2C7eAV8JS7N7gXr ZQS64fupNUwQM8Ulbj2ZzwRxm4DEkj3noe4UlXj5+B8rhK0o0f60AeqGfIm3k18yQswUlDg5 8wnLBEbhWUhGzUJSNgtJGURcT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2BkX8UoWpxaXJyb bmSkl1qUmVxcnJ+nl5dasokRGDMHt/y22sF48LnjIUYBDkYlHt4NrSlhQqyJZcWVuYcYJTiY lUR4ZTNTw4R4UxIrq1KL8uOLSnNSiw8xSnOwKInzNjM9CBUSSE8sSc1OTS1ILYLJMnFwSjUw Cs/7ICp8+uyOxK+8SSZ8wXuvrTdSCk00X6P0rUp1skncgglfipTSdrqHyxXdmjuNpUD1a9CT eiH5T8+tVu//NaHuH6vZvu9COTKp7s73JO/6zDi3fdlFhd5ZXzSnFrIpnHj157+25Ubli0w+ t94WWa2N8tWyX/z8bI9Jb+sctefHs+Q1fpxMVWIpzkg01GIuKk4EAAHFVq6VAgAA Archived-At: Cc: =?iso-8859-1?Q?Ari_Ker=E4nen?= Subject: Re: [Ice] draft-ietf-ice-rfc5245bis-00: 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: Mon, 07 Dec 2015 13:59:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C89172ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In order to clarify that the absence of an RTCP component does NOT by defau= lt mean that RTCP is not used, I suggest some additional text to the new te= xt. Regards, Christer 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. NOTE: There needs to be a signalling mechanism to indicate whether the absence of a component ID of 2 means that RTCP is not used, or that RTP/RTCP multiplexing is used. Such mechanism is outside the scope of this document. 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. NOTE: There needs to be a signalling mechanism to indicate whether the absence of a component ID of 2 means that RTCP is not used, or that RTP/RTCP multiplexing is used. Such mechanism is outside the scope of this document. --_000_7594FB04B1934943A5C02806D1A2204B37C89172ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

In orde= r to clarify that the absence of an RTCP component does NOT by default mean= that RTCP is not used, I suggest some additional text to the new text.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 

Section 4.1.1.1:

--------------------=

 

OLD TEXT:

 

   Each component has an ID assigned to it, cal= led 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 ag= ent 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 discu= ssion):

 

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.

&n= bsp;

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),<= o:p>

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 candida= te.

 

If an agent is using separate candidates for RTP and RTCP, it will end up<= o:p>

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 w= ill

not need to obtain a separate candidate for RTCP.

 

<new>NOTE: There needs to be a signalling me= chanism to indicate whether

the absence of a component ID of 2 means that RTCP= is not used, or that

RTP/RTCP multiplexing is used. Such mechanism is o= utside the scope of

this document.</new>

 

Section 4.2:<= /p>

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

 

OLD TEXT:

 

Each component has an ID ass= igned to it, called the component ID.

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

      and RTCP a component ID of 2.&n= bsp; If an agent is using RTCP, it MUST

      obtain candidates for it.<= /o:p>

 

NEW TEXT:

 

Each component has an ID ass= igned to it, called the component ID.

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

      and RTCP a component ID of 2.&n= bsp; If an agent is using RTCP, it MUST

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

      of RTP and RTCP on the sam= e port</new>.

&n= bsp;

<new>NOTE: There needs to be a signalling me= chanism to indicate whether

the absence of a component ID of 2 means that RTCP= is not used, or that

RTP/RTCP multiplexing is used. Such mechanism is o= utside the scope of

this document.</new>

 

&n= bsp;

 

--_000_7594FB04B1934943A5C02806D1A2204B37C89172ESESSMB209erics_-- From nobody Tue Dec 8 07:49:36 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 313C61B2F51 for ; Tue, 8 Dec 2015 07:49:34 -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 GSegwbT_PODm for ; Tue, 8 Dec 2015 07:49:31 -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 4010B1B2F54 for ; Tue, 8 Dec 2015 07:49:31 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-3b-5666fc09805e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.A9.04590.90CF6665; Tue, 8 Dec 2015 16:49:29 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.149]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 16:49:14 +0100 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: "ice@ietf.org" Thread-Topic: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux. Thread-Index: AdEfK4BAJnqr+40+QtGjMsJ85p/MlQN4A3TAABFKzwABHbhwAA== Date: Tue, 8 Dec 2015 15:49:14 +0000 Message-ID: <37DB4F4C-B92F-4303-BE94-21D9FB638BF2@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B37C36C32@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C7A3F5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0E09FE7011EC4D4284A6F680AAF4C7E1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7vS7nn7Qwgz1d8hbfLtQ6MHosWfKT KYAxissmJTUnsyy1SN8ugSvjy9o9rAVtjhX//u1jbmD8adTFyMkhIWAicaNrBiOELSZx4d56 ti5GLg4hgcOMEit3v2aCcBYzSlzbPoEJpIpNwF5i8pqPYB0iAooSM1ueMYPYzAJmEpdunWAB aRAWaGaUeHDpCSOIIyLQwihxprWdFaLDSeJNfy8biM0ioCKx5NhmsG5eoKkPt5yHWnecUeJ/ 9xx2kASngIPEyVP3wBoYgQ78fmoNE8Q6cYlbT+YzQRwuILFkz3lmCFtU4uXjf6wQtpLEotuf oer1JG5MncIGYVtLNMxYAhXXlli28DXUEYISJ2c+YZnAKD4LyYpZSNpnIWmfhaR9FpL2BYys qxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI+zglt+qOxgvv3E8xCjAwajEw2twPTVMiDWx rLgy9xCjBAezkgjv819pYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5m5kehAoJpCeWpGanphak FsFkmTg4pRoYO9lDum+xFFpOn3Lk41I5t/DsAsXN/RJC5qtFGO/y1oilrlTXKM5SPlC9L0Pz un/h3HXSK57NYM3pn3Z0fTK/b7F66qoTHA/7mCXvH0tlaFb4kvnspsOcGyv/VjhnpgRFWn6b vL/zsfLpiJdRK7n+PLiy7f8v5Q0hqWJfGRRrduvNNai9Fp6jxFKckWioxVxUnAgALT3xVKwC AAA= Archived-At: Cc: Christer Holmberg Subject: Re: [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: Tue, 08 Dec 2015 15:49:34 -0000 Hi all, After a bit more off-line word-smithing, here's the final text we ended up = with for replacing section 4.1.1.1 3rd paragraph (https://tools.ietf.org/ht= ml/draft-ietf-ice-rfc5245bis-00#section-4.1.1.1): Each component has an ID assigned to it, called the component ID. For RTP-based media streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself 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 ends 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 an agent has K IP addresses. Note that the responding agent, when obtaining its candidates, will typically know if the other agent supports RTP/RTCP multiplexing, in which case it will not need to obtain a separate candidate for RTCP. However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. If there are no further comments, I'll submit a new version with this chang= e, and other related changes discussed earlier. Cheers, Ari > On 03 Dec 2015, at 01:28, Ari Ker=E4nen wrote: >=20 > Hi, >=20 > These changes look good to me. If no one objects, I'll make the changes f= or the next revision. >=20 >=20 > Thanks, > Ari >=20 >> On 02 Dec 2015, at 16:12, Christer Holmberg wrote: >>=20 >> Any comments on this? >>=20 >> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 16 November 2015 01:58 >> To: mmusic@ietf.org; ice@ietf.org >> Cc: Ari Ker=E4nen >> Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solut= ion for indicating exclusive support of RTP/RTCP-mux. >>=20 >>=20 >> Hi, >>=20 >> I went through draft-ietf-mmusic-rfc5245bis-05, and identified the follo= wing paragraphs that need to be modified in order to support the ICE soluti= on for exclusive support of RTP/RTCP-mux. >>=20 >> 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 MM= USIC. >>=20 >>=20 >> Section 3: >> ------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT: >>=20 >> 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= RTCP >> are multiplexed on the same port, there are two >> components per media stream -- one for RTP, and one for RTCP. >>=20 >> Section 4.1.1.1: >> -------------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT (based on e-mail discussion): >>=20 >> 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. >>=20 >> 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 candi= date. >>=20 >> If an agent is using separate candidates for RTP and RTCP, it will end u= p >> with 2*K host candidates if the agent has K IP addresses. >>=20 >> NOTE: The responding agent, when obtaining its candidates, will typicall= y know >> whether the other agent supports RTP/RTCP multiplexing, in which case it= will >> not need to obtain a separate candidate for RTCP. >>=20 >>=20 >>=20 >>=20 >> Section 4.2: >> --------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >> NEW TEXT: >>=20 >> 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 multi= plexing >> of RTP and RTCP on the same port. >>=20 >>=20 >>=20 >> Section 5.6.1: >> ----------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT: >>=20 >> 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 multiplex= ing >> of RTP and RTCP on the same port, the offerer includes candidate= s 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 support= s >> multiplexing of RTP and RTCP on the same port, the offerer only includ= es >> candidates for RTP. >>=20 >>=20 >> Regards, >>=20 >> Christer >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Tue Dec 8 09:18:08 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 B715F1A017F for ; Tue, 8 Dec 2015 09:18:07 -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 fMshgUxFjyBJ for ; Tue, 8 Dec 2015 09:18:05 -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 D0B8F1A016C for ; Tue, 8 Dec 2015 09:17:59 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-80-566710c56bcb Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.A5.04590.5C017665; Tue, 8 Dec 2015 18:17:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 18:17:57 +0100 From: Christer Holmberg To: =?iso-8859-1?Q?Ari_Ker=E4nen?= , "ice@ietf.org" Thread-Topic: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solution for indicating exclusive support of RTP/RTCP-mux. Thread-Index: AdEfK4BAJnqr+40+QtGjMsJ85p/MlQN4A3TAABFKzwABHbhwAAAFMFSg Date: Tue, 8 Dec 2015 17:17:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8C5E8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C36C32@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C7A3F5@ESESSMB209.ericsson.se> <37DB4F4C-B92F-4303-BE94-21D9FB638BF2@ericsson.com> In-Reply-To: <37DB4F4C-B92F-4303-BE94-21D9FB638BF2@ericsson.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7k+4xgfQwg3kzOCy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG8p/PWQt+Olc8mTGBtYFxl2kXIyeHhICJxNlvh1khbDGJC/fW s4HYQgKHGSUO/5bqYuQCshczSsx4+IWxi5GDg03AQqL7nzZIjYhAnMTTFztYQGqEBZoZJW69 vMsG4ogItDBKnGltZ4WocpPobX7CAtLMIqAicfVjBEiYV8BXYsqL/2wQC/4ySqz90csCkuAU cJD4tGQDmM0IdNH3U2uYQGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl439QHyhJrD28nQWiXk/i xtQpbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9VKL MpOLi/Pz9PJSSzYxAmPi4JbfqjsYL79xPMQowMGoxMNrcD01TIg1say4MvcQowQHs5II72zO 9DAh3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNITS1KzU1MLUotgskwcnFINjGLfMs11 HTfdDZecWnvt8fqMB99K5US3nP7+13ne56TDBjrSkyYdYXWM8fOzClZ5tvBnZ3P2bAbbqun/ Fiav/7e42C1gSfOVkJUCGubC8ZUZvjNarPPkjZ2Xvp7U3Hm5YZnnP85ojn9fI1ZfS3z7VKzO Y8I1XudpcrVTQpZXP3paLCu8z+jqPSWW4oxEQy3mouJEAEAt1oKFAgAA Archived-At: Subject: Re: [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: Tue, 08 Dec 2015 17:18:07 -0000 Looks good to me. Regards, Christer -----Original Message----- From: Ari Ker=E4nen=20 Sent: 08 December 2015 17:49 To: ice@ietf.org Cc: Christer Holmberg Subject: Re: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solu= tion for indicating exclusive support of RTP/RTCP-mux. Hi all, After a bit more off-line word-smithing, here's the final text we ended up = with for replacing section 4.1.1.1 3rd paragraph (https://tools.ietf.org/ht= ml/draft-ietf-ice-rfc5245bis-00#section-4.1.1.1): Each component has an ID assigned to it, called the component ID. For RTP-based media streams, unless both RTP and RTCP are multiplexed in the same UDP port (RTP/RTCP multiplexing), the RTP itself 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 ends 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 an agent has K IP addresses. Note that the responding agent, when obtaining its candidates, will typically know if the other agent supports RTP/RTCP multiplexing, in which case it will not need to obtain a separate candidate for RTCP. However, absence of a component ID 2 as such does not imply use of RTCP/RTP multiplexing, as it could also mean that RTCP is not used. If there are no further comments, I'll submit a new version with this chang= e, and other related changes discussed earlier. Cheers, Ari > On 03 Dec 2015, at 01:28, Ari Ker=E4nen wrote: >=20 > Hi, >=20 > These changes look good to me. If no one objects, I'll make the changes f= or the next revision. >=20 >=20 > Thanks, > Ari >=20 >> On 02 Dec 2015, at 16:12, Christer Holmberg wrote: >>=20 >> Any comments on this? >>=20 >> From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 16 November 2015 01:58 >> To: mmusic@ietf.org; ice@ietf.org >> Cc: Ari Ker=E4nen >> Subject: [Ice] draft-ietf-mmusic-rfc5245bis-05: Impacts due to ICE solut= ion for indicating exclusive support of RTP/RTCP-mux. >>=20 >>=20 >> Hi, >>=20 >> I went through draft-ietf-mmusic-rfc5245bis-05, and identified the follo= wing paragraphs that need to be modified in order to support the ICE soluti= on for exclusive support of RTP/RTCP-mux. >>=20 >> 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 MM= USIC. >>=20 >>=20 >> Section 3: >> ------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT: >>=20 >> 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=20 >> and RTCP are multiplexed on the same port, there are two >> components per media stream -- one for RTP, and one for RTCP. >>=20 >> Section 4.1.1.1: >> -------------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT (based on e-mail discussion): >>=20 >> Each component has an ID assigned to it, called the component ID. >> For RTP-based media streams, unless RTP and RTCP are multiplexed on=20 >> the same port (RTP/RTCP multiplexing), the RTP has a component ID of=20 >> 1 and RTCP a component ID of 2. In case of RTP/RTCP multiplexing, a=20 >> component ID of 1 is used for both RTP and RTCP. >>=20 >> When candidates are obtained, unless the agent knows for sure that=20 >> RTP/RTCP multiplexing will be used (i.e. the agent knows that the=20 >> other agent also supports, and is willing to use, RTP/RTCP=20 >> multiplexing), or unless the agent only supports RTP/RTCP=20 >> multiplexing, the agent MUST obtain a separate candidate for RTCP. If=20 >> an agent has obtained a candidate for RTCP, and end up using RTP/RTCP=20 >> multiplexing, the agent does not need to perform connectivity checks on = the RTCP candidate. >>=20 >> If an agent is using separate candidates for RTP and RTCP, it will=20 >> end up with 2*K host candidates if the agent has K IP addresses. >>=20 >> NOTE: The responding agent, when obtaining its candidates, will=20 >> typically know whether the other agent supports RTP/RTCP=20 >> multiplexing, in which case it will not need to obtain a separate candid= ate for RTCP. >>=20 >>=20 >>=20 >>=20 >> Section 4.2: >> --------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >> NEW TEXT: >>=20 >> 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 multi= plexing >> of RTP and RTCP on the same port. >>=20 >>=20 >>=20 >> Section 5.6.1: >> ----------------- >>=20 >> OLD TEXT: >>=20 >> 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. >>=20 >>=20 >> NEW TEXT: >>=20 >> 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 multiplex= ing >> of RTP and RTCP on the same port, the offerer includes candidate= s 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 support= s >> multiplexing of RTP and RTCP on the same port, the offerer only includ= es >> candidates for RTP. >>=20 >>=20 >> Regards, >>=20 >> Christer >=20 > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice From nobody Tue Dec 8 12:57:07 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 4B13C1A86E3 for ; Tue, 8 Dec 2015 12:57:06 -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 fccMyUz8Nz8m for ; Tue, 8 Dec 2015 12:57:04 -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 EA2891A6F7B for ; Tue, 8 Dec 2015 12:57:03 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-98-5667441d5b31 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.0C.05149.D1447665; Tue, 8 Dec 2015 21:57:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 21:57:01 +0100 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Draft new version: draft-holmberg-mmusic-mux-exclusive-01 Thread-Index: AdEx+jLFQk2UG7diS5OXSAoUUZcNtgAAK+ew Date: Tue, 8 Dec 2015 20:57:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8D0C8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C8D07A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8D07A@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_7594FB04B1934943A5C02806D1A2204B37C8D0C8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdUlfWJT3M4Ps+TYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJWx9X5ZwWy1ig03YxoY/yt2MXJySAiYSLz808EOYYtJXLi3nq2L kYtDSOAwo8Sea92MEM5iRokJDZOBHA4ONgELie5/2iANIgKKEjNbnjGD2MICbhLNZz+yQcTd JU4f/A9lG0m0nnnDAtLKIqAi8eOYLEiYV8BXYvmmLSwgthCQ/evMSzCbU8BPounIdEYQmxHo nu+n1jCB2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1ghbCWJtYe3s0DU50tcWfieHWKXoMTJ mU9YJjCKzEIyahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRtHi1OKk3HQj I73Uoszk4uL8PL281JJNjMDYObjlt8EOxpfPHQ8xCnAwKvHwGlxPDRNiTSwrrsw9xCjBwawk wluskR4mxJuSWFmVWpQfX1Sak1p8iFGag0VJnLeZ6UGokEB6YklqdmpqQWoRTJaJg1OqgbEg kUv0aOjvVdFWU5rKajb1dlhVB91XeLCswd4wlmvPIo9Qr+UKCdMvPHoQOTN54us/h9xX3TLt OND7un+e8pR4V5snLhyHT29wjXq0976hXCqjTPhDhe83fdLm1dd3zC5KqS3Ycthed+J7r60c XX9mGUw2OdD/ZUpyz42H/BNrb8Tdizmee0aJpTgj0VCLuag4EQD+PxKsmQIAAA== Archived-At: Subject: [Ice] FW: Draft new version: draft-holmberg-mmusic-mux-exclusive-01 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, 08 Dec 2015 20:57:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C8D0C8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, Please provide any comments on the MMUSIC list. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 08 December 2015 22:53 To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclusive-01 Hi, I've submitted a new version (-01) of draft-holmberg-mmusic-mux-exclusive. It now also includes the ICE considerations when indicating support of excl= usive RTP/RTCP multiplexing. NOTE: I have some issues with git, so the new version can NOT yet be found = on github. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C8D0C8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

Please provide any com= ments on the MMUSIC list.

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 08 December 2015 22:53
To: mmusic@ietf.org
Subject: [MMUSIC] Draft new version: draft-holmberg-mmusic-mux-exclu= sive-01

 

Hi,

 

I’ve submitted a new version (-01) of draft-ho= lmberg-mmusic-mux-exclusive.

 

It now also includes the ICE considerations when ind= icating support of exclusive RTP/RTCP multiplexing.

 

NOTE: I have some issues with git, so the new versio= n can NOT yet be found on github.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C8D0C8ESESSMB209erics_-- From nobody Thu Dec 10 08:58:58 2015 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF11A8A76; Thu, 10 Dec 2015 08:58:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151210165856.8625.22880.idtracker@ietfa.amsl.com> Date: Thu, 10 Dec 2015 08:58:56 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-trickle-01.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 16:58:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment Working Group of the IETF. Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol Authors : Emil Ivov Eric Rescorla Justin Uberti Peter Saint-Andre Filename : draft-ietf-ice-trickle-01.txt Pages : 25 Date : 2015-12-10 Abstract: This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. This mechanism is called "trickle ICE". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-trickle-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 10 09:01:56 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 1B32D1A8AC9 for ; Thu, 10 Dec 2015 09:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 Ef3qs9tsFR9L for ; Thu, 10 Dec 2015 09:01:53 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 776021A8ADE for ; Thu, 10 Dec 2015 09:01:24 -0800 (PST) Received: from aither.local (unknown [73.34.202.214]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CE825410D4; Thu, 10 Dec 2015 10:04:40 -0700 (MST) References: <20151210165856.8625.22880.idtracker@ietfa.amsl.com> To: "ice@ietf.org" From: Peter Saint-Andre Message-ID: <5669AFE2.1010403@stpeter.im> Date: Thu, 10 Dec 2015 10:01:22 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151210165856.8625.22880.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-01.txt 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, 10 Dec 2015 17:01:55 -0000 This version represents my attempt to address the open issues, remove the SDP dependency, and perform a general copy edit. Please note that I held the pen on this version, and that my co-authors do not necessarily agree with every change I have made. Some of these modifications are best considered provisional. Please review this version and post to the list with further suggestions for improvement. Thanks! Peter On 12/10/15 9:58 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Interactive Connectivity Establishment Working Group of the IETF. > > Title : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol > Authors : Emil Ivov > Eric Rescorla > Justin Uberti > Peter Saint-Andre > Filename : draft-ietf-ice-trickle-01.txt > Pages : 25 > Date : 2015-12-10 > > Abstract: > This document describes an extension to the Interactive Connectivity > Establishment (ICE) protocol that enables ICE agents to send and > receive candidates incrementally rather than exchanging complete > lists. With such incremental provisioning, ICE agents can begin > connectivity checks while they are still gathering candidates and > considerably shorten the time necessary for ICE processing to > complete. This mechanism is called "trickle ICE". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ice-trickle-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > From nobody Mon Dec 21 02:24:11 2015 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF041A014D; Mon, 21 Dec 2015 02:24:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151221102408.5010.71778.idtracker@ietfa.amsl.com> Date: Mon, 21 Dec 2015 02:24:08 -0800 Archived-At: Cc: ice@ietf.org Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-01.txt X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 10:24:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interactive Connectivity Establishment Working Group of the IETF. Title : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal Authors : Ari Keranen Jonathan Rosenberg Filename : draft-ietf-ice-rfc5245bis-01.txt Pages : 93 Date : 2015-12-21 Abstract: This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/