From nobody Fri Sep 1 04:29:18 2017 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 9F4EE132EFB for ; Fri, 1 Sep 2017 04:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rlil_UYsGA7 for ; Fri, 1 Sep 2017 04:29:14 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 C75481321A7 for ; Fri, 1 Sep 2017 04:29:12 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-bb-59a9448743ec Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.1C.20899.78449A95; Fri, 1 Sep 2017 13:29:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 13:29:10 +0200 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqID///SaAIABesMA Date: Fri, 1 Sep 2017 11:29:10 +0000 Message-ID: References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="euc-kr" Content-ID: <327DA208DB26534FAC9A04888DEF5FA5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7hG67y8pIgy3vBSwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfG5tsnmAs+6FSs7c1vYLyj 3cXIySEhYCJxY3svUxcjF4eQwBFGiR2nrjNCOIsZJZb0LmTuYuTgYBOwkOj+B9YgIlAkcebY FiYQW1jAUeLYiXnsICUiAk4SvxqiIUryJDbtuMwCEmYRUJF4cTwUxOQVsJZYMMsOYvhCFom5 nQ/ApnAK2EusmzmLHcRmFBCT+H5qDVicWUBc4taT+UwQZwpILNlznhnCFpV4+fgfK8hMUQE9 iXf7PSHCShI/NlxigWjVkvjyYx8bhG0tsezBBlYIW1FiSvdDsFW8AoISJ2c+YZnAKDYLybZZ SNpnIWmfhaR9FpL2BYysqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+zglt9WOxgPPnc8 xCjAwajEw9s1cUWkEGtiWXFl7iFGCQ5mJRHeeNOVkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 HfZdiBASSE8sSc1OTS1ILYLJMnFwSjUw9h06UBd3QOfo/7sdWvOOPJ/EyTu9O/Denerz355V ZehV7XO1C4o71bohPP9qEH/hsyMsyvn/30us27aY3ea2enj0nKzrDALPZmrPDY+bJsgst73w bbvpT8tObdOllgcCXkQFXCrp9Z/zdFr+2mv9HN4SLp27NfUKHv/LNUvvkNlxzz530SR3JZbi jERDLeai4kQAKEX+B6wCAAA= Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 11:29:17 -0000 SGksDQoNCj4+Pj4+Pj4gICAgICAgIEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBydWxl IHRoYXQgdGhlIHRyYW5zcG9ydA0KPj4+Pj4+PmZvbGxvd3MNCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+ IGJ1bmRsZSwgd2hhdCBhYm91dCB0aGlzPw0KPj4+Pj4+Pg0KPj4+Pj4+PiBhPWdyb3VwOkJVTkRM RSBtaWQxIG1pZDINCj4+Pj4+Pj4gYT1ncm91cDpCVU5ETEUgbWlkMyBtaWQ0DQo+Pj4+Pj4+DQo+ Pj4+Pj4+IGFuZCBpbiBhIHJlb2ZmZXINCj4+Pj4+Pj4NCj4+Pj4+Pj4gYT1ncm91cDpCVU5ETEUg bWlkMiBtaWQzDQo+Pj4+Pj4+IGE9Z3JvdXA6QlVORExFIG1pZDQgbWlkMQ0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICAgICAgV2hhdCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8NCj4+Pj4+PiBJIHRoaW5rIFRh eWxvciByYWlzZWQgdGhpcyBpc3N1ZSBlYXJsaWVyLiBXaGF0IHlvdSBhcmUgZG9pbmcgYWJvdmUN Cj4+Pj4+PmlzDQo+Pj4+Pj4gbW92aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRv IGFub3RoZXIsIGFuZCBtaXhpbmcgdGhlDQo+Pj4+Pj5CVU5ETEUNCj4+Pj4+PiBncm91cHMgdXAs IGFuZCBJIGRvbqn2dCB0aGluayB0aGF0qfZzIGEgZ29vZCBpZGVhLg0KPj4+Pj4+DQo+Pj4+Pj4g UmVnYXJkcywNCj4+Pj4+Pg0KPj4+Pj4+IENocmlzdGVyDQo+Pj4+PiAgICAgICBJZiB5b3Ugd2Fu dCB0byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQo+Pj4+ PiBsYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5zdGFuY2UsIGEgcnVsZSB0aGF0IG9uY2Ug YSBtaWQgaXMNCj4+Pj4+cGxhY2VkDQo+Pj4+PiBpbiBhIGJ1bmRsZSwgdGhlIG9ubHkgd2F5IHRv IHJlbW92ZSBpdCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxsIGFzIGENCj4+Pj4+IHJ1bGUgdG8g aGFuZGxlIHRoZSBmb2xsb3dpbmc6DQo+Pj4+Pg0KPj4+Pj4gYT1ncm91cDpCVU5ETEUgbWlkMiBt aWQzDQo+Pj4+PiBhPW1pZDogbWlkMSA8LS0tIG5vdCBidW5kbGVkDQo+Pj4+PiAuLi4NCj4+Pj4+ IGE9bWlkOiBtaWQyDQo+Pj4+PiAuLi4NCj4+Pj4+IGE9bWlkOiBtaWQzDQo+Pj4+Pg0KPj4+Pj4g YW5kIGluIGEgcmVvZmZlcg0KPj4+Pj4NCj4+Pj4+IGE9Z3JvdXAgbWlkMSBtaWQyIG1pZDMNCj4+ Pj4+DQo+Pj4+PiAgICAgICBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQg aXMgcmV0YWluZWQ7IG1pZDEncywgb3INCj4+Pj4+IHRoZQ0KPj4+Pj4gYnVuZGxlJ3MuIE9yIHBl cmhhcHMgYSBydWxlIGZvcmJpZGRpbmcgcHJldmlvdXNseSB1bmJ1bmRsZWQgbWlkcyB0bw0KPj4+ Pj5iZQ0KPj4+Pj4gYWRkZWQgdG8gYSBidW5kbGUuDQo+Pj4+IEkgdGhpbmsgdGhpcyBpcyBjb3Zl cmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGluZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQo+Pj4+dG8N Cj4+Pj4gYQ0KPj4+PiBCVU5ETEUgZ3JvdXApIG9mIEJVTkRMRS4NCj4+Pj4NCj4+Pj4gQXNzdW1p bmcgeW91IGFyZSBub3QgY2hhbmdpbmcgdGhlIHRyYW5zcG9ydCBvZiB0aGUgbWlkMSBtLWxpbmUs IHlvdQ0KPj4+PmFyZQ0KPj4+PiBzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJV TkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluDQo+Pj4+c2VjdGlvbg0KPj4+PiA4LjUuMikuDQo+ Pj4gICAgICBSaWdodCwgdGhlIG9mZmVyZXIgaGFzIHRoZSBjaG9pY2Ugb2YgcmV0YWluaW5nIG1p ZDEncyB0cmFuc3BvcnQsDQo+Pj5vcg0KPj4+IGtlZXBpbmcgdGhlIG9sZCBidW5kbGUgdHJhbnNw b3J0LCBhY2NvcmRpbmcgdG8gOC41LjIuIElmIHdlIGRvbid0IGRvDQo+Pj4gc29tZXRoaW5nIGxp a2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjIN Cj4+PiB3b3VsZCBoYXZlIHRvIGJlIHRpZ2h0ZW5lZCBzaWduaWZpY2FudGx5LiBBZ2Fpbiwgb3Vy IHR3byBjaG9pY2VzIGhlcmU6DQo+Pj4NCj4+PiAxLiBGaW5kIGEgd2F5IHRvIGFsbG93IGFuIElD RSBvZmZlcmVyIHRvIGluZGljYXRlIHdoYXQgdHJhbnNwb3J0cyBpdCBpcw0KPj4+IHJldGFpbmlu ZyAoZWc7IHVmcmFnKS4NCj4+IFlvdSBkbyB0aGF0IHVzaW5nIHRoZSBhPWdyb3VwIGF0dHJpYnV0 ZS4NCj4+DQo+PiBhPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3 YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0DQo+Pm9mDQo+PiBtaWQxIChyZWFkOiB5b3UgYXJlIHN1 Z2dlc3RpbmcgYSBuZXcgdHJhbnNwb3J0IGZvciB0aGUgQlVORExFIGdyb3VwKQ0KPj4NCj4+IGE9 Z3JvdXA6QlVORUxFIG1pZDIgbWlkMyBtaWUxIG1lYW5zIHRoYXQgeW91IHdhbnQgdG8gdXNlIHRo ZSB0cmFuc3BvcnQNCj4+b2YNCj4+IG1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRM RSBncm91cCB0cmFuc3BvcnQpLg0KPj4NCj4+IE5vdywgaWYgeW91IElOIEFERElUSU9OIHRvIHRo YXQgd2FudHMgdG8gaW5kaWNhdGUgc29tZXRoaW5nIElDRQ0KPj5zcGVjaWZpYywNCj4+IGUuZywg d2hldGhlciB0byBkbyBhbiBJQ0UgcmVzdGFydCwgSSBndWVzcyB5b3UgY291bGQgdXNlIHVmcmFn IGZvciB0aGF0Lg0KPj4gQnV0LCBJIGRvbqn2dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZp YywgaXMgaXQ/DQo+DQo+ICAgICBPaywgc28gd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgInRy YW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiIuDQo+QnV0IHRoZSBidW5kbGUgc3BlYyBkb2Vzbid0 IF9xdWl0ZV8gZ3VhcmFudGVlIHRoaXMgcmlnaHQgbm93LCBhbmQgaXQNCj5wcm9iYWJseSBzaG91 bGRuJ3QgdHJ5IHRvIGd1YXJhbnRlZSBpdCBlaXRoZXIuIEZvciBpbnN0YW5jZSwgOC41LjENCj5k ZXNjcmliZXMgaG93IHRoZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3Ig dGhlIGJ1bmRsZSwNCj5hbnkgdGltZSBpdCB3YW50cyAoYW5kIGl0IGNvdWxkIHBvdGVudGlhbGx5 IGJlIGEgcHJlLWV4aXN0aW5nIHRyYW5zcG9ydA0KPiJzdG9sZW4iIGZyb20gc29tZSBvdGhlciBi dW5kbGUvbS1zZWN0aW9uISk7IHdpdGhvdXQgdGFraW5nIHNvbWV0aGluZw0KPmxpa2UgdWZyYWcg aW50byBhY2NvdW50LCB0aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2Fz ZS4NCg0KVGhlIEJVTkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBz byBpZiBzb21lb25lIGlzIHRyeWluZw0KdG8gb2ZmZXIgc3VjaCB0aGluZyB0aGUgYW5zd2VyZXIg c2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIsIG9yIGF0IGxlYXN0IG5vdA0KYWNjZXB0IHRoZSBvZmZl cmVkIHRyYW5zcG9ydHMuDQoNCj4gDQo+SG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkg cmlnaHQgaW4gc2F5aW5nICJXZWxsLCBkdWgsIHRoYXQgaXMNCj50cnVlIGZvciBub24tQlVORExF IGFsc28hIiwgd2hpY2ggaXMgd2h5IEkgbGlrZSB0aGUgaWRlYSBvZiBmaXhpbmcgdGhpcw0KPndp dGggdWZyYWcsIHNpbmNlIHRoYXQncyBob3cgd2UgbWFrZSB0aGlzIHdvcmsgaW4gdGhlIG5vbi1C VU5ETEUgY2FzZS4NCg0KSSBndWVzcyBJIHN0aWxsIGhhdmUgc29tZSBwcm9ibGVtcyB0byB1bmRl cnN0YW5kIHdoYXQgdGhlIHByb2JsZW0gaXMuDQoNCkxldKGvcyB0YWtlIHRoZSBmb2xsb3dpbmcg ZXhhbXBsZToNCg0KSW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2U6DQoNCmE9Z3JvdXA6QlVO RExFIG1pZDEgbWlkMiBtaWQzDQphPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDUgbWlkNg0KDQpOb3cs IHlvdSBoYXZlIHR3byB0cmFuc3BvcnRzOiBvbmUgobBvd25lZKGxIGJ5IG1pZDEgYW5kIG9uZSCh sG93bmVkIiBieSBtaWQ0Lg0KDQoNClJlLW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0IG1p ZDIgbWlkMw0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDYNCg0KDQpJbiB0aGUgcmUtb2Zm ZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFu ZA0KbWlkNCAtIHRoZXkgYXJlIHN0aWxsIHRoZSBzYW1lLiBUaGUgZGlmZmVyZW50IGlzIHRoYXQg bWlkMiBhbmQgbWlkMyB3aWxsDQpub3cgc3RhcnQgdXNpbmcgdGhlIHRyYW5zcG9ydCBvZiBtaWQ0 LCBhbmQgbWlkNSBhbmQgbWlkNiB3aWxsIHN0YXJ0IHVzaW5nDQp0aGUgdHJhbnNwb3J0IG9mIG1p ZDEuDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Fri Sep 1 06:37:14 2017 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 79BAF13213D for ; Fri, 1 Sep 2017 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 EHNvWCZfnQM1 for ; Fri, 1 Sep 2017 06:37:09 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5671331BA for ; Fri, 1 Sep 2017 06:37:09 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id n18so2047668oig.2 for ; Fri, 01 Sep 2017 06:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=dKCN48UdoTgN1A2srfU1M81n6c4GjkxpfdWIFjJOI+E=; b=IwEqXnUwcNLQUeMwSh7l17FRxwmFi2P5ZVx64l/2h0RRdIuQrWBeZbNQ81Wh7tLnZf sZR00IbBm4s9qg2NSiacmRGU/SqG45TzSUYvl4GI2JTxtGGh5Ym8wMLuS2Xlz77yAo/R r41npSMHojIrmWNdI0D8Nor3PT0upOse9yxiI= 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dKCN48UdoTgN1A2srfU1M81n6c4GjkxpfdWIFjJOI+E=; b=GeT6gGWoCk/LeyoZWCkw7MgQutoqmKRW4TuWDiZ3KwokNgE3o7ZADMrmgM9FRfL54L cGFGeaUjJqqfh79hlLXYj2mKAcvi41jZRVwPR6zVq5vV0IlZ0884JiLSlFJjHDB7VV29 BYumEJUNGobxc7mDYynfJFENJozk6Sey1Tvodw0HUfRStcW2QPe4VT7fh4AgxHPS9M3A 6zKCxOfo+IGgLl2sIIX1zvwfEvvkEJLsE1iX+tykqkwozd1X3prvCMlJuar+azKW5fla l+fyWkRP2bc7rnpmVG/HnTateuSq3sF8m7jb507QcrBfesq/uComELAUsuvFfWEozghn TR1g== X-Gm-Message-State: AHPjjUiZJGql7bbxd0xwDWws7DDhgaF+zadVgWnbbe3ygWR6ecurwrfq S0ivPqP55nvOYYJmjowEUg== X-Google-Smtp-Source: ADKCNb7Bwf4H1NR6kgFF4w0LXsbiVXwVbHUkvukpKdKWdFcY2c0AViAVpV/c+zsInJmgoVyv6yP2vQ== X-Received: by 10.202.83.12 with SMTP id h12mr2135837oib.35.1504273028390; Fri, 01 Sep 2017 06:37:08 -0700 (PDT) Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id k206sm186616oia.2.2017.09.01.06.37.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 06:37:07 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> From: Byron Campen Message-ID: Date: Fri, 1 Sep 2017 08:37:01 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------04C381ACD36F32FA3D051A7D" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 13:37:12 -0000 This is a multi-part message in MIME format. --------------04C381ACD36F32FA3D051A7D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/1/17 6:29 AM, Christer Holmberg wrote: > Hi, > >>>>>>>> Alright, if we want to write a rule that the transport >>>>>>>> follows >>>>>>>> the >>>>>>>> bundle, what about this? >>>>>>>> >>>>>>>> a=group:BUNDLE mid1 mid2 >>>>>>>> a=group:BUNDLE mid3 mid4 >>>>>>>> >>>>>>>> and in a reoffer >>>>>>>> >>>>>>>> a=group:BUNDLE mid2 mid3 >>>>>>>> a=group:BUNDLE mid4 mid1 >>>>>>>> >>>>>>>> What transport goes where? >>>>>>> I think Taylor raised this issue earlier. What you are doing above >>>>>>> is >>>>>>> moving streams from one BUNDLE group to another, and mixing the >>>>>>> BUNDLE >>>>>>> groups up, and I don¹t think that¹s a good idea. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>> If you want to classify this as a bad idea, we need normative >>>>>> language forbidding it. For instance, a rule that once a mid is >>>>>> placed >>>>>> in a bundle, the only way to remove it is to disable it, as well as a >>>>>> rule to handle the following: >>>>>> >>>>>> a=group:BUNDLE mid2 mid3 >>>>>> a=mid: mid1 <--- not bundled >>>>>> ... >>>>>> a=mid: mid2 >>>>>> ... >>>>>> a=mid: mid3 >>>>>> >>>>>> and in a reoffer >>>>>> >>>>>> a=group mid1 mid2 mid3 >>>>>> >>>>>> We would need to define which transport is retained; mid1's, or >>>>>> the >>>>>> bundle's. Or perhaps a rule forbidding previously unbundled mids to >>>>>> be >>>>>> added to a bundle. >>>>> I think this is covered in section 8.5.2 (Adding a media description >>>>> to >>>>> a >>>>> BUNDLE group) of BUNDLE. >>>>> >>>>> Assuming you are not changing the transport of the mid1 m-line, you >>>>> are >>>>> suggesting a new transport for the BUNDLE group (first bullet in >>>>> section >>>>> 8.5.2). >>>> Right, the offerer has the choice of retaining mid1's transport, >>>> or >>>> keeping the old bundle transport, according to 8.5.2. If we don't do >>>> something like adding ufrag to the transport comparison rules, 8.5.2 >>>> would have to be tightened significantly. Again, our two choices here: >>>> >>>> 1. Find a way to allow an ICE offerer to indicate what transports it is >>>> retaining (eg; ufrag). >>> You do that using the a=group attribute. >>> >>> a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport >>> of >>> mid1 (read: you are suggesting a new transport for the BUNDLE group) >>> >>> a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport >>> of >>> mid2 (read: keep the existing BUNDLE group transport). >>> >>> Now, if you IN ADDITION to that wants to indicate something ICE >>> specific, >>> e.g, whether to do an ICE restart, I guess you could use ufrag for that. >>> But, I don¹t think that is BUNDLE specific, is it? >> Ok, so what you are describing is "transport follows m-section". >> But the bundle spec doesn't _quite_ guarantee this right now, and it >> probably shouldn't try to guarantee it either. For instance, 8.5.1 >> describes how the offerer can suggest a new transport for the bundle, >> any time it wants (and it could potentially be a pre-existing transport >> "stolen" from some other bundle/m-section!); without taking something >> like ufrag into account, this is impossible to detect in the ICE case. > The BUNDLE groups can not use the same transport, so if someone is trying > to offer such thing the answerer should reject the offer, or at least not > accept the offered transports. > >> However, you would be completely right in saying "Well, duh, that is >> true for non-BUNDLE also!", which is why I like the idea of fixing this >> with ufrag, since that's how we make this work in the non-BUNDLE case. > I guess I still have some problems to understand what the problem is. > > Let’s take the following example: > > Initial offer/answer exchange: > > a=group:BUNDLE mid1 mid2 mid3 > a=group:BUNDLE mid4 mid5 mid6 > > Now, you have two transports: one “owned” by mid1 and one “owned" by mid4. > > > Re-offer: > > a=group:BUNDLE mid4 mid2 mid3 > a=group:BUNDLE mid1 mid5 mid6 > > > In the re-offer, the offerer does not change the transports of mid1 and > mid4 - they are still the same. The different is that mid2 and mid3 will > now start using the transport of mid4, and mid5 and mid6 will start using > the transport of mid1.     Right, but as far as I can tell the bundle spec does not forbid this: a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555 a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666 ... m=audio 5555 ... a=mid:mid1 ... m=video 6666 ... a=mid:mid4 and then in a reoffer: a=group:BUNDLE *mid4* mid2 mid3 <--- mid4 and mid1 have swapped... a=group:BUNDLE *mid1* mid5 mid6 ... m=audio *6666* ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now a=mid:mid1 ... m=video *5555* ... a=mid:mid4     If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account. Best regards, Byron Campen --------------04C381ACD36F32FA3D051A7D Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 9/1/17 6:29 AM, Christer Holmberg wrote:
Hi,


       Alright, if we want to write a rule that the transport
follows
the
bundle, what about this?

a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4

and in a reoffer

a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1

       What transport goes where?

I think Taylor raised this issue earlier. What you are doing above
is
moving streams from one BUNDLE group to another, and mixing the
BUNDLE
groups up, and I don¹t think that¹s a good idea.

Regards,

Christer

      If you want to classify this as a bad idea, we need normative
language forbidding it. For instance, a rule that once a mid is
placed
in a bundle, the only way to remove it is to disable it, as well as a
rule to handle the following:

a=group:BUNDLE mid2 mid3
a=mid: mid1 <--- not bundled
...
a=mid: mid2
...
a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

      We would need to define which transport is retained; mid1's, or
the
bundle's. Or perhaps a rule forbidding previously unbundled mids to
be
added to a bundle.

I think this is covered in section 8.5.2 (Adding a media description
to
a
BUNDLE group) of BUNDLE.

Assuming you are not changing the transport of the mid1 m-line, you
are
suggesting a new transport for the BUNDLE group (first bullet in
section
8.5.2).

     Right, the offerer has the choice of retaining mid1's transport,
or
keeping the old bundle transport, according to 8.5.2. If we don't do
something like adding ufrag to the transport comparison rules, 8.5.2
would have to be tightened significantly. Again, our two choices here:

1. Find a way to allow an ICE offerer to indicate what transports it is
retaining (eg; ufrag).

You do that using the a=group attribute.

a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport
of
mid1 (read: you are suggesting a new transport for the BUNDLE group)

a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport
of
mid2 (read: keep the existing BUNDLE group transport).

Now, if you IN ADDITION to that wants to indicate something ICE
specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don¹t think that is BUNDLE specific, is it?

    Ok, so what you are describing is "transport follows m-section".
But the bundle spec doesn't _quite_ guarantee this right now, and it
probably shouldn't try to guarantee it either. For instance, 8.5.1
describes how the offerer can suggest a new transport for the bundle,
any time it wants (and it could potentially be a pre-existing transport
"stolen" from some other bundle/m-section!); without taking something
like ufrag into account, this is impossible to detect in the ICE case.

The BUNDLE groups can not use the same transport, so if someone is trying
to offer such thing the answerer should reject the offer, or at least not
accept the offered transports.


However, you would be completely right in saying "Well, duh, that is
true for non-BUNDLE also!", which is why I like the idea of fixing this
with ufrag, since that's how we make this work in the non-BUNDLE case.

I guess I still have some problems to understand what the problem is.

Let’s take the following example:

Initial offer/answer exchange:

a=group:BUNDLE mid1 mid2 mid3
a=group:BUNDLE mid4 mid5 mid6

Now, you have two transports: one “owned” by mid1 and one “owned" by mid4.


Re-offer:

a=group:BUNDLE mid4 mid2 mid3
a=group:BUNDLE mid1 mid5 mid6


In the re-offer, the offerer does not change the transports of mid1 and
mid4 - they are still the same. The different is that mid2 and mid3 will
now start using the transport of mid4, and mid5 and mid6 will start using
the transport of mid1.

    Right, but as far as I can tell the bundle spec does not forbid this:

a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555
a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666
...
m=audio 5555 ...
a=mid:mid1
...
m=video 6666 ...
a=mid:mid4

and then in a reoffer:

a=group:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped...
a=group:BUNDLE mid1 mid5 mid6
...
m=audio 6666 ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now
a=mid:mid1
...
m=video 5555 ...
a=mid:mid4

    If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account.

Best regards,
Byron Campen


--------------04C381ACD36F32FA3D051A7D-- From nobody Fri Sep 1 06:51:22 2017 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 7EDEA132FB3 for ; Fri, 1 Sep 2017 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 ucAc-FFHtDTB for ; Fri, 1 Sep 2017 06:51:19 -0700 (PDT) Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (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 64D6D13316A for ; Fri, 1 Sep 2017 06:51:19 -0700 (PDT) Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 44E595615; Fri, 1 Sep 2017 09:51:16 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp36.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id C4CCF560F; Fri, 1 Sep 2017 09:51:15 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 09:51:16 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Fri, 1 Sep 2017 07:51:14 -0600 Cc: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <305519A9-DFD4-4A52-8C3A-1CCB81A541D0@iii.ca> References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> To: Byron Campen X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 13:51:20 -0000 I'm lost on what the problem is. That might be because the IETF email = server does not send me all the email to this list but more inline ... > Right, but as far as I can tell the bundle spec does not forbid = this: >=20 > a=3Dgroup:BUNDLE mid1 mid2 mid3 <--- uses port 5555 > a=3Dgroup:BUNDLE mid4 mid5 mid6 <--- uses port 6666 > ... > m=3Daudio 5555 ... > a=3Dmid:mid1 > ... > m=3Dvideo 6666 ... > a=3Dmid:mid4 >=20 > and then in a reoffer: >=20 > a=3Dgroup:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped... > a=3Dgroup:BUNDLE mid1 mid5 mid6 > ... > m=3Daudio 6666 ... <--- but the offerer has explicitly indicated that = 6666 is attached to mid1 now > a=3Dmid:mid1 > ... > m=3Dvideo 5555 ... > a=3Dmid:mid4 >=20 > If the bundle spec allows this, "transport follows m-section" is = not part of the spec; the fundamental rule is "transport is signaled = explicitly every time", which is impossible with ICE unless ufrag is = taken into account. >=20 > Best regards, > Byron Campen Ok, the above helps me understand but now take it to the next level, = what is the problem when we move to ICE. I'd like to point out that with = no ICE, the above is very unlikely to be valid SDP bec because during = the reoffer you have to be able to receive both audio and video on port = 5555.=20 From nobody Fri Sep 1 06:57:20 2017 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 AD099133229 for ; Fri, 1 Sep 2017 06:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuiQGotfNkA5 for ; Fri, 1 Sep 2017 06:57:17 -0700 (PDT) Received: from smtp81.ord1c.emailsrvr.com (smtp81.ord1c.emailsrvr.com [108.166.43.81]) (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 320DE1331FF for ; Fri, 1 Sep 2017 06:57:17 -0700 (PDT) Received: from smtp11.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 98F57A00C8; Fri, 1 Sep 2017 09:57:13 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 61AD9A00E6; Fri, 1 Sep 2017 09:57:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 09:57:13 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> Date: Fri, 1 Sep 2017 07:57:12 -0600 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> To: James Pearce X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 13:57:18 -0000 > On Aug 23, 2017, at 3:06 PM, James Pearce = wrote: >=20 >=20 > The obvious solution seems to be to change the behaviour of mode 2. = Rather than using the default route in all cases, we should use the = route that was used to fetch the origin. This seems to resolve both the = usability and privacy concerns without reducing existing security. I agree this is a significant problem and your proposal does seems like = a better solution that the current text. We should get people to think = about the implications of that change.=20 From nobody Fri Sep 1 07:44:42 2017 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 4FCC5132EEF for ; Fri, 1 Sep 2017 07:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-9UJugKvIZj for ; Fri, 1 Sep 2017 07:44:38 -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 50CA513303A for ; Fri, 1 Sep 2017 07:44:37 -0700 (PDT) X-AuditID: c1b4fb25-94fff70000005333-85-59a9725360b5 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.92.21299.35279A95; Fri, 1 Sep 2017 16:44:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 16:44:35 +0200 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqID///SaAIABesMA///wJ4CAAEZzAA== Date: Fri, 1 Sep 2017 14:44:34 +0000 Message-ID: References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D5CF4BF820EB3christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7k25I0cpIg2cLOC0W3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGwgVH2AqutDFW7H09n7WB sbmZsYuRk0NCwERi15rtrF2MXBxCAkcYJQ7OnMsC4SxmlFjYshzI4eBgE7CQ6P6nDdIgIlAk cebYFiYQW1jAUeLYiXnsICUiAk4SvxqiIUrqJFo3/gQrYRFQkXj34AYbiM0rYC2x8GQnG8T4 DlaJ19e/sIAkOAXsJRa9bgKzGQXEJL6fWgPWzCwgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxVk r6iAnsS7/Z4QYUWJq9OXQ7UmSMycd4kdYq+gxMmZT1gmMIrMQjJ1FpKyWUjKIOJaEl9+7GOD sBUlpnQ/BKrhALI1Jd48rIUIW0vMvrqRGVnJAkaOVYyixanFSbnpRsZ6qUWZycXF+Xl6eakl mxiBEXhwy2/VHYyX3zgeYhTgYFTi4b3avyJSiDWxrLgy9xCjBAezkgivWebKSCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoYq2/avGg7w5ivZvn0/+f+ llzmu0HvnybJPj1xrMdda4eR0LV500V5auz/qB+4yWvasOvne99dk9kNdgixhX4rubXy+4xD xt80ly4ROPdlYna/WeSveUlzSh4YTrZ94LCaaw5LhVLrTFmxBFPLLa/l1nkz75WaXLpkhvzi z0dzZRr4LwU6LfUsVmIpzkg01GIuKk4EACFg6Ti8AgAA Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 14:44:41 -0000 --_000_D5CF4BF820EB3christerholmbergericssoncom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQoNCg0KICAgICAgIEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBydWxl IHRoYXQgdGhlIHRyYW5zcG9ydA0KZm9sbG93cw0KdGhlDQpidW5kbGUsIHdoYXQgYWJvdXQgdGhp cz8NCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyDQphPWdyb3VwOkJVTkRMRSBtaWQzIG1pZDQN Cg0KYW5kIGluIGEgcmVvZmZlcg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCmE9Z3JvdXA6 QlVORExFIG1pZDQgbWlkMQ0KDQogICAgICAgV2hhdCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8NCg0K DQpJIHRoaW5rIFRheWxvciByYWlzZWQgdGhpcyBpc3N1ZSBlYXJsaWVyLiBXaGF0IHlvdSBhcmUg ZG9pbmcgYWJvdmUNCmlzDQptb3Zpbmcgc3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8g YW5vdGhlciwgYW5kIG1peGluZyB0aGUNCkJVTkRMRQ0KZ3JvdXBzIHVwLCBhbmQgSSBkb26p9nQg dGhpbmsgdGhhdKn2cyBhIGdvb2QgaWRlYS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQog ICAgICBJZiB5b3Ugd2FudCB0byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQg bm9ybWF0aXZlDQpsYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5zdGFuY2UsIGEgcnVsZSB0 aGF0IG9uY2UgYSBtaWQgaXMNCnBsYWNlZA0KaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byBy ZW1vdmUgaXQgaXMgdG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBhcyBhDQpydWxlIHRvIGhhbmRsZSB0 aGUgZm9sbG93aW5nOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCmE9bWlkOiBtaWQxIDwt LS0gbm90IGJ1bmRsZWQNCi4uLg0KYT1taWQ6IG1pZDINCi4uLg0KYT1taWQ6IG1pZDMNCg0KYW5k IGluIGEgcmVvZmZlcg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCiAgICAgIFdlIHdvdWxk IG5lZWQgdG8gZGVmaW5lIHdoaWNoIHRyYW5zcG9ydCBpcyByZXRhaW5lZDsgbWlkMSdzLCBvcg0K dGhlDQpidW5kbGUncy4gT3IgcGVyaGFwcyBhIHJ1bGUgZm9yYmlkZGluZyBwcmV2aW91c2x5IHVu YnVuZGxlZCBtaWRzIHRvDQpiZQ0KYWRkZWQgdG8gYSBidW5kbGUuDQoNCg0KSSB0aGluayB0aGlz IGlzIGNvdmVyZWQgaW4gc2VjdGlvbiA4LjUuMiAoQWRkaW5nIGEgbWVkaWEgZGVzY3JpcHRpb24N CnRvDQphDQpCVU5ETEUgZ3JvdXApIG9mIEJVTkRMRS4NCg0KQXNzdW1pbmcgeW91IGFyZSBub3Qg Y2hhbmdpbmcgdGhlIHRyYW5zcG9ydCBvZiB0aGUgbWlkMSBtLWxpbmUsIHlvdQ0KYXJlDQpzdWdn ZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0 IGluDQpzZWN0aW9uDQo4LjUuMikuDQoNCg0KICAgICBSaWdodCwgdGhlIG9mZmVyZXIgaGFzIHRo ZSBjaG9pY2Ugb2YgcmV0YWluaW5nIG1pZDEncyB0cmFuc3BvcnQsDQpvcg0Ka2VlcGluZyB0aGUg b2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG8N CnNvbWV0aGluZyBsaWtlIGFkZGluZyB1ZnJhZyB0byB0aGUgdHJhbnNwb3J0IGNvbXBhcmlzb24g cnVsZXMsIDguNS4yDQp3b3VsZCBoYXZlIHRvIGJlIHRpZ2h0ZW5lZCBzaWduaWZpY2FudGx5LiBB Z2Fpbiwgb3VyIHR3byBjaG9pY2VzIGhlcmU6DQoNCjEuIEZpbmQgYSB3YXkgdG8gYWxsb3cgYW4g SUNFIG9mZmVyZXIgdG8gaW5kaWNhdGUgd2hhdCB0cmFuc3BvcnRzIGl0IGlzDQpyZXRhaW5pbmcg KGVnOyB1ZnJhZykuDQoNCg0KWW91IGRvIHRoYXQgdXNpbmcgdGhlIGE9Z3JvdXAgYXR0cmlidXRl Lg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRv IHVzZSB0aGUgdHJhbnNwb3J0DQpvZg0KbWlkMSAocmVhZDogeW91IGFyZSBzdWdnZXN0aW5nIGEg bmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCkNCg0KYT1ncm91cDpCVU5FTEUgbWlk MiBtaWQzIG1pZTEgbWVhbnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIHRyYW5zcG9ydA0Kb2YN Cm1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFuc3BvcnQpLg0K DQpOb3csIGlmIHlvdSBJTiBBRERJVElPTiB0byB0aGF0IHdhbnRzIHRvIGluZGljYXRlIHNvbWV0 aGluZyBJQ0UNCnNwZWNpZmljLA0KZS5nLCB3aGV0aGVyIHRvIGRvIGFuIElDRSByZXN0YXJ0LCBJ IGd1ZXNzIHlvdSBjb3VsZCB1c2UgdWZyYWcgZm9yIHRoYXQuDQpCdXQsIEkgZG9uqfZ0IHRoaW5r IHRoYXQgaXMgQlVORExFIHNwZWNpZmljLCBpcyBpdD8NCg0KDQogICAgT2ssIHNvIHdoYXQgeW91 IGFyZSBkZXNjcmliaW5nIGlzICJ0cmFuc3BvcnQgZm9sbG93cyBtLXNlY3Rpb24iLg0KQnV0IHRo ZSBidW5kbGUgc3BlYyBkb2Vzbid0IF9xdWl0ZV8gZ3VhcmFudGVlIHRoaXMgcmlnaHQgbm93LCBh bmQgaXQNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0IGVpdGhlci4gRm9y IGluc3RhbmNlLCA4LjUuMQ0KZGVzY3JpYmVzIGhvdyB0aGUgb2ZmZXJlciBjYW4gc3VnZ2VzdCBh IG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBidW5kbGUsDQphbnkgdGltZSBpdCB3YW50cyAoYW5kIGl0 IGNvdWxkIHBvdGVudGlhbGx5IGJlIGEgcHJlLWV4aXN0aW5nIHRyYW5zcG9ydA0KInN0b2xlbiIg ZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rpb24hKTsgd2l0aG91dCB0YWtpbmcgc29tZXRo aW5nDQpsaWtlIHVmcmFnIGludG8gYWNjb3VudCwgdGhpcyBpcyBpbXBvc3NpYmxlIHRvIGRldGVj dCBpbiB0aGUgSUNFIGNhc2UuDQoNCg0KVGhlIEJVTkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhl IHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25lIGlzIHRyeWluZw0KdG8gb2ZmZXIgc3VjaCB0 aGluZyB0aGUgYW5zd2VyZXIgc2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIsIG9yIGF0IGxlYXN0IG5v dA0KYWNjZXB0IHRoZSBvZmZlcmVkIHRyYW5zcG9ydHMuDQoNCg0KDQpIb3dldmVyLCB5b3Ugd291 bGQgYmUgY29tcGxldGVseSByaWdodCBpbiBzYXlpbmcgIldlbGwsIGR1aCwgdGhhdCBpcw0KdHJ1 ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIsIHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhlIGlkZWEgb2Yg Zml4aW5nIHRoaXMNCndpdGggdWZyYWcsIHNpbmNlIHRoYXQncyBob3cgd2UgbWFrZSB0aGlzIHdv cmsgaW4gdGhlIG5vbi1CVU5ETEUgY2FzZS4NCg0KDQpJIGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21l IHByb2JsZW1zIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0KTGV0oa9zIHRh a2UgdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5n ZToNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMNCmE9Z3JvdXA6QlVORExFIG1pZDQg bWlkNSBtaWQ2DQoNCk5vdywgeW91IGhhdmUgdHdvIHRyYW5zcG9ydHM6IG9uZSChsG93bmVkobEg YnkgbWlkMSBhbmQgb25lIKGwb3duZWQiIGJ5IG1pZDQuDQoNCg0KUmUtb2ZmZXI6DQoNCmE9Z3Jv dXA6QlVORExFIG1pZDQgbWlkMiBtaWQzDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDUgbWlkNg0K DQoNCkluIHRoZSByZS1vZmZlciwgdGhlIG9mZmVyZXIgZG9lcyBub3QgY2hhbmdlIHRoZSB0cmFu c3BvcnRzIG9mIG1pZDEgYW5kDQptaWQ0IC0gdGhleSBhcmUgc3RpbGwgdGhlIHNhbWUuIFRoZSBk aWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCm5vdyBzdGFydCB1c2luZyB0aGUg dHJhbnNwb3J0IG9mIG1pZDQsIGFuZCBtaWQ1IGFuZCBtaWQ2IHdpbGwgc3RhcnQgdXNpbmcNCnRo ZSB0cmFuc3BvcnQgb2YgbWlkMS4NCg0KDQogICAgUmlnaHQsIGJ1dCBhcyBmYXIgYXMgSSBjYW4g dGVsbCB0aGUgYnVuZGxlIHNwZWMgZG9lcyBub3QgZm9yYmlkIHRoaXM6DQoNCmE9Z3JvdXA6QlVO RExFIG1pZDEgbWlkMiBtaWQzIDwtLS0gdXNlcyBwb3J0IDU1NTUNCmE9Z3JvdXA6QlVORExFIG1p ZDQgbWlkNSBtaWQ2IDwtLS0gdXNlcyBwb3J0IDY2NjYNCi4uLg0KbT1hdWRpbyA1NTU1IC4uLg0K YT1taWQ6bWlkMQ0KLi4uDQptPXZpZGVvIDY2NjYgLi4uDQphPW1pZDptaWQ0DQoNCmFuZCB0aGVu IGluIGEgcmVvZmZlcjoNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQyIG1pZDMgPC0tLSBtaWQ0 IGFuZCBtaWQxIGhhdmUgc3dhcHBlZC4uLg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDYN Ci4uLg0KbT1hdWRpbyA2NjY2IC4uLiA8LS0tIGJ1dCB0aGUgb2ZmZXJlciBoYXMgZXhwbGljaXRs eSBpbmRpY2F0ZWQgdGhhdCA2NjY2IGlzIGF0dGFjaGVkIHRvIG1pZDEgbm93DQphPW1pZDptaWQx DQouLi4NCm09dmlkZW8gNTU1NSAuLi4NCmE9bWlkOm1pZDQNCg0KICAgIElmIHRoZSBidW5kbGUg c3BlYyBhbGxvd3MgdGhpcywgInRyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiIgaXMgbm90IHBh cnQgb2YgdGhlIHNwZWM7IHRoZSBmdW5kYW1lbnRhbCBydWxlIGlzICJ0cmFuc3BvcnQgaXMgc2ln bmFsZWQgZXhwbGljaXRseSBldmVyeSB0aW1lIiwgd2hpY2ggaXMgaW1wb3NzaWJsZSB3aXRoIElD RSB1bmxlc3MgdWZyYWcgaXMgdGFrZW4gaW50byBhY2NvdW50Lg0KDQoNCk1heWJlIKGwdHJhbnNw b3J0IGZvbGxvd3MgbS1zZWN0aW9uobEgaXMgd3Jvbmcgd29yZGluZy4gVHJhbnNwb3J0IGlzIHdo YXRldmVyIHRoZSBmaXJzdCBtaWQgaW4gdGhlIGE9Z3JvdXA6QlVORExFIGF0dHJpYnV0ZSBpbmRp Y2F0ZXMgaXQgdG8gYmUsIGFuZCBpZiB0aGF0IHRyYW5zcG9ydCBhbHJlYWR5IGV4aXN0cyB0aGVy ZSBpcyBubyBuZWVkIHRvIGRvIGFuIElDRSByZXN0YXJ0Lg0KDQpTbywgaW4geW91ciBleGFtcGxl LCBpIHRoZSByZW9mZmVyIHlvdSBhcmUgc3VnZ2VzdGluZyB0aGF0IG1pZDQsIG1pZDIgYW5kIG1p ZDMgdXNlcyB0aGUgIjU1NTUgdHJhbnNwb3J0Ii4gU2luY2UgdGhpcyB0cmFuc3BvcnQgYWxyZWFk eSBleGlzdHMgKGl0IHdhcyBwcmV2aW91c2x5IHVzZWQgYnkgbWlkMSwgbWlkMiBhbmQgbWlkMyks IHlvdSBkb26hr3QgaGF2ZSB0byBkbyBhbiBJQ0UgcmVzdGFydC4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KDQo= --_000_D5CF4BF820EB3christerholmbergericssoncom_ Content-Type: text/html; charset="euc-kr" Content-ID: <2D5208A66FE38F44896EC2E239C1D785@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+ SGksPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDAp OyI+DQo8ZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpENUNGMTg5MC4yMEU1RiUyNWNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSI+DQo8cHJlIHdyYXA9IiI+DQo8L3ByZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PHByZSB3cmFwPSIiPiAgICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0 aGF0IHRoZSB0cmFuc3BvcnQNCmZvbGxvd3MNCnRoZQ0KYnVuZGxlLCB3aGF0IGFib3V0IHRoaXM/ DQoNCmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMg0KYT1ncm91cDpCVU5ETEUgbWlkMyBtaWQ0DQoN CmFuZCBpbiBhIHJlb2ZmZXINCg0KYT1ncm91cDpCVU5ETEUgbWlkMiBtaWQzDQphPWdyb3VwOkJV TkRMRSBtaWQ0IG1pZDENCg0KICAgICAgIFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/DQo8L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5JIHRoaW5rIFRheWxvciByYWlzZWQgdGhp cyBpc3N1ZSBlYXJsaWVyLiBXaGF0IHlvdSBhcmUgZG9pbmcgYWJvdmUNCmlzDQptb3Zpbmcgc3Ry ZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5vdGhlciwgYW5kIG1peGluZyB0aGUNCkJV TkRMRQ0KZ3JvdXBzIHVwLCBhbmQgSSBkb26p9nQgdGhpbmsgdGhhdKn2cyBhIGdvb2QgaWRlYS4N Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZSB3cmFw PSIiPiAgICAgIElmIHlvdSB3YW50IHRvIGNsYXNzaWZ5IHRoaXMgYXMgYSBiYWQgaWRlYSwgd2Ug bmVlZCBub3JtYXRpdmUNCmxhbmd1YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBy dWxlIHRoYXQgb25jZSBhIG1pZCBpcw0KcGxhY2VkDQppbiBhIGJ1bmRsZSwgdGhlIG9ubHkgd2F5 IHRvIHJlbW92ZSBpdCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxsIGFzIGENCnJ1bGUgdG8gaGFu ZGxlIHRoZSBmb2xsb3dpbmc6DQoNCmE9Z3JvdXA6QlVORExFIG1pZDIgbWlkMw0KYT1taWQ6IG1p ZDEgJmx0Oy0tLSBub3QgYnVuZGxlZA0KLi4uDQphPW1pZDogbWlkMg0KLi4uDQphPW1pZDogbWlk Mw0KDQphbmQgaW4gYSByZW9mZmVyDQoNCmE9Z3JvdXAgbWlkMSBtaWQyIG1pZDMNCg0KICAgICAg V2Ugd291bGQgbmVlZCB0byBkZWZpbmUgd2hpY2ggdHJhbnNwb3J0IGlzIHJldGFpbmVkOyBtaWQx J3MsIG9yDQp0aGUNCmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3JiaWRkaW5nIHByZXZp b3VzbHkgdW5idW5kbGVkIG1pZHMgdG8NCmJlDQphZGRlZCB0byBhIGJ1bmRsZS4NCjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHByZSB3cmFwPSIiPkkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHNl Y3Rpb24gOC41LjIgKEFkZGluZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQp0bw0KYQ0KQlVORExFIGdy b3VwKSBvZiBCVU5ETEUuDQoNCkFzc3VtaW5nIHlvdSBhcmUgbm90IGNoYW5naW5nIHRoZSB0cmFu c3BvcnQgb2YgdGhlIG1pZDEgbS1saW5lLCB5b3UNCmFyZQ0Kc3VnZ2VzdGluZyBhIG5ldyB0cmFu c3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXAgKGZpcnN0IGJ1bGxldCBpbg0Kc2VjdGlvbg0KOC41 LjIpLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+ICAgICBSaWdodCwgdGhl IG9mZmVyZXIgaGFzIHRoZSBjaG9pY2Ugb2YgcmV0YWluaW5nIG1pZDEncyB0cmFuc3BvcnQsDQpv cg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4g SWYgd2UgZG9uJ3QgZG8NCnNvbWV0aGluZyBsaWtlIGFkZGluZyB1ZnJhZyB0byB0aGUgdHJhbnNw b3J0IGNvbXBhcmlzb24gcnVsZXMsIDguNS4yDQp3b3VsZCBoYXZlIHRvIGJlIHRpZ2h0ZW5lZCBz aWduaWZpY2FudGx5LiBBZ2Fpbiwgb3VyIHR3byBjaG9pY2VzIGhlcmU6DQoNCjEuIEZpbmQgYSB3 YXkgdG8gYWxsb3cgYW4gSUNFIG9mZmVyZXIgdG8gaW5kaWNhdGUgd2hhdCB0cmFuc3BvcnRzIGl0 IGlzDQpyZXRhaW5pbmcgKGVnOyB1ZnJhZykuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUg d3JhcD0iIj5Zb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCmE9Z3Jv dXA6QlVORExFIG1pZDEgbWlkMiBtaWQzIG1lYW5zIHRoYXQgeW91IHdhbnQgdG8gdXNlIHRoZSB0 cmFuc3BvcnQNCm9mDQptaWQxIChyZWFkOiB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBuZXcgdHJhbnNw b3J0IGZvciB0aGUgQlVORExFIGdyb3VwKQ0KDQphPWdyb3VwOkJVTkVMRSBtaWQyIG1pZDMgbWll MSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0DQpvZg0KbWlkMiAocmVh ZDoga2VlcCB0aGUgZXhpc3RpbmcgQlVORExFIGdyb3VwIHRyYW5zcG9ydCkuDQoNCk5vdywgaWYg eW91IElOIEFERElUSU9OIHRvIHRoYXQgd2FudHMgdG8gaW5kaWNhdGUgc29tZXRoaW5nIElDRQ0K c3BlY2lmaWMsDQplLmcsIHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91 IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCkJ1dCwgSSBkb26p9nQgdGhpbmsgdGhhdCBpcyBC VU5ETEUgc3BlY2lmaWMsIGlzIGl0Pw0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHdyYXA9 IiI+ICAgIE9rLCBzbyB3aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyAmcXVvdDt0cmFuc3BvcnQg Zm9sbG93cyBtLXNlY3Rpb24mcXVvdDsuDQpCdXQgdGhlIGJ1bmRsZSBzcGVjIGRvZXNuJ3QgX3F1 aXRlXyBndWFyYW50ZWUgdGhpcyByaWdodCBub3csIGFuZCBpdA0KcHJvYmFibHkgc2hvdWxkbid0 IHRyeSB0byBndWFyYW50ZWUgaXQgZWl0aGVyLiBGb3IgaW5zdGFuY2UsIDguNS4xDQpkZXNjcmli ZXMgaG93IHRoZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1 bmRsZSwNCmFueSB0aW1lIGl0IHdhbnRzIChhbmQgaXQgY291bGQgcG90ZW50aWFsbHkgYmUgYSBw cmUtZXhpc3RpbmcgdHJhbnNwb3J0DQomcXVvdDtzdG9sZW4mcXVvdDsgZnJvbSBzb21lIG90aGVy IGJ1bmRsZS9tLXNlY3Rpb24hKTsgd2l0aG91dCB0YWtpbmcgc29tZXRoaW5nDQpsaWtlIHVmcmFn IGludG8gYWNjb3VudCwgdGhpcyBpcyBpbXBvc3NpYmxlIHRvIGRldGVjdCBpbiB0aGUgSUNFIGNh c2UuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5UaGUgQlVORExFIGdyb3Vw cyBjYW4gbm90IHVzZSB0aGUgc2FtZSB0cmFuc3BvcnQsIHNvIGlmIHNvbWVvbmUgaXMgdHJ5aW5n DQp0byBvZmZlciBzdWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVqZWN0IHRoZSBvZmZl ciwgb3IgYXQgbGVhc3Qgbm90DQphY2NlcHQgdGhlIG9mZmVyZWQgdHJhbnNwb3J0cy4NCg0KPC9w cmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5Ib3dldmVyLCB5b3Ug d291bGQgYmUgY29tcGxldGVseSByaWdodCBpbiBzYXlpbmcgJnF1b3Q7V2VsbCwgZHVoLCB0aGF0 IGlzDQp0cnVlIGZvciBub24tQlVORExFIGFsc28hJnF1b3Q7LCB3aGljaCBpcyB3aHkgSSBsaWtl IHRoZSBpZGVhIG9mIGZpeGluZyB0aGlzDQp3aXRoIHVmcmFnLCBzaW5jZSB0aGF0J3MgaG93IHdl IG1ha2UgdGhpcyB3b3JrIGluIHRoZSBub24tQlVORExFIGNhc2UuDQo8L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwcmUgd3JhcD0iIj5JIGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21lIHByb2JsZW1zIHRv IHVuZGVyc3RhbmQgd2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0KTGV0oa9zIHRha2UgdGhlIGZvbGxv d2luZyBleGFtcGxlOg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KYT1ncm91 cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2DQoN Ck5vdywgeW91IGhhdmUgdHdvIHRyYW5zcG9ydHM6IG9uZSChsG93bmVkobEgYnkgbWlkMSBhbmQg b25lIKGwb3duZWQmcXVvdDsgYnkgbWlkNC4NCg0KDQpSZS1vZmZlcjoNCg0KYT1ncm91cDpCVU5E TEUgbWlkNCBtaWQyIG1pZDMNCmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkNSBtaWQ2DQoNCg0KSW4g dGhlIHJlLW9mZmVyLCB0aGUgb2ZmZXJlciBkb2VzIG5vdCBjaGFuZ2UgdGhlIHRyYW5zcG9ydHMg b2YgbWlkMSBhbmQNCm1pZDQgLSB0aGV5IGFyZSBzdGlsbCB0aGUgc2FtZS4gVGhlIGRpZmZlcmVu dCBpcyB0aGF0IG1pZDIgYW5kIG1pZDMgd2lsbA0Kbm93IHN0YXJ0IHVzaW5nIHRoZSB0cmFuc3Bv cnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYgd2lsbCBzdGFydCB1c2luZw0KdGhlIHRyYW5z cG9ydCBvZiBtaWQxLg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgUmlnaHQsIGJ1dCBhcyBmYXIgYXMgSSBjYW4gdGVsbCB0aGUgYnVuZGxlIHNwZWMgZG9l cyBub3QgZm9yYmlkIHRoaXM6PGJyPg0KPGJyPg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1p ZDMgJmx0Oy0tLSB1c2VzIHBvcnQgNTU1NTxicj4NCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBt aWQ2ICZsdDstLS0gdXNlcyBwb3J0IDY2NjY8YnI+DQouLi48YnI+DQptPWF1ZGlvIDU1NTUgLi4u PGJyPg0KYT1taWQ6bWlkMTxicj4NCi4uLjxicj4NCm09dmlkZW8gNjY2NiAuLi48YnI+DQphPW1p ZDptaWQ0PGJyPg0KPGJyPg0KYW5kIHRoZW4gaW4gYSByZW9mZmVyOjxicj4NCjxicj4NCmE9Z3Jv dXA6QlVORExFIDxiPm1pZDQ8L2I+IG1pZDIgbWlkMyAmbHQ7LS0tIG1pZDQgYW5kIG1pZDEgaGF2 ZSBzd2FwcGVkLi4uPGJyPg0KYT1ncm91cDpCVU5ETEUgPGI+bWlkMTwvYj4gbWlkNSBtaWQ2PGJy Pg0KLi4uPGJyPg0KbT1hdWRpbyA8Yj42NjY2PC9iPiAuLi4gJmx0Oy0tLSBidXQgdGhlIG9mZmVy ZXIgaGFzIGV4cGxpY2l0bHkgaW5kaWNhdGVkIHRoYXQgNjY2NiBpcyBhdHRhY2hlZCB0byBtaWQx IG5vdzxicj4NCmE9bWlkOm1pZDE8YnI+DQouLi48YnI+DQptPXZpZGVvIDxiPjU1NTU8L2I+IC4u Ljxicj4NCmE9bWlkOm1pZDQ8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhlIGJ1 bmRsZSBzcGVjIGFsbG93cyB0aGlzLCAmcXVvdDt0cmFuc3BvcnQgZm9sbG93cyBtLXNlY3Rpb24m cXVvdDsgaXMgbm90IHBhcnQgb2YgdGhlIHNwZWM7IHRoZSBmdW5kYW1lbnRhbCBydWxlIGlzICZx dW90O3RyYW5zcG9ydCBpcyBzaWduYWxlZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUmcXVvdDssIHdo aWNoIGlzIGltcG9zc2libGUgd2l0aCBJQ0UgdW5sZXNzIHVmcmFnIGlzIHRha2VuIGludG8gYWNj b3VudC48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsi Pg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNHB4OyBjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8YnI+DQo8L2Rp dj4NCjxkaXY+PGZvbnQgY29sb3I9IiNmZjAwMDAiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1z ZXJpZiI+TWF5YmUmbmJzcDuhsHRyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbqGxIGlzIHdyb25n IHdvcmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdy b3VwOkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFu c3BvcnQgYWxyZWFkeSBleGlzdHMgdGhlcmUgaXMgbm8gbmVlZCB0bw0KIGRvIGFuIElDRSByZXN0 YXJ0LiZuYnNwOzwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAw Ij48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAwIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPlNvLCBpbiB5b3VyIGV4YW1wbGUsIGkgdGhlIHJlb2ZmZXIgeW91IGFyZSBzdWdnZXN0 aW5nIHRoYXQgbWlkNCwgbWlkMiBhbmQgbWlkMyB1c2VzIHRoZSAmcXVvdDs1NTU1IHRyYW5zcG9y dCZxdW90Oy4gU2luY2UgdGhpcyB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMgKGl0IHdhcyBwcmV2 aW91c2x5IHVzZWQgYnkgbWlkMSwgbWlkMiBhbmQgbWlkMyksIHlvdSBkb26hr3QNCiBoYXZlIHRv IGRvIGFuIElDRSByZXN0YXJ0LjwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj48Zm9udCBjb2xvcj0iI2ZmMDAwMCI+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj5SZWdhcmRzLDwvZm9udD48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYw MDAwIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGNvbG9yPSIjZmYwMDAwIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPkNocmlzdGVyPC9mb250PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgY29sb3I9 IiNmZjAwMDAiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjwv Zm9udD48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D5CF4BF820EB3christerholmbergericssoncom_-- From nobody Fri Sep 1 07:52:00 2017 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 A9C9913421A for ; Fri, 1 Sep 2017 07:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3jjZk-sVcgGF for ; Fri, 1 Sep 2017 07:51:55 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 CB646134222 for ; Fri, 1 Sep 2017 07:51:52 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id z67so2790513iof.2 for ; Fri, 01 Sep 2017 07:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=hoJGkovlMyehEVJMFncG98voGbYoGw7W6P9Qyb3qw8Y=; b=eB26HjG5D7/sDjeNnAsB4qI9wBWv4GjHBt6jIg0bmBWmOtFyFK5aZ+DJjoJiXK94VH agqVUuXVXu2NOnB/98z4h6bdvRP+RYL2rbVH2a7JfcDIIU1myuQZORrt5Db5+Zfcy+td knb7p8E7WDNOD5OMTdkPDkz/126Xa/HpsuWYM= 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hoJGkovlMyehEVJMFncG98voGbYoGw7W6P9Qyb3qw8Y=; b=Oh1R0BXsEgZfIbpMAoYM+F/g8EmyovwBmHU5LlNZvJZp1a127hLGX1hK6hD+cNAu7a 1Xst5UcjBnSV7Wrfv2oN4G0lFfaYfc5XU6vB6U/SIIcyWhDW+qg9u5wmqjaetY9zs8b3 1laFcvivpIbh0y511CAujjbhwD6FxpR2NqSw3XPd3nivFsY1wk4/eGFtZB0YoWfIcHNK Ar5wJBBbepFTZdgD5F268g8ZwUrbyVtinXyj5b5cMl+AecrNzYy9eDp5koYDAuIRi+M3 dOQfsA7QiC9WrfXUPzJQjO4vqPaGMby/fOvcnAUvQD4vWcYNuLeI0148W1JN+4Z1PB0D EGJA== X-Gm-Message-State: AHPjjUgdBI8ab2aKxN/TdV2M3psWoflMlNYKxPg7bLjV5xoEjSgJz8Te BXPLRRGG1PrqiXHXx2qdmg== X-Google-Smtp-Source: ADKCNb5iKfAMmg1R5fBBKuzIIR1LYje9dXHSUJdbfNEeMzC4RUXEYyQpUm03xQLcuaMo+1bsFYszew== X-Received: by 10.36.99.131 with SMTP id j125mr839987itc.68.1504277511794; Fri, 01 Sep 2017 07:51:51 -0700 (PDT) Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id 200sm155350itm.8.2017.09.01.07.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 07:51:50 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> From: Byron Campen Message-ID: <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> Date: Fri, 1 Sep 2017 09:51:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6E1ED6061407E9C4C2D9506C" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 14:51:59 -0000 This is a multi-part message in MIME format. --------------6E1ED6061407E9C4C2D9506C Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/1/17 9:44 AM, Christer Holmberg wrote: > Hi, > >>>>>>>>> Alright, if we want to write a rule that the transport >>>>>>>>> follows >>>>>>>>> the >>>>>>>>> bundle, what about this? >>>>>>>>> >>>>>>>>> a=group:BUNDLE mid1 mid2 >>>>>>>>> a=group:BUNDLE mid3 mid4 >>>>>>>>> >>>>>>>>> and in a reoffer >>>>>>>>> >>>>>>>>> a=group:BUNDLE mid2 mid3 >>>>>>>>> a=group:BUNDLE mid4 mid1 >>>>>>>>> >>>>>>>>> What transport goes where? >>>>>>>> I think Taylor raised this issue earlier. What you are doing above >>>>>>>> is >>>>>>>> moving streams from one BUNDLE group to another, and mixing the >>>>>>>> BUNDLE >>>>>>>> groups up, and I don¹t think that¹s a good idea. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>> If you want to classify this as a bad idea, we need normative >>>>>>> language forbidding it. For instance, a rule that once a mid is >>>>>>> placed >>>>>>> in a bundle, the only way to remove it is to disable it, as well as a >>>>>>> rule to handle the following: >>>>>>> >>>>>>> a=group:BUNDLE mid2 mid3 >>>>>>> a=mid: mid1 <--- not bundled >>>>>>> ... >>>>>>> a=mid: mid2 >>>>>>> ... >>>>>>> a=mid: mid3 >>>>>>> >>>>>>> and in a reoffer >>>>>>> >>>>>>> a=group mid1 mid2 mid3 >>>>>>> >>>>>>> We would need to define which transport is retained; mid1's, or >>>>>>> the >>>>>>> bundle's. Or perhaps a rule forbidding previously unbundled mids to >>>>>>> be >>>>>>> added to a bundle. >>>>>> I think this is covered in section 8.5.2 (Adding a media description >>>>>> to >>>>>> a >>>>>> BUNDLE group) of BUNDLE. >>>>>> >>>>>> Assuming you are not changing the transport of the mid1 m-line, you >>>>>> are >>>>>> suggesting a new transport for the BUNDLE group (first bullet in >>>>>> section >>>>>> 8.5.2). >>>>> Right, the offerer has the choice of retaining mid1's transport, >>>>> or >>>>> keeping the old bundle transport, according to 8.5.2. If we don't do >>>>> something like adding ufrag to the transport comparison rules, 8.5.2 >>>>> would have to be tightened significantly. Again, our two choices here: >>>>> >>>>> 1. Find a way to allow an ICE offerer to indicate what transports it is >>>>> retaining (eg; ufrag). >>>> You do that using the a=group attribute. >>>> >>>> a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport >>>> of >>>> mid1 (read: you are suggesting a new transport for the BUNDLE group) >>>> >>>> a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport >>>> of >>>> mid2 (read: keep the existing BUNDLE group transport). >>>> >>>> Now, if you IN ADDITION to that wants to indicate something ICE >>>> specific, >>>> e.g, whether to do an ICE restart, I guess you could use ufrag for that. >>>> But, I don¹t think that is BUNDLE specific, is it? >>> Ok, so what you are describing is "transport follows m-section". >>> But the bundle spec doesn't _quite_ guarantee this right now, and it >>> probably shouldn't try to guarantee it either. For instance, 8.5.1 >>> describes how the offerer can suggest a new transport for the bundle, >>> any time it wants (and it could potentially be a pre-existing transport >>> "stolen" from some other bundle/m-section!); without taking something >>> like ufrag into account, this is impossible to detect in the ICE case. >> The BUNDLE groups can not use the same transport, so if someone is trying >> to offer such thing the answerer should reject the offer, or at least not >> accept the offered transports. >> >>> However, you would be completely right in saying "Well, duh, that is >>> true for non-BUNDLE also!", which is why I like the idea of fixing this >>> with ufrag, since that's how we make this work in the non-BUNDLE case. >> I guess I still have some problems to understand what the problem is. >> >> Let’s take the following example: >> >> Initial offer/answer exchange: >> >> a=group:BUNDLE mid1 mid2 mid3 >> a=group:BUNDLE mid4 mid5 mid6 >> >> Now, you have two transports: one “owned” by mid1 and one “owned" by mid4. >> >> >> Re-offer: >> >> a=group:BUNDLE mid4 mid2 mid3 >> a=group:BUNDLE mid1 mid5 mid6 >> >> >> In the re-offer, the offerer does not change the transports of mid1 and >> mid4 - they are still the same. The different is that mid2 and mid3 will >> now start using the transport of mid4, and mid5 and mid6 will start using >> the transport of mid1. > >     Right, but as far as I can tell the bundle spec does not forbid this: > > a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555 > a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666 > ... > m=audio 5555 ... > a=mid:mid1 > ... > m=video 6666 ... > a=mid:mid4 > > and then in a reoffer: > > a=group:BUNDLE *mid4* mid2 mid3 <--- mid4 and mid1 have swapped... > a=group:BUNDLE *mid1* mid5 mid6 > ... > m=audio *6666* ... <--- but the offerer has explicitly indicated that > 6666 is attached to mid1 now > a=mid:mid1 > ... > m=video *5555* ... > a=mid:mid4 > >     If the bundle spec allows this, "transport follows m-section" is > not part of the spec; the fundamental rule is "transport is signaled > explicitly every time", which is impossible with ICE unless ufrag is > taken into account. > > > Maybe “transport follows m-section” is wrong wording. Transport is > whatever the first mid in the a=group:BUNDLE attribute indicates it to > be, and if that transport already exists there is no need to do an ICE > restart. > > So, in your example, i the reoffer you are suggesting that mid4, mid2 > and mid3 uses the "5555 transport". Since this transport already > exists (it was previously used by mid1, mid2 and mid3), you don’t have > to do an ICE restart. > > Regards, > > Christer > >     Right. The offerer explicitly indicated what it wants to do, and nothing is ambiguous. I like this way of doing things. Which is why I prefer clarifying the spec to say that this explicit signaling is used in the ICE case too, rather than specifying restrictions like "transport follows m-section" to handle the ICE case. Best regards, Byron Campen --------------6E1ED6061407E9C4C2D9506C Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 9/1/17 9:44 AM, Christer Holmberg wrote:
Hi,

       Alright, if we want to write a rule that the transport
follows
the
bundle, what about this?

a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4

and in a reoffer

a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1

       What transport goes where?

I think Taylor raised this issue earlier. What you are doing above
is
moving streams from one BUNDLE group to another, and mixing the
BUNDLE
groups up, and I don¹t think that¹s a good idea.

Regards,

Christer

      If you want to classify this as a bad idea, we need normative
language forbidding it. For instance, a rule that once a mid is
placed
in a bundle, the only way to remove it is to disable it, as well as a
rule to handle the following:

a=group:BUNDLE mid2 mid3
a=mid: mid1 <--- not bundled
...
a=mid: mid2
...
a=mid: mid3

and in a reoffer

a=group mid1 mid2 mid3

      We would need to define which transport is retained; mid1's, or
the
bundle's. Or perhaps a rule forbidding previously unbundled mids to
be
added to a bundle.

I think this is covered in section 8.5.2 (Adding a media description
to
a
BUNDLE group) of BUNDLE.

Assuming you are not changing the transport of the mid1 m-line, you
are
suggesting a new transport for the BUNDLE group (first bullet in
section
8.5.2).

     Right, the offerer has the choice of retaining mid1's transport,
or
keeping the old bundle transport, according to 8.5.2. If we don't do
something like adding ufrag to the transport comparison rules, 8.5.2
would have to be tightened significantly. Again, our two choices here:

1. Find a way to allow an ICE offerer to indicate what transports it is
retaining (eg; ufrag).

You do that using the a=group attribute.

a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport
of
mid1 (read: you are suggesting a new transport for the BUNDLE group)

a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport
of
mid2 (read: keep the existing BUNDLE group transport).

Now, if you IN ADDITION to that wants to indicate something ICE
specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don¹t think that is BUNDLE specific, is it?

    Ok, so what you are describing is "transport follows m-section".
But the bundle spec doesn't _quite_ guarantee this right now, and it
probably shouldn't try to guarantee it either. For instance, 8.5.1
describes how the offerer can suggest a new transport for the bundle,
any time it wants (and it could potentially be a pre-existing transport
"stolen" from some other bundle/m-section!); without taking something
like ufrag into account, this is impossible to detect in the ICE case.

The BUNDLE groups can not use the same transport, so if someone is trying
to offer such thing the answerer should reject the offer, or at least not
accept the offered transports.


However, you would be completely right in saying "Well, duh, that is
true for non-BUNDLE also!", which is why I like the idea of fixing this
with ufrag, since that's how we make this work in the non-BUNDLE case.

I guess I still have some problems to understand what the problem is.

Let’s take the following example:

Initial offer/answer exchange:

a=group:BUNDLE mid1 mid2 mid3
a=group:BUNDLE mid4 mid5 mid6

Now, you have two transports: one “owned” by mid1 and one “owned" by mid4.


Re-offer:

a=group:BUNDLE mid4 mid2 mid3
a=group:BUNDLE mid1 mid5 mid6


In the re-offer, the offerer does not change the transports of mid1 and
mid4 - they are still the same. The different is that mid2 and mid3 will
now start using the transport of mid4, and mid5 and mid6 will start using
the transport of mid1.

    Right, but as far as I can tell the bundle spec does not forbid this:

a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555
a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666
...
m=audio 5555 ...
a=mid:mid1
...
m=video 6666 ...
a=mid:mid4

and then in a reoffer:

a=group:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped...
a=group:BUNDLE mid1 mid5 mid6
...
m=audio 6666 ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now
a=mid:mid1
...
m=video 5555 ...
a=mid:mid4

    If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account.


Maybe “transport follows m-section” is wrong wording. Transport is whatever the first mid in the a=group:BUNDLE attribute indicates it to be, and if that transport already exists there is no need to do an ICE restart. 

So, in your example, i the reoffer you are suggesting that mid4, mid2 and mid3 uses the "5555 transport". Since this transport already exists (it was previously used by mid1, mid2 and mid3), you don’t have to do an ICE restart.

Regards,

Christer


    Right. The offerer explicitly indicated what it wants to do, and nothing is ambiguous. I like this way of doing things. Which is why I prefer clarifying the spec to say that this explicit signaling is used in the ICE case too, rather than specifying restrictions like "transport follows m-section" to handle the ICE case.


Best regards,

Byron Campen

--------------6E1ED6061407E9C4C2D9506C-- From nobody Fri Sep 1 09:21:33 2017 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 2B7D8132E5F for ; Fri, 1 Sep 2017 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0eDs_qy_hEY for ; Fri, 1 Sep 2017 09:21:29 -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 68BB5132FFB for ; Fri, 1 Sep 2017 09:21:28 -0700 (PDT) X-AuditID: c1b4fb25-d31059c000005333-99-59a98906e92a Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.5F.21299.60989A95; Fri, 1 Sep 2017 18:21:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 18:21:13 +0200 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqID///SaAIABesMA///wJ4CAAEZzAP//zm+A///G18A= Date: Fri, 1 Sep 2017 16:21:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> In-Reply-To: <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CD1246BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7hy5b58pIgyendC0W3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGthcPGAuO3WSsmHhtAnMD 44vLjF2MnBwSAiYSX3ZuY+li5OIQEjjCKDHn/CcoZzGjRMP6hcxdjBwcbAIWEt3/tEEaRASK JM4c28IEEhYWcJSYME8IxBQRcJL41RAN0iki0MUoMeNlFytIOYuAisTu/YvZQGxeAV+JM/Ne QY1/zypxaN03JpAEp4C9xM+232AHMQqISXw/tQYsziwgLnHryXwmiEMFJJbsOc8MYYtKvHz8 jxXCVpJYsf0SI0R9vkTXiyYWiGWCEidnPmGZwCg8C8moWUjKZiEpmwX0A7OApsT6XfoQJYoS U7ofskPYGhKtc+ayI4svYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYUwe3/FbdwXj5 jeMhRgEORiUe3g/lKyOFWBPLiitzDzFKcDArifBWtgKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ 8zruuxAhJJCeWJKanZpakFoEk2Xi4JRqYEzYkjN7ZXeOV8miZzPmTGffNFd2t9olJwODiTMr tb51+C18ycVaJW2U5hJdyXxf/1nS12rnIjuJQ0xLFzUICncsO1IRHv2Eb8+p8oxIf5tdC4VM /ydccvrK6/Aq/4SjReOurTbt0j841JbEn7GYtuKQDMNahSccopsv1T4tmd186PKSNU0LC5RY ijMSDbWYi4oTAZzvc++lAgAA Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 16:21:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CD1246BESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhpLA0KDQoNCiAgICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVs ZSB0aGF0IHRoZSB0cmFuc3BvcnQNCg0KZm9sbG93cw0KDQp0aGUNCg0KYnVuZGxlLCB3aGF0IGFi b3V0IHRoaXM/DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDINCg0KYT1ncm91cDpCVU5E TEUgbWlkMyBtaWQ0DQoNCg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwOkJVTkRM RSBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQoNCg0KDQogICAgICAgV2hh dCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8NCg0KSSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNz dWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlDQoNCmlzDQoNCm1vdmluZyBzdHJl YW1zIGZyb20gb25lIEJVTkRMRSBncm91cCB0byBhbm90aGVyLCBhbmQgbWl4aW5nIHRoZQ0KDQpC VU5ETEUNCg0KZ3JvdXBzIHVwLCBhbmQgSSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRl YS4NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQogICAgICBJZiB5b3Ugd2FudCB0 byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQoNCmxhbmd1 YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBp cw0KDQpwbGFjZWQNCg0KaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMg dG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBhcyBhDQoNCnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dp bmc6DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCg0KYT1taWQ6IG1pZDEgPC0tLSBu b3QgYnVuZGxlZA0KDQouLi4NCg0KYT1taWQ6IG1pZDINCg0KLi4uDQoNCmE9bWlkOiBtaWQzDQoN Cg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCg0K DQogICAgICBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWlu ZWQ7IG1pZDEncywgb3INCg0KdGhlDQoNCmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3Ji aWRkaW5nIHByZXZpb3VzbHkgdW5idW5kbGVkIG1pZHMgdG8NCg0KYmUNCg0KYWRkZWQgdG8gYSBi dW5kbGUuDQoNCkkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGlu ZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQoNCnRvDQoNCmENCg0KQlVORExFIGdyb3VwKSBvZiBCVU5E TEUuDQoNCg0KDQpBc3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9m IHRoZSBtaWQxIG0tbGluZSwgeW91DQoNCmFyZQ0KDQpzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9y dCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluDQoNCnNlY3Rpb24NCg0KOC41 LjIpLg0KDQogICAgIFJpZ2h0LCB0aGUgb2ZmZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5p bmcgbWlkMSdzIHRyYW5zcG9ydCwNCg0Kb3INCg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFu c3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG8NCg0Kc29tZXRoaW5nIGxp a2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjIN Cg0Kd291bGQgaGF2ZSB0byBiZSB0aWdodGVuZWQgc2lnbmlmaWNhbnRseS4gQWdhaW4sIG91ciB0 d28gY2hvaWNlcyBoZXJlOg0KDQoNCg0KMS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2Zm ZXJlciB0byBpbmRpY2F0ZSB3aGF0IHRyYW5zcG9ydHMgaXQgaXMNCg0KcmV0YWluaW5nIChlZzsg dWZyYWcpLg0KDQpZb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCg0K DQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVz ZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoNCm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBh IG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApDQoNCg0KDQphPWdyb3VwOkJVTkVM RSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0 DQoNCm9mDQoNCm1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFu c3BvcnQpLg0KDQoNCg0KTm93LCBpZiB5b3UgSU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBp bmRpY2F0ZSBzb21ldGhpbmcgSUNFDQoNCnNwZWNpZmljLA0KDQplLmcsIHdoZXRoZXIgdG8gZG8g YW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCg0K QnV0LCBJIGRvbsK5dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/DQoNCiAg ICBPaywgc28gd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgInRyYW5zcG9ydCBmb2xsb3dzIG0t c2VjdGlvbiIuDQoNCkJ1dCB0aGUgYnVuZGxlIHNwZWMgZG9lc24ndCBfcXVpdGVfIGd1YXJhbnRl ZSB0aGlzIHJpZ2h0IG5vdywgYW5kIGl0DQoNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3Vh cmFudGVlIGl0IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUuMQ0KDQpkZXNjcmliZXMgaG93IHRo ZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSwNCg0K YW55IHRpbWUgaXQgd2FudHMgKGFuZCBpdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIHByZS1leGlz dGluZyB0cmFuc3BvcnQNCg0KInN0b2xlbiIgZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rp b24hKTsgd2l0aG91dCB0YWtpbmcgc29tZXRoaW5nDQoNCmxpa2UgdWZyYWcgaW50byBhY2NvdW50 LCB0aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS4NCg0KVGhlIEJV TkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25l IGlzIHRyeWluZw0KDQp0byBvZmZlciBzdWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVq ZWN0IHRoZSBvZmZlciwgb3IgYXQgbGVhc3Qgbm90DQoNCmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFu c3BvcnRzLg0KDQoNCg0KSG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4g c2F5aW5nICJXZWxsLCBkdWgsIHRoYXQgaXMNCg0KdHJ1ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIs IHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhlIGlkZWEgb2YgZml4aW5nIHRoaXMNCg0Kd2l0aCB1ZnJh Zywgc2luY2UgdGhhdCdzIGhvdyB3ZSBtYWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBj YXNlLg0KDQpJIGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQg d2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0KDQoNCkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4 YW1wbGU6DQoNCg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KDQoNCmE9Z3Jv dXA6QlVORExFIG1pZDEgbWlkMiBtaWQzDQoNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2 DQoNCg0KDQpOb3csIHlvdSBoYXZlIHR3byB0cmFuc3BvcnRzOiBvbmUg4oCcb3duZWTigJ0gYnkg bWlkMSBhbmQgb25lIOKAnG93bmVkIiBieSBtaWQ0Lg0KDQoNCg0KDQoNClJlLW9mZmVyOg0KDQoN Cg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBt aWQ1IG1pZDYNCg0KDQoNCg0KDQpJbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90 IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZA0KDQptaWQ0IC0gdGhleSBhcmUgc3Rp bGwgdGhlIHNhbWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCg0K bm93IHN0YXJ0IHVzaW5nIHRoZSB0cmFuc3BvcnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYg d2lsbCBzdGFydCB1c2luZw0KDQp0aGUgdHJhbnNwb3J0IG9mIG1pZDEuDQoNCiAgICBSaWdodCwg YnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQg dGhpczoNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMgPC0tLSB1c2VzIHBvcnQgNTU1 NQ0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQ1IG1pZDYgPC0tLSB1c2VzIHBvcnQgNjY2Ng0KLi4u DQptPWF1ZGlvIDU1NTUgLi4uDQphPW1pZDptaWQxDQouLi4NCm09dmlkZW8gNjY2NiAuLi4NCmE9 bWlkOm1pZDQNCg0KYW5kIHRoZW4gaW4gYSByZW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0 IG1pZDIgbWlkMyA8LS0tIG1pZDQgYW5kIG1pZDEgaGF2ZSBzd2FwcGVkLi4uDQphPWdyb3VwOkJV TkRMRSBtaWQxIG1pZDUgbWlkNg0KLi4uDQptPWF1ZGlvIDY2NjYgLi4uIDwtLS0gYnV0IHRoZSBv ZmZlcmVyIGhhcyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8g bWlkMSBub3cNCmE9bWlkOm1pZDENCi4uLg0KbT12aWRlbyA1NTU1IC4uLg0KYT1taWQ6bWlkNA0K DQogICAgSWYgdGhlIGJ1bmRsZSBzcGVjIGFsbG93cyB0aGlzLCAidHJhbnNwb3J0IGZvbGxvd3Mg bS1zZWN0aW9uIiBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUg aXMgInRyYW5zcG9ydCBpcyBzaWduYWxlZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUiLCB3aGljaCBp cyBpbXBvc3NpYmxlIHdpdGggSUNFIHVubGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQu DQoNCg0KTWF5YmUg4oCcdHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdv cmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3Vw OkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3Bv cnQgYWxyZWFkeSBleGlzdHMgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4N Cg0KU28sIGluIHlvdXIgZXhhbXBsZSwgaSB0aGUgcmVvZmZlciB5b3UgYXJlIHN1Z2dlc3Rpbmcg dGhhdCBtaWQ0LCBtaWQyIGFuZCBtaWQzIHVzZXMgdGhlICI1NTU1IHRyYW5zcG9ydCIuIFNpbmNl IHRoaXMgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5 IG1pZDEsIG1pZDIgYW5kIG1pZDMpLCB5b3UgZG9u4oCZdCBoYXZlIHRvIGRvIGFuIElDRSByZXN0 YXJ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KICAgIFJpZ2h0LiBUaGUgb2ZmZXJl ciBleHBsaWNpdGx5IGluZGljYXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBp cyBhbWJpZ3VvdXMuIEkgbGlrZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdo eSBJIHByZWZlciBjbGFyaWZ5aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQg c2lnbmFsaW5nIGlzIHVzZWQgaW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lm eWluZyByZXN0cmljdGlvbnMgbGlrZSAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiB0byBo YW5kbGUgdGhlIElDRSBjYXNlLg0KSSB0b3RhbGx5IGFncmVlIOKAkyB0aGUgdHJhbnNwb3J0IGhh cyB0byBiZSBleHBsaWNpdGx5IGluZGljYXRlZC4gQnV0LCBkb27igJl0IHRoZSBJQ0UgU0RQIGF0 dHJpYnV0ZXMgYWxyZWFkeSBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB0cmFuc3BvcnQ/DQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CD1246BESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0Ii IGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0Nztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkhpLDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRv IHdyaXRlIGEgcnVsZSB0aGF0IHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5m b2xsb3dzPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ YnVuZGxlLCB3aGF0IGFib3V0IHRoaXM/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyPG86cD48L286cD48 L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMyBtaWQ0PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+YW5kIGluIGEgcmVvZmZlcjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVO RExFIG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDQg bWlkMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXaGF0IHRyYW5zcG9ydCBnb2Vz IHdoZXJlPzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkkgdGhpbmsgVGF5 bG9yIHJhaXNlZCB0aGlzIGlzc3VlIGVhcmxpZXIuIFdoYXQgeW91IGFyZSBkb2luZyBhYm92ZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlzPG86cD48L286cD48L3ByZT4NCjxwcmU+bW92aW5nIHN0 cmVhbXMgZnJvbSBvbmUgQlVORExFIGdyb3VwIHRvIGFub3RoZXIsIGFuZCBtaXhpbmcgdGhlPG86 cD48L286cD48L3ByZT4NCjxwcmU+QlVORExFPG86cD48L286cD48L3ByZT4NCjxwcmU+Z3JvdXBz IHVwLCBhbmQgSSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNocmlzdGVyPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IElmIHlvdSB3YW50IHRvIGNsYXNzaWZ5IHRoaXMgYXMgYSBiYWQgaWRlYSwgd2Ug bmVlZCBub3JtYXRpdmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5sYW5ndWFnZSBmb3JiaWRkaW5n IGl0LiBGb3IgaW5zdGFuY2UsIGEgcnVsZSB0aGF0IG9uY2UgYSBtaWQgaXM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5wbGFjZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbiBhIGJ1bmRsZSwgdGhl IG9ubHkgd2F5IHRvIHJlbW92ZSBpdCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxsIGFzIGE8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5ydWxlIHRvIGhhbmRsZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVO RExFIG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9bWlkOiBtaWQxICZsdDstLS0g bm90IGJ1bmRsZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5hPW1pZDogbWlkMjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmE9bWlkOiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+YW5kIGluIGEgcmVvZmZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXAgbWlkMSBtaWQyIG1pZDM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2Ugd291bGQgbmVlZCB0byBkZWZpbmUgd2hpY2ggdHJh bnNwb3J0IGlzIHJldGFpbmVkOyBtaWQxJ3MsIG9yPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhl PG86cD48L286cD48L3ByZT4NCjxwcmU+YnVuZGxlJ3MuIE9yIHBlcmhhcHMgYSBydWxlIGZvcmJp ZGRpbmcgcHJldmlvdXNseSB1bmJ1bmRsZWQgbWlkcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmJlPG86cD48L286cD48L3ByZT4NCjxwcmU+YWRkZWQgdG8gYSBidW5kbGUuPG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSB0aGluayB0aGlzIGlzIGNvdmVyZWQgaW4gc2Vj dGlvbiA4LjUuMiAoQWRkaW5nIGEgbWVkaWEgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcHJlPg0K PHByZT50bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5C VU5ETEUgZ3JvdXApIG9mIEJVTkRMRS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5Bc3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJh bnNwb3J0IG9mIHRoZSBtaWQxIG0tbGluZSwgeW91PG86cD48L286cD48L3ByZT4NCjxwcmU+YXJl PG86cD48L286cD48L3ByZT4NCjxwcmU+c3VnZ2VzdGluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRo ZSBCVU5ETEUgZ3JvdXAgKGZpcnN0IGJ1bGxldCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNl Y3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT44LjUuMikuPG86cD48L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCB0aGUgb2Zm ZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5pbmcgbWlkMSdzIHRyYW5zcG9ydCw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5vcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmtlZXBpbmcgdGhlIG9s ZCBidW5kbGUgdHJhbnNwb3J0LCBhY2NvcmRpbmcgdG8gOC41LjIuIElmIHdlIGRvbid0IGRvPG86 cD48L286cD48L3ByZT4NCjxwcmU+c29tZXRoaW5nIGxpa2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0 cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53 b3VsZCBoYXZlIHRvIGJlIHRpZ2h0ZW5lZCBzaWduaWZpY2FudGx5LiBBZ2Fpbiwgb3VyIHR3byBj aG9pY2VzIGhlcmU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+MS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2ZmZXJlciB0byBpbmRpY2F0 ZSB3aGF0IHRyYW5zcG9ydHMgaXQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXRhaW5pbmcg KGVnOyB1ZnJhZykuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+WW91IGRv IHRoYXQgdXNpbmcgdGhlIGE9Z3JvdXAgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMiBt aWQzIG1lYW5zIHRoYXQgeW91IHdhbnQgdG8gdXNlIHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5vZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1pZDEgKHJlYWQ6IHlvdSBhcmUg c3VnZ2VzdGluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5F TEUgbWlkMiBtaWQzIG1pZTEgbWVhbnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIHRyYW5zcG9y dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlkMiAo cmVhZDoga2VlcCB0aGUgZXhpc3RpbmcgQlVORExFIGdyb3VwIHRyYW5zcG9ydCkuPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Tm93LCBpZiB5b3Ug SU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBpbmRpY2F0ZSBzb21ldGhpbmcgSUNFPG86cD48 L286cD48L3ByZT4NCjxwcmU+c3BlY2lmaWMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZS5nLCB3 aGV0aGVyIHRvIGRvIGFuIElDRSByZXN0YXJ0LCBJIGd1ZXNzIHlvdSBjb3VsZCB1c2UgdWZyYWcg Zm9yIHRoYXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+QnV0LCBJIGRvbsK5dCB0aGluayB0aGF0 IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9rLCBzbyB3aGF0IHlvdSBhcmUgZGVzY3JpYmlu ZyBpcyAmcXVvdDt0cmFuc3BvcnQgZm9sbG93cyBtLXNlY3Rpb24mcXVvdDsuPG86cD48L286cD48 L3ByZT4NCjxwcmU+QnV0IHRoZSBidW5kbGUgc3BlYyBkb2Vzbid0IF9xdWl0ZV8gZ3VhcmFudGVl IHRoaXMgcmlnaHQgbm93LCBhbmQgaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm9iYWJseSBz aG91bGRuJ3QgdHJ5IHRvIGd1YXJhbnRlZSBpdCBlaXRoZXIuIEZvciBpbnN0YW5jZSwgOC41LjE8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZXNjcmliZXMgaG93IHRoZSBvZmZlcmVyIGNhbiBzdWdn ZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5hbnkgdGltZSBpdCB3YW50cyAoYW5kIGl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGEgcHJlLWV4 aXN0aW5nIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O3N0b2xlbiZxdW90 OyBmcm9tIHNvbWUgb3RoZXIgYnVuZGxlL20tc2VjdGlvbiEpOyB3aXRob3V0IHRha2luZyBzb21l dGhpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5saWtlIHVmcmFnIGludG8gYWNjb3VudCwgdGhp cyBpcyBpbXBvc3NpYmxlIHRvIGRldGVjdCBpbiB0aGUgSUNFIGNhc2UuPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+VGhlIEJVTkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhl IHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25lIGlzIHRyeWluZzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnRvIG9mZmVyIHN1Y2ggdGhpbmcgdGhlIGFuc3dlcmVyIHNob3VsZCByZWplY3QgdGhl IG9mZmVyLCBvciBhdCBsZWFzdCBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hY2NlcHQgdGhl IG9mZmVyZWQgdHJhbnNwb3J0cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cHJlPkhvd2V2ZXIsIHlvdSB3b3VsZCBiZSBjb21wbGV0ZWx5IHJpZ2h0 IGluIHNheWluZyAmcXVvdDtXZWxsLCBkdWgsIHRoYXQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT50cnVlIGZvciBub24tQlVORExFIGFsc28hJnF1b3Q7LCB3aGljaCBpcyB3aHkgSSBsaWtlIHRo ZSBpZGVhIG9mIGZpeGluZyB0aGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+d2l0aCB1ZnJhZywg c2luY2UgdGhhdCdzIGhvdyB3ZSBtYWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBjYXNl LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkkgZ3Vlc3MgSSBzdGlsbCBo YXZlIHNvbWUgcHJvYmxlbXMgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBwcm9ibGVtIGlzLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkxldOKAmXMg dGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+SW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2U6PG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+YT1ncm91 cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJV TkRMRSBtaWQ0IG1pZDUgbWlkNjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPk5vdywgeW91IGhhdmUgdHdvIHRyYW5zcG9ydHM6IG9uZSDigJxvd25l ZOKAnSBieSBtaWQxIGFuZCBvbmUg4oCcb3duZWQmcXVvdDsgYnkgbWlkNC48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5SZS1vZmZlcjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDIgbWlkMzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkNSBtaWQ2PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+SW4gdGhlIHJlLW9mZmVyLCB0aGUgb2ZmZXJlciBkb2VzIG5vdCBjaGFu Z2UgdGhlIHRyYW5zcG9ydHMgb2YgbWlkMSBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5taWQ0 IC0gdGhleSBhcmUgc3RpbGwgdGhlIHNhbWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFu ZCBtaWQzIHdpbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ub3cgc3RhcnQgdXNpbmcgdGhlIHRy YW5zcG9ydCBvZiBtaWQ0LCBhbmQgbWlkNSBhbmQgbWlkNiB3aWxsIHN0YXJ0IHVzaW5nPG86cD48 L286cD48L3ByZT4NCjxwcmU+dGhlIHRyYW5zcG9ydCBvZiBtaWQxLjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBSaWdodCwgYnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRo ZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQgdGhpczo8YnI+DQo8YnI+DQphPWdyb3VwOkJV TkRMRSBtaWQxIG1pZDIgbWlkMyAmbHQ7LS0tIHVzZXMgcG9ydCA1NTU1PGJyPg0KYT1ncm91cDpC VU5ETEUgbWlkNCBtaWQ1IG1pZDYgJmx0Oy0tLSB1c2VzIHBvcnQgNjY2Njxicj4NCi4uLjxicj4N Cm09YXVkaW8gNTU1NSAuLi48YnI+DQphPW1pZDptaWQxPGJyPg0KLi4uPGJyPg0KbT12aWRlbyA2 NjY2IC4uLjxicj4NCmE9bWlkOm1pZDQ8YnI+DQo8YnI+DQphbmQgdGhlbiBpbiBhIHJlb2ZmZXI6 PGJyPg0KPGJyPg0KYT1ncm91cDpCVU5ETEUgPGI+bWlkNDwvYj4gbWlkMiBtaWQzICZsdDstLS0g bWlkNCBhbmQgbWlkMSBoYXZlIHN3YXBwZWQuLi48YnI+DQphPWdyb3VwOkJVTkRMRSA8Yj5taWQx PC9iPiBtaWQ1IG1pZDY8YnI+DQouLi48YnI+DQptPWF1ZGlvIDxiPjY2NjY8L2I+IC4uLiAmbHQ7 LS0tIGJ1dCB0aGUgb2ZmZXJlciBoYXMgZXhwbGljaXRseSBpbmRpY2F0ZWQgdGhhdCA2NjY2IGlz IGF0dGFjaGVkIHRvIG1pZDEgbm93PGJyPg0KYT1taWQ6bWlkMTxicj4NCi4uLjxicj4NCm09dmlk ZW8gPGI+NTU1NTwvYj4gLi4uPGJyPg0KYT1taWQ6bWlkNDxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyBJZiB0aGUgYnVuZGxlIHNwZWMgYWxsb3dzIHRoaXMsICZxdW90O3RyYW5zcG9ydCBm b2xsb3dzIG0tc2VjdGlvbiZxdW90OyBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRh bWVudGFsIHJ1bGUgaXMgJnF1b3Q7dHJhbnNwb3J0IGlzIHNpZ25hbGVkIGV4cGxpY2l0bHkgZXZl cnkgdGltZSZxdW90Oywgd2hpY2ggaXMgaW1wb3NzaWJsZSB3aXRoIElDRSB1bmxlc3MgdWZyYWcg aXMgdGFrZW4gaW50byBhY2NvdW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5NYXliZSZuYnNwO+KAnHRyYW5z cG9ydCBmb2xsb3dzIG0tc2VjdGlvbuKAnSBpcyB3cm9uZyB3b3JkaW5nLiBUcmFuc3BvcnQgaXMg d2hhdGV2ZXIgdGhlIGZpcnN0IG1pZCBpbiB0aGUgYT1ncm91cDpCVU5ETEUgYXR0cmlidXRlIGlu ZGljYXRlcyBpdCB0byBiZSwgYW5kIGlmIHRoYXQgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzDQog dGhlcmUgaXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVk Ij5TbywgaW4geW91ciBleGFtcGxlLCBpIHRoZSByZW9mZmVyIHlvdSBhcmUgc3VnZ2VzdGluZyB0 aGF0IG1pZDQsIG1pZDIgYW5kIG1pZDMgdXNlcyB0aGUgJnF1b3Q7NTU1NSB0cmFuc3BvcnQmcXVv dDsuIFNpbmNlIHRoaXMgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNs eSB1c2VkIGJ5IG1pZDEsIG1pZDINCiBhbmQgbWlkMyksIHlvdSBkb27igJl0IGhhdmUgdG8gZG8g YW4gSUNFIHJlc3RhcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5DaHJp c3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw PiZuYnNwOyZuYnNwOyZuYnNwOyBSaWdodC4gVGhlIG9mZmVyZXIgZXhwbGljaXRseSBpbmRpY2F0 ZWQgd2hhdCBpdCB3YW50cyB0byBkbywgYW5kIG5vdGhpbmcgaXMgYW1iaWd1b3VzLiBJIGxpa2Ug dGhpcyB3YXkgb2YgZG9pbmcgdGhpbmdzLiBXaGljaCBpcyB3aHkgSSBwcmVmZXIgY2xhcmlmeWlu ZyB0aGUgc3BlYyB0byBzYXkgdGhhdCB0aGlzIGV4cGxpY2l0IHNpZ25hbGluZyBpcyB1c2VkIGlu IHRoZSBJQ0UgY2FzZSB0b28sIHJhdGhlciB0aGFuIHNwZWNpZnlpbmcNCiByZXN0cmljdGlvbnMg bGlrZSAmcXVvdDt0cmFuc3BvcnQgZm9sbG93cyBtLXNlY3Rpb24mcXVvdDsgdG8gaGFuZGxlIHRo ZSBJQ0UgY2FzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRvdGFs bHkgYWdyZWUg4oCTIHRoZSB0cmFuc3BvcnQgaGFzIHRvIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVk LiBCdXQsIGRvbuKAmXQgdGhlIElDRSBTRFAgYXR0cmlidXRlcyBhbHJlYWR5IGV4cGxpY2l0bHkg aW5kaWNhdGUgdGhlIHRyYW5zcG9ydD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0Nzttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CD1246BESESSMB109erics_-- From nobody Fri Sep 1 09:34:30 2017 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 0C1641341C9 for ; Fri, 1 Sep 2017 09:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 C7KxnelKTkbr for ; Fri, 1 Sep 2017 09:34:26 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 E300B1323B5 for ; Fri, 1 Sep 2017 09:34:24 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id t75so6062961oie.3 for ; Fri, 01 Sep 2017 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=YAXogHqDtYs+xdnDQOe55U+NKqkcT8zzn2UUQ8rrMQA=; b=gkHWOZfW/QeG8qtKQhfcMXSscqdia8vi6mYh8il3Oi93OdjfXvR0rFQn9moEgteat7 kqTCLuAxNPsb+JmnhxHlQBg9x+A2sW1xI19x1tb2q1UkSHUuuidaRj8gvOpbaJoTug3b khTZdzJdeyPIrwGUg+UbevYGQbDqiQAdaDbho= 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=YAXogHqDtYs+xdnDQOe55U+NKqkcT8zzn2UUQ8rrMQA=; b=fS6HKUSl+b/dEnuxjja29xd3VZv3srginifg31Fst3XFAFbx61O13VN/38IDh/FsNH gzl9LKBxGo+rBzHTUtQtS+bq/HRFC/OXQUPPHObv8pFYboRItUBvJcSQDIPYUDYgkK5b 5PRD2vU1/pAXyugv95dMaeX+u79l/GvyF/H1ze4EsRhrNgM3fRDkU6rkY5XRxOim3vJi 2mVwru+bwRyL4yXFCnwUInXOdWuncD4h7g1pEJnVfXh0WznavO6qhhaABzkqZXAnylb+ 3CuOZHWKmd4eAqyzBIboMevisjzjbv8GoBCcP4x7vcp9KqI60xEZwwMdQoUj/moQ06uq x1yQ== X-Gm-Message-State: AHPjjUiPEiVbUPrv6ncpsRqBD2fgzLY3MHhTb6cQ577oE6TQ8SXs6+q/ LAsWorcsBu5KCG3Cp7C09w== X-Google-Smtp-Source: ADKCNb6dt0WV8MFt/xRzlZ6Frc4avCBLeqchkdWKvlV1bL4brkeWGYbNLKtCceWepni5dphEy2p+Ag== X-Received: by 10.202.95.213 with SMTP id t204mr903722oib.287.1504283663825; Fri, 01 Sep 2017 09:34:23 -0700 (PDT) Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id u132sm512895oig.34.2017.09.01.09.34.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 09:34:23 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> From: Byron Campen Message-ID: Date: Fri, 1 Sep 2017 11:34:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------844FBB8B22855BFF68A8973E" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 16:34:29 -0000 This is a multi-part message in MIME format. --------------844FBB8B22855BFF68A8973E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/1/17 11:21 AM, Christer Holmberg wrote: > > Hi, > > Hi, > >        Alright, if we want to write a rule that the transport > > follows > > the > > bundle, what about this? > > a=group:BUNDLE mid1 mid2 > > a=group:BUNDLE mid3 mid4 > > and in a reoffer > > a=group:BUNDLE mid2 mid3 > > a=group:BUNDLE mid4 mid1 > >        What transport goes where? > > I think Taylor raised this issue earlier. What you are doing above > > is > > moving streams from one BUNDLE group to another, and mixing the > > BUNDLE > > groups up, and I don¹t think that¹s a good idea. > > Regards, > > Christer > >       If you want to classify this as a bad idea, we need normative > > language forbidding it. For instance, a rule that once a mid is > > placed > > in a bundle, the only way to remove it is to disable it, as well as a > > rule to handle the following: > > a=group:BUNDLE mid2 mid3 > > a=mid: mid1 <--- not bundled > > ... > > a=mid: mid2 > > ... > > a=mid: mid3 > > and in a reoffer > > a=group mid1 mid2 mid3 > >       We would need to define which transport is retained; mid1's, or > > the > > bundle's. Or perhaps a rule forbidding previously unbundled mids to > > be > > added to a bundle. > > I think this is covered in section 8.5.2 (Adding a media description > > to > > a > > BUNDLE group) of BUNDLE. > > Assuming you are not changing the transport of the mid1 m-line, you > > are > > suggesting a new transport for the BUNDLE group (first bullet in > > section > > 8.5.2). > >      Right, the offerer has the choice of retaining mid1's transport, > > or > > keeping the old bundle transport, according to 8.5.2. If we don't do > > something like adding ufrag to the transport comparison rules, 8.5.2 > > would have to be tightened significantly. Again, our two choices here: > > 1. Find a way to allow an ICE offerer to indicate what transports it is > > retaining (eg; ufrag). > > You do that using the a=group attribute. > > a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport > > of > > mid1 (read: you are suggesting a new transport for the BUNDLE group) > > a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport > > of > > mid2 (read: keep the existing BUNDLE group transport). > > Now, if you IN ADDITION to that wants to indicate something ICE > > specific, > > e.g, whether to do an ICE restart, I guess you could use ufrag for that. > > But, I don¹t think that is BUNDLE specific, is it? > >     Ok, so what you are describing is "transport follows m-section". > > But the bundle spec doesn't _quite_ guarantee this right now, and it > > probably shouldn't try to guarantee it either. For instance, 8.5.1 > > describes how the offerer can suggest a new transport for the bundle, > > any time it wants (and it could potentially be a pre-existing transport > > "stolen" from some other bundle/m-section!); without taking something > > like ufrag into account, this is impossible to detect in the ICE case. > > The BUNDLE groups can not use the same transport, so if someone is trying > > to offer such thing the answerer should reject the offer, or at least not > > accept the offered transports. > > However, you would be completely right in saying "Well, duh, that is > > true for non-BUNDLE also!", which is why I like the idea of fixing this > > with ufrag, since that's how we make this work in the non-BUNDLE case. > > I guess I still have some problems to understand what the problem is. > > Let’s take the following example: > > Initial offer/answer exchange: > > a=group:BUNDLE mid1 mid2 mid3 > > a=group:BUNDLE mid4 mid5 mid6 > > Now, you have two transports: one “owned” by mid1 and one “owned" by mid4. > > Re-offer: > > a=group:BUNDLE mid4 mid2 mid3 > > a=group:BUNDLE mid1 mid5 mid6 > > In the re-offer, the offerer does not change the transports of mid1 and > > mid4 - they are still the same. The different is that mid2 and mid3 will > > now start using the transport of mid4, and mid5 and mid6 will start using > > the transport of mid1. > > >     Right, but as far as I can tell the bundle spec does not > forbid this: > > a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555 > a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666 > ... > m=audio 5555 ... > a=mid:mid1 > ... > m=video 6666 ... > a=mid:mid4 > > and then in a reoffer: > > a=group:BUNDLE *mid4* mid2 mid3 <--- mid4 and mid1 have swapped... > a=group:BUNDLE *mid1* mid5 mid6 > ... > m=audio *6666* ... <--- but the offerer has explicitly indicated > that 6666 is attached to mid1 now > a=mid:mid1 > ... > m=video *5555* ... > a=mid:mid4 > >     If the bundle spec allows this, "transport follows m-section" > is not part of the spec; the fundamental rule is "transport is > signaled explicitly every time", which is impossible with ICE > unless ufrag is taken into account. > > Maybe “transport follows m-section” is wrong wording. Transport is > whatever the first mid in the a=group:BUNDLE attribute indicates > it to be, and if that transport already exists there is no need to > do an ICE restart. > > So, in your example, i the reoffer you are suggesting that mid4, > mid2 and mid3 uses the "5555 transport". Since this transport > already exists (it was previously used by mid1, mid2 and mid3), > you don’t have to do an ICE restart. > > Regards, > > Christer > >     Right. The offerer explicitly indicated what it wants to do, and > nothing is ambiguous. I like this way of doing things. Which is why I > prefer clarifying the spec to say that this explicit signaling is used > in the ICE case too, rather than specifying restrictions like > "transport follows m-section" to handle the ICE case. > > I totally agree – the transport has to be explicitly indicated. But, > don’t the ICE SDP attributes already explicitly indicate the transport? >     Sadly, not quite, because there's no clear requirement right now that the ufrag is different for each transport (and indeed it has not been implemented that way by Chrome or Firefox). That's what I'm advocating fixing, instead of adding a bunch of new rules for bundle with ICE. Best regards, Byron Campen --------------844FBB8B22855BFF68A8973E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/1/17 11:21 AM, Christer Holmberg wrote:

Hi,

 

Hi,

 

       Alright, if we want to write a rule that the transport
follows
the
bundle, what about this?
 
a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4
 
and in a reoffer
 
a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1
 
       What transport goes where?
I think Taylor raised this issue earlier. What you are doing above
is
moving streams from one BUNDLE group to another, and mixing the
BUNDLE
groups up, and I don¹t think that¹s a good idea.
 
Regards,
 
Christer
      If you want to classify this as a bad idea, we need normative
language forbidding it. For instance, a rule that once a mid is
placed
in a bundle, the only way to remove it is to disable it, as well as a
rule to handle the following:
 
a=group:BUNDLE mid2 mid3
a=mid: mid1 <--- not bundled
...
a=mid: mid2
...
a=mid: mid3
 
and in a reoffer
 
a=group mid1 mid2 mid3
 
      We would need to define which transport is retained; mid1's, or
the
bundle's. Or perhaps a rule forbidding previously unbundled mids to
be
added to a bundle.
I think this is covered in section 8.5.2 (Adding a media description
to
a
BUNDLE group) of BUNDLE.
 
Assuming you are not changing the transport of the mid1 m-line, you
are
suggesting a new transport for the BUNDLE group (first bullet in
section
8.5.2).
     Right, the offerer has the choice of retaining mid1's transport,
or
keeping the old bundle transport, according to 8.5.2. If we don't do
something like adding ufrag to the transport comparison rules, 8.5.2
would have to be tightened significantly. Again, our two choices here:
 
1. Find a way to allow an ICE offerer to indicate what transports it is
retaining (eg; ufrag).
You do that using the a=group attribute.
 
a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport
of
mid1 (read: you are suggesting a new transport for the BUNDLE group)
 
a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport
of
mid2 (read: keep the existing BUNDLE group transport).
 
Now, if you IN ADDITION to that wants to indicate something ICE
specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don¹t think that is BUNDLE specific, is it?
    Ok, so what you are describing is "transport follows m-section".
But the bundle spec doesn't _quite_ guarantee this right now, and it
probably shouldn't try to guarantee it either. For instance, 8.5.1
describes how the offerer can suggest a new transport for the bundle,
any time it wants (and it could potentially be a pre-existing transport
"stolen" from some other bundle/m-section!); without taking something
like ufrag into account, this is impossible to detect in the ICE case.
The BUNDLE groups can not use the same transport, so if someone is trying
to offer such thing the answerer should reject the offer, or at least not
accept the offered transports.
 
However, you would be completely right in saying "Well, duh, that is
true for non-BUNDLE also!", which is why I like the idea of fixing this
with ufrag, since that's how we make this work in the non-BUNDLE case.
I guess I still have some problems to understand what the problem is.
 
Let’s take the following example:
 
Initial offer/answer exchange:
 
a=group:BUNDLE mid1 mid2 mid3
a=group:BUNDLE mid4 mid5 mid6
 
Now, you have two transports: one “owned” by mid1 and one “owned" by mid4.
 
 
Re-offer:
 
a=group:BUNDLE mid4 mid2 mid3
a=group:BUNDLE mid1 mid5 mid6
 
 
In the re-offer, the offerer does not change the transports of mid1 and
mid4 - they are still the same. The different is that mid2 and mid3 will
now start using the transport of mid4, and mid5 and mid6 will start using
the transport of mid1.


    Right, but as far as I can tell the bundle spec does not forbid this:

a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555
a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666
...
m=audio 5555 ...
a=mid:mid1
...
m=video 6666 ...
a=mid:mid4

and then in a reoffer:

a=group:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped...
a=group:BUNDLE mid1 mid5 mid6
...
m=audio 6666 ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now
a=mid:mid1
...
m=video 5555 ...
a=mid:mid4

    If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account.

 

 

Maybe “transport follows m-section” is wrong wording. Transport is whatever the first mid in the a=group:BUNDLE attribute indicates it to be, and if that transport already exists there is no need to do an ICE restart. 

 

So, in your example, i the reoffer you are suggesting that mid4, mid2 and mid3 uses the "5555 transport". Since this transport already exists (it was previously used by mid1, mid2 and mid3), you don’t have to do an ICE restart.

 

Regards,

 

Christer

 

 

    Right. The offerer explicitly indicated what it wants to do, and nothing is ambiguous. I like this way of doing things. Which is why I prefer clarifying the spec to say that this explicit signaling is used in the ICE case too, rather than specifying restrictions like "transport follows m-section" to handle the ICE case.

I totally agree – the transport has to be explicitly indicated. But, don’t the ICE SDP attributes already explicitly indicate the transport?

 

    Sadly, not quite, because there's no clear requirement right now that the ufrag is different for each transport (and indeed it has not been implemented that way by Chrome or Firefox). That's what I'm advocating fixing, instead of adding a bunch of new rules for bundle with ICE.

Best regards,
Byron Campen
--------------844FBB8B22855BFF68A8973E-- From nobody Fri Sep 1 09:42:06 2017 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 5ABEA132F99 for ; Fri, 1 Sep 2017 09:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffLQq6d9Vb-L for ; Fri, 1 Sep 2017 09:41:50 -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 F3F7A132EB0 for ; Fri, 1 Sep 2017 09:41:49 -0700 (PDT) X-AuditID: c1b4fb30-597ff70000005897-7c-59a98dccaafe Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.A0.22679.CCD89A95; Fri, 1 Sep 2017 18:41:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 18:41:47 +0200 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqID///SaAIABesMA///wJ4CAAEZzAP//zm+A///G18AACrqYAP//3VLg Date: Fri, 1 Sep 2017 16:41:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD125EC@ESESSMB109.ericsson.se> References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CD125ECESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7iu6Z3pWRBn1nBCwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfG+hXKBac+MFYcWfCYrYFx wSvGLkZODgkBE4l7D3rZuxi5OIQEjjBK7L4zkw3CWcwo8eTBBKAqDg42AQuJ7n/aIA0iAkUS Z45tYQIJCws4SkyYJwRiigg4SfxqiAbpFBGYxiixp3MSO0g5i4CKxOy2vawgNq+Ar8ThPV+Y QGwhgRdsEls3SYLYnAL2Ej/fLWYGsRkFxCS+n1oDVsMsIC5x68l8Jog7BSSW7DnPDGGLSrx8 /I8VwlaSWLH9EiNEfb7E0pnL2SF2CUqcnPmEZQKj8Cwko2YhKZuFpGwW0AvMApoS63fpQ5Qo SkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYDwd3PLbYAfj y+eOhxgFOBiVeHi5K1dGCrEmlhVX5h5ilOBgVhLhXd4FFOJNSaysSi3Kjy8qzUktPsQozcGi JM7ruO9ChJBAemJJanZqakFqEUyWiYNTqoFR8HHu6edeS2QrJ+y7VNS6/8aKT4smCCe2Moh2 32IXWbbq9gFthVpjxfDw9bOFbeY9OBZ7vOKTJ+e9rY96pm1jC1DXy3fNOTV/11pJDruHYTd+ M53a13dhWbNa1f1tNQuX3Hpap7A4hFN5T/pUr/qvWV8/TZ7Jz19R3/bA8Wp35Tvru13M7vby SizFGYmGWsxFxYkAHHbQz6MCAAA= Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 16:42:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CD125ECESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhpLA0KDQoNCiAgICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVs ZSB0aGF0IHRoZSB0cmFuc3BvcnQNCg0KZm9sbG93cw0KDQp0aGUNCg0KYnVuZGxlLCB3aGF0IGFi b3V0IHRoaXM/DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDINCg0KYT1ncm91cDpCVU5E TEUgbWlkMyBtaWQ0DQoNCg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwOkJVTkRM RSBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQoNCg0KDQogICAgICAgV2hh dCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8NCg0KSSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNz dWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlDQoNCmlzDQoNCm1vdmluZyBzdHJl YW1zIGZyb20gb25lIEJVTkRMRSBncm91cCB0byBhbm90aGVyLCBhbmQgbWl4aW5nIHRoZQ0KDQpC VU5ETEUNCg0KZ3JvdXBzIHVwLCBhbmQgSSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRl YS4NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQogICAgICBJZiB5b3Ugd2FudCB0 byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQoNCmxhbmd1 YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBp cw0KDQpwbGFjZWQNCg0KaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMg dG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBhcyBhDQoNCnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dp bmc6DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCg0KYT1taWQ6IG1pZDEgPC0tLSBu b3QgYnVuZGxlZA0KDQouLi4NCg0KYT1taWQ6IG1pZDINCg0KLi4uDQoNCmE9bWlkOiBtaWQzDQoN Cg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCg0K DQogICAgICBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWlu ZWQ7IG1pZDEncywgb3INCg0KdGhlDQoNCmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3Ji aWRkaW5nIHByZXZpb3VzbHkgdW5idW5kbGVkIG1pZHMgdG8NCg0KYmUNCg0KYWRkZWQgdG8gYSBi dW5kbGUuDQoNCkkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGlu ZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQoNCnRvDQoNCmENCg0KQlVORExFIGdyb3VwKSBvZiBCVU5E TEUuDQoNCg0KDQpBc3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9m IHRoZSBtaWQxIG0tbGluZSwgeW91DQoNCmFyZQ0KDQpzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9y dCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluDQoNCnNlY3Rpb24NCg0KOC41 LjIpLg0KDQogICAgIFJpZ2h0LCB0aGUgb2ZmZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5p bmcgbWlkMSdzIHRyYW5zcG9ydCwNCg0Kb3INCg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFu c3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG8NCg0Kc29tZXRoaW5nIGxp a2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjIN Cg0Kd291bGQgaGF2ZSB0byBiZSB0aWdodGVuZWQgc2lnbmlmaWNhbnRseS4gQWdhaW4sIG91ciB0 d28gY2hvaWNlcyBoZXJlOg0KDQoNCg0KMS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2Zm ZXJlciB0byBpbmRpY2F0ZSB3aGF0IHRyYW5zcG9ydHMgaXQgaXMNCg0KcmV0YWluaW5nIChlZzsg dWZyYWcpLg0KDQpZb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCg0K DQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVz ZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoNCm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBh IG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApDQoNCg0KDQphPWdyb3VwOkJVTkVM RSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0 DQoNCm9mDQoNCm1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFu c3BvcnQpLg0KDQoNCg0KTm93LCBpZiB5b3UgSU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBp bmRpY2F0ZSBzb21ldGhpbmcgSUNFDQoNCnNwZWNpZmljLA0KDQplLmcsIHdoZXRoZXIgdG8gZG8g YW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCg0K QnV0LCBJIGRvbsK5dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/DQoNCiAg ICBPaywgc28gd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgInRyYW5zcG9ydCBmb2xsb3dzIG0t c2VjdGlvbiIuDQoNCkJ1dCB0aGUgYnVuZGxlIHNwZWMgZG9lc24ndCBfcXVpdGVfIGd1YXJhbnRl ZSB0aGlzIHJpZ2h0IG5vdywgYW5kIGl0DQoNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3Vh cmFudGVlIGl0IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUuMQ0KDQpkZXNjcmliZXMgaG93IHRo ZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSwNCg0K YW55IHRpbWUgaXQgd2FudHMgKGFuZCBpdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIHByZS1leGlz dGluZyB0cmFuc3BvcnQNCg0KInN0b2xlbiIgZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rp b24hKTsgd2l0aG91dCB0YWtpbmcgc29tZXRoaW5nDQoNCmxpa2UgdWZyYWcgaW50byBhY2NvdW50 LCB0aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS4NCg0KVGhlIEJV TkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25l IGlzIHRyeWluZw0KDQp0byBvZmZlciBzdWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVq ZWN0IHRoZSBvZmZlciwgb3IgYXQgbGVhc3Qgbm90DQoNCmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFu c3BvcnRzLg0KDQoNCg0KSG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4g c2F5aW5nICJXZWxsLCBkdWgsIHRoYXQgaXMNCg0KdHJ1ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIs IHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhlIGlkZWEgb2YgZml4aW5nIHRoaXMNCg0Kd2l0aCB1ZnJh Zywgc2luY2UgdGhhdCdzIGhvdyB3ZSBtYWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBj YXNlLg0KDQpJIGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQg d2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0KDQoNCkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4 YW1wbGU6DQoNCg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KDQoNCmE9Z3Jv dXA6QlVORExFIG1pZDEgbWlkMiBtaWQzDQoNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2 DQoNCg0KDQpOb3csIHlvdSBoYXZlIHR3byB0cmFuc3BvcnRzOiBvbmUg4oCcb3duZWTigJ0gYnkg bWlkMSBhbmQgb25lIOKAnG93bmVkIiBieSBtaWQ0Lg0KDQoNCg0KDQoNClJlLW9mZmVyOg0KDQoN Cg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBt aWQ1IG1pZDYNCg0KDQoNCg0KDQpJbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90 IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZA0KDQptaWQ0IC0gdGhleSBhcmUgc3Rp bGwgdGhlIHNhbWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCg0K bm93IHN0YXJ0IHVzaW5nIHRoZSB0cmFuc3BvcnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYg d2lsbCBzdGFydCB1c2luZw0KDQp0aGUgdHJhbnNwb3J0IG9mIG1pZDEuDQoNCiAgICBSaWdodCwg YnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQg dGhpczoNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMgPC0tLSB1c2VzIHBvcnQgNTU1 NQ0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQ1IG1pZDYgPC0tLSB1c2VzIHBvcnQgNjY2Ng0KLi4u DQptPWF1ZGlvIDU1NTUgLi4uDQphPW1pZDptaWQxDQouLi4NCm09dmlkZW8gNjY2NiAuLi4NCmE9 bWlkOm1pZDQNCg0KYW5kIHRoZW4gaW4gYSByZW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0 IG1pZDIgbWlkMyA8LS0tIG1pZDQgYW5kIG1pZDEgaGF2ZSBzd2FwcGVkLi4uDQphPWdyb3VwOkJV TkRMRSBtaWQxIG1pZDUgbWlkNg0KLi4uDQptPWF1ZGlvIDY2NjYgLi4uIDwtLS0gYnV0IHRoZSBv ZmZlcmVyIGhhcyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8g bWlkMSBub3cNCmE9bWlkOm1pZDENCi4uLg0KbT12aWRlbyA1NTU1IC4uLg0KYT1taWQ6bWlkNA0K DQogICAgSWYgdGhlIGJ1bmRsZSBzcGVjIGFsbG93cyB0aGlzLCAidHJhbnNwb3J0IGZvbGxvd3Mg bS1zZWN0aW9uIiBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUg aXMgInRyYW5zcG9ydCBpcyBzaWduYWxlZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUiLCB3aGljaCBp cyBpbXBvc3NpYmxlIHdpdGggSUNFIHVubGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQu DQoNCg0KTWF5YmUg4oCcdHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdv cmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3Vw OkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3Bv cnQgYWxyZWFkeSBleGlzdHMgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4N Cg0KU28sIGluIHlvdXIgZXhhbXBsZSwgaSB0aGUgcmVvZmZlciB5b3UgYXJlIHN1Z2dlc3Rpbmcg dGhhdCBtaWQ0LCBtaWQyIGFuZCBtaWQzIHVzZXMgdGhlICI1NTU1IHRyYW5zcG9ydCIuIFNpbmNl IHRoaXMgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5 IG1pZDEsIG1pZDIgYW5kIG1pZDMpLCB5b3UgZG9u4oCZdCBoYXZlIHRvIGRvIGFuIElDRSByZXN0 YXJ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KICAgIFJpZ2h0LiBUaGUgb2ZmZXJl ciBleHBsaWNpdGx5IGluZGljYXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBp cyBhbWJpZ3VvdXMuIEkgbGlrZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdo eSBJIHByZWZlciBjbGFyaWZ5aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQg c2lnbmFsaW5nIGlzIHVzZWQgaW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lm eWluZyByZXN0cmljdGlvbnMgbGlrZSAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiB0byBo YW5kbGUgdGhlIElDRSBjYXNlLg0KSSB0b3RhbGx5IGFncmVlIOKAkyB0aGUgdHJhbnNwb3J0IGhh cyB0byBiZSBleHBsaWNpdGx5IGluZGljYXRlZC4gQnV0LCBkb27igJl0IHRoZSBJQ0UgU0RQIGF0 dHJpYnV0ZXMgYWxyZWFkeSBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB0cmFuc3BvcnQ/DQoNCiAg ICBTYWRseSwgbm90IHF1aXRlLCBiZWNhdXNlIHRoZXJlJ3Mgbm8gY2xlYXIgcmVxdWlyZW1lbnQg cmlnaHQgbm93IHRoYXQgdGhlIHVmcmFnIGlzIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQg KGFuZCBpbmRlZWQgaXQgaGFzIG5vdCBiZWVuIGltcGxlbWVudGVkIHRoYXQgd2F5IGJ5IENocm9t ZSBvciBGaXJlZm94KS4gVGhhdCdzIHdoYXQgSSdtIGFkdm9jYXRpbmcgZml4aW5nLCBpbnN0ZWFk IG9mIGFkZGluZyBhIGJ1bmNoIG9mIG5ldyBydWxlcyBmb3IgYnVuZGxlIHdpdGggSUNFLg0KDQpB cyBJIHdyb3RlIGluIG15IGUtbWFpbCBvbiBUaHVyc2RheSwgbXkgdW5kZXJzdGFuZGluZyBvZiBS RkMgNTI0NSBpcyB0aGF0IHRoZSB1ZnJhZyBtdXN0IGJlIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFu c3BvcnQsIGlmIHlvdSBkbyBhbiBJQ0UgcmVzdGFydCB5b3UgbXVzdCBjaGFuZ2UgdWZyYWcsIGFu ZCBhIGNoYW5nZSBvZiB1ZnJhZyB3aWxsIHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuLg0KDQpJZiBp bXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBmb2xsb3cgdGhlIHNwZWNzIGl0IGRvZXNu4oCZdCByZWFs bHkgbWF0dGVyIHdoYXQgd2Ugc3BlY2lmeeKApg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CD125ECESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFscmlnaHQsIGlmIHdlIHdhbnQg dG8gd3JpdGUgYSBydWxlIHRoYXQgdGhlIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmZvbGxvd3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5idW5kbGUsIHdoYXQgYWJvdXQgdGhpcz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDI8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQzIG1pZDQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW4gYSByZW9mZmVyPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpC VU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlk NCBtaWQxPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoYXQgdHJhbnNwb3J0IGdv ZXMgd2hlcmU/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSB0aGluayBU YXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3Zl PG86cD48L286cD48L3ByZT4NCjxwcmU+aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tb3Zpbmcg c3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5vdGhlciwgYW5kIG1peGluZyB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CVU5ETEU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ncm91 cHMgdXAsIGFuZCBJIGRvbsK5dCB0aGluayB0aGF0wrlzIGEgZ29vZCBpZGVhLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkgdGhpcyBhcyBhIGJhZCBpZGVhLCB3 ZSBuZWVkIG5vcm1hdGl2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxhbmd1YWdlIGZvcmJpZGRp bmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBpczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnBsYWNlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluIGEgYnVuZGxlLCB0 aGUgb25seSB3YXkgdG8gcmVtb3ZlIGl0IGlzIHRvIGRpc2FibGUgaXQsIGFzIHdlbGwgYXMgYTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dpbmc6PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpC VU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1taWQ6IG1pZDEgJmx0Oy0t LSBub3QgYnVuZGxlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmE9bWlkOiBtaWQyPG86cD48L286cD48L3ByZT4NCjxwcmU+Li4uPG86cD48L286cD48 L3ByZT4NCjxwcmU+YT1taWQ6IG1pZDM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW4gYSByZW9mZmVyPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cCBtaWQxIG1pZDIgbWlkMzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0 cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEncywgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50 aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5idW5kbGUncy4gT3IgcGVyaGFwcyBhIHJ1bGUgZm9y YmlkZGluZyBwcmV2aW91c2x5IHVuYnVuZGxlZCBtaWRzIHRvPG86cD48L286cD48L3ByZT4NCjxw cmU+YmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hZGRlZCB0byBhIGJ1bmRsZS48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5JIHRoaW5rIHRoaXMgaXMgY292ZXJlZCBpbiBz ZWN0aW9uIDguNS4yIChBZGRpbmcgYSBtZWRpYSBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnRvPG86cD48L286cD48L3ByZT4NCjxwcmU+YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PkJVTkRMRSBncm91cCkgb2YgQlVORExFLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzc3VtaW5nIHlvdSBhcmUgbm90IGNoYW5naW5nIHRoZSB0 cmFuc3BvcnQgb2YgdGhlIG1pZDEgbS1saW5lLCB5b3U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h cmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3Ig dGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluPG86cD48L286cD48L3ByZT4NCjxwcmU+ c2VjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjguNS4yKS48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmlnaHQsIHRoZSBv ZmZlcmVyIGhhcyB0aGUgY2hvaWNlIG9mIHJldGFpbmluZyBtaWQxJ3MgdHJhbnNwb3J0LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+a2VlcGluZyB0aGUg b2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG88 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb21ldGhpbmcgbGlrZSBhZGRpbmcgdWZyYWcgdG8gdGhl IHRyYW5zcG9ydCBjb21wYXJpc29uIHJ1bGVzLCA4LjUuMjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PndvdWxkIGhhdmUgdG8gYmUgdGlnaHRlbmVkIHNpZ25pZmljYW50bHkuIEFnYWluLCBvdXIgdHdv IGNob2ljZXMgaGVyZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4xLiBGaW5kIGEgd2F5IHRvIGFsbG93IGFuIElDRSBvZmZlcmVyIHRvIGluZGlj YXRlIHdoYXQgdHJhbnNwb3J0cyBpdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJldGFpbmlu ZyAoZWc7IHVmcmFnKS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Zb3Ug ZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQy IG1pZDMgbWVhbnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIHRyYW5zcG9ydDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPm9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlkMSAocmVhZDogeW91IGFy ZSBzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCk8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJV TkVMRSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNw b3J0PG86cD48L286cD48L3ByZT4NCjxwcmU+b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5taWQy IChyZWFkOiBrZWVwIHRoZSBleGlzdGluZyBCVU5ETEUgZ3JvdXAgdHJhbnNwb3J0KS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ob3csIGlmIHlv dSBJTiBBRERJVElPTiB0byB0aGF0IHdhbnRzIHRvIGluZGljYXRlIHNvbWV0aGluZyBJQ0U8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5zcGVjaWZpYyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lLmcs IHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJh ZyBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CdXQsIEkgZG9uwrl0IHRoaW5rIHRo YXQgaXMgQlVORExFIHNwZWNpZmljLCBpcyBpdD88bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgT2ssIHNvIHdoYXQgeW91IGFyZSBkZXNjcmli aW5nIGlzICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiZxdW90Oy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5CdXQgdGhlIGJ1bmRsZSBzcGVjIGRvZXNuJ3QgX3F1aXRlXyBndWFyYW50 ZWUgdGhpcyByaWdodCBub3csIGFuZCBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb2JhYmx5 IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUu MTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRlc2NyaWJlcyBob3cgdGhlIG9mZmVyZXIgY2FuIHN1 Z2dlc3QgYSBuZXcgdHJhbnNwb3J0IGZvciB0aGUgYnVuZGxlLDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmFueSB0aW1lIGl0IHdhbnRzIChhbmQgaXQgY291bGQgcG90ZW50aWFsbHkgYmUgYSBwcmUt ZXhpc3RpbmcgdHJhbnNwb3J0PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7c3RvbGVuJnF1 b3Q7IGZyb20gc29tZSBvdGhlciBidW5kbGUvbS1zZWN0aW9uISk7IHdpdGhvdXQgdGFraW5nIHNv bWV0aGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxpa2UgdWZyYWcgaW50byBhY2NvdW50LCB0 aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5UaGUgQlVORExFIGdyb3VwcyBjYW4gbm90IHVzZSB0 aGUgc2FtZSB0cmFuc3BvcnQsIHNvIGlmIHNvbWVvbmUgaXMgdHJ5aW5nPG86cD48L286cD48L3By ZT4NCjxwcmU+dG8gb2ZmZXIgc3VjaCB0aGluZyB0aGUgYW5zd2VyZXIgc2hvdWxkIHJlamVjdCB0 aGUgb2ZmZXIsIG9yIGF0IGxlYXN0IG5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFjY2VwdCB0 aGUgb2ZmZXJlZCB0cmFuc3BvcnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+SG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmln aHQgaW4gc2F5aW5nICZxdW90O1dlbGwsIGR1aCwgdGhhdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnRydWUgZm9yIG5vbi1CVU5ETEUgYWxzbyEmcXVvdDssIHdoaWNoIGlzIHdoeSBJIGxpa2Ug dGhlIGlkZWEgb2YgZml4aW5nIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aXRoIHVmcmFn LCBzaW5jZSB0aGF0J3MgaG93IHdlIG1ha2UgdGhpcyB3b3JrIGluIHRoZSBub24tQlVORExFIGNh c2UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSBndWVzcyBJIHN0aWxs IGhhdmUgc29tZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIHByb2JsZW0gaXMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+TGV04oCZ cyB0YWtlIHRoZSBmb2xsb3dpbmcgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Jbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZTo8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdy b3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6 QlVORExFIG1pZDQgbWlkNSBtaWQ2PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Tm93LCB5b3UgaGF2ZSB0d28gdHJhbnNwb3J0czogb25lIOKAnG93 bmVk4oCdIGJ5IG1pZDEgYW5kIG9uZSDigJxvd25lZCZxdW90OyBieSBtaWQ0LjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlJlLW9mZmVyOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkMiBtaWQzPG86cD48 L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDY8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5JbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90IGNo YW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1p ZDQgLSB0aGV5IGFyZSBzdGlsbCB0aGUgc2FtZS4gVGhlIGRpZmZlcmVudCBpcyB0aGF0IG1pZDIg YW5kIG1pZDMgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vdyBzdGFydCB1c2luZyB0aGUg dHJhbnNwb3J0IG9mIG1pZDQsIGFuZCBtaWQ1IGFuZCBtaWQ2IHdpbGwgc3RhcnQgdXNpbmc8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT50aGUgdHJhbnNwb3J0IG9mIG1pZDEuPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCBidXQgYXMgZmFyIGFzIEkgY2FuIHRlbGwg dGhlIGJ1bmRsZSBzcGVjIGRvZXMgbm90IGZvcmJpZCB0aGlzOjxicj4NCjxicj4NCmE9Z3JvdXA6 QlVORExFIG1pZDEgbWlkMiBtaWQzICZsdDstLS0gdXNlcyBwb3J0IDU1NTU8YnI+DQphPWdyb3Vw OkJVTkRMRSBtaWQ0IG1pZDUgbWlkNiAmbHQ7LS0tIHVzZXMgcG9ydCA2NjY2PGJyPg0KLi4uPGJy Pg0KbT1hdWRpbyA1NTU1IC4uLjxicj4NCmE9bWlkOm1pZDE8YnI+DQouLi48YnI+DQptPXZpZGVv IDY2NjYgLi4uPGJyPg0KYT1taWQ6bWlkNDxicj4NCjxicj4NCmFuZCB0aGVuIGluIGEgcmVvZmZl cjo8YnI+DQo8YnI+DQphPWdyb3VwOkJVTkRMRSA8Yj5taWQ0PC9iPiBtaWQyIG1pZDMgJmx0Oy0t LSBtaWQ0IGFuZCBtaWQxIGhhdmUgc3dhcHBlZC4uLjxicj4NCmE9Z3JvdXA6QlVORExFIDxiPm1p ZDE8L2I+IG1pZDUgbWlkNjxicj4NCi4uLjxicj4NCm09YXVkaW8gPGI+NjY2NjwvYj4gLi4uICZs dDstLS0gYnV0IHRoZSBvZmZlcmVyIGhhcyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYg aXMgYXR0YWNoZWQgdG8gbWlkMSBub3c8YnI+DQphPW1pZDptaWQxPGJyPg0KLi4uPGJyPg0KbT12 aWRlbyA8Yj41NTU1PC9iPiAuLi48YnI+DQphPW1pZDptaWQ0PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IElmIHRoZSBidW5kbGUgc3BlYyBhbGxvd3MgdGhpcywgJnF1b3Q7dHJhbnNwb3J0 IGZvbGxvd3MgbS1zZWN0aW9uJnF1b3Q7IGlzIG5vdCBwYXJ0IG9mIHRoZSBzcGVjOyB0aGUgZnVu ZGFtZW50YWwgcnVsZSBpcyAmcXVvdDt0cmFuc3BvcnQgaXMgc2lnbmFsZWQgZXhwbGljaXRseSBl dmVyeSB0aW1lJnF1b3Q7LCB3aGljaCBpcyBpbXBvc3NpYmxlIHdpdGggSUNFIHVubGVzcyB1ZnJh ZyBpcyB0YWtlbiBpbnRvIGFjY291bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPk1heWJlJm5ic3A74oCcdHJh bnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdvcmRpbmcuIFRyYW5zcG9ydCBp cyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3VwOkJVTkRMRSBhdHRyaWJ1dGUg aW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMN CiB0aGVyZSBpcyBubyBuZWVkIHRvIGRvIGFuIElDRSByZXN0YXJ0LiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpy ZWQiPlNvLCBpbiB5b3VyIGV4YW1wbGUsIGkgdGhlIHJlb2ZmZXIgeW91IGFyZSBzdWdnZXN0aW5n IHRoYXQgbWlkNCwgbWlkMiBhbmQgbWlkMyB1c2VzIHRoZSAmcXVvdDs1NTU1IHRyYW5zcG9ydCZx dW90Oy4gU2luY2UgdGhpcyB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMgKGl0IHdhcyBwcmV2aW91 c2x5IHVzZWQgYnkgbWlkMSwgbWlkMg0KIGFuZCBtaWQzKSwgeW91IGRvbuKAmXQgaGF2ZSB0byBk byBhbiBJQ0UgcmVzdGFydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkNo cmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LiBUaGUgb2ZmZXJlciBleHBsaWNpdGx5IGluZGlj YXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBpcyBhbWJpZ3VvdXMuIEkgbGlr ZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdoeSBJIHByZWZlciBjbGFyaWZ5 aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQgc2lnbmFsaW5nIGlzIHVzZWQg aW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lmeWluZw0KIHJlc3RyaWN0aW9u cyBsaWtlICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiZxdW90OyB0byBoYW5kbGUg dGhlIElDRSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3MEFENDc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdG90 YWxseSBhZ3JlZSDigJMgdGhlIHRyYW5zcG9ydCBoYXMgdG8gYmUgZXhwbGljaXRseSBpbmRpY2F0 ZWQuIEJ1dCwgZG9u4oCZdCB0aGUgSUNFIFNEUCBhdHRyaWJ1dGVzIGFscmVhZHkgZXhwbGljaXRs eSBpbmRpY2F0ZSB0aGUgdHJhbnNwb3J0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgU2FkbHksIG5vdCBxdWl0ZSwgYmVjYXVzZSB0aGVy ZSdzIG5vIGNsZWFyIHJlcXVpcmVtZW50IHJpZ2h0IG5vdyB0aGF0IHRoZSB1ZnJhZyBpcyBkaWZm ZXJlbnQgZm9yIGVhY2ggdHJhbnNwb3J0IChhbmQgaW5kZWVkIGl0IGhhcyBub3QgYmVlbiBpbXBs ZW1lbnRlZCB0aGF0IHdheSBieSBDaHJvbWUgb3IgRmlyZWZveCkuIFRoYXQncyB3aGF0IEknbSBh ZHZvY2F0aW5nIGZpeGluZywgaW5zdGVhZCBvZiBhZGRpbmcNCiBhIGJ1bmNoIG9mIG5ldyBydWxl cyBmb3IgYnVuZGxlIHdpdGggSUNFLjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPkFzIEkgd3JvdGUgaW4g bXkgZS1tYWlsIG9uIFRodXJzZGF5LCBteSB1bmRlcnN0YW5kaW5nIG9mIFJGQyA1MjQ1IGlzIHRo YXQgdGhlIHVmcmFnIG11c3QgYmUgZGlmZmVyZW50IGZvciBlYWNoIHRyYW5zcG9ydCwgaWYgeW91 IGRvIGFuIElDRSByZXN0YXJ0IHlvdSBtdXN0IGNoYW5nZQ0KIHVmcmFnLCBhbmQgYSBjaGFuZ2Ug b2YgdWZyYWcgd2lsbCB0cmlnZ2VyIGFuIElDRSByZXN0YXJ0Li4gPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDci PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij5JZiBpbXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBmb2xs b3cgdGhlIHNwZWNzIGl0IGRvZXNu4oCZdCByZWFsbHkgbWF0dGVyIHdoYXQgd2Ugc3BlY2lmeeKA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzBBRDQ3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzcwQUQ0NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3MEFENDciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CD125ECESESSMB109erics_-- From nobody Fri Sep 1 09:47:07 2017 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 B05B41342F0 for ; Fri, 1 Sep 2017 09:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 It_7fo_cWKIH for ; Fri, 1 Sep 2017 09:47:03 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 824F0133131 for ; Fri, 1 Sep 2017 09:47:03 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id r203so6394307oih.0 for ; Fri, 01 Sep 2017 09:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=vtopWo06OwBW/vpzk2PpLu3lakeUT5Nx8x1kXFw91wA=; b=EJvqdfmm4T8Lurg5vYJzbFF83gx5svgWso2HQhoLBkxrlzOzrnwEt52wesNTwxB+ZW G5+sPjlp1Bl2aZ99ZHqm0jIZyNh9inohQbdA0rzEUped8okl1lcxfpHqvet4+EMbXdn2 4d071+vo0i2mmngfeFuc5tCAWk2Zf6MBliyg4= 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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vtopWo06OwBW/vpzk2PpLu3lakeUT5Nx8x1kXFw91wA=; b=d2uV8B06TmDMzia52FLUjf183hRNbCeDPYd5GSGddbRnYPtf8/Np4iMHz+7ZaqZhoi 1u383a7G5kZ1hv9mQ9zTrKCPxwwjmlfm8CDPf6SVulpzonh5UXwwff9dnvJLBmZPgula Vaa+LweStWhnLkpnkcihBOUWmVwzvdoMwyU992jcLCmvnf74LaNmr+dKgWSevtlBCtHT JgYq9OaupAJ+Npvzv37kqgOafBceDxNTjNjCVgkGYpUnhiPnCAE4QXzNcPaROdw6mY0g 3VfkLn8YFX36q8V66nDNZ4lQMVECM02o4YqMTu6ByisXVEr8pLiVOt5ZiOpAnvQ5OpP/ qG0w== X-Gm-Message-State: AHPjjUgxgRG7udiEedjOLbpffcavPsTqy64SX4CKG37h1p2of8BCmz+k 9+1ndzdIzNbEY18o36LuGg== X-Google-Smtp-Source: ADKCNb7vso5oYU2h39AfKuxCVYUIsKbLOhp4LB7T1vzKPjVNbHv8krSsJSJVq6XNGkDxC+ktdC+aBQ== X-Received: by 10.202.104.205 with SMTP id o74mr1586136oik.146.1504284422236; Fri, 01 Sep 2017 09:47:02 -0700 (PDT) Received: from bcampen-19607.local (23-127-222-10.lightspeed.rcsntx.sbcglobal.net. [23.127.222.10]) by smtp.googlemail.com with ESMTPSA id m3sm821505oif.17.2017.09.01.09.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 09:47:01 -0700 (PDT) To: Christer Holmberg , Taylor Brandstetter , RTCWeb IETF References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CD125EC@ESESSMB109.ericsson.se> From: Byron Campen Message-ID: Date: Fri, 1 Sep 2017 11:47:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CD125EC@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------AFAA649905BE896EA89946C4" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 16:47:07 -0000 This is a multi-part message in MIME format. --------------AFAA649905BE896EA89946C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/1/17 11:41 AM, Christer Holmberg wrote: > > Hi, > > Hi, > >        Alright, if we want to write a rule that the transport > > follows > > the > > bundle, what about this? > > > > a=group:BUNDLE mid1 mid2 > > a=group:BUNDLE mid3 mid4 > > > > and in a reoffer > > > > a=group:BUNDLE mid2 mid3 > > a=group:BUNDLE mid4 mid1 > > > >        What transport goes where? > > I think Taylor raised this issue earlier. What you are doing above > > is > > moving streams from one BUNDLE group to another, and mixing the > > BUNDLE > > groups up, and I don¹t think that¹s a good idea. > > > > Regards, > > > > Christer > >       If you want to classify this as a bad idea, we need normative > > language forbidding it. For instance, a rule that once a mid is > > placed > > in a bundle, the only way to remove it is to disable it, as well as a > > rule to handle the following: > > > > a=group:BUNDLE mid2 mid3 > > a=mid: mid1 <--- not bundled > > ... > > a=mid: mid2 > > ... > > a=mid: mid3 > > > > and in a reoffer > > > > a=group mid1 mid2 mid3 > > > >       We would need to define which transport is retained; mid1's, or > > the > > bundle's. Or perhaps a rule forbidding previously unbundled mids to > > be > > added to a bundle. > > I think this is covered in section 8.5.2 (Adding a media description > > to > > a > > BUNDLE group) of BUNDLE. > > > > Assuming you are not changing the transport of the mid1 m-line, you > > are > > suggesting a new transport for the BUNDLE group (first bullet in > > section > > 8.5.2). > >      Right, the offerer has the choice of retaining mid1's transport, > > or > > keeping the old bundle transport, according to 8.5.2. If we don't do > > something like adding ufrag to the transport comparison rules, 8.5.2 > > would have to be tightened significantly. Again, our two choices here: > > > > 1. Find a way to allow an ICE offerer to indicate what transports it is > > retaining (eg; ufrag). > > You do that using the a=group attribute. > > > > a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport > > of > > mid1 (read: you are suggesting a new transport for the BUNDLE group) > > > > a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport > > of > > mid2 (read: keep the existing BUNDLE group transport). > > > > Now, if you IN ADDITION to that wants to indicate something ICE > > specific, > > e.g, whether to do an ICE restart, I guess you could use ufrag for that. > > But, I don¹t think that is BUNDLE specific, is it? > >     Ok, so what you are describing is "transport follows m-section". > > But the bundle spec doesn't _quite_ guarantee this right now, and it > > probably shouldn't try to guarantee it either. For instance, 8.5.1 > > describes how the offerer can suggest a new transport for the bundle, > > any time it wants (and it could potentially be a pre-existing transport > > "stolen" from some other bundle/m-section!); without taking something > > like ufrag into account, this is impossible to detect in the ICE case. > > The BUNDLE groups can not use the same transport, so if someone is trying > > to offer such thing the answerer should reject the offer, or at least not > > accept the offered transports. > > > > However, you would be completely right in saying "Well, duh, that is > > true for non-BUNDLE also!", which is why I like the idea of fixing this > > with ufrag, since that's how we make this work in the non-BUNDLE case. > > I guess I still have some problems to understand what the problem is. > > > > Let’s take the following example: > > > > Initial offer/answer exchange: > > > > a=group:BUNDLE mid1 mid2 mid3 > > a=group:BUNDLE mid4 mid5 mid6 > > > > Now, you have two transports: one “owned” by mid1 and one “owned" by mid4. > > > > > > Re-offer: > > > > a=group:BUNDLE mid4 mid2 mid3 > > a=group:BUNDLE mid1 mid5 mid6 > > > > > > In the re-offer, the offerer does not change the transports of mid1 and > > mid4 - they are still the same. The different is that mid2 and mid3 will > > now start using the transport of mid4, and mid5 and mid6 will start using > > the transport of mid1. > > >     Right, but as far as I can tell the bundle spec does not > forbid this: > > a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555 > a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666 > ... > m=audio 5555 ... > a=mid:mid1 > ... > m=video 6666 ... > a=mid:mid4 > > and then in a reoffer: > > a=group:BUNDLE *mid4* mid2 mid3 <--- mid4 and mid1 have swapped... > a=group:BUNDLE *mid1* mid5 mid6 > ... > m=audio *6666* ... <--- but the offerer has explicitly indicated > that 6666 is attached to mid1 now > a=mid:mid1 > ... > m=video *5555* ... > a=mid:mid4 > >     If the bundle spec allows this, "transport follows m-section" > is not part of the spec; the fundamental rule is "transport is > signaled explicitly every time", which is impossible with ICE > unless ufrag is taken into account. > > Maybe “transport follows m-section” is wrong wording. Transport is > whatever the first mid in the a=group:BUNDLE attribute indicates > it to be, and if that transport already exists there is no need to > do an ICE restart. > > So, in your example, i the reoffer you are suggesting that mid4, > mid2 and mid3 uses the "5555 transport". Since this transport > already exists (it was previously used by mid1, mid2 and mid3), > you don’t have to do an ICE restart. > > Regards, > > Christer > >     Right. The offerer explicitly indicated what it wants to do, and > nothing is ambiguous. I like this way of doing things. Which is why I > prefer clarifying the spec to say that this explicit signaling is used > in the ICE case too, rather than specifying restrictions like > "transport follows m-section" to handle the ICE case. > > I totally agree – the transport has to be explicitly indicated. But, > don’t the ICE SDP attributes already explicitly indicate the transport? > >     Sadly, not quite, because there's no clear requirement right now > that the ufrag is different for each transport (and indeed it has not > been implemented that way by Chrome or Firefox). That's what I'm > advocating fixing, instead of adding a bunch of new rules for bundle > with ICE. > > As I wrote in my e-mail on Thursday, my understanding of RFC 5245 is > that the ufrag must be different for each transport, if you do an ICE > restart you must change ufrag, and a change of ufrag will trigger an > ICE restart.. > > If implementations don’t follow the specs it doesn’t really matter > what we specify… >     That changing the ufrag causes a transport change is clear, but there is presently no language saying that you cannot start out with the same ufrag for every m-section, and this is further confused by the fact that ice-ufrag is allowed to be session level. Best regards, Byron Campen --------------AFAA649905BE896EA89946C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/1/17 11:41 AM, Christer Holmberg wrote:

Hi,

 

Hi,

 

       Alright, if we want to write a rule that the transport
follows
the
bundle, what about this?
 
a=group:BUNDLE mid1 mid2
a=group:BUNDLE mid3 mid4
 
and in a reoffer
 
a=group:BUNDLE mid2 mid3
a=group:BUNDLE mid4 mid1
 
       What transport goes where?
I think Taylor raised this issue earlier. What you are doing above
is
moving streams from one BUNDLE group to another, and mixing the
BUNDLE
groups up, and I don¹t think that¹s a good idea.
 
Regards,
 
Christer
      If you want to classify this as a bad idea, we need normative
language forbidding it. For instance, a rule that once a mid is
placed
in a bundle, the only way to remove it is to disable it, as well as a
rule to handle the following:
 
a=group:BUNDLE mid2 mid3
a=mid: mid1 <--- not bundled
...
a=mid: mid2
...
a=mid: mid3
 
and in a reoffer
 
a=group mid1 mid2 mid3
 
      We would need to define which transport is retained; mid1's, or
the
bundle's. Or perhaps a rule forbidding previously unbundled mids to
be
added to a bundle.
I think this is covered in section 8.5.2 (Adding a media description
to
a
BUNDLE group) of BUNDLE.
 
Assuming you are not changing the transport of the mid1 m-line, you
are
suggesting a new transport for the BUNDLE group (first bullet in
section
8.5.2).
     Right, the offerer has the choice of retaining mid1's transport,
or
keeping the old bundle transport, according to 8.5.2. If we don't do
something like adding ufrag to the transport comparison rules, 8.5.2
would have to be tightened significantly. Again, our two choices here:
 
1. Find a way to allow an ICE offerer to indicate what transports it is
retaining (eg; ufrag).
You do that using the a=group attribute.
 
a=group:BUNDLE mid1 mid2 mid3 means that you want to use the transport
of
mid1 (read: you are suggesting a new transport for the BUNDLE group)
 
a=group:BUNELE mid2 mid3 mie1 means that you want to use the transport
of
mid2 (read: keep the existing BUNDLE group transport).
 
Now, if you IN ADDITION to that wants to indicate something ICE
specific,
e.g, whether to do an ICE restart, I guess you could use ufrag for that.
But, I don¹t think that is BUNDLE specific, is it?
    Ok, so what you are describing is "transport follows m-section".
But the bundle spec doesn't _quite_ guarantee this right now, and it
probably shouldn't try to guarantee it either. For instance, 8.5.1
describes how the offerer can suggest a new transport for the bundle,
any time it wants (and it could potentially be a pre-existing transport
"stolen" from some other bundle/m-section!); without taking something
like ufrag into account, this is impossible to detect in the ICE case.
The BUNDLE groups can not use the same transport, so if someone is trying
to offer such thing the answerer should reject the offer, or at least not
accept the offered transports.
 
However, you would be completely right in saying "Well, duh, that is
true for non-BUNDLE also!", which is why I like the idea of fixing this
with ufrag, since that's how we make this work in the non-BUNDLE case.
I guess I still have some problems to understand what the problem is.
 
Let’s take the following example:
 
Initial offer/answer exchange:
 
a=group:BUNDLE mid1 mid2 mid3
a=group:BUNDLE mid4 mid5 mid6
 
Now, you have two transports: one “owned” by mid1 and one “owned" by mid4.
 
 
Re-offer:
 
a=group:BUNDLE mid4 mid2 mid3
a=group:BUNDLE mid1 mid5 mid6
 
 
In the re-offer, the offerer does not change the transports of mid1 and
mid4 - they are still the same. The different is that mid2 and mid3 will
now start using the transport of mid4, and mid5 and mid6 will start using
the transport of mid1.


    Right, but as far as I can tell the bundle spec does not forbid this:

a=group:BUNDLE mid1 mid2 mid3 <--- uses port 5555
a=group:BUNDLE mid4 mid5 mid6 <--- uses port 6666
...
m=audio 5555 ...
a=mid:mid1
...
m=video 6666 ...
a=mid:mid4

and then in a reoffer:

a=group:BUNDLE mid4 mid2 mid3 <--- mid4 and mid1 have swapped...
a=group:BUNDLE mid1 mid5 mid6
...
m=audio 6666 ... <--- but the offerer has explicitly indicated that 6666 is attached to mid1 now
a=mid:mid1
...
m=video 5555 ...
a=mid:mid4

    If the bundle spec allows this, "transport follows m-section" is not part of the spec; the fundamental rule is "transport is signaled explicitly every time", which is impossible with ICE unless ufrag is taken into account.

 

 

Maybe “transport follows m-section” is wrong wording. Transport is whatever the first mid in the a=group:BUNDLE attribute indicates it to be, and if that transport already exists there is no need to do an ICE restart. 

 

So, in your example, i the reoffer you are suggesting that mid4, mid2 and mid3 uses the "5555 transport". Since this transport already exists (it was previously used by mid1, mid2 and mid3), you don’t have to do an ICE restart.

 

Regards,

 

Christer

 

 

    Right. The offerer explicitly indicated what it wants to do, and nothing is ambiguous. I like this way of doing things. Which is why I prefer clarifying the spec to say that this explicit signaling is used in the ICE case too, rather than specifying restrictions like "transport follows m-section" to handle the ICE case.

I totally agree – the transport has to be explicitly indicated. But, don’t the ICE SDP attributes already explicitly indicate the transport?

 

    Sadly, not quite, because there's no clear requirement right now that the ufrag is different for each transport (and indeed it has not been implemented that way by Chrome or Firefox). That's what I'm advocating fixing, instead of adding a bunch of new rules for bundle with ICE.

 

As I wrote in my e-mail on Thursday, my understanding of RFC 5245 is that the ufrag must be different for each transport, if you do an ICE restart you must change ufrag, and a change of ufrag will trigger an ICE restart..

 

If implementations don’t follow the specs it doesn’t really matter what we specify…

 


    That changing the ufrag causes a transport change is clear, but there is presently no language saying that you cannot start out with the same ufrag for every m-section, and this is further confused by the fact that ice-ufrag is allowed to be session level.

Best regards,
Byron Campen
--------------AFAA649905BE896EA89946C4-- From nobody Fri Sep 1 09:58:19 2017 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 4B549132FF0 for ; Fri, 1 Sep 2017 09:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc9uHUDNKe6T for ; Fri, 1 Sep 2017 09:58:14 -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 C2C581321A5 for ; Fri, 1 Sep 2017 09:58:13 -0700 (PDT) X-AuditID: c1b4fb2d-11bff700000057a4-a7-59a991a3061c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.D1.22436.3A199A95; Fri, 1 Sep 2017 18:58:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 18:58:11 +0200 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? Thread-Index: AQHTIOTZ4UQpHpLMhU27CP3MUN8wBaKbaTqAgAFZmgD///eWgIAAPa0A///RYwCAAbm0gP//0j+AAAbQqID///SaAIABesMA///wJ4CAAEZzAP//zm+A///G18AACrqYAP//3VLg///ZygD//5AXAA== Date: Fri, 1 Sep 2017 16:58:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CD12678@ESESSMB109.ericsson.se> References: <0567f978-4fd6-11b5-1a32-afda996a4cd3@mozilla.com> <325d3a82-eee9-aad4-5f60-c726b2cd9de5@mozilla.com> <1e0d3ba2-c8a9-59bd-d94e-38bd68ce0235@mozilla.com> <234af6f0-c1b1-6491-3b06-e7586ec5a854@mozilla.com> <26e1df6e-1b82-6ff4-212b-2e778bd0696e@mozilla.com> <7594FB04B1934943A5C02806D1A2204B4CD1246B@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CD125EC@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CD12678ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7lO7iiSsjDdq/mlgsvNfKYnF5xUNW i7X/2tkdmD0WbCr1WLLkJ5NH34Eu1gDmKC6blNSczLLUIn27BK6MI/dnsxUc+c9Ysf1LE3MD 44sfjF2MnBwSAiYS03+sZeti5OIQEjjCKLH53GV2CGcxo8Stf0eBHA4ONgELie5/2iANIgJF EmeObWECCQsLOEpMmCcEYooIOEn8aogG6RQRWMYosezAdDaQchYBFYn7x36zg9i8Ar4Sb5bs Z4UY/5Bdoqn1F9gRnAL2Eu+f7wYrYhQQk/h+ag0TiM0sIC5x68l8JohDBSSW7DnPDGGLSrx8 /I8VwlaSWLH9EiNEfb7Et1+/WSCWCUqcnPmEZQKj8Cwko2YhKZuFpGwW0A/MApoS63fpQ5Qo SkzpfsgOYWtItM6Zy44svoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYEwd3PJbdwfj 6teOhxgFOBiVeHhTy1dGCrEmlhVX5h5ilOBgVhLhfdIHFOJNSaysSi3Kjy8qzUktPsQozcGi JM7rsO9ChJBAemJJanZqakFqEUyWiYNTqoFxKqPOLobYZl3JRutjF/6sivO4dzW6ZOKlWJvr qyf9ncQlF9Ph09/UOcvnIpMQl8KNGiHf6amNz4v0X5Wwd/ake99aOrP2x8Q1YtFGTdltV6xn eQcWHmA8u/dR8lnDDZsZnW+/2+Z0b37C2oo/i7Uqj3Z3p2of2Gu5Nr/hdlMeb7t0UemJam4l luKMREMt5qLiRAC5WG4IpQIAAA== Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 16:58:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CD12678ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkhpLA0KDQoNCiAgICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVs ZSB0aGF0IHRoZSB0cmFuc3BvcnQNCg0KZm9sbG93cw0KDQp0aGUNCg0KYnVuZGxlLCB3aGF0IGFi b3V0IHRoaXM/DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDINCg0KYT1ncm91cDpCVU5E TEUgbWlkMyBtaWQ0DQoNCg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwOkJVTkRM RSBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQoNCg0KDQogICAgICAgV2hh dCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8NCg0KSSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNz dWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlDQoNCmlzDQoNCm1vdmluZyBzdHJl YW1zIGZyb20gb25lIEJVTkRMRSBncm91cCB0byBhbm90aGVyLCBhbmQgbWl4aW5nIHRoZQ0KDQpC VU5ETEUNCg0KZ3JvdXBzIHVwLCBhbmQgSSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRl YS4NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQogICAgICBJZiB5b3Ugd2FudCB0 byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQoNCmxhbmd1 YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBp cw0KDQpwbGFjZWQNCg0KaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMg dG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBhcyBhDQoNCnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dp bmc6DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCg0KYT1taWQ6IG1pZDEgPC0tLSBu b3QgYnVuZGxlZA0KDQouLi4NCg0KYT1taWQ6IG1pZDINCg0KLi4uDQoNCmE9bWlkOiBtaWQzDQoN Cg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCg0K DQogICAgICBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWlu ZWQ7IG1pZDEncywgb3INCg0KdGhlDQoNCmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3Ji aWRkaW5nIHByZXZpb3VzbHkgdW5idW5kbGVkIG1pZHMgdG8NCg0KYmUNCg0KYWRkZWQgdG8gYSBi dW5kbGUuDQoNCkkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGlu ZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQoNCnRvDQoNCmENCg0KQlVORExFIGdyb3VwKSBvZiBCVU5E TEUuDQoNCg0KDQpBc3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9m IHRoZSBtaWQxIG0tbGluZSwgeW91DQoNCmFyZQ0KDQpzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9y dCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluDQoNCnNlY3Rpb24NCg0KOC41 LjIpLg0KDQogICAgIFJpZ2h0LCB0aGUgb2ZmZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5p bmcgbWlkMSdzIHRyYW5zcG9ydCwNCg0Kb3INCg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFu c3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG8NCg0Kc29tZXRoaW5nIGxp a2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjIN Cg0Kd291bGQgaGF2ZSB0byBiZSB0aWdodGVuZWQgc2lnbmlmaWNhbnRseS4gQWdhaW4sIG91ciB0 d28gY2hvaWNlcyBoZXJlOg0KDQoNCg0KMS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2Zm ZXJlciB0byBpbmRpY2F0ZSB3aGF0IHRyYW5zcG9ydHMgaXQgaXMNCg0KcmV0YWluaW5nIChlZzsg dWZyYWcpLg0KDQpZb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCg0K DQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVz ZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoNCm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBh IG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApDQoNCg0KDQphPWdyb3VwOkJVTkVM RSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0 DQoNCm9mDQoNCm1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFu c3BvcnQpLg0KDQoNCg0KTm93LCBpZiB5b3UgSU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBp bmRpY2F0ZSBzb21ldGhpbmcgSUNFDQoNCnNwZWNpZmljLA0KDQplLmcsIHdoZXRoZXIgdG8gZG8g YW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCg0K QnV0LCBJIGRvbsK5dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/DQoNCiAg ICBPaywgc28gd2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgInRyYW5zcG9ydCBmb2xsb3dzIG0t c2VjdGlvbiIuDQoNCkJ1dCB0aGUgYnVuZGxlIHNwZWMgZG9lc24ndCBfcXVpdGVfIGd1YXJhbnRl ZSB0aGlzIHJpZ2h0IG5vdywgYW5kIGl0DQoNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3Vh cmFudGVlIGl0IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUuMQ0KDQpkZXNjcmliZXMgaG93IHRo ZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSwNCg0K YW55IHRpbWUgaXQgd2FudHMgKGFuZCBpdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIHByZS1leGlz dGluZyB0cmFuc3BvcnQNCg0KInN0b2xlbiIgZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rp b24hKTsgd2l0aG91dCB0YWtpbmcgc29tZXRoaW5nDQoNCmxpa2UgdWZyYWcgaW50byBhY2NvdW50 LCB0aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS4NCg0KVGhlIEJV TkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25l IGlzIHRyeWluZw0KDQp0byBvZmZlciBzdWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVq ZWN0IHRoZSBvZmZlciwgb3IgYXQgbGVhc3Qgbm90DQoNCmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFu c3BvcnRzLg0KDQoNCg0KSG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4g c2F5aW5nICJXZWxsLCBkdWgsIHRoYXQgaXMNCg0KdHJ1ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIs IHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhlIGlkZWEgb2YgZml4aW5nIHRoaXMNCg0Kd2l0aCB1ZnJh Zywgc2luY2UgdGhhdCdzIGhvdyB3ZSBtYWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBj YXNlLg0KDQpJIGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQg d2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0KDQoNCkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4 YW1wbGU6DQoNCg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KDQoNCmE9Z3Jv dXA6QlVORExFIG1pZDEgbWlkMiBtaWQzDQoNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2 DQoNCg0KDQpOb3csIHlvdSBoYXZlIHR3byB0cmFuc3BvcnRzOiBvbmUg4oCcb3duZWTigJ0gYnkg bWlkMSBhbmQgb25lIOKAnG93bmVkIiBieSBtaWQ0Lg0KDQoNCg0KDQoNClJlLW9mZmVyOg0KDQoN Cg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBt aWQ1IG1pZDYNCg0KDQoNCg0KDQpJbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90 IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZA0KDQptaWQ0IC0gdGhleSBhcmUgc3Rp bGwgdGhlIHNhbWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCg0K bm93IHN0YXJ0IHVzaW5nIHRoZSB0cmFuc3BvcnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYg d2lsbCBzdGFydCB1c2luZw0KDQp0aGUgdHJhbnNwb3J0IG9mIG1pZDEuDQoNCiAgICBSaWdodCwg YnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQg dGhpczoNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMgPC0tLSB1c2VzIHBvcnQgNTU1 NQ0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQ1IG1pZDYgPC0tLSB1c2VzIHBvcnQgNjY2Ng0KLi4u DQptPWF1ZGlvIDU1NTUgLi4uDQphPW1pZDptaWQxDQouLi4NCm09dmlkZW8gNjY2NiAuLi4NCmE9 bWlkOm1pZDQNCg0KYW5kIHRoZW4gaW4gYSByZW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0 IG1pZDIgbWlkMyA8LS0tIG1pZDQgYW5kIG1pZDEgaGF2ZSBzd2FwcGVkLi4uDQphPWdyb3VwOkJV TkRMRSBtaWQxIG1pZDUgbWlkNg0KLi4uDQptPWF1ZGlvIDY2NjYgLi4uIDwtLS0gYnV0IHRoZSBv ZmZlcmVyIGhhcyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8g bWlkMSBub3cNCmE9bWlkOm1pZDENCi4uLg0KbT12aWRlbyA1NTU1IC4uLg0KYT1taWQ6bWlkNA0K DQogICAgSWYgdGhlIGJ1bmRsZSBzcGVjIGFsbG93cyB0aGlzLCAidHJhbnNwb3J0IGZvbGxvd3Mg bS1zZWN0aW9uIiBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUg aXMgInRyYW5zcG9ydCBpcyBzaWduYWxlZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUiLCB3aGljaCBp cyBpbXBvc3NpYmxlIHdpdGggSUNFIHVubGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQu DQoNCg0KTWF5YmUg4oCcdHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdv cmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3Vw OkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3Bv cnQgYWxyZWFkeSBleGlzdHMgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4N Cg0KU28sIGluIHlvdXIgZXhhbXBsZSwgaSB0aGUgcmVvZmZlciB5b3UgYXJlIHN1Z2dlc3Rpbmcg dGhhdCBtaWQ0LCBtaWQyIGFuZCBtaWQzIHVzZXMgdGhlICI1NTU1IHRyYW5zcG9ydCIuIFNpbmNl IHRoaXMgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5 IG1pZDEsIG1pZDIgYW5kIG1pZDMpLCB5b3UgZG9u4oCZdCBoYXZlIHRvIGRvIGFuIElDRSByZXN0 YXJ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KICAgIFJpZ2h0LiBUaGUgb2ZmZXJl ciBleHBsaWNpdGx5IGluZGljYXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBp cyBhbWJpZ3VvdXMuIEkgbGlrZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdo eSBJIHByZWZlciBjbGFyaWZ5aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQg c2lnbmFsaW5nIGlzIHVzZWQgaW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lm eWluZyByZXN0cmljdGlvbnMgbGlrZSAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiB0byBo YW5kbGUgdGhlIElDRSBjYXNlLg0KSSB0b3RhbGx5IGFncmVlIOKAkyB0aGUgdHJhbnNwb3J0IGhh cyB0byBiZSBleHBsaWNpdGx5IGluZGljYXRlZC4gQnV0LCBkb27igJl0IHRoZSBJQ0UgU0RQIGF0 dHJpYnV0ZXMgYWxyZWFkeSBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB0cmFuc3BvcnQ/DQoNCiAg ICBTYWRseSwgbm90IHF1aXRlLCBiZWNhdXNlIHRoZXJlJ3Mgbm8gY2xlYXIgcmVxdWlyZW1lbnQg cmlnaHQgbm93IHRoYXQgdGhlIHVmcmFnIGlzIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQg KGFuZCBpbmRlZWQgaXQgaGFzIG5vdCBiZWVuIGltcGxlbWVudGVkIHRoYXQgd2F5IGJ5IENocm9t ZSBvciBGaXJlZm94KS4gVGhhdCdzIHdoYXQgSSdtIGFkdm9jYXRpbmcgZml4aW5nLCBpbnN0ZWFk IG9mIGFkZGluZyBhIGJ1bmNoIG9mIG5ldyBydWxlcyBmb3IgYnVuZGxlIHdpdGggSUNFLg0KDQpB cyBJIHdyb3RlIGluIG15IGUtbWFpbCBvbiBUaHVyc2RheSwgbXkgdW5kZXJzdGFuZGluZyBvZiBS RkMgNTI0NSBpcyB0aGF0IHRoZSB1ZnJhZyBtdXN0IGJlIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFu c3BvcnQsIGlmIHlvdSBkbyBhbiBJQ0UgcmVzdGFydCB5b3UgbXVzdCBjaGFuZ2UgdWZyYWcsIGFu ZCBhIGNoYW5nZSBvZiB1ZnJhZyB3aWxsIHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuLg0KDQpJZiBp bXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBmb2xsb3cgdGhlIHNwZWNzIGl0IGRvZXNu4oCZdCByZWFs bHkgbWF0dGVyIHdoYXQgd2Ugc3BlY2lmeeKApg0KDQoNCiAgICBUaGF0IGNoYW5naW5nIHRoZSB1 ZnJhZyBjYXVzZXMgYSB0cmFuc3BvcnQgY2hhbmdlIGlzIGNsZWFyLCBidXQgdGhlcmUgaXMgcHJl c2VudGx5IG5vIGxhbmd1YWdlIHNheWluZyB0aGF0IHlvdSBjYW5ub3Qgc3RhcnQgb3V0IHdpdGgg dGhlIHNhbWUgdWZyYWcgZm9yIGV2ZXJ5IG0tc2VjdGlvbiwgYW5kIHRoaXMgaXMgZnVydGhlciBj b25mdXNlZCBieSB0aGUgZmFjdCB0aGF0IGljZS11ZnJhZyBpcyBhbGxvd2VkIHRvIGJlIHNlc3Np b24gbGV2ZWwuDQoNCk9rLCBJIGhlYXIgd2hhdCB5b3UgYXJlIHNheWluZy4gV2UgY2FuIGFsd2F5 cyBtYW5kYXRlIHVuaXF1ZSB1ZnJhZyB2YWx1ZXMgaW4gQlVORExFLCBhbmQgbWF5YmUgYWxzbyBp biA1MjQ1YmlzICh0aGF0IGRpc2N1c3Npb24gYmVsb25ncyB0byB0aGUgSUNFIFdHLCB0aG91Z2gp Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CD12678ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0 Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkhpLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0aGF0IHRo ZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb2xsb3dzPG86cD48L286cD48L3By ZT4NCjxwcmU+dGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+YnVuZGxlLCB3aGF0IGFib3V0IHRo aXM/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+ YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpC VU5ETEUgbWlkMyBtaWQ0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+YW5kIGluIGEgcmVvZmZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDIgbWlkMzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkMTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBXaGF0IHRyYW5zcG9ydCBnb2VzIHdoZXJlPzxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkkgdGhpbmsgVGF5bG9yIHJhaXNlZCB0aGlzIGlzc3Vl IGVhcmxpZXIuIFdoYXQgeW91IGFyZSBkb2luZyBhYm92ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmlzPG86cD48L286cD48L3ByZT4NCjxwcmU+bW92aW5nIHN0cmVhbXMgZnJvbSBvbmUgQlVORExF IGdyb3VwIHRvIGFub3RoZXIsIGFuZCBtaXhpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ QlVORExFPG86cD48L286cD48L3ByZT4NCjxwcmU+Z3JvdXBzIHVwLCBhbmQgSSBkb27CuXQgdGhp bmsgdGhhdMK5cyBhIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNocmlzdGVyPG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHlvdSB3YW50 IHRvIGNsYXNzaWZ5IHRoaXMgYXMgYSBiYWQgaWRlYSwgd2UgbmVlZCBub3JtYXRpdmU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5sYW5ndWFnZSBmb3JiaWRkaW5nIGl0LiBGb3IgaW5zdGFuY2UsIGEg cnVsZSB0aGF0IG9uY2UgYSBtaWQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wbGFjZWQ8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5pbiBhIGJ1bmRsZSwgdGhlIG9ubHkgd2F5IHRvIHJlbW92ZSBp dCBpcyB0byBkaXNhYmxlIGl0LCBhcyB3ZWxsIGFzIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5y dWxlIHRvIGhhbmRsZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDIgbWlkMzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmE9bWlkOiBtaWQxICZsdDstLS0gbm90IGJ1bmRsZWQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPW1pZDogbWlkMjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9bWlkOiBtaWQz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YW5k IGluIGEgcmVvZmZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmE9Z3JvdXAgbWlkMSBtaWQyIG1pZDM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgV2Ugd291bGQgbmVlZCB0byBkZWZpbmUgd2hpY2ggdHJhbnNwb3J0IGlzIHJldGFpbmVkOyBt aWQxJ3MsIG9yPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlPG86cD48L286cD48L3ByZT4NCjxw cmU+YnVuZGxlJ3MuIE9yIHBlcmhhcHMgYSBydWxlIGZvcmJpZGRpbmcgcHJldmlvdXNseSB1bmJ1 bmRsZWQgbWlkcyB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJlPG86cD48L286cD48L3ByZT4N CjxwcmU+YWRkZWQgdG8gYSBidW5kbGUuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwcmU+SSB0aGluayB0aGlzIGlzIGNvdmVyZWQgaW4gc2VjdGlvbiA4LjUuMiAoQWRkaW5nIGEg bWVkaWEgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50bzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CVU5ETEUgZ3JvdXApIG9mIEJVTkRM RS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5B c3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9mIHRoZSBtaWQxIG0t bGluZSwgeW91PG86cD48L286cD48L3ByZT4NCjxwcmU+YXJlPG86cD48L286cD48L3ByZT4NCjxw cmU+c3VnZ2VzdGluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXAgKGZpcnN0 IGJ1bGxldCBpbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlY3Rpb248bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT44LjUuMikuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCB0aGUgb2ZmZXJlciBoYXMgdGhlIGNob2ljZSBv ZiByZXRhaW5pbmcgbWlkMSdzIHRyYW5zcG9ydCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vcjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmtlZXBpbmcgdGhlIG9sZCBidW5kbGUgdHJhbnNwb3J0LCBh Y2NvcmRpbmcgdG8gOC41LjIuIElmIHdlIGRvbid0IGRvPG86cD48L286cD48L3ByZT4NCjxwcmU+ c29tZXRoaW5nIGxpa2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBy dWxlcywgOC41LjI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53b3VsZCBoYXZlIHRvIGJlIHRpZ2h0 ZW5lZCBzaWduaWZpY2FudGx5LiBBZ2Fpbiwgb3VyIHR3byBjaG9pY2VzIGhlcmU6PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+MS4gRmluZCBhIHdh eSB0byBhbGxvdyBhbiBJQ0Ugb2ZmZXJlciB0byBpbmRpY2F0ZSB3aGF0IHRyYW5zcG9ydHMgaXQg aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXRhaW5pbmcgKGVnOyB1ZnJhZykuPG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+WW91IGRvIHRoYXQgdXNpbmcgdGhlIGE9Z3Jv dXAgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMiBtaWQzIG1lYW5zIHRoYXQgeW91IHdh bnQgdG8gdXNlIHRoZSB0cmFuc3BvcnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBhIG5ldyB0cmFu c3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5FTEUgbWlkMiBtaWQzIG1pZTEgbWVh bnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPm9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlkMiAocmVhZDoga2VlcCB0aGUgZXhpc3Rp bmcgQlVORExFIGdyb3VwIHRyYW5zcG9ydCkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Tm93LCBpZiB5b3UgSU4gQURESVRJT04gdG8gdGhhdCB3 YW50cyB0byBpbmRpY2F0ZSBzb21ldGhpbmcgSUNFPG86cD48L286cD48L3ByZT4NCjxwcmU+c3Bl Y2lmaWMsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZS5nLCB3aGV0aGVyIHRvIGRvIGFuIElDRSBy ZXN0YXJ0LCBJIGd1ZXNzIHlvdSBjb3VsZCB1c2UgdWZyYWcgZm9yIHRoYXQuPG86cD48L286cD48 L3ByZT4NCjxwcmU+QnV0LCBJIGRvbsK5dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZpYywg aXMgaXQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE9rLCBzbyB3aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyAmcXVvdDt0cmFuc3BvcnQg Zm9sbG93cyBtLXNlY3Rpb24mcXVvdDsuPG86cD48L286cD48L3ByZT4NCjxwcmU+QnV0IHRoZSBi dW5kbGUgc3BlYyBkb2Vzbid0IF9xdWl0ZV8gZ3VhcmFudGVlIHRoaXMgcmlnaHQgbm93LCBhbmQg aXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm9iYWJseSBzaG91bGRuJ3QgdHJ5IHRvIGd1YXJh bnRlZSBpdCBlaXRoZXIuIEZvciBpbnN0YW5jZSwgOC41LjE8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5kZXNjcmliZXMgaG93IHRoZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBm b3IgdGhlIGJ1bmRsZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbnkgdGltZSBpdCB3YW50cyAo YW5kIGl0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGEgcHJlLWV4aXN0aW5nIHRyYW5zcG9ydDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O3N0b2xlbiZxdW90OyBmcm9tIHNvbWUgb3RoZXIgYnVu ZGxlL20tc2VjdGlvbiEpOyB3aXRob3V0IHRha2luZyBzb21ldGhpbmc8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5saWtlIHVmcmFnIGludG8gYWNjb3VudCwgdGhpcyBpcyBpbXBvc3NpYmxlIHRvIGRl dGVjdCBpbiB0aGUgSUNFIGNhc2UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw cmU+VGhlIEJVTkRMRSBncm91cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBp ZiBzb21lb25lIGlzIHRyeWluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvIG9mZmVyIHN1Y2gg dGhpbmcgdGhlIGFuc3dlcmVyIHNob3VsZCByZWplY3QgdGhlIG9mZmVyLCBvciBhdCBsZWFzdCBu b3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hY2NlcHQgdGhlIG9mZmVyZWQgdHJhbnNwb3J0cy48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhv d2V2ZXIsIHlvdSB3b3VsZCBiZSBjb21wbGV0ZWx5IHJpZ2h0IGluIHNheWluZyAmcXVvdDtXZWxs LCBkdWgsIHRoYXQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50cnVlIGZvciBub24tQlVORExF IGFsc28hJnF1b3Q7LCB3aGljaCBpcyB3aHkgSSBsaWtlIHRoZSBpZGVhIG9mIGZpeGluZyB0aGlz PG86cD48L286cD48L3ByZT4NCjxwcmU+d2l0aCB1ZnJhZywgc2luY2UgdGhhdCdzIGhvdyB3ZSBt YWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBjYXNlLjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cHJlPkkgZ3Vlc3MgSSBzdGlsbCBoYXZlIHNvbWUgcHJvYmxlbXMgdG8g dW5kZXJzdGFuZCB3aGF0IHRoZSBwcm9ibGVtIGlzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4 YW1wbGU6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+SW5pdGlhbCBvZmZlci9hbnN3ZXIgZXhjaGFuZ2U6PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1p ZDM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDUgbWlkNjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5vdywg eW91IGhhdmUgdHdvIHRyYW5zcG9ydHM6IG9uZSDigJxvd25lZOKAnSBieSBtaWQxIGFuZCBvbmUg 4oCcb3duZWQmcXVvdDsgYnkgbWlkNC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZS1vZmZl cjo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h PWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3Jv dXA6QlVORExFIG1pZDEgbWlkNSBtaWQ2PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+SW4gdGhl IHJlLW9mZmVyLCB0aGUgb2ZmZXJlciBkb2VzIG5vdCBjaGFuZ2UgdGhlIHRyYW5zcG9ydHMgb2Yg bWlkMSBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5taWQ0IC0gdGhleSBhcmUgc3RpbGwgdGhl IHNhbWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGw8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5ub3cgc3RhcnQgdXNpbmcgdGhlIHRyYW5zcG9ydCBvZiBtaWQ0LCBhbmQg bWlkNSBhbmQgbWlkNiB3aWxsIHN0YXJ0IHVzaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhl IHRyYW5zcG9ydCBvZiBtaWQxLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyBSaWdodCwgYnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBidW5kbGUgc3BlYyBkb2VzIG5v dCBmb3JiaWQgdGhpczo8YnI+DQo8YnI+DQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMyAm bHQ7LS0tIHVzZXMgcG9ydCA1NTU1PGJyPg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQ1IG1pZDYg Jmx0Oy0tLSB1c2VzIHBvcnQgNjY2Njxicj4NCi4uLjxicj4NCm09YXVkaW8gNTU1NSAuLi48YnI+ DQphPW1pZDptaWQxPGJyPg0KLi4uPGJyPg0KbT12aWRlbyA2NjY2IC4uLjxicj4NCmE9bWlkOm1p ZDQ8YnI+DQo8YnI+DQphbmQgdGhlbiBpbiBhIHJlb2ZmZXI6PGJyPg0KPGJyPg0KYT1ncm91cDpC VU5ETEUgPGI+bWlkNDwvYj4gbWlkMiBtaWQzICZsdDstLS0gbWlkNCBhbmQgbWlkMSBoYXZlIHN3 YXBwZWQuLi48YnI+DQphPWdyb3VwOkJVTkRMRSA8Yj5taWQxPC9iPiBtaWQ1IG1pZDY8YnI+DQou Li48YnI+DQptPWF1ZGlvIDxiPjY2NjY8L2I+IC4uLiAmbHQ7LS0tIGJ1dCB0aGUgb2ZmZXJlciBo YXMgZXhwbGljaXRseSBpbmRpY2F0ZWQgdGhhdCA2NjY2IGlzIGF0dGFjaGVkIHRvIG1pZDEgbm93 PGJyPg0KYT1taWQ6bWlkMTxicj4NCi4uLjxicj4NCm09dmlkZW8gPGI+NTU1NTwvYj4gLi4uPGJy Pg0KYT1taWQ6bWlkNDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGUgYnVuZGxl IHNwZWMgYWxsb3dzIHRoaXMsICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiZxdW90 OyBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUgaXMgJnF1b3Q7 dHJhbnNwb3J0IGlzIHNpZ25hbGVkIGV4cGxpY2l0bHkgZXZlcnkgdGltZSZxdW90Oywgd2hpY2gg aXMgaW1wb3NzaWJsZSB3aXRoIElDRSB1bmxlc3MgdWZyYWcgaXMgdGFrZW4gaW50byBhY2NvdW50 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6cmVkIj5NYXliZSZuYnNwO+KAnHRyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlv buKAnSBpcyB3cm9uZyB3b3JkaW5nLiBUcmFuc3BvcnQgaXMgd2hhdGV2ZXIgdGhlIGZpcnN0IG1p ZCBpbiB0aGUgYT1ncm91cDpCVU5ETEUgYXR0cmlidXRlIGluZGljYXRlcyBpdCB0byBiZSwgYW5k IGlmIHRoYXQgdHJhbnNwb3J0IGFscmVhZHkgZXhpc3RzDQogdGhlcmUgaXMgbm8gbmVlZCB0byBk byBhbiBJQ0UgcmVzdGFydC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5TbywgaW4geW91ciBleGFtcGxl LCBpIHRoZSByZW9mZmVyIHlvdSBhcmUgc3VnZ2VzdGluZyB0aGF0IG1pZDQsIG1pZDIgYW5kIG1p ZDMgdXNlcyB0aGUgJnF1b3Q7NTU1NSB0cmFuc3BvcnQmcXVvdDsuIFNpbmNlIHRoaXMgdHJhbnNw b3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5IG1pZDEsIG1pZDIN CiBhbmQgbWlkMyksIHlvdSBkb27igJl0IGhhdmUgdG8gZG8gYW4gSUNFIHJlc3RhcnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnJlZCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBS aWdodC4gVGhlIG9mZmVyZXIgZXhwbGljaXRseSBpbmRpY2F0ZWQgd2hhdCBpdCB3YW50cyB0byBk bywgYW5kIG5vdGhpbmcgaXMgYW1iaWd1b3VzLiBJIGxpa2UgdGhpcyB3YXkgb2YgZG9pbmcgdGhp bmdzLiBXaGljaCBpcyB3aHkgSSBwcmVmZXIgY2xhcmlmeWluZyB0aGUgc3BlYyB0byBzYXkgdGhh dCB0aGlzIGV4cGxpY2l0IHNpZ25hbGluZyBpcyB1c2VkIGluIHRoZSBJQ0UgY2FzZSB0b28sIHJh dGhlciB0aGFuIHNwZWNpZnlpbmcNCiByZXN0cmljdGlvbnMgbGlrZSAmcXVvdDt0cmFuc3BvcnQg Zm9sbG93cyBtLXNlY3Rpb24mcXVvdDsgdG8gaGFuZGxlIHRoZSBJQ0UgY2FzZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRvdGFsbHkgYWdyZWUg4oCTIHRoZSB0cmFu c3BvcnQgaGFzIHRvIGJlIGV4cGxpY2l0bHkgaW5kaWNhdGVkLiBCdXQsIGRvbuKAmXQgdGhlIElD RSBTRFAgYXR0cmlidXRlcyBhbHJlYWR5IGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhlIHRyYW5zcG9y dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzcwQUQ0Nzttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFNhZGx5LCBub3QgcXVpdGUsIGJlY2F1c2UgdGhlcmUncyBubyBjbGVhciByZXF1aXJlbWVu dCByaWdodCBub3cgdGhhdCB0aGUgdWZyYWcgaXMgZGlmZmVyZW50IGZvciBlYWNoIHRyYW5zcG9y dCAoYW5kIGluZGVlZCBpdCBoYXMgbm90IGJlZW4gaW1wbGVtZW50ZWQgdGhhdCB3YXkgYnkgQ2hy b21lIG9yIEZpcmVmb3gpLiBUaGF0J3Mgd2hhdCBJJ20gYWR2b2NhdGluZyBmaXhpbmcsIGluc3Rl YWQgb2YgYWRkaW5nDQogYSBidW5jaCBvZiBuZXcgcnVsZXMgZm9yIGJ1bmRsZSB3aXRoIElDRS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+QXMgSSB3cm90ZSBpbiBteSBl LW1haWwgb24gVGh1cnNkYXksIG15IHVuZGVyc3RhbmRpbmcgb2YgUkZDIDUyNDUgaXMgdGhhdCB0 aGUgdWZyYWcgbXVzdCBiZSBkaWZmZXJlbnQgZm9yIGVhY2ggdHJhbnNwb3J0LCBpZiB5b3UgZG8g YW4gSUNFIHJlc3RhcnQgeW91IG11c3QgY2hhbmdlDQogdWZyYWcsIGFuZCBhIGNoYW5nZSBvZiB1 ZnJhZyB3aWxsIHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuLiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM3MEFENDciPklmIGltcGxlbWVudGF0aW9ucyBkb27igJl0IGZvbGxvdyB0 aGUgc3BlY3MgaXQgZG9lc27igJl0IHJlYWxseSBtYXR0ZXIgd2hhdCB3ZSBzcGVjaWZ54oCmPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM3MEFENDciPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGF0IGNoYW5naW5nIHRoZSB1ZnJh ZyBjYXVzZXMgYSB0cmFuc3BvcnQgY2hhbmdlIGlzIGNsZWFyLCBidXQgdGhlcmUgaXMgcHJlc2Vu dGx5IG5vIGxhbmd1YWdlIHNheWluZyB0aGF0IHlvdSBjYW5ub3Qgc3RhcnQgb3V0IHdpdGggdGhl IHNhbWUgdWZyYWcgZm9yIGV2ZXJ5IG0tc2VjdGlvbiwgYW5kIHRoaXMgaXMgZnVydGhlciBjb25m dXNlZCBieSB0aGUgZmFjdCB0aGF0IGljZS11ZnJhZyBpcyBhbGxvd2VkIHRvIGJlIHNlc3Npb24g bGV2ZWwuPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNzBBRDQ3Ij5PaywgSSBoZWFyIHdoYXQgeW91IGFyZSBzYXlpbmcuIFdlIGNhbiBhbHdheXMg bWFuZGF0ZSB1bmlxdWUgdWZyYWcgdmFsdWVzIGluIEJVTkRMRSwgYW5kIG1heWJlIGFsc28gaW4g NTI0NWJpcyAodGhhdCBkaXNjdXNzaW9uIGJlbG9uZ3MgdG8gdGhlIElDRSBXRywgdGhvdWdoKS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzBBRDQ3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzcwQUQ0NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPkNocmlzdGVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM3MEFENDciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CD12678ESESSMB109erics_-- From nobody Fri Sep 1 10:02:16 2017 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 D01581342ED; Fri, 1 Sep 2017 10:02:14 -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.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150428533480.3233.6972186263976659113@ietfa.amsl.com> Date: Fri, 01 Sep 2017 10:02:14 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-23.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 17:02:15 -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 : JavaScript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-23.txt Pages : 115 Date : 2017-09-01 Abstract: This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-23 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-23 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 Fri Sep 1 10:07:31 2017 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 88042132E0D for ; Fri, 1 Sep 2017 10:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 XIXp685iLoot for ; Fri, 1 Sep 2017 10:07:22 -0700 (PDT) Received: from smtp105.iad3a.emailsrvr.com (smtp105.iad3a.emailsrvr.com [173.203.187.105]) (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 90D5E13420B for ; Fri, 1 Sep 2017 10:07:21 -0700 (PDT) Received: from smtp6.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp6.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id BEE9F54D1; Fri, 1 Sep 2017 13:07:20 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp6.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 34F6052E3; Fri, 1 Sep 2017 13:07:20 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 13:07:20 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <150428533503.3233.7054787784910290209.idtracker@ietfa.amsl.com> Date: Fri, 1 Sep 2017 11:07:19 -0600 Cc: Justin Uberti , Eric Rescorla , Magnus Westerlund Content-Transfer-Encoding: quoted-printable Message-Id: <1AF5863D-F8DA-4073-BC0A-51900205D2FF@iii.ca> References: <150428533503.3233.7054787784910290209.idtracker@ietfa.amsl.com> To: RTCWeb IETF , IETF Rinse Repeat X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [rtcweb] New Version Notification for draft-ietf-rtcweb-jsep-23.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 17:07:23 -0000 We have submitted a new version to address some of the Last Call = comments.=20 The changes are: o Clarify rollback handling, and treat it similarly to other setLocal/setRemote usages. o Adopt a first-fit policy for handling multiple remote a=3Dimageattr attributes. We hope this addresses Magnus comments on imageaddr=20 o Clarify that a session description with zero m=3D sections is = legal as specified by existing RFCs.=20 Thanks, Cullen > On Sep 1, 2017, at 11:02 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-ietf-rtcweb-jsep-23.txt > has been successfully submitted by Cullen Jennings and posted to the > IETF repository. >=20 > Name: draft-ietf-rtcweb-jsep > Revision: 23 > Title: JavaScript Session Establishment Protocol > Document date: 2017-09-01 > Group: rtcweb > Pages: 115 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-23.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ > Htmlized: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-23 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep-23 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-jsep-23 >=20 > Abstract: > This document describes the mechanisms for allowing a JavaScript > application to control the signaling plane of a multimedia session > via the interface specified in the W3C RTCPeerConnection API, and > discusses how this relates to existing signaling protocols. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Fri Sep 1 14:41:50 2017 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 4940E1343FD for ; Fri, 1 Sep 2017 14:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 ioOvoWTmp7E8 for ; Fri, 1 Sep 2017 14:41:47 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B3C1343CB for ; Fri, 1 Sep 2017 14:41:47 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id j17so2016716iti.1 for ; Fri, 01 Sep 2017 14:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=imS/r9AQOCfwNETL3gQOGMq40/FNASKxlt0Uqb0tfeM=; b=ASxxdEKk1NGPNj3y88MXTi/SY9bWXT1NzjN9lHera8q4cBLETc0thfPqRWrhxTk1oA QSWJfrzJkdqWeWV1W1UKUlEg4AmReb570tacZnj/e5hfJ5OBukFCFVQFXivTRp4pnbyY fo0Nht7fPxOza9lBk+QXj3IQoKuOX7jnyj9TRpsSy1n49rn5T65ZGvyU2TrlNb7TkUtQ eREgiSppCmuRfjAk7IhZbVK59BRQCYrWOSnrrt7eABX6IkZZax20OEvE0ge4dy0GQo49 IsKJbnKyasZZD34aS3Cex2SBd32+0ObsgXsu4BCpe34W03gR765AogTxk0buNYhAd4Bi abCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=imS/r9AQOCfwNETL3gQOGMq40/FNASKxlt0Uqb0tfeM=; b=Epr5jFvO3HRb9zhT+sBBTs8cjydH5uDmnySkAAzzJQuYpeYYOAHqESS78MrRMakpE8 tU6bloK4m0yCzk8xiSUmpB50Th2PQwMyM7GwkyTpO72X3tj78QHroH8wzq+eXvawrBfK cq4it5dgEvc9/IETDhoQnypS39vi20G8gLUpwwULoIBWdKxkSO9y/kg63tWZmFcl2zdk EVjSjIfM4B3qQwBRynysQHdWdF4hok/mUWsytLPHixAn4DO8D7aunACdjQuM2G2Q0RDp p9d4xBEYVCptexJBfpQbWnnYmN3taU9nr8qmdteZrbHVdTPoBZXQO4226vrwyMnwiHi0 bZtA== X-Gm-Message-State: AHPjjUgfrK7R+tMBkWYYLtoiUy/XZN8WIbn2hX9PvpCscUeIJ7+6YGiS aTF3YeQaRbUGiwVCniSSYa5iHMhsKKkU X-Google-Smtp-Source: ADKCNb4ySzJHBgF7Xmd9p9VyWt/tYFTcv1+4/LzPA6i79l7kExRBVgigLRvg2g69COMNivedFCo795Ya8QZt0HlWamg= X-Received: by 10.36.159.135 with SMTP id c129mr776588ite.38.1504302106175; Fri, 01 Sep 2017 14:41:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.148.209 with HTTP; Fri, 1 Sep 2017 14:41:25 -0700 (PDT) In-Reply-To: References: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com> <554c4448-4731-a92c-67b4-dbf86a681319@ericsson.com> From: Justin Uberti Date: Fri, 1 Sep 2017 14:41:25 -0700 Message-ID: To: Magnus Westerlund Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08cd8aacc9b7055827a039" Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec-06 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 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, 01 Sep 2017 21:41:49 -0000 --94eb2c08cd8aacc9b7055827a039 Content-Type: text/plain; charset="UTF-8" Magnus, did you have a chance to take a look at this? I think this is the sole actionable remaining issue for this document. On Sun, Aug 27, 2017 at 1:25 PM, Justin Uberti wrote: > PTAL at https://github.com/juberti/draughts/pull/89 > > On Fri, Jul 21, 2017 at 12:51 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> >> >> Den 2017-07-20 kl. 08:25, skrev Justin Uberti: >> >> Thanks for your comments. Regarding #2, the document currently says the >> following: >> >> Since use of FEC always causes redundant data to be transmitted, this >> will lead to less bandwidth available for the primary encoding when >> in a bandwidth-constrained environment. >> >> Do you think this is insufficient? >> >> >> Yes, I think it should be more explicit that primary + repair need to be >> within the bandwidth limits set by congestion control, etc. >> >> /Magnus >> >> >> On Sun, Jul 16, 2017 at 2:40 AM, Magnus Westerlund < >> magnus.westerlund@ericsson.com> wrote: >> >>> Hi, >>> >>> I was reviewing -06 to ensure that all issues are resolved. I did notice >>> the following issues. >>> >>> >>> 1. Section 4.2, makes a normative refernces to TS.26114, which is listed >>> as informative refences in the reference list. Please move it to the >>> normative part. >>> >>> 2. Section 8. I am missing the statement that primary encoding + FEC >>> needs to keep within the available bandwidth as determined by the >>> congestion control or other bitrate adaptation mechnisms. Thus, likely >>> resulting in that the primary encoding bitrate needs to be reduced to fit >>> the FEC. >>> >>> Otherwise the document looks good. >>> >>> Cheers >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Media Technologies, Ericsson Research >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Torshamnsgatan 23 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> >>> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Media Technologies, Ericsson Research >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 <+46%2010%20714%2082%2087> >> Torshamnsgatan 23 | Mobile +46 73 0949079 <+46%2073%20094%2090%2079> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> > --94eb2c08cd8aacc9b7055827a039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Magnus, did you have a chance to take a look at this? I th= ink this is the sole actionable remaining issue for this document.

On Sun, Aug 27, 2017= at 1:25 PM, Justin Uberti <juberti@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

On Fri, J= ul 21, 2017 at 12:51 AM, Magnus Westerlund <magnus.westerlund= @ericsson.com> wrote:
=20 =20 =20



Den 2017-07-20 kl. 08:25, skrev Justin Uberti:
=20
Thanks for your comments. Regarding #2, the document currently says the following: 

   Since use of FEC always causes redundant data to be transmitt=
ed, this
   will lead to less bandwidth available for the primary encoding when
   in a bandwidth-constrained environment.

          
Do you think this is=
 insufficient? 

        

      

    

    

    Yes, I think it should be more explicit that primary + repair need
    to be within the bandwidth limits set by congestion control, etc. 

    

    /Magnus

    

    

      


        
On Sun, Jul 16, 2017 at 2:40 AM, Magnus
          Westerlund <magnus.westerlund@ericsson.com=
>
          wrote:

          
Hi,

            

            I was reviewing -06 to ensure that all issues are resolved.
            I did notice the following issues.

            

            

            1. Section 4.2, makes a normative refernces to TS.26114,
            which is listed as informative refences in the reference
            list. Please move it to the normative part.

            

            2. Section 8. I am missing the statement that primary
            encoding + FEC needs to keep within the available bandwidth
            as determined by the congestion control or other bitrate
            adaptation mechnisms. Thus, likely resulting in that the
            primary encoding bitrate needs to be reduced to fit the FEC.
            

            Otherwise the document looks good.

            

            Cheers

            

            Magnus Westerlund

            

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

            Media Technologies, Ericsson Research

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

            Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0| Phone=C2=A0 +46 10 7148287

            Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Mob=
ile +46 73 0949079

            SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com

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

            

            

          

        

        

      

    

    

    
--=20

Magnus Westerlund=20

-----------------------------------------------------------------=
-----
Media Technologies, Ericsson Research
-----------------------------------------------------------------=
-----
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------=
-----

  









--94eb2c08cd8aacc9b7055827a039--


From nobody Fri Sep  1 14:43:59 2017
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 DB0A8134323 for ; Fri,  1 Sep 2017 14:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 ap0vEfLXdMuR for ; Fri,  1 Sep 2017 14:43:56 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B4A1344D9 for ; Fri,  1 Sep 2017 14:43:55 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id d78so7000332ioe.4 for ; Fri, 01 Sep 2017 14:43:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HKYTqbiiyHseaEumOIGWHQVDFLe/WK25wPIGvfrBuLs=; b=EAAQP4uoOS13T8CBgTf33Pw8KMbwsT8FAEPG/MQtIdyANN2PA9hNea7ai9USmWtw9S 6D6KYIoSs1o6NqZHlcSU4DuVAFNV10N3sYXsP9wJpHu1dVYQ8F3YlLP6+HOKyR3SUGt1 z8qLp5xDbiAjWYEwwm2re7nvIq2DBXd70JQyHVAj6qMwJcnruHh+FOiO5KRQT539P42I cc459wxxQvui0ADWmNdN21DEaktju2Ijyl3e9NT7W8pLPmUC1JiE8tlzuvQFjvWAprxr jM5CQV0KowLS7rjxFSkerJThrpF7kQ+tPSE5aibc7DQ1Nw01xh+MR0amBYry9+DspKji M4lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HKYTqbiiyHseaEumOIGWHQVDFLe/WK25wPIGvfrBuLs=; b=nEKd0DxPIHWLX5OQiXd//UjoG8g4X9qQKpivWb56aUB/feuEQipgyOiB/mvfM5pLBW LTSNV/DbAT++3g7NunATiCrlBm2oWc1j251y1cH2mp1qKoAZkdNBTiof2CkkdI3aGq3i 3rhMO0aAPByCNR1cyWUMjq0mwHL72Cp+A2cVDD9Xh4fJPc8hisIWeS0HiYXxq+Nqdu0o DWed5HkSv88GO7IWF3kCglaVhqEXIHyN3G10k9ejrcfsIlNDJfPoAF0Ji/30qmEK9bwM 0L9FGB/pA7BsaGrIwr+mTnyx8gzicS+IIYt3l+EkCJuCIalUIb6myUDzkAw8fhuHZ6UA Wzbg==
X-Gm-Message-State: AHPjjUiQaqaSgRXHZmUf3dS+u2yl0ARHIgscR9WLTYQBsviJECnP3kr1 P6TkHNsHQpWuqWWWSlo2UOqcHpIUQsBw
X-Google-Smtp-Source: ADKCNb6y1xDwh9xIO+fcx82Na11iFBU4jY4PELJSyEfXBtN5RALt3+x1UscKT7+vj9lVffdlcQ3YogYlOt00L+z/hPc=
X-Received: by 10.107.142.18 with SMTP id q18mr2803485iod.316.1504302234949; Fri, 01 Sep 2017 14:43:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.148.209 with HTTP; Fri, 1 Sep 2017 14:43:34 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Fri, 1 Sep 2017 14:43:34 -0700
Message-ID: 
To: Bernard Aboba 
Cc: "rtcweb@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c05c5d059d125055827a834"
Archived-At: 
Subject: Re: [rtcweb] JSEP Issue 760: what states/methods allow a "rollback"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Sep 2017 21:43:58 -0000

--94eb2c05c5d059d125055827a834
Content-Type: text/plain; charset="UTF-8"

Note that the latest -23 version has text that explicitly specifies which
states allow rollback.

On Thu, Jul 27, 2017 at 10:08 AM, Bernard Aboba 
wrote:

> Filed as: https://github.com/rtcweb-wg/jsep/issues/760
>
> In W3C WebRTC WG, Issue 1470 was filed relating to checking whether
> rollback is allowed:
> https://github.com/w3c/webrtc-pc/issues/1470
>
> In discussing this issue, we noticed that precise guidance wasn't
> available in JSEP, so this issue was filed.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--94eb2c05c5d059d125055827a834
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Note that the latest -23 version has text that explicitly =
specifies which states allow rollback.

=

On Thu, Jul 27, 2017 at 10:08 AM, Bernard Aboba =
<bernard.aboba@gmail.com> wrote:
Filed as: https://github.com/rtcweb-wg/=
jsep/issues/760

In W3C WebRTC WG, Issue 1470 was=
 filed relating to checking whether rollback is allowed:

In discussing this issue, we noticed that precise guidance wasn't avai=
lable in JSEP, so this issue was filed.


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--94eb2c05c5d059d125055827a834--


From nobody Fri Sep  1 14:46:16 2017
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 C198113455E for ; Fri,  1 Sep 2017 14:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 oAYS_xNvSWBn for ; Fri,  1 Sep 2017 14:45:59 -0700 (PDT)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 993ED13464B for ; Fri,  1 Sep 2017 14:45:56 -0700 (PDT)
Received: by mail-it0-x231.google.com with SMTP id p2so2605102ite.0 for ; Fri, 01 Sep 2017 14:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EBLQDejeeN//rxjo72NRBeCJ1LSB5nfcRXnd717z79Q=; b=FrBToDt7tm9yABMT73NBd6bMDi1tfvo7XzrfLAuBFx0LDMAg8J1l39cejlGp/ion/q 1tsYYoVvFmFtaPbU/ho2lAfa/sCLo3YbWI/zmRlnnAEC1DbrASv/e3VBBazAGAuufLDT ZdZxfjXWO7WNMPDL7KEqTnPVQJCWOmhHUXwMIO/KmFQloSYhEJ2dlYXOg4sTHSuxp4K0 a5g+5AeMAC43ww+xXiZqsrpgHz8eNLuffMJTyk+ANxGV1po82IRndNYaGMuMEtlUcgML hVZ8IHsgvZJUqtg8uqUjSCwo/fsbUBA9eQr7i3bQBUI0372fipO+7Bbtucsva1IqpX13 E4RQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EBLQDejeeN//rxjo72NRBeCJ1LSB5nfcRXnd717z79Q=; b=BFkE/JNg3Ik073tLy56O50PKOvFBgbkjIZqaNkro+CafSdjBqK4jU3LCeh7GietZYr flTGWhAw0hVPDmehtC98syd7Euwi/TyDwSsiaSWB8fuK54Br1ptIHnwbO0VoBHfnjQGi P2EYMNqiPymG4ColZb9VbnW5QLjagd3r4oG5MKPn1/cW2hld1px4dMaCe6QkrNGz/Aq7 qqLQoAGMTvv3ZXFOaOSJj0snZkMLhyDot50B3GSkZfDJOyJttgyr2xXAI3udjNCd2Wo3 nRD+/ncxvz+lC8jkwfs3sMn/RQ0ofT+PpKs7Gk69otBaiepndIjq2QN9xQGaSnqu3MUE i2aQ==
X-Gm-Message-State: AHPjjUg/vcYs3qVeQWJ/XfVinPeVPkSkXH3tzv8odYlv+y0/os5j1g/T OUSBvKTwmCbiQAJrQY613A3OjTk4XWuZ
X-Google-Smtp-Source: ADKCNb7jAvnFFlS4qLq1VXOOwd0TIuY05/MkhL13OSZX5a7ML4jASlHrMwo1nao3o2iVWLXerCllky2k5rNZVT3XvPw=
X-Received: by 10.36.34.15 with SMTP id o15mr809279ito.133.1504302355684; Fri, 01 Sep 2017 14:45:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.148.209 with HTTP; Fri, 1 Sep 2017 14:45:34 -0700 (PDT)
In-Reply-To: <65A7933F-39BC-4E21-B5D2-9F9BB61B7ED7@iii.ca>
References: <150293290297.12432.15822575176336895893@ietfa.amsl.com> <65A7933F-39BC-4E21-B5D2-9F9BB61B7ED7@iii.ca>
From: Justin Uberti 
Date: Fri, 1 Sep 2017 14:45:34 -0700
Message-ID: 
To: Cullen Jennings 
Cc: Carlos Martinez , draft-ietf-rtcweb-jsep.all@ietf.org,  ops-dir@ietf.org, RTCWeb IETF , ietf@ietf.org
Content-Type: multipart/alternative; boundary="001a113f741e8c3ff9055827af6a"
Archived-At: 
Subject: Re: [rtcweb] Opsdir last call review of draft-ietf-rtcweb-jsep-21
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Sep 2017 21:46:01 -0000

--001a113f741e8c3ff9055827af6a
Content-Type: text/plain; charset="UTF-8"

Following up on this - we made some text changes in the -22 version of the
document that should address your comments. Thanks!

On Thu, Aug 17, 2017 at 11:13 AM, Cullen Jennings  wrote:

>
> On Aug 16, 2017, at 6:21 PM, Carlos Martinez 
> wrote:
>
> Reviewer: Carlos Martinez
> Review result: Ready
>
> I have reviewed this document as part of the Operational directorate's
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
>
> Noting that I'm certainly not an expert on the subject matter, I've found
> this
> document to be READY. I found it well-written, it contains plenty of
> detailed
> examples (which I believe are really important for API and
> programming-heavy
> documents), and includes plenty of references as well.
>
> Please do not forget to remove "Appendix B.  Change log".
>
> A minor observation, not even a nit, is that the text in the Security
> Considerations "While formally the JSEP interface is an API, it is better
> to
> think of it is an Internet protocol, with the JS being untrustworthy from
> the
> perspective of the endpoint. " could be more clear.
>
> thanks!
>
> /Carlos
>
>
>
> Thanks Carlos, I'll have a look at the things you mention (
> https://github.com/rtcweb-wg/jsep/issues/791 and https:/
> /github.com/rtcweb-wg/jsep/issues/792 for tracking )
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--001a113f741e8c3ff9055827af6a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Following up on this - we made some text changes in the -2=
2 version of the document that should address your comments. Thanks!
<=
div class=3D"gmail_extra">
On Thu, Aug 17, 20=
17 at 11:13 AM, Cullen Jennings <fluffy@iii.ca> wrote:

On Aug 16, 2017, at 6:21 PM, Car=
los Martinez <carlosm3011@gmail.com> wrote:

Reviewer: Carlos Martinez
Review=
 result: Ready

I have reviewed this document as part of the Operatio=
nal directorate's ongoing
effort to review all IETF documents being =
processed by the IESG.=C2=A0 These
comments were written with the intent=
 of improving the operational aspects of
the IETF drafts. Comments that =
are not addressed in last call may be included
in AD reviews during the =
IESG review.=C2=A0 Document editors and WG chairs should
treat these com=
ments just like any other last call comments.

Noting that I'm ce=
rtainly not an expert on the subject matter, I've found this
documen=
t to be READY. I found it well-written, it contains plenty of detailed
e=
xamples (which I believe are really important for API and programming-heavy=

documents), and includes plenty of references as well.

Please do=
 not forget to remove "Appendix B.=C2=A0 Change log".

A mi=
nor observation, not even a nit, is that the text in the Security
Consid=
erations "While formally the JSEP interface is an API, it is better to=

think of it is an Internet protocol, with the JS being untrustworthy fr=
om the
perspective of the endpoint. " could be more clear.

t=
hanks!

/Carlos



Thanks Carlos, I'll have a look at the things you menti=
on (=C2=A0https://github.com/rtcweb-wg/jsep/issues/791=C2=A0and=
=C2=A0https://github.com/rtcweb-wg/jsep/issues/792=C2=A0for t=
racking )


______________________________=
_________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--001a113f741e8c3ff9055827af6a--


From nobody Fri Sep  1 14:47:29 2017
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 16EB31344FC for ; Fri,  1 Sep 2017 14:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 Hr7P9p8nIYdU for ; Fri,  1 Sep 2017 14:47:26 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512B4132D0C for ; Fri,  1 Sep 2017 14:47:26 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id f199so903622ita.1 for ; Fri, 01 Sep 2017 14:47:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bLBgldyW0zuKODhzh//3tEkXft6q3uKwbOAw9+U7E2g=; b=e6AifEhWFQ14pGfE3B/vWhibZof5pVai8AScTM5+7Cs21mKmjn7uus21FbeST7dv3x RexdAcsdYt1aSHmGKbC1spzBAGicWc7AettNKeShz5obK9sKGMy1R2TVSCvIRd3ZwUmg XgGT7An9niPfKrNn5pMpugQ7ATPvWxymAPd2a3yWx8F6b9UfmqUZ/2EER1T7LD7Ax7S6 rEXXss0Z3u1GDUE0B4nTQpqX81dzdybd9eCIKTzgkPsdlocppkrBlI8hFSNG3eGS9lGs D330tW0J9hGeVU8GqEdPbLbGVeP0NOIwEhfqziywrNyFEVJCadAqIn34XAiLONWJb/RC 18BQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bLBgldyW0zuKODhzh//3tEkXft6q3uKwbOAw9+U7E2g=; b=AwC+an+HNMxdyhNXU2Co563vX9RaBN3+74djrV6B6OsUbz6cUnI6w0Bo0q8OTKVAZ4 bywgtKmh+9n/LOnCWRcr0qxxPvp9h+n/gDWsf//6QPurLcaayZvA9tygy+2WyDt2LJro E57gxAEHN5QUN8lXRQ/FFL6Tk7J9NQ8foXnXo0dbMz6ioOQal3iSTVTYG65aGb1Z6G1U aJwpbzPR2w/zRW4mAGjsNjKEf+y6cIXNoKhFS5/KnwY2sPes+lbdFIq8lsmFCyWHzsAH BmraxqketZBC+RhLR/E5E/NEFOOWdGVEaJTA3B13ZUIRq1WH11SbFynKEnj9pKPPWLfX iOfg==
X-Gm-Message-State: AHPjjUjJmpUhBVTY0KepxE35cHxlq0Lm+8X+DA0pbapyqFMioL9j4Gyq kebrYxFCPzx87E+D/y613y0Uoayo1u9K
X-Google-Smtp-Source: ADKCNb5liNozaqXTSk+mPAKp3sgHK5+ag6OWU1ZZBbikZ52GfL95Oeh70qiNBjxmPUMZZWQSxifuwagRuT190HJv7iQ=
X-Received: by 10.36.176.75 with SMTP id b11mr942029itj.101.1504302445453; Fri, 01 Sep 2017 14:47:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.148.209 with HTTP; Fri, 1 Sep 2017 14:47:04 -0700 (PDT)
In-Reply-To: 
References: 
From: Justin Uberti 
Date: Fri, 1 Sep 2017 14:47:04 -0700
Message-ID: 
To: Ted Hardie 
Cc: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner 
Content-Type: multipart/alternative; boundary="089e08231884e5f6d2055827b40d"
Archived-At: 
Subject: Re: [rtcweb] Working Group Last call on draft-ietf-rtcweb-fec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 01 Sep 2017 21:47:28 -0000

--089e08231884e5f6d2055827b40d
Content-Type: text/plain; charset="UTF-8"

I have received a couple comments from Bernard on this issue, but it could
use more attention to drive it to resolution.

PTAL and comment. Thanks!

On Wed, Aug 2, 2017 at 4:03 PM, Ted Hardie  wrote:

> This call begins a two-week working group last call on
> draft-ietf-rtcweb-fec.  There is one outstanding issue:
> https://github.com/juberti/draughts/issues/81, in which Bernard questions
> the usefulness of the mandated OPUS FEC.  Comments on that issue are
> solicited, as are any other issues which may be identified in review.
>
> regards,
>
> Ted, Sean, Cullen
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

--089e08231884e5f6d2055827b40d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I have received a couple comments from Bernard on this iss=
ue, but it could use more attention to drive it to resolution.

PTAL and comment. Thanks!

=

On Wed, Aug 2, 2017 at 4:03 PM, Ted Hardie <te=
d.ietf@gmail.com> wrote:
This call begins a two-week working group last cal=
l on draft-ietf-rtcweb-fec.=C2=A0 There is one outstanding issue: https:=
//github.com/juberti/draughts/issues/81, in which Bernard question=
s the usefulness of the mandated OPUS FEC.=C2=A0 Comments on that issue are=
 solicited, as are any other issues which may be identified in review.
<=
br>
regards,

Ted, Sean, Cullen


_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




--089e08231884e5f6d2055827b40d--


From nobody Thu Sep  7 02:23:09 2017
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 E16DD132969 for ; Thu,  7 Sep 2017 02:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 tSRmzMhGwY4N for ; Thu,  7 Sep 2017 02:23:05 -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 62549132697 for ; Thu,  7 Sep 2017 02:23:03 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-e1-59b10ec30b23
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D1.37.21299.3CE01B95; Thu,  7 Sep 2017 11:17:56 +0200 (CEST)
Received: from [100.94.38.148] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 7 Sep 2017 11:17:12 +0200
To: Justin Uberti 
CC: "rtcweb@ietf.org" 
References: <71b4d9ad-eeee-a479-f2fc-f30c6c64b240@ericsson.com>  <554c4448-4731-a92c-67b4-dbf86a681319@ericsson.com>  
From: Magnus Westerlund 
Message-ID: <397005c7-9bd1-0376-ca20-f758ed3a115e@ericsson.com>
Date: Thu, 7 Sep 2017 11:17:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030207010600090509090101"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7lu4Rvo2RBtu7DS22ThWyWPuvnd2B yWPBplKPJUt+MgUwRXHZpKTmZJalFunbJXBldG3+yFKwdC1jxc5z+9kaGK/VdjFyckgImEh8 O/uHpYuRi0NI4AijxMzdHewQzkZGiQ0n/zKDVAkL6Evc/NXODmKLCKhJPJy1ixXEZhZQl7iz +BxUwykmiS+L1oIVsQlYSNz80cgGYvMK2EssmLsUrIFFQEXi/O0JYENFBWIkfl56xAJRIyhx cuYTMJtTIFBi/5GZYCcxC3QzShxovQ42VEhAW6KhqYMV4m4lievzrrNMYBSYhaR/FrKeWWAX hkn8fnObFcIWl2j6shLKNpOYt/khM4StLbFs4WsgmwPIVpNY1qqEKgxiW0vM+HWQDcJWlJjS /RBqvKnE66MfGSFsI4l3exrZFzDyrGIULU4tTspNNzLWSy3KTC4uzs/Ty0st2cQIjLmDW36r 7mC8/MbxEKMAB6MSD6/yjw2RQqyJZcWVuYcYVYDmPNqw+gKjFEtefl6qkgjvQ4aNkUK8KYmV ValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwum4X9fNYYbj4e7cu U/3//5nsf3bHXtlmoRq8gpvFwXVjqyfDIgPN8JP6gmar5nux7A2NlJzsKBhX4WH3OMW2W7H+ 9O65WlPOnEqcfM1R9cW8A/J/isvZV36on/x/wuI+h0mr1WO+8T/53nDtWlTduS+fo180rzqv nXE+Nj1huoFhBo/zw/umSizFGYmGWsxFxYkAcs0kEcECAAA=
Archived-At: 
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-fec-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Sep 2017 09:23:08 -0000

--------------ms030207010600090509090101
Content-Type: multipart/alternative;
 boundary="------------131CEDA9E605BC859DD6E5BC"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------131CEDA9E605BC859DD6E5BC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

Sorry, for not having gotten to this until now. The changes looks good.=20
However, I noticed that the 26.114 references references the 13.3=20
version. I looked at the latest 14.4 which appears to have the content=20
referenced at the stated locations. However, if there has been changes=20
to any related text I haven't compared. Even if we would choose to stay=20
with release 13, then the version may still be changed to 13.5 which is=20
the latest release 13 version.

Cheers

Magnus


Den 2017-09-01 kl. 23:41, skrev Justin Uberti:
> Magnus, did you have a chance to take a look at this? I think this is=20
> the sole actionable remaining issue for this document.
>
> On Sun, Aug 27, 2017 at 1:25 PM, Justin Uberti  > wrote:
>
>     PTAL at https://github.com/juberti/draughts/pull/89
>     
>
>     On Fri, Jul 21, 2017 at 12:51 AM, Magnus Westerlund
>          > wrote:
>
>
>
>         Den 2017-07-20 kl. 08:25, skrev Justin Uberti:
>>         Thanks for your comments. Regarding #2, the document
>>         currently says the following:
>>
>>             Since use of FEC always causes redundant data to be transm=
itted, this
>>             will lead to less bandwidth available for the primary enco=
ding when
>>             in a bandwidth-constrained environment.
>>         Do you think this is insufficient?
>
>         Yes, I think it should be more explicit that primary + repair
>         need to be within the bandwidth limits set by congestion
>         control, etc.
>
>         /Magnus
>
>>
>>         On Sun, Jul 16, 2017 at 2:40 AM, Magnus Westerlund
>>         >         > wrote:
>>
>>             Hi,
>>
>>             I was reviewing -06 to ensure that all issues are
>>             resolved. I did notice the following issues.
>>
>>
>>             1. Section 4.2, makes a normative refernces to TS.26114,
>>             which is listed as informative refences in the reference
>>             list. Please move it to the normative part.
>>
>>             2. Section 8. I am missing the statement that primary
>>             encoding + FEC needs to keep within the available
>>             bandwidth as determined by the congestion control or
>>             other bitrate adaptation mechnisms. Thus, likely
>>             resulting in that the primary encoding bitrate needs to
>>             be reduced to fit the FEC.
>>
>>             Otherwise the document looks good.
>>
>>             Cheers
>>
>>             Magnus Westerlund
>>
>>             ----------------------------------------------------------=
------------
>>             Media Technologies, Ericsson Research
>>             ----------------------------------------------------------=
------------
>>             Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0| Phone +46 10 7148287
>>             
>>             Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
| Mobile +46 73 0949079
>>             
>>             SE-164 80 Stockholm, Sweden | mailto:
>>             magnus.westerlund@ericsson.com
>>             
>>             ----------------------------------------------------------=
------------
>>
>>
>>
>
>         -- Magnus Westerlund
>         ---------------------------------------------------------------=
-------
>         Media Technologies, Ericsson Research
>         ---------------------------------------------------------------=
-------
>         Ericsson AB | Phone +46 10 7148287
>         Torshamnsgatan 23 | Mobile +46
>         73 0949079  SE-164 80 Stockholm,
>         Sweden | mailto: magnus.westerlund@ericsson.com
>         
>         ---------------------------------------------------------------=
-------
>
>
>

--=20

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------131CEDA9E605BC859DD6E5BC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi,

    
Sorry, for not having gotten to this until now. The changes looks
      good. However, I noticed that the 26.114 references references the
      13.3 version. I looked at the latest 14.4 which appears to have
      the content referenced at the stated locations. However, if there
      has been changes to any related text I haven't compared. Even if
      we would choose to stay with release 13, then the version may
      still be changed to 13.5 which is the latest release 13 version. 
    

    
Cheers

    
Magnus

    

    

    
Den 2017-09-01 kl. 23:41, skrev Justin=

      Uberti:

    

    

      
      
Magnus, did you have a chance to take a look at
        this? I think this is the sole actionable remaining issue for
        this document.

      


        
On Sun, Aug 27, 2017 at 1:25 PM, Justi=
n
          Uberti <juberti@google.com>
          wrote:

          

            
            

              

                


                  
On Fri, Jul 21, 2017 at 12:5=
1
                    AM, Magnus Westerlund <magnus=
=2Ewesterlund@ericsson.com>
                    wrote:

                    

                      

                          


                          

                          

                          
Den
                            2017-07-20 kl. 08:25, skrev Justin Uberti:
                          

                          

                            
Thanks for your comments.
                              Regarding #2, the document currently says
                              the following:
                              


                              

                              

                                
   Since use of FEC always causes re=
dundant data to be transmitted, this
   will lead to less bandwidth available for the primary encoding when
   in a bandwidth-constrained environment.

                                
Do you think this is insufficient? 

                              

                            

                          

                          

                         Yes, I think it should be more explicit
                        that primary + repair need to be within the
                        bandwidth limits set by congestion control, etc.
                        

                        

                        /Magnus

                          

                          

                            


                              
On Sun, Jul 16,
                                2017 at 2:40 AM, Magnus Westerlund <magnus.weste=
rlund@ericsson.com>
                                wrote:

                                
Hi,

                                  

                                  I was reviewing -06 to ensure that all
                                  issues are resolved. I did notice the
                                  following issues.

                                  

                                  

                                  1. Section 4.2, makes a normative
                                  refernces to TS.26114, which is listed
                                  as informative refences in the
                                  reference list. Please move it to the
                                  normative part.

                                  

                                  2. Section 8. I am missing the
                                  statement that primary encoding + FEC
                                  needs to keep within the available
                                  bandwidth as determined by the
                                  congestion control or other bitrate
                                  adaptation mechnisms. Thus, likely
                                  resulting in that the primary encoding
                                  bitrate needs to be reduced to fit the
                                  FEC.

                                  

                                  Otherwise the document looks good.

                                  

                                  Cheers

                                  

                                  Magnus Westerlund

                                  

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

                                  Media Technologies, Ericsson Research
                                  ----------------------------------=
------------------------------------

                                  Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Phone=C2=A0 +46 10
                                    7148287

                                  Torshamnsgatan 23=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0| Mobile +46 73
                                    0949079

                                  SE-164 80 Stockholm, Sweden | mailto:
                                  magnus.weste=
rlund@ericsson.com

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

                                  

                                  

                                

                              

                              

                            

                          

                          

                        
                        
--=20

Magnus Westerlund=20

---------------------------------------------------------------=
-------
Media Technologies, Ericsson Research
---------------------------------------------------------------=
-------
Ericsson AB                 | Phone  +4=
6 10 7148287
Torshamnsgatan 23           | Mobile +4=
6 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.west=
erlund@ericsson.com
---------------------------------------------------------------=
-------

                      

                    

                  

                  

                

              

            

          

        

        

      

    

    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------131CEDA9E605BC859DD6E5BC--

--------------ms030207010600090509090101
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw
DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2
MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl
c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg
ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4
KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw
vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv
YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg
aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50
ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC
hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs
Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np
dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr
BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K
1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy
rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ
cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER
wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw
zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd
PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ
gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu
e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X
/whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W
EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx
l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8
wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU
ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow
OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg
Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4
Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX
hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB
raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI
7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd
0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj
A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F
GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd
vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx
b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0
Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh
aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v
cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j
ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG
CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ
UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t
L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud
IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3
PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n
65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x
hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv
dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes
s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW
Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw
hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w
behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm
Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em
OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x
JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu
fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNzA5MDcwOTE3MDNaMC8GCSqGSIb3DQEJBDEiBCAWQJ3+VfeUtlG9M+lo
EfTBBwjvuUcPoCu3p7rZeHO+LTBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz
c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH
2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG
CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO
BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw
DQYJKoZIhvcNAQEBBQAEggEAEC/WYujQfCyKWBYTVflo9LnbnS4AKn8xoNtviW4zZefjFhk2
s0Xwwium5DejPaxK0Jer3sC5NIDM4ig2ZroVxDPMi6rqByAkOK3uvCXHd4Zzm2VxyDoHmdxm
u6ZJA8YCg+ejgTuPvmJrdAw99NMxJygMmLcPoKiyO1MO9suMjDjAiym+Ki4Z0XpcF52qQt7H
MQm5TqfShwxEMcBU6/iZ9qmeXFuuQHdb16+SNn8gO6n6eGCKQDClHA+0Z1iYlr8lYr8oicTb
UiDj8ChQ7hj7BQhoWxzqHGVj8m0C4iwXzWggqfATcjEhPqTpIVzrLujsN9DtBVScjRgM0Asx
ixU2jwAAAAAAAA==
--------------ms030207010600090509090101--


From nobody Sun Sep 10 09:35:33 2017
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 07CC1132EBB for ; Sun, 10 Sep 2017 09:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 CYuOQiWX24Wd for ; Sun, 10 Sep 2017 09:35:30 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 34417132D6D for ; Sun, 10 Sep 2017 09:35:30 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f199so25909778wme.0 for ; Sun, 10 Sep 2017 09:35:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=xvo8+9lZVEsqWBuqrqF8FlZfFUyoQrBE8Lo6bsAiFnQ=; b=zApY7MxJW2/AVRR1MJkuI8cWeoLPLmJxzNM77HR9ajEuUHyVWJMWjImMjdw40/MXTy feuDyApcBr76M7th4dTACvt0ZgtaT1CqKfmiErAQvAJvGwA6xmPdeTJAwbT27xqqkvrw SencrVmg/ME6GVfvxN7Gn9HgXB54ujPA+mCM81y44xTdaOUKDKmNXzxa/1iRnpMkNjcK IrpUzTu6MlCht6WdppRrtu3fF2n8wuRJ9Vz2whr2jHsyyI3i8R7c5K2OOnmqyRhRakrn SYYAE16AK2t+SHwjoYA9zd/G9xCHg38H6ROgB+lpIJsZeGuQeTfNZ0vxh1uKmO1S06J2 XIaA==
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 :content-transfer-encoding; bh=xvo8+9lZVEsqWBuqrqF8FlZfFUyoQrBE8Lo6bsAiFnQ=; b=s9tiegdHIZWNKNVOxsW9MWM+VwNuwRjFyqcYvuEi3wOkhzPJB5NCeP4nAJ1oy26dcl ZPWSBAxaiiBs6QAWtfqGAgIGNBEApk6n2kxKQWxvm+HDbT5wDsZ/iyI8pwsHSwa+8xg0 QjDTuYZtonmzbgc1AHndFOK9Xqfd78huDJ6tX/PnM6v4fKAHf8ZoevGOVTfnEe0sUhbN gZM+J29nCYOQzuLXPVY7VMKF6zbuh2UnQR/whroLXtReVTpv0cnKbESxqQGc9Kt+ibpG ME5qdIxFld7OpdEtTDVdX4rbEvuWi8BeO7jdYk2Y/UDJe7McGa0o50U2is+7uDkuFxpX PigQ==
X-Gm-Message-State: AHPjjUhcHsZ+ZU98R7lJ38JbqBthDPjq5SBIX5XhJlFBAzrKkQiRdAP4 pRvqS8U6wMyvifpnRft9I+TSKCGK6JXMiJe5Rg==
X-Google-Smtp-Source: ADKCNb5UrrU4ekO/+sleVBYz5LvvYThbBgFL5Hctbd4kwje9oonvMH/E0V7fw9GSJLcf3i3oSRDCKBnVcztYVr6SKzs=
X-Received: by 10.80.149.87 with SMTP id v23mr7418406eda.284.1505061328297; Sun, 10 Sep 2017 09:35:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Sun, 10 Sep 2017 09:35:07 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 10 Sep 2017 18:35:07 +0200
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 10 Sep 2017 16:35:32 -0000

Hi,

Let's assume I send two videos over a BUNDLEd transport, both of them
with simulcast enabled. So I get a local SDP offer with two m=3Dvideo
sections, having each one 2 or 3 a=3Drid lines.


1) First question:

Should N in "a=3Dextmap:N urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id"
be the same value in both m=3Dsections?

Let's assume that they are different and that MID is not in use. How
would the receiving transport discover which m=3D section the RTP packet
belongs to? Note that, upon receipt of the RTP packet, the transport
should read the RID extension header to get the associated m=3D section.
Which ID should it use to read the packet RID? Unfortunately (DUE THE
ENDLESS SDP MESS) RTP header extensions that are required for the
transport (such as MID, RID, ABS, etc) are placed within m=3D sections
rather than "globally". So sometimes they must match, sometimes not,
and workarounds like that. Is that the case when using RID? should all
the m=3D sections use he same ID mapping for the RID extension?


2) Second question:

Should the values of RID be different in the first m=3Dvideo and the
second m=3Dvideo? If they were the same then bullet 1) above gets
invalidated because the RID value in RTP packets wouldn't be useful to
find the corresponding m=3D section. In that case MID would be mandatory
in order to also use RID. Is this correct?


Thanks a lot.


--=20
I=C3=B1aki Baz Castillo



From nobody Sun Sep 10 11:22:10 2017
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 C381C132F2F for ; Sun, 10 Sep 2017 11:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 kSXEoBoZyiiU for ; Sun, 10 Sep 2017 11:22:07 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EB3132F2A for ; Sun, 10 Sep 2017 11:22:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1905; q=dns/txt; s=iport; t=1505067727; x=1506277327; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VwCzZh9e40EHIr5dib84soqnm5XaIPWZP+4DAYHf0RU=; b=O6NTfhk47q2VkL3/FZw3LjSTS52VCUM6PU9X6LM/nChX7x3hgiJM/hVM /yvDLJdbEaalfS0VVMkSXclqvqpGsIJ+KWxw4rvtMDfKxI2iUn+iDGlMg iruMy1Gf8LFtBiKURVjVIxz5X7wcYQ3QKgB/N42G8wNQCKIYZD7KtBJ6k U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAQBQgrVZ/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieeOJovChgLhAYBRU8ChAtXAQIBAQEBAQJrKIUZAgQBAWw?= =?us-ascii?q?LEAIBCEYnCyUCBA4FijEQsE+LNgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyuCA?= =?us-ascii?q?oFQgg4LgnKEd4NDgjEFkXOGQYhAAosziRwMggeJZYZ5lH4CERkBgTgBV0FMdxV?= =?us-ascii?q?KEgGFBRyBZ3aGdAaCOwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.42,374,1500940800";  d="scan'208";a="1481856"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Sep 2017 18:22:06 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8AIM6ga024053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Sep 2017 18:22:06 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 10 Sep 2017 13:22:05 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Sun, 10 Sep 2017 13:22:05 -0500
From: "Mo Zanaty (mzanaty)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Does RID require the same ext id for all the m= sections?
Thread-Index: AQHTKlLYycaFAbftikGdC4xIWfjdaqKubsPP
Date: Sun, 10 Sep 2017 18:22:05 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 10 Sep 2017 18:22:09 -0000

Bundle requires MID to associate RTP streams to m=3D sections, whether or n=
ot RID is used. RID is never used for that purpose. All extmap IDs must be =
consistent in all bundled m=3D sections, just like PTs.=20

Mo

On Sep 10, 2017, at 12:35 PM, I=F1aki Baz Castillo  wrote:

Hi,

Let's assume I send two videos over a BUNDLEd transport, both of them
with simulcast enabled. So I get a local SDP offer with two m=3Dvideo
sections, having each one 2 or 3 a=3Drid lines.


1) First question:

Should N in "a=3Dextmap:N urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id"
be the same value in both m=3Dsections?

Let's assume that they are different and that MID is not in use. How
would the receiving transport discover which m=3D section the RTP packet
belongs to? Note that, upon receipt of the RTP packet, the transport
should read the RID extension header to get the associated m=3D section.
Which ID should it use to read the packet RID? Unfortunately (DUE THE
ENDLESS SDP MESS) RTP header extensions that are required for the
transport (such as MID, RID, ABS, etc) are placed within m=3D sections
rather than "globally". So sometimes they must match, sometimes not,
and workarounds like that. Is that the case when using RID? should all
the m=3D sections use he same ID mapping for the RID extension?


2) Second question:

Should the values of RID be different in the first m=3Dvideo and the
second m=3Dvideo? If they were the same then bullet 1) above gets
invalidated because the RID value in RTP packets wouldn't be useful to
find the corresponding m=3D section. In that case MID would be mandatory
in order to also use RID. Is this correct?


Thanks a lot.


--=20
I=F1aki Baz Castillo


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


From nobody Mon Sep 11 05:49:59 2017
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 A3D8213306E for ; Mon, 11 Sep 2017 05:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 WJ4VkSTifpEE for ; Mon, 11 Sep 2017 05:49:56 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F61133089 for ; Mon, 11 Sep 2017 05:49:15 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id i189so38819078wmf.1 for ; Mon, 11 Sep 2017 05:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r43dh0AOcJCl9bpXtLA7+tArYFpPDc9YESPe0Gcs20A=; b=CG+3dg7U6i49EwgHDQ4w+zEAxKt1l7kABZb7LglYjYZC3fOoo9FHQOX3eyuBFiTrBa ekNpByBnMSXIlkfKkDSWifFmMwzJOxJfYAp+v4LJGEw8DcKhVmDHCJF/d+GzGOvQ3bRI 0VVNZqWQxBTwVD9oYKLla893ygGg9wzT+9ae3oEPKofTke2XFJaVbXSJHCpMul6qqKPr tbtR6BI47xaiZtE1BS6stFlv8YS5GBtGGxXClkjytqBA539wvHPIb6KlXw38wU5iaSvD mo7IGO4AdVOcRKbId6VYcbq/DBs5t05YImXvKvBcS1hd6AadzVdABuNg+odUHG5kRpn1 bheQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r43dh0AOcJCl9bpXtLA7+tArYFpPDc9YESPe0Gcs20A=; b=VqXeLZdvxl2HxkG/d0usuE0shjDt2iDtwaFY9JOXnwuHPsrTm2D/Cpb1oWQUyRUzAl ufS9MhBnAN83bp5h4ch8xq6iKTyXWzov//san7GCvBvKdL/WpIRJku9wI7t4jRtK+57r K0ots5kJpFD9wOvwXu8A1GmSjvm8jbvPiUby71/XfZCmE4NRIs15guCS3x6Ar1q5sywA Ft00GWnlN1N4RCq6XehQE0C3NJOlubdkz3itIiXRCb1zGpLSKpaU6K3xwLYDiYct6eTW tWp50sofkCuIdTPulUynhX4WWU1QKrJbFMkxcIoUp7ruHk2ZqLj7dgyUYtDDlTTGu4fp 7l3w==
X-Gm-Message-State: AHPjjUjeZK72YEAQbjiYiLkNgkOM94ZYZ833jKddUZovEahb6T/qWQfI vyDz1koehOq/hspWvJAPHXiffjsCipR/Iwbpsg==
X-Google-Smtp-Source: ADKCNb5ra0QxiY2W873gUrxBDF4fCFIpEGjq7Pi3tJDG/S6IzlfHVgSQ1vzLxw/F00lHTkzzXuLSING3c8rAMznnvLU=
X-Received: by 10.80.149.87 with SMTP id v23mr9505405eda.284.1505134154274; Mon, 11 Sep 2017 05:49:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 05:48:53 -0700 (PDT)
In-Reply-To: 
References:  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 14:48:53 +0200
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Cc: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 12:49:58 -0000

On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty)  wr=
ote:
> All extmap IDs must be consistent in all bundled m=3D sections, just like=
 PTs.

Thanks.

However, what does "consistent" mean? I assume/expect that the extmap
ID (for example a=3Dextmap:4) cannot exist in two different m=3D sections
pointing to different extension URLs, right?

But, and given that you told about PTs, it's perfectly valid that two
different PTs point to the same codec+condiguration within the same m=3D
section or in different m=3D sections.

So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo" line while a
m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should both use extmap ID
4?

For example, the extmap ID for MID must be *UNIQUE* across all the
m=3Dsections. Does the same constrain exist for the extmap ID for RID?



--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 06:34:58 2017
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 5978D133084 for ; Mon, 11 Sep 2017 06:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dVb-OZJprERZ for ; Mon, 11 Sep 2017 06:34:53 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1451133083 for ; Mon, 11 Sep 2017 06:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3970; q=dns/txt; s=iport; t=1505136893; x=1506346493; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ELjSyP9bODR/WAmNTlUtIR9vIKgD6S4Sd+/26l1meR4=; b=DW+fFa5WccihcGmS0w1qhGyzEtbZf8+DzsxO19m/mblsFfx6hnaHhLlE lPDxpN/1XF/N1IAcR8++BOas2RvS4dw2eme2m1IbVQlz/xiVcR3jPUEzE PejH4CXvQcwWzxMqu9QtU3W8LLxpQRHE4dHsSVgWawM0CEDYCyqeDocza 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAACpkLZZ/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1tkbieOGJAfkl6FP4ISCiWEBAGBFAKEIT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQZ5EAIBCAQ7BzIUEQIEDgWJTWQQri2LNQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RgFgyuCAoFQgg6CfYg6gjEFkXOGQYhAAodZjHaScZR+AhEZAYE4AR84gQ13FVw?= =?us-ascii?q?BhQUcgWd2iT8BAQE?=
X-IronPort-AV: E=Sophos; i="5.42,378,1500940800"; d="scan'208,217"; a="75920607"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 13:34:28 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8BDYSrA007989 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 13:34:28 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 08:34:27 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 08:34:27 -0500
From: "Mo Zanaty (mzanaty)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Does RID require the same ext id for all the m= sections?
Thread-Index: AQHTKlLYycaFAbftikGdC4xIWfjdaqKubsPPgAGJDoD//7jqJw==
Date: Mon, 11 Sep 2017 13:34:27 +0000
Message-ID: <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>
References:  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_881A3BC9C9ED4E1EACFEC887333BB672ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 13:34:56 -0000

--_000_881A3BC9C9ED4E1EACFEC887333BB672ciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

See bundle section 13.

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38#sec=
tion-13

The same ID must always map to the same URN. Different IDs can map to the s=
ame URN as aliases. (The latter is not stated but implied.)

Mo

On Sep 11, 2017, at 8:49 AM, I=F1aki Baz Castillo > wrote:

On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) > wrote:
All extmap IDs must be consistent in all bundled m=3D sections, just like P=
Ts.

Thanks.

However, what does "consistent" mean? I assume/expect that the extmap
ID (for example a=3Dextmap:4) cannot exist in two different m=3D sections
pointing to different extension URLs, right?

But, and given that you told about PTs, it's perfectly valid that two
different PTs point to the same codec+condiguration within the same m=3D
section or in different m=3D sections.

So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo" line while a
m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should both use extmap ID
4?

For example, the extmap ID for MID must be *UNIQUE* across all the
m=3Dsections. Does the same constrain exist for the extmap ID for RID?



--
I=F1aki Baz Castillo
>

--_000_881A3BC9C9ED4E1EACFEC887333BB672ciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









See bundle section 13. 













The same ID must always map to the same URN. Different IDs can map to =
the same URN as aliases. (The latter is not stated but implied.)







Mo




On Sep 11, 2017, at 8:49 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:






On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:


All extmap IDs must be consistent in all bu=
ndled m=3D sections, just like PTs.





Thanks.



However, what does "consistent" mean? I assume/expect that =
the extmap

ID (for example a=3Dextmap:4) cannot exist in two different m=3D sect=
ions

pointing to different extension URLs, right?



But, and given that you told about PTs, it's perfectly valid that two=


different PTs point to the same codec+condiguration within the sa=
me m=3D

section or in different m=3D sections.



So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo"=
; line while a

m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should bot=
h use extmap ID

4?



For example, the extmap ID for MID must be *UNIQUE* across all the

m=3Dsections. Does the same constrain exist for the extmap ID for RID=
?







-- 

I=F1aki Baz Castillo

<ibc@aliax.net>






--_000_881A3BC9C9ED4E1EACFEC887333BB672ciscocom_--


From nobody Mon Sep 11 06:52:56 2017
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 6F07F133097 for ; Mon, 11 Sep 2017 06:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 FPtbgYGQLHcO for ; Mon, 11 Sep 2017 06:52:44 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 E4A78133091 for ; Mon, 11 Sep 2017 06:52:43 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id 189so8663085wmh.1 for ; Mon, 11 Sep 2017 06:52:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/SnnGL+e4JplcFvg/VXuFl5b/xhgBiYyIGBjU5G96os=; b=rWRQ0QZYg9CMcnk2dTswxJ1Cv2Aq4H+0bXZwGs4wlhHCDbk5hljbWksNXifeGuDmnJ X0CcSm/vScGP79nn5cefNbK38u1QYB3aAxshbDJCgKRVoOlnV79/OKZEz16FAeoH7V/d mhbodrHSGOzpqEwsPRtbdB+UYaLBGC0JrPhKjY90rnvR5X27NjjMpGyycY6edEchYD22 1RpswC7p2SCOs+BLQA7D9WbrrYS8sOmfiR5+s0Bl3tFiaPNBZ6CyH4eY/OsxyXMWs5hF OMZzcELCXSPEi4I7TZtaNXGS0fF6L9xx+0vb0dEwRq8GP6LL3PCZ35psiFceeC44besn rReQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/SnnGL+e4JplcFvg/VXuFl5b/xhgBiYyIGBjU5G96os=; b=Ldm+La6SCm2JdtDcUaPf+gWFzifKlAGyk137k6i/oEwDh96xxMkInOV7zdh18KDL9u qTFhsFz5/q8PvrZGeUqNpVDK5xKQsLt0wpTX+oAmuC/B/JqshOH5wjTnOL01D/F1tSvA pWYCp1tgf5Mj42IJ6yuGl5+LA06oJzk6ujqQBtdYw4D1G/rordpzOJkm2HGrWMGZpSww 82kJrbvjsVEkEdMXykehwcycSFvzWRFP9ZYfdAsr6lrn6NBgCnCrHlXF2LlXo+W9XyMz O4DPCmPiS0oi/ONadXuzX2imBOFgAlnHVSEtgoVqbkqYeKCs9+GjaQPFSLBASw8uZgRy OcoQ==
X-Gm-Message-State: AHPjjUjtm5S6TNxqCQiKCePGkWBoQTI6eRFcytWvf1cSkQHxv2H5CSyk h+q71lEWExjs9k3k3L0ZNv7qQIReZcaG
X-Google-Smtp-Source: ADKCNb4RbkW2G0EhxqYLO9IiQ1Mz8n67GAYK9ABIAYxg+0ZLcee+N+uhR+roIwMMre/gAZFTcM6NzZH1KGDYVKodPu0=
X-Received: by 10.80.149.87 with SMTP id v23mr9658802eda.284.1505137962364; Mon, 11 Sep 2017 06:52:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 06:52:41 -0700 (PDT)
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 06:52:41 -0700 (PDT)
In-Reply-To: <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 15:52:41 +0200
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Cc: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c1997e895c6c30558ea3d90"
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 13:52:50 -0000

--94eb2c1997e895c6c30558ea3d90
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ok, but that is not valid for MID, as the reveiver transport is supposed to
check the MID value using a single extmap ID, right?

El 11 sept. 2017 3:34 p. m., "Mo Zanaty (mzanaty)" 
escribi=C3=B3:

> See bundle section 13.
>
> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-
> negotiation-38#section-13
>
> The same ID must always map to the same URN. Different IDs can map to the
> same URN as aliases. (The latter is not stated but implied.)
>
> Mo
>
> On Sep 11, 2017, at 8:49 AM, I=C3=B1aki Baz Castillo  wrot=
e:
>
> On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) 
> wrote:
>
> All extmap IDs must be consistent in all bundled m=3D sections, just like
> PTs.
>
>
> Thanks.
>
> However, what does "consistent" mean? I assume/expect that the extmap
> ID (for example a=3Dextmap:4) cannot exist in two different m=3D sections
> pointing to different extension URLs, right?
>
> But, and given that you told about PTs, it's perfectly valid that two
> different PTs point to the same codec+condiguration within the same m=3D
> section or in different m=3D sections.
>
> So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo" line while a
> m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should both use extmap I=
D
> 4?
>
> For example, the extmap ID for MID must be *UNIQUE* across all the
> m=3Dsections. Does the same constrain exist for the extmap ID for RID?
>
>
>
> --
> I=C3=B1aki Baz Castillo
> 
>

--94eb2c1997e895c6c30558ea3d90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Ok, but that is not valid for MID, as the reveiver transp=
ort is supposed to check the MID value using a single extmap ID, right?=C2=
=A0

El 11 se=
pt. 2017 3:34 p. m., "Mo Zanaty (mzanaty)" <mzanaty@cisco.com> escribi=C3=B3:









See bundle section 13.=C2=A0













The same ID must always map to the same URN. Different IDs can map to =
the same URN as aliases. (The latter is not stated but implied.)







Mo




On Sep 11, 2017, at 8:49 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:






On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> w=
rote:


All extmap IDs must be consistent in all bu=
ndled m=3D sections, just like PTs.





Thanks.



However, what does "consistent" mean? I assume/expect that =
the extmap

ID (for example a=3Dextmap:4) cannot exist in two different m=3D sect=
ions

pointing to different extension URLs, right?



But, and given that you told about PTs, it's perfectly valid that=
 two

different PTs point to the same codec+condiguration within the same m=
=3D

section or in different m=3D sections.



So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo"=
; line while a

m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should bot=
h use extmap ID

4?



For example, the extmap ID for MID must be *UNIQUE* across all the

m=3Dsections. Does the same constrain exist for the extmap ID for RID=
?







-- 

I=C3=B1aki Baz Castillo

<ibc@aliax.net<=
/a>>









--94eb2c1997e895c6c30558ea3d90--


From nobody Mon Sep 11 07:11:19 2017
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 DCF43132C32 for ; Mon, 11 Sep 2017 07:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 uugZ-LSke9Ej for ; Mon, 11 Sep 2017 07:11:16 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 B1F0213302A for ; Mon, 11 Sep 2017 07:11:15 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id i189so40775631wmf.1 for ; Mon, 11 Sep 2017 07:11:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=G8nmkqVJLr4v5yXFjanqprGFO3DbAJ3XJ6tL245B/34=; b=CT9Gm7IWYuOoUpBPIvQ/gK3E/Il5phVv6JI/avpflHJgrizekAK1DxiYUfWOcVXX+g ggeqdtVhbpa8cERudSz468RG8Ns/VGad5D554GRKs0lHKzcYOtCXO7FGhSENTOx3W45T Zf4jCpL8hu8AZmCfwPO2wocGakGzYrgK5BQOjvYDnAd4ORb6e3EMPAgM5w0VsTh4sVfV Z9TiJUybF7OTj7LaKzYDjhXi8Z6liug6ee702Gcrgi2rzlnViwMSOgLNxFw4oDSLN0fw HJAW014wsziAq3XtTwkp2t0M/Ezfdo1F6NoFaESgq8heleeNVgHAs4xiXByKzdzDmjWh ZIPg==
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:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=G8nmkqVJLr4v5yXFjanqprGFO3DbAJ3XJ6tL245B/34=; b=Yhz/r3qClQVKOUdS/7zPAVfthhAuClmcdPHb5u9dV6+tiECMC/eHMRb64LZC4ALvqS sjggYXzv8K1LtysFjSoja1SsL9zQBAzKErhXJ5BbBn2rATtDiChdKZZcWvM5Txu8ZY8A TiLu+30ERlsTq3/a3rqaCb8xMQATOks1HQp6YIs9lXOV77gf4LlJrXq0yuseDYBjsQFc /zTY+68cW/yq5YYDdFOMUfju6zYqoybCYOuBVoG33T98U5wgcUI7PArFp1lwsLXy10e3 YQ3buTsM1dzVRAYpKSSuYJL7PMIaQGHIQF9iACzaHwPmmvyBXM//+/iyLzMVLYAIlzfo 6LHw==
X-Gm-Message-State: AHPjjUhAb//AdRNJngxmjc3cBFpqxfBN6+zVIavrmA9HZ3AqbE6cOSpU NpfF1yLLYOn24I3BIJjpKw4Z3c22
X-Google-Smtp-Source: AOwi7QBOGydVgSIvow3FnTIr8U9eST2CztH/6KteQ6Ku0MwBftWSKEQ5a1koxXfNYUT5eFzJMi3v4Q==
X-Received: by 10.28.74.211 with SMTP id n80mr3265346wmi.94.1505139073961; Mon, 11 Sep 2017 07:11:13 -0700 (PDT)
Received: from [192.168.1.48] (128.red-79-147-157.dynamicip.rima-tde.net. [79.147.157.128]) by smtp.googlemail.com with ESMTPSA id n3sm7781128wrg.38.2017.09.11.07.11.13 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 07:11:13 -0700 (PDT)
To: rtcweb@ietf.org
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>
From: Sergio Garcia Murillo 
Message-ID: 
Date: Mon, 11 Sep 2017 16:11:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>
Content-Type: multipart/alternative; boundary="------------7476D84B62FADC950E5E0343"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 14:11:19 -0000

This is a multi-part message in MIME format.
--------------7476D84B62FADC950E5E0343
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

But according to RFC 5285:

    An extension URI with the same attributes MUST NOT appear more than
    once applying to the same stream, i.e., at session level or in the
    declarations for a single stream at media level.


And

    In addition, as noted above,
    the IDs used MUST be unique for each stream type for a given media,
    or for the session for session-level declarations.


So it is not possible to have same URN with exact parameters with 
different IDs for same "stream" (whatever "stream" is meant to be 
nowadays), and I would (at least) assume that each URN cannot appear 
more than once in each m-line with same parameters.

Also, IMHO, bundle should be updated to make this requirement session 
level, as it is done with the ID uniqueness.

Best regards
Sergio
On 11/09/2017 15:34, Mo Zanaty (mzanaty) wrote:
> See bundle section 13.
>
> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38#section-13
>
> The same ID must always map to the same URN. Different IDs can map to 
> the same URN as aliases. (The latter is not stated but implied.)
>
> Mo
>
> On Sep 11, 2017, at 8:49 AM, Iaki Baz Castillo  > wrote:
>
> On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) 
> > wrote:
>> All extmap IDs must be consistent in all bundled m= sections, just 
>> like PTs.
>
> Thanks.
>
> However, what does "consistent" mean? I assume/expect that the extmap
> ID (for example a=extmap:4) cannot exist in two different m= sections
> pointing to different extension URLs, right?
>
> But, and given that you told about PTs, it's perfectly valid that two
> different PTs point to the same codec+condiguration within the same m=
> section or in different m= sections.
>
> So, could a m=audio section have an "a=extmap:4 urn:foo" line while a
> m=video section has "a=extmap:8 urn:foo"? or should both use extmap ID
> 4?
>
> For example, the extmap ID for MID must be *UNIQUE* across all the
> m=sections. Does the same constrain exist for the extmap ID for RID?
>
>
>
> -- 
> Iaki Baz Castillo
> >
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--------------7476D84B62FADC950E5E0343
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
But according to RFC 5285:

      

      
   An extension URI with the same attributes MUST NOT appear more than
   once applying to the same stream, i.e., at session level or in the
   declarations for a single stream at media level.

      

      And

      
   In addition, as noted above,
   the IDs used MUST be unique for each stream type for a given media,
   or for the session for session-level declarations.

      

      So it is not possible to have same URN with exact parameters with
      different IDs for same "stream" (whatever "stream" is meant to be
      nowadays), and I would (at least) assume that each URN cannot
      appear more than once in each m-line with same parameters.

      

      Also, IMHO, bundle should be updated to make this requirement
      session level, as it is done with the ID uniqueness.

      

      Best regards

      Sergio

      On 11/09/2017 15:34, Mo Zanaty (mzanaty) wrote:

    

    

      
      
See bundle section 13.

      


      

      
      


      

      
The same ID must always map to the same URN. Different IDs
        can map to the same URN as aliases. (The latter is not stated
        but implied.)

      


      

      
Mo

      


        On Sep 11, 2017, at 8:49 AM, Iaki Baz Castillo <ibc@aliax.net>
        wrote:

        

      

      
On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty)
          <mzanaty@cisco.com>
          wrote:

        
All extmap IDs must be consistent
            in all bundled m= sections, just like PTs.

        

        

        Thanks.

        

        However, what does "consistent" mean? I assume/expect that
          the extmap

        ID (for example a=extmap:4) cannot exist in two different
          m= sections

        pointing to different extension URLs, right?

        

        But, and given that you told about PTs, it's perfectly
          valid that two

        different PTs point to the same codec+condiguration within
          the same m=

        section or in different m= sections.

        

        So, could a m=audio section have an "a=extmap:4 urn:foo"
          line while a

        m=video section has "a=extmap:8 urn:foo"? or should both
          use extmap ID

        4?

        

        For example, the extmap ID for MID must be *UNIQUE* across
          all the

        m=sections. Does the same constrain exist for the extmap
          ID for RID?

        

        

        

        -- 

        Iaki Baz Castillo

        <ibc@aliax.net>

      

      

      

      

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


    

    


    

  


--------------7476D84B62FADC950E5E0343--


From nobody Mon Sep 11 08:02:42 2017
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 7505B132D48 for ; Mon, 11 Sep 2017 08:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 dhYyxGOJrEUf for ; Mon, 11 Sep 2017 08:02:39 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8411330B7 for ; Mon, 11 Sep 2017 08:02:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6987; q=dns/txt; s=iport; t=1505142158; x=1506351758; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zz8cI5Nm1kEpMBEEUSNstCtSpvn9GdiQFf76UQgBVBQ=; b=ibMuBq7XMoW9czH2GMwv8kr/vCWPReGKcU8d64B+m59yZ7TqKmaO94TP 4YvGwGZldj0ekrlslpWDAzDB7MpMraIqKjTVF9QGlUXK+MfuFfl8vMs1o qkYg9CI4qY7gPxICQmPSJIG4r7bcHKL2tbWk/xpD+bzfhCCMHXlfhTAe0 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAADdpLZZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnBrZG4nB44RkCGBdJBqhT+CEgolhAQBgRQChCE/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEEeRACAQgRAwECKAcyFAkIAgQOBYlNZBCuTYsWAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWDK4ICgVCFC4UXhVQFkXOGQYhAAodZjHaScZR+AhEZAYE?= =?us-ascii?q?4AR84gQ13FYUpORyBZ3aIMIEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,378,1500940800";  d="scan'208,217";a="297538354"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2017 15:02:37 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8BF2bUu022332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 15:02:37 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 10:02:36 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 10:02:37 -0500
From: "Mo Zanaty (mzanaty)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Does RID require the same ext id for all the m= sections?
Thread-Index: AQHTKw8B3A0ePhLXr064bZ+T+Mv95A==
Date: Mon, 11 Sep 2017 15:02:36 +0000
Message-ID: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.182.31]
Content-Type: multipart/alternative; boundary="_000_D5DC1C96726D6mzanatyciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 15:02:40 -0000

--_000_D5DC1C96726D6mzanatyciscocom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bundle defines MID, and section 13 restricts all extmap IDs (including MID,=
 RID, etc.) to be consistent across all bundled m=3D sections, just like PT=
s. I see no restriction against aliases, nor any reason to impose one.

Mo

From: I=F1aki Baz Castillo >
Date: Monday, September 11, 2017 at 9:52 AM
To: mzanaty >
Cc: "rtcweb@ietf.org" >
Subject: Re: [rtcweb] Does RID require the same ext id for all the m=3D sec=
tions?

Ok, but that is not valid for MID, as the reveiver transport is supposed to=
 check the MID value using a single extmap ID, right?

El 11 sept. 2017 3:34 p. m., "Mo Zanaty (mzanaty)" > escribi=F3:
See bundle section 13.

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38#sec=
tion-13

The same ID must always map to the same URN. Different IDs can map to the s=
ame URN as aliases. (The latter is not stated but implied.)

Mo

On Sep 11, 2017, at 8:49 AM, I=F1aki Baz Castillo > wrote:

On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) > wrote:
All extmap IDs must be consistent in all bundled m=3D sections, just like P=
Ts.

Thanks.

However, what does "consistent" mean? I assume/expect that the extmap
ID (for example a=3Dextmap:4) cannot exist in two different m=3D sections
pointing to different extension URLs, right?

But, and given that you told about PTs, it's perfectly valid that two
different PTs point to the same codec+condiguration within the same m=3D
section or in different m=3D sections.

So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo" line while a
m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should both use extmap ID
4?

For example, the extmap ID for MID must be *UNIQUE* across all the
m=3Dsections. Does the same constrain exist for the extmap ID for RID?



--
I=F1aki Baz Castillo
>

--_000_D5DC1C96726D6mzanatyciscocom_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <3C681CAADC038141BAD700B94DB63103@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Bundle defines MID, and section 13 restricts all extmap IDs (including=
 MID, RID, etc.) to be consistent across all bundled m=3D sections, just li=
ke PTs. I see no restriction against aliases, nor any reason to impose one.=








Mo









From: I=F1aki Baz Castillo <ibc@aliax.net>

Date: Monday, September 11, 2017 at=
 9:52 AM

To: mzanaty <mzanaty@cisco.com>

Cc: "rtcweb@ietf.org" <=
rtcweb@ietf.org>

Subject: Re: [rtcweb] Does RID requ=
ire the same ext id for all the m=3D sections?













Ok, but that is not valid for MID, as the reveiver transp=
ort is supposed to check the MID value using a single extmap ID, right?&nbs=
p;





El 11 sept. 2017 3:34 p. m., "Mo Zanaty (mz=
anaty)" <mzanaty@cisco.com=
> escribi=F3:








See bundle section 13. 













The same ID must always map to the same URN. Different IDs can map to =
the same URN as aliases. (The latter is not stated but implied.)







Mo




On Sep 11, 2017, at 8:49 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:






On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> w=
rote:


All extmap IDs must be consistent in all bu=
ndled m=3D sections, just like PTs.





Thanks.



However, what does "consistent" mean? I assume/expect that =
the extmap

ID (for example a=3Dextmap:4) cannot exist in two different m=3D sect=
ions

pointing to different extension URLs, right?



But, and given that you told about PTs, it's perfectly valid that two=


different PTs point to the same codec+condiguration within the sa=
me m=3D

section or in different m=3D sections.



So, could a m=3Daudio section have an "a=3Dextmap:4 urn:foo"=
; line while a

m=3Dvideo section has "a=3Dextmap:8 urn:foo"? or should bot=
h use extmap ID

4?



For example, the extmap ID for MID must be *UNIQUE* across all the

m=3Dsections. Does the same constrain exist for the extmap ID for RID=
?







-- 

I=F1aki Baz Castillo

<ibc@aliax.net<=
/a>>



















--_000_D5DC1C96726D6mzanatyciscocom_--


From nobody Mon Sep 11 08:52:36 2017
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 0ED55132F49 for ; Mon, 11 Sep 2017 08:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 TNsBNRNGVtGh for ; Mon, 11 Sep 2017 08:52:33 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 667CA1321DF for ; Mon, 11 Sep 2017 08:52:33 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id i189so43177326wmf.1 for ; Mon, 11 Sep 2017 08:52:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Zemo/tYw6zAvgRbv0P5ZRvMI/gQQD3NYVsmjc/IAhDA=; b=htK6FNdTSJesu26Qh9sRLj8RF/AsczuABctkGurEAUzEjRWBs21oKlrrJNYHcpYM9O ZfXMwQELXV+gI5Be2qzeenFevuv/yuKUxWw10AeDuazM/kDZ7gkOdOtLqJWjJWgq8mUw Wde4pJBud7RyNn4sYlU5hAjnHNl4Cq9GcIb2tv8/pVFxes83hxYN+m8nWOXVlRJ9Pkz/ 08O/dDD3SLunzZwtfoluVKXFpPrmY4JNd7GZajViEM7FxFVn+DAeknLhMLweVhuYZxqY vzxa4HwdKPC4oVyxSRMgHxpaNfxrPvWTPirwaI/NdiXd2ABjat1VfBsux3jU0AIqu1NF l15A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Zemo/tYw6zAvgRbv0P5ZRvMI/gQQD3NYVsmjc/IAhDA=; b=FCDmIGR2SZJXuPmYHEcwiGRYjluhgDFdfEyzGbCvwSkOPo6a98zkVWG0lsA90tn9ld ehTZAImc2vopX+3mfm6pVzkHr9oNeSoKy/deURb31S5sRBvpY6pkU9YhiebMv4bEfPD2 /fXXfTlCREK0b8AmF4oyPdD8QFey+72t+U16x3Lgl0fwb2wRvZuWgjlFcFIiKJp/1sM6 kbhLsTOe7whfUjwLh9/74pKUnTSo6SPLLPrrlvgQ1JnR6ZnZ0LNREHpysSStKS9bepEs 9DTfW8AxTXSrWyqCDe8Hnxf6N4/EVmXcIq+J8si8nBcC+QMAEb1/my0epYoHsYWLoc25 aKEQ==
X-Gm-Message-State: AHPjjUhev3nIOsPPi0QE7YtSLrNthtItO9zCPDirm8kzLCQNOjmBHyUp orYs4oY3mU4WLCWuLkW+AA+GORQDMikNbfY=
X-Google-Smtp-Source: ADKCNb7mHce2tLuZ3mulQCtilDpFWaJWeM6NtEF7yVsgbAufFWruX96bZsV5o3jUY+d4fsr++Y+np0f3Q+U7Xgv+YvI=
X-Received: by 10.80.179.199 with SMTP id t7mr9879763edd.19.1505145151848; Mon, 11 Sep 2017 08:52:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 08:52:11 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 17:52:11 +0200
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Cc: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 15:52:35 -0000

On Mon, Sep 11, 2017 at 5:02 PM, Mo Zanaty (mzanaty)  wr=
ote:
> Bundle defines MID, and section 13 restricts all extmap IDs (including MI=
D,
> RID, etc.) to be consistent across all bundled m=3D sections, just like P=
Ts. I
> see no restriction against aliases, nor any reason to impose one.

The RTP MID extension value is used (should be used when someone
implements it) to lookup the associated m=3Dsection, so the extmap ID
MUST be unique across all the m=3Dsections in the SDP. Otherwise the
lookup operation would be impossible.

This has been discussed in this mailing list not so long ago.


--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 09:04:56 2017
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 3AD3A132D96 for ; Mon, 11 Sep 2017 09:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 SqKCJCsInlWk for ; Mon, 11 Sep 2017 09:04:52 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 2F72B132D79 for ; Mon, 11 Sep 2017 09:04:52 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id f199so43482794wme.0 for ; Mon, 11 Sep 2017 09:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aF39lJGiryCvgWUwybLMZjXicOnjinRjAQHto1GuXqI=; b=T9/0db9v7c5Aw+nOIJyIka648HN6Pv4iVsq8poww2gye882ueydCyuiIaJi1gg4S4b hlDU5scf1SRqmRdmsNMWiRWQpiGFtX8uURORG4l1hKTZBzSH6GMkA7jXpxhXFjy5c0G2 l8GFFx1hFeFQ3S7ypDu0X7KI9mfKtlkqQPfrTf04f7UlY24LFr2Pgo0CMN1gXYfy4pJq A7pcKwAOKHedCpKI2jiZJr0lZAOoknLL8JNvaOsj5VvKss+ZVctCKfy3p2rmIMadGK/x aRc7awah30fpz61C/5/mz2OqVqrNrPyDv7qpJ6p7Bu0JgMwBrcaLuRKEZp2MXjgst3WL ONyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=aF39lJGiryCvgWUwybLMZjXicOnjinRjAQHto1GuXqI=; b=DVavfptW42CjKfDOvsYdyaigqOzsiH4YeaQoCcSTHZPs8SAqOH+i+b2O38+6GKLMME l7oT26+DAiX+aR+HtqhH30gXa59jlgHPu4B8tMFKrjxeurxRvsJc6PLHuhQgjABXHjIN D33JRCDpTNKHPeBC7UTRFvNx5Z0TIyJCVk9VT+YPLzALFslc5ZUQsH+ecV16raCdTqGr NQiIrbOUKrne6X0KJdNa5bSqVqCE6aRLa6Wq21PeaN8va6lRxto0Yy65KR9k8BxAMSmO GjLvfxqvcDmNAyHmr+HR1w2Lw3/N3IrGpBga7dyp9qLT0LjydgRq78MH2JERVn3xXdyz Wwfw==
X-Gm-Message-State: AHPjjUgrEpixFHbXG6VPx3USmVy5fFFGdBYGrUWVZqnTCGdGAtqdeeEP CYyT9qZQFYnf7erl/B4=
X-Google-Smtp-Source: ADKCNb4p2nAdvFZL4AEWC0sJAJb5PKw34UjhSGCcmoUZEXO4DOsMz47uiLKAXkKwM3yxgTMHhfview==
X-Received: by 10.80.142.170 with SMTP id w39mr9820838edw.150.1505145890390; Mon, 11 Sep 2017 09:04:50 -0700 (PDT)
Received: from [192.168.1.48] (128.red-79-147-157.dynamicip.rima-tde.net. [79.147.157.128]) by smtp.googlemail.com with ESMTPSA id e50sm2734649ede.18.2017.09.11.09.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 09:04:48 -0700 (PDT)
To: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "Mo Zanaty (mzanaty)" 
Cc: "rtcweb@ietf.org" 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   
From: Sergio Garcia Murillo 
Message-ID: 
Date: Mon, 11 Sep 2017 18:04:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:04:54 -0000

On 11/09/2017 17:52, Iñaki Baz Castillo wrote:
> On Mon, Sep 11, 2017 at 5:02 PM, Mo Zanaty (mzanaty)  wrote:
>> Bundle defines MID, and section 13 restricts all extmap IDs (including MID,
>> RID, etc.) to be consistent across all bundled m= sections, just like PTs. I
>> see no restriction against aliases, nor any reason to impose one.
> The RTP MID extension value is used (should be used when someone
> implements it) to lookup the associated m=section, so the extmap ID
> MUST be unique across all the m=sections in the SDP. Otherwise the
> lookup operation would be impossible.
>
> This has been discussed in this mailing list not so long ago.

Well, while I am against heder extensions aliases, the extension id are 
meant to be unique across all m-sections, so it is possible to get the 
value of the extensions regardless of the m-section to which the RTP 
packet belongs to. It could be possible then to associate the rtp packet 
with the m-section via the MID value, and validate which header 
extensions ids were allowed in it (including the MID one).

IMHO, it would be better to not allow aliases in bundle across m-sections.

Best regards

Sergio




From nobody Mon Sep 11 09:06:36 2017
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 65BCF133139 for ; Mon, 11 Sep 2017 09:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 P1Vk2XVn8erz for ; Mon, 11 Sep 2017 09:06:23 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 75710132D79 for ; Mon, 11 Sep 2017 09:06:23 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id i189so43497311wmf.1 for ; Mon, 11 Sep 2017 09:06:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ZxgRoRsXwmhWXyjCmpDQfGjoKA13VDrdoCl5eMNP06g=; b=e+foxNou11sJcoogu5BeNpKfqkC6pB9XZtUW7RVSZMw5dgZlg7hEKO5VjYMq063dgd ND2HfBNlYPeLqh8g1tw/zXVdDZsIslI4J+QZLHw/6Cf1lWRh4Hy+oedQmpOhZfQIMqvo 28BolCGdhVHHtmM/NhMmr0DDnSrc4gRN7oj4rcgQq+W9N46ycSLeeKvqsaAAusxDrQcn xEFvLUvNcH3tdOvh+oNkvj27D9TVnEsJdr6VosTQ145VHoJEwe69J35xHjfausMGaSUs yBEVgT7AvAbQbmkkpC/lj+FOGzgiKxngnzCv+/ADhbnbLESsaHeA1MzsxdYRNMrpg6+j vYPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ZxgRoRsXwmhWXyjCmpDQfGjoKA13VDrdoCl5eMNP06g=; b=S7ivhvGQQgPN2jp5VC6mPzLGzWvmmiMirbCXlDesmamAvE9rb4VYDvxAYK9e/JNXr6 QCM8VLgGgONSVm5ll/ebHvOxrwmbrcKS4T6vKobyQ1YWmZqGysSNJNsdPOzE4JyilRK0 Wqc1Nq+j795t4j8GrOI/m9H85GHeY0Bm+K/aIyyJNbOH8KxIJn2rNbcg9NtTV+H7kgzN gMP7ihHuRffC3UBigRtu2SjeUwlbROUXo1Kww2BO9oEco7bBkd5qCTWdWJRGRGisMCta x4upXfgsBjExQABv5mm1z2fmf7fGs6ZNLPh7VDEwJMpbkIGb49o9Qgj84ai/Vj97assI 80iQ==
X-Gm-Message-State: AHPjjUim7OCqzsUWO/f7Eo4Yz1Q77Rx/vrC1qLqiuOgBZ1qoTWvNXr7J nR5viyHSAqgmWMCsqyc=
X-Google-Smtp-Source: ADKCNb44iZuYXswyxm4cuYyhRi6ZntC8gXfOC4RuhjdEE9TIyQIebMgb7QL8pAvMxrTf/x7+pRkaGg==
X-Received: by 10.80.240.67 with SMTP id u3mr5344994edl.35.1505145981594; Mon, 11 Sep 2017 09:06:21 -0700 (PDT)
Received: from [192.168.1.48] (128.red-79-147-157.dynamicip.rima-tde.net. [79.147.157.128]) by smtp.googlemail.com with ESMTPSA id o49sm2225979edo.69.2017.09.11.09.06.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 09:06:20 -0700 (PDT)
To: "Mo Zanaty (mzanaty)" , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= 
Cc: "rtcweb@ietf.org" 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>  
From: Sergio Garcia Murillo 
Message-ID: <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>
Date: Mon, 11 Sep 2017 18:06:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4D7CF5D83FF7B8EC6143BCD0"
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:06:34 -0000

This is a multi-part message in MIME format.
--------------4D7CF5D83FF7B8EC6143BCD0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Aliases are already restricted in same m-line by the header extension RFC.

Best regard
Sergio
On 11/09/2017 17:02, Mo Zanaty (mzanaty) wrote:
> Bundle defines MID, and section 13 restricts all extmap IDs (including 
> MID, RID, etc.) to be consistent across all bundled m= sections, just 
> like PTs. I see no restriction against aliases, nor any reason to 
> impose one.
>
> Mo
>
> From: Iaki Baz Castillo >
> Date: Monday, September 11, 2017 at 9:52 AM
> To: mzanaty >
> Cc: "rtcweb@ietf.org "  >
> Subject: Re: [rtcweb] Does RID require the same ext id for all the m= 
> sections?
>
> Ok, but that is not valid for MID, as the reveiver transport is 
> supposed to check the MID value using a single extmap ID, right?
>
> El 11 sept. 2017 3:34 p. m., "Mo Zanaty (mzanaty)"  > escribi:
>
>     See bundle section 13.
>
>     https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38#section-13
>     
>
>     The same ID must always map to the same URN. Different IDs can map
>     to the same URN as aliases. (The latter is not stated but implied.)
>
>     Mo
>
>     On Sep 11, 2017, at 8:49 AM, Iaki Baz Castillo      > wrote:
>
>     On Sun, Sep 10, 2017 at 8:22 PM, Mo Zanaty (mzanaty)
>     > wrote:
>>     All extmap IDs must be consistent in all bundled m= sections,
>>     just like PTs.
>
>     Thanks.
>
>     However, what does "consistent" mean? I assume/expect that the extmap
>     ID (for example a=extmap:4) cannot exist in two different m= sections
>     pointing to different extension URLs, right?
>
>     But, and given that you told about PTs, it's perfectly valid that two
>     different PTs point to the same codec+condiguration within the same m=
>     section or in different m= sections.
>
>     So, could a m=audio section have an "a=extmap:4 urn:foo" line while a
>     m=video section has "a=extmap:8 urn:foo"? or should both use extmap ID
>     4?
>
>     For example, the extmap ID for MID must be *UNIQUE* across all the
>     m=sections. Does the same constrain exist for the extmap ID for RID?
>
>
>
>     -- 
>     Iaki Baz Castillo
>     >
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



--------------4D7CF5D83FF7B8EC6143BCD0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Aliases are already restricted in same
      m-line by the header extension RFC.

      

      Best regard

      Sergio

      On 11/09/2017 17:02, Mo Zanaty (mzanaty) wrote:

    

    

      
      
Bundle defines MID, and section 13 restricts all extmap IDs
        (including MID, RID, etc.) to be consistent across all bundled
        m= sections, just like PTs. I see no restriction against
        aliases, nor any reason to impose one.

      


      

      
Mo

      


      

      
        

          From: Iaki Baz
          Castillo <ibc@aliax.net>

          Date: Monday, September
          11, 2017 at 9:52 AM

          To: mzanaty <mzanaty@cisco.com>

          Cc: "rtcweb@ietf.org"
          <rtcweb@ietf.org>

          Subject: Re: [rtcweb]
          Does RID require the same ext id for all the m= sections?

        

        


        

        

          

            
Ok, but that is not valid for MID, as the
              reveiver transport is supposed to check the MID value
              using a single extmap ID, right?

            


              
El 11 sept. 2017 3:34 p. m., "Mo
                Zanaty (mzanaty)" <mzanaty@cisco.com>
                escribi:

                

                  

                    
See bundle section 13.

                    


                    

                    
                    


                    

                    
The same ID must always map to the same URN.
                      Different IDs can map to the same URN as aliases.
                      (The latter is not stated but implied.)

                    


                    

                    
Mo

                    


                      On Sep 11, 2017, at 8:49 AM, Iaki Baz Castillo
                      <ibc@aliax.net>
                      wrote:

                      

                    

                    
On Sun, Sep 10, 2017 at 8:22 PM, Mo
                        Zanaty (mzanaty) <mzanaty@cisco.com>
                        wrote:

                      
All extmap IDs must
                          be consistent in all bundled m= sections, just
                          like PTs.

                      

                      

                      Thanks.

                      

                      However, what does "consistent" mean? I
                        assume/expect that the extmap

                      ID (for example a=extmap:4) cannot exist in
                        two different m= sections

                      pointing to different extension URLs, right?

                      

                      But, and given that you told about PTs, it's
                        perfectly valid that two

                      different PTs point to the same
                        codec+condiguration within the same m=

                      section or in different m= sections.

                      

                      So, could a m=audio section have an
                        "a=extmap:4 urn:foo" line while a

                      m=video section has "a=extmap:8 urn:foo"? or
                        should both use extmap ID

                      4?

                      

                      For example, the extmap ID for MID must be
                        *UNIQUE* across all the

                      m=sections. Does the same constrain exist
                        for the extmap ID for RID?

                      

                      

                      

                      -- 

                      Iaki Baz Castillo

                      <ibc@aliax.net>

                    

                  

                

              

            

          

        

      
      

      

      

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


    

    


    

  


--------------4D7CF5D83FF7B8EC6143BCD0--


From nobody Mon Sep 11 09:11:54 2017
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 086BB13313F for ; Mon, 11 Sep 2017 09:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 2EAdmYEqGMcU for ; Mon, 11 Sep 2017 09:11:52 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 C10EA1330DE for ; Mon, 11 Sep 2017 09:11:51 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id f199so43643770wme.0 for ; Mon, 11 Sep 2017 09:11:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nZmgwW2VntPmZlUS8X5/tLxo7WUlb5CO7Gu+CGTqMbc=; b=jE66ODnR40YXWDn1EDkBoJ2FGBHF4sp/tPdgHSLtVmTggznP7DgHtaeZG2FWPRet5R WveOIz0XC2vJBrj9GxA8Rh6yVku63fGfkdLa0dXxnxhNtKsTdgcOtEF9BQUZ+Wv9+AKC 27jI9Z/m5S2SElbA9WXLS9SHcPCTja36NIl0Ew0g0IfGPhUVXTBAf8en2MM/exIM1diF oAXtZ8M52d6xhSA4wh7s4OiN1P0frofs6c8buL2MQeYiBXePJlVr5pDvofnBeGLgJWJP uPFMBiU+6EVIH4e1mSZT0S1sxvw3nYoiYUuKPHKQOw1PCMa/2Mgl3raHK4DDj4mH/NLN nOrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nZmgwW2VntPmZlUS8X5/tLxo7WUlb5CO7Gu+CGTqMbc=; b=PxqyS+VPmJ3NiJNFlz0KPCkgHEmLChHJS3qk9FQcp84sVtlgaxnixIytSQsBkfyI8X gR6p9Fsv2mgioe9FrCeyZeYXjGAXJpywFe2vMrhinAB5yOWpB/MiGXw5OAfjEBHIQljE TX5l438WrWnGrXMYa0mRG1Zu/iqGTNGXOai6/t0kMBTrPGxamkL8Mj9hHYsOk49I3Ls2 PLo2VHkedzCixRUYbb6QsZGDl8RJHNGQy/qhqefH+YL6LCxbQ5qOa3+Wl1gy1DFnxi8n E3SV17bYCqXo4z0dOVzyECkf8iesw9eWnHu5d9qMsgmKA0785sA+bm95gsVzKZRU3eEX Qd0A==
X-Gm-Message-State: AHPjjUhrBeJcSqyzumLbI9TlSrgocxWXWrJ7IFg5mrZlIJw4YVk51eBC AF6L7qUl75iTkRQw7kqh9wcmaqjhAOQVBjQ=
X-Google-Smtp-Source: ADKCNb7E+/tvSrWWVF89MXW/CWR4x6p90p+Nhx3LQ42DndvABERHET2coRo8bWNQWRSRiMHeDh6MJ4ciBgLMuTfaUWY=
X-Received: by 10.80.147.91 with SMTP id n27mr9798700eda.36.1505146310085; Mon, 11 Sep 2017 09:11:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 09:11:29 -0700 (PDT)
In-Reply-To: <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 18:11:29 +0200
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "Mo Zanaty (mzanaty)" , "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:11:53 -0000

On Mon, Sep 11, 2017 at 6:06 PM, Sergio Garcia Murillo
 wrote:
> Aliases are already restricted in same m-line by the header extension RFC=
.

I don't mean aliases within the same m=3D section, but usage of
different "a=3Dextmap:N urn:mid" (different N) in different m=3D sections.

That's not valid since the receiver needs to use a *single* extmap ID
to look for the packet MID extension value, so it can find the
corresponding m=3Dsection it belongs to.

--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 09:15:46 2017
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 2992F133147 for ; Mon, 11 Sep 2017 09:15:44 -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 VK_cdAnoc0Ny for ; Mon, 11 Sep 2017 09:15:42 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 6D9A4133140 for ; Mon, 11 Sep 2017 09:15:42 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id o42so15716668wrb.3 for ; Mon, 11 Sep 2017 09:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mS8OIHMSMU8FY8okSjb8pfRLI4Je+9ng7cjuOA2S7So=; b=q0tiJhJFkTcAh0+e4e+oflstQgr2BLS27IBDI5ekmXZaW9kjGFKcmaFrw/3kv3TVyj K9gBsjnVcYpHNjtr3dv7tuyU9V4fARxKfZbvpIgJlQ6gJK5nHcvUl1eA78u25b7sZX2y HHjPmKGN2qEhV1i7W6HlWDbdnqwhTBbNTokcVbv1hshIxUw2q4R4mUswNOM9QGnor6qS FCQY0rfFNDv0eGJ6vL3r/E+IbbmNaqPgm4nN/ppYYOxH3UYZymH7AUhkCxJKZGAjvLfG mhk7fboTw6ot4xY2spJFb2nAZ3ncZBBKqsNGBBLD/wDbBTjbSp12vVLoaeV/uLadnQNU xUuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mS8OIHMSMU8FY8okSjb8pfRLI4Je+9ng7cjuOA2S7So=; b=G74viA08lSFnnz3mRq/EfXj4i+NL2F5B5kT4u+SdD1LfgmHgcfaa6iPHdFYEHe60LX y3tM9M/Tu/wL+2l1TmcaXLiuSg/POV8XRbJ6gDCVLs0r3tfAgmHcpcQuCeDk5ZZB8DiX 8rl4FK31Nkk4LJp5rGROcBih76Kn/BqzjjtPuKiEwH0I2jr1Uh7K+JXatmf/BNovGGXz fTLjSrfTNgAdnc6NfTrPJeJ2qPUHWwwyzR93KEs1YW7QG9oU6xDCw09TUBT75+nYRYi/ hvSuETmY/L2arLqRspZ6nHqNl2LRhXc2gVwU0sqw7uY1Fj7cyvH7bQ0XEF9TIHdjQbja 77Rw==
X-Gm-Message-State: AHPjjUiUAl2nciEHn/V1mAIq6th/DQvJOYVIfWwW+a6JKMo6Apkh+IzH txFMndcMYFlIJyDyLHg7aKkuoUpPaQ==
X-Google-Smtp-Source: ADKCNb5wzTZpbHoHGsjUjtr2ssvypgsU7M0l1Ay/PNd4ZwKYQHpLrXW0P+wzA6kP2w4E0HL7dkQe3AR/534i43jWCMo=
X-Received: by 10.223.161.137 with SMTP id u9mr3270002wru.280.1505146540956; Mon, 11 Sep 2017 09:15:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 09:15:39 -0700 (PDT)
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 09:15:39 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com> 
From: Sergio Garcia Murillo 
Date: Mon, 11 Sep 2017 18:15:39 +0200
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Cc: rtcweb@ietf.org, "Mo Zanaty (mzanaty)" 
Content-Type: multipart/alternative; boundary="f403045f2db2e8c0fc0558ec3ccd"
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:15:44 -0000

--f403045f2db2e8c0fc0558ec3ccd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

What I meant is that there are already restrictions to aliases in m-lines
on non-bundle and that they would make sense to be extended to all bundled
m-lines.

Br
Sergio

El 11/9/2017 18:11, "I=C3=B1aki Baz Castillo"  escribi=C3=B3=
:

> On Mon, Sep 11, 2017 at 6:06 PM, Sergio Garcia Murillo
>  wrote:
> > Aliases are already restricted in same m-line by the header extension
> RFC.
>
> I don't mean aliases within the same m=3D section, but usage of
> different "a=3Dextmap:N urn:mid" (different N) in different m=3D sections=
.
>
> That's not valid since the receiver needs to use a *single* extmap ID
> to look for the packet MID extension value, so it can find the
> corresponding m=3Dsection it belongs to.
>
> --
> I=C3=B1aki Baz Castillo
> 
>

--f403045f2db2e8c0fc0558ec3ccd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What I meant is that there are already restrictions to al=
iases in m-lines on non-bundle and that they would make sense to be extende=
d to all bundled m-lines.

Br
Sergio

El 11/9/2017 18:11, "I=C3=B1aki Baz Castillo&qu=
ot; <ibc@aliax.net> escribi=C3=
=B3:
On Mon, Sep 11,=
 2017 at 6:06 PM, Sergio Garcia Murillo

<sergio.garcia.murill=
o@gmail.com> wrote:

> Aliases are already restricted in same m-line by the header extension =
RFC.



I don't mean aliases within the same m=3D section, but usage of

different "a=3Dextmap:N urn:mid" (different N) in different m=3D =
sections.



That's not valid since the receiver needs to use a *single* extmap ID
to look for the packet MID extension value, so it can find the

corresponding m=3Dsection it belongs to.



--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>




--f403045f2db2e8c0fc0558ec3ccd--


From nobody Mon Sep 11 09:21:08 2017
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 2951F127005 for ; Mon, 11 Sep 2017 09:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 FjwNLsIjPQKn for ; Mon, 11 Sep 2017 09:21:05 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CAC132D8E for ; Mon, 11 Sep 2017 09:21:04 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id f199so43849063wme.0 for ; Mon, 11 Sep 2017 09:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v/o7+MzBRQtu4ulkwQ4OxJZ8tW+39KKhiqYC4H0s/Ww=; b=0PB4eWd+DkzlAoBLiBZVP9Pn+/HQkRfPbt7MC1lNi8jhkHIDgJHe0YXzrC4VHji0Uy 9BzksVwGis6i1JwxM0lm7uHVMETmKtwTSghUoUdcifEknYiiDIT0nUhH6LpmqLuXXRR3 9A7CIxwHdl482zITYPihkMjgZu4sicquC+pCLMPyN3tu8t6uFZYkbL/7VFS1u5RSjzup d8AXVntCKfj0KNraS/bBNvtB+Hm5tjqbyNHEQQa+goWHCrqL6UHf+uEPv6iEy79Vl+SE vKCWYccxF8W80s4gr+Z6OoJ/dFw58eLGNK4HFIr1QB8myCPk83IMzcu7d6VlglCocbTW upbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v/o7+MzBRQtu4ulkwQ4OxJZ8tW+39KKhiqYC4H0s/Ww=; b=To/pBOblhRpGaj60y6tW9hr/BKZKnzhEOhYIRhnJlX1bRasDLq2k/h0SVazlH/glGO wZDGAUZqSWCuYpcZe5H6NOvtUvD3SQnPTnd2KAOu3wtuAkdZMr3p8ggiWWmkB3JecHHk fNOyqezeMya8m7w4lJyMyfixNE3K7oSYhIlCS1a88vG77eMlqjlZQOdooE+no3IHbEZ5 aE4pV1fn89BLX5lh3pkiilAqsE9eJwDxzYQOhlWN+R/eW//KxeekTKy68PBli3glCPGS S25hg7X+5YIlCMpJf2XkvI13hCOhNfWUysVFzNLD6C2XJOYRcuf8mC3pcTqSoy5Zudb7 b2og==
X-Gm-Message-State: AHPjjUiI1SaRBTtirdLccPGYOse7xmgYJqCupouGhhM/J+iZUJJO8fP6 MoyqjoCDvz1K6242b70kp3KRwAu2HLq6
X-Google-Smtp-Source: ADKCNb6tEdMhNEKtYI5xVv2RgsW6lXH33FshVL9H64h5OnqLz0LSimAyC4ouy2a63EzBChG5AHNbc2sNpsa+xZABmm0=
X-Received: by 10.80.157.141 with SMTP id w13mr2046882ede.151.1505146863298; Mon, 11 Sep 2017 09:21:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 09:20:42 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 18:20:42 +0200
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "rtcweb@ietf.org" , "Mo Zanaty (mzanaty)" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:21:06 -0000

On Mon, Sep 11, 2017 at 6:15 PM, Sergio Garcia Murillo
 wrote:
> What I meant is that there are already restrictions to aliases in m-lines=
 on
> non-bundle and that they would make sense to be extended to all bundled
> m-lines.

Do you mean this?

"the IDs used MUST be unique for each stream type for a given media"

--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 09:24:03 2017
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 7085F127005 for ; Mon, 11 Sep 2017 09:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 AHpMRzgagNed for ; Mon, 11 Sep 2017 09:24:01 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 71897132EC1 for ; Mon, 11 Sep 2017 09:24:00 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id i189so43895125wmf.1 for ; Mon, 11 Sep 2017 09:24:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J5UT2H/cCsY4Cca24C4rb8DeRiUs+vPoAi3Y8ju+Bmw=; b=YZ+JjNsyikfvSKsK4q0D2uWsnO9/36IwpKCWUhbwfYNKoETwU5Z2o1e3WmuTJ0yuxV qAaidGfiAt7abjtV/3IQtkev6mK3Kp/esaUT7X0oRypONLSL5E17Qf4LvkR8eZviYIVy Hi3fUdcq3+Nc1OuxgX3z/2XNt/OmNioW20iidJ2V0RFzsbY8osTRBp+2s0YLAhkCWjSK 332GHngnAXFZCwJLsW75UgdvjoCsywMD02OaFZDaWc6eT3whvaHB9atvg0j9Vqvl/lOJ vY7X1NU6r2ass+o4AnGtHlvTfV/XBD4Ttf2Nj1FXY9hRLqrmcxuEz+u9hz3S2oTUM3t5 fsMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J5UT2H/cCsY4Cca24C4rb8DeRiUs+vPoAi3Y8ju+Bmw=; b=Sd6rBqNTwi7KMNkfCm2cLXMzXmEtnAi8y1sQ+nKtx6diyr7NgP2c2iNzm7qhkGijYq t5RG7Dz34HIP2AH+Ri2h7JPwRVeJn040FQRiMD4CaepsQXxVkTfPXJpC1Rd+TL6MEkZo 75fVcqco7AiAVoQH+S7InHfHkit4WpnXmO5lNXwWpcYfapKKZdn17Y8QmUJ8QrlXFIpk pUkzVCUstilbDDKqElrDOIBQEAd6LF49M7H0AFSzHy97egrLYhOGSRS1YCy8U3SFL30P xH3nAkCRsFi1StI/Ut36l3c6h/BxlQeiTvXqBCGSz14hSiuSdQjTOsUG75KX0CtbGC+g pV5Q==
X-Gm-Message-State: AHPjjUgk5CE4rudx3bZ49RAiwNytXjP/MatYrG08loIG7lnS3+tW/w4N a5jJqHQGnfIfpVLK0tSDCoaIfN8AJPaO
X-Google-Smtp-Source: AOwi7QBd24Xn4rQu+TCgtyvVrYzKdWDOSIhZSUFkuJqPKo0U0dBjWsNYN6fPRvuf1lOmUrR/b8w7Nu1zLh/JfVB5xhw=
X-Received: by 10.28.142.82 with SMTP id q79mr9099983wmd.106.1505147038942; Mon, 11 Sep 2017 09:23:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 09:23:58 -0700 (PDT)
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 09:23:58 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>   
From: Sergio Garcia Murillo 
Date: Mon, 11 Sep 2017 18:23:58 +0200
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Cc: "Mo Zanaty (mzanaty)" , rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="001a114426fc974ac90558ec5a5c"
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 16:24:02 -0000

--001a114426fc974ac90558ec5a5c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

An extension URI with the same attributes MUST NOT appear more than
   once applying to the same stream, i.e., at session level or in the
   declarations for a single stream at media level.


El 11/9/2017 18:21, "I=C3=B1aki Baz Castillo"  escribi=C3=B3=
:

> On Mon, Sep 11, 2017 at 6:15 PM, Sergio Garcia Murillo
>  wrote:
> > What I meant is that there are already restrictions to aliases in
> m-lines on
> > non-bundle and that they would make sense to be extended to all bundled
> > m-lines.
>
> Do you mean this?
>
> "the IDs used MUST be unique for each stream type for a given media"
>
> --
> I=C3=B1aki Baz Castillo
> 
>

--001a114426fc974ac90558ec5a5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


An extension URI with the same attributes M=
UST NOT appear more than
   once applying to the same stream, i.e., at session level or in the
   declarations for a single stream at media level.

El 11/9/2017 18:21, "I=
=C3=B1aki Baz Castillo" <ibc@aliax=
.net> escribi=C3=B3:
On Mon, Sep 11, 2017 at 6:15 PM, Sergio Garcia Murillo

<sergio.garcia.murill=
o@gmail.com> wrote:

> What I meant is that there are already restrictions to aliases in m-li=
nes on

> non-bundle and that they would make sense to be extended to all bundle=
d

> m-lines.



Do you mean this?



"the IDs used MUST be unique for each stream type for a given media&qu=
ot;



--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>




--001a114426fc974ac90558ec5a5c--


From nobody Mon Sep 11 10:00:03 2017
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 4D11B132EBA for ; Mon, 11 Sep 2017 10:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 vXur0kIM4ac8 for ; Mon, 11 Sep 2017 10:00:00 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 C3BE3132644 for ; Mon, 11 Sep 2017 09:59:59 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id 189so10108958wmh.1 for ; Mon, 11 Sep 2017 09:59:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UDWInYkijeaNvNCoAXMMSbmdYc1crwop3m8e74uoF88=; b=yFzLd18W8robkEqsJGwykvlFh/srh79oAHSu6idk+ljdZpfzOGdf2yWTfoFecXYmKg LwaOJIGbPYq6HeiqKQVoRc/m5jn1MojguAq+ioOJSZD9hFpd8WHEzOByScCny90jIVZ4 aTimuyw11ARkme33+KTpoWHWk7/mB5ZzarJt6BPMh4xVL224Td/AQ/Qi3C0OVtunLqd9 rlUMP3GqX/qGQjxcAuSpqHNG9vM0bFcBTtU/tb59bT8Mdgree0qBh3V4wZLZZlhewjwN fDio7Vg1kaW6JCWLVaUGU7eYPeg3HjFw3LTdTbQ3Wihw/5MwfwLZPXyT3qtiRc08mfnr aVtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UDWInYkijeaNvNCoAXMMSbmdYc1crwop3m8e74uoF88=; b=bfqJpTM0n9ZEa+a/JvWP3C84XKKOiu8q0EOLnJkgX/hWkF3woc5CfEG1jkavjCoEjZ mNGj2j3d1IqT8PUWxGXDKumhKzX5ZM0Dw6NsPjZKqtTer28LWhhuSO9JVRXd23DzWqa7 L9QtkgvW1EBxGU2Gc3rzzgWg47rRFkWH6FO+gUPXp3/UqZ+EJ0RDvzJihdnxh9TAGgGS 3ur5UIU2TpQ4qcjZMZnSIQPCYPpVO/eltGDb3MjgzvNXBmIkqdH94nCG17fZipNP9L8f iKLILSDf0/UT5CSPXMcCd2oTPqtug5BzVXo27HSKEHoBH9v/LOC3HPQvwWJn9lDFksyX spNw==
X-Gm-Message-State: AHPjjUhktte8q3STZOeVAy6YBlQ1iSvh4XkOt2fI8eM350wceMMneEre VCXvCuH0TvaIjRXr75JnTaU2NLeInY+A
X-Google-Smtp-Source: ADKCNb5QaHBCobLXLcD1zwSmYzGdzEi8DFgkGf24KAmyqP76AIB6HJrbhyd4Cxyxw6c7ALQbF4BKis8ajU+hBWZsmHI=
X-Received: by 10.80.186.110 with SMTP id 43mr9652469eds.18.1505149198002; Mon, 11 Sep 2017 09:59:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 09:59:37 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 18:59:37 +0200
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "Mo Zanaty (mzanaty)" , "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 17:00:01 -0000

On Mon, Sep 11, 2017 at 6:23 PM, Sergio Garcia Murillo
 wrote:
> An extension URI with the same attributes MUST NOT appear more than
>    once applying to the same stream, i.e., at session level or in the
>    declarations for a single stream at media level.

Nop. It's not that. At "session level" means that two a=3Dextmap
pointing to the same URN+params cannot appear more than once in the
*global* section (this is, before the m=3D sections).



--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 10:07:45 2017
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 89019132EDA for ; Mon, 11 Sep 2017 10:07:43 -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 5osI3G9O2QlJ for ; Mon, 11 Sep 2017 10:07:42 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 C7903132ED3 for ; Mon, 11 Sep 2017 10:07:41 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id a43so16038127wrc.0 for ; Mon, 11 Sep 2017 10:07:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3BNCUJV3XPWuhqZBRaWxSjaiRz7MPdtiKlKHWJvIY5o=; b=nBw7mN9KMV+awLvqjFtg49iMXLq9FbTSMj+jmc/6l0HKPN1uwqBqVy0uieWle9VQ8j w2zpbOCZTVq/wF7yDOU8ll6+m5W4AsEane2WKEpknN9SE/sBt16NoHV6u1m98/Le8PhV G8Y8uUA0YSL2sUhBUicQ0LDGrdi4iOiWNV7WZFCJ2tgmS/emvRku8qR9sOaXSnX3rLiV BBb9DyDnj9drhvPLhRcVFobHJWf7/Q6gt2Wwde9TEcWwxaGNhw9wFbCQI0yDQWW4z7gZ f1uyup6IOoFHZ88+VRyweopodBUhrsvRQDd7XKDMEqK8ZPanky/Qw5TLNIG2UlB6a6eh oWQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3BNCUJV3XPWuhqZBRaWxSjaiRz7MPdtiKlKHWJvIY5o=; b=V3uI0kgX2oAOfflUc+38Qyj8+sBfUqNiBbBbodBsFPJBFShTq34mNMMs+buS8SgJmg 335Ko5Cr1jliZQ5xs+wt1Ua3jOZe3r8yKMrVWH3Jq8+Wa6ThmoS+xRsxN6dbWzgs0HDt FBBUkHOIj4mvbBHIOKzRAooc8WXzrD+ZaAnwE8WpbkykOZpLKzlDRggHzEsa1mcDAJMC O4vkw8yrc9Bun+bqRxudleOMoT7xQa0joTnLUGiSnIsfyA4Hx63uWLtZ8XwrqegGMOb5 DYTkhRsq4Kz+yO3PoRQXByKkARs5NmPe0T88kq9y8PPjphmtcQgavLYt5hxO4dc194VJ Qr+A==
X-Gm-Message-State: AHPjjUhxlnnOLSRxKr/FAx/CWfuAKrW5i5YHfZixWKf5UgmPvmzCeQCT YLDGFbxxJp1yf3KrQGV4Ys9KCZuXqw==
X-Google-Smtp-Source: ADKCNb6LQaBe80KJGC/uma4oUIAAv0e/50JSS/EkQEh5l+3gfbPktya+RUG+eI/rJ5CTiJGzeWDYgyq91Z7giWgXTd0=
X-Received: by 10.223.142.172 with SMTP id q41mr10435339wrb.106.1505149660299;  Mon, 11 Sep 2017 10:07:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 10:07:39 -0700 (PDT)
Received: by 10.28.43.135 with HTTP; Mon, 11 Sep 2017 10:07:39 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>        
From: Sergio Garcia Murillo 
Date: Mon, 11 Sep 2017 19:07:39 +0200
Message-ID: 
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Cc: rtcweb@ietf.org, "Mo Zanaty (mzanaty)" 
Content-Type: multipart/alternative; boundary="f403045f4f94d6069e0558ecf63b"
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 17:07:43 -0000

--f403045f4f94d6069e0558ecf63b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Please, read until the end: "or at media level"

El 11/9/2017 18:59, "I=C3=B1aki Baz Castillo"  escribi=C3=B3=
:

On Mon, Sep 11, 2017 at 6:23 PM, Sergio Garcia Murillo
 wrote:
> An extension URI with the same attributes MUST NOT appear more than
>    once applying to the same stream, i.e., at session level or in the
>    declarations for a single stream at media level.

Nop. It's not that. At "session level" means that two a=3Dextmap
pointing to the same URN+params cannot appear more than once in the
*global* section (this is, before the m=3D sections).



--
I=C3=B1aki Baz Castillo


--f403045f4f94d6069e0558ecf63b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Please, read until the end: "or at media level&=
quot;

El 11/9/=
2017 18:59, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> escribi=C3=B3:
On Mon, Sep 11, 2017 at 6:2=
3 PM, Sergio Garcia Murillo

<sergio.garcia.murill=
o@gmail.com> wrote:

> An extension URI with the same attributes MUST NOT appear more than
>=C2=A0 =C2=A0 once applying to the same stream, i.e., at session level =
or in the

>=C2=A0 =C2=A0 declarations for a single stream at media level.




Nop. It's not that. At "session level" means that two a=
=3Dextmap

pointing to the same URN+params cannot appear more than once in the

*global* section (this is, before the m=3D sections).








--

I=C3=B1aki Baz Castillo

<ibc@aliax.net>





--f403045f4f94d6069e0558ecf63b--


From nobody Mon Sep 11 10:14:36 2017
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 0058013316E for ; Mon, 11 Sep 2017 10:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 OnO651dsEJLY for ; Mon, 11 Sep 2017 10:14:33 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 87D51132ED2 for ; Mon, 11 Sep 2017 10:14:33 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f199so44959568wme.0 for ; Mon, 11 Sep 2017 10:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ivkbIKi/sVdyzEryrqLq3vSkOrXk0ReOJO8W/j5dxZo=; b=tNhRnM2ptCYpNyZ3OaotcLowWt+45B5NSKCef+p5Op7S7tOdGEilrg0j848FT11cBI TPLjeVu5trLSslM72bKBJ/XUaUPasjw+fLCXvoxQUqcqPDL/a5BWCYzXCXA7+f7qUP/U XTuO2hDW9wcZw2qlYCcdv18u6fYZM5JZPerp5m/ouz1hDxMvue3wzBwqKcmUpfD9SjmI o0Axj8yvlS7Go8HsRDm5SBQ15wQE9lVg7jLh26B5LutbQjrtfPkebs4w7TV6kNDT14ug 8D78l9tdhB3EZRsgZ/iKHTz+XvaVvblKCbBl+9ghTyqIhN//HuivNYiF7dy0VgqmlcGk t+zA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ivkbIKi/sVdyzEryrqLq3vSkOrXk0ReOJO8W/j5dxZo=; b=oxAu/oROReBvcLptLAHhdIfFnLAQgBnK2uznrsn9qYkQbSRlx9TpG0/j58JzNI3gHQ oXqRMaLBbgQzaTeMsJ5sNg6O3H0TrLkxpM2Ky4eES5q4RIUSGbFnMkjrzoH+ePUC8Jya uYG0RQHtv2+1w854g0O/qNokRhOcTslzxuNXQ2u3UdDOF8+PlRSi4MDXPZyhAkxNM0tC +/U9YykwGNVhmZDwgbwDbd/90Nq0XK9Ss6nVV7dwxmi9Eg8eJ/CZrY7YuiT7iue7GPat dti42oNmZrYXHn1dLNj9M2cUWqZzrZqduJn2A4rllB3AuuUMtcmOKoTLa0EJw6ZlH3Mt hRmg==
X-Gm-Message-State: AHPjjUhsCSTe49FiOHOAY8rJVnNBKxA8NJ1yj6f2DFuugHb1raesfWkP JaClKVBgMAjqmYJJIOfGGwpdqdA34h82
X-Google-Smtp-Source: ADKCNb64nLlXRULgjamBB3prpfEjdkJQMFxi2QnJGJ27TK8MqHtVFe670nnizL8e35up4ZL5rwXgtjbqu10vI5O5UPc=
X-Received: by 10.80.180.227 with SMTP id x32mr5566425edd.192.1505150069613; Mon, 11 Sep 2017 10:14:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.152.129 with HTTP; Mon, 11 Sep 2017 10:14:08 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   <7029a788-ee1c-0f42-d037-1bfb80b87b52@gmail.com>         
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 11 Sep 2017 19:14:08 +0200
Message-ID: 
To: Sergio Garcia Murillo 
Cc: "rtcweb@ietf.org" , "Mo Zanaty (mzanaty)" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 17:14:35 -0000

On Mon, Sep 11, 2017 at 7:07 PM, Sergio Garcia Murillo
 wrote:
> Please, read until the end: "or at media level"

For me, "at media level" means two a=3Dextmap with same URN but
different ID within the *same* media section.


--=20
I=C3=B1aki Baz Castillo



From nobody Mon Sep 11 10:39:06 2017
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 CBBAD133190 for ; Mon, 11 Sep 2017 10:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zLNpGS2LwTDC for ; Mon, 11 Sep 2017 10:39:02 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E333133182 for ; Mon, 11 Sep 2017 10:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1505151542; x=1506361142; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sXrnNVS5yWK7kpSI41Jad+0bRhtesBBTZUKSlygZ6E8=; b=Vle151/dLV2wj1htw+HC/Tc9CgcbLY02/gGQ1wDHFXx17qIN2JK7yhi6 73JNO2cZuT3qyoCP9sR28tXhtS5APLhCtyut4DzPnWP5StUYv25bdFTQq OrMjKpz+mCdx5k9pPMnbgVz2/NiSSiiqKyNFXwcLC/CQsr4Mo0NFsVGrj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCFybZZ/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1tkbicHnjKBdJg7CiOEBgGBFAKEIlcBAgEBAQEBAmsohRgBAQE?= =?us-ascii?q?EbgsMBAIBCBEDAQIBLjIdCAIEDgWKMRCtZossAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGAWDK4ICgVCBY4MoimsFkXOPAQKHWYx2knGUfgIRGQGBOAFXgQ13FUqFGBy?= =?us-ascii?q?BZ3aIMIEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.42,379,1500940800";  d="scan'208";a="1921796"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 17:39:01 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v8BHd1oR021103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Sep 2017 17:39:01 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 11 Sep 2017 12:39:00 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Mon, 11 Sep 2017 12:39:00 -0500
From: "Mo Zanaty (mzanaty)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
CC: "rtcweb@ietf.org" 
Thread-Topic: [rtcweb] Does RID require the same ext id for all the m= sections?
Thread-Index: AQHTKyTauQnAoXntwkO/htQd6E4Oxw==
Date: Mon, 11 Sep 2017 17:39:00 +0000
Message-ID: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.182.31]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1881D35FA8565D4AAE055DD0B8CC04D1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Sep 2017 17:39:04 -0000

I found a restriction against aliases in 5285bis:
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-14#section-7


"... If an RTP header extension, i.e. a particular extension
URI and configuration using , is offered in
multiple m-lines that are part of the same bundle group it MUST use
the same ID in all of these m-lines."

Remap ID to different URN is disallowed when bundled:
m=3D...
a=3Dextmap:x urn:foo
m=3D...
a=3Dextmap:x urn:bar

Alias ID for same URN is disallowed when bundled:
m=3D...
a=3Dextmap:x urn:foo
m=3D...
a=3Dextamp:y urn:foo



The remap restriction is clearly necessary. I think the alias restriction
is unnecessary, but I'm fine with letting it proceed to publication if it
simplifies things for RTP stack implementors. (It complicates things for
middle box implementors that want to avoid rewriting RTP packets, which
aliases can help avoid.)

Mo


-----Original Message-----
From: I=F1aki Baz Castillo 
Date: Monday, September 11, 2017 at 11:52 AM
To: mzanaty 
Cc: "rtcweb@ietf.org" 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m=3D
sections?

On Mon, Sep 11, 2017 at 5:02 PM, Mo Zanaty (mzanaty) 
wrote:
> Bundle defines MID, and section 13 restricts all extmap IDs (including
>MID,
> RID, etc.) to be consistent across all bundled m=3D sections, just like
>PTs. I
> see no restriction against aliases, nor any reason to impose one.

The RTP MID extension value is used (should be used when someone
implements it) to lookup the associated m=3Dsection, so the extmap ID
MUST be unique across all the m=3Dsections in the SDP. Otherwise the
lookup operation would be impossible.

This has been discussed in this mailing list not so long ago.


--=20
I=F1aki Baz Castillo



From nobody Wed Sep 13 05:04:19 2017
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 1DF9713421F for ; Wed, 13 Sep 2017 05:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, 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 97SuphPXGg1J for ; Wed, 13 Sep 2017 05:04:12 -0700 (PDT)
Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.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 DC4C813337F for ; Wed, 13 Sep 2017 05:04:11 -0700 (PDT)
Received: from smtp7.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A4D3D5262; Wed, 13 Sep 2017 08:04:04 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 62D6A5040;  Wed, 13 Sep 2017 08:04:04 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 13 Sep 2017 08:04:04 -0400
From: Cullen Jennings 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Wed, 13 Sep 2017 06:04:02 -0600
Message-Id: 
To: RTCWeb IETF 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: [rtcweb] Drafts WebRTC depends on
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Sep 2017 12:04:18 -0000

=46rom a rough look at webrtc dependency drafts, here are the current =
drafts that I have as still needing work to get to the IESG.=20

   draft-ietf-oauth-pop-key-distribution - note this is referenced by =
W3C spec and was not on prior lists=20

   draft-ietf-rtcweb-security

   draft-ietf-rtcweb-security-arch

   draft-ietf-ice-rfc5245bis

   draft-ietf-ice-trickle

   draft-ietf-mmusic-data-channel-sdpneg

   draft-ietf-mmusic-ice-sip-sdp

   draft-ietf-mmusic-rfc4566bis

   draft-ietf-mmusic-rid

   draft-ietf-mmusic-sdp-bundle-negotiation

   draft-ietf-mmusic-sdp-simulcast

   draft-ietf-payload-flexible-fec-scheme

   draft-ietf-rtcweb-fec

   draft-ietf-tram-stunbis

More detail at=20

https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps



From nobody Thu Sep 21 13:23:37 2017
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 22B27133063 for ; Thu, 21 Sep 2017 13:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 pcG1QDvHQJrw for ; Thu, 21 Sep 2017 13:23:33 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 05FFF126BF3 for ; Thu, 21 Sep 2017 13:23:33 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id m72so4975968wmc.1 for ; Thu, 21 Sep 2017 13:23:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=ZfIlqofThQMHs2k97oOtqkuQFJHdewvWUScmDeuCDoo=; b=dmctJnk8CiPmQ63HzCYw8RWIbATU9mB8/wH1KMRhzUSKqQrrW9va6QM5KbjRNfNNa4 73GDlI1x2ni+p/LmM030LEm2L4vRZFUD/gHBUTrF0DtxQjYUgNNYa6Br0s0nGpZ6BDCa zOM3vBmp7z9ZqpeTncncCiO2WB4wA4m6BaDwdh8hzC5GGWzUKERv61L8jBc2aKxuQGUd 4NQHyDQQ1Z9AEkNkzLDAwJLRZ2vPc1vJq68mSDoIkZX5EWknTMUbGT4fEghNjT+wEFoV F7QeLKK5E8Hx4La2QjrH01EcYx65Z4SaWEDgxmYpVLt5D3syruuKo+Qa6Q8PiJjPSoon 7OVA==
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 :content-transfer-encoding; bh=ZfIlqofThQMHs2k97oOtqkuQFJHdewvWUScmDeuCDoo=; b=L66iSoxEWSCoRGj8j+pURAiBfkzdbuYHdLUllDiaSg23owEYs0Zy3f5M0BWCo7d6gl NvswEcAR1Cuoi7tkyNPEQwImWlT7GroO1hrsKlx23p/o10MUj9no/G/75lBm26BbxIO4 wj4Jg/vLwlJUs0wv8kqRHt7pBly3ncoxQ/11lx8zk6zbm0rurX1pRBGuHy14IzYQ3oy2 TO+akYPKlKB2LsnAw/wRk19K3pkWW5OLyWvRv6Bi+R0PyzWEYygrQoJs33s2ZO0eZrZP tZmGD0gtsClrZg7KTU5q72kI6eXFlj7EFCMbR3V0yf/1IrLCJOfmI57fXQybCLY2fWku RyUA==
X-Gm-Message-State: AHPjjUgRAihvvzkUthEx11jTGjGP7KZV70uRqV85/y1YjtFIhB6SAdQM GPPgXxmbzzy/bPB5TVqyymEZ2pOBzlh62LSSDm11WpqK
X-Google-Smtp-Source: AOwi7QAPXWiBTPqeEuHO87beayE6zcENfg+LCNrN9SkucTdMTF+5svnfPB15OnDD9vK8fD5cqoK2OMXItuDoMRD7Tr0=
X-Received: by 10.80.147.91 with SMTP id n27mr2547005eda.36.1506025411199; Thu, 21 Sep 2017 13:23:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Thu, 21 Sep 2017 13:23:10 -0700 (PDT)
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 21 Sep 2017 22:23:10 +0200
Message-ID: 
To: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [rtcweb] What is wrong with probation (just padding) RTP packets within the media stream?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 21 Sep 2017 20:23:35 -0000

Hi, just wondering if something is "illegal" in the following approach:

- For each RTP video packet received, the server (an SFU) also sends a
probation RTP packet to the receivers.

- Such a RTP probation packet has the same media SSRC and PT, with
marker bit=3D0, padding bit=3D1, zero payload and N bytes of padding. It
also has the same RTP timestamp that the video media packet and seq+1.

However, the receiver (Chrome in this case) does not render video. By
enabling its webrtc logs it does not complain at all.

Said that, I've also tried to send those probation packets *just*
after a video packet with marker bit=3D1. And it works.

It seems that, having the same timestamp than an already completed
video frame, Chrome does not complain. However I wonder what is wrong
with sending the above probation packets between video packets with
same ts and marker bit=3D0. Why is that wrong? or is it just that this
specific browser does not like it for any reason?

Thanks a lot.


--=20
I=C3=B1aki Baz Castillo



From nobody Fri Sep 22 11:50:10 2017
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 D05D91321B6; Fri, 22 Sep 2017 11:50:08 -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.62.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150610620880.16648.5047841911416926091.idtracker@ietfa.amsl.com>
Date: Fri, 22 Sep 2017 11:50:08 -0700
Archived-At: 
Subject: [rtcweb] rtcweb - New Meeting Session Request for IETF 100
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 22 Sep 2017 18:50:09 -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):  2 Hours
Number of Attendees: 70
Conflicts to Avoid: 
 First Priority: perc sipcore payload mmusic stir httpbis dispatch clue  avtcore aqm rmcat tls quic
 Second Priority:  tsvwg tsvarea ace uta netvc capport



People who must be present:
  Eric Rescorla
  Sean Turner
  Adam Roach
  Cullen Jennings
  Martin Thomson
  Richard Barnes
  Ted Hardie
  Justin Uberti
  Harald Alvestrand

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Tue Sep 26 12:40:03 2017
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 BEFC91330B2 for ; Tue, 26 Sep 2017 12:40:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.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 kE9Vuek_5_w4 for ; Tue, 26 Sep 2017 12:39:48 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 2DA9F13432D for ; Tue, 26 Sep 2017 12:39:44 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id b195so11286282wmb.5 for ; Tue, 26 Sep 2017 12:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1kiO5skbfAiNCSGt8P4V0J/WN2Q28z9EwEjRVcHqziE=; b=TyOactSrQm1aQOr7Bd9MwrkduYNiZtgZJvcV8HWvEOHoTlj6keG/D+Vi/WHQgL/syt rHuWpqScU5qv38EdBySq0zM6XD6Gh7gxpGMSYXsMkXmdxMZK6cR325zHO09uktPwyJkr s66dvkb0421r4AzOo5KXRRQ5yiOu+YGrHZmgDH5voQ72a0Yqh61K13s1FlyPcsr9lS/H 2h8UGztmEsJ6/hk/9Sy8d7aVYW3aXC170m2Z8t6pOGSznji1gUvGpB1H+jmVn0IKePyf XIUN4YMvjh3RdWCgmvG5x+Q4I6Ifij9ADUOzGkAFIbFr7YNq4fRmCaRr3Perw3I6iK2a QoZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1kiO5skbfAiNCSGt8P4V0J/WN2Q28z9EwEjRVcHqziE=; b=l8vo5dxsfHToWjEAP8dXJ+z2znsVGfQVHDab/b/Pqt1d/P57PJ4mLd6slEOq98r5lK dRcRq70ZAfBqsVJgOFo13C8nzfOCtGyQqrTuEf4skVLtdJVtB+JUg1hqJUGirOo5crd4 5dlIVZB2tOqwe+9nwdvzSNTU03cq1g4XemtJx1ZrPXklO3pfulCAoll+9CrE7nSjROMS urtxXD2u/06/V2ucvCWo1s5BKF4NA4t1atYPmOkcAUl+d+/W+Bpl1SEMWcpKFYnmjLji 64U5ngGwEmgqolh4OfcsuV4xUtjpE/ps+KALQbq5qyBhMvmkKnSxp938nT4ztPZKtMLv ro+w==
X-Gm-Message-State: AHPjjUhOWgVoAQgBSwAuZs5SNaB7R5OQsuYWsKtjRwUv8Ig0KvfwEJLU DYa+uaF+vJKg+Nuo9rDOmaXkj0d/Dee82Sf96Iqi4g==
X-Google-Smtp-Source: AOwi7QDINXV98EMHafUI78cbD8xEhohOij2HbUBy2KgsgcN2chmmxLFwfi0No+mdWWUUsk1+cWMSepjwaRBXkQTV5NQ=
X-Received: by 10.80.152.33 with SMTP id g30mr18362470edb.49.1506454782672; Tue, 26 Sep 2017 12:39:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.214.6 with HTTP; Tue, 26 Sep 2017 12:39:21 -0700 (PDT)
In-Reply-To: 
References:    <881A3BC9-C9ED-4E1E-ACFE-C887333BB672@cisco.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Tue, 26 Sep 2017 21:39:21 +0200
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Cc: "rtcweb@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [rtcweb] Does RID require the same ext id for all the m= sections?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Sep 2017 19:40:02 -0000

On Mon, Sep 11, 2017 at 7:39 PM, Mo Zanaty (mzanaty)  wr=
ote:
> I found a restriction against aliases in 5285bis:
> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-14#section-7
>
>
> "... If an RTP header extension, i.e. a particular extension
> URI and configuration using , is offered in
> multiple m-lines that are part of the same bundle group it MUST use
> the same ID in all of these m-lines."

Thanks. I was not aware of that draft. Hope implementors go that way.

--=20
I=C3=B1aki Baz Castillo



From nobody Thu Sep 28 10:49:17 2017
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 C8CAF1342D6; Thu, 28 Sep 2017 10:49:15 -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, rtcweb@ietf.org, rtcweb-chairs@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150662095578.27715.13519598400633742846.idtracker@ietfa.amsl.com>
Date: Thu, 28 Sep 2017 10:49:15 -0700
Archived-At: 
Subject: [rtcweb] rtcweb - Update to a Meeting Session Request for IETF 100
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Sep 2017 17:49:16 -0000

An update to a meeting session request has just been submitted by Adam Roach, a ART Area Director.


---------------------------------------------------------
Working Group Name: Real-Time Communication in WEB-browsers
Area Name: Applications and Real-Time Area
Session Requester: Adam Roach

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 70
Conflicts to Avoid: 
 First Priority: perc sipcore payload mmusic stir httpbis dispatch clue avtcore aqm rmcat tls quic
 Second Priority: tsvwg tsvarea ace uta netvc capport



People who must be present:
  Eric Rescorla
  Sean Turner
  Adam Roach
  Cullen Jennings
  Martin Thomson
  Richard Barnes
  Ted Hardie
  Justin Uberti
  Harald Alvestrand

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Thu Sep 28 11:17:38 2017
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 A6DD21342F4 for ; Thu, 28 Sep 2017 11:17:37 -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, 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 (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 EVuv_Spu7yiy for ; Thu, 28 Sep 2017 11:17:36 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 090751347A0 for ; Thu, 28 Sep 2017 11:17:36 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id o13so2843412qtf.1 for ; Thu, 28 Sep 2017 11:17:35 -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:message-id:date :to; bh=kt43wWUxiEGzgbH8lLQzKlrwdSAcQU0H9fCAwa3sc3c=; b=brxPxPxoGT43R8ha3llA99SrEn6lfT1hLJlcF/W2JAiuopZfH40I8pnJclC6wom7vC R8zUqBGZCuHoTb/uAWzJBHkQ4wVykjpDkLGApVp8sroB4H9G1TZt+sfSs/mZPed3MyWb iqQhZl9RcHt+I6vVCz9mMFNYvtQpzYDSdsuzo=
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:message-id:date:to; bh=kt43wWUxiEGzgbH8lLQzKlrwdSAcQU0H9fCAwa3sc3c=; b=QlUs08B9TRggrpTwgWer2UfDhoNQt+euDTtMo6eaewLXRoScuhwwvozfk/z0aovytF 4dkPVq8FNB3Jo4Woj2hwOeTavB/0FJs29P1XTZR0uBfNUO/yuWl+3ohF6tl5cg3xop8H iuPz4noOeociY8wAbMgPHoi7FBe8MoSDe3JposAiDBk3Fh94TJl43taFawmDNf8DubiI rfuWxBg++q9f79NsHRHlKamWphGYK1fG+xtZ/Gl3vY98WKwWHe9PhD/sxStGBt93yhJT W/fCt+YEue577nKa397jgMxXmCAZW7BuOWqqj/o3DQCZvtnObCwryBODbi3W+4SN6uOb 0Qhg==
X-Gm-Message-State: AMCzsaVEFQVdIoofRDrcp6IdUZvzi0xnGU2XFAcSmJib/UR0S95/Xt3v kQToUr3xDxqDCZEJPvzrWWuWIyQ9pVM=
X-Google-Smtp-Source: AOwi7QCBKItPE1jVEI/P4SBpHJrSNr+btkSqWbgOMSiN/FsrprXUVVyhusWT+nPBT71ChWN3Hpwsaw==
X-Received: by 10.237.57.161 with SMTP id m30mr2389663qte.157.1506622654847; Thu, 28 Sep 2017 11:17:34 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.228.225]) by smtp.gmail.com with ESMTPSA id c185sm1367397qke.60.2017.09.28.11.17.33 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 11:17:33 -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 10.3 \(3273\))
Message-Id: <473CE409-3A96-4C32-AF43-8AD8AA58F4DD@sn3rd.com>
Date: Thu, 28 Sep 2017 14:17:32 -0400
To: RTCWeb IETF 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [rtcweb] Soliciting draft-ietf-rtcweb-security drafts
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Sep 2017 18:17:37 -0000

While the rtcweb-security drafts have expired from the daratracker, they =
are available for review on github:

0. https://github.com/rtcweb-wg/security
1. https://github.com/rtcweb-wg/security-arch

The chairs would appreciate reviews.

Cheers,

spt=


From nobody Sat Sep 30 14:07:26 2017
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 AD4FF124B18 for ; Sat, 30 Sep 2017 14:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 IFM_13YmaKM0 for ; Sat, 30 Sep 2017 14:07:18 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 6E6A2134231 for ; Sat, 30 Sep 2017 14:07:18 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id k4so2370932wmc.1 for ; Sat, 30 Sep 2017 14:07:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wH45wiHjn5gmAOpzkxlN6u5ZdaUoAsWfL7EbMtOOqPc=; b=AQFv3RgD3jE0IimwY2/RXa+OgXzfLljFDSvqeXYjRmfY4LqgqSpfH53jiO7ToX6uBm 1H90/wq5Uos2XzDML3YZNyzfXQRi3v53eLr5R7QGTO6SatqliBPQBUtLvPrKh0A1+aA8 Cc9UKavtrNmuivA9lsRZet97KOr8pIXjNfBV2Ik16jBjafB8ebXpRpClZqTfKnt3IY6Q k2pwHevnFzFDiSQVTZjF5BchCOrrBDmzGmz3QaGYZBcE+jINJp6+VKNTGBEORChzM6Er POPf/29MVnSnfmbrvunMZn7qvAiRBNuUlQia1QJUAKx/b+3o8YFlzlt9BrjY39E2dacR JoOQ==
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=wH45wiHjn5gmAOpzkxlN6u5ZdaUoAsWfL7EbMtOOqPc=; b=VC79FsQZj4mJutQ+4DZj1UOpDykLQz6WlmpaEtt+Ha/6LpAi154o/yRRVjjTt9lqFq GryXvLC5zFdb2XPPhPpUw6CBi1R3bT0o58BqfsVHdqjdcBHIA/1/x4SmKMrvFWdeoYMu rPlk3LwH4RPAOzs3dUXQHvnMvLvPLTwN0NV9B2RnmUdIIGTDIj3tG3VQb3YohPufDY2g Eyw9IR0n3kdDCIEbZyMCFog5guUTXfKmZIOqePmEykF+CYP+rX7eBBSdqkxBT76Gyn4V 4E9YdWQLqq8uPU2r3XVc1yVEFOBmZao2k6nC5xJX2jaGPKG9vzfHDJljXh/x1ShQNeqf bDrA==
X-Gm-Message-State: AHPjjUiGL+vKd995k+qdieqrA2EotHKIDgGyBNyDuzFLh2izq1p5kp5S 8UYm2UlzEjUjsoIW7GxtbF25bQJC+HFWmfTFdqzphrU6
X-Google-Smtp-Source: AOwi7QBy5m1hdfoKLQor7r6oS0XcBWdkwsrdANeRCxv592ZpowXvLC/4ROy2LKfmg9h8mS4S9hOGdWZeiWOPC5OxLWU=
X-Received: by 10.28.9.130 with SMTP id 124mr5972362wmj.65.1506805636407; Sat, 30 Sep 2017 14:07:16 -0700 (PDT)
MIME-Version: 1.0
From: Peter Thatcher 
Date: Sat, 30 Sep 2017 21:07:04 +0000
Message-ID: 
To: "" 
Content-Type: multipart/alternative; boundary="001a114420f6b4e58e055a6e8698"
Archived-At: 
Subject: [rtcweb] WGLC for draft-ietf-ice-rfc5245bis-12
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
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, 30 Sep 2017 21:07:20 -0000

--001a114420f6b4e58e055a6e8698
Content-Type: text/plain; charset="UTF-8"

FYI, in the ICE WG we've just begun the WGLC for
draft-ietf-ice-rfc5245bis-12. It will be 3 weeks and end on Oct 21, 2017
(not 2018 :).  Please direct review comments to the ICE WG mailing list.

If possible, we would like a dedicated reviewer from rtcweb to perform a
"consistent check in depth" with the rtcweb documents.   If you're willing
to be that dedicate reviewer, please let me know.

--001a114420f6b4e58e055a6e8698
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI, in the ICE WG we've just begun the WGLC for draft=
-ietf-ice-rfc5245bis-12. It will be 3 weeks and end on Oct 21, 2017 (not 20=
18 :).=C2=A0 Please direct review comments to the ICE WG mailing list.=C2=
=A0=C2=A0

If possible, we would like a dedicated reviewer from rtcwe=
b to perform a "consistent check in depth" with the rtcweb docume=
nts.=C2=A0 =C2=A0If you're willing to be that dedicate reviewer, please=
 let me know.=C2=A0=C2=A0



--001a114420f6b4e58e055a6e8698--