From nobody Fri Dec 1 03:27:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB01D1289B5 for ; Fri, 1 Dec 2017 03:27:50 -0800 (PST) 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 X2ljEA2vmfei for ; Fri, 1 Dec 2017 03:27:48 -0800 (PST) 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 807AC1274A5 for ; Fri, 1 Dec 2017 03:27:47 -0800 (PST) X-AuditID: c1b4fb30-ca9ff700000029e3-bf-5a213cb2d49a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 03.70.10723.2BC312A5; Fri, 1 Dec 2017 12:27:46 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Fri, 1 Dec 2017 12:27:45 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) - Pull Request Thread-Index: AQHTapdof37vBVhIcEqEaqoRJkAJVw== Date: Fri, 1 Dec 2017 11:27:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: <626251250ED12E4C94B79068DF1F2F7E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7k+4mG8Uogx97pS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj6esr5oIpKhWflt9kb2Cco9zFyMkhIWAi 8X3rG7YuRi4OIYHDjBKrftxihnAWM0p8P/WGpYuRg4NNwEKi+582SFxEoJlR4tr55SwgjrBA J6PEhGWzmCEyXYwSS+Y/YQeZKyKgJ7Fm3yk2EJtFQEXicd95sDivgLXEzH0HWEBsRgExoA1r mEBsZgFxiVtP5jNB3CQgsWTPeWYIW1Ti5eN/rCC2KNDMDSdus0PEFSV2nm1nhujVkvjyYx8b hG0t8ePUBChbUWJK90OovYISJ2c+YZnAKDILybpZSNpnIWmfhaR9FpL2BYysqxhFi1OLk3LT jYz0Uosyk4uL8/P08lJLNjECo+Xglt8GOxhfPnc8xCjAwajEw9tpoRglxJpYVlyZe4hRgoNZ SYTXSBMoxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgbHM gu3sa8udujt0njYfD+3JmWlqtvFQdu8Zx67wnTIi1jd8fylvWCE1jWdvsFih4j2nQ9LK2a4n Hno47Wq+6tt/Ic10Td+/zaeeVDj+OiVnXOlxcvop7+mV23MvPv2rOyfeY7eGYq7hg8wYu9B/ oTXpx4O0UjQTX17MufLtVd9Jo0Oevj6lEkosxRmJhlrMRcWJAE4mSvOSAgAA Archived-At: Subject: Re: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) - Pull Request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 11:27:51 -0000 DQpIaSwNCg0KSSBjcmVhdGVkIGEgUHVsbCBSZXF1ZXN0LCB0aGF0IHdpbGwgYmUgdXBkYXRlZCBi YXNlZCBvbiBjb21tZW50cyByZWNlaXZlZA0KZHVyaW5nIHRoZSBsYXN0IChob3BlZnVsbHmhpikg V0cgcmV2aWV3IG9mIHRoZSBkb2N1bWVudC4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2Ry YWZ0LXNkcC1idW5kbGUvcHVsbC80OA0KDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpP biAzMC8xMS8xNyAxNDozMywgIm1tdXNpYyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmci DQo8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+SGksDQo+DQo+Pj5HcmVldGluZ3MNCj4+PiANCj4+ PiBBdCB0aGlzIHBvaW50LCB0aGVyZSBhcmUgbm8gZnVydGhlciBvdXRzdGFuZGluZyB0ZWNobmlj YWwgaXNzdWVzIGluDQo+Pj4gYnVuZGxlIGFuZCB3ZSBiZWxpZXZlIHRoZSBhdXRob3JzIGhhdmUg YWRkcmVzc2VkIGFsbCB0aGUgZWRpdG9yaWFsDQo+Pj4gY29tbWVudHMgdGhhdCBjYW4gcmVhc29u YWJseSBiZSBhZGRyZXNzZWQuIFdlIGFyZSBwbGFubmluZyB0byBtb3ZlDQo+Pj5haGVhZCANCj4+ PiB3aXRoIHB1YmxpY2F0aW9uIHJlcXVlc3Qgb2YNCj4+PiANCj4+PiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLWJ1bmRsZS1uZWdvdGlhdGlvbi00Mg0K Pj4+IA0KPj4+IHVubGVzcyB3ZSBoZWFyIGFueSBvYmplY3Rpb25zIGZyb20gYW55Ym9keSwgYW5k IGhlbmNlIHRoaXMgd2lsbCBiZSB5b3VyDQo+Pj4gbGFzdCBjaGFuY2UgdG8gY29tbWVudCBvbiB0 aGUgcmVjZW50IGNoYW5nZXMuDQo+Pg0KPj5JIHJlYWxseSB3YW50ZWQgdG8gYmUgc2F0aXNmaWVk IHdpdGggdGhpcy4gQnV0IEkgc3RpbGwgaGF2ZSBhIHByb2JsZW0NCj4+d2l0aCB0aGUgbGFuZ3Vh Z2UuDQo+Pg0KPj5DaHJpc3RlciBoYXMgZGVmaW5pdGVseSBpbXByb3ZlZCB0aGluZ3MgYnkgaW50 cm9kdWNpbmcgdGhlIG5vdGlvbiBvZg0KPj4ic3VnZ2VzdGVkIG9mZmVyZXIgQlVORExFIGFkZHJl c3MiLiBCdXQgdGhpcyB0ZXJtaW5vbG9neSBpcyBvbmx5IHVzZWQgaW4NCj4+cGFzc2luZyBpbiB0 aGUgdGV4dCwgYW5kIGxhY2tzIGEgZGVmaW5pdGlvbi4gQW5kICJPZmZlcmVyIEJVTkRMRQ0KPj5h ZGRyZXNzIiBpcyBzdGlsbCB0aGUgdGVybSB0aGF0IGlzIGRlZmluZWQgYW5kIHVzZWQuIEFuZCBp dCBpcyB1c2VkIGluDQo+PndheXMgdGhhdCBjb25mbGljdCB3aXRoIGl0cyBkZWZpbml0aW9uLg0K Pj4NCj4+SSBwcm9wb3NlIHRoYXQgdGhlIHRlcm1pbm9sb2d5IGJlIHJldmlzZWQsIGFuZCB0aGVu IHNvbWUgbWlub3IgdHdlYWtzDQo+PnRoZSB0aGUgb3RoZXIgdGV4dCBiZSB1cGRhdGVkIHRvIHVz ZSBpdC4gSSB0aGluayB0aGUgZm9sbG93aW5nDQo+PmRlZmluaXRpb25zIHdpbGwgd29yazoNCj4+ DQo+PiAgICBTdWdnZXN0ZWQgT2ZmZXJlciBCVU5ETEUgYWRkcmVzczogdGhlIGFkZHJlc3M6cG9y dCBjb21iaW5hdGlvbiBpbiB0aGUNCj4+ICAgICJtPSIgc2VjdGlvbiBpZGVudGlmaWVkIGJ5IHRo ZSBPZmZlcmVyIEJVTkRMRS10YWcuDQo+Pg0KPj4gICAgT2ZmZXJlciBCVU5ETEUgYWRkcmVzczog dGhlIGFkZHJlc3M6cG9ydCBjb21iaW5hdGlvbiBpbiB0aGUgIm09Ig0KPj4gICAgc2VjdGlvbiBv ZiB0aGUgb2ZmZXIgdGhhdCBjb3JyZXNwb25kcyAocGVyIFtSRkMzMjY0XSkgdG8gdGhlICJtPSIN Cj4+ICAgIHNlY3Rpb24gb2YgdGhlIGFuc3dlciB0aGF0IGlzIGlkZW50aWZpZWQgIGJ5IHRoZSBB bnN3ZXJlciBCVU5ETEUtdGFnLg0KPg0KPkkgZG9uqfZ0IHRoaW5rIHRoYXQgd29ya3MgYXMgc3Vn Z2VzdGVkLg0KPg0KPqn4c3VnZ2VzdGVkqfcgaXMgb25seSB1c2VkIHdoZW4gYSBuZXcgb2ZmZXJl ciBCVU5ETEUgYWRkcmVzcyBpcyB0byBiZQ0KPm5lZ290aWF0ZWQuIEluIHN1YnNlcXVlbnQgb2Zm ZXJzLCBvbmNlIHRoZSBCVU5ETEUgZ3JvdXAgaGFzIGJlZW4gY3JlYXRlZCwNCj5pdCBpcyBub3Qg qfhzdWdnZXN0ZWSp9yBhbnltb3JlOg0KPg0KPiJXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGEg c3Vic2VxdWVudCBvZmZlciAoaS5lLiwgYSBCVU5ETEUgZ3JvdXANCj4gICBoYXMgcHJldmlvdXNs eSBiZWVuIG5lZ290aWF0ZWQpLCBpdCBNVVNUIGFzc2lnbiB0aGUgcHJldmlvdXNseQ0KPiAgIHNl bGVjdGVkIG9mZmVyIEJVTkRMRSBhZGRyZXNzqfcNCj4NCj4NCj5Tbywgd2UgY2FuIGZvcmUgc3Vy ZSBzYXkgdGhhdCB0aGUgb2ZmZXJlciBCVU5ETEUgYWRkcmVzcyBpcyBzZWxlY3RlZCBieQ0KPnRo ZSBhbnN3ZXJlciwgYnV0IHdoZW4gdXNlZCBpbiBzdWJzZXF1ZW50IG9mZmVycyBpdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoDQo+dGhlIGFuc3dlcmVyIEJVTkRMRS10YWcuDQo+DQo+UGVyaGFwcyBz b21ldGhpbmcgbGlrZToNCj4NCj4JT2ZmZXJlciBCVU5ETEUgYWRkcmVzczogb25jZSBhIHN1Z2dl c3RlZCBvZmZlcmVyIEJVTkRMRSBhZGRyZXNzIGhhcyBiZWVuDQo+c2VsZWN0ZWQgYnkgdGhlIGFu c3dlcmVyLCB0aGUgYWRkcmVzczpwb3J0IGNvbWJpbmF0aW9uIHVzZWQgYnkgdGhlIG9mZmVyZXIN Cj5mb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIG1lZGlhLg0KPg0KPg0KPglTdWdnZXN0ZWQgT2Zm ZXJlciBCVU5ETEUgYWRkcmVzczogYmVmb3JlIGFuIG9mZmVyZXIgQlVORExFIGFkZHJlc3MgaGFz DQo+YmVlbiBzZWxlY3RlZCBieSB0aGUgYW5zd2VyZXIsIG9yIHdoZW4gdGhlIG9mZmVyZXIgd2Fu dHMgdG8gY2hhbmdlIGENCj5wcmV2aW91c2x5IHNlbGVjdGVkIG9mZmVyZXIgQlVORExFIGFkZHJl c3MsIHRoZSBhZGRyZXNzOnBvcnQgY29tYmluYXRpb24NCj4JdGhhdCB0aGUgb2ZmZXJlciB3YW50 cyB0byB1c2UgZm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBtZWRpYS4gV2hpbGUNCj5zdWdnZXN0 ZWQgYnkgdGhlIG9mZmVyZXIsIHRoZSBzZWxlY3Rpb24gb2YgdGhlIG9mZmVyZXIgQlVORExFIGFk ZHJlc3MgaXMNCj5kb25lIGJ5IHRoZSBhbnN3ZXJlci4NCj4NCj5EbyB3ZSByZWFsbHkgbmVlZCB0 byB0YWxrIGFib3V0IHRoZSBCVU5ETEUtdGFncyBpbiB0aGUgZGVmaW5pdGlvbiBzZWN0aW9uPw0K PkhvdyB0aGUgQlVORExFIGFkZHJlc3NlcyBhcmUgaWRlbnRpZmllZCBpcyBkZXNjcmliZWQgaW4g dGhlIHNwZWMuDQo+DQo+DQo+DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rlcg0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bW11c2ljIG1haWxpbmcg bGlzdA0KPm1tdXNpY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQoNCg== From nobody Fri Dec 1 08:30:59 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA52E129400 for ; Fri, 1 Dec 2017 08:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 FcWKuPFT7gMt for ; Fri, 1 Dec 2017 08:30:56 -0800 (PST) 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 099DE1293D6 for ; Fri, 1 Dec 2017 08:30:55 -0800 (PST) X-AuditID: c1b4fb30-093dd9c0000029e3-7a-5a2183bec7a5 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.83.10723.EB3812A5; Fri, 1 Dec 2017 17:30:54 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 17:30:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h2vFYTwzSje8kQwvDHOVwvBLJpGiOn3EP/LcL3oP7g4=; b=URbXBiHDDKXILGw3PTv2Xvi2ogNZS5tAE2tnXtgo9xGiiHurOmzXhoEj4cbe3XL40mNKXR58q6otx1n5vHYyfQAJ0h88ujxWQKK41LMgoxWxz/Vud45LPbzn6FeAsCoFq1xBkbJN8HPPfVDu5WLKoztcYuw+XUDe+jda3ltBK9I= Received: from VI1PR07MB3262.eurprd07.prod.outlook.com (10.175.243.144) by VI1PR07MB3262.eurprd07.prod.outlook.com (10.175.243.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 16:30:11 +0000 Received: from VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::552a:7aa2:67c6:82d9]) by VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::552a:7aa2:67c6:82d9%13]) with mapi id 15.20.0282.007; Fri, 1 Dec 2017 16:30:11 +0000 From: Bo Burman To: IETF MMUSIC WG , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" CC: Christer Holmberg , Taylor Brandstetter , Ben Campbell Thread-Topic: Change of -sdp-mux-attributes needed to align with BUNDLE? Thread-Index: AdNqwWHfmFxQvqH0QuKOUUj6GQGJcA== Date: Fri, 1 Dec 2017 16:30:11 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3262; 6:KUn2NPeVkDqaZy31iLxVvbUiUs5hZ7vRor2xbV1X5I2qXoToCeEOdvyFFK9V8VC48VjEeH2Ww7JSsgMlZjdeTReI2SU/q3aD2JZkPcMnUF6e/cFa1hwU99cwa0kXCbedLutWJSy+fTeftSS1RushZW8QW1rwOj1+pFNUjDCVoVGRNn5QGY5sZka2+kpCGfHGEXso3MbTmeKaedDaxHbYiSegvtiJtJ6LiFzPV5AjEmsrKp7G/k3Jr6teqH5S7ijRICEac4I79jRbDqxMggrA7ODm2cNSQCyjdXSxoJ+BzO21bJucEmwYOjkPfhb1UO8WV+qrbZ+XANGrVqM7lSmtKy300XUBRi83A7pXVmB+qMM=; 5:bE4J3RFL5X+BOdeckiMo/yyWOGr1TCzWIGr5NSE72MQ+/jlpuVRaWWC1SZiXxXEH6Qco0KOkUdAmindttnUctZVMI0Q0pxtxTTqE7hyvsY/GgnrphRO7ulK9WNLbVggJXmvUoyNBllzDBYwvHnicvmEvLUcU5SqElV2dbp1x5xk=; 24:trbfmihsHDhBT0yWuVuu50HJkXjsbHxovvFgn34Jlp+IaiwJS6Ega+nYjsEKVIOX1xOWCF1UiHAaKJ3aXqgkgYy2sesIgS1BgKMGjsT0bFA=; 7:ta4o4aNuFT1EL7kKGfiQDVG+AWAfl1zLPpbyiXRcfPOapdO31wTom9svJG2wVQCbcziJsxFXZp/pAD1K51m7VeMKtKT3LyBpU3Kjdp+Gr5oziGIYptFI+qnBXcun6x+GOmfgV5G4JUPTR2AL0pd4IhCf6RU0CwgvD6V5Xu5ELFT3wZKGqtv5kwvlaBolqxspJv+TomBR8OEkQc4lxCQggtEjhQv9oxCL3nbYegJ9W6nmPG2fmfwrdXkzTam/OJMu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1f2562b8-a12a-4436-71d2-08d538d8cb14 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:VI1PR07MB3262; x-ms-traffictypediagnostic: VI1PR07MB3262: x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB3262; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3262; x-forefront-prvs: 05087F0C24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39860400002)(346002)(199003)(189002)(81166006)(8936002)(5250100002)(101416001)(54906003)(4326008)(2900100001)(110136005)(316002)(8676002)(81156014)(3280700002)(3660700001)(66066001)(5660300001)(2906002)(189998001)(99286004)(97736004)(7736002)(25786009)(55016002)(230783001)(966005)(86362001)(14454004)(236005)(54896002)(19609705001)(6306002)(9686003)(478600001)(2501003)(74316002)(53936002)(68736007)(105586002)(6436002)(33656002)(3846002)(102836003)(790700001)(6116002)(606006)(6506006)(54356011)(7696005)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3262; H:VI1PR07MB3262.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB326274D0377B256DAC5224B88D390VI1PR07MB3262eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f2562b8-a12a-4436-71d2-08d538d8cb14 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 16:30:11.2436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3262 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+XbOtqN04HN5eTGFXEa11NSkZokUES1MksAuXsiZR13qtG1K BoopCtOEzMy8xCYu08LKYaWWsuYfYVmmBoJZZluoqCml1ZRWes4E//t9z/O8N/goQtTN96QU Sg2jUsrTxQJnsubss1D/niKfmEDLYxepTvtGKB1unuBLZwfDpVX3LOQhUqY3ZssMBhtPVttp JWWLwz8FUWSMc1gSk67IYVR7whOcU+ermomsIsnlVtuQoABd3V6KnCjAIXDtpoEoRc6UCPci 0He+43OPVwjsHx+wDonLCTCVTZJrJSJczQOdMYFLfUVQPPOUNQR4J+g6PqE1wxVXIdDWP2LL CVyEoG3KxqY24yOgXVxaTVGrKRncsh9ck11xAHSvGIRrTGJfqLEvsEzjOPhgqmUZYW8Y//2Z bUNgDxi16njcERgMLwYIjt1g2mLnc/lzUFnxVsjpW2F8udKR8YYhXRm7KGCzEFoHdY5QADyp mEMcR0LJPy2fYwMC21wgxxIwmrpIjsPgdlm1o2kaFC9YHXocWO8sCbkBegLG7zY6NvWCka5u kjPe86GztYR3HfnVbriI40zoH/vCMo1doK/GSnK6H+if/xBwvBuaGmaIde43WXgbdT0S3kdu akadmJESHBzAqBQX1OpMZYCS0RjR6qd62b4S2IGmJw+bEaaQeBNty/eJEfHlOercDDMCihC7 0hc1qxKdJM+9wqgyz6uy0xm1GW2hSLEH3XecjhHhFLmGSWOYLEa17vIoJ88CFCSnW7ZF7pUm fIudL2zoXEg8ORY2OzUx7+7Vopn6M+BbftQW226XDSQfK4+wZ0d3K8bDmi35tSGSU3TE6EPf vKZ4xdJEsuTSX1zQZnMrPNCzY+hElHzEYtrl0br8WtwYq40+nbvvTFZvVXGoUeuVV+fvfiPe nRxsqIv8vv9XvVlMqlPlQRJCpZb/B/yKdiZQAwAA Archived-At: Subject: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:30:59 -0000 --_000_VI1PR07MB326274D0377B256DAC5224B88D390VI1PR07MB3262eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u= __oKBA3GiieVeda8yydyCtuT5U), Taylor concluded that the -sdp-mux-attributes<= https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/> dra= ft, which is currently in RFC Editor's queue, needs to be updated to align = with current BUNDLE draft. The -sdp-mux-attributes draft unconditionally requires (in section 4.3) tha= t category IDENTICAL attributes and their values "MUST be repeated across a= ll the media descriptions under multiplexing". BUNDLE (section 8.1) requires such repetition for IDENTICAL and TRANSPORT o= nly when a BUNDLE group is initially negotiated. When the BUNDLE addresses = have been selected, for all "m=3D" sections but the one carrying the BUNDLE= -tag, BUNDLE requires the opposite; MUST NOT include SDP attributes with ID= ENTICAL or TRANSPORT category. Does the WG agree that -sdp-mux-attributes has to be changed to align with = what is now described by BUNDLE? Unless anyone objects before EOB Dec 15, we will proceed with such change t= o -sdp-mux-attributes. Thanks, Bo MMUSIC co-chair --_000_VI1PR07MB326274D0377B256DAC5224B88D390VI1PR07MB3262eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U), Taylor concluded that the -sdp-mux-attributes draft, which is currently in RFC Editor’s que= ue, needs to be updated to align with current BUNDLE draft.

 

The -sdp-mux-attributes draft unconditionally requir= es (in section 4.3) that category IDENTICAL attributes and their values = 220;MUST be repeated across all the media descriptions under multiplexing&#= 8221;.

 

BUNDLE (section 8.1) requires such repetition for ID= ENTICAL and TRANSPORT only when a BUNDLE group is initially negotiated. When the BUNDLE ad= dresses have been selected, for all “m=3D” sections but the one= carrying the BUNDLE-tag, BUNDLE requires the opposite; MUST NOT include SD= P attributes with IDENTICAL or TRANSPORT category.

 

Does the WG agree that -sdp-mux-attributes has to be= changed to align with what is now described by BUNDLE?

 

Unless anyone objects before EOB Dec 15, we will pro= ceed with such change to -sdp-mux-attributes.

 

Thanks,

 

Bo

MMUSIC co-chair

 

--_000_VI1PR07MB326274D0377B256DAC5224B88D390VI1PR07MB3262eurp_-- From nobody Fri Dec 1 10:16:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB741275C5 for ; Fri, 1 Dec 2017 10:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Bonj_kUEC2uf for ; Fri, 1 Dec 2017 10:16:32 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4CA0120727 for ; Fri, 1 Dec 2017 10:16:32 -0800 (PST) X-AuditID: 12074411-f95ff70000007f0a-f8-5a219c7f5882 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AE.F1.32522.F7C912A5; Fri, 1 Dec 2017 13:16:31 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vB1IGUYX024161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Dec 2017 13:16:31 -0500 To: Christer Holmberg , "mmusic@ietf.org" References: From: Paul Kyzivat Message-ID: <7185d258-07de-6571-7cd4-0c38c1bd6c04@alum.mit.edu> Date: Fri, 1 Dec 2017 13:16:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=euc-kr; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixO6iqFs/RzHK4O0yA4sLMw8zWkxd/pjF gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4MpoufyXpWCeTMW8de9ZGhiviHUxcnJICJhI TFt4nL2LkYtDSGAHk8TG2zOYIZwHTBKrVi8CywgLdDJKTFg2CyjDwSEikCJxpIsRxBQSsJaY +UkGZBCbgJbEnEP/WUBsXgF7iRNztjCB2CwCKhJvb+4Di4sKpEnsudABVSMocXLmExaQMZwC NhIrrjGDhJkFzCUubfjADmGLS9x6Mp8JwpaXaN46m3kCI/8sJN2zkLTMQtIyC0nLAkaWVYxy iTmlubq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxghYSq4g3HGSblDjAIcjEo8vAFBilFC rIllxZW5hxglOZiURHn5OoFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHjzpwLleFMSK6tSi/Jh UtIcLErivHxL1P2EBNITS1KzU1MLUotgsjIcHEoSvNtnAzUKFqWmp1akZeaUIKSZODhBhvMA DT8NUsNbXJCYW5yZDpE/xWjM0dNz4w8Tx7OZrxuYhVjy8vNSpcR5b84CKhUAKc0ozYObBks1 rxjFgZ4T5t0IMpAHmKbg5r0CWsUEtCpzuTzIqpJEhJRUA2Pk6/x/W6Zv3WGrmsifu2bzgrBs t+QaX8auGWcF8zScXt1wW/V5wdfUCQcLPH/7+9y6tchJsF5lqoiVz+mYNa0yFjv1Ji/fc1Lt XJnr7Q3JhpV7p1w60X3bakf2zaO+bSuW2VnXZd3Z8EzscuD55/Uvngmz35D4zF0T9bX22+Sp lz7fqOfttv2sxFKckWioxVxUnAgAiiUFyxADAAA= Archived-At: Subject: Re: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42) - Pull Request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 18:16:35 -0000 On 12/1/17 6:27 AM, Christer Holmberg wrote: > > Hi, > > I created a Pull Request, that will be updated based on comments received > during the last (hopefully¡¦) WG review of the document. > > https://github.com/cdh4u/draft-sdp-bundle/pull/48 Looks good. Thanks, Paul > Regards, > > Christer > > > > On 30/11/17 14:33, "mmusic on behalf of Christer Holmberg" > > wrote: > >> Hi, >> >>>> Greetings >>>> >>>> At this point, there are no further outstanding technical issues in >>>> bundle and we believe the authors have addressed all the editorial >>>> comments that can reasonably be addressed. We are planning to move >>>> ahead >>>> with publication request of >>>> >>>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42 >>>> >>>> unless we hear any objections from anybody, and hence this will be your >>>> last chance to comment on the recent changes. >>> >>> I really wanted to be satisfied with this. But I still have a problem >>> with the language. >>> >>> Christer has definitely improved things by introducing the notion of >>> "suggested offerer BUNDLE address". But this terminology is only used in >>> passing in the text, and lacks a definition. And "Offerer BUNDLE >>> address" is still the term that is defined and used. And it is used in >>> ways that conflict with its definition. >>> >>> I propose that the terminology be revised, and then some minor tweaks >>> the the other text be updated to use it. I think the following >>> definitions will work: >>> >>> Suggested Offerer BUNDLE address: the address:port combination in the >>> "m=" section identified by the Offerer BUNDLE-tag. >>> >>> Offerer BUNDLE address: the address:port combination in the "m=" >>> section of the offer that corresponds (per [RFC3264]) to the "m=" >>> section of the answer that is identified by the Answerer BUNDLE-tag. >> >> I don©öt think that works as suggested. >> >> ©øsuggested©÷ is only used when a new offerer BUNDLE address is to be >> negotiated. In subsequent offers, once the BUNDLE group has been created, >> it is not ©øsuggested©÷ anymore: >> >> "When an offerer generates a subsequent offer (i.e., a BUNDLE group >> has previously been negotiated), it MUST assign the previously >> selected offer BUNDLE address©÷ >> >> >> So, we can fore sure say that the offerer BUNDLE address is selected by >> the answerer, but when used in subsequent offers it has nothing to do with >> the answerer BUNDLE-tag. >> >> Perhaps something like: >> >> Offerer BUNDLE address: once a suggested offerer BUNDLE address has been >> selected by the answerer, the address:port combination used by the offerer >> for sending and receiving media. >> >> >> Suggested Offerer BUNDLE address: before an offerer BUNDLE address has >> been selected by the answerer, or when the offerer wants to change a >> previously selected offerer BUNDLE address, the address:port combination >> that the offerer wants to use for sending and receiving media. While >> suggested by the offerer, the selection of the offerer BUNDLE address is >> done by the answerer. >> >> Do we really need to talk about the BUNDLE-tags in the definition section? >> How the BUNDLE addresses are identified is described in the spec. >> >> >> >> Regards, >> >> Christer >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Dec 1 13:23:55 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 067251293D8 for ; Fri, 1 Dec 2017 13:23:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151216343402.2867.10587025457031915907.idtracker@ietfa.amsl.com> Date: Fri, 01 Dec 2017 13:23:54 -0800 From: IETF Secretariat Archived-At: Subject: [MMUSIC] Milestones changed for mmusic WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:23:54 -0000 Changed milestone "Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Informational", set description to "Submit Unknown Key Share Attacks on uses of Transport Layer Security with the Session Description Protocol as Proposed Standard". URL: https://datatracker.ietf.org/wg/mmusic/about/ From nobody Fri Dec 1 15:38:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745C4124234 for ; Fri, 1 Dec 2017 15:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 f_FX0j5Ecnq5 for ; Fri, 1 Dec 2017 15:38:22 -0800 (PST) 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 EAF3412420B for ; Fri, 1 Dec 2017 15:38:21 -0800 (PST) X-AuditID: c1b4fb30-ca9ff700000029e3-71-5a21e7eb2e81 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.DA.10723.BE7E12A5; Sat, 2 Dec 2017 00:38:19 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Sat, 2 Dec 2017 00:38:19 +0100 From: Christer Holmberg To: Bo Burman CC: IETF MMUSIC WG , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , Taylor Brandstetter , Ben Campbell Thread-Topic: Change of -sdp-mux-attributes needed to align with BUNDLE? Thread-Index: AdNqwWHfmFxQvqH0QuKOUUj6GQGJcAAPBWYv Date: Fri, 1 Dec 2017 23:38:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D168A8134EE74DF08C417E112382ADB6ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7se7r54pRBpu2WlvM7zzNbnF5xUNW izcX7SymLn/M4sDisWBTqceSJT+ZPGbtfMLi8eXyZ7YAligum5TUnMyy1CJ9uwSujG0737IW LDGuWHzzLnsD4xydLkZODgkBE4lpR5cydTFycQgJHGaUODxzAguEs5hR4t+kpaxdjBwcbAIW Et3/tEEaRATUJB6ubgFrYBZ4xCjx/vM2NpCEsIC7RNeufiaQehEBD4lp/6wh6o0k/ux8zQJi swioSPy58JYRxOYVsJfoeXMArFVIIEbixNkpTCA2p0CsxOKzP5hBbEYBMYnvp9aAxZkFxCVu PZnPBHG0gMSSPeeZIWxRiZeP/7FC1CRLrP68lwVivqDEyZlPWCYwCs9C0j4LSdksJGUQcQOJ 9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYIwd 3PLbYAfjy+eOhxgFOBiVeHhdnilGCbEmlhVX5h5ilOBgVhLhvX4WKMSbklhZlVqUH19UmpNa fIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoFxeZmtimWo4aTEZ5+kZI7aXZEpOPOn 0V9twqXdjHKfdu9ZtdydWVtko+vK5OfV26ZlyHe/1dcJnfQv66XIvde+do5zm7k6Lm5cPLdJ b4qFxKMprM8kF4RyXTYR01Sc73jnQ6v0o+X2TJscemJyu08/zDQXurD6ginPoztXjs82WKY7 aXHDGqYIJZbijERDLeai4kQASdAC660CAAA= Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 23:38:24 -0000 --_000_D168A8134EE74DF08C417E112382ADB6ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, As I believe I have said before, we need to separate two things: 1) Whether the attribute value needs to be applied to all m- sections 2) Whether the attribute needs to be explicitly assigned/encoded to all m- = sections In my opinion, draft-mux-attributes shall only cover 1). 2) is BUNDLE specific. I do agree that it is a little difficult to determine whether =93repeat=94 = means 1) or 2). Regards. Christer Sent from my iPhone On 1 Dec 2017, at 18.30, Bo Burman > wrote: WG, A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u= __oKBA3GiieVeda8yydyCtuT5U), Taylor concluded that the -sdp-mux-attributes<= https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/> dra= ft, which is currently in RFC Editor=92s queue, needs to be updated to alig= n with current BUNDLE draft. The -sdp-mux-attributes draft unconditionally requires (in section 4.3) tha= t category IDENTICAL attributes and their values =93MUST be repeated across= all the media descriptions under multiplexing=94. BUNDLE (section 8.1) requires such repetition for IDENTICAL and TRANSPORT o= nly when a BUNDLE group is initially negotiated. When the BUNDLE addresses = have been selected, for all =93m=3D=94 sections but the one carrying the BU= NDLE-tag, BUNDLE requires the opposite; MUST NOT include SDP attributes wit= h IDENTICAL or TRANSPORT category. Does the WG agree that -sdp-mux-attributes has to be changed to align with = what is now described by BUNDLE? Unless anyone objects before EOB Dec 15, we will proceed with such change t= o -sdp-mux-attributes. Thanks, Bo MMUSIC co-chair --_000_D168A8134EE74DF08C417E112382ADB6ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi,

As I believe I have said before, we need to separate two things:

1) Whether the attribute value needs to be applied to all m- sections<= /div>
2) Whether the attribute needs to be explicitly assigned/encoded to al= l m- sections

In my opinion, draft-mux-attributes shall only cover 1).

2) is BUNDLE specific.

I do agree that it is a little difficult to determine whether =93repea= t=94 means 1) or 2).

Regards.

Christer

Sent from my iPhone

On 1 Dec 2017, at 18.30, Bo Burman <bo.burman@ericsson.com> wrote:

WG,

 

A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U), Taylor concluded that the -sdp-mux-attributes draft, which is currently in RFC Editor=92s queue, = needs to be updated to align with current BUNDLE draft.

 

The -sdp-mux-attributes draft unconditionally requir= es (in section 4.3) that category IDENTICAL attributes and their values =93= MUST be repeated across all the media descriptions under multiplexing=94.

 

BUNDLE (section 8.1) requires such repetition for ID= ENTICAL and TRANSPORT only when a BUNDLE group is initially negotiated. When the BUNDLE ad= dresses have been selected, for all =93m=3D=94 sections but the one carryin= g the BUNDLE-tag, BUNDLE requires the opposite; MUST NOT include SDP attrib= utes with IDENTICAL or TRANSPORT category.

 

Does the WG agree that -sdp-mux-attributes has to be= changed to align with what is now described by BUNDLE?

 

Unless anyone objects before EOB Dec 15, we will pro= ceed with such change to -sdp-mux-attributes.

 

Thanks,

 

Bo

MMUSIC co-chair

 

--_000_D168A8134EE74DF08C417E112382ADB6ericssoncom_-- From nobody Fri Dec 1 16:10:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670E12762F for ; Fri, 1 Dec 2017 16:10:19 -0800 (PST) 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 9Lc1X6_UrpsT for ; Fri, 1 Dec 2017 16:10:16 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 98C401270A0 for ; Fri, 1 Dec 2017 16:10:16 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id h2so9077771uae.12 for ; Fri, 01 Dec 2017 16:10:16 -0800 (PST) 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=uqv2VgmjqRn+c8i/KRbLppVrf5kQUqigH5lqLvuJcro=; b=uqSnfaSW6K+sgF/TbD1OVXG1a1xj961sqoVoygkJo5P3a8iokQI90z8pM92TWptuBX wAzNA2pwO828jKgT19lqj5h75ti16qfY9dM7yWjb+bQ7pgKUsdZCm5k7Fr/lQLS1sdl7 MyE/Wz8PoB6kywf1drpSFw4vtWEhi1eaX5yoWfjAV3HWXSZvVYOXx4YrrfX38o8EIIYU lHmsrd/bea6eoaxAlws4LKhHyRyEBosJyCcfHDaALPXf6uPLOVBpAYVf0enGUhfy7u99 pApDbvnQgLwZJkPYN7RapOIBUuWi0TwRrBA1oRVW5efsKHOvZCuKMrzT6cUcvMHoYq1K OOWg== 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=uqv2VgmjqRn+c8i/KRbLppVrf5kQUqigH5lqLvuJcro=; b=JoG/q1Fmm9r+mTsxZhcfEN5xjMgoubkSYcJIqMc7IL5nRTIxZoYHDhG3u16UOshD/x cOHz8OKcIfRJfawsXltYRph2fEj3lUIp4nAXP58awfpX/PTC16UJtD4tttsOvydUdhDJ KgpJNMcjmBWOC+XfoOZDhUcdy7lxP+wGZqJvvE4Km49xJa6VzeJLQmV1fZNSKuteI32/ DFOh1GD/+yrmOeT5w0jT7ypgQ9vQfpiqi58pbzIhKZKXYCsUJf1jpddGNmwSFlXXKydE L8j+UlJ2uiU4IL31QGLaJs1Qb1W8kDg74rS4LeI/SK+eZxNl8DLk5A13mvhB5WiLPjEA HHPA== X-Gm-Message-State: AJaThX7SeCYk/5IR6BhccxOL7bOxG+YS7YkQ0HCWHiSclivckYJmTaY9 AkHi97Yx9hVACYzjQ/NB+oLXe5QRG7g2qljzK1o= X-Google-Smtp-Source: AGs4zMZLPGYoLDhX334fgljLbcwpFq4ysah5wHn+D813nPUhCUQkQWQ20rR3HfvWTIAZ8zJLl+y0570nxaLG0cKtgg8= X-Received: by 10.176.89.71 with SMTP id o7mr6580789uad.163.1512173415753; Fri, 01 Dec 2017 16:10:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.194 with HTTP; Fri, 1 Dec 2017 16:10:15 -0800 (PST) In-Reply-To: References: From: Suhas Nandakumar Date: Fri, 1 Dec 2017 16:10:15 -0800 Message-ID: To: Christer Holmberg Cc: Bo Burman , Ben Campbell , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , IETF MMUSIC WG Content-Type: multipart/alternative; boundary="001a11467fb848ed74055f504fb0" Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 00:10:19 -0000 --001a11467fb848ed74055f504fb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 1, 2017 at 3:38 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > As I believe I have said before, we need to separate two things: > > 1) Whether the attribute value needs to be applied to all m- sections > 2) Whether the attribute needs to be explicitly assigned/encoded to all m= - > sections > > In my opinion, draft-mux-attributes shall only cover 1). > > 2) is BUNDLE specific. > > I do agree that it is a little difficult to determine whether =E2=80=9Cre= peat=E2=80=9D > means 1) or 2). > > Above was my recollection too. I am not sure if we need to change Mux attributes. Since Mux attributes needs to be read along with the Bundle spec. The Bundle spec may define additional constraints or usage patterns. > Regards. > > Christer > > Sent from my iPhone > > On 1 Dec 2017, at 18.30, Bo Burman wrote: > > WG, > > > > A while ago (in this thread: https://mailarchive.ietf.org/ > arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U), Taylor concluded that the > -sdp-mux-attributes > > draft, which is currently in RFC Editor=E2=80=99s queue, needs to be upda= ted to > align with current BUNDLE > > draft. > > > > The -sdp-mux-attributes draft unconditionally requires (in section 4.3) > that category IDENTICAL attributes and their values =E2=80=9CMUST be repe= ated > across all the media descriptions under multiplexing=E2=80=9D. > > > > BUNDLE (section 8.1) requires such repetition for IDENTICAL and TRANSPORT > *only* when a BUNDLE group is initially negotiated. When the BUNDLE > addresses have been selected, for all =E2=80=9Cm=3D=E2=80=9D sections but= the one carrying > the BUNDLE-tag, BUNDLE requires the opposite; MUST NOT include SDP > attributes with IDENTICAL or TRANSPORT category. > > > > Does the WG agree that -sdp-mux-attributes has to be changed to align wit= h > what is now described by BUNDLE? > > > > Unless anyone objects before EOB Dec 15, we will proceed with such change > to -sdp-mux-attributes. > > > > Thanks, > > > > Bo > > MMUSIC co-chair > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a11467fb848ed74055f504fb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Dec 1, 2017 at 3:38 PM, Christer Holmberg <christer.h= olmberg@ericsson.com> wrote:
Hi,

As I believe I have said before, we need to separate two things:

1) Whether the attribute value needs to be applied to all m- sections<= /div>
2) Whether the attribute needs to be explicitly assigned/encoded to al= l m- sections

In my opinion, draft-mux-attributes shall only cover 1).

2) is BUNDLE specific.

I do agree that it is a little difficult to determine whether =E2=80= =9Crepeat=E2=80=9D means 1) or 2).


Above was my recollec= tion too. I am not sure if we need to change Mux attributes. Since Mux attr= ibutes needs to be read along with the Bundle spec.
=C2=A0The Bun= dle spec may define additional constraints or usage patterns.=C2=A0
=C2=A0
Regards.

Christer

Sent from my iPhone

On 1 Dec 2017, at 18.30, Bo Burman <bo.burman@ericsson.com> wrote:

WG,

=C2=A0

A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yyd= yCtuT5U), Taylor concluded that the -sdp-mux-attributes draft, which is currently in RFC Editor=E2=80=99s q= ueue, needs to be updated to align with current BUNDLE draft.

=C2=A0

The -sdp-mux-attributes draft unconditionally requir= es (in section 4.3) that category IDENTICAL attributes and their values =E2= =80=9CMUST be repeated across all the media descriptions under multiplexing= =E2=80=9D.

=C2=A0

BUNDLE (section 8.1) requires such repetition for ID= ENTICAL and TRANSPORT only when a BUNDLE group is initially negotiated. When the BUNDLE ad= dresses have been selected, for all =E2=80=9Cm=3D=E2=80=9D sections but the= one carrying the BUNDLE-tag, BUNDLE requires the opposite; MUST NOT includ= e SDP attributes with IDENTICAL or TRANSPORT category.

=C2=A0

Does the WG agree that -sdp-mux-attributes has to be= changed to align with what is now described by BUNDLE?

=C2=A0

Unless anyone objects before EOB Dec 15, we will pro= ceed with such change to -sdp-mux-attributes.

=C2=A0

Thanks,

=C2=A0

Bo

MMUSIC co-chair

=C2=A0


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

--001a11467fb848ed74055f504fb0-- From nobody Sun Dec 3 08:27:44 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B682B12009C; Sun, 3 Dec 2017 08:27:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151231845659.12009.7566922191612798047@ietfa.amsl.com> Date: Sun, 03 Dec 2017 08:27:36 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 16:27:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Roni Even Filename : draft-ietf-mmusic-data-channel-sdpneg-14.txt Pages : 41 Date : 2017-12-03 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-14 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 Sun Dec 3 22:08:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA75126D45 for ; Sun, 3 Dec 2017 22:08:07 -0800 (PST) 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 f7pVRrS1EVKA for ; Sun, 3 Dec 2017 22:08:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 97420124D37 for ; Sun, 3 Dec 2017 22:08:05 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 64DCF521F462A for ; Mon, 4 Dec 2017 06:08:00 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 06:08:01 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 14:07:37 +0800 From: Roni Even To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt Thread-Index: AQHTbFO5yfMV375jU0qqW8T9erP2/6Mysvxg Date: Mon, 4 Dec 2017 06:07:37 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD850247@DGGEMM506-MBS.china.huawei.com> References: <151231845659.12009.7566922191612798047@ietfa.amsl.com> In-Reply-To: <151231845659.12009.7566922191612798047@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 06:08:07 -0000 Hi, This new revision addresses all nits pointed out by the idnits tool. As a new editor, I looked at the MMUSIC mail archive and as far as I can te= ll there were no open issues from the list. Thanks Roni Even -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org Sent: =E9=E5=ED=A0=E0 03 =E3=F6=EE=E1=F8 2017 18:28 To: i-d-announce@ietf.org Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiparty Multimedia Session Control WG o= f the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Roni Even Filename : draft-ietf-mmusic-data-channel-sdpneg-14.txt Pages : 41 Date : 2017-12-03 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg= -14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-data-channel-sdpneg-1= 4 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Dec 4 01:16:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2591126C25 for ; Mon, 4 Dec 2017 01:16:55 -0800 (PST) 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_H4=-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 yRlb6IFTDpF1 for ; Mon, 4 Dec 2017 01:16:53 -0800 (PST) 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 42315124207 for ; Mon, 4 Dec 2017 01:16:53 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-7f-5a251283b395 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.EE.13624.382152A5; Mon, 4 Dec 2017 10:16:51 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 10:16:51 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt Thread-Index: AQHTbFO5yfMV375jU0qqW8T9erP2/6MysvxggABI1QA= Date: Mon, 4 Dec 2017 09:16:50 +0000 Message-ID: References: <151231845659.12009.7566922191612798047@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD850247@DGGEMM506-MBS.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD850247@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7qG6zkGqUwZ03yhZTlz9msfh07DyL A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYfm0uS8E764qz9zqZGxhXWHUxcnJICJhI zLj0gL2LkYtDSOAwo8TcT4dYIZzFjBJvnm1h62Lk4GATsJDo/qcN0iAi4CmxrOMCM4gtLBAi 8fnoTXaQEhGBUIm2o5wQJVYSk94+ZAexWQRUJFY+aQWzeQWsJX63TWICsYUEeoF2/Q4AsTmB xrSd6GUEsRkFxCS+n1oDVsMsIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VxBYV0JPYcOI2O0Rc UaL9aQMjyDnMApoS63fpQ4yxljg14yTUSEWJKd0Poc4RlDg58wnLBEaxWUi2zULonoWkexaS 7llIuhcwsq5iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyog1t+W+1gPPjc8RCjAAejEg8v O7NqlBBrYllxZe4hRgkOZiURXgcGoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6Ykl qdmpqQWpRTBZJg5OqQbGWf/PFJyMWBvnyx8tq5G1w2R+S3BP7SH2CW69wa/2zdwhomr+aP18 b/Vo/+tFdrUL5mUt065c/266kOjfRxtSjtZe35W3w2zdOT3pepf6080dokGy2Wkan9jZtpTJ dvSmFokvEJju/H1hVLg352uFXCtjz8WV5Q8v8L2tD1k6z78+ifPKThklluKMREMt5qLiRACo jCfcpAIAAA== Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:16:56 -0000 SGksDQoNCkkgdGhpbmsgdGhpcyBkcmFmdCBjb3VsZCB1c2Ugc29tZSBlZGl0b3JpYWwgd29yay4N Cg0KUTE6IFRoZSBkb2N1bWVudCBkb2VzIG5vdCBjb250YWluIHRoZSBPL0Egc2VjdGlvbiBzdHJ1 Y3R1cmUgdGhhdCB3ZQ0Kbm93YWRheXMgdXNlICjigJxTZW5kaW5nIG9mIGluaXRpYWwgb2ZmZXLi gJ0sIOKAnFNlbmRpbmcgb2YgYW5zd2Vy4oCdLCBldGMuKS4NClRoZXJlIGNhbiB0aGVuIGJlIHN1 YnNlY3Rpb25zIChzZXBhcmF0ZSBmb3IgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyKSBvbg0KaG93 IHRvIG9wZW4gY2hhbm5lbHMsIGNsb3NlIGNoYW5uZWxzIGV0Yy4NCg0KUTI6IFRoZSBwcm9jZWR1 cmUgdGV4dCBpdHNlbGYgaXMgYSBsaXR0bGUgbWVzc3kuIFRoZXJlIGlzIGxvdHMgb2YNCuKAnGdl bmVyYXRlIFNEUOKAnSwg4oCcc2VuZCBTRFDigJ0sIOKAnGFwcGx5IFNEUOKAnSwgZXRjLiBZZXMs IHRoYXQgaXMgaG93IHRoaW5ncyBhcmUNCmRvbmUgaW4gM0dQUCwgYnV0IGluIG15IG9waW5pb24g aXQgbWFrZXMgdGhlIGRyYWZ0IHRleHQgZGlmZmljdWx0IHRvIHJlYWQuDQoNClEzOiBUaGVyZSBp cyBhIHNlY3Rpb24gY2FsbGVkICJWYXJpb3VzIFNEUCBPZmZlci9BbnN3ZXIgU2NlbmFyaW9zIGFu ZA0KQ29uc2lkZXJhdGlvbnPigJ0sIHdoaWNoIGRlc2NyaWJlcyBob3cgZGlmZmVyZW50IFNEUCBy ZWxhdGVkIGNhc2VzIHNoYWxsIGJlDQppbnRlcnByZXRlZC4gVGhlIG9mZmVyZXIgc2VjdGlvbiBz aGFsbCBkZXNjcmliZSBob3cgYXR0cmlidXRlcyBhcmUgc2V0DQpiYXNlZCBvbiB3aGF0IHRoZSBv ZmZlcmVyIHdhbnRzIHRvIGRvLCBhbmQgdGhlIGFuc3dlcmVyIHNlY3Rpb24gc2hhbGwNCmRlc2Ny aWJlIGhvdyB0aGUgcHJlc2VuY2Uvbm9uLXByZXNlbmNlIG9mIGF0dHJpYnV0ZXMgaXMgaW50ZXJw cmV0ZWQuIEl0IElTDQpmaW5lIHRvIGhhdmUgYSBzZWN0aW9uIGRlc2NyaWJpbmcgZGlmZmVyZW50 IGVycm9yIHNjZW5hcmlvcyBldGMsIGJ1dCB0aGlzDQpzZWN0aW9uIGRlc2NyaWJlcyB2YWxpZCB1 c2UtY2FzZXMuDQoNCkp1c3QgdG8gZ2l2ZSBvbmUgZXhhbXBsZS4gVGhlIHRleHQgc2F5czoNCg0K ICAgICJTRFAgYW5zd2VyIGhhcyBubyAiYT1kY3NhOiIgYXR0cmlidXRlcyBmb3IgYSBkYXRhIGNo YW5uZWwuDQoNCiAgICAqICBUaGlzIGlzIGFsbG93ZWQgYW5kIGluZGljYXRlcyB0aGVyZSBhcmUg bm8gc3VicHJvdG9jb2wNCiAgICAgIHBhcmFtZXRlcnMgdG8gY29udmV5IGluIHRoZSBTRFAgYW5z d2VyLuKAnQ0KDQoNClRoaXMgYmVsb25ncyBpbiBhIOKAnFNlbmRpbmcgb2YgYW5zd2Vy4oCdIHNl Y3Rpb24sIGFuZCBzaG91bGQgc2F5IHNvbWV0aGluZw0KbGlrZToNCg0KICAgIOKAnElmIHRoZXJl IGFyZSBzdWJwcm90b2NvbCBwYXJhbWV0ZXJzLCB0aGUgYW5zd2VyZXIgc2hhbGwgYXNzaWduIGEg ZG9zYQ0KYXR0cmlidXRlIHRvIHRoZSBtLSBzZWN0aW9u4oCdDQoNCkkgc2hvdWxkIG5vdCBoYXZl IHRvIHJlYWQgYSDigJxWYXJpb3VzIGNvbnNpZGVyYXRpb25z4oCdIHNlY3Rpb25zIGp1c3QgdG8N CmZpZ3VyZSBvdXQgaG93IHRvIGNyZWF0ZSBhIG5vcm1hbCBhbnN3ZXIuDQoNClE0OiBUaGUgZHRs cy1pZCBoYXMgYmVlbiByZW5hbWVkIHRvIHRscy1pZC4NCg0KUTU6IFRoZSBkcmFmdCBtYWtlcyBz dGF0ZW1lbnRzIG9uIGhvdyBkYXRhIGNoYW5uZWxzIGFuZCBTQ1RQIGFzc29jaWF0aW9ucw0Kd29y ayBhbmQgYmVoYXZlLiBUaGVyZSBzaG91bGQgYmUgcmVmZXJlbmNlcyB0byB0aGUgYXBwcm9wcmlh dGUNCnNwZWNpZmljYXRpb25zLg0KDQpRNjogSSBkb3VidCB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgd2lsbCBwYXNzIHRoZSBJRVNHIHJldmlldy4gSWYNCmludGVybWVkaWFyaWVzIGV0YyBo YXZpbmcgYWNjZXNzIHRvIHRoZSBpbmZvcm1hdGlvbiBldGMgZG9lcyBub3QgY2F1c2UgYW55DQpz ZWN1cml0eSBjb25jZXJucyB5b3Ugc2hvdWxkIHNheSBzby4gSSBhbHNvIHRoaW5rIGl0IHdvdWxk IGJlIGdvb2QgdG8NCnJlZmVyZW5jZSB0byB0aGUgZ2VuZXJpYyBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBmb3IgZGF0YSBjaGFubmVscyBldGMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K DQoNCk9uIDA0LzEyLzE3IDA4OjA3LCAibW11c2ljIG9uIGJlaGFsZiBvZiBSb25pIEV2ZW4iDQo8 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJvbmkuZXZlbkBodWF3ZWkuY29t PiB3cm90ZToNCg0KPkhpLA0KPg0KPlRoaXMgbmV3IHJldmlzaW9uIGFkZHJlc3NlcyBhbGwgbml0 cyBwb2ludGVkIG91dCBieSB0aGUgaWRuaXRzIHRvb2wuDQo+QXMgYSBuZXcgZWRpdG9yLCBJIGxv b2tlZCBhdCB0aGUgTU1VU0lDIG1haWwgYXJjaGl2ZSBhbmQgYXMgZmFyIGFzIEkgY2FuDQo+dGVs bCB0aGVyZSB3ZXJlIG5vIG9wZW4gaXNzdWVzIGZyb20gdGhlIGxpc3QuDQo+DQo+VGhhbmtzDQo+ Um9uaSBFdmVuDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBtbXVz aWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQo+U2VudDog15nXldedINeQIDAzINeT16bXnteR16ggMjAxNyAx ODoyOA0KPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj5DYzogbW11c2ljQGlldGYub3JnDQo+ U3ViamVjdDogW01NVVNJQ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFu bmVsLXNkcG5lZy0xNC50eHQNCj4NCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4NCj5UaGlz IGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lv biBDb250cm9sIFdHDQo+b2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAgICAgICAg OiBTRFAtYmFzZWQgRGF0YSBDaGFubmVsIE5lZ290aWF0aW9uDQo+ICAgICAgICBBdXRob3JzICAg ICAgICAgOiBLZWl0aCBEcmFnZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyaWRpIFIu IE1ha2FyYWp1DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFN0b2V0emVyLUJy YWRsZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFJpY2hhcmQgRWp6YWsNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgIEplcm9tZSBNYXJjb24NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbmkgRXZlbg0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1tdXNpYy1kYXRh LWNoYW5uZWwtc2RwbmVnLTE0LnR4dA0KPglQYWdlcyAgICAgICAgICAgOiA0MQ0KPglEYXRlICAg ICAgICAgICAgOiAyMDE3LTEyLTAzDQo+DQo+QWJzdHJhY3Q6DQo+ICAgVGhlIFJlYWwtVGltZSBD b21tdW5pY2F0aW9uIGluIFdFQi1icm93c2VycyAoUlRDV2ViKSB3b3JraW5nIGdyb3VwIGlzDQo+ ICAgY2hhcmdlZCB0byBwcm92aWRlIHByb3RvY29scyB0byBzdXBwb3J0IGRpcmVjdCBpbnRlcmFj dGl2ZSByaWNoDQo+ICAgY29tbXVuaWNhdGlvbnMgdXNpbmcgYXVkaW8sIHZpZGVvLCBhbmQgZGF0 YSBiZXR3ZWVuIHR3byBwZWVycycgd2ViLQ0KPiAgIGJyb3dzZXJzLiAgRm9yIHRoZSBzdXBwb3J0 IG9mIGRhdGEgY29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYiB3b3JraW5nDQo+ICAgZ3JvdXAgaGFz IGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRh DQo+ICAgY2hhbm5lbHMgb3ZlciBTQ1RQIChTdHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gUHJv dG9jb2wpLCB3aGVyZSBlYWNoDQo+ICAgZGF0YSBjaGFubmVsIG1pZ2h0IGJlIHVzZWQgdG8gdHJh bnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkDQo+ICAgc3VicHJvdG9jb2xzLiAgRGF0YSBj aGFubmVsIHNldHVwIGNhbiBiZSBkb25lIHVzaW5nIGVpdGhlciB0aGUgaW4tDQo+ICAgYmFuZCBE YXRhIENoYW5uZWwgRXN0YWJsaXNobWVudCBQcm90b2NvbCAoRENFUCkgb3IgdXNpbmcgc29tZSBv dXQtb2YtDQo+ICAgYmFuZCBub24tRENFUCBwcm90b2NvbC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGhvdyB0aGUgU0RQIChTZXNzaW9uDQo+ICAgRGVzY3JpcHRpb24gUHJvdG9jb2wpIG9mZmVy L2Fuc3dlciBleGNoYW5nZSBjYW4gYmUgdXNlZCB0byBhY2hpZXZlDQo+ICAgc3VjaCBhbiBvdXQt b2YtYmFuZCBub24tRENFUCBuZWdvdGlhdGlvbi4gIEV2ZW4gdGhvdWdoIGRhdGEgY2hhbm5lbHMN Cj4gICBhcmUgZGVzaWduZWQgZm9yIFJUQ1dlYiB1c2UgaW5pdGlhbGx5LCB0aGV5IG1heSBiZSB1 c2VkIGJ5IG90aGVyDQo+ICAgcHJvdG9jb2xzIGxpa2UsIGJ1dCBub3QgbGltaXRlZCB0bywgdGhl IENMVUUgcHJvdG9jb2wgKHdoaWNoIGlzDQo+ICAgZGVmaW5lZCBieSB0aGUgSUVURiAiQ29udHJv TGxpbmcgbVVsdGlwbGUgc3RyZWFtcyBmb3IgdEVsZXByZXNlbmNlIg0KPiAgIHdvcmtpbmcgZ3Jv dXApLiAgVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIHdoZXJldmVyIGRhdGEN Cj4gICBjaGFubmVscyBhcmUgdXNlZC4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLw0KPg0KPlRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNA0KPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0 YS1jaGFubmVsLXNkcG5lDQo+Zy0xNA0KPg0KPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNA0KPg0KPg0KPlBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m DQo+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0DQo+dG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1tdXNpYyBtYWlsaW5nIGxpc3QN Cj5tbXVzaWNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYw0KDQo= From nobody Mon Dec 4 01:25:54 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAED124207; Mon, 4 Dec 2017 01:25:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151237955346.6318.10415165489676601251@ietfa.amsl.com> Date: Mon, 04 Dec 2017 01:25:53 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-15.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 09:25:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Roni Even Filename : draft-ietf-mmusic-data-channel-sdpneg-15.txt Pages : 41 Date : 2017-12-04 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-15 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-15 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 Mon Dec 4 05:33:52 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C539127076 for ; Mon, 4 Dec 2017 05:33:51 -0800 (PST) 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 97-XYEuFsBgC for ; Mon, 4 Dec 2017 05:33:48 -0800 (PST) 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 533A0126C19 for ; Mon, 4 Dec 2017 05:33:48 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-fc-5a254eba2543 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.3F.13994.ABE452A5; Mon, 4 Dec 2017 14:33:46 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 14:33:46 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications Thread-Index: AQHTbQSColMyBnIAJ0208YZM8KMNHQ== Date: Mon, 4 Dec 2017 13:33:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <25FB30C5361F8D4FA8B9806F3E7516F1@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7n+4uP9Uog8XPFS2mLn/MYvHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxb8EO9oIOjYqd0zazNjC2qHcxcnJICJhI vDy3iqmLkYtDSOAwo8TK3m0sIAkhgcWMEjuXB3YxcnCwCVhIdP/TBgmLCHhKLOu4wAxiCwvU STz4/JAFIl4vcfrhDWYIW09i1bVnYHEWARWJ3Ys/soOM4RWwlnh2DGwto4CYxPdTa5hAbGYB cYlbT+YzQZwjILFkz3lmCFtU4uXjf6wgtijQyA0nbrNDxBUlrk5fzgQykllAU2L9Ln2IMdYS e9a3sUHYihJTuh+ClfMKCEqcnPmEZQKjyCwk22YhdM9C0j0LSfcsJN0LGFlXMYoWpxYX56Yb GeulFmUmFxfn5+nlpZZsYgTGx8Etv3V3MK5+7XiIUYCDUYmH18paNUqINbGsuDL3EKMEB7OS CK+nPlCINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QD49rt 6Uk7JaT272KSvsux5LL1Cnm2mAlsnvUWb9f/0X5+6O4Enlsx3+7pCk/8+nHaPbP4N4fN7F7P 6bh0V+DayZqiP2G1SVqCMjx+j6I55YqW9nq3MIgfVmL64Lt62gnvsyeb7W91T7m//ziXnJvN 22Xb+DOSV710KnvuNnd32bxUtVcX0+vNTZRYijMSDbWYi4oTAc6loOyLAgAA Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 13:33:51 -0000 SGksDQoNClNlY3Rpb24gMSBzYXlzOg0KDQogICAiUHJvY2VkdXJlcyBzcGVjaWZpYyB0byBlYWNo IHN1YnByb3RvY29sIHN1Y2ggYXMgTVNSUCBhcmUgZG9jdW1lbnRlZA0KZWxzZXdoZXJlLiIgIA0K DQoNCkkgdGhpbmsgd2Ugc2hvdWxkIHNheSDigJx3b3VsZCBoYXZlIHRvIGJlIGRvY3VtZW50ZWQg ZWxzZXdoZXJl4oCdLCBiZWNhdXNlIHdlDQpkb27igJl0IGtub3cgd2hldGhlciB0aGV5IHdpbGwg YmUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpPbiAwNC8xMi8xNyAwODowNywgIm1t dXNpYyBvbiBiZWhhbGYgb2YgUm9uaSBFdmVuIg0KPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiByb25pLmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5UaGlz IG5ldyByZXZpc2lvbiBhZGRyZXNzZXMgYWxsIG5pdHMgcG9pbnRlZCBvdXQgYnkgdGhlIGlkbml0 cyB0b29sLg0KPkFzIGEgbmV3IGVkaXRvciwgSSBsb29rZWQgYXQgdGhlIE1NVVNJQyBtYWlsIGFy Y2hpdmUgYW5kIGFzIGZhciBhcyBJIGNhbg0KPnRlbGwgdGhlcmUgd2VyZSBubyBvcGVuIGlzc3Vl cyBmcm9tIHRoZSBsaXN0Lg0KPg0KPlRoYW5rcw0KPlJvbmkgRXZlbg0KPg0KPg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPlNlbnQ6 INeZ15XXnSDXkCAwMyDXk9em157XkdeoIDIwMTcgMTg6MjgNCj5UbzogaS1kLWFubm91bmNlQGll dGYub3JnDQo+Q2M6IG1tdXNpY0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtNTVVTSUNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQudHh0DQo+DQo+DQo+ QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXRw0KPm9mIHRoZSBJRVRG Lg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU0RQLWJhc2VkIERhdGEgQ2hhbm5lbCBO ZWdvdGlhdGlvbg0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VpdGggRHJhZ2UNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgIE1hcmlkaSBSLiBNYWthcmFqdQ0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgSnVlcmdlbiBTdG9ldHplci1CcmFkbGVyDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICBSaWNoYXJkIEVqemFrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKZXJvbWUg TWFyY29uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBSb25pIEV2ZW4NCj4JRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNC50eHQNCj4J UGFnZXMgICAgICAgICAgIDogNDENCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0wMw0KPg0K PkFic3RyYWN0Og0KPiAgIFRoZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbiBXRUItYnJvd3Nl cnMgKFJUQ1dlYikgd29ya2luZyBncm91cCBpcw0KPiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90 b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50ZXJhY3RpdmUgcmljaA0KPiAgIGNvbW11bmljYXRp b25zIHVzaW5nIGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEgYmV0d2VlbiB0d28gcGVlcnMnIHdlYi0N Cj4gICBicm93c2Vycy4gIEZvciB0aGUgc3VwcG9ydCBvZiBkYXRhIGNvbW11bmljYXRpb24sIHRo ZSBSVENXZWIgd29ya2luZw0KPiAgIGdyb3VwIGhhcyBpbiBwYXJ0aWN1bGFyIGRlZmluZWQgdGhl IGNvbmNlcHQgb2YgYmktZGlyZWN0aW9uYWwgZGF0YQ0KPiAgIGNoYW5uZWxzIG92ZXIgU0NUUCAo U3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sKSwgd2hlcmUgZWFjaA0KPiAgIGRh dGEgY2hhbm5lbCBtaWdodCBiZSB1c2VkIHRvIHRyYW5zcG9ydCBvdGhlciBwcm90b2NvbHMsIGNh bGxlZA0KPiAgIHN1YnByb3RvY29scy4gIERhdGEgY2hhbm5lbCBzZXR1cCBjYW4gYmUgZG9uZSB1 c2luZyBlaXRoZXIgdGhlIGluLQ0KPiAgIGJhbmQgRGF0YSBDaGFubmVsIEVzdGFibGlzaG1lbnQg UHJvdG9jb2wgKERDRVApIG9yIHVzaW5nIHNvbWUgb3V0LW9mLQ0KPiAgIGJhbmQgbm9uLURDRVAg cHJvdG9jb2wuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIFNEUCAoU2Vzc2lvbg0K PiAgIERlc2NyaXB0aW9uIFByb3RvY29sKSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgY2FuIGJlIHVz ZWQgdG8gYWNoaWV2ZQ0KPiAgIHN1Y2ggYW4gb3V0LW9mLWJhbmQgbm9uLURDRVAgbmVnb3RpYXRp b24uICBFdmVuIHRob3VnaCBkYXRhIGNoYW5uZWxzDQo+ICAgYXJlIGRlc2lnbmVkIGZvciBSVENX ZWIgdXNlIGluaXRpYWxseSwgdGhleSBtYXkgYmUgdXNlZCBieSBvdGhlcg0KPiAgIHByb3RvY29s cyBsaWtlLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRoZSBDTFVFIHByb3RvY29sICh3aGljaCBpcw0K PiAgIGRlZmluZWQgYnkgdGhlIElFVEYgIkNvbnRyb0xsaW5nIG1VbHRpcGxlIHN0cmVhbXMgZm9y IHRFbGVwcmVzZW5jZSINCj4gICB3b3JraW5nIGdyb3VwKS4gIFRoaXMgZG9jdW1lbnQgaXMgaW50 ZW5kZWQgdG8gYmUgdXNlZCB3aGVyZXZlciBkYXRhDQo+ICAgY2hhbm5lbHMgYXJlIHVzZWQuDQo+ DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6 DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0 YS1jaGFubmVsLXNkcG5lZy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11 c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZQ0KPmctMTQNCj4N Cj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hh bm5lbC1zZHBuZWctMTQNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPnRvb2xzLmlldGYub3Jn Lg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bW11c2ljIG1haWxpbmcg bGlzdA0KPm1tdXNpY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K From nobody Mon Dec 4 05:50:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97F11273E2 for ; Mon, 4 Dec 2017 05:50:51 -0800 (PST) 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 9Zx6XmQCc6m3 for ; Mon, 4 Dec 2017 05:50:47 -0800 (PST) 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 42CAF127369 for ; Mon, 4 Dec 2017 05:50:47 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-cd-5a2552b5640c Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.03.13994.5B2552A5; Mon, 4 Dec 2017 14:50:45 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 14:50:45 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question Thread-Index: AQHTbQbhi4o/9RAH90GqnZx87PkuaA== Date: Mon, 4 Dec 2017 13:50:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <3FC639C08E59394DB5D944D404879682@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7pe7WINUog9srVC2mLn/MYvHp2HkW ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXR3nWPtWCSdsXhnf/YGhhbtLoYOTkkBEwk tj48zNTFyMUhJHCYUeLVs/XMEM5iRolzrf1AGQ4ONgELie5/2iANIgKeEss6LjCD2MICqRJP p9xhh4inSVxc/RTK1pNo3/WLCcRmEVCR2L19DiuIzStgLXFyzjo2EJtRQEzi+6k1YDXMAuIS t57MZ4I4SEBiyZ7zzBC2qMTLx//AekWBZm44cZsdIq4k8WPDJRaQ05gFNCXW79KHGGMt0bp1 IjOErSgxpfshO8RaQYmTM5+wTGAUmYVk2yyE7llIumch6Z6FpHsBI+sqRtHi1OLi3HQjY73U oszk4uL8PL281JJNjMAYObjlt+4OxtWvHQ8xCnAwKvHwWlmrRgmxJpYVV+YeYpTgYFYS4VUP BArxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpg1Da/dcKz MqPun2DnHKtL6yZE3uASfzat/JdgXqc/v7FIvdz3/qgOgZV9LG9Ob1Hdukv72IJnp6aveZSR OHUfR7gjh7gyw5OADQm3u2stXTt6a3cK/4lW+qF24s/p6Du2x5g/s382bztlv+RoyOLIpov+ qzozHnRN2N0g+DdPbE9o7o2mor1CSizFGYmGWsxFxYkAQmPFeI0CAAA= Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 13:50:52 -0000 SGksDQoNClNlY3Rpb24gc2F5czoNCg0KICJJZiBhIHBlZXIgcmVjZWl2ZXMgYW4gU0RQIG9mZmVy IGJlZm9yZSBzdGFydGluZyB0byBzZW5kIGEgbmV3IFNEUCBvZmZlcg0KIHdpdGggZGF0YSBjaGFu bmVscyB0aGF0IGFyZSB0byBiZSBTRFAgb2ZmZXIvYW5zd2VyIG5lZ290aWF0ZWQsIG9yDQogbG9z ZXMgYW4gU0RQIG9mZmVyIGdsYXJlIHJlc29sdXRpb24gcHJvY2VkdXJlIGluIHRoaXMgY2FzZSwg aXQgTVVTVA0KIHdhaXQgdW50aWwgdGhlIG9uZ29pbmcgU0RQIG9mZmVyL2Fuc3dlciBjb21wbGV0 ZXMgYmVmb3JlIHJlc3VtaW5nIHRoZQ0KIFNEUCBvZmZlci9hbnN3ZXIgbmVnb3RpYXRpb24gcHJv Y2VkdXJlLiINCg0KDQpOb3csIGFzc3VtaW5nIEkgdW5kZXJzdGFuZCB0aGUgdGV4dCBjb3JyZWN0 bHksIGl0IHNpbXBseSByZXBlYXRzIGdlbmVyaWMNCk8vQSBnbGFyZSBwcm9jZWR1cmVzLg0KDQpP ciwgaXMgdGhlcmUgc3VwcG9zZWQgdG8gYmUgc29tZXRoaW5nIGRhdGEgY2hhbm5lbCBzcGVjaWZp Yz8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpPbiAwNC8xMi8xNyAwODowNywg Im1tdXNpYyBvbiBiZWhhbGYgb2YgUm9uaSBFdmVuIg0KPG1tdXNpYy1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiByb25pLmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5U aGlzIG5ldyByZXZpc2lvbiBhZGRyZXNzZXMgYWxsIG5pdHMgcG9pbnRlZCBvdXQgYnkgdGhlIGlk bml0cyB0b29sLg0KPkFzIGEgbmV3IGVkaXRvciwgSSBsb29rZWQgYXQgdGhlIE1NVVNJQyBtYWls IGFyY2hpdmUgYW5kIGFzIGZhciBhcyBJIGNhbg0KPnRlbGwgdGhlcmUgd2VyZSBubyBvcGVuIGlz c3VlcyBmcm9tIHRoZSBsaXN0Lg0KPg0KPlRoYW5rcw0KPlJvbmkgRXZlbg0KPg0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPlNl bnQ6INeZ15XXnSDXkCAwMyDXk9em157XkdeoIDIwMTcgMTg6MjgNCj5UbzogaS1kLWFubm91bmNl QGlldGYub3JnDQo+Q2M6IG1tdXNpY0BpZXRmLm9yZw0KPlN1YmplY3Q6IFtNTVVTSUNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQudHh0DQo+DQo+ DQo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzDQo+ZGlyZWN0b3JpZXMuDQo+VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJvbCBXRw0KPm9mIHRoZSBJ RVRGLg0KPg0KPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogU0RQLWJhc2VkIERhdGEgQ2hhbm5l bCBOZWdvdGlhdGlvbg0KPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VpdGggRHJhZ2UNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmlkaSBSLiBNYWthcmFqdQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgSnVlcmdlbiBTdG9ldHplci1CcmFkbGVyDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICBSaWNoYXJkIEVqemFrDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBKZXJv bWUgTWFyY29uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBSb25pIEV2ZW4NCj4JRmlsZW5h bWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNC50eHQN Cj4JUGFnZXMgICAgICAgICAgIDogNDENCj4JRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0wMw0K Pg0KPkFic3RyYWN0Og0KPiAgIFRoZSBSZWFsLVRpbWUgQ29tbXVuaWNhdGlvbiBpbiBXRUItYnJv d3NlcnMgKFJUQ1dlYikgd29ya2luZyBncm91cCBpcw0KPiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBw cm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50ZXJhY3RpdmUgcmljaA0KPiAgIGNvbW11bmlj YXRpb25zIHVzaW5nIGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEgYmV0d2VlbiB0d28gcGVlcnMnIHdl Yi0NCj4gICBicm93c2Vycy4gIEZvciB0aGUgc3VwcG9ydCBvZiBkYXRhIGNvbW11bmljYXRpb24s IHRoZSBSVENXZWIgd29ya2luZw0KPiAgIGdyb3VwIGhhcyBpbiBwYXJ0aWN1bGFyIGRlZmluZWQg dGhlIGNvbmNlcHQgb2YgYmktZGlyZWN0aW9uYWwgZGF0YQ0KPiAgIGNoYW5uZWxzIG92ZXIgU0NU UCAoU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sKSwgd2hlcmUgZWFjaA0KPiAg IGRhdGEgY2hhbm5lbCBtaWdodCBiZSB1c2VkIHRvIHRyYW5zcG9ydCBvdGhlciBwcm90b2NvbHMs IGNhbGxlZA0KPiAgIHN1YnByb3RvY29scy4gIERhdGEgY2hhbm5lbCBzZXR1cCBjYW4gYmUgZG9u ZSB1c2luZyBlaXRoZXIgdGhlIGluLQ0KPiAgIGJhbmQgRGF0YSBDaGFubmVsIEVzdGFibGlzaG1l bnQgUHJvdG9jb2wgKERDRVApIG9yIHVzaW5nIHNvbWUgb3V0LW9mLQ0KPiAgIGJhbmQgbm9uLURD RVAgcHJvdG9jb2wuICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIFNEUCAoU2Vzc2lv bg0KPiAgIERlc2NyaXB0aW9uIFByb3RvY29sKSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgY2FuIGJl IHVzZWQgdG8gYWNoaWV2ZQ0KPiAgIHN1Y2ggYW4gb3V0LW9mLWJhbmQgbm9uLURDRVAgbmVnb3Rp YXRpb24uICBFdmVuIHRob3VnaCBkYXRhIGNoYW5uZWxzDQo+ICAgYXJlIGRlc2lnbmVkIGZvciBS VENXZWIgdXNlIGluaXRpYWxseSwgdGhleSBtYXkgYmUgdXNlZCBieSBvdGhlcg0KPiAgIHByb3Rv Y29scyBsaWtlLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRoZSBDTFVFIHByb3RvY29sICh3aGljaCBp cw0KPiAgIGRlZmluZWQgYnkgdGhlIElFVEYgIkNvbnRyb0xsaW5nIG1VbHRpcGxlIHN0cmVhbXMg Zm9yIHRFbGVwcmVzZW5jZSINCj4gICB3b3JraW5nIGdyb3VwKS4gIFRoaXMgZG9jdW1lbnQgaXMg aW50ZW5kZWQgdG8gYmUgdXNlZCB3aGVyZXZlciBkYXRhDQo+ICAgY2hhbm5lbHMgYXJlIHVzZWQu DQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQg aXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tbXVzaWMt ZGF0YS1jaGFubmVsLXNkcG5lZy8NCj4NCj5UaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9u cyBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZQ0KPmctMTQN Cj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLWRhdGEt Y2hhbm5lbC1zZHBuZWctMTQNCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPnRvb2xzLmlldGYu b3JnLg0KPg0KPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bW11c2ljIG1haWxp bmcgbGlzdA0KPm1tdXNpY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K From nobody Mon Dec 4 05:56:33 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1796126C19 for ; Mon, 4 Dec 2017 05:56:31 -0800 (PST) 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 4So8LRKhjhOM for ; Mon, 4 Dec 2017 05:56:29 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 85759124BAC for ; Mon, 4 Dec 2017 05:56:29 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5F6482D475A7F; Mon, 4 Dec 2017 13:56:25 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 13:56:26 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 21:56:22 +0800 From: Roni Even To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question Thread-Index: AQHTbQbhi4o/9RAH90GqnZx87PkuaKMzNQ5Q Date: Mon, 4 Dec 2017 13:56:22 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8503B8@DGGEMM506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 13:56:32 -0000 SGkgQ2hyaXN0ZXIsDQpUaGlzIGxvb2tzIHRvIG1lIGxpa2UgcmVkdW5kYW50IHRleHQuIA0KUm9u aQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENocmlzdGVyIEhvbG1i ZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiDXmdeV 153CoNeRIDA0INeT16bXnteR16ggMjAxNyAxNTo1MQ0KPiBUbzogUm9uaSBFdmVuOyBtbXVzaWNA aWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtDQo+IHNkcG5lZy0xNC50eHQgLSBnbGFyZSBxdWVzdGlv bg0KPiANCj4gSGksDQo+IA0KPiBTZWN0aW9uIHNheXM6DQo+IA0KPiAgIklmIGEgcGVlciByZWNl aXZlcyBhbiBTRFAgb2ZmZXIgYmVmb3JlIHN0YXJ0aW5nIHRvIHNlbmQgYSBuZXcgU0RQIG9mZmVy ICB3aXRoDQo+IGRhdGEgY2hhbm5lbHMgdGhhdCBhcmUgdG8gYmUgU0RQIG9mZmVyL2Fuc3dlciBu ZWdvdGlhdGVkLCBvciAgbG9zZXMgYW4gU0RQDQo+IG9mZmVyIGdsYXJlIHJlc29sdXRpb24gcHJv Y2VkdXJlIGluIHRoaXMgY2FzZSwgaXQgTVVTVCAgd2FpdCB1bnRpbCB0aGUgb25nb2luZw0KPiBT RFAgb2ZmZXIvYW5zd2VyIGNvbXBsZXRlcyBiZWZvcmUgcmVzdW1pbmcgdGhlICBTRFAgb2ZmZXIv YW5zd2VyDQo+IG5lZ290aWF0aW9uIHByb2NlZHVyZS4iDQo+IA0KPiANCj4gTm93LCBhc3N1bWlu ZyBJIHVuZGVyc3RhbmQgdGhlIHRleHQgY29ycmVjdGx5LCBpdCBzaW1wbHkgcmVwZWF0cyBnZW5l cmljIE8vQQ0KPiBnbGFyZSBwcm9jZWR1cmVzLg0KPiANCj4gT3IsIGlzIHRoZXJlIHN1cHBvc2Vk IHRvIGJlIHNvbWV0aGluZyBkYXRhIGNoYW5uZWwgc3BlY2lmaWM/DQo+IA0KPiBSZWdhcmRzLA0K PiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiAwNC8xMi8xNyAwODowNywg Im1tdXNpYyBvbiBiZWhhbGYgb2YgUm9uaSBFdmVuIg0KPiA8bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+ID5IaSwN Cj4gPg0KPiA+VGhpcyBuZXcgcmV2aXNpb24gYWRkcmVzc2VzIGFsbCBuaXRzIHBvaW50ZWQgb3V0 IGJ5IHRoZSBpZG5pdHMgdG9vbC4NCj4gPkFzIGEgbmV3IGVkaXRvciwgSSBsb29rZWQgYXQgdGhl IE1NVVNJQyBtYWlsIGFyY2hpdmUgYW5kIGFzIGZhciBhcyBJDQo+ID5jYW4gdGVsbCB0aGVyZSB3 ZXJlIG5vIG9wZW4gaXNzdWVzIGZyb20gdGhlIGxpc3QuDQo+ID4NCj4gPlRoYW5rcw0KPiA+Um9u aSBFdmVuDQo+ID4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206 IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4g PmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiA+U2VudDog15nXldedINeQIDAzINeT16bXnteR 16ggMjAxNyAxODoyOA0KPiA+VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiA+Q2M6IG1tdXNp Y0BpZXRmLm9yZw0KPiA+U3ViamVjdDogW01NVVNJQ10gSS1EIEFjdGlvbjoNCj4gPmRyYWZ0LWll dGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQudHh0DQo+ID4NCj4gPg0KPiA+QSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzDQo+ID5kaXJlY3Rvcmllcy4NCj4gPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IE11bHRpcGFydHkgTXVsdGltZWRpYSBTZXNzaW9uIENvbnRyb2wNCj4gPldHIG9mIHRoZSBJRVRG Lg0KPiA+DQo+ID4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFNEUC1iYXNlZCBEYXRhIENoYW5u ZWwgTmVnb3RpYXRpb24NCj4gPiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VpdGggRHJhZ2UN Cj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyaWRpIFIuIE1ha2FyYWp1DQo+ID4gICAg ICAgICAgICAgICAgICAgICAgICAgIEp1ZXJnZW4gU3RvZXR6ZXItQnJhZGxlcg0KPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICBSaWNoYXJkIEVqemFrDQo+ID4gICAgICAgICAgICAgICAgICAg ICAgICAgIEplcm9tZSBNYXJjb24NCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uaSBF dmVuDQo+ID4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVs LXNkcG5lZy0xNC50eHQNCj4gPglQYWdlcyAgICAgICAgICAgOiA0MQ0KPiA+CURhdGUgICAgICAg ICAgICA6IDIwMTctMTItMDMNCj4gPg0KPiA+QWJzdHJhY3Q6DQo+ID4gICBUaGUgUmVhbC1UaW1l IENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcgZ3JvdXANCj4g aXMNCj4gPiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3Qg aW50ZXJhY3RpdmUgcmljaA0KPiA+ICAgY29tbXVuaWNhdGlvbnMgdXNpbmcgYXVkaW8sIHZpZGVv LCBhbmQgZGF0YSBiZXR3ZWVuIHR3byBwZWVycycgd2ViLQ0KPiA+ICAgYnJvd3NlcnMuICBGb3Ig dGhlIHN1cHBvcnQgb2YgZGF0YSBjb21tdW5pY2F0aW9uLCB0aGUgUlRDV2ViIHdvcmtpbmcNCj4g PiAgIGdyb3VwIGhhcyBpbiBwYXJ0aWN1bGFyIGRlZmluZWQgdGhlIGNvbmNlcHQgb2YgYmktZGly ZWN0aW9uYWwgZGF0YQ0KPiA+ICAgY2hhbm5lbHMgb3ZlciBTQ1RQIChTdHJlYW0gQ29udHJvbCBU cmFuc21pc3Npb24gUHJvdG9jb2wpLCB3aGVyZSBlYWNoDQo+ID4gICBkYXRhIGNoYW5uZWwgbWln aHQgYmUgdXNlZCB0byB0cmFuc3BvcnQgb3RoZXIgcHJvdG9jb2xzLCBjYWxsZWQNCj4gPiAgIHN1 YnByb3RvY29scy4gIERhdGEgY2hhbm5lbCBzZXR1cCBjYW4gYmUgZG9uZSB1c2luZyBlaXRoZXIg dGhlIGluLQ0KPiA+ICAgYmFuZCBEYXRhIENoYW5uZWwgRXN0YWJsaXNobWVudCBQcm90b2NvbCAo RENFUCkgb3IgdXNpbmcgc29tZSBvdXQtb2YtDQo+ID4gICBiYW5kIG5vbi1EQ0VQIHByb3RvY29s LiAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRoZSBTRFAgKFNlc3Npb24NCj4gPiAgIERl c2NyaXB0aW9uIFByb3RvY29sKSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgY2FuIGJlIHVzZWQgdG8g YWNoaWV2ZQ0KPiA+ICAgc3VjaCBhbiBvdXQtb2YtYmFuZCBub24tRENFUCBuZWdvdGlhdGlvbi4g IEV2ZW4gdGhvdWdoIGRhdGEgY2hhbm5lbHMNCj4gPiAgIGFyZSBkZXNpZ25lZCBmb3IgUlRDV2Vi IHVzZSBpbml0aWFsbHksIHRoZXkgbWF5IGJlIHVzZWQgYnkgb3RoZXINCj4gPiAgIHByb3RvY29s cyBsaWtlLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRoZSBDTFVFIHByb3RvY29sICh3aGljaCBpcw0K PiA+ICAgZGVmaW5lZCBieSB0aGUgSUVURiAiQ29udHJvTGxpbmcgbVVsdGlwbGUgc3RyZWFtcyBm b3IgdEVsZXByZXNlbmNlIg0KPiA+ICAgd29ya2luZyBncm91cCkuICBUaGlzIGRvY3VtZW50IGlz IGludGVuZGVkIHRvIGJlIHVzZWQgd2hlcmV2ZXIgZGF0YQ0KPiA+ICAgY2hhbm5lbHMgYXJlIHVz ZWQuDQo+ID4NCj4gPg0KPiA+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6DQo+ID5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLw0KPiA+DQo+ID5UaGVyZSBhcmUgYWxzbyBo dG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ID5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNA0KPiA+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNo YW5uZWwtc2QNCj4gPnBuZQ0KPiA+Zy0xNA0KPiA+DQo+ID5BIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZw0KPiA+LTE0DQo+ ID4NCj4gPg0KPiA+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPnN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+dG9vbHMuaWV0Zi5vcmcuDQo+ID4N Cj4gPkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCj4gPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4NCj4gPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID5tbXVzaWMgbWFp bGluZyBsaXN0DQo+ID5tbXVzaWNAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljDQo+ID4NCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID5tbXVzaWMgbWFpbGluZyBsaXN0DQo+ID5tbXVzaWNA aWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2lj DQoNCg== From nobody Mon Dec 4 05:59:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0386126C19 for ; Mon, 4 Dec 2017 05:59:32 -0800 (PST) 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 3sHVjdZK7O9d for ; Mon, 4 Dec 2017 05:59:30 -0800 (PST) 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 77A2E124BAC for ; Mon, 4 Dec 2017 05:59:30 -0800 (PST) X-AuditID: c1b4fb25-385ff70000000151-cc-5a2554c0848c Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.56.00337.0C4552A5; Mon, 4 Dec 2017 14:59:28 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 14:59:28 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question Thread-Index: AQHTbQbhi4o/9RAH90GqnZx87PkuaKMzNQ5QgAAUUgA= Date: Mon, 4 Dec 2017 13:59:27 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD8503B8@DGGEMM506-MBS.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8503B8@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: <88167B47160C654EB330E0052C11E73A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7k+6BENUog89dJhZTlz9msfh07DyL A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4N9+tYI1ZxbRV+9gaGH+YdDFyckgImEhM XvecpYuRi0NI4DCjxKpnjUwQzmJGic3zV7F2MXJwsAlYSHT/0wZpEBHwlFjWcYEZxBYWSJV4 OuUOO0Q8TeLi6qdQtpXErae9bCA2i4CKRO+mmWA2r4C1xLG3e5hAbCGBVkaJna2+IDanQIjE maa/rCA2o4CYxPdTa8BqmAXEJW49mc8EcaiAxJI955khbFGJl4//gdWLCuhJbDhxmx0iriTx Y8MlFpCTmQU0Jdbv0ocYYy3R/v8gC4StKDGl+yE7xDmCEidnPmGZwCg2C8m2WQjds5B0z0LS PQtJ9wJG1lWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgRF1cMtv1R2Ml984HmIU4GBU4uE9 ba0aJcSaWFZcmXuIUYKDWUmEVz0QKMSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBAemJJ anZqakFqEUyWiYNTqoHR79Hpy1f2rpp/pXGvwL62qfuMHqovNz0inbrgBpvYqUm3414vtnK8 YcXwcMmsLJPptunPN3A+2P38c9ubk5tl2r3Uq4LkqmQNvOcmLnbnqfhZtN/qSsxqv0u/LiVu 8LEKuyfZp8X1dsbCtfkfWoxY1Vi7wtkYRZIkFksn/2WYue/Yo8b+4rVaSizFGYmGWsxFxYkA BZV5WqQCAAA= Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - glare question X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 13:59:33 -0000 SGksDQoNClRoZSBkcmFmdCBhbHNvIHJlcGVhdHMg4oCcZGF0YSBjaGFubmVsIHdpdGggT2ZmZXIv QW5zd2Vy4oCdIG1hbnkgdGltZXMuIEkNCnRoaW5rIGl0IGlzIGVub3VnaCB0byBzYXkgb25jZSB0 aGF0IHRoZSBwcm9jZWR1cmVzIGFyZSBmb3IgbmVnb3RpYXRpbmcNCmRhdGEgY2hhbm5lbHMgdXNp bmcgb2ZmZXIvYW5zd2VyLiBObyBuZWVkIHRvIGtlZXAgcmVwZWF0aW5nIGl04oCmDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KT24gMDQvMTIvMTcgMTU6NTYsICJSb25pIEV2ZW4iIDxyb25p LmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBDaHJpc3RlciwNCj5UaGlzIGxvb2tzIHRv IG1lIGxpa2UgcmVkdW5kYW50IHRleHQuDQo+Um9uaQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tXQ0KPj4gU2VudDog15nXldedINeRIDA0INeT16bXnteR16ggMjAx NyAxNTo1MQ0KPj4gVG86IFJvbmkgRXZlbjsgbW11c2ljQGlldGYub3JnDQo+PiBTdWJqZWN0OiBS ZTogW01NVVNJQ10gRlc6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5l bC0NCj4+IHNkcG5lZy0xNC50eHQgLSBnbGFyZSBxdWVzdGlvbg0KPj4gDQo+PiBIaSwNCj4+IA0K Pj4gU2VjdGlvbiBzYXlzOg0KPj4gDQo+PiAgIklmIGEgcGVlciByZWNlaXZlcyBhbiBTRFAgb2Zm ZXIgYmVmb3JlIHN0YXJ0aW5nIHRvIHNlbmQgYSBuZXcgU0RQDQo+Pm9mZmVyICB3aXRoDQo+PiBk YXRhIGNoYW5uZWxzIHRoYXQgYXJlIHRvIGJlIFNEUCBvZmZlci9hbnN3ZXIgbmVnb3RpYXRlZCwg b3IgIGxvc2VzIGFuDQo+PlNEUA0KPj4gb2ZmZXIgZ2xhcmUgcmVzb2x1dGlvbiBwcm9jZWR1cmUg aW4gdGhpcyBjYXNlLCBpdCBNVVNUICB3YWl0IHVudGlsIHRoZQ0KPj5vbmdvaW5nDQo+PiBTRFAg b2ZmZXIvYW5zd2VyIGNvbXBsZXRlcyBiZWZvcmUgcmVzdW1pbmcgdGhlICBTRFAgb2ZmZXIvYW5z d2VyDQo+PiBuZWdvdGlhdGlvbiBwcm9jZWR1cmUuIg0KPj4gDQo+PiANCj4+IE5vdywgYXNzdW1p bmcgSSB1bmRlcnN0YW5kIHRoZSB0ZXh0IGNvcnJlY3RseSwgaXQgc2ltcGx5IHJlcGVhdHMNCj4+ Z2VuZXJpYyBPL0ENCj4+IGdsYXJlIHByb2NlZHVyZXMuDQo+PiANCj4+IE9yLCBpcyB0aGVyZSBz dXBwb3NlZCB0byBiZSBzb21ldGhpbmcgZGF0YSBjaGFubmVsIHNwZWNpZmljPw0KPj4gDQo+PiBS ZWdhcmRzLA0KPj4gDQo+PiBDaHJpc3Rlcg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9u IDA0LzEyLzE3IDA4OjA3LCAibW11c2ljIG9uIGJlaGFsZiBvZiBSb25pIEV2ZW4iDQo+PiA8bW11 c2ljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3 cm90ZToNCj4+IA0KPj4gPkhpLA0KPj4gPg0KPj4gPlRoaXMgbmV3IHJldmlzaW9uIGFkZHJlc3Nl cyBhbGwgbml0cyBwb2ludGVkIG91dCBieSB0aGUgaWRuaXRzIHRvb2wuDQo+PiA+QXMgYSBuZXcg ZWRpdG9yLCBJIGxvb2tlZCBhdCB0aGUgTU1VU0lDIG1haWwgYXJjaGl2ZSBhbmQgYXMgZmFyIGFz IEkNCj4+ID5jYW4gdGVsbCB0aGVyZSB3ZXJlIG5vIG9wZW4gaXNzdWVzIGZyb20gdGhlIGxpc3Qu DQo+PiA+DQo+PiA+VGhhbmtzDQo+PiA+Um9uaSBFdmVuDQo+PiA+DQo+PiA+DQo+PiA+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiA+aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn DQo+PiA+U2VudDog15nXldedINeQIDAzINeT16bXnteR16ggMjAxNyAxODoyOA0KPj4gPlRvOiBp LWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+ID5DYzogbW11c2ljQGlldGYub3JnDQo+PiA+U3ViamVj dDogW01NVVNJQ10gSS1EIEFjdGlvbjoNCj4+ID5kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5u ZWwtc2RwbmVnLTE0LnR4dA0KPj4gPg0KPj4gPg0KPj4gPkEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj4gPmRpcmVjdG9y aWVzLg0KPj4gPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE11bHRpcGFydHkgTXVs dGltZWRpYSBTZXNzaW9uIENvbnRyb2wNCj4+ID5XRyBvZiB0aGUgSUVURi4NCj4+ID4NCj4+ID4g ICAgICAgIFRpdGxlICAgICAgICAgICA6IFNEUC1iYXNlZCBEYXRhIENoYW5uZWwgTmVnb3RpYXRp b24NCj4+ID4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEtlaXRoIERyYWdlDQo+PiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICBNYXJpZGkgUi4gTWFrYXJhanUNCj4+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgIEp1ZXJnZW4gU3RvZXR6ZXItQnJhZGxlcg0KPj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgUmljaGFyZCBFanphaw0KPj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAg SmVyb21lIE1hcmNvbg0KPj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uaSBFdmVuDQo+ PiA+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBu ZWctMTQudHh0DQo+PiA+CVBhZ2VzICAgICAgICAgICA6IDQxDQo+PiA+CURhdGUgICAgICAgICAg ICA6IDIwMTctMTItMDMNCj4+ID4NCj4+ID5BYnN0cmFjdDoNCj4+ID4gICBUaGUgUmVhbC1UaW1l IENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcgZ3JvdXANCj4+ IGlzDQo+PiA+ICAgY2hhcmdlZCB0byBwcm92aWRlIHByb3RvY29scyB0byBzdXBwb3J0IGRpcmVj dCBpbnRlcmFjdGl2ZSByaWNoDQo+PiA+ICAgY29tbXVuaWNhdGlvbnMgdXNpbmcgYXVkaW8sIHZp ZGVvLCBhbmQgZGF0YSBiZXR3ZWVuIHR3byBwZWVycycgd2ViLQ0KPj4gPiAgIGJyb3dzZXJzLiAg Rm9yIHRoZSBzdXBwb3J0IG9mIGRhdGEgY29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYiB3b3JraW5n DQo+PiA+ICAgZ3JvdXAgaGFzIGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBi aS1kaXJlY3Rpb25hbCBkYXRhDQo+PiA+ICAgY2hhbm5lbHMgb3ZlciBTQ1RQIChTdHJlYW0gQ29u dHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wpLCB3aGVyZQ0KPj5lYWNoDQo+PiA+ICAgZGF0YSBj aGFubmVsIG1pZ2h0IGJlIHVzZWQgdG8gdHJhbnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVk DQo+PiA+ICAgc3VicHJvdG9jb2xzLiAgRGF0YSBjaGFubmVsIHNldHVwIGNhbiBiZSBkb25lIHVz aW5nIGVpdGhlciB0aGUgaW4tDQo+PiA+ICAgYmFuZCBEYXRhIENoYW5uZWwgRXN0YWJsaXNobWVu dCBQcm90b2NvbCAoRENFUCkgb3IgdXNpbmcgc29tZQ0KPj5vdXQtb2YtDQo+PiA+ICAgYmFuZCBu b24tRENFUCBwcm90b2NvbC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGhvdyB0aGUgU0RQDQo+ PihTZXNzaW9uDQo+PiA+ICAgRGVzY3JpcHRpb24gUHJvdG9jb2wpIG9mZmVyL2Fuc3dlciBleGNo YW5nZSBjYW4gYmUgdXNlZCB0byBhY2hpZXZlDQo+PiA+ICAgc3VjaCBhbiBvdXQtb2YtYmFuZCBu b24tRENFUCBuZWdvdGlhdGlvbi4gIEV2ZW4gdGhvdWdoIGRhdGEgY2hhbm5lbHMNCj4+ID4gICBh cmUgZGVzaWduZWQgZm9yIFJUQ1dlYiB1c2UgaW5pdGlhbGx5LCB0aGV5IG1heSBiZSB1c2VkIGJ5 IG90aGVyDQo+PiA+ICAgcHJvdG9jb2xzIGxpa2UsIGJ1dCBub3QgbGltaXRlZCB0bywgdGhlIENM VUUgcHJvdG9jb2wgKHdoaWNoIGlzDQo+PiA+ICAgZGVmaW5lZCBieSB0aGUgSUVURiAiQ29udHJv TGxpbmcgbVVsdGlwbGUgc3RyZWFtcyBmb3IgdEVsZXByZXNlbmNlIg0KPj4gPiAgIHdvcmtpbmcg Z3JvdXApLiAgVGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIHdoZXJldmVyIGRh dGENCj4+ID4gICBjaGFubmVscyBhcmUgdXNlZC4NCj4+ID4NCj4+ID4NCj4+ID5UaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+ID5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2Rw bmVnLw0KPj4gPg0KPj4gPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj4+ID5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt ZGF0YS1jaGFubmVsLXNkcG5lZy0xNA0KPj4gPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkDQo+PiA+cG5lDQo+PiA+ Zy0xNA0KPj4gPg0KPj4gPkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZw0KPj4gPi0xNA0KPj4gPg0KPj4gPg0KPj4gPlBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mDQo+PiA+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0DQo+PiA+dG9vbHMuaWV0Zi5vcmcuDQo+PiA+DQo+PiA+SW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4gPmZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiA+DQo+PiA+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5tbXVzaWMgbWFpbGluZyBs aXN0DQo+PiA+bW11c2ljQGlldGYub3JnDQo+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCj4+ID4NCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gPm1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+ID5tbXVzaWNA aWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KPg0KDQo= From nobody Mon Dec 4 06:02:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BC6127337 for ; Mon, 4 Dec 2017 06:02:45 -0800 (PST) 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 EEN5hzrdRmH7 for ; Mon, 4 Dec 2017 06:02:43 -0800 (PST) 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 9737C127369 for ; Mon, 4 Dec 2017 06:02:40 -0800 (PST) X-AuditID: c1b4fb30-093dd9c0000029e3-50-5a25557e5b72 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.01.10723.E75552A5; Mon, 4 Dec 2017 15:02:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 4 Dec 2017 15:02:38 +0100 From: Christer Holmberg To: Roni Even , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - text that can be removed Thread-Index: AQHTbQiK3pDhM4ao+0uhylvhXG/1EQ== Date: Mon, 4 Dec 2017 14:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="utf-8" Content-ID: <9BEB876EAB405B4FB93BEE27D15E4A9E@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM2K7qG5dqGqUwbHzFhZTlz9msfh07DyL A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4euQWc8ES+4pn83rYGhiv2HYxcnJICJhI LG/qZO9i5OIQEjjMKNH1cyELSEJIYDGjxKstYV2MHBxsAhYS3f+0QcIiAp4SyzouMIOEhQXy JaYfsoEIF0j8XfKSHcLWk1g1/xHYFBYBFYkF1+4zgti8AtYSX758ArMZBcQkvp9awwRiMwuI S9x6Mp8J4hwBiSV7zjND2KISLx//YwWxRYFmbjhxmx0iriix82w72AnMApoS63fpQ4yxljj4 p40dwlaUmNL9kB1iraDEyZlPWCYwisxCsm0WQvcsJN2zkHTPQtK9gJF1FaNocWpxUm66kZFe alFmcnFxfp5eXmrJJkZgfBzc8ttgB+PL546HGAU4GJV4eFtDVKOEWBPLiitzDzFKcDArifCq BwKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MHZcSbad JrSrUShw7X+lZp636uHfEoM1nyalxUiKVVwIDGvp+6TkdTlz4uMTmjFvdIoCry43njpXYplU 8M6iZYs4XJ7oT6z7/+9M1J+A2VLtTz7uSTDWa2nX27zmk7ZP2ZlZDy7/nfntzzNHiWZ2pp0d 73eVRsv84f/OGSbTtOXujK3Ctt938CixFGckGmoxFxUnAgCORGVJiwIAAA== Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - text that can be removed X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 14:02:45 -0000 4oCmYW5kIHRoZSBmb2xsb3dpbmcgY2FuIGJlIHJlbW92ZWQsIGluIG15IG9waW5pb246DQoNCiAg ICAiTXVsdGlwbGV4aW5nIGNoYXJhY3RlcmlzdGljcyBvZiBTRFAgYXR0cmlidXRlcyBhcmUgZGVz Y3JpYmVkIGluDQogICAgIFtJLUQuaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzXS4gIFZh cmlvdXMgU0RQIGF0dHJpYnV0ZQ0KICAgICBtdWx0aXBsZXhpbmcgY2F0ZWdvcmllcyBhcmUgaW50 cm9kdWNlZCB0aGVyZS7igJ0NCg0KDQpJdCBpcyBlbm91Z2ggdG8gc2F5IHRoYXQgInRoZSBtdXgg Y2F0ZWdvcnkNCltJLUQuaWV0Zi1tbXVzaWMtc2RwLW11eC1hdHRyaWJ1dGVzXSBpcyB0aGlzIGFu ZCB0aGF0Ii4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpPbiAwNC8xMi8xNyAx NTo1OSwgIm1tdXNpYyBvbiBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmciDQo8bW11c2ljLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4NCndyb3RlOg0KDQo+SGksDQo+DQo+VGhlIGRyYWZ0IGFsc28gcmVwZWF0cyDigJxkYXRhIGNo YW5uZWwgd2l0aCBPZmZlci9BbnN3ZXLigJ0gbWFueSB0aW1lcy4gSQ0KPnRoaW5rIGl0IGlzIGVu b3VnaCB0byBzYXkgb25jZSB0aGF0IHRoZSBwcm9jZWR1cmVzIGFyZSBmb3IgbmVnb3RpYXRpbmcN Cj5kYXRhIGNoYW5uZWxzIHVzaW5nIG9mZmVyL2Fuc3dlci4gTm8gbmVlZCB0byBrZWVwIHJlcGVh dGluZyBpdOKApg0KPg0KPlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj5PbiAwNC8xMi8x NyAxNTo1NiwgIlJvbmkgRXZlbiIgPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4+ SGkgQ2hyaXN0ZXIsDQo+PlRoaXMgbG9va3MgdG8gbWUgbGlrZSByZWR1bmRhbnQgdGV4dC4NCj4+ Um9uaQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IENocmlz dGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPj4+ IFNlbnQ6INeZ15XXnSDXkSAwNCDXk9em157XkdeoIDIwMTcgMTU6NTENCj4+PiBUbzogUm9uaSBF dmVuOyBtbXVzaWNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW01NVVNJQ10gRlc6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC0NCj4+PiBzZHBuZWctMTQudHh0 IC0gZ2xhcmUgcXVlc3Rpb24NCj4+PiANCj4+PiBIaSwNCj4+PiANCj4+PiBTZWN0aW9uIHNheXM6 DQo+Pj4gDQo+Pj4gICJJZiBhIHBlZXIgcmVjZWl2ZXMgYW4gU0RQIG9mZmVyIGJlZm9yZSBzdGFy dGluZyB0byBzZW5kIGEgbmV3IFNEUA0KPj4+b2ZmZXIgIHdpdGgNCj4+PiBkYXRhIGNoYW5uZWxz IHRoYXQgYXJlIHRvIGJlIFNEUCBvZmZlci9hbnN3ZXIgbmVnb3RpYXRlZCwgb3IgIGxvc2VzIGFu DQo+Pj5TRFANCj4+PiBvZmZlciBnbGFyZSByZXNvbHV0aW9uIHByb2NlZHVyZSBpbiB0aGlzIGNh c2UsIGl0IE1VU1QgIHdhaXQgdW50aWwgdGhlDQo+Pj5vbmdvaW5nDQo+Pj4gU0RQIG9mZmVyL2Fu c3dlciBjb21wbGV0ZXMgYmVmb3JlIHJlc3VtaW5nIHRoZSAgU0RQIG9mZmVyL2Fuc3dlcg0KPj4+ IG5lZ290aWF0aW9uIHByb2NlZHVyZS4iDQo+Pj4gDQo+Pj4gDQo+Pj4gTm93LCBhc3N1bWluZyBJ IHVuZGVyc3RhbmQgdGhlIHRleHQgY29ycmVjdGx5LCBpdCBzaW1wbHkgcmVwZWF0cw0KPj4+Z2Vu ZXJpYyBPL0ENCj4+PiBnbGFyZSBwcm9jZWR1cmVzLg0KPj4+IA0KPj4+IE9yLCBpcyB0aGVyZSBz dXBwb3NlZCB0byBiZSBzb21ldGhpbmcgZGF0YSBjaGFubmVsIHNwZWNpZmljPw0KPj4+IA0KPj4+ IFJlZ2FyZHMsDQo+Pj4gDQo+Pj4gQ2hyaXN0ZXINCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+ PiANCj4+PiBPbiAwNC8xMi8xNyAwODowNywgIm1tdXNpYyBvbiBiZWhhbGYgb2YgUm9uaSBFdmVu Ig0KPj4+IDxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygcm9uaS5ldmVuQGh1 YXdlaS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+ID5IaSwNCj4+PiA+DQo+Pj4gPlRoaXMgbmV3IHJl dmlzaW9uIGFkZHJlc3NlcyBhbGwgbml0cyBwb2ludGVkIG91dCBieSB0aGUgaWRuaXRzIHRvb2wu DQo+Pj4gPkFzIGEgbmV3IGVkaXRvciwgSSBsb29rZWQgYXQgdGhlIE1NVVNJQyBtYWlsIGFyY2hp dmUgYW5kIGFzIGZhciBhcyBJDQo+Pj4gPmNhbiB0ZWxsIHRoZXJlIHdlcmUgbm8gb3BlbiBpc3N1 ZXMgZnJvbSB0aGUgbGlzdC4NCj4+PiA+DQo+Pj4gPlRoYW5rcw0KPj4+ID5Sb25pIEV2ZW4NCj4+ PiA+DQo+Pj4gPg0KPj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ID5Gcm9tOiBt bXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+Pj4g PmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4+ID5TZW50OiDXmdeV150g15AgMDMg15PXptee 15HXqCAyMDE3IDE4OjI4DQo+Pj4gPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+PiA+Q2M6 IG1tdXNpY0BpZXRmLm9yZw0KPj4+ID5TdWJqZWN0OiBbTU1VU0lDXSBJLUQgQWN0aW9uOg0KPj4+ ID5kcmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTE0LnR4dA0KPj4+ID4NCj4+ PiA+DQo+Pj4gPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cw0KPj4+ID5kaXJlY3Rvcmllcy4NCj4+PiA+VGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTXVsdGlwYXJ0eSBNdWx0aW1lZGlhIFNlc3Npb24gQ29udHJv bA0KPj4+ID5XRyBvZiB0aGUgSUVURi4NCj4+PiA+DQo+Pj4gPiAgICAgICAgVGl0bGUgICAgICAg ICAgIDogU0RQLWJhc2VkIERhdGEgQ2hhbm5lbCBOZWdvdGlhdGlvbg0KPj4+ID4gICAgICAgIEF1 dGhvcnMgICAgICAgICA6IEtlaXRoIERyYWdlDQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAg ICAgTWFyaWRpIFIuIE1ha2FyYWp1DQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgSnVl cmdlbiBTdG9ldHplci1CcmFkbGVyDQo+Pj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgUmlj aGFyZCBFanphaw0KPj4+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIEplcm9tZSBNYXJjb24N Cj4+PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBSb25pIEV2ZW4NCj4+PiA+CUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQudHh0DQo+ Pj4gPglQYWdlcyAgICAgICAgICAgOiA0MQ0KPj4+ID4JRGF0ZSAgICAgICAgICAgIDogMjAxNy0x Mi0wMw0KPj4+ID4NCj4+PiA+QWJzdHJhY3Q6DQo+Pj4gPiAgIFRoZSBSZWFsLVRpbWUgQ29tbXVu aWNhdGlvbiBpbiBXRUItYnJvd3NlcnMgKFJUQ1dlYikgd29ya2luZyBncm91cA0KPj4+IGlzDQo+ Pj4gPiAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3VwcG9ydCBkaXJlY3QgaW50 ZXJhY3RpdmUgcmljaA0KPj4+ID4gICBjb21tdW5pY2F0aW9ucyB1c2luZyBhdWRpbywgdmlkZW8s IGFuZCBkYXRhIGJldHdlZW4gdHdvIHBlZXJzJyB3ZWItDQo+Pj4gPiAgIGJyb3dzZXJzLiAgRm9y IHRoZSBzdXBwb3J0IG9mIGRhdGEgY29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYg0KPj4+d29ya2lu Zw0KPj4+ID4gICBncm91cCBoYXMgaW4gcGFydGljdWxhciBkZWZpbmVkIHRoZSBjb25jZXB0IG9m IGJpLWRpcmVjdGlvbmFsIGRhdGENCj4+PiA+ICAgY2hhbm5lbHMgb3ZlciBTQ1RQIChTdHJlYW0g Q29udHJvbCBUcmFuc21pc3Npb24gUHJvdG9jb2wpLCB3aGVyZQ0KPj4+ZWFjaA0KPj4+ID4gICBk YXRhIGNoYW5uZWwgbWlnaHQgYmUgdXNlZCB0byB0cmFuc3BvcnQgb3RoZXIgcHJvdG9jb2xzLCBj YWxsZWQNCj4+PiA+ICAgc3VicHJvdG9jb2xzLiAgRGF0YSBjaGFubmVsIHNldHVwIGNhbiBiZSBk b25lIHVzaW5nIGVpdGhlciB0aGUgaW4tDQo+Pj4gPiAgIGJhbmQgRGF0YSBDaGFubmVsIEVzdGFi bGlzaG1lbnQgUHJvdG9jb2wgKERDRVApIG9yIHVzaW5nIHNvbWUNCj4+Pm91dC1vZi0NCj4+PiA+ ICAgYmFuZCBub24tRENFUCBwcm90b2NvbC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGhvdyB0 aGUgU0RQDQo+Pj4oU2Vzc2lvbg0KPj4+ID4gICBEZXNjcmlwdGlvbiBQcm90b2NvbCkgb2ZmZXIv YW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2VkIHRvIGFjaGlldmUNCj4+PiA+ICAgc3VjaCBhbiBv dXQtb2YtYmFuZCBub24tRENFUCBuZWdvdGlhdGlvbi4gIEV2ZW4gdGhvdWdoIGRhdGENCj4+PmNo YW5uZWxzDQo+Pj4gPiAgIGFyZSBkZXNpZ25lZCBmb3IgUlRDV2ViIHVzZSBpbml0aWFsbHksIHRo ZXkgbWF5IGJlIHVzZWQgYnkgb3RoZXINCj4+PiA+ICAgcHJvdG9jb2xzIGxpa2UsIGJ1dCBub3Qg bGltaXRlZCB0bywgdGhlIENMVUUgcHJvdG9jb2wgKHdoaWNoIGlzDQo+Pj4gPiAgIGRlZmluZWQg YnkgdGhlIElFVEYgIkNvbnRyb0xsaW5nIG1VbHRpcGxlIHN0cmVhbXMgZm9yIHRFbGVwcmVzZW5j ZSINCj4+PiA+ICAgd29ya2luZyBncm91cCkuICBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRv IGJlIHVzZWQgd2hlcmV2ZXIgZGF0YQ0KPj4+ID4gICBjaGFubmVscyBhcmUgdXNlZC4NCj4+PiA+ DQo+Pj4gPg0KPj4+ID5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4+PiANCj4+Pj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLw0KPj4+ID4NCj4+PiA+VGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPj4+ID5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0xNA0K Pj4+IA0KPj4+Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkDQo+Pj4gPnBuZQ0KPj4+ID5nLTE0DQo+Pj4gPg0KPj4+ ID5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+Pj4g DQo+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2lj LWRhdGEtY2hhbm5lbC1zZHBuZWcNCj4+PiA+LTE0DQo+Pj4gPg0KPj4+ID4NCj4+PiA+UGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCj4+PiA+c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0DQo+Pj4gPnRvb2xzLmlldGYub3JnLg0KPj4+ID4NCj4+PiA+SW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPj4+ID5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+ID4NCj4+PiA+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiA+bW11c2ljIG1haWxp bmcgbGlzdA0KPj4+ID5tbXVzaWNAaWV0Zi5vcmcNCj4+PiA+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4+PiA+DQo+Pj4gPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gPm1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+ PiA+bW11c2ljQGlldGYub3JnDQo+Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+bW11c2ljIG1haWxpbmcgbGlzdA0KPm1tdXNpY0BpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== From nobody Mon Dec 4 06:03:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E115127444 for ; Mon, 4 Dec 2017 06:03:22 -0800 (PST) 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 XIlQVAdGvfDZ for ; Mon, 4 Dec 2017 06:03:20 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 71177127369 for ; Mon, 4 Dec 2017 06:03:20 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 533DDD629E355; Mon, 4 Dec 2017 14:03:17 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 14:03:18 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 22:02:47 +0800 From: Roni Even To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications Thread-Index: AQHTbQSColMyBnIAJ0208YZM8KMNHaMzNWUw Date: Mon, 4 Dec 2017 14:02:46 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8503FA@DGGEMM506-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 14:03:22 -0000 SGkgQ2hyaXN0ZXIsDQpUaGlzIHNlbnRlbmNlIGlzIHBhcnRpYWxseSBjb3JyZWN0LCBJIHdpbGwg Y2hhbmdlIGJhc2VkIG9uIHlvdXIgcHJvcG9zZWQgdGV4dCBidXQgbWVudGlvbiB0aGF0IE1TUlAg dXNhZ2UgaXMgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2lj LW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTA3IHdpdGggaW5mb3JtYXRpdmUgcmVmZXJlbmNlLg0K Um9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENocmlzdGVyIEhv bG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiDX mdeV153CoNeRIDA0INeT16bXnteR16ggMjAxNyAxNTozNA0KPiBUbzogUm9uaSBFdmVuOyBtbXVz aWNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtNTVVTSUNdIEZXOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtDQo+IHNkcG5lZy0xNC50eHQgLSBDb21tZW50IG9u IHN1YnByb3RvY29sIHNwZWNpZmljYXRpb25zDQo+IA0KPiBIaSwNCj4gDQo+IFNlY3Rpb24gMSBz YXlzOg0KPiANCj4gICAgIlByb2NlZHVyZXMgc3BlY2lmaWMgdG8gZWFjaCBzdWJwcm90b2NvbCBz dWNoIGFzIE1TUlAgYXJlIGRvY3VtZW50ZWQNCj4gZWxzZXdoZXJlLiINCj4gDQo+IA0KPiBJIHRo aW5rIHdlIHNob3VsZCBzYXkg4oCcd291bGQgaGF2ZSB0byBiZSBkb2N1bWVudGVkIGVsc2V3aGVy ZeKAnSwgYmVjYXVzZQ0KPiB3ZSBkb27igJl0IGtub3cgd2hldGhlciB0aGV5IHdpbGwgYmUuDQo+ IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4gT24gMDQvMTIvMTcg MDg6MDcsICJtbXVzaWMgb24gYmVoYWxmIG9mIFJvbmkgRXZlbiINCj4gPG1tdXNpYy1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiByb25pLmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0K PiA+SGksDQo+ID4NCj4gPlRoaXMgbmV3IHJldmlzaW9uIGFkZHJlc3NlcyBhbGwgbml0cyBwb2lu dGVkIG91dCBieSB0aGUgaWRuaXRzIHRvb2wuDQo+ID5BcyBhIG5ldyBlZGl0b3IsIEkgbG9va2Vk IGF0IHRoZSBNTVVTSUMgbWFpbCBhcmNoaXZlIGFuZCBhcyBmYXIgYXMgSQ0KPiA+Y2FuIHRlbGwg dGhlcmUgd2VyZSBubyBvcGVuIGlzc3VlcyBmcm9tIHRoZSBsaXN0Lg0KPiA+DQo+ID5UaGFua3MN Cj4gPlJvbmkgRXZlbg0KPiA+DQo+ID4NCj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID5Gcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+ID5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gPlNlbnQ6INeZ15XXnSDXkCAwMyDX k9em157XkdeoIDIwMTcgMTg6MjgNCj4gPlRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPkNj OiBtbXVzaWNAaWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFtNTVVTSUNdIEktRCBBY3Rpb246DQo+ID5k cmFmdC1pZXRmLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTE0LnR4dA0KPiA+DQo+ID4NCj4g PkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVy bmV0LURyYWZ0cw0KPiA+ZGlyZWN0b3JpZXMuDQo+ID5UaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBNdWx0aXBhcnR5IE11bHRpbWVkaWEgU2Vzc2lvbiBDb250cm9sDQo+ID5XRyBvZiB0 aGUgSUVURi4NCj4gPg0KPiA+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTRFAtYmFzZWQgRGF0 YSBDaGFubmVsIE5lZ290aWF0aW9uDQo+ID4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IEtlaXRo IERyYWdlDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmlkaSBSLiBNYWthcmFqdQ0K PiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBKdWVyZ2VuIFN0b2V0emVyLUJyYWRsZXINCj4g PiAgICAgICAgICAgICAgICAgICAgICAgICAgUmljaGFyZCBFanphaw0KPiA+ICAgICAgICAgICAg ICAgICAgICAgICAgICBKZXJvbWUgTWFyY29uDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg IFJvbmkgRXZlbg0KPiA+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtbW11c2ljLWRhdGEt Y2hhbm5lbC1zZHBuZWctMTQudHh0DQo+ID4JUGFnZXMgICAgICAgICAgIDogNDENCj4gPglEYXRl ICAgICAgICAgICAgOiAyMDE3LTEyLTAzDQo+ID4NCj4gPkFic3RyYWN0Og0KPiA+ICAgVGhlIFJl YWwtVGltZSBDb21tdW5pY2F0aW9uIGluIFdFQi1icm93c2VycyAoUlRDV2ViKSB3b3JraW5nIGdy b3VwDQo+IGlzDQo+ID4gICBjaGFyZ2VkIHRvIHByb3ZpZGUgcHJvdG9jb2xzIHRvIHN1cHBvcnQg ZGlyZWN0IGludGVyYWN0aXZlIHJpY2gNCj4gPiAgIGNvbW11bmljYXRpb25zIHVzaW5nIGF1ZGlv LCB2aWRlbywgYW5kIGRhdGEgYmV0d2VlbiB0d28gcGVlcnMnIHdlYi0NCj4gPiAgIGJyb3dzZXJz LiAgRm9yIHRoZSBzdXBwb3J0IG9mIGRhdGEgY29tbXVuaWNhdGlvbiwgdGhlIFJUQ1dlYiB3b3Jr aW5nDQo+ID4gICBncm91cCBoYXMgaW4gcGFydGljdWxhciBkZWZpbmVkIHRoZSBjb25jZXB0IG9m IGJpLWRpcmVjdGlvbmFsIGRhdGENCj4gPiAgIGNoYW5uZWxzIG92ZXIgU0NUUCAoU3RyZWFtIENv bnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sKSwgd2hlcmUgZWFjaA0KPiA+ICAgZGF0YSBjaGFu bmVsIG1pZ2h0IGJlIHVzZWQgdG8gdHJhbnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkDQo+ ID4gICBzdWJwcm90b2NvbHMuICBEYXRhIGNoYW5uZWwgc2V0dXAgY2FuIGJlIGRvbmUgdXNpbmcg ZWl0aGVyIHRoZSBpbi0NCj4gPiAgIGJhbmQgRGF0YSBDaGFubmVsIEVzdGFibGlzaG1lbnQgUHJv dG9jb2wgKERDRVApIG9yIHVzaW5nIHNvbWUgb3V0LW9mLQ0KPiA+ICAgYmFuZCBub24tRENFUCBw cm90b2NvbC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGhvdyB0aGUgU0RQIChTZXNzaW9uDQo+ ID4gICBEZXNjcmlwdGlvbiBQcm90b2NvbCkgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1 c2VkIHRvIGFjaGlldmUNCj4gPiAgIHN1Y2ggYW4gb3V0LW9mLWJhbmQgbm9uLURDRVAgbmVnb3Rp YXRpb24uICBFdmVuIHRob3VnaCBkYXRhIGNoYW5uZWxzDQo+ID4gICBhcmUgZGVzaWduZWQgZm9y IFJUQ1dlYiB1c2UgaW5pdGlhbGx5LCB0aGV5IG1heSBiZSB1c2VkIGJ5IG90aGVyDQo+ID4gICBw cm90b2NvbHMgbGlrZSwgYnV0IG5vdCBsaW1pdGVkIHRvLCB0aGUgQ0xVRSBwcm90b2NvbCAod2hp Y2ggaXMNCj4gPiAgIGRlZmluZWQgYnkgdGhlIElFVEYgIkNvbnRyb0xsaW5nIG1VbHRpcGxlIHN0 cmVhbXMgZm9yIHRFbGVwcmVzZW5jZSINCj4gPiAgIHdvcmtpbmcgZ3JvdXApLiAgVGhpcyBkb2N1 bWVudCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIHdoZXJldmVyIGRhdGENCj4gPiAgIGNoYW5uZWxz IGFyZSB1c2VkLg0KPiA+DQo+ID4NCj4gPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdl IGZvciB0aGlzIGRyYWZ0IGlzOg0KPiA+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy8NCj4gPg0KPiA+VGhlcmUgYXJl IGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiA+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMTQNCj4g Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt ZGF0YS1jaGFubmVsLXNkDQo+ID5wbmUNCj4gPmctMTQNCj4gPg0KPiA+QSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiA+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcNCj4g Pi0xNA0KPiA+DQo+ID4NCj4gPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID5zdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPnRvb2xzLmlldGYub3Jn Lg0KPiA+DQo+ID5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQo+ID5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+DQo+ ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+bW11 c2ljIG1haWxpbmcgbGlzdA0KPiA+bW11c2ljQGlldGYub3JnDQo+ID5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPiA+DQo+ID5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+bW11c2ljIG1haWxpbmcgbGlzdA0KPiA+ bW11c2ljQGlldGYub3JnDQo+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21tdXNpYw0KDQo= From nobody Tue Dec 5 01:35:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2403C126B7F for ; Tue, 5 Dec 2017 01:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 Xpvb13MKQ4Xv for ; Tue, 5 Dec 2017 01:35:05 -0800 (PST) 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 9E253124205 for ; Tue, 5 Dec 2017 01:35:04 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-26-5a266846da1a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.11.13994.648662A5; Tue, 5 Dec 2017 10:35:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Tue, 5 Dec 2017 10:35:01 +0100 From: Christer Holmberg To: Suhas Nandakumar CC: Bo Burman , Ben Campbell , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , IETF MMUSIC WG Thread-Topic: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? Thread-Index: AdNqwWHfmFxQvqH0QuKOUUj6GQGJcAAPBWYv///4KICABXjPAA== Date: Tue, 5 Dec 2017 09:35:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7sa5bhlqUwYbzchbzO0+zW7y5aGcx dfljFoudczuYHVg8ds66y+6xZMlPJo9ZO5+weHy5/JktgCWKyyYlNSezLLVI3y6BK2Pa7I3M Bc9EKg42NDA3MHYIdjFyckgImEj8eXaeCcQWEjjMKHFjvkkXIxeQvZhR4vv5xYxdjBwcbAIW Et3/tEFqRAS0JFYvnssEUsMscJtRYsOO3cwgCWGBIInlP5awQRQFS6w9cZYFwnaSOPfvEDuI zSKgIrGwaSJYDa+AtcS/398YIZbdZJS4svkTI0iCUyBQYtbumWBFjAJiEt9PrQG7jllAXOLW k/lMEFcLSCzZc54ZwhaVePn4HyuILSqgJ7HhxG12iLiixMdX+xghevUkbkydwgZhW0ssOr0f aqa2xLKFr5khDhKUODnzCcsERvFZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSsl1qU mVxcnJ+nl5dasokRGJcHt/zW3cG4+rXjIUYBDkYlHt7QcLUoIdbEsuLK3EOMEhzMSiK8T+ar RgnxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpgZF/oo3NP 6LXwnO2LFnF/4iwXsF0jwznpEv+N5nfOPht8m/4zzAkv6sk8s8h7F8NbdddHu44+W/WFafNU o4XThZ/d9G//USF4fOmsk0rN55NS/zNf4/Cf9+X3LwXVq6s+PnR/K3N/4b+TEvadL1YeP3t1 Xv4ZywtTGLwrQs5zc/MZXT3WF5D15a4SS3FGoqEWc1FxIgDmWshzxwIAAA== Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 09:35:07 -0000 Hi, >> As I believe I have said before, we need to separate two things: >> >> 1) Whether the attribute value needs to be applied to all m- sections >> 2) Whether the attribute needs to be explicitly assigned/encoded to all >>m- sections >> >> In my opinion, draft-mux-attributes shall only cover 1). >> >> 2) is BUNDLE specific. >> >> I do agree that it is a little difficult to determine whether =B3repeat= =B2 >>means 1) or 2). > > Above was my recollection too. I am not sure if we need to change Mux >attributes. Since Mux attributes needs to be read along with the Bundle >spec. > The Bundle spec may define additional constraints or usage patterns. I guess a note could have been useful, saying something like: =B3NOTE: Eventhough IDENTICAL attributes must be repeated across all media descriptions under multiplexing, they might not always be explicitly encoded across all media descriptions. BUNDLE defines rules for when attributes and their values are implicitly applied to media description.=B2 Regards. Christer Sent from my iPhone On 1 Dec 2017, at 18.30, Bo Burman wrote: WG, =20 A while ago (in this thread: https://mailarchive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U ) , Taylor concluded that the -sdp-mux-attributes draft, which is currently in RFC Editor=B9s queue, needs to be updated to align with current BUNDLE=20 draft. =20 The -sdp-mux-attributes draft unconditionally requires (in section 4.3) that category IDENTICAL attributes and their values =B3MUST be repeated across all the media descriptions under multiplexing=B2. =20 BUNDLE (section 8.1) requires such repetition for IDENTICAL and TRANSPORT only when a BUNDLE group is initially negotiated. When the BUNDLE addresses have been selected, for all =B3m=3D=B2 sections but the one carry= ing the BUNDLE-tag, BUNDLE requires the opposite; MUST NOT include SDP attributes with IDENTICAL or TRANSPORT category. =20 Does the WG agree that -sdp-mux-attributes has to be changed to align with what is now described by BUNDLE? =20 Unless anyone objects before EOB Dec 15, we will proceed with such change to -sdp-mux-attributes. =20 Thanks, =20 Bo MMUSIC co-chair =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Dec 5 03:55:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3403D129427 for ; Tue, 5 Dec 2017 03:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 n6N6ahjmruab for ; Tue, 5 Dec 2017 03:55:24 -0800 (PST) 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 DADCF12943C for ; Tue, 5 Dec 2017 03:55:23 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-ef-5a2689299eaf Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.EA.13624.929862A5; Tue, 5 Dec 2017 12:55:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Tue, 5 Dec 2017 12:55:20 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt Thread-Index: AQHTLXMP48FsKk3ChkCY2+afIZsiz6LI3fUAgACwtID//7EEIIAAs6WAgAA+fYCAOGvZgIAAF2yA///41QCAACC4AIAIFtAAgAAfdACAKjNOAA== Date: Tue, 5 Dec 2017 11:55:20 +0000 Message-ID: References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> 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.7.170905 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7sa5mp1qUwbLlRhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxb+1hpoJ2loqe3RfYGhiXMXcxcnJICJhI 9F5uYeli5OIQEjjMKLF810F2CGcxo8SxqXuAqjg42AQsJLr/aYM0iAj4Sjx7fJsNxBYWCJM4 tfkYE0Q8XGL2u4OsEHadxLs7WxlBbBYBFYkpEy6ygNi8AtYS3+/1skLMv8oqsWjxSrArOAUc JO69fwo2lFFATOL7qTVgQ5kFxCVuPZnPBHGpgMSSPeehrhaVePn4H9gyUQE9iQ0nbrNDxBUl 2p82MEL06kgs2P2JDcK2lrh69i6UrS2xbOFrZoiDBCVOznzCMoFRbBaSdbOQtM9C0j4LSfss JO0LGFlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG1sEtv612MB587niIUYCDUYmHd12x WpQQa2JZcWXuIUYJDmYlEd6ZrUAh3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1Kz U1MLUotgskwcnFINjIlhwSvVqo5d/ZFXzjJrv0X06wT9U4WfhSx7Epr+CloLhfa0H3Fe8NbG 5efVLYZ3StTnb0uuOvbv8pTd7o+TLkdaxsjPZVvVoqLEy2Rr/H4ie+4rs94n3+yer05gZ3Hg NhSY/kyOr9TE65CXnKeyWUvIqfRH4efkmvs8qj2alk97nXl0r8EkJZbijERDLeai4kQAz97t RagCAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 11:55:26 -0000 Any news on this? Regards, Christer On 08/11/17 19:37, "mmusic on behalf of Paul Kyzivat" wrote: >On 11/8/17 10:45 AM, Andy Hutton wrote: > >> Please can the relevant chairs and AD's get together and tell us how to >>proceed. > >Yes, this is the proper way to sort this out. > > Thanks, > Paul > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Dec 6 13:43:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7A51270AC for ; Wed, 6 Dec 2017 13:43:26 -0800 (PST) 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 w1jajrEV5bcy for ; Wed, 6 Dec 2017 13:43:24 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4B71267BB for ; Wed, 6 Dec 2017 13:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=834; q=dns/txt; s=iport; t=1512596604; x=1513806204; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=gZPkjXOLc6VNJaqRZJyjEml0xVIibFNDJTZdi22VQxc=; b=Xn9NNc9E24jpHzN/2bR8UmUCoVL6M8o2/YefGR6IkD9Rh/QNK3V3Kkzb btADLQhjTePT4JznPOAIaH9td0pSWTt27HgOXtpsx1arGnl/biaE6gGd/ 8r4qJFB/4vLMlp7h9BuVcdtJeRQ9pI+MTq803kXC2HbRXBRFB1fu8DOKJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQDfYyha/4cNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPWZxJ4QCiiCOfYFXJpcFghUKGAuESU8ChVQ/GAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQQBASEVNhsLGAICJgICJzAGAQwGAgEBFol8DRCpEoIniloBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEbBYEPhE2BVoISC4J3iDaCYwWTHI9hlRmCFoYRg2WHT5Z?= =?us-ascii?q?TgTofOYFOTCMVOoIphBZdIzeJbQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208";a="40713635" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 21:43:24 +0000 Received: from [10.118.10.18] (rtp-fandreas-2-881-ap.cisco.com [10.118.10.18]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB6LhNPE015922; Wed, 6 Dec 2017 21:43:23 GMT To: Christer Holmberg , Paul Kyzivat , "mmusic@ietf.org" , Ben Campbell References: <150540502703.12603.17962279219166496882@ietfa.amsl.com> <2833E3F5-9646-40CD-995E-8A7F61DA77CA@cisco.com> <7594FB04B1934943A5C02806D1A2204B56302CF2@ESESSMB109.ericsson.se> From: Flemming Andreasen Message-ID: <4c2b8530-5667-9f83-1f51-8c868b9c025e@cisco.com> Date: Wed, 6 Dec 2017 16:43:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 21:43:26 -0000 Hi Christer We are still discussing the best way forward. Thanks -- Flemming On 12/5/17 6:55 AM, Christer Holmberg wrote: > Any news on this? > > Regards, > > Christer > > On 08/11/17 19:37, "mmusic on behalf of Paul Kyzivat" > wrote: > >> On 11/8/17 10:45 AM, Andy Hutton wrote: >> >>> Please can the relevant chairs and AD's get together and tell us how to >>> proceed. >> Yes, this is the proper way to sort this out. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Wed Dec 6 15:24:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE7612871F; Wed, 6 Dec 2017 15:24:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf-MO50BaXT9; Wed, 6 Dec 2017 15:24:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241521205F0; Wed, 6 Dec 2017 15:24:14 -0800 (PST) Received: from [10.0.1.92] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB6NOCPb065872 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Dec 2017 17:24:13 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.92] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_DD91B830-44B5-4336-B499-6602CBE80E10"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> Date: Wed, 6 Dec 2017 17:24:11 -0600 To: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 23:24:20 -0000 --Apple-Mail=_DD91B830-44B5-4336-B499-6602CBE80E10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, These are my AD Evaluation comments for = draft-ietf-mmusic-trickle-ice-sip-11. I have quite a few comments, and = would like to resolve at least the substantive comments prior to IETF = Last Call. Thanks! Ben. *** Substantive: - The draft needs a "deployment considerations" section relating to the presence of middleboxes that may not be aware of trickle ice. I = recognize that b2bUAs may simply be endpoints that don't do trickle, but I wonder = about monitoring devices, etc. Even if the answer is "there is no impact", = some substantiating text would be helpful. -3.2: There seem to be some inconsistencies on how the text talks about = the architectural model. For example, section 3.2 separates the "ICE agent" = from the "offer/answer" module, but 3.3 talks about a "trickle ICE agent" = doing offer/answer. (I suspect this is a terminilogy issue where "trickle ICE agent" as the user agent and "ICE agent" as a software module are too = easily confused.) 4.1.1: What is the motivation for requiring "audio" in the M-line when = one does not know any candidates in advance? What if the intended media is = not audio? I don't understand why the lack of advance candidates would = change that. (Maybe this is an artifact of the pseudo-M-lines from the INFO = bodies?) -4.1.1, 2nd to last paragraph : "... it still MUST include the = "a=3Drtcp-mux" and/or "a=3Drctp-mux-only" attribute in the initial Offer." IIUC, that's an already existing requirement from the referenced spec. = If so, please do not use 2118/8174 keywords to describe it here, unless in the = form of directly quoted text. -4.2.2, RFC editor note: This askes the RFC Editor to do research. I don't think that's a = reasonable expectation. They may notice that sort of thing anyway, but the authors should plan to recheck references during AUTH48. (This comment applies = to several other similar RFC editor notes.) -4.2.2, third paragraph after Fig 4: "or when new candidates have not = been learned since then) and/or they MAY also deliver newly learned = candidates (if available). The Offerer MAY include an end-of-candidates attribute in = case candidate discovery has ended in the mean time." Are those MAYs really correct when the conditions are true? E.g. if you = have newly learned candidates, there's only a MAY requirement to add them? Likewise, if discovery has ended, there's only a MAY requirement to add = the end-of-candidates attribute? -4.2.2, 4th paragraph after fig 4: " and MAY begin trickling" that seems like a statement of fact rather than a normative offering-of-permission. -4.2.2, last paragraph: "... Answerer MUST repeat exactly the same = Answer..." Is that an external requirement, or a new normative one? -4.2.3, first paragraph: "Trickle ICE Agents MAY therefore respond to an INVITE request with provisional responses without an SDP answer" That's only if the offerer indicated support for trickle ICE, right? -4.3: It seems like the use of SDP syntax in the INFO messages creates = quite a bit of complexity due to the use of SDP in (even more) ways not contemplated by it's design. Did the WG discuss the possibility of using = a designed-for-purpose syntax in the INFO bodies? (This is just my = curiosity; I don't expect to make that sort of fundamental change this late in the process.) -4.3: Discussion of "pseudo-M-lines": A complete separation of the trickle-ice from offer/answer seems = unlikely to me, since both must send and receive SIP messages in the same dialog. Is = it that much harder to remember the media type than it is to remember = dialog state? More to the point, are there known implementations that require = this? -4.3, last bullet: "The fmt SHOULD appear only once..." Why not MUST? Would it every be reasonable to include more than one? -4.3, paragraph starting with : "Note that [I-D.ietf-ice-trickle] = requires that when candidates are trickled, each candidate MUST be delivered..." Don't use 2119/8174 keywords to describe external requrements, except in directly quoted text. -4.3: 2nd paragraph prior to Fig 9: Are the discussions about removing previously exchanged candidates still = in process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to requirements that are too vague to state in normative terms. - figure 9 (and other figures including INFO bodies): Please include a = real content-length value. -5, first paragraph: Please don't use normative terms to describe = external requirements. -5.1, first paragraph: I'm confused by the reference to WebRTC clients. These are not assumed = to use SIP at all. How are they relevant examples? -5.2: IIUC, using the GRUU means the INVITE can go only to that = particular device. This seems to circumvent the recipient's ability to use forking = for their own purposes. That's not a showstopper, but it deserves mention. -5.3: The comparisons to XMPP don't seem to add much, and seems like editorializing. (Also in 3.1). The fact that XMPP has more advanced = discovery mechanisms is not particularly relevant unless you want to use those as = an example of how to solve the problems in SIP. -6, 6th paragraph: "The Trickle Answerer MUST follow the guidance on the usage of the "a=3Drtcp" attribute as given in [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]" External requirement... -8.2, first paragraph: External requirement. -9: Please comment about whether this media type is reasonable to use = for other SDP related applications? I gather the answer is "no" given that = it's called "trickle-ice-sdpfrag". -9.2, first paragraph: "A sender SHOULD stick to lower- case for such grammars, but a receiver SHOULD treat them case- insensitive." Why is the second SHOULD not a MUST? - 10.7: The requirement to include the payload only applies to INFO = requests for this particular package, right? That is, not necessarily "all INFO requests". - 10.9: You used the need to pool candidates as a argument against using update. Doesn=E2=80=99t this create the same requirement? Also, do you = think it reasonable that an implementation might not be concerned about this? -11.2: Please use the IESG (iesg@ietf.org) for the change control = authority. The mmusic mailing list could be closed some day. -12: The registered media type refers to this document for security considerations, but I don't see any considerations specific to it here. *** Editorial and Nits: - General: IDNits shows some outdated references. Please fix before = final published version. - section 1, paragraph 1: The sentence structure for listing the 3 phases is odd. The first two = are in a comma separated list, but the third is in a separate sentence. I = suggest breaking all 3 into separate sentences, with the needed connecting = words. Missing "and" before "the second phase" I think the word "latency" would be better expressed as "delay" or = "setup delay", etc. Too many readers are going to think of "latency" in terms = of network latency (i.e packet delivery). - 1, paragraph 2: "simultaneously" I think the operating idea is that they can happen in "parallel" or "be interleaved". -2: Please use the new boilerplate in RFC 8174, unless you specifically = want lower case versions of the RFC 2119 keywords to be interpreted in their = 2119 sense. -2, 2nd paragraph: "This specification makes use of all terminology..." I suggest removing "all". -3.2, first paragraph: I think "the exception of the actual INFO messages," is too big of an exception for this paragraph to be meaningul. For example, this is a = huge change for middleboxes that pay attention to the SDP (e.g. SBCs); I = think saying that things "would look the same" is an overstatement. -4, item 5: "Note that in case of forking multiple early dialogs will = exist." s/will/may (or "might" if you want to avoid "may") -4.1.1, 2nd paragraph: "...before knowing any candidate of one or more = media descriptions..." s/of/for -4.1.1, last paragraph: This seems redundant to the similar statement in section 4, item 2. -4.1.2, last paragraph: s/neither/none (unless you expect there to be exactly 2 trickled = candidates.) -4.2.1, title (and several related titles): I think that usage of "asserting" will trip up some users. Consider "establishing" instead. - Figure 3: This figure needs a comment about the meaning of "+SRFLX = Cand.", similar to those for later figures. -4.2.3, first paragraph: s/possibility/ability -4.2.3, paragraph after Fig 6: "When sending the Answer, the agent MUST repeat all currently known and used candidates, if any, and MAY include = all newly gathered candidates since the last INFO request was sent. If that Answer was sent in a unreliable provisional response, the Answerers MUST repeat exactly the same Answer in the 200 OK response to the INVITE = request in order to fulfill the corresponding requirements in [RFC3264]." This seems self contradictory, but could be fixed with some connecting language like "However", or "An exception..." -4.2.4, title: Spell out 3PCC on first mention. Also, an informational citation would be helpful. -4.3, 3 paragraphs prior to Fig 9: "is an indication of the peer agent = that it will not send any further candidates" s/of/from -4.3, last paragraph before Fig 9: Please refer to the figure by number rather than relative position. -5.2, title: Expand "GRUU" on first mention. First paragraph: s/"SIP US"/"SIP UA" "... require SIP support" - Should that say "trickle ICE support"? 2nd paragraph: Please define "targeted trickling" -7, 4th paragraph: I don't understand the meaning of "latest on..." in = this context. -7, paragraph between "offer" and "INFO" examples: "Once the dialog is established as described in section Section 4.2 the Answerer sends the following INFO request." The word "section" is repeated. -9.2, first paragraph: "It specifies the subset of existing SDP = attributes, that are needed..." s/are/is (the phrase constrains "subset", not "attributes"). "The grammar uses the indicator for case-sensitivity %s is defined in [RFC7405], but also imports grammars for other SDP attributes that = precede the production of that RFC. " I can't parse that sentence. - 10.1, 2nd paragraph: s/introduces/"would introduce" 3rd paragraph: s/"one exchange"/"one active exchange" - 11.2: Weird line spacing. "Applications which use this Media Type: The listed applications only use this media type when using trickle-ice, right? Would it make sense to just include "trickle-ice"? --Apple-Mail=_DD91B830-44B5-4336-B499-6602CBE80E10 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAloofBsACgkQgFZKbJXz 1A3RTA//bAcl2qjnvoIk93La/IrS2rs6UbYkWk3wJ7Wa1eJiCjMquP0LLyAYjBON rOmdYZbbaPu9NFaIrp+ohF57WyqZnQf3hAJWZWwgn0mOBLTZtVrkDllqZ4ML8UxI zXab6J6u1YL/SjiFxiXhmofeNbSkXZjfUrWFjGjh0YVuy1RmnLwHfSfAt3PyzJ0z R7pMBLFHPrYBeTv7R/5xp0KuH31re+Ss2tOu7lfsLJ01HFwxtv9CZTVFrg3/Qgh9 tYfCnXd8J37uM2Tv9/LRa/lDy8DGBmF9GKsHfrJEl4+0ws1+v2HZkrLZHSuYd+L6 Dynxz5/7IkniQGvg6HB5bzuJYK7J10tz7SA5IaWD++al/OntyYFpC9RPKz/xB+rd 0u/hIlVEME/c32zbHGjRwCQpTBBzEj7uiVdNqIlU74Bgnegd0tZGQJ8I1I3tZvP3 Pag5lzfufA19M+izH/mG8OvprwdyeESkR41Nw940cuRBAFy41B/Y8zSlJs0sDtjj 0TIjPApc28pHJhlxFhd0DNnt3vlpeb2Rz8AflTAbKAi7p9K373wWFHNvyl7dwa3r zUm7juzD2oQd/9RLodtwY5AlL2rmeLYAqpg0SzCp0X9ua20wInWF5W91DNy6ObVp M1wrd/mB1TDUu7+G/TYHBaLmJQ3fYpL7jKncydUEsAuk5fMAE/w= =Z1TD -----END PGP SIGNATURE----- --Apple-Mail=_DD91B830-44B5-4336-B499-6602CBE80E10-- From nobody Thu Dec 7 08:58:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15916129483 for ; Thu, 7 Dec 2017 08:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_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 FAaPKR_fFUin for ; Thu, 7 Dec 2017 08:58:24 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609851289B5 for ; Thu, 7 Dec 2017 08:58:24 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id d16so15905812itj.1 for ; Thu, 07 Dec 2017 08:58:24 -0800 (PST) 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; bh=FZZEinEhQ0IUlaFdtVsaL7G5yWeWWIRFkRLhpVpOAS8=; b=DXdZ13b0PZE4exIVAk+2CZIKTogpxJXZFanPz99bBRcd/N7qeTbTxEFR7/s7hRow8x 2m4Eaoxp183+n8HDmNPxWCrTJ88crF9461sTAlaKkbLqx0LbNUJ+cuY46xAwV/eyGbKl sDESQkz/amljPg6kLNqbPTZgLwul7dgk3tnQM= 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; bh=FZZEinEhQ0IUlaFdtVsaL7G5yWeWWIRFkRLhpVpOAS8=; b=mqQXT+mHpQ32alsXFLoWgwMypYTR1ybwedQQXYbkSt+CLK20RnkZCQ3xG28DXsKni7 i4lryvubqo1PG2U0OehpDNzjZYc1YOfVCF9zSNR7O91X1hbKyrJ1vWxv3+l8I2roSy+v 5oAloluW1HT2coUq3XB7ZN5UMtfpQ0M138DlPPLyZTGOn69isDgMUqbLzfB5n+306wl8 VYpvZyUrxbddbEhQ74GyHOAmMujh0QX8cpTgUMbHiX/M5xBJkGjvElEAzFZiPYTbQojN +283jz2JcJSoPTyLZejeOwzdhucTKOfcYi+7Mh1T+SxYmuRDdv/zChZlInmv6qaq6WB4 OyKQ== X-Gm-Message-State: AJaThX48kJ8NrRqJPFn+XQiPVZnvp4wwUZCDT5TeWxk2X8v6j5YED296 llxLJkpulYJYpj7keA/6vGB3AA== X-Google-Smtp-Source: AGs4zMa/ij3Mi6b92E17881nVhCqtf2pra2OQUozDWs+4szWa4SZxLFPQOUhzHnW9+xtFg0HDM2AhA== X-Received: by 10.107.174.222 with SMTP id n91mr37194563ioo.43.1512665903618; Thu, 07 Dec 2017 08:58:23 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id p68sm2892618itc.26.2017.12.07.08.58.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 08:58:22 -0800 (PST) To: Ben Campbell , draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> From: Peter Saint-Andre Message-ID: Date: Thu, 7 Dec 2017 09:58:08 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JVXA4lQncnPdLnnGV6tqRPRiAsKLrSD5G" Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 16:58:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JVXA4lQncnPdLnnGV6tqRPRiAsKLrSD5G Content-Type: multipart/mixed; boundary="JW009I6koSl0WfoMJIaUjutb3HIk9b9Ok"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org Message-ID: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> In-Reply-To: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> --JW009I6koSl0WfoMJIaUjutb3HIk9b9Ok Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ben, thanks for the review; comments inline. On 12/6/17 4:24 PM, Ben Campbell wrote: > *** Substantive: >=20 > - The draft needs a "deployment considerations" section relating to the= > presence of middleboxes that may not be aware of trickle ice. I recogni= ze > that b2bUAs may simply be endpoints that don't do trickle, but I wonder= about > monitoring devices, etc. Even if the answer is "there is no impact", so= me > substantiating text would be helpful. Do you think that this concern is SIP-specific or does it need to go in draft-ietf-ice-trickle? > -4.2.2, 4th paragraph after fig 4: " and MAY begin trickling" > that seems like a statement of fact rather than a normative > offering-of-permission. s/MAY/can/ > -5.3: The comparisons to XMPP don't seem to add much, and seems like > editorializing. (Also in 3.1). The fact that XMPP has more advanced dis= covery > mechanisms is not particularly relevant unless you want to use those as= an > example of how to solve the problems in SIP. Agreed. Peter --JW009I6koSl0WfoMJIaUjutb3HIk9b9Ok-- --JVXA4lQncnPdLnnGV6tqRPRiAsKLrSD5G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlopcyEACgkQZWGMGH9o FKkhGA/+JB7GXbvlSbvH7EncggzRAnhVfQvZW2xNpo8pV3ide91v1WLWnZmPGZBv 5YyogSO9aPOpRkFRV+JAF1T87+ZB4+NqrWBECDF9mNpKMmAT6DAEwNZ8ajCDoHQT 9i3GkQ5JfwypLjD4cY7fXYdlnZU3XYsJ/n15XjenT1aVSbSu290WbsgdZy+dSGd0 /H41tWB/pKVE1AQ3H2IPP89mZCHBAx3w3goOhC3C4jZkV0M4kI7vDV44iKCXUAM2 GDtvOptQmAhhCWss0Wz6aJM4FQSaHafQFQQN61uhjKCIOLVz1LcPGTjM5OT9/yfj PpfvZ3HNmd4/KfiPzQnUmF9QVCGqFm+0n1p6HQB5HmhAWLn6doeE2i0hDwvi9bIL NZj9iz9/4FkqxqVecjTFJ4J835mjw9kuAOTnHJ+lyFy5Dzbm2YE7xy666Sh5gRzL jf3J1gLJEcixsrguFxytHIkqxN0LX2mB48TWIqvkmugOcccT5rdAwYnw8NmziHYW yxLzSmJWR+NlSz/4yCAUXixPT0K+6Bpm1ukI2pfyPpnlXFm1B6KgTE6pvtJLRjt0 1HOW8plYWEVKK6UaEjEcfk8HySG2xa35Vw8ecEPELQttROxM8MThi3hS9WLnZCi5 pqPAchuIz9cQDKtEBtKtHpZJ6lKuzODRSDjJWCe2QYfTWTwg+2M= =J0D7 -----END PGP SIGNATURE----- --JVXA4lQncnPdLnnGV6tqRPRiAsKLrSD5G-- From nobody Thu Dec 7 09:40:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64129128AB0 for ; Thu, 7 Dec 2017 09:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UwL0h08P_EaW for ; Thu, 7 Dec 2017 09:40:12 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id BCC0F127369 for ; Thu, 7 Dec 2017 09:40:11 -0800 (PST) X-AuditID: 12074411-f95ff70000007f0a-e9-5a297cf8ed54 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id FE.2A.32522.8FC792A5; Thu, 7 Dec 2017 12:40:09 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vB7He7QW009748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 7 Dec 2017 12:40:08 -0500 To: mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> From: Paul Kyzivat Message-ID: Date: Thu, 7 Dec 2017 12:40:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixO6iqPuzRjPK4M1rXoupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr48o6w4IlnBX/3m5ga2A8zt7FyMkhIWAi8eH1ZLYuRi4OIYEd TBIrHm9gBUkICXxjkviyjRfEFhbwlvgHVsTJISIgLDHj7V82iBo7iTub9zOC2GwCWhJzDv1n AbF5BewlTtw4B7aARUBF4m/7GTBbVCBNYs+FDqgaQYmTM5+A2ZxA9U/fPgerYRYwk5i3+SEz hC0ucevJfCYIW15i+9s5zBMY+WchaZ+FpGUWkpZZSFoWMLKsYpRLzCnN1c1NzMwpTk3WLU5O zMtLLdI11cvNLNFLTSndxAgJScEdjDNOyh1iFOBgVOLhZXDQjBJiTSwrrsw9xCjJwaQkyuvn BxTiS8pPqcxILM6ILyrNSS0+xCjBwawkwttdBpTjTUmsrEotyodJSXOwKInz8i1R9xMSSE8s Sc1OTS1ILYLJynBwKEnw/qgGahQsSk1PrUjLzClBSDNxcIIM5wEafgukhre4IDG3ODMdIn+K 0Zijp+fGHyaOZzNfNzALseTl56VKifOaAhODkABIaUZpHtw0WFp5xSgO9Jwwbw5IFQ8wJcHN ewW0igloVcwCdZBVJYkIKakGxmaVPg/hNTLZl1bY3tg/I3NiwxkNm86fHmvS+5oX/7/TofuK r3HaReWph24tF+Zbs6spTl1Bf5tia6LFj697fQrfmbX6TrDgUW3ao1M480z8h84XgfrtdvWV 3FkCas81HvSqvgqZe0Ah4frzqXu7t3IdS36Y8yzDcIXvHJuPD0L92JeK3bq8VYmlOCPRUIu5 qDgRALy4S9AGAwAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 17:40:14 -0000 On 12/6/17 6:24 PM, Ben Campbell wrote: > -9: Please comment about whether this media type is reasonable to use for > other SDP related applications? I gather the answer is "no" given that it's > called "trickle-ice-sdpfrag". The history here goes way back. And it was my "fault". I found a relatively recent discussion of it in http://mailarchive.ietf.org/arch/msg/mmusic/1U_jdbotEzH9ElovVgIs-uWX2w8 > I just looked back to refresh my mind what that discussion was. It was > about sdpfrag. At the time it was just application/sdpfrag. My concern > was a generic sdpfrag isn't useful, because arbitrary subsets of sdp > lines are ambiguous. To make it unambiguous you need to include certain > key features that make it so. I was arguing that what was needed was a > application/trickle-ice-sdpfrag that specified the particular subset > that is unambiguous. There is a more complete discussion of this in http://mailarchive.ietf.org/arch/msg/mmusic/1be2OHjOQs5HZV6u4P-u9hAO9IA Bottom line - this is a purpose-build subset of SDP. It may be useful in other ICE-related applications, but hard to imagine it being broader than that. Thanks, Paul From nobody Thu Dec 7 10:14:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF752129468; Thu, 7 Dec 2017 10:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYBmIU_JzbPG; Thu, 7 Dec 2017 10:14:25 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651CC126D85; Thu, 7 Dec 2017 10:14:24 -0800 (PST) Received: from [10.0.1.92] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB7IEMKl091478 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Dec 2017 12:14:23 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.92] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_470EA1DF-FC38-4E01-94FE-00D7C5230240"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 7 Dec 2017 12:14:22 -0600 In-Reply-To: Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org To: Peter Saint-Andre References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 18:14:27 -0000 --Apple-Mail=_470EA1DF-FC38-4E01-94FE-00D7C5230240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 7, 2017, at 10:58 AM, Peter Saint-Andre = wrote: >=20 >> - The draft needs a "deployment considerations" section relating to = the >> presence of middleboxes that may not be aware of trickle ice. I = recognize >> that b2bUAs may simply be endpoints that don't do trickle, but I = wonder about >> monitoring devices, etc. Even if the answer is "there is no impact", = some >> substantiating text would be helpful. >=20 > Do you think that this concern is SIP-specific or does it need to go = in > draft-ietf-ice-trickle? >=20 I suppose their could be considerations for both, but I was mainly = thinking about it from the SDP perspective. E.g. things that might, for = better or worse, attempt to interpret the offer/answer but not be aware = that INFO was carrying additional SDP. I guess the question of what such a middlebox would _do_ with that SDP = might be relevant to draft-ietf-ice-trickle, although hopefully most = devices for which that would matter could be modeled as endpoints for = purposes of ICE. But I suppose there might be stateful firewalls, ALGs, = etc. Ben. --Apple-Mail=_470EA1DF-FC38-4E01-94FE-00D7C5230240 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlophP4ACgkQgFZKbJXz 1A3LlhAAktl3sI4DJs8/cr6Jrew8f7y15TfTdJ3R3O5SgyU/R5OuOVY+NmKQXfYH Xl65PwDPYFktZXg+bDfv5CsCZw0YZ91yFPeBqb39OqjtmgnbF9qT16dLbLUmiCpI qzl4en81OiyxkIWFuYNUybA1IdEI+WgkksyFiZVbBr4RlzJKobRfazXlAuU/KaRK +L0wstgjjs+eXPIutB9omaDHX3hknkeARZRGAIsFnev+gjnfhPQ/6vPCxgVSCVqW MNLR1eaY5Qo+sZl/dXbBgxfIZp8hsxj4uUA0SHp54U/CeluuYkuKGc2Ctl0puhqn fF0RrmQSQcrqJsH3gPi4YZZx4BfjEBzhbT5m44i4D1zzoDbQrBZEcZHkRhtA+g2k r/0uqOIIEPl6MnrTtvxiOBe5r/HYjWb+HaLLthfSVX47KDWMc2sofQ1IoZ9I2vLh 9DZxoPeLTwnTR2A8a9j8E0J3w4ovYHbwZa2+J+2CPbHEPx4ql0NBlraL2X+NvxKm 7acNLZ0U4cKO8BkdjqWspoovDX7Q0zwiN3HCPlc3eajup6ZwfF74K4D0A8/2SQ66 8rydknS2Yuk+x9w+z0bVVbuWRIckLk5UVz4L7l1oHksyWyx3j8GPm1PBZB9lb6Z+ tOEmgvZ+C0VEF9goiGIH2S65NFKQ2hp4qfs4ripiyN88GjHZ10g= =PnO1 -----END PGP SIGNATURE----- --Apple-Mail=_470EA1DF-FC38-4E01-94FE-00D7C5230240-- From nobody Thu Dec 7 10:16:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FD1294B8 for ; Thu, 7 Dec 2017 10:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSw_1ZoaQmuz for ; Thu, 7 Dec 2017 10:16:32 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF007126D85 for ; Thu, 7 Dec 2017 10:16:32 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id d16so16476480itj.1 for ; Thu, 07 Dec 2017 10:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=WZtMsSP0JgIAPdKZuDN0U/tJwNcvOghYtotMiVT+fKo=; b=DZLZJO+g6P5+3QutvwHz1Y27Uc9hvnpBHenHSk+v4FZtD+Dq8XTQohmQOd1zfcXuhK pb2oCPVtwsszbTGsoWnP5uFIbxVQDuIO+HNzCOPiGt4D4M/94+E6Vs36SEZ5aPF78cUU 3U616WoENVHFwDIEQ3ISWAnwdIvoRUjabBzyU= 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; bh=WZtMsSP0JgIAPdKZuDN0U/tJwNcvOghYtotMiVT+fKo=; b=eixJ8+lALE9WBFOpDNvwxA8A1uYQw1zEROR1i2ailCaMd52z1SFId2cdXkP1Y38W05 Qk/w0BI2qtiKMIJD4InTEqOntYe6IwCjWgsP5Q6SJi+defu+CdO8u3VbztID38i10Zvw 8GMaDvPL9l32JEPej3Q6/eM9tawrXKu5kVw6UeVPkZSLZO8wuwbiT6SUZWIOtmTehkYb +z8Frb3AUepmhTuabAEXRGMyg6eEYfjxSH0Ath8T1Tk+iMFyyAMja5OqPAUVLnQTOsia jUKPbXsCBQIHZ8Vl/IeMKLfl34AB+/TfQfakP/GXhXJsgiqq8ypqjB/S3Sqki1ZGAIrJ wk/g== X-Gm-Message-State: AKGB3mLCizTBeJ00mPf4ysDjXu0k6fTJwrt/2BeuFkAor5shEqujzi1k BjsvqHivZEkm1Js8nlvLHKAFzQ== X-Google-Smtp-Source: AGs4zMZfXbxywNzYrRe2mJiKuAelkd1dC33yaOmu8g97gOSa0Bika8f++rFYMN0ft+eP32njUd5rEA== X-Received: by 10.107.23.132 with SMTP id 126mr17520382iox.191.1512670591885; Thu, 07 Dec 2017 10:16:31 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id d3sm1624979itj.34.2017.12.07.10.16.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 10:16:31 -0800 (PST) To: Ben Campbell Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> From: Peter Saint-Andre Message-ID: Date: Thu, 7 Dec 2017 11:16:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3jsK1GxRKtXx9BGse8rM8bsXQQUb7KKse" Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 18:16:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3jsK1GxRKtXx9BGse8rM8bsXQQUb7KKse Content-Type: multipart/mixed; boundary="KM5hC5Qji3NBS7PFeC5k3UIbWgFkpHElV"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org Message-ID: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> In-Reply-To: --KM5hC5Qji3NBS7PFeC5k3UIbWgFkpHElV Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/7/17 11:14 AM, Ben Campbell wrote: >=20 >=20 >> On Dec 7, 2017, at 10:58 AM, Peter Saint-Andre w= rote: >> >>> - The draft needs a "deployment considerations" section relating to t= he >>> presence of middleboxes that may not be aware of trickle ice. I recog= nize >>> that b2bUAs may simply be endpoints that don't do trickle, but I wond= er about >>> monitoring devices, etc. Even if the answer is "there is no impact", = some >>> substantiating text would be helpful. >> >> Do you think that this concern is SIP-specific or does it need to go i= n >> draft-ietf-ice-trickle? >> >=20 > I suppose their could be considerations for both, but I was mainly thin= king about it from the SDP perspective. E.g. things that might, for bette= r or worse, attempt to interpret the offer/answer but not be aware that I= NFO was carrying additional SDP. >=20 > I guess the question of what such a middlebox would _do_ with that SDP = might be relevant to draft-ietf-ice-trickle, although hopefully most devi= ces for which that would matter could be modeled as endpoints for purpose= s of ICE. But I suppose there might be stateful firewalls, ALGs, etc. We removed all mention of SDP from draft-ietf-ice-trickle, so it seems the question really applies to draft-ietf-mmusic-trickle-ice-sip. Thanks! Peter --KM5hC5Qji3NBS7PFeC5k3UIbWgFkpHElV-- --3jsK1GxRKtXx9BGse8rM8bsXQQUb7KKse Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlophX4ACgkQZWGMGH9o FKlpXg/8DXSTIV3AryJnF2J7ZFIHcOW1Kq7ZWHUo76BsB6aOwOUaypIcqOOY2Cj/ TvzK9ALq61vcUtewADjzKRDWxyWPOtw2QbqlGhyl7o+KhvD6eTDZHCB4lxmSnILz s4DfV80cboS7NaH6dEgeBiu1oadeMtRxUhPLj8Sc4AzmtfU99BDg0pKeS4KsDr/P iVXKv9TPDXVSaayneufGX/8bp7ord9kN6e2KBjd2Sg6rboscdbUK8bDmUmHN3B+w hgXNvc3OZ/FaEgABtbPiJZx4q6fTqR/5TJxQoLpclPMRnchUhintCX4vo8pYNrPi D125YWPeJPRX6i39fediuaLCjk3J5yEbATMGGa6kNMnqDfyxb9WdhJ1IRPJOZ6LW mhGHjkh5i2jGJtL1rDGv184a17MJgtOJbgNd0n9S6QFIBmdfBj/QKi8GTZJPy+ID jQQAC7dMQ6iglSSC8sVs4/zgIkT7jvbTtMYyHOsYRq18Dj5oc2dxYMFznNisgrYI QLG9j5pYY5ryqWBAy/+kL7HNe+RjT3YcBM9Ov86Ewr4aKH5B66P096oOxc4DgDh6 PqpemWrb76aTWEAaVejRY0lbKZHu3ppd5b+H24eWsZhdRodAVItcg7Xmcqd4TsIQ YEy9mi7UJiLT7oZ9wYiq5fXGn0K3kWJrMy3hKVprhWRwrapycv4= =wwQi -----END PGP SIGNATURE----- --3jsK1GxRKtXx9BGse8rM8bsXQQUb7KKse-- From nobody Thu Dec 7 10:18:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297D11276AF; Thu, 7 Dec 2017 10:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4f1_M3B_No1; Thu, 7 Dec 2017 10:18:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031E5126D85; Thu, 7 Dec 2017 10:18:41 -0800 (PST) Received: from [10.0.1.92] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vB7IIeEb092007 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Dec 2017 12:18:41 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.92] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Ben Campbell In-Reply-To: Date: Thu, 7 Dec 2017 12:18:40 -0600 Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5DC0FD07-B9DF-4619-B15E-1AFBBB155E6B@nostrum.com> References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 18:18:43 -0000 > On Dec 7, 2017, at 12:16 PM, Peter Saint-Andre = wrote: >=20 > On 12/7/17 11:14 AM, Ben Campbell wrote: >>=20 >>=20 >>> On Dec 7, 2017, at 10:58 AM, Peter Saint-Andre = wrote: >>>=20 >>>> - The draft needs a "deployment considerations" section relating to = the >>>> presence of middleboxes that may not be aware of trickle ice. I = recognize >>>> that b2bUAs may simply be endpoints that don't do trickle, but I = wonder about >>>> monitoring devices, etc. Even if the answer is "there is no = impact", some >>>> substantiating text would be helpful. >>>=20 >>> Do you think that this concern is SIP-specific or does it need to go = in >>> draft-ietf-ice-trickle? >>>=20 >>=20 >> I suppose their could be considerations for both, but I was mainly = thinking about it from the SDP perspective. E.g. things that might, for = better or worse, attempt to interpret the offer/answer but not be aware = that INFO was carrying additional SDP. >>=20 >> I guess the question of what such a middlebox would _do_ with that = SDP might be relevant to draft-ietf-ice-trickle, although hopefully most = devices for which that would matter could be modeled as endpoints for = purposes of ICE. But I suppose there might be stateful firewalls, ALGs, = etc. >=20 > We removed all mention of SDP from draft-ietf-ice-trickle, so it seems > the question really applies to draft-ietf-mmusic-trickle-ice-sip. >=20 Agreed. Thanks! Ben. From nobody Thu Dec 7 23:52:12 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C031126557; Thu, 7 Dec 2017 23:52:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151271952726.5892.1016223872486186759@ietfa.amsl.com> Date: Thu, 07 Dec 2017 23:52:07 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-43.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 07:52:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-43.txt Pages : 66 Date : 2017-12-07 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m= section without meaning that the media described by the "m=" section is disabled or rejected. When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-43 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-43 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-43 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 7 23:58:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF26126557 for ; Thu, 7 Dec 2017 23:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 TZl6KEMSnCNN for ; Thu, 7 Dec 2017 23:58:03 -0800 (PST) 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 39D1E12421A for ; Thu, 7 Dec 2017 23:58:03 -0800 (PST) X-AuditID: c1b4fb3a-7b5619c000003538-ed-5a2a46096507 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.13.13624.9064A2A5; Fri, 8 Dec 2017 08:58:01 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Fri, 8 Dec 2017 08:58:00 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-43 Thread-Index: AQHTb/pDqT7S1+cYAEOQCySCqiUGsQ== Date: Fri, 8 Dec 2017 07:57:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D65014C72724Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7hC6nm1aUwcl1KhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqf+uIK33BV9z56zNTAu5+pi5OSQEDCReL/qPEsXIxeHkMBh Ronda14xQTiLGSWWvGtl72Lk4GATsJDo/qcN0iAioC7xdW8PM4gtLKAq8XxpLyNIiYiAlsSZ IzYQJXoSS9p3MoLYLAIqEoce3WQFsXkFrCWadx0Ba2UUEJP4fmoNE4jNLCAucevJfCaIewQk luw5zwxhi0q8fPwPrFcUaOaGE7fZIeKKElenL4fqTZC4u3kFE8R8QYmTM5+wTGAUmoVk7Cwk ZbOQlEHEDSTen5vPDGFrSyxb+BrK1pfY+OUsI4RtLbFz2hc2ZDULGDlWMYoWpxYX56YbGeml FmUmFxfn5+nlpZZsYgTGycEtv612MB587niIUYCDUYmH96+eVpQQa2JZcWXuIUYJDmYlEd7u Ms0oId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYx8DqoP 8m+zJkx95x0lnCdiuCNoxXbpp17Gc96n5KRXr8pITrmW091nPdMxd7s5s8EE5f+sbNI+7zri mtfHHDG7MGPerCAhdwYzncQLD75qlivz17FNCNPPTG0vcl71sePpxIbdjkwy8Xe19ouWb11h PV3uz68PD1q5eGTPXDt3Zlag5N7SaUosxRmJhlrMRcWJAK6kjfaPAgAA Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-43 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 07:58:05 -0000 --_000_D65014C72724Achristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Based on Paul=92s comments, I have submitted a new version (-43) of BUNDLE. The new version implements the following PR: https://github.com/cdh4u/draft-sdp-bundle/pull/48 I think we are now ready for the publication request :) Regards, Christer --_000_D65014C72724Achristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6BC56FB7267B9A4EBF7C996E56CBDC00@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Based on Paul=92s comments, I have submitted a new version (-43) of BU= NDLE.

The new version implements the following PR:


I think we are now ready for the publication request :)

Regards,

Christer

--_000_D65014C72724Achristerholmbergericssoncom_-- From nobody Fri Dec 8 01:52:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF051200CF; Fri, 8 Dec 2017 01:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 B_YkOmlnRL08; Fri, 8 Dec 2017 01:52:41 -0800 (PST) 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 06AF0126CB6; Fri, 8 Dec 2017 01:52:41 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 9so2354913wme.4; Fri, 08 Dec 2017 01:52:40 -0800 (PST) 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-transfer-encoding:content-language; bh=Iu9YPLkoyl6h+54kDmudGqOqLSBPmkWnY57hL9Uxg7Y=; b=Exbst5vy0w+PJXRoFI+z/zVdWPIqhltdv8gwVd8IXw/IswSM+voqbSc+jJb9qxzI1x OR7lkAOoXlyj6QZs+VkwQLZXidSJMnlyb1wv8FoeuWLf2y/uyI9RSMec3ybrS9Coq542 TGL/4Y/sb++uxeutbhgKa3FvQV9RowT59iHg87plagt8nO9HrpE0tA/0n/gfFLMh+mIw mUa5JiwXKlYIcfjkflzo/IyUxyXbUQD34/hC1Q0n8FTt/m5JlDv/VCx7Kb6CnJ67o0PP 3Bi/qzCvVl0dFblj4aWX1mYKTGDQI58mR1CNmTPWcGwAwJ/9uRmSnond0kxg8KDFtM3a /m3Q== 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-transfer-encoding :content-language; bh=Iu9YPLkoyl6h+54kDmudGqOqLSBPmkWnY57hL9Uxg7Y=; b=j0OHtUJ+tZjZ+oz0Q0GZvYJTIMWlOv7Bo0waRswkX5te8SmDByQphodOFF6aXpF2Gi EJhWf4gWhcMCBUlMezi2Ki45LbSSqEmE9T4WmLkl14JYq2QEk5DNMTayb8nr+jcAgSJm H4S67cbonfXsdj++Zh3SxduIc4K9rJI19ouqIbbgZCZFI5XC2tM6bzQVDAMG/SMR8cdP gpvCf+xEE/rChxeQBD93H4XITqkRxm3lYZlrijYNiTv/XKqbQ2ANa4MK853jeXEwxxSz vmlQ+GjYHh1vM7XONK4b9jf58QqYpB+nSrVT9Oh5fJi1ligRCFj8uzaOGG8t5XdWt86w VFjA== X-Gm-Message-State: AKGB3mKhjEoAce4MlieFlxctlzplueRq+UNx8x6yhI14dmdYPQepD/Rn l1cTwR7hLrcjfa4abnySrqiIWdgi X-Google-Smtp-Source: AGs4zMan6TIwDJuhy/0RyO+s+fHUX901MSGdHV5TRl2xR/uTYI1gMG47bSJvUjECRkYwZjbb83sc1w== X-Received: by 10.28.22.204 with SMTP id 195mr3745196wmw.11.1512726759245; Fri, 08 Dec 2017 01:52:39 -0800 (PST) Received: from [192.168.2.109] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id n32sm9067473wrb.62.2017.12.08.01.52.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 01:52:38 -0800 (PST) To: Peter Saint-Andre , Ben Campbell , draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> From: Thomas Stach Message-ID: <43db1694-6a94-c22c-c238-b7b00ea12fd1@gmail.com> Date: Fri, 8 Dec 2017 10:52:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:52:43 -0000 Ben, thanks for the thorough review. Responses follow in a separate reply. Just a quick follow up on Peter's first point inline On 2017-12-07 17:58, Peter Saint-Andre wrote: > Hi Ben, thanks for the review; comments inline. > > On 12/6/17 4:24 PM, Ben Campbell wrote: > >> *** Substantive: >> >> - The draft needs a "deployment considerations" section relating to the >> presence of middleboxes that may not be aware of trickle ice. I recognize >> that b2bUAs may simply be endpoints that don't do trickle, but I wonder about >> monitoring devices, etc. Even if the answer is "there is no impact", some >> substantiating text would be helpful. > Do you think that this concern is SIP-specific or does it need to go in > draft-ietf-ice-trickle? That was also sort of my thinking as well. However, this already applied to RCFC5245 and there are  deployment consideration in section 20. They apply in the same way to trickle ICE. The most obvious difference is the additional signalling traffic for trickling the candidates. Regards Thomas > >> -4.2.2, 4th paragraph after fig 4: " and MAY begin trickling" >> that seems like a statement of fact rather than a normative >> offering-of-permission. > s/MAY/can/ > >> -5.3: The comparisons to XMPP don't seem to add much, and seems like >> editorializing. (Also in 3.1). The fact that XMPP has more advanced discovery >> mechanisms is not particularly relevant unless you want to use those as an >> example of how to solve the problems in SIP. > Agreed. > > Peter > > From nobody Fri Dec 8 01:59:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609AB126FB3; Fri, 8 Dec 2017 01:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 6Kc7Hta3AUrf; Fri, 8 Dec 2017 01:59:21 -0800 (PST) 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 4505B1200CF; Fri, 8 Dec 2017 01:59:21 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id t8so2391139wmc.3; Fri, 08 Dec 2017 01:59:21 -0800 (PST) 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=VryLHz7xLymNz10fMfn949A808lEZ1kS1sd4vOacxuo=; b=uESMRLWomn/73JdWcxgqiDtBcpmPASJUALKUhGw37Bq8qybDGsejJ884Ba83TVUxfH EMeEdZVEdTAa1SfB77DEAY57d5sYsbsjx4AguyHoKdPZSigkueDuDpPUvlSIgCM+CXDr YZ00SNndePGlwPlcnu9+60+fBnOJ9/a1fWQwBffrls+Ckobkho+QuBpXBTRXo3DazCx5 /WOoWuNEX0EJ/w22KhLHU4BRvWAmKry0wj8jtAZUtF1p0a7jOfzGF8127R8DHz+ns9JP ivvQ+QuF/c78kCrE8CPLJl6e55ByVUAETfjkGrc6XRhDeHesw3wMxDk81jdu3vwiY4Gk mAOw== 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=VryLHz7xLymNz10fMfn949A808lEZ1kS1sd4vOacxuo=; b=pFFrm1gfVEMkyrdigmvc4BlghIJonoNEzaXRfcMB5ie1ftkNmIPoQExRDP9MAVzut2 gwt2o2thUzRfJn0L/kNREwXgjpwyLU/ouPXfvGD0Agbe4fXt9ID5uMnwAuUIEtA1asjP 1cbFJbPKDf3lYdjiwbNYdU8+apeARuh/Kb/roOgILp+db9qZLSQmuq9qPuFE7cb/gYKh 9MjD9S3oXmY0DCr7HbJoZ6eS4fXKlUSt2IvwseBpGIJP7jqVVzTcNtMZUjTxX8u3aLFV J3qZJtUZ7sHtCvtiScvH0LRmDyY8IPwO5K6Tf0F0JKKI0t8jAyUgpaxogFyUhiW1XBIV nbYw== X-Gm-Message-State: AKGB3mKUs1GNW7Byx+EteZ4Mc23vZpRDXI5kOwlicSjOGKOoVzlBkKgw Bt7Hm6zZMyBjPbbMbT8F5O3GCZyA X-Google-Smtp-Source: AGs4zMYvi08JP+r2Jv7Rnyddjaz/ZeJoGir6lX1uic0Qg6uc94wklxonnOhV24Fo2nfIx7QfEzpg3w== X-Received: by 10.28.140.211 with SMTP id o202mr3344246wmd.145.1512727159598; Fri, 08 Dec 2017 01:59:19 -0800 (PST) Received: from [192.168.2.109] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id g7sm9310057wra.38.2017.12.08.01.59.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 01:59:19 -0800 (PST) To: Ben Campbell , Peter Saint-Andre Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <5DC0FD07-B9DF-4619-B15E-1AFBBB155E6B@nostrum.com> From: Thomas Stach Message-ID: Date: Fri, 8 Dec 2017 10:59:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5DC0FD07-B9DF-4619-B15E-1AFBBB155E6B@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 09:59:23 -0000 All, I just spotted this after sending my previous reply. I'll incorporate something in draft-ietf-mmusic-trickle-ice-sip. Regards Thomas On 2017-12-07 19:18, Ben Campbell wrote: > >> On Dec 7, 2017, at 12:16 PM, Peter Saint-Andre wrote: >> >> On 12/7/17 11:14 AM, Ben Campbell wrote: >>> >>>> On Dec 7, 2017, at 10:58 AM, Peter Saint-Andre wrote: >>>> >>>>> - The draft needs a "deployment considerations" section relating to the >>>>> presence of middleboxes that may not be aware of trickle ice. I recognize >>>>> that b2bUAs may simply be endpoints that don't do trickle, but I wonder about >>>>> monitoring devices, etc. Even if the answer is "there is no impact", some >>>>> substantiating text would be helpful. >>>> Do you think that this concern is SIP-specific or does it need to go in >>>> draft-ietf-ice-trickle? >>>> >>> I suppose their could be considerations for both, but I was mainly thinking about it from the SDP perspective. E.g. things that might, for better or worse, attempt to interpret the offer/answer but not be aware that INFO was carrying additional SDP. >>> >>> I guess the question of what such a middlebox would _do_ with that SDP might be relevant to draft-ietf-ice-trickle, although hopefully most devices for which that would matter could be modeled as endpoints for purposes of ICE. But I suppose there might be stateful firewalls, ALGs, etc. >> We removed all mention of SDP from draft-ietf-ice-trickle, so it seems >> the question really applies to draft-ietf-mmusic-trickle-ice-sip. >> > Agreed. > > Thanks! > > Ben. > > From nobody Fri Dec 8 06:46:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928D4126C25 for ; Fri, 8 Dec 2017 06:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QbSamJ_kIN_O for ; Fri, 8 Dec 2017 06:46:13 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 718F11243FE for ; Fri, 8 Dec 2017 06:46:13 -0800 (PST) X-AuditID: 12074412-1fdff7000000748d-3f-5a2aa5b45e21 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 80.02.29837.4B5AA2A5; Fri, 8 Dec 2017 09:46:12 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vB8EkB9f006141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 8 Dec 2017 09:46:12 -0500 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: <7ed179f7-e694-db42-8aed-57170a3654ef@alum.mit.edu> Date: Fri, 8 Dec 2017 09:46:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixO6iqLtlqVaUQc9tXYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+7q20wF3SwVL441sDYwzmDuYuTkkBAwkej+f5ali5GLQ0hg B5PEzn8bmSCcb0wS2w7PYAGpEhYwkrh7v50dxBYREJaY8fYvG4gtJGAtceDwKiYQm01AS2LO of9g9bwC9hIr5vezgtgsAioSb8/OBrNFBdIk9lzogKoRlDg58wmYzSlgIzH9Ug8jiM0sYCtx Z+5uZghbXOLWk/lMELa8RPPW2cwTGPlnIWmfhaRlFpKWWUhaFjCyrGKUS8wpzdXNTczMKU5N 1i1OTszLSy3SNdPLzSzRS00p3cQICUuhHYzrT8odYhTgYFTi4X0wSytKiDWxrLgy9xCjJAeT kiivn59mlBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXi5/oHLelMTKqtSifJiUNAeLkjjvz8Xq fkIC6YklqdmpqQWpRTBZGQ4OJQne7CVAjYJFqempFWmZOSUIaSYOTpDhPEDDg0BqeIsLEnOL M9Mh8qcYLTluPLz+h4mjp+cGkHw283UDsxBLXn5eqpQ4rxdIgwBIQ0ZpHtxMWJp5xSgO9KIw 7xqQKh5gioKb+gpoIRPQwpgF6iALSxIRUlINjFM2G7W3ux75wWO09MD+hIAFerpPbyc+eHki /OZWxW7+Ne29OZs0syTthUzsXol5lJzmOrD/+hFp4cNfBbjqHz5JjThhHCr8YP36yK+OzQ3J E5hFTx28zmxa+Xtx30bBD14TelNUiyTlTM9x1l0qbCziu8fMsFZfYmeC8PqpvJk+TbtkTuyP UmIpzkg01GIuKk4EAFAJaZ0OAwAA Archived-At: Subject: Re: [MMUSIC] Draft new version: BUNDLE-43 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 14:46:24 -0000 WFM Thanks, Paul On 12/8/17 2:57 AM, Christer Holmberg wrote: > Hi, > > Based on Paul’s comments, I have submitted a new version (-43) of BUNDLE. > > The new version implements the following PR: > > https://github.com/cdh4u/draft-sdp-bundle/pull/48 > > I think we are now ready for the publication request :) > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Dec 11 04:22:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C739C126C19; Mon, 11 Dec 2017 04:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnXOrfbW2DLG; Mon, 11 Dec 2017 04:22:34 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::242]) (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 2C88C126B7E; Mon, 11 Dec 2017 04:22:34 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id v22so17376546wrb.0; Mon, 11 Dec 2017 04:22:34 -0800 (PST) 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=VckVR3/qXzc8p+VVmzWXO+OAi932CZzqbpOLo0xgxAk=; b=WMHFDwmBzisNfXoBwv+JQKV5K22h+JslDW4ggPWu57IXlv6i9IC7OvtY3OPgfj/c58 OFZ4Io5hUUV1OmuudJWG/3AUFCSyjFA9Rd3C0zt5XZz0Gcg4AdL3jNT+dnvMCkgdC8UM rLd529d+GZ39ccqulXqsSRAPJMpsJbgS7Nffya74jkzt6NlauGmWHBScPtPBvZIuiroc 78NFOkWxZm3XnzJsbmep8GafPTBjMS86iaJEuluTDqfbSHTA4R1ctaJHp3QPYpuV7Zfj jS4nQavvI5xz43Q6PELF1mZOjXQbc7HrIGLw54zwj41X1we3Rv6tMOf1NxKnSZVChQ/x W9xA== 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=VckVR3/qXzc8p+VVmzWXO+OAi932CZzqbpOLo0xgxAk=; b=nB05/7tF4oEUhSfMw4egtqza4zBt9JgNKpw+VhteAZbVMMOBcTV1PdX4YYNL8yNfY9 lTn8ezfalBGtOAXsPeopfjQHT28B52E9bApwUdjgEVHySk7XggjX+y4aqooDaTWF5bU9 pg62j6QMtDwTpyPt0AIqyN5zi6dD6DK2eammOZtcbUmC1B9gCzeOK3iqII4w8fTr25rW 2pUxSteVhZqqsVYX93LGLu79jhmSPbPQ/nnUcuaH7q6Y3yHqur0a+HMqs00nmHXpOWpg B1tBVvXBemKFuNtcxRtPxjDpvNV8/KMtlQCknMkfG2YoN7hdPoZtEKDIWR2XuaMo5aki nhrw== X-Gm-Message-State: AKGB3mJGNKybX27RGLsr6jKgTryuS8MB8bm786ExLXnojVccpFrQCJ4G MTlV5Uy2N4YYh6UKOV03kke4huCy X-Google-Smtp-Source: ACJfBotXGsW5gPsehd1dlGDx59aaCwYAE8F0vwi2pXRJ/gybnvRuNLNVNJuEnHQC4Ew+3fmkxkBHMA== X-Received: by 10.223.138.182 with SMTP id y51mr191182wry.273.1512994952069; Mon, 11 Dec 2017 04:22:32 -0800 (PST) Received: from [192.168.2.109] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id d18sm17877841wrd.54.2017.12.11.04.22.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 04:22:31 -0800 (PST) To: Ben Campbell , draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> From: Thomas Stach Message-ID: <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> Date: Mon, 11 Dec 2017 13:22:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> Content-Type: multipart/alternative; boundary="------------3045B6969BCA746225C83C31" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 12:22:39 -0000 This is a multi-part message in MIME format. --------------3045B6969BCA746225C83C31 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ben, thanks a lot for your thorough review. We appreciate your comments. Response inline On 2017-12-07 00:24, Ben Campbell wrote: > Hi, > > These are my AD Evaluation comments for draft-ietf-mmusic-trickle-ice-sip-11. I have quite a few comments, and would like to resolve at least the substantive comments prior to IETF Last Call. > > Thanks! > > Ben. > > > *** Substantive: > > - The draft needs a "deployment considerations" section relating to the > presence of middleboxes that may not be aware of trickle ice. I recognize > that b2bUAs may simply be endpoints that don't do trickle, but I wonder about > monitoring devices, etc. Even if the answer is "there is no impact", some > substantiating text would be helpful. We will mention section 19 of draft-ietf-ice-rfc5245bis and will add something that the  newly introduced INFO messages need to considered as well if the middle boxes needs to see the whole picture. > -3.2: There seem to be some inconsistencies on how the text talks about the > architectural model. For example, section 3.2 separates the "ICE agent" from > the "offer/answer" module, but 3.3 talks about a "trickle ICE agent" doing > offer/answer. (I suspect this is a terminilogy issue where "trickle ICE > agent" as the user agent and "ICE agent" as a software module are too easily > confused.) Good point. The "ICE Agent" in Fig. 2 is actually meant to be a software module. We'll change to "ICE module" in order to make that clear. > 4.1.1: What is the motivation for requiring "audio" in the M-line when one > does not know any candidates in advance? What if the intended media is not > audio? I don't understand why the lack of advance candidates would change > that. (Maybe this is an artifact of the pseudo-M-lines from the INFO bodies?) Well spotted. This is actually an artifact. Your comment applies as well to the the proto field where we could also have something different from RTP/AVP. I propose to remove the bullet list and change from "If the Offerer wants to send its initial Offer before knowing any candidate of one or more media descriptions, it MUST include the following default values in the corresponding "m=" line. o The media field is set to 'audio'. o The port value is set to '9'. o The proto value is set to 'RTP/AVP'." to "If the Offerer wants to send its initial Offer before knowing any candidate of one or more media descriptions, it MUST include a port value set to '9' in the corresponding "m=" line. " > -4.1.1, 2nd to last paragraph : "... it still MUST include the "a=rtcp-mux" > and/or "a=rctp-mux-only" attribute in the initial Offer." > IIUC, that's an already existing requirement from the referenced spec. If so, > please do not use 2118/8174 keywords to describe it here, unless in the form > of directly quoted text. OK Would changing from "... it still MUST include  ..." to "... it will include ... " address your comment? > -4.2.2, RFC editor note: > This askes the RFC Editor to do research. I don't think that's a reasonable > expectation. They may notice that sort of thing anyway, but the authors > should plan to recheck references during AUTH48. (This comment applies to > several other similar RFC editor notes.) It was also meant as a reminder to the authors to cross check during AUTH48. Would the following text be better? "RFC EDITOR NOTE: The section XXX in above sentence is correct for version XX of said I-D. The authors need to cross-check during Auth48 since it could have have changed in the meantime." > -4.2.2, third paragraph after Fig 4: "or when new candidates have not been > learned since then) and/or they MAY also deliver newly learned candidates (if > available). The Offerer MAY include an end-of-candidates attribute in case > candidate discovery has ended in the mean time." > > Are those MAYs really correct when the conditions are true? E.g. if you have > newly learned candidates, there's only a MAY requirement to add them? > Likewise, if discovery has ended, there's only a MAY requirement to add the > end-of-candidates attribute? The motivation for the "MAY"s  was to allow for pre-building of that initial INFO only from information that is available  when the Offer was sent. Of course new candidates need to be trickled eventually. Changing the "MAY"s to "SHOULD"s would still allow for such pre-building. We can do that if you prefer. > -4.2.2, 4th paragraph after fig 4: " and MAY begin trickling" > that seems like a statement of fact rather than a normative > offering-of-permission. You're  correct. We will  s/MAY/can/ > -4.2.2, last paragraph: "... Answerer MUST repeat exactly the same Answer..." > Is that an external requirement, or a new normative one? It is required by RFC3264 as stated at the end of that sentence. We will change "... Answerer MUST repeat ... " to "... Answerer needs to repeat ...". > -4.2.3, first paragraph: "Trickle ICE Agents MAY therefore respond to an > INVITE request with provisional responses without an SDP answer" > That's only if the offerer indicated support for trickle ICE, right? Well, that "MAY" is standard RFC3261 behavior, but, yes, in the context of this document, the Offerer would have indicated support for trickle ICE. Based on your comments above, we    s/MAY/can/ > -4.3: It seems like the use of SDP syntax in the INFO messages creates quite > a bit of complexity due to the use of SDP in (even more) ways not > contemplated by it's design. Did the WG discuss the possibility of using a > designed-for-purpose syntax in the INFO bodies? (This is just my curiosity; > I don't expect to make that sort of fundamental change this late in the > process.) No, there wasn't discussion about an alternative syntax. There was discussion about using some generic 'application/sdpfrag' media-type, but the consensus was to define a SDP subset specifically taylored for trickle-ICE. By using "SDP-like" syntax we also assumed that corresponding code could still be re-used for building the INFO bodies. > -4.3: Discussion of "pseudo-M-lines": > A complete separation of the trickle-ice from offer/answer seems unlikely to > me, since both must send and receive SIP messages in the same dialog. Is it that much harder to remember the media type than it is to remember dialog state? More to the point, are there known implementations that require this? I'm, not sure if I  get your point. But yes, a complete separation seems unlikely since we can have candidates already in the Offer, which need to be delivered to the ICE module. The concept of the pseudo m-lines and a=mid attributes was introduced in order to be able to determine to which m-line a candidate belongs. Having said that, I just recognized - sort of embarrassingly - that we omitted to explicitly specify that a-mid attributes need to go into the offers and answers although we have them in all the SDP examples. I'll add that into the next revision. > -4.3, last bullet: "The fmt SHOULD appear only once..." > Why not MUST? Would it every be reasonable to include more than one? I'm OK with MUST > -4.3, paragraph starting with : "Note that [I-D.ietf-ice-trickle] requires > that when candidates are trickled, each candidate MUST be delivered..." > Don't use 2119/8174 keywords to describe external requrements, except in > directly quoted text. will change as above > -4.3: 2nd paragraph prior to Fig 9: > Are the discussions about removing previously exchanged candidates still in > process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to > requirements that are too vague to state in normative terms. These discussions stalled in the meantime, which is partly the reason for the vagueness. We could s/it MAY treat that as an exceptional case/ it would have to treat that as an exceptional case/ and s/is RECOMMENDED for this situation/is advisable for this situation/ > - figure 9 (and other figures including INFO bodies): Please include a real > content-length value. OK > -5, first paragraph: Please don't use normative terms to describe external > requirements. OK > -5.1, first paragraph: > I'm confused by the reference to WebRTC clients. These are not assumed to use > SIP at all. How are they relevant examples? Well spotted. Will remove > -5.2: IIUC, using the GRUU means the INVITE can go only to that particular > device. This seems to circumvent the recipient's ability to use forking for > their own purposes. That's not a showstopper, but it deserves mention. Agreed > -5.3: The comparisons to XMPP don't seem to add much, and seems like > editorializing. (Also in 3.1). The fact that XMPP has more advanced discovery > mechanisms is not particularly relevant unless you want to use those as an > example of how to solve the problems in SIP. Agreed. Can remove the mentioning of XMPP. > -6, 6th paragraph: "The Trickle Answerer MUST follow the guidance > on the usage of the "a=rtcp" attribute as given in > [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]" > External requirement... Agreed > -8.2, first paragraph: External requirement. Here, I think MAY/MUST is correct, since draft-ietf-ice-trickle does not provide the attributes. They are only defined in this document > -9: Please comment about whether this media type is reasonable to use for > other SDP related applications? I gather the answer is "no" given that it's > called "trickle-ice-sdpfrag". The answer is indeed  "No" per the reasons given already by Paul Kyzivat. Do you want us to explicit add into the text that other SDP related applicationsneed to define their own media type? > -9.2, first paragraph: "A sender SHOULD stick to lower- > case for such grammars, but a receiver SHOULD treat them case- > insensitive." > Why is the second SHOULD not a MUST? MUST is correct > - 10.7: The requirement to include the payload only applies to INFO requests > for this particular package, right? That is, not necessarily "all INFO > requests". Sure > - 10.9: You used the need to pool candidates as a argument against using > update. Doesn’t this create the same requirement? The argument was about using offer/answer in UPDATE request/response which would introduce blocking/risk of glare. INFO does not have this problem, but could still pool candidates if they like, but they don't have to. > Also, do you think it > reasonable that an implementation might not be concerned about this? I can't know that. 10.9 is just meant as a reminder to implementors to think about congestion. Do you want us to change anything in the text? > -11.2: Please use the IESG (iesg@ietf.org) for the change control authority. > The mmusic mailing list could be closed some day. Will do > -12: The registered media type refers to this document for security > considerations, but I don't see any considerations specific to it here. Ok, I will explicitly mention the new media type does not introduce additional security considerations > > *** Editorial and Nits: > > - General: IDNits shows some outdated references. Please fix before final > published version. maybe due to updates in the meantime. I spotted however that we still still refer to I-D.ietf-mmusic-rfc5245bis  instead of I-D.ietf-ice-rfc5245bis > - section 1, paragraph 1: > > The sentence structure for listing the 3 phases is odd. The first two are in > a comma separated list, but the third is in a separate sentence. I suggest > breaking all 3 into separate sentences, with the needed connecting words. > > Missing "and" before "the second phase" > > I think the word "latency" would be better expressed as "delay" or "setup > delay", etc. Too many readers are going to think of "latency" in terms of > network latency (i.e packet delivery). OK > - 1, paragraph 2: "simultaneously" > I think the operating idea is that they can happen in "parallel" or "be > interleaved". OK > -2: Please use the new boilerplate in RFC 8174, unless you specifically want > lower case versions of the RFC 2119 keywords to be interpreted in their 2119 > sense. OK > -2, 2nd paragraph: "This specification makes use of all terminology..." > I suggest removing "all". OK > -3.2, first paragraph: > I think "the exception of the actual INFO messages," is too big of an > exception for this paragraph to be meaningul. For example, this is a huge > change for middleboxes that pay attention to the SDP (e.g. SBCs); I think > saying that things "would look the same" is an overstatement. Would the following be better? "From the perspective of all SIP middle boxes and proxies Offer/Answer exchanges look partly similar for Trickle ICE as they would for ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp ]. However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to be considered as well." > -4, item 5: "Note that in case of forking multiple early dialogs will exist." > s/will/may (or "might" if you want to avoid "may") OK > -4.1.1, 2nd paragraph: "...before knowing any candidate of one or more media > descriptions..." > s/of/for OK > -4.1.1, last paragraph: This seems redundant to the similar statement in > section 4, item 2. Probably, but people tend to read only snippets of a document. > -4.1.2, last paragraph: > s/neither/none (unless you expect there to be exactly 2 trickled candidates.) OK > -4.2.1, title (and several related titles): > I think that usage of "asserting" will trip up some users. Consider > "establishing" instead. OK > - Figure 3: This figure needs a comment about the meaning of "+SRFLX Cand.", > similar to those for later figures. OK > -4.2.3, first paragraph: > s/possibility/ability OK > -4.2.3, paragraph after Fig 6: "When sending the Answer, the agent MUST > repeat all currently known and used candidates, if any, and MAY include all > newly gathered candidates since the last INFO request was sent. If that > Answer was sent in a unreliable provisional response, the Answerers MUST > repeat exactly the same Answer in the 200 OK response to the INVITE request > in order to fulfill the corresponding requirements in [RFC3264]." > > This seems self contradictory, but could be fixed with some connecting > language like "However", or "An exception..." OK > -4.2.4, title: Spell out 3PCC on first mention. Also, an informational > citation would be helpful. OK > -4.3, 3 paragraphs prior to Fig 9: "is an indication of the peer agent that > it will not send any further candidates" > s/of/from OK > -4.3, last paragraph before Fig 9: Please refer to the figure by number > rather than relative position. OK > -5.2, title: Expand "GRUU" on first mention. > First paragraph: s/"SIP US"/"SIP UA" > "... require SIP support" - Should that say "trickle ICE support"? > 2nd paragraph: Please define "targeted trickling" OK > -7, 4th paragraph: I don't understand the meaning of "latest on..." in this > context. It might know already e.g. from configuration. Will remove,  in order to avoid confusion > -7, paragraph between "offer" and "INFO" examples: "Once the dialog is > established as described in section Section 4.2 the Answerer sends the > following INFO request." > The word "section" is repeated. OK > -9.2, first paragraph: "It specifies the subset of existing SDP attributes, > that are needed..." > s/are/is (the phrase constrains "subset", not "attributes"). OK > "The grammar uses the indicator for case-sensitivity %s is defined in > [RFC7405], but also imports grammars for other SDP attributes that precede > the production of that RFC. " > I can't parse that sentence. Maybe due to the typo? It should read "... the indicator for case-sensitivity %s _as_ defined in [RFC7405], ..." > - 10.1, 2nd paragraph: s/introduces/"would introduce" > 3rd paragraph: s/"one exchange"/"one active exchange" OK > - 11.2: Weird line spacing. > "Applications which use this Media Type: > The listed applications only use this media type when using trickle-ice, > right? Would it make sense to just include "trickle-ice"? OK Regards Thomas --------------3045B6969BCA746225C83C31 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Ben,

thanks a lot for your thorough review.

We appreciate your comments.

Response inline


On 2017-12-07 00:24, Ben Campbell wrote:
Hi,

These are my AD Evaluation comments for draft-ietf-mmusic-trickle-ice-sip-11. I have quite a few comments, and would like to resolve at least the substantive comments prior to IETF Last Call.

Thanks!

Ben.


*** Substantive:

- The draft needs a "deployment considerations" section relating to the
presence of middleboxes that may not be aware of trickle ice. I recognize
that b2bUAs may simply be endpoints that don't do trickle, but I wonder about
monitoring devices, etc. Even if the answer is "there is no impact", some
substantiating text would be helpful.
We will mention section 19 of draft-ietf-ice-rfc5245bis and will add something that the  newly introduced INFO messages
need to considered as well if the middle boxes needs to see the whole picture.
-3.2: There seem to be some inconsistencies on how the text talks about the
architectural model. For example, section 3.2 separates the "ICE agent" from
the "offer/answer" module, but 3.3 talks about a "trickle ICE agent" doing
offer/answer. (I suspect this is a terminilogy issue where "trickle ICE
agent" as the user agent and "ICE agent" as a software module are too easily
confused.)
Good point. The "ICE Agent" in Fig. 2 is actually meant to be a software module. We'll change to "ICE module" in order to make that clear.
4.1.1: What is the motivation for requiring "audio" in the M-line when one
does not know any candidates in advance? What if the intended media is not
audio? I don't understand why the lack of advance candidates would change
that. (Maybe this is an artifact of the pseudo-M-lines from the INFO bodies?)
Well spotted. This is actually an artifact. Your comment applies as well to the the proto field
where we could also have something different from RTP/AVP.
I propose to remove the bullet list and change from

"If the Offerer wants to send its initial Offer before knowing any
   candidate of one or more media descriptions, it MUST include the
   following default values in the corresponding "m=" line.

   o  The media field is set to 'audio'.

   o  The port value is set to '9'.

   o  The proto value is set to 'RTP/AVP'."

to 

"If the Offerer wants to send its initial Offer before knowing any
candidate of one or more media descriptions, it MUST include a port value set to '9'
in the corresponding "m=" line. "


-4.1.1, 2nd to last paragraph : "... it still MUST include the "a=rtcp-mux"
and/or "a=rctp-mux-only" attribute in the initial Offer."
IIUC, that's an already existing requirement from the referenced spec. If so,
please do not use 2118/8174 keywords to describe it here, unless in the form
of directly quoted text.
OK
Would changing from "... it still MUST include  ..." to "... it will include ... " address your comment?
-4.2.2, RFC editor note:
This askes the RFC Editor to do research. I don't think that's a reasonable
expectation. They may notice that sort of thing anyway, but the authors
should plan to recheck references during AUTH48. (This comment applies to
several other similar RFC editor notes.)
It was also meant as a reminder to the authors to cross check during AUTH48. Would the following text be better?
"RFC EDITOR NOTE: The section XXX in above sentence is correct for
   version XX of said I-D.  The authors need to cross-check during Auth48 since it could have have
   changed in the meantime."


-4.2.2, third paragraph after Fig 4: "or when new candidates have not been
learned since then) and/or they MAY also deliver newly learned candidates (if
available).  The Offerer MAY include an end-of-candidates attribute in case
candidate discovery has ended in the mean time."

Are those MAYs really correct when the conditions are true? E.g. if you have
newly learned candidates, there's only a MAY requirement to add them?
Likewise, if discovery has ended, there's only a MAY requirement to add the
end-of-candidates attribute?
The motivation for the "MAY"s  was to allow for pre-building of that initial INFO only from information that is available  when the Offer was sent.
Of course new candidates need to be trickled eventually.
Changing the "MAY"s to "SHOULD"s would still allow for such pre-building. We can do that if you prefer.
-4.2.2, 4th paragraph after fig 4: " and MAY begin trickling"
that seems like a statement of fact rather than a normative
offering-of-permission.
You're  correct. We will  s/MAY/can/
-4.2.2, last paragraph: "... Answerer MUST repeat exactly the same Answer..."
Is that an external requirement, or a new normative one?
It is required by RFC3264 as stated at the end of that sentence.
We will change "... Answerer MUST repeat ... " to "... Answerer  needs to repeat ...".
-4.2.3, first paragraph: "Trickle ICE Agents MAY therefore respond to an
INVITE request with provisional responses without an SDP answer"
That's only if the offerer indicated support for trickle ICE, right?
Well, that "MAY" is standard RFC3261 behavior, but, yes, in the context of this document, the Offerer would have indicated support for trickle ICE.
Based on your comments above, we    s/MAY/can/
-4.3: It seems like the use of SDP syntax in the INFO messages creates quite
a bit of complexity due to the use of SDP in (even more) ways not
contemplated by it's design. Did the WG discuss the possibility of using a
designed-for-purpose syntax in the INFO bodies?  (This is just my curiosity;
I don't expect to make that sort of fundamental change this late in the
process.)
No, there wasn't discussion about an alternative syntax.
There was discussion about using some generic 'application/sdpfrag' media-type, but the consensus was to define a SDP subset specifically taylored for trickle-ICE.
By using "SDP-like" syntax we also assumed that corresponding code could still be re-used for building the INFO bodies.
-4.3: Discussion of "pseudo-M-lines":
A complete separation of the trickle-ice from offer/answer seems unlikely to
me, since both must send and receive SIP messages in the same dialog. Is it that much harder to remember the media type than it is to remember dialog state?  More to the point, are there known implementations that require this?
I'm, not sure if I  get your point.
But yes, a complete separation seems unlikely since we can have candidates already in the Offer, which need to be delivered to the ICE module.
The concept of the pseudo m-lines and a=mid attributes was introduced in order to be able to determine to which m-line a candidate belongs.

Having said that, I just recognized - sort of embarrassingly - that we omitted to explicitly specify that a-mid attributes need to go into the offers and answers although we have them in all the SDP examples. I'll add that into the next revision.
-4.3, last bullet: "The fmt SHOULD appear only once..."
Why not MUST? Would it every be reasonable to include more than one?
I'm OK with MUST
-4.3, paragraph starting with : "Note that [I-D.ietf-ice-trickle] requires
that when candidates are trickled, each candidate MUST be delivered..."
Don't use 2119/8174 keywords to describe external requrements, except in
directly quoted text.
will change as above
-4.3: 2nd paragraph prior to Fig 9: 
Are the discussions about removing previously exchanged candidates still in
process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to
requirements that are too vague to state in normative terms.
These discussions stalled in the meantime, which is partly the reason for the vagueness.
We could
s/it MAY treat that as an exceptional case/ it would have to treat that as an exceptional case/
and
s/is RECOMMENDED for this situation/is advisable for this situation/ 
- figure 9 (and other figures including INFO bodies): Please include a real
content-length value.
OK
-5, first paragraph: Please don't use normative terms to describe external
requirements.
OK
-5.1, first paragraph:
I'm confused by the reference to WebRTC clients. These are not assumed to use
SIP at all. How are they relevant examples?
Well spotted. Will remove 
-5.2: IIUC, using the GRUU means the INVITE can go only to that particular
device. This seems to circumvent the recipient's ability to use forking for
their own purposes. That's not a showstopper, but it deserves mention.
Agreed
-5.3: The comparisons to XMPP don't seem to add much, and seems like
editorializing. (Also in 3.1). The fact that XMPP has more advanced discovery
mechanisms is not particularly relevant unless you want to use those as an
example of how to solve the problems in SIP.
Agreed. Can remove the mentioning of XMPP.
-6, 6th paragraph: "The Trickle Answerer MUST follow the guidance
   on the usage of the "a=rtcp" attribute as given in
   [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]"
External requirement...
Agreed 
-8.2, first paragraph: External requirement.
Here, I think MAY/MUST is correct, since draft-ietf-ice-trickle does not provide the attributes. They are only defined in this document
-9: Please comment about whether this media type is reasonable to use for
other SDP related applications? I gather the answer is "no" given that it's
called "trickle-ice-sdpfrag".
The answer is indeed  "No" per the reasons given already by Paul Kyzivat.
Do you want us to explicit add into the text that other SDP related applicationsneed to define their own media type?
-9.2, first paragraph: "A sender SHOULD stick to lower-
   case for such grammars, but a receiver SHOULD treat them case-
   insensitive."
Why is the second SHOULD not a MUST?
MUST is correct 
- 10.7: The requirement to include the payload only applies to INFO requests
for this particular package, right? That is, not necessarily "all INFO
requests".
Sure 
- 10.9: You used the need to pool candidates as a argument against using
update. Doesn’t this create the same requirement?
The argument was about using offer/answer in UPDATE request/response which would introduce blocking/risk of glare.
INFO does not have this problem, but could still pool candidates if they like, but they don't have to.
Also, do you think it
reasonable that an implementation might not be concerned about this?
I can't know that. 10.9 is just meant as a reminder to implementors to think about congestion.
Do you want us to change anything in the text?
-11.2: Please use the IESG (iesg@ietf.org) for the change control authority.
The mmusic mailing list could be closed some day.
Will do
-12: The registered media type refers to this document for security
considerations, but I don't see any considerations specific to it here.
Ok, I will explicitly mention the new media type does not introduce additional security considerations

*** Editorial and Nits:

- General: IDNits shows some outdated references. Please fix before final
published version.
maybe due to updates in the meantime.
I spotted however that we still still refer to I-D.ietf-mmusic-rfc5245bis  instead of I-D.ietf-ice-rfc5245bis
- section 1, paragraph 1:

The sentence structure for listing the 3 phases is odd. The first two are in
a comma separated list, but the third is in a separate sentence. I suggest
breaking all 3 into separate sentences, with the needed connecting words.

Missing "and" before "the second phase"

I think the word "latency" would be better expressed as "delay" or "setup
delay", etc. Too many readers are going to think of "latency" in terms of
network latency (i.e packet delivery).
OK 
- 1, paragraph 2: "simultaneously"
I think the operating idea is that they can happen in "parallel" or "be
interleaved".
OK 
-2: Please use the new boilerplate in RFC 8174, unless you specifically want
lower case versions of the RFC 2119 keywords to be interpreted in their 2119
sense.
OK 
-2, 2nd paragraph: "This specification makes use of all terminology..."
I suggest removing "all".
OK
-3.2, first paragraph:
I think "the exception of the actual INFO messages," is too big of an
exception for this paragraph to be meaningul. For example, this is a huge
change for middleboxes that pay attention to the SDP (e.g. SBCs); I think
saying that things "would look the same" is an overstatement.
Would the following be better?
"From the perspective of all SIP middle boxes and proxies 
Offer/Answer exchanges look partly similar for
Trickle ICE as they would for ICE for SIP [I-D.ietf-mmusic-ice-sip-sdp].
However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to 
be considered as well."
  
-4, item 5: "Note that in case of forking multiple early dialogs will exist."
s/will/may (or "might" if you want to avoid "may")
OK
-4.1.1, 2nd paragraph: "...before knowing any candidate of one or more media
descriptions..."
s/of/for
OK 
-4.1.1, last paragraph: This seems redundant to the similar statement in
section 4, item 2.
Probably, but people tend to read only snippets of a document.
-4.1.2, last paragraph:
s/neither/none (unless you expect there to be exactly 2 trickled candidates.)
OK
-4.2.1, title (and several related titles):
I think that usage of "asserting" will trip up some users. Consider
"establishing" instead.
OK
- Figure 3: This figure needs a comment about the meaning of "+SRFLX Cand.",
similar to those for later figures.
OK
-4.2.3, first paragraph:
s/possibility/ability
OK
-4.2.3, paragraph after Fig 6: "When sending the Answer, the agent MUST
repeat all currently known and used candidates, if any, and MAY include all
newly gathered candidates since the last INFO request was sent.  If that
Answer was sent in a unreliable provisional response, the Answerers MUST
repeat exactly the same Answer in the 200 OK response to the INVITE request
in order to fulfill the corresponding requirements in [RFC3264]."

This seems self contradictory, but could be fixed with some connecting
language like "However", or "An exception..."
OK
-4.2.4, title: Spell out 3PCC on first mention. Also, an informational
citation would be helpful.
OK
-4.3, 3 paragraphs prior to Fig 9: "is an indication of the peer agent that
it will not send any further candidates"
s/of/from
OK
-4.3, last paragraph before Fig 9: Please refer to the figure by number
rather than relative position.
OK
-5.2, title: Expand "GRUU" on first mention.
First paragraph: s/"SIP US"/"SIP UA"
"... require SIP support" - Should that say "trickle ICE support"?
2nd paragraph: Please define "targeted trickling"
OK
-7, 4th paragraph: I don't understand the meaning of "latest on..." in this
context.
It might know already e.g. from configuration. Will remove,  in order to avoid confusion
-7, paragraph between "offer" and "INFO" examples: "Once the dialog is
established as described in section Section 4.2 the Answerer sends the
following INFO request."
The word "section" is repeated.
OK
-9.2, first paragraph: "It specifies the subset of existing SDP attributes,
that are needed..."
s/are/is  (the phrase constrains "subset", not "attributes").
OK 
"The grammar uses the indicator for case-sensitivity %s is defined in
[RFC7405], but also imports grammars for other SDP attributes that precede
the production of that RFC. "
I can't parse that sentence.
Maybe due to the typo? It should read "... the indicator for case-sensitivity %s _as_ defined in [RFC7405], ..."
- 10.1, 2nd paragraph: s/introduces/"would introduce"
3rd paragraph: s/"one exchange"/"one active exchange"
OK 
- 11.2: Weird line spacing.
"Applications which use this Media Type: 
The listed applications only use this media type when using trickle-ice,
right? Would it make sense to just include "trickle-ice"?
OK

Regards
Thomas
--------------3045B6969BCA746225C83C31-- From nobody Mon Dec 11 13:10:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA159128959 for ; Mon, 11 Dec 2017 13:10:40 -0800 (PST) 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 HD1bTrcJuqIa for ; Mon, 11 Dec 2017 13:10:39 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549E51288B8 for ; Mon, 11 Dec 2017 13:10:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=273; q=dns/txt; s=iport; t=1513026639; x=1514236239; h=to:cc:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=LDJaCTAntIczhndXMft3u+Lrqkxn7kgqgPpHZ2rWh7w=; b=F6gmXslxIpCR85qTgI6b9ivLriypfPpxTgkQOw7nErhRsmakToq8a0Qx 1IHuEMbkWCsLTx/cQfEw6dkGH8qqMcOR1+GLbcihs3Q290I5fsqAuIRmZ J/pIYwmnmmUjtDNRRhtxfNRS3eLfnAtlJe25FUFwPY3iou40A4N3vyE4q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AgAr9C5a/5FdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnSEKZkggU6ZUAojhRiEdEIVAQEBAQEBAQEBayiFTA8BBUE?= =?us-ascii?q?1AiYCXw0IAQGKFw0QqDWCJ4pjAQEBAQEBBAEBAQEBAQEcBYEPglmCC4FWghKES?= =?us-ascii?q?4ZrgmMFkyOPbod5jSiBfQEYhhKDaYdSjQqJVIE7NSOBT0wjFYJTAQEPgl2CFSO?= =?us-ascii?q?KFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,392,1508803200"; d="scan'208";a="324951524" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 21:10:10 +0000 Received: from [10.118.10.18] (rtp-fandreas-2-881-ap.cisco.com [10.118.10.18]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBBLAAlH029356; Mon, 11 Dec 2017 21:10:10 GMT To: mmusic Cc: Ari Keranen From: Flemming Andreasen Message-ID: Date: Mon, 11 Dec 2017 16:10:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MMUSIC] Draft MMUSIC minutes for IETF 100 (Singapore) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:10:41 -0000 Greetings MMUSIC The draft meeting minutes from IETF 100 are available at: https://datatracker.ietf.org/meeting/100/materials/minutes-100-mmusic/ Please take a look and let us know if you have any questions or comments. Thanks     Flemming, Ari, and Bo From nobody Tue Dec 12 02:52:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1039C126B72 for ; Tue, 12 Dec 2017 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 FpdS9osPdUIL for ; Tue, 12 Dec 2017 02:52:07 -0800 (PST) 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 2D566124C27 for ; Tue, 12 Dec 2017 02:52:07 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-99-5a2fb4d56a8f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6C.75.27591.5D4BF2A5; Tue, 12 Dec 2017 11:52:05 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 11:52:04 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: 4566bis: sending user ID in o= Thread-Index: AQHTczc+1ngj5VYx1UGHMzWEdTkFlg== Date: Tue, 12 Dec 2017 10:52:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D65583A027512christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7q+7VLfpRBv/WilhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGe3nTzMWnJeueHLlA1sD4x7xLkZODgkBE4kbv/pZuhi5OIQE DjNKfD3awwzhLGGUmL5gFmMXIwcHm4CFRPc/bZAGEQF1ia97QWo4OYSB7FMP77BBxHUktt66 wgRh60lMOrCLBcRmEVCV2LZ3NTuIzStgLbFoZxsjiM0oICbx/dQasHpmAXGJW0/mM0EcJCCx ZM95ZghbVOLl43+sILYo0MwNJ26zQ8QVJdqfNjBC9CZINO1fwQwxX1Di5MwnLBMYhWYhGTsL SdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45ywhhW0v8+PWCDVnNAkaOVYyixanFSbnpRkZ6 qUWZycXF+Xl6eaklmxiBsXJwy2+DHYwvnzseYhTgYFTi4Y2Ypx8lxJpYVlyZe4hRgoNZSYS3 uwkoxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgVHAsmh7 hSCfnNTrUH6lPYW2kz91FjzbKWu+4H8qM7NnitTiZMdLRxoPWp3j5Fp9nZW7MMJZwS05edKb jdaWp/VNj35a1bZfM23bb6Y5rkcvB28Ub+dbweLTd0hqy/+wA12pHH/eFvMory1g+CXPLyv2 207p56+3S00bSxKeHktKcKrpvLSeU4mlOCPRUIu5qDgRAHJstYuRAgAA Archived-At: Subject: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 10:52:09 -0000 --_000_D65583A027512christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, As I have not followed all discussions on 4566bis, so please let me know if= the following has been discussed. Regarding the =93o=3D=93 parameter, the text says: is the user's login on the originating host, or it is "-" if the originating host does not support the concept of user ID= s. The MUST NOT contain spaces. Even if the originating host supports =93the concept of user IDs=94 (whatev= er that means), it may not want to send it for privacy reasons. Couldn=92t we instead say SHOULD send =93-=93, but MUST be able to receive = whatever (for backward compatibility)? Regards, Christer --_000_D65583A027512christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9CDA1FE5B2C5BE4EBE7765C9B3306168@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

As I have not followed all discussions on 4566bis, so please let me kn= ow if the following has been discussed.

Regarding the =93o=3D=93 parameter, the text says:
<username>  is the user's lo=
gin on the originating host, or it is "-"
            if the originating host does not support the concept of user ID=
s.
            The <username> MUST NOT contain spaces.
Even if th=
e originating host supports =93the concept of user IDs=94 (whatever that me=
ans), it may not want to send it for privacy reasons.

Couldn=92t we instead say SHOULD =
send =93-=93, but MUST be able to receive whatever (for backward compatibil=
ity)?

Regard=
s,

Christer&=
nbsp;


--_000_D65583A027512christerholmbergericssoncom_-- From nobody Tue Dec 12 03:33:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F23129435 for ; Tue, 12 Dec 2017 03:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 4SNOvplZxuh9 for ; Tue, 12 Dec 2017 03:33:07 -0800 (PST) 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 0433312941D for ; Tue, 12 Dec 2017 03:33:05 -0800 (PST) X-AuditID: c1b4fb2d-d57ff700000036aa-8a-5a2fbe7012f8 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AA.AB.13994.07EBF2A5; Tue, 12 Dec 2017 12:33:04 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 12:33:03 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqQ== Date: Tue, 12 Dec 2017 11:33:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D6558D3B2752Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7qG7BPv0og/1PhC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJeTWtgL1mtWTJ38kLGB8b9cFyMnh4SAicTjP/2MXYxcHEIC hxklLk7exw6SEBJYwijxYapWFyMHB5uAhUT3P22QsIiAusTXvT3MILawgKrExcszmSDiWhJf 5q9ihrD1JK50n2ABsVmAamYeXMMGYvMKWEvseLuFFcRmFBCT+H5qDVgvs4C4xK0n85kg7hGQ WLLnPDOELSrx8vE/sHpRoJkbTtxmh4grSlydvhyqN0Hi5KVT7BDzBSVOznzCMoFRaBaSsbOQ lM1CUgYRN5B4f24+M4StLbFs4WsoW19i45ezjBC2tUTH60mMyGoWMHKsYhQtTi0uzk03MtZL LcpMLi7Oz9PLSy3ZxAiMlINbfuvuYFz92vEQowAHoxIPr8Nu/Sgh1sSy4srcQ4wSHMxKIrzd TUAh3pTEyqrUovz4otKc1OJDjNIcLErivCc9eaOEBNITS1KzU1MLUotgskwcnFINjNO/TjSp 4/a2U5PMWKPGX3lsS/VKrpNJ/P3qy2eHnt4j1PNk/ZtPjKl/tP6se+o3r/iX6q/P+jaHj6ue u7Dj5ZMYqV2PwxrWcApnb1ErM2b80nPzd2pF1vVXDaIBjN99Hs7NXaxywaP++rPZU14p+yWX 1XqWRe9dOZlFyTlvJrMuX7SmwFf9WCWW4oxEQy3mouJEAJ0e4eqQAgAA Archived-At: Subject: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 11:33:09 -0000 --_000_D6558D3B2752Achristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The text says: is an address of the machine from which the session was created. For an address type of IP4, this is= either a fully qualified domain name of the machine or the dotted= -decimal representation of an IP version 4 address of the machine= . For an address type of IP6, this is either a fully qualified do= main name of the machine or the compressed textual representation = of an IP version 6 address of the machine. For both IP4 and IP6, = the fully qualified domain name is the form that SHOULD be given u= nless this is unavailable, in which case a globally unique address = MAY be substituted. Unless an SDP extension for NAT traversal i= s used (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP add= ress MUST NOT be used in any context where the SDP description mig= ht leave the scope in which the address is meaningful (for exampl= e, a local address MUST NOT be included in an application-level ref= erral that might leave the scope). First, I guess it could be clarified that the =93address of the machine=94 = does not have to be the address used for the media (found in the c=3D line)= . Second, I am not sure I understand how the support of ICE allows the usage = of a local address. The combination of o=3D line parts are supposed to crea= te a unique identifier, so what does ICE have to do with that? Regards, Christer --_000_D6558D3B2752Achristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <33FC8430E721124E96FD887A66E18913@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

The text says:

<unic= ast-address> is an address of the machine from which the
                   session was cre=
ated. For an address type of IP4, this is either a
                   fully qualified domain name of the machine or the dotted=
-decimal
                   representation of an IP version 4 address of the machine=
. For an
                   address type of IP6, this is either a fully qualified do=
main name
                   of the machine or the compressed textual representation =
of an IP
                   version 6 address of the machine. For both IP4 and IP6, =
the fully
                   qualified domain name is the form that SHOULD be given u=
nless this
                   is unavailable, in which case a globally unique address =
MAY be
                   substituted. Unless an SDP extension for NAT traversal i=
s used
                   (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP add=
ress MUST
                   NOT be used in any context where the SDP description mig=
ht leave
                   the scope in which the address is meaningful (for exampl=
e, a local
                   address MUST NOT be included in an application-level ref=
erral that
                   might leave the scope).
First, I g=
uess it could be clarified that the =93address of the machine=94 does not h=
ave to be the address used for the media (found in the c=3D line).

Second, I am not sur= e I understand how the support of ICE allows the usage of a local address. = The combination of o=3D line parts are supposed to create a unique identifi= er, so what does ICE have to do with that?
Regards,

Christer

--_000_D6558D3B2752Achristerholmbergericssoncom_-- From nobody Tue Dec 12 11:06:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131F1126D45 for ; Tue, 12 Dec 2017 11:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1Y7TK_vwqcn for ; Tue, 12 Dec 2017 11:06:52 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::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 630231242F5 for ; Tue, 12 Dec 2017 11:06:52 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id f12so14051049pgo.5 for ; Tue, 12 Dec 2017 11:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DrsGxcFVWF0ksl/FHEXJ2FaXD2JAdk0MWL0CE6ogjB8=; b=RcrpbvYfLGpcDM96/JmWf5xIdIsV0KAOExDOoTtMRAgXLPZocKKHmjgHi/DjN/8pbY 4/NZhDNz+R1K3gHyWeJYAJSPCTdMru9ss8NBk75kHCAHdH6QydvIjCw+NQLermBn0qgh /wXzGM4BGlN4cRLTCc0goa692DgJcJa7fIU8B1Rxny+2cwr1esXgbnXI26v6I6S3xoF+ oQMk8gkrQO7p1tjpe/LwtZTK/PuLHEYY7e8wRwVX4bBh3nUqOdbOCQccbOO4p5fcBofN 3gVbXtOaQh+9CnyCUudxXZeMYTjkyc9EhpAbiNjSthNI4V4FBGvkaLIVy5obS9u8OEqf 1VYA== 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=DrsGxcFVWF0ksl/FHEXJ2FaXD2JAdk0MWL0CE6ogjB8=; b=imCoTgiRoSTnJot/SCXIrU7pq3C7/FREo0pPpccwPRmj3lstcYNXgE1tER4jJCwQHb rMPlk1NlSaO9RAq71m74O8R1ag4vqbuIs+94eTyu9qeH8wq7rCva7oChJzi4rKxzQkGb t7nvlIq4MtfYicx50vBTkgzYmRQ7ytEIH68XFIuMUGo5B/TA05CwpxkFYET70RGSMgZx 3+ZnJeMAN8Uo4HHzhqmtXkJYNJc17+E8Xad/WZbUL0I0IEbxIsVbwBp+MmRBuGrt5M1b uf7PhYoS6IYHnpmk7TaiTrDGrGaRR4pCEOJxbFW2RtvjEne1jC0G8I+NCMJs3HWlkZSk 3TwQ== X-Gm-Message-State: AKGB3mKberBiaFwA2RcpwJiKZvTFqKLQSScGCwpf4eqWMr4H9/crJWWU 8Pa4QK6nze9PVyW215mBpEzoA+hM X-Google-Smtp-Source: ACJfBou+jd4UIP1fuSZBQY+UAWXfnsm7iTZra1aUZsT3BkoWUU+nI1DsOi9JjugdwEEmuAsGmBOIbg== X-Received: by 10.99.163.25 with SMTP id s25mr2911158pge.447.1513105611831; Tue, 12 Dec 2017 11:06:51 -0800 (PST) Received: from mail-pf0-f174.google.com (mail-pf0-f174.google.com. [209.85.192.174]) by smtp.gmail.com with ESMTPSA id c73sm29458461pfd.181.2017.12.12.11.06.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 11:06:51 -0800 (PST) Received: by mail-pf0-f174.google.com with SMTP id u19so14910385pfa.12 for ; Tue, 12 Dec 2017 11:06:51 -0800 (PST) X-Received: by 10.159.245.145 with SMTP id a17mr3264126pls.276.1513105606136; Tue, 12 Dec 2017 11:06:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 11:06:45 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Tue, 12 Dec 2017 14:06:45 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="089e082b12342957f30560295a12" Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 19:06:54 -0000 --089e082b12342957f30560295a12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the intent here is to generate something similar to GUID which will uniquely identify the SDP description, but this is severely outdated for cases like ICE or privacy. I think this needs to be updated to use sufficiently large random strings instead of IP addresses, hostnames and user IDs, when local address or host name is not available or should not be exposed due to privacy reasons. Regards, _____________ Roman Shpount On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The text says: > > is an address of the machine from which the > > session was created. For an address type of IP4, this = is either a > fully qualified domain name of the machine or the dott= ed-decimal > representation of an IP version 4 address of the machi= ne. For an > address type of IP6, this is either a fully qualified = domain name > of the machine or the compressed textual representatio= n of an IP > version 6 address of the machine. For both IP4 and IP6= , the fully > qualified domain name is the form that SHOULD be given= unless this > is unavailable, in which case a globally unique addres= s MAY be > substituted. Unless an SDP extension for NAT traversal= is used > (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP a= ddress MUST > NOT be used in any context where the SDP description m= ight leave > the scope in which the address is meaningful (for exam= ple, a local > address MUST NOT be included in an application-level r= eferral that > might leave the scope). > > First, I guess it could be clarified that the =E2=80=9Caddress of the mac= hine=E2=80=9D does not have to be the address used for the media (found in = the c=3D line). > > Second, I am not sure I understand how the support of ICE allows the usag= e of a local address. The combination of o=3D line parts are supposed to cr= eate a unique identifier, so what does ICE have to do with that? > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e082b12342957f30560295a12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the intent here is to generate something similar t= o GUID which will uniquely identify the SDP description, but this is severe= ly outdated for cases like ICE or privacy.

I think this = needs to be updated to use sufficiently large random strings instead of IP = addresses, hostnames and=C2=A0 user IDs, when local address or host name is= not available or should not be exposed due to privacy reasons.
<= br>
Regards,

= _____________
Roman Shpount

On Tue, Dec 12, 2017 at 6:33 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

The text says:

<unicast-address> is an add= ress of the machine from which the
                   session was created. For an address type of =
IP4, this is either a
                   fully qualified domain name of the machine or the dotted=
-decimal
                   representation of an IP version 4 address of the machine=
. For an
                   address type of IP6, this is either a fully qualified do=
main name
                   of the machine or the compressed textual representation =
of an IP
                   version 6 address of the machine. For both IP4 and IP6, =
the fully
                   qualified domain name is the form that SHOULD be given u=
nless this
                   is unavailable, in which case a globally unique address =
MAY be
                   substituted. Unless an SDP extension for NAT traversal i=
s used
                   (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP add=
ress MUST
                   NOT be used in any context where the SDP description mig=
ht leave
                   the scope in which the address is meaningful (for exampl=
e, a local
                   address MUST NOT be included in an application-level ref=
erral that
                   might leave the scope).
First, I guess it could be clarified that the =E2=80=9Caddress of the mac=
hine=E2=80=9D does not have to be the address used for the media (found in =
the c=3D line).

Second, I am not sure I understand how the support of ICE allows=
 the usage of a local address. The combination of o=3D line parts are suppo=
sed to create a unique identifier, so what does ICE have to do with that?

Regard=
s,
Ch=
rister


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

--089e082b12342957f30560295a12-- From nobody Tue Dec 12 11:20:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E75F129526 for ; Tue, 12 Dec 2017 11:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyiIRwvdeJQu for ; Tue, 12 Dec 2017 11:19:42 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 CB8E6129512 for ; Tue, 12 Dec 2017 11:19:40 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id m26so14940560pfj.11 for ; Tue, 12 Dec 2017 11:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0np5JWh8y23mRgcHdZrajbONL1mDKQ2N3S+YqkgzEbM=; b=cc6ZAjRra1eiFXGUSqN6uhsRIK9gbtKjmz7p4272oReWEIYBwZ52c09SkJojNexcMY m4lhgYlaVD/0vkfjqcrknTHsa1XrdZ0ylqYl7YXLGMD0w3CQ7L1qlHULvZ+beRbAlhzX A8tBtCIcPOH7QtsKhr6+1Y14S6sgZ0UKHazVA5YaihnVzRet7E+ZzIF51jCFnPJ3ex5b 5kyBl2licnI1zbOhCqE+VpYj4ODkA7Zz9OF+NKyoQe+/S4zuBKETty7Fk58m32rJPEWc NFgEcQ3gIHftsyuTGVoclx4YWK/wO/wVtUYPKsj/SL07d/mCRN2V3E2+VKtgrNol9Wgq PTEg== 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=0np5JWh8y23mRgcHdZrajbONL1mDKQ2N3S+YqkgzEbM=; b=jyUTumLLl9c9Fm1hDYQPcGKilf23NX6OVbglTcOu5wMQnXajujd4qpUYWUGUfjRsTo l9K5lGfHUL0ksADQHPMENDp8iawRa5AanHwX53/bmRSAveb9fmqlc8IAaob2JVeCvrpj N2rtAJx6jvjXBCuYEVNAnftV7uo8uIwCay71beh/znIMzvHuc2XnR0Y+xYNzeSzfMNT8 ticOSRhZWd2ZEVAC7U4xqWYbPmtuSrBjHGl7eu3GoBZF9NudoFNjUFbnARKiDO+4MtF7 eMZBYxWzLAzz3dMvIqzUhkrHEBnY5353BAbcpZuZ1Y56gT18klPu/S0fQC54JTyei+SJ Vpig== X-Gm-Message-State: AKGB3mKq0dk7xF40qRzrv72gtejzR/MDtAXfAvymKD/tmfdZvz+tOAtV 27IHanRm501JXEt3+JLyE5c6D7+n X-Google-Smtp-Source: ACJfBosp/nMoVrwR98iRJYa4UHybaTgCk3YiPJZT0hXutf6VKA/5mX+ahRbvsRDYkpWnz2Q9EdpOjA== X-Received: by 10.159.252.6 with SMTP id n6mr3308596pls.370.1513106379992; Tue, 12 Dec 2017 11:19:39 -0800 (PST) Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com. [209.85.192.181]) by smtp.gmail.com with ESMTPSA id c73sm29482916pfd.181.2017.12.12.11.19.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 11:19:39 -0800 (PST) Received: by mail-pf0-f181.google.com with SMTP id j124so14946155pfc.2 for ; Tue, 12 Dec 2017 11:19:39 -0800 (PST) X-Received: by 10.101.80.76 with SMTP id k12mr2991668pgo.32.1513106374455; Tue, 12 Dec 2017 11:19:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 11:19:33 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Tue, 12 Dec 2017 14:19:33 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="089e08206f80f4fd7505602987cb" Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 19:19:59 -0000 --089e08206f80f4fd7505602987cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, I do not see any reason why user should be prohibited from sending their user ID, if they do no care about privacy. I would rephrase this as: is the user's login on the originating host. If the origination host does not support the concept of user IDs or if there are any concerns of end user privacy, "-" SHOULD be used as the value. The must not contain spaces. _____________ Roman Shpount On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > As I have not followed all discussions on 4566bis, so please let me know > if the following has been discussed. > > Regarding the =E2=80=9Co=3D=E2=80=9C parameter, the text says: > > is the user's login on the originating host, or it is "-" > if the originating host does not support the concept of user = IDs. > The MUST NOT contain spaces. > > Even if the originating host supports =E2=80=9Cthe concept of user IDs=E2= =80=9D (whatever that means), it may not want to send it for privacy reason= s. > > Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST= be able to receive whatever (for backward compatibility)? > > Regards, > > Christer > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --089e08206f80f4fd7505602987cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

I do not see any reason wh= y user should be prohibited from sending their user ID, if they do no care = about privacy.

I would rephrase this as:

<username> is the user's login on the originating host= . If the origination host does not support the concept of user IDs or if th= ere are any concerns of end user privacy, "-" SHOULD be used as t= he <username> value. The <username> must not contain spaces.

_____________
Roman Shpount<= /div>

On Tue, Dec 12, 2017 at 5:52 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
Hi,

As I have not followed all discussions on 4566bis, so please let me kn= ow if the following has been discussed.

Regarding the =E2=80=9Co=3D=E2=80=9C parameter, the text says:
<username>  is the user's login on the originating ho=
st, or it is "-"
            if the originating host does not support the concept of user ID=
s.
            The <username> MUST NOT contain spaces.
Even if the originating host supports =E2=80=9Cthe concept of user IDs=E2=
=80=9D (whatever that means), it may not want to send it for privacy reason=
s.
Co=
uldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST be =
able to receive whatever (for backward compatibility)?

Regards,

Christer=C2=A0
=


=


=

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

--089e08206f80f4fd7505602987cb-- From nobody Tue Dec 12 12:23:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E811129540 for ; Tue, 12 Dec 2017 12:23:19 -0800 (PST) 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 M_x7y956Luyy for ; Tue, 12 Dec 2017 12:23:16 -0800 (PST) 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 66AE9126B7E for ; Tue, 12 Dec 2017 12:23:16 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-51-5a303ab24690 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D1.82.27591.2BA303A5; Tue, 12 Dec 2017 21:23:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 21:22:27 +0100 From: Christer Holmberg To: Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTczc+1ngj5VYx1UGHMzWEdTkFlqNABRWAgAAhfmA= Date: Tue, 12 Dec 2017 20:22:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C05117AESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7ou4mK4MogxPv5S2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAlbG14x97wbHSitk9/1kaGDcUdTFyckgImEjc +vufpYuRi0NI4DCjxPePR9ghnCWMEuc3NbN1MXJwsAlYSHT/0wZpEBFQlfj7fTITSJhZQF3i 6uIgkLAw0Jzv15+wQpSYSrzfeRvKtpL48PohG4jNAtTa1bsezOYV8JW4efwjM8SqJkaJvU/v MoIkOAUCJdatW8MOYjMKiEl8P7WGCcRmFhCXuPVkPhPE0QISS/acZ4awRSVePv7HCmErSTQu gTiCWSBfYuW+96wQywQlTs58wjKBUWQWklGzkJTNQlI2C+w1TYn1u/QhShQlpnQ/ZIewNSRa 58xlRxZfwMi+ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwpg5u+W2wg/Hlc8dDjAIcjEo8 vGoqBlFCrIllxZW5hxglOJiVRHi7m/SjhHhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJI TyxJzU5NLUgtgskycXBKNTCG7zjRxKN76M5Ho09Zx+4srHvxdk6inoV/1K3akyc+3Yh7/F11 CddZy6N91uZvLtjF6vQp7lgfFLVs5pzP3Gt+MVa55av6eP8r+Wydf3J7zJu8WWKy/+auf1He GXgsYdrChWkel++ov3+4vJJfbcfVDyGLTbXMnngFNFXUejJPu/OqOvBJath3JZbijERDLeai 4kQACO7ahKUCAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:23:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C05117AESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCldoYXQgdXNlciBJRCBpcyB0aGUgdGV4dCB0YWxraW5nIGFib3V0PyBUaGUg dXNlciBJRCBvZiBteSBjb21wdXRlcj8gVGhlIHVzZXIgSUQgb2YgbXkgVm9JUCBhcHBsaWNhdGlv bj8gQW55IHVzZXIgSUQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogUm9tYW4g U2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMTIgRGVjZW1iZXIgMjAx NyAyMToyMA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+DQpDYzogbW11c2ljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW01NVVNJQ10gNDU2NmJp czogc2VuZGluZyB1c2VyIElEIGluIG89DQoNCkhpIENocmlzdGVyLA0KDQpJIGRvIG5vdCBzZWUg YW55IHJlYXNvbiB3aHkgdXNlciBzaG91bGQgYmUgcHJvaGliaXRlZCBmcm9tIHNlbmRpbmcgdGhl aXIgdXNlciBJRCwgaWYgdGhleSBkbyBubyBjYXJlIGFib3V0IHByaXZhY3kuDQoNCkkgd291bGQg cmVwaHJhc2UgdGhpcyBhczoNCg0KPHVzZXJuYW1lPiBpcyB0aGUgdXNlcidzIGxvZ2luIG9uIHRo ZSBvcmlnaW5hdGluZyBob3N0LiBJZiB0aGUgb3JpZ2luYXRpb24gaG9zdCBkb2VzIG5vdCBzdXBw b3J0IHRoZSBjb25jZXB0IG9mIHVzZXIgSURzIG9yIGlmIHRoZXJlIGFyZSBhbnkgY29uY2VybnMg b2YgZW5kIHVzZXIgcHJpdmFjeSwgIi0iIFNIT1VMRCBiZSB1c2VkIGFzIHRoZSA8dXNlcm5hbWU+ IHZhbHVlLiBUaGUgPHVzZXJuYW1lPiBtdXN0IG5vdCBjb250YWluIHNwYWNlcy4NCg0KX19fX19f X19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUdWUsIERlYyAxMiwgMjAxNyBhdCA1OjUyIEFN LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpBcyBJIGhh dmUgbm90IGZvbGxvd2VkIGFsbCBkaXNjdXNzaW9ucyBvbiA0NTY2YmlzLCBzbyBwbGVhc2UgbGV0 IG1lIGtub3cgaWYgdGhlIGZvbGxvd2luZyBoYXMgYmVlbiBkaXNjdXNzZWQuDQoNClJlZ2FyZGlu ZyB0aGUg4oCcbz3igJwgcGFyYW1ldGVyLCB0aGUgdGV4dCBzYXlzOg0KDQo8dXNlcm5hbWU+ICBp cyB0aGUgdXNlcidzIGxvZ2luIG9uIHRoZSBvcmlnaW5hdGluZyBob3N0LCBvciBpdCBpcyAiLSIN Cg0KICAgICAgICAgICAgaWYgdGhlIG9yaWdpbmF0aW5nIGhvc3QgZG9lcyBub3Qgc3VwcG9ydCB0 aGUgY29uY2VwdCBvZiB1c2VyIElEcy4NCg0KICAgICAgICAgICAgVGhlIDx1c2VybmFtZT4gTVVT VCBOT1QgY29udGFpbiBzcGFjZXMuDQoNCkV2ZW4gaWYgdGhlIG9yaWdpbmF0aW5nIGhvc3Qgc3Vw cG9ydHMg4oCcdGhlIGNvbmNlcHQgb2YgdXNlciBJRHPigJ0gKHdoYXRldmVyIHRoYXQgbWVhbnMp LCBpdCBtYXkgbm90IHdhbnQgdG8gc2VuZCBpdCBmb3IgcHJpdmFjeSByZWFzb25zLg0KDQoNCg0K Q291bGRu4oCZdCB3ZSBpbnN0ZWFkIHNheSBTSE9VTEQgc2VuZCDigJwt4oCcLCBidXQgTVVTVCBi ZSBhYmxlIHRvIHJlY2VpdmUgd2hhdGV2ZXIgKGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5KT8N Cg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbXVzaWMgbWFpbGluZyBsaXN0DQpt bXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B6C05117AESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5IaSBSb21hbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldo YXQgdXNlciBJRCBpcyB0aGUgdGV4dCB0YWxraW5nIGFib3V0PyBUaGUgdXNlciBJRCBvZiBteSBj b21wdXRlcj8gVGhlIHVzZXIgSUQgb2YgbXkgVm9JUCBhcHBsaWNhdGlvbj8gQW55IHVzZXIgSUQ/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IDEyIERlY2VtYmVyIDIwMTcgMjE6MjA8YnI+DQo8Yj5Ubzo8L2I+ IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBtbXVzaWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtNTVVTSUNdIDQ1NjZiaXM6IHNlbmRpbmcgdXNlciBJRCBpbiBvPTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENocmlzdGVyLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3Qgc2VlIGFueSByZWFzb24gd2h5IHVzZXIg c2hvdWxkIGJlIHByb2hpYml0ZWQgZnJvbSBzZW5kaW5nIHRoZWlyIHVzZXIgSUQsIGlmIHRoZXkg ZG8gbm8gY2FyZSBhYm91dCBwcml2YWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIHJlcGhyYXNlIHRoaXMgYXM6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0O3VzZXJuYW1lJmd0OyBp cyB0aGUgdXNlcidzIGxvZ2luIG9uIHRoZSBvcmlnaW5hdGluZyBob3N0LiBJZiB0aGUgb3JpZ2lu YXRpb24gaG9zdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBjb25jZXB0IG9mIHVzZXIgSURzIG9yIGlm IHRoZXJlIGFyZSBhbnkgY29uY2VybnMgb2YgZW5kIHVzZXIgcHJpdmFjeSwgJnF1b3Q7LSZxdW90 OyBTSE9VTEQgYmUgdXNlZCBhcyB0aGUgJmx0O3VzZXJuYW1lJmd0OyB2YWx1ZS4gVGhlICZsdDt1 c2VybmFtZSZndDsgbXVzdCBub3QNCiBjb250YWluIHNwYWNlcy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDU6NTIgQU0sIENocmlzdGVyIEhv bG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5BcyBJIGhhdmUgbm90IGZvbGxvd2VkIGFsbCBkaXNjdXNzaW9ucyBvbiA0NTY2YmlzLCBzbyBw bGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlIGZvbGxvd2luZyBoYXMgYmVlbiBkaXNjdXNzZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlJlZ2FyZGluZyB0aGUg4oCcbz3igJwgcGFyYW1ldGVyLCB0aGUgdGV4dCBzYXlz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImZvbnQt dmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO3dvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNl OnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDt1c2VybmFtZSZndDsmbmJz cDsgaXMgdGhlIHVzZXIncyBsb2dpbiBvbiB0aGUgb3JpZ2luYXRpbmcgaG9zdCwgb3IgaXQgaXMg JnF1b3Q7LSZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBkb2VzIG5vdCBz dXBwb3J0IHRoZSBjb25jZXB0IG9mIHVzZXIgSURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgJmx0O3VzZXJuYW1l Jmd0OyBNVVNUIE5PVCBjb250YWluIHNwYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxk aXY+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDt3b3JkLXdyYXA6 YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RXZlbiBpZiB0aGUg b3JpZ2luYXRpbmcgaG9zdCBzdXBwb3J0cyDigJx0aGUgY29uY2VwdCBvZiB1c2VyIElEc+KAnSAo d2hhdGV2ZXIgdGhhdCBtZWFucyksIGl0IG1heSBub3Qgd2FudCB0byBzZW5kIGl0IGZvciBwcml2 YWN5IHJlYXNvbnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5Db3VsZG7igJl0IHdlIGluc3RlYWQgc2F5IFNIT1VMRCBzZW5k IOKAnC3igJwsIGJ1dCBNVVNUIGJlIGFibGUgdG8gcmVjZWl2ZSB3aGF0ZXZlciAoZm9yIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6C05117AESESSMB109erics_-- From nobody Tue Dec 12 12:25:00 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521DA129540 for ; Tue, 12 Dec 2017 12:24:58 -0800 (PST) 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_H4=-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 qp9mC0q989Qe for ; Tue, 12 Dec 2017 12:24:56 -0800 (PST) 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 D5A59126B7E for ; Tue, 12 Dec 2017 12:24:55 -0800 (PST) X-AuditID: c1b4fb3a-90dff7000000028c-56-5a303b155ef3 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.BA.00652.51B303A5; Tue, 12 Dec 2017 21:24:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 21:24:53 +0100 From: Christer Holmberg To: Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqaNAAXaAgAAl+aA= Date: Tue, 12 Dec 2017 20:24:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> References: 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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C0511A9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2J7uK6YtUGUwe+zHBZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgyjjydypjwYSZjBU7v2Q2MLZMZexi5OSQEDCR eHO+k6WLkYtDSOAwo8SWGTDOEkaJJb2z2LoYOTjYBCwkuv9pgzSICKhK/P0+mQkkzCygLnF1 cRBIWFjASOLKjBlsECXGEgcbZrNC2FYSRzo3soPYLECt+z63gdm8Ar4ST+ZvhlrVxChxbNlc JpAEp0CgxOwNT8GaGQXEJL6fWgMWZxYQl7j1ZD4TxNECEkv2nGeGsEUlXj7+xwphK0k0LnnC ClGfL3H/wGUmiGWCEidnPmGZwCgyC8moWUjKZiEpmwX2mqbE+l36ECWKElO6H7JD2BoSrXPm siOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGFUHt/y22sF48LnjIUYBDkYlHt5r KgZRQqyJZcWVuYcYJTiYlUR4u5v0o4R4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8s Sc1OTS1ILYLJMnFwSjUwCtgmbbX03DVVX5o9avGnBfNXLH97VXOl888Fq1PX+JmfVQg4ULTE 9taH43cX3IwSfbtJp3T799m2Yhm7BNIvp0ZfWeMbsXC1SU3WsqYqUSEV8f2JKYc6vOxd/ep+ ZUUKna86r3R/8pktjz727Tt7TW+2ydnb/RMkRfS01O9s+uG8YNX8CrvKPCWW4oxEQy3mouJE AGepE6qmAgAA Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:24:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C0511A9ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIHRoaW5rIHRoZSBpbnRlbnQgaGVyZSBpcyB0byBnZW5lcmF0ZSBzb21ldGhpbmcg c2ltaWxhciB0byBHVUlEIHdoaWNoIHdpbGwgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIFNEUCBkZXNj cmlwdGlvbiwNCg0KSSB1bmRlcnN0YW5kIHRoYXQsIGJ1dCBJIGRvbuKAmXQgc2VlIHdoYXQgSUNF IGhhcyB0byBkbyB3aXRoIGl0Lg0KDQo+IGJ1dCB0aGlzIGlzIHNldmVyZWx5IG91dGRhdGVkIGZv ciBjYXNlcyBsaWtlIElDRSBvciBwcml2YWN5LiBIb3cgaXMgdXNpbmcgYSBsb2NhbCBhZGRyZXNz IGdvaW5nIHRvIG1ha2UgdGhlIFNEUCB1bmlxdWUganVzdCBiZWNhdXNlIEkgdXNlIElDRT8NCj4N Cj4gSSB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHVwZGF0ZWQgdG8gdXNlIHN1ZmZpY2llbnRseSBs YXJnZSByYW5kb20gc3RyaW5ncyBpbnN0ZWFkIG9mIElQIGFkZHJlc3NlcywgaG9zdG5hbWVzIGFu ZA0KPiB1c2VyIElEcywgd2hlbiBsb2NhbCBhZGRyZXNzIG9yIGhvc3QgbmFtZSBpcyBub3QgYXZh aWxhYmxlIG9yIHNob3VsZCBub3QgYmUgZXhwb3NlZCBkdWUgdG8gcHJpdmFjeSByZWFzb25zLg0K DQpXaXRoIFNJUCBhbmQgb2ZmZXIvYW5zd2VyLCBpcyB0aGVyZSBldmVuIGEgbmVlZCB0byB1bmlx dWVseSBpZGVudGl0eSB0aGUgU0RQIGRlc2NyaXB0aW9uPyBUaGUgU0RQIHdpbGwgYWx3YXlzIGJl IGFzc29jaWF0ZWQgd2l0aCBhIHVuaXF1ZWx5IGlkZW50aWZpZWQgU0lQIHNlc3Npb24uDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KT24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgNjoz MyBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxt YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KVGhl IHRleHQgc2F5czoNCg0KPHVuaWNhc3QtYWRkcmVzcz4gaXMgYW4gYWRkcmVzcyBvZiB0aGUgbWFj aGluZSBmcm9tIHdoaWNoIHRoZQ0KDQogICAgICAgICAgICAgICAgICAgc2Vzc2lvbiB3YXMgY3Jl YXRlZC4gRm9yIGFuIGFkZHJlc3MgdHlwZSBvZiBJUDQsIHRoaXMgaXMgZWl0aGVyIGENCg0KICAg ICAgICAgICAgICAgICAgIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSBvZiB0aGUgbWFjaGlu ZSBvciB0aGUgZG90dGVkLWRlY2ltYWwNCg0KICAgICAgICAgICAgICAgICAgIHJlcHJlc2VudGF0 aW9uIG9mIGFuIElQIHZlcnNpb24gNCBhZGRyZXNzIG9mIHRoZSBtYWNoaW5lLiBGb3IgYW4NCg0K ICAgICAgICAgICAgICAgICAgIGFkZHJlc3MgdHlwZSBvZiBJUDYsIHRoaXMgaXMgZWl0aGVyIGEg ZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lDQoNCiAgICAgICAgICAgICAgICAgICBvZiB0aGUg bWFjaGluZSBvciB0aGUgY29tcHJlc3NlZCB0ZXh0dWFsIHJlcHJlc2VudGF0aW9uIG9mIGFuIElQ DQoNCiAgICAgICAgICAgICAgICAgICB2ZXJzaW9uIDYgYWRkcmVzcyBvZiB0aGUgbWFjaGluZS4g Rm9yIGJvdGggSVA0IGFuZCBJUDYsIHRoZSBmdWxseQ0KDQogICAgICAgICAgICAgICAgICAgcXVh bGlmaWVkIGRvbWFpbiBuYW1lIGlzIHRoZSBmb3JtIHRoYXQgU0hPVUxEIGJlIGdpdmVuIHVubGVz cyB0aGlzDQoNCiAgICAgICAgICAgICAgICAgICBpcyB1bmF2YWlsYWJsZSwgaW4gd2hpY2ggY2Fz ZSBhIGdsb2JhbGx5IHVuaXF1ZSBhZGRyZXNzIE1BWSBiZQ0KDQogICAgICAgICAgICAgICAgICAg c3Vic3RpdHV0ZWQuIFVubGVzcyBhbiBTRFAgZXh0ZW5zaW9uIGZvciBOQVQgdHJhdmVyc2FsIGlz IHVzZWQNCg0KICAgICAgICAgICAgICAgICAgIChlLmcuLCBJQ0UgW1JGQzUyNDVdLCBJQ0UgVENQ IFtSRkM2NTQ0XSksIGEgbG9jYWwgSVAgYWRkcmVzcyBNVVNUDQoNCiAgICAgICAgICAgICAgICAg ICBOT1QgYmUgdXNlZCBpbiBhbnkgY29udGV4dCB3aGVyZSB0aGUgU0RQIGRlc2NyaXB0aW9uIG1p Z2h0IGxlYXZlDQoNCiAgICAgICAgICAgICAgICAgICB0aGUgc2NvcGUgaW4gd2hpY2ggdGhlIGFk ZHJlc3MgaXMgbWVhbmluZ2Z1bCAoZm9yIGV4YW1wbGUsIGEgbG9jYWwNCg0KICAgICAgICAgICAg ICAgICAgIGFkZHJlc3MgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gYW4gYXBwbGljYXRpb24tbGV2 ZWwgcmVmZXJyYWwgdGhhdA0KDQogICAgICAgICAgICAgICAgICAgbWlnaHQgbGVhdmUgdGhlIHNj b3BlKS4NCg0KRmlyc3QsIEkgZ3Vlc3MgaXQgY291bGQgYmUgY2xhcmlmaWVkIHRoYXQgdGhlIOKA nGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmXigJ0gZG9lcyBub3QgaGF2ZSB0byBiZSB0aGUgYWRkcmVz cyB1c2VkIGZvciB0aGUgbWVkaWEgKGZvdW5kIGluIHRoZSBjPSBsaW5lKS4NCg0KDQoNClNlY29u ZCwgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgaG93IHRoZSBzdXBwb3J0IG9mIElDRSBhbGxv d3MgdGhlIHVzYWdlIG9mIGEgbG9jYWwgYWRkcmVzcy4gVGhlIGNvbWJpbmF0aW9uIG9mIG89IGxp bmUgcGFydHMgYXJlIHN1cHBvc2VkIHRvIGNyZWF0ZSBhIHVuaXF1ZSBpZGVudGlmaWVyLCBzbyB3 aGF0IGRvZXMgSUNFIGhhdmUgdG8gZG8gd2l0aCB0aGF0Pw0KDQoNCg0KUmVnYXJkcywNCg0KDQoN CkNocmlzdGVyDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNp Yw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C0511A9ESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O0kgdGhpbmsgdGhlIGlu dGVudCBoZXJlIGlzIHRvIGdlbmVyYXRlIHNvbWV0aGluZyBzaW1pbGFyIHRvIEdVSUQgd2hpY2gg d2lsbCB1bmlxdWVseSBpZGVudGlmeSB0aGUgU0RQIGRlc2NyaXB0aW9uLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdW5k ZXJzdGFuZCB0aGF0LCBidXQgSSBkb27igJl0IHNlZSB3aGF0IElDRSBoYXMgdG8gZG8gd2l0aCBp dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgYnV0IHRoaXMgaXMgc2V2ZXJlbHkgb3V0ZGF0ZWQgZm9yIGNhc2VzIGxpa2UgSUNFIG9y IHByaXZhY3kuIEhvdyBpcyB1c2luZyBhIGxvY2FsIGFkZHJlc3MgZ29pbmcgdG8gbWFrZSB0aGUg U0RQIHVuaXF1ZSBqdXN0IGJlY2F1c2UgSSB1c2UgSUNFPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSB0aGluayB0aGlzIG5lZWRzIHRvIGJl IHVwZGF0ZWQgdG8gdXNlIHN1ZmZpY2llbnRseSBsYXJnZSByYW5kb20gc3RyaW5ncyBpbnN0ZWFk IG9mIElQIGFkZHJlc3NlcywgaG9zdG5hbWVzIGFuZCZuYnNwOw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj51c2VyIElE cywgd2hlbiBsb2NhbCBhZGRyZXNzIG9yIGhvc3QgbmFtZSBpcyBub3QgYXZhaWxhYmxlIG9yIHNo b3VsZCBub3QgYmUgZXhwb3NlZCBkdWUgdG8gcHJpdmFjeSByZWFzb25zLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldpdGgg U0lQIGFuZCBvZmZlci9hbnN3ZXIsIGlzIHRoZXJlIGV2ZW4gYSBuZWVkIHRvIHVuaXF1ZWx5IGlk ZW50aXR5IHRoZSBTRFAgZGVzY3JpcHRpb24/IFRoZSBTRFAgd2lsbCBhbHdheXMgYmUgYXNzb2Np YXRlZCB3aXRoIGEgdW5pcXVlbHkgaWRlbnRpZmllZCBTSVAgc2Vzc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgNjozMyBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDt1bmljYXN0LWFk ZHJlc3MmZ3Q7IGlzIGFuIGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUgZnJvbSB3aGljaCB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlh bnQtbGlnYXR1cmVzOm5vcm1hbDt3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUt d3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vzc2lvbiB3YXMgY3JlYXRlZC4gRm9yIGFuIGFk ZHJlc3MgdHlwZSBvZiBJUDQsIHRoaXMgaXMgZWl0aGVyIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1l IG9mIHRoZSBtYWNoaW5lIG9yIHRoZSBkb3R0ZWQtZGVjaW1hbDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXByZXNlbnRhdGlvbiBvZiBhbiBJUCB2 ZXJzaW9uIDQgYWRkcmVzcyBvZiB0aGUgbWFjaGluZS4gRm9yIGFuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgdHlwZSBvZiBJUDYsIHRo aXMgaXMgZWl0aGVyIGEgZnVsbHkgcXVhbGlmaWVkIGRvbWFpbiBuYW1lPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBtYWNoaW5lIG9yIHRo ZSBjb21wcmVzc2VkIHRleHR1YWwgcmVwcmVzZW50YXRpb24gb2YgYW4gSVA8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmVyc2lvbiA2IGFkZHJlc3Mg b2YgdGhlIG1hY2hpbmUuIEZvciBib3RoIElQNCBhbmQgSVA2LCB0aGUgZnVsbHk8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcXVhbGlmaWVkIGRvbWFp biBuYW1lIGlzIHRoZSBmb3JtIHRoYXQgU0hPVUxEIGJlIGdpdmVuIHVubGVzcyB0aGlzPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHVuYXZhaWxh YmxlLCBpbiB3aGljaCBjYXNlIGEgZ2xvYmFsbHkgdW5pcXVlIGFkZHJlc3MgTUFZIGJlPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1YnN0aXR1dGVk LiBVbmxlc3MgYW4gU0RQIGV4dGVuc2lvbiBmb3IgTkFUIHRyYXZlcnNhbCBpcyB1c2VkPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChlLmcuLCBJQ0Ug W1JGQzUyNDVdLCBJQ0UgVENQIFtSRkM2NTQ0XSksIGEgbG9jYWwgSVAgYWRkcmVzcyBNVVNUPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5PVCBiZSB1 c2VkIGluIGFueSBjb250ZXh0IHdoZXJlIHRoZSBTRFAgZGVzY3JpcHRpb24gbWlnaHQgbGVhdmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHNj b3BlIGluIHdoaWNoIHRoZSBhZGRyZXNzIGlzIG1lYW5pbmdmdWwgKGZvciBleGFtcGxlLCBhIGxv Y2FsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFk ZHJlc3MgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gYW4gYXBwbGljYXRpb24tbGV2ZWwgcmVmZXJy YWwgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBtaWdodCBsZWF2ZSB0aGUgc2NvcGUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4N CjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO3dvcmQtd3JhcDpicmVh ay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5GaXJzdCwgSSBndWVzcyBp dCBjb3VsZCBiZSBjbGFyaWZpZWQgdGhhdCB0aGUg4oCcYWRkcmVzcyBvZiB0aGUgbWFjaGluZeKA nSBkb2VzIG5vdCBoYXZlIHRvIGJlIHRoZSBhZGRyZXNzIHVzZWQgZm9yIHRoZSBtZWRpYSAoZm91 bmQgaW4gdGhlIGM9IGxpbmUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2Vjb25kLCBJIGFtIG5vdCBzdXJlIEkgdW5kZXJz dGFuZCBob3cgdGhlIHN1cHBvcnQgb2YgSUNFIGFsbG93cyB0aGUgdXNhZ2Ugb2YgYSBsb2NhbCBh ZGRyZXNzLiBUaGUgY29tYmluYXRpb24gb2Ygbz0gbGluZSBwYXJ0cyBhcmUgc3VwcG9zZWQgdG8g Y3JlYXRlIGEgdW5pcXVlIGlkZW50aWZpZXIsIHNvIHdoYXQgZG9lcyBJQ0UgaGF2ZSB0byBkbyB3 aXRoIHRoYXQ/PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptbXVzaWMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+bW11c2lj QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbW11c2ljIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6C0511A9ESESSMB109erics_-- From nobody Tue Dec 12 12:28:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF81126B7E for ; Tue, 12 Dec 2017 12:28:42 -0800 (PST) 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_H4=-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 nYZJl1Jg2FvX for ; Tue, 12 Dec 2017 12:28:40 -0800 (PST) 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 09875129540 for ; Tue, 12 Dec 2017 12:28:39 -0800 (PST) X-AuditID: c1b4fb3a-ceff29c00000028c-6e-5a303bf6c5a1 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.1B.00652.6FB303A5; Tue, 12 Dec 2017 21:28:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 21:28:37 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqaNAAXaAgAAl+aCAAAFnsA== Date: Tue, 12 Dec 2017 20:28:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C051222ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7k+43a4Mog3PfxC2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAlbFr303GgiU7GSvaVzg0MG7YwtjFyMkhIWAi 0X77E2sXIxeHkMBhRokplzczQThLGCXW/d7B0sXIwcEmYCHR/U8bpEFEIFriw4cFTCBhZgF1 iauLg0DCwgJGEldmzGCDKDGWONgwmxWkRETASeLaDHOQMIuAqsTvpl1gnbwCvhJPr5dALDrG KHHh5jGwck4BP4kNa0tAyhkFxCS+n1rDBGIzC4hL3HoynwniYgGJJXvOM0PYohIvH/9jhbCV JBqXPGGFqM+XWLHpDNg1vAKCEidnPmGZwCgyC8moWUjKZiEpmwX2l6bE+l36ECWKElO6H7JD 2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGE8Ht/y22sF48LnjIUYB DkYlHt5rKgZRQqyJZcWVuYcYJTiYlUR4u5v0o4R4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTk jRISSE8sSc1OTS1ILYLJMnFwSjUwCq0vdNGJeLQi/vr+sHnn/150LfF1jeW+sbtzAZ+K5PUJ +yVmaU8oPLTg4DWFCweSrvietb7YLtfo0cvSv0/T49PcPBZri6KO0hveMhvmM50MnJKjvG3X Ir//1/7oeLzr2Otw8PbheT9m8/yXfzW7VvxEQZirUnJqj9herkeTLrYyxp45XfTeWYmlOCPR UIu5qDgRAB5U4TSjAgAA Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:28:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C051222ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc2VlbXMgbGlrZSBJIHBsYWNlZCBhIHF1ZXN0aW9uIGluIHRoZSB3cm9uZyBwbGFj ZS4NCg0KSXQgc2hvdWxkIGJlOg0KDQrigJxJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IEkgZG9u4oCZ dCBzZWUgd2hhdCBJQ0UgaGFzIHRvIGRvIHdpdGggaXQuIEhvdyBpcyB1c2luZyBhIGxvY2FsIGFk ZHJlc3MgZ29pbmcgdG8gbWFrZSB0aGUgU0RQIHVuaXF1ZSBqdXN0IGJlY2F1c2UgSSB1c2UgSUNF P+KAnQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IG1tdXNpYyBbbWFpbHRvOm1t dXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNl bnQ6IDEyIERlY2VtYmVyIDIwMTcgMjI6MjUNClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1 cml4LmNvbT4NCkNjOiBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSA0NTY2 YmlzOiBsb2NhbCBhZGRyZXNzIGluIG89DQoNCkhpLA0KDQo+SSB0aGluayB0aGUgaW50ZW50IGhl cmUgaXMgdG8gZ2VuZXJhdGUgc29tZXRoaW5nIHNpbWlsYXIgdG8gR1VJRCB3aGljaCB3aWxsIHVu aXF1ZWx5IGlkZW50aWZ5IHRoZSBTRFAgZGVzY3JpcHRpb24sDQoNCkkgdW5kZXJzdGFuZCB0aGF0 LCBidXQgSSBkb27igJl0IHNlZSB3aGF0IElDRSBoYXMgdG8gZG8gd2l0aCBpdC4NCg0KPiBidXQg dGhpcyBpcyBzZXZlcmVseSBvdXRkYXRlZCBmb3IgY2FzZXMgbGlrZSBJQ0Ugb3IgcHJpdmFjeS4g SG93IGlzIHVzaW5nIGEgbG9jYWwgYWRkcmVzcyBnb2luZyB0byBtYWtlIHRoZSBTRFAgdW5pcXVl IGp1c3QgYmVjYXVzZSBJIHVzZSBJQ0U/DQo+DQo+IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSB1 cGRhdGVkIHRvIHVzZSBzdWZmaWNpZW50bHkgbGFyZ2UgcmFuZG9tIHN0cmluZ3MgaW5zdGVhZCBv ZiBJUCBhZGRyZXNzZXMsIGhvc3RuYW1lcyBhbmQNCj4gdXNlciBJRHMsIHdoZW4gbG9jYWwgYWRk cmVzcyBvciBob3N0IG5hbWUgaXMgbm90IGF2YWlsYWJsZSBvciBzaG91bGQgbm90IGJlIGV4cG9z ZWQgZHVlIHRvIHByaXZhY3kgcmVhc29ucy4NCg0KV2l0aCBTSVAgYW5kIG9mZmVyL2Fuc3dlciwg aXMgdGhlcmUgZXZlbiBhIG5lZWQgdG8gdW5pcXVlbHkgaWRlbnRpdHkgdGhlIFNEUCBkZXNjcmlw dGlvbj8gVGhlIFNEUCB3aWxsIGFsd2F5cyBiZSBhc3NvY2lhdGVkIHdpdGggYSB1bmlxdWVseSBp ZGVudGlmaWVkIFNJUCBzZXNzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoN Ck9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDY6MzMgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoZSB0ZXh0IHNheXM6DQoNCjx1bmljYXN0LWFkZHJl c3M+IGlzIGFuIGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUgZnJvbSB3aGljaCB0aGUNCg0KICAgICAg ICAgICAgICAgICAgIHNlc3Npb24gd2FzIGNyZWF0ZWQuIEZvciBhbiBhZGRyZXNzIHR5cGUgb2Yg SVA0LCB0aGlzIGlzIGVpdGhlciBhDQoNCiAgICAgICAgICAgICAgICAgICBmdWxseSBxdWFsaWZp ZWQgZG9tYWluIG5hbWUgb2YgdGhlIG1hY2hpbmUgb3IgdGhlIGRvdHRlZC1kZWNpbWFsDQoNCiAg ICAgICAgICAgICAgICAgICByZXByZXNlbnRhdGlvbiBvZiBhbiBJUCB2ZXJzaW9uIDQgYWRkcmVz cyBvZiB0aGUgbWFjaGluZS4gRm9yIGFuDQoNCiAgICAgICAgICAgICAgICAgICBhZGRyZXNzIHR5 cGUgb2YgSVA2LCB0aGlzIGlzIGVpdGhlciBhIGZ1bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZQ0K DQogICAgICAgICAgICAgICAgICAgb2YgdGhlIG1hY2hpbmUgb3IgdGhlIGNvbXByZXNzZWQgdGV4 dHVhbCByZXByZXNlbnRhdGlvbiBvZiBhbiBJUA0KDQogICAgICAgICAgICAgICAgICAgdmVyc2lv biA2IGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUuIEZvciBib3RoIElQNCBhbmQgSVA2LCB0aGUgZnVs bHkNCg0KICAgICAgICAgICAgICAgICAgIHF1YWxpZmllZCBkb21haW4gbmFtZSBpcyB0aGUgZm9y bSB0aGF0IFNIT1VMRCBiZSBnaXZlbiB1bmxlc3MgdGhpcw0KDQogICAgICAgICAgICAgICAgICAg aXMgdW5hdmFpbGFibGUsIGluIHdoaWNoIGNhc2UgYSBnbG9iYWxseSB1bmlxdWUgYWRkcmVzcyBN QVkgYmUNCg0KICAgICAgICAgICAgICAgICAgIHN1YnN0aXR1dGVkLiBVbmxlc3MgYW4gU0RQIGV4 dGVuc2lvbiBmb3IgTkFUIHRyYXZlcnNhbCBpcyB1c2VkDQoNCiAgICAgICAgICAgICAgICAgICAo ZS5nLiwgSUNFIFtSRkM1MjQ1XSwgSUNFIFRDUCBbUkZDNjU0NF0pLCBhIGxvY2FsIElQIGFkZHJl c3MgTVVTVA0KDQogICAgICAgICAgICAgICAgICAgTk9UIGJlIHVzZWQgaW4gYW55IGNvbnRleHQg d2hlcmUgdGhlIFNEUCBkZXNjcmlwdGlvbiBtaWdodCBsZWF2ZQ0KDQogICAgICAgICAgICAgICAg ICAgdGhlIHNjb3BlIGluIHdoaWNoIHRoZSBhZGRyZXNzIGlzIG1lYW5pbmdmdWwgKGZvciBleGFt cGxlLCBhIGxvY2FsDQoNCiAgICAgICAgICAgICAgICAgICBhZGRyZXNzIE1VU1QgTk9UIGJlIGlu Y2x1ZGVkIGluIGFuIGFwcGxpY2F0aW9uLWxldmVsIHJlZmVycmFsIHRoYXQNCg0KICAgICAgICAg ICAgICAgICAgIG1pZ2h0IGxlYXZlIHRoZSBzY29wZSkuDQoNCkZpcnN0LCBJIGd1ZXNzIGl0IGNv dWxkIGJlIGNsYXJpZmllZCB0aGF0IHRoZSDigJxhZGRyZXNzIG9mIHRoZSBtYWNoaW5l4oCdIGRv ZXMgbm90IGhhdmUgdG8gYmUgdGhlIGFkZHJlc3MgdXNlZCBmb3IgdGhlIG1lZGlhIChmb3VuZCBp biB0aGUgYz0gbGluZSkuDQoNCg0KDQpTZWNvbmQsIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5k IGhvdyB0aGUgc3VwcG9ydCBvZiBJQ0UgYWxsb3dzIHRoZSB1c2FnZSBvZiBhIGxvY2FsIGFkZHJl c3MuIFRoZSBjb21iaW5hdGlvbiBvZiBvPSBsaW5lIHBhcnRzIGFyZSBzdXBwb3NlZCB0byBjcmVh dGUgYSB1bmlxdWUgaWRlbnRpZmllciwgc28gd2hhdCBkb2VzIElDRSBoYXZlIHRvIGRvIHdpdGgg dGhhdD8NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QN Cm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B6C051222ESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc2VlbXMgbGlrZSBJIHBsYWNl ZCBhIHF1ZXN0aW9uIGluIHRoZSB3cm9uZyBwbGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkl0IHNob3VsZCBiZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+4oCcSSB1bmRlcnN0YW5kIHRoYXQsIGJ1dCBJIGRvbuKAmXQgc2VlIHdoYXQg SUNFIGhhcyB0byBkbyB3aXRoIGl0LiBIb3cgaXMgdXNpbmcgYSBsb2NhbCBhZGRyZXNzIGdvaW5n IHRvIG1ha2UgdGhlIFNEUCB1bmlxdWUganVzdCBiZWNhdXNlIEkgdXNlIElDRT/igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hyaXN0 ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IDEyIERlY2VtYmVyIDIw MTcgMjI6MjU8YnI+DQo8Yj5Ubzo8L2I+IFJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXgu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gbW11c2ljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbTU1VU0lDXSA0NTY2YmlzOiBsb2NhbCBhZGRyZXNzIGluIG89PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtJIHRoaW5rIHRoZSBpbnRlbnQgaGVyZSBpcyB0byBn ZW5lcmF0ZSBzb21ldGhpbmcgc2ltaWxhciB0byBHVUlEIHdoaWNoIHdpbGwgdW5pcXVlbHkgaWRl bnRpZnkgdGhlIFNEUCBkZXNjcmlwdGlvbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHVuZGVyc3RhbmQgdGhhdCwgYnV0 IEkgZG9u4oCZdCBzZWUgd2hhdCBJQ0UgaGFzIHRvIGRvIHdpdGggaXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGJ1dCB0aGlzIGlz IHNldmVyZWx5IG91dGRhdGVkIGZvciBjYXNlcyBsaWtlIElDRSBvciBwcml2YWN5LiBIb3cgaXMg dXNpbmcgYSBsb2NhbCBhZGRyZXNzIGdvaW5nIHRvIG1ha2UgdGhlIFNEUCB1bmlxdWUganVzdCBi ZWNhdXNlIEkgdXNlIElDRT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSB1cGRhdGVkIHRvIHVzZSBz dWZmaWNpZW50bHkgbGFyZ2UgcmFuZG9tIHN0cmluZ3MgaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMs IGhvc3RuYW1lcyBhbmQmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8L3NwYW4+dXNlciBJRHMsIHdoZW4gbG9jYWwgYWRk cmVzcyBvciBob3N0IG5hbWUgaXMgbm90IGF2YWlsYWJsZSBvciBzaG91bGQgbm90IGJlIGV4cG9z ZWQgZHVlIHRvIHByaXZhY3kgcmVhc29ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaXRoIFNJUCBhbmQgb2ZmZXIvYW5z d2VyLCBpcyB0aGVyZSBldmVuIGEgbmVlZCB0byB1bmlxdWVseSBpZGVudGl0eSB0aGUgU0RQIGRl c2NyaXB0aW9uPyBUaGUgU0RQIHdpbGwgYWx3YXlzIGJlIGFzc29jaWF0ZWQgd2l0aCBhIHVuaXF1 ZWx5IGlkZW50aWZpZWQgU0lQIHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDY6MzMgQU0sIENocmlzdGVyIEhvbG1i ZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHRleHQgc2F5czo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmx0O3VuaWNhc3QtYWRkcmVzcyZndDsgaXMgYW4gYWRkcmVzcyBvZiB0aGUgbWFjaGlu ZSBmcm9tIHdoaWNoIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw cmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO3dvcmQtd3JhcDpicmVhay13 b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9uIHdh cyBjcmVhdGVkLiBGb3IgYW4gYWRkcmVzcyB0eXBlIG9mIElQNCwgdGhpcyBpcyBlaXRoZXIgYTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmdWxseSBx dWFsaWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIG1hY2hpbmUgb3IgdGhlIGRvdHRlZC1kZWNpbWFs PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcHJl c2VudGF0aW9uIG9mIGFuIElQIHZlcnNpb24gNCBhZGRyZXNzIG9mIHRoZSBtYWNoaW5lLiBGb3Ig YW48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRk cmVzcyB0eXBlIG9mIElQNiwgdGhpcyBpcyBlaXRoZXIgYSBmdWxseSBxdWFsaWZpZWQgZG9tYWlu IG5hbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg b2YgdGhlIG1hY2hpbmUgb3IgdGhlIGNvbXByZXNzZWQgdGV4dHVhbCByZXByZXNlbnRhdGlvbiBv ZiBhbiBJUDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB2ZXJzaW9uIDYgYWRkcmVzcyBvZiB0aGUgbWFjaGluZS4gRm9yIGJvdGggSVA0IGFuZCBJUDYs IHRoZSBmdWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBxdWFsaWZpZWQgZG9tYWluIG5hbWUgaXMgdGhlIGZvcm0gdGhhdCBTSE9VTEQgYmUgZ2l2 ZW4gdW5sZXNzIHRoaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaXMgdW5hdmFpbGFibGUsIGluIHdoaWNoIGNhc2UgYSBnbG9iYWxseSB1bmlxdWUg YWRkcmVzcyBNQVkgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc3Vic3RpdHV0ZWQuIFVubGVzcyBhbiBTRFAgZXh0ZW5zaW9uIGZvciBOQVQgdHJh dmVyc2FsIGlzIHVzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgKGUuZy4sIElDRSBbUkZDNTI0NV0sIElDRSBUQ1AgW1JGQzY1NDRdKSwgYSBsb2Nh bCBJUCBhZGRyZXNzIE1VU1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgTk9UIGJlIHVzZWQgaW4gYW55IGNvbnRleHQgd2hlcmUgdGhlIFNEUCBkZXNj cmlwdGlvbiBtaWdodCBsZWF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgc2NvcGUgaW4gd2hpY2ggdGhlIGFkZHJlc3MgaXMgbWVhbmluZ2Z1 bCAoZm9yIGV4YW1wbGUsIGEgbG9jYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYWRkcmVzcyBNVVNUIE5PVCBiZSBpbmNsdWRlZCBpbiBhbiBhcHBs aWNhdGlvbi1sZXZlbCByZWZlcnJhbCB0aGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1pZ2h0IGxlYXZlIHRoZSBzY29wZSkuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpu b3JtYWw7d29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkZpcnN0LCBJIGd1ZXNzIGl0IGNvdWxkIGJlIGNsYXJpZmllZCB0aGF0IHRoZSDigJxhZGRy ZXNzIG9mIHRoZSBtYWNoaW5l4oCdIGRvZXMgbm90IGhhdmUgdG8gYmUgdGhlIGFkZHJlc3MgdXNl ZCBmb3IgdGhlIG1lZGlhIChmb3VuZCBpbiB0aGUgYz0gbGluZSkuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TZWNvbmQsIEkg YW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIGhvdyB0aGUgc3VwcG9ydCBvZiBJQ0UgYWxsb3dzIHRo ZSB1c2FnZSBvZiBhIGxvY2FsIGFkZHJlc3MuIFRoZSBjb21iaW5hdGlvbiBvZiBvPSBsaW5lIHBh cnRzIGFyZSBzdXBwb3NlZCB0byBjcmVhdGUgYSB1bmlxdWUgaWRlbnRpZmllciwgc28gd2hhdCBk b2VzIElDRSBoYXZlIHRvIGRvIHdpdGggdGhhdD88bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5DaHJp c3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bW11 c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B6C051222ESESSMB109erics_-- From nobody Tue Dec 12 12:30:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D65129540 for ; Tue, 12 Dec 2017 12:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmH6rgT6Ud4r for ; Tue, 12 Dec 2017 12:29:58 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::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 4495F126D73 for ; Tue, 12 Dec 2017 12:29:58 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id o2so82266pgc.8 for ; Tue, 12 Dec 2017 12:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pNSe6lpGokIozDZtegNgK7SYco71VLC3zRdpShCbsc0=; b=fJvuQfJLeBE+JnWC6obxlGg2oQKzt4hNYB+lt5N0i+ak4vhgTnCS42k+ei/0pqR2df jXh3uRa3eeuHfC55CqKrSDljcFcxtsnKh6lDLw8vjbn5CHar0fqHhgyRRbXW4kn4AY9O 8QSe7PfrJevDDNYYhi0H+jiVPeOzGcRB7xtIjQQz4IyHLqkGz5A2F0G7AXertFSk6LDq eOh3emnV4E2z3+hyWs56Vdhrw66aub9bpYbrAG6/dY5KQS8IEZ3WhrkDg7sMMEoGRgGA orcgGXRVqjxkatzJ/fzXUlGaxzlCa0OWEdrK8ivo9IqKXHXqDhSvgizE8mCf6MlzQArx OwlQ== 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=pNSe6lpGokIozDZtegNgK7SYco71VLC3zRdpShCbsc0=; b=S/eJ7ESNSt/anpq719E0uOuAl12UKm3aJtYtT7lMKntrE+bjzC+4bOR4j2eqGCgu3t D7HtsQR2Bo5xi3ZOJUFoYXY5bxCaKs4GbphTFJs12xJ7zvZI0YtZmDTsAQamdQF9YzG/ t5+oy/O7m9W5X7VXv8AhGL7XEGL0KTvEc6F17Muu812rKQOz8V2dGfpJ+3vCJxm0cMZI gmDtN2KnxUx33KIRRbDr8YRPgbPm3EpfExFtvC3/YQT7wRaxAO0cyprKnWIbHXAh2335 1oWX6NZoAQ7M/0bkfh8R2ren6qH0KjnZBxcKFCk1WN+hoqt+kVrUxNDOOkeC3cdzYdJg lIxw== X-Gm-Message-State: AKGB3mL3V3BHPn11JAIuc5KM01RHVLlxK6V/gT+0ijF0QSkKB8vh1SnV iIjC7Osnwwy8Uv1IjwXl9R6cV6C4 X-Google-Smtp-Source: ACJfBovf33KPGURXNO6BsrMwThnIE+C35lXsYnkcAdfNPgDNhO7Zp2CMWzOYbzDT13DODyZS0HJNew== X-Received: by 10.101.77.210 with SMTP id q18mr3124590pgt.145.1513110597534; Tue, 12 Dec 2017 12:29:57 -0800 (PST) Received: from mail-pg0-f51.google.com (mail-pg0-f51.google.com. [74.125.83.51]) by smtp.gmail.com with ESMTPSA id t25sm22626pgu.0.2017.12.12.12.29.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 12:29:57 -0800 (PST) Received: by mail-pg0-f51.google.com with SMTP id w7so86751pgv.6 for ; Tue, 12 Dec 2017 12:29:56 -0800 (PST) X-Received: by 10.98.242.9 with SMTP id m9mr3466344pfh.168.1513110596669; Tue, 12 Dec 2017 12:29:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 12:29:56 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 12 Dec 2017 15:29:56 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403043e33309ed96d05602a83a2" Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:30:00 -0000 --f403043e33309ed96d05602a83a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, I think the original intent was the logged in user in the computer system. I remember RAT (Real Audio Tool) looking at the logged in user on UNIX and putting "user" on Windows. Regards, _____________ Roman Shpount On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Roman, > > > > What user ID is the text talking about? The user ID of my computer? The > user ID of my VoIP application? Any user ID? > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 12 December 2017 21:20 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: sending user ID in o=3D > > > > Hi Christer, > > > > I do not see any reason why user should be prohibited from sending their > user ID, if they do no care about privacy. > > > > I would rephrase this as: > > > > is the user's login on the originating host. If the originatio= n > host does not support the concept of user IDs or if there are any concern= s > of end user privacy, "-" SHOULD be used as the value. The > must not contain spaces. > > > _____________ > Roman Shpount > > > > On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > As I have not followed all discussions on 4566bis, so please let me know > if the following has been discussed. > > > > Regarding the =E2=80=9Co=3D=E2=80=9C parameter, the text says: > > is the user's login on the originating host, or it is "-" > > if the originating host does not support the concept of user = IDs. > > The MUST NOT contain spaces. > > Even if the originating host supports =E2=80=9Cthe concept of user IDs=E2= =80=9D (whatever that means), it may not want to send it for privacy reason= s. > > > > Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST= be able to receive whatever (for backward compatibility)? > > > > Regards, > > > > Christer > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --f403043e33309ed96d05602a83a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

I think the original inten= t was the logged in user in the computer system. I remember RAT (Real Audio= Tool) looking at the logged in user on UNIX and putting "user" o= n Windows.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:22 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi Roman,

=C2=A0

What user ID is the text talking abou= t? The user ID of my computer? The user ID of my VoIP application? Any user= ID?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = Roman Shpount [mailto:roman@telurix.com]
Sent: 12 December 2017 21:20
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D=

=C2=A0

Hi Christer,

=C2=A0

I do not see any reason why user should be prohibite= d from sending their user ID, if they do no care about privacy.

=C2=A0

I would rephrase this as:

=C2=A0

<username> is the user's login on the orig= inating host. If the origination host does not support the concept of user = IDs or if there are any concerns of end user privacy, "-" SHOULD = be used as the <username> value. The <username> must not contain spaces.


_____________
Roman Shpount

=C2=A0

On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As I have not followed all discussions = on 4566bis, so please let me know if the following has been discussed.

=C2=A0

Regarding the =E2=80=9Co=3D=E2=80=9C pa= rameter, the text says:

<username>=C2=A0 is the user&=
#39;s login on the originating host, or it is "-"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 if the originating host does not support the conce=
pt of user IDs.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 The <username> MUST NOT contain spaces.
Even if the originating host supports =E2=80=9Cthe concept of user =
IDs=E2=80=9D (whatever that means), it may not want to send it for privacy =
reasons.
=C2=A0
Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST =
be able to receive whatever (for backward compatibility)?
=C2=A0
Regards,
=C2=A0
Christer=C2=A0
=C2=A0
=C2=A0


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

=C2=A0


--f403043e33309ed96d05602a83a2-- From nobody Tue Dec 12 12:38:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC0712954B for ; Tue, 12 Dec 2017 12:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnTRYfk6GcwV for ; Tue, 12 Dec 2017 12:38:39 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E361287A5 for ; Tue, 12 Dec 2017 12:38:39 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id c204so98720pfc.13 for ; Tue, 12 Dec 2017 12:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=L99vnIZvb9dev45q759VVoCmLx28camoiJsGBOVA9k4=; b=H11aAly0IQIV2lmUoDetJK/e6e+bpoNQeb5cEs8MF4qNbEMh3zO1C8vn5H4s/XoaR1 aDLe1lfyFgCX5S26WyfuxZK6ZRV8YABd2P0dtJ7lWNDoQF0kIpsLw1vAA4gMGv6t24Sr PMDhF/5ZF/p5/JWg+KhdCeyN/MYi/pafkJywSY4Oo0u+Gs8yeIch7Z5xQrifRhz/GbAZ NaDaSwU6JoJxMsCeoBffNIsu6mt0dGxmWPnk6wKG/QUwszjQxlxPD3ft558mB/OghDjZ gj+G6z7sxjxzDDO6NFAmKvUCpUAUhTGGWGPfChL9UsgJMJY6HW7AmS5BfHqgLL5W/gxu jXXg== 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=L99vnIZvb9dev45q759VVoCmLx28camoiJsGBOVA9k4=; b=ln3a2H73sRDoWeYa0DvNSbiXsAF3RSsC0QrytfEbM3sM/XsOBVWGXoZdO4M+bzA/MA Vh5UTXUoHEvZH9GVyMESthm9SbF6mP000y5eM800kFOcqnjs8kcxFYaBd+0M0HI7F/MT n9495KpECESgdHxR61ZCiOx+oM3V8i0FLHJ4hiDMaAugoco8gef//5F0cdxGKhUawp93 rVoo7d31xro8F8YeKTNDHtilXg0WyCPNV5mURfynG7heCu1d3fp5pxaePxYaXJw44hk+ 7/sU0ruc1msZxQGd4hJjYxyPe9ZOJPPVwwmcaTP/96A3Q5V9luj5bNYTpSej2H/mCi2s bEBg== X-Gm-Message-State: AKGB3mLfG1nNVJ/13hlBWUfx/lG7p6pdidf+dnAM1ko52bvf6Qlyx37c lddbOBRXz+sVprJQGrLa9STuHszW X-Google-Smtp-Source: ACJfBov94jSTNn3Ip/YFgguC52/8X18FBMdJLQyFfnm5D9S9XIAXGTXbwkDAD91MaCtFfbkvVipVFg== X-Received: by 10.84.252.142 with SMTP id y14mr3360638pll.367.1513111118513; Tue, 12 Dec 2017 12:38:38 -0800 (PST) Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com. [209.85.192.182]) by smtp.gmail.com with ESMTPSA id t23sm22995pfg.97.2017.12.12.12.38.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 12:38:37 -0800 (PST) Received: by mail-pf0-f182.google.com with SMTP id a90so124260pfk.1 for ; Tue, 12 Dec 2017 12:38:37 -0800 (PST) X-Received: by 10.99.112.92 with SMTP id a28mr3155845pgn.413.1513111117450; Tue, 12 Dec 2017 12:38:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 12:38:36 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 12 Dec 2017 15:38:36 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045c6b5ea9546a05602aa2af" Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:38:41 -0000 --f403045c6b5ea9546a05602aa2af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christer, The issue is, once again, third party call control and unexpected SDP offer collisions between two SIP sessions. Because of this, if offer goes from one SIP session to another due to B2BUA and third party call control, it is important that o=3D line accidentally did not end up being the same between two sessions. If o=3D line is the same, some clients do not parse or compar= e SDP, assuming this is the same SDP description. Because of this, it is important for o=3D line to be globally unique. One option is to use unique system identifier (IP or host name), session identifier and version in the session. Another option is to use something random which is long enough to be unique. When offer is generated when ICE is used, client might not know the globally unique IP address when offer is generated. Client can use local NATed address, but this often results in collisions. The actual advise for this case (use local IP) is actually counter productive, since using local IP is more likely to result in collisions then using something random. This probably needs to be corrected. Regards, _____________ Roman Shpount On Tue, Dec 12, 2017 at 3:28 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I seems like I placed a question in the wrong place. > > > > It should be: > > > > =E2=80=9CI understand that, but I don=E2=80=99t see what ICE has to do wi= th it. How is > using a local address going to make the SDP unique just because I use ICE= ?=E2=80=9D > > > > Regards, > > > > Christer > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 12 December 2017 22:25 > *To:* Roman Shpount > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: local address in o=3D > > > > Hi, > > > > >I think the intent here is to generate something similar to GUID which > will uniquely identify the SDP description, > > > > I understand that, but I don=E2=80=99t see what ICE has to do with it. > > > > > but this is severely outdated for cases like ICE or privacy. How is > using a local address going to make the SDP unique just because I use ICE= ? > > > > > > I think this needs to be updated to use sufficiently large random > strings instead of IP addresses, hostnames and > > > user IDs, when local address or host name is not available or should > not be exposed due to privacy reasons. > > > > With SIP and offer/answer, is there even a need to uniquely identity the > SDP description? The SDP will always be associated with a uniquely > identified SIP session. > > > > Regards, > > > > Christer > > > > > > > > > > > > On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > The text says: > > > > is an address of the machine from which the > > session was created. For an address type of IP4, this = is either a > > fully qualified domain name of the machine or the dott= ed-decimal > > representation of an IP version 4 address of the machi= ne. For an > > address type of IP6, this is either a fully qualified = domain name > > of the machine or the compressed textual representatio= n of an IP > > version 6 address of the machine. For both IP4 and IP6= , the fully > > qualified domain name is the form that SHOULD be given= unless this > > is unavailable, in which case a globally unique addres= s MAY be > > substituted. Unless an SDP extension for NAT traversal= is used > > (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a local IP a= ddress MUST > > NOT be used in any context where the SDP description m= ight leave > > the scope in which the address is meaningful (for exam= ple, a local > > address MUST NOT be included in an application-level r= eferral that > > might leave the scope). > > First, I guess it could be clarified that the =E2=80=9Caddress of the mac= hine=E2=80=9D does not have to be the address used for the media (found in = the c=3D line). > > > > Second, I am not sure I understand how the support of ICE allows the usag= e of a local address. The combination of o=3D line parts are supposed to cr= eate a unique identifier, so what does ICE have to do with that? > > > > Regards, > > > > Christer > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --f403045c6b5ea9546a05602aa2af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christer,

The issue is, once again, thi= rd party call control and unexpected SDP offer collisions between two SIP s= essions. Because of this, if offer goes from one SIP session to another due= to B2BUA and third party call control, it is important that o=3D line acci= dentally did not end up being the same between two sessions. If o=3D line i= s the same, some clients do not parse or compare SDP, assuming this is the = same SDP description. Because of this, it is important for o=3D line to be = globally unique. One option is to use unique system identifier (IP or host = name), session identifier and version in the session. Another option is to = use something random which is long enough to be unique.

When offer is generated when ICE is used, client might not know the g= lobally unique IP address when offer is generated. Client can use local NAT= ed address, but this often results in collisions. The actual advise for thi= s case (use local IP) is actually counter productive, since using local IP = is more likely to result in collisions then using something random. This pr= obably needs to be corrected.

Regards,
=

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:28 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

I seems like I placed a question in t= he wrong place.

=C2=A0

It should be:

=C2=A0

=E2=80=9CI understand that, but I don=E2=80=99t see = what ICE has to do with it. How is using a local address going to make the = SDP unique just because I use ICE?=E2=80=9D

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 12 December 2017 22:25
To: Roman Shpount <roman@telurix.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] 4566bis: local address in o=3D

=C2=A0

Hi,

=C2=A0

>I think the intent here is to generate something= similar to GUID which will uniquely identify the SDP description,

=C2=A0

I understand that, but I don=E2=80=99t see what ICE= has to do with it.

=C2=A0

> but this is severely outdated for cases like IC= E or privacy. How is using a local address going to make the SDP unique jus= t because I use ICE?

>=C2=A0

> I think this needs to be updated to use suffici= ently large random strings instead of IP addresses, hostnames and=C2=A0

> user IDs, when local address or host name is not available or should= not be exposed due to privacy reasons.

=C2=A0

With SIP and offer/answer, is there even a need to = uniquely identity the SDP description? The SDP will always be associated wi= th a uniquely identified SIP session.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

The text says:

=C2=A0

<unicast-address> is an address o= f the machine from which the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 session was created. For an address type of IP4, this is either a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fully qu=
alified domain name of the machine or the dotted-decimal
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 represen=
tation of an IP version 4 address of the machine. For an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address =
type of IP6, this is either a fully qualified domain name
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the m=
achine or the compressed textual representation of an IP
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 version =
6 address of the machine. For both IP4 and IP6, the fully
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 qualifie=
d domain name is the form that SHOULD be given unless this
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is unava=
ilable, in which case a globally unique address MAY be=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 substitu=
ted. Unless an SDP extension for NAT traversal is used=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (e.g., I=
CE [RFC5245], ICE TCP [RFC6544]), a local IP address MUST
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT be u=
sed in any context where the SDP description might leave
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the scop=
e in which the address is meaningful (for example, a local
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address =
MUST NOT be included in an application-level referral that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 might le=
ave the scope).
First, I guess it could be clarified that the =E2=80=9Caddress of t=
he machine=E2=80=9D does not have to be the address used for the media (fou=
nd in the c=3D line).
=C2=A0
Second, I am not sure I understand how the support of ICE allows the usage=
 of a local address. The combination of o=3D line parts are supposed to cre=
ate a unique identifier, so what does ICE have to do with that?
=C2=A0
Regards,
=C2=A0
Christer
=C2=A0


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

=C2=A0


--f403045c6b5ea9546a05602aa2af-- From nobody Tue Dec 12 12:40:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5D31287A5 for ; Tue, 12 Dec 2017 12:40:00 -0800 (PST) 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 kWwVQsXQ1Jo9 for ; Tue, 12 Dec 2017 12:39:50 -0800 (PST) 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 5B4D812954B for ; Tue, 12 Dec 2017 12:39:50 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-9c-5a303e94a6a7 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.F3.27591.49E303A5; Tue, 12 Dec 2017 21:39:48 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 21:38:47 +0100 From: Christer Holmberg To: Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTczc+1ngj5VYx1UGHMzWEdTkFlqNABRWAgAAhfmD///ItAIAAEtyw Date: Tue, 12 Dec 2017 20:38:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C051282@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C051282ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdUXeKnUGUwebtOhZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgypi1cRtzwYlVjBW/N35la2BsWcbYxcjJISFg IjFlzXJWEFtI4DCjxNp7UV2MXED2EkaJhi8H2bsYOTjYBCwkuv9pg9SICKhK/P0+mQkkzCyg LnF1cRBIWBhozPfrT1ghSkwl3u+8DWW7STyds40RpJwFqPXstyyQMK+Ar8SGR3fYIDb1Mkk0 zLvFAlLDKRAo8WtRBEgNo4CYxPdTa5hAbGYBcYlbT+YzQVwsILFkz3lmCFtU4uXjf6wQtpJE 4xKQE0Auy5foXuwMsUpQ4uTMJywTGEVmIZk0C6FqFpIqiLCmxPpd+hDVihJTuh+yQ9gaEq1z 5rIjiy9gZF/FKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJERhNB7f8NtjB+PK54yFGAQ5GJR7e xdYGUUKsiWXFlbmHGCU4mJVEeLub9KOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhP LEnNTk0tSC2CyTJxcEo1MIpOZuT92Pnu581UnwrWFRLP/Q1Yjxv7sO2M5wya9T5PtDZUIK8j 7O+ahtkBIQuO+CYKePZWqeTLaOzQ8RGRe3am25rz4oQi62sTQ0pzfvbef5wQqvalfFXgSstj zPzHJsns8jXo/GMXsutKdPgtVQGutT6znO6K/lCoDlz3/Ny94PzHHS9FlViKMxINtZiLihMB Q6e/QqICAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:40:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C051282ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIHRoaW5rIHRoZSBvcmlnaW5hbCBpbnRlbnQgd2FzIHRoZSBsb2dnZWQgaW4gdXNl ciBpbiB0aGUgY29tcHV0ZXIgc3lzdGVtLiBJID5yZW1lbWJlciBSQVQgKFJlYWwgQXVkaW8gVG9v bCkgbG9va2luZyBhdCB0aGUgbG9nZ2VkIGluIHVzZXIgb24gVU5JWCBhbmQgPnB1dHRpbmcgInVz ZXIiIG9uIFdpbmRvd3MuDQoNCldlbGwsIGlzIEFOWU9ORSBwdXR0aW5nIGEgdXNlciBuYW1lIHRo ZXJlIHRvZGF5PyBJIGhhdmUgb25seSBzZWVuIOKAnC3igJwuDQoNCkFuZCwgYWdhaW4sIHdpdGgg U0lQIHlvdSBhcmUgZ29pbmcgdG8gaGF2ZSBhbGwgdXNlci1yZWxhdGVkIGluZm9ybWF0aW9uIGlu IHRoZSBTSVAgc2lnbmFsbGluZy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIFR1 ZSwgRGVjIDEyLCAyMDE3IGF0IDM6MjIgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KSGkgUm9tYW4sDQoNCldoYXQgdXNlciBJRCBpcyB0aGUgdGV4dCB0YWxraW5n IGFib3V0PyBUaGUgdXNlciBJRCBvZiBteSBjb21wdXRlcj8gVGhlIHVzZXIgSUQgb2YgbXkgVm9J UCBhcHBsaWNhdGlvbj8gQW55IHVzZXIgSUQ/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K RnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPG1haWx0bzpyb21h bkB0ZWx1cml4LmNvbT5dDQpTZW50OiAxMiBEZWNlbWJlciAyMDE3IDIxOjIwDQpUbzogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NCkNjOiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1t dXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSA0NTY2YmlzOiBzZW5kaW5nIHVz ZXIgSUQgaW4gbz0NCg0KSGkgQ2hyaXN0ZXIsDQoNCkkgZG8gbm90IHNlZSBhbnkgcmVhc29uIHdo eSB1c2VyIHNob3VsZCBiZSBwcm9oaWJpdGVkIGZyb20gc2VuZGluZyB0aGVpciB1c2VyIElELCBp ZiB0aGV5IGRvIG5vIGNhcmUgYWJvdXQgcHJpdmFjeS4NCg0KSSB3b3VsZCByZXBocmFzZSB0aGlz IGFzOg0KDQo8dXNlcm5hbWU+IGlzIHRoZSB1c2VyJ3MgbG9naW4gb24gdGhlIG9yaWdpbmF0aW5n IGhvc3QuIElmIHRoZSBvcmlnaW5hdGlvbiBob3N0IGRvZXMgbm90IHN1cHBvcnQgdGhlIGNvbmNl cHQgb2YgdXNlciBJRHMgb3IgaWYgdGhlcmUgYXJlIGFueSBjb25jZXJucyBvZiBlbmQgdXNlciBw cml2YWN5LCAiLSIgU0hPVUxEIGJlIHVzZWQgYXMgdGhlIDx1c2VybmFtZT4gdmFsdWUuIFRoZSA8 dXNlcm5hbWU+IG11c3Qgbm90IGNvbnRhaW4gc3BhY2VzLg0KDQpfX19fX19fX19fX19fDQpSb21h biBTaHBvdW50DQoNCk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDU6NTIgQU0sIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkFzIEkgaGF2ZSBub3QgZm9sbG93 ZWQgYWxsIGRpc2N1c3Npb25zIG9uIDQ1NjZiaXMsIHNvIHBsZWFzZSBsZXQgbWUga25vdyBpZiB0 aGUgZm9sbG93aW5nIGhhcyBiZWVuIGRpc2N1c3NlZC4NCg0KUmVnYXJkaW5nIHRoZSDigJxvPeKA nCBwYXJhbWV0ZXIsIHRoZSB0ZXh0IHNheXM6DQoNCjx1c2VybmFtZT4gIGlzIHRoZSB1c2VyJ3Mg bG9naW4gb24gdGhlIG9yaWdpbmF0aW5nIGhvc3QsIG9yIGl0IGlzICItIg0KDQogICAgICAgICAg ICBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBjb25jZXB0IG9m IHVzZXIgSURzLg0KDQogICAgICAgICAgICBUaGUgPHVzZXJuYW1lPiBNVVNUIE5PVCBjb250YWlu IHNwYWNlcy4NCg0KRXZlbiBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBzdXBwb3J0cyDigJx0aGUg Y29uY2VwdCBvZiB1c2VyIElEc+KAnSAod2hhdGV2ZXIgdGhhdCBtZWFucyksIGl0IG1heSBub3Qg d2FudCB0byBzZW5kIGl0IGZvciBwcml2YWN5IHJlYXNvbnMuDQoNCg0KDQpDb3VsZG7igJl0IHdl IGluc3RlYWQgc2F5IFNIT1VMRCBzZW5kIOKAnC3igJwsIGJ1dCBNVVNUIGJlIGFibGUgdG8gcmVj ZWl2ZSB3aGF0ZXZlciAoZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkpPw0KDQoNCg0KUmVnYXJk cywNCg0KDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9y ZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C051282ESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SSB0aGlu ayB0aGUgb3JpZ2luYWwgaW50ZW50IHdhcyB0aGUgbG9nZ2VkIGluIHVzZXIgaW4gdGhlIGNvbXB1 dGVyIHN5c3RlbS4gSQ0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+cmVt ZW1iZXIgUkFUIChSZWFsIEF1ZGlvIFRvb2wpIGxvb2tpbmcgYXQgdGhlIGxvZ2dlZCBpbiB1c2Vy IG9uIFVOSVggYW5kDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5wdXR0 aW5nICZxdW90O3VzZXImcXVvdDsgb24gV2luZG93cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2VsbCwgaXMgQU5ZT05FIHB1dHRpbmcgYSB1c2VyIG5h bWUgdGhlcmUgdG9kYXk/IEkgaGF2ZSBvbmx5IHNlZW4g4oCcLeKAnC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgYWdhaW4sIHdpdGggU0lQIHlvdSBhcmUg Z29pbmcgdG8gaGF2ZSBhbGwgdXNlci1yZWxhdGVkIGluZm9ybWF0aW9uIGluIHRoZSBTSVAgc2ln bmFsbGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDM6 MjIgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBSb21hbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5XaGF0IHVzZXIgSUQgaXMgdGhlIHRleHQgdGFsa2luZyBhYm91dD8gVGhlIHVzZXIg SUQgb2YgbXkgY29tcHV0ZXI/IFRoZSB1c2VyIElEIG9mIG15IFZvSVAgYXBwbGljYXRpb24/DQog QW55IHVzZXIgSUQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tNzMyMzkxMTYzMjQ1MDEzMTE2 NV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFJvbWFuDQogU2hwb3VudCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpy b21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBEZWNlbWJlciAyMDE3IDIxOjIwPGJyPg0KPGI+VG86PC9i PiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW01NVVNJQ10gNDU2NmJpczogc2VuZGluZyB1c2VyIElEIGluIG89PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgQ2hyaXN0 ZXIsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBk byBub3Qgc2VlIGFueSByZWFzb24gd2h5IHVzZXIgc2hvdWxkIGJlIHByb2hpYml0ZWQgZnJvbSBz ZW5kaW5nIHRoZWlyIHVzZXIgSUQsIGlmIHRoZXkgZG8gbm8gY2FyZSBhYm91dCBwcml2YWN5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSB3b3VsZCByZXBocmFzZSB0aGlzIGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7dXNlcm5hbWUmZ3Q7IGlzIHRoZSB1c2VyJ3MgbG9naW4g b24gdGhlIG9yaWdpbmF0aW5nIGhvc3QuIElmIHRoZSBvcmlnaW5hdGlvbiBob3N0IGRvZXMgbm90 IHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgdXNlciBJRHMgb3IgaWYgdGhlcmUgYXJlIGFueSBjb25j ZXJucyBvZiBlbmQgdXNlciBwcml2YWN5LCAmcXVvdDstJnF1b3Q7IFNIT1VMRA0KIGJlIHVzZWQg YXMgdGhlICZsdDt1c2VybmFtZSZndDsgdmFsdWUuIFRoZSAmbHQ7dXNlcm5hbWUmZ3Q7IG11c3Qg bm90IGNvbnRhaW4gc3BhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4g U2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBUdWUsIERlYyAxMiwgMjAxNyBhdCA1OjUyIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFzIEkgaGF2ZSBub3QgZm9sbG93ZWQg YWxsIGRpc2N1c3Npb25zIG9uIDQ1NjZiaXMsIHNvIHBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGUg Zm9sbG93aW5nIGhhcyBiZWVuIGRpc2N1c3NlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZGluZyB0 aGUg4oCcbz3igJwgcGFyYW1ldGVyLCB0aGUgdGV4dCBzYXlzOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9y bWFsO3dvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZsdDt1c2VybmFtZSZndDsmbmJzcDsgaXMgdGhlIHVzZXIncyBsb2dp biBvbiB0aGUgb3JpZ2luYXRpbmcgaG9zdCwgb3IgaXQgaXMgJnF1b3Q7LSZxdW90Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBjb25jZXB0IG9m IHVzZXIgSURzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgJmx0O3VzZXJuYW1lJmd0OyBNVVNUIE5PVCBjb250YWlu IHNwYWNlcy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDt3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFj ZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RXZlbiBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBzdXBw b3J0cyDigJx0aGUgY29uY2VwdCBvZiB1c2VyIElEc+KAnSAod2hhdGV2ZXIgdGhhdCBtZWFucyks IGl0IG1heSBub3Qgd2FudCB0byBzZW5kIGl0IGZvciBwcml2YWN5IHJlYXNvbnMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5D b3VsZG7igJl0IHdlIGluc3RlYWQgc2F5IFNIT1VMRCBzZW5kIOKAnC3igJwsIGJ1dCBNVVNUIGJl IGFibGUgdG8gcmVjZWl2ZSB3aGF0ZXZlciAoZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkpPzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B6C051282ESESSMB109erics_-- From nobody Tue Dec 12 12:49:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89143127369 for ; Tue, 12 Dec 2017 12:49:19 -0800 (PST) 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 MaINQKHg51nl for ; Tue, 12 Dec 2017 12:49:17 -0800 (PST) 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 C91B912726E for ; Tue, 12 Dec 2017 12:49:15 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-2b-5a3040ca714d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 71.33.13339.AC0403A5; Tue, 12 Dec 2017 21:49:14 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 21:49:13 +0100 From: Christer Holmberg To: Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqaNAAXaAgAAl+aCAAAFnsP//8koAgAAReaA= Date: Tue, 12 Dec 2017 20:49:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0512BD@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051222@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C0512BDESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7ve4pB4MogwezBS2mLn/MYjHjwlRm ByaPJUt+MnncmlIQwBTFZZOSmpNZllqkb5fAlbFz2mnWgkc9TBW/5t5gamC808rUxcjJISFg IrHq+zMgm4tDSOAwo8S/RQfZIZwljBKH9m9g7mLk4GATsJDo/qcN0iAioCrx9/tkJpAws4C6 xNXFQSBhYQEjiSszZrBBlBhLHGyYzQph+0lcX/iGEcRmAWpdMuMxC4jNK+ArMe3EdKhVF5kk 3jf3gxVxCgRKHDr4EqyIUUBM4vupNWCHMguIS9x6Mh/qaAGJJXvOM0PYohIvH/9jhbCVJBqX PGGFuC1fYtdGD4hdghInZz5hmcAoMgvJpFkIVbOQVEGENSXW79KHqFaUmNL9kB3C1pBonTOX HVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAmDq45bfqDsbLbxwPMQpwMCrx8BbY GEQJsSaWFVfmHmKU4GBWEuHtbtKPEuJNSaysSi3Kjy8qzUktPsQozcGiJM570pM3SkggPbEk NTs1tSC1CCbLxMEp1cDYHeb9rGVrRJ3mfoEo1zMznF7dXJxbMan26Y/H3+dfml+SPu97VuqE kLeeDz+cO3vv4LqC6fu02q5ILHhfuqssaP+UqRUbMiuyrSb1zfn48CL/iat/f78+3//f+Mm1 +NYc5n8cc1Q0XzaKc/IdWbNs/4kuwz9CDxq/SXx4XPrP7M6rqkXvY6ItdJRYijMSDbWYi4oT Ab2YDg2lAgAA Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 20:49:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C0512BDESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGUgaXNzdWUgaXMsIG9uY2UgYWdhaW4sIHRoaXJkIHBhcnR5IGNhbGwgY29udHJv bCBhbmQgdW5leHBlY3RlZCBTRFAgb2ZmZXIgY29sbGlzaW9ucyBiZXR3ZWVuIHR3byBTSVAgc2Vz c2lvbnMuIEJlY2F1c2Ugb2YgdGhpcywgaWYgb2ZmZXIgZ29lcyBmcm9tIG9uZSBTSVAgPnNlc3Np b24gdG8gYW5vdGhlciBkdWUgdG8gQjJCVUEgYW5kIHRoaXJkIHBhcnR5IGNhbGwgY29udHJvbCwg aXQgaXMgaW1wb3J0YW50IHRoYXQgbz0gbGluZSBhY2NpZGVudGFsbHkgZGlkIG5vdCBlbmQgdXAg YmVpbmcgdGhlIHNhbWUgYmV0d2VlbiB0d28gc2Vzc2lvbnMuIElmID5vPSBsaW5lIGlzIHRoZSBz YW1lLCBzb21lIGNsaWVudHMgZG8gbm90IHBhcnNlIG9yIGNvbXBhcmUgU0RQLCBhc3N1bWluZyB0 aGlzIGlzIHRoZSBzYW1lIFNEUCBkZXNjcmlwdGlvbi4gQmVjYXVzZSBvZiB0aGlzLCBpdCBpcyBp bXBvcnRhbnQgZm9yIG89IGxpbmUgdG8gYmUgPmdsb2JhbGx5IHVuaXF1ZS4gT25lIG9wdGlvbiBp cyB0byB1c2UgdW5pcXVlIHN5c3RlbSBpZGVudGlmaWVyIChJUCBvciBob3N0IG5hbWUpLCBzZXNz aW9uIGlkZW50aWZpZXIgYW5kIHZlcnNpb24gaW4gdGhlIHNlc3Npb24uIEFub3RoZXIgb3B0aW9u IGlzIHRvIHVzZSA+c29tZXRoaW5nIHJhbmRvbSB3aGljaCBpcyBsb25nIGVub3VnaCB0byBiZSB1 bmlxdWUuDQoNCkZhaXIgZW5vdWdoLg0KDQo+V2hlbiBvZmZlciBpcyBnZW5lcmF0ZWQgd2hlbiBJ Q0UgaXMgdXNlZCwgY2xpZW50IG1pZ2h0IG5vdCBrbm93IHRoZSBnbG9iYWxseSB1bmlxdWUgSVAg YWRkcmVzcyB3aGVuIG9mZmVyIGlzIGdlbmVyYXRlZC4gQ2xpZW50IGNhbiB1c2UgbG9jYWwgTkFU ZWQgPmFkZHJlc3MsIGJ1dCB0aGlzIG9mdGVuIHJlc3VsdHMgaW4gY29sbGlzaW9ucy4gVGhlIGFj dHVhbCBhZHZpc2UgZm9yIHRoaXMgY2FzZSAodXNlIGxvY2FsIElQKSBpcyBhY3R1YWxseSBjb3Vu dGVyIHByb2R1Y3RpdmUsIHNpbmNlIHVzaW5nIGxvY2FsIElQIGlzIG1vcmUgbGlrZWx5IHRvID5y ZXN1bHQgaW4gY29sbGlzaW9ucyB0aGVuIHVzaW5nIHNvbWV0aGluZyByYW5kb20uIFRoaXMgcHJv YmFibHkgbmVlZHMgdG8gYmUgY29ycmVjdGVkLg0KDQpBbHNvLCB0aGUgYWRkcmVzcyBpcyBzdXBw b3NlZCB0byBiZSDigJx0aGUgYWRkcmVzcyBvZiB0aGUgbWFjaGluZSBmcm9tIHdoaWNoIHRoZSBz ZXNzaW9uIHdhcyBjcmVhdGVk4oCdLiBUaGF0IGFkZHJlc3MgaXMgd2hhdGV2ZXIgaXMgdGhlIHNh bWUsIG5vIG1hdHRlciBpZiB5b3UgaGF2ZSBOQVRzIG9yIG5vdC4gTm90ZSB0aGF0IHRoZSB0ZXh0 IGRvZXMgbm90IG1hbmRhdGUgdGhlIGFkZHJlc3MgdGhhdCB5b3UgYXJlIGdvaW5nIHRvIHVzZSBm b3IgbWVkaWEgZXRjIOKAkyBqdXN0ICpBTiogYWRkcmVzcyBvZiB0aGUgbWFjaGluZS4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KT24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgMzoyOCBQ TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSSBzZWVt cyBsaWtlIEkgcGxhY2VkIGEgcXVlc3Rpb24gaW4gdGhlIHdyb25nIHBsYWNlLg0KDQpJdCBzaG91 bGQgYmU6DQoNCuKAnEkgdW5kZXJzdGFuZCB0aGF0LCBidXQgSSBkb27igJl0IHNlZSB3aGF0IElD RSBoYXMgdG8gZG8gd2l0aCBpdC4gSG93IGlzIHVzaW5nIGEgbG9jYWwgYWRkcmVzcyBnb2luZyB0 byBtYWtlIHRoZSBTRFAgdW5pcXVlIGp1c3QgYmVjYXVzZSBJIHVzZSBJQ0U/4oCdDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIENo cmlzdGVyIEhvbG1iZXJnDQpTZW50OiAxMiBEZWNlbWJlciAyMDE3IDIyOjI1DQpUbzogUm9tYW4g U2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkNj OiBtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb TU1VU0lDXSA0NTY2YmlzOiBsb2NhbCBhZGRyZXNzIGluIG89DQoNCkhpLA0KDQo+SSB0aGluayB0 aGUgaW50ZW50IGhlcmUgaXMgdG8gZ2VuZXJhdGUgc29tZXRoaW5nIHNpbWlsYXIgdG8gR1VJRCB3 aGljaCB3aWxsIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSBTRFAgZGVzY3JpcHRpb24sDQoNCkkgdW5k ZXJzdGFuZCB0aGF0LCBidXQgSSBkb27igJl0IHNlZSB3aGF0IElDRSBoYXMgdG8gZG8gd2l0aCBp dC4NCg0KPiBidXQgdGhpcyBpcyBzZXZlcmVseSBvdXRkYXRlZCBmb3IgY2FzZXMgbGlrZSBJQ0Ug b3IgcHJpdmFjeS4gSG93IGlzIHVzaW5nIGEgbG9jYWwgYWRkcmVzcyBnb2luZyB0byBtYWtlIHRo ZSBTRFAgdW5pcXVlIGp1c3QgYmVjYXVzZSBJIHVzZSBJQ0U/DQo+DQo+IEkgdGhpbmsgdGhpcyBu ZWVkcyB0byBiZSB1cGRhdGVkIHRvIHVzZSBzdWZmaWNpZW50bHkgbGFyZ2UgcmFuZG9tIHN0cmlu Z3MgaW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMsIGhvc3RuYW1lcyBhbmQNCj4gdXNlciBJRHMsIHdo ZW4gbG9jYWwgYWRkcmVzcyBvciBob3N0IG5hbWUgaXMgbm90IGF2YWlsYWJsZSBvciBzaG91bGQg bm90IGJlIGV4cG9zZWQgZHVlIHRvIHByaXZhY3kgcmVhc29ucy4NCg0KV2l0aCBTSVAgYW5kIG9m ZmVyL2Fuc3dlciwgaXMgdGhlcmUgZXZlbiBhIG5lZWQgdG8gdW5pcXVlbHkgaWRlbnRpdHkgdGhl IFNEUCBkZXNjcmlwdGlvbj8gVGhlIFNEUCB3aWxsIGFsd2F5cyBiZSBhc3NvY2lhdGVkIHdpdGgg YSB1bmlxdWVseSBpZGVudGlmaWVkIFNJUCBzZXNzaW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KDQoNCk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDY6MzMgQU0sIENocmlzdGVyIEhv bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNClRoZSB0ZXh0IHNheXM6DQoNCjx1 bmljYXN0LWFkZHJlc3M+IGlzIGFuIGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUgZnJvbSB3aGljaCB0 aGUNCg0KICAgICAgICAgICAgICAgICAgIHNlc3Npb24gd2FzIGNyZWF0ZWQuIEZvciBhbiBhZGRy ZXNzIHR5cGUgb2YgSVA0LCB0aGlzIGlzIGVpdGhlciBhDQoNCiAgICAgICAgICAgICAgICAgICBm dWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIG1hY2hpbmUgb3IgdGhlIGRvdHRlZC1k ZWNpbWFsDQoNCiAgICAgICAgICAgICAgICAgICByZXByZXNlbnRhdGlvbiBvZiBhbiBJUCB2ZXJz aW9uIDQgYWRkcmVzcyBvZiB0aGUgbWFjaGluZS4gRm9yIGFuDQoNCiAgICAgICAgICAgICAgICAg ICBhZGRyZXNzIHR5cGUgb2YgSVA2LCB0aGlzIGlzIGVpdGhlciBhIGZ1bGx5IHF1YWxpZmllZCBk b21haW4gbmFtZQ0KDQogICAgICAgICAgICAgICAgICAgb2YgdGhlIG1hY2hpbmUgb3IgdGhlIGNv bXByZXNzZWQgdGV4dHVhbCByZXByZXNlbnRhdGlvbiBvZiBhbiBJUA0KDQogICAgICAgICAgICAg ICAgICAgdmVyc2lvbiA2IGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUuIEZvciBib3RoIElQNCBhbmQg SVA2LCB0aGUgZnVsbHkNCg0KICAgICAgICAgICAgICAgICAgIHF1YWxpZmllZCBkb21haW4gbmFt ZSBpcyB0aGUgZm9ybSB0aGF0IFNIT1VMRCBiZSBnaXZlbiB1bmxlc3MgdGhpcw0KDQogICAgICAg ICAgICAgICAgICAgaXMgdW5hdmFpbGFibGUsIGluIHdoaWNoIGNhc2UgYSBnbG9iYWxseSB1bmlx dWUgYWRkcmVzcyBNQVkgYmUNCg0KICAgICAgICAgICAgICAgICAgIHN1YnN0aXR1dGVkLiBVbmxl c3MgYW4gU0RQIGV4dGVuc2lvbiBmb3IgTkFUIHRyYXZlcnNhbCBpcyB1c2VkDQoNCiAgICAgICAg ICAgICAgICAgICAoZS5nLiwgSUNFIFtSRkM1MjQ1XSwgSUNFIFRDUCBbUkZDNjU0NF0pLCBhIGxv Y2FsIElQIGFkZHJlc3MgTVVTVA0KDQogICAgICAgICAgICAgICAgICAgTk9UIGJlIHVzZWQgaW4g YW55IGNvbnRleHQgd2hlcmUgdGhlIFNEUCBkZXNjcmlwdGlvbiBtaWdodCBsZWF2ZQ0KDQogICAg ICAgICAgICAgICAgICAgdGhlIHNjb3BlIGluIHdoaWNoIHRoZSBhZGRyZXNzIGlzIG1lYW5pbmdm dWwgKGZvciBleGFtcGxlLCBhIGxvY2FsDQoNCiAgICAgICAgICAgICAgICAgICBhZGRyZXNzIE1V U1QgTk9UIGJlIGluY2x1ZGVkIGluIGFuIGFwcGxpY2F0aW9uLWxldmVsIHJlZmVycmFsIHRoYXQN Cg0KICAgICAgICAgICAgICAgICAgIG1pZ2h0IGxlYXZlIHRoZSBzY29wZSkuDQoNCkZpcnN0LCBJ IGd1ZXNzIGl0IGNvdWxkIGJlIGNsYXJpZmllZCB0aGF0IHRoZSDigJxhZGRyZXNzIG9mIHRoZSBt YWNoaW5l4oCdIGRvZXMgbm90IGhhdmUgdG8gYmUgdGhlIGFkZHJlc3MgdXNlZCBmb3IgdGhlIG1l ZGlhIChmb3VuZCBpbiB0aGUgYz0gbGluZSkuDQoNCg0KDQpTZWNvbmQsIEkgYW0gbm90IHN1cmUg SSB1bmRlcnN0YW5kIGhvdyB0aGUgc3VwcG9ydCBvZiBJQ0UgYWxsb3dzIHRoZSB1c2FnZSBvZiBh IGxvY2FsIGFkZHJlc3MuIFRoZSBjb21iaW5hdGlvbiBvZiBvPSBsaW5lIHBhcnRzIGFyZSBzdXBw b3NlZCB0byBjcmVhdGUgYSB1bmlxdWUgaWRlbnRpZmllciwgc28gd2hhdCBkb2VzIElDRSBoYXZl IHRvIGRvIHdpdGggdGhhdD8NCg0KDQoNClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B6C0512BDESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDtUaGUgaXNzdWUgaXMsIG9uY2UgYWdhaW4sIHRoaXJkIHBhcnR5IGNhbGwgY29udHJv bCBhbmQgdW5leHBlY3RlZCBTRFAgb2ZmZXIgY29sbGlzaW9ucyBiZXR3ZWVuIHR3byBTSVAgc2Vz c2lvbnMuIEJlY2F1c2Ugb2YgdGhpcywgaWYgb2ZmZXIgZ29lcyBmcm9tIG9uZSBTSVAgJmd0O3Nl c3Npb24gdG8gYW5vdGhlciBkdWUgdG8gQjJCVUEgYW5kIHRoaXJkIHBhcnR5IGNhbGwgY29udHJv bCwgaXQgaXMgaW1wb3J0YW50DQogdGhhdCBvPSBsaW5lIGFjY2lkZW50YWxseSBkaWQgbm90IGVu ZCB1cCBiZWluZyB0aGUgc2FtZSBiZXR3ZWVuIHR3byBzZXNzaW9ucy4gSWYgJmd0O289IGxpbmUg aXMgdGhlIHNhbWUsIHNvbWUgY2xpZW50cyBkbyBub3QgcGFyc2Ugb3IgY29tcGFyZSBTRFAsIGFz c3VtaW5nIHRoaXMgaXMgdGhlIHNhbWUgU0RQIGRlc2NyaXB0aW9uLiBCZWNhdXNlIG9mIHRoaXMs IGl0IGlzIGltcG9ydGFudCBmb3Igbz0gbGluZSB0byBiZSAmZ3Q7Z2xvYmFsbHkgdW5pcXVlLg0K IE9uZSBvcHRpb24gaXMgdG8gdXNlIHVuaXF1ZSBzeXN0ZW0gaWRlbnRpZmllciAoSVAgb3IgaG9z dCBuYW1lKSwgc2Vzc2lvbiBpZGVudGlmaWVyIGFuZCB2ZXJzaW9uIGluIHRoZSBzZXNzaW9uLiBB bm90aGVyIG9wdGlvbiBpcyB0byB1c2UgJmd0O3NvbWV0aGluZyByYW5kb20gd2hpY2ggaXMgbG9u ZyBlbm91Z2ggdG8gYmUgdW5pcXVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZhaXIgZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1doZW4g b2ZmZXIgaXMgZ2VuZXJhdGVkIHdoZW4gSUNFIGlzIHVzZWQsIGNsaWVudCBtaWdodCBub3Qga25v dyB0aGUgZ2xvYmFsbHkgdW5pcXVlIElQIGFkZHJlc3Mgd2hlbiBvZmZlciBpcyBnZW5lcmF0ZWQu IENsaWVudCBjYW4gdXNlIGxvY2FsIE5BVGVkICZndDthZGRyZXNzLCBidXQgdGhpcyBvZnRlbiBy ZXN1bHRzIGluIGNvbGxpc2lvbnMuIFRoZSBhY3R1YWwgYWR2aXNlIGZvciB0aGlzIGNhc2UgKHVz ZSBsb2NhbA0KIElQKSBpcyBhY3R1YWxseSBjb3VudGVyIHByb2R1Y3RpdmUsIHNpbmNlIHVzaW5n IGxvY2FsIElQIGlzIG1vcmUgbGlrZWx5IHRvICZndDtyZXN1bHQgaW4gY29sbGlzaW9ucyB0aGVu IHVzaW5nIHNvbWV0aGluZyByYW5kb20uIFRoaXMgcHJvYmFibHkgbmVlZHMgdG8gYmUgY29ycmVj dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkFsc28sIHRoZSBhZGRyZXNzIGlzIHN1cHBvc2VkIHRvIGJlIOKAnHRoZSBhZGRyZXNzIG9m IHRoZSBtYWNoaW5lIGZyb20gd2hpY2ggdGhlIHNlc3Npb24gd2FzIGNyZWF0ZWTigJ0uIFRoYXQg YWRkcmVzcyBpcyB3aGF0ZXZlciBpcyB0aGUgc2FtZSwgbm8gbWF0dGVyIGlmIHlvdSBoYXZlIE5B VHMgb3Igbm90Lg0KIE5vdGUgdGhhdCB0aGUgdGV4dCBkb2VzIG5vdCBtYW5kYXRlIHRoZSBhZGRy ZXNzIHRoYXQgeW91IGFyZSBnb2luZyB0byB1c2UgZm9yIG1lZGlhIGV0YyDigJMganVzdCAqPGI+ QU48L2I+KiBhZGRyZXNzIG9mIHRoZSBtYWNoaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgMzoyOCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgc2VlbXMgbGlrZSBJIHBsYWNlZCBhIHF1 ZXN0aW9uIGluIHRoZSB3cm9uZyBwbGFjZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCBzaG91bGQgYmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJxJIHVuZGVy c3RhbmQgdGhhdCwgYnV0IEkgZG9u4oCZdCBzZWUgd2hhdCBJQ0UgaGFzIHRvIGRvIHdpdGggaXQu IEhvdyBpcyB1c2luZyBhIGxvY2FsIGFkZHJlc3MgZ29pbmcgdG8gbWFrZSB0aGUgU0RQIHVuaXF1 ZSBqdXN0IGJlY2F1c2UgSSB1c2UgSUNFP+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNocmlzdGVyPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxh IG5hbWU9Im1fNjY2NTU5OTgwNjAwNDk2NzUyMV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMNCiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVz aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYu b3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5T ZW50OjwvYj4gMTIgRGVjZW1iZXIgMjAxNyAyMjoyNTxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hw b3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFu ayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIDQ1NjZiaXM6IGxvY2FsIGFkZHJlc3Mg aW4gbz08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDtJIHRoaW5rIHRoZSBpbnRlbnQg aGVyZSBpcyB0byBnZW5lcmF0ZSBzb21ldGhpbmcgc2ltaWxhciB0byBHVUlEIHdoaWNoIHdpbGwg dW5pcXVlbHkgaWRlbnRpZnkgdGhlIFNEUCBkZXNjcmlwdGlvbiw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB1bmRl cnN0YW5kIHRoYXQsIGJ1dCBJIGRvbuKAmXQgc2VlIHdoYXQgSUNFIGhhcyB0byBkbyB3aXRoIGl0 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZndDsgYnV0IHRoaXMgaXMgc2V2ZXJlbHkgb3V0ZGF0ZWQgZm9yIGNhc2VzIGxpa2UgSUNF IG9yIHByaXZhY3kuIEhvdyBpcyB1c2luZyBhIGxvY2FsIGFkZHJlc3MgZ29pbmcgdG8gbWFrZSB0 aGUgU0RQIHVuaXF1ZSBqdXN0IGJlY2F1c2UgSSB1c2UgSUNFPzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IEkgdGhpbmsgdGhpcyBuZWVk cyB0byBiZSB1cGRhdGVkIHRvIHVzZSBzdWZmaWNpZW50bHkgbGFyZ2UgcmFuZG9tIHN0cmluZ3Mg aW5zdGVhZCBvZiBJUCBhZGRyZXNzZXMsIGhvc3RuYW1lcyBhbmQmbmJzcDsNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bh bj51c2VyIElEcywgd2hlbiBsb2NhbCBhZGRyZXNzIG9yIGhvc3QgbmFtZSBpcyBub3QgYXZhaWxh YmxlIG9yIHNob3VsZCBub3QgYmUgZXhwb3NlZCBkdWUgdG8gcHJpdmFjeSByZWFzb25zLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5XaXRoIFNJUCBhbmQgb2ZmZXIvYW5zd2VyLCBpcyB0aGVyZSBldmVuIGEgbmVlZCB0 byB1bmlxdWVseSBpZGVudGl0eSB0aGUgU0RQIGRlc2NyaXB0aW9uPyBUaGUgU0RQIHdpbGwgYWx3 YXlzIGJlDQogYXNzb2NpYXRlZCB3aXRoIGEgdW5pcXVlbHkgaWRlbnRpZmllZCBTSVAgc2Vzc2lv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3Rl cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5PbiBUdWUsIERlYyAxMiwgMjAxNyBhdCA2OjMzIEFNLCBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IHNheXM6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbHQ7dW5pY2FzdC1hZGRyZXNzJmd0OyBpcyBhbiBhZGRyZXNzIG9mIHRoZSBt YWNoaW5lIGZyb20gd2hpY2ggdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7d29yZC13cmFwOmJy ZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlc3Np b24gd2FzIGNyZWF0ZWQuIEZvciBhbiBhZGRyZXNzIHR5cGUgb2YgSVA0LCB0aGlzIGlzIGVpdGhl ciBhPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZ1 bGx5IHF1YWxpZmllZCBkb21haW4gbmFtZSBvZiB0aGUgbWFjaGluZSBvciB0aGUgZG90dGVkLWRl Y2ltYWw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg cmVwcmVzZW50YXRpb24gb2YgYW4gSVAgdmVyc2lvbiA0IGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmUu IEZvciBhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBhZGRyZXNzIHR5cGUgb2YgSVA2LCB0aGlzIGlzIGVpdGhlciBhIGZ1bGx5IHF1YWxpZmllZCBk b21haW4gbmFtZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBvZiB0aGUgbWFjaGluZSBvciB0aGUgY29tcHJlc3NlZCB0ZXh0dWFsIHJlcHJlc2VudGF0 aW9uIG9mIGFuIElQPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHZlcnNpb24gNiBhZGRyZXNzIG9mIHRoZSBtYWNoaW5lLiBGb3IgYm90aCBJUDQgYW5k IElQNiwgdGhlIGZ1bGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHF1YWxpZmllZCBkb21haW4gbmFtZSBpcyB0aGUgZm9ybSB0aGF0IFNIT1VMRCBi ZSBnaXZlbiB1bmxlc3MgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBpcyB1bmF2YWlsYWJsZSwgaW4gd2hpY2ggY2FzZSBhIGdsb2JhbGx5IHVu aXF1ZSBhZGRyZXNzIE1BWSBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBzdWJzdGl0dXRlZC4gVW5sZXNzIGFuIFNEUCBleHRlbnNpb24gZm9yIE5B VCB0cmF2ZXJzYWwgaXMgdXNlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAoZS5nLiwgSUNFIFtSRkM1MjQ1XSwgSUNFIFRDUCBbUkZDNjU0NF0pLCBh IGxvY2FsIElQIGFkZHJlc3MgTVVTVDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBOT1QgYmUgdXNlZCBpbiBhbnkgY29udGV4dCB3aGVyZSB0aGUgU0RQ IGRlc2NyaXB0aW9uIG1pZ2h0IGxlYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBzY29wZSBpbiB3aGljaCB0aGUgYWRkcmVzcyBpcyBtZWFu aW5nZnVsIChmb3IgZXhhbXBsZSwgYSBsb2NhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzIE1VU1QgTk9UIGJlIGluY2x1ZGVkIGluIGFu IGFwcGxpY2F0aW9uLWxldmVsIHJlZmVycmFsIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWlnaHQgbGVhdmUgdGhlIHNjb3BlKS48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1 cmVzOm5vcm1hbDt3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Rmlyc3QsIEkgZ3Vlc3MgaXQgY291bGQgYmUgY2xhcmlmaWVkIHRoYXQgdGhlIOKA nGFkZHJlc3Mgb2YgdGhlIG1hY2hpbmXigJ0gZG9lcyBub3QgaGF2ZSB0byBiZSB0aGUgYWRkcmVz cyB1c2VkIGZvciB0aGUgbWVkaWEgKGZvdW5kIGluIHRoZSBjPSBsaW5lKS48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNlY29u ZCwgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgaG93IHRoZSBzdXBwb3J0IG9mIElDRSBhbGxv d3MgdGhlIHVzYWdlIG9mIGEgbG9jYWwgYWRkcmVzcy4gVGhlIGNvbWJpbmF0aW9uIG9mIG89IGxp bmUgcGFydHMgYXJlIHN1cHBvc2VkIHRvIGNyZWF0ZSBhIHVuaXF1ZSBpZGVudGlmaWVyLCBzbyB3 aGF0IGRvZXMgSUNFIGhhdmUgdG8gZG8gd2l0aCB0aGF0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6C0512BDESESSMB109erics_-- From nobody Tue Dec 12 13:18:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0816A12955F for ; Tue, 12 Dec 2017 13:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcroE6favubC for ; Tue, 12 Dec 2017 13:18:04 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 BA1331287A3 for ; Tue, 12 Dec 2017 13:18:04 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id j4so184325pgp.1 for ; Tue, 12 Dec 2017 13:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bJTsliiaX0scdwcHWi5vYtaBZAC4du3I8Aq+gg5u/QI=; b=So2ChE6WVAvQMNrCWfvxYCU1JOAW2Xn4IoG4akwL2938ArDEka8rliS+1yBdOvTYbp uTwnySD7js+GRpZx5h2+x/AVyuXhEigt0QDQeqB/G0S8n3VabmJ4etIj0V9YssBR44v8 doBwq3OF0xqn9JWnawzt1Hd12UKWPFnXZGC8/zghj8okTROFViE8bIdgULRh2IIZSguj tbIRcY2YxphmnoKqYaOfEh/Pdi1yHCZVkW8U67GnYS5s1HT1oRgHfCPB4EyFpcyn3cvu QCd+Bqe3yE5CW0e67+Q/WDWLDDViUhNhirTKevQG4u0dvgl0Sn0W6bl31mgc8TfU4ZDm Ecqg== 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=bJTsliiaX0scdwcHWi5vYtaBZAC4du3I8Aq+gg5u/QI=; b=PIQX7+jwt51VeRHSjBb378OjElIEUUy8abCrMCueEaezhDegKyis6xCdv0JnkbaFZF IigDtYvNgEgXOQV5LAdBkqQDPyixyv21bHl1PQ+V4KMX4XPKDPlZPY6sWuwS0maaxgPY 5IoFjF89tYlgOE2TEbfvd4hjev6TTxCaZjZJDM7I4rDdwX5+93DdZsyBq1rBiWtVMm6S CUVesI0XK7kkmxrfXM1FmQa0evi10Vu4YdfJ6xz42/b4aAT9d33HQxeo8nQACIbPCLTZ pK66EEN1QI2kD9IjB5oKX9G17h5Yx7QByOKGQK2BXYKyMBAgdhOnqG9Xx4fL3Jj1fRKf Mm/w== X-Gm-Message-State: AKGB3mJhMYwAI0cbPWHz3lVeqHmi4rDg/pwadJB47lhjgPAbVVweWdXz 5tmzZ0v/c8P0by5gYsQRYwdHcK10 X-Google-Smtp-Source: ACJfBot0bupLGZe2fZaa0msQ7PV0G3WsxZImZOEhIBDLi73Mm2G21v7REtDoMnfE2LhEE1Tr+AJ7cg== X-Received: by 10.101.69.68 with SMTP id x4mr3197707pgr.272.1513113483448; Tue, 12 Dec 2017 13:18:03 -0800 (PST) Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com. [209.85.192.179]) by smtp.gmail.com with ESMTPSA id b25sm71571pfd.182.2017.12.12.13.18.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 13:18:02 -0800 (PST) Received: by mail-pf0-f179.google.com with SMTP id n6so191654pfa.4 for ; Tue, 12 Dec 2017 13:18:01 -0800 (PST) X-Received: by 10.84.235.68 with SMTP id g4mr3546139plt.155.1513113481327; Tue, 12 Dec 2017 13:18:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 13:18:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C051282@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051282@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 12 Dec 2017 16:18:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="089e08215cf08f394c05602b2fcb" Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 21:18:07 -0000 --089e08215cf08f394c05602b2fcb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just looking at my proxy logs, I see a few examples (I have obfuscated IP addresses): Sonus: o=3DSonus_UAC 859850 235378 IN IP4 999.999.999.999 BlueJeans: o=3DBlueJeans 3722043602 3722043602 IN IP4 999.999.999.999 Asterisk (Actually gets Unix user): o=3Droot 1311534312 1311534312 IN IP4 999.999.999.999 Firefox: o=3Dmozilla...THIS_IS_SDPARTA-57.0.2 2394261013661016088 0 IN IP4 0.0.0.0 Cisco: o=3DMSSMGC 90576391 0 IN IP4 999.999.999.999 Skype SIP gateway: o=3D3726170464 1513055056 1513055056 IN IP4 999.999.999.= 999 So, I would say putting user or product name in o=3D line is pretty common. Putting product and version can also be useful if call goes through B2BUA which hides SIP signaling, but SDP o=3D and s=3D can still be used to ident= ify the original client software make and version. Regards, _____________ Roman Shpount On Tue, Dec 12, 2017 at 3:38 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >I think the original intent was the logged in user in the computer > system. I >remember RAT (Real Audio Tool) looking at the logged in user > on UNIX and >putting "user" on Windows. > > > > Well, is ANYONE putting a user name there today? I have only seen =E2=80= =9C-=E2=80=9C. > > > > And, again, with SIP you are going to have all user-related information i= n > the SIP signalling. > > > > Regards, > > > > Christer > > > > > > > > On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi Roman, > > > > What user ID is the text talking about? The user ID of my computer? The > user ID of my VoIP application? Any user ID? > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 12 December 2017 21:20 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: sending user ID in o=3D > > > > Hi Christer, > > > > I do not see any reason why user should be prohibited from sending their > user ID, if they do no care about privacy. > > > > I would rephrase this as: > > > > is the user's login on the originating host. If the originatio= n > host does not support the concept of user IDs or if there are any concern= s > of end user privacy, "-" SHOULD be used as the value. The > must not contain spaces. > > > _____________ > Roman Shpount > > > > On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > As I have not followed all discussions on 4566bis, so please let me know > if the following has been discussed. > > > > Regarding the =E2=80=9Co=3D=E2=80=9C parameter, the text says: > > is the user's login on the originating host, or it is "-" > > if the originating host does not support the concept of user = IDs. > > The MUST NOT contain spaces. > > Even if the originating host supports =E2=80=9Cthe concept of user IDs=E2= =80=9D (whatever that means), it may not want to send it for privacy reason= s. > > > > Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST= be able to receive whatever (for backward compatibility)? > > > > Regards, > > > > Christer > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > --089e08215cf08f394c05602b2fcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Just looking at my proxy logs, I se= e a few examples (I have obfuscated IP addresses):

Sonus: o=3DSonus_UAC 859850 235378 IN IP4 999.999.999.999
Bl= ueJeans: o=3DBlueJeans 3722043602 3722043602 IN IP4 999.999.999.999
Asterisk (Actually gets Unix user): o=3Droot 1311534312 1311534312 I= N IP4 999.999.999.999
Firefox: o=3Dmozilla...THIS_IS_SDP= ARTA-57.0.2 2394261013661016088 0 IN IP4 0.0.0.0
Cisco:=C2= =A0o=3DMSSMGC 90576391 0 IN IP4 999.999.999.999
Skype SIP gateway= :=C2=A0o=3D3726170464 1513055056 1513055056 IN IP4 999.999.999.999

So, I would say putting user or product name in o=3D line = is pretty common.

Putting product and version can = also be useful if call goes through B2BUA which hides SIP signaling, but SD= P o=3D and s=3D can still be used to identify the original client software = make and version.

Regards,

_____________
Roman Shpount

On Tue, Dec 12, 2017 at 3:38 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

>I think the= original intent was the logged in user in the computer system. I >remember RAT (Real Audio Tool) loo= king at the logged in user on UNIX and >putting "user" on Window= s.

=C2=A0

Well, is ANYONE putting a user name t= here today? I have only seen =E2=80=9C-=E2=80=9C.

=C2=A0

And, again, with SIP you are going to= have all user-related information in the SIP signalling.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi Roman,

=C2=A0

What user ID is the text talking abou= t? The user ID of my computer? The user ID of my VoIP application? Any user ID?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = Roman Shpount [mailto:rom= an@telurix.com]
Sent: 12 December 2017 21:20
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D=

=C2=A0

Hi Christer,

=C2=A0

I do not see any reason why user should be prohibite= d from sending their user ID, if they do no care about privacy.

=C2=A0

I would rephrase this as:

=C2=A0

<username> is the user's login on the orig= inating host. If the origination host does not support the concept of user = IDs or if there are any concerns of end user privacy, "-" SHOULD be used as the <username> value. The <username> must not conta= in spaces.


_____________
Roman Shpount

=C2=A0

On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As I have not followed all discussions = on 4566bis, so please let me know if the following has been discussed.

=C2=A0

Regarding the =E2=80=9Co=3D=E2=80=9C pa= rameter, the text says:

<username>=C2=A0 is the user&=
#39;s login on the originating host, or it is "-"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 if the originating host does not support the conce=
pt of user IDs.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 The <username> MUST NOT contain spaces.
Even if the originating host supports =E2=80=9Cthe concept of user =
IDs=E2=80=9D (whatever that means), it may not want to send it for privacy =
reasons.
=C2=A0
Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST =
be able to receive whatever (for backward compatibility)?<=
/u>
=C2=A0
Regards,
=C2=A0
Christer=C2=A0
=C2=A0
=C2=A0


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

=C2=A0

=C2=A0


--089e08215cf08f394c05602b2fcb-- From nobody Tue Dec 12 13:48:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F858128AA1 for ; Tue, 12 Dec 2017 13:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qCVhey6B2K8L for ; Tue, 12 Dec 2017 13:48:53 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB6124217 for ; Tue, 12 Dec 2017 13:48:52 -0800 (PST) X-AuditID: 12074411-f7dff70000007f0a-4f-5a304ec31f7f Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 44.86.32522.3CE403A5; Tue, 12 Dec 2017 16:48:51 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vBCLmoun008755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 12 Dec 2017 16:48:51 -0500 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Tue, 12 Dec 2017 16:48:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixO6iqHvYzyDKYP4eLYupyx+zODB6LFny kymAMYrLJiU1J7MstUjfLoEr49+0XvaCReYVGx+KNTAeU+9i5OSQEDCR+P1nJXMXIxeHkMAO JolDq/9AOd+ZJCb/vcgOUiUsYCTxfvFiJhBbREBYYsbbv2wQRReZJN439zOCJNgEtCTmHPrP AmLzCthLTLvwEqiBg4NFQFXi/6o8kLCoQJrEngsdUCWCEidnPgGzOQUCJQ4dfAlmMwuYSczb /JAZwhaXuPVkPhOELS/RvHU28wRG/llI2mchaZmFpGUWkpYFjCyrGOUSc0pzdXMTM3OKU5N1 i5MT8/JSi3RN9XIzS/RSU0o3MUKCUnAH44yTcocYBTgYlXh4HzzQjxJiTSwrrsw9xCjJwaQk yjvF1SBKiC8pP6UyI7E4I76oNCe1+BCjBAezkghvdxNQOW9KYmVValE+TEqag0VJnJdvibqf kEB6YklqdmpqQWoRTFaGg0NJgtfIF2ioYFFqempFWmZOCUKaiYMTZDgP0PBHIDW8xQWJucWZ 6RD5U4zGHD09N/4wcTyb+bqBWYglLz8vVUqc9wJIqQBIaUZpHtw0WGJ5xSgO9JwwbxdIFQ8w KcHNewW0iglo1fMWkD+KSxIRUlINjC49Vf1x+yv7npyZ1rlTOMxMqOLJeQ3Hyt1m91tupRZK C2w9rH5VY8WVc5JfT/eqW992FH3+q0fSniPrlCffV5ODogsaQjrtzni5P+nv/TzhhnTN/9VW FUvaWXZ1hoQ9Ngk8VCj1eUtqpVxd4ap/xTMOSosmvLGovZd9a9OxN1OLV56XlluQr8RSnJFo qMVcVJwIAI8QcocHAwAA Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 21:48:56 -0000 On 12/12/17 3:38 PM, Roman Shpount wrote: > Christer, > > The issue is, once again, third party call control and unexpected SDP > offer collisions between two SIP sessions. Because of this, if offer > goes from one SIP session to another due to B2BUA and third party call > control, it is important that o= line accidentally did not end up being > the same between two sessions. If o= line is the same, some clients do > not parse or compare SDP, assuming this is the same SDP description. > Because of this, it is important for o= line to be globally unique. One > option is to use unique system identifier (IP or host name), session > identifier and version in the session. Another option is to use > something random which is long enough to be unique. As things are currently specified, it isn't valid for the session to change for the duration of the sip dialog. A 3PCC B2BUA is responsible for ensuring this remains the case during a transfer. How it does so is its business, but in the end will require rewriting SDP. However, I realize that doesn't often (ever?) happen. Perhaps there ought to be an effort to change things to acknowledge that the session can change, and specify what is to happen when it does. Thanks, Paul > When offer is generated when ICE is used, client might not know the > globally unique IP address when offer is generated. Client can use local > NATed address, but this often results in collisions. The actual advise > for this case (use local IP) is actually counter productive, since using > local IP is more likely to result in collisions then using something > random. This probably needs to be corrected. > > Regards, > > _____________ > Roman Shpount > > On Tue, Dec 12, 2017 at 3:28 PM, Christer Holmberg > > > wrote: > > Hi,____ > > __ __ > > I seems like I placed a question in the wrong place.____ > > __ __ > > It should be:____ > > __ __ > > “I understand that, but I don’t see what ICE has to do with it. How > is using a local address going to make the SDP unique just because I > use ICE?â€____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > __ __ > > *From:*mmusic [mailto:mmusic-bounces@ietf.org > ] *On Behalf Of *Christer Holmberg > *Sent:* 12 December 2017 22:25 > *To:* Roman Shpount > > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: local address in o=____ > > __ __ > > Hi,____ > > __ __ > > >I think the intent here is to generate something similar to GUID > which will uniquely identify the SDP description,____ > > __ __ > > I understand that, but I don’t see what ICE has to do with it.____ > > __ __ > > > but this is severely outdated for cases like ICE or privacy. How > is using a local address going to make the SDP unique just because I > use ICE?____ > > >__ __ > > > I think this needs to be updated to use sufficiently large random > strings instead of IP addresses, hostnames and ____ > > > user IDs, when local address or host name is not available or > should not be exposed due to privacy reasons.____ > > __ __ > > With SIP and offer/answer, is there even a need to uniquely identity > the SDP description? The SDP will always be associated with a > uniquely identified SIP session.____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > __ __ > > __ __ > > __ __ > > __ __ > > On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg > > wrote:____ > > Hi,____ > > __ __ > > The text says:____ > > __ __ > > is an address of the machine from which the____ > >                    session was created. For an address type of > IP4, this is either a____ > >                    fully qualified domain name of the machine > or the dotted-decimal____ > >                    representation of an IP version 4 address of > the machine. For an____ > >                    address type of IP6, this is either a fully > qualified domain name____ > >                    of the machine or the compressed textual > representation of an IP____ > >                    version 6 address of the machine. For both > IP4 and IP6, the fully____ > >                    qualified domain name is the form that > SHOULD be given unless this____ > >                    is unavailable, in which case a globally > unique address MAY be____ > >                    substituted. Unless an SDP extension for NAT > traversal is used____ > >                    (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a > local IP address MUST____ > >                    NOT be used in any context where the SDP > description might leave____ > >                    the scope in which the address is meaningful > (for example, a local____ > >                    address MUST NOT be included in an > application-level referral that____ > >                    might leave the scope).____ > > First, I guess it could be clarified that the “address of the > machine†does not have to be the address used for the media > (found in the c= line).____ > > __ __ > > Second, I am not sure I understand how the support of ICE allows > the usage of a local address. The combination of o= line parts > are supposed to create a unique identifier, so what does ICE > have to do with that?____ > > __ __ > > Regards,____ > > __ __ > > Christer____ > > __ __ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > ____ > > __ __ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Tue Dec 12 14:21:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18A12420B for ; Tue, 12 Dec 2017 14:21:03 -0800 (PST) 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_H4=-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 H2P6_RkRU4dH for ; Tue, 12 Dec 2017 14:21:00 -0800 (PST) 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 281E01294C7 for ; Tue, 12 Dec 2017 14:20:59 -0800 (PST) X-AuditID: c1b4fb3a-925ff7000000028c-36-5a30564a7fb9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.D5.00652.A46503A5; Tue, 12 Dec 2017 23:20:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Tue, 12 Dec 2017 23:20:57 +0100 From: Christer Holmberg To: Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTczc+1ngj5VYx1UGHMzWEdTkFlqNABRWAgAAhfmD///ItAIAAEtyw///6kgCAACIGoA== Date: Tue, 12 Dec 2017 22:20:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0515C9@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051282@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.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C0515C9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7uq5XmEGUwdb3QhZTlz9msZhxYSqz A5PHkiU/mTxuTSkIYIrisklJzcksSy3St0vgynj//AV7waZ3jBU7/ts3ME54wdjFyMkhIWAi 0XJnKUsXIxeHkMBhRomuryuhnCWMEpdv/GfuYuTgYBOwkOj+pw3SICKgKvH3+2QmkDCzgLrE 1cVBIGFhoDnfrz9hhSgxlXi/8zaUHSax+eI0dhCbBah13eP7YHFeAV+J4yc7mEBsIYEZzBLf fxqC2JwCgRKPJ89mA7EZBcQkvp9aA1bDLCAucevJfCaImwUkluw5zwxhi0q8fPyPFcJWkmhc AnEDs0C+xNrjd6B2CUqcnPmEZQKjyCwko2YhKZuFpGwW2GeaEut36UOUKEpM6X7IDmFrSLTO mcuOLL6AkX0Vo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBMHdzy22oH48HnjocYBTgYlXh4 Q20MooRYE8uKK3MPMUpwMCuJ8HY36UcJ8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRslJJCe WJKanZpakFoEk2Xi4JRqYOSMlRF89sfkyc/NIqtkRWd8Kw3r7WJslH/j/OzxEv2tr37auHM9 FigOsrT/3VOSPccn7JTGEa859yZKfL6iLVUyy0jkAK9I1eGJ97Pn3/2b+/mumcl3TVMO7X2b jky/qdl5Nfgqh8wkq5LtTs4LvLRrXR84WMc49wTIbd9UtkVht8zZOmn3U0osxRmJhlrMRcWJ AIev9rKlAgAA Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 22:21:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C0515C9ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHRoaW5rIGEgcHJvZHVjdCBuYW1lIGlzIGEgdXNlciBJRCwgaXMgaXQ/IDopDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21h bkB0ZWx1cml4LmNvbV0NClNlbnQ6IDEyIERlY2VtYmVyIDIwMTcgMjM6MTgNClRvOiBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IG1tdXNpY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVTSUNdIDQ1NjZiaXM6IHNlbmRpbmcgdXNlciBJRCBp biBvPQ0KDQpIaSwNCg0KSnVzdCBsb29raW5nIGF0IG15IHByb3h5IGxvZ3MsIEkgc2VlIGEgZmV3 IGV4YW1wbGVzIChJIGhhdmUgb2JmdXNjYXRlZCBJUCBhZGRyZXNzZXMpOg0KDQpTb251czogbz1T b251c19VQUMgODU5ODUwIDIzNTM3OCBJTiBJUDQgOTk5Ljk5OS45OTkuOTk5DQpCbHVlSmVhbnM6 IG89Qmx1ZUplYW5zIDM3MjIwNDM2MDIgMzcyMjA0MzYwMiBJTiBJUDQgOTk5Ljk5OS45OTkuOTk5 DQpBc3RlcmlzayAoQWN0dWFsbHkgZ2V0cyBVbml4IHVzZXIpOiBvPXJvb3QgMTMxMTUzNDMxMiAx MzExNTM0MzEyIElOIElQNCA5OTkuOTk5Ljk5OS45OTkNCkZpcmVmb3g6IG89bW96aWxsYS4uLlRI SVNfSVNfU0RQQVJUQS01Ny4wLjIgMjM5NDI2MTAxMzY2MTAxNjA4OCAwIElOIElQNCAwLjAuMC4w DQpDaXNjbzogbz1NU1NNR0MgOTA1NzYzOTEgMCBJTiBJUDQgOTk5Ljk5OS45OTkuOTk5DQpTa3lw ZSBTSVAgZ2F0ZXdheTogbz0zNzI2MTcwNDY0IDE1MTMwNTUwNTYgMTUxMzA1NTA1NiBJTiBJUDQg OTk5Ljk5OS45OTkuOTk5DQoNClNvLCBJIHdvdWxkIHNheSBwdXR0aW5nIHVzZXIgb3IgcHJvZHVj dCBuYW1lIGluIG89IGxpbmUgaXMgcHJldHR5IGNvbW1vbi4NCg0KUHV0dGluZyBwcm9kdWN0IGFu ZCB2ZXJzaW9uIGNhbiBhbHNvIGJlIHVzZWZ1bCBpZiBjYWxsIGdvZXMgdGhyb3VnaCBCMkJVQSB3 aGljaCBoaWRlcyBTSVAgc2lnbmFsaW5nLCBidXQgU0RQIG89IGFuZCBzPSBjYW4gc3RpbGwgYmUg dXNlZCB0byBpZGVudGlmeSB0aGUgb3JpZ2luYWwgY2xpZW50IHNvZnR3YXJlIG1ha2UgYW5kIHZl cnNpb24uDQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24g VHVlLCBEZWMgMTIsIDIwMTcgYXQgMzozOCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPj4gd3JvdGU6DQpIaSwNCg0KPkkgdGhpbmsgdGhlIG9yaWdpbmFsIGludGVudCB3YXMgdGhl IGxvZ2dlZCBpbiB1c2VyIGluIHRoZSBjb21wdXRlciBzeXN0ZW0uIEkgPnJlbWVtYmVyIFJBVCAo UmVhbCBBdWRpbyBUb29sKSBsb29raW5nIGF0IHRoZSBsb2dnZWQgaW4gdXNlciBvbiBVTklYIGFu ZCA+cHV0dGluZyAidXNlciIgb24gV2luZG93cy4NCg0KV2VsbCwgaXMgQU5ZT05FIHB1dHRpbmcg YSB1c2VyIG5hbWUgdGhlcmUgdG9kYXk/IEkgaGF2ZSBvbmx5IHNlZW4g4oCcLeKAnC4NCg0KQW5k LCBhZ2Fpbiwgd2l0aCBTSVAgeW91IGFyZSBnb2luZyB0byBoYXZlIGFsbCB1c2VyLXJlbGF0ZWQg aW5mb3JtYXRpb24gaW4gdGhlIFNJUCBzaWduYWxsaW5nLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KT24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgMzoyMiBQTSwgQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSBSb21hbiwNCg0KV2hhdCB1c2VyIElEIGlzIHRo ZSB0ZXh0IHRhbGtpbmcgYWJvdXQ/IFRoZSB1c2VyIElEIG9mIG15IGNvbXB1dGVyPyBUaGUgdXNl ciBJRCBvZiBteSBWb0lQIGFwcGxpY2F0aW9uPyBBbnkgdXNlciBJRD8NCg0KUmVnYXJkcywNCg0K Q2hyaXN0ZXINCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPl0NClNlbnQ6IDEyIERlY2VtYmVyIDIwMTcgMjE6 MjANClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+Pg0KQ2M6IG1tdXNpY0BpZXRm Lm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIDQ1NjZi aXM6IHNlbmRpbmcgdXNlciBJRCBpbiBvPQ0KDQpIaSBDaHJpc3RlciwNCg0KSSBkbyBub3Qgc2Vl IGFueSByZWFzb24gd2h5IHVzZXIgc2hvdWxkIGJlIHByb2hpYml0ZWQgZnJvbSBzZW5kaW5nIHRo ZWlyIHVzZXIgSUQsIGlmIHRoZXkgZG8gbm8gY2FyZSBhYm91dCBwcml2YWN5Lg0KDQpJIHdvdWxk IHJlcGhyYXNlIHRoaXMgYXM6DQoNCjx1c2VybmFtZT4gaXMgdGhlIHVzZXIncyBsb2dpbiBvbiB0 aGUgb3JpZ2luYXRpbmcgaG9zdC4gSWYgdGhlIG9yaWdpbmF0aW9uIGhvc3QgZG9lcyBub3Qgc3Vw cG9ydCB0aGUgY29uY2VwdCBvZiB1c2VyIElEcyBvciBpZiB0aGVyZSBhcmUgYW55IGNvbmNlcm5z IG9mIGVuZCB1c2VyIHByaXZhY3ksICItIiBTSE9VTEQgYmUgdXNlZCBhcyB0aGUgPHVzZXJuYW1l PiB2YWx1ZS4gVGhlIDx1c2VybmFtZT4gbXVzdCBub3QgY29udGFpbiBzcGFjZXMuDQoNCl9fX19f X19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBEZWMgMTIsIDIwMTcgYXQgNTo1MiBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWls dG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KQXMgSSBo YXZlIG5vdCBmb2xsb3dlZCBhbGwgZGlzY3Vzc2lvbnMgb24gNDU2NmJpcywgc28gcGxlYXNlIGxl dCBtZSBrbm93IGlmIHRoZSBmb2xsb3dpbmcgaGFzIGJlZW4gZGlzY3Vzc2VkLg0KDQpSZWdhcmRp bmcgdGhlIOKAnG894oCcIHBhcmFtZXRlciwgdGhlIHRleHQgc2F5czoNCg0KPHVzZXJuYW1lPiAg aXMgdGhlIHVzZXIncyBsb2dpbiBvbiB0aGUgb3JpZ2luYXRpbmcgaG9zdCwgb3IgaXQgaXMgIi0i DQoNCiAgICAgICAgICAgIGlmIHRoZSBvcmlnaW5hdGluZyBob3N0IGRvZXMgbm90IHN1cHBvcnQg dGhlIGNvbmNlcHQgb2YgdXNlciBJRHMuDQoNCiAgICAgICAgICAgIFRoZSA8dXNlcm5hbWU+IE1V U1QgTk9UIGNvbnRhaW4gc3BhY2VzLg0KDQpFdmVuIGlmIHRoZSBvcmlnaW5hdGluZyBob3N0IHN1 cHBvcnRzIOKAnHRoZSBjb25jZXB0IG9mIHVzZXIgSURz4oCdICh3aGF0ZXZlciB0aGF0IG1lYW5z KSwgaXQgbWF5IG5vdCB3YW50IHRvIHNlbmQgaXQgZm9yIHByaXZhY3kgcmVhc29ucy4NCg0KDQoN CkNvdWxkbuKAmXQgd2UgaW5zdGVhZCBzYXkgU0hPVUxEIHNlbmQg4oCcLeKAnCwgYnV0IE1VU1Qg YmUgYWJsZSB0byByZWNlaXZlIHdoYXRldmVyIChmb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSk/ DQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11c2ljIG1haWxpbmcgbGlzdA0K bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B6C0515C9ESESSMB109erics_ 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 Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmhvZW56Yg0K CXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkb27igJl0IHRo aW5rIGEgcHJvZHVjdCBuYW1lIGlzIGEgdXNlciBJRCwgaXMgaXQ/IDopPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMTIgRGVjZW1iZXIgMjAxNyAyMzoxODxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIg SG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10g NDU2NmJpczogc2VuZGluZyB1c2VyIElEIGluIG89PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5KdXN0IGxvb2tpbmcgYXQgbXkgcHJveHkgbG9ncywgSSBzZWUgYSBmZXcgZXhhbXBsZXMg KEkgaGF2ZSBvYmZ1c2NhdGVkIElQIGFkZHJlc3Nlcyk6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbnVzOiBvPVNvbnVzX1VBQyA4NTk4NTAg MjM1Mzc4IElOIElQNCA5OTkuOTk5Ljk5OS45OTk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJsdWVKZWFuczogbz1CbHVlSmVhbnMgMzcyMjA0MzYw MiAzNzIyMDQzNjAyIElOIElQNCA5OTkuOTk5Ljk5OS45OTk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzdGVyaXNrIChBY3R1YWxseSBnZXRzIFVu aXggdXNlcik6IG89cm9vdCAxMzExNTM0MzEyIDEzMTE1MzQzMTIgSU4gSVA0IDk5OS45OTkuOTk5 Ljk5OTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZpcmVmb3g6IG89bW96aWxsYS4uLlRISVNfSVNfU0RQQVJUQS01Ny4wLjIgMjM5NDI2 MTAxMzY2MTAxNjA4OCAwIElOIElQNCAwLjAuMC4wPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpc2NvOiZuYnNwO289TVNTTUdDIDkw NTc2MzkxIDAgSU4gSVA0IDk5OS45OTkuOTk5Ljk5OTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2t5cGUgU0lQIGdhdGV3YXk6Jm5ic3A7bz0zNzI2 MTcwNDY0IDE1MTMwNTUwNTYgMTUxMzA1NTA1NiBJTiBJUDQgOTk5Ljk5OS45OTkuOTk5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBJIHdv dWxkIHNheSBwdXR0aW5nIHVzZXIgb3IgcHJvZHVjdCBuYW1lIGluIG89IGxpbmUgaXMgcHJldHR5 IGNvbW1vbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UHV0dGluZyBwcm9kdWN0IGFuZCB2ZXJzaW9uIGNhbiBhbHNvIGJlIHVzZWZ1bCBpZiBj YWxsIGdvZXMgdGhyb3VnaCBCMkJVQSB3aGljaCBoaWRlcyBTSVAgc2lnbmFsaW5nLCBidXQgU0RQ IG89IGFuZCBzPSBjYW4gc3RpbGwgYmUgdXNlZCB0byBpZGVudGlmeSB0aGUgb3JpZ2luYWwgY2xp ZW50IHNvZnR3YXJlIG1ha2UgYW5kIHZlcnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f X19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDM6MzggUE0sIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkkgdGhpbmsgdGhl IG9yaWdpbmFsIGludGVudCB3YXMgdGhlIGxvZ2dlZCBpbiB1c2VyIGluIHRoZSBjb21wdXRlciBz eXN0ZW0uIEkNCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPnJlbWVtYmVy IFJBVCAoUmVhbCBBdWRpbyBUb29sKSBsb29raW5nIGF0IHRoZSBsb2dnZWQgaW4gdXNlciBvbiBV TklYIGFuZA0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+cHV0dGluZyAm cXVvdDt1c2VyJnF1b3Q7IG9uIFdpbmRvd3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZWxsLCBpcyBBTllPTkUgcHV0dGluZyBhIHVzZXIgbmFt ZSB0aGVyZSB0b2RheT8gSSBoYXZlIG9ubHkgc2VlbiDigJwt4oCcLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgYWdhaW4sIHdpdGggU0lQIHlvdSBh cmUgZ29pbmcgdG8gaGF2ZSBhbGwgdXNlci1yZWxhdGVkIGluZm9ybWF0aW9uIGluIHRoZSBTSVAg c2lnbmFsbGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFR1ZSwgRGVjIDEyLCAyMDE3IGF0IDM6MjIgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGkgUm9tYW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+V2hhdCB1c2VyIElEIGlzIHRoZSB0ZXh0IHRhbGtpbmcgYWJvdXQ/IFRoZSB1 c2VyIElEIG9mIG15IGNvbXB1dGVyPyBUaGUgdXNlciBJRCBvZiBteSBWb0lQIGFwcGxpY2F0aW9u Pw0KIEFueSB1c2VyIElEPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fMjM3NDg4OTk4NDI0ODk5 MDM5MV9tXy03MzIzOTExNjMyNDUwMTMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuDQogU2hwb3VudCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMiBEZWNlbWJlciAyMDE3IDIxOjIwPGJyPg0KPGI+ VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2lj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gNDU2NmJpczogc2VuZGluZyB1c2VyIElEIGluIG89PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkg Q2hyaXN0ZXIsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSBkbyBub3Qgc2VlIGFueSByZWFzb24gd2h5IHVzZXIgc2hvdWxkIGJlIHByb2hpYml0ZWQg ZnJvbSBzZW5kaW5nIHRoZWlyIHVzZXIgSUQsIGlmIHRoZXkgZG8gbm8gY2FyZSBhYm91dCBwcml2 YWN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSB3b3VsZCByZXBocmFzZSB0aGlzIGFzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbHQ7dXNlcm5hbWUmZ3Q7IGlzIHRoZSB1c2VyJ3Mg bG9naW4gb24gdGhlIG9yaWdpbmF0aW5nIGhvc3QuIElmIHRoZSBvcmlnaW5hdGlvbiBob3N0IGRv ZXMgbm90IHN1cHBvcnQgdGhlIGNvbmNlcHQgb2YgdXNlciBJRHMgb3IgaWYgdGhlcmUgYXJlIGFu eSBjb25jZXJucyBvZiBlbmQgdXNlciBwcml2YWN5LCAmcXVvdDstJnF1b3Q7IFNIT1VMRA0KIGJl IHVzZWQgYXMgdGhlICZsdDt1c2VybmFtZSZndDsgdmFsdWUuIFRoZSAmbHQ7dXNlcm5hbWUmZ3Q7 IG11c3Qgbm90IGNvbnRhaW4gc3BhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fPGJyPg0K Um9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBUdWUsIERlYyAxMiwgMjAxNyBhdCA1OjUyIEFNLCBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFzIEkgaGF2ZSBub3QgZm9s bG93ZWQgYWxsIGRpc2N1c3Npb25zIG9uIDQ1NjZiaXMsIHNvIHBsZWFzZSBsZXQgbWUga25vdyBp ZiB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIGRpc2N1c3NlZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2Fy ZGluZyB0aGUg4oCcbz3igJwgcGFyYW1ldGVyLCB0aGUgdGV4dCBzYXlzOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVy ZXM6bm9ybWFsO3dvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDt1c2VybmFtZSZndDsmbmJzcDsgaXMgdGhlIHVzZXIn cyBsb2dpbiBvbiB0aGUgb3JpZ2luYXRpbmcgaG9zdCwgb3IgaXQgaXMgJnF1b3Q7LSZxdW90Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpZiB0aGUgb3JpZ2luYXRpbmcgaG9zdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBjb25j ZXB0IG9mIHVzZXIgSURzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgJmx0O3VzZXJuYW1lJmd0OyBNVVNUIE5PVCBj b250YWluIHNwYWNlcy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDt3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RXZlbiBpZiB0aGUgb3JpZ2luYXRpbmcgaG9z dCBzdXBwb3J0cyDigJx0aGUgY29uY2VwdCBvZiB1c2VyIElEc+KAnSAod2hhdGV2ZXIgdGhhdCBt ZWFucyksIGl0IG1heSBub3Qgd2FudCB0byBzZW5kIGl0IGZvciBwcml2YWN5IHJlYXNvbnMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5Db3VsZG7igJl0IHdlIGluc3RlYWQgc2F5IFNIT1VMRCBzZW5kIOKAnC3igJwsIGJ1dCBN VVNUIGJlIGFibGUgdG8gcmVjZWl2ZSB3aGF0ZXZlciAoZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRp dj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkNocmlzdGVyJm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQptbXVzaWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1tdXNp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B6C0515C9ESESSMB109erics_-- From nobody Tue Dec 12 14:31:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF97312956B for ; Tue, 12 Dec 2017 14:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBGaHCgXN_oI for ; Tue, 12 Dec 2017 14:31:15 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 24ED91279E5 for ; Tue, 12 Dec 2017 14:31:15 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id g7so318829pgs.0 for ; Tue, 12 Dec 2017 14:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IVVpdo/53Re4QIEBjCV0ZjSc6yeCeymzLjLkZmV/PpA=; b=oiD/RZBq9hWPWAMsTPOA8dzKBlMjcAdrNMWRgxvTsQJ8CRAkNyajfJzbYtveF9KGtU bwX7j/y4qMgS0KTZznu/WVMdJ032RaZ/D2T5J4JRwTwUE0tK5LteRHFlgOQ5HmwR610r 2YRf0HlczoRzVFH35JG98NHK3BP+JsVf+/daqp8V2+bEsJckhLoR9hkAQ/tCeQfS1fs0 08SCbAWE5qbzNlYB2LBgSIsftIYbrJyr7Y2Vf6cw4fSzCTn86bwg3L/gmpIR1WuWRRZN N4muZOJBIAGdcaUmUsa+A8NQl48Us4ZLDmKC3+t2ujjFBCS8sYXKhwghlReeRdJHLewa AioA== 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=IVVpdo/53Re4QIEBjCV0ZjSc6yeCeymzLjLkZmV/PpA=; b=TsvdZwplyYHKTer4Sv1w/8SMyPOJJpIrgP/fkzACL64V+2Lz6lNIYckyce9comACkq +DsGRhE3RzjcjQHhLGmp+Gt42HvU6M2PINZ5JgoqISM78cXH73S5EdAfo8/D6wkhBIEn YG0kCrvxhU5NngUV2uK/dNIBe2fHOmpw1MVfuSnVwc4tBpkP2GWBPU/JZGxGk/y+FUXq yMCKfOyv8xyQgFuuA7vJFR6WLjD+vrTvK0PxJGvYjNSXIf5GQ2FwSe/xgv+tKj2/M0Yt vodJQiCf/HoCb/8yl1uKMAvwrDwUtKMyV8U24g2zgjlcRbQqclLohUiA9eagS2l9uGqY 4dyQ== X-Gm-Message-State: AKGB3mKtOUbnNmcVxbeJizDR9EeCKRmOTTrbFNam92KxG/ZZi7PeiVi8 VyMxoxf9JEmKE7TfwVlkhpMaGA7p X-Google-Smtp-Source: ACJfBotyTr89YOlSKMEOKNXvK5LINHH02+v529IPJXYyG8Fs76JajL/0SlnnUMPJJ8oX1Z8en0AN2w== X-Received: by 10.101.66.66 with SMTP id d2mr3347739pgq.244.1513117874336; Tue, 12 Dec 2017 14:31:14 -0800 (PST) Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com. [209.85.192.170]) by smtp.gmail.com with ESMTPSA id o84sm223518pfa.46.2017.12.12.14.31.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 14:31:13 -0800 (PST) Received: by mail-pf0-f170.google.com with SMTP id a90so343550pfk.1 for ; Tue, 12 Dec 2017 14:31:13 -0800 (PST) X-Received: by 10.84.214.2 with SMTP id h2mr3846376pli.142.1513117872800; Tue, 12 Dec 2017 14:31:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 14:31:12 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0515C9@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051282@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C0515C9@ESESSMB109.ericsson.se> From: Roman Shpount Date: Tue, 12 Dec 2017 17:31:12 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045d26484fca0905602c3557" Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 22:31:18 -0000 --f403045d26484fca0905602c3557 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Probably not the clearest name even for this spec. Should be user agent ID or something similar. Regards, _____________ Roman Shpount On Tue, Dec 12, 2017 at 5:20 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I don=E2=80=99t think a product name is a user ID, is it? :) > > > > Regards, > > > > Christer > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 12 December 2017 23:18 > > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: sending user ID in o=3D > > > > Hi, > > > > Just looking at my proxy logs, I see a few examples (I have obfuscated IP > addresses): > > > > Sonus: o=3DSonus_UAC 859850 235378 IN IP4 999.999.999.999 > > BlueJeans: o=3DBlueJeans 3722043602 3722043602 IN IP4 999.999.999.999 > > Asterisk (Actually gets Unix user): o=3Droot 1311534312 1311534312 IN IP4 > 999.999.999.999 > > Firefox: o=3Dmozilla...THIS_IS_SDPARTA-57.0.2 2394261013661016088 0 IN IP= 4 > 0.0.0.0 > > Cisco: o=3DMSSMGC 90576391 0 IN IP4 999.999.999.999 > > Skype SIP gateway: o=3D3726170464 1513055056 1513055056 IN IP4 > 999.999.999.999 > > > > So, I would say putting user or product name in o=3D line is pretty commo= n. > > > > Putting product and version can also be useful if call goes through B2BUA > which hides SIP signaling, but SDP o=3D and s=3D can still be used to ide= ntify > the original client software make and version. > > > > Regards, > > > _____________ > Roman Shpount > > > > On Tue, Dec 12, 2017 at 3:38 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > >I think the original intent was the logged in user in the computer > system. I >remember RAT (Real Audio Tool) looking at the logged in user > on UNIX and >putting "user" on Windows. > > > > Well, is ANYONE putting a user name there today? I have only seen =E2=80= =9C-=E2=80=9C. > > > > And, again, with SIP you are going to have all user-related information i= n > the SIP signalling. > > > > Regards, > > > > Christer > > > > > > > > On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi Roman, > > > > What user ID is the text talking about? The user ID of my computer? The > user ID of my VoIP application? Any user ID? > > > > Regards, > > > > Christer > > > > > > *From:* Roman Shpount [mailto:roman@telurix.com] > *Sent:* 12 December 2017 21:20 > *To:* Christer Holmberg > *Cc:* mmusic@ietf.org > *Subject:* Re: [MMUSIC] 4566bis: sending user ID in o=3D > > > > Hi Christer, > > > > I do not see any reason why user should be prohibited from sending their > user ID, if they do no care about privacy. > > > > I would rephrase this as: > > > > is the user's login on the originating host. If the originatio= n > host does not support the concept of user IDs or if there are any concern= s > of end user privacy, "-" SHOULD be used as the value. The > must not contain spaces. > > > _____________ > Roman Shpount > > > > On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > As I have not followed all discussions on 4566bis, so please let me know > if the following has been discussed. > > > > Regarding the =E2=80=9Co=3D=E2=80=9C parameter, the text says: > > is the user's login on the originating host, or it is "-" > > if the originating host does not support the concept of user = IDs. > > The MUST NOT contain spaces. > > Even if the originating host supports =E2=80=9Cthe concept of user IDs=E2= =80=9D (whatever that means), it may not want to send it for privacy reason= s. > > > > Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST= be able to receive whatever (for backward compatibility)? > > > > Regards, > > > > Christer > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > --f403045d26484fca0905602c3557 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Probably not the clearest name even for this spec. Should = be user agent ID or something similar.

Regards,
_____________
Roman Shpount

On Tue, Dec 12, 2017 at 5:20 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

I don=E2=80=99t think a product name = is a user ID, is it? :)

=C2=A0

Regards,

=C2=A0

Christer

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: = Roman Shpount [mailto:roman@telurix.com]
Sent: 12 December 2017 23:18


To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D=

=C2=A0

Hi,

=C2=A0

Just looking at my proxy logs, I see a few examples = (I have obfuscated IP addresses):

=C2=A0

Sonus: o=3DSonus_UAC 859850 235378 IN IP4 999.999.99= 9.999

BlueJeans: o=3DBlueJeans 3722043602 3722043602 IN IP= 4 999.999.999.999

Asterisk (Actually gets Unix user): o=3Droot 1311534= 312 1311534312 IN IP4 999.999.999.999

Firefox: o=3Dmozilla...THIS_IS_SDPARTA-57.0.2 2= 394261013661016088 0 IN IP4 0.0.0.0

Cisco:=C2=A0o=3DMSSMGC 90576391 0 IN IP4 999.999.999= .999

Skype SIP gateway:=C2=A0o=3D3726170464 1513055056 15= 13055056 IN IP4 999.999.999.999

=C2=A0

So, I would say putting user or product name in o=3D= line is pretty common.

=C2=A0

Putting product and version can also be useful if ca= ll goes through B2BUA which hides SIP signaling, but SDP o=3D and s=3D can = still be used to identify the original client software make and version.=

=C2=A0

Regards,


_____________
Roman Shpount

=C2=A0

On Tue, Dec 12, 2017 at 3:38 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

>I think the= original intent was the logged in user in the computer system. I >remember RAT (Real Audio Tool) loo= king at the logged in user on UNIX and >putting "user" on Window= s.

=C2=A0

Well, is ANYONE putting a user name t= here today? I have only seen =E2=80=9C-=E2=80=9C.

=C2=A0

And, again, with SIP you are going to= have all user-related information in the SIP signalling.<= /u>

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Tue, Dec 12, 2017 at 3:22 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi Roman,

=C2=A0

What user ID is the text talking abou= t? The user ID of my computer? The user ID of my VoIP application? Any user ID?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = Roman Shpount [mailto:rom= an@telurix.com]
Sent: 12 December 2017 21:20
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: mmusic@ietf= .org
Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D=

=C2=A0

Hi Christer,

=C2=A0

I do not see any reason why user should be prohibite= d from sending their user ID, if they do no care about privacy.

=C2=A0

I would rephrase this as:

=C2=A0

<username> is the user's login on the orig= inating host. If the origination host does not support the concept of user = IDs or if there are any concerns of end user privacy, "-" SHOULD be used as the <username> value. The <username> must not conta= in spaces.


_____________
Roman Shpount

=C2=A0

On Tue, Dec 12, 2017 at 5:52 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As I have not followed all discussions = on 4566bis, so please let me know if the following has been discussed.

=C2=A0

Regarding the =E2=80=9Co=3D=E2=80=9C pa= rameter, the text says:

<username>=C2=A0 is the user&=
#39;s login on the originating host, or it is "-"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 if the originating host does not support the conce=
pt of user IDs.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 The <username> MUST NOT contain spaces.
Even if the originating host supports =E2=80=9Cthe concept of user =
IDs=E2=80=9D (whatever that means), it may not want to send it for privacy =
reasons.
=C2=A0
Couldn=E2=80=99t we instead say SHOULD send =E2=80=9C-=E2=80=9C, but MUST =
be able to receive whatever (for backward compatibility)?<=
/u>
=C2=A0
Regards,
=C2=A0
Christer=C2=A0
=C2=A0
=C2=A0


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

=C2=A0

=C2=A0

=C2=A0


--f403045d26484fca0905602c3557-- From nobody Tue Dec 12 20:25:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157B128D64 for ; Tue, 12 Dec 2017 20:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1vvseIlJUTP for ; Tue, 12 Dec 2017 20:24:59 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (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 3EC61128D19 for ; Tue, 12 Dec 2017 20:24:57 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id OybAe5tHZ27mvOybIeGPBR; Wed, 13 Dec 2017 04:24:56 +0000 Received: from hobgoblin.ariadne.com ([65.96.206.41]) by resomta-ch2-17v.sys.comcast.net with SMTP id OybHeGi0pEmODOybIetnyG; Wed, 13 Dec 2017 04:24:56 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vBD4Osag010487; Tue, 12 Dec 2017 23:24:54 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBD4OsA5010484; Tue, 12 Dec 2017 23:24:54 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg Cc: roman@telurix.com, mmusic@ietf.org In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 12 Dec 2017 23:24:54 -0500 Message-ID: <87tvwvz23t.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCjI9C4NzksataHWTi7FYHrWVnNvcGpWpOKWUOx8B/+9QkH1H+Otull1QiFZFJJW4POA3n4cnbjAvCvjN3GluEQ9nkm6LXzHDaIjNVl0njXNAlsgmoTT 8MNMFsMPXcmCmkFFojar9mXDV2cIpnsw7bDiRPppQ2ZRHZFH902pvscr1yZG60MM6OJrhZ4H1RodfBophFnNWGWt09xj1zjs1Y3W1yjDFOH8g9hBH2DkkZhW XJz4R8lDBem+TBQwLrwAHg== Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 04:25:00 -0000 Christer Holmberg writes: > What user ID is the text talking about? The user ID of my computer? > The user ID of my VoIP application? Any user ID? Reading RFC 4566 section 5.2, I suspect the original thinking was "if we combine the host's address, the time (at 1 sec resolution), and the user name, that will surely be unique" -- but that only host address and time together might risk that two users will fire up the VoIP application during the same second. So the answer is more or less, "a user ID is a thing which can only start one SDP session per second". What really matters is the global uniqueness constraint. Dale From nobody Tue Dec 12 22:55:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6B7126E64 for ; Tue, 12 Dec 2017 22:55:06 -0800 (PST) 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_H4=-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 sVO9ceLVJOLE for ; Tue, 12 Dec 2017 22:55:05 -0800 (PST) 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 1B17C126CD6 for ; Tue, 12 Dec 2017 22:55:04 -0800 (PST) X-AuditID: c1b4fb3a-ceff29c00000028c-7a-5a30cec7954f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 01.FE.00652.7CEC03A5; Wed, 13 Dec 2017 07:55:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 07:55:02 +0100 From: Christer Holmberg To: "Dale R. Worley" CC: "roman@telurix.com" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTc8pT1ngj5VYx1UGHMzWEdTkFlqNA6mAA Date: Wed, 13 Dec 2017 06:55:02 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <87tvwvz23t.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tvwvz23t.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <603D49FF317EFA4CB960E387FADE6DBD@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7tO7xcwZRBkfWi1tMXf6YxWLGhanM Fi9PlDkwe0ze/5XZY8mSn0wet6YUBDBHcdmkpOZklqUW6dslcGU8WrSIpaCVtWLeyh8sDYzf mbsYOTkkBEwkvm8/xtjFyMUhJHCYUeJl/0RWCGcJo8Tq5l1MXYwcHGwCFhLd/7RBTBEBTYmO BTkgvcwCQRLrZ/exg9jCQHMuXt/GAmKLCJhKvN95mxWi3Ehi4fNUkDCLgKrElP5LYGt5Bawl Nh98DFYuJFAmMePhPCYQm1PAWKJ9wl6wGkYBMYnvp9YwQawSl7j1ZD4TxMkCEkv2nIc6X1Ti 5eN/rCC2qICexIYTt9lB1koIKElM25oG0Wog8f7cfGYI21pi67QrLBC2tsSyha+hzhGUODnz CcsERvFZSLbNQtI+C0n7LCTts5C0L2BkXcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGHkH t/y22sF48LnjIUYBDkYlHt4Zpw2ihFgTy4orcw8xSnAwK4nw9sQDhXhTEiurUovy44tKc1KL DzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTCaSFQs7Ek7fOH16bV6p8MNPTe9O+fb a9hjxG3yO3mCZvvR1Ii65R22Vn+r+m93X49o8Xm//EjhoyCNtEObj/2Pco7ymtY+Z2fvu8bX Oa82Re54FHFVOO3ah7+vvvbeExPzO7dD5e/Hxzu6S1kV3Gylc5fPYdltNulLX1vSgzTmOTbK e7V3RrIosRRnJBpqMRcVJwIAK1xjQLgCAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 06:55:07 -0000 Hi, >>What user ID is the text talking about? The user ID of my computer? >> The user ID of my VoIP application? Any user ID? > >Reading RFC 4566 section 5.2, I suspect the original thinking was "if we >combine the host's address, the time (at 1 sec resolution), and the user >name, that will surely be unique" -- but that only host address and time >together might risk that two users will fire up the VoIP application >during the same second. > >So the answer is more or less, "a user ID is a thing which can only >start one SDP session per second". =8Awhich means one should not use a product name. Regards, Christer From nobody Tue Dec 12 23:11:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA13126E64 for ; Tue, 12 Dec 2017 23:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bchGrRZpOE0 for ; Tue, 12 Dec 2017 23:11:40 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 02E18126BF3 for ; Tue, 12 Dec 2017 23:11:39 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id j124so969213pfc.2 for ; Tue, 12 Dec 2017 23:11:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/v0/WCN0u0bohLlvG1CWotPQN5p5Ea7Wn4pafZB1wVU=; b=npqqZBbmq+kOkexskndtdDCR0C8IV6mvhCPOnrWjnvRnBw/oMI69ptpG7sK0T+Wbn0 BYTiLwyNajr8iMBIrRA4fur6Ywef0u3NtX67VKLbl/66bJxwkQF0J3tHM7bO5G5YbXL1 OHN6A7Cn4D7M4b3KJvLVLHfQnuiT/ooakuYz0D3adexn8E93QMVvP2X7Az3mAeVLyTLs 3kShPQ3KjE2JsarU/CG8nDxoztVfAyTLmS8qdfML8lAMOmg3NndQU4QnlbwLYmIsLxmR NWIB3Lb6ate/nb/bYm679mZqRK2l2QDpQb/TBzewZ3zn84T5Hr/ZIVh4zLoy96a4GZc0 Rt3Q== 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=/v0/WCN0u0bohLlvG1CWotPQN5p5Ea7Wn4pafZB1wVU=; b=bu9mBwZIxLbj6ipNQl4jwKD8LLhdTiQqW4q5D7VDlF4HjH4r+2xExv6slmb2gFGupU ma1htf3Jk+uygs+756O1RwYjMGVRfrVlywgi0lLc+HhzZ6/he6p8E+F+OTOCrbe2JGOu 0pj4EFT7jk4TNAwgBa0MXipMsW7Eo87o1cZXBWvrh1y+7miOtttkkou5dHdadenOt13p f9Zh5pU0rqLE1Bk2kcD1oQXihdJ0JkjzV9Iugnmax+ePNl0KBcUFcjMFBWydUcrgDL6R 2IeRocM2MotdgrvHXXAFh4fAZGiV7CADTUFtx+SkO6y9k9k9zEbXU/jySXJc2dCpcEwB kgDA== X-Gm-Message-State: AKGB3mIKWHosnwY7Sn3sA6rFqjnCAb4wnLL+k0jQwRkVFZdTcyv7mmpJ gfh696Ak+3r5AATAKZJ7C9YQLNmT X-Google-Smtp-Source: ACJfBovH4yFlNKogyO2jbz+orClCmSmghDfOuCxBxoYi2zEkcYw2es4MSB0Whn5cRqzkPTS+b97QUw== X-Received: by 10.99.120.73 with SMTP id t70mr4402549pgc.402.1513149099133; Tue, 12 Dec 2017 23:11:39 -0800 (PST) Received: from mail-pg0-f52.google.com (mail-pg0-f52.google.com. [74.125.83.52]) by smtp.gmail.com with ESMTPSA id y80sm1790930pfi.183.2017.12.12.23.11.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 23:11:38 -0800 (PST) Received: by mail-pg0-f52.google.com with SMTP id g7so911480pgs.0 for ; Tue, 12 Dec 2017 23:11:38 -0800 (PST) X-Received: by 10.98.3.5 with SMTP id 5mr5062081pfd.42.1513149098083; Tue, 12 Dec 2017 23:11:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 23:11:37 -0800 (PST) Received: by 10.100.140.202 with HTTP; Tue, 12 Dec 2017 23:11:37 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <87tvwvz23t.fsf@hobgoblin.ariadne.com> From: Roman Shpount Date: Wed, 13 Dec 2017 02:11:37 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "Dale R. Worley" , mmusic@ietf.org Content-Type: multipart/alternative; boundary="94eb2c09262c7bcd680560337ac5" Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:11:41 -0000 --94eb2c09262c7bcd680560337ac5 Content-Type: text/plain; charset="UTF-8" Hi, On Dec 13, 2017 1:55 AM, "Christer Holmberg" wrote: >So the answer is more or less, "a user ID is a thing which can only >start one SDP session per second". which means one should not use a product name. Which is true only if NTP is used for . If you use some other way to generate sess-id for the given address, then it can be any string with no spaces. The only real requirements are that combination of is unique and that monotonicaly increases. The rest are mostly outdated and widely ignored suggestions. Roman Shpount --94eb2c09262c7bcd680560337ac5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

On Dec 13, 2017 1:55= AM, "Christer Holmberg" <christer.holmberg@ericsson.com>= wrote:
<= /div>
>So the answer is more or less, "a user ID is a thing which can onl= y
>start one SDP session per second".

which means one should not use a product name.
=

Which is true only if NTP is used for <sess-= id>. If you use some other way to generate sess-id for the given address= , then it can be any string with no spaces.

The only re= al requirements are that combination of=C2=A0<username> <sess-id> <nettype> <addrtype>=C2=A0<unicast-address> is uni= que and that <sess-version> monotonicaly increases. The rest are most= ly outdated and widely ignored suggestions.

Roman Shpount
--94eb2c09262c7bcd680560337ac5-- From nobody Tue Dec 12 23:17:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FB7126C26 for ; Tue, 12 Dec 2017 23:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 d9GngG2nOtXI for ; Tue, 12 Dec 2017 23:17:45 -0800 (PST) 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 DF237126BF3 for ; Tue, 12 Dec 2017 23:17:44 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-08-5a30d41697a1 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7A.E9.13339.614D03A5; Wed, 13 Dec 2017 08:17:43 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 08:17:42 +0100 From: Christer Holmberg To: Roman Shpount CC: "Dale R. Worley" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTc8pT1ngj5VYx1UGHMzWEdTkFlqNA6mAA///ggoCAACXUAA== Date: Wed, 13 Dec 2017 07:17:42 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <87tvwvz23t.fsf@hobgoblin.ariadne.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.7.170905 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D656A27727765christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2J7iK74FYMog9bTvBZTlz9msZhxYSqz xcsTZQ7MHpP3f2X2WLLkJ5PHrSkFAcxRXDYpqTmZZalF+nYJXBmTV99lKegyqri1/BdrA+M5 7S5GDg4JAROJCcdTuhg5OYQEDjNKTF4h3sXIBWQvYZTY+riLDaSGTcBCovufNkiNiICqxN/v k5lAbGYBP4m7XxuYQWxhoDEXr29jgagxlXi/8zYrhO0kceLiNLB6FqDeS7ePsoHYvALWEmsv X2GH2PWeUWLJv39gDZwCgRIP9q9iB7EZBcQkvp9aA7VMXOLWk/lgtoSAgMSSPeeZIWxRiZeP IXpFBfQkNpy4zQ7xl6LE8n45EJNZIEHiaa8gxFpBiZMzn7BMYBSdhWToLISqWUiqIEoMJN6f m88MYWtLLFv4GsrWl9j45SwjhG0tsXDxcTZkNQsYOVYxihanFiflphsZ66UWZSYXF+fn6eWl lmxiBMbjwS2/VXcwXn7jeIhRgINRiYd312mDKCHWxLLiytxDjBIczEoivD3xQCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8Jz15o4QE0hNLUrNTUwtSi2CyTBycUg2Myn5WX3zOaa3dp+GWWPRZ IPPyS0vHNRvE91/fw15Xd/WfgFNUYNzGEM6+D4rfpVdzm4QqtDxTUxUpka0z9A1pbveZuKQ7 g/fsJ/5va9vvPLb4bavCff51CGfKhekWFd2Si83Yrz3K9VpRKff9sv0bjYfWT4ONmX4t5hdi S1izYLpzLsteUyElluKMREMt5qLiRAB82Zw+wwIAAA== Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:17:47 -0000 --_000_D656A27727765christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, With so many parameters forming the unique value, I don=92t think the risk = for collision is very small. My main issue is the text. Perhaps we should simply say that is = a token, and MAY contain user ID, product ID, or whatever else. And, if peo= ple don=92t want to include a value, they use =93-=93. Regards, Christer From: Roman Shpount > Date: Wednesday 13 December 2017 at 09:11 To: Christer Holmberg > Cc: Dale Worley >, "mmusic@ie= tf.org" > Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D Hi, On Dec 13, 2017 1:55 AM, "Christer Holmberg" > wrote: >So the answer is more or less, "a user ID is a thing which can only >start one SDP session per second". which means one should not use a product name. Which is true only if NTP is used for . If you use some other way = to generate sess-id for the given address, then it can be any string with n= o spaces. The only real requirements are that combination of is unique and that monot= onicaly increases. The rest are mostly outdated and widely ignored suggesti= ons. Roman Shpount --_000_D656A27727765christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

With so many parameters forming the unique value, I don=92t think the = risk for collision is very small.

My main issue is the text. Perhaps we should simply say that <usern= ame> is a token, and MAY contain user ID, product ID, or whatever else. = And, if people don=92t want to include a value, they use =93-=93.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Wednesday 13 December 2017 at= 09:11
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Dale Worley <worley@ariadne.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4566bis: send= ing user ID in o=3D

Hi,

On Dec 13, 2017 1:55 AM, "Christer Holmberg= " <christer.holmberg@ericsson.com> wrote:
>So the answer is more = or less, "a user ID is a thing which can only
>start one SDP session per second".

which means one should not use a product name.

Which is true only if NTP is used for <sess-id>. If you use some othe= r way to generate sess-id for the given address, then it can be any string = with no spaces.

The only real requirements are that= combination of <username> &= lt;sess-id> <nettype> <addrtype> <unicast-address> is unique and that <sess-ve= rsion> monotonicaly increases. The rest are mostly outdated and widely ignored suggestions.

Roman Shpount
 --_000_D656A27727765christerholmbergericssoncom_-- From nobody Tue Dec 12 23:18:51 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA67126C26 for ; Tue, 12 Dec 2017 23:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 7ZZu1Q08T6Wr for ; Tue, 12 Dec 2017 23:18:46 -0800 (PST) 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 AC81B126BF3 for ; Tue, 12 Dec 2017 23:18:45 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-86-5a30d453d4b1 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.FA.27591.354D03A5; Wed, 13 Dec 2017 08:18:44 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 08:18:43 +0100 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: sending user ID in o= Thread-Index: AQHTc8pT1ngj5VYx1UGHMzWEdTkFlqNA6mAA///ggoCAACXUAIAAAEiA Date: Wed, 13 Dec 2017 07:18:43 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <87tvwvz23t.fsf@hobgoblin.ariadne.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.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D656A31327770christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7lm7IFYMog9ZWJoupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZby7v52loMexYtLZG6wNjI2WXYycHBICJhIr 7zWxdzFycQgJHGaUaF3ynQ3CWcIocerBaaYuRg4ONgELie5/2iANIgLREh8+LAALMwuoS1xd HAQSFgaac/H6NhaIElOJ9ztvs0LYbhJtr7Yzg9gsAqoSG79OYQOxeQWsJX7OPQS1aiGTxN6L R9hBEpwCNhLv3u8EsxkFxCS+n1rDBGIzC4hL3HoynwniaAGJJXvOM0PYohIvH/8DWyYqoCex 4cRtdoi4osTV6cuh7kyQuLjOAGKvoMTJmU9YJjCKzkIydRZC1SwkVRAlBhLvz81nhrC1JZYt fA1l60ts/HKWEcK2lvh99xQrspoFjByrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQIj8OCW 3wY7GF8+dzzEKMDBqMTDa37WIEqINbGsuDL3EKMEB7OSCG9PPFCINyWxsiq1KD++qDQntfgQ ozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QD4/z619rVnJxLV+jX/HFYuvelh/LLnrPl XzfVLrz/RnJ1afQln/cpLzUqtA0bao8/lF8+4cHahZttueadvCwyY9JtXbaqm3GfuH9sDzZ+ 2XU0htFv1rTYPk/e3qCt510mak5YuduQWzXA7MSkrlN3XVIW+Z+5d71q34eDXgfqLbSuBdyY GdWfmqHEUpyRaKjFXFScCAAqOXLevAIAAA== Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:18:47 -0000 --_000_D656A31327770christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think the risk for collision is very small, that is. From: mmusic > on b= ehalf of Christer Holmberg > Date: Wednesday 13 December 2017 at 09:17 To: Roman Shpount > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D Hi, With so many parameters forming the unique value, I don=92t think the risk = for collision is very small. My main issue is the text. Perhaps we should simply say that is = a token, and MAY contain user ID, product ID, or whatever else. And, if peo= ple don=92t want to include a value, they use =93-=93. Regards, Christer From: Roman Shpount > Date: Wednesday 13 December 2017 at 09:11 To: Christer Holmberg > Cc: Dale Worley >, "mmusic@ie= tf.org" > Subject: Re: [MMUSIC] 4566bis: sending user ID in o=3D Hi, On Dec 13, 2017 1:55 AM, "Christer Holmberg" > wrote: >So the answer is more or less, "a user ID is a thing which can only >start one SDP session per second". which means one should not use a product name. Which is true only if NTP is used for . If you use some other way = to generate sess-id for the given address, then it can be any string with n= o spaces. The only real requirements are that combination of is unique and that monot= onicaly increases. The rest are mostly outdated and widely ignored suggesti= ons. Roman Shpount --_000_D656A31327770christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <60BC08E9A4D93045A8451C8205467BB8@ericsson.com> Content-Transfer-Encoding: quoted-printable
I think the risk for collision is very small, that is.

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Wednesday 13 December 2017 at= 09:17
To: Roman Shpount <roman@telurix.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] 4566bis: send= ing user ID in o=3D

Hi,

With so many parameters forming the unique value, I don=92t think the = risk for collision is very small.

My main issue is the text. Perhaps we should simply say that <usern= ame> is a token, and MAY contain user ID, product ID, or whatever else. = And, if people don=92t want to include a value, they use =93-=93.

Regards,

Christer

From: Roman Shpount <roman@telurix.com>
Date: Wednesday 13 December 2017 at= 09:11
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Dale Worley <worley@ariadne.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] 4566bis: send= ing user ID in o=3D

Hi,

On Dec 13, 2017 1:55 AM, "Christer Holmberg= " <christer.holmberg@ericsson.com> wrote:
>So the answer is more = or less, "a user ID is a thing which can only
>start one SDP session per second".

which means one should not use a product name.

Which is true only if NTP is used for <sess-id>. If you use some othe= r way to generate sess-id for the given address, then it can be any string = with no spaces.

The only real requirements are that= combination of <username> &= lt;sess-id> <nettype> <addrtype> <unicast-address> is unique and that <sess-ve= rsion> monotonicaly increases. The rest are mostly outdated and widely ignored suggestions.

Roman Shpount
 --_000_D656A31327770christerholmbergericssoncom_-- From nobody Wed Dec 13 00:48:59 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA17F12700F for ; Wed, 13 Dec 2017 00:48:57 -0800 (PST) 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 KiKQubT1t5lI for ; Wed, 13 Dec 2017 00:48:54 -0800 (PST) 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 5F861120726 for ; Wed, 13 Dec 2017 00:48:54 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-10-5a30e97451c9 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.5E.13339.479E03A5; Wed, 13 Dec 2017 09:48:52 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 09:48:47 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqaNAAXaAgAAl+aCAAAFnsP//8koAgAATnwCAANyDAA== Date: Wed, 13 Dec 2017 08:48:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> 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.7.170905 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7rm7JS4Mog4YzGhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx5ZlWwUyrik3TORoYP2t0MXJySAiYSGxe e4G9i5GLQ0jgMKPEzVMPmSCcJYwS/QfWMXYxcnCwCVhIdP/TBmkQEfCVePb4NhuILSxgJPF+ 8WImiLixxMGG2awQdpjE8o/PmUFsFgFViaM9L8HqeQWsJRac3MIMMb+dWeLPh4csIAlOAQeJ Pxt2gNmMAmIS30+tARvKLCAucevJfCaISwUkluw5zwxhi0q8fPwPbJmogJ7EhhO32UHulBBQ lFjeLwfRqidxY+oUNgjbWuLIuWOsELa2xLKFr5kh7hGUODnzCcsERrFZSLbNQtI+C0n7LCTt s5C0L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGFMHt/xW3cF4+Y3jIUYBDkYlHt7u pwZRQqyJZcWVuYcYJTiYlUR4e+KBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5ak ZqemFqQWwWSZODilGhjZC9fvWXP/zBvJ8q8JwlsEdpsd14xrLhJtYPDbbX6MVWiFiLVpbf3b u7u/F4tdr9//36F20U1Hj3OLtxi2SP5cMyuei0Xr6tW9EyNDrmxXuBC/6MtuSfYUzwqNCObl PbXrGd2sDS6Ef8ta4rPYa/vHpJC62XXtGUWcM0uN9mwq5hfoSgv9PEeJpTgj0VCLuag4EQCo 82erpQIAAA== Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 08:48:57 -0000 Hi, >>The issue is, once again, third party call control and unexpected SDP >> offer collisions between two SIP sessions. Because of this, if offer >> goes from one SIP session to another due to B2BUA and third party call >> control, it is important that o=3D line accidentally did not end up bein= g >> the same between two sessions. If o=3D line is the same, some clients do >> not parse or compare SDP, assuming this is the same SDP description. >> Because of this, it is important for o=3D line to be globally unique. On= e >> option is to use unique system identifier (IP or host name), session >> identifier and version in the session. Another option is to use >> something random which is long enough to be unique. > >As things are currently specified, it isn't valid for the session to >change for the duration of the sip dialog. A 3PCC B2BUA is responsible >for ensuring this remains the case during a transfer. How it does so is >its business, but in the end will require rewriting SDP. > >However, I realize that doesn't often (ever?) happen. Perhaps there >ought to be an effort to change things to acknowledge that the session >can change, and specify what is to happen when it does. This of course depends on what we mean by =B3session=B2. Even if the SIP session doesn=B9t change, does it mean the SDP session can=B9t change? Regards, Christer >> When offer is generated when ICE is used, client might not know the >> globally unique IP address when offer is generated. Client can use >>local=20 >> NATed address, but this often results in collisions. The actual advise >> for this case (use local IP) is actually counter productive, since >>using=20 >> local IP is more likely to result in collisions then using something >> random. This probably needs to be corrected. >>=20 >> Regards, >>=20 >> _____________ >> Roman Shpount >>=20 >> On Tue, Dec 12, 2017 at 3:28 PM, Christer Holmberg >> >> >> wrote: >>=20 >> Hi,____ >>=20 >> __ __ >>=20 >> I seems like I placed a question in the wrong place.____ >>=20 >> __ __ >>=20 >> It should be:____ >>=20 >> __ __ >>=20 >> =B3I understand that, but I don=B9t see what ICE has to do with it. = How >> is using a local address going to make the SDP unique just because I >> use ICE?=B2____ >>=20 >> __ __ >>=20 >> Regards,____ >>=20 >> __ __ >>=20 >> Christer____ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> *From:*mmusic [mailto:mmusic-bounces@ietf.org >> ] *On Behalf Of *Christer Holmberg >> *Sent:* 12 December 2017 22:25 >> *To:* Roman Shpount > >> *Cc:* mmusic@ietf.org >> *Subject:* Re: [MMUSIC] 4566bis: local address in o=3D____ >>=20 >> __ __ >>=20 >> Hi,____ >>=20 >> __ __ >>=20 >> >I think the intent here is to generate something similar to GUID >> which will uniquely identify the SDP description,____ >>=20 >> __ __ >>=20 >> I understand that, but I don=B9t see what ICE has to do with it.____ >>=20 >> __ __ >>=20 >> > but this is severely outdated for cases like ICE or privacy. How >> is using a local address going to make the SDP unique just because I >> use ICE?____ >>=20 >> >__ __ >>=20 >> > I think this needs to be updated to use sufficiently large random >> strings instead of IP addresses, hostnames and ____ >>=20 >> > user IDs, when local address or host name is not available or >> should not be exposed due to privacy reasons.____ >>=20 >> __ __ >>=20 >> With SIP and offer/answer, is there even a need to uniquely identity >> the SDP description? The SDP will always be associated with a >> uniquely identified SIP session.____ >>=20 >> __ __ >>=20 >> Regards,____ >>=20 >> __ __ >>=20 >> Christer____ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> __ __ >>=20 >> On Tue, Dec 12, 2017 at 6:33 AM, Christer Holmberg >> > > wrote:____ >>=20 >> Hi,____ >>=20 >> __ __ >>=20 >> The text says:____ >>=20 >> __ __ >>=20 >> is an address of the machine from which >>the____ >>=20 >> session was created. For an address type of >> IP4, this is either a____ >>=20 >> fully qualified domain name of the machine >> or the dotted-decimal____ >>=20 >> representation of an IP version 4 address of >> the machine. For an____ >>=20 >> address type of IP6, this is either a fully >> qualified domain name____ >>=20 >> of the machine or the compressed textual >> representation of an IP____ >>=20 >> version 6 address of the machine. For both >> IP4 and IP6, the fully____ >>=20 >> qualified domain name is the form that >> SHOULD be given unless this____ >>=20 >> is unavailable, in which case a globally >> unique address MAY be____ >>=20 >> substituted. Unless an SDP extension for NAT >> traversal is used____ >>=20 >> (e.g., ICE [RFC5245], ICE TCP [RFC6544]), a >> local IP address MUST____ >>=20 >> NOT be used in any context where the SDP >> description might leave____ >>=20 >> the scope in which the address is meaningful >> (for example, a local____ >>=20 >> address MUST NOT be included in an >> application-level referral that____ >>=20 >> might leave the scope).____ >>=20 >> First, I guess it could be clarified that the =B3address of the >> machine=B2 does not have to be the address used for the media >> (found in the c=3D line).____ >>=20 >> __ __ >>=20 >> Second, I am not sure I understand how the support of ICE allows >> the usage of a local address. The combination of o=3D line parts >> are supposed to create a unique identifier, so what does ICE >> have to do with that?____ >>=20 >> __ __ >>=20 >> Regards,____ >>=20 >> __ __ >>=20 >> Christer____ >>=20 >> __ __ >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> ____ >>=20 >> __ __ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Dec 13 01:54:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C50127AD4 for ; Wed, 13 Dec 2017 01:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YlITHbfOcoqd for ; Wed, 13 Dec 2017 01:54:15 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1CA127843 for ; Wed, 13 Dec 2017 01:54:15 -0800 (PST) Received: from [81.187.2.149] (port=40587 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eP3jx-0006TF-MC; Wed, 13 Dec 2017 09:54:13 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: Date: Wed, 13 Dec 2017 09:54:10 +0000 Cc: Christer Holmberg , "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4A2A6AF4-B617-44D6-81A4-E290C322121A@csperkins.org> References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> To: Roman Shpount X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:54:17 -0000 Hi, > On 12 Dec 2017, at 20:29, Roman Shpount wrote: >=20 > I think the original intent was the logged in user in the computer = system. I remember RAT (Real Audio Tool) looking at the logged in user = on UNIX and putting =E2=80=9Cuser" on Windows. Right - originally all this stuff (vic, RAT, sdr, etc.) was running on = Unix workstations, and the username in SDP (and the username part of the = RTCP CNAME) was the Unix login name of the user. The Windows ports made = us think a little more about this, which is where the =E2=80=9C-=E2=80=9C = came from. These days, we likely want to say SHOULD use =E2=80=9C-=E2=80=9C= but allow other values that look like a username for backwards = compatibility. --=20 Colin Perkins https://csperkins.org/ From nobody Wed Dec 13 01:57:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA32A127B60 for ; Wed, 13 Dec 2017 01:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 xHJt0I_R0ePi for ; Wed, 13 Dec 2017 01:57:46 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50447126C26 for ; Wed, 13 Dec 2017 01:57:46 -0800 (PST) Received: from [81.187.2.149] (port=33307 helo=[192.168.0.71]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1eP3nM-0006rA-8M; Wed, 13 Dec 2017 09:57:44 +0000 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E30E4323-27E6-4AD9-B653-2085D1FA4FC8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Dec 2017 09:57:42 +0000 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> Cc: Roman Shpount , "mmusic@ietf.org" To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:57:48 -0000 --Apple-Mail=_E30E4323-27E6-4AD9-B653-2085D1FA4FC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Dec 2017, at 20:24, Christer Holmberg = wrote: >=20 > Hi, > =20 > >I think the intent here is to generate something similar to GUID = which will uniquely identify the SDP description, > =20 > I understand that, but I don=E2=80=99t see what ICE has to do with it. > =20 > > but this is severely outdated for cases like ICE or privacy. How is = using a local address going to make the SDP unique just because I use = ICE? > >=20 > > I think this needs to be updated to use sufficiently large random = strings instead of IP addresses, hostnames and=20 > > user IDs, when local address or host name is not available or should = not be exposed due to privacy reasons. > =20 > With SIP and offer/answer, is there even a need to uniquely identity = the SDP description? The SDP will always be associated with a uniquely = identified SIP session. Remember this comes from the Mbone days with multicast session = directories. For that type of use, uniquely identifying SDP descriptions = is important. The Mbone is surely dead, but declarative SDP isn=E2=80=99t = necessarily, so the ability to uniquely identify the SDP is maybe still = needed. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_E30E4323-27E6-4AD9-B653-2085D1FA4FC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 12 Dec 2017, at 20:24, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,
 
>I think the intent here is to generate something similar = to GUID which will uniquely identify the SDP description,
 
I understand that, but I don=E2=80=99t see what = ICE has to do with it.
 
> but this is severely outdated for cases like ICE or = privacy. How is using a local address going to make the SDP unique just = because I use ICE?
> 
> I think this needs to be updated to use = sufficiently large random strings instead of IP addresses, hostnames = and 
> user IDs, when local = address or host name is not available or should not be exposed due to = privacy reasons.
 
With SIP and offer/answer, = is there even a need to uniquely identity the SDP description? The SDP = will always be associated with a uniquely identified SIP = session.

Remember this comes from the Mbone days with = multicast session directories. For that type of use, uniquely = identifying SDP descriptions is important. The Mbone is surely dead, but = declarative SDP isn=E2=80=99t necessarily, so the ability to uniquely = identify the SDP is maybe still needed.

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_E30E4323-27E6-4AD9-B653-2085D1FA4FC8-- From nobody Wed Dec 13 02:08:17 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E3E124B17 for ; Wed, 13 Dec 2017 02:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 VkeRH57EWKmW for ; Wed, 13 Dec 2017 02:08:13 -0800 (PST) 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 7FE891200CF for ; Wed, 13 Dec 2017 02:08:13 -0800 (PST) X-AuditID: c1b4fb30-11d5e9c000006bc7-24-5a30fc0b6381 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 86.A2.27591.B0CF03A5; Wed, 13 Dec 2017 11:08:11 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 11:08:10 +0100 From: Christer Holmberg To: Colin Perkins CC: Roman Shpount , "mmusic@ietf.org" Thread-Topic: [MMUSIC] 4566bis: local address in o= Thread-Index: AQHTczz4oewluGKnjUiWFPJYPXaRqaNAAXaAgAAl+aCAANL1AIAAJw0A Date: Wed, 13 Dec 2017 10:08:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> 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.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D656CA7B278B0christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7hy73H4Mog3/XVCyWvzzBaDF1+WMW ixkXpjI7MHtMu3+fzWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlTDn3iqXgoFlF57+3LA2M G/S6GDk5JARMJL50zWfrYuTiEBI4zChxa8ViJghnCaPElPl72bsYOTjYBCwkuv9pgzSICKhK 7Dj+jxHEZhbwkmiYvZ0NxBYWMJJ4vxikF6TGWOJgw2xWCNtNYmfHG7B6FqDe/z3LwWxeAWuJ a39XQy3+yyjx6/xWsGZOAUeJXwvmsYDYjAJiEt9PrWGCWCYucevJfCaIqwUkluw5zwxhi0q8 fPwPbJmogJ7EhhO32SHiihI7z7YzQ/QmSMz7CXEQr4CgxMmZT1gmMIrOQjJ2FpKyWUjKIOIG Eu/PzWeGsLUlli18DWXrS2z8cpYRwraWWPD1LBuymgWMHKsYRYtTi5Ny042M9FKLMpOLi/Pz 9PJSSzYxAmPz4JbfBjsYXz53PMQowMGoxMO744lBlBBrYllxZe4hRgkOZiUR3p54oBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZJg5OqQbG4oVndn+I+bhgvove 0ooYvYUvYjWtzy/pmh3vJHT9oNdBYZHeL1mlxxeYfJCrnpoo9+BZXkOP6xU+N52Omr/HJHt+ NGqwFpZ8fvF8Dt8uoT+WTtPS/2sY9X02il1Q7qomtq7q34b0P0IL+bgdC00LW512d8Wx7/7A YrZyas2Hmwv/RT0LKutSYinOSDTUYi4qTgQAOci3j8kCAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:08:16 -0000 --_000_D656CA7B278B0christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Hi, >I think the intent here is to generate something similar to GUID which wil= l uniquely identify the SDP description, I understand that, but I don=92t see what ICE has to do with it. > but this is severely outdated for cases like ICE or privacy. How is using= a local address going to make the SDP unique just because I use ICE? > > I think this needs to be updated to use sufficiently large random strings= instead of IP addresses, hostnames and > user IDs, when local address or host name is not available or should not = be exposed due to privacy reasons. With SIP and offer/answer, is there even a need to uniquely identity the SD= P description? The SDP will always be associated with a uniquely identified= SIP session. > Remember this comes from the Mbone days with multicast session directorie= s. For that type of use, uniquely identifying SDP descriptions is important= . The Mbone is surely dead, but declarative SDP isn=92t necessarily, so the= ability to uniquely identify the SDP is maybe still needed. Sure. But, then the text could mandate uniqueness, unless there is some oth= er mechanism to ensure it. Anyway, I have no issue with mandating uniqueness. My issue is more the tex= t on addresses itself. Regards, Christer --_000_D656CA7B278B0christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Hi,
 
>I think the intent here is to generate something similar to GUID which = will uniquely identify the SDP description,
 
I understand that, but I don=92t see what ICE has to do with it.
 
> but this is severely outdated for cases like ICE or privacy. How is us= ing a local address going to make the SDP unique just because I use ICE?
> 
> I think this needs to be updated to use sufficiently large random stri= ngs instead of IP addresses, hostnames and 
> user IDs, = when local address or host name is not available or should not be exposed d= ue to privacy reasons.
 
With SIP and offer/answer, is there even a need to uniquely identity the= SDP description? The SDP will always be associated with a uniquely identif= ied SIP session.

> Remember this comes from the Mbone days with multicast session di= rectories. For that type of use, uniquely identifying SDP descriptions is i= mportant. The Mbone is surely dead, but declarative SDP isn=92t necessarily= , so the ability to uniquely identify the SDP is maybe still needed.

Sure. But, then the text could mandate uniqueness, unless there is som= e other mechanism to ensure it.

Anyway, I have no issue with mandating uniqueness. My issue is more th= e text on addresses itself.

Regards,

Christer






 --_000_D656CA7B278B0christerholmbergericssoncom_-- From nobody Wed Dec 13 07:55:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5239312783A for ; Wed, 13 Dec 2017 07:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ISZbLQnPydrE for ; Wed, 13 Dec 2017 07:55:54 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 394C3127337 for ; Wed, 13 Dec 2017 07:55:52 -0800 (PST) X-AuditID: 12074414-0ebff70000006ddf-79-5a314d8624da Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D2.D4.28127.68D413A5; Wed, 13 Dec 2017 10:55:50 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vBDFtmsJ029003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 13 Dec 2017 10:55:50 -0500 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B6C05117A@ESESSMB109.ericsson.se> <87tvwvz23t.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <35c13e91-16da-13a0-d5e3-5c91c4e245b6@alum.mit.edu> Date: Wed, 13 Dec 2017 10:55:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixO6iqNvmaxhl0HjCyGLq8scsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKuHBtLWPBHq6KRbfesDYwzuLoYuTkkBAwkVi3+zhjFyMXh5DA DiaJqZcXsUI435kkVr26zA5SJQxUdfH6NhYQW0RAWGLG279sEEXvGSWW/PvHCpJgE9CSmHPo P1gRr4C9RMu5tWwgNouAqsSWdeuZQGxRgTSJPRc6oGoEJU7OfAJmcwoESjzYvwpsGbOAmcS8 zQ+ZIWxxiVtP5jNB2PISzVtnM09g5J+FpH0WkpZZSFpmIWlZwMiyilEuMac0Vzc3MTOnODVZ tzg5MS8vtUjXQi83s0QvNaV0EyMkMEV2MB45KXeIUYCDUYmHl8PAMEqINbGsuDL3EKMkB5OS KO8rH6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV5ZFqAcb0piZVVqUT5MSpqDRUmc99tidT8h gfTEktTs1NSC1CKYrAwHh5IE72aQoYJFqempFWmZOSUIaSYOTpDhPEDDD4PU8BYXJOYWZ6ZD 5E8xGnP09Nz4w8TxbObrBmYhlrz8vFQpcd6P3kClAiClGaV5cNNgyeUVozjQc8K8NiADeYCJ CW7eK6BVTECrnrfog6wqSURISTUwTlSvsghadUHr9fMkLg2zT+VbDnYu8Puz/7dkuP0Nobcx j7+yze5hYTUP8400Ucha9tzu3gTu5YseMRhNErt5aqY4m4vKpM+3xAt4ftf3GFlfWDXBwFR0 VatAxfUlT49WXY7InVHmcXnSpR1rO4o2rIrYxzbr5JbXs5jD1ItYf59P1T9i1fm6S4mlOCPR UIu5qDgRAHMWDvUJAwAA Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 15:55:56 -0000 On 12/13/17 2:11 AM, Roman Shpount wrote: > Hi, > > On Dec 13, 2017 1:55 AM, "Christer Holmberg" > > > wrote: > > >So the answer is more or less, "a user ID is a thing which can only > >start one SDP session per second". > > which means one should not use a product name. > > > Which is true only if NTP is used for . If you use some other > way to generate sess-id for the given address, then it can be any string > with no spaces. > > The only real requirements are that combination of >   is unique and that > monotonicaly increases. The rest are mostly outdated and widely ignored > suggestions. To be pedantic for a moment: Even if every implementation takes care to ensure that each combined value they generate is unique from every other, without any agreement on how these are formed there is a risk that values from different implementations may conflict. Stepping back to the real world, I agree that the *likelihood* of such a conflict is small. This risk is eliminated if everyone follows the "suggestion" to use an NTP timestamp. Perhaps it is time to elevate this suggestion to SHOULD. Thanks, Paul From nobody Wed Dec 13 08:01:59 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF091270B4 for ; Wed, 13 Dec 2017 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 E49pDb0wG-ZL for ; Wed, 13 Dec 2017 08:01:51 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 13D5512009C for ; Wed, 13 Dec 2017 08:01:50 -0800 (PST) X-AuditID: 12074412-1fdff7000000748d-c4-5a314eedcfb2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C3.F6.29837.DEE413A5; Wed, 13 Dec 2017 11:01:49 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vBDG1mkP029348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Dec 2017 11:01:49 -0500 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B6C0511A9@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C051222@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <940d7ae9-f66d-1c72-b18d-faf188f06a58@alum.mit.edu> Date: Wed, 13 Dec 2017 11:01:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixO6iqPvOzzDKYPEZJosLMw8zWkxd/pjF gcnj19erbB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYumMJe8EjvootD3cyNzDe5u5i5OSQEDCR eLB2ElMXIxeHkMAOJolLnzrZIJyHTBI9fycygVQJCxhJvF+8GMjm4BARSJE40sUIUbOTWaJ1 2jlWkBo2AS2JOYf+s4DYvAL2EnuOr2EDsVkEVCWWT3gHFhcVSJPYc6EDqkZQ4uTMJ2A2p4CN xJPzlxlBbGYBM4l5mx8yQ9jiEreezGeCsOUlmrfOZp7AyD8LSfssJC2zkLTMQtKygJFlFaNc Yk5prm5uYmZOcWqybnFyYl5eapGumV5uZoleakrpJkZIqArtYFx/Uu4QowAHoxIPL4eBYZQQ a2JZcWXuIUZJDiYlUd5XPkAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryyLEA53pTEyqrUonyY lDQHi5I478/F6n5CAumJJanZqakFqUUwWRkODiUJXnlgTAoJFqWmp1akZeaUIKSZODhBhvMA Da/0BRleXJCYW5yZDpE/xWjM0dNz4w8Tx7OZrxuYhVjy8vNSpcR5e0BKBUBKM0rz4KbB0s0r RnGg54R5o0GW8gBTFdy8V0CrmIBWPW/RB1lVkoiQkmpg7IpyZnDYy1eVGPN2m+/Ohe8PHF9w QfaZxMxqrUf+SmfUc2WcPirek1x9mn+ZWVLNShW2lZwTD98yXzZZ9stBHTkL5hvGHV3HQxUU Nnmb/Hz0gFNM8sO/tScXH6yPDFkipMKgLH1E2MXv++SnfntzXztXfuTZJ8/y/tr9+5Zz9mok dSS8njq3SomlOCPRUIu5qDgRAFITi64SAwAA Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 16:01:57 -0000 On 12/13/17 3:48 AM, Christer Holmberg wrote: > Hi, > >>> The issue is, once again, third party call control and unexpected SDP >>> offer collisions between two SIP sessions. Because of this, if offer >>> goes from one SIP session to another due to B2BUA and third party call >>> control, it is important that o= line accidentally did not end up being >>> the same between two sessions. If o= line is the same, some clients do >>> not parse or compare SDP, assuming this is the same SDP description. >>> Because of this, it is important for o= line to be globally unique. One >>> option is to use unique system identifier (IP or host name), session >>> identifier and version in the session. Another option is to use >>> something random which is long enough to be unique. >> >> As things are currently specified, it isn't valid for the session to >> change for the duration of the sip dialog. A 3PCC B2BUA is responsible >> for ensuring this remains the case during a transfer. How it does so is >> its business, but in the end will require rewriting SDP. >> >> However, I realize that doesn't often (ever?) happen. Perhaps there >> ought to be an effort to change things to acknowledge that the session >> can change, and specify what is to happen when it does. > > This of course depends on what we mean by ³session². Even if the SIP > session doesn¹t change, does it mean the SDP session can¹t change? I'd have to reread all the relevant text to be certain, but I'm pretty sure the current text at least implies that a given dialog is tied to a single SDP session. Certainly there is nothing that explains what is to be done if the SDP session changes. IMO this is an open issue that has been studiously ignored forever. Question is whether there is any interest in confronting it. But this isn't an issue for 4566bis. Thanks, Paul From nobody Wed Dec 13 13:12:18 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B15126B7E; Wed, 13 Dec 2017 13:12:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151319953642.30031.5747921986115374317@ietfa.amsl.com> Date: Wed, 13 Dec 2017 13:12:16 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-44.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:12:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-44.txt Pages : 67 Date : 2017-12-13 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m=" section without meaning that the media described by the "m=" section is disabled or rejected. When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new Real-time Transport Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-44 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-44 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-44 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 13 13:14:49 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FDF126B7E for ; Wed, 13 Dec 2017 13:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 MTIzhyaOP4X3 for ; Wed, 13 Dec 2017 13:14:46 -0800 (PST) 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 CAD94126E7A for ; Wed, 13 Dec 2017 13:14:42 -0800 (PST) X-AuditID: c1b4fb2d-b35ff70000007932-e7-5a319840f6d3 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.87.31026.048913A5; Wed, 13 Dec 2017 22:14:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 13 Dec 2017 22:14:40 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-44 Thread-Index: AdN0VyOpNHXVhnjeTNmYaEspK/Mi6w== Date: Wed, 13 Dec 2017 21:14:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C05453A@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C05453AESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM2K7ja7DDMMogzePrC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ6jS5kK1ktVHDxc18DYKt7FyMkhIWAi0XFwEksXIxeHkMBh RomfX38ygiSEBJYwSuxcaNXFyMHBJmAh0f1PGyQsIqAu8XVvDzNIWFhAVeLtjXiIsJbE27cH 2CBsPYl/k2cygZSwAJV0nk0CCfMK+Epce3SLCcRmFBCT+H5qDZjNLCAucevJfCaIawQkluw5 zwxhi0q8fPyPFcJWklix/RIjRH2+xLQva9ggZgpKnJz5hGUCo+AsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2IULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIDPmDW37r 7mBc/drxEKMAB6MSD29xg2GUEGtiWXFl7iFGCQ5mJRFetYlAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYzZla9mllya4f6k3i/RjOWMzdWUyPoy0ZXe GmoxW1YlRdcc2/k96grHxx1WtsmFefefsfDoJL11kbovrM71jbHu5GmZig4mB1XOO/vLuH80 zJhX32pzdMWPIp8bwruDtwSxKdboX3l/mL3rqkKG9NQbm+b3BFhWXv/z9W1JS9iTrarzk1/v LlJiKc5INNRiLipOBACJYs0ddQIAAA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-44 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:14:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C05453AESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the WG chair reviews by Flemming and Bo, I have submitted a new ve= rsion of BUNDLE. There are quite a few changes, but most are editorial, and a huge part are = very simple ones (spelling errors, missing dots etc). I have also closed Taylor's GitHub issues, and a couple of them had yet not= been implemented, so I added some text based on those. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6C05453AESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the WG chair reviews by Flemming and Bo, I = have submitted a new version of BUNDLE.

 

There are quite a few changes, but most are editoria= l, and a huge part are very simple ones (spelling errors, missing dots etc)= .

 

I have also closed Taylor’s GitHub issues, and= a couple of them had yet not been implemented, so I added some text based = on those.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C05453AESESSMB109erics_-- From nobody Wed Dec 13 19:09:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E15120727 for ; Wed, 13 Dec 2017 19:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Av2ynFetP2dz for ; Wed, 13 Dec 2017 19:09:53 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 9B43C127078 for ; Wed, 13 Dec 2017 19:09:53 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id PJu1ebYsq2SVIPJuCelMdP; Thu, 14 Dec 2017 03:09:52 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-11v.sys.comcast.net with SMTP id PJuBe5jqcPxZnPJuCef3dL; Thu, 14 Dec 2017 03:09:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vBE39pr2019912; Wed, 13 Dec 2017 22:09:51 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBE39prB019909; Wed, 13 Dec 2017 22:09:51 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg Cc: pkyzivat@alum.mit.edu, mmusic@ietf.org In-Reply-To: Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 13 Dec 2017 22:09:51 -0500 Message-ID: <87bmj2yphc.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfKuv3qM9kI8ppJPpmXeBRf5sNWu5reKR49BcvllrSSREx60gVFtZMNW344B+sNRwNb5aTrLNqA2YsVcmUMTUvJrjyaelSyv33xaMJWW+N1hTtckGeEfy 0RWap11ti1Onjg23BKmZLwspAc1hiNRFV/omjK85Ydl/yqUFEphJo1+OQJ17eCjKUbVrK/4J9MPd+fzP4wuiL/Cr+rm7of8kciVMHyIm2gW2PeY0i4YYoUSO Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 03:09:55 -0000 Christer Holmberg writes: > This of course depends on what we mean by 'session'. Even if the SIP > session doesn't change, does it mean the SDP session can't change? s/SIP session/SIP dialog/ The RFCs presume that a SIP dialog will be associated with exactly one SDP session, and so if a UA does 3PCC gymnastics, the UA has to adjust the SDP that it passes through to match the requirements for "a successor SDP for a session". (I once hacked through this in detail -- see what that looks like in RFC 7088. It's not pretty.) The odds are that most devices don't enforce these requirements strictly. But clearly, some do -- I've seen complaints about one device that terminated a dialog if it received SDP with the wrong sess-id. Certainly, there are devices that assume that if the o= line doesn't change, the rest of the SDP must be the same as before. Dale From nobody Wed Dec 13 19:15:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91A61276AF for ; Wed, 13 Dec 2017 19:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1erhFJSa2z9T for ; Wed, 13 Dec 2017 19:15:13 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 8884412426E for ; Wed, 13 Dec 2017 19:15:13 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with ESMTP id PJyxeuUcTtSqDPJzMeTpe7; Thu, 14 Dec 2017 03:15:12 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with SMTP id PJzKeZxVhOvz8PJzLeMk1l; Thu, 14 Dec 2017 03:15:12 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vBE3FAqT020217; Wed, 13 Dec 2017 22:15:10 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vBE3FA3S020214; Wed, 13 Dec 2017 22:15:10 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Roman Shpount Cc: christer.holmberg@ericsson.com, mmusic@ietf.org In-Reply-To: (roman@telurix.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 13 Dec 2017 22:15:10 -0500 Message-ID: <878te6yp8h.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHCsQcXxsNz24EDoR9ng8WKv1GXjfcZXEXBGYA90Gy2dEKJdVD3R6UmBEEkU62Z+igmvahoJnl00JCM6s8dLADGM7+Kk1yKbM9TPlNQ8CvxOQZIn2ubn G9Gvn3XOEBO1EbspH86t9ZdH5HCYRIzcqvMD7nRatbpO6oJN1gqtktQWA0jyfYjHm3uCaA1AnIx+1Q/yYWPSH57YnYbFZ75tsMh7hdWZc77aLBqF9/FSXr6p Archived-At: Subject: Re: [MMUSIC] 4566bis: sending user ID in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 03:15:15 -0000 Roman Shpount writes: > The only real requirements are that combination of > is unique and that > monotonicaly increases. The rest are mostly outdated and widely ignored > suggestions. Basically, no other requirement is verifiable from outside the UA, and so isn't enforceable. Of course, actually satisfying that requirement isn't so easy. As Christer points out on another thread, has low information content in a world with NATs. So either or needs to contain a large number of statistically-random bits. Dale From nobody Wed Dec 13 19:55:35 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A513126D74 for ; Wed, 13 Dec 2017 19:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ljplgwil_qAq for ; Wed, 13 Dec 2017 19:55:24 -0800 (PST) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3441270A0 for ; Wed, 13 Dec 2017 19:55:21 -0800 (PST) X-AuditID: 1207440c-7e5ff7000000143e-f4-5a31f626c5a7 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 89.CB.05182.726F13A5; Wed, 13 Dec 2017 22:55:19 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vBE3tHCk003701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 Dec 2017 22:55:17 -0500 To: "Dale R. Worley" , Christer Holmberg Cc: mmusic@ietf.org References: <87bmj2yphc.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <2894813e-736b-3eb2-77c3-582e3532a5d5@alum.mit.edu> Date: Wed, 13 Dec 2017 22:55:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <87bmj2yphc.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixO6iqKv+zTDK4PR6fYsLMw8zWkxd/pjF 4uWJMgdmj8n7vzJ7/Pp6lc1jyZKfTAHMUVw2Kak5mWWpRfp2CVwZO65/Zyv4ylnx9HgrSwPj a/YuRk4OCQETiYs7ZrB0MXJxCAnsYJJ4ffYGlPOQSeJq835GkCphASOJ94sXM3UxcnCICKRJ rPztCBJmFhCWuLP8PyNIWAio5NHXDJAwm4CWxJxD/1lAbF4Be4lFXWvBbBYBVYm/r+4zg9ii QFP2XOiAqhGUODnzCZjNKWAs8aJzIQvEeDOJeZsfMkPY4hK3nsxngrDlJba/ncM8gVFgFpL2 WUhaZiFpmYWkZQEjyypGucSc0lzd3MTMnOLUZN3i5MS8vNQiXUO93MwSvdSU0k2MkIDm2cH4 bZ3MIUYBDkYlHt4NuoZRQqyJZcWVuYcYJTmYlER5fz4DCvEl5adUZiQWZ8QXleakFh9ilOBg VhLhVZsIlONNSaysSi3Kh0lJc7AoifOqLlH3ExJITyxJzU5NLUgtgsnKcHAoSfC++QLUKFiU mp5akZaZU4KQZuLgBBnOAzT8OEgNb3FBYm5xZjpE/hSjMUdPz40/TBzPZr5uYBZiycvPS5US 570LUioAUppRmgc3DZaUXjGKAz0nzOv/FaiKB5jQ4Oa9AlrFBLTqeYs+yKqSRISUVAOjI/fz d+W6/jPOGNpe+3xU7H1v62Fp3R3F/YvO1k33/ymrHKrGtriR5UCMY/YkB/ODh59GdrAJaq1P 7GC3tjlyzuXIgZ2zcoVc7714P7X6/+4dTQtUpi44HDVpY4X1HNuq6VY6+6pm/D5a4XZve1jY meijahKhyZN7w+p1J1Yzv7UoSVrP0PhbiaU4I9FQi7moOBEAH9PlPSUDAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: local address in o= X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 03:55:34 -0000 On 12/13/17 10:09 PM, Dale R. Worley wrote: > Christer Holmberg writes: >> This of course depends on what we mean by 'session'. Even if the SIP >> session doesn't change, does it mean the SDP session can't change? > > s/SIP session/SIP dialog/ > > The RFCs presume that a SIP dialog will be associated with exactly one > SDP session, and so if a UA does 3PCC gymnastics, the UA has to adjust > the SDP that it passes through to match the requirements for "a > successor SDP for a session". (I once hacked through this in detail -- > see what that looks like in RFC 7088. It's not pretty.) > > The odds are that most devices don't enforce these requirements > strictly. But clearly, some do -- I've seen complaints about one device > that terminated a dialog if it received SDP with the wrong sess-id. > Certainly, there are devices that assume that if the o= line doesn't > change, the rest of the SDP must be the same as before. That is encouraged by the text that defines the semantics. As a programmer I am never so trusting. I always process the SDP as if it were changed, or else verify it is unchanged. (E.g. save and check a hash of the body.) But I guess some implementors are more trusting. From nobody Thu Dec 14 05:15:22 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3256A124205; Thu, 14 Dec 2017 05:15:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151325731614.6234.7778847254784357919@ietfa.amsl.com> Date: Thu, 14 Dec 2017 05:15:16 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-45.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 13:15:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-45.txt Pages : 67 Date : 2017-12-14 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m=" section without meaning that the media described by the "m=" section is disabled or rejected. When Real-time Transport Protocol (RTP)-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-45 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-45 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-45 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 05:17:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9582128DF2 for ; Thu, 14 Dec 2017 05:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 uLFzjs7YZnTR for ; Thu, 14 Dec 2017 05:17:33 -0800 (PST) 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 CD98E1292CE for ; Thu, 14 Dec 2017 05:17:31 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-23-5a3279e91458 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 11.34.13339.9E9723A5; Thu, 14 Dec 2017 14:17:29 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Thu, 14 Dec 2017 14:17:26 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: BUNDLE-45 Thread-Index: AQHTdN3i1QmGj3O3l0+v+eZriJoXlQ== Date: Thu, 14 Dec 2017 13:17:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D65848B527BEAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7je7LSqMog/Y7NhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt05bewFpzkqNs2dztzAuIu9i5GTQ0LARGLe6pfMXYxcHEIC hxkldvafZ4dwljBKLHw/ESjDwcEmYCHR/U8bpEFEQF3i694eZhBbWEBV4vbMs+wgJSICWhI3 jqlAlOhJzDy1gA3EZgEq6ejZDlbOK2At8ePMHBYQm1FATOL7qTVMIDazgLjErSfzmSDuEZBY suc8M4QtKvHy8T9WEFsUaOaGE7fBVkkIKElM25oG0ZogsWv1OajxghInZz5hmcAoNAvJ1FlI ymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGOoXmuJKbceMiKrWcDIsYpRtDi1OCk33chYL7Uo M7m4OD9PLy+1ZBMjME4ObvmtuoPx8hvHQ4wCHIxKPLz3MoyihFgTy4orcw8xSnAwK4nwtkYD hXhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTBKr7pmuvns vQ9pk+SeXOz/8bKp0aT5m/9N+ZleovIm6avMDkrVieWmBUvwRfj7fo9l3yMuJfZ7yifb0r1K hrEXu7Qn25extQmcLNM4fnlxq+X0T3VTgp5dyajlTFNmuhK0ItnqYTH/icfyD2t2m51cdfDE pSdflqU18gpGG7panaj5dfSUQ5kSS3FGoqEWc1FxIgBcgnxNjwIAAA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-45 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 13:17:35 -0000 --_000_D65848B527BEAchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Colin found a couple of abbreviation nits in BUNDLE-44, so I have fixed the= m and submitted a new version (-45). Regards, Christer --_000_D65848B527BEAchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Colin found a couple of abbreviation nits in BUNDLE-44, so I have fixe= d them and submitted a new version (-45).

Regards,

Christer
--_000_D65848B527BEAchristerholmbergericssoncom_-- From nobody Thu Dec 14 12:02:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831BF129443 for ; Thu, 14 Dec 2017 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 U-vH5IWMzPCF for ; Thu, 14 Dec 2017 12:02:24 -0800 (PST) Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 ECD88128B8D for ; Thu, 14 Dec 2017 12:02:23 -0800 (PST) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id vBEK06Ar043232 for ; Thu, 14 Dec 2017 15:02:22 -0500 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 325D56D for ; Thu, 14 Dec 2017 15:02:23 -0500 (EST) Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 275526D for ; Thu, 14 Dec 2017 15:02:23 -0500 (EST) Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id vBEK2Mh9021796 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 14 Dec 2017 15:02:22 -0500 Received: by mail-oi0-f69.google.com with SMTP id d76so2993304oig.12 for ; Thu, 14 Dec 2017 12:02:22 -0800 (PST) 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=2rIGnazA/CRShiWudfKaMKvHtqdcwtLyHRRZ/jxYqWw=; b=AF0/ZsuQvEZtM81ocsMKMLemf75hsBhvZh+rUmEpNpGC993amuafeimv7v6SZRm8BB 7CqV/ecz9+1KFVVIFJBA8li45apmWFUQKTFxkFCj10uqcm7GdMtuWnaLot+GrAXdaz1x PmMGOF0qO6HqmcJpxtFxeDbr+Pp7msZvfLwyz8JgkJa6sr0DgrCFU07Sfwd/pi9sMxyc E6ifNHsSGU56YSeh0QTMHi7GiP0CnLjQnQqhgllqaO2w0yChaaZDeueTNGilRwdrjFhB 15Gg/36GVRIDrRX3dU/5t3RftAOAw9no1+T+w/iW+Pxp/NpoWqQ5X7BS5V/swSaJgCye XEKw== X-Gm-Message-State: AKGB3mJfb0y1jQzGN4uCzDOTrkU4ke2ICPdODWd31i45m3SmztBfMAQ8 lb8WaYmXjFOL3pdnx+WZe+VfCFl0sFBcrYfwqzKDWJkeAxiIUIR1/b9AHK+a6RIYPvOF19MJUyl J22JnBdncP+OGHhkNi3lPmuyc9Cky8ko= X-Received: by 10.157.47.34 with SMTP id h31mr6194153otb.362.1513281741859; Thu, 14 Dec 2017 12:02:21 -0800 (PST) X-Google-Smtp-Source: ACJfBotW4cdZS+/VX5Pgo06TErXS+P4csn6ntebqS3UOdgzgmtvDlz+Y08oLEGZ6xQdaGiCPRAsaF84PwGJm1oaXggY= X-Received: by 10.157.47.34 with SMTP id h31mr6194137otb.362.1513281741450; Thu, 14 Dec 2017 12:02:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.9.184 with HTTP; Thu, 14 Dec 2017 12:02:00 -0800 (PST) From: Henning Schulzrinne Date: Thu, 14 Dec 2017 15:02:00 -0500 Message-ID: To: mmusic@ietf.org Content-Type: text/plain; charset="UTF-8" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.78 on 128.59.72.14 Archived-At: Subject: [MMUSIC] draft-ietf-mmusic-sdp-bundle-negotiation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 20:02:25 -0000 For the record: As one of the co-authors of RFC 3264, I'm happy to grant BCP78 rights to the IETF Trust for making modifications to the RFC. Henning From nobody Thu Dec 14 14:40:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1A126BF7; Thu, 14 Dec 2017 14:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57irAwejKs3l; Thu, 14 Dec 2017 14:39:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B26AA1242F5; Thu, 14 Dec 2017 14:39:57 -0800 (PST) Received: from [10.0.1.99] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vBEMds77044124 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Dec 2017 16:39:55 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.99] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_62EF7B94-F66C-4CCD-AE7D-3D72A891A436"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 14 Dec 2017 16:39:39 -0600 In-Reply-To: <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org To: Thomas Stach References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 22:40:00 -0000 --Apple-Mail=_62EF7B94-F66C-4CCD-AE7D-3D72A891A436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the response. More comments inline; I removed sections that = do not seem to need further discussion. Thanks! Ben. > On Dec 11, 2017, at 6:22 AM, Thomas Stach = wrote: >=20 >=20 [=E2=80=A6] >=20 >=20 >> -4.1.1, 2nd to last paragraph : "... it still MUST include the = "a=3Drtcp-mux" >> and/or "a=3Drctp-mux-only" attribute in the initial Offer." >> IIUC, that's an already existing requirement from the referenced = spec. If so, >> please do not use 2118/8174 keywords to describe it here, unless in = the form >> of directly quoted text. >>=20 > OK > Would changing from "... it still MUST include ..." to "... it will = include ... " address your comment? Yes, thanks. >> -4.2.2, RFC editor note: >> This askes the RFC Editor to do research. I don't think that's a = reasonable >> expectation. They may notice that sort of thing anyway, but the = authors >> should plan to recheck references during AUTH48. (This comment = applies to >> several other similar RFC editor notes.) >>=20 > It was also meant as a reminder to the authors to cross check during = AUTH48. Would the following text be better? > "RFC EDITOR NOTE: The section XXX in above sentence is correct for > version XX of said I-D. The authors need to cross-check during = Auth48 since it could have have > changed in the meantime.=E2=80=9D Yes, that=E2=80=99s fine with me :-) >=20 >=20 >> -4.2.2, third paragraph after Fig 4: "or when new candidates have not = been >> learned since then) and/or they MAY also deliver newly learned = candidates (if >> available). The Offerer MAY include an end-of-candidates attribute = in case >> candidate discovery has ended in the mean time." >>=20 >> Are those MAYs really correct when the conditions are true? E.g. if = you have >> newly learned candidates, there's only a MAY requirement to add them? >> Likewise, if discovery has ended, there's only a MAY requirement to = add the >> end-of-candidates attribute? >>=20 > The motivation for the "MAY"s was to allow for pre-building of that = initial INFO only from information that is available when the Offer was = sent. > Of course new candidates need to be trickled eventually. > Changing the "MAY"s to "SHOULD"s would still allow for such = pre-building. We can do that if you prefer. SHOULD helps, but it doesn=E2=80=99t really get to the point of my = comment. The text says =E2=80=9CMAY also deliver newly learned = candidates ( *if available*)=E2=80=9D (emphasis mine). So, my question = is, _if_, they are available, is it ever reasonable to not send them? = (Same applies to the end-of-candidates attribute). Would it make sense to say something along the lines of =E2=80=9CIf = newly learned candidates have become available since=E2=80=A6 the = offerer [MUST/SHOULD] include them.=E2=80=9D ? [=E2=80=A6] >> -4.3: It seems like the use of SDP syntax in the INFO messages = creates quite >> a bit of complexity due to the use of SDP in (even more) ways not >> contemplated by it's design. Did the WG discuss the possibility of = using a >> designed-for-purpose syntax in the INFO bodies? (This is just my = curiosity; >> I don't expect to make that sort of fundamental change this late in = the >> process.) >>=20 > No, there wasn't discussion about an alternative syntax. > There was discussion about using some generic 'application/sdpfrag' = media-type, but the consensus was to define a SDP subset specifically = taylored for trickle-ICE. > By using "SDP-like" syntax we also assumed that corresponding code = could still be re-used for building the INFO bodies. Okay. >> -4.3: Discussion of "pseudo-M-lines": >> A complete separation of the trickle-ice from offer/answer seems = unlikely to >> me, since both must send and receive SIP messages in the same dialog. = Is it that much harder to remember the media type than it is to remember = dialog state? More to the point, are there known implementations that = require this? >>=20 > I'm, not sure if I get your point. > But yes, a complete separation seems unlikely since we can have = candidates already in the Offer, which need to be delivered to the ICE = module. > The concept of the pseudo m-lines and a=3Dmid attributes was = introduced in order to be able to determine to which m-line a candidate = belongs. >=20 > Having said that, I just recognized - sort of embarrassingly - that we = omitted to explicitly specify that a-mid attributes need to go into the = offers and answers although we have them in all the SDP examples. I'll = add that into the next revision. Okay. [=E2=80=A6] >> -4.3: 2nd paragraph prior to Fig 9: >> Are the discussions about removing previously exchanged candidates = still in >> process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to >> requirements that are too vague to state in normative terms. >>=20 > These discussions stalled in the meantime, which is partly the reason = for the vagueness. > We could > s/it MAY treat that as an exceptional case/ it would have to treat = that as an exceptional case/ > and > s/is RECOMMENDED for this situation/is advisable for this situation/ That works for me. [=E2=80=A6] >>=20 >> -8.2, first paragraph: External requirement. > Here, I think MAY/MUST is correct, since draft-ietf-ice-trickle does = not provide the attributes. They are only defined in this document Okay. >> -9: Please comment about whether this media type is reasonable to use = for >> other SDP related applications? I gather the answer is "no" given = that it's >> called "trickle-ice-sdpfrag". >>=20 > The answer is indeed "No" per the reasons given already by Paul = Kyzivat. > Do you want us to explicit add into the text that other SDP related = applicationsneed to define their own media type? I think that would help. [=E2=80=A6] >> - 10.9: You used the need to pool candidates as a argument against = using >> update. Doesn=E2=80=99t this create the same requirement? >>=20 > The argument was about using offer/answer in UPDATE request/response = which would introduce blocking/risk of glare. > INFO does not have this problem, but could still pool candidates if = they like, but they don't have to. Okay. >> Also, do you think it >> reasonable that an implementation might not be concerned about this? >>=20 > I can't know that. 10.9 is just meant as a reminder to implementors to = think about congestion. > Do you want us to change anything in the text? No, it=E2=80=99s probably fine like it is. [=E2=80=A6] >>=20 > Will do >> -12: The registered media type refers to this document for security >> considerations, but I don't see any considerations specific to it = here. >>=20 > Ok, I will explicitly mention the new media type does not introduce = additional security considerations I suggest adding something to the effect of =E2=80=9Cwhen used in the = context of trickle-ice...=E2=80=9D and =E2=80=9CIt=E2=80=99s not = intended to be used for other applications, so any security = considerations for it=E2=80=99s use in other contexts is out of scope" >>=20 >> *** Editorial and Nits: >>=20 [=E2=80=A6] >> -3.2, first paragraph: >> I think "the exception of the actual INFO messages," is too big of an >> exception for this paragraph to be meaningul. For example, this is a = huge >> change for middleboxes that pay attention to the SDP (e.g. SBCs); I = think >> saying that things "would look the same" is an overstatement. >>=20 > Would the following be better? > "=46rom the perspective of all SIP middle boxes and proxies > Offer/Answer exchanges look partly similar for > Trickle ICE as they would for ICE for SIP [ > I-D.ietf-mmusic-ice-sip-sdp > ]. > However, in order to have the full picture of the candidate exchange, = the newly introduced INFO messages need to > be considered as well.=E2=80=9D WFM. [=E2=80=A6] >> -4.1.1, last paragraph: This seems redundant to the similar statement = in >> section 4, item 2. >>=20 > Probably, but people tend to read only snippets of a document. Sigh. Okay :-) [=E2=80=A6] >> "The grammar uses the indicator for case-sensitivity %s is defined in >> [RFC7405], but also imports grammars for other SDP attributes that = precede >> the production of that RFC. " >> I can't parse that sentence. >>=20 > Maybe due to the typo? It should read "... the indicator for = case-sensitivity %s _as_ defined in [RFC7405], =E2=80=A6" Ah, yes, that makes more sense :-) [=E2=80=A6] --Apple-Mail=_62EF7B94-F66C-4CCD-AE7D-3D72A891A436 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAloy/asACgkQgFZKbJXz 1A30Zw//Rjjq0ay+4v4z+xogRjDrmUXpKIj/C+NY8ZkAwWJ82uey4lpv50Y2/zCw iv2wOVNYLXBF/PqNqsxwpSWuUWDVwDqETKGBrB47Gu7hY0Y1czcpPpdhn4qw8BEl u3fXGiuXX8TFh4of/fd+sl+1cdm6jhlqT4+8RAot6YJ2Cu4oFw+obmKFROPPeSxN ptNGsU5zoI2jz5+mubbuZPVKeRgm0jnaM0kPXdBJW/Hl4FeFYWMageTBVwX7qWqX vmB4LBUX8er7WUpRJj351Z8RaYli4sV375Fjb+5Z3U1Qi1H/1l08jd03ITWItEnm LklJxkX8ZWdDRcKGuzTUs7UK8SMQSrEzkeQDM23iUiT9xv3hOfbJEqahIz6JSja5 yojiG/BxVbXMUCGWMhKzuWLb7tk//WS/3ixpKcP/LFrbSA0XozZRJBpyDjU6ky3B ylEHBzkrqNiB7Jr48CIvrvK2D/G8yYh3at/AtanWpPdz4Ep49+bCSDKxgXNaIEpf VdGjcHoy7L0jjRoEbinPTe1NYFwQumu6vrEc0EvBVsWHkenqEEo5WDFTXl0QRNRU koImMCSTHdJ/AAvbwdRLnfKUk7y92dSfGt2g5p1z9HliZ06eAeACy6Kn2Zz3iaY6 W16TiHAQmm9APls/mI2qfBVYX8O3ZSkRWS93ZiaWTsWtrkIaauo= =zY5X -----END PGP SIGNATURE----- --Apple-Mail=_62EF7B94-F66C-4CCD-AE7D-3D72A891A436-- From nobody Thu Dec 14 20:15:10 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD181200F1 for ; Thu, 14 Dec 2017 20:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 AIP7spRRZF59 for ; Thu, 14 Dec 2017 20:15:07 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 7C0BF126DCA for ; Thu, 14 Dec 2017 20:15:06 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id q3so6818831oth.2 for ; Thu, 14 Dec 2017 20:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=oXCZai79za/7w0XII6B1LyRvX4Ea6UoSulgEtx/BggQ=; b=VZ0P4U0EXdFy0+KXw+hEjBHcU1LGuQ85NtW7CMFQO88WcdfqLFvTLlqENoHcmaHd2O ZAYj0QYI1ZWnyugLPmPK6X/SciMcQNbudersPGUUE6rxuyeEuGoYgYIdWJVGHh4dS/wY E9eMAD3qVzst/2/MNuo0ImpbmJtnXrJcfUAJA= 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; bh=oXCZai79za/7w0XII6B1LyRvX4Ea6UoSulgEtx/BggQ=; b=pKQ23KSBQNAzGjN7+ionmgtDLKACITc9CI/57LOlo9zyUFkBLVYjZv3FFxGOb94SOe mZeen20cbV051XgF90jMvrITikepUEvJJVtCDeGASwKzATE9vn/PJb/sYY9Y8EuGp9oP cS6nmpNZ5AUoVEhKJNLZyvRODmBBmSqmY5p42AHlIOf6uU2HwlWMeLm4BvyWMd7Z9Wrd yHthewKQTn5sRxZW/G5h6LPXuFt0Gr4I4ZTAQ3U2ivpLRnnwihpxMbMfd2HnWfRHyKBf A1L6diJCE459JTHDxSRo0udJZRtm1U0O95lulepgK3QUnDWsijRARcmQjCTNw0/0Rx/o NFng== X-Gm-Message-State: AKGB3mL0dHJ4rtrK6iD1Wg8CswDcqBjYqohVbimo5c+BDsmJoC/aysTb pX6tWZLpqhsrbh6IxvnErA0h3g== X-Google-Smtp-Source: ACJfBosjqV/QwFQOcK7YH2k0eXspRMsxE2fgfBOKB1EUx0BKq+wBXvb/zdmEl03UT+1mO+w36ojIZQ== X-Received: by 10.157.8.2 with SMTP id 2mr7187679oty.250.1513311305705; Thu, 14 Dec 2017 20:15:05 -0800 (PST) Received: from dragon.local (rrcs-97-79-186-3.sw.biz.rr.com. [97.79.186.3]) by smtp.gmail.com with ESMTPSA id h138sm2558681oib.16.2017.12.14.20.15.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 20:15:04 -0800 (PST) To: Ben Campbell , Thomas Stach Cc: mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> From: Peter Saint-Andre Message-ID: Date: Thu, 14 Dec 2017 22:15:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nqAJt9bRFkgaBbwXBpxBTnvk9IqkesjmJ" Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 04:15:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nqAJt9bRFkgaBbwXBpxBTnvk9IqkesjmJ Content-Type: multipart/mixed; boundary="5DRFjBeM6PSRVlXLxq2IxBOur7gT8IHx0"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , Thomas Stach Cc: mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org Message-ID: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> In-Reply-To: --5DRFjBeM6PSRVlXLxq2IxBOur7gT8IHx0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/14/17 4:39 PM, Ben Campbell wrote: >> On Dec 11, 2017, at 6:22 AM, Thomas Stach wr= ote: >> >>> -4.2.2, third paragraph after Fig 4: "or when new candidates have not= been >>> learned since then) and/or they MAY also deliver newly learned candid= ates (if >>> available). The Offerer MAY include an end-of-candidates attribute i= n case >>> candidate discovery has ended in the mean time." >>> >>> Are those MAYs really correct when the conditions are true? E.g. if y= ou have >>> newly learned candidates, there's only a MAY requirement to add them?= >>> Likewise, if discovery has ended, there's only a MAY requirement to a= dd the >>> end-of-candidates attribute? >>> >> The motivation for the "MAY"s was to allow for pre-building of that i= nitial INFO only from information that is available when the Offer was s= ent. >> Of course new candidates need to be trickled eventually. >> Changing the "MAY"s to "SHOULD"s would still allow for such pre-buildi= ng. We can do that if you prefer. >=20 > SHOULD helps, but it doesn=E2=80=99t really get to the point of my comm= ent. The text says =E2=80=9CMAY also deliver newly learned candidates ( *= if available*)=E2=80=9D (emphasis mine). So, my question is, _if_, they a= re available, is it ever reasonable to not send them? (Same applies to th= e end-of-candidates attribute). >=20 > Would it make sense to say something along the lines of =E2=80=9CIf new= ly learned candidates have become available since=E2=80=A6 the offerer [M= UST/SHOULD] include them.=E2=80=9D ? My understanding is we don't want to force an agent to tell its peer about all candidates because some of them might be expensive to use (thus the agent might want to hold them in reserve). Peter --5DRFjBeM6PSRVlXLxq2IxBOur7gT8IHx0-- --nqAJt9bRFkgaBbwXBpxBTnvk9IqkesjmJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlozTEcACgkQZWGMGH9o FKk7ww/9Gi168IcP6idLtonJrqYCKnayGEcsnMwfLaNBQNR6LPsIw9B5dD9EFO0E k8hFWMy9lZKBycqp8zSOdumP6gAINQ5qQGyfEgwx4f5WKu/aGEh9aT7ehkBbOof6 2dCMzI16oyTW99YYcFp/YtM8O2rG+0Nh3q35b2jURZ0etMNiJnikyu/yE8qOFhb9 tntojBtFtPFYw0UWUOGyrE8pLIQ4yELOY8T4tWDgsPV1eOa0q7+RDAyV3HX8lsJN GN3POedN7D2sRnlfOUy+T4cEzdDGdBoajNTnvm0eTb+DLgLLVbjx0NTzheAVVfQG BYQYPsUZ6X92zSRdzvw04/dbA9dM4wsDzcN6fSm/FSrpWcB/Ie0PPqO9ngbbkJYy YtQmt5MjrSCmKRN912PYiRcq6mJVLi9wi70uScPTb1RnaYyDPLRZ/0Gh7kBgWZUI fjNE12zlzuLyt/TBv+im1C0B00Xpc9Rv0FZtO3NUggmnY0Pj36rUr4lvOul0THiv sP4EAnJFWH/ijcmvjrSF6Di+pZHr2x0NWVlvZtq47ihNNGWA3cvQCeKqgxr6D5X+ 6N+D12wcxLhdTLUIXVgzxWvj8hkIUU/CyxKjuXNAKk9SmG0HJn6TJwJt96RFCtCF 7ula2bylCchhoqU/41kpmpvLpsFyIiXtu7by61FGAZGo3X7DHoY= =u7C0 -----END PGP SIGNATURE----- --nqAJt9bRFkgaBbwXBpxBTnvk9IqkesjmJ-- From nobody Thu Dec 14 23:56:36 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 813B9124D37; Thu, 14 Dec 2017 23:56:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151332459549.30350.10986510189696303504@ietfa.amsl.com> Date: Thu, 14 Dec 2017 23:56:35 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-46.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 07:56:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-46.txt Pages : 67 Date : 2017-12-14 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m=" section without meaning that the media described by the "m=" section is disabled or rejected. When Real-time Transport Protocol (RTP)-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-46 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-46 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-46 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 23:59:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D60124D37; Thu, 14 Dec 2017 23:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 8QtRNiNeue7x; Thu, 14 Dec 2017 23:59:12 -0800 (PST) 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 2ED0312702E; Thu, 14 Dec 2017 23:59:11 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-a1-5a3380ce5f0f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9C.1D.13339.EC0833A5; Fri, 15 Dec 2017 08:59:10 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Fri, 15 Dec 2017 08:59:00 +0100 From: Christer Holmberg To: "mmusic@ietf.org" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new version: BUNDLE-46 Thread-Index: AQHTdXqQCkw2PM/mIEafA6tEM6hUTQ== Date: Fri, 15 Dec 2017 07:58:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D6594F9827C4Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7je65BuMog2urBC3md55mtzi/cz2T xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsErozWaxwF/7gqLl+8xNrAuJWzi5GT Q0LAROLa9wWMXYxcHEIChxkl3i/qYYdwljBK3DnYyNzFyMHBJmAh0f1PG6RBREBd4uveHmYQ m1kgXGLOmzOsILawgKrE7+k3GCFqtCTer/nPBNIqIqAn0XzPEyTMAlRy69ARNhCbV8BaYuq6 T+wgNqOAmMT3U2uYIEaKS9x6Mp8J4jYBiSV7zjND2KISLx//A1slCjRyw4nb7BBxRYmr05dD 9SZITL79kB1ivqDEyZlPWCYwCs9CMnYWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfAYqJcD yLaW+L8iCFnJAkaOVYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBsXVwy2/VHYyX3zgeYhTg YFTi4S0oMY4SYk0sK67MPcQowcGsJMJ7zw0oxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+U kEB6YklqdmpqQWoRTJaJg1OqgbFlzq1JzK/Zt3k4/rB2v7j49v2VFnMTv7Z3nu8ufZqzXujt 21l7LnF5/w66uX3n/6gN5yU+rDy/VOS0cubntSZyHx5ueVnhlndL2tJuyvzKroOLb2xyWxs+ IaFsSuA+3cZkTu/dCsUG17QPHu8SuWhlF7NBovQUV8WrpQJ2fj531ui+Xi48eYm3EktxRqKh FnNRcSIAc6p9OakCAAA= Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-46 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 07:59:14 -0000 --_000_D6594F9827C4Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Yet another version (-46) of BUNDLE has been submitted. * The mux category for the group:BUNDLE attribute has been added * The pre-RFC5378 disclaimer has been removed (Note: We are still pendi= ng for approval from Jonathan R, one of the RFC 3264 authors). Regards, Christer --_000_D6594F9827C4Cchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3BE72F95CD8E1545A74054F357972F92@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Yet another version (-46) of BUNDLE has been submitted.
  • The mux category for the group:BUNDLE attribute has been added
  • = The pre-RFC5378 disclaimer has been removed (Note: We are still pending for= approval from Jonathan R, one of the RFC 3264 authors).
Regards,

Christer
--_000_D6594F9827C4Cchristerholmbergericssoncom_-- From nobody Fri Dec 15 05:54:35 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC730128ACA; Fri, 15 Dec 2017 05:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 Ueh1_aaXY0Uv; Fri, 15 Dec 2017 05:54:32 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 B59DB1200B9; Fri, 15 Dec 2017 05:54:31 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id r78so17702491wme.5; Fri, 15 Dec 2017 05:54:31 -0800 (PST) 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=OSlVV03AGa/sC0VWS5D47qSPGld6RxTWyBLP0oKCxns=; b=sDWsp3LOqe9DfJf/iCfXvO099isHoNDyqHmlcjxjv5PASz4hj1KsN1MQSzXG8ik9Q2 b27TtinykzrTrJK8mcmElojuwFugYphoVgPpVVWYQMd33XhMc28ooiJr6LTfy+CSmwZW 7yNEJ1ohm9hXl9TrYK+8JNOFKgHmSCpw5v+aIRzrOaTNa4PN0HWQl8VN3XhHzy6zvlGt rp45ZT1+3OaWRLFFlBQJul/1ziGSwdFMnyQ3KtCURhBJ+Qflzc0LeNd1kUiXJSjmSwTv /11AjB1JLDyPfzY5UaedlWiUZE0pzxxl6HvknJKQDLo+L50DJREqMOI+F4pN+DwZEBjr 9aXw== 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=OSlVV03AGa/sC0VWS5D47qSPGld6RxTWyBLP0oKCxns=; b=t+n/54oMgt8WoERAh9PfNz2LVcCtx9c13GzHw3kAVMTdgAqa7A2k6a9xX2lWmV5rB5 HhHrCSWph4EokGVOQIEBB/MDTBLJqiYcnu7V6U+SpeC+ZTO9u/IX0g8xqdM1ytWA83GU umhmyr+DIczZjaIEsIae161FybBJkFZuarx1bGKyHDHhMBHbP2XrD/Vss738sSVO5rUC JSH0Z/chaqiSH4xJcTYrjvlGkcqb+H708inDZzAF5JaRSqodTI8DTFdlUx0a+5Zx3UCf 0Lh177gN5AEhz96ECBHQJfb4bQioJCDZ3Vn+1W+U63y48RIqzKFs+fuic9gEAWs0gBIH 14jw== X-Gm-Message-State: AKGB3mL7BhJAFFybR4Xap3vISIxLWs1pSmhx2bIfKMVRycBXerb0/fuE Q1884YWK63BDIxeW37dODrI6mooO X-Google-Smtp-Source: ACJfBouGyyVqoFPL6IFDJcN1O4Z9GmQaqXBL6EU7sKkIqW+u86BJ09a+YapeScvihSB5Rw1/IkvJKQ== X-Received: by 10.80.173.227 with SMTP id b32mr18060293edd.65.1513346069840; Fri, 15 Dec 2017 05:54:29 -0800 (PST) Received: from ?IPv6:2001:62a:4:41c:f91e:2804:a666:4b34? ([2001:62a:4:41c:f91e:2804:a666:4b34]) by smtp.googlemail.com with ESMTPSA id m48sm5479363edd.7.2017.12.15.05.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 05:54:28 -0800 (PST) To: Peter Saint-Andre , Ben Campbell Cc: mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> From: Thomas Stach Message-ID: <5a582906-4353-c136-4377-d8d5559834ad@gmail.com> Date: Fri, 15 Dec 2017 14:54:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 13:54:34 -0000 Ben, Peter, On 2017-12-15 05:15, Peter Saint-Andre wrote: > On 12/14/17 4:39 PM, Ben Campbell wrote: > >>> On Dec 11, 2017, at 6:22 AM, Thomas Stach wrote: >>> > > >>>> -4.2.2, third paragraph after Fig 4: "or when new candidates have not been >>>> learned since then) and/or they MAY also deliver newly learned candidates (if >>>> available). The Offerer MAY include an end-of-candidates attribute in case >>>> candidate discovery has ended in the mean time." >>>> >>>> Are those MAYs really correct when the conditions are true? E.g. if you have >>>> newly learned candidates, there's only a MAY requirement to add them? >>>> Likewise, if discovery has ended, there's only a MAY requirement to add the >>>> end-of-candidates attribute? >>>> >>> The motivation for the "MAY"s was to allow for pre-building of that initial INFO only from information that is available when the Offer was sent. >>> Of course new candidates need to be trickled eventually. >>> Changing the "MAY"s to "SHOULD"s would still allow for such pre-building. We can do that if you prefer. >> SHOULD helps, but it doesn’t really get to the point of my comment. The text says “MAY also deliver newly learned candidates ( *if available*)†(emphasis mine). So, my question is, _if_, they are available, is it ever reasonable to not send them? (Same applies to the end-of-candidates attribute). >> >> Would it make sense to say something along the lines of “If newly learned candidates have become available since… the offerer [MUST/SHOULD] include them.†? > My understanding is we don't want to force an agent to tell its peer > about all candidates because some of them might be expensive to use > (thus the agent might want to hold them in reserve). > > Peter > > I assume   incorporating Peter's point into the document as  a motivation for MAY/SHOULD would make sense? Would MAY or SHOULD be the better choice? I tend to use SHOULD. Regards Thomas From nobody Fri Dec 15 05:59:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E103B1275FD; Fri, 15 Dec 2017 05:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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] 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 AggjVyYDNc7c; Fri, 15 Dec 2017 05:59:08 -0800 (PST) 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 22868126C25; Fri, 15 Dec 2017 05:59:08 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 64so17735730wme.3; Fri, 15 Dec 2017 05:59:08 -0800 (PST) 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=7Z0cEEdC+92ATOdejD/+2zUFMvCarRcEx6VDNCwvuFA=; b=VYri5IYCy0A+A2a8U32q0OTsk+1cClXMpvXVx2IP8SiEPXfAo7v9NZ94itvPH1J6LZ DFBVcZM/XdPwHCjl+X7Ol8BCvIzBtIRr9Z8PRxz1VksBvfyX6yVkJiGpywD9sPLY3iGa fmVJWMPHSzPDWF8TohLuD2ZIhc8Ov2/twdf9PcAOqzm1Bs6nQZgAHuKAV9QiVkw8ZmcA o9q68Il6EeCQT/3GklLTH6MNBm5ZY+t0sLbVaJh1TOcKKxvnVMdnH2ykCcf/8uTEGZmu zGzCZ4m1FhSbbmgBxHkSBV8K5DCxPAgXvwx69Tx+wkJVMAgTh/l7sQucd7N5ks990Bsf +54A== 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=7Z0cEEdC+92ATOdejD/+2zUFMvCarRcEx6VDNCwvuFA=; b=IpDcPG8d3Ts6p7m/3QeF8gRQSpW+mU3gR7kT6kLdAw+HuAA513B/HfZ5MqrdhbHmfa Ite+l2paL9ExpjSBD/Rw5RnDlATnndyw7ZzjRyGx4hoz2e6OQqjXxicnKARl3lhMLYwu s5FuSpprc2A/VVgJ3HJU9SFhuTWsTvyX/nI7CIKkv2Z6EB+fU2Y4p9JkXBBXjYmzl1wX wnzTf4IIklaTMR17zplyY+CVdivdj+rXw5K50l0t0v/cR/M8LV7iP0GKwWFWb7/UWYpz biDIlytEwbmANOS3ilgVpaQPLBYC3J0K03nyXSGyqdynW7RxvaejKgzfwH18lW9/F3I+ wgQQ== X-Gm-Message-State: AKGB3mLmQEB+ToEwRZkKpAA8vOG7dCboIc/0D7EilwxJZBxK1LUeBtm8 23YzAXGK0riaMye85A7qW/1GR0aM X-Google-Smtp-Source: ACJfBotExLFX7Ym64+5cirB0PYNDrEnxVfQm2AVOPAdfteyVPeoh9Zq4RfnS3cwkP5hpdSt5P8uGsQ== X-Received: by 10.80.152.66 with SMTP id h2mr16996750edb.192.1513346346234; Fri, 15 Dec 2017 05:59:06 -0800 (PST) Received: from ?IPv6:2001:62a:4:41c:f91e:2804:a666:4b34? ([2001:62a:4:41c:f91e:2804:a666:4b34]) by smtp.googlemail.com with ESMTPSA id g7sm5755099edf.50.2017.12.15.05.59.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 05:59:05 -0800 (PST) To: Ben Campbell Cc: draft-ietf-mmusic-trickle-ice-sip.all@ietf.org, mmusic@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> From: Thomas Stach Message-ID: <8e7df069-439e-2ccb-a8e2-7d2a3b16e3d5@gmail.com> Date: Fri, 15 Dec 2017 14:58:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 13:59:11 -0000 Ben, thanks for the responses. Once the issue about candidate delivery is resolved, I'll provide an updated draft, hopefully during the next week. Regards Thomas On 2017-12-14 23:39, Ben Campbell wrote: > Thanks for the response. More comments inline; I removed sections that do not seem to need further discussion. > > Thanks! > > Ben. > >> On Dec 11, 2017, at 6:22 AM, Thomas Stach wrote: >> >> > […] > >> >>> -4.1.1, 2nd to last paragraph : "... it still MUST include the "a=rtcp-mux" >>> and/or "a=rctp-mux-only" attribute in the initial Offer." >>> IIUC, that's an already existing requirement from the referenced spec. If so, >>> please do not use 2118/8174 keywords to describe it here, unless in the form >>> of directly quoted text. >>> >> OK >> Would changing from "... it still MUST include ..." to "... it will include ... " address your comment? > Yes, thanks. > >>> -4.2.2, RFC editor note: >>> This askes the RFC Editor to do research. I don't think that's a reasonable >>> expectation. They may notice that sort of thing anyway, but the authors >>> should plan to recheck references during AUTH48. (This comment applies to >>> several other similar RFC editor notes.) >>> >> It was also meant as a reminder to the authors to cross check during AUTH48. Would the following text be better? >> "RFC EDITOR NOTE: The section XXX in above sentence is correct for >> version XX of said I-D. The authors need to cross-check during Auth48 since it could have have >> changed in the meantime.†> Yes, that’s fine with me :-) > >> >>> -4.2.2, third paragraph after Fig 4: "or when new candidates have not been >>> learned since then) and/or they MAY also deliver newly learned candidates (if >>> available). The Offerer MAY include an end-of-candidates attribute in case >>> candidate discovery has ended in the mean time." >>> >>> Are those MAYs really correct when the conditions are true? E.g. if you have >>> newly learned candidates, there's only a MAY requirement to add them? >>> Likewise, if discovery has ended, there's only a MAY requirement to add the >>> end-of-candidates attribute? >>> >> The motivation for the "MAY"s was to allow for pre-building of that initial INFO only from information that is available when the Offer was sent. >> Of course new candidates need to be trickled eventually. >> Changing the "MAY"s to "SHOULD"s would still allow for such pre-building. We can do that if you prefer. > SHOULD helps, but it doesn’t really get to the point of my comment. The text says “MAY also deliver newly learned candidates ( *if available*)†(emphasis mine). So, my question is, _if_, they are available, is it ever reasonable to not send them? (Same applies to the end-of-candidates attribute). > > Would it make sense to say something along the lines of “If newly learned candidates have become available since… the offerer [MUST/SHOULD] include them.†? > > […] > > > >>> -4.3: It seems like the use of SDP syntax in the INFO messages creates quite >>> a bit of complexity due to the use of SDP in (even more) ways not >>> contemplated by it's design. Did the WG discuss the possibility of using a >>> designed-for-purpose syntax in the INFO bodies? (This is just my curiosity; >>> I don't expect to make that sort of fundamental change this late in the >>> process.) >>> >> No, there wasn't discussion about an alternative syntax. >> There was discussion about using some generic 'application/sdpfrag' media-type, but the consensus was to define a SDP subset specifically taylored for trickle-ICE. >> By using "SDP-like" syntax we also assumed that corresponding code could still be re-used for building the INFO bodies. > Okay. > > >>> -4.3: Discussion of "pseudo-M-lines": >>> A complete separation of the trickle-ice from offer/answer seems unlikely to >>> me, since both must send and receive SIP messages in the same dialog. Is it that much harder to remember the media type than it is to remember dialog state? More to the point, are there known implementations that require this? >>> >> I'm, not sure if I get your point. >> But yes, a complete separation seems unlikely since we can have candidates already in the Offer, which need to be delivered to the ICE module. >> The concept of the pseudo m-lines and a=mid attributes was introduced in order to be able to determine to which m-line a candidate belongs. >> >> Having said that, I just recognized - sort of embarrassingly - that we omitted to explicitly specify that a-mid attributes need to go into the offers and answers although we have them in all the SDP examples. I'll add that into the next revision. > Okay. > > […] > >>> -4.3: 2nd paragraph prior to Fig 9: >>> Are the discussions about removing previously exchanged candidates still in >>> process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to >>> requirements that are too vague to state in normative terms. >>> >> These discussions stalled in the meantime, which is partly the reason for the vagueness. >> We could >> s/it MAY treat that as an exceptional case/ it would have to treat that as an exceptional case/ >> and >> s/is RECOMMENDED for this situation/is advisable for this situation/ > That works for me. > > […] > > >>> -8.2, first paragraph: External requirement. >> Here, I think MAY/MUST is correct, since draft-ietf-ice-trickle does not provide the attributes. They are only defined in this document > Okay. > >>> -9: Please comment about whether this media type is reasonable to use for >>> other SDP related applications? I gather the answer is "no" given that it's >>> called "trickle-ice-sdpfrag". >>> >> The answer is indeed "No" per the reasons given already by Paul Kyzivat. >> Do you want us to explicit add into the text that other SDP related applicationsneed to define their own media type? > I think that would help. > > […] > >>> - 10.9: You used the need to pool candidates as a argument against using >>> update. Doesn’t this create the same requirement? >>> >> The argument was about using offer/answer in UPDATE request/response which would introduce blocking/risk of glare. >> INFO does not have this problem, but could still pool candidates if they like, but they don't have to. > Okay. > > >>> Also, do you think it >>> reasonable that an implementation might not be concerned about this? >>> >> I can't know that. 10.9 is just meant as a reminder to implementors to think about congestion. >> Do you want us to change anything in the text? > No, it’s probably fine like it is. > > […] > >> Will do >>> -12: The registered media type refers to this document for security >>> considerations, but I don't see any considerations specific to it here. >>> >> Ok, I will explicitly mention the new media type does not introduce additional security considerations > I suggest adding something to the effect of “when used in the context of trickle-ice...†and “It’s not intended to be used for other applications, so any security considerations for it’s use in other contexts is out of scope" > >>> *** Editorial and Nits: >>> > […] > >>> -3.2, first paragraph: >>> I think "the exception of the actual INFO messages," is too big of an >>> exception for this paragraph to be meaningul. For example, this is a huge >>> change for middleboxes that pay attention to the SDP (e.g. SBCs); I think >>> saying that things "would look the same" is an overstatement. >>> >> Would the following be better? >> "From the perspective of all SIP middle boxes and proxies >> Offer/Answer exchanges look partly similar for >> Trickle ICE as they would for ICE for SIP [ >> I-D.ietf-mmusic-ice-sip-sdp >> ]. >> However, in order to have the full picture of the candidate exchange, the newly introduced INFO messages need to >> be considered as well.†> WFM. > > […] > >>> -4.1.1, last paragraph: This seems redundant to the similar statement in >>> section 4, item 2. >>> >> Probably, but people tend to read only snippets of a document. > Sigh. Okay :-) > > […] > >>> "The grammar uses the indicator for case-sensitivity %s is defined in >>> [RFC7405], but also imports grammars for other SDP attributes that precede >>> the production of that RFC. " >>> I can't parse that sentence. >>> >> Maybe due to the typo? It should read "... the indicator for case-sensitivity %s _as_ defined in [RFC7405], …" > Ah, yes, that makes more sense :-) > > […] From nobody Fri Dec 15 09:17:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8167B1293F9; Fri, 15 Dec 2017 09:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMsoUyTlQVA8; Fri, 15 Dec 2017 09:17:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7DE1200CF; Fri, 15 Dec 2017 09:17:42 -0800 (PST) Received: from [10.0.1.99] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vBFHHdRZ072631 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Dec 2017 11:17:40 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.99] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EB7E3A1A-2F88-477D-9BA0-65244B1FD523"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 15 Dec 2017 11:17:38 -0600 In-Reply-To: Cc: Thomas Stach , mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org To: Peter Saint-Andre References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:17:44 -0000 --Apple-Mail=_EB7E3A1A-2F88-477D-9BA0-65244B1FD523 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 14, 2017, at 10:15 PM, Peter Saint-Andre = wrote: >=20 > On 12/14/17 4:39 PM, Ben Campbell wrote: >=20 >>> On Dec 11, 2017, at 6:22 AM, Thomas Stach = wrote: >>>=20 >=20 > >=20 >>>> -4.2.2, third paragraph after Fig 4: "or when new candidates have = not been >>>> learned since then) and/or they MAY also deliver newly learned = candidates (if >>>> available). The Offerer MAY include an end-of-candidates attribute = in case >>>> candidate discovery has ended in the mean time." >>>>=20 >>>> Are those MAYs really correct when the conditions are true? E.g. if = you have >>>> newly learned candidates, there's only a MAY requirement to add = them? >>>> Likewise, if discovery has ended, there's only a MAY requirement to = add the >>>> end-of-candidates attribute? >>>>=20 >>> The motivation for the "MAY"s was to allow for pre-building of that = initial INFO only from information that is available when the Offer was = sent. >>> Of course new candidates need to be trickled eventually. >>> Changing the "MAY"s to "SHOULD"s would still allow for such = pre-building. We can do that if you prefer. >>=20 >> SHOULD helps, but it doesn=E2=80=99t really get to the point of my = comment. The text says =E2=80=9CMAY also deliver newly learned = candidates ( *if available*)=E2=80=9D (emphasis mine). So, my question = is, _if_, they are available, is it ever reasonable to not send them? = (Same applies to the end-of-candidates attribute). >>=20 >> Would it make sense to say something along the lines of =E2=80=9CIf = newly learned candidates have become available since=E2=80=A6 the = offerer [MUST/SHOULD] include them.=E2=80=9D ? >=20 > My understanding is we don't want to force an agent to tell its peer > about all candidates because some of them might be expensive to use > (thus the agent might want to hold them in reserve). Okay, that makes sense. A sentence to that effect in the text might help = clarify things. Thanks! Ben. --Apple-Mail=_EB7E3A1A-2F88-477D-9BA0-65244B1FD523 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlo0A7IACgkQgFZKbJXz 1A1OcBAAkE4hUm246ezMhHnZuCimJ32fdeMM0C3xW9ljY+YCVFqwI7H4e3zeIbT8 Q2JP/5hV/m8Z0aMbJsj5Vowbf8NUw47ZmrLVN/XzhmkxD3HTavwGGzdC2NZTPlnk /5HjEoNLhHdfkYXm9sEJuTr1O1JZH1C3i1H0zHHRDZMZwumiUkdJU1DVwVIXmFfg s7QW9Wknv6GrqGG/G8TutrUJiPMGOTakG4R2nQvb+qcX//WMTLZssoYS6SWvrqVJ nQlfxFKVwGoCLbnn2yauMExRwXi5hLXHCKQ6oGZSxhTcty3GLwNrQx9l8cSSkRC5 8q0nKsgv1ntHRBYmwRwm3uwWnZRZPTiYCzQKmtPAtiZ7sUKRIzjF9BhdlRhzs/yE s20qIDTxFVqh7AR7qCxoBY9mjj1mEM7uHH9vCwVCb/K1XH9ZSioK3iObGHn8B+Nq JwUtKeubdNMVHBUXLxZsDBaNDEszXEhAE406eSkvlPJ2b35U0lyXHx6+k8R8lih3 FAplNETxJWwMD7twniXV3chIMv6upM9MysX8ZOidZr/qbGKdZnU3vz9tPExQCcBA yAVwdv5Ut2xVvxLTjLjdcJDN8GdpAhjPt4yUiFaHBo5a1jf/I6ZfCuwd67vmFtWC MG1CO6vedbmqpzL0yGdwrsFifi+6jQkrZZmlKtOf5mjkzfvGUg4= =37z+ -----END PGP SIGNATURE----- --Apple-Mail=_EB7E3A1A-2F88-477D-9BA0-65244B1FD523-- From nobody Fri Dec 15 10:35:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA7012706D for ; Fri, 15 Dec 2017 10:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keP2RYToPPcj for ; Fri, 15 Dec 2017 10:35:53 -0800 (PST) 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 3A3D8127B60 for ; Fri, 15 Dec 2017 10:35:53 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id 184so6796084oii.2 for ; Fri, 15 Dec 2017 10:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=gHL7w1UwpLQD2RUfXx0ko+UEcNS5hYN7XmUsN+udOh8=; b=OQG1Tpy+y1y4G7ar7DaTrZkszwnih0bz1JeYTTVjFO/CaTmt670kHqbKMT7UBtdxIm XzjfBevSxTcbhW5mNGYicr+bJHiwe+DsbfeOS6fbfj2cOmo8oomW6bLMk+eYWOgI8i+v IgEe9fZ07c6ua9zBfTIn2lpw9m6e2keXKulSI= 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; bh=gHL7w1UwpLQD2RUfXx0ko+UEcNS5hYN7XmUsN+udOh8=; b=cxHZvKsN05eDaST/R7OWyN2EenUJuU757MYixQz8zEV4BrJAqSFiSifRCW7CNTSSLA VUiSGBMaqBxp6nGzmInqLQ3IfQNk+MFGx3boNCEjGc1JOAQfw6pT2G7uQqzylRqTK9wS /UVwOCTqTL6hsA1wG9Qmp0vQ+l3azTmMxUX7X1330YO/z6dmohCWyAdyEcC4JwZO+7kD 24kce7i1JutZ0sT+CAz3x+dE7h+ZrULa/e3lZGGDSspZ+kcoNqgSwL53drZCWcHrRJm4 vrr0JgYAwKBGxbTVuMQ8QU3mWoCQvUWl7EpITJ/frO5izbLulCEH44fMdeVQhHd3pGXg Xg6Q== X-Gm-Message-State: AKGB3mKlguxoX2pYtR7eHL8JCD3CMcYF6VujkHfNq2WsgwCAp+A0dre6 omCSIh240MnHnH+sx+cPSMEvOXtRs8Y= X-Google-Smtp-Source: ACJfBosuq/PZ8jTaBX9Rh4UMRIZsef9WGZhGm2vGE9qY1CNc3Dvfx0oRcx7eUexIJBUyd4L+7qVXKQ== X-Received: by 10.202.58.8 with SMTP id h8mr7539453oia.88.1513362952390; Fri, 15 Dec 2017 10:35:52 -0800 (PST) Received: from dragon.local (rrcs-97-79-186-3.sw.biz.rr.com. [97.79.186.3]) by smtp.gmail.com with ESMTPSA id t37sm3347504oti.24.2017.12.15.10.35.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 10:35:51 -0800 (PST) To: Ben Campbell Cc: Thomas Stach , mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> From: Peter Saint-Andre Message-ID: Date: Fri, 15 Dec 2017 12:35:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vw21UiID2R7NrVNErucViLNRFWll9c0ev" Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 18:35:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vw21UiID2R7NrVNErucViLNRFWll9c0ev Content-Type: multipart/mixed; boundary="FpPS8E7htIcclnORvRNI6EKAHbip2gwrx"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell Cc: Thomas Stach , mmusic@ietf.org, draft-ietf-mmusic-trickle-ice-sip.all@ietf.org Message-ID: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-trickle-ice-sip-11 References: <70438631-8BE0-46D1-884E-F6D31BB5BE85@nostrum.com> <6274dfc4-558c-dbe5-7827-f1a4c508121b@gmail.com> In-Reply-To: --FpPS8E7htIcclnORvRNI6EKAHbip2gwrx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/15/17 11:17 AM, Ben Campbell wrote: >=20 >=20 >> On Dec 14, 2017, at 10:15 PM, Peter Saint-Andre = wrote: >> >> On 12/14/17 4:39 PM, Ben Campbell wrote: >> >>>> On Dec 11, 2017, at 6:22 AM, Thomas Stach = wrote: >>>> >> >> >> >>>>> -4.2.2, third paragraph after Fig 4: "or when new candidates have n= ot been >>>>> learned since then) and/or they MAY also deliver newly learned cand= idates (if >>>>> available). The Offerer MAY include an end-of-candidates attribute= in case >>>>> candidate discovery has ended in the mean time." >>>>> >>>>> Are those MAYs really correct when the conditions are true? E.g. if= you have >>>>> newly learned candidates, there's only a MAY requirement to add the= m? >>>>> Likewise, if discovery has ended, there's only a MAY requirement to= add the >>>>> end-of-candidates attribute? >>>>> >>>> The motivation for the "MAY"s was to allow for pre-building of that= initial INFO only from information that is available when the Offer was= sent. >>>> Of course new candidates need to be trickled eventually. >>>> Changing the "MAY"s to "SHOULD"s would still allow for such pre-buil= ding. We can do that if you prefer. >>> >>> SHOULD helps, but it doesn=E2=80=99t really get to the point of my co= mment. The text says =E2=80=9CMAY also deliver newly learned candidates (= *if available*)=E2=80=9D (emphasis mine). So, my question is, _if_, they= are available, is it ever reasonable to not send them? (Same applies to = the end-of-candidates attribute). >>> >>> Would it make sense to say something along the lines of =E2=80=9CIf n= ewly learned candidates have become available since=E2=80=A6 the offerer = [MUST/SHOULD] include them.=E2=80=9D ? >> >> My understanding is we don't want to force an agent to tell its peer >> about all candidates because some of them might be expensive to use >> (thus the agent might want to hold them in reserve). >=20 > Okay, that makes sense. A sentence to that effect in the text might hel= p clarify things. BTW, there is a brief mention of this topic in Section 11 of draft-ietf-ice-trickle-15. Peter --FpPS8E7htIcclnORvRNI6EKAHbip2gwrx-- --vw21UiID2R7NrVNErucViLNRFWll9c0ev Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlo0FgYACgkQZWGMGH9o FKlU1g//dUhpghirRmRMBAU96MmfawItTNfISTEa36mamkMjO0xx9ZMwV19jHisz sQ28moBI4r9EJ3tmyu17itcrlNURAzjxIxWzFcGAs4yP/sfU1MCYibTVgU1HTARE nfNazxJ+LYUygzkE0vKM9vuf3HW9/kNAEn8mzhbQkBcBJHxl1m3SWqQexWDSfNAV dR1JHhbNe4L0Ji+7yotKgZx2hEH329wlPyNG5qYO6zcWrGQo6rZBwyTtourBsNgO /i80OQTUQF2MuZ0EeyKaHAYyfbDHz0hmgPJt/qKNIA7IlJMNVJrKxgST8nhDNNEt IU4YZic4U0EoFB5IMy5Sy29mwzvw/w/0ytcvAggP+2J09Qj3nhWU9hsTHW2DdUJI aqjx9ezAHKxP7VlRGbMtNOoAJsaffAL5xaQHRpM6GleNGOT5clDLkCMT5Fs0rQCP WYjGYLVipGWE7UpLXZQ2EsPqAZPmlzHQDMYC/xXDQ2hy0p9xZOlb/EFQn31xAkBd 6Kf4bv1Imycy2UBbGBEn+oOq3+ct0T2Moa/AnO56VPA4dBM9ZyL9qQ4relhDBEHl d4orv+R0jOj7zSoQOIPV4RFEV4j1qOFh/9sr1hypCMCxP2UVJlXYZcPX1F6c+vWw Xs0Jk5bVmS/I0nGjbGTTtOI7w2Rewd3x4uSNPJH260AMYijK0b0= =OX1c -----END PGP SIGNATURE----- --vw21UiID2R7NrVNErucViLNRFWll9c0ev-- From nobody Mon Dec 18 04:32:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5708D127867 for ; Mon, 18 Dec 2017 04:32:40 -0800 (PST) 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 CjZeqlkEojDf for ; Mon, 18 Dec 2017 04:32:36 -0800 (PST) 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 83E6B127333 for ; Mon, 18 Dec 2017 04:32:36 -0800 (PST) X-AuditID: c1b4fb2d-b4dff70000007932-d3-5a37b561b350 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A6.37.31026.165B73A5; Mon, 18 Dec 2017 13:32:34 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 18 Dec 2017 13:32:33 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 Thread-Index: AQHTd/xHyx+qbUdapUGHFySsWFTOLw== Date: Mon, 18 Dec 2017 12:32:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D65D843F27DD5christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7qG7SVvMog11TuCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujD2f5jIVTPStaH12irmB8YV9FyMHh4SAicSkBq0uRi4OIYHD jBKz1vxihXCWMEpMnH6TGaSITcBCovufdhcjJ4eIgLrE1709zCC2sECwxISX+5kg4hESJ/6/ ZIOw9ST+fp0JFmcRUJXYMO082BheAWuJ1Z9VQMKMAmIS30+tASthFhCXuPVkPpgtISAgsWTP eWYIW1Ti5eN/rCC2KNDIDSdus0PEFSV2nm1nhuhNkPg1czdYL6+AoMTJmU9YJjAKzUIydhaS sllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKWEcK2lvg8dzILspoFjByrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQLj5OCW37o7GFe/djzEKMDBqMTDu3qzeZQQa2JZcWXuIUYJDmYlEd7U YqAQb0piZVVqUX58UWlOavEhRmkOFiVx3pOevFFCAumJJanZqakFqUUwWSYOTqkGRrZL+8T+ fZW02ir1Ku4468aH/H9uMSwXfbPDwr7hd9tGXlu3eVMvPOpVltTfoFJX9WAJ+6qVtjEfNbRu n0u6eHO5yurDp468W39/W7ayYRBPb5GlcPH76LPXmX2O3Ti67m3y/+zK4vWrhSvDPqVejvt7 bIm06BUbj56vx7OWJQZ8fnOLTfinvLMSS3FGoqEWc1FxIgB3PXkCjwIAAA== Archived-At: Subject: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 12:32:41 -0000 --_000_D65D843F27DD5christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, As I had some time to breath during the work to finalise BUNDLE, I noted so= me issues with trickle-ice-sip. They are mostly editorial, and I did check = that Ben hadn=92t given the same comments as part of his AD review (if he d= id, I missed it). Q1_EDITORIAL: The draft talks about =93INVITE requests=94, =9318x responses=94 etc, but u= ses both =93INFO messages=94 and =93INFO requests". I suggest to only say = =93INFO requests=94, in order to have consistent terminology. Q2_TECHNICAL: Section 4.1.3 says: "Section Section 4.1.1 applies to the Answerer with the roles of Offerer a= nd Answer being swapped." Does this mean that the answerer shall also, for each m- section where it h= as yet no candidates, use =93audio=94, port 9 and RTP/AVP, no matter what w= as used in the corresponding offer? If so, I believe that would require an = update to RFC 3264. Q3_ EDITORIAL: Where is there no procedures for sub-sequent offers/answers? Q4_EDITORIAL: Related to Q3: The text in section 4.2.2 says: "When sending the Answer in the 200 OK response to the INVITE request, the Answerer MUST repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response." What about other answers? For example, there could be O/A transactions BEFO= RE the 200 OK is sent, using UPDATEs or PRACKs? What about answerer sent later during the session? Q5_EDITORIAL: First, in section 7, in the initial offer example, there is no a=3Dice-opti= ons:trickle attribute. Is there a reason for that? Second, in section 7, in the initial offer example, you don=92t use the =93= audio=94/port 9/=93RTP/AVP=94 rule from section 4.1.1. If that is due to BU= NDLE, I think you need to be more explicit about it. Third, in section 7, in the INFO example, I assume the second m- section sh= all contain a bundle-only attribute? Fourth, section 7 does contain the following text: "Except for bundle-only "m=3D" lines, a Half Trickle Offerer would have to send an offer with candidates for all bundled "m=3D" lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the "m=3D" line with the suggested Offerer BUNDLE address." Not really sure how this fits with the example. Also, in the case of full t= rickle, I am not sure I understand why you only would have to include candi= dates in the m- section associated with the offerer BUNDLE address, if ther= e are multiple non-bundle-only m- sections. Could you explain? Regards, Christer --_000_D65D843F27DD5christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

As I had some time to breath during the work to finalise BUNDLE, I noted so= me issues with trickle-ice-sip. They are mostly editorial, and I did check = that Ben hadn=92t given the same comments as part of his AD review (if he d= id, I missed it).


Q1_EDITORIAL:

The draft talks about =93INVITE requests=94, =9318x responses=94 etc, but u= ses both =93INFO messages=94 and =93INFO requests". I suggest to only = say =93INFO requests=94, in order to have consistent terminology.


Q2_TECHNICAL:

Section 4.1.3 says:
 "Section Section 4.1.1 applies to the Answerer with=
 the roles of Offerer and Answer being swapped."
Does this mean that the answerer shall also, for each m- section where= it has yet no candidates, use =93audio=94, port 9 and RTP/AVP, no matter w= hat was used in the corresponding offer? If so, I believe that would requir= e an update to RFC 3264.


Q3_ EDITORIAL:

Where is there no procedures for sub-sequent offers/answers?


Q4_EDITORIAL:

Related to Q3:

The text in section 4.2.2 says:
   "When sending the Answer in the 200 OK response t=
o the INVITE request,
   the Answerer MUST repeat exactly the same Answer that was previously
   sent in the unreliable provisional response in order to fulfill the
   corresponding requirements in [RFC3264].  Thus, the Offerer needs to
   be prepared for receiving a different number of candidates in that
   repeated Answer than previously exchanged via trickling and MUST
   ignore the candidate information in that 200 OK response."

What about other answers? For example, there could be O/A transactions= BEFORE the 200 OK is sent, using UPDATEs or PRACKs?

What about answerer sent later during the session?


Q5_EDITORIAL:

First, in section 7, in the initial offer example, there is no a=3Dice-options:trickle attribute. Is there a reason for that?

Second, in section 7, in the initial offer example, you don=92t use th= e =93audio=94/port 9/=93RTP/AVP=94 rule from section 4.1.1. If that is due = to BUNDLE, I think you need to be more explicit about it.

Third, in section 7, in the INFO example, I assume the second m- secti= on shall contain a bundle-only attribute?

Fourth, section 7 does contain the following text:
   "Except for bundle-only "m=3D" lines, a=
 Half Trickle Offerer would have
   to send an offer with candidates for all bundled "m=3D" lines.=
  The
   additional flexibility, however, allows a Full Trickle Offerer to
   initially send only candidates for the "m=3D" line with the su=
ggested
   Offerer BUNDLE address."
Not really sure how this fits with the example. Also, in the case of f= ull trickle, I am not sure I understand why you only would have to include = candidates in the m- section associated with the offerer BUNDLE address, if= there are multiple non-bundle-only m- sections. Could you explain?

Regards,

Christer
--_000_D65D843F27DD5christerholmbergericssoncom_-- From nobody Mon Dec 18 08:46:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B92E31267BB for ; Mon, 18 Dec 2017 08:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSzOUEz0yueB for ; Mon, 18 Dec 2017 08:46:10 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 964051243F3 for ; Mon, 18 Dec 2017 08:46:09 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id a41so14759354wra.6 for ; Mon, 18 Dec 2017 08:46:09 -0800 (PST) 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=Xc0/4J68v82Nb5W1DPXJB4rGDrMlSYtBw51pwsnNBVg=; b=naskvCGKYnCHiYt6zyC1h9JcV9mnBm0z9B9I3OTDxfRzfu1ESuuiDQJV25kQ4JerzI uO6ACRCCcxOIpIXzLst4Qq5vc/ejqqM2gR/bD2B3HLB/zsaqBXtDYunBtnrBs1vSgbXa y4ojIAJGP3XFqvqRni7BOU4a/rnudYxEKWZdegb4UUPHpb1WvABMlE/zJOgTEslu1QYt WHCYfzpKV+LtaBFyiGULMrEuYdmnrw6Oeodkx0kxTzCR40btF9LfLLDRSp8/cbH0+tg7 mfLFzmici6RRbI0VoLo64CXc/+yiJrwKUklD0MDdKBsqlSkuNFt2NJrknu6pWV2t/80i 4s4w== 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=Xc0/4J68v82Nb5W1DPXJB4rGDrMlSYtBw51pwsnNBVg=; b=kjvvHW6LniB7y9syWgqK2oXODTJfP1bt5XkVn1mCVXrLi5uvmxhRlKhb4ecWVZsEr6 u9hdSpHOWrTqrnYv69yYXmqBlYtKe8jAAShTQqnUrWHhNthxgq2QzetnZvYMF2kgq5x1 1TS5Ur8E6vS7dGq/K5azrL/wxRF1K0OKKKacG7ATAbWmfYBoh1cDpdQclaA/B0cDDvji 6QrtJD/bgD8CPGyt+l+JFYCuRIswjihdnrgEK21isQy+WRxpjjSnMegBr1o70y9QCMgj D177ZEMAEN5HZvrWSxQhVf2THOAiRAdHcOg9XZ+tYZp5CxhW/IulHS9YmcCl8CkqeeSL gnLQ== X-Gm-Message-State: AKGB3mLNS00Oq3OrecAz2QIBoE621hEbJNRD6Q/duswOAuXKaBXchvoh NatrjrQI2F1vHHfU200XhHM= X-Google-Smtp-Source: ACJfBovVkoSGhObgmRz8pFez82qt0N+NP4fmPBUN88U1uX8xlrRMdLba2btDsxlZGbHi386r0yJWFw== X-Received: by 10.223.172.146 with SMTP id o18mr490222wrc.128.1513615567733; Mon, 18 Dec 2017 08:46:07 -0800 (PST) Received: from [192.168.2.109] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id l25sm20007945wmi.35.2017.12.18.08.46.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 08:46:07 -0800 (PST) To: mmusic@ietf.org, Christer Holmberg References: From: Thomas Stach Message-ID: <19c32292-f07f-ea8c-ad04-59d34b0c4a23@gmail.com> Date: Mon, 18 Dec 2017 17:46:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------42F45872BCE60BC50B11CF92" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 16:46:13 -0000 This is a multi-part message in MIME format. --------------42F45872BCE60BC50B11CF92 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Christer, thanks for the additional co-author review and your comments. responses inline .. On 2017-12-18 13:32, Christer Holmberg wrote: > Hi, > > As I had some time to breath during the work to finalise BUNDLE, I > noted some issues with trickle-ice-sip. They are mostly editorial, and > I did check that Ben hadn’t given the same comments as part of his AD > review (if he did, I missed it). > > > *Q1_EDITORIAL:* > > The draft talks about “INVITE requests”, “18x responses” etc, but uses > both “INFO messages” and “INFO requests". I suggest to only say “INFO > requests”, in order to have consistent terminology. I also recognized that. I already started the alignment > > > *Q2_TECHNICAL:* > > Section 4.1.3 says: > "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped." > Does this mean that the answerer shall also, for each m- section where > it has yet no candidates, use “audio”, port 9 and RTP/AVP, no matter > what was used in the corresponding offer? If so, I believe that would > require an update to RFC 3264. Good point. Of course not. This will be clarified when I address a similar comment by Ben on section 4.1.1. > > > *Q3_ EDITORIAL:* > > Where is there no procedures for sub-sequent offers/answers? That will be as for regular ICE. I'll add a section that refers to draft-ice-sip-sdp to make that explicit. > > > *Q4_EDITORIAL:* > > Related to Q3: > > The text in section 4.2.2 says: > "When sending the Answer in the 200 OK response to the INVITE request, > the Answerer MUST repeat exactly the same Answer that was previously > sent in the unreliable provisional response in order to fulfill the > corresponding requirements in [RFC3264]. Thus, the Offerer needs to > be prepared for receiving a different number of candidates in that > repeated Answer than previously exchanged via trickling and MUST > ignore the candidate information in that 200 OK response." > > What about other answers? For example, there could be O/A transactions > BEFORE the 200 OK is sent, using UPDATEs or PRACKs? Good point. Even more interesting is how the  offer looks like. However, that should be covered by the  section on subsequent offers for regular ICE, even if we are in the middle of trickling. There is the following text in 4.2.1.2.1 of ice-sip-sdp: "An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream." If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dialog, it just puts all already signaled candidates in that offer. I'll mention that in the section for subsequent offers/answer. > > What about answerer sent later during the session? as above > > > *Q5_EDITORIAL:* > * > * > First, in section 7, in the initial offer example, there is no > a=ice-options:trickle attribute. Is there a reason for that? just an oversight > > Second, in section 7, in the initial offer example, you don’t use the > “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is due to > BUNDLE, I think you need to be more explicit about it. That rule in 4.1.1. was just a last resort, but there will be anyhow an adaptation based on a comment by Ben. So, the SDP probably needs some  adaptations as well. However, if you know your ports, codecs, etc. you will put that into the initial offer. There is nothing bundle-specific here. Nevertheless, you have a point in that a host candidate could already go into this example offer. > > Third, in section 7, in the INFO example, I assume the second m- > section shall contain a bundle-only attribute? Thanks for the reminder. -11 was produced before the latest changes in bundle. > > Fourth, section 7 does contain the following text: > "Except for bundle-only "m=" lines, a Half Trickle Offerer would have > to send an offer with candidates for all bundled "m=" lines. The > additional flexibility, however, allows a Full Trickle Offerer to > initially send only candidates for the "m=" line with the suggested > Offerer BUNDLE address." > Not really sure how this fits with the example. Also, in the case of > full trickle, I am not sure I understand why you only would have to > include candidates in the m- section associated with the offerer > BUNDLE address, if there are multiple non-bundle-only m- sections. > Could you explain? If my understanding of bundle is still correct (I haven't looked yet into the latest update), you would have to provide candidates for all non-bundle-only m-lines as a fallback in case that bundle is rejected/not supported. These candidates were wasted, if bundle was accepted. With trickle you can initially provide candidates just for the m-line with the offerer bundle address. The other candidates would be trickled only if needed, i.e. if bundle is rejected. Does that make sense? Regards Thomas > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------42F45872BCE60BC50B11CF92 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Christer,

thanks for the additional co-author review and your comments.

responses inline ..


On 2017-12-18 13:32, Christer Holmberg wrote:
Hi,

As I had some time to breath during the work to finalise BUNDLE, I noted some issues with trickle-ice-sip. They are mostly editorial, and I did check that Ben hadn’t given the same comments as part of his AD review (if he did, I missed it).


Q1_EDITORIAL:

The draft talks about “INVITE requests”, “18x responses” etc, but uses both “INFO messages” and “INFO requests". I suggest to only say “INFO requests”, in order to have consistent terminology.
I also recognized that. I already started the alignment


Q2_TECHNICAL:

Section 4.1.3 says:
 "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped."
Does this mean that the answerer shall also, for each m- section where it has yet no candidates, use “audio”, port 9 and RTP/AVP, no matter what was used in the corresponding offer? If so, I believe that would require an update to RFC 3264.
Good point.
Of course not. This will be clarified when I address a similar comment by Ben on section 4.1.1.



Q3_ EDITORIAL:

Where is there no procedures for sub-sequent offers/answers?
That will be as for regular ICE. I'll add a section that refers to draft-ice-sip-sdp to make that explicit.


Q4_EDITORIAL:

Related to Q3:

The text in section 4.2.2 says:
   "When sending the Answer in the 200 OK response to the INVITE request,
   the Answerer MUST repeat exactly the same Answer that was previously
   sent in the unreliable provisional response in order to fulfill the
   corresponding requirements in [RFC3264].  Thus, the Offerer needs to
   be prepared for receiving a different number of candidates in that
   repeated Answer than previously exchanged via trickling and MUST
   ignore the candidate information in that 200 OK response."

What about other answers? For example, there could be O/A transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?
Good point.
Even more interesting is how the  offer looks like.
However, that should be covered by the  section on subsequent offers for regular ICE, even if we are in the middle of trickling.
There is the following text in 4.2.1.2.1 of ice-sip-sdp:
"An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream."
If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dialog, it just puts all already signaled candidates in that offer.
I'll mention that in the section for subsequent offers/answer.

What about answerer sent later during the session?
as above


Q5_EDITORIAL:

First, in section 7, in the initial offer example, there is no a=ice-options:trickle attribute. Is there a reason for that?
just an oversight

Second, in section 7, in the initial offer example, you don’t use the “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is due to BUNDLE, I think you need to be more explicit about it.
That rule in 4.1.1. was just a last resort, but there will be anyhow an adaptation based on a comment by Ben.
So, the SDP probably needs some  adaptations as well.
However, if you know your ports, codecs, etc. you will put that into the initial offer. There is nothing bundle-specific here.
Nevertheless, you have a point in that a host candidate could already go into this example offer.


Third, in section 7, in the INFO example, I assume the second m- section shall contain a bundle-only attribute?
Thanks for the reminder. -11 was produced before the latest changes in bundle.

Fourth, section 7 does contain the following text:
   "Except for bundle-only "m=" lines, a Half Trickle Offerer would have
   to send an offer with candidates for all bundled "m=" lines.  The
   additional flexibility, however, allows a Full Trickle Offerer to
   initially send only candidates for the "m=" line with the suggested
   Offerer BUNDLE address."
Not really sure how this fits with the example. Also, in the case of full trickle, I am not sure I understand why you only would have to include candidates in the m- section associated with the offerer BUNDLE address, if there are multiple non-bundle-only m- sections. Could you explain?
If my understanding of bundle is still correct (I haven't looked yet into the latest update), you would have to provide candidates for all non-bundle-only m-lines
as a fallback in case that bundle is rejected/not supported. These candidates were wasted, if bundle was accepted.
With trickle you can initially provide candidates just for the m-line with the offerer bundle address.
The other candidates would be trickled only if needed, i.e. if bundle is rejected.
Does that make sense?

Regards
Thomas

Regards,

Christer


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

--------------42F45872BCE60BC50B11CF92-- From nobody Mon Dec 18 09:00:53 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 641131289B0; Mon, 18 Dec 2017 09:00:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151361645234.3442.8545129773741480937@ietfa.amsl.com> Date: Mon, 18 Dec 2017 09:00:52 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-47.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 17:00:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-47.txt Pages : 67 Date : 2017-12-18 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group. To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow assigning a zero port value to a "m=" section without meaning that the media described by the "m=" section is disabled or rejected. When Real-time Transport Protocol (RTP)-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section. This specification defines a new RTP Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific "m=" section. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-47 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-47 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-47 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 Mon Dec 18 10:21:32 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1C12D831; Mon, 18 Dec 2017 10:21:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Flemming Andreasen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, iesg-secretary@ietf.org, mmusic@ietf.org Message-ID: <151362128440.3478.11553006795675719495.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 10:21:24 -0800 Archived-At: Subject: [MMUSIC] Publication has been requested for draft-ietf-mmusic-sdp-bundle-negotiation-47 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 18:21:24 -0000 Flemming Andreasen has requested publication of draft-ietf-mmusic-sdp-bundle-negotiation-47 as Proposed Standard on behalf of the MMUSIC working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ From nobody Mon Dec 18 12:03:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718A212D854 for ; Mon, 18 Dec 2017 12:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 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, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-EUR2D2UjyS for ; Mon, 18 Dec 2017 12:02:57 -0800 (PST) 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 87D3C124319 for ; Mon, 18 Dec 2017 12:02:56 -0800 (PST) X-AuditID: c1b4fb3a-90dff7000000028c-41-5a381eee135a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FB.38.00652.EEE183A5; Mon, 18 Dec 2017 21:02:54 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 18 Dec 2017 21:02:53 +0100 From: Christer Holmberg To: Thomas Stach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 Thread-Index: AQHTd/xHyx+qbUdapUGHFySsWFTOL6NJPqeAgAA9x8A= Date: Mon, 18 Dec 2017 20:02:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C0C6665@ESESSMB109.ericsson.se> References: <19c32292-f07f-ea8c-ad04-59d34b0c4a23@gmail.com> In-Reply-To: <19c32292-f07f-ea8c-ad04-59d34b0c4a23@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C0C6665ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdRfednEWUwatl0hZTlz9msfh0YiuT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxc/oZpoKJyxkrDh6UaGD8OoGxi5GTQ0LA RGL5snvMILaQwGFGic2T1boYuYDsJYwS/xftZu9i5OBgE7CQ6P6nDVIjIhAo8fnMcSYQW1gg QWLbsutsEPFEiealb6FsK4lrhxawgNgsAqoSu5rngM3nFfCV+HP5HTvErjyJg+/3gMU5BWwl Pi5ZyApiMwqISXw/tQZsPrOAuMStJ/OZIO4UkFiy5zwzhC0q8fLxP1YIW0li0e3PUPX5Ei// LGCH2CUocXLmE5YJjMKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopR tDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMH4ObvlttYPx4HPHQ4wCHIxKPLw1EhZRQqyJZcWV uYcYJTiYlUR4/c6aRwnxpiRWVqUW5ccXleakFh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgST ZeLglGpgnHHFr65HfG8b50Und9nzkt7pG9XeFT4UvPzM5aE6E+MX56oTqh8aa1dv2bE1d925 OJNTNqwPbERe1V1OmPog2DjX4+yf35Zff/T4/YtbvOjSXb99nv8E4l9L/Nrivids7+o979u/ 1dfZ8TnILWu7UTZNqF3Pg+1cTUjYj5STV7sjzSZNP9P/RImlOCPRUIu5qDgRALaIguibAgAA Archived-At: Subject: Re: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:02:59 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6C0C6665ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please see inline. Q2_TECHNICAL: Section 4.1.3 says: "Section Section 4.1.1 applies to the Answerer with the roles of Offerer a= nd Answer being swapped." Does this mean that the answerer shall also, for each m- section where it h= as yet no candidates, use "audio", port 9 and RTP/AVP, no matter what was u= sed in the corresponding offer? If so, I believe that would require an upda= te to RFC 3264. Good point. Of course not. This will be clarified when I address a similar comment by B= en on section 4.1.1. [Christer] I have probably missed it, but what is the reason for mandating = "audio" and "RTP/AVP" to begin with (I do understand the usage of port 9)? = I think it should be explained in this document, as it is SDP-specific. Q3_ EDITORIAL: Where is there no procedures for sub-sequent offers/answers? That will be as for regular ICE. I'll add a section that refers to draft-ic= e-sip-sdp to make that explicit. [Christer] See below (Q4). Q4_EDITORIAL: Related to Q3: The text in section 4.2.2 says: "When sending the Answer in the 200 OK response to the INVITE request, the Answerer MUST repeat exactly the same Answer that was previously sent in the unreliable provisional response in order to fulfill the corresponding requirements in [RFC3264]. Thus, the Offerer needs to be prepared for receiving a different number of candidates in that repeated Answer than previously exchanged via trickling and MUST ignore the candidate information in that 200 OK response." What about other answers? For example, there could be O/A transactions BEFO= RE the 200 OK is sent, using UPDATEs or PRACKs? Good point. Even more interesting is how the offer looks like. However, that should be covered by the section on subsequent offers for re= gular ICE, even if we are in the middle of trickling. There is the following text in 4.2.1.2.1 of ice-sip-sdp: "An agent MUST include candidate attributes for all local candidates it had= signaled previously for that media stream." If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dial= og, it just puts all already signaled candidates in that offer. I'll mention that in the section for subsequent offers/answer. [Christer] Thanks. Q5_EDITORIAL: First, in section 7, in the initial offer example, there is no a=3Dice-opti= ons:trickle attribute. Is there a reason for that? just an oversight Second, in section 7, in the initial offer example, you don't use the "audi= o"/port 9/"RTP/AVP" rule from section 4.1.1. If that is due to BUNDLE, I th= ink you need to be more explicit about it. That rule in 4.1.1. was just a last resort, but there will be anyhow an ada= ptation based on a comment by Ben. So, the SDP probably needs some adaptations as well. However, if you know your ports, codecs, etc. you will put that into the in= itial offer. There is nothing bundle-specific here. Nevertheless, you have a point in that a host candidate could already go in= to this example offer. [Christer] I think it would be good to have some explanation associated wit= h the examples. What exactly is the example showing. Third, in section 7, in the INFO example, I assume the second m- section sh= all contain a bundle-only attribute? Thanks for the reminder. -11 was produced before the latest changes in bund= le. Fourth, section 7 does contain the following text: "Except for bundle-only "m=3D" lines, a Half Trickle Offerer would have to send an offer with candidates for all bundled "m=3D" lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the "m=3D" line with the suggested Offerer BUNDLE address." Not really sure how this fits with the example. Also, in the case of full t= rickle, I am not sure I understand why you only would have to include candi= dates in the m- section associated with the offerer BUNDLE address, if ther= e are multiple non-bundle-only m- sections. Could you explain? If my understanding of bundle is still correct (I haven't looked yet into t= he latest update), you would have to provide candidates for all non-bundle-= only m-lines as a fallback in case that bundle is rejected/not supported. These candidat= es were wasted, if bundle was accepted. With trickle you can initially provide candidates just for the m-line with = the offerer bundle address. The other candidates would be trickled only if needed, i.e. if bundle is re= jected. Does that make sense? [Christer] If you have multiple non-bundle-only m- sections, you don't know= which will become the offerer bundle address before you receive the initia= l answer (as the answerer selects the offerer bundle address). Obviously, o= nce the offerer bundle address has been selected, you only need to send can= didates for that m- section. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6C0C6665ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Please see= inline.

 

Q2_TECHNICAL:

 

Section 4.1.3 says:

 "Section Section 4.1.1 applies to the Answerer with the roles of=
 Offerer and Answer being swapped."

Does this mean that the answerer shall also, fo= r each m- section where it has yet no candidates, use “audio”, = port 9 and RTP/AVP, no matter what was used in the corresponding offer? If so, I believe that would require an update to RFC 3264.

Good point.
Of course not. This will be clarified when I address a similar comment by B= en on section 4.1.1.

[Christer] I have probably missed it, but= what is the reason for mandating “audio” and “RTP/AVP= 221; to begin with (I do understand the usage of port 9)? I think it should be explained in this document, as it is SDP-specific.

 

 

Q3_ EDITORIAL:

 

Where is there no procedures for sub-sequent of= fers/answers?

That will be as for regular ICE. I'll add a section = that refers to draft-ice-sip-sdp to make that explicit.

[Christer] See below (Q4).

 

 

Q4_EDITORIAL:

 

Related to Q3:

 

The text in section 4.2.2 says:

   "When sending the Answer in the 200 OK resp=
onse to the INVITE request,
   the Answerer MUST repeat exactly the same Answer that was=
 previously
   sent in the unreliable provisional response in order to f=
ulfill the
   corresponding requirements in [RFC3264].  Thus, the =
Offerer needs to
   be prepared for receiving a different number of candidate=
s in that
   repeated Answer than previously exchanged via trickling a=
nd MUST
   ignore the candidate information in that 200 OK response.=
"

 

What about other answers? For example, there co= uld be O/A transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?=

Good point.
Even more interesting is how the  offer looks like.
However, that should be covered by the  section on subsequent offers f= or regular ICE, even if we are in the middle of trickling.
There is the following text in 4.2.1.2.1 of ice-sip-sdp:
"An agent MUST include candidate attributes for all local candidates i= t had signaled previously for that media stream."
If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dial= og, it just puts all already signaled candidates in that offer.
I'll mention that in the section for subsequent offers/answer.

[Christer] Thanks.

 

 

 

Q5_EDITORIAL:

 

First, in section 7, in the initial offer examp= le, there is no a=3Dice-options:trickle attribute. Is there a reason f= or that?

just an oversight

Second, in section 7, in the initial offer exam= ple, you don’t use the “audio”/port 9/“RTP/AVP̶= 1; rule from section 4.1.1. If that is due to BUNDLE, I think you need to b= e more explicit about it.

That rule in 4.1.1. was just a last resort, but ther= e will be anyhow an adaptation based on a comment by Ben.
So, the SDP probably needs some  adaptations as well.
However, if you know your ports, codecs, etc. you will put that into the in= itial offer. There is nothing bundle-specific here.
Nevertheless, you have a point in that a host candidate could already go in= to this example offer.

[Christer] I think it would be good to have some = explanation associated with the examples. What exactly is the example showi= ng.

 

Third, in section 7, in the INFO example, I ass= ume the second m- section shall contain a bundle-only attribute?=

Thanks for the reminder. -11 was produced before the= latest changes in bundle.

Fourth, section 7 does contain the following te= xt:

   "Except for bundle-only "m=3D" li=
nes, a Half Trickle Offerer would have
   to send an offer with candidates for all bundled "m=
=3D" lines.  The
   additional flexibility, however, allows a Full Trickle Of=
ferer to
   initially send only candidates for the "m=3D" l=
ine with the suggested
   Offerer BUNDLE address."

Not really sure how this fits with the example.= Also, in the case of full trickle, I am not sure I understand why you only= would have to include candidates in the m- section associated with the offerer BUNDLE address, if there are multiple non-bund= le-only m- sections. Could you explain?

If my understanding of bundle is still correct (I ha= ven't looked yet into the latest update), you would have to provide candida= tes for all non-bundle-only m-lines
as a fallback in case that bundle is rejected/not supported. These candidat= es were wasted, if bundle was accepted.
With trickle you can initially provide candidates just for the m-line with = the offerer bundle address.
The other candidates would be trickled only if needed, i.e. if bundle is re= jected.
Does that make sense?

[Christer] If you have multiple non-bundl= e-only m- sections, you don’t know which will become the offerer bund= le address before you receive the initial answer (as the answerer selects the offerer bundle address). Obviously, once the offe= rer bundle address has been selected, you only need to send candidates for = that m- section.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C0C6665ESESSMB109erics_-- From nobody Wed Dec 20 00:52:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56B5126CF9 for ; Wed, 20 Dec 2017 00:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, T_KAM_HTML_FONT_INVALID=0.01] 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 98esuT16jdXw for ; Wed, 20 Dec 2017 00:52:10 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F1D1200C1 for ; Wed, 20 Dec 2017 00:52:09 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id f140so8203441wmd.2 for ; Wed, 20 Dec 2017 00:52:09 -0800 (PST) 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=pwOyvVsaj8M+uRNg4/XuOk9IBJ0IHyofbbmJltd/u+8=; b=qy77L4vnv3isaMXFS+MnrqlN4JpiUlD8Dau4Dhwkt9Hwo12fVajpX0FZ/KolxVLwpy tS/z0M6jzU3TIdTG2cT2J7ChtnA6A98TKatkyvadbWwpJ07R78ToKwPav7qgpfJraid1 P2GO1ob991IP0HcEruXDQ5pu7l4VuI5lxEyb20qVWxl8mRjT7GI9RbqY1WaPT5CCMCzX 7nDBm1IcmlTqi+5vWfLTj3GdEpTuGmsAfHe/7DLL+M094nZYYARPmAdKKdV5thqn6SlI DblCzR1sOmJ4cpyNj13aq0er8QYw9aA+j9CeSL/CBpxUaLxJiijdDcCPHHses7gSGOS/ KUGQ== 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=pwOyvVsaj8M+uRNg4/XuOk9IBJ0IHyofbbmJltd/u+8=; b=L66ZiOpTUmNHqxi4waBERz5Kh6y59uQcp2iEfaEj3NuhuqPIvYjMrf3Z1vLQjaIh3z 3sL6HbB88RVe0iL0wcRzFO16oZs8O4T0UCUbbhS+hZJVBnr5hMebq+MlEmr+4NMO9mrl lG+ETHWXnJcjUg7U/+54j6KwyA6cbLOgVO0aedBgiHEsP0uEXAiY3OaS/3C5QiIzaGLQ ywWzsAjzYHpj0lUNrAyogtf8mN7JR5C4xwy0PSMw2q1eIVUClzLAVhJlOoRsG/zCVdjy VopzIvPr8+SN7I0ZTKJGL8dUPGGtUECJL4bLZ0GvBim5uwrmTJj0360zCLLf6wsYW0GA 1eyQ== X-Gm-Message-State: AKGB3mKodiukbA4g3EMmQ/vFviJlKQ08V7HmAAnO9vIGnpMKlEV8pPjs ipiWjP/DHCMso4ITP3hZXTbtPb8s X-Google-Smtp-Source: ACJfBovYVyjbuURjwjqmuGndIzI5UGv28NeDPYiK0rcLBsW310ia9m+aEopqdMz92h4enY9R1MjQOg== X-Received: by 10.80.147.14 with SMTP id m14mr4364621eda.121.1513759927710; Wed, 20 Dec 2017 00:52:07 -0800 (PST) Received: from [192.168.2.104] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id a52sm15933916eda.92.2017.12.20.00.52.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 00:52:06 -0800 (PST) To: Christer Holmberg , "mmusic@ietf.org" References: <19c32292-f07f-ea8c-ad04-59d34b0c4a23@gmail.com> <7594FB04B1934943A5C02806D1A2204B6C0C6665@ESESSMB109.ericsson.se> From: Thomas Stach Message-ID: <79159349-4eb6-29f2-ea78-59224ab3d004@gmail.com> Date: Wed, 20 Dec 2017 09:52:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C0C6665@ESESSMB109.ericsson.se> Content-Type: multipart/alternative; boundary="------------B19126C409B2CF877CE37E7B" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 08:52:19 -0000 This is a multi-part message in MIME format. --------------B19126C409B2CF877CE37E7B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Christer, On 2017-12-18 21:02, Christer Holmberg wrote: > > Hi, > > Please see inline. > > *Q2_TECHNICAL:* > > Section 4.1.3 says: > > "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped." > > Does this mean that the answerer shall also, for each m- section > where it has yet no candidates, use “audio”, port 9 and RTP/AVP, > no matter what was used in the corresponding offer? If so, I > believe that would require an update to RFC 3264. > > Good point. > Of course not. This will be clarified when I address a similar comment > by Ben on section 4.1.1. > > [Christer] I have probably missed it, but what is the reason for > mandating “audio” and “RTP/AVP” to begin with (I do understand the > usage of port 9) I think it should be explained in this document, as > it is SDP-specific. > Usage of "audio" and "RTP/AVP" is just an artifact and will be corrected in the next revision > > *Q3_ EDITORIAL:* > > Where is there no procedures for sub-sequent offers/answers? > > That will be as for regular ICE. I'll add a section that refers to > draft-ice-sip-sdp to make that explicit. > > [Christer] See below (Q4). > > *Q4_EDITORIAL:* > > Related to Q3: > > The text in section 4.2.2 says: > >    "When sending the Answer in the 200 OK response to the INVITE request, > >    the Answerer MUST repeat exactly the same Answer that was previously > >    sent in the unreliable provisional response in order to fulfill the > >    corresponding requirements in [RFC3264].  Thus, the Offerer needs to > >    be prepared for receiving a different number of candidates in that > >    repeated Answer than previously exchanged via trickling and MUST > >    ignore the candidate information in that 200 OK response." > > What about other answers? For example, there could be O/A > transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs? > > Good point. > Even more interesting is how the  offer looks like. > However, that should be covered by the  section on subsequent offers > for regular ICE, even if we are in the middle of trickling. > There is the following text in 4.2.1.2.1 of ice-sip-sdp: > "An agent MUST include candidate attributes for all local candidates > it had signaled previously for that media stream." > If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early > dialog, it just puts all already signaled candidates in that offer. > I'll mention that in the section for subsequent offers/answer. > > [Christer] Thanks. > > *Q5_EDITORIAL:* > > First, in section 7, in the initial offer example, there is > no a=ice-options:trickle attribute. Is there a reason for that? > > just an oversight > > Second, in section 7, in the initial offer example, you don’t use > the “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is > due to BUNDLE, I think you need to be more explicit about it. > > That rule in 4.1.1. was just a last resort, but there will be anyhow > an adaptation based on a comment by Ben. > So, the SDP probably needs some  adaptations as well. > However, if you know your ports, codecs, etc. you will put that into > the initial offer. There is nothing bundle-specific here. > Nevertheless, you have a point in that a host candidate could already > go into this example offer. > > [Christer] I think it would be good to have some explanation > associated with the examples. What exactly is the example showing. > All the text in section 7 (and 8) is meant to be that explanation. There might be some small artifacts, which I'll correct in the next revision.  Let me know if something remains unclear once the next revision is out. Regards Thomas > > Third, in section 7, in the INFO example, I assume the second m- > section shall contain a bundle-only attribute? > > Thanks for the reminder. -11 was produced before the latest changes in > bundle. > > Fourth, section 7 does contain the following text: > >    "Except for bundle-only "m=" lines, a Half Trickle Offerer would have > >    to send an offer with candidates for all bundled "m=" lines.  The > >    additional flexibility, however, allows a Full Trickle Offerer to > >    initially send only candidates for the "m=" line with the suggested > >    Offerer BUNDLE address." > > Not really sure how this fits with the example. Also, in the case > of full trickle, I am not sure I understand why you only would > have to include candidates in the m- section associated with the > offerer BUNDLE address, if there are multiple non-bundle-only m- > sections. Could you explain? > > If my understanding of bundle is still correct (I haven't looked yet > into the latest update), you would have to provide candidates for all > non-bundle-only m-lines > as a fallback in case that bundle is rejected/not supported. These > candidates were wasted, if bundle was accepted. > With trickle you can initially provide candidates just for the m-line > with the offerer bundle address. > The other candidates would be trickled only if needed, i.e. if bundle > is rejected. > Does that make sense? > > [Christer] If you have multiple non-bundle-only m- sections, you don’t > know which will become the offerer bundle address before you receive > the initial answer (as the answerer selects the offerer bundle > address). Obviously, once the offerer bundle address has been > selected, you only need to send candidates for that m- section. > > Regards, > > Christer > --------------B19126C409B2CF877CE37E7B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Christer,



On 2017-12-18 21:02, Christer Holmberg wrote:

Hi,

 

Please see inline.

 

Q2_TECHNICAL:

 

Section 4.1.3 says:

 "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped."

Does this mean that the answerer shall also, for each m- section where it has yet no candidates, use “audio”, port 9 and RTP/AVP, no matter what was used in the corresponding offer? If so, I believe that would require an update to RFC 3264.

Good point.
Of course not. This will be clarified when I address a similar comment by Ben on section 4.1.1.

[Christer] I have probably missed it, but what is the reason for mandating “audio” and “RTP/AVP” to begin with (I do understand the usage of port 9) I think it should be explained in this document, as it is SDP-specific.

Usage of "audio" and "RTP/AVP" is just an artifact and will be corrected in the next revision

 

 

Q3_ EDITORIAL:

 

Where is there no procedures for sub-sequent offers/answers?

That will be as for regular ICE. I'll add a section that refers to draft-ice-sip-sdp to make that explicit.

[Christer] See below (Q4).

 

 

Q4_EDITORIAL:

 

Related to Q3:

 

The text in section 4.2.2 says:

   "When sending the Answer in the 200 OK response to the INVITE request,
   the Answerer MUST repeat exactly the same Answer that was previously
   sent in the unreliable provisional response in order to fulfill the
   corresponding requirements in [RFC3264].  Thus, the Offerer needs to
   be prepared for receiving a different number of candidates in that
   repeated Answer than previously exchanged via trickling and MUST
   ignore the candidate information in that 200 OK response."

 

What about other answers? For example, there could be O/A transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?

Good point.
Even more interesting is how the  offer looks like.
However, that should be covered by the  section on subsequent offers for regular ICE, even if we are in the middle of trickling.
There is the following text in 4.2.1.2.1 of ice-sip-sdp:
"An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream."
If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dialog, it just puts all already signaled candidates in that offer.
I'll mention that in the section for subsequent offers/answer.

[Christer] Thanks.

 

 

 

Q5_EDITORIAL:

 

First, in section 7, in the initial offer example, there is no a=ice-options:trickle attribute. Is there a reason for that?

just an oversight

Second, in section 7, in the initial offer example, you don’t use the “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is due to BUNDLE, I think you need to be more explicit about it.

That rule in 4.1.1. was just a last resort, but there will be anyhow an adaptation based on a comment by Ben.
So, the SDP probably needs some  adaptations as well.
However, if you know your ports, codecs, etc. you will put that into the initial offer. There is nothing bundle-specific here.
Nevertheless, you have a point in that a host candidate could already go into this example offer.

[Christer] I think it would be good to have some explanation associated with the examples. What exactly is the example showing.

All the text in section 7 (and 8) is meant to be that explanation. There might be some small artifacts, which I'll correct in the next revision.
 Let me know if something remains unclear once the next revision is out.

Regards
Thomas

 

Third, in section 7, in the INFO example, I assume the second m- section shall contain a bundle-only attribute?

Thanks for the reminder. -11 was produced before the latest changes in bundle.

Fourth, section 7 does contain the following text:

   "Except for bundle-only "m=" lines, a Half Trickle Offerer would have
   to send an offer with candidates for all bundled "m=" lines.  The
   additional flexibility, however, allows a Full Trickle Offerer to
   initially send only candidates for the "m=" line with the suggested
   Offerer BUNDLE address."

Not really sure how this fits with the example. Also, in the case of full trickle, I am not sure I understand why you only would have to include candidates in the m- section associated with the offerer BUNDLE address, if there are multiple non-bundle-only m- sections. Could you explain?

If my understanding of bundle is still correct (I haven't looked yet into the latest update), you would have to provide candidates for all non-bundle-only m-lines
as a fallback in case that bundle is rejected/not supported. These candidates were wasted, if bundle was accepted.
With trickle you can initially provide candidates just for the m-line with the offerer bundle address.
The other candidates would be trickled only if needed, i.e. if bundle is rejected.
Does that make sense?

[Christer] If you have multiple non-bundle-only m- sections, you don’t know which will become the offerer bundle address before you receive the initial answer (as the answerer selects the offerer bundle address). Obviously, once the offerer bundle address has been selected, you only need to send candidates for that m- section.

 

Regards,

 

Christer


--------------B19126C409B2CF877CE37E7B-- From nobody Wed Dec 20 05:28:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48A712D890 for ; Wed, 20 Dec 2017 05:28:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 D31kCNtOtpho for ; Wed, 20 Dec 2017 05:28:51 -0800 (PST) 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 2EA02126CC7 for ; Wed, 20 Dec 2017 05:28:51 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-c3-5a3a6591f896 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.2D.13339.1956A3A5; Wed, 20 Dec 2017 14:28:49 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Dec 2017 14:28:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7Fg7hAZZwXA0cwkkUoJweorm6mGuhAhmjECmkS5hEzA=; b=OXLGr/fIjm+5DP2vKWclPmB0EOIPJOluYbCC9924ZPEQn8kdYJC6wPEyEO6MqHaPlRKWpHAlor439SSzZ+WaiLdo9yMI/1MkzXg5hh2QwlIcT+71bE34lukF645AVI0MlWKaio3Ljp72BZ45/WTib95M5lULRuB6uIkbf5Q5YT0= Received: from VI1PR07MB3262.eurprd07.prod.outlook.com (10.175.243.144) by VI1PR07MB3264.eurprd07.prod.outlook.com (10.175.243.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Wed, 20 Dec 2017 13:28:47 +0000 Received: from VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::445d:573d:af80:7d92]) by VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::445d:573d:af80:7d92%13]) with mapi id 15.20.0345.009; Wed, 20 Dec 2017 13:28:47 +0000 From: Bo Burman To: Christer Holmberg , Suhas Nandakumar CC: Ben Campbell , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , IETF MMUSIC WG Thread-Topic: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? Thread-Index: AdNqwWHfmFxQvqH0QuKOUUj6GQGJcAAPBWYvAAEdi4AAqpk4gAIAiQVA Date: Wed, 20 Dec 2017 13:28:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3264; 6:ZZr/TpZX6zOB+U1jVaTaZmVSCFsfTbA6sfbN4EMZ5RL+mHp8nLj1TugjtUvDa3WMPCxH/KmzvTDQxe5CkwD+JtILRJvGBWYooSi8Kni8L9Llw7dAtloJUtxmxBXDX/31PJHsqSXWJgnF2+TfcLt1hM0zVK9Uz+u7k8rOF8rz2ElgISrQ6YjAHstSk34soyKZ5hZCwylMSEsEHrZuFtv8JM5jQZ1I2/b39w4jfucC09iRCfwID5aaNSf0uKIHlC5Cr33/94QnEy0InNu3weniWkeBxjLV2cFPt4TX5gHud65IoIHfl2bFr8LXY6IKegSbeBGORk8JSjzY4cCdxMExvIKwcHJjS6SsmueMsGXE6u8=; 5:WPqGmjEN/7RuUejGKolcnVsmjFSlzTtggZ9ePbC+JK84IlJbEEWZYdHcx3uUY2S0T+THYWLkqjYE1c9rpJmAL4w24B1IKbkO0rgzfEsgPl6eC36bAq1G1B/ynzLyV3oaJLA75HF4g7bDDwYj/+d5/a8aacfno+HXiiEQE5UKN6s=; 24:Al7paoLVu8q4DIxi+PrDd3AkPptUbbvU6/jI9/8BB6LiylFChOO2c5IEBI/LBfRU0qxyzc5KrBZO/FsdrJJRedm1ealgtthIHfO05iKUmkY=; 7:NOKxO5DN+L+RU0BS+M4lDS0SSNhV+W7qx1XrdIv3Yyy7Tgz91Lr0Ua4U9D5A2N527UIGrp0g4FYYHePM3CXuwLX6fdnM3g1v0vGSULyRKET0E0mhEU/PNuocBhnp3/NyZlH6jiyzdPTw27FRNag/rCXPIXsoXittZmM2SoJyDFDEwtb8P19gXl4G9VvvgbXHzQY3dzktJDrDuVIJRYI8n3gJlGcPkcPq2gXzDyoMuVH95rMBicMQkzqPUUM43Rvp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 757214ec-14c7-46bf-a856-08d547ad99ae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:VI1PR07MB3264; x-ms-traffictypediagnostic: VI1PR07MB3264: x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(93006095)(93001095)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR07MB3264; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3264; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(366004)(39380400002)(199004)(189003)(13464003)(24454002)(81166006)(105586002)(97736004)(8676002)(81156014)(106356001)(93886005)(7736002)(5003630100001)(74316002)(68736007)(305945005)(478600001)(316002)(966005)(6436002)(9686003)(6306002)(110136005)(54906003)(14454004)(86362001)(55016002)(229853002)(66066001)(5660300001)(53936002)(3660700001)(2906002)(6246003)(6506007)(2900100001)(53546011)(2950100002)(5250100002)(76176011)(7696005)(8936002)(39060400002)(25786009)(6116002)(230783001)(33656002)(3280700002)(4326008)(102836003)(3846002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3264; H:VI1PR07MB3262.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 757214ec-14c7-46bf-a856-08d547ad99ae X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 13:28:47.4661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3264 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe3evd9fR7G1pHjShVoKpzbKiZUuyqJZhmSXqkHLpRYc6Zdck M8IMoTRNM9FZMRdmEZpSig4yaJGpU+YniOFHbhalVmQoZVje3QX99zvPec57PnhpQqJ38aI1 2ixGp1WnSSkRqY9t9d9WxoSotvcubpAbbliE8tn+UHnFIxspN92/ThwglabqMaGytvanQFlt spPKH4PzVCSpEimSmDRNNqMLCk0QpRT8KRdmPva++L1jQJiHjOsLkSsNeBf0dY8hjiX4NYLJ iTOFSLTCnQiu2XsoLiBxMQGVBfcoPqMXwMO5BWdgQ1B1c07A1VPYDwxt3Fs07Y4ToOdqOOch cCuCPION5DzrcBQ0LTQTHLvj09DQ2UvyfARGLDaKYxL7QnfhoEMX43jI75gn+WZFAmgcqnUk XLEC6tqHHIMj7AMTi+MOncCeMGo3CPjlMNS+sBI8e8An27IL74+D8rJeIa9vhIlf5U6PDwwY ihDXDLBZCB+/VDhNMmgpm3NsBjgCihcCeU8Dgrv5U85ifxiemqN4VkBVUaVTT4WWO71O/TjU 1+U7G9QQ0P7gG1GKgqr/G5xnGYxU3KF4DoA64wxR7bjGWujS28kaRD5BHizDnk9PDt4pY3Sa RJbN0Mq0TNYztPJhXjUv+bahwdkwM8I0kq4WJ0aHqCQu6mw2J92MgCak7uLc+b0qiThJnXOJ 0WWc011IY1gz8qZJqae465hYJcHJ6iwmlWEyGd2/rIB29cpDspLDfs2btzRYQjZ5ulkT+0vH R+xvY/p/K55/sC6h+ohRn76l/dY3n58q+vcpYmNOHSo1Hn1P2TSWrXbfQkve+J6cpICY3Cvp X6lJKtJ1t2DV9MtAFNU0Y2XCbrtNuXgfLDAFa0riGt9FxyuHZWeHLzetWWaN024nZm+dzKiU hUtJNkW9w5/Qseq/jsvRWCwDAAA= Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:28:54 -0000 Christer, all, So, to be clear, you suggest to add such note to the -sdp-mux-attributes dr= aft? Do the draft authors and the WG agree with that? /Bo MMUSIC co-chair > -----Original Message----- > From: Christer Holmberg > Sent: den 5 december 2017 10:35 > To: Suhas Nandakumar > Cc: Bo Burman ; Ben Campbell ; d= raft-ietf-mmusic-sdp-mux- > attributes@tools.ietf.org; IETF MMUSIC WG > Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with = BUNDLE? >=20 > Hi, >=20 > >> As I believe I have said before, we need to separate two things: > >> > >> 1) Whether the attribute value needs to be applied to all m- sections > >> 2) Whether the attribute needs to be explicitly assigned/encoded to > >>all > >>m- sections > >> > >> In my opinion, draft-mux-attributes shall only cover 1). > >> > >> 2) is BUNDLE specific. > >> > >> I do agree that it is a little difficult to determine whether > >>=B3repeat=B2 means 1) or 2). > > > > Above was my recollection too. I am not sure if we need to change Mux > >attributes. Since Mux attributes needs to be read along with the Bundle > >spec. > > The Bundle spec may define additional constraints or usage patterns. >=20 > I guess a note could have been useful, saying something like: >=20 > =B3NOTE: Eventhough IDENTICAL attributes must be repeated across all medi= a descriptions under multiplexing, they might > not always be explicitly encoded across all media descriptions. BUNDLE de= fines rules for when attributes and their values > are implicitly applied to media description.=B2 >=20 > Regards. >=20 > Christer >=20 >=20 >=20 >=20 > Sent from my iPhone >=20 > On 1 Dec 2017, at 18.30, Bo Burman wrote: >=20 >=20 >=20 > WG, >=20 > A while ago (in this thread: > https://mailarchive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U > ) > , Taylor concluded that the >=20 > -sdp-mux-attributes > > draft, which is currently in RFC Editor=B9s queue, needs to be updated to= align with current >=20 > BUNDLE > > draft. >=20 > The -sdp-mux-attributes draft unconditionally requires (in section 4.3) t= hat category IDENTICAL attributes and their > values =B3MUST be repeated across all the media descriptions under multip= lexing=B2. >=20 > BUNDLE (section 8.1) requires such repetition for IDENTICAL and TRANSPORT= only when a BUNDLE group is initially > negotiated. When the BUNDLE addresses have been selected, for all =B3m=3D= =B2 sections but the one carrying the BUNDLE-tag, > BUNDLE requires the opposite; MUST NOT include SDP attributes with IDENTI= CAL or TRANSPORT category. >=20 > Does the WG agree that -sdp-mux-attributes has to be changed to align wit= h what is now described by BUNDLE? >=20 > Unless anyone objects before EOB Dec 15, we will proceed with such change= to -sdp-mux-attributes. >=20 > Thanks, >=20 > Bo > MMUSIC co-chair >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 >=20 >=20 >=20 From nobody Wed Dec 20 05:31:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580B5120724 for ; Wed, 20 Dec 2017 05:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bdKdxezb820 for ; Wed, 20 Dec 2017 05:31:20 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 7923912422F for ; Wed, 20 Dec 2017 05:31:20 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id f13so24030566lff.12 for ; Wed, 20 Dec 2017 05:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=+yfK1XrfqNx2wZ4JLc0x7aNBnKP6bLJLJWi2fWIoUbE=; b=Curkzz5BqzBzzyFr0rEFrzaJj8ppploZiHXNiZjbbdxSL9qGBYNbChu3wQEx5Pug8T hujsU73g5yZ/zKSQN3A3rc3j88ZkMrY8o9otxEnG1d4L8v4NIEHdMV0Wl5oZPQTZRlwz k22WWFQyOFDX5cj4rKMncopyP9EzcaRZmUcLo3kNhkqzpnhiiy4b7SOfMoAmUX+uroB5 2LDtNbJ78bYjzguMBBcW8LIYdPiQnDr9XXhqxGFmLICl62fYKlmoy+XPIklvUNSTbj0D Y4wLF0hHYXrkLVE/Eay/uNtgtcYTf6OEtbkJbWnO4nZgYmYO2cmcbK0cmXa5icC7BXN9 o4OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=+yfK1XrfqNx2wZ4JLc0x7aNBnKP6bLJLJWi2fWIoUbE=; b=Tbibm5ZFOWDDMwVwwEH28G1dAeobyaWOgfkqsWfrYFrjUY5jG5dnFwHphY0Lm9Cncv 2YYL3rTl9i6MZQE+KdQjAdu9+IML0a4EJ6GC5hN2fI0ZjUeA7b7bqtbiWgNgeKhSZUNn 9GRd5hyGuAQog8x6RSg2DSeTWmIbQ9ueXpRDaKoQyPUcOiivImnH3qnb6qokcx0ZPEtX HhBpYfkh4NoDUDxIPJlohvMWV9kqZA2yym1mjx1QJifn0BaIjYAaj11FUwe1iDtTE6Bv m2/L1Wqf7a1KcsngTSn4JA8VUPkwDU8Ec4l+xk8nGHZjFJkLsXxBIB8V4I0Qf6h4Nu3C 6Dqw== X-Gm-Message-State: AKGB3mK7ROgfpwCzflGqICXpmyoL8Gl8AnqccY8tjCqvM8qVztRnD0fO LhnrQN5CvpNqEkz/tz8FyPM71tO4 X-Google-Smtp-Source: ACJfBouvxUmM1FqvL90dGdAn0xT3ctlxtvc+9WvIG9L9YnCESNIxR8TW0fXgyzVsgz24LBv1xneMug== X-Received: by 10.46.83.29 with SMTP id h29mr4367925ljb.144.1513776678387; Wed, 20 Dec 2017 05:31:18 -0800 (PST) Received: from [192.168.2.104] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id o64sm171302lfo.53.2017.12.20.05.31.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 05:31:17 -0800 (PST) To: MMUSIC From: Thomas Stach Message-ID: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.com> Date: Wed, 20 Dec 2017 14:31:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [MMUSIC] 4566bis: media field terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:31:22 -0000 Hi, just a quick observation. In 5.14 the end of the first para reads: "A media field has several sub-fields: " Wouldn't that have to be "A "m=" line has several sub-fields: "  ? There are several other occurrences of "media field" in the document, where sometimes _"m-" line_ and sometimes _media description_ seems to be more appropriate. p.14, 5.6, 3rd para ... before the first media field --> media description p.21, 1st para ... can also be added before the first media field  --> media description p.22, 2nd para  ... defined in the sub-field of the media field. --> "m-" line Regards Thomas From nobody Wed Dec 20 05:42:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC4B12D890 for ; Wed, 20 Dec 2017 05:42:04 -0800 (PST) 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 a_d6gzFLHgnh for ; Wed, 20 Dec 2017 05:42:01 -0800 (PST) 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 857CF120724 for ; Wed, 20 Dec 2017 05:42:01 -0800 (PST) X-AuditID: c1b4fb30-d49ff70000006bc7-c3-5a3a68a77333 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DD.AE.27591.7A86A3A5; Wed, 20 Dec 2017 14:41:59 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Wed, 20 Dec 2017 14:41:59 +0100 From: Christer Holmberg To: Bo Burman , Suhas Nandakumar CC: Ben Campbell , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , IETF MMUSIC WG Thread-Topic: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? Thread-Index: AdNqwWHfmFxQvqH0QuKOUUj6GQGJcAAPBWYv///4KICABXjPAIAXsESAgAAn4gA= Date: Wed, 20 Dec 2017 13:41:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: <5D9FEA1DB16E2B4CB46914C09D74F134@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7h+7yDKsog62TzS3md55mt3hz0c5i 6vLHLBY753YwO7B47Jx1l91jyZKfTB6zdj5h8fhy+TNbAEsUl01Kak5mWWqRvl0CV8aK+XEF 91QqJv2awdLA+ES5i5GTQ0LAROJwx3XGLkYuDiGBw4wSfx9MZwdJCAksYZRY38jVxcjBwSZg IdH9TxskLCLgJ7FgxW8mkHpmge2MEg3zH7OAJIQFgiSW/1jCBlEULLH2xFkWmIZ58zvAZrII qErsuXkWrIZXwFriwtJ1LBCL7zFJzFjznBUkwSkQK/H70X+wZkYBMYnvp9YwgdjMAuISt57M Z4K4WkBiyZ7zzBC2qMTLx//AekUF9CQ2nLjNDnK0hICSxLStaRCtWhJffuxjAwkzA+29f9gZ IqwoMaX7ITvEOYISJ2c+YZnAKD4LybJZSLpnIXTPQtI9C0n3AkbWVYyixanFSbnpRkZ6qUWZ ycXF+Xl6eaklmxiB8Xhwy2+DHYwvnzseYhTgYFTi4f0UYhUlxJpYVlyZe4hRgoNZSYS3+rNl lBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHek568UUIC6YklqdmpqQWpRTBZJg5OqQZGk2Sukrcz bd+6+XFbfNC45cj6trOkl/1Kbq7Oc+69frzMYYt/5kdomtex1eyZkMH3LEbE40zke5G4czcu 9/TwfbnhGbLAvv8g287HKXNK6x1uiKRHTI3awdVn8zsu12Dij8bAZXfvc1hPXrjhg3X521sr c1zq4hMm3btwWtj31Mwp+y0WHEhRYinOSDTUYi4qTgQA77KIzsMCAAA= Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:42:04 -0000 SGksDQoNCj5TbywgdG8gYmUgY2xlYXIsIHlvdSBzdWdnZXN0IHRvIGFkZCBzdWNoIG5vdGUgdG8g dGhlIC1zZHAtbXV4LWF0dHJpYnV0ZXMNCj5kcmFmdD8NCg0KWWVzLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQoNCg0KDQoNCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBDaHJpc3RlciBIb2xtYmVyZw0KPj4gU2VudDogZGVuIDUgZGVjZW1iZXIgMjAxNyAxMDozNQ0K Pj4gVG86IFN1aGFzIE5hbmRha3VtYXIgPHN1aGFzaWV0ZkBnbWFpbC5jb20+DQo+PiBDYzogQm8g QnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1 bS5jb20+Ow0KPj5kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LQ0KPj4gYXR0cmlidXRlc0B0b29s cy5pZXRmLm9yZzsgSUVURiBNTVVTSUMgV0cgPG1tdXNpY0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6 IFJlOiBbTU1VU0lDXSBDaGFuZ2Ugb2YgLXNkcC1tdXgtYXR0cmlidXRlcyBuZWVkZWQgdG8gYWxp Z24NCj4+d2l0aCBCVU5ETEU/DQo+Pg0KPj4gSGksDQo+Pg0KPj4gPj4gQXMgSSBiZWxpZXZlIEkg aGF2ZSBzYWlkIGJlZm9yZSwgd2UgbmVlZCB0byBzZXBhcmF0ZSB0d28gdGhpbmdzOg0KPj4gPj4N Cj4+ID4+IDEpIFdoZXRoZXIgdGhlIGF0dHJpYnV0ZSB2YWx1ZSBuZWVkcyB0byBiZSBhcHBsaWVk IHRvIGFsbCBtLSBzZWN0aW9ucw0KPj4gPj4gMikgV2hldGhlciB0aGUgYXR0cmlidXRlIG5lZWRz IHRvIGJlIGV4cGxpY2l0bHkgYXNzaWduZWQvZW5jb2RlZCB0bw0KPj4gPj5hbGwNCj4+ID4+bS0g c2VjdGlvbnMNCj4+ID4+DQo+PiA+PiBJbiBteSBvcGluaW9uLCBkcmFmdC1tdXgtYXR0cmlidXRl cyBzaGFsbCBvbmx5IGNvdmVyIDEpLg0KPj4gPj4NCj4+ID4+IDIpIGlzIEJVTkRMRSBzcGVjaWZp Yy4NCj4+ID4+DQo+PiA+PiBJIGRvIGFncmVlIHRoYXQgaXQgaXMgYSBsaXR0bGUgZGlmZmljdWx0 IHRvIGRldGVybWluZSB3aGV0aGVyDQo+PiA+Pqn4cmVwZWF0qfcgbWVhbnMgMSkgb3IgMikuDQo+ PiA+DQo+PiA+IEFib3ZlIHdhcyBteSByZWNvbGxlY3Rpb24gdG9vLiBJIGFtIG5vdCBzdXJlIGlm IHdlIG5lZWQgdG8gY2hhbmdlIE11eA0KPj4gPmF0dHJpYnV0ZXMuIFNpbmNlIE11eCBhdHRyaWJ1 dGVzIG5lZWRzIHRvIGJlIHJlYWQgYWxvbmcgd2l0aCB0aGUgQnVuZGxlDQo+PiA+c3BlYy4NCj4+ ID4gVGhlIEJ1bmRsZSBzcGVjIG1heSBkZWZpbmUgYWRkaXRpb25hbCBjb25zdHJhaW50cyBvciB1 c2FnZSBwYXR0ZXJucy4NCj4+DQo+PiBJIGd1ZXNzIGEgbm90ZSBjb3VsZCBoYXZlIGJlZW4gdXNl ZnVsLCBzYXlpbmcgc29tZXRoaW5nIGxpa2U6DQo+Pg0KPj4gqfhOT1RFOiBFdmVudGhvdWdoIElE RU5USUNBTCBhdHRyaWJ1dGVzIG11c3QgYmUgcmVwZWF0ZWQgYWNyb3NzIGFsbA0KPj5tZWRpYSBk ZXNjcmlwdGlvbnMgdW5kZXIgbXVsdGlwbGV4aW5nLCB0aGV5IG1pZ2h0DQo+PiBub3QgYWx3YXlz IGJlIGV4cGxpY2l0bHkgZW5jb2RlZCBhY3Jvc3MgYWxsIG1lZGlhIGRlc2NyaXB0aW9ucy4gQlVO RExFDQo+PmRlZmluZXMgcnVsZXMgZm9yIHdoZW4gYXR0cmlidXRlcyBhbmQgdGhlaXIgdmFsdWVz DQo+PiBhcmUgaW1wbGljaXRseSBhcHBsaWVkIHRvIG1lZGlhIGRlc2NyaXB0aW9uLqn3DQo+Pg0K Pj4gUmVnYXJkcy4NCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+Pg0KPj4NCj4+IFNlbnQgZnJv bSBteSBpUGhvbmUNCj4+DQo+PiBPbiAxIERlYyAyMDE3LCBhdCAxOC4zMCwgQm8gQnVybWFuIDxi by5idXJtYW5AZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+IFdHLA0KPj4NCj4+ IEEgd2hpbGUgYWdvIChpbiB0aGlzIHRocmVhZDoNCj4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvbW11c2ljL3VfX29LQkEzR2lpZVZlZGE4eXlkeUN0dVQ1VQ0KPj4gDQo+ PjxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL21tdXNpYy91X19vS0JBM0dp aWVWZWRhOHl5ZHlDdHVUNVUNCj4+PikNCj4+ICwgVGF5bG9yIGNvbmNsdWRlZCB0aGF0IHRoZQ0K Pj4NCj4+IC1zZHAtbXV4LWF0dHJpYnV0ZXMNCj4+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMvPg0KPj4gZHJhZnQs IHdoaWNoIGlzIGN1cnJlbnRseSBpbiBSRkMgRWRpdG9yqfZzIHF1ZXVlLCBuZWVkcyB0byBiZSB1 cGRhdGVkIHRvDQo+PmFsaWduIHdpdGggY3VycmVudA0KPj4NCj4+IEJVTkRMRQ0KPj4gDQo+Pjxo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtYnVu ZGxlLW5lZ290aWF0aW8NCj4+bi8NCj4+ID4gZHJhZnQuDQo+Pg0KPj4gVGhlIC1zZHAtbXV4LWF0 dHJpYnV0ZXMgZHJhZnQgdW5jb25kaXRpb25hbGx5IHJlcXVpcmVzIChpbiBzZWN0aW9uIDQuMykN Cj4+dGhhdCBjYXRlZ29yeSBJREVOVElDQUwgYXR0cmlidXRlcyBhbmQgdGhlaXINCj4+IHZhbHVl cyCp+E1VU1QgYmUgcmVwZWF0ZWQgYWNyb3NzIGFsbCB0aGUgbWVkaWEgZGVzY3JpcHRpb25zIHVu ZGVyDQo+Pm11bHRpcGxleGluZ6n3Lg0KPj4NCj4+IEJVTkRMRSAoc2VjdGlvbiA4LjEpIHJlcXVp cmVzIHN1Y2ggcmVwZXRpdGlvbiBmb3IgSURFTlRJQ0FMIGFuZA0KPj5UUkFOU1BPUlQgb25seSB3 aGVuIGEgQlVORExFIGdyb3VwIGlzIGluaXRpYWxseQ0KPj4gbmVnb3RpYXRlZC4gV2hlbiB0aGUg QlVORExFIGFkZHJlc3NlcyBoYXZlIGJlZW4gc2VsZWN0ZWQsIGZvciBhbGwgqfhtPan3DQo+PnNl Y3Rpb25zIGJ1dCB0aGUgb25lIGNhcnJ5aW5nIHRoZSBCVU5ETEUtdGFnLA0KPj4gQlVORExFIHJl cXVpcmVzIHRoZSBvcHBvc2l0ZTsgTVVTVCBOT1QgaW5jbHVkZSBTRFAgYXR0cmlidXRlcyB3aXRo DQo+PklERU5USUNBTCBvciBUUkFOU1BPUlQgY2F0ZWdvcnkuDQo+Pg0KPj4gRG9lcyB0aGUgV0cg YWdyZWUgdGhhdCAtc2RwLW11eC1hdHRyaWJ1dGVzIGhhcyB0byBiZSBjaGFuZ2VkIHRvIGFsaWdu DQo+PndpdGggd2hhdCBpcyBub3cgZGVzY3JpYmVkIGJ5IEJVTkRMRT8NCj4+DQo+PiBVbmxlc3Mg YW55b25lIG9iamVjdHMgYmVmb3JlIEVPQiBEZWMgMTUsIHdlIHdpbGwgcHJvY2VlZCB3aXRoIHN1 Y2gNCj4+Y2hhbmdlIHRvIC1zZHAtbXV4LWF0dHJpYnV0ZXMuDQo+Pg0KPj4gVGhhbmtzLA0KPj4N Cj4+IEJvDQo+PiBNTVVTSUMgY28tY2hhaXINCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+ Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPj4gbW11c2ljQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KPj4NCj4+DQo+Pg0KPj4N Cj4+DQo+Pg0KPg0KDQo= From nobody Wed Dec 20 05:45:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DD712DA07 for ; Wed, 20 Dec 2017 05:45:23 -0800 (PST) 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 6h1KadaXwBEX for ; Wed, 20 Dec 2017 05:45:17 -0800 (PST) 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 430CC12AF6E for ; Wed, 20 Dec 2017 05:45:17 -0800 (PST) X-AuditID: c1b4fb3a-335ff700000037f2-61-5a3a696bf256 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.D5.14322.B696A3A5; Wed, 20 Dec 2017 14:45:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Wed, 20 Dec 2017 14:45:15 +0100 From: Christer Holmberg To: Thomas Stach , MMUSIC Thread-Topic: [MMUSIC] 4566bis: media field terminology Thread-Index: AQHTeZbWImZdvRCe0EaYUhyLmvlObKNMUcgA Date: Wed, 20 Dec 2017 13:45:14 +0000 Message-ID: References: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.com> In-Reply-To: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <95A9AEB5DC522A4E9B1CCFD928FD7981@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7gW52plWUwfoHChZTlz9msfh0YiuT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxd/IV9oL9HBU7nm1ga2D8wtbFyMkhIWAi cX3eBSCbi0NI4DCjxKoNT1khnCWMEpPuXGLuYuTgYBOwkOj+pw3SICLgIvHoxQx2EFtYwEzi 45cGVoi4ucS+NWvZIGwjidbG3SwgNouAqsTjZb/B4rwC1hIvz9wA6xUSsJFounGIDWQ8p4Ct RNMTf5Awo4CYxPdTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf2BrRQX0JDacuM0OEVeU +PhqHyNEr47Egt2f2CBsa4mnS7+wQtjaEssWvmaGOEdQ4uTMJywTGMVmIVk3C0n7LCTts5C0 z0LSvoCRdRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYFQd3PLbagfjweeOhxgFOBiVeHhv h1pFCbEmlhVX5h5ilOBgVhLhrf5sGSXEm5JYWZValB9fVJqTWnyIUZqDRUmc1ynNIkpIID2x JDU7NbUgtQgmy8TBKdXAKGrneqo++dO6x3f3HVvIXFGsGxnz7HSE5sG1rc58zZbaL54+mTX9 nay44qX9l0yXd71Y6cHZd2V/9VXfGiPBzdfrJy+S3rq2N5Ozae0t5Q9Ks3U/viq87O7QXnzf zLQp772zaGRLIs/hDSmuX5l+9nlFLhBdnOB4w6Z+Ql1k8YdKEzP76w2tSizFGYmGWsxFxYkA L20+EaYCAAA= Archived-At: Subject: Re: [MMUSIC] 4566bis: media field terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 13:45:24 -0000 Hi, There was a previous discussion about this: https://www.ietf.org/mail-archive/web/mmusic/current/msg18238.html Regards, Christer On 20/12/17 15:31, "mmusic on behalf of Thomas Stach" wrote: >Hi, > >just a quick observation. > >In 5.14 the end of the first para reads: >"A media field has several sub-fields: " > >Wouldn't that have to be >"A "m=3D" line has several sub-fields: " ? > >There are several other occurrences of "media field" in the document, >where sometimes _"m-" line_ and sometimes _media description_ seems to >be more appropriate. > >p.14, 5.6, 3rd para >... before the first media field --> media description >p.21, 1st para >... can also be added before the first media field --> media description >p.22, 2nd para > ... defined in the sub-field of the media field. --> "m-" line > > >Regards >Thomas > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Dec 20 06:03:14 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3BB126CD6; Wed, 20 Dec 2017 06:03:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151377858940.2739.10063455950412489818@ietfa.amsl.com> Date: Wed, 20 Dec 2017 06:03:09 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 14:03:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Using Simulcast in SDP and RTP Sessions Authors : Bo Burman Magnus Westerlund Suhas Nandakumar Mo Zanaty Filename : draft-ietf-mmusic-sdp-simulcast-11.txt Pages : 40 Date : 2017-12-20 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-11 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 20 07:07:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B596124217 for ; Wed, 20 Dec 2017 07:07:52 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 zfiM51Mi6VAQ for ; Wed, 20 Dec 2017 07:07:49 -0800 (PST) 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 31FD91252BA for ; Wed, 20 Dec 2017 07:07:49 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-7e-5a3a7cc25bd0 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.A0.27591.2CC7A3A5; Wed, 20 Dec 2017 16:07:47 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 20 Dec 2017 16:07:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=L7+epqelvS1QsF2xg9c+rxj2Cn+ngRM9uuTLZk3lc9s=; b=dMD22o5r0jwyQPcbdtjS9E2eQ0bgNzHADmajzVKgHGL22CLnNK707aJRA1JZEKDNw09LFPZhZhPAxxo1AYG59vmzs9SpQstbvTfG8rVfZq7am6PBj5MA12pGVA5AC5v07CjwUflKCJtvlY/YrUDJIh6C5MOHOz3eK7mMQjX95LU= Received: from VI1PR07MB3262.eurprd07.prod.outlook.com (10.175.243.144) by VI1PR07MB3262.eurprd07.prod.outlook.com (10.175.243.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Wed, 20 Dec 2017 15:07:45 +0000 Received: from VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::445d:573d:af80:7d92]) by VI1PR07MB3262.eurprd07.prod.outlook.com ([fe80::445d:573d:af80:7d92%13]) with mapi id 15.20.0345.009; Wed, 20 Dec 2017 15:07:45 +0000 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-simulcast-11.txt Thread-Index: AQHTeZtYRpnoeGnaBECmgzbXHex3N6NMUHMg Date: Wed, 20 Dec 2017 15:07:45 +0000 Message-ID: References: <151377858940.2739.10063455950412489818@ietfa.amsl.com> In-Reply-To: <151377858940.2739.10063455950412489818@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bo.burman@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3262; 6:fbWmsgUIZ9NC61BPoJnIGx9+TYPpPvafgqnM2s+yhrSDy8HHelVn3Z3GBttB8l9Yhk83DoYq9VA8bNB0SIx+qUuo95FsJAEX6y0XKNwglU4iLaIiR+NxZk0cJmtRHH6SquVQ8VKQOCyxxbxo+y9PgZtRREUx6ZHxNOWU4Mx7kFKrehVgz8ulOQ+oLL6dvGTmHaYMy8Exccs4YsAt3Le23Q7uCSKusKwL6zULwbz/VBRKKXS6y+OK8gmItXYCSdgQLqgUbm6+e4MTVPmPeeueWrRishlg0k1B6OYl3SH6Boo70j0YBKzqawqnOVJppVy+4BZnth3omXGXSUctg4HhFixIR897Be2O4r59J7Xe6k4=; 5:toMEjftXTRgOyy1TS4OKPv7P0OTuY4xw+5HcNesYufzczYPvXRf1SPWj/g6NldiQFXY2ooknURlhGTvZBWe4sz3VAgUel5QSIvwo50zJUo1lgvEXkKNtMPPAkcEaEnau8Nuijc8KYNz6YqP+d0BOuWwgPJIsgPdpYHRdtRZu4Yc=; 24:buEDhMYkQ58V218yXnOKMSVAV3LywQ6WzcP1KNfroYsprySeMPSxwRavCCI/0eybIqDMAxiCdgCZ45aHSiLE/DhfQFr1a3ScA60ARIubDas=; 7:1UEfuhQWSYJPT5/m0+5EzZ+FFwPvENO2iSEIq5PzQQIrgxbjXpTh+jtTJntLIqyS/s4dokeoTtzr0tP40sNkeUzrtRSaZ7tp/Y6nKXbVSB+i9WwWHFQ8OdYrPlblXmNoN11tUo70hjV4jVJ2lTZur97X01mlEbaGVNdZ5lShrMFZKyET5bPPOkwoAvG4saoW97/SUAvwd1+/ZmDeH4r4CmOEYlAVBTjIvoeUATpXUrMgA88dJsldon5zDEWlISqT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 708975f5-62a5-4794-5613-08d547bb6cd7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:VI1PR07MB3262; x-ms-traffictypediagnostic: VI1PR07MB3262: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR07MB3262; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3262; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(366004)(346002)(39380400002)(189003)(199004)(13464003)(377424004)(105586002)(316002)(6506007)(53546011)(305945005)(7696005)(2906002)(76176011)(7736002)(53936002)(68736007)(5250100002)(99286004)(86362001)(25786009)(2501003)(2351001)(6916009)(6116002)(229853002)(102836003)(3846002)(74316002)(4001150100001)(2950100002)(6306002)(230783001)(9686003)(6436002)(66066001)(14454004)(478600001)(33656002)(966005)(2900100001)(81156014)(97736004)(55016002)(8936002)(5640700003)(5660300001)(1730700003)(3660700001)(8676002)(6246003)(81166006)(3280700002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3262; H:VI1PR07MB3262.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 708975f5-62a5-4794-5613-08d547bb6cd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 15:07:45.2207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3262 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUyM2K7lu7hGqsog4tHuC2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJNTjzIV3JGp2H1pN2MD436xLkZODgkBE4kL35aydjFycQgJ HGaU2LLsHzuEc4JR4s2HBrAMi0Avs8SxmTOhymYySUxcd5QNwnnMKNE7CSTDycEmoCExf8dd RhBbREBd4uveHuYuRg4OYQF7iU2T6iDCDhJNE7rZIGwjibYni8BaWQRUJY7d/8ICYvMKxEgs uX+LHcQWEnCWaPxxmQnE5hRwkbj5sBOsnlFAVuL+93tg9cwC4hK3nsxngvhHQGLJnvPMELao xMvH/6DqIyUmTzzLDhFXkLj/azJUjazEpfndjCC/SAgcYpf4OvEpVJGexNaJbxkhbF+J6/2z oYrWMkocOzsFqkhLYtOBXSwQdrZEx/NLUA3WEicW32SBaFjALNH+eQHUeTISNx5dgko0sUls 2bicbQKj7iwkb0DYOhILdn9ig7C1JZYtfM08Cxw0ghInZz5hWcDIsopRtDi1OCk33chIL7Uo M7m4OD9PLy+1ZBMjMFEc3PLbYAfjy+eOhxgFOBiVeHjzc6yihFgTy4orcw8xSnAwK4nwVn+2 jBLiTUmsrEotyo8vKs1JLT7EKM3BoiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXA2JAqcot3 MaP50sPs88+WuM4+pCyx93a74ucPy0NnHmfNvZ96xyJJsEG909VNZadStXysPa++gdHD/6+j 2nf0TO+f+eV4YdcLi/IVDEo1MpdDZ85YvGbldu/28+GCkiYsUct3zq8KaSi+mGsWIfxtr6D2 mxDTwuLnt5lvHlzJnmkg5RdSYPhLiaU4I9FQi7moOBEAoOVdbxADAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 15:07:52 -0000 The changes in this version are based on discussions and conclusions at IET= F 100 in Singapore (https://datatracker.ietf.org/meeting/100/materials/minu= tes-100-mmusic/): o Added new SDP example section on Simulcast and Redundancy, including both RED (RFC2198), RTP RTX (RFC4588), and FEC (draft- ietf-payload-flexible-fec-scheme). o Removed restriction that "related" payload formats in an RTP stream (such as CN and DTMF) must not have their own rid-id, since there is no reason to forbid this and corresponding clarification is made in draft-ietf-mmusic-rid. o Removed any mention of source-specific signaling and the reference to RFC5576, since draft-ietf-mmusic-rid is not defined for source- specific signaling. o Changed some SDP examples to use a=3Drid restrictions instead of a=3Dimageattr. o Changed reference from the obsoleted RFC 5285 to RFC 8285. Note that there is also an ongoing discussion among the authors to change d= raft-ietf-mmusic-rid accordingly. Cheers, /Bo (as individual) > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in= ternet-drafts@ietf.org > Sent: den 20 december 2017 15:03 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: I-D Action: draft-ietf-mmusic-sdp-simulcast-11.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control WG= of the IETF. >=20 > Title : Using Simulcast in SDP and RTP Sessions > Authors : Bo Burman > Magnus Westerlund > Suhas Nandakumar > Mo Zanaty > Filename : draft-ietf-mmusic-sdp-simulcast-11.txt > Pages : 40 > Date : 2017-12-20 >=20 > Abstract: > In some application scenarios it may be desirable to send multiple > differently encoded versions of the same media source in different > RTP streams. This is called simulcast. This document describes how > to accomplish simulcast in RTP and how to signal it in SDP. The > described solution uses an RTP/RTCP identification method to identify > RTP streams belonging to the same media source, and makes an > extension to SDP to relate those RTP streams as being different > simulcast formats of that media source. The SDP extension consists > of a new media level SDP attribute that expresses capability to send > and/or receive simulcast RTP streams. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-11 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-11 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.= ietf.org/ietf/1shadow-sites.txt From nobody Wed Dec 20 08:20:36 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230BB1242F7 for ; Wed, 20 Dec 2017 08:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8A8k01AYRsp for ; Wed, 20 Dec 2017 08:20:33 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 EB7541200FC for ; Wed, 20 Dec 2017 08:20:32 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id j124so24691544lfg.2 for ; Wed, 20 Dec 2017 08:20:32 -0800 (PST) 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-transfer-encoding:content-language; bh=CDjEcvbdCDYrrO354cql7tP0jKnhWgoU8xeq5e44OG8=; b=sMqa7AjL3C+fnKEO9JQDYUy0NfaPvFAYs8i/AeArwI08mwIxaoMur308oGwTnYfG6P 0QfTGuKuyDR+2KDh7R7WEfD8F8n/e1T4SVzDRdiXYBdA/5mK6oSEb0T6KBsDn4E901CB tEOKBStOWpZK51XPASpRV6FDoeggvYhslHi1xPmMDBNvdtY3R5/fc0QD1rwZlGH1PP+5 x0c8Eu9AqAgE9DEaKkMppKA2EYGTy76Q9UgXONpRMr8Ks7bOU88RQ0n6AIzJUxhR8RIQ ze9cx8YuN08f9DFZHtSaIbl2qtBMG4iHPzExeJG8U5t7llpW0K2KVbx5VZPP733xKz+R j1sQ== 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-transfer-encoding :content-language; bh=CDjEcvbdCDYrrO354cql7tP0jKnhWgoU8xeq5e44OG8=; b=Uzgy7Ut8YV7+nsYJzNCLrS0sxCFPmHlw+k8Pjo8PqRb0bW5BfNAb0O8//tGjYKlhqf 0wQ1s5QtlMK9S2GM7rdQ4yz1Ytm6+HXMiLwaUf89ADaPolbCcKVSnd5lYBTOiomy2icq y0tbhwQ1gBsrafC6x/ORC+3mo4zBOkVURN29GeYZMxfPxblFb3ynZ7tijN5c2/oOgRLJ +67UIf7sn/ZC6XVv7o9bE5SLxXUvxBspQG+RyEQQTyrdNyZJRmn71HXk1/BKh9hyWGWS Izze9zQSQD92DsK4e8Oa+7Dn9bgxz9c1CoxOC0alLMROtR7SH0pIQ9LJSVYkthmiCFsU Fbkw== X-Gm-Message-State: AKGB3mKM2GOublST3+IHwsdR45aTYib5vgp8uYkJW+ijeGeddPl2zK5u dtdlzaeZxHpynrminr0T+gaIu6uS X-Google-Smtp-Source: ACJfBosS/gmursaQ/DX/Goc6Ab/SVX91jwfzMtMsRmU+Qq9mY+JY4q5MA3q00smMWAx+N0b/NnS1vA== X-Received: by 10.25.217.70 with SMTP id q67mr642269lfg.54.1513786830913; Wed, 20 Dec 2017 08:20:30 -0800 (PST) Received: from [192.168.2.104] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id g74sm3692003lje.52.2017.12.20.08.20.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 08:20:30 -0800 (PST) To: Christer Holmberg , MMUSIC References: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.com> From: Thomas Stach Message-ID: Date: Wed, 20 Dec 2017 17:20:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: [MMUSIC] 4566bis: media field terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 16:20:35 -0000 Christer, while your issue seems to be resolved in -24 my issue is different. I think -24 is not clear in the usage of  terminology for "m=" line, media description, media field (Is the thing from the first line in 5.14 meant?. Is this thing a "media field" or a "media sub-field"). In the meantime, I recognized that in the grammar in section 9 there is a "media-field" (with dash), which seems to be the equivalent to a "m-" line(?). In this "media-field" thing there is a "media" field (or sub-field?). Is this "media-field" thing (with dash) meant by "media field" (without dash ) in 5.14? If so, the language needs to be made consistent and a cross-ref to the grammar section would be worthwhile. I can guess the answers to the above questions, but believe the usage of terminology in  5.14 is at least unfortunate, if not confusing. BTW: I didn't check the other sections 5.x for similar weirdness. Regards Thomas On 2017-12-20 14:45, Christer Holmberg wrote: > Hi, > > There was a previous discussion about this: > > https://www.ietf.org/mail-archive/web/mmusic/current/msg18238.html > > > Regards, > > Christer > > > On 20/12/17 15:31, "mmusic on behalf of Thomas Stach" > wrote: > >> Hi, >> >> just a quick observation. >> >> In 5.14 the end of the first para reads: >> "A media field has several sub-fields:" >> >> Wouldn't that have to be >> "A "m=" line has several sub-fields: " ? >> >> There are several other occurrences of "media field" in the document, >> where sometimes _"m-" line_ and sometimes _media description_ seems to >> be more appropriate. >> >> p.14, 5.6, 3rd para >> ... before the first media field --> media description >> p.21, 1st para >> ... can also be added before the first media field --> media description >> p.22, 2nd para >> ... defined in the sub-field of the media field. --> "m-" line >> >> >> Regards >> Thomas >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Dec 20 08:22:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01FF1242F7 for ; Wed, 20 Dec 2017 08:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 462aX6LsjUyY for ; Wed, 20 Dec 2017 08:22:18 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 415EC1200FC for ; Wed, 20 Dec 2017 08:22:18 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id n9so7082406ual.13 for ; Wed, 20 Dec 2017 08:22:18 -0800 (PST) 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=azRyE/TuYmkzs+Zpj60qgWGLqSx2VoGTyULWtzdxS5Q=; b=XISeRInuy7C6jkdFMU6zBAVYyMZZ83hDGCJEM/nMnXeyNh8nQ+pU032h78d76KClcT dN7O+GDFGwGC8jHadQSWIIHsfFmYG7/3rQqXxeURkXri+HW9qoijN9uoVMawzdzrCFZE vpqUjjjNv0SexiK4d8AdI7glKYsPrNf5haaaDZfyhjlyyJXd/4cEQ+Vf46zsC3fXS2/3 x+B/zy5nzLJ7F4NRW3pJ0NDig/NxU02M7aPy/JpBSBhCSHWVeGOkUWriY85VPdXfg9K/ p4EiZ83mok9wQtW36+xW6niFXqyUOtrOsLD8QPZqr9h5LQy38sgOUDuRZ3hP80Upx8HV N1rQ== 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=azRyE/TuYmkzs+Zpj60qgWGLqSx2VoGTyULWtzdxS5Q=; b=Jj1y2B1oQUPDQv8LnxrJIt+PwFoo2FfKEeitwfsqvprZ5IWKkdzgS6n4fIwLmef8H4 biHgmB27VXCuv7+Q8KDzk9cUaEjmKGlq5PP7rdFM+HRfpqTbiyAogiHUKT8FzFuzHM8i L39qdFxK5ZTjZk7LaWXK1vt366/fmOMHCRJv7EpjyiGKzfdYxvURxWkiZenXIIoktX0g 7mVx6/N66c9hLNDiN0fMLAT/vYHcd9DbI8b1dFh5Lj+uS2cnE8XvYH730faJA6SXM7SE zMY4m8DmgqV/pQaw7iRpHJmmfqYd4S6230UvxAXRZ/fzBF1wiGaC7YVpanvs0AaBS1Wb JyJg== X-Gm-Message-State: AKGB3mKoa9f5oAuBrygYoPotpj0e9rWO7gYNe1PbyY72AMW0kclFR5tL HCugIF+yl4NP0L36xhGMhlNIH1uSkyEooa+qRr4= X-Google-Smtp-Source: ACJfBouMvgGXZnXKrVTUast6McdeBTjOFd2r1i0P1LtF7eomuwGdjVVz1ZU+8YmvXKJ8TJh58Y5FZ7h39U1JSQxGPrI= X-Received: by 10.176.17.199 with SMTP id q7mr8335026uac.49.1513786937263; Wed, 20 Dec 2017 08:22:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.239 with HTTP; Wed, 20 Dec 2017 08:22:16 -0800 (PST) In-Reply-To: References: From: Suhas Nandakumar Date: Wed, 20 Dec 2017 08:22:16 -0800 Message-ID: To: Christer Holmberg Cc: Bo Burman , Ben Campbell , "draft-ietf-mmusic-sdp-mux-attributes@tools.ietf.org" , IETF MMUSIC WG Content-Type: multipart/alternative; boundary="f403045d7a24a959830560c7fc8b" Archived-At: Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align with BUNDLE? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 16:22:21 -0000 --f403045d7a24a959830560c7fc8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am fine with the note if it is helping bring clarity. so +1 On Wed, Dec 20, 2017 at 5:41 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >So, to be clear, you suggest to add such note to the -sdp-mux-attributes > >draft? > > Yes. > > Regards, > > Christer > > > > > > >> -----Original Message----- > >> From: Christer Holmberg > >> Sent: den 5 december 2017 10:35 > >> To: Suhas Nandakumar > >> Cc: Bo Burman ; Ben Campbell = ; > >>draft-ietf-mmusic-sdp-mux- > >> attributes@tools.ietf.org; IETF MMUSIC WG > >> Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to align > >>with BUNDLE? > >> > >> Hi, > >> > >> >> As I believe I have said before, we need to separate two things: > >> >> > >> >> 1) Whether the attribute value needs to be applied to all m- sectio= ns > >> >> 2) Whether the attribute needs to be explicitly assigned/encoded to > >> >>all > >> >>m- sections > >> >> > >> >> In my opinion, draft-mux-attributes shall only cover 1). > >> >> > >> >> 2) is BUNDLE specific. > >> >> > >> >> I do agree that it is a little difficult to determine whether > >> >>=C2=B3repeat=C2=B2 means 1) or 2). > >> > > >> > Above was my recollection too. I am not sure if we need to change Mu= x > >> >attributes. Since Mux attributes needs to be read along with the Bund= le > >> >spec. > >> > The Bundle spec may define additional constraints or usage patterns. > >> > >> I guess a note could have been useful, saying something like: > >> > >> =C2=B3NOTE: Eventhough IDENTICAL attributes must be repeated across al= l > >>media descriptions under multiplexing, they might > >> not always be explicitly encoded across all media descriptions. BUNDLE > >>defines rules for when attributes and their values > >> are implicitly applied to media description.=C2=B2 > >> > >> Regards. > >> > >> Christer > >> > >> > >> > >> > >> Sent from my iPhone > >> > >> On 1 Dec 2017, at 18.30, Bo Burman wrote: > >> > >> > >> > >> WG, > >> > >> A while ago (in this thread: > >> https://mailarchive.ietf.org/arch/msg/mmusic/u__ > oKBA3GiieVeda8yydyCtuT5U > >> > >> oKBA3GiieVeda8yydyCtuT5U > >>>) > >> , Taylor concluded that the > >> > >> -sdp-mux-attributes > >> > > >> draft, which is currently in RFC Editor=C2=B9s queue, needs to be upda= ted to > >>align with current > >> > >> BUNDLE > >> > >> bundle-negotiatio > >>n/ > >> > draft. > >> > >> The -sdp-mux-attributes draft unconditionally requires (in section 4.3= ) > >>that category IDENTICAL attributes and their > >> values =C2=B3MUST be repeated across all the media descriptions under > >>multiplexing=C2=B2. > >> > >> BUNDLE (section 8.1) requires such repetition for IDENTICAL and > >>TRANSPORT only when a BUNDLE group is initially > >> negotiated. When the BUNDLE addresses have been selected, for all =C2= =B3m=3D=C2=B2 > >>sections but the one carrying the BUNDLE-tag, > >> BUNDLE requires the opposite; MUST NOT include SDP attributes with > >>IDENTICAL or TRANSPORT category. > >> > >> Does the WG agree that -sdp-mux-attributes has to be changed to align > >>with what is now described by BUNDLE? > >> > >> Unless anyone objects before EOB Dec 15, we will proceed with such > >>change to -sdp-mux-attributes. > >> > >> Thanks, > >> > >> Bo > >> MMUSIC co-chair > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > >> > >> > >> > >> > >> > >> > > > > --f403045d7a24a959830560c7fc8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am fine with the note if it is helping bring clarity. so= +1=C2=A0

On Wed, = Dec 20, 2017 at 5:41 AM, Christer Holmberg <christer.holmberg= @ericsson.com> wrote:
Hi,
>So, to be clear, you suggest to add such note to the -sdp-mux-attribute= s
>draft?

Yes.

Regards,

Christer





>> -----Original Message-----
>> From: Christer Holmberg
>> Sent: den 5 december 2017 10:35
>> To: Suhas Nandakumar <su= hasietf@gmail.com>
>> Cc: Bo Burman <bo.bur= man@ericsson.com>; Ben Campbell <ben@nostrum.com>;
>>draft-ietf-mmusic-sdp-mux-
>> attributes@tools.ietf= .org; IETF MMUSIC WG <mmusic@ietf= .org>
>> Subject: Re: [MMUSIC] Change of -sdp-mux-attributes needed to alig= n
>>with BUNDLE?
>>
>> Hi,
>>
>> >> As I believe I have said before, we need to separate two = things:
>> >>
>> >> 1) Whether the attribute value needs to be applied to all= m- sections
>> >> 2) Whether the attribute needs to be explicitly assigned/= encoded to
>> >>all
>> >>m- sections
>> >>
>> >> In my opinion, draft-mux-attributes shall only cover 1).<= br> >> >>
>> >> 2) is BUNDLE specific.
>> >>
>> >> I do agree that it is a little difficult to determine whe= ther
>> >>=C2=B3repeat=C2=B2 means 1) or 2).
>> >
>> > Above was my recollection too. I am not sure if we need to ch= ange Mux
>> >attributes. Since Mux attributes needs to be read along with t= he Bundle
>> >spec.
>> > The Bundle spec may define additional constraints or usage pa= tterns.
>>
>> I guess a note could have been useful, saying something like:
>>
>> =C2=B3NOTE: Eventhough IDENTICAL attributes must be repeated acros= s all
>>media descriptions under multiplexing, they might
>> not always be explicitly encoded across all media descriptions. BU= NDLE
>>defines rules for when attributes and their values
>> are implicitly applied to media description.=C2=B2
>>
>> Regards.
>>
>> Christer
>>
>>
>>
>>
>> Sent from my iPhone
>>
>> On 1 Dec 2017, at 18.30, Bo Burman <bo.burman@ericsson.com> wrote:
>>
>>
>>
>> WG,
>>
>> A while ago (in this thread:
>> https://mailarchive= .ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U
>>
>><https://mailarch= ive.ietf.org/arch/msg/mmusic/u__oKBA3GiieVeda8yydyCtuT5U
>>>)
>> , Taylor concluded that the
>>
>> -sdp-mux-attributes
>> <https://datatrack= er.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/>
>> draft, which is currently in RFC Editor=C2=B9s queue, needs to be = updated to
>>align with current
>>
>> BUNDLE
>>
>><https://datatrac= ker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiatio
>>n/
>> > draft.
>>
>> The -sdp-mux-attributes draft unconditionally requires (in section= 4.3)
>>that category IDENTICAL attributes and their
>> values =C2=B3MUST be repeated across all the media descriptions un= der
>>multiplexing=C2=B2.
>>
>> BUNDLE (section 8.1) requires such repetition for IDENTICAL and >>TRANSPORT only when a BUNDLE group is initially
>> negotiated. When the BUNDLE addresses have been selected, for all = =C2=B3m=3D=C2=B2
>>sections but the one carrying the BUNDLE-tag,
>> BUNDLE requires the opposite; MUST NOT include SDP attributes with=
>>IDENTICAL or TRANSPORT category.
>>
>> Does the WG agree that -sdp-mux-attributes has to be changed to al= ign
>>with what is now described by BUNDLE?
>>
>> Unless anyone objects before EOB Dec 15, we will proceed with such=
>>change to -sdp-mux-attributes.
>>
>> Thanks,
>>
>> Bo
>> MMUSIC co-chair
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmus= ic
>>
>>
>>
>>
>>
>>
>


--f403045d7a24a959830560c7fc8b-- From nobody Thu Dec 21 00:06:32 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C627120227 for ; Thu, 21 Dec 2017 00:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 oq6cOeVFYxlG for ; Thu, 21 Dec 2017 00:06:29 -0800 (PST) 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 370B71200FC for ; Thu, 21 Dec 2017 00:06:29 -0800 (PST) X-AuditID: c1b4fb2d-f179c9c000007932-34-5a3b6b831605 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.F6.31026.38B6B3A5; Thu, 21 Dec 2017 09:06:27 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Thu, 21 Dec 2017 09:06:25 +0100 From: Christer Holmberg To: Thomas Stach , MMUSIC Thread-Topic: [MMUSIC] 4566bis: media field terminology Thread-Index: AQHTeZbWImZdvRCe0EaYUhyLmvlObKNMUcgAgAAHLYCAASyIAA== Date: Thu, 21 Dec 2017 08:06:25 +0000 Message-ID: References: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.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.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <82D027E8C8610A4EB8C4805840627744@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7uG5ztnWUwc6/4hZTlz9msfh0YiuT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx9CVLwW+Bih/bb7A2MJ7i7WLk5JAQMJHY v+IHexcjF4eQwGFGiSffbzJCOEsYJWacf8rWxcjBwSZgIdH9TxukQUTAReLRixnsILawgJnE xy8NrBBxc4l9a9ayQdhOErsbrzKD2CwCqhIzdh9lBLF5BawlDi87wQQxfyGjxM/2tcwg8zkF bCU6lkqD1DAKiEl8P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv4HtldUQE9iw4nb7BBx RYmPr/YxQvTqSdyYOgXsfGagvd8vcEOEtSWWLXzNDHGOoMTJmU9YJjCKzUKybRaS7lkI3bOQ dM9C0r2AkXUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBEHdzyW3cH4+rXjocYBTgYlXh4 e7Oso4RYE8uKK3MPMUpwMCuJ8FZ/towS4k1JrKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9 sSQ1OzW1ILUIJsvEwSnVwOjg0axicEVA8ZNQ9PHvS7u92GwDGhXnthVdbm2+5KNt3mqrfWx5 4qYz6jP4xWIZgvt1j9fnuYY7ce1VKtI7FxPwPj385jXeCpvcrM8/jnzctTBX7NC0h6cqmJ1O /Vaede9jy/3kQ9oP15xcvPdlQ/oLi/38Ecf2VU9JVty1je28UJOZ/eSLy5RYijMSDbWYi4oT AXgV5AWkAgAA Archived-At: Subject: Re: [MMUSIC] 4566bis: media field terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:06:31 -0000 Hi, >while your issue seems to be resolved in -24 my issue is different. > >I think -24 is not clear in the usage of terminology for >"m=3D" line, media description, media field (Is the thing from the >first line in 5.14 meant?. >Is this thing a "media field" or a "media sub-field"). > >In the meantime, I recognized that in the grammar in section 9 there is >a "media-field" (with dash), >which seems to be the equivalent to a "m-" line(?). >In this "media-field" thing there is a "media" field (or sub-field?). >Is this "media-field" thing (with dash) meant by "media field" (without >dash ) in 5.14? >If so, the language needs to be made consistent and a cross-ref to the >grammar section would be worthwhile. I don=B9t think we need =B3media field=B2 in the normative text, because I = think it is equivalent to =B3m=3D=B3 line. Regards, Christer >On 2017-12-20 14:45, Christer Holmberg wrote: >> Hi, >> >> There was a previous discussion about this: >> >> https://www.ietf.org/mail-archive/web/mmusic/current/msg18238.html >> >> >> Regards, >> >> Christer >> >> >> On 20/12/17 15:31, "mmusic on behalf of Thomas Stach" >> wrote: >> >>> Hi, >>> >>> just a quick observation. >>> >>> In 5.14 the end of the first para reads: >>> "A media field has several sub-fields:" >>> >>> Wouldn't that have to be >>> "A "m=3D" line has several sub-fields: " ? >>> >>> There are several other occurrences of "media field" in the document, >>> where sometimes _"m-" line_ and sometimes _media description_ seems to >>> be more appropriate. >>> >>> p.14, 5.6, 3rd para >>> ... before the first media field --> media description >>> p.21, 1st para >>> ... can also be added before the first media field --> media >>>description >>> p.22, 2nd para >>> ... defined in the sub-field of the media field. --> "m-" >>>line >>> >>> >>> Regards >>> Thomas >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> > From nobody Thu Dec 21 00:51:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3792124207 for ; Thu, 21 Dec 2017 00:51:21 -0800 (PST) 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 UxJ6nc7Bno8f for ; Thu, 21 Dec 2017 00:51:18 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3052E1200FC for ; Thu, 21 Dec 2017 00:51:18 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id c19so7099062lfg.3 for ; Thu, 21 Dec 2017 00:51:18 -0800 (PST) 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-transfer-encoding:content-language; bh=fr3jofvzTeun7jmC0++DxZNqUQmpELrVLxTO3FBflsM=; b=FsgeiLCaTT+vQDeauPaEY4JXQ6ijGUJguurlhZO3uMCQpjmp9L3kYjQKycTPdvEqO9 Ry7oVmBrvedcqQxQc8bmEdLS/KD7iY/yW14NdYzgV0n6I7a4oCUZQFUZIleNUiDXqg7h HLBso2mDyC+0SQLpHBd7MFXmVp/Gwv7riGfMZKKrDDpN4EfZcx0uPH1fAlgz+c5aKzps e3xD6iOqCRqQ2u/iOQnDu0A5DD68+FdxQACtDaXC+F3KGEnpy8E/sXrRE3ZqNJyl3d9q TCrkL/GyL2QnYGmCdvuKhbhH0lNjzzv27Bzvf0hKpZtXNrhHbvxreOGTd4ruparpUQ5S KM0w== 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-transfer-encoding :content-language; bh=fr3jofvzTeun7jmC0++DxZNqUQmpELrVLxTO3FBflsM=; b=N62LLpW/TgHwB+zKBLVFW44C0WrHU35o2W1yiNrg4AvosgfwK80q/0QIwLtZXELdZt 4IxiZfzEctKL+9ZjcjYM414CUMUGYO+4Ya2bkx3QUlCF4nl/wioyKfH7TsFuDrr6B0j1 jhAT2Fn17ZqeQhRiPr8/OkD4JLzDQSkNOCAnwO32Qe8vHjO2iv0bjkFxg5BdAF3lXf9a sHjl6uaKcWvN1xc5F53yL8Kghe0L0W0f8yFyjKKZgXVeQGK08F2A6COWYOTF9hyHBQvm ihCcfMJ7XNN6KeNIKvKmaK320Cw+a+88Lx0pe0swCBgZFeNw4uToEKjObcw23V3nPGVD zJqA== X-Gm-Message-State: AKGB3mIqNueAdvyzkxVG+RRBwlahbelmev5x9lILzGqlxSqAxKzomIwC w1WgmW+vXa58gSCrrAjybYP6b/a1 X-Google-Smtp-Source: ACJfBotmkCQnl92mnToQ6asuwXVkDCqr2hJVcGl1i4AT/YZ97pKvwPQ845yDvbHEL1ZhUGL3YZzl7Q== X-Received: by 10.46.43.86 with SMTP id q83mr6254054lje.104.1513846276130; Thu, 21 Dec 2017 00:51:16 -0800 (PST) Received: from [192.168.2.104] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id w7sm3874489ljd.95.2017.12.21.00.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 00:51:15 -0800 (PST) To: Christer Holmberg , MMUSIC References: <35c1dc30-5ccb-77e5-800d-2d7c0b56d00c@gmail.com> From: Thomas Stach Message-ID: <91f5744d-6239-0173-b45e-ce6b0e208414@gmail.com> Date: Thu, 21 Dec 2017 09:51:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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: [MMUSIC] 4566bis: media field terminology X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:51:22 -0000 inline On 2017-12-21 09:06, Christer Holmberg wrote: > Hi, > >> while your issue seems to be resolved in -24 my issue is different. >> >> I think -24 is not clear in the usage of terminology for >> "m=" line, media description, media field (Is the thing from the >> first line in 5.14 meant?. >> Is this thing a "media field" or a "media sub-field"). >> >> In the meantime, I recognized that in the grammar in section 9 there is >> a "media-field" (with dash), >> which seems to be the equivalent to a "m-" line(?). >> In this "media-field" thing there is a "media" field (or sub-field?). >> Is this "media-field" thing (with dash) meant by "media field" (without >> dash ) in 5.14? >> If so, the language needs to be made consistent and a cross-ref to the >> grammar section would be worthwhile. > I don¹t think we need ³media field² in the normative text, because I think > it is equivalent to ³m=³ line. That's what I'd prefer as well together with the substitutions from my initial post (below) Regards Thomas > > Regards, > > Christer > > > > >> On 2017-12-20 14:45, Christer Holmberg wrote: >>> Hi, >>> >>> There was a previous discussion about this: >>> >>> https://www.ietf.org/mail-archive/web/mmusic/current/msg18238.html >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> On 20/12/17 15:31, "mmusic on behalf of Thomas Stach" >>> wrote: >>> >>>> Hi, >>>> >>>> just a quick observation. >>>> >>>> In 5.14 the end of the first para reads: >>>> "A media field has several sub-fields:" >>>> >>>> Wouldn't that have to be >>>> "A "m=" line has several sub-fields: " ? >>>> >>>> There are several other occurrences of "media field" in the document, >>>> where sometimes _"m-" line_ and sometimes _media description_ seems to >>>> be more appropriate. >>>> >>>> p.14, 5.6, 3rd para >>>> ... before the first media field --> media description >>>> p.21, 1st para >>>> ... can also be added before the first media field --> media >>>> description >>>> p.22, 2nd para >>>> ... defined in the sub-field of the media field. --> "m-" >>>> line >>>> >>>> >>>> Regards >>>> Thomas >>>> >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Dec 22 13:35:37 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C88161241F5; Fri, 22 Dec 2017 13:35:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151397853677.11984.12124797956820733188@ietfa.amsl.com> Date: Fri, 22 Dec 2017 13:35:36 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 21:35:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : A Session Initiation Protocol (SIP) usage for Trickle ICE Authors : Emil Ivov Thomas Stach Enrico Marocco Christer Holmberg Filename : draft-ietf-mmusic-trickle-ice-sip-12.txt Pages : 45 Date : 2017-12-22 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-12 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-12 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 Dec 22 13:39:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE34127136 for ; Fri, 22 Dec 2017 13:39:13 -0800 (PST) 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, 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=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 ePFLFU-3hdr7 for ; Fri, 22 Dec 2017 13:39:10 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28341241F5 for ; Fri, 22 Dec 2017 13:39:09 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id i11so23825441wmf.4 for ; Fri, 22 Dec 2017 13:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=/opRQNT6leaKXakWZ5GebXYJc6HQBtksKiCyBSYJPtA=; b=qFOTPr6/5J+Ns2VVGDJ+Hj/p2FBzkdDxMwAsVi7e1KyIKbwOQQmRtChgcpTJLVZKgJ 3oYDmPl2BNI3lVlTy7W15zCWqVy2hlCLW9Si+SARMUgrUOrvxzKSCElAjRcqr31H05Av oPqvTNUVA49uYZUFtUgnr6anDQBGY2GkxLajHSNxB9ZNF9cvAFio+2Z4q/5G1/PCUwyD lLiL1mI7/FzU3JT94cYWguAn7Huy6xGGqg2LU03eFPEHBIVmm6iG7bsQkw1/2IXspvvl bXu2VvkEoWDlxyP2AYYaueAnvYe78AdzA/Q3beros4Y3DSG9siKbgdzfNh2jwSgjne/5 MZpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/opRQNT6leaKXakWZ5GebXYJc6HQBtksKiCyBSYJPtA=; b=gADOdlZVJYtWy2IAWSzr6YjGLKI4LfVt2gGiZbAdiyxgIRSK2R6PcGZlPGGGfL9I57 bY4HnZwZL4XSlUEwtYYgE9yfWWCgfeoTvDP3kcO8JQwEag+e2R82/NrtxTwAshEtNNvy U9GLO0x3VLuWjUVjCRRFaoEGOQlF6mcbO1zaf2KhWlutnNWISLPZHpQi1zBopaDmvTIA MP+zmmdiLWXyvFqY2hVvRCnX/sbkFMRklG/mI8dLWccZ6j6E6EgJLeEVIJEO3OspUjMD xIfe7X4t6sHqrhoEFkPmbk7wCbh+DQcrkXmkysr6lWcb5Btoj2kTYCeCjufa0xYcvs3Y I7oA== X-Gm-Message-State: AKGB3mIlzXBzPIPX3XroMxC2P0ITIRHQZcp4h8TFapqidUeTPfE8p/sS llRWeyEPGKhwyoaTF1EAHqU= X-Google-Smtp-Source: ACJfBotrV9K/lbGL+qve7ygTerrSnghLdEitZbCaH/SIg7Ijc5YvHGxQtldt6Q2lOmUgszDOuHkLKw== X-Received: by 10.28.72.9 with SMTP id v9mr14277206wma.102.1513978748219; Fri, 22 Dec 2017 13:39:08 -0800 (PST) Received: from [192.168.2.104] (d91-130-2-54.cust.tele2.at. [91.130.2.54]) by smtp.googlemail.com with ESMTPSA id o107sm32387702wrc.63.2017.12.22.13.39.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Dec 2017 13:39:07 -0800 (PST) References: <151397853699.11984.9244404367924484838.idtracker@ietfa.amsl.com> To: MMUSIC , Ben Campbell , Flemming Andreasen From: Thomas Stach X-Forwarded-Message-Id: <151397853699.11984.9244404367924484838.idtracker@ietfa.amsl.com> Message-ID: <1d992ddc-3853-791f-2bd2-ed8228b1cf8a@gmail.com> Date: Fri, 22 Dec 2017 22:39:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151397853699.11984.9244404367924484838.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------CE619AA7B0C08CEAD5603675" Content-Language: en-US Archived-At: Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 21:39:13 -0000 This is a multi-part message in MIME format. --------------CE619AA7B0C08CEAD5603675 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit All, this update addresses comments from Ben's AD review and from Christer's review as a co-author. Changes from draft-ietf-mmusic-trickle-ice-sip-11 include:    o  addressing comments from Ben Campell's AD review and Christer's       review    o  Numerous editorial improvements/corrections    o  Added [RFC8174] boiler plate and adapted usage of normative       language    o  Clarified terminology ICE modules .vs.  ICE agent    o  Added more detailed OA procedures    o  Corrected default values in m-line and usage of "a=mid:" attribute       explicitly mentioned for offer/answer    o  Removed explicit mentioning of XMPP    o  Added Deployment Considerations section    o  Fixed ref for rfc5245bis Regards Thomas -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-12.txt Date: Fri, 22 Dec 2017 13:35:36 -0800 From: internet-drafts@ietf.org To: Christer Holmberg , Enrico Marocco , Thomas Stach , Emil Ivov A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-12.txt has been successfully submitted by Thomas Stach and posted to the IETF repository. Name: draft-ietf-mmusic-trickle-ice-sip Revision: 12 Title: A Session Initiation Protocol (SIP) usage for Trickle ICE Document date: 2017-12-22 Group: mmusic Pages: 45 URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-12 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-12 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. 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. The IETF Secretariat --------------CE619AA7B0C08CEAD5603675 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit All,

this update addresses comments from Ben's AD review and from Christer's review as a co-author.

Changes from draft-ietf-mmusic-trickle-ice-sip-11 include:
   o  addressing comments from Ben Campell's AD review and Christer's
      review
   o  Numerous editorial improvements/corrections
   o  Added [RFC8174] boiler plate and adapted usage of normative
      language
   o  Clarified terminology ICE modules .vs.  ICE agent
   o  Added more detailed OA procedures
   o  Corrected default values in m-line and usage of "a=mid:" attribute
      explicitly mentioned for offer/answer
   o  Removed explicit mentioning of XMPP
   o  Added Deployment Considerations section
   o  Fixed ref for rfc5245bis

Regards
Thomas


-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-12.txt
Date: Fri, 22 Dec 2017 13:35:36 -0800
From: internet-drafts@ietf.org
To: Christer Holmberg <christer.holmberg@ericsson.com>, Enrico Marocco <enrico.marocco@telecomitalia.it>, Thomas Stach <thomass.stach@gmail.com>, Emil Ivov <emcho@jitsi.org> 


A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-12.txt
has been successfully submitted by Thomas Stach and posted to the
IETF repository.

Name:		draft-ietf-mmusic-trickle-ice-sip
Revision:	12
Title:		A Session Initiation Protocol (SIP) usage for Trickle ICE
Document date:	2017-12-22
Group:		mmusic
Pages:		45
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-12.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-12
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-12
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-12

Abstract:
   The Interactive Connectivity Establishment (ICE) protocol describes a
   Network Address Translator (NAT) traversal mechanism for UDP-based
   multimedia sessions established with the Offer/Answer model.  The ICE
   extension for Incremental Provisioning of Candidates (Trickle ICE)
   defines a mechanism that allows ICE Agents to shorten session
   establishment delays by making the candidate gathering and
   connectivity checking phases of ICE non-blocking and by executing
   them in parallel.

   This document defines usage semantics for Trickle ICE with the
   Session Initiation Protocol (SIP) and defines a new SIP Info Package.

                                                                                  


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.

The IETF Secretariat
--------------CE619AA7B0C08CEAD5603675-- From nobody Mon Dec 25 01:41:46 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C881200F1; Mon, 25 Dec 2017 01:41:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151419490141.6885.2420498489309827599@ietfa.amsl.com> Date: Mon, 25 Dec 2017 01:41:41 -0800 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Dec 2017 09:41:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Roni Even Filename : draft-ietf-mmusic-data-channel-sdpneg-16.txt Pages : 42 Date : 2017-12-25 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP (Stream Control Transmission Protocol), where each data channel might be used to transport other protocols, called subprotocols. Data channel setup can be done using either the in- band Data Channel Establishment Protocol (DCEP) or using some out-of- band non-DCEP protocol. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve such an out-of-band non-DCEP negotiation. Even though data channels are designed for RTCWeb use initially, they may be used by other protocols like, but not limited to, the CLUE protocol (which is defined by the IETF "ControLling mUltiple streams for tElepresence" working group). This document is intended to be used wherever data channels are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-16 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sdpneg-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-16 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/