From nobody Tue Sep 4 02:17:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEE5130E6A; Tue, 4 Sep 2018 02:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xi60eWN9qrL; Tue, 4 Sep 2018 02:16:32 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22855130E66; Tue, 4 Sep 2018 02:16:32 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 555F93AAC2EA3; Tue, 4 Sep 2018 10:16:28 +0100 (IST) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 4 Sep 2018 10:16:29 +0100 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.84]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0399.000; Tue, 4 Sep 2018 17:16:24 +0800 From: "Roni Even (A)" To: Applications and Real-Time Area Discussion CC: "rtcweb@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHUP8PoxOqO8W0TIUG4QCVRlDei1qTf3t7g Date: Tue, 4 Sep 2018 09:16:25 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8D276B@dggemm526-mbx.china.huawei.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <0e4f9505-5d96-f0c1-afbc-f493d1097b65@nostrum.com> In-Reply-To: <0e4f9505-5d96-f0c1-afbc-f493d1097b65@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.152] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8D276Bdggemm526mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 09:16:35 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8D276Bdggemm526mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbSwNCg0KSXMgdGhlcmUgYSByZWFsIG5lZWQgdG8gdXBkYXRlIGRyYWZ0LWlldGYtY2x1 ZS1zaWduYWxpbmctMTMNCg0KDQoNClRoZXJlIGlzIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBSRkM1MjQ1IGFuZCB0aGUgdGV4dCBpcw0KDQoNCg0KDQpBIENMVUUgY2FsbCBtYXkgaW52b2x2 ZSBzZW5kaW5nIGFuZC9vciByZWNlaXZpbmcgc2lnbmlmaWNhbnQgbnVtYmVycw0KICAgb2YgbWVk aWEgc3RyZWFtcy4gIENvbnZlbnRpb25hbGx5LCBtZWRpYSBzdHJlYW1zIGFyZSBzZW50IGFuZA0K ICAgcmVjZWl2ZWQgb24gdW5pcXVlIHBvcnRzLiAgSG93ZXZlciwgZWFjaCBzZXBhcmF0ZSBwb3J0 IHVzZWQgZm9yIHRoaXMNCiAgIHB1cnBvc2UgbWF5IGltcG9zZSBjb3N0cyB0aGF0IGEgZGV2aWNl IHdpc2hlcyB0byBhdm9pZCwgc3VjaCBhcyB0aGUNCiAgIG5lZWQgdG8gb3BlbiB0aGF0IHBvcnQg b24gZmlyZXdhbGxzIGFuZCBOQVRzLCB0aGUgbmVlZCB0byBjb2xsZWN0IElDRQ0KICAgY2FuZGlk YXRlcyBbUkZDNTI0NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NT5dLCBldGMu DQoNCg0KDQoNCg0KU28gc2luY2UgUkZDODQ0NWIgb2Jzb2xldGUgUkZDNTI0NSB0aGlzIGlzIG5v dCBhIG1ham9yIGlzc3VlLg0KDQpBbnlob3cgSSB3aWxsIGFzayB0aGUgYXV0aG9ycyB0byB1cGRh dGUgdGhlIGRvY3VtZW50DQoNClJvbmkgRXZlbg0KDQoNCkZyb206IGNsdWUgW21haWx0bzpjbHVl LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoDQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAyOSwgMjAxOCA5OjEzIFBNDQpUbzogQXBwbGljYXRpb25zIGFuZCBSZWFsLVRp bWUgQXJlYSBEaXNjdXNzaW9uDQpDYzogcnRjd2ViQGlldGYub3JnOyBjbHVlQGlldGYub3JnOyBt bXVzaWNAaWV0Zi5vcmc7IGljZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSBJQ0UsIElD RS1iaXMsIGFuZCBDbHVzdGVyIDIzOA0KDQpJdCdzIGJlZW4gYSB3ZWVrOyBzbyBmYXIgdGhlcmUg aGF2ZSBiZWVuIG5vIG9iamVjdGlvbnMgdG8gdGhpcyBwbGFuLCBhbmQgc2V2ZXJhbCBtZXNzYWdl cyBpbiBzdXBwb3J0LiBJIHBsYW4gdG8gY29uc3VsdCB3aXRoIHRoZSBvdGhlciBBUlQgQURzIHRv IGV2YWx1YXRlIGNvbnNlbnN1cyBvbiB0aGlzIHByb3Bvc2FsIG5leHQgd2VlaywgYW5kIHRha2Ug YXBwcm9wcmlhdGUgYWN0aW9uLiBJZiB5b3UgaGF2ZSB0aG91Z2h0cyB0byBzaGFyZSwgcGxlYXNl IHNlbmQgdGhlbSB0byB0aGUgQVJUIG1haWxpbmcgbGlzdCBiZWZvcmUgU2VwdGVtYmVyIDV0aC4N Cg0KVGhhbmtzIQ0KDQovYQ0KDQpPbiA4LzIyLzE4IDEyOjU4IFBNLCBBZGFtIFJvYWNoIHdyb3Rl Og0KTWVtYmVycyBvZiB0aGUgQVJUIGNvbW11bml0eSBpbnRlcmVzdGVkIGluIHJlYWwtdGltZSBj b21tdW5pY2F0aW9uczoNCg0KQ2x1c3RlciAyMzggWzFdIGlzIGEgc2V0IG9mIGludGVyLXJlbGF0 ZWQgZG9jdW1lbnRzIGRlYWxpbmcgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMuIFRoZSBi dWxrIG9mIHRoZXNlIGRvY3VtZW50cyByZWxhdGUgdG8gV2ViUlRDLCBlaXRoZXIgZGlyZWN0bHkg b3IgaW5kaXJlY3RseS4gVGhleSBhbHNvIGZvcm0gdGhlIHVuZGVycGlubmluZ3Mgb2YgQ0xVRS4g QXMgb2Ygbm93LCB0aGVyZSBhcmUgMzQgZG9jdW1lbnRzIGluIHRoZSBjbHVzdGVyIHRoYXQgYXJl IG5vdCB5ZXQgcHVibGlzaGVkLCB3aXRoIDI1IG9mIHRoZXNlIGFscmVhZHkgaW4gdGhlIFJGQyBF ZGl0b3IncyBxdWV1ZS4gVGhlIGRlcGVuZGVuY3kgZ3JhcGggYW1vbmcgdGhlc2UgZG9jdW1lbnRz IGlzIHN1Y2ggdGhhdCB0aGUgYnVsayBvZiB0aGVtIGNhbiBiZSBwdWJsaXNoZWQgYXMgc29vbiBh cyBhIHNwZWNpZmljIHNpeCBvZiB0aGVtIGFyZSBoYW5kZWQgb2ZmIHRvIHRoZSBSRkMgZWRpdG9y LCBhbmQgd2UgZXhwZWN0IHRoaXMgdG8gaGFwcGVuIGluIHRoZSB1cGNvbWluZyBmZXcgbW9udGhz Lg0KDQpPbmUgbG9uZy1ydW5uaW5nIGNvbXBsaWNhdGlvbiBmb3IgdGhpcyBjbHVzdGVyIG9mIGRv Y3VtZW50cyBpcyB0aGF0IGVhY2ggb2YgdGhlIGRvY3VtZW50cyB3ZXJlIGRldmVsb3BlZCBvdmVy IHRoZSBjb3Vyc2Ugb2Ygc2V2ZW4geWVhcnMsIGluIGNvbmNlcnQgd2l0aCBpbXBsZW1lbnRhdGlv bnMsIHdoaWxlIHRoZSBJQ0UgcHJvdG9jb2wgaXRzZWxmIHdhcyB1bmRlcmdvaW5nIHNpZ25pZmlj YW50IHJldmlzaW9uLiBBcyBhIGNvbnNlcXVlbmNlLCBzb21lIGRvY3VtZW50cyByZWx5IChkaXJl Y3RseSBvciBpbmRpcmVjdGx5KSBvbiB0aGUgb2xkZXIgSUNFIHNwZWNpZmljYXRpb24gKFJGQyA1 MjQ1KSwgd2hpbGUgc29tZSByZWx5IG9uIHRoZSBuZXdlciBvbmUgKFJGQyA4NDQ1KS4gSW4gc29t ZSBjYXNlcywgZG9jdW1lbnRzIHJlZmVyIGRpcmVjdGx5IHRvIHRoZSBvbGQgdmVyc2lvbiBhbmQg dHJhbnNpdGl2ZWx5IHRvIHRoZSBuZXcgdmVyc2lvbi4NCg0KSXQgaXMgbm90ZXdvcnRoeSB0aGF0 IFJGQyA4NDQ1IG9ic29sZXRlcyBSRkMgNTI0NTsgYW5kIHRoYXQgdGhlIG1lY2hhbmlzbSBkZXNj cmliZWQgaW4gUkZDIDg0NDUgaGFzIHNvbWUgIGNoYW5nZXMgdGhhdCBicmVhayBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSB3aXRoIHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMgNTI0NSAod2l0 aCBzdWNoIGJlaGF2aW9yYWwgY2hhbmdlcyBjb250cm9sbGVkIGJ5IGFuIFNEUCBhdHRyaWJ1dGUs IGFsbG93aW5nIGNsaWVudHMgdG8gdHJhbnNpdGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIpLg0K DQpNb3N0IG5vdGFibHksIGRyYWZ0LWlldGYtcnRjd2ViLWpzZXAgKHdoaWNoIGlzIHRoZSBjb3Jl IFdlYlJUQyBwcm90b2NvbCBpbiB0aGUgSUVURikgcmVmZXJzIHRvIGRpcmVjdGx5IHRvIFJGQyA1 MjQ1LCB3aGlsZSByZWx5aW5nIG9uIHRoZSBiZWhhdmlvciBkZWZpbmVkIGluIGRyYWZ0LWlldGYt aWNlLXRyaWNrbGU7IGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUsIGluIHR1cm4sIGlzIGJhc2VkIG9u IHRoZSBuZXdlciBSRkMgODQ0NSBoYW5kbGluZy4gSlNFUCdzIHJlZmVyZW5jZSB0byBSRkMgNTI0 NSBpcyBhIHByYWN0aWNhbCBjb25zaWRlcmF0aW9uIHRoYXQgYWNrbm93bGVkZ2VzIHRoYXQgY3Vy cmVudCBkZXBsb3ltZW50cyBvZiBXZWJSVEMgaW1wbGVtZW50IHRoZSBvbGRlciB2ZXJzaW9uIG9m IElDRS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlc2UgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIHVz ZSBhIHNvbWV3aGF0IG9sZGVyIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSBpbiBj b25jZXJ0IHdpdGggdGhlIG9sZGVyIElDRSBpbXBsZW1lbnRhdGlvbi4NCg0KSW4gb3JkZXIgdG8g Z2V0IENsdXN0ZXIgMjM4IHB1Ymxpc2hlZCwgd2UgbmVlZCB0byBmaW5kIHNvbWUgd2F5IHRvIHJh dGlvbmFsaXplIGl0cyByZWZlcmVuY2VzIHRvIElDRS4gQXQgYSBiYXNpYyBsZXZlbCwgdGhlIEFS VCBBcmVhIERpcmVjdG9ycyBkbyBub3QgYmVsaWV2ZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHB1 Ymxpc2ggbmV3IGRvY3VtZW50cyB0aGF0IHJlZmVyIHRvIGFuIGFscmVhZHkgb2Jzb2xldGVkIFJG Qy4gQXQgdGhlIHNhbWUgdGltZSwgd2UgcmVjb2duaXplIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4g b3VyIHNwZWNpZmljYXRpb25zIGJlaW5nIGluZm9ybWVkIGJ5IHJ1bm5pbmcgY29kZS4gRm9yIFdl YlJUQywgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIHN5c3RlbSBoYXMgbGVkIHVzIHRvIGEgcG9pbnQg dGhhdCB3ZSBtdXN0IGNob29zZSBiZXR3ZWVuIHRoZXNlIHByaW5jaXBsZXMuIE91ciBwcm9wb3Nh bCBpcyB0byBjaG9vc2UgdGhlIGZpcnN0LCB3aGlsZSBhY2tub3dsZWRnaW5nIHRoZSBzZWNvbmQu DQoNClRoaXMgd291bGQgcmVzdWx0IGluIGEgcmVxdWVzdCB0byB0aGUgUkZDIGVkaXRvciB0byB1 cGRhdGUgYWxsIHJlZmVyZW5jZXMgdG8gUkZDIDUyNDUgaW4gdGhlIENsdXN0ZXIgMjM4IGRvY3Vt ZW50cyB0byBpbnN0ZWFkIHBvaW50IHRvIFJGQyA4NDQ1LiBEb2N1bWVudHMgbm90IHlldCBpbiB0 aGUgUkZDIGVkaXRvciBxdWV1ZSB3b3VsZCBiZSB1cGRhdGVkIHByaW9yIHRvIElFU0cgcmV2aWV3 LiBXZSB3b3VsZCBmdXJ0aGVyIHJlcXVlc3QgdGhhdCB0aGUgUkZDIGVkaXRvciBhZGQgdGhlIGZv bGxvd2luZyB0ZXh0IHRvIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IGFuZCBkcmFmdC1pZXRm LXJ0Y3dlYi1qc2VwOg0KV2hpbGUgdGhpcyBzcGVjaWZpY2F0aW9uIGZvcm1hbGx5IHJlbGllcyBv biBbUkZDODQ0NV0sIGF0IHRoZSB0aW1lIG9mIGl0cyBwdWJsaWNhdGlvbiwgdGhlIG1ham9yaXR5 IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGUgdmVyc2lvbiBvZiBJQ0UgZGVz Y3JpYmVkIGluIFtSRkM1MjQ1XSwgYW5kIHVzZSBhIHByZS1zdGFuZGFyZCB2ZXJzaW9uIG9mIHRo ZSB0cmlja2xlIGljZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtSRkNYWFhYXS4gVGhlIHVzZSBv ZiB0aGUgImljZTIiIGF0dHJpYnV0ZSBkZWZpbmVkIGluIFtSRkM4NDQ1XSBjYW4gYmUgdXNlZCB0 byBkZXRlY3QgdGhlIHZlcnNpb24gaW4gdXNlIGJ5IGEgcmVtb3RlIGVuZHBvaW50IGFuZCB0byBw cm92aWRlIGEgc21vb3RoIHRyYW5zaXRpb24gZnJvbSB0aGUgb2xkZXIgc3BlY2lmaWNhdGlvbiB0 byB0aGUgbmV3ZXIgb25lLg0KUkZDIDg0NDUgd291bGQgYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNl IGZvciBib3RoIGRvY3VtZW50cywgd2hpbGUgUkZDIDUyNDUgd291bGQgYmUgaW5mb3JtYXRpdmUu DQoNClRoZXJlIGlzIG9uZSBtb3JlIG1pbm9yIGNvbXBsaWNhdGlvbiwgaW4gdGhhdCBkcmFmdC1p ZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgKHdoaWNoIGN1cnJlbnRseSBwb2ludHMgdG8g UkZDIDUyNDUpIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB0aGUgU0RQ IGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnRzIGl0IGxpc3RzLCBhbmQgUkZDIDg0 NDUgYWRkcyBhIG5ldyAiaWNlMiIgYXR0cmlidXRlIHRoYXQgd2FzIG5vdCBwcmVzZW50IGluIFJG QyA1MjQ1LiBGb3IgdGhpcyByZWFzb24sIHdlIHdvdWxkIGFsc28gYXNrIHRoZSBSRkMgRWRpdG9y IHRvIGFkZCBhIG5ldyByb3cgdG8gdGhlIHRhYmxlIGluIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1t dXgtYXR0cmlidXRlcyBzZWN0aW9uIDUuMTIsIGFzIGZvbGxvd3M6DQoNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0t Kw0KDQogICB8IE5hbWUgICAgICAgICAgICAgIHwgTm90ZXMgICAgICAgICAgICAgICAgICAgICB8 IExldmVsIHwgTXV4ICAgICAgIHwNCg0KICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICB8IENhdGVnb3J5ICB8DQoNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0t Kw0KDQogICB8IGljZTIgICAgICAgICAgICAgIHwgTm90IEltcGFjdGVkICAgICAgICAgICAgICB8 IFMgICAgIHwgTk9STUFMICAgIHwNCg0KICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICB8DQoNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0t Kw0KDQoNCkZvciBjbGFyaXR5LCB0aGUgYWZmZWN0ZWQgZG9jdW1lbnRzIGFyZSBhcyBmb2xsb3dz Lg0KDQpUaGUgZm9sbG93aW5nIGRvY3VtZW50cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5j ZSBSRkMgODQ0NSBwcmlvciB0byBJRVNHIGV2YWx1YXRpb246DQoNCiAgKiAgIGRyYWZ0LWlldGYt Y2x1ZS1kYXRhY2hhbm5lbA0KICAqICAgZHJhZnQtaWV0Zi1jbHVlLXNpZ25hbGluZw0KICAqICAg ZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHkNCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3Vy aXR5LWFyY2gNCg0KDQoNClRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQg dG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yOg0KDQogICogICBkcmFmdC1p ZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZlDQogICogICBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNk cA0KICAqICAgZHJhZnQtaWV0Zi1ydGN3ZWItYWxwbg0KICAqICAgZHJhZnQtaWV0Zi1ydGN3ZWIt ZGF0YS1jaGFubmVsDQogICogICBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UNCg0KDQoNClRo ZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4 NDQ1IGFuZCBoYXZlIHRoZSB0ZXh0IHByb3Bvc2VkIGFib3ZlIGFkZGVkIHRvIHRoZW06DQoNCiAg KiAgIGRyYWZ0LWlldGYtcnRjd2ViLWpzZXANCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2 aWV3DQoNCg0KDQpUaGUgZm9sbG93aW5nIGRvY3VtZW50IHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVm ZXJlbmNlIFJGQyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yLCBhbmQgaW5jbHVkZSBhIG5ldyByb3cg Zm9yICJpY2UyIiBpbiBpdHMgU2VjdGlvbiA1LjEyLCBhcyBkZXNjcmliZWQgYWJvdmU6DQoNCiAg KiAgIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcw0KDQoNCg0KVGhpcyBtZXNz YWdlIGlzIGNyb3NzLXBvc3RlZCB0byB0aGUgYWZmZWN0ZWQgd29ya2luZyBncm91cHMuIEJlY2F1 c2UgdGhlIGlzc3VlIGF0IGhhbmQgaGFzIGltcGFjdCBhY3Jvc3Mgc2V2ZXJhbCBkaWZmZXJlbnQg Z3JvdXBzLCB3ZSBhc2sgdGhhdCBhbGwgZm9sbG93LXVwIGRpc2N1c3Npb24gdGFrZSBwbGFjZSBv biA8YXJ0QGlldGYub3JnPjxtYWlsdG86YXJ0QGlldGYub3JnPi4gVGhhbmsgeW91Lg0KDQovQWRh bSBvbiBiZWhhbGYgb2YgdGhlIEFSVCBBcmVhIERpcmVjdG9ycw0KDQpfX19fDQpbMV0gaHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzIzOA0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8D276Bdggemm526mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KaDEN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFy IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MjQu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6d2lu ZG93dGV4dDsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSGVhZGlu ZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC13ZWlnaHQ6Ym9s ZDt9DQpzcGFuLmgxDQoJe21zby1zdHlsZS1uYW1lOmgxO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2NTY3NjU5OTE7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg3MDExNzU5Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MTY5MTEwMDE5NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTExMDQyMzk3NzI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk OjE3MTA4MzU4MDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMjc5OTYwODI7fQ0KQGxpc3Qg bDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjIxMTI4OTU5NDQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE0ODk0MzY2MTI7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFkYW0sPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JcyB0aGVyZSBhIHJlYWwg bmVlZCB0byB1cGRhdGUgPC9zcGFuPjxiPmRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmctMTM8bzpw PjwvbzpwPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48 Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1saW5lLWhlaWdo dC1hbHQ6MHB0Ij48Yj5UaGVyZSBpcyBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDNTI0 NSBhbmQgdGhlIHRleHQgaXM8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1s aW5lLWhlaWdodC1hbHQ6MHB0Ij48Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48L3ByZT4NCjxwcmUg c3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48Yj48bzpwPiZuYnNwOzwvbzpwPjwvYj48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BIENMVUUgY2FsbCBtYXkgaW52 b2x2ZSBzZW5kaW5nIGFuZC9vciByZWNlaXZpbmcgc2lnbmlmaWNhbnQgbnVtYmVyczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgb2YgbWVkaWEgc3RyZWFtcy4mbmJzcDsgQ29udmVudGlvbmFsbHksIG1lZGlhIHN0cmVhbXMg YXJlIHNlbnQgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyByZWNlaXZlZCBvbiB1bmlxdWUgcG9ydHMuJm5ic3A7IEhv d2V2ZXIsIGVhY2ggc2VwYXJhdGUgcG9ydCB1c2VkIGZvciB0aGlzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBwdXJwb3Nl IG1heSBpbXBvc2UgY29zdHMgdGhhdCBhIGRldmljZSB3aXNoZXMgdG8gYXZvaWQsIHN1Y2ggYXMg dGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBuZWVkIHRvIG9wZW4gdGhhdCBwb3J0IG9uIGZpcmV3YWxscyBhbmQgTkFU cywgdGhlIG5lZWQgdG8gY29sbGVjdCBJQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNhbmRpZGF0ZXMgWzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ1IiB0aXRsZT0iJnF1b3Q7SW50ZXJh Y3RpdmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQgKElDRSk6IEEgUHJvdG9jb2wgZm9yIE5l dHdvcmsgQWRkcmVzcyBUcmFuc2xhdG9yIChOQVQpIFRyYXZlcnNhbCBmb3IgT2ZmZXIvQW5zd2Vy IFByb3RvY29scyZxdW90OyI+UkZDNTI0NTwvYT5dLA0KIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGI+PG86cD4mbmJzcDs8 L286cD48L2I+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGI+ PG86cD4mbmJzcDs8L286cD48L2I+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQt YWx0OjBwdCI+PGI+U28gc2luY2UgUkZDODQ0NWIgb2Jzb2xldGUgUkZDNTI0NSB0aGlzIGlzIG5v dCBhIG1ham9yIGlzc3VlLjxvOnA+PC9vOnA+PC9iPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLWxp bmUtaGVpZ2h0LWFsdDowcHQiPjxiPkFueWhvdyBJIHdpbGwgYXNrIHRoZSBhdXRob3JzIHRvIHVw ZGF0ZSB0aGUgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1s aW5lLWhlaWdodC1hbHQ6MHB0Ij48Yj5Sb25pIEV2ZW48bzpwPjwvbzpwPjwvYj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4gY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QWRhbSBSb2FjaDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAy OSwgMjAxOCA5OjEzIFBNPGJyPg0KPGI+VG86PC9iPiBBcHBsaWNhdGlvbnMgYW5kIFJlYWwtVGlt ZSBBcmVhIERpc2N1c3Npb248YnI+DQo8Yj5DYzo8L2I+IHJ0Y3dlYkBpZXRmLm9yZzsgY2x1ZUBp ZXRmLm9yZzsgbW11c2ljQGlldGYub3JnOyBpY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtjbHVlXSBJQ0UsIElDRS1iaXMsIGFuZCBDbHVzdGVyIDIzODxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCdzIGJlZW4gYSB3ZWVr OyBzbyBmYXIgdGhlcmUgaGF2ZSBiZWVuIG5vIG9iamVjdGlvbnMgdG8gdGhpcyBwbGFuLCBhbmQg c2V2ZXJhbCBtZXNzYWdlcyBpbiBzdXBwb3J0LiBJIHBsYW4gdG8gY29uc3VsdCB3aXRoIHRoZSBv dGhlciBBUlQgQURzIHRvIGV2YWx1YXRlIGNvbnNlbnN1cyBvbiB0aGlzIHByb3Bvc2FsIG5leHQg d2VlaywgYW5kIHRha2UgYXBwcm9wcmlhdGUgYWN0aW9uLiBJZiB5b3UgaGF2ZSB0aG91Z2h0cw0K IHRvIHNoYXJlLCBwbGVhc2Ugc2VuZCB0aGVtIHRvIHRoZSBBUlQgbWFpbGluZyBsaXN0IGJlZm9y ZSBTZXB0ZW1iZXIgNXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi9hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDgvMjIvMTggMTI6NTggUE0sIEFkYW0gUm9hY2ggd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVtYmVycyBv ZiB0aGUgQVJUIGNvbW11bml0eSBpbnRlcmVzdGVkIGluIHJlYWwtdGltZSBjb21tdW5pY2F0aW9u czoNCjxvOnA+PC9vOnA+PC9wPg0KPHA+Q2x1c3RlciAyMzggWzFdIGlzIGEgc2V0IG9mIGludGVy LXJlbGF0ZWQgZG9jdW1lbnRzIGRlYWxpbmcgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMu IFRoZSBidWxrIG9mIHRoZXNlIGRvY3VtZW50cyByZWxhdGUgdG8gV2ViUlRDLCBlaXRoZXIgZGly ZWN0bHkgb3IgaW5kaXJlY3RseS4gVGhleSBhbHNvIGZvcm0gdGhlIHVuZGVycGlubmluZ3Mgb2Yg Q0xVRS4gQXMgb2Ygbm93LCB0aGVyZSBhcmUgMzQgZG9jdW1lbnRzIGluIHRoZSBjbHVzdGVyDQog dGhhdCBhcmUgbm90IHlldCBwdWJsaXNoZWQsIHdpdGggMjUgb2YgdGhlc2UgYWxyZWFkeSBpbiB0 aGUgUkZDIEVkaXRvcidzIHF1ZXVlLiBUaGUgZGVwZW5kZW5jeSBncmFwaCBhbW9uZyB0aGVzZSBk b2N1bWVudHMgaXMgc3VjaCB0aGF0IHRoZSBidWxrIG9mIHRoZW0gY2FuIGJlIHB1Ymxpc2hlZCBh cyBzb29uIGFzIGEgc3BlY2lmaWMgc2l4IG9mIHRoZW0gYXJlIGhhbmRlZCBvZmYgdG8gdGhlIFJG QyBlZGl0b3IsIGFuZCB3ZSBleHBlY3QgdGhpcw0KIHRvIGhhcHBlbiBpbiB0aGUgdXBjb21pbmcg ZmV3IG1vbnRocy48bzpwPjwvbzpwPjwvcD4NCjxwPk9uZSBsb25nLXJ1bm5pbmcgY29tcGxpY2F0 aW9uIGZvciB0aGlzIGNsdXN0ZXIgb2YgZG9jdW1lbnRzIGlzIHRoYXQgZWFjaCBvZiB0aGUgZG9j dW1lbnRzIHdlcmUgZGV2ZWxvcGVkIG92ZXIgdGhlIGNvdXJzZSBvZiBzZXZlbiB5ZWFycywgaW4g Y29uY2VydCB3aXRoIGltcGxlbWVudGF0aW9ucywgd2hpbGUgdGhlIElDRSBwcm90b2NvbCBpdHNl bGYgd2FzIHVuZGVyZ29pbmcgc2lnbmlmaWNhbnQgcmV2aXNpb24uIEFzIGEgY29uc2VxdWVuY2Us DQogc29tZSBkb2N1bWVudHMgcmVseSAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhlIG9s ZGVyIElDRSBzcGVjaWZpY2F0aW9uIChSRkMgNTI0NSksIHdoaWxlIHNvbWUgcmVseSBvbiB0aGUg bmV3ZXIgb25lIChSRkMgODQ0NSkuIEluIHNvbWUgY2FzZXMsIGRvY3VtZW50cyByZWZlciBkaXJl Y3RseSB0byB0aGUgb2xkIHZlcnNpb24gYW5kIHRyYW5zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNp b24uPG86cD48L286cD48L3A+DQo8cD5JdCBpcyBub3Rld29ydGh5IHRoYXQgUkZDIDg0NDUgb2Jz b2xldGVzIFJGQyA1MjQ1OyBhbmQgdGhhdCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBSRkMg ODQ0NSBoYXMgc29tZSZuYnNwOyBjaGFuZ2VzIHRoYXQgYnJlYWsgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDUyNDUgKHdpdGggc3VjaCBi ZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxlZCBieSBhbiBTRFAgYXR0cmlidXRlLCBhbGxvd2lu Zw0KIGNsaWVudHMgdG8gdHJhbnNpdGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIpLjxvOnA+PC9v OnA+PC9wPg0KPHA+TW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwICh3aGljaCBp cyB0aGUgY29yZSBXZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVycyB0byBkaXJlY3Rs eSB0byBSRkMgNTI0NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBk cmFmdC1pZXRmLWljZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xlLCBpbiB0dXJuLCBp cyBiYXNlZCBvbiB0aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuDQogSlNFUCdzIHJlZmVyZW5j ZSB0byBSRkMgNTI0NSBpcyBhIHByYWN0aWNhbCBjb25zaWRlcmF0aW9uIHRoYXQgYWNrbm93bGVk Z2VzIHRoYXQgY3VycmVudCBkZXBsb3ltZW50cyBvZiBXZWJSVEMgaW1wbGVtZW50IHRoZSBvbGRl ciB2ZXJzaW9uIG9mIElDRS4gQXQgdGhlIHNhbWUgdGltZSwgdGhlc2UgZGVwbG95ZWQgaW1wbGVt ZW50YXRpb25zIHVzZSBhIHNvbWV3aGF0IG9sZGVyIHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1pY2Ut dHJpY2tsZSBpbiBjb25jZXJ0DQogd2l0aCB0aGUgb2xkZXIgSUNFIGltcGxlbWVudGF0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPHA+SW4gb3JkZXIgdG8gZ2V0IENsdXN0ZXIgMjM4IHB1Ymxpc2hlZCwg d2UgbmVlZCB0byBmaW5kIHNvbWUgd2F5IHRvIHJhdGlvbmFsaXplIGl0cyByZWZlcmVuY2VzIHRv IElDRS4gQXQgYSBiYXNpYyBsZXZlbCwgdGhlIEFSVCBBcmVhIERpcmVjdG9ycyBkbyBub3QgYmVs aWV2ZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIHB1Ymxpc2ggbmV3IGRvY3VtZW50cyB0aGF0IHJl ZmVyIHRvIGFuIGFscmVhZHkgb2Jzb2xldGVkIFJGQy4gQXQgdGhlIHNhbWUNCiB0aW1lLCB3ZSBy ZWNvZ25pemUgdGhhdCB0aGVyZSBpcyB2YWx1ZSBpbiBvdXIgc3BlY2lmaWNhdGlvbnMgYmVpbmcg aW5mb3JtZWQgYnkgcnVubmluZyBjb2RlLiBGb3IgV2ViUlRDLCB0aGUgY29tcGxleGl0eSBvZiB0 aGUgc3lzdGVtIGhhcyBsZWQgdXMgdG8gYSBwb2ludCB0aGF0IHdlIG11c3QgY2hvb3NlIGJldHdl ZW4gdGhlc2UgcHJpbmNpcGxlcy4gT3VyIHByb3Bvc2FsIGlzIHRvIGNob29zZSB0aGUgZmlyc3Qs IHdoaWxlIGFja25vd2xlZGdpbmcNCiB0aGUgc2Vjb25kLjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhp cyB3b3VsZCByZXN1bHQgaW4gYSByZXF1ZXN0IHRvIHRoZSBSRkMgZWRpdG9yIHRvIHVwZGF0ZSBh bGwgcmVmZXJlbmNlcyB0byBSRkMgNTI0NSBpbiB0aGUgQ2x1c3RlciAyMzggZG9jdW1lbnRzIHRv IGluc3RlYWQgcG9pbnQgdG8gUkZDIDg0NDUuIERvY3VtZW50cyBub3QgeWV0IGluIHRoZSBSRkMg ZWRpdG9yIHF1ZXVlIHdvdWxkIGJlIHVwZGF0ZWQgcHJpb3IgdG8gSUVTRyByZXZpZXcuIFdlIHdv dWxkIGZ1cnRoZXIgcmVxdWVzdCB0aGF0DQogdGhlIFJGQyBlZGl0b3IgYWRkIHRoZSBmb2xsb3dp bmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBhbmQgZHJhZnQtaWV0Zi1ydGN3 ZWItanNlcDo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhp cyBzcGVjaWZpY2F0aW9uIGZvcm1hbGx5IHJlbGllcyBvbiBbUkZDODQ0NV0sIGF0IHRoZSB0aW1l IG9mIGl0cyBwdWJsaWNhdGlvbiwgdGhlIG1ham9yaXR5IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlv bnMgc3VwcG9ydCB0aGUgdmVyc2lvbiBvZiBJQ0UgZGVzY3JpYmVkIGluIFtSRkM1MjQ1XSwgYW5k IHVzZSBhIHByZS1zdGFuZGFyZCB2ZXJzaW9uIG9mIHRoZSB0cmlja2xlIGljZSBtZWNoYW5pc20N CiBkZXNjcmliZWQgaW4gW1JGQ1hYWFhdLiBUaGUgdXNlIG9mIHRoZSAmcXVvdDtpY2UyJnF1b3Q7 IGF0dHJpYnV0ZSBkZWZpbmVkIGluIFtSRkM4NDQ1XSBjYW4gYmUgdXNlZCB0byBkZXRlY3QgdGhl IHZlcnNpb24gaW4gdXNlIGJ5IGEgcmVtb3RlIGVuZHBvaW50IGFuZCB0byBwcm92aWRlIGEgc21v b3RoIHRyYW5zaXRpb24gZnJvbSB0aGUgb2xkZXIgc3BlY2lmaWNhdGlvbiB0byB0aGUgbmV3ZXIg b25lLg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SRkMgODQ0NSB3b3VsZCBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9yIGJvdGggZG9jdW1l bnRzLCB3aGlsZSBSRkMgNTI0NSB3b3VsZCBiZSBpbmZvcm1hdGl2ZS4NCjxvOnA+PC9vOnA+PC9w Pg0KPHA+VGhlcmUgaXMgb25lIG1vcmUgbWlub3IgY29tcGxpY2F0aW9uLCBpbiB0aGF0IGRyYWZ0 LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyAod2hpY2ggY3VycmVudGx5IHBvaW50cyB0 byBSRkMgNTI0NSkgaXMgaW50ZW5kZWQgdG8gYmUgYW4gZXhoYXVzdGl2ZSBsaXN0IG9mIHRoZSBT RFAgYXR0cmlidXRlcyBkZWZpbmVkIGluIHRoZSBkb2N1bWVudHMgaXQgbGlzdHMsIGFuZCBSRkMg ODQ0NSBhZGRzIGEgbmV3ICZxdW90O2ljZTImcXVvdDsgYXR0cmlidXRlDQogdGhhdCB3YXMgbm90 IHByZXNlbnQgaW4gUkZDIDUyNDUuIEZvciB0aGlzIHJlYXNvbiwgd2Ugd291bGQgYWxzbyBhc2sg dGhlIFJGQyBFZGl0b3IgdG8gYWRkIGEgbmV3IHJvdyB0byB0aGUgdGFibGUgaW4gZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzIHNlY3Rpb24gNS4xMiwgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT4mbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tLS0tLS0tLS0t JiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0t LS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgfCBOYW1lJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgTm90ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBMZXZlbCB8IE11eCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgQ2F0ZWdvcnkmbmJzcDsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB8IGljZTImbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCBOb3QgSW1wYWN0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgTk9STUFMJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYj NDM7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+Rm9yIGNsYXJpdHksIHRoZSBhZmZlY3RlZCBkb2N1 bWVudHMgYXJlIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD5UaGUgZm9sbG93aW5nIGRv Y3VtZW50cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBwcmlvciB0byBJ RVNHIGV2YWx1YXRpb246PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtY2x1 ZS1kYXRhY2hhbm5lbDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmc8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpk cmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtcnRjd2ViLXNlY3Vy aXR5LWFyY2g8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHA+VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2Ug UkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3I6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm8yIj4NCmRy YWZ0LWlldGYtbW11c2ljLW11eC1leGNsdXNpdmU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLW1tdXNpYy1z Y3RwLXNkcDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwz IGxldmVsMSBsZm8yIj4NCmRyYWZ0LWlldGYtcnRjd2ViLWFscG48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRm LXJ0Y3dlYi1kYXRhLWNoYW5uZWw8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2U8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VGhlIGZv bGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0NDUg YW5kIGhhdmUgdGhlIHRleHQgcHJvcG9zZWQgYWJvdmUgYWRkZWQgdG8gdGhlbTo8bzpwPjwvbzpw PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzMiPg0KZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCmRyYWZ0LWll dGYtcnRjd2ViLW92ZXJ2aWV3PG86cD48L286cD48L2xpPjwvdWw+DQo8cD48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwPlRoZSBmb2xsb3dpbmcgZG9jdW1lbnQgd291bGQgYmUgdXBkYXRlZCB0byBy ZWZlcmVuY2UgUkZDIDg0NDUgYnkgdGhlIFJGQyBFZGl0b3IsIGFuZCBpbmNsdWRlIGEgbmV3IHJv dyBmb3IgJnF1b3Q7aWNlMiZxdW90OyBpbiBpdHMgU2VjdGlvbiA1LjEyLCBhcyBkZXNjcmliZWQg YWJvdmU6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij4NCmRyYWZ0LWlldGYtbW11c2ljLXNkcC1t dXgtYXR0cmlidXRlczxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHA+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cD5UaGlzIG1lc3NhZ2UgaXMgY3Jvc3MtcG9zdGVkIHRvIHRoZSBhZmZlY3RlZCB3b3Jr aW5nIGdyb3Vwcy4gQmVjYXVzZSB0aGUgaXNzdWUgYXQgaGFuZCBoYXMgaW1wYWN0IGFjcm9zcyBz ZXZlcmFsIGRpZmZlcmVudCBncm91cHMsIHdlIGFzayB0aGF0IGFsbCBmb2xsb3ctdXAgZGlzY3Vz c2lvbiB0YWtlIHBsYWNlIG9uDQo8YSBocmVmPSJtYWlsdG86YXJ0QGlldGYub3JnIj4mbHQ7YXJ0 QGlldGYub3JnJmd0OzwvYT4uIFRoYW5rIHlvdS48bzpwPjwvbzpwPjwvcD4NCjxwPi9BZGFtIG9u IGJlaGFsZiBvZiB0aGUgQVJUIEFyZWEgRGlyZWN0b3JzPG86cD48L286cD48L3A+DQo8cD5fX19f PGJyPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5m by5waHA/Y2lkPUMyMzgiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5w aHA/Y2lkPUMyMzg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_6E58094ECC8D8344914996DAD28F1CCD8D276Bdggemm526mbxchina_-- From nobody Tue Sep 4 02:34:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE57130EBA for ; Tue, 4 Sep 2018 02:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyw0ltogtuOX for ; Tue, 4 Sep 2018 02:33:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3E9130E8E for ; Tue, 4 Sep 2018 02:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536053622; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+WDUc6gVJG0hb8+qOfsZ8mTdFWDC6SDg+kJAcWH9kzg=; b=fPPlLi7/0IF1z5TXmhgAfuoPx/au8YM7P1HTAYecNId4R83JQtuc/2GJG12Sluad OoZkdPcwqZ4IxiFwG2ASz5Rl1k9tw4Z00PvLi/xsIMamSoU8+thXqo6ZwXnzTXhp 8793LxvJWmJFoMSn8AO3qksrW1SjdxKOeFK2MXKbmyk=; X-AuditID: c1b4fb30-ff9ff700000055da-09-5b8e51765c78 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.1C.21978.6715E8B5; Tue, 4 Sep 2018 11:33:42 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 4 Sep 2018 11:33:42 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Tue, 4 Sep 2018 11:33:41 +0200 From: Christer Holmberg To: "Roni Even (A)" , "Applications and Real-Time Area Discussion" CC: "clue@ietf.org" , "rtcweb@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: [art] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURDJda78veyqWb0yhrjMsvHPoKg== Date: Tue, 4 Sep 2018 09:33:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: multipart/alternative; boundary="_000_BC42B57FC31A4798969E52D0270F82D2ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2J7mW5ZYF+0wdsV4hYr7npY7D91mdni 24Vai6nLH7NYfDp2nsVi7b92dgc2j5Yjb1k9liz5yRTAFMVlk5Kak1mWWqRvl8CVsXTfOZaC 9i9MFcsmfGZpYFz1iqmLkZNDQsBEYvrkF6xdjFwcQgJHGSWmPVjMDuF8ZZSYcmIiVGYpo0TX jx7GLkYODjYBC4nuf9og3SICmRK9m38zgdQwC/QxShx894QFpEZYwFzi3SE2iBoLie0vP7NA 2HoSt862MYPYLAIqEu/734PV8ArYS2w6ug2shlFATOL7qTVg1zELiEvcejIf6lIBiSV7zjND 2KISLx//YwVZJSqgLzHtcgBEWEliS+8WqNZkiSkv9rFCjBeUODnzCcsERpFZSKbOQlI2C0nZ LKCpzAKaEut36UOUKEpM6X7IDmFrSLTOmQtlW0s8+bCbFVnNAkaOVYyixanFSbnpRkZ6qUWZ ycXF+Xl6eaklmxiBUXlwy2+DHYwvnzseYhTgYFTi4d3p1RctxJpYVlyZe4hRgoNZSYTXjx8o xJuSWFmVWpQfX1Sak1p8iFGag0VJnNfCb3OUkEB6YklqdmpqQWoRTJaJg1OqgXGGAnfBnImS J74vEXjsUb/umXVvVVpxrPbl9tMCB20016+89XZRQ9z5mBuW5zLdL2RMuRDZvzNvJ8fT+xqC GmcclpWs13zNdH+/2fxH4icVQ1fUHXcudjhgK98RveWq1SmFQw0HPG8J9s7IePjkWanVbpvk CPuy5aZTT1ZLT1R02rmd5a/M/EYlluKMREMt5qLiRABQtxSaxgIAAA== Archived-At: Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 09:33:56 -0000 --_000_BC42B57FC31A4798969E52D0270F82D2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkl0IHRha2VzIDMgbWludXRlcyB0byBjaGFuZ2UgdGhlIHJlZmVyZW5jZSBhbmQgc3Vi bWl0IGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IDopDQoNCkFsc28gbm90ZSB0aGF0IOKAnG9i c29sZXRl4oCdIGRvZXMgbm90IG1lYW4g4oCccmVwbGFjZeKAnSwgYXMgZmFyIGFzIEkga25vdy4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogYXJ0IDxhcnQtYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mICJSb25pIEV2ZW4gKEEpIiA8cm9uaS5ldmVuQGh1YXdlaS5jb20+DQpE YXRlOiBUdWVzZGF5IDQgU2VwdGVtYmVyIDIwMTggYXQgMTI6MTYNClRvOiBBcHBsaWNhdGlvbnMg YW5kIFJlYWwtVGltZSBBcmVhIERpc2N1c3Npb24gPGFydEBpZXRmLm9yZz4NCkNjOiAiY2x1ZUBp ZXRmLm9yZyIgPGNsdWVAaWV0Zi5vcmc+LCAicnRjd2ViQGlldGYub3JnIiA8cnRjd2ViQGlldGYu b3JnPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4sICJpY2VAaWV0Zi5vcmci IDxpY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2FydF0gW2NsdWVdIElDRSwgSUNFLWJpcywg YW5kIENsdXN0ZXIgMjM4DQoNCkhpIEFkYW0sDQoNCklzIHRoZXJlIGEgcmVhbCBuZWVkIHRvIHVw ZGF0ZSBkcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5nLTEzDQoNCg0KDQpUaGVyZSBpcyBhbiBpbmZv cm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDNTI0NSBhbmQgdGhlIHRleHQgaXMNCg0KDQoNCg0KQSBD TFVFIGNhbGwgbWF5IGludm9sdmUgc2VuZGluZyBhbmQvb3IgcmVjZWl2aW5nIHNpZ25pZmljYW50 IG51bWJlcnMNCiAgIG9mIG1lZGlhIHN0cmVhbXMuICBDb252ZW50aW9uYWxseSwgbWVkaWEgc3Ry ZWFtcyBhcmUgc2VudCBhbmQNCiAgIHJlY2VpdmVkIG9uIHVuaXF1ZSBwb3J0cy4gIEhvd2V2ZXIs IGVhY2ggc2VwYXJhdGUgcG9ydCB1c2VkIGZvciB0aGlzDQogICBwdXJwb3NlIG1heSBpbXBvc2Ug Y29zdHMgdGhhdCBhIGRldmljZSB3aXNoZXMgdG8gYXZvaWQsIHN1Y2ggYXMgdGhlDQogICBuZWVk IHRvIG9wZW4gdGhhdCBwb3J0IG9uIGZpcmV3YWxscyBhbmQgTkFUcywgdGhlIG5lZWQgdG8gY29s bGVjdCBJQ0UNCiAgIGNhbmRpZGF0ZXMgW1JGQzUyNDU8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzUyNDU+XSwgZXRjLg0KDQoNCg0KDQoNClNvIHNpbmNlIFJGQzg0NDViIG9ic29sZXRl IFJGQzUyNDUgdGhpcyBpcyBub3QgYSBtYWpvciBpc3N1ZS4NCg0KQW55aG93IEkgd2lsbCBhc2sg dGhlIGF1dGhvcnMgdG8gdXBkYXRlIHRoZSBkb2N1bWVudA0KDQpSb25pIEV2ZW4NCg0KDQpGcm9t OiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWRhbSBS b2FjaA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjksIDIwMTggOToxMyBQTQ0KVG86IEFwcGxp Y2F0aW9ucyBhbmQgUmVhbC1UaW1lIEFyZWEgRGlzY3Vzc2lvbg0KQ2M6IHJ0Y3dlYkBpZXRmLm9y ZzsgY2x1ZUBpZXRmLm9yZzsgbW11c2ljQGlldGYub3JnOyBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbY2x1ZV0gSUNFLCBJQ0UtYmlzLCBhbmQgQ2x1c3RlciAyMzgNCg0KSXQncyBiZWVuIGEg d2Vlazsgc28gZmFyIHRoZXJlIGhhdmUgYmVlbiBubyBvYmplY3Rpb25zIHRvIHRoaXMgcGxhbiwg YW5kIHNldmVyYWwgbWVzc2FnZXMgaW4gc3VwcG9ydC4gSSBwbGFuIHRvIGNvbnN1bHQgd2l0aCB0 aGUgb3RoZXIgQVJUIEFEcyB0byBldmFsdWF0ZSBjb25zZW5zdXMgb24gdGhpcyBwcm9wb3NhbCBu ZXh0IHdlZWssIGFuZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi4gSWYgeW91IGhhdmUgdGhvdWdo dHMgdG8gc2hhcmUsIHBsZWFzZSBzZW5kIHRoZW0gdG8gdGhlIEFSVCBtYWlsaW5nIGxpc3QgYmVm b3JlIFNlcHRlbWJlciA1dGguDQoNClRoYW5rcyENCg0KL2ENCg0KT24gOC8yMi8xOCAxMjo1OCBQ TSwgQWRhbSBSb2FjaCB3cm90ZToNCk1lbWJlcnMgb2YgdGhlIEFSVCBjb21tdW5pdHkgaW50ZXJl c3RlZCBpbiByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnM6DQoNCkNsdXN0ZXIgMjM4IFsxXSBpcyBh IHNldCBvZiBpbnRlci1yZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1lIGNv bW11bmljYXRpb25zLiBUaGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdlYlJU QywgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1bmRl cnBpbm5pbmdzIG9mIENMVUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBpbiB0 aGUgY2x1c3RlciB0aGF0IGFyZSBub3QgeWV0IHB1Ymxpc2hlZCwgd2l0aCAyNSBvZiB0aGVzZSBh bHJlYWR5IGluIHRoZSBSRkMgRWRpdG9yJ3MgcXVldWUuIFRoZSBkZXBlbmRlbmN5IGdyYXBoIGFt b25nIHRoZXNlIGRvY3VtZW50cyBpcyBzdWNoIHRoYXQgdGhlIGJ1bGsgb2YgdGhlbSBjYW4gYmUg cHVibGlzaGVkIGFzIHNvb24gYXMgYSBzcGVjaWZpYyBzaXggb2YgdGhlbSBhcmUgaGFuZGVkIG9m ZiB0byB0aGUgUkZDIGVkaXRvciwgYW5kIHdlIGV4cGVjdCB0aGlzIHRvIGhhcHBlbiBpbiB0aGUg dXBjb21pbmcgZmV3IG1vbnRocy4NCg0KT25lIGxvbmctcnVubmluZyBjb21wbGljYXRpb24gZm9y IHRoaXMgY2x1c3RlciBvZiBkb2N1bWVudHMgaXMgdGhhdCBlYWNoIG9mIHRoZSBkb2N1bWVudHMg d2VyZSBkZXZlbG9wZWQgb3ZlciB0aGUgY291cnNlIG9mIHNldmVuIHllYXJzLCBpbiBjb25jZXJ0 IHdpdGggaW1wbGVtZW50YXRpb25zLCB3aGlsZSB0aGUgSUNFIHByb3RvY29sIGl0c2VsZiB3YXMg dW5kZXJnb2luZyBzaWduaWZpY2FudCByZXZpc2lvbi4gQXMgYSBjb25zZXF1ZW5jZSwgc29tZSBk b2N1bWVudHMgcmVseSAoZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgb24gdGhlIG9sZGVyIElDRSBz cGVjaWZpY2F0aW9uIChSRkMgNTI0NSksIHdoaWxlIHNvbWUgcmVseSBvbiB0aGUgbmV3ZXIgb25l IChSRkMgODQ0NSkuIEluIHNvbWUgY2FzZXMsIGRvY3VtZW50cyByZWZlciBkaXJlY3RseSB0byB0 aGUgb2xkIHZlcnNpb24gYW5kIHRyYW5zaXRpdmVseSB0byB0aGUgbmV3IHZlcnNpb24uDQoNCkl0 IGlzIG5vdGV3b3J0aHkgdGhhdCBSRkMgODQ0NSBvYnNvbGV0ZXMgUkZDIDUyNDU7IGFuZCB0aGF0 IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFJGQyA4NDQ1IGhhcyBzb21lICBjaGFuZ2VzIHRo YXQgYnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmlu ZWQgaW4gUkZDIDUyNDUgKHdpdGggc3VjaCBiZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxlZCBi eSBhbiBTRFAgYXR0cmlidXRlLCBhbGxvd2luZyBjbGllbnRzIHRvIHRyYW5zaXRpb24gZnJvbSBv bmUgdG8gdGhlIG90aGVyKS4NCg0KTW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2Vw ICh3aGljaCBpcyB0aGUgY29yZSBXZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVycyB0 byBkaXJlY3RseSB0byBSRkMgNTI0NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3IgZGVm aW5lZCBpbiBkcmFmdC1pZXRmLWljZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xlLCBp biB0dXJuLCBpcyBiYXNlZCBvbiB0aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuIEpTRVAncyBy ZWZlcmVuY2UgdG8gUkZDIDUyNDUgaXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbiB0aGF0IGFj a25vd2xlZGdlcyB0aGF0IGN1cnJlbnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGltcGxlbWVudCB0 aGUgb2xkZXIgdmVyc2lvbiBvZiBJQ0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNlIGRlcGxveWVk IGltcGxlbWVudGF0aW9ucyB1c2UgYSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0LWll dGYtaWNlLXRyaWNrbGUgaW4gY29uY2VydCB3aXRoIHRoZSBvbGRlciBJQ0UgaW1wbGVtZW50YXRp b24uDQoNCkluIG9yZGVyIHRvIGdldCBDbHVzdGVyIDIzOCBwdWJsaXNoZWQsIHdlIG5lZWQgdG8g ZmluZCBzb21lIHdheSB0byByYXRpb25hbGl6ZSBpdHMgcmVmZXJlbmNlcyB0byBJQ0UuIEF0IGEg YmFzaWMgbGV2ZWwsIHRoZSBBUlQgQXJlYSBEaXJlY3RvcnMgZG8gbm90IGJlbGlldmUgdGhhdCBp dCBtYWtlcyBzZW5zZSB0byBwdWJsaXNoIG5ldyBkb2N1bWVudHMgdGhhdCByZWZlciB0byBhbiBh bHJlYWR5IG9ic29sZXRlZCBSRkMuIEF0IHRoZSBzYW1lIHRpbWUsIHdlIHJlY29nbml6ZSB0aGF0 IHRoZXJlIGlzIHZhbHVlIGluIG91ciBzcGVjaWZpY2F0aW9ucyBiZWluZyBpbmZvcm1lZCBieSBy dW5uaW5nIGNvZGUuIEZvciBXZWJSVEMsIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBzeXN0ZW0gaGFz IGxlZCB1cyB0byBhIHBvaW50IHRoYXQgd2UgbXVzdCBjaG9vc2UgYmV0d2VlbiB0aGVzZSBwcmlu Y2lwbGVzLiBPdXIgcHJvcG9zYWwgaXMgdG8gY2hvb3NlIHRoZSBmaXJzdCwgd2hpbGUgYWNrbm93 bGVkZ2luZyB0aGUgc2Vjb25kLg0KDQpUaGlzIHdvdWxkIHJlc3VsdCBpbiBhIHJlcXVlc3QgdG8g dGhlIFJGQyBlZGl0b3IgdG8gdXBkYXRlIGFsbCByZWZlcmVuY2VzIHRvIFJGQyA1MjQ1IGluIHRo ZSBDbHVzdGVyIDIzOCBkb2N1bWVudHMgdG8gaW5zdGVhZCBwb2ludCB0byBSRkMgODQ0NS4gRG9j dW1lbnRzIG5vdCB5ZXQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgd291bGQgYmUgdXBkYXRlZCBw cmlvciB0byBJRVNHIHJldmlldy4gV2Ugd291bGQgZnVydGhlciByZXF1ZXN0IHRoYXQgdGhlIFJG QyBlZGl0b3IgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVy dmlldyBhbmQgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDoNCldoaWxlIHRoaXMgc3BlY2lmaWNhdGlv biBmb3JtYWxseSByZWxpZXMgb24gW1JGQzg0NDVdLCBhdCB0aGUgdGltZSBvZiBpdHMgcHVibGlj YXRpb24sIHRoZSBtYWpvcml0eSBvZiBXZWJSVEMgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhl IHZlcnNpb24gb2YgSUNFIGRlc2NyaWJlZCBpbiBbUkZDNTI0NV0sIGFuZCB1c2UgYSBwcmUtc3Rh bmRhcmQgdmVyc2lvbiBvZiB0aGUgdHJpY2tsZSBpY2UgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBb UkZDWFhYWF0uIFRoZSB1c2Ugb2YgdGhlICJpY2UyIiBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBbUkZD ODQ0NV0gY2FuIGJlIHVzZWQgdG8gZGV0ZWN0IHRoZSB2ZXJzaW9uIGluIHVzZSBieSBhIHJlbW90 ZSBlbmRwb2ludCBhbmQgdG8gcHJvdmlkZSBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gdGhlIG9s ZGVyIHNwZWNpZmljYXRpb24gdG8gdGhlIG5ld2VyIG9uZS4NClJGQyA4NDQ1IHdvdWxkIGJlIGEg bm9ybWF0aXZlIHJlZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1MjQ1IHdv dWxkIGJlIGluZm9ybWF0aXZlLg0KDQpUaGVyZSBpcyBvbmUgbW9yZSBtaW5vciBjb21wbGljYXRp b24sIGluIHRoYXQgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzICh3aGljaCBj dXJyZW50bHkgcG9pbnRzIHRvIFJGQyA1MjQ1KSBpcyBpbnRlbmRlZCB0byBiZSBhbiBleGhhdXN0 aXZlIGxpc3Qgb2YgdGhlIFNEUCBhdHRyaWJ1dGVzIGRlZmluZWQgaW4gdGhlIGRvY3VtZW50cyBp dCBsaXN0cywgYW5kIFJGQyA4NDQ1IGFkZHMgYSBuZXcgImljZTIiIGF0dHJpYnV0ZSB0aGF0IHdh cyBub3QgcHJlc2VudCBpbiBSRkMgNTI0NS4gRm9yIHRoaXMgcmVhc29uLCB3ZSB3b3VsZCBhbHNv IGFzayB0aGUgUkZDIEVkaXRvciB0byBhZGQgYSBuZXcgcm93IHRvIHRoZSB0YWJsZSBpbiBkcmFm dC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgc2VjdGlvbiA1LjEyLCBhcyBmb2xsb3dz Og0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KICAgfCBOYW1lICAgICAgICAgICAgICB8IE5vdGVzICAg ICAgICAgICAgICAgICAgICAgfCBMZXZlbCB8IE11eCAgICAgICB8DQoNCiAgIHwgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCBDYXRlZ29yeSAg fA0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KICAgfCBpY2UyICAgICAgICAgICAgICB8IE5vdCBJbXBh Y3RlZCAgICAgICAgICAgICAgfCBTICAgICB8IE5PUk1BTCAgICB8DQoNCiAgIHwgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfCAgICAgICAgICAg fA0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tLS0tLSsNCg0KDQpGb3IgY2xhcml0eSwgdGhlIGFmZmVjdGVkIGRvY3Vt ZW50cyBhcmUgYXMgZm9sbG93cy4NCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUg dXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOg0K DQogICogICBkcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwNCiAgKiAgIGRyYWZ0LWlldGYtY2x1 ZS1zaWduYWxpbmcNCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5DQogICogICBkcmFm dC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoDQoNCg0KDQpUaGUgZm9sbG93aW5nIGRvY3VtZW50 cyB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVkaXRv cjoNCg0KICAqICAgZHJhZnQtaWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2ZQ0KICAqICAgZHJhZnQt aWV0Zi1tbXVzaWMtc2N0cC1zZHANCiAgKiAgIGRyYWZ0LWlldGYtcnRjd2ViLWFscG4NCiAgKiAg IGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbA0KICAqICAgZHJhZnQtaWV0Zi1ydGN3ZWIt cnRwLXVzYWdlDQoNCg0KDQpUaGUgZm9sbG93aW5nIGRvY3VtZW50cyB3b3VsZCBiZSB1cGRhdGVk IHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBhbmQgaGF2ZSB0aGUgdGV4dCBwcm9wb3NlZCBhYm92ZSBh ZGRlZCB0byB0aGVtOg0KDQogICogICBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwDQogICogICBkcmFm dC1pZXRmLXJ0Y3dlYi1vdmVydmlldw0KDQoNCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudCB3b3Vs ZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVkaXRvciwgYW5k IGluY2x1ZGUgYSBuZXcgcm93IGZvciAiaWNlMiIgaW4gaXRzIFNlY3Rpb24gNS4xMiwgYXMgZGVz Y3JpYmVkIGFib3ZlOg0KDQogICogICBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0 ZXMNCg0KDQoNClRoaXMgbWVzc2FnZSBpcyBjcm9zcy1wb3N0ZWQgdG8gdGhlIGFmZmVjdGVkIHdv cmtpbmcgZ3JvdXBzLiBCZWNhdXNlIHRoZSBpc3N1ZSBhdCBoYW5kIGhhcyBpbXBhY3QgYWNyb3Nz IHNldmVyYWwgZGlmZmVyZW50IGdyb3Vwcywgd2UgYXNrIHRoYXQgYWxsIGZvbGxvdy11cCBkaXNj dXNzaW9uIHRha2UgcGxhY2Ugb24gPGFydEBpZXRmLm9yZz48bWFpbHRvOmFydEBpZXRmLm9yZz4u IFRoYW5rIHlvdS4NCg0KL0FkYW0gb24gYmVoYWxmIG9mIHRoZSBBUlQgQXJlYSBEaXJlY3RvcnMN Cg0KX19fXw0KWzFdIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5waHA/ Y2lkPUMyMzgNCg0K --_000_BC42B57FC31A4798969E52D0270F82D2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2489BB310ADA4F4D8E20A998BF3B11B3@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQpoMQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUt bGluazoiSGVhZGluZyAxIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGNtOw0KCWZvbnQtc2l6ZToyNC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp ZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhlYWRpbmcxQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SGVhZGluZyAxIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5r OiJIZWFkaW5nIDEiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjIN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLmgxDQoJe21zby1zdHlsZS1uYW1lOmgxO30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE2NTY3NjU5OTE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjg3MDExNzU5Mjt9 DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoxNjkxMTAwMTk3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTEwNDIz OTc3Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMg0KCXttc28tbGlzdC1pZDoxNzEwODM1ODA0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoy MDI3OTk2MDgyO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjIxMTI4OTU5NDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE0ODk0MzY2MTI7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkhpLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij5JdCB0YWtlcyAzIG1pbnV0ZXMgdG8gY2hhbmdlIHRoZSByZWZlcmVu Y2UgYW5kIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCA6KTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij5BbHNvIG5vdGUgdGhhdCDigJxvYnNvbGV0ZeKAnSBkb2VzIG5vdCBtZWFuIOKAnHJlcGxh Y2XigJ0sIGFzIGZhciBhcyBJIGtub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206IDwvYj5hcnQgJmx0O2FydC1ib3VuY2Vz QGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7Um9uaSBFdmVuIChBKSZxdW90OyAmbHQ7 cm9uaS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXkgNCBTZXB0 ZW1iZXIgMjAxOCBhdCAxMjoxNjxicj4NCjxiPlRvOiA8L2I+QXBwbGljYXRpb25zIGFuZCBSZWFs LVRpbWUgQXJlYSBEaXNjdXNzaW9uICZsdDthcnRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDtjbHVlQGlldGYub3JnJnF1b3Q7ICZsdDtjbHVlQGlldGYub3JnJmd0OywgJnF1b3Q7 cnRjd2ViQGlldGYub3JnJnF1b3Q7ICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDttbXVz aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O21tdXNpY0BpZXRmLm9yZyZndDssICZxdW90O2ljZUBpZXRm Lm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W2FydF0gW2NsdWVdIElDRSwgSUNFLWJpcywgYW5kIENsdXN0ZXIgMjM4PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IaSBBZGFtLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1zby1saW5l LWhlaWdodC1hbHQ6MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUg YSByZWFsIG5lZWQgdG8gdXBkYXRlIDwvc3Bhbj48Yj5kcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5n LTEzPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0 OjBwdCI+PGI+Jm5ic3A7PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbGlu ZS1oZWlnaHQtYWx0OjBwdCI+PGI+VGhlcmUgaXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRv IFJGQzUyNDUgYW5kIHRoZSB0ZXh0IGlzPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGI+Jm5ic3A7PC9iPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGI+Jm5ic3A7PC9iPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QSBDTFVFIGNhbGwg bWF5IGludm9sdmUgc2VuZGluZyBhbmQvb3IgcmVjZWl2aW5nIHNpZ25pZmljYW50IG51bWJlcnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IG9mIG1lZGlhIHN0cmVhbXMuJm5ic3A7IENvbnZlbnRpb25hbGx5LCBtZWRpYSBz dHJlYW1zIGFyZSBzZW50IGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcmVjZWl2ZWQgb24gdW5pcXVlIHBvcnRzLiZu YnNwOyBIb3dldmVyLCBlYWNoIHNlcGFyYXRlIHBvcnQgdXNlZCBmb3IgdGhpczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg cHVycG9zZSBtYXkgaW1wb3NlIGNvc3RzIHRoYXQgYSBkZXZpY2Ugd2lzaGVzIHRvIGF2b2lkLCBz dWNoIGFzIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbmVlZCB0byBvcGVuIHRoYXQgcG9ydCBvbiBmaXJld2FsbHMg YW5kIE5BVHMsIHRoZSBuZWVkIHRvIGNvbGxlY3QgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjYW5kaWRhdGVzIFs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTI0NSIgdGl0bGU9IiZxdW90 O0ludGVyYWN0aXZlIENvbm5lY3Rpdml0eSBFc3RhYmxpc2htZW50IChJQ0UpOiBBIFByb3RvY29s IGZvciBOZXR3b3JrIEFkZHJlc3MgVHJhbnNsYXRvciAoTkFUKSBUcmF2ZXJzYWwgZm9yIE9mZmVy L0Fuc3dlciBQcm90b2NvbHMmcXVvdDsiPlJGQzUyNDU8L2E+XSwNCiBldGMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQiPjxiPiZuYnNw OzwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUtaGVpZ2h0LWFsdDow cHQiPjxiPiZuYnNwOzwvYj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLWxpbmUt aGVpZ2h0LWFsdDowcHQiPjxiPlNvIHNpbmNlIFJGQzg0NDViIG9ic29sZXRlIFJGQzUyNDUgdGhp cyBpcyBub3QgYSBtYWpvciBpc3N1ZS48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48Yj5Bbnlob3cgSSB3aWxsIGFzayB0aGUgYXV0aG9y cyB0byB1cGRhdGUgdGhlIGRvY3VtZW50PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGI+Um9uaSBFdmVuPC9iPjxvOnA+PC9vOnA+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFkYW0gUm9hY2g8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBBdWd1c3QgMjksIDIwMTggOToxMyBQTTxicj4NCjxiPlRvOjwvYj4gQXBwbGljYXRp b25zIGFuZCBSZWFsLVRpbWUgQXJlYSBEaXNjdXNzaW9uPGJyPg0KPGI+Q2M6PC9iPiBydGN3ZWJA aWV0Zi5vcmc7IGNsdWVAaWV0Zi5vcmc7IG1tdXNpY0BpZXRmLm9yZzsgaWNlQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY2x1ZV0gSUNFLCBJQ0UtYmlzLCBhbmQgQ2x1c3RlciAy Mzg8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQncyBiZWVuIGEgd2Vlazsgc28gZmFyIHRoZXJlIGhhdmUgYmVlbiBubyBvYmplY3Rpb25zIHRv IHRoaXMgcGxhbiwgYW5kIHNldmVyYWwgbWVzc2FnZXMgaW4gc3VwcG9ydC4gSSBwbGFuIHRvIGNv bnN1bHQgd2l0aCB0aGUgb3RoZXIgQVJUIEFEcyB0byBldmFsdWF0ZSBjb25zZW5zdXMgb24gdGhp cyBwcm9wb3NhbCBuZXh0IHdlZWssIGFuZCB0YWtlIGFwcHJvcHJpYXRlIGFjdGlvbi4gSWYgeW91 IGhhdmUgdGhvdWdodHMNCiB0byBzaGFyZSwgcGxlYXNlIHNlbmQgdGhlbSB0byB0aGUgQVJUIG1h aWxpbmcgbGlzdCBiZWZvcmUgU2VwdGVtYmVyIDV0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA4LzIyLzE4IDEyOjU4IFBNLCBB ZGFtIFJvYWNoIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1lbWJlcnMgb2YgdGhlIEFSVCBjb21tdW5pdHkgaW50ZXJlc3RlZCBpbiByZWFsLXRp bWUgY29tbXVuaWNhdGlvbnM6DQo8bzpwPjwvbzpwPjwvcD4NCjxwPkNsdXN0ZXIgMjM4IFsxXSBp cyBhIHNldCBvZiBpbnRlci1yZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1l IGNvbW11bmljYXRpb25zLiBUaGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdl YlJUQywgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1 bmRlcnBpbm5pbmdzIG9mIENMVUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBp biB0aGUgY2x1c3Rlcg0KIHRoYXQgYXJlIG5vdCB5ZXQgcHVibGlzaGVkLCB3aXRoIDI1IG9mIHRo ZXNlIGFscmVhZHkgaW4gdGhlIFJGQyBFZGl0b3IncyBxdWV1ZS4gVGhlIGRlcGVuZGVuY3kgZ3Jh cGggYW1vbmcgdGhlc2UgZG9jdW1lbnRzIGlzIHN1Y2ggdGhhdCB0aGUgYnVsayBvZiB0aGVtIGNh biBiZSBwdWJsaXNoZWQgYXMgc29vbiBhcyBhIHNwZWNpZmljIHNpeCBvZiB0aGVtIGFyZSBoYW5k ZWQgb2ZmIHRvIHRoZSBSRkMgZWRpdG9yLCBhbmQgd2UgZXhwZWN0IHRoaXMNCiB0byBoYXBwZW4g aW4gdGhlIHVwY29taW5nIGZldyBtb250aHMuPG86cD48L286cD48L3A+DQo8cD5PbmUgbG9uZy1y dW5uaW5nIGNvbXBsaWNhdGlvbiBmb3IgdGhpcyBjbHVzdGVyIG9mIGRvY3VtZW50cyBpcyB0aGF0 IGVhY2ggb2YgdGhlIGRvY3VtZW50cyB3ZXJlIGRldmVsb3BlZCBvdmVyIHRoZSBjb3Vyc2Ugb2Yg c2V2ZW4geWVhcnMsIGluIGNvbmNlcnQgd2l0aCBpbXBsZW1lbnRhdGlvbnMsIHdoaWxlIHRoZSBJ Q0UgcHJvdG9jb2wgaXRzZWxmIHdhcyB1bmRlcmdvaW5nIHNpZ25pZmljYW50IHJldmlzaW9uLiBB cyBhIGNvbnNlcXVlbmNlLA0KIHNvbWUgZG9jdW1lbnRzIHJlbHkgKGRpcmVjdGx5IG9yIGluZGly ZWN0bHkpIG9uIHRoZSBvbGRlciBJQ0Ugc3BlY2lmaWNhdGlvbiAoUkZDIDUyNDUpLCB3aGlsZSBz b21lIHJlbHkgb24gdGhlIG5ld2VyIG9uZSAoUkZDIDg0NDUpLiBJbiBzb21lIGNhc2VzLCBkb2N1 bWVudHMgcmVmZXIgZGlyZWN0bHkgdG8gdGhlIG9sZCB2ZXJzaW9uIGFuZCB0cmFuc2l0aXZlbHkg dG8gdGhlIG5ldyB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+SXQgaXMgbm90ZXdvcnRoeSB0 aGF0IFJGQyA4NDQ1IG9ic29sZXRlcyBSRkMgNTI0NTsgYW5kIHRoYXQgdGhlIG1lY2hhbmlzbSBk ZXNjcmliZWQgaW4gUkZDIDg0NDUgaGFzIHNvbWUmbmJzcDsgY2hhbmdlcyB0aGF0IGJyZWFrIGJh Y2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggdGhlIG1lY2hhbmlzbSBkZWZpbmVkIGluIFJGQyA1 MjQ1ICh3aXRoIHN1Y2ggYmVoYXZpb3JhbCBjaGFuZ2VzIGNvbnRyb2xsZWQgYnkgYW4gU0RQIGF0 dHJpYnV0ZSwgYWxsb3dpbmcNCiBjbGllbnRzIHRvIHRyYW5zaXRpb24gZnJvbSBvbmUgdG8gdGhl IG90aGVyKS48bzpwPjwvbzpwPjwvcD4NCjxwPk1vc3Qgbm90YWJseSwgZHJhZnQtaWV0Zi1ydGN3 ZWItanNlcCAod2hpY2ggaXMgdGhlIGNvcmUgV2ViUlRDIHByb3RvY29sIGluIHRoZSBJRVRGKSBy ZWZlcnMgdG8gZGlyZWN0bHkgdG8gUkZDIDUyNDUsIHdoaWxlIHJlbHlpbmcgb24gdGhlIGJlaGF2 aW9yIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZTsgZHJhZnQtaWV0Zi1pY2UtdHJp Y2tsZSwgaW4gdHVybiwgaXMgYmFzZWQgb24gdGhlIG5ld2VyIFJGQyA4NDQ1IGhhbmRsaW5nLg0K IEpTRVAncyByZWZlcmVuY2UgdG8gUkZDIDUyNDUgaXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlv biB0aGF0IGFja25vd2xlZGdlcyB0aGF0IGN1cnJlbnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGlt cGxlbWVudCB0aGUgb2xkZXIgdmVyc2lvbiBvZiBJQ0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNl IGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyB1c2UgYSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9m IGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUgaW4gY29uY2VydA0KIHdpdGggdGhlIG9sZGVyIElDRSBp bXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwPkluIG9yZGVyIHRvIGdldCBDbHVzdGVy IDIzOCBwdWJsaXNoZWQsIHdlIG5lZWQgdG8gZmluZCBzb21lIHdheSB0byByYXRpb25hbGl6ZSBp dHMgcmVmZXJlbmNlcyB0byBJQ0UuIEF0IGEgYmFzaWMgbGV2ZWwsIHRoZSBBUlQgQXJlYSBEaXJl Y3RvcnMgZG8gbm90IGJlbGlldmUgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byBwdWJsaXNoIG5ldyBk b2N1bWVudHMgdGhhdCByZWZlciB0byBhbiBhbHJlYWR5IG9ic29sZXRlZCBSRkMuIEF0IHRoZSBz YW1lDQogdGltZSwgd2UgcmVjb2duaXplIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4gb3VyIHNwZWNp ZmljYXRpb25zIGJlaW5nIGluZm9ybWVkIGJ5IHJ1bm5pbmcgY29kZS4gRm9yIFdlYlJUQywgdGhl IGNvbXBsZXhpdHkgb2YgdGhlIHN5c3RlbSBoYXMgbGVkIHVzIHRvIGEgcG9pbnQgdGhhdCB3ZSBt dXN0IGNob29zZSBiZXR3ZWVuIHRoZXNlIHByaW5jaXBsZXMuIE91ciBwcm9wb3NhbCBpcyB0byBj aG9vc2UgdGhlIGZpcnN0LCB3aGlsZSBhY2tub3dsZWRnaW5nDQogdGhlIHNlY29uZC48bzpwPjwv bzpwPjwvcD4NCjxwPlRoaXMgd291bGQgcmVzdWx0IGluIGEgcmVxdWVzdCB0byB0aGUgUkZDIGVk aXRvciB0byB1cGRhdGUgYWxsIHJlZmVyZW5jZXMgdG8gUkZDIDUyNDUgaW4gdGhlIENsdXN0ZXIg MjM4IGRvY3VtZW50cyB0byBpbnN0ZWFkIHBvaW50IHRvIFJGQyA4NDQ1LiBEb2N1bWVudHMgbm90 IHlldCBpbiB0aGUgUkZDIGVkaXRvciBxdWV1ZSB3b3VsZCBiZSB1cGRhdGVkIHByaW9yIHRvIElF U0cgcmV2aWV3LiBXZSB3b3VsZCBmdXJ0aGVyIHJlcXVlc3QgdGhhdA0KIHRoZSBSRkMgZWRpdG9y IGFkZCB0aGUgZm9sbG93aW5nIHRleHQgdG8gZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXcgYW5k IGRyYWZ0LWlldGYtcnRjd2ViLWpzZXA6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldoaWxlIHRoaXMgc3BlY2lmaWNhdGlvbiBmb3JtYWxseSByZWxpZXMgb24gW1JGQzg0 NDVdLCBhdCB0aGUgdGltZSBvZiBpdHMgcHVibGljYXRpb24sIHRoZSBtYWpvcml0eSBvZiBXZWJS VEMgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgdGhlIHZlcnNpb24gb2YgSUNFIGRlc2NyaWJlZCBp biBbUkZDNTI0NV0sIGFuZCB1c2UgYSBwcmUtc3RhbmRhcmQgdmVyc2lvbiBvZiB0aGUgdHJpY2ts ZSBpY2UgbWVjaGFuaXNtDQogZGVzY3JpYmVkIGluIFtSRkNYWFhYXS4gVGhlIHVzZSBvZiB0aGUg JnF1b3Q7aWNlMiZxdW90OyBhdHRyaWJ1dGUgZGVmaW5lZCBpbiBbUkZDODQ0NV0gY2FuIGJlIHVz ZWQgdG8gZGV0ZWN0IHRoZSB2ZXJzaW9uIGluIHVzZSBieSBhIHJlbW90ZSBlbmRwb2ludCBhbmQg dG8gcHJvdmlkZSBhIHNtb290aCB0cmFuc2l0aW9uIGZyb20gdGhlIG9sZGVyIHNwZWNpZmljYXRp b24gdG8gdGhlIG5ld2VyIG9uZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UkZDIDg0NDUgd291bGQgYmUgYSBub3JtYXRpdmUgcmVmZXJlbmNl IGZvciBib3RoIGRvY3VtZW50cywgd2hpbGUgUkZDIDUyNDUgd291bGQgYmUgaW5mb3JtYXRpdmUu DQo8bzpwPjwvbzpwPjwvcD4NCjxwPlRoZXJlIGlzIG9uZSBtb3JlIG1pbm9yIGNvbXBsaWNhdGlv biwgaW4gdGhhdCBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgKHdoaWNoIGN1 cnJlbnRseSBwb2ludHMgdG8gUkZDIDUyNDUpIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4aGF1c3Rp dmUgbGlzdCBvZiB0aGUgU0RQIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnRzIGl0 IGxpc3RzLCBhbmQgUkZDIDg0NDUgYWRkcyBhIG5ldyAmcXVvdDtpY2UyJnF1b3Q7IGF0dHJpYnV0 ZQ0KIHRoYXQgd2FzIG5vdCBwcmVzZW50IGluIFJGQyA1MjQ1LiBGb3IgdGhpcyByZWFzb24sIHdl IHdvdWxkIGFsc28gYXNrIHRoZSBSRkMgRWRpdG9yIHRvIGFkZCBhIG5ldyByb3cgdG8gdGhlIHRh YmxlIGluIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyBzZWN0aW9uIDUuMTIs IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7ICZuYnNwOyYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHwgTmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE5vdGVzJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTGV2ZWwgfCBN dXgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IENhdGVnb3J5Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0t LS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgfCBpY2Uy Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgTm90IEltcGFjdGVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE5PUk1BTCZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYj NDM7LS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkZvciBjbGFyaXR5LCB0 aGUgYWZmZWN0ZWQgZG9jdW1lbnRzIGFyZSBhcyBmb2xsb3dzLjxvOnA+PC9vOnA+PC9wPg0KPHA+ VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZD IDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+ DQpkcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWw8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpkcmFmdC1pZXRmLWNsdWUtc2ln bmFsaW5nPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzEiPg0KZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHk8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpkcmFmdC1p ZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoPG86cD48L286cD48L2xpPjwvdWw+DQo8cD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwPlRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0 ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yOjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBs ZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLW1tdXNpYy1tdXgtZXhjbHVzaXZlPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPg0KZHJh ZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+DQpkcmFmdC1pZXRmLXJ0Y3dlYi1hbHBuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzIiPg0KZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPg0KZHJhZnQtaWV0Zi1y dGN3ZWItcnRwLXVzYWdlPG86cD48L286cD48L2xpPjwvdWw+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwPlRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVm ZXJlbmNlIFJGQyA4NDQ1IGFuZCBoYXZlIHRoZSB0ZXh0IHByb3Bvc2VkIGFib3ZlIGFkZGVkIHRv IHRoZW06PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCmRyYWZ0LWlldGYtcnRjd2ViLWpzZXA8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEg bGZvMyI+DQpkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldzxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5UaGUgZm9sbG93aW5nIGRvY3VtZW50IHdvdWxk IGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yLCBhbmQg aW5jbHVkZSBhIG5ldyByb3cgZm9yICZxdW90O2ljZTImcXVvdDsgaW4gaXRzIFNlY3Rpb24gNS4x MiwgYXMgZGVzY3JpYmVkIGFib3ZlOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQpkcmFmdC1p ZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXM8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+VGhpcyBtZXNzYWdlIGlzIGNyb3NzLXBvc3RlZCB0byB0 aGUgYWZmZWN0ZWQgd29ya2luZyBncm91cHMuIEJlY2F1c2UgdGhlIGlzc3VlIGF0IGhhbmQgaGFz IGltcGFjdCBhY3Jvc3Mgc2V2ZXJhbCBkaWZmZXJlbnQgZ3JvdXBzLCB3ZSBhc2sgdGhhdCBhbGwg Zm9sbG93LXVwIGRpc2N1c3Npb24gdGFrZSBwbGFjZSBvbg0KPGEgaHJlZj0ibWFpbHRvOmFydEBp ZXRmLm9yZyI+Jmx0O2FydEBpZXRmLm9yZyZndDs8L2E+LiBUaGFuayB5b3UuPG86cD48L286cD48 L3A+DQo8cD4vQWRhbSBvbiBiZWhhbGYgb2YgdGhlIEFSVCBBcmVhIERpcmVjdG9yczxvOnA+PC9v OnA+PC9wPg0KPHA+X19fXzxicj4NClsxXSA8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9jbHVzdGVyX2luZm8ucGhwP2NpZD1DMjM4Ij5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9jbHVzdGVyX2luZm8ucGhwP2NpZD1DMjM4PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BC42B57FC31A4798969E52D0270F82D2ericssoncom_-- From nobody Tue Sep 4 12:02:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DEE130FA3 for ; Tue, 4 Sep 2018 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svaim0unWkly for ; Tue, 4 Sep 2018 12:02:05 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8C5130F99 for ; Tue, 4 Sep 2018 12:01:55 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id w193-v6so1764553vke.2 for ; Tue, 04 Sep 2018 12:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Tg/R0lm6Wx9WIAaqK1AiQXlBA6+VAg9LfMUMxsIHR8M=; b=I8p5yq49dRilIkzwlHGrNAbmFC3A/szVhrmLlYHzcuEawWpU7JU3Pkp4Ybwi/ptuxb HRX9tQQEq6CnbN46rubsH4UHefVC6OmBeUYk8ImSJdRzCmj1pkXy9EEE71U6HL5g2LaQ AKnhEkuyuSa2WGDE78/FIbBJw6R7ah/vnMrJiKZmmUbgFGVf/rX9tJSRy2YQBOVlNMBW ndVaCjR5nTXeEk9Jh1AKWfxK0utQyYenJgWj5AxAWazhnE5xV/+YAVukY+wZZIxUcw9j BZGyR2VtY5F5Pu8Y7Wzrlk/8g7b4bTQDRiJRmyAUkP5DOex1CJpTFynqlQhyhft78fKC J4uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tg/R0lm6Wx9WIAaqK1AiQXlBA6+VAg9LfMUMxsIHR8M=; b=B3YarKbK9aINf6hbjJDa+HrVnChSitq7FPjOLrBxBLIEY/TVynBrRjIENZ0wNzUKSi H51twHgvIRpsBVkAQsOrxQkwpSI13U37+H6YZPNrfzlzSEQbtZuAmpXc0o8qtY6FgJMS 3uUxwZxt0bFGfegyLOlEEAU9iUFRZ2fUXZcgF5Z7e6/qgMr8g2EYl3rx/BTjvvNWUHC3 ZKxpsXtaj6FcdjgVdC7ey9uxStJaloUn6EKreg/BhsLkb3xIWSDpk/614COPvvDrXHOB seO/aScHLaJrzJ/lypzVAPWDOHSGoVPOgJz16v+0VMXRPc9LkG7YwKvrRVvGez7hATcc RZAg== X-Gm-Message-State: APzg51CXe04zFYxavev/3E/Z9Bln3opiThvYKRrRnX9WRaqv+GrFoGNL Ob6+zK8qObCeDx+qCCCoLhrMZG4uUYNmHUZgW9ZT+yuU X-Google-Smtp-Source: ANB0VdaemMVjwqXPODXN9STu75vj83gjhchEtgtgIZlrRslh6ST6qqCs42MsXvkfQl4S9pzW7r4ojqV1kbpI97LD9SU= X-Received: by 2002:a1f:6ac3:: with SMTP id f186-v6mr16695761vkc.119.1536087714221; Tue, 04 Sep 2018 12:01:54 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Tue, 4 Sep 2018 12:01:43 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000008cdb320575104adf" Archived-At: Subject: [rtcweb] WebRTC Next Version Use Cases: now available! X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 19:02:07 -0000 --0000000000008cdb320575104adf Content-Type: text/plain; charset="UTF-8" An initial draft of one of the world's least remarkable documents has become available. By clicking on the links below, your eyes could be among the first to see it! Parental discretion advised! To obtain your complementary copy of "WebRTC Next Version Use Cases", click here: https://w3c.github.io/webrtc-nv-use-cases/ To enable readers to express their outrage and dismay, Issues can be filed here: https://github.com/w3c/webrtc-nv-use-cases/issues --0000000000008cdb320575104adf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
An initial draft of one of the world's least remarkabl= e documents has become available. By clicking on the links below, your eyes= could be among the first to see it! Parental discretion advised!

<= /div>
To obtain your complementary copy of "WebRTC Next Version Us= e Cases", click here:

To enable readers to express their outrage and dismay, Is= sues can be filed here:
--0000000000008cdb320575104adf-- From nobody Thu Sep 6 13:24:56 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72194130EDB for ; Thu, 6 Sep 2018 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EJyUuYWRDox for ; Thu, 6 Sep 2018 13:24:48 -0700 (PDT) Received: from smtp113.ord1d.emailsrvr.com (smtp113.ord1d.emailsrvr.com [184.106.54.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94F0130F1C for ; Thu, 6 Sep 2018 13:24:47 -0700 (PDT) Received: from smtp23.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 0C1A02012C; Thu, 6 Sep 2018 16:24:47 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7EFC12058A; Thu, 6 Sep 2018 16:24:46 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.173] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:25 (trex/5.7.12); Thu, 06 Sep 2018 16:24:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_1CAE2495-9FB4-401A-86A6-D79AD3300118" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> Date: Thu, 6 Sep 2018 13:24:45 -0700 Cc: "clue@ietf.org" , RTCWeb IETF , "mmusic@ietf.org" , "ice@ietf.org" Message-Id: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> To: Applications and Real-Time Area Discussion X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 20:24:51 -0000 --Apple-Mail=_1CAE2495-9FB4-401A-86A6-D79AD3300118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I object to this plan.=20 It is not merely an issue of which document we point out, and they are = all the same. The problem is the timing of 8445 is not clearly = interoperable with the timing of 5245. ICE relies on both sides to do = sequence things at roughly the same order so that suicided packets open = pinholes in the reverse direction at the right time. The changes in = timing change how this happens and is a problem for the ICE algorithm.=20= This was discussed in the WG, and though not everyone agrees it is a = problem or not, no one has ever provided a convincing argument that it = is not. This is a very substantial change to the on the wire protocol = and at a minimum would need to be reviewed and discussed in the WG not = slipped through in Auth 48 during a one week period in the summer while = everyone is on vacation. We will also need to change other examples and = normative text in drafts like JSEP.=20 I would propose that instead of the parts of specs that use the trickle = mechanism purely reference that part of the new ICE spec that defines = the syntax and say to transfer trickle candidates.=20 Cisco has implemented stuff that is WebRTC 1.0 compliant without this = change. These gratuitous changes, years after the implementation were = coded, with no real benefit will ensure that we are not and will not = become compliant with the RFC. It's unlikely we will upgrade to the new = ICE until it has real befits. It is doubtful Justin will want to = implement the 8445 mechanisms of supporting both new and old ICE. = Instead, we will move to say "works with Browser X version Y or later." = We have watched at W3C as it moved to be that unless chrome does it, it = rare that it becomes a standard. Right here I am watching how the stuff = IETF defines will be less relevant than the issue of what chrome = implements.=20 > On Aug 22, 2018, at 10:58 AM, Adam Roach wrote: >=20 > Members of the ART community interested in real-time communications: > Cluster 238 [1] is a set of inter-related documents dealing with = real-time communications. The bulk of these documents relate to WebRTC, = either directly or indirectly. They also form the underpinnings of CLUE. = As of now, there are 34 documents in the cluster that are not yet = published, with 25 of these already in the RFC Editor's queue. The = dependency graph among these documents is such that the bulk of them can = be published as soon as a specific six of them are handed off to the RFC = editor, and we expect this to happen in the upcoming few months. >=20 > One long-running complication for this cluster of documents is that = each of the documents were developed over the course of seven years, in = concert with implementations, while the ICE protocol itself was = undergoing significant revision. As a consequence, some documents rely = (directly or indirectly) on the older ICE specification (RFC 5245), = while some rely on the newer one (RFC 8445). In some cases, documents = refer directly to the old version and transitively to the new version. > It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the = mechanism described in RFC 8445 has some changes that break backwards = compatibility with the mechanism defined in RFC 5245 (with such = behavioral changes controlled by an SDP attribute, allowing clients to = transition from one to the other). >=20 > Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC = protocol in the IETF) refers to directly to RFC 5245, while relying on = the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, = in turn, is based on the newer RFC 8445 handling. JSEP's reference to = RFC 5245 is a practical consideration that acknowledges that current = deployments of WebRTC implement the older version of ICE. At the same = time, these deployed implementations use a somewhat older version of = draft-ietf-ice-trickle in concert with the older ICE implementation. >=20 > In order to get Cluster 238 published, we need to find some way to = rationalize its references to ICE. At a basic level, the ART Area = Directors do not believe that it makes sense to publish new documents = that refer to an already obsoleted RFC. At the same time, we recognize = that there is value in our specifications being informed by running = code. For WebRTC, the complexity of the system has led us to a point = that we must choose between these principles. Our proposal is to choose = the first, while acknowledging the second. >=20 > This would result in a request to the RFC editor to update all = references to RFC 5245 in the Cluster 238 documents to instead point to = RFC 8445. Documents not yet in the RFC editor queue would be updated = prior to IESG review. We would further request that the RFC editor add = the following text to draft-ietf-rtcweb-overview and = draft-ietf-rtcweb-jsep: >=20 >=20 >> While this specification formally relies on [RFC8445], at the time of = its publication, the majority of WebRTC implementations support the = version of ICE described in [RFC5245], and use a pre-standard version of = the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" = attribute defined in [RFC8445] can be used to detect the version in use = by a remote endpoint and to provide a smooth transition from the older = specification to the newer one. > RFC 8445 would be a normative reference for both documents, while RFC = 5245 would be informative. > There is one more minor complication, in that = draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC = 5245) is intended to be an exhaustive list of the SDP attributes defined = in the documents it lists, and RFC 8445 adds a new "ice2" attribute that = was not present in RFC 5245. For this reason, we would also ask the RFC = Editor to add a new row to the table in = draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows: >=20 >> = +-------------------+---------------------------+-------+-----------+ >> | Name | Notes | Level | Mux = | >> | | | | Category = | >> = +-------------------+---------------------------+-------+-----------+ >> | ice2 | Not Impacted | S | NORMAL = | >> | | | | = | >> = +-------------------+---------------------------+-------+-----------+ >=20 > For clarity, the affected documents are as follows. >=20 > The following documents would be updated to reference RFC 8445 prior = to IESG evaluation: > draft-ietf-clue-datachannel > draft-ietf-clue-signaling > draft-ietf-rtcweb-security > draft-ietf-rtcweb-security-arch >=20 > The following documents would be updated to reference RFC 8445 by the = RFC Editor: > draft-ietf-mmusic-mux-exclusive > draft-ietf-mmusic-sctp-sdp > draft-ietf-rtcweb-alpn > draft-ietf-rtcweb-data-channel > draft-ietf-rtcweb-rtp-usage >=20 > The following documents would be updated to reference RFC 8445 and = have the text proposed above added to them: > draft-ietf-rtcweb-jsep > draft-ietf-rtcweb-overview >=20 > The following document would be updated to reference RFC 8445 by the = RFC Editor, and include a new row for "ice2" in its Section 5.12, as = described above: >=20 > draft-ietf-mmusic-sdp-mux-attributes >=20 > This message is cross-posted to the affected working groups. Because = the issue at hand has impact across several different groups, we ask = that all follow-up discussion take place on = . Thank you. >=20 > /Adam on behalf of the ART Area Directors > ____ > [1] https://www.rfc-editor.org/cluster_info.php?cid=3DC238 = > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_1CAE2495-9FB4-401A-86A6-D79AD3300118 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I object = to this plan. 

It is not merely an issue of which document we point out, and = they are all the same. The problem is the timing of 8445 is not clearly = interoperable with the timing of 5245. ICE relies on both sides to do = sequence things at roughly the same order so that suicided packets open = pinholes in the reverse direction at the right time. The changes in = timing change how this happens and is a problem for the ICE = algorithm. 

This was discussed in the WG, and though not everyone agrees = it is a problem or not, no one has ever provided a convincing argument = that it is not. This is a very substantial change to the on the wire = protocol and at a minimum would need to be reviewed and discussed in the = WG not slipped through in Auth 48 during a one week period in the summer = while everyone is on vacation. We will also need to change other = examples and normative text in drafts like JSEP. 

I would propose that = instead of the parts of specs that use the trickle mechanism purely = reference that part of the new ICE spec that defines the syntax and say = to transfer trickle candidates. 

Cisco has implemented stuff that is = WebRTC 1.0 compliant without this change. These gratuitous changes, = years after the implementation were coded, with no real benefit will = ensure that we are not and will not become compliant with the RFC. It's = unlikely we will upgrade to the new ICE until it has real befits. It is = doubtful Justin will want to implement the 8445 mechanisms of supporting = both new and old ICE. Instead, we will move to say "works with Browser X = version Y or later." We have watched at W3C as it moved to be that = unless chrome does it, it rare that it becomes a standard.  Right = here I am watching how the stuff IETF defines will be less relevant than = the issue of what chrome implements. 


On Aug 22, 2018, at 10:58 AM, = Adam Roach <adam@nostrum.com> wrote:

=20 =20
Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents = dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these documents is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-running complication for this cluster of documents = is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; = and that the mechanism described in RFC 8445 has some  changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most notably, draft-ietf-rtcweb-jsep (which is the core = WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 = published, we need to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a = request to the RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:


While this specification = formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute defined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:


   =
+-------------------+---------------------------+-------+-----------+
   | Name              | Notes                     | Level | Mux       |
   |                   |                           |       | Category  |
   +-------------------+---------------------------+-------+-----------+
   | ice2              | Not Impacted              | S     | NORMAL    |
   |                   |                           |       |           |
   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are = as follows.

The following documents would be updated to = reference RFC 8445 prior to IESG evaluation:

  • draft-ietf-clue-datachannel
  • draft-ietf-clue-signaling
  • draft-ietf-rtcweb-security
  • draft-ietf-rtcweb-security-arch


The following documents would be updated to = reference RFC 8445 by the RFC Editor:

  • draft-ietf-mmusic-mux-exclusive
  • draft-ietf-mmusic-sctp-sdp
  • draft-ietf-rtcweb-alpn
  • draft-ietf-rtcweb-data-channel
  • draft-ietf-rtcweb-rtp-usage


The following documents would be updated to = reference RFC 8445 and have the text proposed above added to them:

  • draft-ietf-rtcweb-jsep
  • draft-ietf-rtcweb-overview


The following document would be updated to = reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Section 5.12, as described above:

  • draft-ietf-mmusic-sdp-mux-attributes


This message is cross-posted to the affected = working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <art@ietf.org>. Thank you.

/Adam on behalf of the ART Area = Directors

____
[1] https://ww= w.rfc-editor.org/cluster_info.php?cid=3DC238

_______________________________________________
clue = mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_1CAE2495-9FB4-401A-86A6-D79AD3300118-- From nobody Thu Sep 6 13:41:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0FF130F43; Thu, 6 Sep 2018 13:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdLrnsGwFy7M; Thu, 6 Sep 2018 13:41:12 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 B85DA130EBC; Thu, 6 Sep 2018 13:41:11 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id q7-v6so10193199uam.12; Thu, 06 Sep 2018 13:41:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8xNvUcTCIpFSP1L9JMhOcpBVxZViIOjRQjBI+dRfD4k=; b=Pe7IYFMjcGr3lEl5jtfj0TP61e4ZXHEvLqFYIMCfyOa7JWWTo/PD2nF1+4ZHNnfGYw ZI+sme10w/9B7ge2UHAfrM1Zb2S0Rtj/bcsWqzfZkqbW2WRI0NGl+tfoyBtYwIHVNZ7o pF+uv1bfYcsDFtNhASmW2dwMpAZmMytOAXKBgCSvOHA9ZdkWsZakUCGsCrZh05DOJDUK AfbsvZXE7zICADABNVmA7frKHB3qNHzggmQar9izC12bdh+x1qcn+ugVXKSYFDoRBzrl z2/iz8qqGljGaJS7z3L0DEfu+Q3vQcwQx311Mzt4eLzzx2hqVZ9hG8jBYfWeLIJoCHk4 GTXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8xNvUcTCIpFSP1L9JMhOcpBVxZViIOjRQjBI+dRfD4k=; b=bEavS/weR1qdtNUz5vTV8/H5aytU+9KuZB8whuIsx5nM4oiqRY+aRfH/8Zm7EHAxJV fIdskZshPTQexh5EEHWVoZvoq/wNioUmaS10hnKfXUtI/VVM5xdJHvHIcMp2QuFdIIxr j1R0LOcJsR9pzBPmg+KGuUEuvFKnQAB8yuEYNP96Yp/FBqNDuT6fOmbkh4BkckvEVI+T EGdSLR8TDTcl34qpMi+8jl78e07ruxmsOPkqrJZtr5Zs2dE6s0wGLPsz91a6w9ypNFFU oyDz15s/2JbiHt/B4ahBmrN8wcnbiq5Miux48U5vh1Akkl5c5f9Z/3XPJeE8ri9lB/ov DBjA== X-Gm-Message-State: APzg51CTwvlrtwwBtapWdKV4m7heizkWRhCiX1nrzVzYqLD4Dj83SSnR F5jHoG4GDig/yvhPxV0YnOotZcLB9h1XzE6kqbnx1Q== X-Google-Smtp-Source: ANB0VdYvR0VpnHFDiUZfwthJ6q2r/qg7yLbCmG67l2pLc/q+pfXxHwUEIe67F78e3HiCZ8JN0fXCJDp4zHfZ6uBnXos= X-Received: by 2002:ab0:4364:: with SMTP id k91-v6mr1886041uak.46.1536266470463; Thu, 06 Sep 2018 13:41:10 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> In-Reply-To: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> From: Bernard Aboba Date: Thu, 6 Sep 2018 13:40:59 -0700 Message-ID: To: Cullen Jennings Cc: Applications and Real-Time Area Discussion , RTCWeb IETF , "clue@ietf.org" , "ice@ietf.org" , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000409ca8057539e9b8" Archived-At: Subject: Re: [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 20:41:16 -0000 --000000000000409ca8057539e9b8 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 6, 2018 at 1:25 PM Cullen Jennings wrote: > > It's unlikely we will upgrade to the new ICE until it has real benefits. > [BA] Do not worry. Since there are limited benefits in 8445, upgrades will be slow to arrive at best, except perhaps if they are bundled with Trickle support. > It is doubtful Justin will want to implement the 8445 mechanisms of > supporting both new and old ICE. > [BA] Yes, the 8445 negotiation mechanism never really made sense (though Trickle negotiation does make sense). Right here I am watching how the stuff IETF defines will be less relevant > than the issue of what chrome implements. > [BA] Implementations have always mattered. What has changed is that the IETF seems to be paying less attention to cost/benefit tradeoffs. > > On Aug 22, 2018, at 10:58 AM, Adam Roach wrote: > > Members of the ART community interested in real-time communications: > > Cluster 238 [1] is a set of inter-related documents dealing with real-time > communications. The bulk of these documents relate to WebRTC, either > directly or indirectly. They also form the underpinnings of CLUE. As of > now, there are 34 documents in the cluster that are not yet published, with > 25 of these already in the RFC Editor's queue. The dependency graph among > these documents is such that the bulk of them can be published as soon as a > specific six of them are handed off to the RFC editor, and we expect this > to happen in the upcoming few months. > > One long-running complication for this cluster of documents is that each > of the documents were developed over the course of seven years, in concert > with implementations, while the ICE protocol itself was undergoing > significant revision. As a consequence, some documents rely (directly or > indirectly) on the older ICE specification (RFC 5245), while some rely on > the newer one (RFC 8445). In some cases, documents refer directly to the > old version and transitively to the new version. > > It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism > described in RFC 8445 has some changes that break backwards compatibility > with the mechanism defined in RFC 5245 (with such behavioral changes > controlled by an SDP attribute, allowing clients to transition from one to > the other). > > Most notably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in > the IETF) refers to directly to RFC 5245, while relying on the behavior > defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is > based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a > practical consideration that acknowledges that current deployments of > WebRTC implement the older version of ICE. At the same time, these deployed > implementations use a somewhat older version of draft-ietf-ice-trickle in > concert with the older ICE implementation. > > In order to get Cluster 238 published, we need to find some way to > rationalize its references to ICE. At a basic level, the ART Area Directors > do not believe that it makes sense to publish new documents that refer to > an already obsoleted RFC. At the same time, we recognize that there is > value in our specifications being informed by running code. For WebRTC, the > complexity of the system has led us to a point that we must choose between > these principles. Our proposal is to choose the first, while acknowledging > the second. > > This would result in a request to the RFC editor to update all references > to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. > Documents not yet in the RFC editor queue would be updated prior to IESG > review. We would further request that the RFC editor add the following text > to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep: > > While this specification formally relies on [RFC8445], at the time of its > publication, the majority of WebRTC implementations support the version of > ICE described in [RFC5245], and use a pre-standard version of the trickle > ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute > defined in [RFC8445] can be used to detect the version in use by a remote > endpoint and to provide a smooth transition from the older specification to > the newer one. > > RFC 8445 would be a normative reference for both documents, while RFC 5245 > would be informative. > > There is one more minor complication, in that > draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) > is intended to be an exhaustive list of the SDP attributes defined in the > documents it lists, and RFC 8445 adds a new "ice2" attribute that was not > present in RFC 5245. For this reason, we would also ask the RFC Editor to > add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section > 5.12, as follows: > > +-------------------+---------------------------+-------+-----------+ > | Name | Notes | Level | Mux | > | | | | Category | > +-------------------+---------------------------+-------+-----------+ > | ice2 | Not Impacted | S | NORMAL | > | | | | | > +-------------------+---------------------------+-------+-----------+ > > > For clarity, the affected documents are as follows. > > The following documents would be updated to reference RFC 8445 prior to > IESG evaluation: > > - draft-ietf-clue-datachannel > - draft-ietf-clue-signaling > - draft-ietf-rtcweb-security > - draft-ietf-rtcweb-security-arch > > > The following documents would be updated to reference RFC 8445 by the RFC > Editor: > > - draft-ietf-mmusic-mux-exclusive > - draft-ietf-mmusic-sctp-sdp > - draft-ietf-rtcweb-alpn > - draft-ietf-rtcweb-data-channel > - draft-ietf-rtcweb-rtp-usage > > > The following documents would be updated to reference RFC 8445 and have > the text proposed above added to them: > > - draft-ietf-rtcweb-jsep > - draft-ietf-rtcweb-overview > > > The following document would be updated to reference RFC 8445 by the RFC > Editor, and include a new row for "ice2" in its Section 5.12, as described > above: > > - draft-ietf-mmusic-sdp-mux-attributes > > > This message is cross-posted to the affected working groups. Because the > issue at hand has impact across several different groups, we ask that all > follow-up discussion take place on . Thank > you. > > /Adam on behalf of the ART Area Directors > > ____ > [1] https://www.rfc-editor.org/cluster_info.php?cid=C238 > _______________________________________________ > > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --000000000000409ca8057539e9b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 6, 2018 at 1:25 PM Cullen Jennings <<= a href=3D"mailto:fluffy@iii.ca">fluffy@iii.ca> wrote:

=C2=A0It's unlikely we will up= grade to the new ICE until it has real benefits.

[BA] Do not worry. Since there = are limited benefits in 8445, upgrades will be slow to arrive at best, exce= pt perhaps if they are bundled with Trickle support.

It is doubtful Justin will want to implement= the 8445 mechanisms of supporting both new and old ICE.

[BA] Yes, the 8445 neg= otiation mechanism never really made sense (though Trickle negotiation does= make sense).=C2=A0

Right here I am watching = how the stuff IETF defines will be less relevant than the issue of what chr= ome implements.=C2=A0

<= div dir=3D"auto">[BA] Implementations have always mattered. What has change= d is that the IETF seems to be paying less attention to cost/benefit tradeo= ffs.



On Aug 22, 2018, at 10:58 = AM, Adam Roach <ad= am@nostrum.com> wrote:

<= div style=3D"word-wrap:break-word">
=20 =20 =20
Members of the ART community interested in real-time communications:

Cluster 238 [1] is a set of inter-related documents dealing with real-time communications. The bulk of these documents relate to WebRTC, either directly or indirectly. They also form the underpinnings of CLUE. As of now, there are 34 documents in the cluster that are not yet published, with 25 of these already in the RFC Editor's queue. The dependency graph among these document= s is such that the bulk of them can be published as soon as a specific six of them are handed off to the RFC editor, and we expect this to happen in the upcoming few months.

One long-runn= ing complication for this cluster of documents is that each of the documents were developed over the course of seven years, in concert with implementations, while the ICE protocol itself was undergoing significant revision. As a consequence, some documents rely (directly or indirectly) on the older ICE specification (RFC 5245), while some rely on the newer one (RFC 8445). In some cases, documents refer directly to the old version and transitively to the new version.

It is noteworthy that RFC 8445 obsoletes RFC 5245; and that the mechanism described in RFC 8445 has some=C2=A0 changes that break backwards compatibility with the mechanism defined in RFC 5245 (with such behavioral changes controlled by an SDP attribute, allowing clients to transition from one to the other).

Most not= ably, draft-ietf-rtcweb-jsep (which is the core WebRTC protocol in the IETF) refers to directly to RFC 5245, while relying on the behavior defined in draft-ietf-ice-trickle; draft-ietf-ice-trickle, in turn, is based on the newer RFC 8445 handling. JSEP's reference to RFC 5245 is a practical consideration that acknowledges that current deployments of WebRTC implement the older version of ICE. At the same time, these deployed implementations use a somewhat older version of draft-ietf-ice-trickle in concert with the older ICE implementation.

In order to get Cluster 238 published, we need = to find some way to rationalize its references to ICE. At a basic level, the ART Area Directors do not believe that it makes sense to publish new documents that refer to an already obsoleted RFC. At the same time, we recognize that there is value in our specifications being informed by running code. For WebRTC, the complexity of the system has led us to a point that we must choose between these principles. Our proposal is to choose the first, while acknowledging the second.

This would result in a request to the= RFC editor to update all references to RFC 5245 in the Cluster 238 documents to instead point to RFC 8445. Documents not yet in the RFC editor queue would be updated prior to IESG review. We would further request that the RFC editor add the following text to draft-ietf-rtcweb-overview and draft-ietf-rtcweb-jsep:


While this specification formally relies on [RFC8445], at the time of its publication, the majority of WebRTC implementations support the version of ICE described in [RFC5245], and use a pre-standard version of the trickle ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute def= ined in [RFC8445] can be used to detect the version in use by a remote endpoint and to provide a smooth transition from the older specification to the newer one.
RFC 8445 would be a normative reference for both documents, while RFC 5245 would be informative.

There is one more minor complication, in that draft-ietf-mmusic-sdp-mux-attributes (which currently points to RFC 5245) is intended to be an exhaustive list of the SDP attributes defined in the documents it lists, and RFC 8445 adds a new "ice2" attribute that was not present in RFC 5245. For = this reason, we would also ask the RFC Editor to add a new row to the table in draft-ietf-mmusic-sdp-mux-attributes section 5.12, as follows:


<= /div> 
   +-------------------+-=
--------------------------+-------+-----------+
   | Name              | Notes                     | Level | Mux       |
   |                   |                           |       | Category  |
   +-------------------+---------------------------+-------+-----------+
   | ice2              | Not Impacted              | S     | NORMAL    |
   |                   |                           |       |           |
   +-------------------+---------------------------+-------+-----------+

For clarity, the affected documents are as follows.

The fo= llowing documents would be updated to reference RFC 8445 prior to IESG evaluation:

  • draft-ietf-clue-datachannel
  • draft-ietf-clue-signaling
  • draft-ietf-rtcweb-security
  • draft-ietf-rtcweb-security-arch


The following documents would be updated to reference RFC 8445 b= y the RFC Editor:

  • draft-ietf-mmusic-mux-exclusive
  • draft-ietf-mmusic-sctp-sdp
  • draft-ietf-rtcweb-alpn
  • draft-ietf-rtcweb-data-channel
  • draft-ietf-rtcweb-rtp-usage


The following documents would be updated to reference RFC 8445 and have the text proposed above added to them:

  • draft-ietf-rtcweb-jsep
  • draft-ietf-rtcweb-overview


The following document would be updated to reference RFC 8445 by the RFC Editor, and include a new row for "ice2" in its Sec= tion 5.12, as described above:

  • draft-ietf-mmusic-sdp-mux-attributes


This message is cross-posted to the affected working groups. Because the issue at hand has impact across several different groups, we ask that all follow-up discussion take place on <art@ietf.org>. Thank you.

/Adam on behalf of the ART Area Directors

____
[1] ht= tps://www.rfc-editor.org/cluster_info.php?cid=3DC238

_______________________________________________
_____________________________________________= __
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000409ca8057539e9b8-- From nobody Thu Sep 6 17:54:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC14E130FE6; Thu, 6 Sep 2018 17:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IFrF4JP06-g; Thu, 6 Sep 2018 17:54:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AB68212F295; Thu, 6 Sep 2018 17:54:16 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w870sDod037951 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Sep 2018 19:54:15 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Cullen Jennings , Applications and Real-Time Area Discussion Cc: RTCWeb IETF , "clue@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> From: Adam Roach Message-ID: Date: Thu, 6 Sep 2018 19:54:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 00:54:24 -0000 On 9/6/18 3:24 PM, Cullen Jennings wrote: > I would propose that instead of the parts of specs that use the > trickle mechanism purely reference that part of the new ICE spec that > defines the syntax and say to transfer trickle candidates. Unfortunately, it's not quite so simple. The mismatch with trickle-ice is only the most obvious problem. In practice, there are a few dozen places where unpublished documents in the cluster refer directly to one version of ICE, and indirectly to another, or indirectly to both. To help wrap our collective minds around this issue, I've put together a dependency graph that shows which Cluster 238 documents refer to which version of ICE. The red lines indicate references (directly or indirectly) to RFC 5245, while the purple lines indicate references to RFC 8445. The thickness of the line indicates how many hops away from ICE the reference is. Dotted lines are informative references. https://trac.ietf.org/trac/art/wiki/c238 To put a finer point on this, it took me a couple of hours to pare this graph down to something that was small enough to look at and actually understand -- there are actually twice as many documents involved in this mess, but including them makes the situation too confusing to even start to get a grip on. Everywhere you see a purple document with a red arrow or vice-versa is a place we need to figure out how to handle this mismatch. You can push the boundaries around, but the count of mismatches is pretty much the same no matter how you do that. On a first order estimation, this is days -- or, more likely, weeks of work. And I'm talking about person-hours, not calendar time. If you can do this, or find someone to step up and do it, then your proposal would be a viable alternative to the one that the ART ADs have proposed. Short of that, I'm not sure how we can do what you want. /a From nobody Fri Sep 7 00:25:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6D130E7C for ; Fri, 7 Sep 2018 00:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.308 X-Spam-Level: X-Spam-Status: No, score=-4.308 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qTrNlAPoT2i for ; Fri, 7 Sep 2018 00:25:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0841286D9 for ; Fri, 7 Sep 2018 00:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536305117; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FkGBDykQ/ya0c1IzjIFgjsVVAsc0Zz2Uq5JoqQAveR0=; b=LNIXG9KzlLieZgUEgSP1c1Vj/8bkD+6Es3FHM6yJTAV3ZVjXufckRjIJGUJpyZXV jwuE4O2rIt3yGAuRPboYpeP1YcYVdMo9ZBso8ERsrhXhsVP82UBBaYudW9uaUMrw UKpxVMoorR9gHcKjp5VmD6n9Qw0VNpechEWctOhRBTM=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-e8-5b9227dc84ff Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.F6.22015.CD7229B5; Fri, 7 Sep 2018 09:25:17 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Sep 2018 09:25:13 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Fri, 7 Sep 2018 09:25:13 +0200 From: Christer Holmberg To: Cullen Jennings , "Applications and Real-Time Area Discussion" CC: RTCWeb IETF , "clue@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: [art] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURh+v3CEVPFpjI0266oWKAGTzsaTkftOA Date: Fri, 7 Sep 2018 07:25:13 +0000 Message-ID: <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> In-Reply-To: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: multipart/alternative; boundary="_000_46E40ED2D2894C0F8C0B82A5980B2692ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsUyM2J7he5d9UnRBstuMVqsuOthsf/UZWaL D+t/MFp8u1BrMXX5YxaLtf/a2R3YPJYs+cnkcfn8R8YApigum5TUnMyy1CJ9uwSujJbdygWX m5grdkyobWA89oOpi5GDQ0LARGLShPIuRk4OIYGjjBIfGvQg7K+MEidbCiHspYwS75Yxg5Sz CVhIdP/TBgmLCCRJTNo9m7GLkYuDWaCDUWL77kOsIDXCAuYS7w6xQdRYSGx/+ZkFwjaSuDVz LSuIzSKgIvF41X8wm1fAXmLdroXsIK1CAnkS9z9LgIQ5Bawk1nQ2sIPYjAJiEt9PrWECsZkF xCVuPZkPZksICEgs2XOeGcIWlXj5+B/YBaIC+hLTLgdAhJUktvRugWpNltj89QYbxFZBiZMz n7BMYBSbhWTqLCRls5CUzQKayiygKbF+lz5EiaLElO6H7BC2hkTrnLlQtrXE/b9PmJHVLGDk WMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGLcHt/zW3cG4+rXjIUYBDkYlHt5ZYpOihVgT y4orcw8xSnAwK4nwMikAhXhTEiurUovy44tKc1KLDzFKc7AoifPqrdoTJSSQnliSmp2aWpBa BJNl4uCUamAs+HJ9+aa/Deu2b7hR8fRH6VkzDYct52MyPzMWJP5btknsgNucS3HLdz/RTXDu 1XjzcbvgljX/vJ0kuHq/LrmY0fZQkLfLu0V+0jK1XOdV24wb6torhN98vNJt+1K4vluea5U3 /+9DNxYa6KzhSHKpNroeqB87K1A4R/AEa7PD7D9OL7S9OpmVWIozEg21mIuKEwEAy+Xg1wIA AA== Archived-At: Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 07:25:32 -0000 --_000_46E40ED2D2894C0F8C0B82A5980B2692ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj4gSSBvYmplY3QgdG8gdGhpcyBwbGFuLg0KPg0KPiBJdCBpcyBub3QgbWVyZWx5IGFu IGlzc3VlIG9mIHdoaWNoIGRvY3VtZW50IHdlIHBvaW50IG91dCwgYW5kIHRoZXkgYXJlIGFsbCB0 aGUgc2FtZS4gVGhlIHByb2JsZW0gaXMgdGhlIHRpbWluZyBvZiA4NDQ1IGlzIG5vdCBjbGVhcmx5 IGludGVyb3BlcmFibGUgd2l0aCB0aGUgdGltaW5nIG9mIDUyNDUuIElDRSByZWxpZXMgb24gYm90 aA0KPiBzaWRlcyB0byBkbyBzZXF1ZW5jZSB0aGluZ3MgYXQgcm91Z2hseSB0aGUgc2FtZSBvcmRl ciBzbyB0aGF0IHN1aWNpZGVkIHBhY2tldHMgb3BlbiBwaW5ob2xlcyBpbiB0aGUgcmV2ZXJzZSBk aXJlY3Rpb24gYXQgdGhlIHJpZ2h0IHRpbWUuIFRoZSBjaGFuZ2VzIGluIHRpbWluZyBjaGFuZ2Ug aG93IHRoaXMgaGFwcGVucyBhbmQgaXMgYSBwcm9ibGVtIGZvciB0aGUgSUNFIGFsZ29yaXRobS4N Cj4NCj4gVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBXRywgYW5kIHRob3VnaCBub3QgZXZlcnlv bmUgYWdyZWVzIGl0IGlzIGEgcHJvYmxlbSBvciBub3QsIG5vIG9uZSBoYXMgZXZlciBwcm92aWRl ZCBhIGNvbnZpbmNpbmcgYXJndW1lbnQgdGhhdCBpdCBpcyBub3QuIFRoaXMgaXMgYSB2ZXJ5IHN1 YnN0YW50aWFsIGNoYW5nZSB0byB0aGUgb24gdGhlIHdpcmUgcHJvdG9jb2wgYW5kIGF0IGEgbWlu aW11bQ0KPiB3b3VsZCBuZWVkIHRvIGJlIHJldmlld2VkIGFuZCBkaXNjdXNzZWQgaW4gdGhlIFdH IG5vdCBzbGlwcGVkIHRocm91Z2ggaW4gQXV0aCA0OCBkdXJpbmcgYSBvbmUgd2VlayBwZXJpb2Qg aW4gdGhlIHN1bW1lciB3aGlsZSBldmVyeW9uZSBpcyBvbiB2YWNhdGlvbi4gV2Ugd2lsbCBhbHNv IG5lZWQgdG8gY2hhbmdlIG90aGVyIGV4YW1wbGVzIGFuZCBub3JtYXRpdmUgdGV4dCBpbiBkcmFm dHMgbGlrZSBKU0VQLg0KDQpXaGF0IG5vcm1hdGl2ZSB0ZXh0IGRvIHlvdSBuZWVkIHRvIGNoYW5n ZSBpbiBKU0VQPw0KDQpJbiBmYWN0LCBJIHdvdWxkIGV2ZW4gY2xhaW0gdGhhdCB0aGUgSlNFUCB0 ZXh0IGlzIG1vcmUgYWxpZ25lZCB3aXRoIDg0NDUgdGhhbiA1MjQ1LiBGb3IgZXhhbXBsZSwgSlNF UCBkb2VzIG5vdCB0YWxrIGFib3V0IGFnZ3Jlc3NpdmUgYW5kIG5vcm1hdGl2ZSBub21pbmF0aW9u LCBvbmx5IGFib3V0IG5vbWluYXRpb24uDQoNCj4gSSB3b3VsZCBwcm9wb3NlIHRoYXQgaW5zdGVh ZCBvZiB0aGUgcGFydHMgb2Ygc3BlY3MgdGhhdCB1c2UgdGhlIHRyaWNrbGUgbWVjaGFuaXNtIHB1 cmVseSByZWZlcmVuY2UgdGhhdCBwYXJ0IG9mIHRoZSBuZXcgSUNFIHNwZWMgdGhhdCBkZWZpbmVz IHRoZSBzeW50YXggYW5kIHNheSB0byB0cmFuc2ZlciB0cmlja2xlIGNhbmRpZGF0ZXMuDQoNCkl0 IGlzIG5vdCBvbmx5IGFib3V0IHRoZSBzeW50YXguIFRoZSB0cmlja2xlIHByb2NlZHVyZXMgYXJl IGJhc2VkIG9uIHByb2NlZHVyZXMgaW4gODQ0NS4NCg0KPiBDaXNjbyBoYXMgaW1wbGVtZW50ZWQg c3R1ZmYgdGhhdCBpcyBXZWJSVEMgMS4wIGNvbXBsaWFudCB3aXRob3V0IHRoaXMgY2hhbmdlLiBU aGVzZSBncmF0dWl0b3VzIGNoYW5nZXMsIHllYXJzIGFmdGVyIHRoZSBpbXBsZW1lbnRhdGlvbiB3 ZXJlIGNvZGVkLCB3aXRoIG5vIHJlYWwgYmVuZWZpdCB3aWxsIGVuc3VyZSB0aGF0IHdlIGFyZSBu b3QNCj4gYW5kIHdpbGwgbm90IGJlY29tZSBjb21wbGlhbnQgd2l0aCB0aGUgUkZDLiBJdCdzIHVu bGlrZWx5IHdlIHdpbGwgdXBncmFkZSB0byB0aGUgbmV3IElDRSB1bnRpbCBpdCBoYXMgcmVhbCBi ZWZpdHMuDQoNClRoZSBtYWluIHJlYXNvbiB3ZSBkaWQgODQ0NSB3YXMgYmVjYXVzZSBwZW9wbGUg aGFkIGlkZW50aWZpZWQgaXNzdWVzIHdpdGggNTI0NS4gVGhlIHdvcmsgd2FzIGRyaXZlbiBtb3N0 bHkgYnkgdGhlIFdlYlJUQyBjb21tdW5pdHksIGluY2x1ZGluZyB5b3Vyc2VsZiBhbmQgdGhlIENo cm9tZSBwZW9wbGUgKG9yLCBhdCBsZWFzdCB0aGUgR29vZ2xlIHBlb3BsZSksIGFuZCBvbmUgb2Yg dGhlIHJlYXNvbiBpdCB0b29rIHRpbWUgdG8gZmluYWxpemUgODQ0NSB3YXMgYmVjYXVzZSB5b3Ug KGFtb25nIG90aGVycykgd2FudGVkIHRvIG1ha2Ugc3VyZSB3ZSBnZXQgdGhpbmdzIHJpZ2h0IChi eSBtYWtpbmcgbmV0d29yayBtZWFzdXJlbWVudHMgZXRjKS4gQXJlIHlvdSBub3cgc2F5aW5nIGFs bCB0aG9zZSBjaGFuZ2VzIGJyaW5nIG5vIGJlbmVmaXQ/IERpZCB3ZSBhbGwgd2FzdGUgb3VyIHRp bWU/DQoNCj4gSXQgaXMgZG91YnRmdWwgSnVzdGluIHdpbGwgd2FudCB0byBpbXBsZW1lbnQgdGhl IDg0NDUgbWVjaGFuaXNtcyBvZiBzdXBwb3J0aW5nIGJvdGggbmV3IGFuZCBvbGQgSUNFLiBJbnN0 ZWFkLCB3ZSB3aWxsIG1vdmUgdG8gc2F5ICJ3b3JrcyB3aXRoIEJyb3dzZXIgWCB2ZXJzaW9uIFkg b3IgbGF0ZXIuIiBXZSBoYXZlIHdhdGNoZWQgYXQgVzNDIGFzIGl0IG1vdmVkIHRvIGJlIHRoYXQg dW5sZXNzIGNocm9tZSBkb2VzIGl0LCBpdCByYXJlIHRoYXQgaXQgYmVjb21lcyBhIHN0YW5kYXJk Lg0KPiBSaWdodCBoZXJlIEkgYW0gd2F0Y2hpbmcgaG93IHRoZSBzdHVmZiBJRVRGIGRlZmluZXMg d2lsbCBiZSBsZXNzIHJlbGV2YW50IHRoYW4gdGhlIGlzc3VlIG9mIHdoYXQgY2hyb21lIGltcGxl bWVudHMuDQoNCldoYXQgZXhhY3RseSB3b3VsZCBKdXN0aW4gaGF2ZSB0byBjaGFuZ2U/DQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCk9uIEF1ZyAyMiwgMjAxOCwgYXQgMTA6NTggQU0s IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb208bWFpbHRvOmFkYW1Abm9zdHJ1bS5jb20+PiB3 cm90ZToNCg0KTWVtYmVycyBvZiB0aGUgQVJUIGNvbW11bml0eSBpbnRlcmVzdGVkIGluIHJlYWwt dGltZSBjb21tdW5pY2F0aW9uczoNCkNsdXN0ZXIgMjM4IFsxXSBpcyBhIHNldCBvZiBpbnRlci1y ZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1lIGNvbW11bmljYXRpb25zLiBU aGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdlYlJUQywgZWl0aGVyIGRpcmVj dGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1bmRlcnBpbm5pbmdzIG9mIENM VUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBpbiB0aGUgY2x1c3RlciB0aGF0 IGFyZSBub3QgeWV0IHB1Ymxpc2hlZCwgd2l0aCAyNSBvZiB0aGVzZSBhbHJlYWR5IGluIHRoZSBS RkMgRWRpdG9yJ3MgcXVldWUuIFRoZSBkZXBlbmRlbmN5IGdyYXBoIGFtb25nIHRoZXNlIGRvY3Vt ZW50cyBpcyBzdWNoIHRoYXQgdGhlIGJ1bGsgb2YgdGhlbSBjYW4gYmUgcHVibGlzaGVkIGFzIHNv b24gYXMgYSBzcGVjaWZpYyBzaXggb2YgdGhlbSBhcmUgaGFuZGVkIG9mZiB0byB0aGUgUkZDIGVk aXRvciwgYW5kIHdlIGV4cGVjdCB0aGlzIHRvIGhhcHBlbiBpbiB0aGUgdXBjb21pbmcgZmV3IG1v bnRocy4NCk9uZSBsb25nLXJ1bm5pbmcgY29tcGxpY2F0aW9uIGZvciB0aGlzIGNsdXN0ZXIgb2Yg ZG9jdW1lbnRzIGlzIHRoYXQgZWFjaCBvZiB0aGUgZG9jdW1lbnRzIHdlcmUgZGV2ZWxvcGVkIG92 ZXIgdGhlIGNvdXJzZSBvZiBzZXZlbiB5ZWFycywgaW4gY29uY2VydCB3aXRoIGltcGxlbWVudGF0 aW9ucywgd2hpbGUgdGhlIElDRSBwcm90b2NvbCBpdHNlbGYgd2FzIHVuZGVyZ29pbmcgc2lnbmlm aWNhbnQgcmV2aXNpb24uIEFzIGEgY29uc2VxdWVuY2UsIHNvbWUgZG9jdW1lbnRzIHJlbHkgKGRp cmVjdGx5IG9yIGluZGlyZWN0bHkpIG9uIHRoZSBvbGRlciBJQ0Ugc3BlY2lmaWNhdGlvbiAoUkZD IDUyNDUpLCB3aGlsZSBzb21lIHJlbHkgb24gdGhlIG5ld2VyIG9uZSAoUkZDIDg0NDUpLiBJbiBz b21lIGNhc2VzLCBkb2N1bWVudHMgcmVmZXIgZGlyZWN0bHkgdG8gdGhlIG9sZCB2ZXJzaW9uIGFu ZCB0cmFuc2l0aXZlbHkgdG8gdGhlIG5ldyB2ZXJzaW9uLg0KSXQgaXMgbm90ZXdvcnRoeSB0aGF0 IFJGQyA4NDQ1IG9ic29sZXRlcyBSRkMgNTI0NTsgYW5kIHRoYXQgdGhlIG1lY2hhbmlzbSBkZXNj cmliZWQgaW4gUkZDIDg0NDUgaGFzIHNvbWUgIGNoYW5nZXMgdGhhdCBicmVhayBiYWNrd2FyZHMg Y29tcGF0aWJpbGl0eSB3aXRoIHRoZSBtZWNoYW5pc20gZGVmaW5lZCBpbiBSRkMgNTI0NSAod2l0 aCBzdWNoIGJlaGF2aW9yYWwgY2hhbmdlcyBjb250cm9sbGVkIGJ5IGFuIFNEUCBhdHRyaWJ1dGUs IGFsbG93aW5nIGNsaWVudHMgdG8gdHJhbnNpdGlvbiBmcm9tIG9uZSB0byB0aGUgb3RoZXIpLg0K TW9zdCBub3RhYmx5LCBkcmFmdC1pZXRmLXJ0Y3dlYi1qc2VwICh3aGljaCBpcyB0aGUgY29yZSBX ZWJSVEMgcHJvdG9jb2wgaW4gdGhlIElFVEYpIHJlZmVycyB0byBkaXJlY3RseSB0byBSRkMgNTI0 NSwgd2hpbGUgcmVseWluZyBvbiB0aGUgYmVoYXZpb3IgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWlj ZS10cmlja2xlOyBkcmFmdC1pZXRmLWljZS10cmlja2xlLCBpbiB0dXJuLCBpcyBiYXNlZCBvbiB0 aGUgbmV3ZXIgUkZDIDg0NDUgaGFuZGxpbmcuIEpTRVAncyByZWZlcmVuY2UgdG8gUkZDIDUyNDUg aXMgYSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbiB0aGF0IGFja25vd2xlZGdlcyB0aGF0IGN1cnJl bnQgZGVwbG95bWVudHMgb2YgV2ViUlRDIGltcGxlbWVudCB0aGUgb2xkZXIgdmVyc2lvbiBvZiBJ Q0UuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXNlIGRlcGxveWVkIGltcGxlbWVudGF0aW9ucyB1c2Ug YSBzb21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUgaW4gY29u Y2VydCB3aXRoIHRoZSBvbGRlciBJQ0UgaW1wbGVtZW50YXRpb24uDQpJbiBvcmRlciB0byBnZXQg Q2x1c3RlciAyMzggcHVibGlzaGVkLCB3ZSBuZWVkIHRvIGZpbmQgc29tZSB3YXkgdG8gcmF0aW9u YWxpemUgaXRzIHJlZmVyZW5jZXMgdG8gSUNFLiBBdCBhIGJhc2ljIGxldmVsLCB0aGUgQVJUIEFy ZWEgRGlyZWN0b3JzIGRvIG5vdCBiZWxpZXZlIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gcHVibGlz aCBuZXcgZG9jdW1lbnRzIHRoYXQgcmVmZXIgdG8gYW4gYWxyZWFkeSBvYnNvbGV0ZWQgUkZDLiBB dCB0aGUgc2FtZSB0aW1lLCB3ZSByZWNvZ25pemUgdGhhdCB0aGVyZSBpcyB2YWx1ZSBpbiBvdXIg c3BlY2lmaWNhdGlvbnMgYmVpbmcgaW5mb3JtZWQgYnkgcnVubmluZyBjb2RlLiBGb3IgV2ViUlRD LCB0aGUgY29tcGxleGl0eSBvZiB0aGUgc3lzdGVtIGhhcyBsZWQgdXMgdG8gYSBwb2ludCB0aGF0 IHdlIG11c3QgY2hvb3NlIGJldHdlZW4gdGhlc2UgcHJpbmNpcGxlcy4gT3VyIHByb3Bvc2FsIGlz IHRvIGNob29zZSB0aGUgZmlyc3QsIHdoaWxlIGFja25vd2xlZGdpbmcgdGhlIHNlY29uZC4NClRo aXMgd291bGQgcmVzdWx0IGluIGEgcmVxdWVzdCB0byB0aGUgUkZDIGVkaXRvciB0byB1cGRhdGUg YWxsIHJlZmVyZW5jZXMgdG8gUkZDIDUyNDUgaW4gdGhlIENsdXN0ZXIgMjM4IGRvY3VtZW50cyB0 byBpbnN0ZWFkIHBvaW50IHRvIFJGQyA4NDQ1LiBEb2N1bWVudHMgbm90IHlldCBpbiB0aGUgUkZD IGVkaXRvciBxdWV1ZSB3b3VsZCBiZSB1cGRhdGVkIHByaW9yIHRvIElFU0cgcmV2aWV3LiBXZSB3 b3VsZCBmdXJ0aGVyIHJlcXVlc3QgdGhhdCB0aGUgUkZDIGVkaXRvciBhZGQgdGhlIGZvbGxvd2lu ZyB0ZXh0IHRvIGRyYWZ0LWlldGYtcnRjd2ViLW92ZXJ2aWV3IGFuZCBkcmFmdC1pZXRmLXJ0Y3dl Yi1qc2VwOg0KDQpXaGlsZSB0aGlzIHNwZWNpZmljYXRpb24gZm9ybWFsbHkgcmVsaWVzIG9uIFtS RkM4NDQ1XSwgYXQgdGhlIHRpbWUgb2YgaXRzIHB1YmxpY2F0aW9uLCB0aGUgbWFqb3JpdHkgb2Yg V2ViUlRDIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IHRoZSB2ZXJzaW9uIG9mIElDRSBkZXNjcmli ZWQgaW4gW1JGQzUyNDVdLCBhbmQgdXNlIGEgcHJlLXN0YW5kYXJkIHZlcnNpb24gb2YgdGhlIHRy aWNrbGUgaWNlIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gW1JGQ1hYWFhdLiBUaGUgdXNlIG9mIHRo ZSAiaWNlMiIgYXR0cmlidXRlIGRlZmluZWQgaW4gW1JGQzg0NDVdIGNhbiBiZSB1c2VkIHRvIGRl dGVjdCB0aGUgdmVyc2lvbiBpbiB1c2UgYnkgYSByZW1vdGUgZW5kcG9pbnQgYW5kIHRvIHByb3Zp ZGUgYSBzbW9vdGggdHJhbnNpdGlvbiBmcm9tIHRoZSBvbGRlciBzcGVjaWZpY2F0aW9uIHRvIHRo ZSBuZXdlciBvbmUuDQpSRkMgODQ0NSB3b3VsZCBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgZm9y IGJvdGggZG9jdW1lbnRzLCB3aGlsZSBSRkMgNTI0NSB3b3VsZCBiZSBpbmZvcm1hdGl2ZS4NClRo ZXJlIGlzIG9uZSBtb3JlIG1pbm9yIGNvbXBsaWNhdGlvbiwgaW4gdGhhdCBkcmFmdC1pZXRmLW1t dXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgKHdoaWNoIGN1cnJlbnRseSBwb2ludHMgdG8gUkZDIDUy NDUpIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB0aGUgU0RQIGF0dHJp YnV0ZXMgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnRzIGl0IGxpc3RzLCBhbmQgUkZDIDg0NDUgYWRk cyBhIG5ldyAiaWNlMiIgYXR0cmlidXRlIHRoYXQgd2FzIG5vdCBwcmVzZW50IGluIFJGQyA1MjQ1 LiBGb3IgdGhpcyByZWFzb24sIHdlIHdvdWxkIGFsc28gYXNrIHRoZSBSRkMgRWRpdG9yIHRvIGFk ZCBhIG5ldyByb3cgdG8gdGhlIHRhYmxlIGluIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0 cmlidXRlcyBzZWN0aW9uIDUuMTIsIGFzIGZvbGxvd3M6DQoNCg0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0rDQoN CiAgIHwgTmFtZSAgICAgICAgICAgICAgfCBOb3RlcyAgICAgICAgICAgICAgICAgICAgIHwgTGV2 ZWwgfCBNdXggICAgICAgfA0KDQogICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgIHwgQ2F0ZWdvcnkgIHwNCg0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0rDQoN CiAgIHwgaWNlMiAgICAgICAgICAgICAgfCBOb3QgSW1wYWN0ZWQgICAgICAgICAgICAgIHwgUyAg ICAgfCBOT1JNQUwgICAgfA0KDQogICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgIHwNCg0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLS0tLS0rDQoN CkZvciBjbGFyaXR5LCB0aGUgYWZmZWN0ZWQgZG9jdW1lbnRzIGFyZSBhcyBmb2xsb3dzLg0KVGhl IGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0 NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOg0KDQogICogICBkcmFmdC1pZXRmLWNsdWUtZGF0 YWNoYW5uZWwNCiAgKiAgIGRyYWZ0LWlldGYtY2x1ZS1zaWduYWxpbmcNCiAgKiAgIGRyYWZ0LWll dGYtcnRjd2ViLXNlY3VyaXR5DQogICogICBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNo DQoNClRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNl IFJGQyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yOg0KDQogICogICBkcmFmdC1pZXRmLW1tdXNpYy1t dXgtZXhjbHVzaXZlDQogICogICBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcA0KICAqICAgZHJh ZnQtaWV0Zi1ydGN3ZWItYWxwbg0KICAqICAgZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVs DQogICogICBkcmFmdC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UNCg0KVGhlIGZvbGxvd2luZyBkb2N1 bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byByZWZlcmVuY2UgUkZDIDg0NDUgYW5kIGhhdmUgdGhl IHRleHQgcHJvcG9zZWQgYWJvdmUgYWRkZWQgdG8gdGhlbToNCg0KICAqICAgZHJhZnQtaWV0Zi1y dGN3ZWItanNlcA0KICAqICAgZHJhZnQtaWV0Zi1ydGN3ZWItb3ZlcnZpZXcNCg0KVGhlIGZvbGxv d2luZyBkb2N1bWVudCB3b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0 aGUgUkZDIEVkaXRvciwgYW5kIGluY2x1ZGUgYSBuZXcgcm93IGZvciAiaWNlMiIgaW4gaXRzIFNl Y3Rpb24gNS4xMiwgYXMgZGVzY3JpYmVkIGFib3ZlOg0KDQogICogICBkcmFmdC1pZXRmLW1tdXNp Yy1zZHAtbXV4LWF0dHJpYnV0ZXMNCg0KVGhpcyBtZXNzYWdlIGlzIGNyb3NzLXBvc3RlZCB0byB0 aGUgYWZmZWN0ZWQgd29ya2luZyBncm91cHMuIEJlY2F1c2UgdGhlIGlzc3VlIGF0IGhhbmQgaGFz IGltcGFjdCBhY3Jvc3Mgc2V2ZXJhbCBkaWZmZXJlbnQgZ3JvdXBzLCB3ZSBhc2sgdGhhdCBhbGwg Zm9sbG93LXVwIGRpc2N1c3Npb24gdGFrZSBwbGFjZSBvbiA8YXJ0QGlldGYub3JnPjxtYWlsdG86 YXJ0QGlldGYub3JnPi4gVGhhbmsgeW91Lg0KL0FkYW0gb24gYmVoYWxmIG9mIHRoZSBBUlQgQXJl YSBEaXJlY3RvcnMNCl9fX18NClsxXSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9jbHVzdGVy X2luZm8ucGhwP2NpZD1DMjM4DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K DQo= --_000_46E40ED2D2894C0F8C0B82A5980B2692ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <59185D9569DF284781A950EA028BBAAF@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjk3OTA0MDE7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjE5MjMxNTM2NzI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4 MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTE0OTYzNzg2ODsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTAxOTE1Mzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTg5NzQ2NjUwNzsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODkxODU0OTg0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3 Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjE5NTczMzA0 MTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03MDc2MjYxMjY7fQ0KQGxpc3QgbDM6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEkgb2JqZWN0IHRv IHRoaXMgcGxhbi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IEl0IGlzIG5vdCBtZXJlbHkgYW4gaXNzdWUgb2Ygd2hpY2ggZG9j dW1lbnQgd2UgcG9pbnQgb3V0LCBhbmQgdGhleSBhcmUgYWxsIHRoZSBzYW1lLg0KPC9zcGFuPlRo ZSBwcm9ibGVtIGlzIHRoZSB0aW1pbmcgb2YgODQ0NSBpcyBub3QgY2xlYXJseSBpbnRlcm9wZXJh YmxlIHdpdGggdGhlIHRpbWluZyBvZiA1MjQ1LiBJQ0UgcmVsaWVzIG9uIGJvdGg8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+c2lkZXMgdG8gZG8gc2VxdWVuY2UgdGhpbmdzIGF0IHJvdWdo bHkgdGhlIHNhbWUgb3JkZXIgc28gdGhhdCBzdWljaWRlZCBwYWNrZXRzIG9wZW4gcGluaG9sZXMg aW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uIGF0IHRoZSByaWdodCB0aW1lLg0KPC9zcGFuPlRoZSBj aGFuZ2VzIGluIHRpbWluZyBjaGFuZ2UgaG93IHRoaXMgaGFwcGVucyBhbmQgaXMgYSBwcm9ibGVt IGZvciB0aGUgSUNFIGFsZ29yaXRobS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgVGhpcyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBXRywgYW5k IHRob3VnaCBub3QgZXZlcnlvbmUgYWdyZWVzIGl0IGlzIGEgcHJvYmxlbSBvciBub3QsIG5vIG9u ZSBoYXMgZXZlciBwcm92aWRlZCBhIGNvbnZpbmNpbmcgYXJndW1lbnQgdGhhdCBpdCBpcyBub3Qu DQo8L3NwYW4+VGhpcyBpcyBhIHZlcnkgc3Vic3RhbnRpYWwgY2hhbmdlIHRvIHRoZSBvbiB0aGUg d2lyZSBwcm90b2NvbCBhbmQgYXQgYSBtaW5pbXVtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPndvdWxkIG5lZWQgdG8gYmUgcmV2aWV3ZWQgYW5kIGRpc2N1c3NlZCBpbiB0aGUgV0cgbm90 IHNsaXBwZWQgdGhyb3VnaCBpbiBBdXRoIDQ4IGR1cmluZyBhIG9uZSB3ZWVrIHBlcmlvZCBpbiB0 aGUgc3VtbWVyIHdoaWxlIGV2ZXJ5b25lIGlzIG9uIHZhY2F0aW9uLg0KPC9zcGFuPldlIHdpbGwg YWxzbyBuZWVkIHRvIGNoYW5nZSBvdGhlciBleGFtcGxlcyBhbmQgbm9ybWF0aXZlIHRleHQgaW4g ZHJhZnRzIGxpa2UgSlNFUC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgbm9ybWF0aXZlIHRleHQgZG8geW91IG5lZWQg dG8gY2hhbmdlIGluIEpTRVA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBmYWN0LCBJIHdvdWxkIGV2 ZW4gY2xhaW0gdGhhdCB0aGUgSlNFUCB0ZXh0IGlzIG1vcmUgYWxpZ25lZCB3aXRoIDg0NDUgdGhh biA1MjQ1LiBGb3IgZXhhbXBsZSwgSlNFUCBkb2VzIG5vdCB0YWxrIGFib3V0IGFnZ3Jlc3NpdmUg YW5kIG5vcm1hdGl2ZSBub21pbmF0aW9uLCBvbmx5IGFib3V0IG5vbWluYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7IEkgd291bGQgcHJvcG9zZSB0aGF0IGluc3Rl YWQgb2YgdGhlIHBhcnRzIG9mIHNwZWNzIHRoYXQgdXNlIHRoZSB0cmlja2xlIG1lY2hhbmlzbSBw dXJlbHkgcmVmZXJlbmNlIHRoYXQgcGFydCBvZiB0aGUgbmV3IElDRSBzcGVjIHRoYXQgZGVmaW5l cyB0aGUgc3ludGF4IGFuZCBzYXkgdG8gdHJhbnNmZXIgdHJpY2tsZSBjYW5kaWRhdGVzLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SXQgaXMgbm90IG9ubHkgYWJvdXQgdGhlIHN5bnRheC4gVGhl IHRyaWNrbGUgcHJvY2VkdXJlcyBhcmUgYmFzZWQgb24gcHJvY2VkdXJlcyBpbiA4NDQ1LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBDaXNjbyBo YXMgaW1wbGVtZW50ZWQgc3R1ZmYgdGhhdCBpcyBXZWJSVEMgMS4wIGNvbXBsaWFudCB3aXRob3V0 IHRoaXMgY2hhbmdlLg0KPC9zcGFuPlRoZXNlIGdyYXR1aXRvdXMgY2hhbmdlcywgeWVhcnMgYWZ0 ZXIgdGhlIGltcGxlbWVudGF0aW9uIHdlcmUgY29kZWQsIHdpdGggbm8gcmVhbCBiZW5lZml0IHdp bGwgZW5zdXJlIHRoYXQgd2UgYXJlIG5vdA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PmFuZCB3aWxsIG5vdCBiZWNvbWUgY29tcGxpYW50IHdpdGggdGhlIFJGQy4NCjwvc3Bhbj5JdCdz IHVubGlrZWx5IHdlIHdpbGwgdXBncmFkZSB0byB0aGUgbmV3IElDRSB1bnRpbCBpdCBoYXMgcmVh bCBiZWZpdHMuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgbWFpbiByZWFzb24gd2UgZGlkIDg0NDUgd2FzIGJlY2F1c2UgcGVvcGxlIGhhZCBpZGVudGlm aWVkIGlzc3VlcyB3aXRoIDUyNDUuIFRoZSB3b3JrIHdhcyBkcml2ZW4gbW9zdGx5IGJ5IHRoZSBX ZWJSVEMgY29tbXVuaXR5LCBpbmNsdWRpbmcgeW91cnNlbGYgYW5kIHRoZSBDaHJvbWUgcGVvcGxl IChvciwgYXQgbGVhc3QgdGhlIEdvb2dsZSBwZW9wbGUpLCBhbmQgb25lIG9mDQogdGhlIHJlYXNv biBpdCB0b29rIHRpbWUgdG8gZmluYWxpemUgODQ0NSB3YXMgYmVjYXVzZSB5b3UgKGFtb25nIG90 aGVycykgd2FudGVkIHRvIG1ha2Ugc3VyZSB3ZSBnZXQgdGhpbmdzIHJpZ2h0IChieSBtYWtpbmcg bmV0d29yayBtZWFzdXJlbWVudHMgZXRjKS4gQXJlIHlvdSBub3cgc2F5aW5nIGFsbCB0aG9zZSBj aGFuZ2VzIGJyaW5nIG5vIGJlbmVmaXQ/IERpZCB3ZSBhbGwgd2FzdGUgb3VyIHRpbWU/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7IEl0IGlzIGRvdWJ0ZnVsIEp1c3RpbiB3aWxsIHdhbnQgdG8gaW1w bGVtZW50IHRoZSA4NDQ1IG1lY2hhbmlzbXMgb2Ygc3VwcG9ydGluZyBib3RoIG5ldyBhbmQgb2xk IElDRS4NCjwvc3Bhbj5JbnN0ZWFkLCB3ZSB3aWxsIG1vdmUgdG8gc2F5ICZxdW90O3dvcmtzIHdp dGggQnJvd3NlciBYIHZlcnNpb24gWSBvciBsYXRlci4mcXVvdDsgV2UgaGF2ZSB3YXRjaGVkIGF0 IFczQyBhcyBpdCBtb3ZlZCB0byBiZSB0aGF0IHVubGVzcyBjaHJvbWUgZG9lcyBpdCwgaXQgcmFy ZSB0aGF0IGl0IGJlY29tZXMgYSBzdGFuZGFyZC4gJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPlJpZ2h0IGhlcmUgSSBhbSB3YXRjaGluZyBob3cgdGhlIHN0dWZmIElFVEYgZGVm aW5lcyB3aWxsIGJlIGxlc3MgcmVsZXZhbnQgdGhhbiB0aGUgaXNzdWUgb2Ygd2hhdCBjaHJvbWUg aW1wbGVtZW50cy4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+V2hhdCBleGFjdGx5IHdvdWxkIEp1c3RpbiBoYXZlIHRvIGNo YW5nZT8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNo cmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBBdWcgMjIs IDIwMTgsIGF0IDEwOjU4IEFNLCBBZGFtIFJvYWNoICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OmFkYW1Abm9zdHJ1bS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5hZGFtQG5vc3RydW0uY29tPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1lbWJlcnMgb2YgdGhlIEFSVCBjb21tdW5pdHkgaW50ZXJlc3RlZCBpbiByZWFsLXRpbWUg Y29tbXVuaWNhdGlvbnM6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Q2x1c3RlciAyMzggWzFdIGlzIGEgc2V0IG9mIGludGVyLXJlbGF0ZWQgZG9jdW1lbnRzIGRlYWxp bmcgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbnMuIFRoZSBidWxrIG9mIHRoZXNlIGRvY3Vt ZW50cyByZWxhdGUgdG8gV2ViUlRDLCBlaXRoZXIgZGlyZWN0bHkgb3IgaW5kaXJlY3RseS4gVGhl eSBhbHNvDQogZm9ybSB0aGUgdW5kZXJwaW5uaW5ncyBvZiBDTFVFLiBBcyBvZiBub3csIHRoZXJl IGFyZSAzNCBkb2N1bWVudHMgaW4gdGhlIGNsdXN0ZXIgdGhhdCBhcmUgbm90IHlldCBwdWJsaXNo ZWQsIHdpdGggMjUgb2YgdGhlc2UgYWxyZWFkeSBpbiB0aGUgUkZDIEVkaXRvcidzIHF1ZXVlLiBU aGUgZGVwZW5kZW5jeSBncmFwaCBhbW9uZyB0aGVzZSBkb2N1bWVudHMgaXMgc3VjaCB0aGF0IHRo ZSBidWxrIG9mIHRoZW0gY2FuIGJlIHB1Ymxpc2hlZCBhcyBzb29uDQogYXMgYSBzcGVjaWZpYyBz aXggb2YgdGhlbSBhcmUgaGFuZGVkIG9mZiB0byB0aGUgUkZDIGVkaXRvciwgYW5kIHdlIGV4cGVj dCB0aGlzIHRvIGhhcHBlbiBpbiB0aGUgdXBjb21pbmcgZmV3IG1vbnRocy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T25lIGxvbmctcnVubmluZyBjb21wbGljYXRpb24g Zm9yIHRoaXMgY2x1c3RlciBvZiBkb2N1bWVudHMgaXMgdGhhdCBlYWNoIG9mIHRoZSBkb2N1bWVu dHMgd2VyZSBkZXZlbG9wZWQgb3ZlciB0aGUgY291cnNlIG9mIHNldmVuIHllYXJzLCBpbiBjb25j ZXJ0IHdpdGggaW1wbGVtZW50YXRpb25zLCB3aGlsZSB0aGUNCiBJQ0UgcHJvdG9jb2wgaXRzZWxm IHdhcyB1bmRlcmdvaW5nIHNpZ25pZmljYW50IHJldmlzaW9uLiBBcyBhIGNvbnNlcXVlbmNlLCBz b21lIGRvY3VtZW50cyByZWx5IChkaXJlY3RseSBvciBpbmRpcmVjdGx5KSBvbiB0aGUgb2xkZXIg SUNFIHNwZWNpZmljYXRpb24gKFJGQyA1MjQ1KSwgd2hpbGUgc29tZSByZWx5IG9uIHRoZSBuZXdl ciBvbmUgKFJGQyA4NDQ1KS4gSW4gc29tZSBjYXNlcywgZG9jdW1lbnRzIHJlZmVyIGRpcmVjdGx5 IHRvIHRoZSBvbGQNCiB2ZXJzaW9uIGFuZCB0cmFuc2l0aXZlbHkgdG8gdGhlIG5ldyB2ZXJzaW9u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyBub3Rld29ydGh5 IHRoYXQgUkZDIDg0NDUgb2Jzb2xldGVzIFJGQyA1MjQ1OyBhbmQgdGhhdCB0aGUgbWVjaGFuaXNt IGRlc2NyaWJlZCBpbiBSRkMgODQ0NSBoYXMgc29tZSZuYnNwOyBjaGFuZ2VzIHRoYXQgYnJlYWsg YmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4NCiBS RkMgNTI0NSAod2l0aCBzdWNoIGJlaGF2aW9yYWwgY2hhbmdlcyBjb250cm9sbGVkIGJ5IGFuIFNE UCBhdHRyaWJ1dGUsIGFsbG93aW5nIGNsaWVudHMgdG8gdHJhbnNpdGlvbiBmcm9tIG9uZSB0byB0 aGUgb3RoZXIpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Nb3N0IG5v dGFibHksIGRyYWZ0LWlldGYtcnRjd2ViLWpzZXAgKHdoaWNoIGlzIHRoZSBjb3JlIFdlYlJUQyBw cm90b2NvbCBpbiB0aGUgSUVURikgcmVmZXJzIHRvIGRpcmVjdGx5IHRvIFJGQyA1MjQ1LCB3aGls ZSByZWx5aW5nIG9uIHRoZSBiZWhhdmlvciBkZWZpbmVkIGluIGRyYWZ0LWlldGYtaWNlLXRyaWNr bGU7DQogZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSwgaW4gdHVybiwgaXMgYmFzZWQgb24gdGhlIG5l d2VyIFJGQyA4NDQ1IGhhbmRsaW5nLiBKU0VQJ3MgcmVmZXJlbmNlIHRvIFJGQyA1MjQ1IGlzIGEg cHJhY3RpY2FsIGNvbnNpZGVyYXRpb24gdGhhdCBhY2tub3dsZWRnZXMgdGhhdCBjdXJyZW50IGRl cGxveW1lbnRzIG9mIFdlYlJUQyBpbXBsZW1lbnQgdGhlIG9sZGVyIHZlcnNpb24gb2YgSUNFLiBB dCB0aGUgc2FtZSB0aW1lLCB0aGVzZSBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbnMNCiB1c2UgYSBz b21ld2hhdCBvbGRlciB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUgaW4gY29uY2Vy dCB3aXRoIHRoZSBvbGRlciBJQ0UgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkluIG9yZGVyIHRvIGdldCBDbHVzdGVyIDIzOCBwdWJsaXNoZWQs IHdlIG5lZWQgdG8gZmluZCBzb21lIHdheSB0byByYXRpb25hbGl6ZSBpdHMgcmVmZXJlbmNlcyB0 byBJQ0UuIEF0IGEgYmFzaWMgbGV2ZWwsIHRoZSBBUlQgQXJlYSBEaXJlY3RvcnMgZG8gbm90IGJl bGlldmUgdGhhdCBpdCBtYWtlcyBzZW5zZQ0KIHRvIHB1Ymxpc2ggbmV3IGRvY3VtZW50cyB0aGF0 IHJlZmVyIHRvIGFuIGFscmVhZHkgb2Jzb2xldGVkIFJGQy4gQXQgdGhlIHNhbWUgdGltZSwgd2Ug cmVjb2duaXplIHRoYXQgdGhlcmUgaXMgdmFsdWUgaW4gb3VyIHNwZWNpZmljYXRpb25zIGJlaW5n IGluZm9ybWVkIGJ5IHJ1bm5pbmcgY29kZS4gRm9yIFdlYlJUQywgdGhlIGNvbXBsZXhpdHkgb2Yg dGhlIHN5c3RlbSBoYXMgbGVkIHVzIHRvIGEgcG9pbnQgdGhhdCB3ZSBtdXN0IGNob29zZSBiZXR3 ZWVuDQogdGhlc2UgcHJpbmNpcGxlcy4gT3VyIHByb3Bvc2FsIGlzIHRvIGNob29zZSB0aGUgZmly c3QsIHdoaWxlIGFja25vd2xlZGdpbmcgdGhlIHNlY29uZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGhpcyB3b3VsZCByZXN1bHQgaW4gYSByZXF1ZXN0IHRvIHRoZSBS RkMgZWRpdG9yIHRvIHVwZGF0ZSBhbGwgcmVmZXJlbmNlcyB0byBSRkMgNTI0NSBpbiB0aGUgQ2x1 c3RlciAyMzggZG9jdW1lbnRzIHRvIGluc3RlYWQgcG9pbnQgdG8gUkZDIDg0NDUuIERvY3VtZW50 cyBub3QgeWV0IGluIHRoZSBSRkMgZWRpdG9yDQogcXVldWUgd291bGQgYmUgdXBkYXRlZCBwcmlv ciB0byBJRVNHIHJldmlldy4gV2Ugd291bGQgZnVydGhlciByZXF1ZXN0IHRoYXQgdGhlIFJGQyBl ZGl0b3IgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmll dyBhbmQgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGlsZSB0aGlzIHNwZWNpZmljYXRpb24gZm9ybWFsbHkgcmVsaWVzIG9u IFtSRkM4NDQ1XSwgYXQgdGhlIHRpbWUgb2YgaXRzIHB1YmxpY2F0aW9uLCB0aGUgbWFqb3JpdHkg b2YgV2ViUlRDIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0IHRoZSB2ZXJzaW9uIG9mIElDRSBkZXNj cmliZWQgaW4gW1JGQzUyNDVdLCBhbmQgdXNlIGEgcHJlLXN0YW5kYXJkIHZlcnNpb24gb2YgdGhl IHRyaWNrbGUgaWNlIG1lY2hhbmlzbQ0KIGRlc2NyaWJlZCBpbiBbUkZDWFhYWF0uIFRoZSB1c2Ug b2YgdGhlICZxdW90O2ljZTImcXVvdDsgYXR0cmlidXRlIGRlZmluZWQgaW4gW1JGQzg0NDVdIGNh biBiZSB1c2VkIHRvIGRldGVjdCB0aGUgdmVyc2lvbiBpbiB1c2UgYnkgYSByZW1vdGUgZW5kcG9p bnQgYW5kIHRvIHByb3ZpZGUgYSBzbW9vdGggdHJhbnNpdGlvbiBmcm9tIHRoZSBvbGRlciBzcGVj aWZpY2F0aW9uIHRvIHRoZSBuZXdlciBvbmUuDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQyA4NDQ1IHdvdWxkIGJlIGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1MjQ1IHdvdWxkIGJlIGluZm9y bWF0aXZlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGlz IG9uZSBtb3JlIG1pbm9yIGNvbXBsaWNhdGlvbiwgaW4gdGhhdCBkcmFmdC1pZXRmLW1tdXNpYy1z ZHAtbXV4LWF0dHJpYnV0ZXMgKHdoaWNoIGN1cnJlbnRseSBwb2ludHMgdG8gUkZDIDUyNDUpIGlz IGludGVuZGVkIHRvIGJlIGFuIGV4aGF1c3RpdmUgbGlzdCBvZiB0aGUgU0RQIGF0dHJpYnV0ZXMN CiBkZWZpbmVkIGluIHRoZSBkb2N1bWVudHMgaXQgbGlzdHMsIGFuZCBSRkMgODQ0NSBhZGRzIGEg bmV3ICZxdW90O2ljZTImcXVvdDsgYXR0cmlidXRlIHRoYXQgd2FzIG5vdCBwcmVzZW50IGluIFJG QyA1MjQ1LiBGb3IgdGhpcyByZWFzb24sIHdlIHdvdWxkIGFsc28gYXNrIHRoZSBSRkMgRWRpdG9y IHRvIGFkZCBhIG5ldyByb3cgdG8gdGhlIHRhYmxlIGluIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1t dXgtYXR0cmlidXRlcyBzZWN0aW9uIDUuMTIsIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT4mbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0Mzs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgfCBOYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgTm90ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCBMZXZlbCB8IE11eCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgQ2F0ZWdvcnkmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSYjNDM7LS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB8IGljZTImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBOb3Qg SW1wYWN0ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgTk9STUFMJm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tJiM0MzstLS0tLS0tLS0tLSYjNDM7PG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgY2xhcml0eSwgdGhlIGFmZmVj dGVkIGRvY3VtZW50cyBhcmUgYXMgZm9sbG93cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIGZvbGxvd2luZyBkb2N1bWVudHMgd291bGQgYmUgdXBkYXRlZCB0byBy ZWZlcmVuY2UgUkZDIDg0NDUgcHJpb3IgdG8gSUVTRyBldmFsdWF0aW9uOjxvOnA+PC9vOnA+PC9w Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBs ZXZlbDEgbGZvMSI+DQpkcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWw8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMSI+DQpkcmFmdC1p ZXRmLWNsdWUtc2lnbmFsaW5nIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCmRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5IDxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBs Zm8xIj4NCmRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2ggPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5UaGUgZm9sbG93aW5nIGRvY3VtZW50cyB3b3VsZCBiZSB1cGRhdGVk IHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVkaXRvcjo8bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPg0KZHJhZnQtaWV0Zi1tbXVzaWMtbXV4LWV4Y2x1c2l2ZTxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCmRyYWZ0 LWlldGYtbW11c2ljLXNjdHAtc2RwIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCmRyYWZ0LWlldGYtcnRjd2ViLWFscG4gPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPg0KZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsIDxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCmRyYWZ0LWlldGYt cnRjd2ViLXJ0cC11c2FnZSA8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBm b2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1 IGFuZCBoYXZlIHRoZSB0ZXh0IHByb3Bvc2VkIGFib3ZlIGFkZGVkIHRvIHRoZW06PG86cD48L286 cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwxIGxldmVsMSBsZm8zIj4NCmRyYWZ0LWlldGYtcnRjd2ViLWpzZXAgPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KZHJhZnQt aWV0Zi1ydGN3ZWItb3ZlcnZpZXcgPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5U aGUgZm9sbG93aW5nIGRvY3VtZW50IHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4 NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yLCBhbmQgaW5jbHVkZSBhIG5ldyByb3cgZm9yICZxdW90O2lj ZTImcXVvdDsgaW4gaXRzIFNlY3Rpb24gNS4xMiwgYXMgZGVzY3JpYmVkIGFib3ZlOjxvOnA+PC9v OnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMyBsZXZlbDEgbGZvNCI+DQpkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMg PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIG1lc3NhZ2UgaXMgY3Jvc3Mt cG9zdGVkIHRvIHRoZSBhZmZlY3RlZCB3b3JraW5nIGdyb3Vwcy4gQmVjYXVzZSB0aGUgaXNzdWUg YXQgaGFuZCBoYXMgaW1wYWN0IGFjcm9zcyBzZXZlcmFsIGRpZmZlcmVudCBncm91cHMsIHdlIGFz ayB0aGF0IGFsbCBmb2xsb3ctdXAgZGlzY3Vzc2lvbiB0YWtlIHBsYWNlDQogb24gPGEgaHJlZj0i bWFpbHRvOmFydEBpZXRmLm9yZyI+Jmx0O2FydEBpZXRmLm9yZyZndDs8L2E+LiBUaGFuayB5b3Uu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi9BZGFtIG9uIGJlaGFsZiBv ZiB0aGUgQVJUIEFyZWEgRGlyZWN0b3JzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPl9fX188YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv Y2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzIzOCI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1 c3Rlcl9pbmZvLnBocD9jaWQ9QzIzODwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpjbHVlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjbHVlQGll dGYub3JnIj5jbHVlQGlldGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2x1ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_46E40ED2D2894C0F8C0B82A5980B2692ericssoncom_-- From nobody Fri Sep 7 00:31:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1863130E85 for ; Fri, 7 Sep 2018 00:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1jOXTIDNKoP for ; Fri, 7 Sep 2018 00:31:27 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D83130DF9 for ; Fri, 7 Sep 2018 00:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536305482; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hAXz1B/DWW574d7NWgaGNclb5rnMNhSeWsX0OTeWh4o=; b=ECyGmqsxkgpwpcu1I6vNsJWCdVpT0o8iPJ0p39bGnd9a98KEwBNCQ4mRsPV50fS/ 4vd3XcEmO+FvdNJkdDb3kB0k1X/7BX7gCvVjKJXITZfJkiWZMIQm6ej5Wls40NQO 3Mrue9R+0LFJkcj/ru3sQzVdu9AnycfcQh2xFN0D95s=; X-AuditID: c1b4fb30-3cd869c0000055da-c7-5b9229498e7f Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 30.11.21978.949229B5; Fri, 7 Sep 2018 09:31:21 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Sep 2018 09:31:17 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Fri, 7 Sep 2018 09:31:17 +0200 From: Christer Holmberg To: Bernard Aboba , Cullen Jennings CC: Applications and Real-Time Area Discussion , RTCWeb IETF , "mmusic@ietf.org" , "clue@ietf.org" , "ice@ietf.org" Thread-Topic: [clue] [rtcweb] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURiH50HGXchKtREuHsgaAdRXGaKTkgICA Date: Fri, 7 Sep 2018 07:31:17 +0000 Message-ID: <975BB4D8-376C-498A-8CD2-EAD9BD4D4689@ericsson.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyM2J7qa6n5qRog/4TNhYr7npYbNj3n9li /6nLzBYf1v9gtPh2odZi6vLHLBZr/7WzO7B77Jx1l91jyZKfTB6Xz39kDGCO4rJJSc3JLEst 0rdL4Mo4N+8NY8Eyj4oFX+QaGHe4dTFyckgImEhM/ryFpYuRi0NI4CijxKHezcwQzldGiYeb 3rNBOEsZJY5sucLUxcjBwSZgIdH9TxukW0TAR2Ln3MVg3cwg3VOWXGEBqREWsJbYfN4eosZG omfiBmYI20hi6sPvjCA2i4CKxKcJG5hAbF4Be4lrV+5DLd7KKPHz6Gc2kDmcAoESm7qMQGoY BcQkvp9aA1bPLCAucevJfCaIDwQkluw5zwxhi0q8fPyPFaRVVEBfYtrlAIiwksSW3i1g1zML aEqs36UPMcVa4s6HN6wQtqLElO6H7BDXCEqcnPmEZQKjxCwky2YhdM9C0j0LSfcsJN0LGFlX MYoWpxYn5aYbGemlFmUmFxfn5+nlpZZsYgRG7sEtvw12ML587niIUYCDUYmHt0R0UrQQa2JZ cWXuIUYJDmYlEV4mBaAQb0piZVVqUX58UWlOavEhRmkOFiVxXgu/zVFCAumJJanZqakFqUUw WSYOTqkGRs0Xvl7Pj0xT6priHpzt06V3K7h2aqIn948GG/vMBqt75y7dD3h57G2n/HKmdUUa jTzMAXvU4ouYP9cFX7Kp3J2y8+zFqX/mbBJ+lBhxc/YEc8ckc7H69zEvJnruc3vYJP7F+uCx mQbzaxUKLsXIf+h0lT5i+3vy9t9rMu/kXGAM3CffU6j9UYmlOCPRUIu5qDgRAO4ie/nYAgAA Archived-At: Subject: Re: [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 07:31:36 -0000 SGksDQoNCj4+IEl0IGlzIGRvdWJ0ZnVsIEp1c3RpbiB3aWxsIHdhbnQgdG8gaW1wbGVtZW50IHRo ZSA4NDQ1IG1lY2hhbmlzbXMgb2Ygc3VwcG9ydGluZyBib3RoIG5ldyBhbmQgb2xkIElDRS4gDQo+ DQo+IFtCQV0gWWVzLCB0aGUgODQ0NSBuZWdvdGlhdGlvbiBtZWNoYW5pc20gbmV2ZXIgcmVhbGx5 IG1hZGUgc2Vuc2UgKHRob3VnaCBUcmlja2xlIG5lZ290aWF0aW9uIGRvZXMgbWFrZSBzZW5zZSku wqANCg0KRXhhY3RseSB3aGF0IDg0NDUgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGRvZXMgbm90IG1h a2Ugc2Vuc2UsIGNvbXBhcmVkIHRvIDUyNDU/DQoNCj4+IFJpZ2h0IGhlcmUgSSBhbSB3YXRjaGlu ZyBob3cgdGhlIHN0dWZmIElFVEYgZGVmaW5lcyB3aWxsIGJlIGxlc3MgcmVsZXZhbnQgdGhhbiB0 aGUgaXNzdWUgb2Ygd2hhdCBjaHJvbWUgaW1wbGVtZW50cy7CoA0KPg0KPiBbQkFdIEltcGxlbWVu dGF0aW9ucyBoYXZlIGFsd2F5cyBtYXR0ZXJlZC4gV2hhdCBoYXMgY2hhbmdlZCBpcyB0aGF0IHRo ZSBJRVRGIHNlZW1zIHRvIGJlIHBheWluZyBsZXNzIGF0dGVudGlvbiB0byBjb3N0L2JlbmVmaXQg dHJhZGVvZmZzLg0KDQpJIGNhbid0IG9mIGNvdXJzZSBzcGVhayBmb3IgZXZlcnlvbmUsIGJ1dCBz b21lIGltcGxlbWVudGVycyBJIHRhbGtlZCB0byBkdXJpbmcgdGhlIHllYXJzIG9mIHdvcmsgb24g ODQ0NSB0b2xkIG1lIHRoYXQgdGhlIHdheSB0aGV5IGltcGxlbWVudGVkIDUyNDUgd2FzIGFjdHVh bGx5IG1vcmUgODQ0NSB0aGFuIDUyNDUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoN Cg0KT24gQXVnIDIyLCAyMDE4LCBhdCAxMDo1OCBBTSwgQWRhbSBSb2FjaCA8bWFpbHRvOmFkYW1A bm9zdHJ1bS5jb20+IHdyb3RlOg0KDQpNZW1iZXJzIG9mIHRoZSBBUlQgY29tbXVuaXR5IGludGVy ZXN0ZWQgaW4gcmVhbC10aW1lIGNvbW11bmljYXRpb25zOiANCkNsdXN0ZXIgMjM4IFsxXSBpcyBh IHNldCBvZiBpbnRlci1yZWxhdGVkIGRvY3VtZW50cyBkZWFsaW5nIHdpdGggcmVhbC10aW1lIGNv bW11bmljYXRpb25zLiBUaGUgYnVsayBvZiB0aGVzZSBkb2N1bWVudHMgcmVsYXRlIHRvIFdlYlJU QywgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoZXkgYWxzbyBmb3JtIHRoZSB1bmRl cnBpbm5pbmdzIG9mIENMVUUuIEFzIG9mIG5vdywgdGhlcmUgYXJlIDM0IGRvY3VtZW50cyBpbiB0 aGUgY2x1c3RlciB0aGF0IGFyZSBub3QgeWV0IHB1Ymxpc2hlZCwgd2l0aCAyNSBvZiB0aGVzZSBh bHJlYWR5IGluIHRoZSBSRkMgRWRpdG9yJ3MgcXVldWUuIFRoZSBkZXBlbmRlbmN5IGdyYXBoIGFt b25nIHRoZXNlIGRvY3VtZW50cyBpcyBzdWNoIHRoYXQgdGhlIGJ1bGsgb2YgdGhlbSBjYW4gYmUg cHVibGlzaGVkIGFzIHNvb24gYXMgYSBzcGVjaWZpYyBzaXggb2YgdGhlbSBhcmUgaGFuZGVkIG9m ZiB0byB0aGUgUkZDIGVkaXRvciwgYW5kIHdlIGV4cGVjdCB0aGlzIHRvIGhhcHBlbiBpbiB0aGUg dXBjb21pbmcgZmV3IG1vbnRocy4NCk9uZSBsb25nLXJ1bm5pbmcgY29tcGxpY2F0aW9uIGZvciB0 aGlzIGNsdXN0ZXIgb2YgZG9jdW1lbnRzIGlzIHRoYXQgZWFjaCBvZiB0aGUgZG9jdW1lbnRzIHdl cmUgZGV2ZWxvcGVkIG92ZXIgdGhlIGNvdXJzZSBvZiBzZXZlbiB5ZWFycywgaW4gY29uY2VydCB3 aXRoIGltcGxlbWVudGF0aW9ucywgd2hpbGUgdGhlIElDRSBwcm90b2NvbCBpdHNlbGYgd2FzIHVu ZGVyZ29pbmcgc2lnbmlmaWNhbnQgcmV2aXNpb24uIEFzIGEgY29uc2VxdWVuY2UsIHNvbWUgZG9j dW1lbnRzIHJlbHkgKGRpcmVjdGx5IG9yIGluZGlyZWN0bHkpIG9uIHRoZSBvbGRlciBJQ0Ugc3Bl Y2lmaWNhdGlvbiAoUkZDIDUyNDUpLCB3aGlsZSBzb21lIHJlbHkgb24gdGhlIG5ld2VyIG9uZSAo UkZDIDg0NDUpLiBJbiBzb21lIGNhc2VzLCBkb2N1bWVudHMgcmVmZXIgZGlyZWN0bHkgdG8gdGhl IG9sZCB2ZXJzaW9uIGFuZCB0cmFuc2l0aXZlbHkgdG8gdGhlIG5ldyB2ZXJzaW9uLg0KSXQgaXMg bm90ZXdvcnRoeSB0aGF0IFJGQyA4NDQ1IG9ic29sZXRlcyBSRkMgNTI0NTsgYW5kIHRoYXQgdGhl IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gUkZDIDg0NDUgaGFzIHNvbWXCoCBjaGFuZ2VzIHRoYXQg YnJlYWsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgbWVjaGFuaXNtIGRlZmluZWQg aW4gUkZDIDUyNDUgKHdpdGggc3VjaCBiZWhhdmlvcmFsIGNoYW5nZXMgY29udHJvbGxlZCBieSBh biBTRFAgYXR0cmlidXRlLCBhbGxvd2luZyBjbGllbnRzIHRvIHRyYW5zaXRpb24gZnJvbSBvbmUg dG8gdGhlIG90aGVyKS4NCk1vc3Qgbm90YWJseSwgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcCAod2hp Y2ggaXMgdGhlIGNvcmUgV2ViUlRDIHByb3RvY29sIGluIHRoZSBJRVRGKSByZWZlcnMgdG8gZGly ZWN0bHkgdG8gUkZDIDUyNDUsIHdoaWxlIHJlbHlpbmcgb24gdGhlIGJlaGF2aW9yIGRlZmluZWQg aW4gZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZTsgZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZSwgaW4gdHVy biwgaXMgYmFzZWQgb24gdGhlIG5ld2VyIFJGQyA4NDQ1IGhhbmRsaW5nLiBKU0VQJ3MgcmVmZXJl bmNlIHRvIFJGQyA1MjQ1IGlzIGEgcHJhY3RpY2FsIGNvbnNpZGVyYXRpb24gdGhhdCBhY2tub3ds ZWRnZXMgdGhhdCBjdXJyZW50IGRlcGxveW1lbnRzIG9mIFdlYlJUQyBpbXBsZW1lbnQgdGhlIG9s ZGVyIHZlcnNpb24gb2YgSUNFLiBBdCB0aGUgc2FtZSB0aW1lLCB0aGVzZSBkZXBsb3llZCBpbXBs ZW1lbnRhdGlvbnMgdXNlIGEgc29tZXdoYXQgb2xkZXIgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLWlj ZS10cmlja2xlIGluIGNvbmNlcnQgd2l0aCB0aGUgb2xkZXIgSUNFIGltcGxlbWVudGF0aW9uLg0K SW4gb3JkZXIgdG8gZ2V0IENsdXN0ZXIgMjM4IHB1Ymxpc2hlZCwgd2UgbmVlZCB0byBmaW5kIHNv bWUgd2F5IHRvIHJhdGlvbmFsaXplIGl0cyByZWZlcmVuY2VzIHRvIElDRS4gQXQgYSBiYXNpYyBs ZXZlbCwgdGhlIEFSVCBBcmVhIERpcmVjdG9ycyBkbyBub3QgYmVsaWV2ZSB0aGF0IGl0IG1ha2Vz IHNlbnNlIHRvIHB1Ymxpc2ggbmV3IGRvY3VtZW50cyB0aGF0IHJlZmVyIHRvIGFuIGFscmVhZHkg b2Jzb2xldGVkIFJGQy4gQXQgdGhlIHNhbWUgdGltZSwgd2UgcmVjb2duaXplIHRoYXQgdGhlcmUg aXMgdmFsdWUgaW4gb3VyIHNwZWNpZmljYXRpb25zIGJlaW5nIGluZm9ybWVkIGJ5IHJ1bm5pbmcg Y29kZS4gRm9yIFdlYlJUQywgdGhlIGNvbXBsZXhpdHkgb2YgdGhlIHN5c3RlbSBoYXMgbGVkIHVz IHRvIGEgcG9pbnQgdGhhdCB3ZSBtdXN0IGNob29zZSBiZXR3ZWVuIHRoZXNlIHByaW5jaXBsZXMu IE91ciBwcm9wb3NhbCBpcyB0byBjaG9vc2UgdGhlIGZpcnN0LCB3aGlsZSBhY2tub3dsZWRnaW5n IHRoZSBzZWNvbmQuDQpUaGlzIHdvdWxkIHJlc3VsdCBpbiBhIHJlcXVlc3QgdG8gdGhlIFJGQyBl ZGl0b3IgdG8gdXBkYXRlIGFsbCByZWZlcmVuY2VzIHRvIFJGQyA1MjQ1IGluIHRoZSBDbHVzdGVy IDIzOCBkb2N1bWVudHMgdG8gaW5zdGVhZCBwb2ludCB0byBSRkMgODQ0NS4gRG9jdW1lbnRzIG5v dCB5ZXQgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUgd291bGQgYmUgdXBkYXRlZCBwcmlvciB0byBJ RVNHIHJldmlldy4gV2Ugd291bGQgZnVydGhlciByZXF1ZXN0IHRoYXQgdGhlIFJGQyBlZGl0b3Ig YWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyBhbmQg ZHJhZnQtaWV0Zi1ydGN3ZWItanNlcDoNCg0KV2hpbGUgdGhpcyBzcGVjaWZpY2F0aW9uIGZvcm1h bGx5IHJlbGllcyBvbiBbUkZDODQ0NV0sIGF0IHRoZSB0aW1lIG9mIGl0cyBwdWJsaWNhdGlvbiwg dGhlIG1ham9yaXR5IG9mIFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCB0aGUgdmVyc2lv biBvZiBJQ0UgZGVzY3JpYmVkIGluIFtSRkM1MjQ1XSwgYW5kIHVzZSBhIHByZS1zdGFuZGFyZCB2 ZXJzaW9uIG9mIHRoZSB0cmlja2xlIGljZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFtSRkNYWFhY XS4gVGhlIHVzZSBvZiB0aGUgImljZTIiIGF0dHJpYnV0ZSBkZWZpbmVkIGluIFtSRkM4NDQ1XSBj YW4gYmUgdXNlZCB0byBkZXRlY3QgdGhlIHZlcnNpb24gaW4gdXNlIGJ5IGEgcmVtb3RlIGVuZHBv aW50IGFuZCB0byBwcm92aWRlIGEgc21vb3RoIHRyYW5zaXRpb24gZnJvbSB0aGUgb2xkZXIgc3Bl Y2lmaWNhdGlvbiB0byB0aGUgbmV3ZXIgb25lLiANClJGQyA4NDQ1IHdvdWxkIGJlIGEgbm9ybWF0 aXZlIHJlZmVyZW5jZSBmb3IgYm90aCBkb2N1bWVudHMsIHdoaWxlIFJGQyA1MjQ1IHdvdWxkIGJl IGluZm9ybWF0aXZlLiANClRoZXJlIGlzIG9uZSBtb3JlIG1pbm9yIGNvbXBsaWNhdGlvbiwgaW4g dGhhdCBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMgKHdoaWNoIGN1cnJlbnRs eSBwb2ludHMgdG8gUkZDIDUyNDUpIGlzIGludGVuZGVkIHRvIGJlIGFuIGV4aGF1c3RpdmUgbGlz dCBvZiB0aGUgU0RQIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgZG9jdW1lbnRzIGl0IGxpc3Rz LCBhbmQgUkZDIDg0NDUgYWRkcyBhIG5ldyAiaWNlMiIgYXR0cmlidXRlIHRoYXQgd2FzIG5vdCBw cmVzZW50IGluIFJGQyA1MjQ1LiBGb3IgdGhpcyByZWFzb24sIHdlIHdvdWxkIGFsc28gYXNrIHRo ZSBSRkMgRWRpdG9yIHRvIGFkZCBhIG5ldyByb3cgdG8gdGhlIHRhYmxlIGluIGRyYWZ0LWlldGYt bW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcyBzZWN0aW9uIDUuMTIsIGFzIGZvbGxvd3M6DQoNCiAg ICstLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0tLS0tKw0KICAgfCBOYW1lICAgICAgICAgICAgICB8IE5vdGVzICAgICAgICAgICAg ICAgICAgICAgfCBMZXZlbCB8IE11eCAgICAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgQ2F0ZWdvcnkgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0t LS0tLS0tKw0KICAgfCBpY2UyICAgICAgICAgICAgICB8IE5vdCBJbXBhY3RlZCAgICAgICAgICAg ICAgfCBTICAgICB8IE5PUk1BTCAgICB8DQogICB8ICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0t Kw0KDQpGb3IgY2xhcml0eSwgdGhlIGFmZmVjdGVkIGRvY3VtZW50cyBhcmUgYXMgZm9sbG93cy4N ClRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJG QyA4NDQ1IHByaW9yIHRvIElFU0cgZXZhbHVhdGlvbjoNCuKAoiBkcmFmdC1pZXRmLWNsdWUtZGF0 YWNoYW5uZWwNCuKAoiBkcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5nIA0K4oCiIGRyYWZ0LWlldGYt cnRjd2ViLXNlY3VyaXR5IA0K4oCiIGRyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2ggDQoN ClRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxkIGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJG QyA4NDQ1IGJ5IHRoZSBSRkMgRWRpdG9yOg0K4oCiIGRyYWZ0LWlldGYtbW11c2ljLW11eC1leGNs dXNpdmUNCuKAoiBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNkcCANCuKAoiBkcmFmdC1pZXRmLXJ0 Y3dlYi1hbHBuIA0K4oCiIGRyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbCANCuKAoiBkcmFm dC1pZXRmLXJ0Y3dlYi1ydHAtdXNhZ2UgDQoNClRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHdvdWxk IGJlIHVwZGF0ZWQgdG8gcmVmZXJlbmNlIFJGQyA4NDQ1IGFuZCBoYXZlIHRoZSB0ZXh0IHByb3Bv c2VkIGFib3ZlIGFkZGVkIHRvIHRoZW06DQrigKIgZHJhZnQtaWV0Zi1ydGN3ZWItanNlcCANCuKA oiBkcmFmdC1pZXRmLXJ0Y3dlYi1vdmVydmlldyANCg0KVGhlIGZvbGxvd2luZyBkb2N1bWVudCB3 b3VsZCBiZSB1cGRhdGVkIHRvIHJlZmVyZW5jZSBSRkMgODQ0NSBieSB0aGUgUkZDIEVkaXRvciwg YW5kIGluY2x1ZGUgYSBuZXcgcm93IGZvciAiaWNlMiIgaW4gaXRzIFNlY3Rpb24gNS4xMiwgYXMg ZGVzY3JpYmVkIGFib3ZlOg0K4oCiIGRyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRl cyANCg0KVGhpcyBtZXNzYWdlIGlzIGNyb3NzLXBvc3RlZCB0byB0aGUgYWZmZWN0ZWQgd29ya2lu ZyBncm91cHMuIEJlY2F1c2UgdGhlIGlzc3VlIGF0IGhhbmQgaGFzIGltcGFjdCBhY3Jvc3Mgc2V2 ZXJhbCBkaWZmZXJlbnQgZ3JvdXBzLCB3ZSBhc2sgdGhhdCBhbGwgZm9sbG93LXVwIGRpc2N1c3Np b24gdGFrZSBwbGFjZSBvbiBtYWlsdG86YXJ0QGlldGYub3JnLiBUaGFuayB5b3UuDQovQWRhbSBv biBiZWhhbGYgb2YgdGhlIEFSVCBBcmVhIERpcmVjdG9ycw0KX19fXw0KWzFdIGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2NsdXN0ZXJfaW5mby5waHA/Y2lkPUMyMzgNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KbWFp bHRvOmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cnRjd2ViIG1haWxpbmcgbGlzdA0KbWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCg0K From nobody Fri Sep 7 09:25:06 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462D12F1A2 for ; Fri, 7 Sep 2018 09:24:46 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25gVUBCeG424 for ; Fri, 7 Sep 2018 09:24:45 -0700 (PDT) Received: from smtp65.iad3b.emailsrvr.com (smtp65.iad3b.emailsrvr.com [146.20.161.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67FE130E02 for ; Fri, 7 Sep 2018 09:24:43 -0700 (PDT) Received: from smtp1.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id AFAD660097; Fri, 7 Sep 2018 12:24:42 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 182B46007D; Fri, 7 Sep 2018 12:24:42 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 07 Sep 2018 12:24:42 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Cullen Jennings In-Reply-To: Date: Fri, 7 Sep 2018 10:24:40 -0600 Cc: Applications and Real-Time Area Discussion , "clue@ietf.org" , RTCWeb IETF , "mmusic@ietf.org" , "ice@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <250E036A-63AB-4705-BFF5-288704FB40CA@iii.ca> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> To: Adam Roach X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 16:24:47 -0000 That=E2=80=99s a very useful graph but when I look at the what is = actually used in the purple links, most of them seem they could trivial = work with any version of ICE with the exception of the few places = trickle is used and need the explicit stuff around how to deal with = trickle.=20 > On Sep 6, 2018, at 6:54 PM, Adam Roach wrote: >=20 > On 9/6/18 3:24 PM, Cullen Jennings wrote: >> I would propose that instead of the parts of specs that use the = trickle mechanism purely reference that part of the new ICE spec that = defines the syntax and say to transfer trickle candidates. >=20 >=20 > Unfortunately, it's not quite so simple. The mismatch with trickle-ice = is only the most obvious problem. In practice, there are a few dozen = places where unpublished documents in the cluster refer directly to one = version of ICE, and indirectly to another, or indirectly to both. >=20 > To help wrap our collective minds around this issue, I've put together = a dependency graph that shows which Cluster 238 documents refer to which = version of ICE. The red lines indicate references (directly or = indirectly) to RFC 5245, while the purple lines indicate references to = RFC 8445. The thickness of the line indicates how many hops away from = ICE the reference is. Dotted lines are informative references. >=20 > https://trac.ietf.org/trac/art/wiki/c238 >=20 > To put a finer point on this, it took me a couple of hours to pare = this graph down to something that was small enough to look at and = actually understand -- there are actually twice as many documents = involved in this mess, but including them makes the situation too = confusing to even start to get a grip on. >=20 > Everywhere you see a purple document with a red arrow or vice-versa is = a place we need to figure out how to handle this mismatch. You can push = the boundaries around, but the count of mismatches is pretty much the = same no matter how you do that. On a first order estimation, this is = days -- or, more likely, weeks of work. And I'm talking about = person-hours, not calendar time. If you can do this, or find someone to = step up and do it, then your proposal would be a viable alternative to = the one that the ART ADs have proposed. Short of that, I'm not sure how = we can do what you want. >=20 > /a >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Sep 7 09:36:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E972C12F1A2 for ; Fri, 7 Sep 2018 09:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2X-GY1ppYps for ; Fri, 7 Sep 2018 09:36:39 -0700 (PDT) Received: from smtp65.ord1d.emailsrvr.com (smtp65.ord1d.emailsrvr.com [184.106.54.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5676130DF7 for ; Fri, 7 Sep 2018 09:36:37 -0700 (PDT) Received: from smtp1.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id D6594404ED; Fri, 7 Sep 2018 12:36:36 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 54563403D1; Fri, 7 Sep 2018 12:36:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 07 Sep 2018 12:36:36 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_229D84CB-B9E6-4319-9E94-646186D4468C" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Cullen Jennings In-Reply-To: <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> Date: Fri, 7 Sep 2018 10:36:35 -0600 Cc: Applications and Real-Time Area Discussion , "clue@ietf.org" , RTCWeb IETF , "mmusic@ietf.org" , "ice@ietf.org" Message-Id: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 16:36:42 -0000 --Apple-Mail=_229D84CB-B9E6-4319-9E94-646186D4468C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 7, 2018, at 1:25 AM, Christer Holmberg = wrote: >=20 > > Cisco has implemented stuff that is WebRTC 1.0 compliant without = this change. These gratuitous changes, years after the implementation = were coded, with no real benefit will ensure that we are not > > and will not become compliant with the RFC. It's unlikely we will = upgrade to the new ICE until it has real befits.=20 > =20 > The main reason we did 8445 was because people had identified issues = with 5245. The work was driven mostly by the WebRTC community, including = yourself and the Chrome people (or, at least the Google people), and one = of the reason it took time to finalize 8445 was because you (among = others) wanted to make sure we get things right (by making network = measurements etc). Are you now saying all those changes bring no = benefit? Did we all waste our time? Our testing, which we do not share, dig not indicate an improvement of = connectivity rates. I did not see results from others that did. Some of = the early test results from others that drove this work were not = reproducible in our testing. The one thing I think most people did find = is that the more out of sync the pacing of the two agents was, the worse = the connectivity was. But all of this is water under the bridge, we have = old and new ice, people can use either. What we are talking about here = is what is the minimum bar for WebRTC 1.0=20 > =20 > > It is doubtful Justin will want to implement the 8445 mechanisms of = supporting both new and old ICE. Instead, we will move to say "works = with Browser X version Y or later." We have watched at W3C as it moved = to be that unless chrome does it, it rare that it becomes a standard. =20= > > Right here I am watching how the stuff IETF defines will be less = relevant than the issue of what chrome implements.=20 > =20 > What exactly would Justin have to change? > =20 For us, the largest part is having to test for both old and new - it=E2=80= =99s not easy to do good automated testing for ICE.=20= --Apple-Mail=_229D84CB-B9E6-4319-9E94-646186D4468C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 7, 2018, at 1:25 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> = Cisco has implemented stuff that is WebRTC 1.0 compliant without this = change. These = gratuitous changes, years after the implementation were coded, with no = real benefit will ensure that we are not
> and will not become compliant with the RFC. It's unlikely we = will upgrade to the new ICE until it has real befits. 
 
The main reason we did 8445 was because people = had identified issues with 5245. The work was driven mostly by the = WebRTC community, including yourself and the Chrome people (or, at least = the Google people), and one of the reason it took time to finalize 8445 = was because you (among others) wanted to make sure we get things right = (by making network measurements etc). Are you now saying all those = changes bring no benefit? Did we all waste our = time?

Our = testing, which we do not share, dig not indicate an improvement of = connectivity rates. I did not see results from others that did. Some of = the early test results from others that drove this work were not = reproducible in our testing. The one thing I think most people did find = is that the more out of sync the pacing of the two agents was, the worse = the connectivity was. But all of this is water under the bridge, we have = old and new ice, people can use either. What we are talking about here = is what is the minimum bar for WebRTC 1.0 

 
> It = is doubtful Justin will want to implement the 8445 mechanisms of = supporting both new and old ICE. Instead, we will = move to say "works with Browser X version Y or later." We have watched = at W3C as it moved to be that unless chrome does it, it rare that it = becomes a standard.  
> Right here I am watching how the stuff IETF defines will be = less relevant than the issue of what chrome = implements. 
 
What exactly would Justin = have to change?
 

For us, the largest part is having to test = for both old and new - it=E2=80=99s not easy to do good automated = testing for ICE. 
= --Apple-Mail=_229D84CB-B9E6-4319-9E94-646186D4468C-- From nobody Fri Sep 7 11:26:30 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086B130E6C for ; Fri, 7 Sep 2018 11:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4VCqq1rmH4z for ; Fri, 7 Sep 2018 11:26:03 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD46130E7A for ; Fri, 7 Sep 2018 11:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536344756; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IFkWzfUGEm32nVPlDTAq068htvXbJmcZFwFMJ+dUJKs=; b=UP8m+SKCYleofS7Jt6XFTrPd7Cz69/a1eORxMtc3xxQZiT0s/QXJIvJ/2m/307fz JjTYEhWuPNl36OQHSTbIfQg1JfsO35CS7YBiqdxty7EoJN2ixCtrrqd6uByxEDK0 K3FUwudtxk3kx1BXpri89fxIe8HnTg+i/l0n5Wd+m54=; X-AuditID: c1b4fb30-fe1ff700000055da-35-5b92c2b432a7 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.00.21978.4B2C29B5; Fri, 7 Sep 2018 20:25:56 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Sep 2018 20:25:56 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Fri, 7 Sep 2018 20:25:56 +0200 From: Christer Holmberg To: Cullen Jennings CC: Applications and Real-Time Area Discussion , "clue@ietf.org" , RTCWeb IETF , "mmusic@ietf.org" , "ice@ietf.org" Thread-Topic: [art] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURh+v3CEVPFpjI0266oWKAGTzsaTkftOAgABlSICAADz38A== Date: Fri, 7 Sep 2018 18:25:56 +0000 Message-ID: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> 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.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2J7se6WQ5OiDT6usbJYcdfDYv+py8wW H9b/YLT4dqHWYuryxywWa/+1szuweSxZ8pPJ4/L5j4wBTFFcNimpOZllqUX6dglcGS9n9TEV XJOrOPd0C2sD4wfZLkZODgkBE4knS3exdzFycQgJHGWUaJ17Hsr5yijx59IBVghnKaPEzmuP mLoYOTjYBCwkuv9pg3SLCChLnNtxlxmkhhmk+9Hl2awgCWEBc4kdex+wQhRZSGx/+ZkFwnaS ePhsCpjNIqAi8fLRJnYQm1fAWuLA6yaoZVcYJbrmgtzEwcEpYCWx7HsFSA2jgJjE91NrmEBs ZgFxiVtP5jNBvCAgsWTPeWYIW1Ti5eN/rBC2ksTeY9dZQMYwC2hKrN+lD9GqKDGl+yHUWkGJ kzOfsExgFJuFZOoshI5ZSDpmIelYwMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwxg5u +W2wg/Hlc8dDjAIcjEo8vP57JkULsSaWFVfmHmKU4GBWEuF1rQMK8aYkVlalFuXHF5XmpBYf YpTmYFES57Xw2xwlJJCeWJKanZpakFoEk2Xi4JRqYLTeefO0EeeL1Bcb5qbNOBlqVpTbZ3gs dd7pPfXzjCp7nDb8e1pnvTlsQrjcQrU8M8sLDD2BacJrzc/NSzxY7BRtIS1at0KIfUqAJktr ZPn19BYJO9c380scD3G1xhyX9i7z3HctOnqz/8bol/P2rWaotohccOJA7laVn77BGnVtC55q iB41V2Ipzkg01GIuKk4EAO9vZWStAgAA Archived-At: Subject: Re: [rtcweb] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 18:26:13 -0000 SGksDQoNCj4+PiBDaXNjbyBoYXMgaW1wbGVtZW50ZWQgc3R1ZmYgdGhhdCBpcyBXZWJSVEMgMS4w IGNvbXBsaWFudCB3aXRob3V0IHRoaXMgY2hhbmdlLsKgVGhlc2UgZ3JhdHVpdG91cyANCj4+PiBj aGFuZ2VzLCB5ZWFycyBhZnRlciB0aGUgaW1wbGVtZW50YXRpb24gd2VyZSBjb2RlZCwgd2l0aCBu byByZWFsIGJlbmVmaXQgd2lsbCBlbnN1cmUgdGhhdCB3ZSBhcmUgbm90DQo+Pj7CoGFuZCB3aWxs IG5vdCBiZWNvbWUgY29tcGxpYW50IHdpdGggdGhlIFJGQy7CoEl0J3MgdW5saWtlbHkgd2Ugd2ls bCB1cGdyYWRlIHRvIHRoZSBuZXcgSUNFIHVudGlsIGl0IGhhcyByZWFsIGJlZml0cy7CoA0KPj7C oA0KPj4gVGhlIG1haW4gcmVhc29uIHdlIGRpZCA4NDQ1IHdhcyBiZWNhdXNlIHBlb3BsZSBoYWQg aWRlbnRpZmllZCBpc3N1ZXMgd2l0aCA1MjQ1LiBUaGUgd29yayB3YXMgZHJpdmVuIA0KPj4gbW9z dGx5IGJ5IHRoZSBXZWJSVEMgY29tbXVuaXR5LCBpbmNsdWRpbmcgeW91cnNlbGYgYW5kIHRoZSBD aHJvbWUgcGVvcGxlIChvciwgYXQgbGVhc3QgdGhlIEdvb2dsZSBwZW9wbGUpLCANCj4+IGFuZCBv bmUgb2YgdGhlIHJlYXNvbiBpdCB0b29rIHRpbWUgdG8gZmluYWxpemUgODQ0NSB3YXMgYmVjYXVz ZSB5b3UgKGFtb25nIG90aGVycykgd2FudGVkIHRvIG1ha2Ugc3VyZSB3ZSBnZXQgDQo+PiB0aGlu Z3MgcmlnaHQgKGJ5IG1ha2luZyBuZXR3b3JrIG1lYXN1cmVtZW50cyBldGMpLiBBcmUgeW91IG5v dyBzYXlpbmcgYWxsIHRob3NlIGNoYW5nZXMgYnJpbmcgbm8gYmVuZWZpdD8gRGlkIA0KPj4gd2Ug YWxsIHdhc3RlIG91ciB0aW1lPw0KPg0KPk91ciB0ZXN0aW5nLCB3aGljaCB3ZSBkbyBub3Qgc2hh cmUsIA0KDQpJIGFtIHRhbGtpbmcgYWJvdXQgdGhlIHRlc3QgcmVzdWx0cyB0aGF0IHdlcmUgc2hh cmVkIChieSBHb29nbGUsIGlmIEkgcmVtZW1iZXIgY29ycmVjdGx5KSBhdCBvbmUgb2YgdGhlIElF VEYgbWVldGluZ3MsIHdoaWNoIHdlIHVzZWQgdG8gbW9kaWZ5IHNvbWUgdGltZXIgdmFsdWVzLiBJ J2QgaGF2ZSB0byBkaWcgaW4gdGhlIGFyY2hpdmVzIGZvciB0aGUgZGV0YWlscywgYnV0IHlvdSBz YWlkIHdlIGNhbid0IG1vdmUgdGhlIGRyYWZ0IGZvcndhcmQgYmVmb3JlIHdlIGdldCB0aG9zZSBy ZXN1bHRzLCBhbmQgSSB0aGluayB3ZSB3YWl0ZWQgMS0yIG1lZXRpbmcgY3ljbGVzIGZyb20gdGhl bS4NCg0KTm90ZSB0aGF0IEkgYW0gbm90IGJsYW1pbmcgeW91IGZvciB3YW50aW5nIHRvIHNldCB2 YWx1ZXMgYmFzZWQgb24gcmVhbC1saWZlIGV4cGVyaWVuY2UgLSB0aGF0J3MgYSBnb29kIHRoaW5n LiBJIGFtIGp1c3Qgc3VycHJpc2VkIHRoYXQgZXZlcnl0aGluZyB3ZSBkaWQgbm93IHNlZW1zIGxp a2UgYSB3YXN0ZSBvZiB0aW1lLg0KDQo+IGRpZyBub3QgaW5kaWNhdGUgYW4gaW1wcm92ZW1lbnQg b2YgY29ubmVjdGl2aXR5IHJhdGVzLiBJIGRpZCBub3Qgc2VlIHJlc3VsdHMgZnJvbSBvdGhlcnMg dGhhdCBkaWQuIFNvbWUgb2YgdGhlIGVhcmx5IHRlc3QgcmVzdWx0cyBmcm9tIA0KPiBvdGhlcnMg dGhhdCBkcm92ZSB0aGlzIHdvcmsgd2VyZSBub3QgcmVwcm9kdWNpYmxlIGluIG91ciB0ZXN0aW5n LiBUaGUgb25lIHRoaW5nIEkgdGhpbmsgbW9zdCBwZW9wbGUgZGlkIGZpbmQgaXMgdGhhdCB0aGUg bW9yZSBvdXQgb2YgDQo+IHN5bmMgdGhlIHBhY2luZyBvZiB0aGUgdHdvIGFnZW50cyB3YXMsIHRo ZSB3b3JzZSB0aGUgY29ubmVjdGl2aXR5IHdhcy4gQnV0IGFsbCBvZiB0aGlzIGlzIHdhdGVyIHVu ZGVyIHRoZSBicmlkZ2UsIHdlIGhhdmUgb2xkIGFuZCANCj4gbmV3IGljZSwgcGVvcGxlIGNhbiB1 c2UgZWl0aGVyLiBXaGF0IHdlIGFyZSB0YWxraW5nIGFib3V0IGhlcmUgaXMgd2hhdCBpcyB0aGUg bWluaW11bSBiYXIgZm9yIFdlYlJUQyAxLjDCoA0KDQpDb3JyZWN0IG1lIGlmIEknbSB3cm9uZywg YnV0IFdlYlJUQyAxLjAgZG9lcyB1c2UgdHJpY2tsZSwgYW5kIGRvZXMgbm90IHVzZSBhZ2dyZXNz aXZlIG5vbWluYXRpb24uIFRyaWNrbGUgaXMgYmFzZWQgb24gODQ0NSwgYW5kIGFnZ3Jlc3NpdmUg bm9taW5hdGlvbiB3YXMgZGVwcmVjYXRlZCBpbiA4NDQ1LiBTbywgd2hhdCBleGFjdGx5IGFyZSB5 b3Ugc3VnZ2VzdGluZyB0aGUgbWluaW11bSBiYXIgZm9yIFdlYlJUQyAxLjAgc2hvdWxkIGJlPyBT b21lICJwcm9maWxlIiBvZiA1MjQ1Pw0KwqANCj4+PiBJdCBpcyBkb3VidGZ1bCBKdXN0aW4gd2ls bCB3YW50IHRvIGltcGxlbWVudCB0aGUgODQ0NSBtZWNoYW5pc21zIG9mIHN1cHBvcnRpbmcgYm90 aCBuZXcgYW5kIG9sZCBJQ0UuwqBJbnN0ZWFkLCB3ZSB3aWxsIG1vdmUgDQo+Pj4gdG8gc2F5ICJ3 b3JrcyB3aXRoIEJyb3dzZXIgWCB2ZXJzaW9uIFkgb3IgbGF0ZXIuIiBXZSBoYXZlIHdhdGNoZWQg YXQgVzNDIGFzIGl0IG1vdmVkIHRvIGJlIHRoYXQgdW5sZXNzIGNocm9tZSBkb2VzIGl0LCBpdCBy YXJlIA0KPj4+IHRoYXQgaXQgYmVjb21lcyBhIHN0YW5kYXJkLiDCoA0KPj4+wqBSaWdodCBoZXJl IEkgYW0gd2F0Y2hpbmcgaG93IHRoZSBzdHVmZiBJRVRGIGRlZmluZXMgd2lsbCBiZSBsZXNzIHJl bGV2YW50IHRoYW4gdGhlIGlzc3VlIG9mIHdoYXQgY2hyb21lIGltcGxlbWVudHMuwqANCj4+DQo+ PiBXaGF0IGV4YWN0bHkgd291bGQgSnVzdGluIGhhdmUgdG8gY2hhbmdlPw0KPsKgDQo+IEZvciB1 cywgdGhlIGxhcmdlc3QgcGFydCBpcyBoYXZpbmcgdG8gdGVzdCBmb3IgYm90aCBvbGQgYW5kIG5l dyAtIGl04oCZcyBub3QgZWFzeSB0byBkbyBnb29kIGF1dG9tYXRlZCB0ZXN0aW5nIGZvciBJQ0Uu wqANCg0KU28sIGFnYWluc3Qgd2hhdCBzcGVjIGRvIHlvdSB0ZXN0IHRyaWNrbGU/IA0KDQpSZWdh cmRzLA0KDQpDaHJpc3Rlcg0K From nobody Fri Sep 7 11:29:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5F9130E48 for ; Fri, 7 Sep 2018 11:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEca59EukU9A for ; Fri, 7 Sep 2018 11:28:57 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0582130E42 for ; Fri, 7 Sep 2018 11:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536344935; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JHlvtc3OJoZJi/Nc7/DKZREYFh9TX1155vm2taA36v4=; b=ImKB5G4/xTv9MjmlLLHXldQdtZkj/Q27cncw4I/JPmBc/fsGDY2QQvxi6OaNWB/l ZYn+1AfNIHaoB98Vn7/WqhKUhwyNclmQ9RbuX9CtMiUZb5GrNA4k3jxyQi5KypVj 2tkgMCP8fnpOtd3rCRMEigmj93iwKHuBU4R8g4Q3xf0=; X-AuditID: c1b4fb30-fe1ff700000055da-2e-5b92c36626f3 Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.80.21978.763C29B5; Fri, 7 Sep 2018 20:28:55 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB504.ericsson.se (153.88.183.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Sep 2018 20:28:54 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Fri, 7 Sep 2018 20:28:54 +0200 From: Christer Holmberg To: Cullen Jennings , Adam Roach CC: Applications and Real-Time Area Discussion , "ice@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , RTCWeb IETF Thread-Topic: [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURh+v3CEVPFpjI0266oWKAGTzsaTj3MoAgAED/QCAAEOkYA== Date: Fri, 7 Sep 2018 18:28:54 +0000 Message-ID: <486e6b6c689445ed936cb3717c71341d@ericsson.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <250E036A-63AB-4705-BFF5-288704FB40CA@iii.ca> In-Reply-To: <250E036A-63AB-4705-BFF5-288704FB40CA@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2J7lW764UnRBv1PGS32/F3EbrHirofF /lOXmS0+rP/BaPHtQq3F1OWPWSzW/mtnd2D3WLLkJ5PH5fMfGT1m7XzCEsAcxWWTkpqTWZZa pG+XwJXx7ckr9oJ3chVv/6o1MHbIdTFyckgImEj8mTyfuYuRi0NI4CijREPzL1YI5yujxLWP e6EySxklvvc3MnUxcnCwCVhIdP/TBukWEXCSaH/6CqyGGaS7tXsRI0hCWMBN4v6x+6wQRe4S /a2XWEF6QRq2zQ8AMVkEVCQmNnKBVPAKWEvMvn+HDWLVZUaJdfMXgrVyClhJTJnxAcxmFBCT +H5qDROIzSwgLnHryXwmiA8EJJbsOc8MYYtKvHz8jxXCVpLYe+w6C8guZgFNifW79CFaFSWm dD9kh9grKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWl lmxiBMbcwS2/DXYwvnzueIhRgINRiYfXf8+kaCHWxLLiytxDjBIczEoivK51QCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8Fn6bo4QE0hNLUrNTUwtSi2CyTBycUg2MtYvnO5tWr3Dm9VolJJ/a LpPa7HudQXzqKoGQ/ynhVQJb/kaK12Ve3cVyRPlbD/eSQGVPBndngUfqz34f3v/yZWhyYerS Xcu6d+it/73Kb+bOv1VnN/KnLNwi4cqRL3l0cse+SXOyBP1StpSYX1f68m+B+8JFbleuc1/q 57qTb/ZDUzh+yp2tSizFGYmGWsxFxYkAFUIjLbUCAAA= Archived-At: Subject: Re: [rtcweb] [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 18:29:09 -0000 SGksDQoNCj5UaGF04oCZcyBhIHZlcnkgdXNlZnVsIGdyYXBoIGJ1dCB3aGVuIEkgbG9vayBhdCB0 aGUgd2hhdCBpcyBhY3R1YWxseSB1c2VkIGluIHRoZSBwdXJwbGUgbGlua3MsID5tb3N0IG9mIHRo ZW0gc2VlbSB0aGV5IGNvdWxkIHRyaXZpYWwgd29yayB3aXRoIGFueSB2ZXJzaW9uIG9mIElDRSB3 aXRoIHRoZSBleGNlcHRpb24gb2YgdGhlID5mZXcgcGxhY2VzIHRyaWNrbGUgaXMgdXNlZCBhbmQg bmVlZCB0aGUgZXhwbGljaXQgc3R1ZmYgYXJvdW5kIGhvdyB0byBkZWFsIHdpdGggdHJpY2tsZS4g DQoNClRyaWNrbGUgaXMgYmFzZWQgb24gIkVtaWwncyB0YWJsZSIsIHdoaWNoIGlzIG9uZSBvZiB0 aGUgbWFqb3IgdGhpbmdzIHdlIGRpZCBpbiA4NDQ1LiBTbywgaWYgeW91IGltcGxlbWVudCB0aGF0 IGZvciB0cmlja2xlLCB5b3UndmUgaW1wbGVtZW50ZWQgbW9zdCBvZiA4NDQ1IDopDQoNClRoZSBv dGhlciBtYWpvciB0aGluZyB3ZSBkaWQgaW4gODQ0NSB3YXMgdGhlIHJlbW92YWwgb2YgYWdncmVz c2l2ZSBub21pbmF0aW9uLCB3aGljaCBtYW55IHNlZW0gdG8gaGF2ZSBkb25lIGluIHRoZWlyIGN1 cnJlbnQgaW1wbGVtZW50YXRpb25zIGFueXdheS4uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCj4gT24gU2VwIDYsIDIwMTgsIGF0IDY6NTQgUE0sIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1 bS5jb20+IHdyb3RlOg0KPiANCj4gT24gOS82LzE4IDM6MjQgUE0sIEN1bGxlbiBKZW5uaW5ncyB3 cm90ZToNCj4+IEkgd291bGQgcHJvcG9zZSB0aGF0IGluc3RlYWQgb2YgdGhlIHBhcnRzIG9mIHNw ZWNzIHRoYXQgdXNlIHRoZSB0cmlja2xlIG1lY2hhbmlzbSBwdXJlbHkgcmVmZXJlbmNlIHRoYXQg cGFydCBvZiB0aGUgbmV3IElDRSBzcGVjIHRoYXQgZGVmaW5lcyB0aGUgc3ludGF4IGFuZCBzYXkg dG8gdHJhbnNmZXIgdHJpY2tsZSBjYW5kaWRhdGVzLg0KPiANCj4gDQo+IFVuZm9ydHVuYXRlbHks IGl0J3Mgbm90IHF1aXRlIHNvIHNpbXBsZS4gVGhlIG1pc21hdGNoIHdpdGggdHJpY2tsZS1pY2Ug aXMgb25seSB0aGUgbW9zdCBvYnZpb3VzIHByb2JsZW0uIEluIHByYWN0aWNlLCB0aGVyZSBhcmUg YSBmZXcgZG96ZW4gcGxhY2VzIHdoZXJlIHVucHVibGlzaGVkIGRvY3VtZW50cyBpbiB0aGUgY2x1 c3RlciByZWZlciBkaXJlY3RseSB0byBvbmUgdmVyc2lvbiBvZiBJQ0UsIGFuZCBpbmRpcmVjdGx5 IHRvIGFub3RoZXIsIG9yIGluZGlyZWN0bHkgdG8gYm90aC4NCj4gDQo+IFRvIGhlbHAgd3JhcCBv dXIgY29sbGVjdGl2ZSBtaW5kcyBhcm91bmQgdGhpcyBpc3N1ZSwgSSd2ZSBwdXQgdG9nZXRoZXIg YSBkZXBlbmRlbmN5IGdyYXBoIHRoYXQgc2hvd3Mgd2hpY2ggQ2x1c3RlciAyMzggZG9jdW1lbnRz IHJlZmVyIHRvIHdoaWNoIHZlcnNpb24gb2YgSUNFLiBUaGUgcmVkIGxpbmVzIGluZGljYXRlIHJl ZmVyZW5jZXMgKGRpcmVjdGx5IG9yIGluZGlyZWN0bHkpIHRvIFJGQyA1MjQ1LCB3aGlsZSB0aGUg cHVycGxlIGxpbmVzIGluZGljYXRlIHJlZmVyZW5jZXMgdG8gUkZDIDg0NDUuIFRoZSB0aGlja25l c3Mgb2YgdGhlIGxpbmUgaW5kaWNhdGVzIGhvdyBtYW55IGhvcHMgYXdheSBmcm9tIElDRSB0aGUg cmVmZXJlbmNlIGlzLiBEb3R0ZWQgbGluZXMgYXJlIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+ IA0KPiBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9hcnQvd2lraS9jMjM4DQo+IA0KPiBUbyBw dXQgYSBmaW5lciBwb2ludCBvbiB0aGlzLCBpdCB0b29rIG1lIGEgY291cGxlIG9mIGhvdXJzIHRv IHBhcmUgdGhpcyBncmFwaCBkb3duIHRvIHNvbWV0aGluZyB0aGF0IHdhcyBzbWFsbCBlbm91Z2gg dG8gbG9vayBhdCBhbmQgYWN0dWFsbHkgdW5kZXJzdGFuZCAtLSB0aGVyZSBhcmUgYWN0dWFsbHkg dHdpY2UgYXMgbWFueSBkb2N1bWVudHMgaW52b2x2ZWQgaW4gdGhpcyBtZXNzLCBidXQgaW5jbHVk aW5nIHRoZW0gbWFrZXMgdGhlIHNpdHVhdGlvbiB0b28gY29uZnVzaW5nIHRvIGV2ZW4gc3RhcnQg dG8gZ2V0IGEgZ3JpcCBvbi4NCj4gDQo+IEV2ZXJ5d2hlcmUgeW91IHNlZSBhIHB1cnBsZSBkb2N1 bWVudCB3aXRoIGEgcmVkIGFycm93IG9yIHZpY2UtdmVyc2EgaXMgYSBwbGFjZSB3ZSBuZWVkIHRv IGZpZ3VyZSBvdXQgaG93IHRvIGhhbmRsZSB0aGlzIG1pc21hdGNoLiBZb3UgY2FuIHB1c2ggdGhl IGJvdW5kYXJpZXMgYXJvdW5kLCBidXQgdGhlIGNvdW50IG9mIG1pc21hdGNoZXMgaXMgcHJldHR5 IG11Y2ggdGhlIHNhbWUgbm8gbWF0dGVyIGhvdyB5b3UgZG8gdGhhdC4gT24gYSBmaXJzdCBvcmRl ciBlc3RpbWF0aW9uLCB0aGlzIGlzIGRheXMgLS0gb3IsIG1vcmUgbGlrZWx5LCB3ZWVrcyBvZiB3 b3JrLiBBbmQgSSdtIHRhbGtpbmcgYWJvdXQgcGVyc29uLWhvdXJzLCBub3QgY2FsZW5kYXIgdGlt ZS4gSWYgeW91IGNhbiBkbyB0aGlzLCBvciBmaW5kIHNvbWVvbmUgdG8gc3RlcCB1cCBhbmQgZG8g aXQsIHRoZW4geW91ciBwcm9wb3NhbCB3b3VsZCBiZSBhIHZpYWJsZSBhbHRlcm5hdGl2ZSB0byB0 aGUgb25lIHRoYXQgdGhlIEFSVCBBRHMgaGF2ZSBwcm9wb3NlZC4gU2hvcnQgb2YgdGhhdCwgSSdt IG5vdCBzdXJlIGhvdyB3ZSBjYW4gZG8gd2hhdCB5b3Ugd2FudC4NCj4gDQo+IC9hDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbXVzaWMg bWFpbGluZyBsaXN0DQo+IG1tdXNpY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0KSWNlQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K From nobody Fri Sep 7 12:49:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D465812008A; Fri, 7 Sep 2018 12:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZK4lcviOTSx; Fri, 7 Sep 2018 12:49:20 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 6826E127AC2; Fri, 7 Sep 2018 12:49:20 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id b11-v6so7496416pfo.3; Fri, 07 Sep 2018 12:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jz+LljBeg/I1O6lXsBh9v3cWhxMRhQqzfoQVcgF4X8Y=; b=WSlYLGSqIpdaQfGSqkE/8RHN8UXP/AifyE3nLu6cNTJOPY5xOf9Gwpv57HHNb86e9S 1t1RB98S0GJuPGwlMdB+zHwgDLOPxhR6jK8QSyQkIEkIiIpiuV7Yq9qPuaRt7PvYXsCJ pBb4/8chUm+Ye3Snf6LV+ondpj5rMi1dX3xWUdjwcU5UhfhgDjtuoemHLOnlYCCMpY9S 2w04wh98QVCTYfQX/FCl0/E7J6apNBsqO4EWwX2PyOe1cxzu9eVU1Eu02p5Xr1eclgW4 6ygVA8214+Vxic6PSBZSCvAbGLPTH62ldz+OR3KAF0G93jexC60RtbSiEnlqcPGlKZdA AuWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jz+LljBeg/I1O6lXsBh9v3cWhxMRhQqzfoQVcgF4X8Y=; b=Uh0voNIRFMwDY2PyxDfnLDZWlc1srzbuB9R0vP+fSGMHx/Nl8uOJTeC2qoIotrpNcN 04BVF40AyVaDwgjdLxaf/ATVTny1TXQfHDCN00S1VY3FSmfRod83PgyvUNe6I4COS0/C 4Zut6AxTriZwH/H467INP1ABLe5Hisw+/GnPY/g1V9+iHBwzpcjvg4XUOjaLaad14VwG fxKJCY6nQU8YQBbRc+DVdsmIXttxTFdOBIMw55izgtI/IMMB29tyGk6ssdFCsZWQSyuk 30on/b+iyT08ijnmfjGrUmBXXLefRy7cXvFMdWdbru+3mioL6tv9unrSo8UAP3O9c3J1 gF/g== X-Gm-Message-State: APzg51Aa8i0NZVkATsVGvz3zyLhnmJFkPxJwFVPlTRiZuHo91gAAfBin zgkGUtFlSVIeZG0rdD/dNZFxA1BM X-Google-Smtp-Source: ANB0VdY2fbyyP1e0uqvsbFjh5uRUWTkcU4iW8Aa4K5dpv1+rOU/IDc/0ed5pGwcvx9EIhW6TgpOlgQ== X-Received: by 2002:a62:d2c4:: with SMTP id c187-v6mr10391835pfg.8.1536349759229; Fri, 07 Sep 2018 12:49:19 -0700 (PDT) Received: from ?IPv6:2600:380:463a:a0c9:d578:c8bc:8de4:5575? ([2600:380:463a:a0c9:d578:c8bc:8de4:5575]) by smtp.gmail.com with ESMTPSA id 83-v6sm13277405pft.40.2018.09.07.12.49.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 12:49:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Fri, 7 Sep 2018 12:49:17 -0700 Cc: Cullen Jennings , Applications and Real-Time Area Discussion , "ice@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <670CB2D0-3861-451E-88F4-5CB7F7D8C8D0@gmail.com> References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> To: Christer Holmberg Archived-At: Subject: Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 19:49:22 -0000 On Sep 7, 2018, at 11:25 AM, Christer Holmberg wrote: >=20 > Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not use= aggressive nomination. Trickle is based on 8445, and aggressive nomination w= as deprecated in 8445. So, what exactly are you suggesting the minimum bar f= or WebRTC 1.0 should be? [BA] I am wary of attempts to support too many variations in the matrix of =E2= =80=9CFull Trickle=E2=80=9D/=E2=80=9CHalf Trickle=E2=80=9D and 8445/5245. IMHO, the most likely variants are =E2=80=9CFull Trickle=E2=80=9D/8445 and p= erhaps =E2=80=9CHalf Trickle=E2=80=9D/5245 although I would hope the later w= ill be quickly superceded by the former.= From nobody Fri Sep 7 12:56:38 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6664130DF4 for ; Fri, 7 Sep 2018 12:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxJsoT6Fn2na for ; Fri, 7 Sep 2018 12:56:10 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 0379B130E7B for ; Fri, 7 Sep 2018 12:56:07 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id b30-v6so4755442pla.0 for ; Fri, 07 Sep 2018 12:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kxRleG4LVbpgAlBe0LjjqlFMcVzliWpF4CkmmCyAM6k=; b=Ffyo5oA4o1sFCYLeQTNx+h38wZD1DzSQYWQZy6gexp2+tJKTuiS4LQGvBmLFdO4X3t QKLlfLNhleAMNLTBoBndtM5ecVsiAqmgPmvO3PzldIDxVCgu6zWIR5947M4IkxeYKgJx 4nHbYhyXYuV3ZGeoDmSSxU51OxQ9ToACo7KgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kxRleG4LVbpgAlBe0LjjqlFMcVzliWpF4CkmmCyAM6k=; b=s/HF0pE5/ugxoHh9CcxhOIzv2mo+rGrrXCCa8LFyWMzcdhXg+W6yIVXtu2opeTn0AK 30NOqhXCPM9PgeYRas5+HMSFO9zqB56wHZKWCZ+dpKZN7wbgAF0zbXlcicQku3QO7/kJ l3grzFLKHzfkD+giQUgz/4E6QXvTqFE/rqIbRus/YbvOS6LdwYCZontIJXrLFodo6hYL jJkREB+WCNT2aL/OiDZ6eUj0/n0WWyZURij0QlZ1Zxu9G4YKxd1tQn9CNgf8uKlZBCOS b8FYWgwqq4Neq6BMsOb2NtlEqeIkg3qwQf5iCivmOOFcJBGhPiFFdgraZ2KNJg/j2jQ7 qtmg== X-Gm-Message-State: APzg51BcntuemyngCGqnJZ9nT+trDH3WvWwf0IvVC+uLyoEdsoCcAnLz YESwdohRyYvoaVqbtYTMXQqw9w== X-Google-Smtp-Source: ANB0VdY6euAXdtgztKFykgQya1FaAk2IbnJdNMEicf3YHXOjDMTdcWrUoBk85zGToZmT4BUZiIeZkg== X-Received: by 2002:a17:902:b688:: with SMTP id c8-v6mr9757113pls.114.1536350166255; Fri, 07 Sep 2018 12:56:06 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f1b4:fa2c:dab4:bde9? ([2601:647:4600:3f31:f1b4:fa2c:dab4:bde9]) by smtp.gmail.com with ESMTPSA id s14-v6sm14010290pfj.105.2018.09.07.12.56.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 12:56:04 -0700 (PDT) From: Nils Ohlmeier Message-Id: <52EA7B1E-D7BE-4940-B6C2-9F9AE90D3DAC@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_08F6DABC-271D-484E-82C5-CB686D533A45"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 7 Sep 2018 12:56:02 -0700 In-Reply-To: Cc: Cullen Jennings , Applications and Real-Time Area Discussion , "ice@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , RTCWeb IETF To: Christer Holmberg References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 19:56:12 -0000 --Apple-Mail=_08F6DABC-271D-484E-82C5-CB686D533A45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 7, 2018, at 11:25, Christer Holmberg = wrote: >> dig not indicate an improvement of connectivity rates. I did not see = results from others that did. Some of the early test results from >> others that drove this work were not reproducible in our testing. The = one thing I think most people did find is that the more out of >> sync the pacing of the two agents was, the worse the connectivity = was. But all of this is water under the bridge, we have old and >> new ice, people can use either. What we are talking about here is = what is the minimum bar for WebRTC 1.0 >=20 > Correct me if I'm wrong, but WebRTC 1.0 does use trickle, and does not = use aggressive nomination. Sorry but that is not correct. Firefox does use aggressive nomination. = Chrome (and everyone who copies their full stack including their ICE = implementation) does not. I=E2=80=99m not aware of any normative = language for any of the WebRTC specs demanding to use full nomination = only. Best Nils Ohlmeier --Apple-Mail=_08F6DABC-271D-484E-82C5-CB686D533A45 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAluS19IACgkQY2o/VmzJ +KFOjw/+MWZ85IfbxZvSanUnkY+0hSLAMc/Vw6WkshvflusSE3a29vcj2zT3ffw0 QMZq5HsKSIZSVg3KF/9yMCkgawRtoOPFXynydcOoL9JX5zPOH1uwuivSqcObofYS xWfnEIoL84TkbrkYeSR1G9o2vnJnLRR3QY9hL7cZCFl3rwQ69bxSPXJtuIOghCDH kNjOm+sHT3Sns4VPqsW1nWcVIo/pH7UqhvSBWg0OOy6u9nTkEFvDBx+qXJ6I8C7s mp23B8gdUNfm9aF4QUCquMBUo/tDDLQsx9jW89wQFF2gUALADHOPY/qGqkaTWrEI lWrfjGd6x7mWAiLvmEbK7tSZmUJZzYwu7EwWkqKipV6oqg6tyOGGKPGW90N82vst jkDeLfEnNZX2nV6VynuL5ersFhSSuWnMX5dlKWwNBc5eETu7ezmg8D0hwOuiMK0X x/WrvnF6uXdBMqkqUh/e196ceo7KZxl0OrBX4DC0IQNEMDchOu5zGOwzMOkdGNSb L5y5ZQV5wa6AYJSGN64qFPKJzB8gycSEuLCdxjqehYO97TLwQ8K5X1TQGLiw5i3m woWurFNy1KefBiMV+c9+SmvD5eHzlVbdsMUOKZQD6wQuR0tYLfFlrctRdPRsWybD urSZUjFmXrDR4f/7ySDEc/Rl9avI7X1tcwCKhWizcJCimDVbSe0= =F5k9 -----END PGP SIGNATURE----- --Apple-Mail=_08F6DABC-271D-484E-82C5-CB686D533A45-- From nobody Fri Sep 7 13:01:24 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30E2130DDA for ; Fri, 7 Sep 2018 13:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zor7vfSRwze for ; Fri, 7 Sep 2018 13:01:16 -0700 (PDT) Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 2D684130DDB for ; Fri, 7 Sep 2018 13:01:14 -0700 (PDT) Received: by mail-pf1-x42f.google.com with SMTP id h69-v6so7512023pfd.4 for ; Fri, 07 Sep 2018 13:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5+l+h4Kkb9SvkyUAxZa29pzTRhiJ6ES5UqOqrFmyfrQ=; b=YuXkCpWuQ0LpDcY/Ls6LsVxH3ml+gY3nPiWzqjc3iV3j21hWmWmEbBQunyOa9XJz/x 7EHAm5KzMmiDHcUqm5ai0G9PVh9GXNJRcwyyfNuynTRIHYOXMnQT6BVrmXhzf2SMWsJ2 fCei3opLMIFQLD9P5uxD1r7D2Kk4lv1iCwBFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5+l+h4Kkb9SvkyUAxZa29pzTRhiJ6ES5UqOqrFmyfrQ=; b=mFysWkiEEqRcyID3jZLuUf9eO1s60eY91VslqboyWEpU9urdmwdHb0dukzc1LjeYb8 GK/BUnGa3lRqxBLyil28hkFscNR2W2cK0tg/A8mn1/5df8oXSkeVV01IhcXQm1f9Hqn0 Ibz7IvaRoiu9rcFAgYni/grZkAdCF0YIgTb17t3gFsI3vS31sTMYor9Hy70Bncs3zUON XFGpOKxG6wfWMjodBh+Bb4+SDd99AnUkNMv1ilXvHYjfz1w/1faLugEk+vPw87BiGkqV kFphyk+aQHL+gcGmMIb6/BFgUtCfE7XZIPP54kcrqAIZAS2GPPB0eNKR2f147FAA1Gmo FtpQ== X-Gm-Message-State: APzg51BI7w+9pIvcgmrEbVGPQFJSGu+3b+eS/5HfAnZEiuD44fvUOxrf 9uVF/apLI8qJGw+L9/9avZk+fA== X-Google-Smtp-Source: ANB0Vdac4HoWm0BMwrYwJK58TNRCiUxJTPzHLab/USUOyFbz7163dgZ3BRe2oN6IFbyXWc6W+Dqt0g== X-Received: by 2002:a62:6711:: with SMTP id b17-v6mr10456115pfc.243.1536350473636; Fri, 07 Sep 2018 13:01:13 -0700 (PDT) Received: from ?IPv6:2601:647:4600:3f31:f1b4:fa2c:dab4:bde9? ([2601:647:4600:3f31:f1b4:fa2c:dab4:bde9]) by smtp.gmail.com with ESMTPSA id c78-v6sm12260430pfc.188.2018.09.07.13.01.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 13:01:12 -0700 (PDT) From: Nils Ohlmeier Message-Id: <81680B8E-5F4D-4146-851A-36649E1AAAA2@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D0D594AE-AECF-4650-B2FA-A33012ACD88E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 7 Sep 2018 13:01:09 -0700 In-Reply-To: <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> Cc: Applications and Real-Time Area Discussion , RTCWeb IETF , "clue@ietf.org" , "mmusic@ietf.org" , "ice@ietf.org" To: Cullen Jennings References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 20:01:17 -0000 --Apple-Mail=_D0D594AE-AECF-4650-B2FA-A33012ACD88E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 6, 2018, at 13:24, Cullen Jennings wrote: >=20 >=20 > Cisco has implemented stuff that is WebRTC 1.0 compliant without this = change. These gratuitous changes, years after the implementation were = coded, with no real benefit will ensure that we are not and will not = become compliant with the RFC. It's unlikely we will upgrade to the new = ICE until it has real befits. It is doubtful Justin will want to = implement the 8445 mechanisms of supporting both new and old ICE. = Instead, we will move to say "works with Browser X version Y or = later.=E2=80=9D Obviously I=E2=80=99m not Justin. But the current plan for Firefox is to implement support for 8845 some = time in 2019 and then have support for 5245 and 8845 going forward. Best regards Nils Ohlmeier --Apple-Mail=_D0D594AE-AECF-4650-B2FA-A33012ACD88E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAluS2QUACgkQY2o/VmzJ +KF0mhAAh6E7Y6heS7u/CPqAYJaaPDhA9sg9JfUDb39rYer8HOvkc0IgrLMwOpK+ qiABe2+8LC1WO7jQaeSRUwXh7BfermB6depkHLtrm565Qj5POEhsjMNRlH0osv76 Rj6nB7rfLtUU9rsYv/bKXGrfRYWX0Fkyfh9akp4B1FhlyLCbevRd9z5yx/xo8RO/ jaJrWQj3uVRAIrY6I268fxe15vD/hDicibGRF01SLLj9gIF/tEnv02c8lbKdSLEO ggxtQ9iYovyTh8RcTBCSTMz/hgWKrefNW3pRkEfdB7o1wqXGSaNnMO/cHYSf0jDC QgcCb7uAR6GtFVvaAHXZsezk2GTiGIpHDcPY4EGpXBCT1QePzLVhlFh0/+LVh5AG i1wLTX+h8+3+nr8jOTAlcudtufAJDMKKU6ef1vqzQx8H6AVy+ArZcMLp9BZjziBu HTpObQcqPs+zNvjJk8EMyqyFff3bAgfkqqy6lvKH9a/i8AkNaXI9batqDFHsNuDU YxOLdOksq5r/qTPiFXV54rfJ2uqFTzD0UfZmPTJxbho4wzAHIuka04YOOs2HxzRF 52yYciUMQCFWlK+GsUCmKryRpaSmI4WLgRf/06xpAs5tWnZr1GOc9dCK4UqRajCX EzAHcDE/05kW1Kp+fckS6LG3QHLYOiH8QoK34IDXtTub7O18UYA= =1C1Q -----END PGP SIGNATURE----- --Apple-Mail=_D0D594AE-AECF-4650-B2FA-A33012ACD88E-- From nobody Sat Sep 8 00:48:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9983130E12 for ; Sat, 8 Sep 2018 00:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqzABxwtOQti for ; Sat, 8 Sep 2018 00:48:37 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31F512F1A5 for ; Sat, 8 Sep 2018 00:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536392915; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1N8l0+TrtqmGzZDSGg57W9v7ZciSfQq8kEc/E17uwRE=; b=dB9kOFIsanib6dTyp8CBRnVqSNQfmLDXVpAUKg/1R6DllJWWaPmO1HEmPE6RA8s0 UDyKbH8z3BTVzJ1GQ4o/3cvua8kNhVP+femxnZSWRoik4mf5m6+MUgU4o6YxwMv6 RAPgayJwLDMpq57jFfF6acwMQG+LApuxJOZfctoAdko=; X-AuditID: c1b4fb30-ff9ff700000055da-29-5b937ed39423 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.36.21978.3DE739B5; Sat, 8 Sep 2018 09:48:35 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 8 Sep 2018 09:48:34 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sat, 8 Sep 2018 09:48:34 +0200 From: Christer Holmberg To: Nils Ohlmeier , Cullen Jennings CC: Applications and Real-Time Area Discussion , RTCWeb IETF , "mmusic@ietf.org" , "clue@ietf.org" , "ice@ietf.org" Thread-Topic: [MMUSIC] [rtcweb] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURuWPZreWlI5zSUCNFBIlXO5ivqTmAmpw Date: Sat, 8 Sep 2018 07:48:34 +0000 Message-ID: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <81680B8E-5F4D-4146-851A-36649E1AAAA2@mozilla.com> In-Reply-To: <81680B8E-5F4D-4146-851A-36649E1AAAA2@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2J7se7lusnRBjdusFmsuOthsf/UZWaL D+t/MFp8u1BrMXX5YxaL6/MmM1qs/dfO7sDusWTJTyaPy+c/Mnr0HehiDWCO4rJJSc3JLEst 0rdL4MrYd/wee8E1jooLJz+zNzDu4Ohi5OSQEDCR6Fg8l62LkYtDSOAoo8T61l+MEM5XRonX L5ZCZZYySnzY2s/SxcjBwSZgIdH9TxukW0TAS+La9R/sIDXMIN1TllxhAUkICzhLHJt4ggmi yEXi7sz1LBC2kcSxnlVsIDaLgIrE658LGEFsXgFriad7PrFALFvMKNG64BJYA6eAvcThn9vZ QWxGATGJ76fWgA1lFhCXuPVkPhPEDwISS/acZ4awRSVePv7HCmErSew9dh3saGYBTYn1u/Qh WhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlWMYoWpxYn5aYbGemlFmUmFxfn 5+nlpZZsYgRG3sEtvw12ML587niIUYCDUYmHNy11crQQa2JZcWXuIUYJDmYlEd5paUAh3pTE yqrUovz4otKc1OJDjNIcLErivBZ+m6OEBNITS1KzU1MLUotgskwcnFINjH18T9eVXkmvvLCT x26vN/NV3V0JD7OEbyZ7JxVUJ1QzlNvYdK6Zk6EjGctuwG/lZ6LJ8+JXc2lrRFRs7+sl+5z+ +U5i2dVYXPvBouGCKEtC8IkQjVCvHK/y5bv55yy22+epz9m/Rqx2eZ5oMb/dw93TO2YJcpz+ pvF4MZP0n+qj01qOt5xTYinOSDTUYi4qTgQAd6zuGrgCAAA= Archived-At: Subject: Re: [rtcweb] [MMUSIC] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 07:48:40 -0000 SGkgTmlscywNCg0KPj4gQ2lzY28gaGFzIGltcGxlbWVudGVkIHN0dWZmIHRoYXQgaXMgV2ViUlRD IDEuMCBjb21wbGlhbnQgd2l0aG91dCB0aGlzIGNoYW5nZS4gVGhlc2UgDQo+PiBncmF0dWl0b3Vz IGNoYW5nZXMsIHllYXJzIGFmdGVyIHRoZSBpbXBsZW1lbnRhdGlvbiB3ZXJlIGNvZGVkLCB3aXRo IG5vIHJlYWwgYmVuZWZpdCANCj4+IHdpbGwgZW5zdXJlIHRoYXQgd2UgYXJlIG5vdCBhbmQgd2ls bCBub3QgYmVjb21lIGNvbXBsaWFudCB3aXRoIHRoZSBSRkMuIEl0J3MgdW5saWtlbHkgd2UgDQo+ PiB3aWxsIHVwZ3JhZGUgdG8gdGhlIG5ldyBJQ0UgdW50aWwgaXQgaGFzIHJlYWwgYmVmaXRzLiBJ dCBpcyBkb3VidGZ1bCBKdXN0aW4gd2lsbCB3YW50IHRvIGltcGxlbWVudCANCj4+IHRoZSA4NDQ1 IG1lY2hhbmlzbXMgb2Ygc3VwcG9ydGluZyBib3RoIG5ldyBhbmQgb2xkIElDRS4gSW5zdGVhZCwg d2Ugd2lsbCBtb3ZlIHRvIHNheSAid29ya3MgDQo+PiB3aXRoIEJyb3dzZXIgWCB2ZXJzaW9uIFkg b3IgbGF0ZXIu4oCdDQo+DQo+IE9idmlvdXNseSBJ4oCZbSBub3QgSnVzdGluLg0KPiBCdXQgdGhl IGN1cnJlbnQgcGxhbiBmb3IgRmlyZWZveCBpcyB0byBpbXBsZW1lbnQgc3VwcG9ydCBmb3IgODg0 NSBzb21lIHRpbWUgaW4gMjAxOSBhbmQgdGhlbiBoYXZlIA0KPiBzdXBwb3J0IGZvciA1MjQ1IGFu ZCA4ODQ1IGdvaW5nIGZvcndhcmQuDQoNCkRvIHlvdSBoYXZlIGFueSBpZGVhcywgb24gYSBoaWdo IGxldmVsLCBob3cgYmlnIHRoZSBkaWZmZXJlbmNlcyB3aWxsIGJlPw0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQo= From nobody Sat Sep 8 00:57:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F98130DBE for ; Sat, 8 Sep 2018 00:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSKOarLI1DZE for ; Sat, 8 Sep 2018 00:56:51 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA52B130DEC for ; Sat, 8 Sep 2018 00:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536393406; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zhZAutLXyaIcItL598yiw1QuHbz30KNK8yQe5zq3YVY=; b=Gldx9uL3vZXI0c3QqE1Rc2+OcMSh3dBMcoCa2YsE3KXiROXlCvMSrdZInpmRnOez JIYclGWtLBk58bFAaGQ8PNP4DVTh7KghDnw+st4E8p3qcNJn+iHh/EAY68yKW9BC umSa8DMEIlt5kHQICws8Mw/r4IaqZrx6O08AVMo+Gig=; X-AuditID: c1b4fb30-fe1ff700000055da-25-5b9380be2fe1 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1B.17.21978.EB0839B5; Sat, 8 Sep 2018 09:56:46 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 8 Sep 2018 09:56:46 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sat, 8 Sep 2018 09:56:46 +0200 From: Christer Holmberg To: Nils Ohlmeier CC: Cullen Jennings , "Applications and Real-Time Area Discussion" , "ice@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , RTCWeb IETF Thread-Topic: [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 Thread-Index: AQHURh+v3CEVPFpjI0266oWKAGTzsaTkftOAgABlSICAADz38P//+sMAgADoqRA= Date: Sat, 8 Sep 2018 07:56:46 +0000 Message-ID: References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <52EA7B1E-D7BE-4940-B6C2-9F9AE90D3DAC@mozilla.com> In-Reply-To: <52EA7B1E-D7BE-4940-B6C2-9F9AE90D3DAC@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2J7pe6+hsnRBk//y1usuOthsf/UZWaL D+t/MFp8u1BrMXX5YxaL6/MmM1qs/dfO7sDusWTJTyaPy+c/Mnr0HehiDWCO4rJJSc3JLEst 0rdL4MrYe+gRY8E33orFkz+wNzCe4O1i5OSQEDCReNY0na2LkYtDSOAoo8Sh67fZQRJCAl8Z JU4eYIdILGWUOLjuL2MXIwcHm4CFRPc/bRBTREBT4sRGPpASZoFXjBITv61hA+kVFrCV2Njx CcwWEbCTuL3pMguE7Sfx8vIlVhCbRUBF4tPW2ewgc3gFrCWeny+DWLWbSWLd+ZVg9ZwC9hIP Gt8ygtiMAmIS30+tYQKxmQXEJW49mc8E8YCAxJI955khbFGJl4//sULYShJ7j11nAZnPDHTn +l36EK2KElO6H4K9yCsgKHFy5hOWCYxis5BMnYXQMQtJxywkHQsYWVYxihanFiflphsZ6aUW ZSYXF+fn6eWllmxiBMbcwS2/DXYwvnzueIhRgINRiYc3LXVytBBrYllxZe4hRgkOZiUR3mlp QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Fn6bo4QE0hNLUrNTUwtSi2CyTBycUg2Mmrl3BI9/ XLVf9It1skTB7Mp/rZ6XIjedj+BeVKGn6d01tf9qwHIdoVeC6wx3sR610q+ZoxrQIphYtPnF 7J8fblh+yS55Jx62K8vR0astLGQ348/nH3rKJt3SP7j60aw1u3g3RG+rzzpyf7reAr7djhd+ /bj+U/fVIcbNGvGmCa7zBKbeLv5RpMRSnJFoqMVcVJwIAC1qMxu1AgAA Archived-At: Subject: Re: [rtcweb] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2018 07:56:53 -0000 SGksDQoNCj4+PiBkaWcgbm90IGluZGljYXRlIGFuIGltcHJvdmVtZW50IG9mIGNvbm5lY3Rpdml0 eSByYXRlcy4gSSBkaWQgbm90IHNlZSANCj4+PiByZXN1bHRzIGZyb20gb3RoZXJzIHRoYXQgZGlk LiBTb21lIG9mIHRoZSBlYXJseSB0ZXN0IHJlc3VsdHMgZnJvbSANCj4+PiBvdGhlcnMgdGhhdCBk cm92ZSB0aGlzIHdvcmsgd2VyZSBub3QgcmVwcm9kdWNpYmxlIGluIG91ciB0ZXN0aW5nLiBUaGUg DQo+Pj4gb25lIHRoaW5nIEkgdGhpbmsgbW9zdCBwZW9wbGUgZGlkIGZpbmQgaXMgdGhhdCB0aGUg bW9yZSBvdXQgb2Ygc3luYyANCj4+PiB0aGUgcGFjaW5nIG9mIHRoZSB0d28gYWdlbnRzIHdhcywg dGhlIHdvcnNlIHRoZSBjb25uZWN0aXZpdHkgd2FzLiBCdXQgDQo+Pj4gYWxsIG9mIHRoaXMgaXMg d2F0ZXIgdW5kZXIgdGhlIGJyaWRnZSwgd2UgaGF2ZSBvbGQgYW5kIG5ldyBpY2UsIA0KPj4+IHBl b3BsZSBjYW4gdXNlIGVpdGhlci4gV2hhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCBoZXJlIGlzIHdo YXQgaXMgdGhlIA0KPj4+IG1pbmltdW0gYmFyIGZvciBXZWJSVEMgMS4wDQo+PiANCj4+IENvcnJl Y3QgbWUgaWYgSSdtIHdyb25nLCBidXQgV2ViUlRDIDEuMCBkb2VzIHVzZSB0cmlja2xlLCBhbmQg ZG9lcyBub3QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4NCj4NCj4gU29ycnkgYnV0IHRoYXQg aXMgbm90IGNvcnJlY3QuIEZpcmVmb3ggZG9lcyB1c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uLiBD aHJvbWUgKGFuZCBldmVyeW9uZSB3aG8gY29waWVzIHRoZWlyIA0KPiBmdWxsIHN0YWNrIGluY2x1 ZGluZyB0aGVpciBJQ0UgaW1wbGVtZW50YXRpb24pIGRvZXMgbm90LiBJ4oCZbSBub3QgYXdhcmUg b2YgYW55IG5vcm1hdGl2ZSBsYW5ndWFnZSBmb3IgYW55IG9mIHRoZSANCj4gV2ViUlRDIHNwZWNz IGRlbWFuZGluZyB0byB1c2UgZnVsbCBub21pbmF0aW9uIG9ubHkuDQoNCldpdGggImZ1bGwgbm9t aW5hdGlvbiIgSSBhc3N1bWUgeW91IG1lYW4gcmVndWxhciBub21pbmF0aW9uIChhcyBkZWZpbmVk IGluIDUyNDUpPw0KDQpNeSBwb2ludCB3YXMgdGhhdCBXZWJSVEMgZGVmaW5lcyB0aGUgdXNhZ2Ug b2YgIm5vbWluYXRpb24iLCB3aGljaCBpcyB0aGUgdGVybWlub2xvZ3kgODQ0NSB1c2VzLiBJIGFt IG5vdCBzYXlpbmcgaXQncyBmb3JiaWRkZW4gdG8gdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwg YnV0IGFzIGZhciBhcyBJIGtub3cgKEkgbWF5IGJlIHdyb25nKSB1c2FnZSBvZiBpdCBpcyBub3Qg bWVudGlvbmVkIGFueXdoZXJlLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Mon Sep 10 08:07:23 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C965130DFD for ; Mon, 10 Sep 2018 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_H7sPIG_z4i for ; Mon, 10 Sep 2018 08:07:20 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E950C1277BB for ; Mon, 10 Sep 2018 08:07:19 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id o15-v6so24488430qtk.6 for ; Mon, 10 Sep 2018 08:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=rBkRd3XSQuTwi5jWPhOmUdBu9wqz2awbgvMYTHeonyA=; b=KSkL8Rl9SsDNPqRy9VwZ5ii7hld26vW5JaL8dZhhO4Hf/naxvk1YqksKUmqT5HAMBR hm7qovMnZg2ilVe13lQiLnIfeDEfsmau+UReHP8nhhMSwRQBmsnim1GDIsLh/LSqtMP+ 3Mmf2T5jOUXYZbNF8EcMekscAUnBXEeLxFurs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=rBkRd3XSQuTwi5jWPhOmUdBu9wqz2awbgvMYTHeonyA=; b=sTexSS8WoAnrOwd5fTuhlHM8ReLR7rS6TDXiE3/uAJdt2hJu6Pt1+9NzWjJbQ0+T6K tPCgSNN2vffz4xa/RwZrGmgJnFb8hNtKF7UhuySKZE2Ibqers6fuZ434JWdYiujr3t+u 6JFQjxQpiqoux9xE03pOgdZ56f6Kkmx4FyBby6GUGAx/rlYrzryZt91fpryvAT40F1AJ zhnOBTxvQ/8sMtVJYqS8h+l+swwWvb956jsjpQNz1ks86sq1cytVpI2tHJ+/O5ZMvyco ti+lYxsbj0NalwRFuF5G+PY7zgpScO5zcjS5bWdigbewqVLmbOMPAR1LGOLdtXILF6V6 zhdg== X-Gm-Message-State: APzg51C7CYCV3BDv1RL4maRJyO1HhYUELRJ92jaQG2YNYfbtb5vLy9dH ZgT9qxhpJ2D2NqsJPVlDUrur4q1md4k= X-Google-Smtp-Source: ANB0VdbuaWjq3Sk/oJHF3kjiGdCnnRZrQBPD1DRK55VymP/x5X3uMIjE9CtMUfWr4UH161E3YTO6wA== X-Received: by 2002:ac8:1b83:: with SMTP id z3-v6mr16488227qtj.321.1536592038799; Mon, 10 Sep 2018 08:07:18 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.107]) by smtp.gmail.com with ESMTPSA id o15-v6sm10649529qtj.46.2018.09.10.08.07.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 08:07:17 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 10 Sep 2018 11:07:16 -0400 References: To: RTCWeb IETF , draft-mdns-ice-candidates@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] WG adoption call: draft-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 15:07:21 -0000 Hi, it seems like we had enough interest based on Montreal=E2=80=99s session = and mailing list to adopt this a WG item. Remember the plan is to adopt = this and then if the draft needs to be split - it=E2=80=99ll get split. Authors - please submit the draft as = draft-ietf-rtcweb-mdns-ice-candidates at your earliest convenience. spt > On Jul 27, 2018, at 20:42, Sean Turner wrote: >=20 > The consensus in the RFCWEB@IETF102 room was that the WG should adopt = https://datatracker.ietf.org/doc/draft-mdns-ice-candidates/ as a WG = item. But, we need to confirm this on list. If you would like for this = draft to become a WG document and you are willing to review it as it = moves through the process, then please let the list know by 2359UTC = 20180810. If you are opposed to this being a WG document, please say so = (and say why). >=20 > Note that the draft has been marked as a =E2=80=9CCall for Adoption by = WG Issued=E2=80=9D in the datatracker. >=20 > Thanks - spt From nobody Mon Sep 10 09:13:13 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F758130EDA for ; Mon, 10 Sep 2018 09:13:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153659598112.26539.10607776396129766348.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2018 09:13:01 -0700 From: IETF Secretariat Archived-At: Subject: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 16:13:12 -0000 Changed milestone "Complete Overview (and hold for dependency resolution) (draft-ietf-rtcweb-overview)", resolved as "Done". Changed milestone "Send Security and Privacy Problem Statement (draft-ietf- rtcweb-security) to IESG for publication as Informational", added draft-ietf-rtcweb-ip-handling to milestone. Changed milestone "Send Media Transport (draft-ietf-rtcweb-rtp-usage) to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Audio Processing and Audio Codecs (draft-ietf-rtcweb-audio) to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Send Data Stream Transport for non-media data (draft-ietf- rtcweb-data-channel) to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Send Specification of Transport Protocols and their NAT Traversal to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Send Signalling Negotiation and NAT Traversal (draft-ietf- rtcweb-jsep) to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Send STUN Usage for Consent Freshness to IESG for publication as proposed standard", resolved as "Done". Changed milestone "Video Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed StandardVideo Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for publication as Proposed Standard", resolved as "Done", added draft-ietf-rtcweb-video to milestone. Changed milestone "Send Overview (after dependencies are ready) to IESG for publication as Applicability Statement", resolved as "Done". URL: https://datatracker.ietf.org/wg/rtcweb/about/ From nobody Mon Sep 10 09:23:40 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292BB130E6F for ; Mon, 10 Sep 2018 09:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6du9sT1t8Lw for ; Mon, 10 Sep 2018 09:23:36 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47562130E52 for ; Mon, 10 Sep 2018 09:23:36 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id k38-v6so24803337qtk.11 for ; Mon, 10 Sep 2018 09:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Uh+b7R+y3mQ4obtlRUsSSlniQfyzWIiYmKuheBDr+Pk=; b=TNaY0uQ22GpCt+CwwGHbtpJKSRmmuywzl48uHqlyyL/fa8EhLDFGtZdp3fr0efEWNb VYyp2yDV7a4Ebm2orVhjaVsH28tpx7EiF8GCtEnzSSnbJ/dOPizjn8RmeuXxbbfDFapr UOMmd1RZxfmHqWcNZBXz7TpwBMTN1o7GxpsmU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Uh+b7R+y3mQ4obtlRUsSSlniQfyzWIiYmKuheBDr+Pk=; b=dxkRlsHhLgbylZD6NfVRLuiIq/CJtY43eEK0g0Ie5UWWd4ogQHePl/n0jy0gqpYE06 JYAfMrmLEUENDVctJ9eZ+QXsjtqj21U0+34UAmAO9nzM09y7UbXsHeJa5aB6yjALxidv QxqLdJPQCQzOpisF0JVywKk6YV+vcRxUZwBmz8aOi6LkD79pyppRjZlxQjvj1Jug50Vr Wrd/yLaB2pOsVcEtRVdQPNMeObo9GU110Bzoi8hAUp+Y2Mnp5Ru/mo38Eg6qHOIcp62Z oKemlLSqlszEffeRZNu9eSL6N9fY8soOCWNLkDTUy0KN+YCAxPQbk/6CeNXrHQpcSxU7 aqlQ== X-Gm-Message-State: APzg51D97tF3AWWw24O7eREUas/F0zEiYUNxXonO2pp7Ml8KWfnVrT+b T9a0srpYrDszaVivSALphElfNLBDlo0= X-Google-Smtp-Source: ANB0VdZ/9VchDWG+L2/hRS8hbz8tcwQDgd8Ue+CUAWz+jT7ENilLagldXHiaGCEYEca70zXZ5eQrAg== X-Received: by 2002:a0c:a482:: with SMTP id x2-v6mr14973530qvx.76.1536596615251; Mon, 10 Sep 2018 09:23:35 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.107]) by smtp.gmail.com with ESMTPSA id r13-v6sm12699269qta.7.2018.09.10.09.23.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 09:23:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 10 Sep 2018 12:23:33 -0400 References: <153659598112.26539.10607776396129766348.idtracker@ietfa.amsl.com> To: RTCWeb IETF In-Reply-To: <153659598112.26539.10607776396129766348.idtracker@ietfa.amsl.com> Message-Id: <19BBBA16-377A-42AF-85EE-1BFEE42955DB@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 16:23:38 -0000 Obviously, just doing some house keeping. spt > On Sep 10, 2018, at 12:13, IETF Secretariat = wrote: >=20 > Changed milestone "Complete Overview (and hold for dependency = resolution) > (draft-ietf-rtcweb-overview)", resolved as "Done". >=20 > Changed milestone "Send Security and Privacy Problem Statement = (draft-ietf- > rtcweb-security) to IESG for publication as Informational", added > draft-ietf-rtcweb-ip-handling to milestone. >=20 > Changed milestone "Send Media Transport (draft-ietf-rtcweb-rtp-usage) = to IESG > for publication as Proposed Standard", resolved as "Done". >=20 > Changed milestone "Audio Processing and Audio Codecs > (draft-ietf-rtcweb-audio) to IESG for publication as Proposed = Standard", > resolved as "Done". >=20 > Changed milestone "Send Data Stream Transport for non-media data = (draft-ietf- > rtcweb-data-channel) to IESG for publication as Proposed Standard", = resolved > as "Done". >=20 > Changed milestone "Send Specification of Transport Protocols and their = NAT > Traversal to IESG for publication as Proposed Standard", resolved as = "Done". >=20 > Changed milestone "Send Signalling Negotiation and NAT Traversal = (draft-ietf- > rtcweb-jsep) to IESG for publication as Proposed Standard", resolved = as > "Done". >=20 > Changed milestone "Send STUN Usage for Consent Freshness to IESG for > publication as proposed standard", resolved as "Done". >=20 > Changed milestone "Video Processing and Video Codecs > (draft-ietf-rtcweb-video) to IESG for publication as Proposed = StandardVideo > Processing and Video Codecs (draft-ietf-rtcweb-video) to IESG for = publication > as Proposed Standard", resolved as "Done", added = draft-ietf-rtcweb-video to > milestone. >=20 > Changed milestone "Send Overview (after dependencies are ready) to = IESG for > publication as Applicability Statement", resolved as "Done". >=20 > URL: https://datatracker.ietf.org/wg/rtcweb/about/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Sep 11 06:36:15 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C4112F1A2 for ; Tue, 11 Sep 2018 06:36:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153667297362.16780.15629192781826662297.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2018 06:36:13 -0700 From: IETF Secretariat Archived-At: Subject: [rtcweb] Milestones changed for rtcweb WG X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 13:36:14 -0000 Changed milestone "Send Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-rtcweb-mdns-ice-candidates) to IESG as Informational", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/rtcweb/about/ From nobody Wed Sep 12 06:36:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872AD130DC8 for ; Wed, 12 Sep 2018 06:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1j47bYgCGFx for ; Wed, 12 Sep 2018 06:36:08 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 01B1E1252B7 for ; Wed, 12 Sep 2018 06:36:07 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id w11-v6so187151iob.2 for ; Wed, 12 Sep 2018 06:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dLXMN2YCFs+GJNRfn5P3l0NYVpmqAXLWnwjwHp13OKg=; b=skHixXNtdzkkmlkfisEugHuECIrmDl9TAby0TBHGDq+kl/VsJZfE4hsvCtEN7eIaZk Etk1xAwc+GXmEA8gzQCgC7L/A6zLJDrK7qepQ78QOf/+ICM71+ya4qZIN+QP0kp1wb5G /8Whtbha3rMcn+naEDt0n18fqUGEAvLi+K4e/SGCYKncFKFN6ZWTBjTGnvEeYmvlMGj/ ejf+HN/dIKHd23+EA9IYd0cZ2QXZgE0O288vqSOzbdecwlIFXHEP7QzW/Uwgk+YNMDa0 TJuzrf+pLaFcBpzfbZwiXVPn+YzUfe6oLkkDO2IOTrbeOUpYtHXDCCi8WdXvkBXTuEdj yUcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dLXMN2YCFs+GJNRfn5P3l0NYVpmqAXLWnwjwHp13OKg=; b=qyDM5Vc/j7zVEns9VDR9IgiGqA37ZZfaunlkVrUIO9G1Sf9sV5iPSKfUQjpB5fkAMd WpjZ/rVKENPDriDn42VTraT7C5KLyD1pWgoY7X2twVcDkkv95V1Bynna8gzrzW+GBr11 yJmlFWiC2TfpBP5tiWpcKhb0n0TaLCXWljfWUW9Ku//cMfVRxZXWGQZ/5Bap9ZUUYlb5 yfjniGgs8k53jSdYH+A7mwbnuiKpN98FAsuzadFV+dkLfycfRwV+Mk3Wb7BfL40iKuYL Hdqg0fipVcIN2bBmZs92h9Tvcoxy8xfZuVPEe9p4xqWgMLq4ynUo5KUaXVRJIu4metOp TdJQ== X-Gm-Message-State: APzg51DVR8vAeeVhelipZ41phpOHaSAHhNCHKnrfnjl5WW94S+vH+i0s NqymRLcD33C+nN2hIOSeOiXenyGU5f/BSjwCgJv9qDCrmdpQKA== X-Google-Smtp-Source: ANB0VdZ8HiVuw2LTe634cw8RQIlqeSxsdz4IKyeDgy+q6Toljbvwf1vtPekZoC768YHhXihB++lUBFBYvcPU1aN3nc8= X-Received: by 2002:a6b:de0c:: with SMTP id v12-v6mr1700759iog.121.1536759366830; Wed, 12 Sep 2018 06:36:06 -0700 (PDT) MIME-Version: 1.0 From: James Pearce Date: Wed, 12 Sep 2018 14:35:51 +0100 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002a6bcb0575acac71" Archived-At: Subject: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 13:36:10 -0000 --0000000000002a6bcb0575acac71 Content-Type: text/plain; charset="UTF-8" Hi, I have a quesion about the use of getUserMedia to obtain user consent for Mode 1 operation. I have an application that uses WebRTC to deliver real-time media streams in one direction only. Client applications are consumers only, in some cases the client devices do not have any media capture capability. I'm trying to develop a strategy for deploying the application on the public web so, naturally, my plan is to use TURN to relay through NAT. I've run into trouble with a) The requirement that Mode 1 is needed to use TURN b) User consent for Mode 1 is tied to getUserMedia() Firstly, it's not clear to me why there is a restriction on using TURN in mode 2. Does TURN reveal address information that would otherwise be hidden to the peer? I've noticed that Chrome seems to use TURN even without consent being given. Firefox does not. Secondly, with no capture devices, getUserMedia can never succeed, thus, a user can never give consent for Mode 1. This is unfortunate, as WebRTC is ideal for some applications that require one-way streaming to limited-spec devices. Granted, not many devices today have no capture capability, but even when they do, requesting permission to access a microphone when it'll never be needed is confusing to end users. Is there a better mechanism we can use to obtain consent when getUserMedia is not necessary? I know I've raised this issue tangentially before, but having to explain issues to end users is beginning to wear thin. It's becoming a headache. Thanks, James --0000000000002a6bcb0575acac71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0
<= br>
I have a quesion about the use of getUserMedia to obtain user= consent for Mode 1 operation.

I have an applicati= on that uses WebRTC to deliver real-time media streams in one direction onl= y. Client applications are consumers only, in some cases the client devices= do not have any media capture capability.
I'm trying to deve= lop a strategy for deploying the application on the public web so, naturall= y, my plan is to use TURN to relay through NAT.

I&= #39;ve run into trouble with=C2=A0
=C2=A0 a) The requirement that= Mode 1 is needed to use TURN
=C2=A0 b) User consent for Mode 1 i= s tied to getUserMedia()

Firstly, it's not cle= ar to me why there is a restriction on using TURN in mode 2. Does TURN reve= al address information that would otherwise be hidden to the peer? I've= noticed that Chrome seems to use TURN even without consent being given. Fi= refox does not.

Secondly, with no capture devices,= getUserMedia can never succeed, thus, a user can never give consent for Mo= de 1. This is unfortunate, as WebRTC is ideal for some applications that re= quire one-way streaming to limited-spec devices. Granted, not many devices = today have no capture capability, but even when they do, requesting permiss= ion to access a microphone when it'll never be needed is confusing to e= nd users. Is there a better mechanism we can use to obtain consent when get= UserMedia is not necessary?


I know = I've raised this issue tangentially before, but having to explain issue= s to end users is beginning to wear thin. It's becoming a headache.

Thanks,

James
--0000000000002a6bcb0575acac71-- From nobody Wed Sep 12 07:47:21 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF691130DD8 for ; Wed, 12 Sep 2018 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sxiJCpdaTEM for ; Wed, 12 Sep 2018 07:47:17 -0700 (PDT) Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24C41292AD for ; Wed, 12 Sep 2018 07:47:16 -0700 (PDT) Received: (qmail 22329 invoked from network); 12 Sep 2018 14:47:14 -0000 X-APM-Authkey: 255286/0(159927/0) 1629 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 12 Sep 2018 14:47:14 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id AD0DB18A04F1; Wed, 12 Sep 2018 15:47:14 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4Fs4SUbmzNcW; Wed, 12 Sep 2018 15:47:14 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 812DA18A01FD; Wed, 12 Sep 2018 15:47:14 +0100 (BST) From: westhawk Message-Id: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_63683A57-EC0A-4AC2-A519-0D4F97D72A97" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 12 Sep 2018 15:47:13 +0100 In-Reply-To: Cc: RTCWeb IETF To: James Pearce References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 14:47:20 -0000 --Apple-Mail=_63683A57-EC0A-4AC2-A519-0D4F97D72A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yeah, I call this the =E2=80=9CYou have to take a selfie before you fly = the drone=E2=80=9D problem. I=E2=80=99ve just filed a GitHub issue on it for the use case spec for = webRTC NV. https://github.com/w3c/webrtc-nv-use-cases/issues/1 = Feel free to add commentary there as well as here. T. > On 12 Sep 2018, at 14:35, James Pearce wrote: >=20 >=20 > Hi,=20 >=20 > I have a quesion about the use of getUserMedia to obtain user consent = for Mode 1 operation. >=20 > I have an application that uses WebRTC to deliver real-time media = streams in one direction only. Client applications are consumers only, = in some cases the client devices do not have any media capture = capability. > I'm trying to develop a strategy for deploying the application on the = public web so, naturally, my plan is to use TURN to relay through NAT. >=20 > I've run into trouble with=20 > a) The requirement that Mode 1 is needed to use TURN > b) User consent for Mode 1 is tied to getUserMedia() >=20 > Firstly, it's not clear to me why there is a restriction on using TURN = in mode 2. Does TURN reveal address information that would otherwise be = hidden to the peer? I've noticed that Chrome seems to use TURN even = without consent being given. Firefox does not. >=20 > Secondly, with no capture devices, getUserMedia can never succeed, = thus, a user can never give consent for Mode 1. This is unfortunate, as = WebRTC is ideal for some applications that require one-way streaming to = limited-spec devices. Granted, not many devices today have no capture = capability, but even when they do, requesting permission to access a = microphone when it'll never be needed is confusing to end users. Is = there a better mechanism we can use to obtain consent when getUserMedia = is not necessary? >=20 >=20 > I know I've raised this issue tangentially before, but having to = explain issues to end users is beginning to wear thin. It's becoming a = headache. >=20 > Thanks, >=20 > James > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_63683A57-EC0A-4AC2-A519-0D4F97D72A97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yeah,= I call this the =E2=80=9CYou have to take a selfie before you fly the = drone=E2=80=9D problem.
I=E2=80=99ve just filed a GitHub = issue on it for the use case spec for webRTC NV.

https://github.com/w3c/webrtc-nv-use-cases/issues/1

Feel free to add = commentary there as well as here.

T.


On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com> wrote:


Hi, 

I have a quesion about the use of = getUserMedia to obtain user consent for Mode 1 operation.

I have an application = that uses WebRTC to deliver real-time media streams in one direction = only. Client applications are consumers only, in some cases the client = devices do not have any media capture capability.
I'm= trying to develop a strategy for deploying the application on the = public web so, naturally, my plan is to use TURN to relay through = NAT.

I've run = into trouble with 
  a) The requirement = that Mode 1 is needed to use TURN
  b) User = consent for Mode 1 is tied to getUserMedia()

Firstly, it's not clear to me why there = is a restriction on using TURN in mode 2. Does TURN reveal address = information that would otherwise be hidden to the peer? I've noticed = that Chrome seems to use TURN even without consent being given. Firefox = does not.

Secondly, with no capture devices, getUserMedia can never = succeed, thus, a user can never give consent for Mode 1. This is = unfortunate, as WebRTC is ideal for some applications that require = one-way streaming to limited-spec devices. Granted, not many devices = today have no capture capability, but even when they do, requesting = permission to access a microphone when it'll never be needed is = confusing to end users. Is there a better mechanism we can use to obtain = consent when getUserMedia is not necessary?


I = know I've raised this issue tangentially before, but having to explain = issues to end users is beginning to wear thin. It's becoming a = headache.

Thanks,

James
_______________________________________________
rtcweb = mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_63683A57-EC0A-4AC2-A519-0D4F97D72A97-- From nobody Wed Sep 12 12:58:06 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC8F130E16 for ; Wed, 12 Sep 2018 12:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHx2MfEAEB2u for ; Wed, 12 Sep 2018 12:58:01 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07C6130D7A for ; Wed, 12 Sep 2018 12:58:01 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id j198-v6so12786179ita.0 for ; Wed, 12 Sep 2018 12:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2J9VRY9peHWrTCc16oPQ7MTrG0hmIQ5sX7Rp8HDWHHE=; b=mZOK8HVP61vLlKH0jpKoEiGiq7opuQNI5IbgJYXosh9gLCtlZ33V01tefaGKU5V1+s CSJ1j7mhL4doczr9sTKmp9f76/st1WY9TTmwbIHnth6IZhxvIB9QQwhEIzkeTh2xe00o vz5AAUZRyUdm0X8e+nQC+x5J9I6LNL4muczat6kYI7ZijbYify9yFZBbx+z9Np+LGRhi 9lRXOAIyT3Y1CUE4HH7JwjINPP9kQjukSrX9GEz1Y/WwsVml4lwH6wxrDV43qzVIexCD QbMrZ+feySsbcT6UVe3FoKBaYC+surDHEsneGSyiqOb4ySQR7kUpyVLUc4q9SfimvpD2 AGHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2J9VRY9peHWrTCc16oPQ7MTrG0hmIQ5sX7Rp8HDWHHE=; b=X0pOn/1dG0f+Jm9D/Vg1r8uDHYd/A1yqVIRTxUWFaVpkK7Y8sEGAuDEjiF5Yqub//v gwPmAfDmtzpVsO7cY6e/XuOlIf/WJUeTh8UiRMOUKgLMNZJNds5L+r/MkqCOhNE0QeYn ZuxEjPJYo8b2JKjDF+2SaEVbz1IuSuClwHngxXMcXgIyWr5z7z23reWpGAXAcqITk3Zc rOUVub5hH3AOa5K/zM80LqPDKsX2v2Of2LWSItS2L+dO7QZVCN5Sm8pxXj08HhGh0DhO uECh4ZJcqsQEA8JY0fDB7CL/yRJVaEyc+di+IFLEKsFmNmKKTHmIKr3MOP0Tkf3jYLF7 pL0g== X-Gm-Message-State: APzg51DIa6PdVHjF33nWhRzmtcsVff4dvr5v6SBnWMo0F7d4IKP5ZHkZ qktEY0oS0OXBJUEg6M9EvmijTyChS6HPeZebzrdfnun7Hb4= X-Google-Smtp-Source: ANB0VdatXR1jjpBj91NRBt6NKWdQHjRyU68EXVRUXkuMD8gsijs5bixoQzoltt5BlbJrNW1m0tBPOlRg/+PEC7NWoR0= X-Received: by 2002:a02:5651:: with SMTP id o78-v6mr3626037jab.8.1536782280938; Wed, 12 Sep 2018 12:58:00 -0700 (PDT) MIME-Version: 1.0 References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> In-Reply-To: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> From: James Pearce Date: Wed, 12 Sep 2018 20:57:44 +0100 Message-ID: To: thp@westhawk.co.uk Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000f3ee570575b20176" Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 19:58:05 -0000 --000000000000f3ee570575b20176 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's interesting - in the GitHub comments, you say that without Mode 1, you have to use TURN. It's my understanding that Mode 1 is also required for TURN - that's certainly what the spec seems to say. I know Firefox will not enumerate relay ice candidates until I've called getUserMedia(). James On Wed, 12 Sep 2018 at 15:47, westhawk wrote: > Yeah, I call this the =E2=80=9CYou have to take a selfie before you fly t= he drone=E2=80=9D > problem. > I=E2=80=99ve just filed a GitHub issue on it for the use case spec for we= bRTC NV. > > https://github.com/w3c/webrtc-nv-use-cases/issues/1 > > Feel free to add commentary there as well as here. > > T. > > > On 12 Sep 2018, at 14:35, James Pearce wrote: > > > Hi, > > I have a quesion about the use of getUserMedia to obtain user consent for > Mode 1 operation. > > I have an application that uses WebRTC to deliver real-time media streams > in one direction only. Client applications are consumers only, in some > cases the client devices do not have any media capture capability. > I'm trying to develop a strategy for deploying the application on the > public web so, naturally, my plan is to use TURN to relay through NAT. > > I've run into trouble with > a) The requirement that Mode 1 is needed to use TURN > b) User consent for Mode 1 is tied to getUserMedia() > > Firstly, it's not clear to me why there is a restriction on using TURN in > mode 2. Does TURN reveal address information that would otherwise be hidd= en > to the peer? I've noticed that Chrome seems to use TURN even without > consent being given. Firefox does not. > > Secondly, with no capture devices, getUserMedia can never succeed, thus, = a > user can never give consent for Mode 1. This is unfortunate, as WebRTC is > ideal for some applications that require one-way streaming to limited-spe= c > devices. Granted, not many devices today have no capture capability, but > even when they do, requesting permission to access a microphone when it'l= l > never be needed is confusing to end users. Is there a better mechanism we > can use to obtain consent when getUserMedia is not necessary? > > > I know I've raised this issue tangentially before, but having to explain > issues to end users is beginning to wear thin. It's becoming a headache. > > Thanks, > > James > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000f3ee570575b20176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's interesting - in the GitHub comments, you say t= hat without Mode 1, you have to use TURN.
It's my understanding tha= t Mode 1 is also required for TURN - that's certainly what the spec see= ms to say. I know Firefox will not enumerate relay ice candidates until I&#= 39;ve called getUserMedia().

James

=
On Wed, 12 Sep 2018 at 15:47, w= esthawk <thp@westhawk.co.uk>= ; wrote:
Yeah, I call this the =E2=80=9CYou h= ave to take a selfie before you fly the drone=E2=80=9D problem.
I=E2=80= =99ve just filed a GitHub issue on it for the use case spec for webRTC NV.<= /div>


Feel free to add commentary there as = well as here.

T.


On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com>= wrote:

<= div>

Hi,=C2=A0

I have a quesion about the use of getUserMedia to obtain = user consent for Mode 1 operation.

I have an appli= cation that uses WebRTC to deliver real-time media streams in one direction= only. Client applications are consumers only, in some cases the client dev= ices do not have any media capture capability.
I'm trying to = develop a strategy for deploying the application on the public web so, natu= rally, my plan is to use TURN to relay through NAT.

I've run into trouble with=C2=A0
=C2=A0 a) The requirement = that Mode 1 is needed to use TURN
=C2=A0 b) User consent for Mode= 1 is tied to getUserMedia()

Firstly, it's not= clear to me why there is a restriction on using TURN in mode 2. Does TURN = reveal address information that would otherwise be hidden to the peer? I= 9;ve noticed that Chrome seems to use TURN even without consent being given= . Firefox does not.

Secondly, with no capture devi= ces, getUserMedia can never succeed, thus, a user can never give consent fo= r Mode 1. This is unfortunate, as WebRTC is ideal for some applications tha= t require one-way streaming to limited-spec devices. Granted, not many devi= ces today have no capture capability, but even when they do, requesting per= mission to access a microphone when it'll never be needed is confusing = to end users. Is there a better mechanism we can use to obtain consent when= getUserMedia is not necessary?


I k= now I've raised this issue tangentially before, but having to explain i= ssues to end users is beginning to wear thin. It's becoming a headache.=

Thanks,

James
_______________________________________________
rtcweb mailing list
<= a href=3D"mailto:rtcweb@ietf.org" target=3D"_blank">rtcweb@ietf.org
= = https://www.ietf.org/mailman/listinfo/rtcweb

--000000000000f3ee570575b20176-- From nobody Wed Sep 12 13:19:19 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D1B130D7A for ; Wed, 12 Sep 2018 13:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulNKQLfWTvPy for ; Wed, 12 Sep 2018 13:19:10 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771CB130EB2 for ; Wed, 12 Sep 2018 13:19:09 -0700 (PDT) Received: (qmail 51720 invoked from network); 12 Sep 2018 20:19:08 -0000 X-APM-Authkey: 255286/0(159927/0) 2311 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 12 Sep 2018 20:19:08 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 03AFB18A1028; Wed, 12 Sep 2018 21:19:08 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 45OAShj6JeM9; Wed, 12 Sep 2018 21:19:07 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 954A918A0244; Wed, 12 Sep 2018 21:19:07 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: westhawk In-Reply-To: Date: Wed, 12 Sep 2018 21:19:05 +0100 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> To: James Pearce X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 20:19:14 -0000 > On 12 Sep 2018, at 20:57, James Pearce wrote: >=20 > That's interesting - in the GitHub comments, you say that without Mode = 1, you have to use TURN. > It's my understanding that Mode 1 is also required for TURN - that's = certainly what the spec seems to say. I know Firefox will not enumerate = relay ice candidates until I've called getUserMedia(). No, Mode 3 explicitly supports TURN: " Default route only: This is the the same as Mode 2, except that the = associated private address MUST NOT be provided. This may cause traffic = to hairpin through a NAT, fall back to the application TURN server, or = fail altogether, with resulting quality implications. =E2=80=9C I suppose I should write some test code to verify what is actually = happening... I see Safari 12 looks like supporting MDNS names in ICE candidates. It is definitely a mess.=20 T. >=20 > James >=20 > On Wed, 12 Sep 2018 at 15:47, westhawk wrote: > Yeah, I call this the =E2=80=9CYou have to take a selfie before you = fly the drone=E2=80=9D problem. > I=E2=80=99ve just filed a GitHub issue on it for the use case spec for = webRTC NV. >=20 > https://github.com/w3c/webrtc-nv-use-cases/issues/1 >=20 > Feel free to add commentary there as well as here. >=20 > T. >=20 >=20 >> On 12 Sep 2018, at 14:35, James Pearce wrote: >>=20 >>=20 >> Hi,=20 >>=20 >> I have a quesion about the use of getUserMedia to obtain user consent = for Mode 1 operation. >>=20 >> I have an application that uses WebRTC to deliver real-time media = streams in one direction only. Client applications are consumers only, = in some cases the client devices do not have any media capture = capability. >> I'm trying to develop a strategy for deploying the application on the = public web so, naturally, my plan is to use TURN to relay through NAT. >>=20 >> I've run into trouble with=20 >> a) The requirement that Mode 1 is needed to use TURN >> b) User consent for Mode 1 is tied to getUserMedia() >>=20 >> Firstly, it's not clear to me why there is a restriction on using = TURN in mode 2. Does TURN reveal address information that would = otherwise be hidden to the peer? I've noticed that Chrome seems to use = TURN even without consent being given. Firefox does not. >>=20 >> Secondly, with no capture devices, getUserMedia can never succeed, = thus, a user can never give consent for Mode 1. This is unfortunate, as = WebRTC is ideal for some applications that require one-way streaming to = limited-spec devices. Granted, not many devices today have no capture = capability, but even when they do, requesting permission to access a = microphone when it'll never be needed is confusing to end users. Is = there a better mechanism we can use to obtain consent when getUserMedia = is not necessary? >>=20 >>=20 >> I know I've raised this issue tangentially before, but having to = explain issues to end users is beginning to wear thin. It's becoming a = headache. >>=20 >> Thanks, >>=20 >> James >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 From nobody Wed Sep 12 14:56:20 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ECA126F72; Wed, 12 Sep 2018 14:56:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <153678937808.9522.4000911693895472411@ietfa.amsl.com> Date: Wed, 12 Sep 2018 14:56:18 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-mdns-ice-candidates-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 21:56:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Using Multicast DNS to protect privacy when exposing ICE candidates Authors : Youenn Fablet Jeroen De Borst Justin Uberti Qingsi Wang Filename : draft-ietf-rtcweb-mdns-ice-candidates-00.txt Pages : 7 Date : 2018-09-12 Abstract: WebRTC applications rely on ICE candidates to enable peer-to-peer connections between clients in as many network configurations as possible. To maximize the probability to create a direct peer-to- peer connection, client private IP addresses are often exposed without user consent. This is currently used as a way to track users. This document describes a way to share IP addresses with other clients while preserving client privacy. This is achieved by obfuscating IP addresses using dynamically generated names resolvable through Multicast DNS [RFC6763]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-mdns-ice-candidates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-00 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-mdns-ice-candidates-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 12 23:00:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D584130F61 for ; Wed, 12 Sep 2018 23:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fGfbrCjl81Y for ; Wed, 12 Sep 2018 23:00:41 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1082130E1B for ; Wed, 12 Sep 2018 23:00:40 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id v14-v6so2228798iob.4 for ; Wed, 12 Sep 2018 23:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RMFvcj7GRPllh/sE/pW0sLwZgO5r3e9/ZsjJAUAfRGo=; b=E3lN6asSt/wJdolnahG9XBXB2mFjUe9ydbqGYd7ORiIrllQ1CYXCcKAcNgS52QDcPg fr5HF4NxM24ZqpkBZcsa5QXDSOc6TSxXLWiU/S9psbiKcD73KktfjUoNEosYdbVT8+lP ZJ71FcfuVZuLOUc/ji5zBwWBRiITCgMVeHEflOWLE2C5WqRb/c/kgwF2fnIhmYqSV3Nq 5uTJ/+POOTp624v7bTlyyI8+e+K471MA1aHAWpAE8MDJZ5+HsfJ49anYKC4HNil7PUsg yGlScYKPRfmDTLgTBQ0UEx76NDMP3/AP9QOCVutuRJvpGMLu6O3UkZNu7Vr6ZSMqTYHv 4a8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RMFvcj7GRPllh/sE/pW0sLwZgO5r3e9/ZsjJAUAfRGo=; b=h5NOjfXCCBGuzeg0JOeADLlA8FlE1vi8gn/J3cuwMzeL3IQA4CraHSYD0ZDWhnAwqD 40fnmjKzqMvamtlMHhawwWbpPMXw2OfxPDoBZ4tX5tqtdK224Zz8xotOvaA+i1/EF0t9 zGGnO2Uxd48PSmdzVI/DMh1ohim8amexi3qXW/e+IXZ3Ob0Nepm66wfUM+/cFBnung3P WRSzY8Kbh2clRyl+UzlIKI3HEVGsJkG9wSQXMSdpPAjfHK9e86mMomlWc209bUE6/XfK y9hA2zAyGbQGpofp+5FiOIOXXjpkTAs/995/f0fyJwdzDncqWPRBpyOxPwt+86GP/PUL Q5LA== X-Gm-Message-State: APzg51BXJfM+uqHqtj1qYYOj0hEJTFAJ6Z91fOn5dYtmsozEW9mzWViB uRGS5CtYhBKCXrirPG7Oh6NFLaKNWWuLehCiIk4VioPzJfw= X-Google-Smtp-Source: ANB0VdYI6ONURRV0WZNjzdE9+nXawezULyvV2B/c0cB20/vpUQimQkh8zDPxy7kUOlSQjrjC7fCqAzpVvCyQ0LAVk4U= X-Received: by 2002:a6b:e70d:: with SMTP id b13-v6mr5051526ioh.38.1536818439616; Wed, 12 Sep 2018 23:00:39 -0700 (PDT) MIME-Version: 1.0 References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> In-Reply-To: From: Justin Uberti Date: Wed, 12 Sep 2018 23:00:28 -0700 Message-ID: To: Tim Panton Cc: James Pearce , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002dff9f0575ba6dee" Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 06:00:44 -0000 --0000000000002dff9f0575ba6dee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mode 1 is not needed for TURN. On Wed, Sep 12, 2018 at 1:19 PM westhawk wrote: > > > > On 12 Sep 2018, at 20:57, James Pearce wrote: > > > > That's interesting - in the GitHub comments, you say that without Mode > 1, you have to use TURN. > > It's my understanding that Mode 1 is also required for TURN - that's > certainly what the spec seems to say. I know Firefox will not enumerate > relay ice candidates until I've called getUserMedia(). > > No, Mode 3 explicitly supports TURN: > > " > Default route only: This is the the same as Mode 2, except that the > associated private address MUST NOT be provided. This may cause traffic t= o > hairpin through a NAT, fall back to the application TURN server, or fail > altogether, with resulting quality implications. > =E2=80=9C > > I suppose I should write some test code to verify what is actually > happening... > > I see Safari 12 looks like supporting MDNS names in ICE candidates. > > It is definitely a mess. > > T. > > > > > > > > James > > > > On Wed, 12 Sep 2018 at 15:47, westhawk wrote: > > Yeah, I call this the =E2=80=9CYou have to take a selfie before you fly= the > drone=E2=80=9D problem. > > I=E2=80=99ve just filed a GitHub issue on it for the use case spec for = webRTC NV. > > > > https://github.com/w3c/webrtc-nv-use-cases/issues/1 > > > > Feel free to add commentary there as well as here. > > > > T. > > > > > >> On 12 Sep 2018, at 14:35, James Pearce wrote: > >> > >> > >> Hi, > >> > >> I have a quesion about the use of getUserMedia to obtain user consent > for Mode 1 operation. > >> > >> I have an application that uses WebRTC to deliver real-time media > streams in one direction only. Client applications are consumers only, in > some cases the client devices do not have any media capture capability. > >> I'm trying to develop a strategy for deploying the application on the > public web so, naturally, my plan is to use TURN to relay through NAT. > >> > >> I've run into trouble with > >> a) The requirement that Mode 1 is needed to use TURN > >> b) User consent for Mode 1 is tied to getUserMedia() > >> > >> Firstly, it's not clear to me why there is a restriction on using TURN > in mode 2. Does TURN reveal address information that would otherwise be > hidden to the peer? I've noticed that Chrome seems to use TURN even witho= ut > consent being given. Firefox does not. > >> > >> Secondly, with no capture devices, getUserMedia can never succeed, > thus, a user can never give consent for Mode 1. This is unfortunate, as > WebRTC is ideal for some applications that require one-way streaming to > limited-spec devices. Granted, not many devices today have no capture > capability, but even when they do, requesting permission to access a > microphone when it'll never be needed is confusing to end users. Is there= a > better mechanism we can use to obtain consent when getUserMedia is not > necessary? > >> > >> > >> I know I've raised this issue tangentially before, but having to > explain issues to end users is beginning to wear thin. It's becoming a > headache. > >> > >> Thanks, > >> > >> James > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000002dff9f0575ba6dee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mode 1 is not needed for TURN.

On Wed, Sep 12, 2018 at 1:19 PM westhawk <thp@westhawk.co.uk> wrote:


> On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> wrote:
>
> That's interesting - in the GitHub comments, you say that without = Mode 1, you have to use TURN.
> It's my understanding that Mode 1 is also required for TURN - that= 's certainly what the spec seems to say. I know Firefox will not enumer= ate relay ice candidates until I've called getUserMedia().

No, Mode 3 explicitly supports TURN:

"
Default route only: This is the the same as Mode 2, except that the associa= ted private address MUST NOT be provided. This may cause traffic to hairpin= through a NAT, fall back to the application TURN server, or fail altogethe= r, with resulting quality implications.
=E2=80=9C

I suppose I should write some test code to verify what is actually happenin= g...

I see Safari 12 looks like supporting MDNS names in ICE candidates.

It is definitely a mess.

T.




>
> James
>
> On Wed, 12 Sep 2018 at 15:47, westhawk <thp@westhawk.co.uk> wrote:
> Yeah, I call this the =E2=80=9CYou have to take a selfie before you fl= y the drone=E2=80=9D problem.
> I=E2=80=99ve just filed a GitHub issue on it for the use case spec for= webRTC NV.
>
> https://github.com/w3c/webrtc-nv-use-cases/i= ssues/1
>
> Feel free to add commentary there as well as here.
>
> T.
>
>
>> On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com> wrote:
>>
>>
>> Hi,
>>
>> I have a quesion about the use of getUserMedia to obtain user cons= ent for Mode 1 operation.
>>
>> I have an application that uses WebRTC to deliver real-time media = streams in one direction only. Client applications are consumers only, in s= ome cases the client devices do not have any media capture capability.
>> I'm trying to develop a strategy for deploying the application= on the public web so, naturally, my plan is to use TURN to relay through N= AT.
>>
>> I've run into trouble with
>>=C2=A0 =C2=A0a) The requirement that Mode 1 is needed to use TURN >>=C2=A0 =C2=A0b) User consent for Mode 1 is tied to getUserMedia() >>
>> Firstly, it's not clear to me why there is a restriction on us= ing TURN in mode 2. Does TURN reveal address information that would otherwi= se be hidden to the peer? I've noticed that Chrome seems to use TURN ev= en without consent being given. Firefox does not.
>>
>> Secondly, with no capture devices, getUserMedia can never succeed,= thus, a user can never give consent for Mode 1. This is unfortunate, as We= bRTC is ideal for some applications that require one-way streaming to limit= ed-spec devices. Granted, not many devices today have no capture capability= , but even when they do, requesting permission to access a microphone when = it'll never be needed is confusing to end users. Is there a better mech= anism we can use to obtain consent when getUserMedia is not necessary?
>>
>>
>> I know I've raised this issue tangentially before, but having = to explain issues to end users is beginning to wear thin. It's becoming= a headache.
>>
>> Thanks,
>>
>> James
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000002dff9f0575ba6dee-- From nobody Thu Sep 13 00:02:19 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102D1130F72 for ; Thu, 13 Sep 2018 00:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxkYOuwdM5y7 for ; Thu, 13 Sep 2018 00:02:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A9D4F130E2D for ; Thu, 13 Sep 2018 00:02:14 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8D726k7017992 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Sep 2018 02:02:09 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Justin Uberti , Tim Panton Cc: RTCWeb IETF , James Pearce References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> From: Adam Roach Message-ID: <104bf6e8-183a-fbd6-7651-772ee68a0ef4@nostrum.com> Date: Thu, 13 Sep 2018 02:02:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------377CF72E3583CFC4C433BD09" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 07:02:17 -0000 This is a multi-part message in MIME format. --------------377CF72E3583CFC4C433BD09 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To be clear, if you're seeing Firefox behave in a way that doesn't comply with the ip-handling specification, please either file a bug at , or send me an email that describes exact steps to reproduce the issue you're seeing and an explanation of what is happening versus what should be happening, and I'll forward it to the relevant parties. /a On 9/13/18 1:00 AM, Justin Uberti wrote: > Mode 1 is not needed for TURN. > > On Wed, Sep 12, 2018 at 1:19 PM westhawk > wrote: > > > > > On 12 Sep 2018, at 20:57, James Pearce > wrote: > > > > That's interesting - in the GitHub comments, you say that > without Mode 1, you have to use TURN. > > It's my understanding that Mode 1 is also required for TURN - > that's certainly what the spec seems to say. I know Firefox will > not enumerate relay ice candidates until I've called getUserMedia(). > > No, Mode 3 explicitly supports TURN: > > " > Default route only: This is the the same as Mode 2, except that > the associated private address MUST NOT be provided. This may > cause traffic to hairpin through a NAT, fall back to the > application TURN server, or fail altogether, with resulting > quality implications. > “ > > I suppose I should write some test code to verify what is actually > happening... > > I see Safari 12 looks like supporting MDNS names in ICE candidates. > > It is definitely a mess. > > T. > > > > > > > > James > > > > On Wed, 12 Sep 2018 at 15:47, westhawk > wrote: > > Yeah, I call this the “You have to take a selfie before you fly > the drone” problem. > > I’ve just filed a GitHub issue on it for the use case spec for > webRTC NV. > > > > https://github.com/w3c/webrtc-nv-use-cases/issues/1 > > > > Feel free to add commentary there as well as here. > > > > T. > > > > > >> On 12 Sep 2018, at 14:35, James Pearce > wrote: > >> > >> > >> Hi, > >> > >> I have a quesion about the use of getUserMedia to obtain user > consent for Mode 1 operation. > >> > >> I have an application that uses WebRTC to deliver real-time > media streams in one direction only. Client applications are > consumers only, in some cases the client devices do not have any > media capture capability. > >> I'm trying to develop a strategy for deploying the application > on the public web so, naturally, my plan is to use TURN to relay > through NAT. > >> > >> I've run into trouble with > >>   a) The requirement that Mode 1 is needed to use TURN > >>   b) User consent for Mode 1 is tied to getUserMedia() > >> > >> Firstly, it's not clear to me why there is a restriction on > using TURN in mode 2. Does TURN reveal address information that > would otherwise be hidden to the peer? I've noticed that Chrome > seems to use TURN even without consent being given. Firefox does not. > >> > >> Secondly, with no capture devices, getUserMedia can never > succeed, thus, a user can never give consent for Mode 1. This is > unfortunate, as WebRTC is ideal for some applications that require > one-way streaming to limited-spec devices. Granted, not many > devices today have no capture capability, but even when they do, > requesting permission to access a microphone when it'll never be > needed is confusing to end users. Is there a better mechanism we > can use to obtain consent when getUserMedia is not necessary? > >> > >> > >> I know I've raised this issue tangentially before, but having > to explain issues to end users is beginning to wear thin. It's > becoming a headache. > >> > >> Thanks, > >> > >> James > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------377CF72E3583CFC4C433BD09 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
To be clear, if you're seeing Firefox behave in a way that doesn't comply with the ip-handling specification, please either file a bug at <https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=WebRTC>, or send me an email that describes exact steps to reproduce the issue you're seeing and an explanation of what is happening versus what should be happening, and I'll forward it to the relevant parties.

/a

On 9/13/18 1:00 AM, Justin Uberti wrote:
Mode 1 is not needed for TURN.

On Wed, Sep 12, 2018 at 1:19 PM westhawk <thp@westhawk.co.uk> wrote:


> On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> wrote:
>
> That's interesting - in the GitHub comments, you say that without Mode 1, you have to use TURN.
> It's my understanding that Mode 1 is also required for TURN - that's certainly what the spec seems to say. I know Firefox will not enumerate relay ice candidates until I've called getUserMedia().

No, Mode 3 explicitly supports TURN:

"
Default route only: This is the the same as Mode 2, except that the associated private address MUST NOT be provided. This may cause traffic to hairpin through a NAT, fall back to the application TURN server, or fail altogether, with resulting quality implications.
“

I suppose I should write some test code to verify what is actually happening...

I see Safari 12 looks like supporting MDNS names in ICE candidates.

It is definitely a mess.

T.




>
> James
>
> On Wed, 12 Sep 2018 at 15:47, westhawk <thp@westhawk.co.uk> wrote:
> Yeah, I call this the “You have to take a selfie before you fly the drone” problem.
> I’ve just filed a GitHub issue on it for the use case spec for webRTC NV.
>
> https://github.com/w3c/webrtc-nv-use-cases/issues/1
>
> Feel free to add commentary there as well as here.
>
> T.
>
>
>> On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com> wrote:
>>
>>
>> Hi,
>>
>> I have a quesion about the use of getUserMedia to obtain user consent for Mode 1 operation.
>>
>> I have an application that uses WebRTC to deliver real-time media streams in one direction only. Client applications are consumers only, in some cases the client devices do not have any media capture capability.
>> I'm trying to develop a strategy for deploying the application on the public web so, naturally, my plan is to use TURN to relay through NAT.
>>
>> I've run into trouble with
>>   a) The requirement that Mode 1 is needed to use TURN
>>   b) User consent for Mode 1 is tied to getUserMedia()
>>
>> Firstly, it's not clear to me why there is a restriction on using TURN in mode 2. Does TURN reveal address information that would otherwise be hidden to the peer? I've noticed that Chrome seems to use TURN even without consent being given. Firefox does not.
>>
>> Secondly, with no capture devices, getUserMedia can never succeed, thus, a user can never give consent for Mode 1. This is unfortunate, as WebRTC is ideal for some applications that require one-way streaming to limited-spec devices. Granted, not many devices today have no capture capability, but even when they do, requesting permission to access a microphone when it'll never be needed is confusing to end users. Is there a better mechanism we can use to obtain consent when getUserMedia is not necessary?
>>
>>
>> I know I've raised this issue tangentially before, but having to explain issues to end users is beginning to wear thin. It's becoming a headache.
>>
>> Thanks,
>>
>> James
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>

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

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


--------------377CF72E3583CFC4C433BD09-- From nobody Thu Sep 13 08:28:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C18A130E06 for ; Thu, 13 Sep 2018 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGOBL46_KOKr for ; Thu, 13 Sep 2018 08:28:00 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 9AB5A1200D7 for ; Thu, 13 Sep 2018 08:28:00 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id r196-v6so3500659iod.0 for ; Thu, 13 Sep 2018 08:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LBBSZgw+jdlDai+MBoBd/yeOQpSgT2ny8gSgDN+iAbw=; b=qcWImZPhwa9UTiNpONw9Yv+ede2dz2tMyej58jz+QR51wltUwNcT8nxMeNR4hQlhhn BKwHS3Ccxw76lv/5z4pKQHVHepmk6qIgdELDBexAsuGUoZR7Q5I/1q9BdDIL3tTkH3IC qt8nHAISRnY66RCOZvZZIDfcEx2XCiJnIfyj57UWMKmWt1YHDtCUlrXf6I/O4YF9UfmY SQvheHpXX8bFX2MDLbAzabZJ7yOICDvtqZq8WH36QF0Ub24daKDWTeg3tUAwINoxHS5L BVHlYF6967+kk+wEr+qSWRB3Ds/iXUmwoUpJTWdK3eOF32OXM7yyxEPlSFKpTkd+NGRN BfBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LBBSZgw+jdlDai+MBoBd/yeOQpSgT2ny8gSgDN+iAbw=; b=G53AJGmo3PDvVQvJTLYgyqG3ThhCbHW8BjcqCY2hpt6ktAISQvBux1lBucvNdtyNsA 4i9tGOcI6IGqmuw+y37XP8jgR7yQ9wFlPaXgNLYU9VtJIaPq4ISOtl1eUf8yQb969MuM 0cjALQXvhjv1AGMyNHzz/aWsmIqD3F+2zEmPtxkrsltH9XRz/V1HActWP0vc43jaiBTY /ldlmK6LSR06Z0SuelvTlhSE5ybzjJ8T1xjBbO5Eg192K7/YGiUTOh1UzM5tl5WKQ1c4 UnSLn80ikh+J2kZWuK9E+Q/Mzed+Kgb74qDkJN5aHbRJiGm+v+RuSyag7e2QpfWfLwgW 6eWg== X-Gm-Message-State: APzg51ALJ22lUmkunGIoJ5muc4EEoiUSJN/yJoqmM4WKJJfRXSsUH6i2 4dOYYP6PbwZ+ZCrx6NqBvUGYOKSgb20t0LjHOtWtbA== X-Google-Smtp-Source: ANB0VdZqrxxY6K0ltrR5pReRcL9ReQl/WitbZB2llQxnv5llTdqYY6u32JZsXpRENjXhhuqpROOWdhY8bueyuzni2v4= X-Received: by 2002:a6b:9303:: with SMTP id v3-v6mr6443027iod.264.1536852479769; Thu, 13 Sep 2018 08:27:59 -0700 (PDT) MIME-Version: 1.0 References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> <104bf6e8-183a-fbd6-7651-772ee68a0ef4@nostrum.com> In-Reply-To: <104bf6e8-183a-fbd6-7651-772ee68a0ef4@nostrum.com> From: James Pearce Date: Thu, 13 Sep 2018 16:27:43 +0100 Message-ID: To: Adam Roach Cc: juberti=40google.com@dmarc.ietf.org, Tim Panton , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000002129f10575c25a47" Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 15:28:03 -0000 --0000000000002129f10575c25a47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With Firefox, I may be running into a different variant of the bug I entered before: *Bug 1384265 * If I add a TURN iceServer, and set iceTransportPolicy to relay, but never call GUM, Chrome will connect, but Firefox won't. However, the TURN server is on a VPN network. That bug above is about Firefox not choosing the route to the origin when in mode 1. I guess that would also mean it wouldn't use that supplied TURN server either. James On Thu, 13 Sep 2018 at 08:02, Adam Roach wrote: > To be clear, if you're seeing Firefox behave in a way that doesn't comply > with the ip-handling specification, please either file a bug at > > , > or send me an email that describes exact steps to reproduce the issue > you're seeing and an explanation of what is happening versus what should = be > happening, and I'll forward it to the relevant parties. > > /a > > On 9/13/18 1:00 AM, Justin Uberti wrote: > > Mode 1 is not needed for TURN. > > On Wed, Sep 12, 2018 at 1:19 PM westhawk wrote: > >> >> >> > On 12 Sep 2018, at 20:57, James Pearce wrote: >> > >> > That's interesting - in the GitHub comments, you say that without Mode >> 1, you have to use TURN. >> > It's my understanding that Mode 1 is also required for TURN - that's >> certainly what the spec seems to say. I know Firefox will not enumerate >> relay ice candidates until I've called getUserMedia(). >> >> No, Mode 3 explicitly supports TURN: >> >> " >> Default route only: This is the the same as Mode 2, except that the >> associated private address MUST NOT be provided. This may cause traffic = to >> hairpin through a NAT, fall back to the application TURN server, or fail >> altogether, with resulting quality implications. >> =E2=80=9C >> >> I suppose I should write some test code to verify what is actually >> happening... >> >> I see Safari 12 looks like supporting MDNS names in ICE candidates. >> >> It is definitely a mess. >> >> T. >> >> >> >> >> > >> > James >> > >> > On Wed, 12 Sep 2018 at 15:47, westhawk wrote: >> > Yeah, I call this the =E2=80=9CYou have to take a selfie before you fl= y the >> drone=E2=80=9D problem. >> > I=E2=80=99ve just filed a GitHub issue on it for the use case spec for= webRTC >> NV. >> > >> > https://github.com/w3c/webrtc-nv-use-cases/issues/1 >> > >> > Feel free to add commentary there as well as here. >> > >> > T. >> > >> > >> >> On 12 Sep 2018, at 14:35, James Pearce wrote: >> >> >> >> >> >> Hi, >> >> >> >> I have a quesion about the use of getUserMedia to obtain user consent >> for Mode 1 operation. >> >> >> >> I have an application that uses WebRTC to deliver real-time media >> streams in one direction only. Client applications are consumers only, i= n >> some cases the client devices do not have any media capture capability. >> >> I'm trying to develop a strategy for deploying the application on the >> public web so, naturally, my plan is to use TURN to relay through NAT. >> >> >> >> I've run into trouble with >> >> a) The requirement that Mode 1 is needed to use TURN >> >> b) User consent for Mode 1 is tied to getUserMedia() >> >> >> >> Firstly, it's not clear to me why there is a restriction on using TUR= N >> in mode 2. Does TURN reveal address information that would otherwise be >> hidden to the peer? I've noticed that Chrome seems to use TURN even with= out >> consent being given. Firefox does not. >> >> >> >> Secondly, with no capture devices, getUserMedia can never succeed, >> thus, a user can never give consent for Mode 1. This is unfortunate, as >> WebRTC is ideal for some applications that require one-way streaming to >> limited-spec devices. Granted, not many devices today have no capture >> capability, but even when they do, requesting permission to access a >> microphone when it'll never be needed is confusing to end users. Is ther= e a >> better mechanism we can use to obtain consent when getUserMedia is not >> necessary? >> >> >> >> >> >> I know I've raised this issue tangentially before, but having to >> explain issues to end users is beginning to wear thin. It's becoming a >> headache. >> >> >> >> Thanks, >> >> >> >> James >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/r= tcweb > > > --0000000000002129f10575c25a47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With Firefox, I may be running into a different variant of= the bug I entered before:

<= /div>
If I add a TURN iceServer, and set iceTransportPolicy to relay, b= ut never call GUM, Chrome will connect, but Firefox won't.
Ho= wever, the TURN server is on a VPN network. That bug above is about Firefox= not choosing the route to the origin when in mode 1. I guess that would al= so mean it wouldn't use that supplied TURN server either.

James

On Thu, 13 Sep 2018 at 08:02, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
To be clear, if you= 're seeing Firefox behave in a way that doesn't comply with the ip-handling specification, please either file a bug at <https://bugzilla.mozilla.org/enter_bug.cgi?product=3DCore= &component=3DWebRTC>, or send me an email that describes exact steps to reproduce the issue you're seeing and an explanation of what is happening versu= s what should be happening, and I'll forward it to the relevant parties.

/a

On 9/13/18 1:00 AM,= Justin Uberti wrote:
=20
Mode 1 is not needed for TURN.

On Wed, Sep 12, 2018 at 1:19 PM westhawk <thp@westhawk.co.uk&g= t; wrote:


> On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> wrote= :
>
> That's interesting - in the GitHub comments, you say tha= t without Mode 1, you have to use TURN.
> It's my understanding that Mode 1 is also required for TURN - that's certainly what the spec seems to say. I know Firefox will not enumerate relay ice candidates until I've called getUserMedia().

No, Mode 3 explicitly supports TURN:

"
Default route only: This is the the same as Mode 2, except that the associated private address MUST NOT be provided. This may cause traffic to hairpin through a NAT, fall back to the application TURN server, or fail altogether, with resulting quality implications.
=E2=80=9C

I suppose I should write some test code to verify what is actually happening...

I see Safari 12 looks like supporting MDNS names in ICE candidates.

It is definitely a mess.

T.




>
> James
>
> On Wed, 12 Sep 2018 at 15:47, westhawk <thp@westhawk.co.uk> wrote: > Yeah, I call this the =E2=80=9CYou have to take a selfie bef= ore you fly the drone=E2=80=9D problem.
> I=E2=80=99ve just filed a GitHub issue on it for the use cas= e spec for webRTC NV.
>
> https://github.com/w3c/webrtc-nv-u= se-cases/issues/1
>
> Feel free to add commentary there as well as here.
>
> T.
>
>
>> On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com> w= rote:
>>
>>
>> Hi,
>>
>> I have a quesion about the use of getUserMedia to obtain user consent for Mode 1 operation.
>>
>> I have an application that uses WebRTC to deliver real-time media streams in one direction only. Client applications are consumers only, in some cases the client devices do not have any media capture capability.
>> I'm trying to develop a strategy for deploying the application on the public web so, naturally, my plan is to use TURN to relay through NAT.
>>
>> I've run into trouble with
>>=C2=A0 =C2=A0a) The requirement that Mode 1 is needed to = use TURN
>>=C2=A0 =C2=A0b) User consent for Mode 1 is tied to getUserMedia()
>>
>> Firstly, it's not clear to me why there is a restriction on using TURN in mode 2. Does TURN reveal address information that would otherwise be hidden to the peer? I've noticed that Chrome seems to use TURN even without consent being given. Firefox does not.
>>
>> Secondly, with no capture devices, getUserMedia can never succeed, thus, a user can never give consent for Mode 1. This is unfortunate, as WebRTC is ideal for some applications that require one-way streaming to limited-spec devices. Granted, not many devices today have no capture capability, but even when they do, requesting permission to access a microphone when it'll never be needed is confusing to end users. Is there a better mechanism we can use to obtain consent when getUserMedia is not necessary?
>>
>>
>> I know I've raised this issue tangentially before, but having to explain issues to end users is beginning to wear thin. It's becoming a headache.
>>
>> Thanks,
>>
>> James
>> _______________________________________________
>> rtcweb mailing list
>> rtc= web@ietf.org
>> https://www.ietf.org/mailman/listinfo= /rtcweb
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.= org
https://www.ietf.org/mailman/listinfo/rtcweb

___________________=
____________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/m=
ailman/listinfo/rtcweb


--0000000000002129f10575c25a47-- From nobody Thu Sep 13 08:55:25 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA808130E04 for ; Thu, 13 Sep 2018 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq7PcG-gh2w0 for ; Thu, 13 Sep 2018 08:55:21 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491571292AD for ; Thu, 13 Sep 2018 08:55:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536854118; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4uQ2tNiJErioKbmUYImK5j1ZZH8ovCksbpuvtUfDBUM=; b=JYpo9jGCOOj3hp/LQpdy937iIcxV4R94ZJUSdNA6c3I1k9eCAqZgCUb7s049zDYf CqqUxG00+mSdmCS815DddVcDHTDQyTQ1MFN+d8d2Agq3jRUkx0YrFlvlg2hPlSiE Zi73d6L4r3iGWH8Sxq74bz0SmxTRt6Ce5ErtSkhj9a4=; X-AuditID: c1b4fb25-8e7ff700000013ad-ba-5b9a8866eb08 Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.69.05037.6688A9B5; Thu, 13 Sep 2018 17:55:18 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 13 Sep 2018 17:55:18 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Thu, 13 Sep 2018 17:55:18 +0200 From: Christer Holmberg To: RTCWeb IETF Thread-Topic: mdns-ice-candidates: Single IP address:port Thread-Index: AdRLeY7UkDR+ba78Rh2H1pCtMfjd0g== Date: Thu, 13 Sep 2018 15:55:18 +0000 Message-ID: <6370f43ad94440e4a2e5b7641dbe54ca@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: multipart/alternative; boundary="_000_6370f43ad94440e4a2e5b7641dbe54caericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7hW5ax6xogyunzC3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsOzZraCz5IVZ/5sZG1gvCjWxcjJISFgInHmzGPWLkYuDiGB o4wSb6YcZYdwvjFKPDkzlRnCWcYo0Th5L1sXIwcHm4CFRPc/bZBuEQFFiScLlzCC2MJAkzYc eMwEEbeU2P7oKZStJ7H3zVoWEJtFQFXia+NNZhCbV8BaYsLzn2A1jAJiEt9PrQGzmQXEJW49 mc8EcZ2AxJI955khbFGJl4//sULYShJ7j11ngahPllgxZQ/UTEGJkzOfsExgFJqFZNQsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+A/QOsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWb GIFRcXDLb9UdjJffOB5iFOBgVOLhXb16ZrQQa2JZcWXuIUYJDmYlEd71obOihXhTEiurUovy 44tKc1KLDzFKc7AoifM+NN8cJSSQnliSmp2aWpBaBJNl4uCUamAMkDC5Zi5ZPV36clyQ+AGF xy+SM749aUn6ZriqucU/MShvX2TL1vpLYh82Ce6zuLNZM2hj2GfrJ/7acrejItfMMDn8V7LJ ZN2vx56P4yxMI3k/LPt4LTWk4rOwYO8DMZ3Mkwqtd2ReR6l7ZjrtqVI4f3Rr8F++f98in5Zz HuXQbhH4UbzuHpMSS3FGoqEWc1FxIgBLhtVWhgIAAA== Archived-At: Subject: [rtcweb] mdns-ice-candidates: Single IP address:port X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 15:55:23 -0000 --_000_6370f43ad94440e4a2e5b7641dbe54caericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A couple of comments: Q1: As discussed back in July, as an ICE candidate by definition is associa= ted with a single IP address:port, we should make it clear in the draft tha= t there can only be an 1:1 mapping between the "mdns candidate" and an IP a= ddress:port. Q2: Related to Q1, I assume we can remove the last paragraph in section 3.2= . Regards, Christer --_000_6370f43ad94440e4a2e5b7641dbe54caericssoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A couple of comments:

 

Q1: As discussed back in July, as an ICE candidate b= y definition is associated with a single IP address:port, we should make it= clear in the draft that there can only be an 1:1 mapping between the ̶= 0;mdns candidate” and an IP address:port.

 

Q2: Related to Q1, I assume we can remove the last p= aragraph in section 3.2.

 

Regards,

 

Christer

--_000_6370f43ad94440e4a2e5b7641dbe54caericssoncom_-- From nobody Thu Sep 13 09:47:16 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CB8130DD8 for ; Thu, 13 Sep 2018 09:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSj9YcstyZhi for ; Thu, 13 Sep 2018 09:47:11 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56D0B1294D0 for ; Thu, 13 Sep 2018 09:47:11 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id v90-v6so6899610wrc.0 for ; Thu, 13 Sep 2018 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TLIzvyk1YtyR6wypD92UP+nqbkfu44KIMj4QDRQQVes=; b=Navmc1UCw7w9c/MeBohkh7hwnEDGAMMeN+pXH1qlX8DIJXs5jLcmZ4hZFpDX8rHuV9 k/Np5AP/R21pAs9uliITpukEE9pQzsUtjcpXG/pz0spBVe7YtjR19rhefnMIBzvAoEiz hReOoJTtnSYRujSgmrnVko1MI/XjF5r+J7bIa8x2a93Dma+8LzoBnqouy2nB2lhR+K4J 1hBVsrugZ/WmEvZ1bWw+fzDU9c5Pd04nFqztQd+KsTvWKyzp4yqlXw6+5KgJjzkhwKyf LgUhKoEmwyCn6qo6msaXd7/cUOD4cjEpZ2TDxPsnqDPjPnI+TLcoT28dQj7BQIVarxkC mrbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TLIzvyk1YtyR6wypD92UP+nqbkfu44KIMj4QDRQQVes=; b=lhs5yjJjbbVU1V82Llin0ymEmkOZ4z6kc9BMEjU8BFMylFJYevtRrIrK57xFNy6FI9 eX+ffW09v941FAb9AhZslp5S959SjtTDfassQ0LS6enpDAYws2FBqTlaq2nnc483AvUd wPi+ki0QX2fL4ebo3U/ibnsGu59IoBhj3/jKbmo9TfkqCPo9Koxlf5v5aFBfhDGza08l K4QKHozEpfRI2ETb8IxX88DgdB9/LbH735VfhcRhp1mFaV0FNzJ1T5JRy6K+ot34Q+Go 2hAj4bA/Jl6xheeC8BmdCAOXWqRzVPF5O1PqLH7aZQ6Ikmyz3ZtLDOkOxik2G9+qBL07 1TQg== X-Gm-Message-State: APzg51Cx5d503IY+FRkFzj+nCe+nKHeSIX9N+XL39mLSrx6YVIrxuA/T lWPXJc7WsW7UHuRfYukNuilgf8cO X-Google-Smtp-Source: ANB0VdZKiaUn8/gDfGvNjJ9Odx7R4gWXbJg6ebsAU3WopmVpA3gLf2sJzs/iRY2CnVMw+dbmk1UYvA== X-Received: by 2002:a1c:f30d:: with SMTP id q13-v6mr5786046wmq.36.1536857229505; Thu, 13 Sep 2018 09:47:09 -0700 (PDT) Received: from [10.26.2.1] ([31.10.151.172]) by smtp.gmail.com with ESMTPSA id u40-v6sm7551802wrc.43.2018.09.13.09.47.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 09:47:08 -0700 (PDT) To: rtcweb@ietf.org References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> <104bf6e8-183a-fbd6-7651-772ee68a0ef4@nostrum.com> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Cc: James Pearce Message-ID: <8827440f-667c-ee0a-f971-93457a802bf9@gmail.com> Date: Thu, 13 Sep 2018 18:47:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 16:47:14 -0000 That sounds like a result of mode 2. I assume Firefox collects the address of the default route first and then talks to all the STUN/TURN servers provided via that interface only. If the VPN's address is not the default route and the TURN server is only available in the VPN, the TURN server cannot be reached. I'm actually not sure what's correct in that case. But if the TURN server is reachable via multiple interfaces, the public IP from both of your interfaces would leak. So, I guess Firefox is correct and Chrome shouldn't reach the TURN server either? By the way, 1000% agree that we need a proper way to access mode 1 for other use cases. Cheers Lennart On 13.09.2018 17:27, James Pearce wrote: > With Firefox, I may be running into a different variant of the bug I > entered before: > *Bug 1384265 * > > If I add a TURN iceServer, and set iceTransportPolicy to relay, but never > call GUM, Chrome will connect, but Firefox won't. > However, the TURN server is on a VPN network. That bug above is about > Firefox not choosing the route to the origin when in mode 1. I guess that > would also mean it wouldn't use that supplied TURN server either. > > James > > On Thu, 13 Sep 2018 at 08:02, Adam Roach wrote: > >> To be clear, if you're seeing Firefox behave in a way that doesn't comply >> with the ip-handling specification, please either file a bug at >> >> , >> or send me an email that describes exact steps to reproduce the issue >> you're seeing and an explanation of what is happening versus what should be >> happening, and I'll forward it to the relevant parties. >> >> /a >> >> On 9/13/18 1:00 AM, Justin Uberti wrote: >> >> Mode 1 is not needed for TURN. >> >> On Wed, Sep 12, 2018 at 1:19 PM westhawk wrote: >> >>> >>> >>>> On 12 Sep 2018, at 20:57, James Pearce wrote: >>>> >>>> That's interesting - in the GitHub comments, you say that without Mode >>> 1, you have to use TURN. >>>> It's my understanding that Mode 1 is also required for TURN - that's >>> certainly what the spec seems to say. I know Firefox will not enumerate >>> relay ice candidates until I've called getUserMedia(). >>> >>> No, Mode 3 explicitly supports TURN: >>> >>> " >>> Default route only: This is the the same as Mode 2, except that the >>> associated private address MUST NOT be provided. This may cause traffic to >>> hairpin through a NAT, fall back to the application TURN server, or fail >>> altogether, with resulting quality implications. >>> “ >>> >>> I suppose I should write some test code to verify what is actually >>> happening... >>> >>> I see Safari 12 looks like supporting MDNS names in ICE candidates. >>> >>> It is definitely a mess. >>> >>> T. >>> >>> >>> >>> >>>> >>>> James >>>> >>>> On Wed, 12 Sep 2018 at 15:47, westhawk wrote: >>>> Yeah, I call this the “You have to take a selfie before you fly the >>> drone” problem. >>>> I’ve just filed a GitHub issue on it for the use case spec for webRTC >>> NV. >>>> >>>> https://github.com/w3c/webrtc-nv-use-cases/issues/1 >>>> >>>> Feel free to add commentary there as well as here. >>>> >>>> T. >>>> >>>> >>>>> On 12 Sep 2018, at 14:35, James Pearce wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> I have a quesion about the use of getUserMedia to obtain user consent >>> for Mode 1 operation. >>>>> >>>>> I have an application that uses WebRTC to deliver real-time media >>> streams in one direction only. Client applications are consumers only, in >>> some cases the client devices do not have any media capture capability. >>>>> I'm trying to develop a strategy for deploying the application on the >>> public web so, naturally, my plan is to use TURN to relay through NAT. >>>>> >>>>> I've run into trouble with >>>>> a) The requirement that Mode 1 is needed to use TURN >>>>> b) User consent for Mode 1 is tied to getUserMedia() >>>>> >>>>> Firstly, it's not clear to me why there is a restriction on using TURN >>> in mode 2. Does TURN reveal address information that would otherwise be >>> hidden to the peer? I've noticed that Chrome seems to use TURN even without >>> consent being given. Firefox does not. >>>>> >>>>> Secondly, with no capture devices, getUserMedia can never succeed, >>> thus, a user can never give consent for Mode 1. This is unfortunate, as >>> WebRTC is ideal for some applications that require one-way streaming to >>> limited-spec devices. Granted, not many devices today have no capture >>> capability, but even when they do, requesting permission to access a >>> microphone when it'll never be needed is confusing to end users. Is there a >>> better mechanism we can use to obtain consent when getUserMedia is not >>> necessary? >>>>> >>>>> >>>>> I know I've raised this issue tangentially before, but having to >>> explain issues to end users is beginning to wear thin. It's becoming a >>> headache. >>>>> >>>>> Thanks, >>>>> >>>>> James >>>>> _______________________________________________ >>>>> rtcweb mailing list >>>>> rtcweb@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> _______________________________________________ >> rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb >> >> >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Thu Sep 13 12:35:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC30128CF3 for ; Thu, 13 Sep 2018 12:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT-esmgoGMJQ for ; Thu, 13 Sep 2018 12:35:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1DC7F126CB6 for ; Thu, 13 Sep 2018 12:35:38 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w8DJZXAS044707 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 13 Sep 2018 14:35:34 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Christer Holmberg , RTCWeb IETF References: <6370f43ad94440e4a2e5b7641dbe54ca@ericsson.com> From: Adam Roach Message-ID: <05f502dd-4441-36ee-19c1-4e9f4b1eac80@nostrum.com> Date: Thu, 13 Sep 2018 14:35:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <6370f43ad94440e4a2e5b7641dbe54ca@ericsson.com> Content-Type: multipart/alternative; boundary="------------DCBA7454265974C17DA24D0B" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] mdns-ice-candidates: Single IP address:port X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 19:35:41 -0000 This is a multi-part message in MIME format. --------------DCBA7454265974C17DA24D0B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit [as an individual] On 9/13/18 10:55 AM, Christer Holmberg wrote: > > Hi, > > A couple of comments: > > Q1: As discussed back in July, as an ICE candidate by definition is > associated with a single IP address:port, we should make it clear in > the draft that there can only be an 1:1 mapping between the “mdns > candidate” and an IP address:port. > Part of why this wasn't simple enough to slipstream into the existing documents is that we don't have well-defined handling in SDP for dealing with names in the field of "c=" lines. The extent of RFC 4566's text on the topic is:    A session description can contain domain names in the "o=", "u=",    "e=", "c=", and "a=" lines.  Any domain name used in SDP MUST comply    with [1], [2].  Internationalised domain names (IDNs) MUST be    represented using the ASCII Compatible Encoding (ACE) form defined in    [11] and MUST NOT be directly represented in UTF-8 or any other    encoding (this requirement is for compatibility with RFC 2327 and    other SDP-related standards, which predate the development of    internationalised domain names). Unfortunately, this doesn't provide a lot of clarity about what happens if a DNS lookup of the corresponding domain name returns multiple A or AAAA records. (The fact that "c=" lines clearly indicate their address family saves us from having to worry about any happy-eyeballs-style address family fiddling, but the handling of name lookups is still somewhat ambiguous). So I think we need to reach a common understanding about how to handle the normal name-to-address mapping case, and then apply the same principle to mDNS as we do to DNS. /a --------------DCBA7454265974C17DA24D0B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as an individual]

On 9/13/18 10:55 AM, Christer Holmberg wrote:

Hi,

 

A couple of comments:

 

Q1: As discussed back in July, as an ICE candidate by definition is associated with a single IP address:port, we should make it clear in the draft that there can only be an 1:1 mapping between the “mdns candidate” and an IP address:port.


Part of why this wasn't simple enough to slipstream into the existing documents is that we don't have well-defined handling in SDP for dealing with names in the <connection-address> field of "c=" lines. The extent of RFC 4566's text on the topic is:


   A session description can contain domain names in the "o=", "u=",
   "e=", "c=", and "a=" lines.  Any domain name used in SDP MUST comply
   with [1], [2].  Internationalised domain names (IDNs) MUST be
   represented using the ASCII Compatible Encoding (ACE) form defined in
   [11] and MUST NOT be directly represented in UTF-8 or any other
   encoding (this requirement is for compatibility with RFC 2327 and
   other SDP-related standards, which predate the development of
   internationalised domain names).


Unfortunately, this doesn't provide a lot of clarity about what happens if a DNS lookup of the corresponding domain name returns multiple A or AAAA records. (The fact that "c=" lines clearly indicate their address family saves us from having to worry about any happy-eyeballs-style address family fiddling, but the handling of name lookups is still somewhat ambiguous).

So I think we need to reach a common understanding about how to handle the normal name-to-address mapping case, and then apply the same principle to mDNS as we do to DNS.

/a

--------------DCBA7454265974C17DA24D0B-- From nobody Fri Sep 14 00:09:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C083130DDB for ; Fri, 14 Sep 2018 00:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2ShKgpo19VS for ; Fri, 14 Sep 2018 00:09:51 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 03658130DD2 for ; Fri, 14 Sep 2018 00:09:51 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id 101-v6so6593737uav.7 for ; Fri, 14 Sep 2018 00:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=nO39EqyYpLT55u5NrbMhxBsLu/CCw3AAy+cvkATzMHo=; b=NzzwsoEUCqudDPvP3Cl7yjN1pQvvatGJYnADGxFwaySUPBcWAOrVIso++lTnkOYNnI KjWQhT+YucdTOVtlgtbLDdNPdo1Wis9vsSzB1WcXymXWKkVz0GtvTuZ3omPzx+3z1oUd lQsE2asQb3M7NG6/oHcIydx8XEmTqYtJzLOVAwJL+u0WQ9HjMOVTNsGQL8yadokNKKRo p0SRFNBf/Omgg075DxGGJMM0ZklDn2HGosXZAv2ELHn6fRraJT5ArzPhfL81qSxMQV9T o4re3gVVooa+u6AS0kvR5rss/6D+tHye6QE6tt75rdD4uc4tbiWRgtxCmJpBXemnEi3X sOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=nO39EqyYpLT55u5NrbMhxBsLu/CCw3AAy+cvkATzMHo=; b=K+9asP96lzPV4uqWxBpvmyziy7+ffWJOcVdfuESZeGh9hKJ+TtAOUJrrqRKmnI5MOU x/huLxZrgil4wiJTakGMIzeaqeM1beu4QRHyNIqNz1xCKevNkZ1KnE+r1PwDshlTJEYr MH4DGcL8YSdX9hx8BxaH/4RSAvyMu9wuNCNU15VNz17S3LkmI1AHwEk5Zuj9rYf61e5k y+u4nH4WSXDuFKt8tyEIutRYwLoTyHaDsukaOKrz3LWaPKbUtFX8gyk4Vwx5hgRRbIBf eIqrJy6unglDG+rQXfIYGR7myVJVhN2ASwCkzSOk7kiOojIErzEgdN+b29Wjye9eb8Mq aDSg== X-Gm-Message-State: APzg51B/N63waej9Sba/csAVnVOD4u+/ntcEdGjOUJikVgGpAZNl+s3W /yzx0M1xAzO2ikCQBYaUDOuHV2dSRanPiEvoRph1Y3p0 X-Google-Smtp-Source: ANB0VdZLZEeolEBUMZ6MuApKdaFvVMvulCKFlUN7JYHTf+PGuCcog9XdyYUfp0DohwxDXS2alNjKfcXWryvx2u+DLp4= X-Received: by 2002:ab0:59c2:: with SMTP id k2-v6mr3687227uad.124.1536908989720; Fri, 14 Sep 2018 00:09:49 -0700 (PDT) MIME-Version: 1.0 From: Bernard Aboba Date: Fri, 14 Sep 2018 00:09:38 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000626c8d0575cf82f4" Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 07:09:53 -0000 --000000000000626c8d0575cf82f4 Content-Type: text/plain; charset="UTF-8" While I understand the overall goal of this document, it strikes me as suffering from two major problems: a. Introduction of backwards compatibility problems and potential additional delays due to utilization of name resolution mechanisms in ICE, with a corresponding benefit (successful connectivity checks between host candidates on the same network) which is only a marginal improvement over mode 3 (no host candidates). b. Over-reliance on permission mechanisms which have already been stretched to the breaking point, leaving the potential for collateral damage in data channel-only scenarios. Due to limitations in the current permissions mechanisms, it is not currently practically impossible to distinguish legitimate data channel applications that would obtain permissions if there were usable means to do so from illegitimate applications attempting to compromise user privacy. Data-channel only scenarios that would be impacted include those where: 1. Permissions cannot be obtained (e.g. where there is no microphone or camera attached to the device so that getUserMedia will always fail). 2. Low latency communications is a requirement so that TURN server traversal is unacceptable (e.g. in financial applications where there may be regulatory requirements relating to allowable delays). 3. TURN traversal would impose an unacceptable financial cost, such as in branch office scenarios where a TURN servers is not provided in each branch office, and branch office connectivity may be constrained (still an issue for branch offices located on other continents). Essentially, the problem is that these scenarios may have valid reasons why they cannot utilize or do not wish to utilize getUserMedia as a permission-granting mechanism. --000000000000626c8d0575cf82f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I understand the overall goal of this document,=C2= =A0 it strikes me as suffering from two major problems:=C2=A0

a. Introduction of backwards compatibility problems and potential add= itional delays due to utilization of name resolution mechanisms in ICE, wit= h a corresponding benefit (successful connectivity checks between host cand= idates on the same network) which is only a marginal improvement over mode = 3 (no host candidates).=C2=A0

b. Over-reliance on pe= rmission mechanisms which have already been stretched to the breaking point= , leaving the potential for collateral damage in data channel-only scenario= s. Due to limitations in the current permissions mechanisms, it is not curr= ently practically impossible to distinguish legitimate data channel applica= tions that would obtain permissions if there were usable means to do so fro= m illegitimate applications attempting to compromise user privacy.=C2=A0

Data-channel only scenarios that would be impacted i= nclude those where:

1. Permissions cannot be = obtained (e.g. where there is no microphone or camera attached to the devic= e so that getUserMedia will always fail).=C2=A0

2.= Low latency communications is a requirement so that TURN server traversal = is unacceptable (e.g. in financial applications where there may be regulato= ry requirements relating to allowable delays).

3. = TURN traversal would impose an unacceptable financial cost, such as in bran= ch office scenarios where a TURN servers is not provided in each branch off= ice, and branch office connectivity may be constrained (still an issue for = branch offices located on other continents).=C2=A0

Essentially, the problem is that these scenarios may have valid reasons wh= y they cannot utilize or do not wish to utilize getUserMedia as a permissio= n-granting mechanism.=C2=A0=C2=A0


<= br>



--000000000000626c8d0575cf82f4-- From nobody Fri Sep 14 03:02:43 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6238E130DD2 for ; Fri, 14 Sep 2018 03:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHBYCrdfZSvp for ; Fri, 14 Sep 2018 03:02:39 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DF412F295 for ; Fri, 14 Sep 2018 03:02:39 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id h1-v6so1810271itj.4 for ; Fri, 14 Sep 2018 03:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vy6egG7Pf9/ImMJAw8bKj4sYYami9lqY8zeSXHfLX30=; b=pKKr8KThuAKCwlAOGCQ45tJLnwgN/0TFthD3sORL95Xtb48yvK3o7TIeYaif1dffCN qUnTDb7/0E13JNWRsBGZoLxTMJjcLhpLdSQAKZ8Zn6NLw7sx6Q3IRc6uHtoAnXweJanV 0T0VDfcZRcb/JiH+aCdZ2cisR3UlVpd8xE19TlMvKmPJsbW2z4SDZfa881Y3cWRAEC6q cFlkAunvvIDLq1qiH7g3Jw7RkMUICFpHPJVyEeOE4mQgXe1hG4KargqpdGJIywz9DXrL 3Iom+wDMjKAinq9U420L1SwRLr0K8rgnALyVX0LSQnfvvFeJY1yBtdFsWSX6Bgecb3JX IR/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vy6egG7Pf9/ImMJAw8bKj4sYYami9lqY8zeSXHfLX30=; b=mrAaY8PAlP10C4d0MZ9rZe4ooKtf7K/abwwkb6Qpurh+ODNovmsMLu/TVE+vaZv+6c NgzLiSAeSCjaZuZK7zMXO55gew2BpGLOVcYLJAa/5q8h9W0+EGhXUt7I4i8R/WyIyzKS zLO9s7eRE9DRYIiRfwdsIVTIWff2H4SJCEb/Le/Y9m9V8a3Eu5+iYZNFXjkBSGdBwoq1 v1HJyz4txLvpSggoJERJDyzPTqfFdJyyN3KzrhlrHdjekkduU9zHF/k3BENbP0guNXgd P3dK2T32nZxHNUxXJ1exUPsjnOQUf/UNi54Sgg6D60PAIczVPfI99Cg8KXI65Rvi1vUp bB6w== X-Gm-Message-State: APzg51BikgS3lwIhV6kRnZNmy0+48FJeOqVsEwx4rrwVL2bHvn/7j4BV /sobanLdhkoHYzioRikUbPkaJ8xeOXX0CsJ0j7ZVqg== X-Google-Smtp-Source: ANB0Vdb1+a0K3MqKEgKXi6Y6BsQd37yMlt9IN+DphVkKLnRx4p4SYIAnIqZh+nCROAUMqvbp3jAhF4BYP53VkUYbAMc= X-Received: by 2002:a24:b101:: with SMTP id o1-v6mr1550553itf.121.1536919358968; Fri, 14 Sep 2018 03:02:38 -0700 (PDT) MIME-Version: 1.0 References: <85AC649C-F7B3-40E4-B9FC-FAC8C4332A5E@westhawk.co.uk> <104bf6e8-183a-fbd6-7651-772ee68a0ef4@nostrum.com> <8827440f-667c-ee0a-f971-93457a802bf9@gmail.com> In-Reply-To: <8827440f-667c-ee0a-f971-93457a802bf9@gmail.com> From: James Pearce Date: Fri, 14 Sep 2018 11:02:22 +0100 Message-ID: To: lennart.grahl@gmail.com Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000070acc60575d1ec24" Archived-At: Subject: Re: [rtcweb] Mode 1 and getUserMedia X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 10:02:42 -0000 --00000000000070acc60575d1ec24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's correct, but Firefox chooses the wrong default route. That's the existing bug. All browsers except Firefox use the route to the origin as the default route (which is now in the spec). So what I'm seeing is expected given that bug exists. James On Thu, 13 Sep 2018 at 17:47, Lennart Grahl wrote= : > That sounds like a result of mode 2. I assume Firefox collects the > address of the default route first and then talks to all the STUN/TURN > servers provided via that interface only. If the VPN's address is not > the default route and the TURN server is only available in the VPN, the > TURN server cannot be reached. > > I'm actually not sure what's correct in that case. But if the TURN > server is reachable via multiple interfaces, the public IP from both of > your interfaces would leak. So, I guess Firefox is correct and Chrome > shouldn't reach the TURN server either? > > By the way, 1000% agree that we need a proper way to access mode 1 for > other use cases. > > Cheers > Lennart > > On 13.09.2018 17:27, James Pearce wrote: > > With Firefox, I may be running into a different variant of the bug I > > entered before: > > *Bug 1384265 * > > > > If I add a TURN iceServer, and set iceTransportPolicy to relay, but nev= er > > call GUM, Chrome will connect, but Firefox won't. > > However, the TURN server is on a VPN network. That bug above is about > > Firefox not choosing the route to the origin when in mode 1. I guess th= at > > would also mean it wouldn't use that supplied TURN server either. > > > > James > > > > On Thu, 13 Sep 2018 at 08:02, Adam Roach wrote: > > > >> To be clear, if you're seeing Firefox behave in a way that doesn't > comply > >> with the ip-handling specification, please either file a bug at > >> < > https://bugzilla.mozilla.org/enter_bug.cgi?product=3DCore&component=3DWeb= RTC> > >> < > https://bugzilla.mozilla.org/enter_bug.cgi?product=3DCore&component=3DWeb= RTC>, > >> or send me an email that describes exact steps to reproduce the issue > >> you're seeing and an explanation of what is happening versus what > should be > >> happening, and I'll forward it to the relevant parties. > >> > >> /a > >> > >> On 9/13/18 1:00 AM, Justin Uberti wrote: > >> > >> Mode 1 is not needed for TURN. > >> > >> On Wed, Sep 12, 2018 at 1:19 PM westhawk wrote: > >> > >>> > >>> > >>>> On 12 Sep 2018, at 20:57, James Pearce wrote: > >>>> > >>>> That's interesting - in the GitHub comments, you say that without Mo= de > >>> 1, you have to use TURN. > >>>> It's my understanding that Mode 1 is also required for TURN - that's > >>> certainly what the spec seems to say. I know Firefox will not enumera= te > >>> relay ice candidates until I've called getUserMedia(). > >>> > >>> No, Mode 3 explicitly supports TURN: > >>> > >>> " > >>> Default route only: This is the the same as Mode 2, except that the > >>> associated private address MUST NOT be provided. This may cause > traffic to > >>> hairpin through a NAT, fall back to the application TURN server, or > fail > >>> altogether, with resulting quality implications. > >>> =E2=80=9C > >>> > >>> I suppose I should write some test code to verify what is actually > >>> happening... > >>> > >>> I see Safari 12 looks like supporting MDNS names in ICE candidates. > >>> > >>> It is definitely a mess. > >>> > >>> T. > >>> > >>> > >>> > >>> > >>>> > >>>> James > >>>> > >>>> On Wed, 12 Sep 2018 at 15:47, westhawk wrote: > >>>> Yeah, I call this the =E2=80=9CYou have to take a selfie before you = fly the > >>> drone=E2=80=9D problem. > >>>> I=E2=80=99ve just filed a GitHub issue on it for the use case spec f= or webRTC > >>> NV. > >>>> > >>>> https://github.com/w3c/webrtc-nv-use-cases/issues/1 > >>>> > >>>> Feel free to add commentary there as well as here. > >>>> > >>>> T. > >>>> > >>>> > >>>>> On 12 Sep 2018, at 14:35, James Pearce wrote= : > >>>>> > >>>>> > >>>>> Hi, > >>>>> > >>>>> I have a quesion about the use of getUserMedia to obtain user conse= nt > >>> for Mode 1 operation. > >>>>> > >>>>> I have an application that uses WebRTC to deliver real-time media > >>> streams in one direction only. Client applications are consumers only= , > in > >>> some cases the client devices do not have any media capture capabilit= y. > >>>>> I'm trying to develop a strategy for deploying the application on t= he > >>> public web so, naturally, my plan is to use TURN to relay through NAT= . > >>>>> > >>>>> I've run into trouble with > >>>>> a) The requirement that Mode 1 is needed to use TURN > >>>>> b) User consent for Mode 1 is tied to getUserMedia() > >>>>> > >>>>> Firstly, it's not clear to me why there is a restriction on using > TURN > >>> in mode 2. Does TURN reveal address information that would otherwise = be > >>> hidden to the peer? I've noticed that Chrome seems to use TURN even > without > >>> consent being given. Firefox does not. > >>>>> > >>>>> Secondly, with no capture devices, getUserMedia can never succeed, > >>> thus, a user can never give consent for Mode 1. This is unfortunate, = as > >>> WebRTC is ideal for some applications that require one-way streaming = to > >>> limited-spec devices. Granted, not many devices today have no capture > >>> capability, but even when they do, requesting permission to access a > >>> microphone when it'll never be needed is confusing to end users. Is > there a > >>> better mechanism we can use to obtain consent when getUserMedia is no= t > >>> necessary? > >>>>> > >>>>> > >>>>> I know I've raised this issue tangentially before, but having to > >>> explain issues to end users is beginning to wear thin. It's becoming = a > >>> headache. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> James > >>>>> _______________________________________________ > >>>>> rtcweb mailing list > >>>>> rtcweb@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rtcweb > >>>> > >>> > >>> _______________________________________________ > >>> rtcweb mailing list > >>> rtcweb@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rtcweb > >>> > >> > >> _______________________________________________ > >> rtcweb mailing listrtcweb@ietf.orghttps:// > www.ietf.org/mailman/listinfo/rtcweb > >> > >> > >> > > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > > --00000000000070acc60575d1ec24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's correct, but Firefox chooses the wrong default = route. That's the existing bug.
All browsers except Firefox use the= route to the origin as the default route (which is now in the spec).=C2=A0=
So what I'm seeing is expected given that bug exists.
James

On Thu, 13 Sep 2018 at 17:47, Lennart Grahl <lennart.grahl@gmail.com> wrote:
That sounds like a result of mode 2. I assume = Firefox collects the
address of the default route first and then talks to all the STUN/TURN
servers provided via that interface only. If the VPN's address is not the default route and the TURN server is only available in the VPN, the
TURN server cannot be reached.

I'm actually not sure what's correct in that case. But if the TURN<= br> server is reachable via multiple interfaces, the public IP from both of
your interfaces would leak. So, I guess Firefox is correct and Chrome
shouldn't reach the TURN server either?

By the way, 1000% agree that we need a proper way to access mode 1 for
other use cases.

Cheers
Lennart

On 13.09.2018 17:27, James Pearce wrote:
> With Firefox, I may be running into a different variant of the bug I > entered before:
> *Bug 1384265 <https://bugzilla.mozilla= .org/show_bug.cgi?id=3D1384265>*
>
> If I add a TURN iceServer, and set iceTransportPolicy to relay, but ne= ver
> call GUM, Chrome will connect, but Firefox won't.
> However, the TURN server is on a VPN network. That bug above is about<= br> > Firefox not choosing the route to the origin when in mode 1. I guess t= hat
> would also mean it wouldn't use that supplied TURN server either.<= br> >
> James
>
> On Thu, 13 Sep 2018 at 08:02, Adam Roach <adam@nostrum.com> wrote:
>
>> To be clear, if you're seeing Firefox behave in a way that doe= sn't comply
>> with the ip-handling specification, please either file a bug at >> <https:= //bugzilla.mozilla.org/enter_bug.cgi?product=3DCore&component=3DWebRTC<= /a>>
>> <https:= //bugzilla.mozilla.org/enter_bug.cgi?product=3DCore&component=3DWebRTC<= /a>>,
>> or send me an email that describes exact steps to reproduce the is= sue
>> you're seeing and an explanation of what is happening versus w= hat should be
>> happening, and I'll forward it to the relevant parties.
>>
>> /a
>>
>> On 9/13/18 1:00 AM, Justin Uberti wrote:
>>
>> Mode 1 is not needed for TURN.
>>
>> On Wed, Sep 12, 2018 at 1:19 PM westhawk <thp@westhawk.co.uk> wrote:
>>
>>>
>>>
>>>> On 12 Sep 2018, at 20:57, James Pearce <james@jamesandjo.com> wro= te:
>>>>
>>>> That's interesting - in the GitHub comments, you say t= hat without Mode
>>> 1, you have to use TURN.
>>>> It's my understanding that Mode 1 is also required for= TURN - that's
>>> certainly what the spec seems to say. I know Firefox will not = enumerate
>>> relay ice candidates until I've called getUserMedia().
>>>
>>> No, Mode 3 explicitly supports TURN:
>>>
>>> "
>>> Default route only: This is the the same as Mode 2, except tha= t the
>>> associated private address MUST NOT be provided. This may caus= e traffic to
>>> hairpin through a NAT, fall back to the application TURN serve= r, or fail
>>> altogether, with resulting quality implications.
>>> =E2=80=9C
>>>
>>> I suppose I should write some test code to verify what is actu= ally
>>> happening...
>>>
>>> I see Safari 12 looks like supporting MDNS names in ICE candid= ates.
>>>
>>> It is definitely a mess.
>>>
>>> T.
>>>
>>>
>>>
>>>
>>>>
>>>> James
>>>>
>>>> On Wed, 12 Sep 2018 at 15:47, westhawk <thp@westhawk.co.uk> wrote:<= br> >>>> Yeah, I call this the =E2=80=9CYou have to take a selfie b= efore you fly the
>>> drone=E2=80=9D problem.
>>>> I=E2=80=99ve just filed a GitHub issue on it for the use c= ase spec for webRTC
>>> NV.
>>>>
>>>> https://github.com/w3c/webrtc-nv= -use-cases/issues/1
>>>>
>>>> Feel free to add commentary there as well as here.
>>>>
>>>> T.
>>>>
>>>>
>>>>> On 12 Sep 2018, at 14:35, James Pearce <james@jamesandjo.com>= wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have a quesion about the use of getUserMedia to obta= in user consent
>>> for Mode 1 operation.
>>>>>
>>>>> I have an application that uses WebRTC to deliver real= -time media
>>> streams in one direction only. Client applications are consume= rs only, in
>>> some cases the client devices do not have any media capture ca= pability.
>>>>> I'm trying to develop a strategy for deploying the= application on the
>>> public web so, naturally, my plan is to use TURN to relay thro= ugh NAT.
>>>>>
>>>>> I've run into trouble with
>>>>>=C2=A0 =C2=A0a) The requirement that Mode 1 is needed t= o use TURN
>>>>>=C2=A0 =C2=A0b) User consent for Mode 1 is tied to getU= serMedia()
>>>>>
>>>>> Firstly, it's not clear to me why there is a restr= iction on using TURN
>>> in mode 2. Does TURN reveal address information that would oth= erwise be
>>> hidden to the peer? I've noticed that Chrome seems to use = TURN even without
>>> consent being given. Firefox does not.
>>>>>
>>>>> Secondly, with no capture devices, getUserMedia can ne= ver succeed,
>>> thus, a user can never give consent for Mode 1. This is unfort= unate, as
>>> WebRTC is ideal for some applications that require one-way str= eaming to
>>> limited-spec devices. Granted, not many devices today have no = capture
>>> capability, but even when they do, requesting permission to ac= cess a
>>> microphone when it'll never be needed is confusing to end = users. Is there a
>>> better mechanism we can use to obtain consent when getUserMedi= a is not
>>> necessary?
>>>>>
>>>>>
>>>>> I know I've raised this issue tangentially before,= but having to
>>> explain issues to end users is beginning to wear thin. It'= s becoming a
>>> headache.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> James
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> r= tcweb@ietf.org
>>>>> https://www.ietf.org/mailman/listin= fo/rtcweb
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/rtc= web
>>>
>>
>> _______________________________________________
>> rtcweb mailing listrtcweb@ietf.orghttps://www.ie= tf.org/mailman/listinfo/rtcweb
>>
>>
>>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb >
--00000000000070acc60575d1ec24-- From nobody Fri Sep 14 08:37:01 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 917F2130ED9; Fri, 14 Sep 2018 08:36:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, ted.ietf@gmail.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153693940751.17705.103921502188404462.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2018 08:36:47 -0700 Archived-At: Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 103 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 15:36:59 -0000 A new meeting session request has just been submitted by Ted Hardie, a Chair of the rtcweb working group. --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Ted Hardie Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 65 Conflicts to Avoid: First Priority: dispatch doh dprive httpbis ice mmusic iasa2 quic saag secdispatch Second Priority: cbor mtgvenue tsvarea People who must be present: Eric Rescorla Sean Turner Adam Roach Cullen Jennings Ted Hardie Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 14 10:45:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E3B130E25 for ; Fri, 14 Sep 2018 10:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8X052gho36MP for ; Fri, 14 Sep 2018 10:45:04 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 790A8130DFB for ; Fri, 14 Sep 2018 10:45:03 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id j19-v6so8182786ljc.7 for ; Fri, 14 Sep 2018 10:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xfMcpq7Ja9nVNG1Do3qKHQq+onmKOA98Ehv0imMgU5s=; b=V+Kc0BlTH5esDUuriDFI6hcT8oEa+EzoduV9dgWzKZrXtSxiPhQYjB1golefNrQwiw p/ZcsEMjBJOOHjI7TE53DI2hNoJXBh2zSOTfk7/xcua3j/D9W4HLTIo/PbjHv/qHdpv5 kdagbIKnzaYK8wHHVbcJfCOt3zlpSBkSG0DafHADw1ICtZ9J/SfWykqXY9/8UMw7NJGE i43H7ian4JNsjVgm0TkrUZ/ESXOmmCFJL5Bg1P7W8vTZX52WqPp4BWGkKLe8+0OyjCVF vyQlCtkKkgHb4HChzOztEzqdTL/qnJG6q8j4ptYkHjvl9xnNfdu+g1ODSGa/Rs5lAYrJ sMOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xfMcpq7Ja9nVNG1Do3qKHQq+onmKOA98Ehv0imMgU5s=; b=kTh4X7lKCRhfivyfXqkyIhMV47/0LzXtg0RLFvdyU3ml0AbX2CWG2YPJzNIyp/kWuh Yo7l4+vN2Y5Cw0kiwIe6ClrP1o6Bsi9n3RbmHp8KwrjXw6+a8ZqSkXtJjNkrro8ssxoU WwNRBb9Q4cbx8IwOArkjnICE7b3sAxLJgbH+Pw+upCt+8+5Zl++o/UPgIC4KVilKJORp ZfxSPuMhkwfuS74Tsjj1Cc9geGMQl3bJvDD4vACuj8q5spK8vDWdS0EdlgT5IqeqlHaJ sHPzoCVD7Jf1opdx0eIiMYSjkZv7KTtOUbiT+7K1c65yI56NHZzfIBhGigWCIOt2TRDt 0bMg== X-Gm-Message-State: APzg51C3Y2auSvHDl8DtdZjfd0DaIPRUY0zg1EXRtir26iryJsSxtSa0 n/W44nkIp0TICUTG7cOytFUDen0hFftEsPmsD7dGzg== X-Google-Smtp-Source: ANB0VdabJk2GVou3obcPOTP+bytj02U56Ivu6z3pgRX7IyaPS3oIP+Dp74+hW7qeWw1kwRUUN8aBrWsNGFdg4nROHzw= X-Received: by 2002:a2e:87cf:: with SMTP id v15-v6mr249626ljj.13.1536947101425; Fri, 14 Sep 2018 10:45:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: youenn fablet Date: Fri, 14 Sep 2018 10:44:49 -0700 Message-ID: To: Bernard Aboba Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000004e6900575d86290" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 17:45:07 -0000 --00000000000004e6900575d86290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review Bernard, Agreed that this proposal does not solve all cases. But it does so in a number of cases like home/small office scenarios. In general, I do not think there is a guarantee to successfully connect without sometimes relying on TURN servers. This proposal and other solutions should allow reducing the need to use TURN. Describing precisely the problematic scenarios is useful as we can find additional means specific to those scenarios. For instance, can it be envisioned to deploy STUN servers inside the user network for the financial applications/branch offices scenarios you are mentioning? Le ven. 14 sept. 2018 =C3=A0 00:10, Bernard Aboba = a =C3=A9crit : > While I understand the overall goal of this document, it strikes me as > suffering from two major problems: > > a. Introduction of backwards compatibility problems and potential > additional delays due to utilization of name resolution mechanisms in ICE= , > with a corresponding benefit (successful connectivity checks between host > candidates on the same network) which is only a marginal improvement over > mode 3 (no host candidates). > > b. Over-reliance on permission mechanisms which have already been > stretched to the breaking point, leaving the potential for collateral > damage in data channel-only scenarios. Due to limitations in the current > permissions mechanisms, it is not currently practically impossible to > distinguish legitimate data channel applications that would obtain > permissions if there were usable means to do so from illegitimate > applications attempting to compromise user privacy. > > Data-channel only scenarios that would be impacted include those where: > > 1. Permissions cannot be obtained (e.g. where there is no microphone or > camera attached to the device so that getUserMedia will always fail). > > 2. Low latency communications is a requirement so that TURN server > traversal is unacceptable (e.g. in financial applications where there may > be regulatory requirements relating to allowable delays). > > 3. TURN traversal would impose an unacceptable financial cost, such as in > branch office scenarios where a TURN servers is not provided in each bran= ch > office, and branch office connectivity may be constrained (still an issue > for branch offices located on other continents). > > Essentially, the problem is that these scenarios may have valid reasons > why they cannot utilize or do not wish to utilize getUserMedia as a > permission-granting mechanism. > > > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000004e6900575d86290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review Bernard,

Agreed t= hat this proposal does not solve all cases.
But it does so in a n= umber of cases like home/small office scenarios.

<= div>In general, I do not think there is a guarantee to successfully connect= without sometimes relying on TURN servers.
This proposal and oth= er solutions should allow reducing the need to use TURN.

Describing precisely the = problematic scenarios is useful as we can find additional means specific to= those scenarios.
For instance, can it be envisioned to deploy ST= UN servers inside the user network for the financial applications/branch of= fices scenarios you are mentioning?

Le=C2=A0ven. 1= 4 sept. 2018 =C3=A0=C2=A000:10, Bernard Aboba <bernard.aboba@gmail.com> a =C3=A9crit=C2=A0:
While I understand the overall goal of this document,=C2=A0 it strikes = me as suffering from two major problems:=C2=A0

a. Introd= uction of backwards compatibility problems and potential additional delays = due to utilization of name resolution mechanisms in ICE, with a correspondi= ng benefit (successful connectivity checks between host candidates on the s= ame network) which is only a marginal improvement over mode 3 (no host cand= idates).=C2=A0

b. Over-reliance on permission mechan= isms which have already been stretched to the breaking point, leaving the p= otential for collateral damage in data channel-only scenarios. Due to limit= ations in the current permissions mechanisms, it is not currently practical= ly impossible to distinguish legitimate data channel applications that woul= d obtain permissions if there were usable means to do so from illegitimate = applications attempting to compromise user privacy.=C2=A0

Data-channel only scenarios that would be impacted include those wh= ere:

1. Permissions cannot be obtained (e.g. = where there is no microphone or camera attached to the device so that getUs= erMedia will always fail).=C2=A0

2. Low latency co= mmunications is a requirement so that TURN server traversal is unacceptable= (e.g. in financial applications where there may be regulatory requirements= relating to allowable delays).

3. TURN traversal = would impose an unacceptable financial cost, such as in branch office scena= rios where a TURN servers is not provided in each branch office, and branch= office connectivity may be constrained (still an issue for branch offices = located on other continents).=C2=A0

Essentially, t= he problem is that these scenarios may have valid reasons why they cannot u= tilize or do not wish to utilize getUserMedia as a permission-granting mech= anism.=C2=A0=C2=A0



<= br>


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000004e6900575d86290-- From nobody Fri Sep 14 10:46:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10205130DFB for ; Fri, 14 Sep 2018 10:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqVxT4MEDAiJ for ; Fri, 14 Sep 2018 10:46:44 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 7D93C130934 for ; Fri, 14 Sep 2018 10:46:44 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v9-v6so8191852ljk.4 for ; Fri, 14 Sep 2018 10:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gNxCj4IboLgAnLZzzR6tlsjmlQtR6W4CNHTsKANSV7E=; b=JFxXpXQSvx9sWqRe6jztfwaOmz48rr5Kk0r4gT6izAavkQKk8vIkKsZpJrp1UuFr9k hnLwyB8qKjVfQmBv4Z8f6KB9v//65B6Q5rBf7DXYIbiBL+W2/WxssykWU2wpSyZ5vQYW dxdG2JDkLFSTBU+iE7E7S7vhN9+WEMKUJYr8Pxk3nr3uo5uLam+wRxw0bhC6qciU/4mi SRwARcWkkL0c6+L3CeT43zRcZH4Vi7SZn6iw3XwZDA9a77g05W+KfAREXc22DLAU5vMl vw6liCj64oZsIX8qxyyS7sXsa7oNti1bnsQGD4if//V5xumyUICKTMsS5ZErHZM0S+fz 2QoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gNxCj4IboLgAnLZzzR6tlsjmlQtR6W4CNHTsKANSV7E=; b=WXhu5vLR3hT1/n3On7lR9jN44GPMlm0ybMglXY3oaPn7UsVm7JdrTH8UeoqeSP51Tn OWnNbmbc8ikippPqwYCdw2OU7CMo+jhMkvmu6e3wesafN8xJ/8RvbVAGU3QZccwPfqXW QEAdZrPUi9uYXhp3T8mj1rtKcVOdgnoBYYUQychGbn8eXpvxQZNOeSm3/fykZ6qvCSup CNIR9dfIo3d7rC+inhS4exZ9CSbXhXQMlmSaIDV85yor4O3vmcfjFy80lvGE4Ro3StOU +CF/OGViuauXZ0Hxam0i3e0G+Eeyi3DWTXYbz33Y8wmFWKot1MYKHziCuejm0BKyZ2QB ndUQ== X-Gm-Message-State: APzg51BMCQ1JlOwouDMb6ynUYS/oj8w/S06wxC0wSdSoqWQLj5lfb3eW l0DYYiY5Px3gvuZwZiI+xBV0XkJ0eVUbO1wyin0= X-Google-Smtp-Source: ANB0VdZIIXWBEo+VOdFST8O/gFaZpnjgyi4BGQwM0IdipDtrSypd9zXbXwbxXYwxUSe5MVWmlGEtw6WcOJVYHd7F6Uw= X-Received: by 2002:a2e:58b:: with SMTP id 133-v6mr8251616ljf.28.1536947202544; Fri, 14 Sep 2018 10:46:42 -0700 (PDT) MIME-Version: 1.0 References: <6370f43ad94440e4a2e5b7641dbe54ca@ericsson.com> <05f502dd-4441-36ee-19c1-4e9f4b1eac80@nostrum.com> In-Reply-To: <05f502dd-4441-36ee-19c1-4e9f4b1eac80@nostrum.com> From: youenn fablet Date: Fri, 14 Sep 2018 10:46:31 -0700 Message-ID: To: Adam Roach Cc: Christer Holmberg , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000bd6b60575d86874" Archived-At: Subject: Re: [rtcweb] mdns-ice-candidates: Single IP address:port X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 17:46:47 -0000 --0000000000000bd6b60575d86874 Content-Type: text/plain; charset="UTF-8" > > Part of why this wasn't simple enough to slipstream into the existing > documents is that we don't have well-defined handling in SDP for dealing > with names in the field of "c=" lines. The extent of > RFC 4566's text on the topic is: > > > A session description can contain domain names in the "o=", "u=", > "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply > with [1], [2]. Internationalised domain names (IDNs) MUST be > represented using the ASCII Compatible Encoding (ACE) form defined in > [11] and MUST NOT be directly represented in UTF-8 or any other > encoding (this requirement is for compatibility with RFC 2327 and > other SDP-related standards, which predate the development of > internationalised domain names). > > > Unfortunately, this doesn't provide a lot of clarity about what happens if > a DNS lookup of the corresponding domain name returns multiple A or AAAA > records. (The fact that "c=" lines clearly indicate their address family > saves us from having to worry about any happy-eyeballs-style address family > fiddling, but the handling of name lookups is still somewhat ambiguous). > > So I think we need to reach a common understanding about how to handle the > normal name-to-address mapping case, and then apply the same principle to > mDNS as we do to DNS. > I agree with the principle. In practice though, MDNS might be simpler to use. The MDNS specification does not require an application to register a name for both IPv4 and IPv6. We might end up with two different MDNS ids for IPv4 and IPv6, each id resolving to exactly one record. --0000000000000bd6b60575d86874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

Part of why this wasn't si= mple enough to slipstream into the existing documents is that we don't have well-defined handling in SDP for dealing with names in the <connection-address> field of "c=3D" lines. The extent of RFC 4566's text on the t= opic is:


=C2=A0=C2=A0 A session description can contain domain names in the &= quot;o=3D", "u=3D",
=C2=A0=C2=A0 "e=3D", "c=3D", and "a=3D"= lines.=C2=A0 Any domain name used in SDP MUST comply
=C2=A0=C2=A0 with [1], [2].=C2=A0 Internationalised domain names (IDN= s) MUST be
=C2=A0=C2=A0 represented using the ASCII Compatible Encoding (ACE) fo= rm defined in
=C2=A0=C2=A0 [11] and MUST NOT be directly represented in UTF-8 or an= y other
=C2=A0=C2=A0 encoding (this requirement is for compatibility with RFC= 2327 and
=C2=A0=C2=A0 other SDP-related standards, which predate the developme= nt of
=C2=A0=C2=A0 internationalised domain names).


Unfortunately, this doesn't provide a lot of clarity about what happens if a DNS lookup of the corresponding domain name returns multiple A or AAAA records. (The fact that "c=3D" lines cle= arly indicate their address family saves us from having to worry about any happy-eyeballs-style address family fiddling, but the handling of name lookups is still somewhat ambiguous).

So I think we need to reach a common understanding about how to handle the normal name-to-address mapping case, and then apply the same principle to mDNS as we do to DNS.

<= div dir=3D"ltr">
I agree with the principle.=
In practice though, MDNS might be simpler to use.
The MDNS = specification does not require an application to register a name for both I= Pv4 and IPv6.
We mi= ght end up with two different MDNS ids for IPv4 and IPv6, each id resolving= to exactly one record.

--0000000000000bd6b60575d86874-- From nobody Fri Sep 14 10:48:08 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B25C130E23 for ; Fri, 14 Sep 2018 10:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OazQxDbeMdqv for ; Fri, 14 Sep 2018 10:48:04 -0700 (PDT) Received: from smtp001-out.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03638130934 for ; Fri, 14 Sep 2018 10:48:03 -0700 (PDT) Received: (qmail 16559 invoked from network); 14 Sep 2018 17:48:02 -0000 X-APM-Authkey: 255286/0(159927/0) 2986 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 14 Sep 2018 17:48:02 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 2203318A0A0E; Fri, 14 Sep 2018 18:48:02 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GHHI3oqTQiTz; Fri, 14 Sep 2018 18:48:02 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id F0D2B18A0963; Fri, 14 Sep 2018 18:48:01 +0100 (BST) From: westhawk Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F156FF96-6EA4-4273-B182-450E0BB83E94" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 14 Sep 2018 18:47:59 +0100 In-Reply-To: Cc: RTCWeb IETF To: Bernard Aboba References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 17:48:07 -0000 --Apple-Mail=_F156FF96-6EA4-4273-B182-450E0BB83E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2018, at 08:09, Bernard Aboba = wrote: >=20 > Data-channel only scenarios that would be impacted include those = where: I=E2=80=99d argue that sendonly video is also impacted - things like = town-hall meetings etc T.= --Apple-Mail=_F156FF96-6EA4-4273-B182-450E0BB83E94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2018, at 08:09, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Data-channel only scenarios that = would be impacted include those = where:


I=E2=80=99d argue  that sendonly = video is also impacted - things like town-hall meetings etc
T.
= --Apple-Mail=_F156FF96-6EA4-4273-B182-450E0BB83E94-- From nobody Fri Sep 14 11:55:51 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A2C130DCB for ; Fri, 14 Sep 2018 11:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FHDYml3B2yU for ; Fri, 14 Sep 2018 11:55:47 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A2D130DC4 for ; Fri, 14 Sep 2018 11:55:47 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id b129-v6so4794227pga.13 for ; Fri, 14 Sep 2018 11:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LgRIPOSVePtYz2kKSlMsbig0DqRcw1TygWqhhbuBcHY=; b=BZC6KmFq4OAD8pP8YMGy9Rwd8J0t3dIU9+KaaRUySeMTR9QSgYyHvOvM3QyGAlidfC v39mAUG66bEtfY15hU0r6dxEzHoTdrRhoAw5NKfZwgadadjiht5mwYtNXnJY7mm8wyeo KBkAkV1zHzshQcFdCkMfyp/zuoxRWC/tt+SjqLGCVUM/2B3DAMw3P/4hy1NZfhOtd+VE uQqEmthz3nYEuksQUIRW04Ir28hf/7N52DToJKBccA/FbeKD0Vjem1/8qKsdkUe/uRss HbtkJI9PeUdPLU/xY8Jute6RFAsWQ/+cCrblH7fU4ZkO9YjBp4YxZvfvBZsFV79oezRQ bl5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LgRIPOSVePtYz2kKSlMsbig0DqRcw1TygWqhhbuBcHY=; b=LCKDaGkiwRCny5WKqWk2IRSGkbeB+CpWpU5HfinCX9yr3Eg4ROXPlgLhwHBtLdQnW2 zRfgZwTpT7esliteZ+tVly5Uw8nMDbyJI2BBcr6Ls+NdI8A+KWRZA7HcXL8ul0IRkquu ApnUiITly02HVw39bOoBjxCCqutydWJ4dopNYMfEyAjQIs72yGhOwjScsihfYGgTO9PR y6mpK2wGOex5OSSyEXWZnGj2j9O40kvhNQENKJpzr+FH9M6G5uaKcdYlpVpWPVOA9Pk4 KVWDa7McPdB5Dp3sOPv22rUSOx80nVmE1Oyz3HX43mlwjKcK3L41g3Vdo6hqErABvAWx v1ug== X-Gm-Message-State: APzg51A2J/gAi49gFTc3MJFOG9lIgPwjpIQAfBvP3KXiEKfhXfYV/Ihw J9mc1amn/ptu0ZQsaXBq4Dugnb4C X-Google-Smtp-Source: ANB0VdYn8A9xoiLNwRnQcwpuEWLbnk0mQq/IJC7EL2iWNDOF9Oot1/q+wm+gbUiW5CmKjs/o6Wb9ig== X-Received: by 2002:aa7:8591:: with SMTP id w17-v6mr13906495pfn.77.1536951346565; Fri, 14 Sep 2018 11:55:46 -0700 (PDT) Received: from ?IPv6:2600:380:8658:7f45:5433:3218:7f20:2992? ([2600:380:8658:7f45:5433:3218:7f20:2992]) by smtp.gmail.com with ESMTPSA id y4-v6sm9145880pfm.137.2018.09.14.11.55.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 11:55:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Fri, 14 Sep 2018 11:55:44 -0700 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> References: To: westhawk Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 18:55:50 -0000 Good point. In that scenario (where getUserMedia isn=E2=80=99t called) the c= urrent permissions model wouldn=E2=80=99t even allow presentation of alterna= tive output audio devices (e.g. speaker or headphones).=20 > On Sep 14, 2018, at 10:47 AM, westhawk wrote: >=20 > I=E2=80=99d argue that sendonly video is also impacted - things like town= -hall meetings etc > T. From nobody Fri Sep 14 12:49:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256A5130E6B for ; Fri, 14 Sep 2018 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjvnrFG1wDJu for ; Fri, 14 Sep 2018 12:49:15 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EF5130E3A for ; Fri, 14 Sep 2018 12:49:15 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id y17-v6so8456321ljy.8 for ; Fri, 14 Sep 2018 12:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B0PcHXfVcUYLJyoo/GKv+wz6+S9cOcfE1GW4exjvm5o=; b=C6F0ikMiLAo8hFYqcRGqZS60/9GElgn/+eoh55Wsv19K3qsqi5EdgFM4g2j3knorGp iVAFRhcshu7K1MiX78fnzNOUCraTVn3Smmm92ipi/49oaL3tDIQ2MKxL0SbYmgDW/fjb eTbXMVtuOBFrUGCYZTd42wgYpABoNWC1Rz+qxdeX49l6D7wft0WLjQncT+JyTMOyFrnE XR76VHWYKUX5Rv3s9jCAwpT9UzFFvERkXpV6Ui8AEFe/Ub0vdl2fS9A4T/NvWGHViRjV Wqx5IpEUL9DcvIzeeVT0TryQKJceXE8zecYIuaW0lpYr69QGZC2/2f5y02FrkqR5J/gd f47A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B0PcHXfVcUYLJyoo/GKv+wz6+S9cOcfE1GW4exjvm5o=; b=e0AYVNr3+iXhUEwLGBE9uqUHVGqfvbYCFGoU/LM/muH7ZLmidc7nweAFbqzZMpDWSs WYISWKjD45wjLQ1RD6IkoESm+BcCqzA3yIYg6RG9l8gesX09pFQomK0qVNGj61xV7+Rd PbQRHfngRqBuch2+zFbo+tHBumLVHP/KgGUvBVu0jKApCU5Q4wTt09BQ+VmAxk1M4fJI Yn2Gf1w8AP5N9ytTJwzCi7KJnfmuZt9CToviAqOkVimjrk4Aojvs813FC2+wPAsqNetp 5wUd5KyUgiC1gSBIssw3XOQylwDVfh5OsiLJU2vEQ8xThkP0e3k8Tl1Da/W14j/vEO7Z VtfA== X-Gm-Message-State: APzg51Bb3QmKzFz3Rt2dFSYVSvzg+Rp88eUPxMjXzNFBvJaw0cCN73Ly b7AXBGcLEBcq9/c2Bb1XSAg/sEqXE8rziQROk38= X-Google-Smtp-Source: ANB0VdaGmlKGNieoi/NyH1JYkseq4Nzo4RmaCrukQJLs2FoI1tG0nKI0jhursFwPBELhxxsI10nd4DbmcAto98+rTL0= X-Received: by 2002:a2e:8188:: with SMTP id e8-v6mr8645190ljg.138.1536954553392; Fri, 14 Sep 2018 12:49:13 -0700 (PDT) MIME-Version: 1.0 References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> In-Reply-To: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> From: youenn fablet Date: Fri, 14 Sep 2018 12:49:01 -0700 Message-ID: To: Bernard Aboba Cc: westhawk , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000030e2e30575da1e5b" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 19:49:19 -0000 --00000000000030e2e30575da1e5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 14 sept. 2018 =C3=A0 11:56, Bernard Aboba = a =C3=A9crit : > Good point. In that scenario (where getUserMedia isn=E2=80=99t called) th= e current > permissions model wouldn=E2=80=99t even allow presentation of alternative= output > audio devices (e.g. speaker or headphones). > Is that an issue though? How is it different than viewing regular DASH/HLS content? I would hope that the browser makes a good job at selecting the right output in such case. If it does not do so, maybe that is a browser bug. Or maybe the page could provide hints so that the browser does the right selection. To return to the initial question, in the sendonly/town-hall meeting scenario, what is the configuration that mandates exposing host candidates? How common is it? > > On Sep 14, 2018, at 10:47 AM, westhawk wrote: > > > > I=E2=80=99d argue that sendonly video is also impacted - things like t= own-hall > meetings etc > > T. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000030e2e30575da1e5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le=C2=A0ven. 14 sept. 2018 =C3=A0=C2=A011:56, Bernard= Aboba <bernard.aboba@gmail.c= om> a =C3=A9crit=C2=A0:
Good point. In that scenario (where getUserMedi= a isn=E2=80=99t called) the current permissions model wouldn=E2=80=99t even= allow presentation of alternative output audio devices (e.g. speaker or he= adphones).

Is that an issue though? Ho= w is it different than viewing regular DASH/HLS content?
I would = hope that the browser makes a good job at selecting the right output in suc= h case.
If it does not do so, maybe that is a browser bug. Or may= be the page could provide hints so that the browser does the right selectio= n.=C2=A0
=C2=A0
To return to the initial question, in t= he sendonly/town-hall meeting scenario, what is the configuration that mand= ates exposing host candidates? How common is it?


> On Sep 14, 2018, at 10:47 AM, westhawk <thp@westhawk.co.uk> wrote:
>
> I=E2=80=99d argue=C2=A0 that sendonly video is also impacted - things = like town-hall meetings etc
> T.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000030e2e30575da1e5b-- From nobody Fri Sep 14 13:01:19 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD45130F61 for ; Fri, 14 Sep 2018 13:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEnaODviYZLE for ; Fri, 14 Sep 2018 13:01:02 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCB0130F58 for ; Fri, 14 Sep 2018 13:01:01 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id x17-v6so4781025pfh.5 for ; Fri, 14 Sep 2018 13:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46ZJ2p6gCizBnq0ka0JdpunUN9x6ZE7elb6xiOpuFRw=; b=LtVj1k0iZM3C1iEQNKS47v/E2VF1td12u3s7VP7QNMjv4UyXO2SnuQTTBg2unfsGOJ Hi7UdkLHXg8G+jRG/66yKI44yTkc3cLsXp12C+tTAevzEPZ8yLA0fKBj1foB0OuqldQ6 1CNEwuouPIQeyhhgdbYKLdhwrDsWsPVc7qDNuH03W3FFDJOXB4wtzFbrNBTv2KmDZF20 TVYRfA0PnpGY3KVop0XW9Ah3c6a5rs06Pe8AVrIzU2mqP6qcvfm3y+viwR6MQIiqSka8 /FtIDBAEv+1KxKb8JvEhbMTSQ8h4L7BAZsOzf8YRigvZ8v8yhA/avcviJV3odx21E1Xs rwcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=46ZJ2p6gCizBnq0ka0JdpunUN9x6ZE7elb6xiOpuFRw=; b=RHp6LfYYJ0Rw2sURzXskJC5QzwvnnSnePvrqd0XyElKJ22gWkf7cVlOF2u+F/DE5ST 8gdCj1TMOjSXy0+2UJgId2UFLqhiPlhsZgZT5rN8qSO93QhVlpMEqumi9KjVGzEGu+0t fs3x4XZ7jCFnf8moHZyx3BnSM9ltV+w2uEn9MgYIusuKo0qSfaeot0qWFblWk9Ol/rX6 Gd6PQNbyPPYjJPMP+mi3hSAdnSSB5l/6T5y++R3dEGog10RZVsQ/hqaj4lJHrtoX7Bh9 tkn8RgZDR0avz00Mcygm+3BfGmmFEdmKZSsDdyBKI1X+pqOy1+Lz8j+JgayJnuTweLuI SAhw== X-Gm-Message-State: APzg51CSglsylEVGphFzM4ja+1gpUsn4NjuirvfErSr5bR7ugDeMeYgm QKAtKV8i9yZowgM5ZdREslI= X-Google-Smtp-Source: ANB0VdZ2+FFpjwVNmlzAYNVDizlbFkU2pZNAQ5aEXq8NkTzGrtQat0m2tsmYIP7pDasnWVOLjUb09A== X-Received: by 2002:a63:6183:: with SMTP id v125-v6mr13516741pgb.242.1536955260308; Fri, 14 Sep 2018 13:01:00 -0700 (PDT) Received: from ?IPv6:2600:380:8658:7f45:5433:3218:7f20:2992? ([2600:380:8658:7f45:5433:3218:7f20:2992]) by smtp.gmail.com with ESMTPSA id s16-v6sm9540075pfm.114.2018.09.14.13.00.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 13:00:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (15G77) In-Reply-To: Date: Fri, 14 Sep 2018 13:00:58 -0700 Cc: westhawk , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> To: youenn fablet Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 20:01:18 -0000 On Sep 14, 2018, at 12:49 PM, youenn fablet wrote: > To return to the initial question, in the sendonly/town-hall meeting scena= rio, what is the configuration that mandates exposing host candidates? How c= ommon is it? [BA] Assuming that WebRTC is used instead of streaming media, the scenario o= ften involves communication within an enterprise network, such as a group, d= ivisional or campus-wide company meeting. getUserMedia is only called when a= n employee needs to ask a question (or sometimes questions are pre-selected)= . Employees watch the meeting at their desks. In these scenarios, media often flows directly on the multi-segment corpnet b= etween host candidate pairs without a relay.= From nobody Fri Sep 14 13:09:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A43130E1F for ; Fri, 14 Sep 2018 13:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdmeKNDuxZpx for ; Fri, 14 Sep 2018 13:09:15 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1131130E28 for ; Fri, 14 Sep 2018 13:09:14 -0700 (PDT) Received: (qmail 84618 invoked from network); 14 Sep 2018 20:09:13 -0000 X-APM-Authkey: 255286/0(159927/0) 3038 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Sep 2018 20:09:13 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 3833918A02B6; Fri, 14 Sep 2018 21:09:13 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XzR-Z8x1QF6t; Fri, 14 Sep 2018 21:09:13 +0100 (BST) Received: from [192.67.4.84] (unknown [192.67.4.84]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A7C5318A00F7; Fri, 14 Sep 2018 21:09:12 +0100 (BST) From: westhawk Message-Id: <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_E6B4335C-AB5A-4C2F-90B6-38B9B38D5D15" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 14 Sep 2018 21:09:10 +0100 In-Reply-To: Cc: Bernard Aboba , RTCWeb IETF To: youenn fablet References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 20:09:19 -0000 --Apple-Mail=_E6B4335C-AB5A-4C2F-90B6-38B9B38D5D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2018, at 20:49, youenn fablet wrote: >=20 > Le ven. 14 sept. 2018 =C3=A0 11:56, Bernard Aboba = > a =C3=A9crit = : > Good point. In that scenario (where getUserMedia isn=E2=80=99t called) = the current permissions model wouldn=E2=80=99t even allow presentation = of alternative output audio devices (e.g. speaker or headphones).=20 >=20 > Is that an issue though? How is it different than viewing regular = DASH/HLS content? > I would hope that the browser makes a good job at selecting the right = output in such case. > If it does not do so, maybe that is a browser bug. Or maybe the page = could provide hints so that the browser does the right selection.=20 > =20 > To return to the initial question, in the sendonly/town-hall meeting = scenario, what is the configuration that mandates exposing host = candidates? How common is it? I don=E2=80=99t know - but here are the cases I=E2=80=99ve come across: 1) Burning man video relay - There is often decent bandwidth across the = playa on a segmented class B but=20 terrible connectivity to the outside world. If you want to relay audio = and video from an art performance you _really_ want to keep the media within the class B. MDNS won=E2=80=99t = do the trick because of the segmentation. I imagine there are corporate networks that look like this too. 2) (I need to test the MDNS properties of this one) - Drone wifi = tethered to a smartphone, with the smartphone on 4g. You want video from the drone (and control data channel) to use the wifi = link for the webRTC connection. Tim. >=20 >=20 > > On Sep 14, 2018, at 10:47 AM, westhawk > wrote: > >=20 > > I=E2=80=99d argue that sendonly video is also impacted - things = like town-hall meetings etc > > T. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb = --Apple-Mail=_E6B4335C-AB5A-4C2F-90B6-38B9B38D5D15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2018, at 20:49, youenn fablet <youennf@gmail.com> = wrote:

Le ven. 14 sept. 2018 = =C3=A0 11:56, Bernard Aboba <bernard.aboba@gmail.com> a =C3=A9crit :
Good point. In that scenario (where getUserMedia = isn=E2=80=99t called) the current permissions model wouldn=E2=80=99t = even allow presentation of alternative output audio devices (e.g. = speaker or headphones).

Is that an issue though? How is it = different than viewing regular DASH/HLS content?
I = would hope that the browser makes a good job at selecting the right = output in such case.
If it does not do so, maybe = that is a browser bug. Or maybe the page could provide hints so that the = browser does the right selection. 
 
To return to the initial = question, in the sendonly/town-hall meeting scenario, what is the = configuration that mandates exposing host candidates? How common is = it?

I don=E2=80=99t know - but here are the cases = I=E2=80=99ve come across:

1) Burning = man video relay - There is often decent bandwidth across the playa on a = segmented class B but 
terrible connectivity to the = outside world. If you want to relay audio and video from an art = performance you
 _really_ want to keep the media =  within the class B. MDNS won=E2=80=99t do the trick because of the = segmentation.

I imagine there are = corporate networks that look like this too.

2) (I need to test the MDNS properties of this = one) - Drone wifi tethered to a smartphone, with the smartphone on = 4g.
You want video from the drone (and control data channel) = to use the wifi link for the webRTC connection.

Tim.









> On Sep 14, 2018, at 10:47 AM, westhawk <thp@westhawk.co.uk> wrote:
>
> I=E2=80=99d argue  that sendonly video is also impacted - = things like town-hall meetings etc
> T.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
=

= --Apple-Mail=_E6B4335C-AB5A-4C2F-90B6-38B9B38D5D15-- From nobody Fri Sep 14 14:21:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835E8130E43 for ; Fri, 14 Sep 2018 14:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkxBf9lMcb6A for ; Fri, 14 Sep 2018 14:21:07 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D2C128C65 for ; Fri, 14 Sep 2018 14:21:06 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id v26-v6so8626032ljj.3 for ; Fri, 14 Sep 2018 14:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OnDvckO1gSouXI294tk8O6cJfk4AWHSHcvXqbcwc5LA=; b=XdD20F2TEx6HQ2BEojCvH70M3ie5jOfs9OzVW5n6B9icRGNjxZ+JjTHnkUGQeyK/Ej OQTbmPB3olPlD0BVN8vu0Kji5+5fhU7q2uyk/rVdIXjLOfStAJk6PVlLIfuux7KErIBN eBMRN9GXUVz6qIQJLw9hzFGBhoFdu8TPgA3x6BaH0P1bTv0qFKhTLmW4IdZs0YalAFtQ x6RDRIFCn/RWvWQ8qfG5q4EPAek95ZYRRHANzW5s1rH+tXafrH/cYBXmXHVYBEI9EkKy npAj4iQppxa/xh9HwBARDCFEnOBgwjhTOKEwf9NqzrYa91+AziUbnqh5Ao7zAWWydQsp SWxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OnDvckO1gSouXI294tk8O6cJfk4AWHSHcvXqbcwc5LA=; b=Hd9wHjo14+CikAvNuV5ReaeHNn4JhdBZwme8xZVNvtNwmSlKT7ByGMXc6y9ic/t/0e lzKRAIbcb7kjllDRsLZLqoCw0cwemeCML+e696MtbhUNtMpUVA6AvNuSdxE6keN60eDf IddxnNEHoSRTdHnkmXaWEsISQxz6pLsU2x4T4Zf6avxMuCUP+IXJnkQ3lgcEHtkbtuGq OAzvpDnjvuGxqa2lPoC0ZdsXByDNjjXaTSrbCBoERNwArFfcr/wmBFHnbYh8Ay+mXrMw N/Fc9A9fkBUf+1PKL/JW0S33Au0qPel6KXrrO1nS8CE1Sl72BXnL+uMBPp4cb8DpFLaQ I8BA== X-Gm-Message-State: APzg51CL0qvb6T2mpSLMrijARkIkOT2rCSWB3UjR22fzlQPHxgivxmNs KJi+wp6VkuXAVKwhfFtnQG83DPDRMqRxl4awxuA= X-Google-Smtp-Source: ANB0VdY/Qzuczjr9UKBUrOgGgkX3cHbsXcYWemHK4EJcTVCm7OUAoGozcg8aN18qMNBdfnPJyq7xYbL55F3cPrjYbmU= X-Received: by 2002:a2e:58b:: with SMTP id 133-v6mr8612957ljf.28.1536960064839; Fri, 14 Sep 2018 14:21:04 -0700 (PDT) MIME-Version: 1.0 References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> In-Reply-To: From: youenn fablet Date: Fri, 14 Sep 2018 14:20:53 -0700 Message-ID: To: Bernard Aboba Cc: westhawk , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000b2ef3f0575db66c4" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 21:21:09 -0000 --000000000000b2ef3f0575db66c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 14 sept. 2018 =C3=A0 13:01, Bernard Aboba = a =C3=A9crit : > On Sep 14, 2018, at 12:49 PM, youenn fablet wrote: > > To return to the initial question, in the sendonly/town-hall meeting > scenario, what is the configuration that mandates exposing host candidate= s? > How common is it? > > [BA] Assuming that WebRTC is used instead of streaming media, the scenari= o > often involves communication within an enterprise network, such as a grou= p, > divisional or campus-wide company meeting. getUserMedia is only called wh= en > an employee needs to ask a question (or sometimes questions are > pre-selected). Employees watch the meeting at their desks. > > In these scenarios, media often flows directly on the multi-segment > corpnet between host candidate pairs without a relay. Is the sender a web browser? Is the sender sending the media to each receiver or are there some receivers acting as senders to other receivers? --000000000000b2ef3f0575db66c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2= =A0ven. 14 sept. 2018 =C3=A0=C2=A013:01, Bernard Aboba <bernard.aboba@gmail.com> a =C3=A9crit=C2= =A0:
On Sep 14, 2018, at 12:49 PM, = youenn fablet <yo= uennf@gmail.com> wrote:
> To return to the initial question, in the sendonly/town-hall meeting s= cenario, what is the configuration that mandates exposing host candidates? = How common is it?

[BA] Assuming that WebRTC is used instead of streaming media, the scenario = often involves communication within an enterprise network, such as a group,= divisional or campus-wide company meeting. getUserMedia is only called whe= n an employee needs to ask a question (or sometimes questions are pre-selec= ted).=C2=A0 Employees watch the meeting at their desks.

In these scenarios, media often flows directly on the multi-segment corpnet= between host candidate pairs without a relay.

<= div>Is the sender a web browser?
Is the sender sending the media = to each receiver or are there some receivers acting as senders to other rec= eivers?
--000000000000b2ef3f0575db66c4-- From nobody Fri Sep 14 15:02:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62096130E7E for ; Fri, 14 Sep 2018 15:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qF9XfpFdiUaG for ; Fri, 14 Sep 2018 15:02:07 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15467130E62 for ; Fri, 14 Sep 2018 15:02:06 -0700 (PDT) Received: (qmail 13910 invoked from network); 14 Sep 2018 22:02:05 -0000 X-APM-Authkey: 255286/0(159927/0) 3055 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 14 Sep 2018 22:02:05 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 875DD18A046D; Fri, 14 Sep 2018 23:02:05 +0100 (BST) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id x9I_5ux-ES2Z; Fri, 14 Sep 2018 23:02:05 +0100 (BST) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 4F50D18A01E5; Fri, 14 Sep 2018 23:02:05 +0100 (BST) From: T H Panton Message-Id: <5763778B-0E13-44B6-AE5A-0BF011873F23@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F500ED2-0E7C-4F2A-B808-6F693892BD18" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 14 Sep 2018 23:02:04 +0100 In-Reply-To: Cc: Bernard Aboba , RTCWeb IETF To: youenn fablet References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 22:02:10 -0000 --Apple-Mail=_3F500ED2-0E7C-4F2A-B808-6F693892BD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Sep 2018, at 22:20, youenn fablet wrote: >=20 >=20 >=20 > Le ven. 14 sept. 2018 =C3=A0 13:01, Bernard Aboba = > a =C3=A9crit = : > On Sep 14, 2018, at 12:49 PM, youenn fablet > wrote: > > To return to the initial question, in the sendonly/town-hall meeting = scenario, what is the configuration that mandates exposing host = candidates? How common is it? >=20 > [BA] Assuming that WebRTC is used instead of streaming media, the = scenario often involves communication within an enterprise network, such = as a group, divisional or campus-wide company meeting. getUserMedia is = only called when an employee needs to ask a question (or sometimes = questions are pre-selected). Employees watch the meeting at their = desks. >=20 > In these scenarios, media often flows directly on the multi-segment = corpnet between host candidate pairs without a relay. >=20 > Is the sender a web browser? In the Drone case no.=20 In the Town hall case probably not - there will be some sort of = camera/MUX device if there are more than a few users. > Is the sender sending the media to each receiver or are there some = receivers acting as senders to other receivers? In the problematic scenarios I'm looking at things are either senders or = receivers, never both. T. --Apple-Mail=_3F500ED2-0E7C-4F2A-B808-6F693892BD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 14 Sep 2018, at 22:20, youenn fablet <youennf@gmail.com> = wrote:



Le ven. 14 sept. = 2018 =C3=A0 13:01, Bernard Aboba <bernard.aboba@gmail.com> a =C3=A9crit :
On Sep 14, 2018, at = 12:49 PM, youenn fablet <youennf@gmail.com> wrote:
> To return to the initial question, in the sendonly/town-hall = meeting scenario, what is the configuration that mandates exposing host = candidates? How common is it?

[BA] Assuming that WebRTC is used instead of streaming media, the = scenario often involves communication within an enterprise network, such = as a group, divisional or campus-wide company meeting. getUserMedia is = only called when an employee needs to ask a question (or sometimes = questions are pre-selected).  Employees watch the meeting at their = desks.

In these scenarios, media often flows directly on the multi-segment = corpnet between host candidate pairs without a relay.

Is the sender a web = browser?

In the Drone case no. 
In the Town = hall case probably not - there will be some sort of camera/MUX device if = there are more than a few users.

Is the sender sending the media to = each receiver or are there some receivers acting as senders to other = receivers?

In the problematic = scenarios I'm looking at things are either senders or receivers, never = both.

T.

= --Apple-Mail=_3F500ED2-0E7C-4F2A-B808-6F693892BD18-- From nobody Fri Sep 14 17:42:20 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F227130DC3 for ; Fri, 14 Sep 2018 17:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsAcQG8tPYDv for ; Fri, 14 Sep 2018 17:42:16 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C303126F72 for ; Fri, 14 Sep 2018 17:42:16 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id p10-v6so8879241ljg.2 for ; Fri, 14 Sep 2018 17:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yZzWmrhDb70hZO2VHZQkJWvvQI+T1xZqmElCRHVPD6A=; b=reeliyIDZ0GieVT5iZEgHNa5xgoNlwbeEjcpCQqhPAV9ts+bEFAXddNib4z5Orixju eIvv6IcAkPBZmWwQNa4KOpXP/mW25D/9gOg3UhqhU3TQ8lx5oCW04iH/ofok9qZ8Hw07 LA5bChxF3NjgS62O2YKmYV1DrW7miGrG7OJB1tEl9VHA4t1PkcF7QqUvANlzlOhX2t4o ZsQXqZ4YbTkzmE9ZNIDZbZmMFdCuiDlwbbMDrN7X3r/o+5v75hT/gAi8aH3KY8NkGk2/ M/Ki3x7JhfJmpDTpGOl2HyuS7CJoDZa5qgMp9D3c8lQVN0dwB0h5Ls/p4QIAFZo7sDqU Xi0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yZzWmrhDb70hZO2VHZQkJWvvQI+T1xZqmElCRHVPD6A=; b=By+kF3cNy8EuEf9VwnJ/aYj846BeA7BKEl5ck+7FVsf3N9Nd5M+xzMxMbbaxo9ret5 3kK6z+F/W2U4UzjOJyuNyLRwIsWIr8NkO6/vaDnkQbZcVMY33GWY/jzeBrgE1VxH4uFB 0afS+blnCF+odcSrOeO3zLftcmoXVJSPJgXTB+Pa2Mi77ElYmbEZ/Tb3ESOZRqZyG3OV 5jNpLT0kO+L8ZxIzoa5pbHtSP8i2RxEcU3dxIswU3x0Pp1reN5JbhAHmPr1RKm7ATzEx RmPxIzyOWd19c2uKlo1UF4DMKzf3PS+0CuxixFK6UEY2298uZegctqLqVh9ZuDrF17Iv rOgw== X-Gm-Message-State: APzg51BaWip0kte1MvEAnGk9/A/aer7ViX+vHQcVg6nW3lBp776cNvXh PFo05pP5Cl4q18+NY5zpX6/BlqQaMUTwnZvpjvPLGhv5 X-Google-Smtp-Source: ANB0Vdb1JUKWQtx2SwgmCofUDtbSZOk/84I0qKApqFaRQaawxTlitpseRy4PIO9wfIuWXl9eZ0XEKWrY/Eaaiv0tT8E= X-Received: by 2002:a2e:8513:: with SMTP id j19-v6mr9115373lji.10.1536972134624; Fri, 14 Sep 2018 17:42:14 -0700 (PDT) MIME-Version: 1.0 References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <5763778B-0E13-44B6-AE5A-0BF011873F23@westhawk.co.uk> In-Reply-To: <5763778B-0E13-44B6-AE5A-0BF011873F23@westhawk.co.uk> From: youenn fablet Date: Fri, 14 Sep 2018 17:42:02 -0700 Message-ID: To: T H Panton Cc: Bernard Aboba , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000001d328e0575de36be" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 00:42:19 -0000 --0000000000001d328e0575de36be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 14 sept. 2018 =C3=A0 15:02, T H Panton a =C3= =A9crit : > > On 14 Sep 2018, at 22:20, youenn fablet wrote: > > > > Le ven. 14 sept. 2018 =C3=A0 13:01, Bernard Aboba a > =C3=A9crit : > >> On Sep 14, 2018, at 12:49 PM, youenn fablet wrote: >> > To return to the initial question, in the sendonly/town-hall meeting >> scenario, what is the configuration that mandates exposing host candidat= es? >> How common is it? >> >> [BA] Assuming that WebRTC is used instead of streaming media, the >> scenario often involves communication within an enterprise network, such= as >> a group, divisional or campus-wide company meeting. getUserMedia is only >> called when an employee needs to ask a question (or sometimes questions = are >> pre-selected). Employees watch the meeting at their desks. >> >> In these scenarios, media often flows directly on the multi-segment >> corpnet between host candidate pairs without a relay. > > > Is the sender a web browser? > > > In the Drone case no. > In the Town hall case probably not - there will be some sort of camera/MU= X > device if there are more than a few users. > In that case, the camera/MUX device might act as a STUN/TURN server. It will probably expose all of its host candidates. Ditto if sender is a browser since getUserMedia is on. I would think the connection to be feasible through peer reflexive candidates without the receiver to expose its own host candidates to JavaScript. > Is the sender sending the media to each receiver or are there some > receivers acting as senders to other receivers? > > > In the problematic scenarios I'm looking at things are either senders or > receivers, never both. > --0000000000001d328e0575de36be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2= =A0ven. 14 sept. 2018 =C3=A0=C2=A015:02, T H Panton <thp@westhawk.co.uk> a =C3=A9crit=C2=A0:
=

On 14 Sep 2018= , at 22:20, youenn fablet <youennf@gmail.com> wrote:



Le=C2=A0ven. 14 sept. 2018 =C3=A0=C2=A0= 13:01, Bernard Aboba <bernard.aboba@gmail.com> a =C3=A9crit=C2=A0:
On Sep 14, 2018, at 12:49 PM, youenn fablet &l= t;youennf@gmail.com<= /a>> wrote:
> To return to the initial question, in the sendonly/town-hall meeting s= cenario, what is the configuration that mandates exposing host candidates? = How common is it?

[BA] Assuming that WebRTC is used instead of streaming media, the scenario = often involves communication within an enterprise network, such as a group,= divisional or campus-wide company meeting. getUserMedia is only called whe= n an employee needs to ask a question (or sometimes questions are pre-selec= ted).=C2=A0 Employees watch the meeting at their desks.

In these scenarios, media often flows directly on the multi-segment corpnet= between host candidate pairs without a relay.

<= div>Is the sender a web browser?

In that case, the camera/MUX device might act as a STUN/TURN server.

It will probably expose all of its host candidates. Di= tto if sender is a browser since getUserMedia is on.
I would thin= k the connection=C2=A0to be feasible through peer reflexive candidates with= out the receiver to expose its own host candidates to JavaScript.
=


Is the sender = sending the media to each receiver or are there some receivers acting as se= nders to other receivers?

In the problematic scenarios I'= ;m looking at things are either senders or receivers, never both.
=C2=A0
--0000000000001d328e0575de36be-- From nobody Fri Sep 14 18:00:17 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B301126F72 for ; Fri, 14 Sep 2018 18:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT75OA0lH_bi for ; Fri, 14 Sep 2018 18:00:12 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 B2F0F12008A for ; Fri, 14 Sep 2018 18:00:12 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id c12-v6so7881378uan.3 for ; Fri, 14 Sep 2018 18:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+JrP5Ctgfaa8FJIx6ThDWKYl3T+N498IdCODP9WwC2w=; b=e/8POwG3rVMqGp4pehTB2WNthIFS0qBcaDm84Ot58KnqVcfoCi3vPeyj9Cl46wef6U B8f5fvBMs2zOy9dlNf7Gx8nTYgTP3HTENKzsTCevKXTaVvD0m98waP3tnC19qVs+gNws acBC3m1O+wgJsFvX6r+TKWfYfs44cIGV1VSA3FsTfTN43vabYrcSza/iVnGaGQyDDhc8 eczugtBJFgXdCPuV2AS/1VcXMzGUw3jD0RA8Zc4Tyere8V+XrixayHRqoGyFjUSqo1eV ULeNy1I1qJJfJixy/ZNewLPz40GEnZtGbtSDidIf5kPKKWU0f+Vw13yPGNzIpAepWW6q b95Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+JrP5Ctgfaa8FJIx6ThDWKYl3T+N498IdCODP9WwC2w=; b=TKw5Ar4nK+/t2aNa89RL64HlFHvjQPtgbftT4T1RCB+bX899Tx+Evma4jBge5hYDye 9foaF70cREIITAHhrvHwgPZqRnfMbhbt7GbuAbHh53gYLctNA/M27lnQkoQJXqiiTc3z O2bcL+uVVuu3sOuO7+if19z2HnwsBIOyDgExwLQDwU0pV72Eco+vRBveCP42qaCyO8iq w3D6SvzToTOB84Hqt7tcveCjucpyDDO8eDnP3pTBJMzYYKooYCfNofSeZ7d634j8Nkj/ B8yTqJ8NPc72L8UDLzHmgfaJ69tVj3BiGxkxpB5Zg0xCjIkmqYwVmkdjIfu0UmHP8nIx 8jyw== X-Gm-Message-State: APzg51CaloFg0HzygfMCei6lCkPqds+pCxGU+CemKWN9QYxAhFGXZkgW 97WngJndxn5SrEKLA2GCwFWi6RWT7brRAwDr/G4= X-Google-Smtp-Source: ANB0VdYxLLR8o9AR6q/wz3XShbAa1pNw7KxVprAv22Khe1+wwtWeblNvjYMN4F2M5m5kbPBYZP2sYQEZ4K7g2L9+Y4I= X-Received: by 2002:ab0:4364:: with SMTP id k91-v6mr5214022uak.46.1536973211583; Fri, 14 Sep 2018 18:00:11 -0700 (PDT) MIME-Version: 1.0 References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <5763778B-0E13-44B6-AE5A-0BF011873F23@westhawk.co.uk> In-Reply-To: From: Bernard Aboba Date: Fri, 14 Sep 2018 18:00:00 -0700 Message-ID: To: youenn fablet Cc: RTCWeb IETF , T H Panton Content-Type: multipart/alternative; boundary="0000000000004e49b00575de76b2" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 01:00:15 -0000 --0000000000004e49b00575de76b2 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 14, 2018 at 5:42 PM youenn fablet wrote: > > In that case, the camera/MUX device might act as a STUN/TURN server. > [BA] In the usage I have seen the sender is a PC or Mac brought in to run the meeting; STUN/TURN servers are run by an infrastructure group and are separate. > > It will probably expose all of its host candidates. Ditto if sender is a > browser since getUserMedia is on. > I would think the connection to be feasible through peer reflexive > candidates without the receiver to expose its own host candidates to > JavaScript. > [BA] The STUN/TURN servers are often placed in the DMZ rather than on the corpnet so using addresses other than host candidates will result in hairpinning or unnecessary relaying. > >> Is the sender sending the media to each receiver or are there some >> receivers acting as senders to other receivers? >> >> [BA] For a large meeting, there is typically a conference server (SFU) which forwards video and mixes or forwards audio to the receivers, most of whom never send. --0000000000004e49b00575de76b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

In that case, the camera/MUX device might a= ct as a STUN/TURN server.
<= br>
[BA] In the usage I have seen the sender is a PC= or Mac brought in to run the meeting; STUN/TURN servers are run by an infr= astructure group and are separate.

It w= ill probably expose all of its host candidates. Ditto if sender is a browse= r since getUserMedia is on.
I would think the connection=C2=A0to = be feasible through peer reflexive candidates without the receiver to expos= e its own host candidates to JavaScript.

[BA] The STUN/TURN servers are of= ten placed in the DMZ rather than on the corpnet so using addresses other t= han host candidates will result in hairpinning or unnecessary relaying.=C2= =A0

Is the sender sending the media= to each receiver or are there some receivers acting as senders to other re= ceivers?

[BA] For = a large meeting, there is typically a conference server (SFU) which forward= s video and mixes or forwards audio to the receivers, most of whom never se= nd.


--0000000000004e49b00575de76b2-- From nobody Wed Sep 19 18:15:01 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67D0130DDD for ; Wed, 19 Sep 2018 18:15:00 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 izzQ0qc8QGTb for ; Wed, 19 Sep 2018 18:14:59 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0AD1271FF for ; Wed, 19 Sep 2018 18:14:59 -0700 (PDT) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 86A6F5A41; Wed, 19 Sep 2018 21:14:56 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A12955A42; Wed, 19 Sep 2018 21:14:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.19.248.210] ([UNAVAILABLE]. [104.153.224.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Wed, 19 Sep 2018 21:14:56 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD466A7-8DC7-4454-9388-B71B561AEA4B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk> Date: Wed, 19 Sep 2018 18:12:43 -0700 Cc: youenn fablet , RTCWeb IETF Message-Id: <73F0A366-77DC-4EE5-A6B6-D2F7112D7912@iii.ca> References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk> To: Tim Panton X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 01:15:01 -0000 --Apple-Mail=_AAD466A7-8DC7-4454-9388-B71B561AEA4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 14, 2018, at 1:09 PM, westhawk wrote: >=20 > 1) Burning man video relay - There is often decent bandwidth across = the playa on a segmented class B but=20 > terrible connectivity to the outside world. If you want to relay audio = and video from an art performance you > _really_ want to keep the media within the class B. MDNS won=E2=80=99t= do the trick because of the segmentation. >=20 > I imagine there are corporate networks that look like this too. I think the majority of large enterprise networks have weird and = interesting forwarding and filtering of MDNS. Particularly over the the = WiFI portion of the network. Be worth understanding the impact of that a = bit.=20= --Apple-Mail=_AAD466A7-8DC7-4454-9388-B71B561AEA4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 14, 2018, at 1:09 PM, westhawk <thp@westhawk.co.uk> = wrote:

1) Burning man video relay - = There is often decent bandwidth across the playa on a segmented class B = but 
terrible = connectivity to the outside world. If you want to relay audio and video = from an art performance you
 _really_ want to keep the media  within the class = B. MDNS won=E2=80=99t do the trick because of the = segmentation.

I imagine = there are corporate networks that look like this = too.

I = think the majority of large enterprise networks have weird and = interesting forwarding and filtering of MDNS. Particularly over the the = WiFI portion of the network. Be worth understanding the impact of that a = bit. 
= --Apple-Mail=_AAD466A7-8DC7-4454-9388-B71B561AEA4B-- From nobody Wed Sep 19 18:15:23 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4156130E22 for ; Wed, 19 Sep 2018 18:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsZ_dXjLmn59 for ; Wed, 19 Sep 2018 18:15:21 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03580130E11 for ; Wed, 19 Sep 2018 18:15:20 -0700 (PDT) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 56E5D5641 for ; Wed, 19 Sep 2018 21:15:19 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9C8D85651 for ; Wed, 19 Sep 2018 21:15:16 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [172.19.248.210] ([UNAVAILABLE]. [104.153.224.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.7.12); Wed, 19 Sep 2018 21:15:19 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <153678937808.9522.4000911693895472411@ietfa.amsl.com> Date: Wed, 19 Sep 2018 18:15:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <839ACAD9-EDD5-4DFD-ABC5-BCC827A10F11@iii.ca> References: <153678937808.9522.4000911693895472411@ietfa.amsl.com> To: RTCWeb IETF X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] dos and draft-ietf-rtcweb-mdns-ice-candidates-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 01:15:22 -0000 I think the document should looking into the issue if a drive by web = page load could create enough MDNS traffic to cause problems on the the = network. I'm not arguing this is a problem but just that it might be and = some should look into that and document that in the security section of = the draft.=20= From nobody Wed Sep 19 21:53:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE0A130EA2 for ; Wed, 19 Sep 2018 21:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JngYbXxNGtnX for ; Wed, 19 Sep 2018 21:52:41 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 70534130E25 for ; Wed, 19 Sep 2018 21:52:35 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id y8-v6so4252260wrh.7 for ; Wed, 19 Sep 2018 21:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MuCBrULxlSFkTCiYIgkvDiJKQTD4FDrSzEewPifyWeY=; b=PNnzdO4ImT1yJAa8wsVbKaNCD5HHOvFoqOlFYh9dh0H/7BgekqmXTkxCT5v5KqOO6w 9xgkXY93hZGW+JvshbzMlSrA9o4PxyGvyQbzQlo7BVYXghVEVCHSj2aD42/zyPhMytQ5 vUQgqXswsdCdScq9v3UAylal48yXkxN3F98S1YkTnLnB8XjSSM+PYNiYRXR/Bv9zzN1Q 2SxQY2DsOQix3lV9oVvxsJ5u4T6UGXoiHR43dDhuWbldXK+TT6WRFPqI3wsaY9r97QrW zwfv7718SdJBHy1bhiIooG71fmSA0EryF3D7eVsav4baKN7Y0l6g0RsoAhMAIjf5XzAY FXOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MuCBrULxlSFkTCiYIgkvDiJKQTD4FDrSzEewPifyWeY=; b=Q29926VFCWxng/tp0aaRb9RQ7eyWx4oFse7yLiqusWd5OoF2EfUL4DZJwBfeBtIZLm Ctnqi6ogWDvNPeVah7IgqLXpWGTmdACO/IZAPkrjJe+3IIsFH+LeaOW7z1GSut2tBP0T qsuyENSClJHLrJUgqL4fpaGNS4V3m67AECtbrUJnDHqLc/NhRLsC2r4cEPnZU8/tevau OT702q9G4qMs6kJdpg2A0r0C7I+kJgJHa03h05IK/bXArhddNIn8+sStiLTb5qbgmu5E 5aGUUWrzmzojk2NfVGBKePg070lr5yeQikXpP/bV/lZCP0ZS7bWlYItnJXfOp2HmizJd mQpA== X-Gm-Message-State: APzg51BdGi2pO67R81VTCU7fn92TCTy9XqgMvR1qwF4TTqtTxS3fVZ1u KbhRLQ26H+3SnvVcyNuGGH79YfwpBl/gHEZLfAigBQ== X-Google-Smtp-Source: ANB0VdaazlvlTrF083O2W9DQETWh6MRrRK5ljik/DMMJTZBB06GJwgxPftH6IBFbsrdEbpJN89kFtzpEzTQLTzU2M0c= X-Received: by 2002:adf:b3d7:: with SMTP id x23-v6mr30300083wrd.253.1537419153508; Wed, 19 Sep 2018 21:52:33 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Peter Thatcher Date: Wed, 19 Sep 2018 21:52:20 -0700 Message-ID: To: Cullen Jennings Cc: Christer Holmberg , Applications and Real-Time Area Discussion , "ice@ietf.org" , "clue@ietf.org" , "mmusic@ietf.org" , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000847f730576464ad5" Archived-At: Subject: Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 04:52:51 -0000 --000000000000847f730576464ad5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm late to the discussion, and reading through it, it seems that we have a lot of back and forth without addressing Cullen's root issue. Let me see if I understand Cullen's root issue correctly. I think it's something like= : 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant" without changing to be compliant with 8445. 2. Cisco has existing code that it wants to continue to interoperate with endpoints, especially Chrome, even as they make changes to become 8445 compliant. And they don't want to have to test against old and new versions. Cullen, is that accurate? OK, so some of my thoughts: 1. I don't think there is any interop risk here at all related to timings. If you're worried about the drop in minimum check interval going from 20ms to 5ms, don't. Just because the spec allows for going that low doesn't mean endpoints will. And if they do, they'll do it carefully. Endpoints can and should still choose a value that works best regardless of the min in the spec. For example, Chrome is still using an interval of 48ms (we're not in a rush to lower it, but we have non-browser endpoints that do go lower). And if we roll out a lower value, it will be via experiments or opt-ins and carefully tracked to make sure connectivity rates don't drop. If any problem were found in practice, it would be quickly reverted. 2. I don't think there is any interop risk here related to nomination either. Chrome's default behavior has never been compliant to any spec anyway, and it's never been an issue. And like with ping intervals, any changes to implementations will be done slowly and carefully. 3. I don't think it really matters to major implementations what the dependency graph looks like. Whether some point to 5245 and others to 8445 or if all of them point to 8445, it doesn't matter, implementations will behave the same either way. Chrome, for example will adjust timings as works well in practice (perhaps someday to below 20ms interval) regardless of which RFCs point to 8445 and which point to 5245. If interop issues ever do come up, then they can be fixed. And that has nothing to do with which RFCs point to 5245 and which point to 8445. 5. You're going to need to test against different versions of different browser no matter what the RFC references are. ICE timings and nominations seem like the least of your testing problems. But on the flip side, Chrome (and I assume other browsers) have been very slow and careful when making changes to the ICE code. 6. FlexICE should go a long way to putting the web app in control of the ICE behavior. So if you are worried about what browsers will do with ICE, I suggest supporting the FlexICE effort. In fact, it's the result of your proposal at TPAC in 2017 for wanting to have lower-level of control of ICE. If we get that into all the browsers, you won't have to worry any more about any of this because you'll be in control (assuming you control the web app). Altogether, I don't see any reason to not reference 8445 everywhere, at least not any related to interop risk and web browsers. On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: > > On Sep 7, 2018, at 1:25 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Cisco has implemented stuff that is WebRTC 1.0 compliant without this > change. These gratuitous changes, years after the implementation were > coded, with no real benefit will ensure that we are not > > and will not become compliant with the RFC. It's unlikely we will > upgrade to the new ICE until it has real befits. > > The main reason we did 8445 was because people had identified issues with > 5245. The work was driven mostly by the WebRTC community, including > yourself and the Chrome people (or, at least the Google people), and one = of > the reason it took time to finalize 8445 was because you (among others) > wanted to make sure we get things right (by making network measurements > etc). Are you now saying all those changes bring no benefit? Did we all > waste our time? > > > Our testing, which we do not share, dig not indicate an improvement of > connectivity rates. I did not see results from others that did. Some of t= he > early test results from others that drove this work were not reproducible > in our testing. The one thing I think most people did find is that the mo= re > out of sync the pacing of the two agents was, the worse the connectivity > was. But all of this is water under the bridge, we have old and new ice, > people can use either. What we are talking about here is what is the > minimum bar for WebRTC 1.0 > > > > It is doubtful Justin will want to implement the 8445 mechanisms of > supporting both new and old ICE. Instead, we will move to say "works with > Browser X version Y or later." We have watched at W3C as it moved to be > that unless chrome does it, it rare that it becomes a standard. > > Right here I am watching how the stuff IETF defines will be less > relevant than the issue of what chrome implements. > > What exactly would Justin have to change? > > > > For us, the largest part is having to test for both old and new - it=E2= =80=99s not > easy to do good automated testing for ICE. > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --000000000000847f730576464ad5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm late to the discussion, and reading through i= t, it seems that we have a lot of back and forth without addressing Cullen&= #39;s root issue.=C2=A0 Let me see if I understand Cullen's root issue = correctly.=C2=A0 I think it's something like:

= 1.=C2=A0 Cisco has existing code that it wants to call "WebRTC 1.0 com= pliant" without changing to be compliant with 8445.

2.=C2=A0 Cisco has existing code that it wants to continue to intero= perate with endpoints, especially Chrome, even as they make changes to beco= me 8445 compliant.=C2=A0 And they don't want to have to test against ol= d and new versions.=C2=A0=C2=A0

Cullen, is that ac= curate?



OK, so some = of my thoughts:

1.=C2=A0 I don't think there i= s any interop risk here at all related to timings.=C2=A0 If you're worr= ied about the drop in minimum check interval going from 20ms to 5ms, don= 9;t.=C2=A0 Just because the spec allows for going that low doesn't mean= endpoints will.=C2=A0 And if they do, they'll do it carefully.=C2=A0 E= ndpoints can and should still choose a value that works best regardless of = the min in the spec.=C2=A0 For example, Chrome is still using an interval o= f 48ms (we're not in a rush to lower it, but we have non-browser endpoi= nts that do go lower).=C2=A0 And if we roll out a lower value, it will be v= ia experiments or opt-ins and carefully tracked to make sure connectivity r= ates don't drop.=C2=A0 If any problem were found in practice, it would = be quickly reverted.=C2=A0=C2=A0

2.=C2=A0 I don= 9;t think there is any interop risk here related to nomination either.=C2= =A0=C2=A0
Chrome's default behavior has never been compliant = to any spec anyway, and it's never been an issue.=C2=A0 And like with p= ing intervals, any changes to implementations will be done slowly and caref= ully.=C2=A0=C2=A0

3.=C2=A0 I don't think it re= ally matters to major implementations what the dependency graph looks like.= =C2=A0 Whether some point to 5245 and others to 8445 or if all of them poin= t to 8445, it doesn't matter, implementations will behave the same eith= er way.=C2=A0 Chrome, for example will adjust timings as works well in prac= tice (perhaps someday to below 20ms interval) regardless of which RFCs poin= t to 8445 and which point to 5245.=C2=A0 If interop issues ever do come up,= then they can be fixed.=C2=A0 And that has nothing to do with which RFCs p= oint to 5245 and which point to 8445.

5.=C2=A0 You= 're going to need to test against different versions of different brows= er no matter what the RFC references are.=C2=A0 ICE timings and nominations= seem like the least of your testing problems.=C2=A0 But on the flip side, = Chrome (and I assume other browsers) have been very slow and careful when m= aking changes to the ICE code.

6.=C2=A0 FlexICE sh= ould go a long way to putting the web app in control of the ICE behavior.= =C2=A0 So if you are worried about what browsers will do with ICE, I sugges= t supporting the FlexICE effort.=C2=A0 In fact, it's the result of your= proposal at TPAC in 2017 for wanting to have lower-level of control of ICE= .=C2=A0 If we get that into all the browsers, you won't have to worry a= ny more about any of this because you'll be in control (assuming you co= ntrol the web app).=C2=A0

Altogether, I don't = see any reason to not reference 8445 everywhere, at least not any related t= o interop risk and web browsers.






= =C2=A0









On Fri, Sep 7, 2018 at 9:37 AM Cullen Jenning= s <fluffy@iii.ca> wrote:

On Sep 7, 20= 18, at 1:25 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote= :

<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start= ;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;te= xt-decoration:none">
> Cisco has implement= ed stuff that is WebRTC 1.0 compliant without this change.=C2=A0These gratui= tous changes, years after the implementation were coded, with no real benef= it will ensure that we are not
>=C2= =A0and will not become compliant with th= e RFC.=C2=A0It's unlikely we will upgrade to the new ICE until it has re= al befits.=C2= =A0
=C2=A0
The main reason we did 8445 was because people had id= entified issues with 5245. The work was driven mostly by the WebRTC communi= ty, including yourself and the Chrome people (or, at least the Google peopl= e), and one of the reason it took time to finalize 8445 was because you (am= ong others) wanted to make sure we get things right (by making network meas= urements etc). Are you now saying all those changes bring no benefit? Did w= e all waste our time?

<= /div>
Our testing, which we do not share, dig not indicate an improvement o= f connectivity rates. I did not see results from others that did. Some of t= he early test results from others that drove this work were not reproducibl= e in our testing. The one thing I think most people did find is that the mo= re out of sync the pacing of the two agents was, the worse the connectivity= was. But all of this is water under the bridge, we have old and new ice, p= eople can use either. What we are talking about here is what is the minimum= bar for WebRTC 1.0=C2=A0

=C2=A0
> It is doubtful Justin will want to implement the 8445 = mechanisms of supporting both new and old ICE.=C2=A0Instead, we will move to= say "works with Browser X version Y or later." We have watched a= t W3C as it moved to be that unless chrome does it, it rare that it becomes= a standard. =C2=A0
><= span class=3D"m_-6802286700116899682Apple-converted-space">=C2=A0Right here I am watching how the stuff IETF define= s will be less relevant than the issue of what chrome implements.=C2=A0
=C2=A0
What exactly would Justin have to change?<= /u>
=C2=A0<= /div>

For us, the largest part is having= to test for both old and new - it=E2=80=99s not easy to do good automated = testing for ICE.=C2=A0
_________________________________________= ______
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--000000000000847f730576464ad5-- From nobody Wed Sep 19 23:21:35 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B279130E34 for ; Wed, 19 Sep 2018 23:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcXXow7WtBw3 for ; Wed, 19 Sep 2018 23:21:31 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 7F910130E25 for ; Wed, 19 Sep 2018 23:21:31 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id u18-v6so2592678vsu.8 for ; Wed, 19 Sep 2018 23:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s5i5t0vukJgUr7kRjXgT0PAR+4lUsn2I8CkIBAWgTtg=; b=rAxQ2uPVwZ2fx2y+yEGA3NIGTzLGfcKal2EBkWWUBGLJHvDC0w2OzFiUqmNR1rhwAo j7BOSYvmJq5KXYD3iz4khuuwiwIjYZBekvL/MLf87+n+/oQANL8H7Gi32SXiTRznfeCC U7dlOeYxrGaTyZoFyZhKHG9cgS30RjaCU3LTSPMNCDzPNH2VoR9htQPcIGYlgwHCrUX5 C6rwFJKi9eWYwhtOScM+ArNIPDL9pwrtjR1PUZnTdYzOl1u7t4TH1XOl95n9LSKv3CI3 tsjsXLy9KBlt7zco1PiuN7GKl7Au/PA+uE5sMFL/GJFKU+G7WWjewl6WPBUngAGCcxZx yqgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s5i5t0vukJgUr7kRjXgT0PAR+4lUsn2I8CkIBAWgTtg=; b=J+FnCZhahoKuJyuwrciXXnh/2hFM+Lva5+IUlCRmUqT5KRkfD26gCEih5NFwynCqPD 8yKMsLdmJovxe4WapgmlA1BiCAuDc+LKz3bwxaAIy/1fBeI2aUKPMshJvHtHHA7OntSR 4mCeI4Ps/1+Y5KLFh005i+ebdoHnO20cFLkOI9+fIACqCaZ7Ihk22UTn13+WYm0utnUS SH2jqyf9rpOk+iTtsMfJmN2hBZTXosd46E1codW6vdHinPu2d73Hc6AgReZpMVJK0zkd MkbUpwh4MKGxuJ6pAQyyxMyvvOQmYHLY1KtfF153aO1glewUqqgzkeRL+GGI3b8o22kz R4hg== X-Gm-Message-State: APzg51BvrSwmLcTsxvhguexYh/xpMKunib5szkIYKlhV6tET/Dpg0hFI oM1OVwxhmqAbM8vz2oN6o5XIzOLWd5QKafnycnlKIA== X-Google-Smtp-Source: ANB0Vdba68lE7kh0lI2gEp2qhCunP8TbXWnceTstnsmQVhHZSyEojv4CmNSBmw+rtQ+8Gzbv3QboynGKIgvnEi5VrDY= X-Received: by 2002:a67:4e53:: with SMTP id c80-v6mr10412009vsb.32.1537424490175; Wed, 19 Sep 2018 23:21:30 -0700 (PDT) MIME-Version: 1.0 References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk> <73F0A366-77DC-4EE5-A6B6-D2F7112D7912@iii.ca> In-Reply-To: <73F0A366-77DC-4EE5-A6B6-D2F7112D7912@iii.ca> From: Bernard Aboba Date: Wed, 19 Sep 2018 23:21:19 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF , Tim Panton Content-Type: multipart/alternative; boundary="0000000000009b2192057647887c" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 06:21:33 -0000 --0000000000009b2192057647887c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From what I have seen, relaying of mDNS is rare in enterprise WiFi networks because of the effect of multicast on overall throughput. Even if lower rates (e.g. < 11 Mbps) are disallowed, the effect on available time slots can be substantial, particularly with 802.11ac deployed and higher speeds coming. So we should assume that mDNS is link-local scope. On Wed, Sep 19, 2018 at 18:15 Cullen Jennings wrote: > > On Sep 14, 2018, at 1:09 PM, westhawk wrote: > > 1) Burning man video relay - There is often decent bandwidth across the > playa on a segmented class B but > terrible connectivity to the outside world. If you want to relay audio an= d > video from an art performance you > _really_ want to keep the media within the class B. MDNS won=E2=80=99t = do the > trick because of the segmentation. > > I imagine there are corporate networks that look like this too. > > > I think the majority of large enterprise networks have weird and > interesting forwarding and filtering of MDNS. Particularly over the the > WiFI portion of the network. Be worth understanding the impact of that a > bit. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009b2192057647887c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From what I have seen, relaying of mDNS is rare in e= nterprise WiFi networks because of the effect of multicast on overall throu= ghput. Even if lower rates (e.g. < 11 Mbps) are disallowed, the effect o= n available time slots can be substantial, particularly with 802.11ac deplo= yed and higher speeds coming.

So we should assume that mDNS is link-local scope.
On Wed, Sep 19, 2018 at 18:15= Cullen Jennings <fluffy@iii.ca>= wrote:

On Sep 14, 2018, at 1:09 P= M, westhawk <thp= @westhawk.co.uk> wrote:

1) Burning man video relay - There is often dece= nt bandwidth across the playa on a segmented class B but=C2=A0
terribl= e connectivity to the outside world. If you want to relay audio and video f= rom an art performance you
=C2=A0_really_ want to keep the media =C2= =A0within the class B. MDNS won=E2=80=99t do the trick because of the segme= ntation.

I imagine there are corporate networks that look li= ke this too.

I think the majority of= large enterprise networks have weird and interesting forwarding and filter= ing of MDNS. Particularly over the the WiFI portion of the network. Be wort= h understanding the impact of that a bit.=C2=A0
________________= _______________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009b2192057647887c-- From nobody Thu Sep 20 01:06:31 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECED7130DCE for ; Thu, 20 Sep 2018 01:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLp5gRNYbSzj for ; Thu, 20 Sep 2018 01:06:27 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27EAF124C04 for ; Thu, 20 Sep 2018 01:06:27 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id f38-v6so7059260edd.8 for ; Thu, 20 Sep 2018 01:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FMXgCG+zWLO4RHmKL9TUdgkemrAYlduH5pnemPQkb20=; b=Idfx5TQXbtPHFLQbe5CsGt48ETj7c6BOL09+es3CHe8J+5KLO/RwHAjkyyLwEaqJ5Y GRjT+vtByRTEyMoSV68AGUxsVUHoXB2aueHvvLmZnLgT1k2r8wSibQBNJLyRn4dpRbuq kjNFZV4wPnQ2SH0mRWBxPoVYoks4Db4Me/0pmDdhwz01lqoXN7qC1/z3oXOFB/gfyEqn qc9+Q7Wg6nGjIoQ4V57vN1L5QVpS/xuYILOrdJbRYGK+orVAAp3fNkLa8n7yhPRQkdOE 53xCjU0lzH5tDNaxspv5zUoJ2yXAABLqD1ClbkVcm+QN8TW+pIGuawDwP+lMN8sntI+8 jQZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FMXgCG+zWLO4RHmKL9TUdgkemrAYlduH5pnemPQkb20=; b=nSd0+auYCcqUpXlQ4vhQqBA7Y0WU7mcoGJWs/pBzmIi9tpzDeyan31R9LuSTYWSZyE pdBix7P1vpSrpAPn6twq0Df4+6W4sushZMhm1Crcbr7lVZ1n+YpVDNaKNtlZGmsVI+8w 9e8zvSChwUTV7/F2rgz25+5Sc8BnqZfaNPm8P9no8GaIKqmFxcHMvhODldAY0u+i44Xk 5Wj7IQmHc832FmNOVp3kSv9raFjaeY6VEPVEUatOUsB6g0fKSJ+WrSD6SRkXaEN0sj1z pj+L6Mhjs0ppH42ywBevRNvYbue3s1nFxWBpoHlq3uGAWlXhgdEkcCYwWlsu06c8Sxe2 pLWA== X-Gm-Message-State: APzg51C4uDIjH07H0IFquGYOkQ2DT6TOdp5pfbQk0KIjmEpnem1hYdAO 5NiwyG8BjgmypX8jU1i8aZIWj/Cz X-Google-Smtp-Source: ANB0Vda+Q5YlrybXZ6RabSILGtX8/ixchCQn+pnu9roGf0wE7RirK2opLdNEH7pCd4J6eJLLHXUl3A== X-Received: by 2002:a50:d2d7:: with SMTP id q23-v6mr2708608edg.183.1537430785425; Thu, 20 Sep 2018 01:06:25 -0700 (PDT) Received: from [192.168.11.149] ([185.41.76.142]) by smtp.gmail.com with ESMTPSA id e38-v6sm485673eda.74.2018.09.20.01.06.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Sep 2018 01:06:24 -0700 (PDT) To: rtcweb@ietf.org References: <84F2BA5D-3B55-4B75-A8BE-C36852BA251C@gmail.com> <4EB3E785-B014-470F-961C-CA63B051FD1E@westhawk.co.uk> <73F0A366-77DC-4EE5-A6B6-D2F7112D7912@iii.ca> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: Date: Thu, 20 Sep 2018 10:07:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <73F0A366-77DC-4EE5-A6B6-D2F7112D7912@iii.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 08:06:29 -0000 On 20.09.18 03:12, Cullen Jennings wrote: > >> On Sep 14, 2018, at 1:09 PM, westhawk wrote: >> >> 1) Burning man video relay - There is often decent bandwidth across the playa on a segmented class B but >> terrible connectivity to the outside world. If you want to relay audio and video from an art performance you >> _really_ want to keep the media within the class B. MDNS won’t do the trick because of the segmentation. >> >> I imagine there are corporate networks that look like this too. > > I think the majority of large enterprise networks have weird and interesting forwarding and filtering of MDNS. Particularly over the the WiFI portion of the network. Be worth understanding the impact of that a bit. Also for home/small office WiFi access points. I'm not sure they all forward multicast packets and mDNS as expected. Cheers Lennart From nobody Thu Sep 20 01:18:25 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD3F130E3C for ; Thu, 20 Sep 2018 01:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8DSwELz4_4m for ; Thu, 20 Sep 2018 01:18:22 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 86DCD124C04 for ; Thu, 20 Sep 2018 01:18:22 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id p52-v6so7065929eda.12 for ; Thu, 20 Sep 2018 01:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e5/xrssmHDPOF9a0pHxcKKtfK0Ayb7bPoDPJvrvMUdQ=; b=Bnngcm+HnRmcHYkcEhUnzQiW3kM0kKmhWUW32r3OVG3VH+cIKmp+2qeflxLPe4OXFj 1c25v1CbujofExHQ1Tc0iCnAKJqULZWY61+vhKn2x618us+0lr8sRMSids2u0gN7wyoq SVlUQOr6ch+SEiYPJ/L3ry4VBRgXWWj7cCcrb2Cq009rgCQ7znZMdBLKniVeTUc5wtpF 1isVmphkdQH264WU9Gz+Hvdxj8unkOB+jS6KYazrA+BZ6qHJErIoz7Se7bx2lzBqKOa2 2bvAJzS99TiCgD2szEthO+secWp2RNQXBYeK0t9wIjFTnQ5YCUfO/7RA7K1mH0Eo3Dzf hCdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=e5/xrssmHDPOF9a0pHxcKKtfK0Ayb7bPoDPJvrvMUdQ=; b=ehwA/j82vkYIiyieK3q9MufKw857CrFq472XZpLNf2LCU7ZSiGziYntE+ZMkQ72pAo MGRrjOidYPgWJHmkzfGK4P9HeF94C4VelJvJVjRu9CpVt0/Amy2JxfYDMobFLRa9qBcm WrglIky8Hhdby+FfyBxN2YHMtzPjdrmRbq6zPM+lVDSOhePoII3MVvHr3apjkK5pO4zb lSmAMGip8C4K9KCbr0Hka7VKw50G9e+/ASapzml+D9oN2m5JEEv0vR407m5JkzkWONpm 9ahoGyJzHa+Vq/wTlTy3vGOdBOGTIFOub4dw95Rr+c6ulBJ3HfyqE9hcxGgludv7hWus WQiQ== X-Gm-Message-State: APzg51Byk11KYyDJPOl5doBmHGnRlUdadYVOkq/bTpy6aNPtt8iQvQra 4XqgdBGrdyNt4byASQc+9JhBS41H X-Google-Smtp-Source: ANB0VdYXVmIISFXgp9KdAYgV1grewK0EDOiYWo9zhAbCkKG/vCE37/LBuAIeB1hUHbj9MKROb99lAQ== X-Received: by 2002:a50:d75d:: with SMTP id i29-v6mr2778049edj.17.1537431500751; Thu, 20 Sep 2018 01:18:20 -0700 (PDT) Received: from [192.168.11.149] ([185.41.76.142]) by smtp.gmail.com with ESMTPSA id h3-v6sm925764ede.42.2018.09.20.01.18.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Sep 2018 01:18:20 -0700 (PDT) To: rtcweb@ietf.org References: From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: Date: Thu, 20 Sep 2018 10:19:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 08:18:24 -0000 On 14.09.18 19:44, youenn fablet wrote: > Agreed that this proposal does not solve all cases. > But it does so in a number of cases like home/small office scenarios. > > [...] >> In general, I do not think there is a guarantee to successfully connect > without sometimes relying on TURN servers. > This proposal and other solutions should allow reducing the need to use > TURN. The problem I see is that the document deteriorates the default situation while it only levels it out for home/small office scenarios. For the majority of implementations (which use mode 2 by default) the host-to-host connections will less likely succeed than previously. > Describing precisely the problematic scenarios is useful as we can find > additional means specific to those scenarios. > For instance, can it be envisioned to deploy STUN servers inside the user > network for the financial applications/branch offices scenarios you are > mentioning? Perhaps its feasible for those use cases where the administrator is already aware of the software but definitely not for small applications such as sharedrop.io, Threema Web whose main use case is the direct connection in same network environments and its significant benefits regarding throughput. Cheers Lennart > > Le ven. 14 sept. 2018 à 00:10, Bernard Aboba a > écrit : > >> While I understand the overall goal of this document, it strikes me as >> suffering from two major problems: >> >> a. Introduction of backwards compatibility problems and potential >> additional delays due to utilization of name resolution mechanisms in ICE, >> with a corresponding benefit (successful connectivity checks between host >> candidates on the same network) which is only a marginal improvement over >> mode 3 (no host candidates). >> >> b. Over-reliance on permission mechanisms which have already been >> stretched to the breaking point, leaving the potential for collateral >> damage in data channel-only scenarios. Due to limitations in the current >> permissions mechanisms, it is not currently practically impossible to >> distinguish legitimate data channel applications that would obtain >> permissions if there were usable means to do so from illegitimate >> applications attempting to compromise user privacy. >> >> Data-channel only scenarios that would be impacted include those where: >> >> 1. Permissions cannot be obtained (e.g. where there is no microphone or >> camera attached to the device so that getUserMedia will always fail). >> >> 2. Low latency communications is a requirement so that TURN server >> traversal is unacceptable (e.g. in financial applications where there may >> be regulatory requirements relating to allowable delays). >> >> 3. TURN traversal would impose an unacceptable financial cost, such as in >> branch office scenarios where a TURN servers is not provided in each branch >> office, and branch office connectivity may be constrained (still an issue >> for branch offices located on other continents). >> >> Essentially, the problem is that these scenarios may have valid reasons >> why they cannot utilize or do not wish to utilize getUserMedia as a >> permission-granting mechanism. From nobody Mon Sep 24 03:53:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7C1130E82 for ; Mon, 24 Sep 2018 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPubkndhXvbT for ; Mon, 24 Sep 2018 03:53:08 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8E5130E77 for ; Mon, 24 Sep 2018 03:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537786386; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZfVaCJ00p1wj7gqMQnTnv4obumkZHxiX8zrV+ObP9Ng=; b=bWqbSGYSJElTBJDtWFvmsEtDfNmu692PeFKkvmS/wyIaAxDFpCPPHfiGlJZGhzUs KV9bDOzzuNVIaJZnxTxqMBxQe3hhUZ5MdHYZlpXF58HaPcmg+VuOPgJ2LtKNDUhS OEtFhp+smGVn6f+paLdjcPNsgy9Pl0jaAzU5/m5o8pk=; X-AuditID: c1b4fb2d-223ff700000055ff-bc-5ba8c21257d8 Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.EA.22015.212C8AB5; Mon, 24 Sep 2018 12:53:06 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 24 Sep 2018 12:53:05 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 24 Sep 2018 12:53:05 +0200 From: Christer Holmberg To: RTCWeb IETF CC: Sean Turner , Martin Thomson , "adam@nostrum.com" , Cullen Jennings Thread-Topic: Identity assertion: identity attribute pull request updated Thread-Index: AQHUU/TFu06o5XqMoUaQ7HZIl5Fo7w== Date: Mon, 24 Sep 2018 10:53:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <78758B7DF92E7443820E85015ECDAD01@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyM2J7pa7QoRXRBguucFvs+buI3aJjMpvF tTP/GC3W/mtnt7iyqpHZgdVjyu+NrB47Z91l91iy5CeTx6ydT1g8Dh5kDGCN4rJJSc3JLEst 0rdL4Mq4tqaDuWALS8WVOU2MDYxLWLoYOTkkBEwkrpxcwtbFyMUhJHCUUWLKhlMsEM43Romt T7uhnGWMEot/vmLqYuTgYBOwkOj+pw3SLSKgKPFk4RJGEJtZYAajxLlfgiC2sICLxO6PC1gh ajwlzlxtY4Kw9SSmvLrODmKzCKhKHOo4DHYFr4C9xJ49s9lAbEYBMYnvp9YwQcwUl7j1ZD4T xKUCEkv2nGeGsEUlXj7+xwpyjqiAvsS0ywEQYSWJLb1bwK5kFtCUWL9LH8K0lpizTRdioKLE lO6H7BBLBSVOznzCMoFRbBaSXbMQmmchNM9C0jwLSfMCRtZVjKLFqcXFuelGxnqpRZnJxcX5 eXp5qSWbGIFxeHDLb90djKtfOx5iFOBgVOLh1d23IlqINbGsuDL3EKMEB7OSCK/breXRQrwp iZVVqUX58UWlOanFhxilOViUxHn1Vu2JEhJITyxJzU5NLUgtgskycXBKNTBKLe76M+fsoy2r RWq52OOWL6qrefxZ49mLDONLv59Nm52k06tlcmfpor1cAXEbPQuCLsx3PvVe9u3903mpihMN P70NXC+zUHLawiv/JbMYN/Uwr5rY5nK89oaMm8dfBcN/P+tWO1769q7WvlTJlMV+yk82Dq9p r72Mkov++DvLzP+75vPxlvfPlFiKMxINtZiLihMBcVG/Qr8CAAA= Archived-At: Subject: [rtcweb] Identity assertion: identity attribute pull request updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 10:53:11 -0000 SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3Qgb24gdGhlIFNEUCBpZGVudGl0 eSBhdHRyaWJ1dGUsIGJhc2VkIG9uIGNvbW1lbnRzIGZyb20gTWFydGluLCBDdWxsZW4gYW5kIEFk YW06DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvc2VjdXJpdHktYXJjaC9wdWxsLzc3 DQoNCkkgd2lsbCBzdGlsbCBoYXZlIHRvIGZpeCB0aGUgTy9BIHByb2NlZHVyZXMuIE1hcnRpbiBz dWdnZXN0ZWQgdG8gbWVyZ2Ugc29tZSBzZWN0aW9ucywgd2hpbGUgQWRhbSBzdWdnZXN0ZWQgdG8g dXNlIHRoZSBvbGQgaW5pdGlhbC9zdWJzZXF1ZW50IE8vQSBzdHJ1Y3R1cmUuIEkgd2lsbCBsb29r IGludG8gaXQgYW5kIHN1Z2dlc3Qgc29tZXRoaW5nIHNvb24uDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQogDQoNCg== From nobody Mon Sep 24 03:55:44 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A758D130E77 for ; Mon, 24 Sep 2018 03:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_Y-lxVR0cPc for ; Mon, 24 Sep 2018 03:55:41 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E429126DBF for ; Mon, 24 Sep 2018 03:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537786539; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hB5EHYwg/E6rl2EV11zf5BliUn+M+S5Qi3M0vZEP+WA=; b=JhyOJLfnzIKAcq5nUxyEzy9vLEI+Zc3+Y8mL7JgpNdSSbpaYSOyHr4bk4OVUYnPT KET5LtfTCgRvtdEfuTVGb87ogDdlzZea6YEGC4NA4LAEbci9YIeWYxuKeolXHQ7B 9sIou7MYBAgmnKn4tVj9BN4MEQ7T3uMVRDthGC1rfYE=; X-AuditID: c1b4fb25-8ffff700000013ad-61-5ba8c2ab6cbd Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D8.42.05037.BA2C8AB5; Mon, 24 Sep 2018 12:55:39 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 24 Sep 2018 12:55:38 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 24 Sep 2018 12:55:38 +0200 From: Christer Holmberg To: RTCWeb IETF CC: Sean Turner , Martin Thomson , "adam@nostrum.com" , Cullen Jennings Thread-Topic: [rtcweb] Identity assertion: identity attribute pull request updated Thread-Index: AQHUU/Uh6XZGEqEZvEO/tavRjlOlRQ== Date: Mon, 24 Sep 2018 10:55:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <7C792923FED2774386FDBD8A41A48DEB@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7te7qQyuiDRo/iljs+buI3aJjMpvF tTP/GC3W/mtnt7iyqpHZgdVjyu+NrB47Z91l91iy5CeTx6ydT1g8Dh5kDGCN4rJJSc3JLEst 0rdL4MqY+f8dS8E7zopbD18yNjCe4exi5OSQEDCR6D+4mLGLkYtDSOAoo8TeJcvYIJxvjBIf Dv1mgnCWMUosu7eFuYuRg4NNwEKi+582SLeIgKLEk4VLGEFsZoEZjBLnfgmClAgLBEssuhUE URIicWLGEVYIW0/iWd8NFhCbRUBV4vjHbUwgNq+AvcSBg0fAbEYBMYnvp9YwQYwUl7j1ZD4T xKECEkv2nGeGsEUlXj7+xwqySlRAX2La5QCIsJLElt4tTCBhZgFNifW79CGmWEs8u9vGCmEr SkzpfsgOsVVQ4uTMJywTGMVmIVk2C6F7FpLuWUi6ZyHpXsDIuopRtDi1OCk33chYL7UoM7m4 OD9PLy+1ZBMjMBIPbvmtuoPx8hvHQ4wCHIxKPLwv9q6IFmJNLCuuzD3EKMHBrCTC63ZrebQQ b0piZVVqUX58UWlOavEhRmkOFiVx3ofmm6OEBNITS1KzU1MLUotgskwcnFINjJP5TDSmJmZX r5kt0ZiWLPis9+2cqbldzr67WZ/xfVf3Y2/l3ehRrGrfYHciaY2vWb2EePhkzSvTUmdrtDT9 TymvUHmcttDCWS4iKXTfx483D317bniw8vTy65OWa4oK72wIX7OcgV3lx4m819nBjktylvfn fFvl/DfywOED+5hP7zs90/2onRJLcUaioRZzUXEiAHI3wU/AAgAA Archived-At: Subject: Re: [rtcweb] Identity assertion: identity attribute pull request updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 10:55:43 -0000 SGksDQoNCk5vdGUgdGhhdCB0aGUgdGV4dCBkb2VzIE5PVCBhbGxvdyBtdWx0aXBsZSBpZGVudGl0 eSBhc3NlcnRpb25zLiBJZiBzb21lb25lIGhhcyBhIHByb2JsZW0gd2l0aCB0aGF0IGhlL3NoZSBu ZWVkcyB0byBzcGVhayB1cC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQrvu79PbiAyNC8w OS8xOCAxMzo1MywgInJ0Y3dlYiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmciIDxydGN3 ZWItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPiB3cm90ZToNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgaGF2ZSB1cGRhdGVkIHRoZSBw dWxsIHJlcXVlc3Qgb24gdGhlIFNEUCBpZGVudGl0eSBhdHRyaWJ1dGUsIGJhc2VkIG9uIGNvbW1l bnRzIGZyb20gTWFydGluLCBDdWxsZW4gYW5kIEFkYW06DQogICAgDQogICAgaHR0cHM6Ly9naXRo dWIuY29tL3J0Y3dlYi13Zy9zZWN1cml0eS1hcmNoL3B1bGwvNzcNCiAgICANCiAgICBJIHdpbGwg c3RpbGwgaGF2ZSB0byBmaXggdGhlIE8vQSBwcm9jZWR1cmVzLiBNYXJ0aW4gc3VnZ2VzdGVkIHRv IG1lcmdlIHNvbWUgc2VjdGlvbnMsIHdoaWxlIEFkYW0gc3VnZ2VzdGVkIHRvIHVzZSB0aGUgb2xk IGluaXRpYWwvc3Vic2VxdWVudCBPL0Egc3RydWN0dXJlLiBJIHdpbGwgbG9vayBpbnRvIGl0IGFu ZCBzdWdnZXN0IHNvbWV0aGluZyBzb29uLg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAg Q2hyaXN0ZXINCiAgICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBydGN3ZWIgbWFpbGluZyBsaXN0DQogICAgcnRjd2ViQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWIN CiAgICANCg0K From nobody Mon Sep 24 07:11:28 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8917A130DC7 for ; Mon, 24 Sep 2018 07:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU3qja2B2RSe for ; Mon, 24 Sep 2018 07:11:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D456B12F295 for ; Mon, 24 Sep 2018 07:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537798284; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ms2Kl6K4JomZSacesu5Br6KNf4Ab9PC8RQbKKIjfWeo=; b=BewZiQZC16NnNvGK3GA7hlv4FcmTbNjY5bVfiOv2Ws7odacfxbjwlwwLPztfBZF8 AslTWm0G2PX/Z+pXTAyRBSUnw3itgSHq4LTKBss0fxy4rwALH3eOHrWgDbVQoldL ZgNcyw//ISIYhPqhwRZldXc7gS4yLXEbVtjA3VyanIw=; X-AuditID: c1b4fb30-ff9ff700000055da-05-5ba8f08cc4bb Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.49.21978.C80F8AB5; Mon, 24 Sep 2018 16:11:24 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 24 Sep 2018 16:11:23 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Mon, 24 Sep 2018 16:11:23 +0200 From: Christer Holmberg To: RTCWeb IETF Thread-Topic: [rtcweb] Identity assertion: identity attribute pull request updated Thread-Index: AQHUU/Uh6XZGEqEZvEO/tavRjlOlRaT/iaEA Date: Mon, 24 Sep 2018 14:11:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <1965C5D9DB222047A532CB42CD56CA4E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2J7pW7PhxXRBi3PmSzW/mtnt7iyqpHZ gcljyZKfTB4HDzIGMEVx2aSk5mSWpRbp2yVwZUzsW8VUMEmg4u6zb2wNjHf4uxg5OSQETCSO tz5n62Lk4hASOMoosWX7byjnG6PExZlrWCCcZYwS16Y9BHI4ONgELCS6/2mDdIsIKEo8WbiE ESTMLKAg8XCqKYgpLBAssehWEERFiMSJGUdYIWwjiePrDoLZLAKqEsunn2AFKecVsJe49pAH JCwEZH5Z+JsdxOYUcJBYu7oFrJxRQEzi+6k1TCA2s4C4xK0n85kgzheQWLLnPDOELSrx8vE/ sJGiAvoS0y4HQISVJLb0bmGCuFFTYv0ufYgp1hLHv/xkhbAVJaZ0PwTbyisgKHFy5hOWCYwS s5Asm4XQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERh7B7f8NtjB +PK54yFGAQ5GJR7eU69WRAuxJpYVV+YeYpTgYFYS4XW7tTxaiDclsbIqtSg/vqg0J7X4EKM0 B4uSOK+F3+YoIYH0xJLU7NTUgtQimCwTB6dUAyPPUbuH6u8KFju5zfViseCRPzZPMonJLHLi k6ubxUK0TGK0o0POPiibtyNar+Dy91crrkzK22sfvOa3qu+TaOdYtb5FrjXma/bv44n+cviR l/vPJY6ioZ77Nc71bzL0YOzRyjhdw/n3QtXkuDXLz6e6qu+Yzl4zNW3u65mcjoJGefmTvz8U 3ajEUpyRaKjFXFScCACI1TaluQIAAA== Archived-At: Subject: Re: [rtcweb] Identity assertion: identity attribute pull request updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 14:11:27 -0000 SGksDQoNCkkgaGF2ZSBub3cgbW9kaWZpZWQgdGhlIE8vQSBzZWN0aW9uLCB1c2luZyB0aGUgb2xk IHN0eWxlLg0KDQpJIFRISU5LIEkgaGF2ZSBub3cgYWRkcmVzc2VkIGFsbCBpc3N1ZXMsIGJ1dCBw bGVhc2UgdGFrZSBhIGxvb2sgdG8gdmVyaWZ5Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cu+7v09uIDI0LzA5LzE4IDEzOjU1LCAicnRjd2ViIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xt YmVyZyIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgTm90ZSB0aGF0 IHRoZSB0ZXh0IGRvZXMgTk9UIGFsbG93IG11bHRpcGxlIGlkZW50aXR5IGFzc2VydGlvbnMuIElm IHNvbWVvbmUgaGFzIGEgcHJvYmxlbSB3aXRoIHRoYXQgaGUvc2hlIG5lZWRzIHRvIHNwZWFrIHVw Lg0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAgQ2hyaXN0ZXINCiAgICANCiAgICANCiAg ICBPbiAyNC8wOS8xOCAxMzo1MywgInJ0Y3dlYiBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJl cmciIDxydGN3ZWItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICANCiAgICAgICAgSGksDQogICAgICAgIA0KICAg ICAgICBJIGhhdmUgdXBkYXRlZCB0aGUgcHVsbCByZXF1ZXN0IG9uIHRoZSBTRFAgaWRlbnRpdHkg YXR0cmlidXRlLCBiYXNlZCBvbiBjb21tZW50cyBmcm9tIE1hcnRpbiwgQ3VsbGVuIGFuZCBBZGFt Og0KICAgICAgICANCiAgICAgICAgaHR0cHM6Ly9naXRodWIuY29tL3J0Y3dlYi13Zy9zZWN1cml0 eS1hcmNoL3B1bGwvNzcNCiAgICAgICAgDQogICAgICAgIEkgd2lsbCBzdGlsbCBoYXZlIHRvIGZp eCB0aGUgTy9BIHByb2NlZHVyZXMuIE1hcnRpbiBzdWdnZXN0ZWQgdG8gbWVyZ2Ugc29tZSBzZWN0 aW9ucywgd2hpbGUgQWRhbSBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBvbGQgaW5pdGlhbC9zdWJzZXF1 ZW50IE8vQSBzdHJ1Y3R1cmUuIEkgd2lsbCBsb29rIGludG8gaXQgYW5kIHN1Z2dlc3Qgc29tZXRo aW5nIHNvb24uDQogICAgICAgIA0KICAgICAgICBSZWdhcmRzLA0KICAgICAgICANCiAgICAgICAg Q2hyaXN0ZXINCiAgICAgICAgIA0KICAgICAgICANCiAgICAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgcnRjd2ViIG1haWxpbmcgbGlz dA0KICAgICAgICBydGN3ZWJAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCiAgICAgICAgDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBydGN3ZWIgbWFpbGluZyBs aXN0DQogICAgcnRjd2ViQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGN3ZWINCiAgICANCg0K From nobody Mon Sep 24 22:14:02 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10613131217 for ; Mon, 24 Sep 2018 22:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d86JmQwo_vmn for ; Mon, 24 Sep 2018 22:13:59 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C28131127 for ; Mon, 24 Sep 2018 22:13:58 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id p6-v6so20405175ljc.5 for ; Mon, 24 Sep 2018 22:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vLk4kS7W6SY0Jdl+M12Z16iagUNOOJTDpgXeFNMmUGg=; b=ANJzc90zKk0Nvu5bt69in7TSzvDqRiFhNRpxDYQ1BlTOxA5o/uSfxHx9dOdSzS8yqE yZz3cMKmMP4AHz22j4vIUpf3QnbR4U33kmNMobxdG4mJvJrvpmvgdJvCb86ld2Gaongh mW3NFyLQUvIrzG/s3LnfzZ6aWf6Vl5OIgDbN8gS1m+j81ZGZRiXCrwEcR/iqDf5mWrdp 5QuYNxuff8nGa7WBQPwvAiR6f1cVwkVQOy7FSG0LF/BwBVOyI+WcBY4OzyqUqVhz4exW VQapaEulBDwEWLkBB6t1Qt8UZbodZEADQG9pPAE8ZLiDGIM+m+/yzcGXqDEIzexQAyTi dZbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vLk4kS7W6SY0Jdl+M12Z16iagUNOOJTDpgXeFNMmUGg=; b=rz2NTiJjKrDlVtbLQ77G7dyIV3BPcUBKdg50sjQcOT6LaD21aOaA0rhyc2TKWCH1gC 4GTavtTr+DTQ48rjFdsz1OVtU/Belp3Ot17/RcJ8ViGg7bDfhvIkkpEHoQn2Ux8O/tYE HsdFqqhDtJush9AJY4dEzOLK7Mg/zD0992BCcJId6xkaizAxMSlonVjxP6ZclC+5mB54 6VT/cCiQ7okHJgh8MeUYVNNugz/sZRGnlhxKg2+tfhWg1RTkfgs7WTt4cuwY9hEaezNU 2F8tVS8woARCs6bwuVP0QPB3tMnNRsq1NBHmANGgvEa3jLCM7rw8mTfwwF+7zU3fnCq+ 46mQ== X-Gm-Message-State: ABuFfohxEYNjhQNV5J5qmywD7+ywclLDkrj7I2Bdy5Mcuxl+SWNw4eLF O8HYyFPa6Ptwr9xIiyu+ogf9RWjCIkHUUF4fZk8= X-Google-Smtp-Source: ACcGV60ZxbU9Qw4c5TXYR7aN0D+MvUT/4TfLFaHF2BjbkFHT/cerGMkljbV1RrDEXNNOpkFxl+/FbkRovzkuD2ttqK8= X-Received: by 2002:a2e:2942:: with SMTP id u63-v6mr1197569lje.28.1537852436803; Mon, 24 Sep 2018 22:13:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: youenn fablet Date: Mon, 24 Sep 2018 22:13:45 -0700 Message-ID: To: Lennart Grahl Cc: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="0000000000003676440576ab2c85" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 05:14:01 -0000 --0000000000003676440576ab2c85 Content-Type: text/plain; charset="UTF-8" > > Perhaps its feasible for those use cases where the administrator is > already aware of the software but definitely not for small applications > such as sharedrop.io, Threema Web whose main use case is the direct > connection in same network environments and its significant benefits > regarding throughput. > I agree this is the most likely scenario where host candidates are actually useful: two web browsers doing pure data channel on a managed/complex network, and no coordination between the network admin being and the app. --0000000000003676440576ab2c85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Perhaps its feasible for those use cases where the administrator is
already aware of the software but definitely not for small applications
such as sharedrop.io, Threema Web whose main use case is the direct
connection in same network environments and its significant benefits
regarding throughput.
=C2=A0
I agree this is= the most likely scenario where host candidates are actually useful: two we= b browsers doing pure data channel on a managed/complex network, and no coo= rdination between the network admin being and the app.

=
--0000000000003676440576ab2c85-- From nobody Mon Sep 24 22:14:14 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEFB131253 for ; Mon, 24 Sep 2018 22:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKbDW4OgkH9e for ; Mon, 24 Sep 2018 22:14:05 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D05A131251 for ; Mon, 24 Sep 2018 22:14:05 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id j25-v6so391264ljg.2 for ; Mon, 24 Sep 2018 22:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yWlrUfj6ntEmicTFTSgUgY6MYuptKSUPhQFIHWi2EfY=; b=XY1FdRqrXsGwBagh7iy/X3/4tAWwqNIw62R+0XJFez2pG8Lgxw+1ZHgR16e0xP49bQ 5PPpyqaGByvQQs2rQhNlpxhDQa2EoKpY2MdX9DVS6R/Kp/NP5gKTp3iuwkqcc+v94CN2 6ChMgh6nhs4L7qsYjeKeB3zjwzsP92lKPPBMwILYE8cN7LzjtSVZRuBVA+8pq7A+c/RT P23pJn3CWDy8cNNHTNeGvw6VDQch1nENqd+v0dykPRPKzMc95hQAFPjg/8bVdW6nfwVP mFb+I/yGl9otWsSsouihyAt3SnlhdzasPt6sEqz4Sm4X7wOk131ExZxg2Wnalf1u1ab0 EhVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yWlrUfj6ntEmicTFTSgUgY6MYuptKSUPhQFIHWi2EfY=; b=hUqoWGAlxDsG8CcTrJV951MiHDI7PmvOAc46Q0rM45uf7G9EsW3iu52GsO1ipbi83A pwVGsLzAZn1fy+YZaLFXNOr5XI3McboLshlIJZqFW0KdcTmB6+pYXvdBLwU19U4Z5Vic P0TJ9+n6e+l4Pm6EWng4SMmiNkQq+WjP/g1hfMYW68B4C5Mh8yPDpK48jn+vRB5ESxfH WYjgSyp4VyiCKUzCdtGWMJlLaG2fMsJN1GGfQ29QzbhNgzsm58DeZrLNKfNzrQvCAbCe qoiZsZElh6RsOv8nfTu8MrSYMSaKSRjycjS4G0NmBfx3y+ca6kgVpwLOksVZoKaVt7fd TQEg== X-Gm-Message-State: ABuFfohY19p81jMbG6OALhwROjbF2MDI7ioZk00VRJcJ0JQLzTZXxvMV OmyeT2SGh9Qj0eKfWfwQadD49Y0BFz8EL24F2/3+dw== X-Google-Smtp-Source: ACcGV60RPpC1SCEa3r9s8nW2yi/GReoBxbayqF3lfE2JLVZAeFDlQB2qquOT6pY4cCkbJNtndrgGmOfmr/Fv0CD0/DE= X-Received: by 2002:a2e:8513:: with SMTP id j19-v6mr1251367lji.10.1537852443191; Mon, 24 Sep 2018 22:14:03 -0700 (PDT) MIME-Version: 1.0 References: <153678937808.9522.4000911693895472411@ietfa.amsl.com> <839ACAD9-EDD5-4DFD-ABC5-BCC827A10F11@iii.ca> In-Reply-To: <839ACAD9-EDD5-4DFD-ABC5-BCC827A10F11@iii.ca> From: youenn fablet Date: Mon, 24 Sep 2018 22:13:51 -0700 Message-ID: To: Cullen Jennings Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000097ec940576ab2c35" Archived-At: Subject: Re: [rtcweb] dos and draft-ietf-rtcweb-mdns-ice-candidates-00 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 05:14:13 -0000 --00000000000097ec940576ab2c35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed, I filed https://github.com/youennf/mdns-ice-candidates/issues/5 to track this. Thanks, Y Le mer. 19 sept. 2018 =C3=A0 18:15, Cullen Jennings a =C3= =A9crit : > > I think the document should looking into the issue if a drive by web page > load could create enough MDNS traffic to cause problems on the the networ= k. > I'm not arguing this is a problem but just that it might be and some shou= ld > look into that and document that in the security section of the draft. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --00000000000097ec940576ab2c35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed, I filed=C2=A0https://github.com/youennf/mdns-ice-candidat= es/issues/5=C2=A0to track this.
Thanks,
=C2=A0 =C2=A0Y
Le=C2=A0mer. 19 sept. 2018= =C3=A0=C2=A018:15, Cullen Jennings <fl= uffy@iii.ca> a =C3=A9crit=C2=A0:

I think the document should looking into the issue if a drive by web page l= oad could create enough MDNS traffic to cause problems on the the network. = I'm not arguing this is a problem but just that it might be and some sh= ould look into that and document that in the security section of the draft.=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000097ec940576ab2c35-- From nobody Tue Sep 25 01:01:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25B0131240 for ; Tue, 25 Sep 2018 01:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4RJsXOdfExw for ; Tue, 25 Sep 2018 01:01:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EBD131233 for ; Tue, 25 Sep 2018 01:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537862476; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YWaG2QopSGuJHO8Vl3jF9PI6CoQv85whAhtbWYR1jmM=; b=QLmYzvr1Wfrq4TcTpIekYbCsMmiDTF+m3DkrMAAXo8JyEvlJDJRCs/v2CRduI/NY 7kqzTzNmFTZ5sx6OCMiseHxV37X4XrNl0TRp2jT4vlwjYNC9NmLCF5m0Ik8nXMgk SNWy39PqRcddggNgkTBpQjOh2caeK/krCrC0LdumiV0=; X-AuditID: c1b4fb25-8ffff700000013ad-e4-5ba9eb4c949b Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.23.05037.C4BE9AB5; Tue, 25 Sep 2018 10:01:16 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 25 Sep 2018 10:01:16 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Tue, 25 Sep 2018 10:01:16 +0200 From: Christer Holmberg To: RTCWeb IETF CC: Cullen Jennings , Nils Ohlmeier Thread-Topic: [rtcweb] Identity assertion: identity attribute pull request updated Thread-Index: AQHUU/Uh6XZGEqEZvEO/tavRjlOlRaT/iaEAgAEq74A= Date: Tue, 25 Sep 2018 08:01:16 +0000 Message-ID: <51F9A434-42EC-4E8B-B4C3-6218230DC7E0@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.0.180812 x-originating-ip: [153.88.183.157] Content-Type: text/plain; charset="utf-8" Content-ID: <030AE662A1DA10499E76863DE10A0DDD@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2J7ka7P65XRBndOyll0TGazuD5vMqPF 2n/t7A7MHlN+b2T1WLLkJ5NH34Eu1gDmKC6blNSczLLUIn27BK6M3U+PsRScEavYe066gbFB rIuRk0NCwETiw6H7zF2MXBxCAkcZJf6fvMUE4XxjlPg+ZRkLhLOMUWLf/83sXYwcHGwCFhLd /7RBukUEFCWeLFzCCGIzC/hK/Lq/BaxEWCBYYtGtIIiSEIkTM46wgoRFBKwk+nergIRZBFQl jt37wgRi8wrYS3xZ+ZYNxBYSKJXYu2Mu2EROAQeJdfdPsoLYjAJiEt9PrWGC2CQucevJfCaI +wUkluw5zwxhi0q8fPwPbJWogL7EtMsBEGEliS29W5hAwswCmhLrd+lDTLGWODVvEtRERYkp 3Q/ZIa4RlDg58wnLBEaJWUiWzULonoWkexaS7llIuhcwsq5iFC1OLU7KTTcy1kstykwuLs7P 08tLLdnECIzHg1t+q+5gvPzG8RCjAAejEg9v5uOV0UKsiWXFlbmHGCU4mJVEeJt0gUK8KYmV ValF+fFFpTmpxYcYpTlYlMR5H5pvjhISSE8sSc1OTS1ILYLJMnFwSjUw6nTsO3iM7/Cy3dLe 398su9Y1Jyd/40LvOeYX/rEdcTFjnLr9ZMilqnenWWtqy8IafHP4d36X6X+18ZfBgZ93Svtv H2KQycnSWN8ytfig1JdTlbvY39usqSn94K3I62Ix6e/M1jhf0WSptrec1aHxJZ7zr2XrZv6V fMet3ur9fdqOTVeq9phcVmIpzkg01GIuKk4EAJdamQzDAgAA Archived-At: Subject: Re: [rtcweb] Identity assertion: identity attribute pull request updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 08:01:26 -0000 SGksDQoNClB1bGwgcmVxdWVzdCB1cGRhdGVkIChjb21taXQgIzQpIGJhc2VkIG9uIGNvbW1lbnRz IGZyb20gQ3VsbGVuIGFuZCBOaWxzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCu+7v09u IDI0LzA5LzE4IDE3OjExLCAicnRjd2ViIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVyZyIg PHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgSSBoYXZlIG5vdyBtb2Rp ZmllZCB0aGUgTy9BIHNlY3Rpb24sIHVzaW5nIHRoZSBvbGQgc3R5bGUuDQogICAgDQogICAgSSBU SElOSyBJIGhhdmUgbm93IGFkZHJlc3NlZCBhbGwgaXNzdWVzLCBidXQgcGxlYXNlIHRha2UgYSBs b29rIHRvIHZlcmlmeS4NCiAgICANCiAgICBSZWdhcmRzLA0KICAgIA0KICAgIENocmlzdGVyDQog ICAgDQogICAgDQogICAgT24gMjQvMDkvMTggMTM6NTUsICJydGN3ZWIgb24gYmVoYWxmIG9mIENo cmlzdGVyIEhvbG1iZXJnIiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgDQogICAgICAgIEhpLA0K ICAgICAgICANCiAgICAgICAgTm90ZSB0aGF0IHRoZSB0ZXh0IGRvZXMgTk9UIGFsbG93IG11bHRp cGxlIGlkZW50aXR5IGFzc2VydGlvbnMuIElmIHNvbWVvbmUgaGFzIGEgcHJvYmxlbSB3aXRoIHRo YXQgaGUvc2hlIG5lZWRzIHRvIHNwZWFrIHVwLg0KICAgICAgICANCiAgICAgICAgUmVnYXJkcywN CiAgICAgICAgDQogICAgICAgIENocmlzdGVyDQogICAgICAgIA0KICAgICAgICANCiAgICAgICAg T24gMjQvMDkvMTggMTM6NTMsICJydGN3ZWIgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJn IiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgICAgIA0KICAgICAgICAgICAgSGksDQogICAgICAg ICAgICANCiAgICAgICAgICAgIEkgaGF2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3Qgb24gdGhl IFNEUCBpZGVudGl0eSBhdHRyaWJ1dGUsIGJhc2VkIG9uIGNvbW1lbnRzIGZyb20gTWFydGluLCBD dWxsZW4gYW5kIEFkYW06DQogICAgICAgICAgICANCiAgICAgICAgICAgIGh0dHBzOi8vZ2l0aHVi LmNvbS9ydGN3ZWItd2cvc2VjdXJpdHktYXJjaC9wdWxsLzc3DQogICAgICAgICAgICANCiAgICAg ICAgICAgIEkgd2lsbCBzdGlsbCBoYXZlIHRvIGZpeCB0aGUgTy9BIHByb2NlZHVyZXMuIE1hcnRp biBzdWdnZXN0ZWQgdG8gbWVyZ2Ugc29tZSBzZWN0aW9ucywgd2hpbGUgQWRhbSBzdWdnZXN0ZWQg dG8gdXNlIHRoZSBvbGQgaW5pdGlhbC9zdWJzZXF1ZW50IE8vQSBzdHJ1Y3R1cmUuIEkgd2lsbCBs b29rIGludG8gaXQgYW5kIHN1Z2dlc3Qgc29tZXRoaW5nIHNvb24uDQogICAgICAgICAgICANCiAg ICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICANCiAgICAgICAgICAgIENocmlzdGVyDQog ICAgICAgICAgICAgDQogICAgICAgICAgICANCiAgICAgICAgICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgICBydGN3ZWIgbWFpbGlu ZyBsaXN0DQogICAgICAgICAgICBydGN3ZWJAaWV0Zi5vcmcNCiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQogICAgICAgICAgICANCiAgICAg ICAgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgICAgIHJ0Y3dlYiBtYWlsaW5nIGxpc3QNCiAgICAgICAgcnRjd2ViQGlldGYub3Jn DQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQog ICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgcnRjd2ViIG1haWxpbmcgbGlzdA0KICAgIHJ0Y3dlYkBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQogICAgDQoN Cg== From nobody Wed Sep 26 12:22:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9471C12872C for ; Wed, 26 Sep 2018 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJpcojqsKPrd for ; Wed, 26 Sep 2018 12:22:23 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FA1127333 for ; Wed, 26 Sep 2018 12:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537989741; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sI8Gctno9tdoG7q2HWDPebmZEPVt0oiuuw001lUo7f0=; b=c4xXCiB3pWcM+ncN648HqR81TDlimTUd8bNWbK6EbRCLdUaR9UwQkvin96hFkH2P u2AtIoCtNkqJSjK2c33ERutm+MZzNro35iMlQzt6pCbps+dIlP6G2xk6PZl2TYqG DRYWCEsrJfTXM3vFC/FyDSXRb7ejGlvmA5V1MxY1IhE=; X-AuditID: c1b4fb30-fe1ff700000055da-75-5babdc6d71ac Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A4.40.21978.D6CDBAB5; Wed, 26 Sep 2018 21:22:21 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 26 Sep 2018 21:22:20 +0200 Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Wed, 26 Sep 2018 21:22:20 +0200 From: Christer Holmberg To: Christer Holmberg , RTCWeb IETF CC: Cullen Jennings Thread-Topic: [rtcweb] Identity assertion: identity attribute pull request updated Thread-Index: AQHUU/Uh6XZGEqEZvEO/tavRjlOlRaT/iaEAgAEq74CAAj9PEA== Date: Wed, 26 Sep 2018 19:22:20 +0000 Message-ID: <68544dec22024a24a43042388a0575f7@ericsson.com> References: <51F9A434-42EC-4E8B-B4C3-6218230DC7E0@ericsson.com> In-Reply-To: <51F9A434-42EC-4E8B-B4C3-6218230DC7E0@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbG9RDf3zupog62HeCw6JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZexrvcVWME2h4vGUt8wNjGvkuxg5OCQETCQu nQvuYuTiEBI4yijx/10LE4TzjVFi5v5rzBDOMkaJh3/XM4N0sAlYSHT/0+5i5OQQEQiXOH2r jRHEZhZQk3h0+TAziC0sECyxcPpZVoiaEIkTM45A2U4SEx7eZAOxWQRUJd4ufQNm8wpYSxw/ t5QVYtdqRonP7dfBhnIKOEicObQLrJlRQEzi+6k1TBDLxCVuPZkPZksICEgs2XOeGcIWlXj5 +B8rhK0ksffYdRaQm5kFNCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis1CMnUWQscsJB2zkHQs YGRZxShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYOwe3/DbYwfjyueMhRgEORiUe3o7jq6OF WBPLiitzDzFKcDArifCu2w4U4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmvhtzlKSCA9sSQ1OzW1 ILUIJsvEwSnVwNjKsv9kYOBhfQ3h1wv3ND1SfSEkVGPxw0D8UtDBTVeCj053E5b8pbuofq3B nIyoBRNnFMlsqoqYWDb5dxBvUmTZ2ujM9GLV836zmiv33TW0ExSwa5NM9a7eaKeewXd7Xl3g vxnq5283hcz8u/z6h/mv77I9f3/9QOyplRaaeR7zUhSij+hb6iuxFGckGmoxFxUnAgA6yGbW mQIAAA== Archived-At: Subject: Re: [rtcweb] Identity assertion: identity attribute pull request updated X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 19:22:26 -0000 SGksDQoNCkkgdXBkYXRlZCB0aGUgcHVsbCByZXF1ZXN0IChjb21taXQgIzUpLCB3aGVyZSBJIHRy aWVkIHRvIGFsaWduIHRoZSBTRFAgYXR0cmlidXRlIHRlcm1pbm9sb2d5Lg0KDQpBIGNvdXBsZSBv ZiBxdWVzdGlvbnM6DQoNCjEuIFNvbWV0aW1lcyB0aGUgZHJhZnQgdXNlcyA8c3Bhbng+IGFyb3Vu ZCBhdHRyaWJ1dGUgbmFtZXMsIGFuZCBzb21ldGltZXMgaXQgZG9lc24ndC4NCg0KMi4gJ2Zpbmdl cnByaW50JyBpcyB1c2VkIGZvciBtYW55IHRoaW5ncyBpbiB0aGUgZHJhZnQ6IHRoZSBhcnJheSBu YW1lIGluIGEgSlNPTiBzdHJ1Y3R1cmUsIHRoZSBTRFAgYXR0cmlidXRlLCBhbmQgdGhlIGZpbmdl cnByaW50cyBpbiBnZW5lcmFsLiBXZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGUgdGV4dCBpcyBjbGVh ciBvbiB3aGF0IGl0IHJlZmVycyB0byBpbiBldmVyeSBpbnN0YW5jZS4NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHJ0Y3dlYiBbbWFp bHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJl cmcNClNlbnQ6IDI1IFNlcHRlbWJlciAyMDE4IDExOjAxDQpUbzogUlRDV2ViIElFVEYgPHJ0Y3dl YkBpZXRmLm9yZz4NCkNjOiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+DQpTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gSWRlbnRpdHkgYXNzZXJ0aW9uOiBpZGVudGl0eSBhdHRyaWJ1dGUg cHVsbCByZXF1ZXN0IHVwZGF0ZWQNCg0KSGksDQoNClB1bGwgcmVxdWVzdCB1cGRhdGVkIChjb21t aXQgIzQpIGJhc2VkIG9uIGNvbW1lbnRzIGZyb20gQ3VsbGVuIGFuZCBOaWxzLg0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCu+7v09uIDI0LzA5LzE4IDE3OjExLCAicnRjd2ViIG9uIGJlaGFs ZiBvZiBDaHJpc3RlciBIb2xtYmVyZyIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs ZiBvZiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQogICAgSGksDQog ICAgDQogICAgSSBoYXZlIG5vdyBtb2RpZmllZCB0aGUgTy9BIHNlY3Rpb24sIHVzaW5nIHRoZSBv bGQgc3R5bGUuDQogICAgDQogICAgSSBUSElOSyBJIGhhdmUgbm93IGFkZHJlc3NlZCBhbGwgaXNz dWVzLCBidXQgcGxlYXNlIHRha2UgYSBsb29rIHRvIHZlcmlmeS4NCiAgICANCiAgICBSZWdhcmRz LA0KICAgIA0KICAgIENocmlzdGVyDQogICAgDQogICAgDQogICAgT24gMjQvMDkvMTggMTM6NTUs ICJydGN3ZWIgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIiA8cnRjd2ViLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQogICAgDQogICAgICAgIEhpLA0KICAgICAgICANCiAgICAgICAgTm90ZSB0aGF0IHRoZSB0 ZXh0IGRvZXMgTk9UIGFsbG93IG11bHRpcGxlIGlkZW50aXR5IGFzc2VydGlvbnMuIElmIHNvbWVv bmUgaGFzIGEgcHJvYmxlbSB3aXRoIHRoYXQgaGUvc2hlIG5lZWRzIHRvIHNwZWFrIHVwLg0KICAg ICAgICANCiAgICAgICAgUmVnYXJkcywNCiAgICAgICAgDQogICAgICAgIENocmlzdGVyDQogICAg ICAgIA0KICAgICAgICANCiAgICAgICAgT24gMjQvMDkvMTggMTM6NTMsICJydGN3ZWIgb24gYmVo YWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVo YWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQogICAgICAgIA0K ICAgICAgICAgICAgSGksDQogICAgICAgICAgICANCiAgICAgICAgICAgIEkgaGF2ZSB1cGRhdGVk IHRoZSBwdWxsIHJlcXVlc3Qgb24gdGhlIFNEUCBpZGVudGl0eSBhdHRyaWJ1dGUsIGJhc2VkIG9u IGNvbW1lbnRzIGZyb20gTWFydGluLCBDdWxsZW4gYW5kIEFkYW06DQogICAgICAgICAgICANCiAg ICAgICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9ydGN3ZWItd2cvc2VjdXJpdHktYXJjaC9wdWxs Lzc3DQogICAgICAgICAgICANCiAgICAgICAgICAgIEkgd2lsbCBzdGlsbCBoYXZlIHRvIGZpeCB0 aGUgTy9BIHByb2NlZHVyZXMuIE1hcnRpbiBzdWdnZXN0ZWQgdG8gbWVyZ2Ugc29tZSBzZWN0aW9u cywgd2hpbGUgQWRhbSBzdWdnZXN0ZWQgdG8gdXNlIHRoZSBvbGQgaW5pdGlhbC9zdWJzZXF1ZW50 IE8vQSBzdHJ1Y3R1cmUuIEkgd2lsbCBsb29rIGludG8gaXQgYW5kIHN1Z2dlc3Qgc29tZXRoaW5n IHNvb24uDQogICAgICAgICAgICANCiAgICAgICAgICAgIFJlZ2FyZHMsDQogICAgICAgICAgICAN CiAgICAgICAgICAgIENocmlzdGVyDQogICAgICAgICAgICAgDQogICAgICAgICAgICANCiAgICAg ICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgICAgICAgICBydGN3ZWIgbWFpbGluZyBsaXN0DQogICAgICAgICAgICBydGN3ZWJAaWV0Zi5v cmcNCiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRj d2ViDQogICAgICAgICAgICANCiAgICAgICAgDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgIHJ0Y3dlYiBtYWlsaW5nIGxpc3QN CiAgICAgICAgcnRjd2ViQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcnRjd2ViDQogICAgICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgcnRjd2ViIG1haWxpbmcgbGlz dA0KICAgIHJ0Y3dlYkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcnRjd2ViDQogICAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpydGN3ZWIgbWFpbGluZyBsaXN0DQpydGN3ZWJAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo= From nobody Wed Sep 26 18:10:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B6F130D7A for ; Wed, 26 Sep 2018 18:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8YHElMuaFVg for ; Wed, 26 Sep 2018 18:10:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003067.outbound.protection.outlook.com [40.92.3.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB45127AC2 for ; Wed, 26 Sep 2018 18:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VSnWrQNrUvh7EpON6z2KNStf6ZzNc2SQ7VALfSC/5Cs=; b=ZQi0IlpyeBkHz7sljCg68mGGh2DckBHrfkNMh7aQ8xiGbvEr8RQIWw5gV7rd84Pd7YuajwsTasgnpl7fb0kTUCHivFhHiF6RRNFuTXIVAZPVrwamwc4mFoTdfg4I+VUDVttvSz/JJEV06Lx3iBaO5edURqIX6qZ8ZMoI4CNfBGN1eXy9VBeMfj5hr+UN+3ZCuMr3S3hZQxlOBxPaREfOdctHCsZAxggmk5bKLpAb07O2gC57Fgemvu83gKTdRtdRj9eiX4+ZMbsLnPW7+XKCv2yPfl7rHmqucOR+dGrqeSn5H44YkoX0gjmm9+UKf+Joy8J8e2UXyp0mavVOKqSfwg== Received: from BL2NAM02FT060.eop-nam02.prod.protection.outlook.com (10.152.76.56) by BL2NAM02HT158.eop-nam02.prod.protection.outlook.com (10.152.76.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1185.13; Thu, 27 Sep 2018 01:10:40 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com (10.152.76.57) by BL2NAM02FT060.mail.protection.outlook.com (10.152.76.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1185.13 via Frontend Transport; Thu, 27 Sep 2018 01:10:40 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com ([fe80::d588:9eb9:cc8c:2be5]) by CY4PR0101MB3095.prod.exchangelabs.com ([fe80::d588:9eb9:cc8c:2be5%5]) with mapi id 15.20.1143.022; Thu, 27 Sep 2018 01:10:40 +0000 From: Adam Sobieski To: "rtcweb@ietf.org" Thread-Topic: WebRTC and Real-time Translation Thread-Index: AQHUVe1M2MPUNlozpUmfS3sPuCqXGw== Date: Thu, 27 Sep 2018 01:10:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3FC214BFD73AB7FC7580597DAE09D491A6C029ABE8A13157CD7C5CFDAF74FB26; UpperCasedChecksum:28AE485D5B1923B42ACA4260926394BCEE5FA711D2760539FCB414E7AF1DEC17; SizeAsReceived:6802; Count:43 x-tmn: [yUFdECqLbOkCTu6vd4GV0XvvjF34ZJXo] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL2NAM02HT158; 6:0dc1ZFv1/bdP7k84g4T73sK21O8BADDUhI6/E8+hpZwoY7e6aErixLzXZYvlp0UlFddG5z2n7ONeHZvJpkZtWwfZfKu8tgPFT5CCa993M3WfStV1rKCi7SY+PHArtdro2CmKzBJOzqncD6KrZSduH9Af/E7f1AVQsGozTbKIeequCnTolnFRilVeyq1Ity3TSBafDN7oMhoh+JNUWv9p1G3eipCLyht5oDPErCDVvW5bs+LASYB1NNhCd6TbBGHIz3hTcDJ4AItifGYGvh11YJTX1BCB3o/xYLTrZbA0A3ltd58YW/d+Gv3wUBizRy1fUoRLiHwrvmYfkqkvhXzLEF6a2Av6eBVrhR7+92jsnB3/WRyNWtHzN2CRsWMmc80rhfe3cm9nqVNJpdbu2br0OSgCUz7iiiQt/KZLdWqTec2CPTwDUBVP8kGKq1P1smBCRAm1YxpYgyAS4GKoYiXZYw==; 5:8vaE7dwxQQlYDMy3IFwA91eJ3CqgbSULOaikit9pG5snikk3vwqTjWfLDbiBZzQqlbwG/2Bm3qXsiQh2GfVTu4JK3pBvn3Hz2IvPf1XvSTazeSwWLnQ2tldF4M6bye5qIFDUeY3vtuCmKqZiNHa44n92DUhIFGtxGjvH2C81Zio=; 7:cDHEyxHbP7a24/1Sym/cYTrvaqIHZRdQtLieJ+NaAbe58PMrMO+zWDVxDsStl4VBjFZp4EZ9PM3Tnz5u39rswheVrKa7PvyLkZ8ugwgrWoxIA+MLm9AX6N/6gWbunlHotiLEsj6l01UZRdPYu+6J8DjtAQqQMjGqNKinnGcIYM9Qcg8D7/ZQIuPpxd4fFDItfV58Ny3CufGT0tzZXXjXgMDT93Z5ZDHgM3u/F9j0PbibjNlvb8Mog1XlQSnq3X9b x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:BL2NAM02HT158; x-ms-traffictypediagnostic: BL2NAM02HT158: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BL2NAM02HT158; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT158; x-forefront-prvs: 0808323E97 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(71190400001)(81156014)(6506007)(86362001)(606006)(3480700004)(8936002)(87572001)(56003)(73972006)(7696005)(486006)(8676002)(26005)(476003)(25786009)(20460500001)(99286004)(54896002)(1730700003)(55016002)(83332001)(6306002)(966005)(68736007)(236005)(14454004)(33656002)(6436002)(6346003)(2351001)(102836004)(97736004)(104016004)(6916009)(5640700003)(2900100001)(2501003)(82202002)(71200400001)(14444005)(34290500001)(256004)(74316002)(9686003)(105586002)(5660300001)(106356001)(5250100002)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT158; H:CY4PR0101MB3095.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=adamsobieski@hotmail.com; x-microsoft-antispam-message-info: tCFr7URrcz0ShowVlPa0dcbVN7xYwEGAw9XkOIiy5uu1TdqEZZByYmWz2quDNlibZyNjqHgCdBqznaay4uaBo24Xudzi2rgIOPKz8vMxd2KNtsZJi9TBxDXyTEWSgOAvK2JjhxDpjl/T1MuIAefyeX8pMFTXVxDlq3Mi+wlQCGAWMBiV7+Ws0BNDLROHsXbwt3rXwUAGfZasvS5l9rhMAO5d8eZF5HWN+4AF+rUCXdc= Content-Type: multipart/alternative; boundary="_000_CY4PR0101MB309521AF4EF436C0D1503741C5150CY4PR0101MB3095_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: 9cc9db0f-9b4c-471c-2bd4-08d624160a6e X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 01:10:40.1506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT158 Archived-At: Subject: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 01:10:44 -0000 --_000_CY4PR0101MB309521AF4EF436C0D1503741C5150CY4PR0101MB3095_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF RTCWEB Working Group, Greetings. I opened an issue on WebRTC and Real-time Translation at the Git= Hub repository for WebRTC version next use cases (https://github.com/w3c/we= brtc-nv-use-cases/issues/2). Introduction Real-time translation is both an interesting and important use case for a n= ext version of WebRTC. Speech Recognition, Translation and Speech Synthesis Approaches to real-time speech-to-speech machine translation include those = which interconnect speech recognition, translation and speech synthesis com= ponents and services. In that regard, we can consider client-side, on-prem,= server-side, third-party and cloud-based components and services. In that = regard, we can also consider both free and priced components and services. We can envision post-text speech technology and machine translation compone= nts and services. Speech recognition need not output to text; we can consid= er speech-to-SSML. Machine translation need not input from nor output to te= xt; we can consider SSML-to-SSML machine translation. Components and servic= es may provide various options with respect to their input and output data = formats. Connecting Components and Services by Constructing Graphs We can consider APIs which facilitate the construction of graphs which repr= esent the flow of data between components and services. As these graphs are= constructed, users could be apprised of relevant notifications, requests f= or permissions and options for payments. As these constructed graphs are ac= tivated, a number of protocols could be utilized to interconnect the compon= ents and services which, together, provide users with real-time translation= . Hyperlinks WebRTC Translator Demo Real Time Translation in WebRTC Best regards, Adam Sobieski http://www.phoster.com/contents/ --_000_CY4PR0101MB309521AF4EF436C0D1503741C5150CY4PR0101MB3095_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IETF RTCWEB Working Group,

 

Greetings. I opened an issue on WebRTC and Real-t= ime Translation at the GitHub repository for WebRTC version next use ca= ses (https:= //github.com/w3c/webrtc-nv-use-cases/issues/2).

 

Introdu= ction

Real-time translation is both an interesting and important = use case for a next version of WebRTC.

Speech Recognition, Translation and Speech Synthesis

Approaches to real-time speech-to-speech machine translatio= n include those which interconnect speech recognition, translation and spee= ch synthesis components and services. In that regard, we can consider client-side, on-prem, server-side, third-party and= cloud-based components and services. In that regard, we can also consider = both free and priced components and services.

We can envision post-text speech technology and = machine translation components and services. Speech recognition need not output to text; we can consider speech-to-SSML. Machine translation ne= ed not input from nor output to text; we can consider SSML-to-SSML machine = translation. Components and services may provide various options with respe= ct to their input and output data formats.

Connecting Components and Services by Constructing Graphs

We can consider APIs which facilitate the construction of g= raphs which represent the flow of data between components and services. As = these graphs are constructed, users could be apprised of relevant notifications, requests for permissions and options f= or payments. As these constructed graphs are activated, a number of protoco= ls could be utilized to interconnect the components and services which, tog= ether, provide users with real-time translation.

Hyperlinks

W= ebRTC Translator Demo
Real Time Translation in WebRTC

 

 

Best regards,

Adam Sobieski

http://= www.phoster.com/contents/

 

--_000_CY4PR0101MB309521AF4EF436C0D1503741C5150CY4PR0101MB3095_-- From nobody Wed Sep 26 21:58:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1392B130DF0 for ; Wed, 26 Sep 2018 21:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCnWkzNk2RTV for ; Wed, 26 Sep 2018 21:58:21 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 4941A130DEE for ; Wed, 26 Sep 2018 21:58:21 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id y11-v6so759232vso.5 for ; Wed, 26 Sep 2018 21:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dKKC7A7TCt7q29RycOs4e0YDfQW455WCcFtQV1LOZBc=; b=V/urth0Q+WGx2oC6SQzIdnwA/1Te063zbfH5hfBLuzuzWoFDvlIHVDXR0eAxlBnpoP 1fBO9DlR15ORhcZ3+okN1gsPYlJDQuO3XvuDcoxfsGoIg/xVGqiV7HKW6e4tzt7igIeC 3FxlbytydJBPfeBju6GPc0yKEQkV/dt6/cJUeBaWvifDbI6DLiD0q/z2P+FV7ULh80eq qBg9wNhFHg652WWOZ4dl0Pfl8nfXsj9KJyiT8aZluzJ17XkB38MNwU5acq2zXGCOZuUV OSpJOxsfR0+9XyYe5v2Vm+vW1Ellr9vQTP1nJjcLa9hSmJdSCgFYLmAmAQ0X/xpspPTT xEmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dKKC7A7TCt7q29RycOs4e0YDfQW455WCcFtQV1LOZBc=; b=ICwNnMsg6gY/J8jpRnBVDr4HSzwNrnEfAqtuwi3ZxiuooUyHOVKdYnWIERDIZ+Vxz8 OL2PL+O/CNUz+y4ZONVIj2DkveLH7ykHz2mCO3NrpOw7JyCwNLh0cMCxoMMqurDmmhDI k2tUybkIMNolFySFCVEKIZoKSqq37BFnTrMYFb+HO0wVPmxgYD3PtQSE0DfQzmHXImJB /bICC4SuVuHZ/Ss7VKf0jWY2PdwDE1gsZSbmBwld7lCv5U/1xpLDYFFYM2EdQZqnIYzE fwEr5ZX/fvElAXD0GMEqlaKWamS5YtpXHwynrRjtflyMfuK00cSn39yqxELehSLlUoEG 9WEw== X-Gm-Message-State: ABuFfoh5DErdjHPTjVOjxzUv+byiSGKKgVE76uO3LiQrcWOAijFs2W3w KpTymWbmnClUtugybJgDBQETdIEY6CfTmw7IMRE= X-Google-Smtp-Source: ACcGV63m7IEcaXxvTRjZu71jOrdr4EVm2G2Jv8ljXD3Gb9K1XprDZcHf7Cn/OYDQBF+ro6T6NQMSFzFFVPN6Y0Uzd1w= X-Received: by 2002:a67:d388:: with SMTP id b8-v6mr2879415vsj.144.1538024299883; Wed, 26 Sep 2018 21:58:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Wed, 26 Sep 2018 21:58:08 -0700 Message-ID: To: adamsobieski@hotmail.com Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000cf2c10576d3301e" Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 04:58:24 -0000 --0000000000000cf2c10576d3301e Content-Type: text/plain; charset="UTF-8" One of the key questions for "Next Version Use Cases" is what WebRTC-deficiencies are preventing these use cases from being satisfactorily implemented today. For example, speech transcription cloud services have been implemented over Websockets, where a snippet of speech is uploaded, and a transcription is provided in reply. The latency is satisfactory for some uses cases. Improvements can perhaps be made by sending an audio stream and receiving a transcription via the data channel, but this is also within the capabilities of the existing RTCWEB protocols and WebRTC-PC API. What seems to differentiate *next version* scenarios are situations where the processing is best done on the device, in order to lower latency or enhance privacy. On-device processing brings in discussion of workers/worklets, access to raw audio/video, etc. However, so far I'm not aware of on-device implementations of transcription or translation. On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski wrote: > IETF RTCWEB Working Group, > > > > Greetings. I opened an issue on *WebRTC and Real-time Translation* at the > GitHub repository for WebRTC version next use cases ( > https://github.com/w3c/webrtc-nv-use-cases/issues/2). > > > Introduction > > Real-time translation is both an interesting and important use case for a > next version of WebRTC. > Speech Recognition, Translation and Speech Synthesis > > Approaches to real-time speech-to-speech machine translation include those > which interconnect speech recognition, translation and speech synthesis > components and services. In that regard, we can consider client-side, > on-prem, server-side, third-party and cloud-based components and services. > In that regard, we can also consider both free and priced components and > services. > > We can envision *post-text* speech technology and machine translation > components and services. Speech recognition need not output to text; we can > consider speech-to-SSML. Machine translation need not input from nor output > to text; we can consider SSML-to-SSML machine translation. Components and > services may provide various options with respect to their input and output > data formats. > Connecting Components and Services by Constructing Graphs > > We can consider APIs which facilitate the construction of graphs which > represent the flow of data between components and services. As these graphs > are constructed, users could be apprised of relevant notifications, > requests for permissions and options for payments. As these constructed > graphs are activated, a number of protocols could be utilized to > interconnect the components and services which, together, provide users > with real-time translation. > Hyperlinks > > WebRTC Translator Demo > Real Time Translation in WebRTC > > > > > > > Best regards, > > Adam Sobieski > > http://www.phoster.com/contents/ > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000000cf2c10576d3301e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the key questions for "Next Version Use Cases&= quot; is what WebRTC-deficiencies are preventing these use cases from being= satisfactorily implemented today.=C2=A0

For example, sp= eech transcription cloud services have been implemented over Websockets, wh= ere a snippet of speech is uploaded, and a transcription is provided in rep= ly.=C2=A0 The latency is satisfactory for some uses cases.=C2=A0
= Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API.=C2=A0

=
What seems to differentiate *next version* scenarios are situati= ons where the processing is best done on the device, in order to lower late= ncy or enhance privacy.=C2=A0 On-device processing brings in discussion of = workers/worklets, access to raw audio/video, etc.=C2=A0 However, so far I&#= 39;m not aware of on-device implementations of transcription or translation= .

On Wed, Sep 26= , 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> wrote:

IETF RTCWEB Working Group,

=C2=A0

Greetings. I opened an issue on WebRTC and Real-t= ime Translation at the GitHub repository for WebRTC version next use ca= ses (https://github.com/w3c/webrtc-nv-use-cases/issues/2).

=C2=A0

Introdu= ction

Real-time translation is both an interesting and important = use case for a next version of WebRTC.

Speech Recognition, Translation and Speech Synthesis=

Approaches to real-time speech-to-speech machine translatio= n include those which interconnect speech recognition, translation and spee= ch synthesis components and services. In that regard, we can consider client-side, on-prem, server-side, third-party and= cloud-based components and services. In that regard, we can also consider = both free and priced components and services.

We can envision=C2=A0post-text=C2=A0speech technology and = machine translation components and services. Speech recognition need not output to text; we can consider speech-to-SSML. Machine translation ne= ed not input from nor output to text; we can consider SSML-to-SSML machine = translation. Components and services may provide various options with respe= ct to their input and output data formats.

Connecting Components and Services by Constructing Graphs

We can consider APIs which facilitate the construction of g= raphs which represent the flow of data between components and services. As = these graphs are constructed, users could be apprised of relevant notifications, requests for permissions and options f= or payments. As these constructed graphs are activated, a number of protoco= ls could be utilized to interconnect the components and services which, tog= ether, provide users with real-time translation.

Hyperlinks

WebRTC Translator Demo
Real Time Translation in WebRTC

=C2=A0

=C2=A0

Best regards,

Adam Sobieski

http://www.phoster.com/contents/

=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000000cf2c10576d3301e-- From nobody Thu Sep 27 08:37:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF91130E65 for ; Thu, 27 Sep 2018 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N37YLM-c61Yg for ; Thu, 27 Sep 2018 08:37:49 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 ABA02130E54 for ; Thu, 27 Sep 2018 08:37:49 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id e18-v6so2970574oti.8 for ; Thu, 27 Sep 2018 08:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jbwuw1abo7xkC6goDBIDZNCrx/wkj7a6z3nSDBBFSDk=; b=cvjUFAlHH8kX5LW9cTm8URl/P+h0pHDhLnvdvrNrvYvtREgQPLdQ3b+i9o+zA308dU a/91ZnCF0qkSay0Em+3Rm+s5uObg00bJLSUS/6iZsyNU++0y5Kx0ZsIpOOjKq3L/ZRGZ DgTFyIN5U8uVEJngDJGjHC466+wo0MpN+ST3qh66D2zl8uFGjDS7/x7NQuMM5nFBygFx BSLeASDITo3WPp7ib54NoweKFFfxYaNxwr82qJQF5CeanP0fDZZhpX4SFM6fcBqsfbGc q5eIoGl6SElLR453QdMlehv2QA8qeHr4p/NrNz8id5iCtfvM/HmRY0v2BhMsejOHPerT 7P+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jbwuw1abo7xkC6goDBIDZNCrx/wkj7a6z3nSDBBFSDk=; b=Lh2rlQcDpEEw48rIKSyUsyqCMaV4yNiASctXZwlirOeXLcqc9rcHSAYaQy/rt5WEFr MDtkpRpnVwaCv4njuadrwAFDFDJoJkeMyl22TgPZMnLE5azxknp9yRoa/AtnzMG6M/tz avCvipyPBWHCbr3vBAG9JHJDLpKJDdPZpAoZUh712IyvZIB2dinDEwxcOT+iigX86t9O dsHqGRwjx+q+Ixbr2VyvOv0yJW5b/+U1txYhoFn5wcJBS3oai1wI2jTl0NwKD/aRQPxr Qrt65/1uBWZxfHK9zLzksT5LaTxthVAGfNvEcuq13KYNskkwp8zZSKMCpI1RpmKBxuu3 zihg== X-Gm-Message-State: ABuFfojxfkNd9DRdkMYP7XtpAh3P4EWWssKLOdRbP7a4OEcc4CgBfBg8 ann4SH09TbVHqk2wHiJZkIezF+m8N0OJcgQqj+SITg== X-Google-Smtp-Source: ACcGV60dcDgc7zB2xbDx2uk+SGl8/kUHJbf/R8qCzWETdku+vA4FlwmmLkgBhthn+l7i9wRgoPsaui5XkHB/s+kNKSM= X-Received: by 2002:a9d:640c:: with SMTP id h12-v6mr7123717otl.75.1538062668678; Thu, 27 Sep 2018 08:37:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Thu, 27 Sep 2018 08:37:22 -0700 Message-ID: To: adamsobieski@hotmail.com Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000249970576dc1f7f" Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 15:37:52 -0000 --0000000000000249970576dc1f7f Content-Type: text/plain; charset="UTF-8" Hi Adam, Are there specific work items for the IETF which you believe arise from this use case, or was this an FYI? regards, Ted On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski wrote: > IETF RTCWEB Working Group, > > > > Greetings. I opened an issue on *WebRTC and Real-time Translation* at the > GitHub repository for WebRTC version next use cases ( > https://github.com/w3c/webrtc-nv-use-cases/issues/2). > > > Introduction > > Real-time translation is both an interesting and important use case for a > next version of WebRTC. > Speech Recognition, Translation and Speech Synthesis > > Approaches to real-time speech-to-speech machine translation include those > which interconnect speech recognition, translation and speech synthesis > components and services. In that regard, we can consider client-side, > on-prem, server-side, third-party and cloud-based components and services. > In that regard, we can also consider both free and priced components and > services. > > We can envision *post-text* speech technology and machine translation > components and services. Speech recognition need not output to text; we can > consider speech-to-SSML. Machine translation need not input from nor output > to text; we can consider SSML-to-SSML machine translation. Components and > services may provide various options with respect to their input and output > data formats. > Connecting Components and Services by Constructing Graphs > > We can consider APIs which facilitate the construction of graphs which > represent the flow of data between components and services. As these graphs > are constructed, users could be apprised of relevant notifications, > requests for permissions and options for payments. As these constructed > graphs are activated, a number of protocols could be utilized to > interconnect the components and services which, together, provide users > with real-time translation. > Hyperlinks > > WebRTC Translator Demo > Real Time Translation in WebRTC > > > > > > > Best regards, > > Adam Sobieski > > http://www.phoster.com/contents/ > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000000249970576dc1f7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adam,

Are there specific = work items for the IETF which you believe arise from this use case, or was = this an FYI?

regards,

Ted=

On Wed, Sep= 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> wrote:

IETF RTCWEB Working Group,

=C2=A0

Greetings. I opened an issue on WebRTC and Real-t= ime Translation at the GitHub repository for WebRTC version next use ca= ses (https://github.com/w3c/webrtc-nv-use-cases/issues/2).

=C2=A0

Introdu= ction

Real-time translation is both an interesting and important = use case for a next version of WebRTC.

Speech Recognition, Translation and Speech Synthesis=

Approaches to real-time speech-to-speech machine translatio= n include those which interconnect speech recognition, translation and spee= ch synthesis components and services. In that regard, we can consider client-side, on-prem, server-side, third-party and= cloud-based components and services. In that regard, we can also consider = both free and priced components and services.

We can envision=C2=A0post-text=C2=A0speech technology and = machine translation components and services. Speech recognition need not output to text; we can consider speech-to-SSML. Machine translation ne= ed not input from nor output to text; we can consider SSML-to-SSML machine = translation. Components and services may provide various options with respe= ct to their input and output data formats.

Connecting Components and Services by Constructing Graphs

We can consider APIs which facilitate the construction of g= raphs which represent the flow of data between components and services. As = these graphs are constructed, users could be apprised of relevant notifications, requests for permissions and options f= or payments. As these constructed graphs are activated, a number of protoco= ls could be utilized to interconnect the components and services which, tog= ether, provide users with real-time translation.

Hyperlinks

WebRTC Translator Demo
Real Time Translation in WebRTC

=C2=A0

=C2=A0

Best regards,

Adam Sobieski

http://www.phoster.com/contents/

=C2=A0

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000000249970576dc1f7f-- From nobody Thu Sep 27 16:10:35 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A5F129C6A for ; Thu, 27 Sep 2018 16:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i38oSiH1qZjD for ; Thu, 27 Sep 2018 16:10:25 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 5386F130DD6 for ; Thu, 27 Sep 2018 16:10:25 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id l7-v6so3082906iok.6 for ; Thu, 27 Sep 2018 16:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wu9JpiV246HndEbMCaaRhBTvEO0WjCyj9J6625+ZRck=; b=u7frNTk+qvoixEFfTm+sYS9iqYeQTW2CYjc51AWvQMosf4W+scSMQUIN5hzGdMcoXB x7tjMKtMv6IBrWdi7WsqYhcFuFfcUVCSLcdwkYc2BrFnIzIytOclWPrJDYaodKBCh49w CrutLAQNoyZ3rfpbD62Sf2yWDugPBSqU5ff2WIlI8OSQG38TzTgd4PPQey9l88bfzLTb u9sHJPe26imyPpR3t18EOGwZ+JIxbX+RlEYCzikdPe2FJ+bZi7Zh5T3eXUsxWkSKfqvi zMF0vha/XSSDR9a32OG2VTj8JkA6ujkD7uB/udC4zMPDckT5A8Kt57Qr9r+CgLsETwIs fPVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wu9JpiV246HndEbMCaaRhBTvEO0WjCyj9J6625+ZRck=; b=igANDjoQB77mw6XYzgl20WznZrW+qq3h48sF6ciREl/q9DM8v64vTFNdLBGXHn8xAw pLMqG/pRSMJmqVtAzhDqQqs9PnSWbMWZlzjIwNx5ox/N5lQOsY9dNCwDmQVo+RT0wPJW BGJrXuJQs2N/sSMyyy2zPLTHVuEXl0xMvkehl+S3sEQNtRIEMILb9QhXEYxHkcomQupt kcqxTfn57c9NP6Gz61BNLqOyogZa8JhrIRF/nj6RYsZ3SZ8S9wKb8tZxCx+h8zexhgen Sa5ox3Yr9hg1tr7yTpGQfx5vz1Zj3piRW/pjKFdZjklluhnrtxv7NWhtkRh+kE+djsFK SKzA== X-Gm-Message-State: ABuFfojziccYQpOODg2wPqHG9M9Bv4OSAYVflKyhRKEfkNGiF63wSaBE 1JeIV+IqU4rcI7ZDe6juzdcuLiRLv612JfzWI8GzJA== X-Google-Smtp-Source: ACcGV61nCk6Wukv4aJVFOgwcP9QN6dzM/YKnm7O2FXH3GTc/zEuYq7p9hOTzSl2aT7GyUx5agIjVywadbazpLCRc/Jg= X-Received: by 2002:a5e:9809:: with SMTP id s9-v6mr9987791ioj.87.1538089824230; Thu, 27 Sep 2018 16:10:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 27 Sep 2018 16:10:12 -0700 Message-ID: To: youenn fablet Cc: Lennart Grahl , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000009bcd210576e271bd" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 23:10:27 -0000 --0000000000009bcd210576e271bd Content-Type: text/plain; charset="UTF-8" I suggest that we hold off on assessing what this might mean for data channel and related applications until we have data from browsers showing the actual connectivity/traffic impact of mDNS. We should have initial data on this topic from Chrome by EOY. On Mon, Sep 24, 2018 at 10:14 PM youenn fablet wrote: > > >> Perhaps its feasible for those use cases where the administrator is >> already aware of the software but definitely not for small applications >> such as sharedrop.io, Threema Web whose main use case is the direct >> connection in same network environments and its significant benefits >> regarding throughput. >> > > I agree this is the most likely scenario where host candidates are > actually useful: two web browsers doing pure data channel on a > managed/complex network, and no coordination between the network admin > being and the app. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000009bcd210576e271bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suggest that we hold off on assessing what this might me= an for data channel and related applications until we have data from browse= rs showing the actual connectivity/traffic impact of mDNS.

We should have initial data on this topic from Chrome by EOY.

On Mon, Sep 24, 2018 at 10= :14 PM youenn fablet <youennf@gmail= .com> wrote:


Perhaps its feasible for those use cases where the administrator is
already aware of the software but definitely not for small applications
such as sharedrop.io, Threema Web whose main use case is the direct
connection in same network environments and its significant benefits
regarding throughput.
=C2=A0
I agree this is= the most likely scenario where host candidates are actually useful: two we= b browsers doing pure data channel on a managed/complex network, and no coo= rdination between the network admin being and the app.

=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009bcd210576e271bd-- From nobody Thu Sep 27 16:21:28 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEF7130E7D for ; Thu, 27 Sep 2018 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikcxV2h8eqpt for ; Thu, 27 Sep 2018 16:21:05 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63A7130EEC for ; Thu, 27 Sep 2018 16:21:00 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id y3-v6so3094657ioc.5 for ; Thu, 27 Sep 2018 16:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C/ZNM7lRselywSWIJv3uPUKxLLEvYwL/Bby0bpTXuwM=; b=PEw6di1fT+YHr0gwFlBx5B8vZ53DKxYTj8teApxNHNN4Z4/B6LF8lfyYDU0o41Vpl+ 7SHjiUn2kbYd+twZRy6lFZExqyjlm53Sm5DY4hqnZtWa8jAOTKoGi2ykA+7RtVrzsQ+F rop3EtdtbVJ35IY2uCp3GyMElQa0+tUSKTPiHhTPUa0CXXmfxW/jui2RoRE5o/7FDUx4 Gq8VIUGOusV4JdmOlUxxUcRi1kjNUO3u2y99gkLZRCkPO/Jqn9JCIuyp9rDrFxSsYcIb Sp05i43ZE7wa3iLhD4KmYEXiL5U8LBtNPj9MMq5g4vEe6KtLz0MB2UlD10iPWmZxp98N QsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C/ZNM7lRselywSWIJv3uPUKxLLEvYwL/Bby0bpTXuwM=; b=jJX8cFeaoGoxk2PTcJiDjyTMF/ugNmM9hIfhGNDkWrecuIvJ7ay0isXqT4dlwi3UCz b9ZkU7T+q11LKNzwLTfkV4QJUN+g7sk7nqYjXqWBLiE3u3AE+wvvHKPLkx2u1qox0ODK 3PAg79VB4XAYq8ir64GWh0Q137De8vLCfCj1JOeztC+tdvrAp5Kpzj7tjT0wmcei5/uT O3gc24ErFeT6UnggsuKloLfyYEngfnfrF1lFRT1mH5OEF3MZG6Dy8nbSWuYatVCU4VqU QIAIUnlo2LT8WPh7PWYrUMh2bVRC81xcTK+B3Jo2yO7Wdlpzc1o3KiYxLwPiQsSrx1/U wj/A== X-Gm-Message-State: ABuFfoigsk/7+bf/aBv+rvFmMik62/RxFZqFwsw6bhU/vdF/nuJTmbfk iaIyk3XvelMQGRv3Mk7IB2+hpML4DjxzbvaWn4MXhg== X-Google-Smtp-Source: ACcGV609yGctu70nystnKnYZJaszxmv15771Lj8bINCY32kRhu2DHj2WdPe5q7kPFjEae50imdF/9Hm9yAVOrr/qEVE= X-Received: by 2002:a6b:39c3:: with SMTP id g186-v6mr10970700ioa.32.1538090459711; Thu, 27 Sep 2018 16:20:59 -0700 (PDT) MIME-Version: 1.0 References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> In-Reply-To: From: Justin Uberti Date: Thu, 27 Sep 2018 16:20:47 -0700 Message-ID: To: pthatcher=40google.com@dmarc.ietf.org Cc: Cullen Jennings , mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF , Christer Holmberg Content-Type: multipart/alternative; boundary="0000000000007c20230576e297d1" Archived-At: Subject: Re: [rtcweb] [Ice] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 23:21:07 -0000 --0000000000007c20230576e297d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Peter. Chrome's implementation is already closer to 8445 than 5245, so I don't see any issues associated with snapping this cluster to 8445 (aside from the work involved). On that topic, note that JSEP will need a few more changes than just the addition of the 8445 reference and note; the examples will have to be updated, as will the logic regarding generation of offers and answers and their parsing (to deal with the new ice-option). These changes will be modest but probably will need to be done by the authors. On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher wrote: > I'm late to the discussion, and reading through it, it seems that we have > a lot of back and forth without addressing Cullen's root issue. Let me s= ee > if I understand Cullen's root issue correctly. I think it's something li= ke: > > 1. Cisco has existing code that it wants to call "WebRTC 1.0 compliant" > without changing to be compliant with 8445. > > 2. Cisco has existing code that it wants to continue to interoperate wit= h > endpoints, especially Chrome, even as they make changes to become 8445 > compliant. And they don't want to have to test against old and new > versions. > > Cullen, is that accurate? > > > > OK, so some of my thoughts: > > 1. I don't think there is any interop risk here at all related to > timings. If you're worried about the drop in minimum check interval goin= g > from 20ms to 5ms, don't. Just because the spec allows for going that low > doesn't mean endpoints will. And if they do, they'll do it carefully. > Endpoints can and should still choose a value that works best regardless = of > the min in the spec. For example, Chrome is still using an interval of > 48ms (we're not in a rush to lower it, but we have non-browser endpoints > that do go lower). And if we roll out a lower value, it will be via > experiments or opt-ins and carefully tracked to make sure connectivity > rates don't drop. If any problem were found in practice, it would be > quickly reverted. > > 2. I don't think there is any interop risk here related to nomination > either. > Chrome's default behavior has never been compliant to any spec anyway, an= d > it's never been an issue. And like with ping intervals, any changes to > implementations will be done slowly and carefully. > > 3. I don't think it really matters to major implementations what the > dependency graph looks like. Whether some point to 5245 and others to 84= 45 > or if all of them point to 8445, it doesn't matter, implementations will > behave the same either way. Chrome, for example will adjust timings as > works well in practice (perhaps someday to below 20ms interval) regardles= s > of which RFCs point to 8445 and which point to 5245. If interop issues > ever do come up, then they can be fixed. And that has nothing to do with > which RFCs point to 5245 and which point to 8445. > > 5. You're going to need to test against different versions of different > browser no matter what the RFC references are. ICE timings and nominatio= ns > seem like the least of your testing problems. But on the flip side, Chro= me > (and I assume other browsers) have been very slow and careful when making > changes to the ICE code. > > 6. FlexICE should go a long way to putting the web app in control of the > ICE behavior. So if you are worried about what browsers will do with ICE= , > I suggest supporting the FlexICE effort. In fact, it's the result of you= r > proposal at TPAC in 2017 for wanting to have lower-level of control of > ICE.. If we get that into all the browsers, you won't have to worry any > more about any of this because you'll be in control (assuming you control > the web app). > > Altogether, I don't see any reason to not reference 8445 everywhere, at > least not any related to interop risk and web browsers. > > > > > > > > > > > > > > > > > > On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings wrote: > >> >> On Sep 7, 2018, at 1:25 AM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this >> change. These gratuitous changes, years after the implementation were >> coded, with no real benefit will ensure that we are not >> > and will not become compliant with the RFC. It's unlikely we will >> upgrade to the new ICE until it has real befits. >> >> The main reason we did 8445 was because people had identified issues wit= h >> 5245. The work was driven mostly by the WebRTC community, including >> yourself and the Chrome people (or, at least the Google people), and one= of >> the reason it took time to finalize 8445 was because you (among others) >> wanted to make sure we get things right (by making network measurements >> etc). Are you now saying all those changes bring no benefit? Did we all >> waste our time? >> >> >> Our testing, which we do not share, dig not indicate an improvement of >> connectivity rates. I did not see results from others that did. Some of = the >> early test results from others that drove this work were not reproducibl= e >> in our testing. The one thing I think most people did find is that the m= ore >> out of sync the pacing of the two agents was, the worse the connectivity >> was. But all of this is water under the bridge, we have old and new ice, >> people can use either. What we are talking about here is what is the >> minimum bar for WebRTC 1.0 >> >> >> > It is doubtful Justin will want to implement the 8445 mechanisms of >> supporting both new and old ICE. Instead, we will move to say "works >> with Browser X version Y or later." We have watched at W3C as it moved t= o >> be that unless chrome does it, it rare that it becomes a standard. >> > Right here I am watching how the stuff IETF defines will be less >> relevant than the issue of what chrome implements. >> >> What exactly would Justin have to change? >> >> >> >> For us, the largest part is having to test for both old and new - it=E2= =80=99s >> not easy to do good automated testing for ICE. >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > --0000000000007c20230576e297d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Peter. Chrome's implementation is already= closer to 8445 than 5245, so I don't see any issues associated with sn= apping this cluster to 8445 (aside from the work involved).

<= div>On that topic, note that JSEP will need a few more changes than just th= e addition of the 8445 reference and note; the examples will have to be upd= ated, as will the logic regarding generation of offers and answers and thei= r parsing (to deal with the new ice-option). These changes will be modest b= ut probably will need to be done by the authors.

On Wed, Sep 19, 2018 at 9:52 PM Peter Tha= tcher <pthatcher=3D40goog= le.com@dmarc.ietf.org> wrote:
I'm late to the discussion, and reading through= it, it seems that we have a lot of back and forth without addressing Culle= n's root issue.=C2=A0 Let me see if I understand Cullen's root issu= e correctly.=C2=A0 I think it's something like:

1.=C2=A0 Cisco has existing code that it wants to call "WebRTC 1.0 c= ompliant" without changing to be compliant with 8445.

2.=C2=A0 Cisco has existing code that it wants to continue to inte= roperate with endpoints, especially Chrome, even as they make changes to be= come 8445 compliant.=C2=A0 And they don't want to have to test against = old and new versions.=C2=A0=C2=A0

Cullen, is that = accurate?



OK, so som= e of my thoughts:

1.=C2=A0 I don't think there= is any interop risk here at all related to timings.=C2=A0 If you're wo= rried about the drop in minimum check interval going from 20ms to 5ms, don&= #39;t.=C2=A0 Just because the spec allows for going that low doesn't me= an endpoints will.=C2=A0 And if they do, they'll do it carefully.=C2=A0= Endpoints can and should still choose a value that works best regardless o= f the min in the spec.=C2=A0 For example, Chrome is still using an interval= of 48ms (we're not in a rush to lower it, but we have non-browser endp= oints that do go lower).=C2=A0 And if we roll out a lower value, it will be= via experiments or opt-ins and carefully tracked to make sure connectivity= rates don't drop.=C2=A0 If any problem were found in practice, it woul= d be quickly reverted.=C2=A0=C2=A0

2.=C2=A0 I don&= #39;t think there is any interop risk here related to nomination either.=C2= =A0=C2=A0
Chrome's default behavior has never been compliant = to any spec anyway, and it's never been an issue.=C2=A0 And like with p= ing intervals, any changes to implementations will be done slowly and caref= ully.=C2=A0=C2=A0

3.=C2=A0 I don't think it re= ally matters to major implementations what the dependency graph looks like.= =C2=A0 Whether some point to 5245 and others to 8445 or if all of them poin= t to 8445, it doesn't matter, implementations will behave the same eith= er way.=C2=A0 Chrome, for example will adjust timings as works well in prac= tice (perhaps someday to below 20ms interval) regardless of which RFCs poin= t to 8445 and which point to 5245.=C2=A0 If interop issues ever do come up,= then they can be fixed.=C2=A0 And that has nothing to do with which RFCs p= oint to 5245 and which point to 8445.

5.=C2=A0 You= 're going to need to test against different versions of different brows= er no matter what the RFC references are.=C2=A0 ICE timings and nominations= seem like the least of your testing problems.=C2=A0 But on the flip side, = Chrome (and I assume other browsers) have been very slow and careful when m= aking changes to the ICE code.

6.=C2=A0 FlexICE sh= ould go a long way to putting the web app in control of the ICE behavior.= =C2=A0 So if you are worried about what browsers will do with ICE, I sugges= t supporting the FlexICE effort.=C2=A0 In fact, it's the result of your= proposal at TPAC in 2017 for wanting to have lower-level of control of ICE= ..=C2=A0 If we get that into all the browsers, you won't have to worry = any more about any of this because you'll be in control (assuming you c= ontrol the web app).=C2=A0

Altogether, I don't= see any reason to not reference 8445 everywhere, at least not any related = to interop risk and web browsers.


<= br>




= =C2=A0









On Fri, Sep 7, 2018 at 9:37 AM Cullen Jenning= s <fluffy@iii.ca&= gt; wrote:

On Sep 7, 2018, at 1:25 AM, Christer Holmberg <christer.holmberg@ericsson= .com> wrote:

> Cisco has implemented stuff that is WebRTC 1.0 complian= t without this change.=C2=A0These gratuitous changes, y= ears after the implementation were coded, with no real benefit will ensure = that we are not
>=C2=A0and will not become compliant wit= h the RFC.=C2=A0It's unlikely we will upgrade to th= e new ICE until it has real befits.=C2=A0
<= div style=3D"margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
The main = reason we did 8445 was because people had identified issues with 5245. The = work was driven mostly by the WebRTC community, including yourself and the = Chrome people (or, at least the Google people), and one of the reason it to= ok time to finalize 8445 was because you (among others) wanted to make sure= we get things right (by making network measurements etc). Are you now sayi= ng all those changes bring no benefit? Did we all waste our time?

Our testing, which we do = not share, dig not indicate an improvement of connectivity rates. I did not= see results from others that did. Some of the early test results from othe= rs that drove this work were not reproducible in our testing. The one thing= I think most people did find is that the more out of sync the pacing of th= e two agents was, the worse the connectivity was. But all of this is water = under the bridge, we have old and new ice, people can use either. What we a= re talking about here is what is the minimum bar for WebRTC 1.0=C2=A0
=

<= /u>=C2=A0
> It is doub= tful Justin will want to implement the 8445 mechanisms of supporting both n= ew and old ICE.=C2=A0Instead, we will move to say "= ;works with Browser X version Y or later." We have watched at W3C as i= t moved to be that unless chrome does it, it rare that it becomes a standar= d. =C2=A0
>=C2= =A0Right here I am watching how the stuf= f IETF defines will be less relevant than the issue of what chrome implemen= ts.=C2=A0
=C2=A0<= /div>
What exactly would Justin have to chang= e?
=C2=A0

For us, the largest p= art is having to test for both old and new - it=E2=80=99s not easy to do go= od automated testing for ICE.=C2=A0
____________________________= ___________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
--0000000000007c20230576e297d1-- From nobody Thu Sep 27 17:50:10 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAAE130DD5 for ; Thu, 27 Sep 2018 17:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FRi7wPL2r6P for ; Thu, 27 Sep 2018 17:50:05 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001061.outbound.protection.outlook.com [40.92.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8A41286E3 for ; Thu, 27 Sep 2018 17:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L4xy+4hx/305A7dvhwWBTmq7+MzpHPuvbYr1tVkye6A=; b=byvriOgKoutFsImZcHyRT/RIhKvp3fHdXJ3eLblxml2wz7reNERWk0k0RCAmXzuzpaivMwgDSJr+2RL2OjDQjQYfK+Sg3qLPhfN/P3g06uEZh3Ywc6croYh11ZgBEhljbVvVMmJLt6CqLBymeQAfp2iFgROZ7ZpYss0hlB850xKVdP4C9VcxUtmEIt3LjLxgZ6FUcRWZF+vfR2Aune+oU35iC6QlFhm0wl0vwCVcR9tnpB733vy0NzN8N9it/N6W5/wGRAsE2DbpecNtTToqe/e30dIMSKNhWljtaCwtgYRTM7/b6GXF7woM9BW9eVU6wmRFFLxo8HXsL+TyGz1vpA== Received: from SN1NAM01FT024.eop-nam01.prod.protection.outlook.com (10.152.64.52) by SN1NAM01HT165.eop-nam01.prod.protection.outlook.com (10.152.64.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1185.13; Fri, 28 Sep 2018 00:50:02 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com (10.152.64.56) by SN1NAM01FT024.mail.protection.outlook.com (10.152.64.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1185.13 via Frontend Transport; Fri, 28 Sep 2018 00:50:02 +0000 Received: from CY4PR0101MB3095.prod.exchangelabs.com ([fe80::d588:9eb9:cc8c:2be5]) by CY4PR0101MB3095.prod.exchangelabs.com ([fe80::d588:9eb9:cc8c:2be5%5]) with mapi id 15.20.1143.022; Fri, 28 Sep 2018 00:50:02 +0000 From: Adam Sobieski To: Bernard Aboba , "ted.ietf@gmail.com" CC: RTCWeb IETF Thread-Topic: [rtcweb] WebRTC and Real-time Translation Thread-Index: AQHUVe1M2MPUNlozpUmfS3sPuCqXG6UDkYIAgAE+1yU= Date: Fri, 28 Sep 2018 00:50:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C6A66B213E7BD9A8A3C332C98705B2AC0DF9C30ECD24578FF83278BD5C5433CC; UpperCasedChecksum:EF0C4A67E96A41D70124D04B874DF9FED64F408144D9456EBB67AC290D93AC79; SizeAsReceived:7211; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [QZQAjesnfgdNFp7qi/VnUwm63D3upFLj] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT165; 6:IFitJkTOREkDUeaAq60QWkvPIIn3wzJwsaNAj9PiUi84ZQhpBE5A5r0HMD95/lgS2xVTJ68ocL7c6dgHbZL8IsCk0+LEaAv8hNS5Yd6MYM3YZT6CgKDzZ4SPlZyBzPLmQIMXVz9PZIQ4S6MqirnuGy4REY8Ov9GjQMO7R6EbXgpuXwagX8iB3GQAOgK8b5wECFhe/3kgoK8IhFzDe/aswXfITIY4jQQkiS3Q8MksQ5gk0ImonyRLj0Pl8TzBPe+IJ8d4nGyjcRmAS23ujyIh32j1Jb2uNZ9XYpTdlkKZZYB3u38BvyGpjZjD3Zx6GqvlcKy+V4uGVv3vvziHL4cvmGvs7brpT0gPEGiKzH0ZMcO8rJS6VQ8v2ugAeLKljfDcVGx4RvqPrwcA6cEEazoqmN6lhWp0qF4BjKn5C1PO3fVC/0h8XE2HPUIjgeu+W2SuGQgYEyOguAUHBiqlxKR9rw==; 5:CD49P4FK+EezPkdX3DVxS7XrJNMYAF+b/iw/vTFsMDmXXa1GX0k/Se9nBZCWHjwdBNAbS0x5bUT8vtNeqdG00yfTpOB24vgsmASDM6YMHZiwNj4JEU+WEib7hTt7t6emVoOfu5E/fK04Ez9OHepPsJcwpuvgEoUta1WKSsWDaac=; 7:BtzIEtt7Pxp4WXGbAF6Brmog5zASgBYE5NAQ43WLEZOtdv5US5iLW4rD6Mx7fgnA/epYi+iy6kHK+2v/KHPiC5n6wgmbRlwjKd30245b5/q8qnlIhtGQc+CJzXeQbEWtPrpRudaAuJ9Vcey9sjsIwstiMv+uo6LeFaXfEP3sS57NOU+tnzalcAdjbLoevo221G9fRJo2qbxUDW2FpDm222hyH0S/0pEYfx6fIMBFnYNXL0c0HkWzuwhYrN3TjmYf x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM01HT165; x-ms-traffictypediagnostic: SN1NAM01HT165: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM01HT165; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT165; x-forefront-prvs: 0809C12563 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(53546011)(54896002)(81156014)(76176011)(26005)(6346003)(25786009)(102836004)(33656002)(9686003)(74316002)(6506007)(6246003)(7696005)(104016004)(5660300001)(55016002)(6306002)(229853002)(6436002)(236005)(20460500001)(39060400002)(97736004)(8936002)(345774005)(53946003)(4326008)(2900100001)(105586002)(2501003)(106356001)(56003)(68736007)(110136005)(45080400002)(446003)(5250100002)(71190400001)(11346002)(83332001)(8676002)(606006)(575784001)(87572001)(476003)(486006)(966005)(73972006)(14454004)(99286004)(86362001)(82202002)(14444005)(256004)(71200400001)(34290500001)(15852004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT165; H:CY4PR0101MB3095.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=adamsobieski@hotmail.com; x-microsoft-antispam-message-info: 5NFBXBJCtB8iar7toRW5hkHPtB7ODJnAdDlWCpmA5Sh6Ew0z79L/S0On15KQPTb+/iBLVr+7UKJCMx7r8YKZJ0qke2wBFnWgUquTgPBSXQq0FdATngd+g6uNdel6pA2RJuaNLXjOmvV7HIhmG3B+nMJXXxpTDUfzd8yALbc8b6MFXGaW6YLoQctTwQARixEGuqcB9FcGj7Oo56ph48/xXOI0T/jEEryd7UIw22mDxw0= Content-Type: multipart/alternative; boundary="_000_CY4PR0101MB3095FC76C07E9FD6EB177506C5140CY4PR0101MB3095_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-Network-Message-Id: 163fa616-0fc1-4bd7-9aad-08d624dc5309 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: d4d70346-2c10-4f39-8c00-e767963926d9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2018 00:50:02.3606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT165 Archived-At: Subject: Re: [rtcweb] WebRTC and Real-time Translation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 00:50:09 -0000 --_000_CY4PR0101MB3095FC76C07E9FD6EB177506C5140CY4PR0101MB3095_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Bernard Aboba, Ted Hardie, Client-side Transcription and Translation With respect to client-side speech recognition, transcription, translation = and speech synthesis scenarios, we can consider GPGPU approaches. HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognition engine that le= verages modern GPU-based parallel computing architectures to realize accura= te real-time recognition with extremely large models.=94 In 2012, Professor= Ian Lane indicated that HYDRA performs 20x faster than other approaches [3= ]. Deep Speech [4][5][6] is a deep-learning-based approach to speech recogniti= on which =93outperforms previously published results on the widely studied = Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93h= andles challenging noisy environments better than widely used, state-of-the= -art commercial speech systems.=94 Articulatory synthesis can be accelerated by graphics cards [7]. WaveNet [8][9] is a deep generative model of raw audio waveforms including = speech audio. Facebook AI Research recently advanced machine translation [10], advancing = performance metrics by 10 BLEU points. With respect to desktop-based translation, vendors such as SYSTRAN [11] off= er desktop-based, server-based and cloud-based solutions. There are some desktop-based transcription and machine translation solution= s [12] and it is expected that real-time client-side solutions for transcri= ption and translation, processing speech audio, will exist in the upcoming = years, at least for desktop computing if not mobile computing. On-premises Transcription and Translation In addition to client-side solutions, on-premises solutions can deliver low= ered latency and enhanced privacy. Server-side and Cloud-based Transcription and Translation For a number of scenarios including mobile computing, server-side and cloud= -based transcription and translation services make sense. Major software vendors such as Amazon, Facebook, Google, IBM and Microsoft = offer priced cloud-based services which include speech recognition, machine= translation and speech synthesis. Post-text Speech Technology I am an advocate of post-text speech technologies. Speech-to-text is too lo= ssy. Information pertaining to prosody, intonation, emphases and pauses are= discarded in text output. Such information can be useful, for example info= rming machine translation components and services. In addition to speech-to= -SSML speech recognition and SSML-to-SSML machine translation scenarios, we= can envision new, intermediate data formats beyond SSML. The inputs and outputs of speech recognition, translation and speech synthe= sis components and services could be multiple formats =96 formats other tha= n text. API Sketch: Dataflow Graphs Sketches with respect to APIs include the declarative construction of dataf= low graphs which interconnect abstract components. Such APIs can abstract a= way whether the interconnectable components are client-side, on-prem, serve= r-side, third-party or cloud-based. Such APIs can abstract away whether the= interconnectable components are for free or priced to end-users. Considera= tions to such API include the data formats and stream specifications of com= ponents=92 various inputs and outputs to be interconnected. Dataflow graphs can be an intuitive abstraction layer, one which provides i= ntuitive and convenient programming while interconnecting arbitrary numbers= of components and services. Dataflow graphs can interconnect client-side a= nd remote speech recognition, translation and speech synthesis components a= s well as any other components which could reasonably be interconnected or = pipelined. When such dataflow graphs are prepared for activation, it is envisioned tha= t users will be provided with notifications, requests for permissions and o= ptions for payment. Potential IETF Work Items When such dataflow graphs are activated, it is envisioned that computer net= working protocols will be utilized to notify remote components or services = of proper data routings, e.g. daisy-chain or pipeline configurations, in a = secure manner. That is, there may be new protocols and computer networking topics with reg= ard to implementing the APIs for interconnecting WebRTC peers with speech r= ecognition, translation and speech synthesis components and services. Conclusion Tight WebRTC integration is important for envisioned efficient, low-latency= , high-performance, scalable real-time translation scenarios. While there exist some ad hoc approaches to providing real-time translation= with WebRTC, standardizing new APIs and protocols can convenience develope= rs, convenience end users, and create new markets with respect to real-time= translation scenarios. Thank you for considering adding real-time translation to the use cases for= a next version of WebRTC. I look forward to any discussion on these topics= . References [1] http://www.cs.cmu.edu/~ianlane/hydra/ [2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY [3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg [4] https://arxiv.org/abs/1412.5567 [5] https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu= -accelerated-deep-learning/ [6] https://github.com/mozilla/DeepSpeech [7] https://open.library.ubc.ca/media/stream/pdf/24/1.0348751/3 [8] https://deepmind.com/blog/wavenet-generative-model-raw-audio/ [9] https://devblogs.nvidia.com/nv-wavenet-gpu-speech-synthesis/ [10] https://www.forbes.com/sites/williamfalcon/2018/09/01/facebook-ai-just= -set-a-new-record-in-translation-and-why-it-matters/#205b9e5b3124 [11] https://store.systran.us/lp/storeSystran?Langue=3Den_US [12] https://en.wikipedia.org/wiki/Comparison_of_machine_translation_applic= ations From: Bernard Aboba Sent: Thursday, September 27, 2018 12:58 AM Subject: Re: [rtcweb] WebRTC and Real-time Translation One of the key questions for "Next Version Use Cases" is what WebRTC-defici= encies are preventing these use cases from being satisfactorily implemented= today. For example, speech transcription cloud services have been implemented over= Websockets, where a snippet of speech is uploaded, and a transcription is = provided in reply. The latency is satisfactory for some uses cases. Improvements can perhaps be made by sending an audio stream and receiving a= transcription via the data channel, but this is also within the capabiliti= es of the existing RTCWEB protocols and WebRTC-PC API. What seems to differentiate *next version* scenarios are situations where t= he processing is best done on the device, in order to lower latency or enha= nce privacy. On-device processing brings in discussion of workers/worklets= , access to raw audio/video, etc. However, so far I'm not aware of on-devi= ce implementations of transcription or translation. On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski > wrote: IETF RTCWEB Working Group, Greetings. I opened an issue on WebRTC and Real-time Translation at the Git= Hub repository for WebRTC version next use cases (https://github.com/w3c/we= brtc-nv-use-cases/issues/2). Introduction Real-time translation is both an interesting and important use case for a n= ext version of WebRTC. Speech Recognition, Translation and Speech Synthesis Approaches to real-time speech-to-speech machine translation include those = which interconnect speech recognition, translation and speech synthesis com= ponents and services. In that regard, we can consider client-side, on-prem,= server-side, third-party and cloud-based components and services. In that = regard, we can also consider both free and priced components and services. We can envision post-text speech technology and machine translation compone= nts and services. Speech recognition need not output to text; we can consid= er speech-to-SSML. Machine translation need not input from nor output to te= xt; we can consider SSML-to-SSML machine translation. Components and servic= es may provide various options with respect to their input and output data = formats. Connecting Components and Services by Constructing Graphs We can consider APIs which facilitate the construction of graphs which repr= esent the flow of data between components and services. As these graphs are= constructed, users could be apprised of relevant notifications, requests f= or permissions and options for payments. As these constructed graphs are ac= tivated, a number of protocols could be utilized to interconnect the compon= ents and services which, together, provide users with real-time translation= . Hyperlinks WebRTC Translator Demo Real Time Translation in WebRTC Best regards, Adam Sobieski http://www.phoster.com/contents/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_CY4PR0101MB3095FC76C07E9FD6EB177506C5140CY4PR0101MB3095_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Bernard = Aboba,
Ted Hardie,

Client-side Transcription and Translation=

With respect to client-side speech recognition, transcripti= on, translation and speech synthesis scenarios, we can consider GPGPU appro= aches.

HYDRA [1][2] is a =93hybrid GPU/CPU-based speech recognitio= n engine that leverages modern GPU-based parallel computing architectures t= o realize accurate real-time recognition with extremely large models.=94 In 2012, Professor Ian Lane indicated that HYDR= A performs 20x faster than other approaches [3].

Deep Speech [4][5][6] is a deep-learning-based approach to = speech recognition which =93outperforms previously published results on the= widely studied Switchboard Hub5'00, achieving 16.0% error on the full test set=94 and =93handles challenging noisy envir= onments better than widely used, state-of-the-art commercial speech systems= .=94

Articulatory synthesis can be accelerated by graphics cards= [7].

WaveNet [8][9] is a deep generative model of raw audio wave= forms including speech audio.

Facebook AI Research recently advanced machine translation = [10], advancing performance metrics by 10 BLEU points.

With respect to desktop-based translation, vendors such as = SYSTRAN [11] offer desktop-based, server-based and cloud-based solutions.

There are some desktop-based transcription and machine tran= slation solutions [12] and it is expected that real-time client-side soluti= ons for transcription and translation, processing speech audio, will exist in the upcoming years, at least for desktop compu= ting if not mobile computing.

On-premises Transcription and Translation=

In addition to client-side solutions, on-premises solutions= can deliver lowered latency and enhanced privacy.

Server-side and Cloud-based Transcription and Translation

For a number of scenarios including mobile computing, serve= r-side and cloud-based transcription and translation services make sense.

Major software vendors such as Amazon, Facebook, Google, IB= M and Microsoft offer priced cloud-based services which include speech reco= gnition, machine translation and speech synthesis.

Post-text Speech Technology

I am an advocate of post-text speech technologies. Speech-t= o-text is too lossy. Information pertaining to prosody, intonation, emphase= s and pauses are discarded in text output. Such information can be useful, for example informing machine translation compo= nents and services. In addition to speech-to-SSML speech recognition and SS= ML-to-SSML machine translation scenarios, we can envision new, intermediate= data formats beyond SSML.

The inputs and outputs of speech recognition, translation a= nd speech synthesis components and services could be multiple formats =96 f= ormats other than text.

API Sketch: Dataflow Graphs

Sketches with respect to APIs include the declarative const= ruction of dataflow graphs which interconnect abstract components. Such API= s can abstract away whether the interconnectable components are client-side, on-prem, server-side, third-party or cloud-bas= ed. Such APIs can abstract away whether the interconnectable components are= for free or priced to end-users. Considerations to such API include the da= ta formats and stream specifications of components=92 various inputs and outputs to be interconnected.

Dataflow graphs can be an intuitive abstraction layer, one = which provides intuitive and convenient programming while interconnecting a= rbitrary numbers of components and services. Dataflow graphs can interconnect client-side and remote speech recognition= , translation and speech synthesis components as well as any other componen= ts which could reasonably be interconnected or pipelined.=

When such dataflow graphs are prepared for activation, it i= s envisioned that users will be provided with notifications, requests for p= ermissions and options for payment.

Potential IETF Work Items

When such dataflow graphs are activated, it is envisioned t= hat computer networking protocols will be utilized to notify remote compone= nts or services of proper data routings, e.g. daisy-chain or pipeline configurations, in a secure manner.

That is, there may be new protocols and computer networking= topics with regard to implementing the APIs for interconnecting WebRTC pee= rs with speech recognition, translation and speech synthesis components and services.

Conclusion

Tight WebRTC integration is important for envisioned effici= ent, low-latency, high-performance, scalable real-time translation scenario= s.

While there exist some ad hoc approaches to providing real-= time translation with WebRTC, standardizing new APIs and protocols can conv= enience developers, convenience end users, and create new markets with respect to real-time translation scenarios.

Thank you for considering adding real-time translation to t= he use cases for a next version of WebRTC. I look forward to any discussion= on these topics.

References

[1] = http://www.cs.cmu.edu/~ianlane/hydra/<= /a>
[2] https://www.youtube.com/watch?v=3D73rQ0lRx2aY<= /a>
[3] https://www.youtube.com/watch?v=3DY7Jlj7QYrcg<= /a>
[4] https://arxiv.org/abs/1412.5567
[5] = https://devblogs.nvidia.com/deep-speech-accurate-speech-recognition-gpu-acc= elerated-deep-learning/
[6] https://github.com/mozilla/DeepSpeech
[7] https://open.library.ubc.ca/media/strea= m/pdf/24/1.0348751/3
[8] https://deepmind.com/blog/wavenet-gen= erative-model-raw-audio/
[9] https://devblogs.nvidia.com/nv-wavenet= -gpu-speech-synthesis/
[10] https://www.forbes.com/sites/williamf= alcon/2018/09/01/facebook-ai-just-set-a-new-record-in-translation-and-why-i= t-matters/#205b9e5b3124
[11] https://store.systran.us/lp/storeSystran?L= angue=3Den_US
[12] https://en.wikipedia.= org/wiki/Comparison_of_machine_translation_applications

 

 

From: Bernard Aboba
Sent: Thursday, September 27, 2018 12:58 AM
Subject: Re: [rtcweb] WebRTC and Real-time Translation

 

One of the key questions for "Next Version Use = Cases" is what WebRTC-deficiencies are preventing these use cases from= being satisfactorily implemented today. 

 

For example, speech transcription cloud services hav= e been implemented over Websockets, where a snippet of speech is uploaded, = and a transcription is provided in reply.  The latency is satisfactory= for some uses cases. 

Improvements can perhaps be made by sending an audio= stream and receiving a transcription via the data channel, but this is als= o within the capabilities of the existing RTCWEB protocols and WebRTC-PC AP= I. 

 

What seems to differentiate *next version* scenarios= are situations where the processing is best done on the device, in order t= o lower latency or enhance privacy.  On-device processing brings in di= scussion of workers/worklets, access to raw audio/video, etc.  However, so far I'm not aware of on-device imp= lementations of transcription or translation.

 

On Wed, Sep 26, 2018 at 6:10 PM Adam Sobieski <adamsobieski@hotmail.com> = wrote:

IETF RTCWEB Working Group,

 

Greetings. I opened an issue on WebRTC and Real-time Translation at the GitHub repository for WebRTC= version next use cases (https://github.com/w3c/webrtc-nv-use-cases/= issues/2).

 

Introdu= ction

Real-tim= e translation is both an interesting and important use case for a next vers= ion of WebRTC.

Speech = Recognition, Translation and Speech Synthesis

Approach= es to real-time speech-to-speech machine translation include those which in= terconnect speech recognition, translation and speech synthesis components and services. In that regard, we can consider = client-side, on-prem, server-side, third-party and cloud-based components a= nd services. In that regard, we can also consider both free and priced comp= onents and services.

We can e= nvision Connect= ing Components and Services by Constructing Graphs

We can c= onsider APIs which facilitate the construction of graphs which represent th= e flow of data between components and services. As these graphs are constructed, users could be apprised of relevant notif= ications, requests for permissions and options for payments. As these const= ructed graphs are activated, a number of protocols could be utilized to int= erconnect the components and services which, together, provide users with real-time translation.

Hyperli= nks

WebRTC Translator Demo
Real Time Translation in WebRTC

 

 

Best regards,

Adam Sobieski

htt= p://www.phoster.com/contents/

 

________________________= _______________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

 

--_000_CY4PR0101MB3095FC76C07E9FD6EB177506C5140CY4PR0101MB3095_-- From nobody Thu Sep 27 22:02:00 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97E12F1AB for ; Thu, 27 Sep 2018 22:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmuVy2EyXzgh for ; Thu, 27 Sep 2018 22:01:56 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC467130DC3 for ; Thu, 27 Sep 2018 22:01:55 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id r191-v6so3994917lff.2 for ; Thu, 27 Sep 2018 22:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PpXq8AVVJbq2bDBCTUt1uzF7PYWeoh/tnufhbz10y70=; b=Im5+zwoQ3uDrTWhcSxh+Oyf7kGTqdGy6qs1m1JoeDH0TRVsArkk67dVGAE/RiWxFbX c3xNmO6kdP2K1PhULoL4LW5AP8uvJF8Gy6NbgTMwhHgMoWPSg9eoe5nS5a4YBXBsNkDg NckqaaapF5ZY9d6SyFKYNkM3wl8Ejz9j/Lu8VlSD6CfAYVf48Gb77tZmfgeLP4tGEZDH Y4ovURxSGdZKIKBwYu00KxE4LjiJoeaV1HxVjE8fp3SD1AzAh6oKkq+WCmDuTdhx/5vS +fzMGqcSc7UfmJKXqlKnkCwh529pP4GOOgdFPNnfMMIAoWpEEugfOLC1+nQL5AsI70Rm xZow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PpXq8AVVJbq2bDBCTUt1uzF7PYWeoh/tnufhbz10y70=; b=XejTqXaI61DRW0GsBmnMdohFoA0kPG3oHmW6b0FpDeSRiBSGZmb7qMbdxPMDwBwcgM OP3eLxYZY8XF24aAl+O71YlOXSlFd6list3uQ+CfcmK8ljSSovOSVj6ABjb3UNO9Vts9 8sdX2U63iRhpJfTImaza4Fdz+/TERuIfetOX5gloVS7mdlhY1K8uHMS/Hb0wWdZX998q 6z0Y48LRqzO7vN4icAQin9RGBiHPAjfRrDEWDSt/qh7ntDYtN8dOYCIORW/7sL+bHoVN JGMQ4YjmHhGDDABwwaxCmQXv6koPad/rPWigBo7YxGygSvsJfEP1VTPQG1F+IEU0FWlN WYGQ== X-Gm-Message-State: ABuFfoihOWn+3LErR3ydquSvmwABAIH4dzOaffo6UL6qCwlhqBNjHrob NUC9uocU2qmMhInZ/6/kvhcLhI4uZALMAtztp9wGQQ== X-Google-Smtp-Source: ACcGV60kACnKZdEAudswf7Qz3M0C9Fa4DChCmJY1OgcpNKiHTGjBxIRQWxtF/nJwB+gkAFk8LXvvwHby5FyUdi/ABUQ= X-Received: by 2002:a19:1346:: with SMTP id j67-v6mr9158512lfi.93.1538110913463; Thu, 27 Sep 2018 22:01:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: youenn fablet Date: Thu, 27 Sep 2018 22:01:40 -0700 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000009f495a0576e75a01" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 05:01:59 -0000 --0000000000009f495a0576e75a01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI, we are tracking the feedback from this thread and last IETF meeting at https://github.com/youennf/mdns-ice-candidates/issues. Y Le jeu. 27 sept. 2018 =C3=A0 16:10, Justin Uberti a = =C3=A9crit : > I suggest that we hold off on assessing what this might mean for data > channel and related applications until we have data from browsers showing > the actual connectivity/traffic impact of mDNS. > > We should have initial data on this topic from Chrome by EOY. > > On Mon, Sep 24, 2018 at 10:14 PM youenn fablet wrote: > >> >> >>> Perhaps its feasible for those use cases where the administrator is >>> already aware of the software but definitely not for small applications >>> such as sharedrop.io, Threema Web whose main use case is the direct >>> connection in same network environments and its significant benefits >>> regarding throughput. >>> >> >> I agree this is the most likely scenario where host candidates are >> actually useful: two web browsers doing pure data channel on a >> managed/complex network, and no coordination between the network admin >> being and the app. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --0000000000009f495a0576e75a01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI, we are tracking the feedback from this thread an= d last IETF meeting at=C2=A0https://github.com/youennf/mdns-ice-candidates/issues.
=C2=A0 =C2=A0Y

I suggest tha= t we hold off on assessing what this might mean for data channel and relate= d applications until we have data from browsers showing the actual connecti= vity/traffic impact of mDNS.

We should have initial data= on this topic from Chrome by EOY.

On Mon, Sep 24, 2018 at= 10:14 PM youenn fablet <youennf@gmail.com> wrote:


Perhaps its feasible for those use cases where the administrator is
already aware of the software but definitely not for small applications
such as sharedrop.io, Threema Web whose main use case is the direct
connection in same network environments and its significant benefits
regarding throughput.
=C2=A0
I agree this is= the most likely scenario where host candidates are actually useful: two we= b browsers doing pure data channel on a managed/complex network, and no coo= rdination between the network admin being and the app.

=
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000009f495a0576e75a01-- From nobody Fri Sep 28 04:05:30 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D769130E1A for ; Fri, 28 Sep 2018 04:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQnKjYXV4TBf for ; Fri, 28 Sep 2018 04:05:26 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 C4389130E17 for ; Fri, 28 Sep 2018 04:05:25 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id t11-v6so7786945edq.11 for ; Fri, 28 Sep 2018 04:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AjSp6XIAgUVQ3KA/08OZ4ML7U+deYO8+BfDUS+mI2V8=; b=MNFHhkJtyqUz2z07KoJESuuasWZ2cGK2i81NsRYpMbuRoh9uhpTILHGPWeoOzKUTdb 4bMFymCyhrcIgzdnqQfkof/dHReHnt0jnkmXLEkf6HIj5XeyXnyTVINZdtwc5A94SGgq QQBVGclVLZhLQczEflDbCM0hUSefyHhvCO1zj4ISbU3fi5wZFo6p0ObKOBK/X/05+KWC nEq6Myzfja/ju+LMR8nuWyL5cNvXb0/yK8njiSYXyTkWCP+N3A3UQ/6Ci8gMhwkKNphv u9VgPF8bi02IEb7+T+uwCO8cwqNn+FepBRmAfA6mBzGyGc1JJ/Wqwfdb02LHb7QMKEPu YsIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AjSp6XIAgUVQ3KA/08OZ4ML7U+deYO8+BfDUS+mI2V8=; b=BemTLW0efPtE1gJovAxZbH5BKQFRiAdFvHAlNmxkWr0QwSN8Lg+vXw0bs8wQoFuKrM Kr6UXiSqGienY4GdabvJEALQplEv85o5YQA3iz7Xsj0+/u2COTbBYTpO1oBijf9+yzSX EEORwRVYesQ+03Bf9jcWNiw/7/r1FbXb4xvuE2ZvOQlYO1boEMD6xC/abePEnwC5xcEY /oKJpv+KvsYtx6yzN0Wt3aLg30WiiFl3+t8VqHiLob+A70VhdXEFDTR07TQQPV39AMec yQ0iOwoFsVAbLe3PhwcRk5l+/dufePzoU0xl4duO+4U5NrtdU0P3zS0THKkRlfi7FXf4 0W7g== X-Gm-Message-State: ABuFfohFDhF+BuT/N0+qLSa1edWbHfEDa1ip0uVcT3HWMvLrj/FjhJGL mN8TQOVHiiqNK29qgdFhHMW0780l X-Google-Smtp-Source: ACcGV61We3sUGRUC/KUZ6rnRRj/sC6TIeEhHILlU0fbqXIM/aziZsYWzhAwiCKuk8qNCpP3FKzjEkA== X-Received: by 2002:aa7:d615:: with SMTP id c21-v6mr2140741edr.286.1538132723533; Fri, 28 Sep 2018 04:05:23 -0700 (PDT) Received: from [192.168.11.149] ([185.41.76.142]) by smtp.gmail.com with ESMTPSA id x22-v6sm2084170edb.8.2018.09.28.04.05.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Sep 2018 04:05:22 -0700 (PDT) To: RTCWeb IETF References: From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt Message-ID: <95fbba91-b573-fbe4-3e3d-e9e2c4245fbd@gmail.com> Date: Fri, 28 Sep 2018 13:06:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 11:05:28 -0000 How will that data be gathered? Is anyone else gathering data? Safari? Cheers Lennart On 28.09.18 01:10, Justin Uberti wrote: > I suggest that we hold off on assessing what this might mean for data > channel and related applications until we have data from browsers showing > the actual connectivity/traffic impact of mDNS. > > We should have initial data on this topic from Chrome by EOY. > > On Mon, Sep 24, 2018 at 10:14 PM youenn fablet wrote: > >> >> >>> Perhaps its feasible for those use cases where the administrator is >>> already aware of the software but definitely not for small applications >>> such as sharedrop.io, Threema Web whose main use case is the direct >>> connection in same network environments and its significant benefits >>> regarding throughput. >>> >> >> I agree this is the most likely scenario where host candidates are >> actually useful: two web browsers doing pure data channel on a >> managed/complex network, and no coordination between the network admin >> being and the app. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > From nobody Fri Sep 28 23:16:17 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AF7130DC5 for ; Fri, 28 Sep 2018 23:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yd04IdM-2OqX for ; Fri, 28 Sep 2018 23:16:13 -0700 (PDT) Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 6BF45124C04 for ; Fri, 28 Sep 2018 23:16:13 -0700 (PDT) Received: by mail-it1-x134.google.com with SMTP id 74-v6so5258260itw.1 for ; Fri, 28 Sep 2018 23:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/3jYRWKk7KMDeexkYOvHmZYBxDsOPJ7PBonU6ic7ZqA=; b=mLbM3nCkGb56GudW26jgNtQyIgmjaO2sSjznRPJyPyGuwYEWnjaOKmVnhdPHRbPFFq 8mojH25eVlAw1oSZvLFYg56pSCRIePP7QmFbsfKduWwjFHPR9Dsh9AWuhoCOZY+9bIsB 3t+Rc7BtYEuM6/Awo4PgQ85V+COGPcUD2Tv4Op9q/2dlEdh5z29F/xm8vVyYm2lXWLmC Pq06tnsmXcW7CBYNbNvSYx/WYJ5KaXuMYmmFOeW+Hb+DMIpSihi+g6oitvWVxeo7AJ+z HmHtB9EI/adtLM2K4IIVVKzhAJ5mqTnHsRI6Z6vnRgh1OQYBcUjn4Dn6AUXsbvX3EmGN pqow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/3jYRWKk7KMDeexkYOvHmZYBxDsOPJ7PBonU6ic7ZqA=; b=bGkr8HN7PnVIwuIRZ/+RH/AqYaoS8+9uzCjvXr9xiygq2DP1REOEe95v2O2NEyA7z3 NwZDhZCKkVSZi5FMwV85x8jNhTOqK5cGzwVhSdIR9QQ4BzZw/3jTA97IuPUCeZSVPs0A LYntzd2T5xPrTLqZ2fSV2C2FOCcm6L0HoGQIOlkyU8615ztuWsZ+N3pw3NM+lDzx60Or NbnYuJUI7eRdoNXYmSgJH/NVmlGKi7jmzMNuJfkMsDwrvHvgOdJSveLOFLNTA7lyOJyh RkiftHrMilmPWMBMA/zFIZ40riTr4cWwvmZ+/+bCGmeMtwEJX7MNIHAZA9XzFzywZe+O NLTg== X-Gm-Message-State: ABuFfoiqIt3AixQXpwmraO8NaVnd+gp5VLNjvRYvxCvCPrUP/mDssUzN Dvnj5cxAxIzEi2+yjIfN1CGciXVXZ2CDuSzN39pFNA== X-Google-Smtp-Source: ACcGV60xiK1STwrD0oQw95OJItkVUeWfnQVyNGV/Uy5OmAHp9ZzglzKgKbc7W3BiFNmaa7ZHd5HCq7YFtodZ99JGrBw= X-Received: by 2002:a24:d1c5:: with SMTP id w188-v6mr3658891itg.99.1538201772340; Fri, 28 Sep 2018 23:16:12 -0700 (PDT) MIME-Version: 1.0 References: <95fbba91-b573-fbe4-3e3d-e9e2c4245fbd@gmail.com> In-Reply-To: <95fbba91-b573-fbe4-3e3d-e9e2c4245fbd@gmail.com> From: Justin Uberti Date: Fri, 28 Sep 2018 23:16:00 -0700 Message-ID: To: Lennart Grahl Cc: RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000003c51560576fc8281" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 06:16:16 -0000 --0000000000003c51560576fc8281 Content-Type: text/plain; charset="UTF-8" We will turn it on for N% of Chrome instances and observe the connection success rate and setup time versus control. On Fri, Sep 28, 2018 at 4:05 AM Lennart Grahl wrote: > How will that data be gathered? Is anyone else gathering data? Safari? > > Cheers > Lennart > > On 28.09.18 01:10, Justin Uberti wrote: > > I suggest that we hold off on assessing what this might mean for data > > channel and related applications until we have data from browsers showing > > the actual connectivity/traffic impact of mDNS. > > > > We should have initial data on this topic from Chrome by EOY. > > > > On Mon, Sep 24, 2018 at 10:14 PM youenn fablet > wrote: > > > >> > >> > >>> Perhaps its feasible for those use cases where the administrator is > >>> already aware of the software but definitely not for small applications > >>> such as sharedrop.io, Threema Web whose main use case is the direct > >>> connection in same network environments and its significant benefits > >>> regarding throughput. > >>> > >> > >> I agree this is the most likely scenario where host candidates are > >> actually useful: two web browsers doing pure data channel on a > >> managed/complex network, and no coordination between the network admin > >> being and the app. > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000003c51560576fc8281 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We will turn it on for N% of Chrome instances and observe = the connection success rate and setup time versus control.

On Fri, Sep 28, 2018 at 4:05 AM Lennar= t Grahl <le= nnart.grahl@gmail.com> wrote:
youennf@gmail.com> wrote:
>
>>
>>
>>> Perhaps its feasible for those use cases where the administrat= or is
>>> already aware of the software but definitely not for small app= lications
>>> such as sharedrop.io, Threema Web whose main use case is the dir= ect
>>> connection in same network environments and its significant be= nefits
>>> regarding throughput.
>>>
>>
>> I agree this is the most likely scenario where host candidates are=
>> actually useful: two web browsers doing pure data channel on a
>> managed/complex network, and no coordination between the network a= dmin
>> being and the app.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.o= rg
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000003c51560576fc8281-- From nobody Sat Sep 29 03:25:36 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16DA130E08 for ; Sat, 29 Sep 2018 03:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7UrxiSabAni for ; Sat, 29 Sep 2018 03:25:34 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 D0CA4130DFD for ; Sat, 29 Sep 2018 03:25:33 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id j8-v6so8834559wrw.5 for ; Sat, 29 Sep 2018 03:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:from:openpgp:autocrypt:to:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5xsysozod5YidSXoRpBcshd29MtW9MRCmP1S71nnkNo=; b=et+6qur6xVzymZLjTqaYBSbYxax/TpDQrypYTrKkWwENvT+ycbtJmnkHNa7tXl/UqX 1pXcE4T5fI1EG33JpPWdEE7Y7KsvW/iIaQ355e2cwhQERcFCxNUCgQ+lOJVxQEy8948F QQpGHpYLFpX6/b8MFqk2m0HfupQ9NG//WMh6LOqlZI/V7dvI6IKsZmxdfeP51R0FEv32 lI+PSnzQwB34PT39wr52ugh05Yzcmv2q957e5tAXglqPKYfOq6B+B5wb0eFOxrs9y4tr pdKWWn5ue1wwiEqUhFGTkSEgWYNnJnnbVqkocljRofAxnotcaAYlbfGeKzD8sTt/xeTb eXBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:from:openpgp:autocrypt:to :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5xsysozod5YidSXoRpBcshd29MtW9MRCmP1S71nnkNo=; b=rStWMY/qfNq0B7MeVirv/bbsE9iWjc7YARrBkkarALau7G4o0ziR3I3n09OU452BaK O+Jy+VQ1X+m5sGTIjpH78t6p9OooTVS25Jba88ZglBULpwuDicumI3TYZq4GnWGZMlJD csYZ2uXgaj9EVY/AOin7y9U3rDSURjAJg2SG0nt3Pk7iWQ3VgiyAnuZfc4J8T0e1DAp6 bU4fDhBWPNk8ez19+9/XBzQ5JnkKb5P9MY2JwDOeYxR6pu+mtP21P2CoRLIoPXfIultw gYga/zAxlsAkyf1e7h9ujUFr4tWBD2kfVAfqK68pS+QtDrF1yXaafi70I2oYpaLOclrH sPEg== X-Gm-Message-State: ABuFfogjuv0RSX8bvSPkKrrL6p9+5/DvuKw8Kxp0BnJHOEaFDFywlC0x wR1abWKkIAg/ve6lQvPZq71u2S69 X-Google-Smtp-Source: ACcGV62Y4a/EwTskxUW2QhLYz72Y1m1kHppk7a0w4NtVCr0OGpZxtY13nlfPdnC0xnwQ30AWZprc7g== X-Received: by 2002:adf:e50b:: with SMTP id j11-v6mr1566586wrm.111.1538216731811; Sat, 29 Sep 2018 03:25:31 -0700 (PDT) Received: from [10.26.2.1] ([31.10.151.172]) by smtp.gmail.com with ESMTPSA id v6-v6sm3296547wmc.43.2018.09.29.03.25.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Sep 2018 03:25:31 -0700 (PDT) References: <95fbba91-b573-fbe4-3e3d-e9e2c4245fbd@gmail.com> From: Lennart Grahl Openpgp: preference=signencrypt Autocrypt: addr=lennart.grahl@gmail.com; prefer-encrypt=mutual; keydata= xsBNBFMHjy4BCADZR/nHk6jzDsEA2+dPG13NiXyBl34TtChDsZekZyO5jBgwslLgHVksQxlS 79n1lvVH0MxcI8SFifwLAAIjMfukNLGPAjEyJEQhQVpfXxkJXyZgncM2Wq+nlVCDZTiZLg/E 6jJP1zx9vB7sf5dWaB/Dt0YDHLM86EcDChQur9lrJk9K0Jiwt27Oo3B4FFfIOaVNUXgnRPbr Vw1/+O2jLg87Fsib9LP7Ghyv0Z2/VV7wJ4NLsLmIu60vcZVDYDOvcQRH4FZ76VBvlmlO+2TL 5L6yZLGgXS9GZyF3QXKAwhYqu5ouWEOUgXHch5deryjbENanimj4ntZQmF1nkxSZayk9ABEB AAHNJ0xlbm5hcnQgR3JhaGwgPGxlbm5hcnQuZ3JhaGxAZ21haWwuY29tPsLAfwQTAQIAKQUC UwePLgIbIwUJCWYBgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEPmPvtEEgqumkk0H /2dMGPa9VmgR0kmr2inGODWuCy4WXNUxeEMfY/Hob/8Ou50os6iK35TQI9WtvvlAq23aIvoJ +1OjnqekgKmavPoQ0Uf1h2LegiQNKpDGC6/S33SLitQoQyELyJCU5Ato9lIL0AzpLvr+8UaF plWbPB4Z0GfZGBQSyp0Dmdeb00sld378m9qXHByJfHjPGiDFY+el1talbCuxS87+SvwIvM05 5m1/ceJbZDjx3trvgzbSQOHMT82/Hva7cSyVAch7mJc/lIq2Q0hjoZlD9nqS6gVJ9PQnEW8z dAXXVvBoy9DtomH18jimq+xUxeBwiFRB64gZx3Yyo1CKgULzeWaQ/qfOwE0EUwePLgEIAKP+ Dw5Ow5QuITKcI+ooXZAOBCBOitdsAGrGAEORjv1VyYU1jvjNb07UlRWmpjtaZsQoC2DwfEJy OaBphhErkOVEHCvetfBq8aJ718on4A49XwyQZeyh521BvLQUj0VY5D1iTYzgNVr4Ic39duH/ 00b489Wf9sM7TwzONJOCR5pSKUzYfGUIfQIJRc4tbzOM+bzSknLwbYAWRraOstbRjf2+V3pf 46mzv8tteLnsMm91qshFUwiBfeMNZiKAM3eid80ghlEbQo5J07FOrqK1GxqMi8LQT/oA5lpu +BB6UzGP5nQ5fip95zAq3vu+Iasz1DWj6F1HkHDEHfdtVpTAN70AEQEAAcLAZQQYAQIADwUC UwePLgIbDAUJCWYBgAAKCRD5j77RBIKrpihiCACQq7ARCPSzDrtUcq3uTdP+fMHp8YCYD4UD fdt3vcw4a5JESaknUcWi7CbQrdcLT7iIFYa3pk5I8w4n2lH29uUTWwt9boDtdYkBY5a4Rg+m Z9ndsLh0fHdZM6BXv/6gWMMdGbV5+xcV0FDcXZIlHLZIriDgeZQR3cDEa9lFWUYrI9KKmdoq ngaND7jPZaMCyvn9VDOAGBWxg49gQV/x1d+DiIyMbF9J+ya4YqaSZtu2y/H03eVCawmI6SMH UzdOo+Yqen3Udcdur0KnWMUOP3FIdjgxaPoIEKfFTBy7n8rlzrrTzyrv5Gouusxj0JHMwvuh ixK1bmVy/XYqoG0TVwBt To: RTCWeb IETF Message-ID: Date: Sat, 29 Sep 2018 12:25:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2018 10:25:36 -0000 I would suggest observing the connection success rate of * host-to-host candidate pairs only, * without getUserMedia (on the local side), and * only if the remote peer also takes part in the mDNS test (should be easy to recognise by looking at the remote's host candidates but doesn't work if the remote peer uses getUserMedia... perhaps signal it via an SDP attribute) in comparison to as it is now. All of the above conditions should be required for reporting results because this is the case that we want to observe. Cheers Lennart On 29.09.2018 08:16, Justin Uberti wrote: > We will turn it on for N% of Chrome instances and observe the connection > success rate and setup time versus control. > > On Fri, Sep 28, 2018 at 4:05 AM Lennart Grahl > wrote: > >> How will that data be gathered? Is anyone else gathering data? Safari? >> >> Cheers >> Lennart >> >> On 28.09.18 01:10, Justin Uberti wrote: >>> I suggest that we hold off on assessing what this might mean for data >>> channel and related applications until we have data from browsers showing >>> the actual connectivity/traffic impact of mDNS. >>> >>> We should have initial data on this topic from Chrome by EOY. >>> >>> On Mon, Sep 24, 2018 at 10:14 PM youenn fablet >> wrote: >>> >>>> >>>> >>>>> Perhaps its feasible for those use cases where the administrator is >>>>> already aware of the software but definitely not for small applications >>>>> such as sharedrop.io, Threema Web whose main use case is the direct >>>>> connection in same network environments and its significant benefits >>>>> regarding throughput. >>>>> >>>> >>>> I agree this is the most likely scenario where host candidates are >>>> actually useful: two web browsers doing pure data channel on a >>>> managed/complex network, and no coordination between the network admin >>>> being and the app. >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >