From nobody Sun Jan 1 02:49: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 74EA11294F0 for ; Sun, 1 Jan 2017 02:49:18 -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 hjRD7WLIhlKZ for ; Sun, 1 Jan 2017 02:49:17 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19A61294BC for ; Sun, 1 Jan 2017 02:49:16 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id d45so202481052qta.1 for ; Sun, 01 Jan 2017 02:49: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:content-transfer-encoding; bh=s5ui/yFiIC57U3Uw290hYEXq3Opfq+0pqT38tdEHXCw=; b=hhlEeCwxZqXU3IArJ1zrfZQOeHsMFFXb4HQiCPaIK92Xx08Uur9XOg6qmGs0wWN0PV e8sr4SXYWzMf7xk891Foyh8Z7ZGmDKmjXSUfKbYe8h8zygez+5nz9tBOoQ4N7Qk+Lxba MqzaA8s2/dmsp5Y7JC+jgITwDlwV7+FsA83lpG66dwse+/Vs19pY+KiSgw1KuguoxXxG JuNBQOb+W/TJlyDdfr9UQ64UZlQWLUxLFbBgpKNgEDxq2qgyXOU7xvUno1V40HLY4NNc aY3b+SuBE8k3vtPkuxE8Y+1kS/Ty2jrxLrt8cF9PpEegsCnLU6/DghwWlanmLozIgXgN HmWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s5ui/yFiIC57U3Uw290hYEXq3Opfq+0pqT38tdEHXCw=; b=Z2lySmhAD/6ohVtkzPnJ1dYvzKlsrmqXg3xmXeMXsOLMDLO/lou1Zxv5LlllNZl3Hb 0VYBKGZ5ZyCyF1llQv7xyPbqWRBZU44/VbFjVt6buzTV9w28SDO/z50GjYENA5cgiCVI CUyv6nVAeWl9xBMqgS9J0NBme5ItS+fMigieO8AIz1AGI8BycEFmGZF+JZzkYVXzfL9L nXsPHXJdS8rLmb4tASPN0cc2VC5WGGQ6Er2k/fczo975I6jfKisiwaAT/uGCbINrS/Ok l9/0FgaTE0TiGaMpRufVECT/4/X+ruAt5a2FGLosmp/GnrAWrUMf+Cvy6xVejKiCXi2/ Nmhw== X-Gm-Message-State: AIkVDXKHe4CV0C14rkrYJPsxLJQKfXVH+8AT5YdwDLrFJvu0iJvaSs7c2RFD0ffWE7DTpWtH7IzTVZWMfvF5ig== X-Received: by 10.200.35.14 with SMTP id a14mr48887832qta.159.1483267755947; Sun, 01 Jan 2017 02:49:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Sun, 1 Jan 2017 02:49:15 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> From: Martin Thomson Date: Sun, 1 Jan 2017 21:49:15 +1100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Jonathan Lennox \(jonathan@vidyo.com\)" , "mmusic@ietf.org" , "Cullen Jennings \(fluffy@iii.ca\)" Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 10:49:18 -0000 We can remove MD2. MD5 is dead, SHA-1 is in its death throes, but MD2 is merely a (bad) memory. On 30 December 2016 at 22:27, Christer Holmberg wrote: > Hi, > > > > Please note the following: > > > > RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people have a > problem with that? I assume we=E2=80=99ll end up in trouble with the secu= rity folks > if we keep the old RFC=E2=80=A6 > > > > And, considering MD2 is historic, do we even need to mention it in > draft-4572-update anymore? > > > > Regards, > > > > Christer > > > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmb= erg > Sent: 30 December 2016 11:42 > To: mmusic@ietf.org > Cc: Jonathan Lennox (jonathan@vidyo.com) ; Cullen > Jennings (fluffy@iii.ca) > Subject: [MMUSIC] draft-4572-update: Spec contains references to a number= of > obsoleted RFCs > > > > Hi, > > > > The idnits check returns the following for draft-4572-update. > > > > ** Obsolete normative reference: RFC 1319 (ref. '3') (Obsoleted by RFC 61= 49) > > > > ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. > '4') > > > > ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by RFC > 5280) > > > > ** Obsolete normative reference: RFC 4234 (ref. '11') (Obsoleted by RFC > > 5234) > > > > ** Obsolete normative reference: RFC 4288 (ref. '12') (Obsoleted by RFC > > 6838) > > > > ** Obsolete normative reference: RFC 4346 (ref. '13') (Obsoleted by RFC > > 5246) > > > > -- Obsolete informational reference (is this intentional?): RFC 2617 (r= ef. > > '15') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) > > > > -- Obsolete informational reference (is this intentional?): RFC 3525 (r= ef. > > '20') (Obsoleted by RFC 5125) > > > > -- Obsolete informational reference (is this intentional?): RFC 3851 (r= ef. > > '22') (Obsoleted by RFC 5751) > > > > The reason for this is that we used RFC 4572 as base, and did not > change/update the references. > > > > I had a look, and I don=E2=80=99t think there should be any issues in rep= lacing the > current RFCs with the new ones. But, please indicate if you see any issue= s. > > > > Regards, > > > > Christer From nobody Mon Jan 2 01:48: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 47A76129592 for ; Mon, 2 Jan 2017 01:48:41 -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 jrFKwP8hThZN for ; Mon, 2 Jan 2017 01:48:40 -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 A8A7A12950E for ; Mon, 2 Jan 2017 01:48:39 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-48-586a21f56e65 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 52.29.17130.5F12A685; Mon, 2 Jan 2017 10:48:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Mon, 2 Jan 2017 10:48:35 +0100 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" Thread-Index: AQHSYhjBH1X2RC5m+kOKZV1FMA4fiqEk9oZg Date: Mon, 2 Jan 2017 09:48:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF53147@ESESSMB209.ericsson.se> References: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> In-Reply-To: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7oO5XxawIgyPX5C32/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj88E1jAW/eCte7z3L2sA4m7uLkZNDQsBE 4u+EZSxdjFwcQgLrGCUm9C1lg3AWM0qs334cyOHgYBOwkOj+pw1iigi4Scw7lQ7SKywQJnF2 2mxGEFtEIFzi7dQuKNtIYvNkkJmcHCwCKhL7r0xhAmnlFfCVOLDNCSQsJGAn8WZ/DzOIzSlg LzFp31Iwm1FATOL7qTVMIDazgLjErSfzmSDOFJBYsuc8M4QtKvHy8T9WCFtJYsX2S4wQ9ToS C3Z/YoOwtSWWLXwNVs8rIChxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZL LcpMLi7Oz9PLSy3ZxAiMhYNbfqvuYLz8xvEQowAHoxIP74fOzAgh1sSy4srcQ4wSHMxKIrwy clkRQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTDKtPzb fFn82nbNIyv+JPAoVF9Z4Jp1NX/mA0d9PwVt3ucnDkwvNv/X7TR7kYPt3TdZfU0HXpfd9HX+ u13I/tiGYofvL1kVRSoel69QUTjcY+nR4Pt/xo7py3+83W2umJJduezs4T8OiyQ3vZk7s2vK ojaOJ51n0m8+PTPnaXHDh9mVFw9+EOj9rsRSnJFoqMVcVJwIANqytZCBAgAA Archived-At: Subject: Re: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 09:48:41 -0000 Hi Adam, Thanks for your comment! I'll get back to you asap. Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Adam Roach Sent: 29 December 2016 23:16 To: mmusic@ietf.org Subject: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-= only" We've recently come across an issue with the way the "bundle-only"=20 attribute is described in the current document. The current language regard= ing port handling reads: The usage of the 'bundle-only' attribute is only defined for a bundled "m=3D" line with a zero port value, within an offer. Other usage is unspecified. Usually, when we have this kind of language, we still ensure that behavior = is well defined, to help avoid unnecessary interop failures. I see a couple= of different options here: 1. Remove the final sentence and add language saying that creators of SDP MUST NOT include a "bundle-only" attribute in an m-section that has a non-zero port, and that recipients of such SDP {SHOULD,MUST} reject it; or 2. Retain language saying that including a "bundle-only" attribute in a non-zero m-section is unspecified, but add normative language along the lines of: "implementations that receive an m-section with a non-zero port that also contains a 'bundle-only' attribute MUST ignore the {attribute,port}." I don't have a preference between these choices, but I think we do need cla= rity. To be absolutely clear, this feedback is based on actual implementati= on interop failures in the field. This problem is not theoretical. /a _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Jan 2 02:41: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 26873129511 for ; Mon, 2 Jan 2017 02:41:34 -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 ieYdrXGFMEGI for ; Mon, 2 Jan 2017 02:41:32 -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 3A5581294FF for ; Mon, 2 Jan 2017 02:41:31 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-e2-586a2e59d6f4 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id 85.FB.31458.95E2A685; Mon, 2 Jan 2017 11:41:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Mon, 2 Jan 2017 11:41:27 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: draft-4572-update: Spec contains references to a number of obsoleted RFCs Thread-Index: AdJigL/3HmdriiVMRVGMYSdDZzSqOwADa/tQAGF4AYAANAiaQA== Date: Mon, 2 Jan 2017 10:41:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7um6kXlaEwb2d2hYf1v9gtNi/+Dyz xbUz/xgtpi5/zGIx48JUZgdWj52z7rJ7LFnyk8nj8vmPjB63phR4tD27wx7AGsVlk5Kak1mW WqRvl8CVMePMUdaCK9IV33dMY21g/CHVxcjJISFgItH04jBTFyMXh5DAOkaJC0/uMEI4ixkl bp3bCuRwcLAJWEh0/9MGaRAR0JVYdPYBO0gNs8A+Rom/f8+ygCSEBSIkrj1/zAxRFClxph8i LiLgJLHoxAp2EJtFQEXi4YIFrCA2r4CvxKNH7xhBbCGBG4wSr16ng9icAoEScxYtYQOxGQXE JL6fWsMEYjMLiEvcejKfCeJqAYkle84zQ9iiEi8f/2OFsJUkVmy/BHYzs4CmxPpd+hCtihJT uh+yQ6wVlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJS SzYxAuPr4JbfBjsYXz53PMQowMGoxMP7oTMzQog1say4MvcQowQHs5IIb4t6VoQQb0piZVVq UX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjLOu296vzRH51rK8syKd 5YT4nXodxhOTIxZH3ZnrcZSBLeG/nsc+xi/fUq/ZGqt8OadgJ2gWs9fuvC1Py6Y5rrEpyzim Psxe/nnKjM9Ondont+14qWHLPkvjy8NrHUrssZPrGK++kdmy8u+BgLsHkiYrPtH8NOExp5XI JLkXu3fsq01VVl0c1KvEUpyRaKjFXFScCAAbAQtIqwIAAA== Archived-At: Cc: "Jonathan Lennox \(jonathan@vidyo.com\)" , "mmusic@ietf.org" , "Cullen Jennings \(fluffy@iii.ca\)" Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 10:41:34 -0000 SGksDQoNCj5XZSBjYW4gcmVtb3ZlIE1EMi4gIE1ENSBpcyBkZWFkLCBTSEEtMSBpcyBpbiBpdHMg ZGVhdGggdGhyb2VzLCBidXQgTUQyIGlzIG1lcmVseSBhID4oYmFkKSBtZW1vcnkuDQoNClNvLCBt eSBzdWdnZXN0aW9uIGlzIHRvIHJlbW92ZSBhbGwgcmVmZXJlbmNlcyB0byBNRDIgKGluY2x1ZGlu ZyB0aGUgQUJORikgZm9yIG5vdywgYW5kIHdlJ2xsIHRoZW4gc2VlIHdoYXQgdGhlIHNlY3VyaXR5 IGZvbGtzIHNheSBhYm91dCBNRDUgYW5kIFNIQS0xLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCk9uIDMwIERlY2VtYmVyIDIwMTYgYXQgMjI6MjcsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBIaSwNCj4NCj4NCj4NCj4gUGxl YXNlIG5vdGUgdGhlIGZvbGxvd2luZzoNCj4NCj4NCj4NCj4gUkZDIDYxNDksIHdoaWNoIG9ic29s ZXRlcyBSRkMgMTMxOSwgbWFrZXMgTUQyIGhpc3RvcmljLiBEbyBwZW9wbGUgaGF2ZSANCj4gYSBw cm9ibGVtIHdpdGggdGhhdD8gSSBhc3N1bWUgd2XigJlsbCBlbmQgdXAgaW4gdHJvdWJsZSB3aXRo IHRoZSANCj4gc2VjdXJpdHkgZm9sa3MgaWYgd2Uga2VlcCB0aGUgb2xkIFJGQ+KApg0KPg0KPg0K Pg0KPiBBbmQsIGNvbnNpZGVyaW5nIE1EMiBpcyBoaXN0b3JpYywgZG8gd2UgZXZlbiBuZWVkIHRv IG1lbnRpb24gaXQgaW4gDQo+IGRyYWZ0LTQ1NzItdXBkYXRlIGFueW1vcmU/DQo+DQo+DQo+DQo+ IFJlZ2FyZHMsDQo+DQo+DQo+DQo+IENocmlzdGVyDQo+DQo+DQo+DQo+DQo+DQo+IEZyb206IG1t dXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0 ZXIgDQo+IEhvbG1iZXJnDQo+IFNlbnQ6IDMwIERlY2VtYmVyIDIwMTYgMTE6NDINCj4gVG86IG1t dXNpY0BpZXRmLm9yZw0KPiBDYzogSm9uYXRoYW4gTGVubm94IChqb25hdGhhbkB2aWR5by5jb20p IDxqb25hdGhhbkB2aWR5by5jb20+OyBDdWxsZW4gDQo+IEplbm5pbmdzIChmbHVmZnlAaWlpLmNh KSA8Zmx1ZmZ5QGlpaS5jYT4NCj4gU3ViamVjdDogW01NVVNJQ10gZHJhZnQtNDU3Mi11cGRhdGU6 IFNwZWMgY29udGFpbnMgcmVmZXJlbmNlcyB0byBhIA0KPiBudW1iZXIgb2Ygb2Jzb2xldGVkIFJG Q3MNCj4NCj4NCj4NCj4gSGksDQo+DQo+DQo+DQo+IFRoZSBpZG5pdHMgY2hlY2sgcmV0dXJucyB0 aGUgZm9sbG93aW5nIGZvciBkcmFmdC00NTcyLXVwZGF0ZS4NCj4NCj4NCj4NCj4gKiogT2Jzb2xl dGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDEzMTkgKHJlZi4gJzMnKSAoT2Jzb2xldGVkIGJ5 IFJGQyANCj4gNjE0OSkNCj4NCj4NCj4NCj4gICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJl bmNlIHRvIGFuIEluZm9ybWF0aW9uYWwgUkZDOiBSRkMgMTMyMSAocmVmLg0KPiAnNCcpDQo+DQo+ DQo+DQo+ICAgKiogT2Jzb2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDMyODAgKHJlZi4g JzgnKSAoT2Jzb2xldGVkIGJ5IA0KPiBSRkMNCj4gNTI4MCkNCj4NCj4NCj4NCj4gICAqKiBPYnNv bGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNDIzNCAocmVmLiAnMTEnKSAoT2Jzb2xldGVk IGJ5IA0KPiBSRkMNCj4NCj4gICAgICA1MjM0KQ0KPg0KPg0KPg0KPiAgICoqIE9ic29sZXRlIG5v cm1hdGl2ZSByZWZlcmVuY2U6IFJGQyA0Mjg4IChyZWYuICcxMicpIChPYnNvbGV0ZWQgYnkgDQo+ IFJGQw0KPg0KPiAgICAgIDY4MzgpDQo+DQo+DQo+DQo+ICAgKiogT2Jzb2xldGUgbm9ybWF0aXZl IHJlZmVyZW5jZTogUkZDIDQzNDYgKHJlZi4gJzEzJykgKE9ic29sZXRlZCBieSANCj4gUkZDDQo+ DQo+ICAgICAgNTI0NikNCj4NCj4NCj4NCj4gICAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJl ZmVyZW5jZSAoaXMgdGhpcyBpbnRlbnRpb25hbD8pOiBSRkMgMjYxNyAocmVmLg0KPg0KPiAgICAg ICcxNScpIChPYnNvbGV0ZWQgYnkgUkZDIDcyMzUsIFJGQyA3NjE1LCBSRkMgNzYxNiwgUkZDIDc2 MTcpDQo+DQo+DQo+DQo+ICAgLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlz IHRoaXMgaW50ZW50aW9uYWw/KTogUkZDIDM1MjUgKHJlZi4NCj4NCj4gICAgICAnMjAnKSAoT2Jz b2xldGVkIGJ5IFJGQyA1MTI1KQ0KPg0KPg0KPg0KPiAgIC0tIE9ic29sZXRlIGluZm9ybWF0aW9u YWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJGQyAzODUxIChyZWYuDQo+DQo+ ICAgICAgJzIyJykgKE9ic29sZXRlZCBieSBSRkMgNTc1MSkNCj4NCj4NCj4NCj4gVGhlIHJlYXNv biBmb3IgdGhpcyBpcyB0aGF0IHdlIHVzZWQgUkZDIDQ1NzIgYXMgYmFzZSwgYW5kIGRpZCBub3Qg DQo+IGNoYW5nZS91cGRhdGUgdGhlIHJlZmVyZW5jZXMuDQo+DQo+DQo+DQo+IEkgaGFkIGEgbG9v aywgYW5kIEkgZG9u4oCZdCB0aGluayB0aGVyZSBzaG91bGQgYmUgYW55IGlzc3VlcyBpbiANCj4g cmVwbGFjaW5nIHRoZSBjdXJyZW50IFJGQ3Mgd2l0aCB0aGUgbmV3IG9uZXMuIEJ1dCwgcGxlYXNl IGluZGljYXRlIGlmIHlvdSBzZWUgYW55IGlzc3Vlcy4NCj4NCj4NCj4NCj4gUmVnYXJkcywNCj4N Cj4NCj4NCj4gQ2hyaXN0ZXINCg== From nobody Mon Jan 2 04:25:58 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 364F612941D; Mon, 2 Jan 2017 04:25:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148335995721.21823.8686111068523387388.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 04:25:57 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 12:25:57 -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 of the IETF. Title : Connection-Oriented Media Transport over TLS in SDP Authors : Jonathan Lennox Christer Holmberg Filename : draft-ietf-mmusic-4572-update-09.txt Pages : 17 Date : 2017-01-02 Abstract: This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-09 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 Jan 2 05:42: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 A9739129459 for ; Mon, 2 Jan 2017 05:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] 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 HdFha5InHZ2S for ; Mon, 2 Jan 2017 05:42:31 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFAE124281 for ; Mon, 2 Jan 2017 05:42:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id EC29D7C4C18 for ; Mon, 2 Jan 2017 14:42:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkMRseAU0Ziy for ; Mon, 2 Jan 2017 14:42:28 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 058EC7C4C17 for ; Mon, 2 Jan 2017 14:42:27 +0100 (CET) To: mmusic@ietf.org References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> From: Harald Alvestrand Message-ID: <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> Date: Mon, 2 Jan 2017 14:42:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 13:42:32 -0000 Den 22. des. 2016 18:30, skrev Eric Rescorla: > __ > > Okay, I agree that having any rules for what you should offer here > based on what the actual outcome is not the best idea here. I think > the rules should be based on capability and intent. So if you only > are going offer TCP candidates, then you clearly should use TCP/…, > > > I'm going to push on this. If we've already agreed that mismatches are > normal, why should we do that? Wouldn't it be better to just effectively > deprecate this field? > Concur with EKR. This field (the TCP/UDP part of the protocol field) was defined in a way that makes its original purpose (to negotiate profiles) not only impossible while using ICE, but actively harmful, because you end up telling lies in very many cases, so people will have to accept things that don't match reality. Make the world as simple for implementors as possible: Send a fixed string, and accept all strings. From nobody Mon Jan 2 10:04: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 13B91128B38 for ; Mon, 2 Jan 2017 10:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 idSm7U4-impY for ; Mon, 2 Jan 2017 10:04:18 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747EB1200A0 for ; Mon, 2 Jan 2017 10:04:18 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id r204so272504980ywb.0 for ; Mon, 02 Jan 2017 10:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T5bjFR/Qum2XIaLNyQh6XYe8rPcodi8Mw7BRo161j4g=; b=HNlBPdH7M5I02x087CTZ1Ex9yZYTcNRFcBRPPoSei1gV6mUFKn3mfCEivR9FdH7oNC Jz+Yqo/XJGyZcGK84AtU1G+98Nnk2U9Ws6xIFhJRcb25AG3Xmm81ykDabKxgzzfd/Yhq I0nUZSXXIuU/k8m0mghieL8/+aMDnE4Jn2Pf9EarG7Xe/b0qExB7MGx6bhliRhqoC++4 0swd2v/6znC336byh+7Y72sYHBciFUAyjiIsoUOO1t2Jn232YjbgvLUuCx638CyaDDv1 cT+XIPevCf+z0v1f/OJxkvuM373Md/GiUG444vEn9rV9aZx3OUSwJhwsVNnCgckyrKIc fIUg== 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=T5bjFR/Qum2XIaLNyQh6XYe8rPcodi8Mw7BRo161j4g=; b=WqG3DAcGUOd3m/GwZ4ezO2NMn6ThOU7Q2KYZGIWohhfVfP7x9sw0NwjSYDXg97LM2M IbAtULwF5nPLG+LKD58tROZQiIdvPRUko1jr3IXbAGHnl0AiCWbA4pooEKwcTAjDubHi n6D3JERGeCba/DDL+vJlw9u7R7DfXLeIGtbyO8yvpJZvN+aot9ruzM6hKvQFgjU76ddW y1578n+6Cw/ga7TMefMVum1WFGj/NUsZXgIReL8vKHDMBKPG0pAZ/DPB4Qp0/0YWYyQO R/wewleE47V+U0ln6VLHw52HSSWR6pUIW2lNIX7NOBKlglIbTWzyRXg5icsMblcc0R+1 jvMQ== X-Gm-Message-State: AIkVDXJG0KEcojODvLETZZcauAD0Rus1zDX7dGPVx04RdXHHxxhnvCT8WyrGuhOVEJCzEZqsRUlteU5/GiJAAg== X-Received: by 10.129.125.215 with SMTP id y206mr53582195ywc.234.1483380257652; Mon, 02 Jan 2017 10:04:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 2 Jan 2017 10:03:37 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 2 Jan 2017 10:03:37 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11492dfa53575105452061a6 Archived-At: Cc: "Jonathan Lennox \(jonathan@vidyo.com\)" , "mmusic@ietf.org" , "Cullen Jennings \(fluffy@iii.ca\)" Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 18:04:20 -0000 --001a11492dfa53575105452061a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 2, 2017 at 2:41 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >We can remove MD2. MD5 is dead, SHA-1 is in its death throes, but MD2 i= s > merely a >(bad) memory. > > So, my suggestion is to remove all references to MD2 (including the ABNF) > for now, and we'll then see what the security folks say about MD5 and SHA= -1. > Given the threat model here, I think we want to tell people to ignore MD* (i.e., treat it as an unknown hash) and to accept SHA-1 (though perhaps only temporarily). Accordingly, I propose removing MD2 and MD5 from this grammar, but leave SHA-1. -Ekr Regards, > > Christer > > > On 30 December 2016 at 22:27, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > > > > > Please note the following: > > > > > > > > RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people have > > a problem with that? I assume we=E2=80=99ll end up in trouble with the > > security folks if we keep the old RFC=E2=80=A6 > > > > > > > > And, considering MD2 is historic, do we even need to mention it in > > draft-4572-update anymore? > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: 30 December 2016 11:42 > > To: mmusic@ietf.org > > Cc: Jonathan Lennox (jonathan@vidyo.com) ; Cullen > > Jennings (fluffy@iii.ca) > > Subject: [MMUSIC] draft-4572-update: Spec contains references to a > > number of obsoleted RFCs > > > > > > > > Hi, > > > > > > > > The idnits check returns the following for draft-4572-update. > > > > > > > > ** Obsolete normative reference: RFC 1319 (ref. '3') (Obsoleted by RFC > > 6149) > > > > > > > > ** Downref: Normative reference to an Informational RFC: RFC 1321 (re= f. > > '4') > > > > > > > > ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by > > RFC > > 5280) > > > > > > > > ** Obsolete normative reference: RFC 4234 (ref. '11') (Obsoleted by > > RFC > > > > 5234) > > > > > > > > ** Obsolete normative reference: RFC 4288 (ref. '12') (Obsoleted by > > RFC > > > > 6838) > > > > > > > > ** Obsolete normative reference: RFC 4346 (ref. '13') (Obsoleted by > > RFC > > > > 5246) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 2617 > (ref. > > > > '15') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 3525 > (ref. > > > > '20') (Obsoleted by RFC 5125) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 3851 > (ref. > > > > '22') (Obsoleted by RFC 5751) > > > > > > > > The reason for this is that we used RFC 4572 as base, and did not > > change/update the references. > > > > > > > > I had a look, and I don=E2=80=99t think there should be any issues in > > replacing the current RFCs with the new ones. But, please indicate if > you see any issues. > > > > > > > > Regards, > > > > > > > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11492dfa53575105452061a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 2, 2017 at 2:41 AM, Christer Holmberg <christer.holmb= erg@ericsson.com> wrote:
Hi= ,

>We can remove MD2.=C2=A0 MD5 is dead, SHA-1 is in its death throes, but= MD2 is merely a >(bad) memory.

So, my suggestion is to remove all references to MD2 (including the = ABNF) for now, and we'll then see what the security folks say about MD5= and SHA-1.

Given the threat model here= , I think we want to tell people to ignore MD* (i.e., treat it as an unknow= n hash) and to accept SHA-1 (though perhaps only temporarily). Accordingly,= I propose removing MD2 and MD5 from this grammar, but leave SHA-1.

-Ekr


Regards,

Christer


On 30 December 2016 at 22:27, Christer Holmberg <christer.holmberg@ericsson.com> wrot= e:
> Hi,
>
>
>
> Please note the following:
>
>
>
> RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people have=
> a problem with that? I assume we=E2=80=99ll end up in trouble with the=
> security folks if we keep the old RFC=E2=80=A6
>
>
>
> And, considering MD2 is historic, do we even need to mention it in
> draft-4572-update anymore?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> From: mmusic [mailto:mmusic= -bounces@ietf.org] On Behalf Of Christer
> Holmberg
> Sent: 30 December 2016 11:42
> To: mmusic@ietf.org
> Cc: Jonathan Lennox (jonathan@vi= dyo.com) <jonathan@vidyo.com>; Cullen
> Jennings (fluffy@iii.ca) <fluffy@iii.ca>
> Subject: [MMUSIC] draft-4572-update: Spec contains references to a
> number of obsoleted RFCs
>
>
>
> Hi,
>
>
>
> The idnits check returns the following for draft-4572-update.
>
>
>
> ** Obsolete normative reference: RFC 1319 (ref. '3') (Obsolete= d by RFC
> 6149)
>
>
>
>=C2=A0 =C2=A0** Downref: Normative reference to an Informational RFC: R= FC 1321 (ref.
> '4')
>
>
>
>=C2=A0 =C2=A0** Obsolete normative reference: RFC 3280 (ref. '8'= ;) (Obsoleted by
> RFC
> 5280)
>
>
>
>=C2=A0 =C2=A0** Obsolete normative reference: RFC 4234 (ref. '11= 9;) (Obsoleted by
> RFC
>
>=C2=A0 =C2=A0 =C2=A0 5234)
>
>
>
>=C2=A0 =C2=A0** Obsolete normative reference: RFC 4288 (ref. '12= 9;) (Obsoleted by
> RFC
>
>=C2=A0 =C2=A0 =C2=A0 6838)
>
>
>
>=C2=A0 =C2=A0** Obsolete normative reference: RFC 4346 (ref. '13= 9;) (Obsoleted by
> RFC
>
>=C2=A0 =C2=A0 =C2=A0 5246)
>
>
>
>=C2=A0 =C2=A0-- Obsolete informational reference (is this intentional?)= : RFC 2617 (ref.
>
>=C2=A0 =C2=A0 =C2=A0 '15') (Obsoleted by RFC 7235, RFC 7615, RF= C 7616, RFC 7617)
>
>
>
>=C2=A0 =C2=A0-- Obsolete informational reference (is this intentional?)= : RFC 3525 (ref.
>
>=C2=A0 =C2=A0 =C2=A0 '20') (Obsoleted by RFC 5125)
>
>
>
>=C2=A0 =C2=A0-- Obsolete informational reference (is this intentional?)= : RFC 3851 (ref.
>
>=C2=A0 =C2=A0 =C2=A0 '22') (Obsoleted by RFC 5751)
>
>
>
> The reason for this is that we used RFC 4572 as base, and did not
> change/update the references.
>
>
>
> I had a look, and I don=E2=80=99t think there should be any issues in<= br> > replacing the current RFCs with the new ones. But, please indicate if = you see any issues.
>
>
>
> Regards,
>
>
>
> Christer
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--001a11492dfa53575105452061a6-- From nobody Mon Jan 2 18:28: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 53806129521 for ; Mon, 2 Jan 2017 18:28:17 -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 UpKQ50phMbMo for ; Mon, 2 Jan 2017 18:28:16 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 4858B129474 for ; Mon, 2 Jan 2017 18:28:16 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id u25so48277221qki.2 for ; Mon, 02 Jan 2017 18:28: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=bjFRDWu3+wrtEemVEhEPf3NQ7pFY8ENeSB53IGAd3f0=; b=e7EmDfNrXrD64roJLzvAk0+isHW/uJ0yPQ8zNIlltxOpv67uoYXx2uWdnrkDpU9HY+ LkUFl0yeRQ2b11Vh7DI6S/1AuVEjA4TlOTjCjNF3hU+LZu0tU+EzKsFqgf2RDLp9pt/x +ThNHiP0jkNwf+RRB+dT7xEspvBKz73AzeEzAvmyDcFsc3RE1yaq1XrjU095Va256WPX IqbaRBsL9CcvJ4aBJvicYLe7tDvJpoI76miwZ+5NA1WWwgQdmOgi3bgg6bQSynJGYvQB Ny3/Xk0WHTxRUZjorz4C0y9EFR4yzuRomjA1+VjxkVJyRsflLl/azUXYoKMJstklr1tq 4W9w== 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=bjFRDWu3+wrtEemVEhEPf3NQ7pFY8ENeSB53IGAd3f0=; b=CYGN3vurfHByeNn5EYLim6dMOGu5zXRXa2qJ0ooeUMMKSnDPSt9KftNiJDCHAWlNKq Of0Pfz4JOBTbenL+2GQ8vpTpMKsUFk02tYuvCxFFyu4Fge0H1I1zZiCOuacoxt7rhoMY rqw1qpnB4fxWLTDtgDez6syfQ/Tc3VWUpYJF9v4RgkivykoSlJCGFvpQwEf2kfeo1Je1 REaE0+HkfCstqIOGCLvTPpecnJyI+cshC0cKjTYf5cIiUvCUTQneUpEsO/prVT3rp87z VZq5D00HI43rAggPsvYMS73MnocWctYryihLqdUiMW6AvNOVLCaEjX8hWZLSb+ZmWWuy 9tPg== X-Gm-Message-State: AIkVDXLWb/YI2+9JnckjYKdOvCXU+ez29BRGki4/QxdPicIhhBPOfz6f+xqaT/2LV2iJOdUMoh0bgBwBTQQjWQ== X-Received: by 10.55.138.2 with SMTP id m2mr34561795qkd.115.1483410495471; Mon, 02 Jan 2017 18:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 2 Jan 2017 18:28:15 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> From: Martin Thomson Date: Tue, 3 Jan 2017 13:28:15 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Jonathan Lennox \(jonathan@vidyo.com\)" , "mmusic@ietf.org" , "Cullen Jennings \(fluffy@iii.ca\)" , Christer Holmberg Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 02:28:17 -0000 On 3 January 2017 at 05:03, Eric Rescorla wrote: > Given the threat model here, I think we want to tell people to ignore MD* > (i.e., treat it as an unknown hash) and to accept SHA-1 (though perhaps only > temporarily). Accordingly, I propose removing MD2 and MD5 from this grammar, > but leave SHA-1. That makes sense. These busted hashes will then appear to be unsupported extensions. From nobody Tue Jan 3 00:04:31 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 E2E6712948F for ; Tue, 3 Jan 2017 00:04:29 -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 ThsVGSY92gkA for ; Tue, 3 Jan 2017 00:04:28 -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 49ED3129429 for ; Tue, 3 Jan 2017 00:04:27 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-be-586b5b092422 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id EA.5B.31458.90B5B685; Tue, 3 Jan 2017 09:04:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 09:04:40 +0100 From: Christer Holmberg To: Martin Thomson Thread-Topic: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs Thread-Index: AdJigL/3HmdriiVMRVGMYSdDZzSqOwADa/tQAGF4AYAANAiaQAANbYuAABGfxoAADdKELA== Date: Tue, 3 Jan 2017 08:04:01 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ky5ndHaEwc77RhYrXp9jt/iw/gej xf7F55ktrp35x2gxdfljFgdWj52z7rJ7LFnyk8nj8vmPjB6TH7cxe7Q9u8MewBrFZZOSmpNZ llqkb5fAlXF06g+2goOsFS1fZzA3MK5k6WLk5JAQMJG4vPoscxcjF4eQwDpGiU2/HzBCOIsZ JXY9/M3UxcjBwSZgIdH9TxukQURAV2LR2QfsIDXMAjsZJRa/fAo2SVggUeLW9o1sEEVJEm+a tzBC2GESq598BLNZBFQkug5uZQaxeQXsJa5eOQi1eQWzxKrWnWDNnAKBElf2P2IFsRkFxCS+ n1rDBGIzC4hL3HoynwnibAGJJXvOM0PYohIvH/9jhajRkViw+xMbhK0tsWzha6hlghInZz5h mcAoMgvJqFlIWmYhaZmFpGUBI8sqRtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMB4Orjlt8EO xpfPHQ8xCnAwKvHwfsjKihBiTSwrrsw9xCjBwawkwqsemR0hxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA6PMfeW50WJWqXcSvxpubhZL0jpRLS+pznap nt9w/0zjD4WWXxJfnA4z/BLb/m6VNNvE3vm7t4pNt63corhw+ZujLhOv73h1qPGP6xOf/emh KSWz6hek+T9M07sZKpT19NiZCoF+vi2yD19ycH/fJrla8HKB1IqH0/243XvDy/9P6PfyjnDv 7VNiKc5INNRiLipOBAAv4uebowIAAA== Archived-At: Cc: "Jonathan Lennox \(jonathan@vidyo.com\)" , "mmusic@ietf.org" , "Cullen Jennings \(fluffy@iii.ca\)" Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 08:04:30 -0000 Hi, I am fine to also remove MD5. However, I want to make sure we don't bring b= ack Cullen's backward compatibility issues. Regards, Christer Sent from my iPhone > On 3 Jan 2017, at 4.28, Martin Thomson wrote: >=20 >> On 3 January 2017 at 05:03, Eric Rescorla wrote: >> Given the threat model here, I think we want to tell people to ignore MD= * >> (i.e., treat it as an unknown hash) and to accept SHA-1 (though perhaps = only >> temporarily). Accordingly, I propose removing MD2 and MD5 from this gram= mar, >> but leave SHA-1. >=20 >=20 > That makes sense. These busted hashes will then appear to be > unsupported extensions. From nobody Tue Jan 3 09:34: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 41A241295DE for ; Tue, 3 Jan 2017 09:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5EsSc0k7VH5 for ; Tue, 3 Jan 2017 09:34:40 -0800 (PST) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (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 3F187129A74 for ; Tue, 3 Jan 2017 09:34:40 -0800 (PST) Received: from smtp2.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7DA365B9B; Tue, 3 Jan 2017 12:34:37 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp2.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E75C85B9F; Tue, 3 Jan 2017 12:34:36 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 03 Jan 2017 12:34:37 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: Date: Tue, 3 Jan 2017 10:34:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> To: Eric Rescorla X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 17:34:42 -0000 Trivial nit but ... Actually I don't think you want MD5 treated as a unknown hash, you want = treated as a known but don't use. If A offers old and bad crypto to B, = we have B log that such that we can track down and upgrade A. If we got = a a new unknown cipher call SSHHAA we would not log that as bad crypto = because we would assume it was new and good.=20 > On Jan 2, 2017, at 11:03 AM, Eric Rescorla wrote: >=20 > On Mon, Jan 2, 2017 at 2:41 AM, Christer Holmberg = wrote: > Hi, >=20 > >We can remove MD2. MD5 is dead, SHA-1 is in its death throes, but = MD2 is merely a >(bad) memory. >=20 > So, my suggestion is to remove all references to MD2 (including the = ABNF) for now, and we'll then see what the security folks say about MD5 = and SHA-1. >=20 > Given the threat model here, I think we want to tell people to ignore = MD* (i.e., treat it as an unknown hash) and to accept SHA-1 (though = perhaps only temporarily). Accordingly, I propose removing MD2 and MD5 = from this grammar, but leave SHA-1. >=20 > -Ekr >=20 >=20 > Regards, >=20 > Christer >=20 >=20 > On 30 December 2016 at 22:27, Christer Holmberg = wrote: > > Hi, > > > > > > > > Please note the following: > > > > > > > > RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people = have > > a problem with that? I assume we=E2=80=99ll end up in trouble with = the > > security folks if we keep the old RFC=E2=80=A6 > > > > > > > > And, considering MD2 is historic, do we even need to mention it in > > draft-4572-update anymore? > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > Sent: 30 December 2016 11:42 > > To: mmusic@ietf.org > > Cc: Jonathan Lennox (jonathan@vidyo.com) ; = Cullen > > Jennings (fluffy@iii.ca) > > Subject: [MMUSIC] draft-4572-update: Spec contains references to a > > number of obsoleted RFCs > > > > > > > > Hi, > > > > > > > > The idnits check returns the following for draft-4572-update. > > > > > > > > ** Obsolete normative reference: RFC 1319 (ref. '3') (Obsoleted by = RFC > > 6149) > > > > > > > > ** Downref: Normative reference to an Informational RFC: RFC 1321 = (ref. > > '4') > > > > > > > > ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by > > RFC > > 5280) > > > > > > > > ** Obsolete normative reference: RFC 4234 (ref. '11') (Obsoleted = by > > RFC > > > > 5234) > > > > > > > > ** Obsolete normative reference: RFC 4288 (ref. '12') (Obsoleted = by > > RFC > > > > 6838) > > > > > > > > ** Obsolete normative reference: RFC 4346 (ref. '13') (Obsoleted = by > > RFC > > > > 5246) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC = 2617 (ref. > > > > '15') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC = 3525 (ref. > > > > '20') (Obsoleted by RFC 5125) > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC = 3851 (ref. > > > > '22') (Obsoleted by RFC 5751) > > > > > > > > The reason for this is that we used RFC 4572 as base, and did not > > change/update the references. > > > > > > > > I had a look, and I don=E2=80=99t think there should be any issues = in > > replacing the current RFCs with the new ones. But, please indicate = if you see any issues. > > > > > > > > Regards, > > > > > > > > Christer > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Tue Jan 3 09:37: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 4345F129A7A for ; Tue, 3 Jan 2017 09:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6_T1jowY54ya for ; Tue, 3 Jan 2017 09:37:12 -0800 (PST) Received: from smtp146.dfw.emailsrvr.com (smtp146.dfw.emailsrvr.com [67.192.241.146]) (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 41B3D129A7E for ; Tue, 3 Jan 2017 09:37:11 -0800 (PST) Received: from smtp19.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 9884740154; Tue, 3 Jan 2017 12:37:10 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0E8CC4016A; Tue, 3 Jan 2017 12:37:09 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 03 Jan 2017 12:37:10 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: Date: Tue, 3 Jan 2017 10:37:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <305DCC95-7F32-47FA-AB6E-704E1F1440E8@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 17:37:15 -0000 > On Jan 3, 2017, at 1:04 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I am fine to also remove MD5. However, I want to make sure we don't = bring back Cullen's backward compatibility issues. >=20 > Regards, Everything I know that offered MD5 also offered SHA1 so I don't see any = problem with not support MD5. And if there is a problem, I'm not very = sympathetic.=20 From nobody Tue Jan 3 09:44: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 BF985129A7A for ; Tue, 3 Jan 2017 09:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Uo8wzuF3N_bt for ; Tue, 3 Jan 2017 09:44:34 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D891129A76 for ; Tue, 3 Jan 2017 09:44:34 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so469066727qtc.2 for ; Tue, 03 Jan 2017 09:44:34 -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=bsLLFiH+en9vQaWGWjIR5AUHERnBgQE/P9QDL8KGGLk=; b=nZZ7PhDtRAtrzn0lMccW9ewFdDsgx3E7k+trvrLTVpVnNrO5lRkHWoS0TF1cOCv0SU TyAG27A91PauZXrctRYzse80Akq68E46XCL+TB3Qnxl5Qn4HpV1NpTMkIiw6+KzcpOdI PXwh2PeaEycpibuHrmf/MHHGaS90f+eUy8MO1qrWJs2emqPu5Xv2NVk7WQ9KEnCc+X/M xdNSosL6IGD+4J+u+uorL7rqH2XeIFjVHLpdPaMajUMn4JOYdL2WCusfO2tLoqXEIhgi SD2ex1l6HMkIeKII/M4IKI+7Sc1au5BdL/AvHOpEQyrEqYMICGytBJepmnrU6l7pOVRD QCwQ== 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=bsLLFiH+en9vQaWGWjIR5AUHERnBgQE/P9QDL8KGGLk=; b=DJxElzHXuP6g7lahYPBjFgLrY5MXempVn35712+3QqwSZUJXqJva/Dk2uf/z17CP4V opGM9qisxNwz8/mf60oRIVBE40jO+woH35BmXHOYTRaJLoQaE+DV7dBOqYKIU+NmNYUK AoFsqr6mcKWPNjUjF/AmRmJx/m7Ux7223CXegEOM4iHv2nfZ3t+s6teeLZrrihrGRkwI M0d5UxUw8A1P2Fy10oCm402DnpUpZb5UZxQnuosZpZbAvHY7Iwns8fjV3qUYGET/9hob /1BVtx+oRawaW5NU9fEb4atr6zmPXfIwt0fit4azlwjdH3q/7YOFFkTO59tensuxZbgD nouw== X-Gm-Message-State: AIkVDXIRe4l7cuO9BXHqD7lFqWTrSn0QLfgavKduGn4JoRMYr6ZAwl4hLoquCkFwCYuX0A== X-Received: by 10.200.37.101 with SMTP id 34mr57384139qtn.273.1483465473609; Tue, 03 Jan 2017 09:44:33 -0800 (PST) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com. [209.85.220.178]) by smtp.gmail.com with ESMTPSA id k26sm28829938qtc.36.2017.01.03.09.44.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 09:44:33 -0800 (PST) Received: by mail-qk0-f178.google.com with SMTP id h201so242768013qke.1 for ; Tue, 03 Jan 2017 09:44:32 -0800 (PST) X-Received: by 10.55.80.198 with SMTP id e189mr60814187qkb.222.1483465472781; Tue, 03 Jan 2017 09:44:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 09:44:32 -0800 (PST) In-Reply-To: <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> From: Roman Shpount Date: Tue, 3 Jan 2017 12:44:32 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a114a6f028aca4505453438fa Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 17:44:37 -0000 --001a114a6f028aca4505453438fa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree, I think MD2 and MD5 should be defined in the grammar but specification should state that they MUST NOT be used. This way there are no potential backwards interop problems. Regards, _____________ Roman Shpount On Tue, Jan 3, 2017 at 12:34 PM, Cullen Jennings wrote: > > Trivial nit but ... > > Actually I don't think you want MD5 treated as a unknown hash, you want > treated as a known but don't use. If A offers old and bad crypto to B, we > have B log that such that we can track down and upgrade A. If we got a a > new unknown cipher call SSHHAA we would not log that as bad crypto becaus= e > we would assume it was new and good. > > > > On Jan 2, 2017, at 11:03 AM, Eric Rescorla wrote: > > > > On Mon, Jan 2, 2017 at 2:41 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > >We can remove MD2. MD5 is dead, SHA-1 is in its death throes, but MD2 > is merely a >(bad) memory. > > > > So, my suggestion is to remove all references to MD2 (including the > ABNF) for now, and we'll then see what the security folks say about MD5 a= nd > SHA-1. > > > > Given the threat model here, I think we want to tell people to ignore > MD* (i.e., treat it as an unknown hash) and to accept SHA-1 (though perha= ps > only temporarily). Accordingly, I propose removing MD2 and MD5 from this > grammar, but leave SHA-1. > > > > -Ekr > > > > > > Regards, > > > > Christer > > > > > > On 30 December 2016 at 22:27, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > > > > > > > > > Please note the following: > > > > > > > > > > > > RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people hav= e > > > a problem with that? I assume we=E2=80=99ll end up in trouble with th= e > > > security folks if we keep the old RFC=E2=80=A6 > > > > > > > > > > > > And, considering MD2 is historic, do we even need to mention it in > > > draft-4572-update anymore? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer > > > Holmberg > > > Sent: 30 December 2016 11:42 > > > To: mmusic@ietf.org > > > Cc: Jonathan Lennox (jonathan@vidyo.com) ; Cullen > > > Jennings (fluffy@iii.ca) > > > Subject: [MMUSIC] draft-4572-update: Spec contains references to a > > > number of obsoleted RFCs > > > > > > > > > > > > Hi, > > > > > > > > > > > > The idnits check returns the following for draft-4572-update. > > > > > > > > > > > > ** Obsolete normative reference: RFC 1319 (ref. '3') (Obsoleted by RF= C > > > 6149) > > > > > > > > > > > > ** Downref: Normative reference to an Informational RFC: RFC 1321 > (ref. > > > '4') > > > > > > > > > > > > ** Obsolete normative reference: RFC 3280 (ref. '8') (Obsoleted by > > > RFC > > > 5280) > > > > > > > > > > > > ** Obsolete normative reference: RFC 4234 (ref. '11') (Obsoleted by > > > RFC > > > > > > 5234) > > > > > > > > > > > > ** Obsolete normative reference: RFC 4288 (ref. '12') (Obsoleted by > > > RFC > > > > > > 6838) > > > > > > > > > > > > ** Obsolete normative reference: RFC 4346 (ref. '13') (Obsoleted by > > > RFC > > > > > > 5246) > > > > > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 261= 7 > (ref. > > > > > > '15') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) > > > > > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 352= 5 > (ref. > > > > > > '20') (Obsoleted by RFC 5125) > > > > > > > > > > > > -- Obsolete informational reference (is this intentional?): RFC 385= 1 > (ref. > > > > > > '22') (Obsoleted by RFC 5751) > > > > > > > > > > > > The reason for this is that we used RFC 4572 as base, and did not > > > change/update the references. > > > > > > > > > > > > I had a look, and I don=E2=80=99t think there should be any issues in > > > replacing the current RFCs with the new ones. But, please indicate if > you see any issues. > > > > > > > > > > > > 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 > --001a114a6f028aca4505453438fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree, I think MD2 and MD5 should be defined in the gram= mar but specification should state that they MUST NOT be used. This way the= re are no potential backwards interop problems.

Regards,=

_____________
Roman= Shpount

On Tue, Jan 3, 2017 at 12:34 PM, Cullen Jenn= ings <fluffy@iii.ca> wrote:
Trivial nit but ...

Actually I don't think you want MD5 treated as a unknown hash, you want= treated as a known but don't use. If A offers old and bad crypto to B,= we have B log that such that we can track down and upgrade A. If we got a = a new unknown cipher call SSHHAA we would not log that as bad crypto becaus= e we would assume it was new and good.


> On Jan 2, 2017, at 11:03 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Mon, Jan 2, 2017 at 2:41 AM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:
> Hi,
>
> >We can remove MD2.=C2=A0 MD5 is dead, SHA-1 is in its death throes= , but MD2 is merely a >(bad) memory.
>
> So, my suggestion is to remove all references to MD2 (including the AB= NF) for now, and we'll then see what the security folks say about MD5 a= nd SHA-1.
>
> Given the threat model here, I think we want to tell people to ignore = MD* (i.e., treat it as an unknown hash) and to accept SHA-1 (though perhaps= only temporarily). Accordingly, I propose removing MD2 and MD5 from this g= rammar, but leave SHA-1.
>
> -Ekr
>
>
> Regards,
>
> Christer
>
>
> On 30 December 2016 at 22:27, Christer Holmberg <christer.holmberg@ericsson.com>= wrote:
> > Hi,
> >
> >
> >
> > Please note the following:
> >
> >
> >
> > RFC 6149, which obsoletes RFC 1319, makes MD2 historic. Do people= have
> > a problem with that? I assume we=E2=80=99ll end up in trouble wit= h the
> > security folks if we keep the old RFC=E2=80=A6
> >
> >
> >
> > And, considering MD2 is historic, do we even need to mention it i= n
> > draft-4572-update anymore?
> >
> >
> >
> > Regards,
> >
> >
> >
> > Christer
> >
> >
> >
> >
> >
> > From: mmusic [mailto:m= music-bounces@ietf.org] On Behalf Of Christer
> > Holmberg
> > Sent: 30 December 2016 11:42
> > To: mmusic@ietf.org
> > Cc: Jonathan Lennox (jonath= an@vidyo.com) <jonathan@vidyo.= com>; Cullen
> > Jennings (fluffy@iii.ca) <= ;fluffy@iii.ca>
> > Subject: [MMUSIC] draft-4572-update: Spec contains references to = a
> > number of obsoleted RFCs
> >
> >
> >
> > Hi,
> >
> >
> >
> > The idnits check returns the following for draft-4572-update.
> >
> >
> >
> > ** Obsolete normative reference: RFC 1319 (ref. '3') (Obs= oleted by RFC
> > 6149)
> >
> >
> >
> >=C2=A0 =C2=A0** Downref: Normative reference to an Informational R= FC: RFC 1321 (ref.
> > '4')
> >
> >
> >
> >=C2=A0 =C2=A0** Obsolete normative reference: RFC 3280 (ref. '= 8') (Obsoleted by
> > RFC
> > 5280)
> >
> >
> >
> >=C2=A0 =C2=A0** Obsolete normative reference: RFC 4234 (ref. '= 11') (Obsoleted by
> > RFC
> >
> >=C2=A0 =C2=A0 =C2=A0 5234)
> >
> >
> >
> >=C2=A0 =C2=A0** Obsolete normative reference: RFC 4288 (ref. '= 12') (Obsoleted by
> > RFC
> >
> >=C2=A0 =C2=A0 =C2=A0 6838)
> >
> >
> >
> >=C2=A0 =C2=A0** Obsolete normative reference: RFC 4346 (ref. '= 13') (Obsoleted by
> > RFC
> >
> >=C2=A0 =C2=A0 =C2=A0 5246)
> >
> >
> >
> >=C2=A0 =C2=A0-- Obsolete informational reference (is this intentio= nal?): RFC 2617 (ref.
> >
> >=C2=A0 =C2=A0 =C2=A0 '15') (Obsoleted by RFC 7235, RFC 761= 5, RFC 7616, RFC 7617)
> >
> >
> >
> >=C2=A0 =C2=A0-- Obsolete informational reference (is this intentio= nal?): RFC 3525 (ref.
> >
> >=C2=A0 =C2=A0 =C2=A0 '20') (Obsoleted by RFC 5125)
> >
> >
> >
> >=C2=A0 =C2=A0-- Obsolete informational reference (is this intentio= nal?): RFC 3851 (ref.
> >
> >=C2=A0 =C2=A0 =C2=A0 '22') (Obsoleted by RFC 5751)
> >
> >
> >
> > The reason for this is that we used RFC 4572 as base, and did not=
> > change/update the references.
> >
> >
> >
> > I had a look, and I don=E2=80=99t think there should be any issue= s in
> > replacing the current RFCs with the new ones. But, please indicat= e if you see any issues.
> >
> >
> >
> > 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

--001a114a6f028aca4505453438fa-- From nobody Tue Jan 3 11:44: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 2C047129B2F; Tue, 3 Jan 2017 11:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, 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 f26emO4Wpzm5; Tue, 3 Jan 2017 11:43:58 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F342C129B2E; Tue, 3 Jan 2017 11:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21506; q=dns/txt; s=iport; t=1483472638; x=1484682238; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Z/PV3QGOqmSkyPeAQbegnhws/PnoTOMk3VHnEO7RaAU=; b=XV0UL5Wf/Zoo57ZrN88eZTySPu28h7+J76D0c/XkciS6M6Gtlu5y5jRj +JZ9Y3lIlbSAWpoSrvycbQ7yzKqt4oLX3Q9GcGjInBrFAD/9aV5TxZl+n 6VchY5ImBL37bUsvO65gaRJGFOHMlFbfYgI6VcALLCdwz3UVnV6xVAyyo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQAd/mtY/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFGAQEBAQEfX4EMB41QlEeHe4d4gxmCD4IIKoV4AhqBMj8UAQI?= =?us-ascii?q?BAQEBAQEBYiiEaAEBAQQjVhACAQgRAwECKAMCAgIfERQJCAIEDgUbiDoDGA6vL?= =?us-ascii?q?4IlK4cPDYJkAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIR4FZgQaCToIYFoJOLYI?= =?us-ascii?q?wBZUJhT81AYZThnGDeZBViXOEO4QOAR84gSo8AYVOcgGHMIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,456,1477958400"; d="scan'208,217";a="368110480" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 19:43:57 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v03JhuSg013608 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 19:43:57 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 13:43:56 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 3 Jan 2017 13:43:56 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount Thread-Topic: [MMUSIC] [bfcpbis] m= line protocol in case of ICE Thread-Index: AQHSZfm46LjmSy7T7UmDYerMTbGdsg== Date: Tue, 3 Jan 2017 19:43:55 +0000 Message-ID: <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> In-Reply-To: <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.130.138] Content-Type: multipart/alternative; boundary="_000_633D349183B1421FB48C0A61B1314E99ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 19:44:00 -0000 --_000_633D349183B1421FB48C0A61B1314E99ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q3JpY2tldHPigKYNCklmIG5vIG9uZSBpcyBvciBoYXMgcGxhbnMgZm9yIHVzaW5nIElDRSB3aXRo IFRDUC9CRkNQLCBwZXJoYXBzIGl0IGlzIGJlc3QgdG8gc3RhdGUgdGhhdCBhcyBvZiB0aGlzIHJl diBvZiB0aGUgQkZDUCBzcGVjLCBCRkNQIHdpdGggVENQIGNhbmRpZGF0ZXMgaXMgbm90IGRlZmlu ZWQuIEZ1dHVyZSB1cGRhdGVzIHRvIHRoZSBzcGVjIG1heSBkZWZpbmUgdGhpcyB1c2FnZS4NCg0K Q2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBtbXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5jb20+DQpEYXRlOiBG cmlkYXksIERlY2VtYmVyIDIsIDIwMTYgYXQgNDowMSBQTQ0KVG86IFJvbWFuIFNocG91bnQgPHJv bWFuQHRlbHVyaXguY29tPg0KQ2M6ICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+LCAiYmZj cGJpc0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbYmZjcGJpc10gbT0gbGluZSBwcm90b2Nv bCBpbiBjYXNlIG9mIElDRQ0KDQpJIGhhdmUgbm8gZXhwZXJpZW5jZSB3aXRoIElDRSB3aXRoIFRD UCBjYW5kaWRhdGVzIHNvIGhvcGVmdWxseSBvdGhlcnMgY2FuIGNoaW1lIGluIGFzIHRvIHdoYXQg dGhleSB0aGluayBpcyBhIHdvcmthYmxlIHNvbHV0aW9uLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoN CkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KRGF0ZTogVGh1cnNkYXks IERlY2VtYmVyIDEsIDIwMTYgYXQgMTI6MzQgUE0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1 QGNpc2NvLmNvbT4NCkNjOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBnbWFpbC5jb20+LCAiYmZjcGJp c0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCAiaWNlQGlldGYub3JnIiA8aWNlQGlldGYu b3JnPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRmLm9yZz4sIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KQ2hhcmxlcywN Cg0KUkZDIDY1NDQgU2VuZGluZyBNZWRpYSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzY1NDQjc2VjdGlvbi0xMC4xKSBzYXlzIHRoYXQgIlRoZSBmcmFtaW5nIGRlZmluZWQgaW4gUkZD IDQ1NzE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ1NzE+IE1VU1QgYmUgdXNlZCB3 aGVuIHNlbmRpbmcgbWVkaWEuIiBUaGlzIG1lYW5zIHRoZSBwcm90b2NvbCB1c2VkIGlzIG5vdCBU Q1AvQkZDUCB3aGljaCBpcyB1c2luZyBhcHBsaWNhdGlvbiBsZXZlbCBmcmFtaW5nLiBJIGJlbGll dmUgdGhhdCBTVFVOL01lZGlhIGRlbXVsdGlwbGV4aW5nIHJlcXVpcmVtZW50cyB3b3VsZCBwcmV2 ZW50IHVzaW5nIFRDUC9CRkNQIGRpcmVjdGx5IHdpdGggaWNlIHRjcCBjYW5kaWRhdGVzIHdpdGhv dXQgcmVkZXNpZ24gb2YgZWl0aGVyIElDRSBUQ1Agb3IgVENQL0JGQ1AuDQoNCkZ1cnRoZXJtb3Jl IHRoZXJlIGFyZSBvdGhlciBpbXBsaWVkIElDRSByZXF1aXJlbWVudHMgdGhhdCBJIG91dGxpbmVk IGJlZm9yZSAoc3dpdGNoaW5nIGJldHdlZW4gdWRwIGFuZCB0cGMgY2FuZGlkYXRlcywgZXhpc3Rl bmNlIG9mIFNCQyB3aGljaCB0ZXJtaW5hdGUgSUNFIG9ubHkgYnV0IGRvIG5vdCBzdXBwb3J0IHRo ZSBlbWJlZGRlZCBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBpY2UgdGNwIGlzIGNvbnNpZGVy ZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWlyZSBmcmFnbWVudGF0aW9uIHN1 cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBub3QgcGFydCBvZiBUQ1AvQkZD UC4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQpPbiBUaHUs IERlYyAxLCAyMDE2IGF0IDM6MTcgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIDxlY2tlbGN1 QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+PiB3cm90ZToNClJvbWFuLA0KDQpX aHkgd291bGQgc2VsZWN0aW5nIFRDUC9CRkNQIGFzIHRyYW5zcG9ydCB2aW9sYXRlIFJGQyA2NTQ0 PyBQZXJoYXBzIGl0IGRvZXMsIGJ1dCBhZnRlciBhIHF1aWNrIHNjYW4gSSBhbSBub3Qgc3VyZSB3 aHkuDQoNCkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVs dXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkRhdGU6IFR1ZXNkYXksIE5vdmVt YmVyIDI5LCAyMDE2IGF0IDEwOjM4IEFNDQpUbzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNj by5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4NCkNjOiBBbGFuIEZvcmQgPGFsYW4uZm9y ZEBnbWFpbC5jb208bWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5jb20+PiwgImJmY3BiaXNAaWV0Zi5v cmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+IiA8YmZjcGJpc0BpZXRmLm9yZzxtYWlsdG86YmZj cGJpc0BpZXRmLm9yZz4+LCAiaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+IiA8aWNl QGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+PiwgIm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3Jn Pj4sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KT24gVHVlLCBO b3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIDxlY2tlbGN1 QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+PiB3cm90ZToNCkl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxkIGJlIHRvIG1h bmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVuIHVzaW5nIElDRSwgdXNlIFVEUCBh cyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwgdGhlIEJGQ1AgbS1saW5lIGFzIGlm IGl0IGlzIEJGQ1Agb3ZlciBVRFAuIElmIHdlIGNhbiBtYW5kYXRlIHRoZSB1c2Ugb2YgRFRMUywg dGhhdCB3b3VsZCBiZSBldmVuIGJldHRlci4NClRob3VnaHRzPw0KDQoNCkkgYWdyZWUuDQoNClRo ZSBvbmx5IGlzc3VlIHRoYXQgSSBzdGlsbCBoYXZlLCBpZiBEVExTIGlzIG5vdCB1c2VkLCB3aGF0 IHByb3RvY29sIGlzIHVzZWQgd2hlbiBJQ0UgdGNwIGNhbmRpZGF0ZSBpcyBzZWxlY3RlZCBmb3Ig dHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFnYWluc3QgUkZDNjU0NCkg IG9yIGlzIGl0IFVEUC9CRkNQIHdpdGggUkZDNDU3MSBmcmFtaW5nPyBJZiBpdCBpcyBVRFAvQkZD UCB3aXRoIFJGQzQ1NzEgZnJhbWluZywgd2hhdCB0cmFuc3BvcnQgdGFnIHNob3VsZCBiZSB1c2Vk IGluIHRoZSByZS1JTlZJVEUgd2hpY2ggaXMgc2VudCBhZnRlciBJQ0Ugbm9taW5hdGlvbiB3aXRo IG9ubHkgc2VsZWN0ZWQgY2FuZGlkYXRlPyBTaG91bGQgaXQgYmUgVENQL1VEUC9CRkNQIG9yIHNv bWV0aGluZyBzaW1pbGFyPw0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQoNCg== --_000_633D349183B1421FB48C0A61B1314E99ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <26F517D76A00684796153C9920564741@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNyaWNrZXRz4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiBubyBvbmUgaXMgb3IgaGFzIHBsYW5zIGZvciB1c2luZyBJQ0Ugd2l0aCBUQ1AvQkZD UCwgcGVyaGFwcyBpdCBpcyBiZXN0IHRvIHN0YXRlIHRoYXQgYXMgb2YgdGhpcyByZXYgb2YgdGhl IEJGQ1Agc3BlYywgQkZDUCB3aXRoIFRDUCBjYW5kaWRhdGVzIGlzIG5vdCBkZWZpbmVkLiBGdXR1 cmUgdXBkYXRlcyB0byB0aGUgc3BlYyBtYXkgZGVmaW5lIHRoaXMgdXNhZ2UuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNoYXJsZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2NvbG9yOmJsYWNrIj5tbXVzaWMgJmx0O21tdXNpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBv biBiZWhhbGYgb2YgQ2hhcmxlcyBFY2tlbCAmbHQ7ZWNrZWxjdUBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+RGF0ZTogPC9iPkZyaWRheSwgRGVjZW1iZXIgMiwgMjAxNiBhdCA0OjAxIFBNPGJyPg0KPGI+ VG86IDwvYj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5D YzogPC9iPiZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0OywgJnF1 b3Q7YmZjcGJpc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmZjcGJpc0BpZXRmLm9yZyZndDssIENocmlz dGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7LCAmcXVv dDttbXVzaWNAaWV0Zi5vcmcmcXVvdDsgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtNTVVTSUNdIFtiZmNwYmlzXSBtPSBsaW5lIHByb3RvY29sIGluIGNh c2Ugb2YgSUNFPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgaGF2ZSBubyBleHBlcmllbmNlIHdpdGggSUNFIHdpdGggVENQIGNhbmRpZGF0ZXMg c28gaG9wZWZ1bGx5IG90aGVycyBjYW4gY2hpbWUgaW4gYXMgdG8gd2hhdCB0aGV5IHRoaW5rIGlz IGEgd29ya2FibGUgc29sdXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhcmxlczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0 ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIERlY2VtYmVyIDEsIDIw MTYgYXQgMTI6MzQgUE08YnI+DQo8Yj5UbzogPC9iPkNoYXJsZXMgRWNrZWwgJmx0O2Vja2VsY3VA Y2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+QWxhbiBGb3JkICZsdDthbGFuLmZvcmRAZ21h aWwuY29tJmd0OywgJnF1b3Q7YmZjcGJpc0BpZXRmLm9yZyZxdW90OyAmbHQ7YmZjcGJpc0BpZXRm Lm9yZyZndDssICZxdW90O2ljZUBpZXRmLm9yZyZxdW90OyAmbHQ7aWNlQGlldGYub3JnJmd0Oywg JnF1b3Q7bW11c2ljQGlldGYub3JnJnF1b3Q7ICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7LCBDaHJp c3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5SZTogW2JmY3BiaXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wg aW4gY2FzZSBvZiBJQ0U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoYXJsZXMsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UkZDIDY1NDQgU2VuZGluZyBNZWRpYSAoPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1NDQjc2VjdGlvbi0xMC4xIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEwLjE8L2E+KSZuYnNwO3NheXMgdGhhdCAm cXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+VGhlIGZyYW1p bmcgZGVmaW5lZCBpbg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0NTcxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UkZDIDQ1NzE8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4gTVVTVCBiZSB1 c2VkIHdoZW4gc2VuZGluZyBtZWRpYS4mcXVvdDsgVGhpcyBtZWFucyB0aGUgcHJvdG9jb2wgdXNl ZCBpcyBub3QgVENQL0JGQ1Agd2hpY2ggaXMgdXNpbmcgYXBwbGljYXRpb24gbGV2ZWwNCiBmcmFt aW5nLiBJIGJlbGlldmUgdGhhdCBTVFVOL01lZGlhIGRlbXVsdGlwbGV4aW5nIHJlcXVpcmVtZW50 cyB3b3VsZCBwcmV2ZW50IHVzaW5nIFRDUC9CRkNQIGRpcmVjdGx5IHdpdGggaWNlIHRjcCBjYW5k aWRhdGVzIHdpdGhvdXQgcmVkZXNpZ24gb2YgZWl0aGVyIElDRSBUQ1Agb3IgVENQL0JGQ1AuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+RnVydGhlcm1vcmUm bmJzcDt0aGVyZSBhcmUgb3RoZXIgaW1wbGllZCBJQ0UgcmVxdWlyZW1lbnRzIHRoYXQgSSBvdXRs aW5lZCBiZWZvcmUgKHN3aXRjaGluZyBiZXR3ZWVuIHVkcCBhbmQgdHBjIGNhbmRpZGF0ZXMsIGV4 aXN0ZW5jZSBvZiBTQkMgd2hpY2ggdGVybWluYXRlIElDRSBvbmx5IGJ1dCBkbyBub3Qgc3VwcG9y dCB0aGUgZW1iZWRkZWQNCiBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBpY2UgdGNwIGlzIGNv bnNpZGVyZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWlyZSBmcmFnbWVudGF0 aW9uIHN1cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBub3QgcGFydCBvZiBU Q1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5S ZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBT aHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCBEZWMgMSwgMjAxNiBhdCAzOjE3IFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWNrZWxj dUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2h5IHdv dWxkIHNlbGVjdGluZyBUQ1AvQkZDUCBhcyB0cmFuc3BvcnQgdmlvbGF0ZSBSRkMgNjU0ND8gUGVy aGFwcyBpdCBkb2VzLCBidXQgYWZ0ZXIgYSBxdWljayBzY2FuIEkgYW0gbm90IHN1cmUgd2h5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xv cjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmk7Y29sb3I6YmxhY2siPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0 ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTYgYXQgMTA6MzggQU08YnI+ DQo8Yj5UbzogPC9iPkNoYXJsZXMgRWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPkFsYW4gRm9yZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5hbGFuLmZvcmRAZ21haWwuY29tPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9hPiZxdW90 Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNl QGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9h PiZndDssIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtiZmNwYmlzXSBbTU1V U0lDXSBtPSBsaW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVHVlLCBOb3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwg KGVja2VsY3UpICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFw cHJvYWNoIHdvdWxkIGJlIHRvIG1hbmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVu IHVzaW5nIElDRSwgdXNlIFVEUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwg dGhlIEJGQ1AgbS1saW5lDQogYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1h bmRhdGUgdGhlIHVzZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg YWdyZWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGUgb25seSBpc3N1ZSB0aGF0IEkgc3RpbGwgaGF2ZSwgaWYgRFRMUyBpcyBub3Qg dXNlZCwgd2hhdCBwcm90b2NvbCBpcyB1c2VkIHdoZW4gSUNFIHRjcCBjYW5kaWRhdGUgaXMmbmJz cDtzZWxlY3RlZCBmb3IgdHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFn YWluc3QgUkZDNjU0NCkgJm5ic3A7b3INCiBpcyBpdCBVRFAvQkZDUCB3aXRoIFJGQzQ1NzEgZnJh bWluZz8gSWYgaXQgaXMgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmcsIHdoYXQgdHJhbnNw b3J0IHRhZyBzaG91bGQgYmUgdXNlZCBpbiB0aGUgcmUtSU5WSVRFIHdoaWNoIGlzIHNlbnQgYWZ0 ZXIgSUNFIG5vbWluYXRpb24gd2l0aCBvbmx5IHNlbGVjdGVkIGNhbmRpZGF0ZT8gU2hvdWxkIGl0 IGJlIFRDUC9VRFAvQkZDUCBvciBzb21ldGhpbmcgc2ltaWxhcj88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19f X19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_633D349183B1421FB48C0A61B1314E99ciscocom_-- From nobody Tue Jan 3 12: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 94663129B77 for ; Tue, 3 Jan 2017 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable 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 roCmwrDCY-Rq for ; Tue, 3 Jan 2017 12:08:09 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3374B129B5B for ; Tue, 3 Jan 2017 12:08:07 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u25so375658513qki.2 for ; Tue, 03 Jan 2017 12:08:07 -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=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=LmqFjgGnJpEAT8293nLy+iZwrWMh6/9AtnJ3EJzHJ/CEpEA7F73DgS6q1ac1enCr9J d/omcMmi6YnB9Y6A/qRtFRIuzO8ZPbW9E48imMy/H5aMFqGcP/e+b3Pl2l0Ps3HAb8Su ONbKOomO6rn211o/OWEReNUkoeE42tVcIBdEFGEeGYGKF82lddUGcyVi0pQmxosKAD45 HOZ45Bs4HShG1QfFxHffGDqtAKqpJJ8JHcuWJglY2AO69SOjOVTUZd/5J+K3sbiEF/RN LrXYbIQyqfWSYYKaoOhiw3J2k+v3n8Bk7DgUJ0ZgqCRt7e9dW+QiQJq5i2Xu9sHEccyf PyTg== 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=7y3H8XNkvR1aeMz8bkAx3Ee0MwlRaiQOFINbX/t73r8=; b=YNxLu96z7my7GcvGDGraPLnVOGL+/V22jRMtAN8kSh7dcwDiykQtAGqUb/KZBrrQBu idEKd+VnOqZ08cwoW7z6mwOPF0q1dxZOQ5Bd9ijaviK4PoPmprLbAcHyQaC68P2v+AvB AYt/2ydRzRz+Mwsps2RfEC5UtuFPmhFYVeWzlB/Vk0TYgeMlSrkYWjfBr4pBYTr3A7rw ahGY2WxX9C4XXqCCwynmmQLtSsTDm4fqM/b9FKEbS9s3Cst6eOsXO6NohG/obe06wlUX 9LUD1B6+DJfpfD1fW6wBhqA8aF/1JHty9NHyR7W87D+C/c1KPAQvih1zrsvTuSO7r0YE 17Qg== X-Gm-Message-State: AIkVDXIFHoHKSBWlUQiraMEfM1NRksMgRy5kHXK6LCOv75Souzd/pSVLFam/Lb6Ae1f//A== X-Received: by 10.55.185.133 with SMTP id j127mr59738566qkf.39.1483474086212; Tue, 03 Jan 2017 12:08:06 -0800 (PST) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com. [209.85.216.169]) by smtp.gmail.com with ESMTPSA id k143sm17289079qke.37.2017.01.03.12.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 12:08:05 -0800 (PST) Received: by mail-qt0-f169.google.com with SMTP id k15so233896116qtg.3; Tue, 03 Jan 2017 12:08:05 -0800 (PST) X-Received: by 10.200.45.144 with SMTP id p16mr589450qta.141.1483474085308; Tue, 03 Jan 2017 12:08:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 12:08:04 -0800 (PST) In-Reply-To: <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> From: Roman Shpount Date: Tue, 3 Jan 2017 15:08:04 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a1140396ce390540545363931 Archived-At: Cc: "bfcpbis@ietf.org" , Christer Holmberg , "mmusic@ietf.org" , "ice@ietf.org" Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 20:08:11 -0000 --001a1140396ce390540545363931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Charles, I do not think not supporting ICE tcp candidates will quite work since it will reduce the usability considerably. The simplest way to move forward is to define a different transport tag for BFCP with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks strange and I am open to other suggestions, such as calling all packet based protocols DBFCP). In general what I am proposing is: TCP/BFCP -- existing BFCP over TCP TLS/BFCP -- exisitng BFCP over TLS UDP/BFCP -- BFCP over UDP or ICE udp candidates TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp candidates UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work with NAT or ICE using normal ICE procedures. If we call all packet based protocols DBFCP then transport tags will be: TCP/BFCP -- existing BFCP over TCP TLS/BFCP -- exisitng BFCP over TLS UDP/DBFCP -- DBFCP over UDP or ICE udp candidates TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp candidate= s UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over ICE tcp candidates Since BFCP over UDP (or other packet based protocols) is quite different due to timers and transmission restrictions, it can have a different transport tag and even be defined in a separate RFC. Regards, _____________ Roman Shpount On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) wrote: > Crickets=E2=80=A6 > > If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best > to state that as of this rev of the BFCP spec, BFCP with TCP candidates i= s > not defined. Future updates to the spec may define this usage. > > > > Cheers, > > Charles > > > > *From: *mmusic on behalf of Charles Eckel < > eckelcu@cisco.com> > *Date: *Friday, December 2, 2016 at 4:01 PM > *To: *Roman Shpount > *Cc: *"ice@ietf.org" , "bfcpbis@ietf.org" , > Christer Holmberg , "mmusic@ietf.org" < > mmusic@ietf.org> > *Subject: *Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE > > > > I have no experience with ICE with TCP candidates so hopefully others can > chime in as to what they think is a workable solution. > > > > Cheers, > > Charles > > > > *From: *Roman Shpount > *Date: *Thursday, December 1, 2016 at 12:34 PM > *To: *Charles Eckel > *Cc: *Alan Ford , "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < > mmusic@ietf.org>, Christer Holmberg > *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE > > > > Charles, > > > > RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1)= says > that "The framing defined in RFC 4571 > MUST be used when sending media." > This means the protocol used is not TCP/BFCP which is using application > level framing. I believe that STUN/Media demultiplexing requirements woul= d > prevent using TCP/BFCP directly with ice tcp candidates without redesign = of > either ICE TCP or TCP/BFCP. > > > > Furthermore there are other implied ICE requirements that I outlined > before (switching between udp and tpc candidates, existence of SBC which > terminate ICE only but do not support the embedded protocol) because of > which ice tcp is considered unreliable transport and will require > fragmentation support and re-transmit timers that are not part of TCP/BFC= P. > > > > Regards, > > > _____________ > Roman Shpount > > > > On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) > wrote: > > Roman, > > > > Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it > does, but after a quick scan I am not sure why. > > > > Cheers, > > Charles > > > > *From: *Roman Shpount > *Date: *Tuesday, November 29, 2016 at 10:38 AM > *To: *Charles Eckel > *Cc: *Alan Ford , "bfcpbis@ietf.org" < > bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < > mmusic@ietf.org>, Christer Holmberg > *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE > > > > On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > > It seems to me that the most straightforward approach would be to mandate > support for BFCP over UDP when using ICE, use UDP as the default candidat= e, > and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate t= he > use of DTLS, that would be even better. > > Thoughts? > > > > > > I agree. > > > > The only issue that I still have, if DTLS is not used, what protocol is > used when ICE tcp candidate is selected for transport. Is this TCP/BFCP > (which goes against RFC6544) or is it UDP/BFCP with RFC4571 framing? If = it > is UDP/BFCP with RFC4571 framing, what transport tag should be used in th= e > re-INVITE which is sent after ICE nomination with only selected candidate= ? > Should it be TCP/UDP/BFCP or something similar? > > > > Regards, > > _____________ > Roman Shpount > > > > > > --001a1140396ce390540545363931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Charles,

I do not think not supporting = ICE tcp candidates will quite work since it will reduce the usability consi= derably. The simplest way to move forward is to define a different transpor= t tag for BFCP =C2=A0with RFC 4571 over TCP not to confuse it with TCP/BFCP= . It can be TCP/UDP/BFCP (I know this looks strange and I am open to other = suggestions, such as calling all packet based protocols DBFCP).=C2=A0
=

In general what I am proposing is:

=
TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP= over TLS
UDP/BFCP -- BFCP over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571 framing=C2=A0over TCP or over ICE tcp= candidates
UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp c= andidates
TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing= =C2=A0over TCP or over ICE tcp candidates

Legacy B= FCP over TCP or TLS cannot work with ICE or NAT. Other protocols can work w= ith NAT or ICE using normal ICE procedures.

If we = call all packet based protocols DBFCP then transport tags will be:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP= -- exisitng BFCP over TLS
UDP/DBFCP -- DBFCP over UDP or ICE udp= candidates
TCP/DBFCP -- DBFCP with RFC 4571 framing=C2=A0over TC= P or over ICE tcp candidates
UDP/DTLS/DBFCP -- DBFCP over DTL= S or over ICE udp candidates
TCP/DTLS/DBFCP -- DBFCP over DTLS wi= th RFC 4571 framing=C2=A0over TCP or over ICE tcp candidates

=
Since BFCP over UDP (or other packet based protocols) is q= uite different due to timers and transmission restrictions, it can have a d= ifferent transport tag and even be defined in a separate RFC.
Regards,

__= ___________
Roman Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Ecke= l (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for using ICE with TCP/BFC= P, perhaps it is best to state that as of this rev of the BFCP spec, BFCP w= ith TCP candidates is not defined. Future updates to the spec may define th= is usage.

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: mmusic <mmusic-bounces@ietf.org> on behalf of Charles Eckel <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf= .org" <ice@ie= tf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@eric= sson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE=

=C2=A0

I have no experience with ICE with TCP candidates so= hopefully others can chime in as to what they think is a workable solution= .

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: Roman Shpount <roman@telurix.com>=
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <= ;mmusic@ietf.org&g= t;, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Charles,

=C2=A0

RFC 6544 Sending Media (https://tools.ietf.org/h= tml/rfc6544#section-10.1)=C2=A0says that "The framing defined in RFC 4571 MUST be used when sending media." This means the = protocol used is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would preve= nt using TCP/BFCP directly with ice tcp candidates without redesign of eith= er ICE TCP or TCP/BFCP.

=C2=A0

Further= more=C2=A0there are other implied ICE requirements that I outlined before (= switching between udp and tpc candidates, existence of SBC which terminate = ICE only but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and = will require fragmentation support and re-transmit timers that are not part= of TCP/BFCP.

=C2=A0

Regards= ,


_____________
Roman Shpount

=C2=A0

On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckel= cu) <eckelcu@cisc= o.com> wrote:

Roman,

=C2=A0

Why would selecting TCP/BFCP as transport violate RF= C 6544? Perhaps it does, but after a quick scan I am not sure why.

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: Roman Shpount &l= t;roman@telurix.com<= /a>>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>= , "mmusic@ietf.or= g" <mmusic= @ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eck= elcu) <eckelcu@ci= sco.com> wrote:

It seems to me that the most straightforward approac= h would be to mandate support for BFCP over UDP when using ICE, use UDP as = the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would b= e even better.

Thoughts?

=C2=A0

=C2=A0

I agree.

=C2=A0

The only issue that I still have, if DTLS is not use= d, what protocol is used when ICE tcp candidate is=C2=A0selected for transp= ort. Is this TCP/BFCP (which goes against RFC6544) =C2=A0or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framin= g, what transport tag should be used in the re-INVITE which is sent after I= CE nomination with only selected candidate? Should it be TCP/UDP/BFCP or so= mething similar?

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0


--001a1140396ce390540545363931-- From nobody Tue Jan 3 14:06: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 CE0AE1297CC for ; Tue, 3 Jan 2017 14:06:35 -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 ZxtcQHeNpVYM for ; Tue, 3 Jan 2017 14:06:34 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 4384412940B for ; Tue, 3 Jan 2017 14:06:34 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c47so475477920qtc.2 for ; Tue, 03 Jan 2017 14:06:34 -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=s3i+WIeGruYqvfmdsIcMEvlSgChS4NMDvHTota+9ZIM=; b=IR5cWlKORipg7Gtj1dmha5HN3n0XkoIPdfyw47Lw9etopbyNN87joVo5tbLND2AUE0 8RVFQptbtL9e0BC0/osZ0JSHCR+zTfL1tQqfvnPDbdJlE7lU1X7Sk6vOIayaoZPQJRYM sQgI5CFxQJcBulQRBcSYDHXubsAEeOyyEBHj1hynvd/iFz8r3exmWkT9Syqu7OWFnqNN lSzfr0XoU3xb/d+CrXOC+Yj8PSyM0Lkv1HszeWPEsFDk/OMGMYAKD+lB88ibTFavkHxi FemOhsxqSzvYdvy0Jn+EVPUxPW6sSRrvFXrcVYXzy7g+hZVv/F6eYvcDZyVK+yFcqLfz Qmkw== 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=s3i+WIeGruYqvfmdsIcMEvlSgChS4NMDvHTota+9ZIM=; b=on087/srXafU1TziQ78LQxZYh+jaqIFDdpe3sozKtakQrZzHMSbeksgMfd2aXWJrmh 2M17K2YYmX8n6Lj/mJipRFHNNmmUMTwXnTNYmps+DTIoQhmgDtTg1fxQrktWMejRMnXJ casm7vSLi5B+2CX2qhGMLVM+1k6rCXo/neLxxN0NvNpNmbd1Hu7K8X9HlJ249NhLqN7p S85x0wAHWLdBAkDFE9j9HDWNSXhsZRsZDF6ncFb1Yt57rUw134cmiKLzX1qC4jArEVbp qaELaVGP3/Fhzps3UwnFgD2Vo1zTRp1fkbC6Zgn36ON5P6q1MB4EIqsHP1QcM2JeGeiT meVg== X-Gm-Message-State: AIkVDXIbGlDsRcA/33H2LVUsFX1zsSZwX83yTOXYaH/80rN03J9Cn0zcg3BhplPfYTrgAv9IAyg3SvIJcJABOQ== X-Received: by 10.237.55.97 with SMTP id i88mr60332711qtb.143.1483481193408; Tue, 03 Jan 2017 14:06:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 3 Jan 2017 14:06:32 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> From: Martin Thomson Date: Wed, 4 Jan 2017 09:06:32 +1100 Message-ID: To: Roman Shpount Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Cullen Jennings , Christer Holmberg Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 22:06:36 -0000 On 4 January 2017 at 04:44, Roman Shpount wrote: > I agree, I think MD2 and MD5 should be defined in the grammar but > specification should state that they MUST NOT be used. This way there are no > potential backwards interop problems. To address Christer's original concern, I would say that you don't need a reference to the algorithms to achieve that. An informative reference is as far as you might go. From nobody Tue Jan 3 15:23: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 6505C1296D2; Tue, 3 Jan 2017 15:23:42 -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, 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 e1W2VjBQ6l5K; Tue, 3 Jan 2017 15:23:39 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 1AD26129489; Tue, 3 Jan 2017 15:23:39 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id c85so50636396wmi.1; Tue, 03 Jan 2017 15:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=R8b7nx3h9sjcj8vW/+hkDlOT6Q+PMl5eew0oKWnCYFX2X62ZpULrNBXW70XYsT6En8 rLTbhkWDo05p4yKyJWMlyTm8svY8B05hipzFtfEqYiXt5+EHihhxB1dyAAPKYqKqS5cR araqhUnU/xO6Ik91bgCr0Ck0D2i6O1j8fW/QNhlGebIIjmgUQfrM72cbtrVcN4Y6donc /ZqHAx1grpnNnRCfwEOrXPvUyZkmbtCf1tQHVeV5chswBqjrJcR+jOlZg8Y9H3FaktOP YCJaJd9J2GQwYJlmSqkqWfnx62VENZE6OH2Acvm6+Jlo1NHP3vkfRhB9Wp9AKNFvtvvb T22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AkHARHZY+XfXLQV3sHh78JQyhU1tfmZeiNhVSbXkLnc=; b=ggq2jWtHqeJQ55QzYpK50DCWqzYlh/Pg1VR14VXR3kS3LmS5fRgeL2QUxItuSjSWVp q//nyHJCtWBvDfogYSyraleCAifzEd/LlmMUCSHnboZsv24skVONxb32ldL5gW0BYU9I HC74Sz+x4wmTCDGbMl0DuJopN4UiSrfQw2SkQdnxC3wnrHcQ5dD/zsBj3RC4kkTISXyu Pszt7KcGI8Etby0x3ZFiqmKVq4u8uKKWeycXxJqDir5upXF3gxduakZJi9sFSqjpBGA7 EsyGQA7cEhcXCdkl49YxSmSA09nN41buyBzjVEHU8zjOXZEN90ouvqKvsy1i249vdYEX ek/A== X-Gm-Message-State: AIkVDXJfyrrdfWKKoy8TJtjJcId+3xOi7iuPB6xM8FZfMVosOEX15KFpfvNY2nuPe43tGw== X-Received: by 10.28.9.80 with SMTP id 77mr56746324wmj.68.1483485817526; Tue, 03 Jan 2017 15:23:37 -0800 (PST) Received: from alans-mbp.lan ([37.152.254.113]) by smtp.gmail.com with ESMTPSA id u78sm91845081wma.11.2017.01.03.15.23.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 15:23:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan Ford In-Reply-To: Date: Tue, 3 Jan 2017 23:23:35 +0000 Message-Id: <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> To: Roman Shpount X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ice@ietf.org" , "mmusic@ietf.org" , "bfcpbis@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 23:23:42 -0000 --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Roman, Do any of those work for having both tcp and udp ICE candidates? I = assume any with ICE (+ 4571 framing) would be acceptable for that case? Ideally we need to support the case where an answer=E2=80=99s m-line = protocol does not match any of the candidates, so that an answer could = only support TCP (say) when the offerer supported both (and used a UDP = m-line protocol). If Christer=E2=80=99s proposed change which permitted = an answer not to match the m-line protocol in the ICE candidates was = accepted, that would resolve this case. Do you see any problems here? Regards, Alan > On 3 Jan 2017, at 20:08, Roman Shpount wrote: >=20 > Charles, >=20 > I do not think not supporting ICE tcp candidates will quite work since = it will reduce the usability considerably. The simplest way to move = forward is to define a different transport tag for BFCP with RFC 4571 = over TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know = this looks strange and I am open to other suggestions, such as calling = all packet based protocols DBFCP).=20 >=20 > In general what I am proposing is: >=20 > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/BFCP -- BFCP over UDP or ICE udp candidates > TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp = candidates > UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates > TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over = ICE tcp candidates >=20 > Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other = protocols can work with NAT or ICE using normal ICE procedures. >=20 > If we call all packet based protocols DBFCP then transport tags will = be: >=20 > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/DBFCP -- DBFCP over UDP or ICE udp candidates > TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp = candidates > UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates > TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or = over ICE tcp candidates >=20 > Since BFCP over UDP (or other packet based protocols) is quite = different due to timers and transmission restrictions, it can have a = different transport tag and even be defined in a separate RFC. >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) = > wrote: > Crickets=E2=80=A6 >=20 > If no one is or has plans for using ICE with TCP/BFCP, perhaps it is = best to state that as of this rev of the BFCP spec, BFCP with TCP = candidates is not defined. Future updates to the spec may define this = usage. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: mmusic > on behalf of Charles Eckel = > > Date: Friday, December 2, 2016 at 4:01 PM > To: Roman Shpount > > Cc: "ice@ietf.org " >, "bfcpbis@ietf.org " = >, Christer Holmberg = >, "mmusic@ietf.org = " > > Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE >=20 > =20 >=20 > I have no experience with ICE with TCP candidates so hopefully others = can chime in as to what they think is a workable solution. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: Roman Shpount > > Date: Thursday, December 1, 2016 at 12:34 PM > To: Charles Eckel > > Cc: Alan Ford >, = "bfcpbis@ietf.org " >, "ice@ietf.org " = >, "mmusic@ietf.org = " >, = Christer Holmberg > > Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >=20 > =20 >=20 > Charles, >=20 > =20 >=20 > RFC 6544 Sending Media = (https://tools.ietf.org/html/rfc6544#section-10.1 = ) says that "The = framing defined in RFC 4571 MUST = be used when sending media." This means the protocol used is not = TCP/BFCP which is using application level framing. I believe that = STUN/Media demultiplexing requirements would prevent using TCP/BFCP = directly with ice tcp candidates without redesign of either ICE TCP or = TCP/BFCP. >=20 > =20 >=20 > Furthermore there are other implied ICE requirements that I outlined = before (switching between udp and tpc candidates, existence of SBC which = terminate ICE only but do not support the embedded protocol) because of = which ice tcp is considered unreliable transport and will require = fragmentation support and re-transmit timers that are not part of = TCP/BFCP. >=20 > =20 >=20 > Regards, >=20 >=20 >=20 > _____________ > Roman Shpount >=20 > =20 >=20 > On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) = > wrote: >=20 > Roman, >=20 > =20 >=20 > Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it = does, but after a quick scan I am not sure why. >=20 > =20 >=20 > Cheers, >=20 > Charles >=20 > =20 >=20 > From: Roman Shpount > > Date: Tuesday, November 29, 2016 at 10:38 AM > To: Charles Eckel > > Cc: Alan Ford >, = "bfcpbis@ietf.org " >, "ice@ietf.org " = >, "mmusic@ietf.org = " >, = Christer Holmberg > > Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >=20 > =20 >=20 > On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) = > wrote: >=20 > It seems to me that the most straightforward approach would be to = mandate support for BFCP over UDP when using ICE, use UDP as the default = candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we = can mandate the use of DTLS, that would be even better. >=20 > Thoughts? >=20 > =20 >=20 > =20 >=20 > I agree. >=20 > =20 >=20 > The only issue that I still have, if DTLS is not used, what protocol = is used when ICE tcp candidate is selected for transport. Is this = TCP/BFCP (which goes against RFC6544) or is it UDP/BFCP with RFC4571 = framing? If it is UDP/BFCP with RFC4571 framing, what transport tag = should be used in the re-INVITE which is sent after ICE nomination with = only selected candidate? Should it be TCP/UDP/BFCP or something similar? >=20 > =20 >=20 > Regards, >=20 > _____________ > Roman Shpount >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Roman,

Do = any of those work for having both tcp and udp ICE candidates? I assume = any with ICE (+ 4571 framing) would be acceptable for that = case?

Ideally = we need to support the case where an answer=E2=80=99s m-line protocol = does not match any of the candidates, so that an answer could only = support TCP (say) when the offerer supported both (and used a UDP m-line = protocol). If Christer=E2=80=99s proposed change which permitted an = answer not to match the m-line protocol in the ICE candidates was = accepted, that would resolve this case. Do you see any problems = here?

Regards,
Alan

On = 3 Jan 2017, at 20:08, Roman Shpount <roman@telurix.com> = wrote:

Charles,

I do not think not supporting ICE tcp candidates will quite = work since it will reduce the usability considerably. The simplest way = to move forward is to define a different transport tag for BFCP =  with RFC 4571 over TCP not to confuse it with TCP/BFCP. It can be = TCP/UDP/BFCP (I know this looks strange and I am open to other = suggestions, such as calling all packet based protocols = DBFCP). 

In= general what I am proposing is:

TCP/BFCP -- existing BFCP over = TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/BFCP -- BFCP over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or = over ICE tcp candidates
UDP/DTLS/BFCP = -- BFCP over DTLS or over ICE udp candidates
TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 = framing over TCP or over ICE tcp candidates

Legacy BFCP over TCP or TLS cannot work = with ICE or NAT. Other protocols can work with NAT or ICE using normal = ICE procedures.

If we call all packet based protocols DBFCP then transport = tags will be:

TCP/BFCP -- existing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UDP/DBFCP -- DBFCP over UDP or ICE udp candidates
TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or = over ICE tcp candidates
UDP/DTLS/DBFCP= -- DBFCP over DTLS or over ICE udp candidates
TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 = framing over TCP or over ICE tcp candidates

Since BFCP over UDP (or other = packet based protocols) is quite different due to timers and = transmission restrictions, it can have a different transport tag and = even be defined in a separate RFC.

Regards,

_____________
Roman = Shpount

On Tue, Jan 3, 2017 at 2:43 = PM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for = using ICE with TCP/BFCP, perhaps it is best to state that as of this rev = of the BFCP spec, BFCP with TCP candidates is not defined. Future = updates to the spec may define this usage.

 

Cheers,

Charles

 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Charles Eckel = <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
= To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf.org" <ice@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg = <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in = case of ICE

 

I have no experience with ICE with TCP = candidates so hopefully others can chime in as to what they think is a = workable solution.

 

Cheers,

Charles

 

From: Roman Shpount = <roman@telurix.com>
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg = <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in = case of ICE

 

Charles,

 

RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1) says that "The framing defined in RFC = 4571 MUST be used = when sending media." This means the protocol used is not TCP/BFCP which = is using application level framing. I believe that STUN/Media demultiplexing requirements would = prevent using TCP/BFCP directly with ice tcp candidates without redesign = of either ICE TCP or TCP/BFCP.

 

Furthermore there are other implied ICE requirements = that I outlined before (switching between udp and tpc candidates, = existence of SBC which terminate ICE only but do not support the = embedded protocol) because of which ice tcp is considered unreliable transport = and will require fragmentation support and re-transmit timers that are = not part of TCP/BFCP.

 

Regards,


_____________
Roman Shpount

 

On Thu, Dec 1, 2016 at 3:17 PM, = Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Roman,

 

Why would selecting TCP/BFCP = as transport violate RFC 6544? Perhaps it does, but after a quick scan I = am not sure why.

 

Cheers,

Charles

 

From: Roman = Shpount <roman@telurix.com>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in = case of ICE

 

On Tue, Nov 29, 2016 at 12:48 PM, = Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

It seems to me that the most = straightforward approach would be to mandate support for BFCP over UDP = when using ICE, use UDP as the default candidate, and signal the BFCP = m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that = would be even better.

Thoughts?

 

 

I agree.

 

The only issue that I still have, = if DTLS is not used, what protocol is used when ICE tcp candidate = is selected for transport. Is this TCP/BFCP (which goes against = RFC6544)  or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 = framing, what transport tag should be used in the re-INVITE which is = sent after ICE nomination with only selected candidate? Should it be = TCP/UDP/BFCP or something similar?

=

 

Regards,

_____________
Roman Shpount

 

 


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

= --Apple-Mail=_08AEB35B-C7EA-4835-939D-0F9C88F9998B-- From nobody Tue Jan 3 15:45:05 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 B4CE11294CA for ; Tue, 3 Jan 2017 15:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=unavailable 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 yK4cv-21VxB2 for ; Tue, 3 Jan 2017 15:44:57 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 CCCE71294BA for ; Tue, 3 Jan 2017 15:44:56 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u25so380629205qki.2 for ; Tue, 03 Jan 2017 15:44:56 -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=Pu65gb48CRUseGZeKNMMzv6tCkKbSWV0Ws0de+ymHPo=; b=zGLQWuWu0mSpnnBjaDzrRoTOfcCKYUHR0QA3LtOCT2Mguswwdw7ZnOGyTm50pnTVPI o5VFN59gSOxeDD16TnB1X+/qj9nWTKc8wXvf5pmWEavUnAlmIJc7c/5WZNFwwl7J1HNl pcsPZ7m2OMfPD51G/jimxNFK1WF+YBSF0cRh1ZldZtvvpaUghQw038NK4nkzDOrWXH38 +uiB6OmZvA1olfaCq1AJzXNb49XcraYubUV4pbYc4J0vX5RgGDSc8u3xpI58kcTTEK1O pm2sgDN83w2QhDOM9jzHB1ACi1GQAzwIvj74oyIcddLeD+sN7StTDBQqoG6eSz3PYJdm 0eVQ== 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=Pu65gb48CRUseGZeKNMMzv6tCkKbSWV0Ws0de+ymHPo=; b=sL1FTMr7S0IhznyH0jjw5z1STGdCwopYHBJaI3g6fipX0/K2h/Fr9uUgXnQRFhZxH3 IIe4kEbpoTPTj01gfV/hNnsmze+32iLLwzZ8I8EKSt05wCt+x/I1CgJrbDQa8PIjc2a3 eDh+SqgfL3+aFnErJzma/JQOSsDC2mBTpCTYSxamZc5n9Fm4mFPg92oWYLkLKAh2l44u yTA7XU8AO4kW6NpT9c1UoT97whyv/mz/Qc1uBxT0rG/tcq17W+Z93Lta7TqQ2Aa96fKV KvsIbgDKpMhFNmV5A/5uXfIxPdl6KWhMErB7vGI49zcnng5Fft0c+KygAn06RXbscYwD TqLg== X-Gm-Message-State: AIkVDXLgRdJA1LcF3ZfiSNdAqvUsd+KmLSW0q45XdMxlelQl8l5jyc8R76ijStKXVnK6uQ== X-Received: by 10.55.110.69 with SMTP id j66mr70590785qkc.92.1483487095868; Tue, 03 Jan 2017 15:44:55 -0800 (PST) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com. [209.85.220.177]) by smtp.gmail.com with ESMTPSA id h47sm44734971qtc.27.2017.01.03.15.44.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 15:44:55 -0800 (PST) Received: by mail-qk0-f177.google.com with SMTP id t184so391765693qkd.0; Tue, 03 Jan 2017 15:44:55 -0800 (PST) X-Received: by 10.55.142.1 with SMTP id q1mr59800932qkd.225.1483487095063; Tue, 03 Jan 2017 15:44:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.136.230 with HTTP; Tue, 3 Jan 2017 15:44:54 -0800 (PST) In-Reply-To: <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> <739486DE-BDFA-48FD-ACBA-41E45D208748@gmail.com> From: Roman Shpount Date: Tue, 3 Jan 2017 18:44:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Alan Ford Content-Type: multipart/alternative; boundary=94eb2c0830de5493180545394135 Archived-At: Cc: "ice@ietf.org" , "mmusic@ietf.org" , "bfcpbis@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 03 Jan 2017 23:45:01 -0000 --94eb2c0830de5493180545394135 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alan, TCP/BFCP and TLS/BFCP will not work with ICE. Or, to be more precise, will not work without some specification changes either in ICE tcp or in BFCP. One pair of protocols which will work with ICE is UDP/DTLS/BFCP and TCP/DTLS/BFCP. It will support both tcp and udp candidates. I think this pair should be recommended since it provides encryption. Another pair that will work with ICE is UDP/BFCP and TCP/UDP/BFCP. It will also support tcp and udp candidates. It is not something I would use over public internet since it will transmit data in the clear text. Finally, I prefer that any end point which implement BFCP and supports ICE and DTLS, MUST support UDP/DTLS/BFCP and use it for default candidate. Any endpoint which implements BFCP and ICE, but does not support DTLS, MUST support UDP/BFCP and use it as a default candidate. Once the ICE candidate pair is selected, the transport matching the selected candidate pair should be used in the SDP. There is no practical need for the asymmetric transport tags. I think the whole thing is coming from the confusion that TCP/BFCP can be used with ICE tcp candidates. It cannot without some specification changes. Also, there is no reason to use TCP/DTLS/BFCP or TCP/UDP/BFCP, unless ICE is used. Because of this, there is no reason to use either of those transports for default candidate, since default candidate is selected for interop with end points not supporting ICE. Regards, _____________ Roman Shpount On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford wrote: > Roman, > > Do any of those work for having both tcp and udp ICE candidates? I assume > any with ICE (+ 4571 framing) would be acceptable for that case? > > Ideally we need to support the case where an answer=E2=80=99s m-line prot= ocol does > not match any of the candidates, so that an answer could only support TCP > (say) when the offerer supported both (and used a UDP m-line protocol). I= f > Christer=E2=80=99s proposed change which permitted an answer not to match= the > m-line protocol in the ICE candidates was accepted, that would resolve th= is > case. Do you see any problems here? > > Regards, > Alan > > On 3 Jan 2017, at 20:08, Roman Shpount wrote: > > Charles, > > I do not think not supporting ICE tcp candidates will quite work since it > will reduce the usability considerably. The simplest way to move forward = is > to define a different transport tag for BFCP with RFC 4571 over TCP not = to > confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this looks stran= ge > and I am open to other suggestions, such as calling all packet based > protocols DBFCP). > > In general what I am proposing is: > > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/BFCP -- BFCP over UDP or ICE udp candidates > TCP/UDP/BFCP -- BFCP with RFC 4571 framing over TCP or over ICE tcp > candidates > UDP/DTLS/BFCP -- BFCP over DTLS or over ICE udp candidates > TCP/DTLS/BFCP -- BFCP over DTLS with RFC 4571 framing over TCP or over IC= E > tcp candidates > > Legacy BFCP over TCP or TLS cannot work with ICE or NAT. Other protocols > can work with NAT or ICE using normal ICE procedures. > > If we call all packet based protocols DBFCP then transport tags will be: > > TCP/BFCP -- existing BFCP over TCP > TLS/BFCP -- exisitng BFCP over TLS > UDP/DBFCP -- DBFCP over UDP or ICE udp candidates > TCP/DBFCP -- DBFCP with RFC 4571 framing over TCP or over ICE tcp > candidates > UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates > TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing over TCP or over > ICE tcp candidates > > Since BFCP over UDP (or other packet based protocols) is quite different > due to timers and transmission restrictions, it can have a different > transport tag and even be defined in a separate RFC. > > Regards, > > _____________ > Roman Shpount > > On Tue, Jan 3, 2017 at 2:43 PM, Charles Eckel (eckelcu) > wrote: > >> Crickets=E2=80=A6 >> >> If no one is or has plans for using ICE with TCP/BFCP, perhaps it is bes= t >> to state that as of this rev of the BFCP spec, BFCP with TCP candidates = is >> not defined. Future updates to the spec may define this usage. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *mmusic on behalf of Charles Eckel < >> eckelcu@cisco.com> >> *Date: *Friday, December 2, 2016 at 4:01 PM >> *To: *Roman Shpount >> *Cc: *"ice@ietf.org" , "bfcpbis@ietf.org" , >> Christer Holmberg , "mmusic@ietf.org" < >> mmusic@ietf.org> >> *Subject: *Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE >> >> >> >> I have no experience with ICE with TCP candidates so hopefully others ca= n >> chime in as to what they think is a workable solution. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *Roman Shpount >> *Date: *Thursday, December 1, 2016 at 12:34 PM >> *To: *Charles Eckel >> *Cc: *Alan Ford , "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < >> mmusic@ietf.org>, Christer Holmberg >> *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >> >> >> >> Charles, >> >> >> >> RFC 6544 Sending Media (https://tools.ietf.org/html/rfc6544#section-10.1= ) says >> that "The framing defined in RFC 4571 >> MUST be used when sending media." >> This means the protocol used is not TCP/BFCP which is using application >> level framing. I believe that STUN/Media demultiplexing requirements wou= ld >> prevent using TCP/BFCP directly with ice tcp candidates without redesign= of >> either ICE TCP or TCP/BFCP. >> >> >> >> Furthermore there are other implied ICE requirements that I outlined >> before (switching between udp and tpc candidates, existence of SBC which >> terminate ICE only but do not support the embedded protocol) because of >> which ice tcp is considered unreliable transport and will require >> fragmentation support and re-transmit timers that are not part of TCP/BF= CP. >> >> >> >> Regards, >> >> >> _____________ >> Roman Shpount >> >> >> >> On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >> Roman, >> >> >> >> Why would selecting TCP/BFCP as transport violate RFC 6544? Perhaps it >> does, but after a quick scan I am not sure why. >> >> >> >> Cheers, >> >> Charles >> >> >> >> *From: *Roman Shpount >> *Date: *Tuesday, November 29, 2016 at 10:38 AM >> *To: *Charles Eckel >> *Cc: *Alan Ford , "bfcpbis@ietf.org" < >> bfcpbis@ietf.org>, "ice@ietf.org" , "mmusic@ietf.org" < >> mmusic@ietf.org>, Christer Holmberg >> *Subject: *Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE >> >> >> >> On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel (eckelcu) < >> eckelcu@cisco.com> wrote: >> >> It seems to me that the most straightforward approach would be to mandat= e >> support for BFCP over UDP when using ICE, use UDP as the default candida= te, >> and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate = the >> use of DTLS, that would be even better. >> >> Thoughts? >> >> >> >> >> >> I agree. >> >> >> >> The only issue that I still have, if DTLS is not used, what protocol is >> used when ICE tcp candidate is selected for transport. Is this TCP/BFCP >> (which goes against RFC6544) or is it UDP/BFCP with RFC4571 framing? If= it >> is UDP/BFCP with RFC4571 framing, what transport tag should be used in t= he >> re-INVITE which is sent after ICE nomination with only selected candidat= e? >> Should it be TCP/UDP/BFCP or something similar? >> >> >> >> Regards, >> >> _____________ >> Roman Shpount >> >> >> >> >> >> > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > > > --94eb2c0830de5493180545394135 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan,

TCP/BFCP and=C2=A0TLS/BFCP will not work with ICE. Or, to be more precise, w= ill not work without some specification changes either in ICE tcp or in BFC= P.

<= /span>
One pair= of protocols which will work with ICE is UDP/DTLS/BFCP and=C2=A0TCP/DTLS/BFCP. It wil= l support both tcp and udp candidates. I think this pair should be recommen= ded since it provides encryption.=C2=A0

= Another pair that = will work with ICE is=C2=A0UDP/BFCP and=C2=A0TCP/UDP/BFCP. It will also support tcp and udp candidates. = It is not something I would use over public internet since it will transmit= data in the clear text.

Finally, I prefer that any end point which implement BFCP= and supports ICE and DTLS, MUST support=C2=A0UDP/DTLS/BFCP and use it=C2=A0for default candidate. Any e= ndpoint which implements=C2=A0BFCP and ICE, but does not support DTLS, MUST= support UDP/BFCP and use it as a default candidate.=C2=A0

Once the ICE candidate pair is selected, the transport matching the select= ed candidate pair should be used in the SDP.

=
There is no p= ractical need for the asymmetric transport tags. I think the whole thing is= coming from =C2=A0the confusion that TCP/BFCP can be used with ICE tcp can= didates. It cannot without some specification changes. Also, there is no re= ason to use=C2=A0TCP/DTLS/BFCP or=C2=A0TCP/UDP/BFCP, unless ICE is used. Because of this, there is no re= ason to use either of those transports for default candidate, since default= candidate is selected for interop with end points not supporting ICE.

<= /span>
Regards,

_____________
Roman Shpount

On Tue, Jan 3, 2017 at 6:23 PM, Alan Ford <alan.ford@gmail.com> wrote:
Roman,

Do any of = those work for having both tcp and udp ICE candidates? I assume any with IC= E (+ 4571 framing) would be acceptable for that case?

<= div>Ideally we need to support the case where an answer=E2=80=99s m-line pr= otocol does not match any of the candidates, so that an answer could only s= upport TCP (say) when the offerer supported both (and used a UDP m-line pro= tocol). If Christer=E2=80=99s proposed change which permitted an answer not= to match the m-line protocol in the ICE candidates was accepted, that woul= d resolve this case. Do you see any problems here?

Regards,
Alan

=
On 3 Jan 2017, at 20:08, Roman Shpount <roman@telurix.com> w= rote:

Charles,

I do not think not supporting ICE tcp candidates will quite work si= nce it will reduce the usability considerably. The simplest way to move for= ward is to define a different transport tag for BFCP =C2=A0with RFC 4571 ov= er TCP not to confuse it with TCP/BFCP. It can be TCP/UDP/BFCP (I know this= looks strange and I am open to other suggestions, such as calling all pack= et based protocols DBFCP).=C2=A0

In general what I= am proposing is:

TCP/BFCP -- existing BFCP over T= CP
TLS/BFCP -- exisitng BFCP over TLS
UDP/BFCP -- BFCP = over UDP or ICE udp candidates
TCP/UDP/BFCP -- BFCP with RFC 4571= framing=C2=A0over TCP or over ICE tcp candidates
UDP/DTLS/BF= CP -- BFCP over DTLS or over ICE udp candidates
TCP/DTLS/BFCP -- = BFCP over DTLS with RFC 4571 framing=C2=A0over TCP or over ICE tcp candidat= es

Legacy BFCP over TCP or TLS cannot work with IC= E or NAT. Other protocols can work with NAT or ICE using normal ICE procedu= res.

If we call all packet based protocols DBFCP t= hen transport tags will be:

TCP/BFCP -- exist= ing BFCP over TCP
TLS/BFCP -- exisitng BFCP over TLS
UD= P/DBFCP -- DBFCP over UDP or ICE udp candidates
TCP/DBFCP -- DBFC= P with RFC 4571 framing=C2=A0over TCP or over ICE tcp candidates
<= div>UDP/DTLS/DBFCP -- DBFCP over DTLS or over ICE udp candidates
= TCP/DTLS/DBFCP -- DBFCP over DTLS with RFC 4571 framing=C2=A0over TCP or ov= er ICE tcp candidates

Since BFCP over UDP (o= r other packet based protocols) is quite different due to timers and transm= ission restrictions, it can have a different transport tag and even be defi= ned in a separate RFC.

Regards,

_____________
Ro= man Shpount

On Tue, Jan 3, 2017 at 2:43 PM, Charles Ecke= l (eckelcu) <eckelcu@cisco.com> wrote:

Crickets=E2=80=A6

If no one is or has plans for using ICE with TCP/BFCP, perhaps it is best= to state that as of this rev of the BFCP spec, BFCP with TCP candidates is= not defined. Future updates to the spec may define this usage.

=C2=A0

Cheers,

Charles

<= p class=3D"MsoNormal">=C2=A0

From= : mmusic <mmusic-bounces@ietf.org> on beh= alf of Charles Eckel <eckelcu@cisco.com>
Date: Friday, December 2, 2016 at 4:01 PM
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf= .org" <ice@ie= tf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Christer Holmberg <christer.holmberg@eric= sson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [bfcpbis] m=3D line protocol in case of ICE=

=C2=A0

I have no experience with ICE with TCP candida= tes so hopefully others can chime in as to what they think is a workable so= lution.

=C2=A0

Cheers,

Charles

=C2=A0

From= : Roman Shpount <roman@telurix.com>
Date: Thursday, December 1, 2016 at 12:34 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>, "mmusic@ietf.org" <= ;mmusic@ietf.org&g= t;, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

Charles,

=C2=A0

RFC 6544 Sending Media (https://tools.ietf.= org/html/rfc6544#section-10.1)=C2=A0says that "The framing defined in RFC 4571 MUST be used when sending media." This means the protocol used = is not TCP/BFCP which is using application level framing. I believe that STUN/Media demultiplexing requirements would preve= nt using TCP/BFCP directly with ice tcp candidates without redesign of eith= er ICE TCP or TCP/BFCP.

=C2=A0

Furthermore=C2= =A0there are other implied ICE requirements that I outlined before (switchi= ng between udp and tpc candidates, existence of SBC which terminate ICE onl= y but do not support the embedded protocol) because of which ice tcp is considered unreliable transport and = will require fragmentation support and re-transmit timers that are not part= of TCP/BFCP.

=C2=A0

Regards,<= u>


_____________
Roman Shpount

=C2=A0

On Thu, Dec 1, 2016 at 3:17 PM, Charles Eckel (= eckelcu) <eckelcu= @cisco.com> wrote:

Roman,

= =C2=A0

Why would selecting TCP/BFCP= as transport violate RFC 6544? Perhaps it does, but after a quick scan I a= m not sure why.

=C2=A0

Cheers,

Charles

=C2=A0

From= : Roman Shpount <roman@telurix.com>
Date: Tuesday, November 29, 2016 at 10:38 AM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Alan Ford <alan.ford@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "ice@ietf.org" <ice@ietf.org>= , "mmusic@ietf.or= g" <mmusic= @ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com&g= t;
Subject: Re: [bfcpbis] [MMUSIC] m=3D line protocol in case of ICE

=C2=A0

On Tue, Nov 29, 2016 at 12:48 PM, Charles Eckel= (eckelcu) <eckel= cu@cisco.com> wrote:

It seems to me that the most straightforward ap= proach would be to mandate support for BFCP over UDP when using ICE, use UD= P as the default candidate, and signal the BFCP m-line as if it is BFCP over UDP. If we can mandate the use of DTLS, that would b= e even better.

Thoughts?<= /u>

=C2=A0

=C2=A0

I agree.

=C2=A0

The only issue that I still have, if DTLS is no= t used, what protocol is used when ICE tcp candidate is=C2=A0selected for t= ransport. Is this TCP/BFCP (which goes against RFC6544) =C2=A0or is it UDP/BFCP with RFC4571 framing? If it is UDP/BFCP with RFC4571 framin= g, what transport tag should be used in the re-INVITE which is sent after I= CE nomination with only selected candidate? Should it be TCP/UDP/BFCP or so= mething similar?

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

=C2=A0


_______________________________________________
bfcpbis mailing lis= t
bfcpbis@ietf.org=
https://www.ietf.org/mailman/listinfo/bfcpbis


--94eb2c0830de5493180545394135-- From nobody Wed Jan 4 03:22: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 E1F901293EC for ; Wed, 4 Jan 2017 03:22:11 -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 gclSAmt6SMW8 for ; Wed, 4 Jan 2017 03:22:10 -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 D745C128AB0 for ; Wed, 4 Jan 2017 03:22:09 -0800 (PST) X-AuditID: c1b4fb30-92fff70000007ae2-48-586cdade6998 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id B4.3A.31458.EDADC685; Wed, 4 Jan 2017 12:22:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 12:22:45 +0100 From: Christer Holmberg To: Martin Thomson , Roman Shpount Thread-Topic: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs Thread-Index: AdJigL/3HmdriiVMRVGMYSdDZzSqOwADa/tQAGF4AYAANAiaQAANbYuAADFHBoAAAFj2AAAJJncAAB0+kFA= Date: Wed, 4 Jan 2017 11:22:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF56AF4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7ge6DWzkRBmtvCVh8WP+D0WL/4vPM FtfO/GO0mLr8MYvFjAtTmR1YPXbOusvusWTJTyaPy+c/MnrcmlLg0fbsDnsAaxSXTUpqTmZZ apG+XQJXxqf3B5kLLilV7Gz5xtLA+ECxi5GTQ0LARGL/i2VMXYxcHEIC6xglLnXdZgJJCAks ZpSYNkW7i5GDg03AQqL7nzZIWEQgSOLhw8csIDazQIHEo3Un2EFsYYFEiY8netkgapIk3jRv YYSxr688zwwyhkVAReLhCWkQk1fAV+LZdj+IrQtZJFZsvsAKUs4pECjRuO8VmM0oICbx/dQa JohV4hK3nsxngjhZQGLJHpCRILaoxMvH/1ghbCWJxiVPWEHmMwtoSqzfpQ/Rqigxpfsh2JW8 AoISJ2c+YZnAKDoLydRZCB2zkHTMQtKxgJFlFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg ZB3c8ttgB+PL546HGAU4GJV4eAv2ZEcIsSaWFVfmHmKU4GBWEuG1vJkTIcSbklhZlVqUH19U mpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILUIpgsEwenVAPjJln/Qxt3tm8s+ZM5ayO/pYkb s/Ta5TkeH/90TGDctLwnP8Jwbu0K7tu84ol1CexfL5xbXB1en7rs6bbLc6u7D8w4aKbK6Vqa sfjYo+7AmJgrNyuX/b39sVN4xYZHF+4lZTRp3I/W/19d5HQjz0zmU5LANbvFqxeaJ855teWe Yuqs8CLzvf/XKrEUZyQaajEXFScCADQY3fKoAgAA Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jan 2017 11:22:12 -0000 T2ssIHRvIG1ha2Ugc3VyZSB3ZSBhcmUgYWxsIG9uIHRoZSBzYW1lIHBhZ2UsIGJlbG93IGFyZSB0 aGUgcGxhY2VzIGluIHRoZSBwcmV2aW91cyB2ZXJzaW9uICgtMDgpIG9mIHRoZSBkcmFmdCB3aGVy ZSBNRDIgYW5kIE1ENSBhcmUgbWVudGlvbmVkLCBhbmQgbXkgc3VnZ2VzdGlvbiBvbiB3aGF0L2lm IHRvIGRvOg0KDQoNClNlY3Rpb24gNToNCi0tLS0tLS0tLS0tLS0NCg0KImhhc2gtZnVuYyAgICAg ICAgICAgICAgPSAgInNoYS0xIiAvICJzaGEtMjI0IiAvICJzaGEtMjU2IiAvDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICJzaGEtMzg0IiAvICJzaGEtNTEyIiAvDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJtZDUiIC8gIm1kMiIgLyB0b2tlbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA7IEFkZGl0aW9uYWwgaGFzaCBmdW5jdGlvbnMgY2FuIG9ubHkgY29tZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA7IGZyb20gdXBkYXRlcyB0byBSRkMgMzI3OSINCg0K Q2hyaXN0ZXIncyBzdWdnZXN0aW9uOiBLZWVwIHRoZSB0ZXh0IGFzIGl0IGlzLg0KDQotLS0tLS0t LS0tLS0tDQoNCiAgICJGb2xsb3dpbmcgUkZDIDMyNzkgWzddIGFzIHVwZGF0ZWQgYnkgUkZDIDQw NTUgWzldLCB0aGVyZWZvcmUsIHRoZQ0KICAgZGVmaW5lZCBoYXNoIGZ1bmN0aW9ucyBhcmUgJ1NI QS0xJyBbMV0gWzE4XSwgJ1NIQS0yMjQnIFsxXSwgJ1NIQS0yNTYnDQogICBbMV0sICdTSEEtMzg0 J1sxXSwgJ1NIQS01MTInIFsxXSwgJ01ENScgWzRdLCBhbmQgJ01EMicgWzNdLCB3aXRoDQogICAn U0hBLTI1NicgcHJlZmVycmVkLiAgQSBuZXcgSUFOQSByZWdpc3RyeSBvZiBIYXNoIEZ1bmN0aW9u IFRleHR1YWwNCiAgIE5hbWVzLCBzcGVjaWZpZWQgaW4gU2VjdGlvbiA4LCBhbGxvd3MgZm9yIGFk ZGl0aW9uIG9mIGZ1dHVyZSB0b2tlbnMsDQogICBidXQgdGhleSBtYXkgb25seSBiZSBhZGRlZCBp ZiB0aGV5IGFyZSBpbmNsdWRlZCBpbiBSRkNzIHRoYXQgdXBkYXRlDQogICBvciBvYnNvbGV0ZSBS RkMgMzI3OSBbN10uIg0KDQpDaHJpc3RlcidzIHN1Z2dlc3Rpb246IEtlZXAgdGhlIHRleHQsIGJ1 dCB1cGRhdGUgdGhlIE1EMiBhbmQgTUQ1IHJlZmVyZW5jZXMgKFszXSBhbmQgWzRdKSwgYW5kIGFk ZCB0aGUgZm9sbG93aW5nIG5ldyBwYXJhZ3JhcGggdGV4dDoNCg0KIkZvciBiYWNrd2FyZCBjb21w YXRpYmlsaXR5IHdpdGggaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB3aXRoIFJGQyA0NTcyLCB0 aGUgTUQyIGFuZCBNRDUgY2lwaGVyIHN1aXRlIGFyZSBzdGlsbCBsaXN0ZWQgaW4gdGhlIHN5bnRh eC4gSG93ZXZlciwgaW1wbGVtZW50YXRpb25zIGNvbXBsaWFudCB0byB0aGlzIHNwZWNpZmljYXRp b24gTVVTVCBOT1QgdXNlIHRoZW0uIg0KDQoNClNlY3Rpb24gODoNCi0tLS0tLS0tLS0tLS0NCg0K IlRhYmxlIDEgY29udGFpbnMgdGhlIGluaXRpYWwgdmFsdWVzIG9mIHRoaXMgcmVnaXN0cnkuDQoN CiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLSsNCiAgICAgICAgfCBIYXNoIEZ1bmN0aW9uIE5hbWUgfCAgICAgICAgICBPSUQg ICAgICAgICAgIHwgUmVmZXJlbmNlIHwNCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLSsNCiAgICAgICAgfCAgICAgICAibWQy IiAgICAgICAgfCAgIDEuMi44NDAuMTEzNTQ5LjIuMiAgIHwgIFJGQyAzMjc5IHwNCiAgICAgICAg fCAgICAgICAibWQ1IiAgICAgICAgfCAgIDEuMi44NDAuMTEzNTQ5LjIuNSAgIHwgIFJGQyAzMjc5 IHwNCiAgICAgICAgfCAgICAgICJzaGEtMSIgICAgICAgfCAgICAgMS4zLjE0LjMuMi4yNiAgICAg IHwgIFJGQyAzMjc5IHwNCiAgICAgICAgfCAgICAgInNoYS0yMjQiICAgICAgfCAyLjE2Ljg0MC4x LjEwMS4zLjQuMi40IHwgIFJGQyA0MDU1IHwNCiAgICAgICAgfCAgICAgInNoYS0yNTYiICAgICAg fCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi4xIHwgIFJGQyA0MDU1IHwNCiAgICAgICAgfCAgICAgInNo YS0zODQiICAgICAgfCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi4yIHwgIFJGQyA0MDU1IHwNCiAgICAg ICAgfCAgICAgInNoYS01MTIiICAgICAgfCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi4zIHwgIFJGQyA0 MDU1IHwNCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLSsiDQoNCkNocmlzdGVyJ3Mgc3VnZ2VzdGlvbjogS2VlcCB0aGUgYWJv dmUgdGV4dCwgd2l0aG91dCBjaGFuZ2VzLiBUaGlzIGlzIHRoZSBpbml0aWFsIElBTkEgcmVnaXN0 cmF0aW9uLCBhbmQgd2UgZG9uJ3QgY2hhbmdlIHRoYXQuDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9t c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IDA0IEphbnVhcnkg MjAxNyAwMDowNw0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KQ2M6IEN1 bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT47IEpvbmF0aGFuIExlbm5veCA8am9uYXRoYW5A dmlkeW8uY29tPjsgbW11c2ljQGlldGYub3JnOyBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIGRyYWZ0LTQ1NzIt dXBkYXRlOiBTcGVjIGNvbnRhaW5zIHJlZmVyZW5jZXMgdG8gYSBudW1iZXIgb2Ygb2Jzb2xldGVk IFJGQ3MNCg0KT24gNCBKYW51YXJ5IDIwMTcgYXQgMDQ6NDQsIFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPiB3cm90ZToNCj4gSSBhZ3JlZSwgSSB0aGluayBNRDIgYW5kIE1ENSBzaG91 bGQgYmUgZGVmaW5lZCBpbiB0aGUgZ3JhbW1hciBidXQgDQo+IHNwZWNpZmljYXRpb24gc2hvdWxk IHN0YXRlIHRoYXQgdGhleSBNVVNUIE5PVCBiZSB1c2VkLiBUaGlzIHdheSB0aGVyZSANCj4gYXJl IG5vIHBvdGVudGlhbCBiYWNrd2FyZHMgaW50ZXJvcCBwcm9ibGVtcy4NCg0KVG8gYWRkcmVzcyBD aHJpc3RlcidzIG9yaWdpbmFsIGNvbmNlcm4sIEkgd291bGQgc2F5IHRoYXQgeW91IGRvbid0IG5l ZWQgYSByZWZlcmVuY2UgdG8gdGhlIGFsZ29yaXRobXMgdG8gYWNoaWV2ZSB0aGF0LiAgQW4gaW5m b3JtYXRpdmUgcmVmZXJlbmNlIGlzIGFzIGZhciBhcyB5b3UgbWlnaHQgZ28uDQo= From nobody Wed Jan 4 06:31: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 1162E129583 for ; Wed, 4 Jan 2017 06:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 Zn7eiQGVUY8s for ; Wed, 4 Jan 2017 06:31:21 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 5BBE5129451 for ; Wed, 4 Jan 2017 06:31:21 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id t184so408055553qkd.0 for ; Wed, 04 Jan 2017 06:31:21 -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=2EgB+YSG8JvA3YrhsDRFC1EhBaf6IiXVOioJx4MRKcQ=; b=Q6+4nnCco/HRVEPcnLPCChGnuz/6y4jYRgpWjMfcP50U2xvb8tD0V4ikUIG4YXB8iz xakfU0wUPpoMJnz0HFOCwhBu6D0ofUqWtStBnN9HRdSQywXzUVaO2MAIOfdu/GjTV+hg 8X18/EEyhfmHj/xxcmV+gE93XnJr8i/9FIM/HaFOLISfVZikAQ/0Lyd4stcgUZlbFasi STAUfhh4AO7XnTQx3W3zPa6WkOofDKAvE6H3nocvP8l9Gq/S5liefG64exf3DamciSQr NKt4xXQoQMK5BQIkKdYC+9CKC/aEDzdxXZRJBElvig02JILgrVBnQk1JOfWBVzQ0um97 2MGg== 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=2EgB+YSG8JvA3YrhsDRFC1EhBaf6IiXVOioJx4MRKcQ=; b=RIX5B4GmMgfuPyb9Y1QDKnrECBB1RtV3tfZnS6dBkscMrztXF6mOOD/zE8hXnqE6Xz u+GHuLyYjTy/lXMv18f4PFjEHoT8CHtSRIjthG3TiH4U6lpq0aN+Sr/wd4AX0t+dqUd2 hfFCZmy6VfWyHOZfpU8zRGDNpCrAVAD8he6d67bWVbbpuPdnqOmqKjHXxhmc6UGQ8j6N df9s0P/J5Kd2QZXYjaERG8MYw27MwU3vWD61kLXPp218+MktjHlCQD7fe3WDx+Vd7CqX Lo0W3+Z+4kKz1LtUKL/dzOR5CQ+A4lolvKNGRmMTVqN4JFcHf+T61YpepB9CMERW3ur8 GIEA== X-Gm-Message-State: AIkVDXJlR8Ib7RBdXLmYDNm2UtBdLYrcFLVPOJ9qawH/F73FNz/gopiYEdCk97Z0p/lhEg== X-Received: by 10.55.70.76 with SMTP id t73mr63934522qka.195.1483540280466; Wed, 04 Jan 2017 06:31:20 -0800 (PST) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com. [209.85.220.176]) by smtp.gmail.com with ESMTPSA id i187sm45933299qkd.20.2017.01.04.06.31.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 06:31:20 -0800 (PST) Received: by mail-qk0-f176.google.com with SMTP id t184so408055012qkd.0 for ; Wed, 04 Jan 2017 06:31:19 -0800 (PST) X-Received: by 10.55.161.212 with SMTP id k203mr716974qke.234.1483540279575; Wed, 04 Jan 2017 06:31:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Wed, 4 Jan 2017 06:31:19 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF56AF4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> <7594FB04B1934943A5C02806D1A2204B4BF56AF4@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 4 Jan 2017 09:31:19 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c06e7945fd2ba054545a3ee Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jan 2017 14:31:23 -0000 --94eb2c06e7945fd2ba054545a3ee Content-Type: text/plain; charset=UTF-8 This looks good to me _____________ Roman Shpount On Wed, Jan 4, 2017 at 6:22 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Ok, to make sure we are all on the same page, below are the places in the > previous version (-08) of the draft where MD2 and MD5 are mentioned, and my > suggestion on what/if to do: > > > Section 5: > ------------- > > "hash-func = "sha-1" / "sha-224" / "sha-256" / > "sha-384" / "sha-512" / > "md5" / "md2" / token > ; Additional hash functions can only come > ; from updates to RFC 3279" > > Christer's suggestion: Keep the text as it is. > > ------------- > > "Following RFC 3279 [7] as updated by RFC 4055 [9], therefore, the > defined hash functions are 'SHA-1' [1] [18], 'SHA-224' [1], 'SHA-256' > [1], 'SHA-384'[1], 'SHA-512' [1], 'MD5' [4], and 'MD2' [3], with > 'SHA-256' preferred. A new IANA registry of Hash Function Textual > Names, specified in Section 8, allows for addition of future tokens, > but they may only be added if they are included in RFCs that update > or obsolete RFC 3279 [7]." > > Christer's suggestion: Keep the text, but update the MD2 and MD5 > references ([3] and [4]), and add the following new paragraph text: > > "For backward compatibility with implementations compliant with RFC 4572, > the MD2 and MD5 cipher suite are still listed in the syntax. However, > implementations compliant to this specification MUST NOT use them." > > > Section 8: > ------------- > > "Table 1 contains the initial values of this registry. > > +--------------------+------------------------+-----------+ > | Hash Function Name | OID | Reference | > +--------------------+------------------------+-----------+ > | "md2" | 1.2.840.113549.2.2 | RFC 3279 | > | "md5" | 1.2.840.113549.2.5 | RFC 3279 | > | "sha-1" | 1.3.14.3.2.26 | RFC 3279 | > | "sha-224" | 2.16.840.1.101.3.4.2.4 | RFC 4055 | > | "sha-256" | 2.16.840.1.101.3.4.2.1 | RFC 4055 | > | "sha-384" | 2.16.840.1.101.3.4.2.2 | RFC 4055 | > | "sha-512" | 2.16.840.1.101.3.4.2.3 | RFC 4055 | > +--------------------+------------------------+-----------+" > > Christer's suggestion: Keep the above text, without changes. This is the > initial IANA registration, and we don't change that. > > > Regards, > > Christer > > > > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: 04 January 2017 00:07 > To: Roman Shpount > Cc: Cullen Jennings ; Jonathan Lennox ; > mmusic@ietf.org; Christer Holmberg > Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a > number of obsoleted RFCs > > On 4 January 2017 at 04:44, Roman Shpount wrote: > > I agree, I think MD2 and MD5 should be defined in the grammar but > > specification should state that they MUST NOT be used. This way there > > are no potential backwards interop problems. > > To address Christer's original concern, I would say that you don't need a > reference to the algorithms to achieve that. An informative reference is > as far as you might go. > --94eb2c06e7945fd2ba054545a3ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks good to me

_____________
Roman Shpount

On Wed, Jan 4, 2017 at 6:22 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:
Ok, to make sure we are all on the same pa= ge, below are the places in the previous version (-08) of the draft where M= D2 and MD5 are mentioned, and my suggestion on what/if to do:


Section 5:
-------------

"hash-func=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=C2=A0 &= quot;sha-1" / "sha-224" / "sha-256" /
=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"sha-384" / "sha-512" /<= br> =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"md5" / "md2" / token =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; Additional hash functions can only come =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; from updates to RFC 3279"

Christer's suggestion: Keep the text as it is.

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

=C2=A0 =C2=A0"Following RFC 3279 [7] as updated by RFC 4055 [9], there= fore, the
=C2=A0 =C2=A0defined hash functions are 'SHA-1' [1] [18], 'SHA-= 224' [1], 'SHA-256'
=C2=A0 =C2=A0[1], 'SHA-384'[1], 'SHA-512' [1], 'MD5'= ; [4], and 'MD2' [3], with
=C2=A0 =C2=A0'SHA-256' preferred.=C2=A0 A new IANA registry of Hash= Function Textual
=C2=A0 =C2=A0Names, specified in Section 8, allows for addition of future t= okens,
=C2=A0 =C2=A0but they may only be added if they are included in RFCs that u= pdate
=C2=A0 =C2=A0or obsolete RFC 3279 [7]."

Christer's suggestion: Keep the text, but update the MD2 and MD5 refere= nces ([3] and [4]), and add the following new paragraph text:

"For backward compatibility with implementations compliant with RFC 45= 72, the MD2 and MD5 cipher suite are still listed in the syntax. However, i= mplementations compliant to this specification MUST NOT use them."


Section 8:
-------------

"Table 1 contains the initial values of this registry.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+--------------------= ----+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 | Hash Function Name |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 OID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Reference |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+--------------------= ----+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0"md2"=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A01.2.840.113549.2.2=C2=A0 =C2=A0|=C2= =A0 RFC 3279 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0"md5"=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A01.2.840.113549.2.5=C2=A0 =C2=A0|=C2= =A0 RFC 3279 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 "sha-1"=C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A01.3.14.3.2.26=C2=A0 =C2=A0 =C2=A0 = |=C2=A0 RFC 3279 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0"sha-224"=C2=A0 = =C2=A0 =C2=A0 | 2.16.840.1.101.3.4.2.4 |=C2=A0 RFC 4055 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0"sha-256"=C2=A0 = =C2=A0 =C2=A0 | 2.16.840.1.101.3.4.2.1 |=C2=A0 RFC 4055 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0"sha-384"=C2=A0 = =C2=A0 =C2=A0 | 2.16.840.1.101.3.4.2.2 |=C2=A0 RFC 4055 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0"sha-512"=C2=A0 = =C2=A0 =C2=A0 | 2.16.840.1.101.3.4.2.3 |=C2=A0 RFC 4055 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+--------------------= ----+-----------+"

Christer's suggestion: Keep the above text, without changes. This is th= e initial IANA registration, and we don't change that.


Regards,

Christer




-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: 04 January 2017 00:07
To: Roman Shpount <roman@telurix.co= m>
Cc: Cullen Jennings <fluffy@iii.ca&= gt;; Jonathan Lennox <jonathan@vid= yo.com>; mmusic@ietf.org; Chr= ister Holmberg <christ= er.holmberg@ericsson.com>
Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a numb= er of obsoleted RFCs

On 4 January 2017 at 04:44, Roman Shpount <roman@telurix.com> wrote:
> I agree, I think MD2 and MD5 should be defined in the grammar but
> specification should state that they MUST NOT be used. This way there<= br> > are no potential backwards interop problems.

To address Christer's original concern, I would say that you don't = need a reference to the algorithms to achieve that.=C2=A0 An informative re= ference is as far as you might go.

--94eb2c06e7945fd2ba054545a3ee-- From nobody Wed Jan 4 10:59: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 D9E62129991; Wed, 4 Jan 2017 10:59:28 -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 OJhFauav46Rl; Wed, 4 Jan 2017 10:59:25 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0151B1296D6; Wed, 4 Jan 2017 10:59:24 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id i68so253966131uad.0; Wed, 04 Jan 2017 10:59:24 -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=LT9ahLTOpdZ4GEbZNpkoSGSzvKpEZb+A1ABnrwb7RPo=; b=DHY7jdKjgLJBUm19xK7dBSDREKsvTqUNRxq5CnH4KJ53Fsp4s/YnTO1lX1NGGitr+q kXVa3RVHHD5ziafuwV1iESx7YaFyOPKGa6G6p3ZzF3Pmz+lRT8N9i6v712AS/FVzM8FS DbCsSLoQ4euccYvH3Balm1g82yQA7E5xrQi/y9V83F+ZACxBS6rhK6g+etGz2xKIToLJ i1XGO3Ksal5ogZe2maXA+ugDOC8QpwIvZcyILMVh22yUjCakTSsDdqZGYqMXTLqgbcbw 7ViMMLYL1bl5y3PNHWy0nnpP3dAA0mps4LAWZZNr73zUjURpsfJghZdyBZrsv4NLeL34 mXGg== 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=LT9ahLTOpdZ4GEbZNpkoSGSzvKpEZb+A1ABnrwb7RPo=; b=hbCFZLMCidMh7MkCUdVD3X49nDPMqv03ddC9Xi+l5BZmZshhhdRsOmM2IN8cnLiM6o S7T/37Pqq7k863SJ2+oMMrRbgc/lKSasODrszKgBBK2SWUEWRrxc9X8ZhQaX/tvdNKXe mBFlGLK7kbCTQ2QTclHpHTVxcHoBfkXvKVdaVCt8rOv/YKg/zKgH5OSR4gMBz6WFcBM5 QafI1nBTwvz4hkus020Np4ZbV+AieCNug2Xt41TJcdRqFyn3tZxXbZ0OaRMqmcbp3VeT Or6zuqBj9QYQ39LBNaotzcTojvOFxzySALQeDtlvoicmr7Fzv/kQuXlanTX+KfXfXeM+ QLsQ== X-Gm-Message-State: AIkVDXL8FH7N5e4yWpljLisIOfoEjp9VKQZXffnVlwKbTW62OdAoPVFrNN8ccTNTmAlr9EXpMuaKjTOfC9yqkQ== X-Received: by 10.176.2.210 with SMTP id 76mr49993674uah.117.1483556363765; Wed, 04 Jan 2017 10:59:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.5 with HTTP; Wed, 4 Jan 2017 10:59:03 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Wed, 4 Jan 2017 10:59:03 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113dc310112fd105454962ed Archived-At: Cc: "mmusic \(E-mail\)" , Robin Raymond , draft-ietf-rtcweb-jsep@tools.ietf.org, RTCWeb IETF , Cullen Jennings , Colin Perkins , draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [MMUSIC] [rtcweb] RTP demux in JSEP and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 04 Jan 2017 18:59:29 -0000 --001a113dc310112fd105454962ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like to emphasize the importance of standardizing "routing rule" behavior at an appropriate level of detail. Developers are encountering interoperability problems and are filing bugs against implementations. To address the issues we are seeing, it is necessary to get to the level of detail in the JSEP-17 Section 6 text. On Fri, Dec 9, 2016 at 10:01 AM, Bernard Aboba wrote: > I agree with Eric and Cullen that a more explicit algorithm is needed. > The proposed text is not specific enough to resolve observed implementati= on > differences. > > Cullen said: > > " I'd also like it be clear that MID takes priority over PT." > > [BA] Yes. This is something that multiple implementations appear to agre= e > on. Also, Peter's suggestion that a MID mismatch result in a packet drop > should be restored. > > "I believe we agreed that if the PT was unique, then it would be used for > demux as well." > > [BA] That is my understanding as well. > > However, I'd also like to understand what happens if the PT is not > unique. The proposed text does not provide enough detail and existing > implementations differ in how they treat non-unique PTs. I am familiar wi= th > an implementation that declares SDP with non-unique PTs to be in error. > Another implementation fills a Payload Type table with a single value, wi= th > the value selected depending on whether SSRCs are also specified (e.g. > specification of SSRCs is taken as an indication that only SSRC matching = is > desired, and therefore that a Payload Type entry is not needed). The ORT= C > API spec says to latch the SSRC on a Payload Type match and then remove t= he > Payload Type table entry, but some implementations have found this leads = to > problems so they have foresaken either the latching or the PT removal (or > both). > > Cullen said: > > "I prefer the much more explicit algorithm particularly for the RTCP > handling as implementors have a hard time figuring out wha they need to d= o > to process the RTCP." > > [BA] I would also prefer that we have a more explicit algorithm here, > because we have seen very substantial implementation differences. One > implementation I'm familiar with sends the RTCP packets to all RtpSender > and RtpReceiver objects. While this is inefficient, it does avoid sendin= g > RTCP packets to the wrong objects. Another implementation sorts the RTCP > reports as indicated in the proposed text - but has found that the requir= ed > handling is so message-dependent that it leads to bugs (e.g. FIR and APP > messages have caused issues in particular). So this approach is more > efficient, unless we are willing to get into detail on every RTCP message= , > it will fall short. > > > On Fri, Dec 9, 2016 at 9:13 AM, Eric Rescorla wrote: > >> I agree with Cullen that the algorithm structure used in current JSEP is >> the better structure. >> >> Magnus, Colin, do you think you could rewrite your text in that structur= e? >> >> -Ekr >> >> >> On Fri, Dec 9, 2016 at 7:10 AM, Cullen Jennings wrote: >> >>> >>> In general, I think it makes sense to put most the details in bundle an= d >>> overview in jsep as you have proposed here. >>> >>> I believe we agreed that if the PT was unique, then that would be used >>> for the demux as well. I'd like to see that explicitly spelled out in t= his >>> text instead of just left as an option allowed but not really specified= by >>> this text. I'd also like it be clear that MID takes priority over PT. >>> >>> I prefer the much more explicit algorithm particularly for the RTCP >>> handling as implementors have a hard time figuring out wha they need to= do >>> to process the RTCP. >>> >>> >>> >>> > On Dec 8, 2016, at 3:54 AM, Colin Perkins wrote: >>> > >>> > Hi, >>> > >>> > [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP an= d BUNDLE >>> drafts] >>> > >>> > There=E2=80=99s been a lot of discussion on the lists, and at the mee= ting in >>> Seoul, around how RTP streams are mapped onto higher-level, application >>> meaningful, semantic roles. In particular, around how RTP streams map o= nto >>> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose = the >>> following updates to JSEP and BUNDLE to try to clarify the behaviour. >>> > >>> > Comments and feedback very welcome. >>> > >>> > Cheers, >>> > Colin >>> > >>> > >>> > >>> > # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17 >>> > >>> >
>>> > As described in , RTP packets are >>> > associated with RTP streams . Metadata >>> > about those streams, including source description information >>> > and reception quality feedback is conveyed in RTCP packets. >>> > Each RTP stream is identified by an SSRC, and each RTP packet >>> > carries an SSRC value that is used to associate the packet with >>> > the correct RTP stream. RTCP packets also use SSRCs to identify >>> > the RTP streams that the reports and metadata relate to. RTCP >>> > packets generally carry multiple SSRC values and report on, or >>> > deliver source description information relating to, several RTP >>> > streams. >>> > >>> > Each incoming RTP stream, identified by its SSRC, is mapped to >>> > an m=3D section in the SDP. The SDP m=3D sections then correspond = to >>> > RtpReceiver objects. This allows each RTP stream to be associated >>> > with an RtpTransceiver. Further processing of the RTP stream can >>> > then be done at the RtpTransceiver level. This includes using >>> > RID to distinguish between >>> > multiple Encoded Streams, as well as determine which Source RTP >>> > stream should be repaired by a given Redundancy RTP stream. >>> > >>> > The process of mapping RTP streams onto m=3D sections depends o= n >>> > whether streams are bundled or not. If the SDP BUNDLE extension >>> > is in use, then RTP streams are mapped onto m=3D sections based on >>> > the MID values as described in >>> > . If the >>> > SDP BUNDLE extension is not in use, each m=3D section corresponds >>> > to a transport layer connection and the RTP streams received on >>> > that connection correspond to the m=3D section. >>> > >>> > Incoming RTCP packets contain metadata including reception >>> > quality feedback, source description information, and other >>> > signalling relating to RTP streams. The RTCP packets are parsed, >>> > the associated RTP streams are identified based on the included >>> > SSRC values, and the metadata relating to those RTP streams is >>> > updated (this might include updating the MID information, used >>> > to associate RTP streams with m=3D sections, if the SDP BUNDLE >>> > extension is in use). This updated metadata is available to the >>> > RtpTransceiver objects associated with those RTP streams. >>> > >>> >
>>> > >>> > >>> > >>> > # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-n >>> egotiation-36 >>> > >>> >
>> > title=3D"Associating RTP Streams With Correct SDP Media >>> Description" >>> > toc=3D"default"> >>> > As described in >> > target=3D"RFC3550"/>, RTP packets are associated with RTP strea= ms >>> >> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each = RTP >>> stream is >>> > identified by an SSRC value, and each RTP packet carries an SSR= C >>> value >>> > that is used to associate the packet with the correct RTP >>> stream. RTCP >>> > packets also uses SSRCs to identify on which RTP streams any >>> report or >>> > feedback relate to. Thus, an RTCP packet will commonly carry >>> multiple >>> > SSRC values, and might therefore be providing feedback or repor= t >>> on >>> > multiple RTP streams. >>> > >>> > In order to be able to process received RTP packets correctl= y >>> it >>> > must be possible to associate an RTP stream with the correct "m= =3D" >>> > line, as the "m=3D" line and SDP attributes associated with the >>> "m=3D" >>> > line contain information needed to process the packets. >>> > >>> > As all RTP streams associated with a BUNDLE group are part o= f >>> the >>> > same RTP session and using the same address:port combination fo= r >>> > sending and receiving RTP/RTCP packets, the local address:port >>> > combination cannot be used to associate an RTP stream with the >>> correct >>> > "m=3D" line. In addition, multiple RTP streams might be associa= ted >>> with >>> > the same "m=3D" line. >>> > >>> > Also, as described in >> > target=3D"sec-rtp-sessions-pt"/>, the same payload type value >>> might be >>> > used by multiple RTP streams, in which case the payload type >>> value >>> > cannot be used to associate an RTP stream with the correct "m= =3D" >>> line. >>> > However, there are cases where each "m=3D" line has unique payl= oad >>> type >>> > values, and then the payload type could serve as hint to the >>> relevant >>> > "m=3D" line the RTP stream is associated with. >>> > >>> > An offerer and answerer can inform each other which SSRC >>> values >>> > they will use for an RTP stream by using the SDP 'ssrc' attribu= te >>> > . >>> However, an >>> > offerer will not know which SSRC values the answerer will use >>> until >>> > the offerer has received the answer providing that information. >>> Due to >>> > this, before the offerer has received the answer, the offerer >>> will not >>> > be able to associate an RTP stream with the correct "m=3D" line >>> using >>> > the SSRC value associated with the RTP stream. In addition, the >>> > offerer and answerer may start using new SSRC values mid-sessio= n, >>> > without informing each other using the SDP 'ssrc' attribute. >>> > >>> > In order for an offerer and answerer to always be able to >>> associate >>> > an RTP stream with the correct "m=3D" line, the offerer and >>> answerer >>> > using the BUNDLE extension MUST support the mechanism defined i= n >>> >> > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"/= >, >>> where the >>> > offerer and answerer includes the identification-tag (provided >>> by the >>> > remote peer) associated with an "m=3D" line in the RTP Streams = and >>> in >>> > RTCP SDES packets part of a BUNDLE group. >>> > >>> > The mapping from an SSRC to an identification-tag is carried >>> in >>> > RTCP SDES packets or in RTP header extensions (>> format=3D"default" >>> > pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compoun= d RTCP >>> > packet can contain multiple RTCP SDES packets, and each RTCP SD= ES >>> > packet can contain multiple chunks, an RTCP packet can contain >>> several >>> > SSRC to identification-tag mappings. The offerer and answerer >>> maintain >>> > tables mapping RTP streams identified by SSRC to "m=3D" lines >>> identified >>> > by the identification-tag. >>> > When receiving an RTP packet carrying a MID header extension >>> > with the identification-tag, or an RTCP packet carrying one or >>> > more SDES MID items, the offerer or answerer creates a mapping >>> > table entry between the SSRC value and the identification-tag, >>> > in order to associate the RTP stream associated with that SSRC >>> > value with the "m=3D" line corresponding to the >>> identification-tag. >>> > >>> > The mapping between the SSRC an identification-tag might >>> change >>> > mid-session if, for a given SSRC value, a different >>> identification-tag >>> > is provided in an RTP or RTCP packet. In that case these tables >>> are >>> > updated each time an RTP/RTCP packet containing a new mappings >>> from >>> > SSRC to identification-tag is received. Some considerations for >>> > avoiding update flaps are provided in Section 4.2.6 of >> > target=3D"RFC7941"/> which should be followed. >>> > >>> > If an offerer and answerer is not able to associate an RTP >>> stream >>> > with an "m=3D" line (using the mechanisms described in this >>> section, or >>> > using other appropriate mechanism, e.g., based on the payload >>> type >>> > value if it is unique to a single "m=3D" line), it MUST either >>> drop the >>> > RTP packets associated with the RTP stream, or process them in = an >>> > application specific manner, once non-stream specific processin= g >>> > (e.g., related to congestion control) of the RTP packets have >>> > occurred. >>> > >>> > When compound RTCP packets are received, they are split >>> > into their component RTCP packets and those component RTCP >>> > packets are processed based on their RTCP packet type, in >>> > the order in which they were placed into the compound RTCP >>> > packet. Non-compound RTCP packets are processed based on >>> > their RTCP packet type, in the order they are received. >>> Information >>> > in each RTCP packet can relate to one or more RTP streams. >>> > For example, RTCP Sender Report (SR) and Receiver Report (RR) >>> > packets include an SSRC of sender field that indicates the >>> > identity of the participant that sent the RTCP packet, along >>> > with a list of Report Blocks. Each report contains data on the >>> > reception quality of a single RTP stream, identified by SSRC, >>> > as received by the SSRC that sent the RTCP packet. Other RTCP >>> > packet types similarly contain references to the SSRC of the >>> > sender of the RTCP packet, and the RTP streams to which it >>> > refers. >>> > >>> > It should always be possible to process RTCP packets, and >>> > store the received information in a data structure associated >>> > with an RTP stream, identified by SSRC, for later access and >>> > use. It is possible that RTCP packets relating to an SSRC can >>> > be received before RTP packets relating to that SSRC, so the >>> > data structures relating to an SSRC might need to be created >>> > before the corresponding RTP stream is received. >>> > >>> > Similarly, information relating to an RTP stream might be >>> > received before the data needed to map it onto an m=3D line is >>> > received. Information carried in RTCP packets relating to such >>> > an RTP stream that is application and/or "m=3D" line dependent >>> > MAY be dropped until the SSRCs is associated with a particular >>> > "m=3D" line. However, information to generate RTCP report block= s >>> > and other basic transport level feedback or reporting needs to >>> > be retained, so RTCP reports relating to the stream can be >>> > generated. >>> > >>> >
>>> > >>> > >>> > >>> > >>> > -- >>> > Colin Perkins >>> > https://csperkins.org/ >>> > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> > --001a113dc310112fd105454962ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to emphasize the importance of standardizing = "routing rule" behavior at an appropriate level of detail.=C2=A0<= div>
Developers are encountering interoperability problems an= d are filing bugs against implementations.

To addr= ess the issues we are seeing, it is necessary to get to the level of detail= in the JSEP-17 Section 6 text.=C2=A0

On Fri, Dec 9, 2016 at 10:01 AM, Bernard Ab= oba <bernard.aboba@gmail.com> wrote:
I agree with Eric and Cullen that a more = explicit algorithm is needed.=C2=A0 The proposed text is not specific enoug= h to resolve observed implementation differences.=C2=A0
Cullen said:=C2=A0

"=C2=A0I= 9;d also like it be clear that MID takes priority over PT."

[BA] Yes.=C2=A0 This is something that multiple = implementations appear to agree on.=C2=A0 Also, Peter's suggestion that= a MID mismatch result in a packet drop should be restored.

"I believe we= agreed that if the PT was unique, then it would be used for demux as well.= "

[BA] That is my understanding as well. =C2= =A0

However, I'd also like to understand what = happens if the PT is not unique.=C2=A0 The proposed text does not provide e= nough detail and existing implementations differ in how they treat non-uniq= ue PTs. I am familiar with an implementation that declares SDP with non-uni= que PTs to be in error.=C2=A0 Another implementation fills a Payload Type t= able with a single value, with the value selected depending on whether SSRC= s are also specified (e.g. specification of SSRCs is taken as an indication= that only SSRC matching is desired, and therefore that a Payload Type entr= y is not needed).=C2=A0 The ORTC API spec says to latch the SSRC on a Paylo= ad Type match and then remove the Payload Type table entry, but some implem= entations have found this leads to problems so they have foresaken either t= he latching or the PT removal (or both). =C2=A0
<= div id=3D"m_-6603285502549914630gmail-q_158e4a627b100c1c_1" class=3D"m_-660= 3285502549914630gmail-ajR m_-6603285502549914630gmail-h4">

Cullen said:=C2=A0

"I prefer the much more explicit algorithm part= icularly for the RTCP handling as implementors have a hard time figuring ou= t wha they need to do to process the RTCP."

[BA] I would also prefer that we have a more explicit algorith= m here, because we have seen very substantial implementation differences.= =C2=A0 One implementation I'm familiar with sends the RTCP packets to a= ll RtpSender and RtpReceiver objects.=C2=A0 While this is inefficient, it d= oes avoid sending RTCP packets to the wrong objects.=C2=A0 Another implemen= tation sorts the RTCP reports as indicated in the proposed text - but has f= ound that the required handling is so message-dependent that it leads to bu= gs (e.g. FIR and APP messages have caused issues in particular).=C2=A0 So t= his approach is more efficient, unless we are willing to get into detail on= every RTCP message, it will fall short.=C2=A0


On Fri, Dec 9, 2016 at 9:13 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
I agree with Cullen that the algorithm structure used in = current JSEP is the better structure.

Magnus, Colin, do = you think you could rewrite your text in that structure?

-Ekr

<= br>
On Fri, Dec 9, 2016 at 7:10 AM, Cullen Jennin= gs <fluffy@iii.ca> wrote:

In general, I think it makes sense to put most the details in bundle and ov= erview in jsep as you have proposed here.

I believe we agreed that if the PT was unique, then that would be used for = the demux as well. I'd like to see that explicitly spelled out in this = text instead of just left as an option allowed but not really specified by = this text.=C2=A0 I'd also like it be clear that MID takes priority over= PT.

I prefer the much more explicit algorithm particularly for the RTCP handlin= g as implementors have a hard time figuring out wha they need to do to proc= ess the RTCP.



> On Dec 8, 2016, at 3:54 AM, Colin Perkins <csp@csperkins.org> wrote:
>
> Hi,
>
> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and= BUNDLE drafts]
>
> There=E2=80=99s been a lot of discussion on the lists, and at the meet= ing in Seoul, around how RTP streams are mapped onto higher-level, applicat= ion meaningful, semantic roles. In particular, around how RTP streams map o= nto JSEP objects for WebRTC. Magnus Westerlund and I would like to propose = the following updates to JSEP and BUNDLE to try to clarify the behaviour. >
> Comments and feedback very welcome.
>
> Cheers,
> Colin
>
>
>
> # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17
>
> <section title=3D"Processing RTP/RTCP" anchor=3D"sec= .rtp.demux">
>=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550&= quot;/>, RTP packets are
>=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC76= 56"/>. Metadata
>=C2=A0 =C2=A0 about those streams, including source description informa= tion
>=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packet= s.
>=C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP pa= cket
>=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packe= t with
>=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to id= entify
>=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.= =C2=A0 RTCP
>=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report o= n, or
>=C2=A0 =C2=A0 deliver source description information relating to, sever= al RTP
>=C2=A0 =C2=A0 streams.</t>
>
>=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC= , is mapped to
>=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then co= rrespond to
>=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be as= sociated
>=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP str= eam can
>=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This incl= udes using
>=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/>= ; to distinguish between
>=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Sour= ce RTP
>=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP strea= m.</t>
>
>=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D sec= tions depends on
>=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE ext= ension
>=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections= based on
>=C2=A0 =C2=A0 the MID values as described in
>=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-n= egotiation"/>.=C2=A0 If the
>=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section cor= responds
>=C2=A0 =C2=A0 to a transport layer connection and the RTP streams recei= ved on
>=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>=
>
>=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including= reception
>=C2=A0 =C2=A0 quality feedback, source description information, and oth= er
>=C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are = parsed,
>=C2=A0 =C2=A0 the associated RTP streams are identified based on the in= cluded
>=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP strea= ms is
>=C2=A0 =C2=A0 updated (this might include updating the MID information,= used
>=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP B= UNDLE
>=C2=A0 =C2=A0 extension is in use). This updated metadata is available = to the
>=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.=
>=C2=A0 =C2=A0 </t>
> </section>
>
>
>
> # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-n<= wbr>egotiation-36
>
>=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associat= ing RTP Streams With Correct SDP Media Description"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default&qu= ot;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D&= quot;default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packe= ts are associated with RTP streams <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"RFC7656"/>. Each RTP stream is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP pa= cket carries an SSRC value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with th= e correct RTP stream. RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which= RTP streams any report or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet wil= l commonly carry multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providin= g feedback or report on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process rece= ived RTP packets correctly it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream = with the correct "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP a= ttributes associated with the "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process t= he packets.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with = a BUNDLE group are part of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:= port combination for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the = local address:port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an R= TP stream with the correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple= RTP streams might be associated with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref form= at=3D"default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, the same payload type value might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case = the payload type value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream wi= th the correct "m=3D" line.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m= =3D" line has unique payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serv= e as hint to the relevant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;m=3D" line the RTP stream is associated with.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform = each other which SSRC values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the= SDP 'ssrc' attribute
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno= =3D"false" target=3D"RFC5576"/>. However, an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the = answerer will use until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providin= g that information. Due to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the an= swer, the offerer will not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the = correct "m=3D" line using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP strea= m. In addition, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSR= C values mid-session,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP &= #39;ssrc' attribute.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answere= r to always be able to associate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D&qu= ot; line, the offerer and answerer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the = mechanism defined in <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"sec-receiver-id"/>, where the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identifica= tion-tag (provided by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D&q= uot; line in the RTP Streams and in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.<= ;/t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an iden= tification-tag is carried in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extension= s (<xref format=3D"default"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"se= c-receiver-id"/>). Since a compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packet= s, and each RTCP SDES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP = packet can contain several
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The off= erer and answerer maintain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSR= C to "m=3D" lines identified
>=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID = header extension
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP pack= et carrying one or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer= creates a mapping
>=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the i= dentification-tag,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associa= ted with that SSRC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line corresp= onding to the identification-tag.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an ide= ntification-tag might change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a di= fferent identification-tag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In tha= t case these tables are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet contain= ing a new mappings from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some= considerations for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Sectio= n 4.2.6 of <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which shou= ld be followed. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not a= ble to associate an RTP stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mec= hanisms described in this section, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., bas= ed on the payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D= " line), it MUST either drop the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, = or process them in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream= specific processing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the= RTP packets have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are rece= ived, they are split
>=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those = component RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP pa= cket type, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the= compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are proces= sed based on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they ar= e received. Information
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or mor= e RTP streams.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Rec= eiver Report (RR)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that= indicates the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RT= CP packet, along
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report co= ntains data on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, id= entified by SSRC,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP p= acket. Other RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to= the SSRC of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP strea= ms to which it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to pro= cess RTCP packets, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data str= ucture associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for = later access and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relati= ng to an SSRC can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to t= hat SSRC, so the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might ne= ed to be created
>=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is recei= ved.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to = an RTP stream might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it on= to an m=3D line is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packet= s relating to such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or &qu= ot;m=3D" line dependent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated= with a particular
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information = to generate RTCP report blocks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or = reporting needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the= stream can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>
>
>=C2=A0 =C2=A0 =C2=A0</section>
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>

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


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


--001a113dc310112fd105454962ed-- From nobody Thu Jan 5 05:16: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 C54051288B8 for ; Thu, 5 Jan 2017 05:16:44 -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 K1j4OW7EU29E for ; Thu, 5 Jan 2017 05:16:42 -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 687EA1293FC for ; Thu, 5 Jan 2017 05:16:42 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-da-586e47383517 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id D4.E0.17130.8374E685; Thu, 5 Jan 2017 14:16:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 14:17:17 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs Thread-Index: AdJigL/3HmdriiVMRVGMYSdDZzSqOwADa/tQAGF4AYAANAiaQAANbYuAADFHBoAAAFj2AAAJJncAAB0+kFAABSYWgAAxw0ag Date: Thu, 5 Jan 2017 13:16:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF58F77@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF50A9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF50DF5@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF53260@ESESSMB209.ericsson.se> <7A58D0A4-CC5C-4740-B93A-B5D602FBDD9B@iii.ca> <7594FB04B1934943A5C02806D1A2204B4BF56AF4@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF58F77ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7oq6Fe16Ewfb/khYf1v9gtNi/+Dyz xbUz/xgtpi5/zGIx48JUZgdWj52z7rJ7LFnyk8nj8vmPjB63phR4tD27wx7AGsVlk5Kak1mW WqRvl8CV8fgbX8GKyYwVLTP/sDUwbuhn7GLk5JAQMJHYNukfkM3FISSwjlHi/LU9TBDOYkaJ L6u+MHcxcnCwCVhIdP/TBmkQEVCV+Pt9MlgNs8BcRolb/66zgiSEBRIlPp7oZYMoSpJ407yF EcLOk/i0twfMZhFQkbgyvY0FxOYV8JXY1bKXGWLZGlaJtX/2gg3iFAiUePnjNlgDo4CYxPdT a5hAbGYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLEotufmUCOZhbIlzj9XQRil6DEyZlP WCYwisxCMmkWQtUsJFUQYU2J9bv0IaoVJaZ0P2SHsDUkWufMZUcWX8DIvopRtDi1OCk33chY L7UoM7m4OD9PLy+1ZBMjMCIPbvmtuoPx8hvHQ4wCHIxKPLwfeHMjhFgTy4orcw8xSnAwK4nw ZrvmRQjxpiRWVqUW5ccXleakFh9ilOZgURLnNVt5P1xIID2xJDU7NbUgtQgmy8TBKdXAGPZa +QfPyg0SxRpdUw4Gnpx50fBj8qatpyXXz0idIlHp3Su/l4V9uWvQ84zlC+5IuW/sy0hyT657 8b2AuW3lkd+R07JYBbZoGH9bUW/0NvnT37xOtaLT7+UmTV0Svur9xTuaqq7pV7RW2grt3bhQ KLfB3TF56wW22Uli4eJu7itW1CWE95zrVWIpzkg01GIuKk4EAHefwnbEAgAA Archived-At: Cc: Jonathan Lennox , "mmusic@ietf.org" , Cullen Jennings Subject: Re: [MMUSIC] draft-4572-update: Spec contains references to a number of obsoleted RFCs X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jan 2017 13:16:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF58F77ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2ssIEnigJlsbCBzdWJtaXQgYSBuZXcgdmVyc2lvbiAoLTEwKSBiYXNlZCBvbiB0aGUgY2hhbmdl cyBiZWxvdy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBb bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMDQgSmFudWFyeSAyMDE3IDE2OjMxDQpU bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNj OiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgQ3VsbGVuIEplbm5p bmdzIDxmbHVmZnlAaWlpLmNhPjsgSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb20+ OyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBkcmFmdC00NTcyLXVwZGF0 ZTogU3BlYyBjb250YWlucyByZWZlcmVuY2VzIHRvIGEgbnVtYmVyIG9mIG9ic29sZXRlZCBSRkNz DQoNClRoaXMgbG9va3MgZ29vZCB0byBtZQ0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50 DQoNCk9uIFdlZCwgSmFuIDQsIDIwMTcgYXQgNjoyMiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpPaywgdG8gbWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNh bWUgcGFnZSwgYmVsb3cgYXJlIHRoZSBwbGFjZXMgaW4gdGhlIHByZXZpb3VzIHZlcnNpb24gKC0w OCkgb2YgdGhlIGRyYWZ0IHdoZXJlIE1EMiBhbmQgTUQ1IGFyZSBtZW50aW9uZWQsIGFuZCBteSBz dWdnZXN0aW9uIG9uIHdoYXQvaWYgdG8gZG86DQoNCg0KU2VjdGlvbiA1Og0KLS0tLS0tLS0tLS0t LQ0KDQoiaGFzaC1mdW5jICAgICAgICAgICAgICA9ICAic2hhLTEiIC8gInNoYS0yMjQiIC8gInNo YS0yNTYiIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgInNoYS0zODQiIC8gInNoYS01 MTIiIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIm1kNSIgLyAibWQyIiAvIHRva2Vu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgQWRkaXRpb25hbCBoYXNoIGZ1bmN0aW9u cyBjYW4gb25seSBjb21lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgZnJvbSB1cGRh dGVzIHRvIFJGQyAzMjc5Ig0KDQpDaHJpc3RlcidzIHN1Z2dlc3Rpb246IEtlZXAgdGhlIHRleHQg YXMgaXQgaXMuDQoNCi0tLS0tLS0tLS0tLS0NCg0KICAgIkZvbGxvd2luZyBSRkMgMzI3OSBbN10g YXMgdXBkYXRlZCBieSBSRkMgNDA1NSBbOV0sIHRoZXJlZm9yZSwgdGhlDQogICBkZWZpbmVkIGhh c2ggZnVuY3Rpb25zIGFyZSAnU0hBLTEnIFsxXSBbMThdLCAnU0hBLTIyNCcgWzFdLCAnU0hBLTI1 NicNCiAgIFsxXSwgJ1NIQS0zODQnWzFdLCAnU0hBLTUxMicgWzFdLCAnTUQ1JyBbNF0sIGFuZCAn TUQyJyBbM10sIHdpdGgNCiAgICdTSEEtMjU2JyBwcmVmZXJyZWQuICBBIG5ldyBJQU5BIHJlZ2lz dHJ5IG9mIEhhc2ggRnVuY3Rpb24gVGV4dHVhbA0KICAgTmFtZXMsIHNwZWNpZmllZCBpbiBTZWN0 aW9uIDgsIGFsbG93cyBmb3IgYWRkaXRpb24gb2YgZnV0dXJlIHRva2VucywNCiAgIGJ1dCB0aGV5 IG1heSBvbmx5IGJlIGFkZGVkIGlmIHRoZXkgYXJlIGluY2x1ZGVkIGluIFJGQ3MgdGhhdCB1cGRh dGUNCiAgIG9yIG9ic29sZXRlIFJGQyAzMjc5IFs3XS4iDQoNCkNocmlzdGVyJ3Mgc3VnZ2VzdGlv bjogS2VlcCB0aGUgdGV4dCwgYnV0IHVwZGF0ZSB0aGUgTUQyIGFuZCBNRDUgcmVmZXJlbmNlcyAo WzNdIGFuZCBbNF0pLCBhbmQgYWRkIHRoZSBmb2xsb3dpbmcgbmV3IHBhcmFncmFwaCB0ZXh0Og0K DQoiRm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBpbXBsZW1lbnRhdGlvbnMgY29tcGxp YW50IHdpdGggUkZDIDQ1NzIsIHRoZSBNRDIgYW5kIE1ENSBjaXBoZXIgc3VpdGUgYXJlIHN0aWxs IGxpc3RlZCBpbiB0aGUgc3ludGF4LiBIb3dldmVyLCBpbXBsZW1lbnRhdGlvbnMgY29tcGxpYW50 IHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIE5PVCB1c2UgdGhlbS4iDQoNCg0KU2VjdGlvbiA4 Og0KLS0tLS0tLS0tLS0tLQ0KDQoiVGFibGUgMSBjb250YWlucyB0aGUgaW5pdGlhbCB2YWx1ZXMg b2YgdGhpcyByZWdpc3RyeS4NCg0KICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKw0KICAgICAgICB8IEhhc2ggRnVuY3Rpb24g TmFtZSB8ICAgICAgICAgIE9JRCAgICAgICAgICAgfCBSZWZlcmVuY2UgfA0KICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKw0K ICAgICAgICB8ICAgICAgICJtZDIiICAgICAgICB8ICAgMS4yLjg0MC4xMTM1NDkuMi4yICAgfCAg UkZDIDMyNzkgfA0KICAgICAgICB8ICAgICAgICJtZDUiICAgICAgICB8ICAgMS4yLjg0MC4xMTM1 NDkuMi41ICAgfCAgUkZDIDMyNzkgfA0KICAgICAgICB8ICAgICAgInNoYS0xIiAgICAgICB8ICAg ICAxLjMuMTQuMy4yLjI2ICAgICAgfCAgUkZDIDMyNzkgfA0KICAgICAgICB8ICAgICAic2hhLTIy NCIgICAgICB8IDIuMTYuODQwLjEuMTAxLjMuNC4yLjQgfCAgUkZDIDQwNTUgfA0KICAgICAgICB8 ICAgICAic2hhLTI1NiIgICAgICB8IDIuMTYuODQwLjEuMTAxLjMuNC4yLjEgfCAgUkZDIDQwNTUg fA0KICAgICAgICB8ICAgICAic2hhLTM4NCIgICAgICB8IDIuMTYuODQwLjEuMTAxLjMuNC4yLjIg fCAgUkZDIDQwNTUgfA0KICAgICAgICB8ICAgICAic2hhLTUxMiIgICAgICB8IDIuMTYuODQwLjEu MTAxLjMuNC4yLjMgfCAgUkZDIDQwNTUgfA0KICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKyINCg0KQ2hyaXN0ZXIncyBzdWdn ZXN0aW9uOiBLZWVwIHRoZSBhYm92ZSB0ZXh0LCB3aXRob3V0IGNoYW5nZXMuIFRoaXMgaXMgdGhl IGluaXRpYWwgSUFOQSByZWdpc3RyYXRpb24sIGFuZCB3ZSBkb24ndCBjaGFuZ2UgdGhhdC4NCg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208 bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT5dDQpTZW50OiAwNCBKYW51YXJ5IDIwMTcg MDA6MDcNClRvOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20+Pg0KQ2M6IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYTxtYWlsdG86 Zmx1ZmZ5QGlpaS5jYT4+OyBKb25hdGhhbiBMZW5ub3ggPGpvbmF0aGFuQHZpZHlvLmNvbTxtYWls dG86am9uYXRoYW5AdmlkeW8uY29tPj47IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGll dGYub3JnPjsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBb TU1VU0lDXSBkcmFmdC00NTcyLXVwZGF0ZTogU3BlYyBjb250YWlucyByZWZlcmVuY2VzIHRvIGEg bnVtYmVyIG9mIG9ic29sZXRlZCBSRkNzDQoNCk9uIDQgSmFudWFyeSAyMDE3IGF0IDA0OjQ0LCBS b21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+ PiB3cm90ZToNCj4gSSBhZ3JlZSwgSSB0aGluayBNRDIgYW5kIE1ENSBzaG91bGQgYmUgZGVmaW5l ZCBpbiB0aGUgZ3JhbW1hciBidXQNCj4gc3BlY2lmaWNhdGlvbiBzaG91bGQgc3RhdGUgdGhhdCB0 aGV5IE1VU1QgTk9UIGJlIHVzZWQuIFRoaXMgd2F5IHRoZXJlDQo+IGFyZSBubyBwb3RlbnRpYWwg YmFja3dhcmRzIGludGVyb3AgcHJvYmxlbXMuDQoNClRvIGFkZHJlc3MgQ2hyaXN0ZXIncyBvcmln aW5hbCBjb25jZXJuLCBJIHdvdWxkIHNheSB0aGF0IHlvdSBkb24ndCBuZWVkIGEgcmVmZXJlbmNl IHRvIHRoZSBhbGdvcml0aG1zIHRvIGFjaGlldmUgdGhhdC4gIEFuIGluZm9ybWF0aXZlIHJlZmVy ZW5jZSBpcyBhcyBmYXIgYXMgeW91IG1pZ2h0IGdvLg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BF58F77ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T2ssIEnigJlsbCBzdWJtaXQgYSBuZXcgdmVy c2lvbiAoLTEwKSBiYXNlZCBvbiB0aGUgY2hhbmdlcyBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiAwNCBKYW51YXJ5IDIwMTcgMTY6MzE8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1i ZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgQ3VsbGVu IEplbm5pbmdzICZsdDtmbHVmZnlAaWlpLmNhJmd0OzsgSm9uYXRoYW4gTGVubm94ICZsdDtqb25h dGhhbkB2aWR5by5jb20mZ3Q7OyBtbXVzaWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtNTVVTSUNdIGRyYWZ0LTQ1NzItdXBkYXRlOiBTcGVjIGNvbnRhaW5zIHJlZmVyZW5jZXMg dG8gYSBudW1iZXIgb2Ygb2Jzb2xldGVkIFJGQ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGxvb2tzIGdvb2QgdG8gbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJy Pg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFdlZCwgSmFuIDQsIDIwMTcgYXQgNjoyMiBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PaywgdG8g bWFrZSBzdXJlIHdlIGFyZSBhbGwgb24gdGhlIHNhbWUgcGFnZSwgYmVsb3cgYXJlIHRoZSBwbGFj ZXMgaW4gdGhlIHByZXZpb3VzIHZlcnNpb24gKC0wOCkgb2YgdGhlIGRyYWZ0IHdoZXJlIE1EMiBh bmQgTUQ1IGFyZSBtZW50aW9uZWQsIGFuZCBteSBzdWdnZXN0aW9uIG9uIHdoYXQvaWYgdG8gZG86 PGJyPg0KPGJyPg0KPGJyPg0KU2VjdGlvbiA1Ojxicj4NCi0tLS0tLS0tLS0tLS08YnI+DQo8YnI+ DQomcXVvdDtoYXNoLWZ1bmMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPSZuYnNwOyAmcXVvdDtzaGEtMSZxdW90OyAvICZxdW90O3NoYS0yMjQmcXVvdDsg LyAmcXVvdDtzaGEtMjU2JnF1b3Q7IC88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3NoYS0zODQmcXVvdDsgLyAmcXVvdDtzaGEtNTEyJnF1 b3Q7IC88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZxdW90O21kNSZxdW90OyAvICZxdW90O21kMiZxdW90OyAvIHRva2VuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs7IEFkZGl0aW9uYWwgaGFzaCBm dW5jdGlvbnMgY2FuIG9ubHkgY29tZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OyBmcm9tIHVwZGF0ZXMgdG8gUkZDIDMyNzkmcXVvdDs8YnI+DQo8 YnI+DQpDaHJpc3RlcidzIHN1Z2dlc3Rpb246IEtlZXAgdGhlIHRleHQgYXMgaXQgaXMuPGJyPg0K PGJyPg0KLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsmcXVvdDtGb2xsb3dp bmcgUkZDIDMyNzkgWzddIGFzIHVwZGF0ZWQgYnkgUkZDIDQwNTUgWzldLCB0aGVyZWZvcmUsIHRo ZTxicj4NCiZuYnNwOyAmbmJzcDtkZWZpbmVkIGhhc2ggZnVuY3Rpb25zIGFyZSAnU0hBLTEnIFsx XSBbMThdLCAnU0hBLTIyNCcgWzFdLCAnU0hBLTI1Nic8YnI+DQombmJzcDsgJm5ic3A7WzFdLCAn U0hBLTM4NCdbMV0sICdTSEEtNTEyJyBbMV0sICdNRDUnIFs0XSwgYW5kICdNRDInIFszXSwgd2l0 aDxicj4NCiZuYnNwOyAmbmJzcDsnU0hBLTI1NicgcHJlZmVycmVkLiZuYnNwOyBBIG5ldyBJQU5B IHJlZ2lzdHJ5IG9mIEhhc2ggRnVuY3Rpb24gVGV4dHVhbDxicj4NCiZuYnNwOyAmbmJzcDtOYW1l cywgc3BlY2lmaWVkIGluIFNlY3Rpb24gOCwgYWxsb3dzIGZvciBhZGRpdGlvbiBvZiBmdXR1cmUg dG9rZW5zLDxicj4NCiZuYnNwOyAmbmJzcDtidXQgdGhleSBtYXkgb25seSBiZSBhZGRlZCBpZiB0 aGV5IGFyZSBpbmNsdWRlZCBpbiBSRkNzIHRoYXQgdXBkYXRlPGJyPg0KJm5ic3A7ICZuYnNwO29y IG9ic29sZXRlIFJGQyAzMjc5IFs3XS4mcXVvdDs8YnI+DQo8YnI+DQpDaHJpc3RlcidzIHN1Z2dl c3Rpb246IEtlZXAgdGhlIHRleHQsIGJ1dCB1cGRhdGUgdGhlIE1EMiBhbmQgTUQ1IHJlZmVyZW5j ZXMgKFszXSBhbmQgWzRdKSwgYW5kIGFkZCB0aGUgZm9sbG93aW5nIG5ldyBwYXJhZ3JhcGggdGV4 dDo8YnI+DQo8YnI+DQomcXVvdDtGb3IgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIGltcGxl bWVudGF0aW9ucyBjb21wbGlhbnQgd2l0aCBSRkMgNDU3MiwgdGhlIE1EMiBhbmQgTUQ1IGNpcGhl ciBzdWl0ZSBhcmUgc3RpbGwgbGlzdGVkIGluIHRoZSBzeW50YXguIEhvd2V2ZXIsIGltcGxlbWVu dGF0aW9ucyBjb21wbGlhbnQgdG8gdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgTk9UIHVzZSB0aGVt LiZxdW90Ozxicj4NCjxicj4NCjxicj4NClNlY3Rpb24gODo8YnI+DQotLS0tLS0tLS0tLS0tPGJy Pg0KPGJyPg0KJnF1b3Q7VGFibGUgMSBjb250YWlucyB0aGUgaW5pdGlhbCB2YWx1ZXMgb2YgdGhp cyByZWdpc3RyeS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0tLS0tLSYjNDM7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgSGFzaCBGdW5j dGlvbiBOYW1lIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE9JRCZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBSZWZlcmVuY2UgfDxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tJiM0Mzs8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O21kMiZx dW90OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOzEuMi44NDAuMTEz NTQ5LjIuMiZuYnNwOyAmbmJzcDt8Jm5ic3A7IFJGQyAzMjc5IHw8YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O21kNSZxdW90 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOzEuMi44NDAuMTEzNTQ5 LjIuNSZuYnNwOyAmbmJzcDt8Jm5ic3A7IFJGQyAzMjc5IHw8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3NoYS0xJnF1b3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7MS4zLjE0LjMuMi4yNiZu YnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgUkZDIDMyNzkgfDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtzaGEtMjI0JnF1b3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi40IHwmbmJzcDsgUkZDIDQw NTUgfDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJz cDsmcXVvdDtzaGEtMjU2JnF1b3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAyLjE2Ljg0MC4xLjEw MS4zLjQuMi4xIHwmbmJzcDsgUkZDIDQwNTUgfDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtzaGEtMzg0JnF1b3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgfCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi4yIHwmbmJzcDsgUkZDIDQwNTUgfDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtz aGEtNTEyJnF1b3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAyLjE2Ljg0MC4xLjEwMS4zLjQuMi4z IHwmbmJzcDsgUkZDIDQwNTUgfDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0t LS0tLS0tLS0tJiM0MzsmcXVvdDs8YnI+DQo8YnI+DQpDaHJpc3RlcidzIHN1Z2dlc3Rpb246IEtl ZXAgdGhlIGFib3ZlIHRleHQsIHdpdGhvdXQgY2hhbmdlcy4gVGhpcyBpcyB0aGUgaW5pdGlhbCBJ QU5BIHJlZ2lzdHJhdGlvbiwgYW5kIHdlIGRvbid0IGNoYW5nZSB0aGF0Ljxicj4NCjxicj4NCjxi cj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTwvYT5dPGJyPg0KU2VudDogMDQgSmFudWFyeSAyMDE3IDAwOjA3PGJyPg0KVG86IFJv bWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSI+cm9tYW5A dGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCkNjOiBDdWxsZW4gSmVubmluZ3MgJmx0OzxhIGhyZWY9 Im1haWx0bzpmbHVmZnlAaWlpLmNhIj5mbHVmZnlAaWlpLmNhPC9hPiZndDs7IEpvbmF0aGFuIExl bm5veCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZpZHlvLmNvbSI+am9uYXRoYW5Admlk eW8uY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNA aWV0Zi5vcmc8L2E+OyBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPiZndDs8YnI+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gZHJhZnQtNDU3Mi11cGRhdGU6IFNw ZWMgY29udGFpbnMgcmVmZXJlbmNlcyB0byBhIG51bWJlciBvZiBvYnNvbGV0ZWQgUkZDczxicj4N Cjxicj4NCk9uIDQgSmFudWFyeSAyMDE3IGF0IDA0OjQ0LCBSb21hbiBTaHBvdW50ICZsdDs8YSBo cmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyBJIGFncmVlLCBJIHRoaW5rIE1EMiBhbmQgTUQ1IHNob3VsZCBiZSBk ZWZpbmVkIGluIHRoZSBncmFtbWFyIGJ1dDxicj4NCiZndDsgc3BlY2lmaWNhdGlvbiBzaG91bGQg c3RhdGUgdGhhdCB0aGV5IE1VU1QgTk9UIGJlIHVzZWQuIFRoaXMgd2F5IHRoZXJlPGJyPg0KJmd0 OyBhcmUgbm8gcG90ZW50aWFsIGJhY2t3YXJkcyBpbnRlcm9wIHByb2JsZW1zLjxicj4NCjxicj4N ClRvIGFkZHJlc3MgQ2hyaXN0ZXIncyBvcmlnaW5hbCBjb25jZXJuLCBJIHdvdWxkIHNheSB0aGF0 IHlvdSBkb24ndCBuZWVkIGEgcmVmZXJlbmNlIHRvIHRoZSBhbGdvcml0aG1zIHRvIGFjaGlldmUg dGhhdC4mbmJzcDsgQW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGlzIGFzIGZhciBhcyB5b3UgbWln aHQgZ28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BF58F77ESESSMB209erics_-- From nobody Thu Jan 5 06:08:02 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 D322A126579; Thu, 5 Jan 2017 06:08:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148362528085.20689.16457140451404229249.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 06:08:00 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:08:01 -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 of the IETF. Title : Connection-Oriented Media Transport over TLS in SDP Authors : Jonathan Lennox Christer Holmberg Filename : draft-ietf-mmusic-4572-update-10.txt Pages : 17 Date : 2017-01-05 Abstract: This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-10 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 Jan 5 10:57: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 28B74129624 for ; Thu, 5 Jan 2017 10:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 kdWtO4fa12NS for ; Thu, 5 Jan 2017 10:57:14 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 72823129619 for ; Thu, 5 Jan 2017 10:57:14 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id r204so350671336ywb.0 for ; Thu, 05 Jan 2017 10:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xEOJ78duhkQssgamMmKsIUFfi7KLFl19A8XRzvzH59w=; b=2JMebF7l91kddNMw/C6/n+k1OBXKp33/Qx8niCymZTE0CDMp/U7x/KL6kH4TQuX9RW RuZ+lPde2zKobIiqhEwWbGA49p/JrLkmRAKS14N8MTDzQ5TqJ7up+IE3/rSe88TNa0bI uLFBH2LAYQbK8Elv2hw0lPSZLCl2h3rW+2GIZmI886pchfbQ78gj2JG7Y6jqinHe/mqE 8VKe+L2X8WqjzpL3VWYM+G7Xhi2rrAcEKZiLykYvc/3ynrxjCv63U4Aao83kJWoDmLps MJ37so9zIR4ZsaQvs9RHSdw1i0GQ77+4pzZxncgbXXdhS4TVuwTwrLbcZasTmSRFdSdS q4Yg== 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=xEOJ78duhkQssgamMmKsIUFfi7KLFl19A8XRzvzH59w=; b=YV/xZGIt/l9pogbmglTJ+g5xDJhMnpeh6qyxfMr4NpHpYNyEMY9JStdbwQU1yWwG6m LMc/8Pf6ak2Tmdi2yq9NDj7pBHjNQvdtY6uVEyFFC7kdZrzb5lruX28SQIBnm3T6EsfP NJ1JCJDf/neR+5HVkwQjzeFODE+Mv1TggH0RgBN++7DTxPgXiBWqzVGHb/LzSgHekSo+ mbGy7HlLEFlc9Aaw/Jl42gjhXN6h5Z+eOrh5j5LR0IQhtRha0+GHbdIfsYFKg3e5utt2 I7LvZ7SmEb42kT6UTG5YZ85rLLyFLF3sEQhnATMdSmHYTlKzZW53d5XuJ3e16/8h+Ptr nxUA== X-Gm-Message-State: AIkVDXIlbKx1FL5OTtuVXSgoUOLtPSzI1Q7QqQR7FHqWp3dJ+HHaWIgwgi06AYp6m8w5O30AS+pTPnw17od95A== X-Received: by 10.13.221.71 with SMTP id g68mr913668ywe.21.1483642633613; Thu, 05 Jan 2017 10:57:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 5 Jan 2017 10:56:33 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 5 Jan 2017 10:56:33 -0800 Message-ID: To: Bernard Aboba Content-Type: multipart/alternative; boundary=94eb2c075f7c26a5cb05455d78bf Archived-At: Cc: "mmusic \(E-mail\)" , Robin Raymond , draft-ietf-rtcweb-jsep@tools.ietf.org, RTCWeb IETF , Cullen Jennings , Colin Perkins , draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [MMUSIC] [rtcweb] RTP demux in JSEP and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 05 Jan 2017 18:57:17 -0000 --94eb2c075f7c26a5cb05455d78bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This discussion seems to have stalled. I think it's clear that: - There's a strong (though not necessarily unanimous) feeling on the JSEP side that we need to specify an actual algorithm in the way that JSEP did. - Magnus and Colin feel like the algorithm in JSEP isn't adequate. Given that, I think the best way to proceed is to schedule a virtual interim to jointly produce text in algorithmic form that addresses Colin and Magnus's concerns. This approach worked well the last time we had some contentious wordsmithing (the rules around IP address handling). Chairs, do you think you could arrange this sometime soon so it doesn't hold up JSEP. -Ekr On Wed, Jan 4, 2017 at 10:59 AM, Bernard Aboba wrote: > I would like to emphasize the importance of standardizing "routing rule" > behavior at an appropriate level of detail. > > Developers are encountering interoperability problems and are filing bugs > against implementations. > > To address the issues we are seeing, it is necessary to get to the level > of detail in the JSEP-17 Section 6 text. > > On Fri, Dec 9, 2016 at 10:01 AM, Bernard Aboba > wrote: > >> I agree with Eric and Cullen that a more explicit algorithm is needed. >> The proposed text is not specific enough to resolve observed implementat= ion >> differences. >> >> Cullen said: >> >> " I'd also like it be clear that MID takes priority over PT." >> >> [BA] Yes. This is something that multiple implementations appear to >> agree on. Also, Peter's suggestion that a MID mismatch result in a pack= et >> drop should be restored. >> >> "I believe we agreed that if the PT was unique, then it would be used fo= r >> demux as well." >> >> [BA] That is my understanding as well. >> >> However, I'd also like to understand what happens if the PT is not >> unique. The proposed text does not provide enough detail and existing >> implementations differ in how they treat non-unique PTs. I am familiar w= ith >> an implementation that declares SDP with non-unique PTs to be in error. >> Another implementation fills a Payload Type table with a single value, w= ith >> the value selected depending on whether SSRCs are also specified (e.g. >> specification of SSRCs is taken as an indication that only SSRC matching= is >> desired, and therefore that a Payload Type entry is not needed). The OR= TC >> API spec says to latch the SSRC on a Payload Type match and then remove = the >> Payload Type table entry, but some implementations have found this leads= to >> problems so they have foresaken either the latching or the PT removal (o= r >> both). >> >> Cullen said: >> >> "I prefer the much more explicit algorithm particularly for the RTCP >> handling as implementors have a hard time figuring out wha they need to = do >> to process the RTCP." >> >> [BA] I would also prefer that we have a more explicit algorithm here, >> because we have seen very substantial implementation differences. One >> implementation I'm familiar with sends the RTCP packets to all RtpSender >> and RtpReceiver objects. While this is inefficient, it does avoid sendi= ng >> RTCP packets to the wrong objects. Another implementation sorts the RTC= P >> reports as indicated in the proposed text - but has found that the requi= red >> handling is so message-dependent that it leads to bugs (e.g. FIR and APP >> messages have caused issues in particular). So this approach is more >> efficient, unless we are willing to get into detail on every RTCP messag= e, >> it will fall short. >> >> >> On Fri, Dec 9, 2016 at 9:13 AM, Eric Rescorla wrote: >> >>> I agree with Cullen that the algorithm structure used in current JSEP i= s >>> the better structure. >>> >>> Magnus, Colin, do you think you could rewrite your text in that >>> structure? >>> >>> -Ekr >>> >>> >>> On Fri, Dec 9, 2016 at 7:10 AM, Cullen Jennings wrote: >>> >>>> >>>> In general, I think it makes sense to put most the details in bundle >>>> and overview in jsep as you have proposed here. >>>> >>>> I believe we agreed that if the PT was unique, then that would be used >>>> for the demux as well. I'd like to see that explicitly spelled out in = this >>>> text instead of just left as an option allowed but not really specifie= d by >>>> this text. I'd also like it be clear that MID takes priority over PT. >>>> >>>> I prefer the much more explicit algorithm particularly for the RTCP >>>> handling as implementors have a hard time figuring out wha they need t= o do >>>> to process the RTCP. >>>> >>>> >>>> >>>> > On Dec 8, 2016, at 3:54 AM, Colin Perkins wrote: >>>> > >>>> > Hi, >>>> > >>>> > [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP a= nd BUNDLE >>>> drafts] >>>> > >>>> > There=E2=80=99s been a lot of discussion on the lists, and at the me= eting in >>>> Seoul, around how RTP streams are mapped onto higher-level, applicatio= n >>>> meaningful, semantic roles. In particular, around how RTP streams map = onto >>>> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose= the >>>> following updates to JSEP and BUNDLE to try to clarify the behaviour. >>>> > >>>> > Comments and feedback very welcome. >>>> > >>>> > Cheers, >>>> > Colin >>>> > >>>> > >>>> > >>>> > # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17 >>>> > >>>> >
>>>> > As described in , RTP packets are >>>> > associated with RTP streams . Metadata >>>> > about those streams, including source description information >>>> > and reception quality feedback is conveyed in RTCP packets. >>>> > Each RTP stream is identified by an SSRC, and each RTP packet >>>> > carries an SSRC value that is used to associate the packet with >>>> > the correct RTP stream. RTCP packets also use SSRCs to identify >>>> > the RTP streams that the reports and metadata relate to. RTCP >>>> > packets generally carry multiple SSRC values and report on, or >>>> > deliver source description information relating to, several RTP >>>> > streams. >>>> > >>>> > Each incoming RTP stream, identified by its SSRC, is mapped to >>>> > an m=3D section in the SDP. The SDP m=3D sections then correspond= to >>>> > RtpReceiver objects. This allows each RTP stream to be associated >>>> > with an RtpTransceiver. Further processing of the RTP stream can >>>> > then be done at the RtpTransceiver level. This includes using >>>> > RID to distinguish between >>>> > multiple Encoded Streams, as well as determine which Source RTP >>>> > stream should be repaired by a given Redundancy RTP stream. >>>> > >>>> > The process of mapping RTP streams onto m=3D sections depends = on >>>> > whether streams are bundled or not. If the SDP BUNDLE extension >>>> > is in use, then RTP streams are mapped onto m=3D sections based o= n >>>> > the MID values as described in >>>> > . If th= e >>>> > SDP BUNDLE extension is not in use, each m=3D section corresponds >>>> > to a transport layer connection and the RTP streams received on >>>> > that connection correspond to the m=3D section. >>>> > >>>> > Incoming RTCP packets contain metadata including reception >>>> > quality feedback, source description information, and other >>>> > signalling relating to RTP streams. The RTCP packets are parsed, >>>> > the associated RTP streams are identified based on the included >>>> > SSRC values, and the metadata relating to those RTP streams is >>>> > updated (this might include updating the MID information, used >>>> > to associate RTP streams with m=3D sections, if the SDP BUNDLE >>>> > extension is in use). This updated metadata is available to the >>>> > RtpTransceiver objects associated with those RTP streams. >>>> > >>>> >
>>>> > >>>> > >>>> > >>>> > # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-= n >>>> egotiation-36 >>>> > >>>> >
>>> > title=3D"Associating RTP Streams With Correct SDP Media >>>> Description" >>>> > toc=3D"default"> >>>> > As described in >>> > target=3D"RFC3550"/>, RTP packets are associated with RTP stre= ams >>>> >>> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each= RTP >>>> stream is >>>> > identified by an SSRC value, and each RTP packet carries an >>>> SSRC value >>>> > that is used to associate the packet with the correct RTP >>>> stream. RTCP >>>> > packets also uses SSRCs to identify on which RTP streams any >>>> report or >>>> > feedback relate to. Thus, an RTCP packet will commonly carry >>>> multiple >>>> > SSRC values, and might therefore be providing feedback or >>>> report on >>>> > multiple RTP streams. >>>> > >>>> > In order to be able to process received RTP packets >>>> correctly it >>>> > must be possible to associate an RTP stream with the correct >>>> "m=3D" >>>> > line, as the "m=3D" line and SDP attributes associated with th= e >>>> "m=3D" >>>> > line contain information needed to process the packets. >>>> > >>>> > As all RTP streams associated with a BUNDLE group are part >>>> of the >>>> > same RTP session and using the same address:port combination f= or >>>> > sending and receiving RTP/RTCP packets, the local address:port >>>> > combination cannot be used to associate an RTP stream with the >>>> correct >>>> > "m=3D" line. In addition, multiple RTP streams might be >>>> associated with >>>> > the same "m=3D" line. >>>> > >>>> > Also, as described in >>> > target=3D"sec-rtp-sessions-pt"/>, the same payload type value >>>> might be >>>> > used by multiple RTP streams, in which case the payload type >>>> value >>>> > cannot be used to associate an RTP stream with the correct "m= =3D" >>>> line. >>>> > However, there are cases where each "m=3D" line has unique >>>> payload type >>>> > values, and then the payload type could serve as hint to the >>>> relevant >>>> > "m=3D" line the RTP stream is associated with. >>>> > >>>> > An offerer and answerer can inform each other which SSRC >>>> values >>>> > they will use for an RTP stream by using the SDP 'ssrc' >>>> attribute >>>> > = . >>>> However, an >>>> > offerer will not know which SSRC values the answerer will use >>>> until >>>> > the offerer has received the answer providing that information= . >>>> Due to >>>> > this, before the offerer has received the answer, the offerer >>>> will not >>>> > be able to associate an RTP stream with the correct "m=3D" lin= e >>>> using >>>> > the SSRC value associated with the RTP stream. In addition, th= e >>>> > offerer and answerer may start using new SSRC values >>>> mid-session, >>>> > without informing each other using the SDP 'ssrc' attribute. >>>> > >>>> > In order for an offerer and answerer to always be able to >>>> associate >>>> > an RTP stream with the correct "m=3D" line, the offerer and >>>> answerer >>>> > using the BUNDLE extension MUST support the mechanism defined >>>> in >>> > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"= />, >>>> where the >>>> > offerer and answerer includes the identification-tag (provided >>>> by the >>>> > remote peer) associated with an "m=3D" line in the RTP Streams >>>> and in >>>> > RTCP SDES packets part of a BUNDLE group. >>>> > >>>> > The mapping from an SSRC to an identification-tag is carrie= d >>>> in >>>> > RTCP SDES packets or in RTP header extensions (>>> format=3D"default" >>>> > pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compou= nd >>>> RTCP >>>> > packet can contain multiple RTCP SDES packets, and each RTCP >>>> SDES >>>> > packet can contain multiple chunks, an RTCP packet can contain >>>> several >>>> > SSRC to identification-tag mappings. The offerer and answerer >>>> maintain >>>> > tables mapping RTP streams identified by SSRC to "m=3D" lines >>>> identified >>>> > by the identification-tag. >>>> > When receiving an RTP packet carrying a MID header extension >>>> > with the identification-tag, or an RTCP packet carrying one or >>>> > more SDES MID items, the offerer or answerer creates a mapping >>>> > table entry between the SSRC value and the identification-tag, >>>> > in order to associate the RTP stream associated with that SSRC >>>> > value with the "m=3D" line corresponding to the >>>> identification-tag. >>>> > >>>> > The mapping between the SSRC an identification-tag might >>>> change >>>> > mid-session if, for a given SSRC value, a different >>>> identification-tag >>>> > is provided in an RTP or RTCP packet. In that case these table= s >>>> are >>>> > updated each time an RTP/RTCP packet containing a new mappings >>>> from >>>> > SSRC to identification-tag is received. Some considerations fo= r >>>> > avoiding update flaps are provided in Section 4.2.6 of >>> > target=3D"RFC7941"/> which should be followed. >>>> > >>>> > If an offerer and answerer is not able to associate an RTP >>>> stream >>>> > with an "m=3D" line (using the mechanisms described in this >>>> section, or >>>> > using other appropriate mechanism, e.g., based on the payload >>>> type >>>> > value if it is unique to a single "m=3D" line), it MUST either >>>> drop the >>>> > RTP packets associated with the RTP stream, or process them in >>>> an >>>> > application specific manner, once non-stream specific processi= ng >>>> > (e.g., related to congestion control) of the RTP packets have >>>> > occurred. >>>> > >>>> > When compound RTCP packets are received, they are split >>>> > into their component RTCP packets and those component RTCP >>>> > packets are processed based on their RTCP packet type, in >>>> > the order in which they were placed into the compound RTCP >>>> > packet. Non-compound RTCP packets are processed based on >>>> > their RTCP packet type, in the order they are received. >>>> Information >>>> > in each RTCP packet can relate to one or more RTP streams. >>>> > For example, RTCP Sender Report (SR) and Receiver Report (RR) >>>> > packets include an SSRC of sender field that indicates the >>>> > identity of the participant that sent the RTCP packet, along >>>> > with a list of Report Blocks. Each report contains data on the >>>> > reception quality of a single RTP stream, identified by SSRC, >>>> > as received by the SSRC that sent the RTCP packet. Other RTCP >>>> > packet types similarly contain references to the SSRC of the >>>> > sender of the RTCP packet, and the RTP streams to which it >>>> > refers. >>>> > >>>> > It should always be possible to process RTCP packets, and >>>> > store the received information in a data structure associated >>>> > with an RTP stream, identified by SSRC, for later access and >>>> > use. It is possible that RTCP packets relating to an SSRC can >>>> > be received before RTP packets relating to that SSRC, so the >>>> > data structures relating to an SSRC might need to be created >>>> > before the corresponding RTP stream is received. >>>> > >>>> > Similarly, information relating to an RTP stream might be >>>> > received before the data needed to map it onto an m=3D line is >>>> > received. Information carried in RTCP packets relating to such >>>> > an RTP stream that is application and/or "m=3D" line dependent >>>> > MAY be dropped until the SSRCs is associated with a particular >>>> > "m=3D" line. However, information to generate RTCP report bloc= ks >>>> > and other basic transport level feedback or reporting needs to >>>> > be retained, so RTCP reports relating to the stream can be >>>> > generated. >>>> > >>>> >
>>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Colin Perkins >>>> > https://csperkins.org/ >>>> > >>>> > >>>> > >>>> > >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >> > --94eb2c075f7c26a5cb05455d78bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This discussion seems to have stalled. I think it's cl= ear that:

- There's a strong (though not necessarily= unanimous) feeling on the JSEP side that we need to specify an actual algo= rithm in the way that JSEP did.
- Magnus and Colin feel like the = algorithm in JSEP isn't adequate.

Given that, = I think the best way to proceed is to schedule a virtual interim to jointly= produce text in algorithmic form that addresses Colin and Magnus's con= cerns. This approach worked well the last time we had some contentious word= smithing (the rules around IP address handling). Chairs, do you think you c= ould arrange this sometime soon so it doesn't hold up JSEP.
<= br>
-Ekr



<= /div>

On Wed= , Jan 4, 2017 at 10:59 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
I wo= uld like to emphasize the importance of standardizing "routing rule&qu= ot; behavior at an appropriate level of detail.=C2=A0

De= velopers are encountering interoperability problems and are filing bugs aga= inst implementations.

To address the issues we are= seeing, it is necessary to get to the level of detail in the JSEP-17 Secti= on 6 text.=C2=A0

On Fri, Dec 9, 2016 at 1= 0:01 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote= :
I agree with Eric and = Cullen that a more explicit algorithm is needed.=C2=A0 The proposed text is= not specific enough to resolve observed implementation differences.=C2=A0<= span>

Cullen said:=C2=A0

"= =C2=A0I'd also like it be clear that MID takes priority over PT."

[BA] Yes.=C2=A0 This is something that m= ultiple implementations appear to agree on.=C2=A0 Also, Peter's suggest= ion that a MID mismatch result in a packet drop should be restored.<= /div>

"I be= lieve we agreed that if the PT was unique, then it would be used for demux = as well."

[BA] That is my understanding as we= ll. =C2=A0

However, I'd also like to understan= d what happens if the PT is not unique.=C2=A0 The proposed text does not pr= ovide enough detail and existing implementations differ in how they treat n= on-unique PTs. I am familiar with an implementation that declares SDP with = non-unique PTs to be in error.=C2=A0 Another implementation fills a Payload= Type table with a single value, with the value selected depending on wheth= er SSRCs are also specified (e.g. specification of SSRCs is taken as an ind= ication that only SSRC matching is desired, and therefore that a Payload Ty= pe entry is not needed).=C2=A0 The ORTC API spec says to latch the SSRC on = a Payload Type match and then remove the Payload Type table entry, but some= implementations have found this leads to problems so they have foresaken e= ither the latching or the PT removal (or both). =C2=A0
=

Cullen said:=C2=A0

"= ;I prefer the much more explicit algorithm= particularly for the RTCP handling as implementors have a hard time figuri= ng out wha they need to do to process the RTCP."

=
[BA] I would also prefer that we have a more explicit alg= orithm here, because we have seen very substantial implementation differenc= es.=C2=A0 One implementation I'm familiar with sends the RTCP packets t= o all RtpSender and RtpReceiver objects.=C2=A0 While this is inefficient, i= t does avoid sending RTCP packets to the wrong objects.=C2=A0 Another imple= mentation sorts the RTCP reports as indicated in the proposed text - but ha= s found that the required handling is so message-dependent that it leads to= bugs (e.g. FIR and APP messages have caused issues in particular).=C2=A0 S= o this approach is more efficient, unless we are willing to get into detail= on every RTCP message, it will fall short.=C2=A0


On Fri, Dec 9, 2016 at 9:13 AM, Eric Rescorla = <ekr= @rtfm.com> wrote:
I agree wit= h Cullen that the algorithm structure used in current JSEP is the better st= ructure.

Magnus, Colin, do you think you could rewrite y= our text in that structure?

-Ekr

<= div class=3D"m_7291791861056250763m_-6603285502549914630h5">

On Fri, Dec 9, 2016 at 7:10 AM, = Cullen Jennings <fluffy@iii.ca> wrote:

In general, I think it makes sense to put most the details in bundle and ov= erview in jsep as you have proposed here.

I believe we agreed that if the PT was unique, then that would be used for = the demux as well. I'd like to see that explicitly spelled out in this = text instead of just left as an option allowed but not really specified by = this text.=C2=A0 I'd also like it be clear that MID takes priority over= PT.

I prefer the much more explicit algorithm particularly for the RTCP handlin= g as implementors have a hard time figuring out wha they need to do to proc= ess the RTCP.



> On Dec 8, 2016, at 3:54 AM, Colin Perkins <csp@csperkins.org> wrote:
>
> Hi,
>
> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and= BUNDLE drafts]
>
> There=E2=80=99s been a lot of discussion on the lists, and at the meet= ing in Seoul, around how RTP streams are mapped onto higher-level, applicat= ion meaningful, semantic roles. In particular, around how RTP streams map o= nto JSEP objects for WebRTC. Magnus Westerlund and I would like to propose = the following updates to JSEP and BUNDLE to try to clarify the behaviour. >
> Comments and feedback very welcome.
>
> Cheers,
> Colin
>
>
>
> # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17
>
> <section title=3D"Processing RTP/RTCP" anchor=3D"sec= .rtp.demux">
>=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550&= quot;/>, RTP packets are
>=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC76= 56"/>. Metadata
>=C2=A0 =C2=A0 about those streams, including source description informa= tion
>=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packet= s.
>=C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP pa= cket
>=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packe= t with
>=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to id= entify
>=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.= =C2=A0 RTCP
>=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report o= n, or
>=C2=A0 =C2=A0 deliver source description information relating to, sever= al RTP
>=C2=A0 =C2=A0 streams.</t>
>
>=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC= , is mapped to
>=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then co= rrespond to
>=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be as= sociated
>=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP str= eam can
>=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This incl= udes using
>=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/>= ; to distinguish between
>=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Sour= ce RTP
>=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP strea= m.</t>
>
>=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D sec= tions depends on
>=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE ext= ension
>=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections= based on
>=C2=A0 =C2=A0 the MID values as described in
>=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-n= egotiation"/>.=C2=A0 If the
>=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section cor= responds
>=C2=A0 =C2=A0 to a transport layer connection and the RTP streams recei= ved on
>=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>=
>
>=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including= reception
>=C2=A0 =C2=A0 quality feedback, source description information, and oth= er
>=C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are = parsed,
>=C2=A0 =C2=A0 the associated RTP streams are identified based on the in= cluded
>=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP strea= ms is
>=C2=A0 =C2=A0 updated (this might include updating the MID information,= used
>=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP B= UNDLE
>=C2=A0 =C2=A0 extension is in use). This updated metadata is available = to the
>=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.=
>=C2=A0 =C2=A0 </t>
> </section>
>
>
>
> # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-n<= wbr>egotiation-36
>
>=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associat= ing RTP Streams With Correct SDP Media Description"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default&qu= ot;>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D&= quot;default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packe= ts are associated with RTP streams <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"RFC7656"/>. Each RTP stream is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP pa= cket carries an SSRC value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with th= e correct RTP stream. RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which= RTP streams any report or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet wil= l commonly carry multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providin= g feedback or report on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process rece= ived RTP packets correctly it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream = with the correct "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP a= ttributes associated with the "m=3D"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process t= he packets.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with = a BUNDLE group are part of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:= port combination for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the = local address:port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an R= TP stream with the correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple= RTP streams might be associated with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref form= at=3D"default" pageno=3D"false"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, the same payload type value might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case = the payload type value
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream wi= th the correct "m=3D" line.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m= =3D" line has unique payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serv= e as hint to the relevant
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;m=3D" line the RTP stream is associated with.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform = each other which SSRC values
>=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the= SDP 'ssrc' attribute
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno= =3D"false" target=3D"RFC5576"/>. However, an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the = answerer will use until
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providin= g that information. Due to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the an= swer, the offerer will not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the = correct "m=3D" line using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP strea= m. In addition, the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSR= C values mid-session,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP &= #39;ssrc' attribute.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answere= r to always be able to associate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D&qu= ot; line, the offerer and answerer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the = mechanism defined in <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"= false" target=3D"sec-receiver-id"/>, where the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identifica= tion-tag (provided by the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D&q= uot; line in the RTP Streams and in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.<= ;/t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an iden= tification-tag is carried in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extension= s (<xref format=3D"default"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"se= c-receiver-id"/>). Since a compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packet= s, and each RTCP SDES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP = packet can contain several
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The off= erer and answerer maintain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSR= C to "m=3D" lines identified
>=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID = header extension
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP pack= et carrying one or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer= creates a mapping
>=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the i= dentification-tag,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associa= ted with that SSRC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line corresp= onding to the identification-tag.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an ide= ntification-tag might change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a di= fferent identification-tag
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In tha= t case these tables are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet contain= ing a new mappings from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some= considerations for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Sectio= n 4.2.6 of <xref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which shou= ld be followed. </t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not a= ble to associate an RTP stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mec= hanisms described in this section, or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., bas= ed on the payload type
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D= " line), it MUST either drop the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, = or process them in an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream= specific processing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the= RTP packets have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are rece= ived, they are split
>=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those = component RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP pa= cket type, in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the= compound RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are proces= sed based on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they ar= e received. Information
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or mor= e RTP streams.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Rec= eiver Report (RR)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that= indicates the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RT= CP packet, along
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report co= ntains data on the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, id= entified by SSRC,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP p= acket. Other RTCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to= the SSRC of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP strea= ms to which it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to pro= cess RTCP packets, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data str= ucture associated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for = later access and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relati= ng to an SSRC can
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to t= hat SSRC, so the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might ne= ed to be created
>=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is recei= ved.</t>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to = an RTP stream might be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it on= to an m=3D line is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packet= s relating to such
>=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or &qu= ot;m=3D" line dependent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated= with a particular
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information = to generate RTCP report blocks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or = reporting needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the= stream can be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>
>
>=C2=A0 =C2=A0 =C2=A0</section>
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>

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


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



--94eb2c075f7c26a5cb05455d78bf-- From nobody Fri Jan 6 11:24: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 4C9C2129DE5 for ; Fri, 6 Jan 2017 11:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msCOsYOc-5Bb for ; Fri, 6 Jan 2017 11:24:05 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D30129DE0 for ; Fri, 6 Jan 2017 11:24:02 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 192so22758476itl.0 for ; Fri, 06 Jan 2017 11:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e8/h0v9mjwFAffJdCTIqV6uE+Ke7qSKN64UiLhrK4l8=; b=KUHuuLl34V1DS5GHHx3u3jvy/OishxXkU2kJuxX7uck9ObYHHWjj020g2uwbqIMTfN KTDXzj+dMCZBlzDdReRmm+eEDhJd59PqdO0fW57l8pojDknbersNnYFDoxbyI6unfzyn KvX0Q/LDPyPpq0toqxY/DKHnlkuTxNILcKyh3YBpyfmG/xQWWeaiJFvnOXiAlFE6yiLF NJ5gIkN23OWuUY6+t4E0G+S3mzQzNHhhWjugUpYirBKNsuTpKUBvW0KQM3iDJxMoilRK WwVBAWaI9qnxXv0B5weDjD8E1pE39OxX6FRZiXq+GpLZckiiQVotTrElTL6gYURpT/oF 48Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e8/h0v9mjwFAffJdCTIqV6uE+Ke7qSKN64UiLhrK4l8=; b=SEPLg+N4TGcIfzennt11qPRlddorjCZ0bPCy320SY0Z1KKAW3N26DP40T5pTuoLLkq R/7pw7AGWucpYGolYlDzvCdH9bRfOHXa8wlBqizhq2O/K/FsYKHm/TmRbZGFPJdBLsLH X00KtlL651450UFP8dtMR/4iQoCGSelojGQQXgiizOELphKrckkpYgnyhwvfU2fXYvnw RELlXzh9QRmtE9kdtcCMPGc9CklgcjoIZXrq8oVdmOymbHmKGjL5Lj7QOEM4Lkn4w2Qu OUcCeKt+wv7Zt2BHY5CfKMoC/7450E5XOur6vic8z+CkQcBniZxWAVpbe9dG++R+Kg/E Ie1A== X-Gm-Message-State: AIkVDXIJyokPsqKBslcintpG0U1A64UC74vqA9hqiqycZEFqwLnpa14qn4fJ+FzlbEEwkgAWoBie7EGaTRWi+eQv X-Received: by 10.36.129.2 with SMTP id q2mr205972itd.26.1483730641605; Fri, 06 Jan 2017 11:24:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Fri, 06 Jan 2017 19:23:50 +0000 Message-ID: To: Colin Perkins , "mmusic (E-mail)" , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08da88d6256d054571f51e Archived-At: Cc: Magnus Westerlund , draft-ietf-rtcweb-jsep@tools.ietf.org, draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [MMUSIC] RTP demux in JSEP and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jan 2017 19:24:07 -0000 --94eb2c08da88d6256d054571f51e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When I read your text, I get the impression that you want to simplify the algorithm to only supporting MIDs for demux with SSRC latching. No PT demux. No SSRC demux (except for ones latched by MID). In other words, if you want to use BUNDLE, you must use MID and only MID. But it's not clear if that's the case. Perhaps I missed something. I agree with others that a more explicit algorithm would make your intention clear. To help, here is my interpretation of your text as an algorithm. Please let me know if it's a correct interpretation:
To prepare for demultiplexing RTP packets to the correct "m=3D" line, the following steps MUST be followed for each BUNDLE group. Construct a table mapping MID to "m=3D" line for each "m=3D" line in this BUNDLE group. Construct an empty table mapping incoming SSRC to "m=3D" line. As "m=3D" lines are added or removed from the BUNDLE groups, or their configurations are changed, the tables above must also be updated. For each RTP packet received, the following steps MUST be followed to route the packet to the correct "m=3D" section within a BUNDLE group: If the packet has a MID and that MID is not in the table mapping MID to "m=3D" line, drop the packet and stop. If the packet has a MID and that MID is in the table mapping MID to "m=3D" line, update the incoming SSRC mapping table to include an entry that maps the packet's SSRC to the "m=3D" line for that MID. If the packet's SSRC is in the incoming SSRC mapping table, route the packet to the associated "m=3D" line and stop. Otherwise, drop the packet. ... similar for RTCP ...
On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: Hi, [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts] There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application meaningful, semantic roles. In particular, around how RTP streams map onto JSEP objects for WebRTC. Magnus Westerlund and I would like to propose the following updates to JSEP and BUNDLE to try to clarify the behaviour. Comments and feedback very welcome. Cheers, Colin # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17
As described in , RTP packets are associated with RTP streams . Metadata about those streams, including source description information and reception quality feedback is conveyed in RTCP packets. Each RTP stream is identified by an SSRC, and each RTP packet carries an SSRC value that is used to associate the packet with the correct RTP stream. RTCP packets also use SSRCs to identify the RTP streams that the reports and metadata relate to. RTCP packets generally carry multiple SSRC values and report on, or deliver source description information relating to, several RTP streams. Each incoming RTP stream, identified by its SSRC, is mapped to an m=3D section in the SDP. The SDP m=3D sections then correspond to RtpReceiver objects. This allows each RTP stream to be associated with an RtpTransceiver. Further processing of the RTP stream can then be done at the RtpTransceiver level. This includes using RID to distinguish between multiple Encoded Streams, as well as determine which Source RTP stream should be repaired by a given Redundancy RTP stream. The process of mapping RTP streams onto m=3D sections depends on whether streams are bundled or not. If the SDP BUNDLE extension is in use, then RTP streams are mapped onto m=3D sections based on the MID values as described in . If the SDP BUNDLE extension is not in use, each m=3D section corresponds to a transport layer connection and the RTP streams received on that connection correspond to the m=3D section. Incoming RTCP packets contain metadata including reception quality feedback, source description information, and other signalling relating to RTP streams. The RTCP packets are parsed, the associated RTP streams are identified based on the included SSRC values, and the metadata relating to those RTP streams is updated (this might include updating the MID information, used to associate RTP streams with m=3D sections, if the SDP BUNDLE extension is in use). This updated metadata is available to the RtpTransceiver objects associated with those RTP streams.
# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotiation-36
As described in , RTP packets are associated with RTP streams . Each RTP s= tream is identified by an SSRC value, and each RTP packet carries an SSRC value that is used to associate the packet with the correct RTP stream. RTCP packets also uses SSRCs to identify on which RTP streams any report or feedback relate to. Thus, an RTCP packet will commonly carry multipl= e SSRC values, and might therefore be providing feedback or report on multiple RTP streams. In order to be able to process received RTP packets correctly it must be possible to associate an RTP stream with the correct "m=3D" line, as the "m=3D" line and SDP attributes associated with the "m= =3D" line contain information needed to process the packets. As all RTP streams associated with a BUNDLE group are part of the same RTP session and using the same address:port combination for sending and receiving RTP/RTCP packets, the local address:port combination cannot be used to associate an RTP stream with the correct "m=3D" line. In addition, multiple RTP streams might be associated w= ith the same "m=3D" line. Also, as described in , the same payload type value might = be used by multiple RTP streams, in which case the payload type value cannot be used to associate an RTP stream with the correct "m=3D" li= ne. However, there are cases where each "m=3D" line has unique payload t= ype values, and then the payload type could serve as hint to the relevan= t "m=3D" line the RTP stream is associated with. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute . Howe= ver, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=3D" line usin= g the SSRC value associated with the RTP stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=3D" line, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in , wh= ere the offerer and answerer includes the identification-tag (provided by th= e remote peer) associated with an "m=3D" line in the RTP Streams and i= n RTCP SDES packets part of a BUNDLE group. The mapping from an SSRC to an identification-tag is carried in RTCP SDES packets or in RTP header extensions (). Since a compound RTC= P packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, an RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables mapping RTP streams identified by SSRC to "m=3D" lines identified by the identification-tag. When receiving an RTP packet carrying a MID header extension with the identification-tag, or an RTCP packet carrying one or more SDES MID items, the offerer or answerer creates a mapping table entry between the SSRC value and the identification-tag, in order to associate the RTP stream associated with that SSRC value with the "m=3D" line corresponding to the identification-tag.<= /t> The mapping between the SSRC an identification-tag might change mid-session if, for a given SSRC value, a different identification-tag is provided in an RTP or RTCP packet. In that case these tables are updated each time an RTP/RTCP packet containing a new mappings from SSRC to identification-tag is received. Some considerations for avoiding update flaps are provided in Section 4.2.6 of which should be followed. If an offerer and answerer is not able to associate an RTP stream with an "m=3D" line (using the mechanisms described in this section,= or using other appropriate mechanism, e.g., based on the payload type value if it is unique to a single "m=3D" line), it MUST either drop = the RTP packets associated with the RTP stream, or process them in an application specific manner, once non-stream specific processing (e.g., related to congestion control) of the RTP packets have occurred. When compound RTCP packets are received, they are split into their component RTCP packets and those component RTCP packets are processed based on their RTCP packet type, in the order in which they were placed into the compound RTCP packet. Non-compound RTCP packets are processed based on their RTCP packet type, in the order they are received. Information in each RTCP packet can relate to one or more RTP streams. For example, RTCP Sender Report (SR) and Receiver Report (RR) packets include an SSRC of sender field that indicates the identity of the participant that sent the RTCP packet, along with a list of Report Blocks. Each report contains data on the reception quality of a single RTP stream, identified by SSRC, as received by the SSRC that sent the RTCP packet. Other RTCP packet types similarly contain references to the SSRC of the sender of the RTCP packet, and the RTP streams to which it refers. It should always be possible to process RTCP packets, and store the received information in a data structure associated with an RTP stream, identified by SSRC, for later access and use. It is possible that RTCP packets relating to an SSRC can be received before RTP packets relating to that SSRC, so the data structures relating to an SSRC might need to be created before the corresponding RTP stream is received. Similarly, information relating to an RTP stream might be received before the data needed to map it onto an m=3D line is received. Information carried in RTCP packets relating to such an RTP stream that is application and/or "m=3D" line dependent MAY be dropped until the SSRCs is associated with a particular "m=3D" line. However, information to generate RTCP report blocks and other basic transport level feedback or reporting needs to be retained, so RTCP reports relating to the stream can be generated.
-- Colin Perkins https://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --94eb2c08da88d6256d054571f51e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I read your text, I get the impression that you want = to simplify the algorithm to only supporting MIDs for demux with SSRC latch= ing.=C2=A0 No PT demux. =C2=A0 No SSRC demux (except for ones latched by MI= D). =C2=A0 In other words, if you want to use BUNDLE, you must use MID and = only MID.

But it's not clear if that's the case.= =C2=A0 Perhaps I missed something.=C2=A0 I agree with others that a more ex= plicit algorithm would make your intention clear.

To hel= p, here is my interpretation of your text as an algorithm.=C2=A0 Please let= me know if it's a correct interpretation:

=C2=A0 =C2=A0 <section title=3D"Appendix B" anchor=3D"s= ec.appendix-b">
=C2=A0 =C2=A0 =C2=A0 <t>To prepare = for demultiplexing RTP packets to the correct "m=3D"
= =C2=A0 =C2=A0 =C2=A0 line, the following steps MUST be followed for each BU= NDLE
=C2=A0 =C2=A0 =C2=A0 group.</t>

=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Construct a= table mapping MID to "m=3D" line for each "m=3D"
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line in this BUNDLE group.</t>= ;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Cons= truct an empty table mapping incoming SSRC to "m=3D" line. </t= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 = =C2=A0 =C2=A0 </t>

=C2=A0 =C2=A0 =C2=A0 <= t>As "m=3D" lines are added or removed from the BUNDLE groups,= or
=C2=A0 =C2=A0 =C2=A0 their configurations are changed, the ta= bles above must also be
=C2=A0 =C2=A0 =C2=A0 updated.</t>

=C2=A0 =C2=A0 =C2=A0 <t>For each RTP packet r= eceived, the following steps MUST be
=C2=A0 =C2=A0 =C2=A0 followe= d to route the packet to the correct "m=3D" section within
<= div>=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:</t>

=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <l= ist>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet= has a MID and that MID is not in the table
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 mapping MID to "m=3D" line, drop the packet and sto= p.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &l= t;t>If the packet has a MID and that MID is in the table
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D" line, updat= e the incoming SSRC mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ta= ble to include an entry that maps the packet's SSRC to the
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m=3D" line for that MID.</= t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>= If the packet's SSRC is in the incoming SSRC mapping
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route the packet to the associated "= ;m=3D" line and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stop.<= /t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>= ;Otherwise, drop the packet.</t>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 </list>
=C2=A0 =C2=A0 =C2=A0 </t>

<= /div>
... similar for RTCP ...
=C2=A0 =C2=A0 </section>=





On Thu, Dec= 8, 2016, 2:55 AM Colin Perkins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing updates to JSEP and BUNDLE to try to clarify the behaviour.

Comments and feedback very welcome.

Cheers,
Colin



# Replacement for Section 6 of draft-ietf-rtcweb-jsep-17

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.=C2= =A0 RTCP
=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=C2=A0 =C2=A0 streams.</t>

=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC, is= mapped to
=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= using
=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/> to= distinguish between
=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negotiatio= n"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = on
=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>

=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotia= tion-36

=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect RTP stream. RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which RTP= streams any report or
=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback or report on
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process received= RTP packets correctly it
=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream with= the correct "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE group are part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:port= combination for
=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream with the correct
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple RTP= streams might be associated with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, t= he same payload type value might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case the = payload type value
=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve as= hint to the relevant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;m=3D" line the RTP stream is associated with.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform each= other which SSRC values
=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the SDP= 'ssrc' attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno=3D&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC to= "m=3D" lines identified
=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific processing
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the RTP= packets have
=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. Other RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to the= SSRC of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP streams t= o which it
=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




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




_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
--94eb2c08da88d6256d054571f51e-- From nobody Fri Jan 6 14:49: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 3E81B12962A for ; Fri, 6 Jan 2017 14:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y302EgKPRtXC for ; Fri, 6 Jan 2017 14:49:26 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F8F129563 for ; Fri, 6 Jan 2017 14:49:26 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id v96so43164287ioi.0 for ; Fri, 06 Jan 2017 14:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:from:date:message-id:subject:to:cc; bh=HSgpm+itc6g0YvgszBcSpWsSWbt38F6Rij0s7/VVbdI=; b=erxzEZIydr9mBbJlBp7Xd0IjpCbBzeD1IWVtez0dJWqKmNCey/Fwz4BgTLINarnW28 PqAbyDSS8uwCkN8gIIm9+T+6xrau1e9orq07vrcGNpY/uvsBPPG6eW0m772Q93HiPmZd 113C6FxmVWnc0I0PKG55qTEDubOaDKH/kuUrr9VL7RSWRp+vj4bmyuk0vtWcaGcsYVhc dSOdM2UZ/kRC3Ek0dcCPK1S5tISm2H0f4CPxvwqkq4XSxWra29RP7u67iniOUyeXVhvQ hdkQVMtkPboacOWDaz4AkC3MQ9Otj5eocSE9BBObV24rCdUeuHrZYT4iFWoz8wSWSPNJ 5Wiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc; bh=HSgpm+itc6g0YvgszBcSpWsSWbt38F6Rij0s7/VVbdI=; b=P23JIDRpQkx+faPDA+LuGM9yykBMWgl+ZzHkBCtJxxeZ8BYQ10npCGkt7r7T+x0yoY Duw1k96vBEYjB2mmsO72+2x4GqEQJflbRTlHPIXhAw+S52TYnI7aC6hZ4+zt1Zax/fbo QmE4sOztiJsiRwFgWMFSVH4v3ejoXoQ7czhZaY9v5ZX+3Q0yTj4hm0jwQrlVAmy09iCw TS6SgblcjGDfHVlKh1XBPfALcAUTneWaAnAGdYfR/ihS+t4YcKTN8wRRrNm9yqwQ7L6x oD1VEz6yB5/1vt6SXcifulXWi3T49D8o+f2JqCPQ+/AZ2YtZnxzMCzrTs3nPNyn8a+gq OsIw== X-Gm-Message-State: AIkVDXL5O+I+G6kvVviMkXpHhmR0HbVt7PN7JUwFNhlXgr0ixSBeHe3ukRcScfoNmibw9dHAhEiYV9qhhW4kJskh X-Received: by 10.107.19.78 with SMTP id b75mr34565165ioj.111.1483742965259; Fri, 06 Jan 2017 14:49:25 -0800 (PST) MIME-Version: 1.0 References: From: Peter Thatcher Date: Fri, 06 Jan 2017 22:49:14 +0000 Message-ID: To: Colin Perkins , "mmusic (E-mail)" , rtcweb@ietf.org Content-Type: multipart/alternative; boundary=001a113f26fc621bbc054574d43b Archived-At: Cc: Magnus Westerlund , draft-ietf-rtcweb-jsep@tools.ietf.org, draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [MMUSIC] RTP demux in JSEP and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jan 2017 22:49:32 -0000 --001a113f26fc621bbc054574d43b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I made a PR for JSEP that incorporates your text *and* adds a more specific algorithm which only uses MID and SSRC latching (my interpretation of your text, which I'm still not sure is correct): https://github.com/rtcweb-wg/jsep/pull/489 In practice, I think this is mostly word smithing and doesn't require a virtual interim. The big questions, which perhaps to require a virtual interim, are: 1. Do we want to include PT demux in the algorithm (when neither SSRC nor MID match)? 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC table is loaded with signaled SSRCs)? The question to both of those is "yes" in PR 411 and "no" in PR 489. On Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher wrote= : > When I read your text, I get the impression that you want to simplify the > algorithm to only supporting MIDs for demux with SSRC latching. No PT > demux. No SSRC demux (except for ones latched by MID). In other words= , > if you want to use BUNDLE, you must use MID and only MID. > > But it's not clear if that's the case. Perhaps I missed something. I > agree with others that a more explicit algorithm would make your intentio= n > clear. > > To help, here is my interpretation of your text as an algorithm. Please > let me know if it's a correct interpretation: > >
> To prepare for demultiplexing RTP packets to the correct "m=3D" > line, the following steps MUST be followed for each BUNDLE > group. > > > > Construct a table mapping MID to "m=3D" line for each "m=3D" > line in this BUNDLE group. > > Construct an empty table mapping incoming SSRC to "m=3D" lin= e. > > > > > As "m=3D" lines are added or removed from the BUNDLE groups, or > their configurations are changed, the tables above must also be > updated. > > For each RTP packet received, the following steps MUST be > followed to route the packet to the correct "m=3D" section within > a BUNDLE group: > > > > If the packet has a MID and that MID is not in the table > mapping MID to "m=3D" line, drop the packet and stop. > > If the packet has a MID and that MID is in the table > mapping MID to "m=3D" line, update the incoming SSRC mapping > table to include an entry that maps the packet's SSRC to the > "m=3D" line for that MID. > > If the packet's SSRC is in the incoming SSRC mapping > table, route the packet to the associated "m=3D" line and > stop. > > Otherwise, drop the packet. > > > > ... similar for RTCP ... >
> > > > > > On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: > > Hi, > > [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BU= NDLE > drafts] > > There=E2=80=99s been a lot of discussion on the lists, and at the meeting= in > Seoul, around how RTP streams are mapped onto higher-level, application > meaningful, semantic roles. In particular, around how RTP streams map ont= o > JSEP objects for WebRTC. Magnus Westerlund and I would like to propose th= e > following updates to JSEP and BUNDLE to try to clarify the behaviour. > > Comments and feedback very welcome. > > Cheers, > Colin > > > > # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17 > >
> As described in , RTP packets are > associated with RTP streams . Metadata > about those streams, including source description information > and reception quality feedback is conveyed in RTCP packets. > Each RTP stream is identified by an SSRC, and each RTP packet > carries an SSRC value that is used to associate the packet with > the correct RTP stream. RTCP packets also use SSRCs to identify > the RTP streams that the reports and metadata relate to. RTCP > packets generally carry multiple SSRC values and report on, or > deliver source description information relating to, several RTP > streams. > > Each incoming RTP stream, identified by its SSRC, is mapped to > an m=3D section in the SDP. The SDP m=3D sections then correspond to > RtpReceiver objects. This allows each RTP stream to be associated > with an RtpTransceiver. Further processing of the RTP stream can > then be done at the RtpTransceiver level. This includes using > RID to distinguish between > multiple Encoded Streams, as well as determine which Source RTP > stream should be repaired by a given Redundancy RTP stream. > > The process of mapping RTP streams onto m=3D sections depends on > whether streams are bundled or not. If the SDP BUNDLE extension > is in use, then RTP streams are mapped onto m=3D sections based on > the MID values as described in > . If the > SDP BUNDLE extension is not in use, each m=3D section corresponds > to a transport layer connection and the RTP streams received on > that connection correspond to the m=3D section. > > Incoming RTCP packets contain metadata including reception > quality feedback, source description information, and other > signalling relating to RTP streams. The RTCP packets are parsed, > the associated RTP streams are identified based on the included > SSRC values, and the metadata relating to those RTP streams is > updated (this might include updating the MID information, used > to associate RTP streams with m=3D sections, if the SDP BUNDLE > extension is in use). This updated metadata is available to the > RtpTransceiver objects associated with those RTP streams. > >
> > > > # Replacement text for section 10.2 of > draft-ietf-mmusic-sdp-bundle-negotiation-36 > >
title=3D"Associating RTP Streams With Correct SDP Media > Description" > toc=3D"default"> > As described in target=3D"RFC3550"/>, RTP packets are associated with RTP streams > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each RTP= stream > is > identified by an SSRC value, and each RTP packet carries an SSRC > value > that is used to associate the packet with the correct RTP stream. > RTCP > packets also uses SSRCs to identify on which RTP streams any repor= t > or > feedback relate to. Thus, an RTCP packet will commonly carry > multiple > SSRC values, and might therefore be providing feedback or report o= n > multiple RTP streams. > > In order to be able to process received RTP packets correctly i= t > must be possible to associate an RTP stream with the correct "m=3D= " > line, as the "m=3D" line and SDP attributes associated with the "m= =3D" > line contain information needed to process the packets. > > As all RTP streams associated with a BUNDLE group are part of t= he > same RTP session and using the same address:port combination for > sending and receiving RTP/RTCP packets, the local address:port > combination cannot be used to associate an RTP stream with the > correct > "m=3D" line. In addition, multiple RTP streams might be associated > with > the same "m=3D" line. > > Also, as described in target=3D"sec-rtp-sessions-pt"/>, the same payload type value migh= t be > used by multiple RTP streams, in which case the payload type value > cannot be used to associate an RTP stream with the correct "m=3D" > line. > However, there are cases where each "m=3D" line has unique payload > type > values, and then the payload type could serve as hint to the > relevant > "m=3D" line the RTP stream is associated with. > > An offerer and answerer can inform each other which SSRC values > they will use for an RTP stream by using the SDP 'ssrc' attribute > . Ho= wever, > an > offerer will not know which SSRC values the answerer will use unti= l > the offerer has received the answer providing that information. Du= e > to > this, before the offerer has received the answer, the offerer will > not > be able to associate an RTP stream with the correct "m=3D" line us= ing > the SSRC value associated with the RTP stream. In addition, the > offerer and answerer may start using new SSRC values mid-session, > without informing each other using the SDP 'ssrc' attribute. > > In order for an offerer and answerer to always be able to > associate > an RTP stream with the correct "m=3D" line, the offerer and answer= er > using the BUNDLE extension MUST support the mechanism defined in > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"/>, = where > the > offerer and answerer includes the identification-tag (provided by > the > remote peer) associated with an "m=3D" line in the RTP Streams and= in > RTCP SDES packets part of a BUNDLE group. > > The mapping from an SSRC to an identification-tag is carried in > RTCP SDES packets or in RTP header extensions ( format=3D"default" > pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compound R= TCP > packet can contain multiple RTCP SDES packets, and each RTCP SDES > packet can contain multiple chunks, an RTCP packet can contain > several > SSRC to identification-tag mappings. The offerer and answerer > maintain > tables mapping RTP streams identified by SSRC to "m=3D" lines > identified > by the identification-tag. > When receiving an RTP packet carrying a MID header extension > with the identification-tag, or an RTCP packet carrying one or > more SDES MID items, the offerer or answerer creates a mapping > table entry between the SSRC value and the identification-tag, > in order to associate the RTP stream associated with that SSRC > value with the "m=3D" line corresponding to the > identification-tag. > > The mapping between the SSRC an identification-tag might change > mid-session if, for a given SSRC value, a different > identification-tag > is provided in an RTP or RTCP packet. In that case these tables ar= e > updated each time an RTP/RTCP packet containing a new mappings fro= m > SSRC to identification-tag is received. Some considerations for > avoiding update flaps are provided in Section 4.2.6 of target=3D"RFC7941"/> which should be followed. > > If an offerer and answerer is not able to associate an RTP stre= am > with an "m=3D" line (using the mechanisms described in this sectio= n, > or > using other appropriate mechanism, e.g., based on the payload type > value if it is unique to a single "m=3D" line), it MUST either dro= p > the > RTP packets associated with the RTP stream, or process them in an > application specific manner, once non-stream specific processing > (e.g., related to congestion control) of the RTP packets have > occurred. > > When compound RTCP packets are received, they are split > into their component RTCP packets and those component RTCP > packets are processed based on their RTCP packet type, in > the order in which they were placed into the compound RTCP > packet. Non-compound RTCP packets are processed based on > their RTCP packet type, in the order they are received. Informatio= n > in each RTCP packet can relate to one or more RTP streams. > For example, RTCP Sender Report (SR) and Receiver Report (RR) > packets include an SSRC of sender field that indicates the > identity of the participant that sent the RTCP packet, along > with a list of Report Blocks. Each report contains data on the > reception quality of a single RTP stream, identified by SSRC, > as received by the SSRC that sent the RTCP packet. Other RTCP > packet types similarly contain references to the SSRC of the > sender of the RTCP packet, and the RTP streams to which it > refers. > > It should always be possible to process RTCP packets, and > store the received information in a data structure associated > with an RTP stream, identified by SSRC, for later access and > use. It is possible that RTCP packets relating to an SSRC can > be received before RTP packets relating to that SSRC, so the > data structures relating to an SSRC might need to be created > before the corresponding RTP stream is received. > > Similarly, information relating to an RTP stream might be > received before the data needed to map it onto an m=3D line is > received. Information carried in RTCP packets relating to such > an RTP stream that is application and/or "m=3D" line dependent > MAY be dropped until the SSRCs is associated with a particular > "m=3D" line. However, information to generate RTCP report blocks > and other basic transport level feedback or reporting needs to > be retained, so RTCP reports relating to the stream can be > generated. > >
> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a113f26fc621bbc054574d43b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I made a PR for JSEP that incorporates your text *and* add= s a more specific algorithm which only uses MID and SSRC latching (my inter= pretation of your text, which I'm still not sure is correct):

<= /div>


In practice, I think this is mostly word smithing and doesn't req= uire a virtual interim.=C2=A0 The big questions, which perhaps to require a= virtual interim, are:

1.=C2=A0 Do we want to incl= ude PT demux in the algorithm (when neither SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signaled SSRCs in the demux algorithm= (the SSRC table is loaded with signaled SSRCs)?

T= he question to both of those is "yes" in PR 411 and "no"= ; in PR 489.

On = Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher <pthatcher@google.com> wrote:
When I read your text, I get the impression = that you want to simplify the algorithm to only supporting MIDs for demux w= ith SSRC latching.=C2=A0 No PT demux. =C2=A0 No SSRC demux (except for ones= latched by MID). =C2=A0 In other words, if you want to use BUNDLE, you mus= t use MID and only MID.

But it's not clear if that&#= 39;s the case.=C2=A0 Perhaps I missed something.=C2=A0 I agree with others = that a more explicit algorithm would make your intention clear.

To help, here is my interpretation of your text as an algorithm.=C2= =A0 Please let me know if it's a correct interpretation:

=
=C2=A0 =C2=A0 <section title=3D"Appendix B" an= chor=3D"sec.appendix-b">
=C2=A0 =C2=A0 =C2=A0 <t&= gt;To prepare for demultiplexing RTP packets to the correct "m=3D"= ;
=C2=A0 =C2=A0 =C2=A0 line, the following steps MUST be followed= for each BUNDLE
=C2=A0 =C2=A0 =C2=A0 group.</t>
=
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t&= gt;Construct a table mapping MID to "m=3D" line for each "m= =3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line in this BUNDLE = group.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <t>Construct an empty table mapping incoming SSRC to "m=3D&q= uot; line. </t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0 =C2=A0 </t>

=C2=A0 = =C2=A0 =C2=A0 <t>As "m=3D" lines are added or removed from = the BUNDLE groups, or
=C2=A0 =C2=A0 =C2=A0 their configurations a= re changed, the tables above must also be
=C2=A0 =C2=A0 =C2=A0 up= dated.</t>

=C2=A0 =C2=A0 =C2=A0 <t>For= each RTP packet received, the following steps MUST be
=C2=A0 =C2= =A0 =C2=A0 followed to route the packet to the correct "m=3D" sec= tion within
=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:</t>
<= div>
=C2=A0 =C2=A0 =C2=A0 <t>
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= ;t>If the packet has a MID and that MID is not in the table
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D" line, dr= op the packet and stop.</t>

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <t>If the packet has a MID and that MID is in th= e table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m= =3D" line, update the incoming SSRC mapping
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 table to include an entry that maps the packet's S= SRC to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m=3D" li= ne for that MID.</t>

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 <t>If the packet's SSRC is in the incoming SSRC map= ping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route the packet t= o the associated "m=3D" line and
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 stop.</t>

=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 <t>Otherwise, drop the packet.</t>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0 =C2=A0 </= t>

... similar for RTCP ...
=C2=A0 = =C2=A0 </section>



<= div dir=3D"auto" class=3D"gmail_msg">

On Thu, Dec 8, 2016, 2:55 AM Colin Perkins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing updates to JSEP and BUNDLE to try to clarify the behaviour.

Comments and feedback very welcome.

Cheers,
Colin



# Replacement for Section 6 of draft-ietf-rtcweb-jsep-17

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.=C2= =A0 RTCP
=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=C2=A0 =C2=A0 streams.</t>

=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC, is= mapped to
=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= using
=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/> to= distinguish between
=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negotiatio= n"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = on
=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>

=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-negotia= tion-36

=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect RTP stream. RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which RTP= streams any report or
=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback or report on
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process received= RTP packets correctly it
=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream with= the correct "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE group are part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:port= combination for
=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream with the correct
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple RTP= streams might be associated with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/>, t= he same payload type value might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case the = payload type value
=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve as= hint to the relevant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;m=3D" line the RTP stream is associated with.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform each= other which SSRC values
=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the SDP= 'ssrc' attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno=3D&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC to= "m=3D" lines identified
=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific processing
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the RTP= packets have
=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. Other RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to the= SSRC of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP streams t= o which it
=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




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




_______________________________________________
mmusic mailing list
mm= usic@ietf.org
https://www.ietf.org/mailman/listinf= o/mmusic
<= /div> --001a113f26fc621bbc054574d43b-- From nobody Fri Jan 6 16:48:29 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 9CDCE1296D6; Fri, 6 Jan 2017 16:48:27 -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 wrLO2EuHVU6T; Fri, 6 Jan 2017 16:48:24 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 1309B12966F; Fri, 6 Jan 2017 16:48:24 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id i68so316174363uad.0; Fri, 06 Jan 2017 16:48:24 -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=edd4bW3v15+fZqChu6iZBDAfDphbZKnXuv4wIj0fSuo=; b=T0RKUeB3CY8T3HO+36OHy+vpwwkFqJ0CG860PoTlSMOFZt0XiKQ52GVU//NkblU8E4 96cCXlGWjF8rQ5rbi1RDnm7uxS2kt2l6RbQDvJxpBvvhdq+q3Dq9aLCxfjQaBFSTNv2q NvSsyzk0b0sfJbpmBqem2WdQ0FjLi1KTR9ULWo0qUeClmDZ9c6H7Z0tWsn455+IaHfLI PLBOGM31pPzNIcy7ysji7zHsIL6HSTjMc7lAe2YDi08IjheuyL5hXvviDfz3OJWo939t GwvH+t8QDuOUCMv3bRgQuy8tn/R+qV+ZRhKMUKFxWQH9pGyVfNKMNfliVa6lbOL42VwL pSiQ== 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=edd4bW3v15+fZqChu6iZBDAfDphbZKnXuv4wIj0fSuo=; b=WfZaIm5uRJBzttriWRmnk7KcY4SiJ65ozuOCcqDnvzOkjn2eXvzzDZA1zBB/C+xcHv x1GuYxSLY5OU9xIn0YROax1eE8UpBOXPOTQCAkENmj6YCmqPzvY+x91CT6JMZPZTEZmN zqdQ9Q59D5REl27edxUkkUxVSwG7Q6RwolvMqJqxjPLLZ9vB4BLWfrfhn6PVlQGDIStE rQgrCY9xuA3UTg0DlqlvjZcK7VNVsTI2AxtP0ZObp+w4l+z3Z0DE0RmcbZPDPv1SR1Va GBIXkSewoFqjqc5NAs20nTPLjv6/kiPLQUtvxU3RX3aQxHhNlFJcrn9Zw5Lyf2G0A+Xp p/sA== X-Gm-Message-State: AIkVDXIv7ORLdYVylX2Lil0o6CMOgP1XRc0xOZ5dX1zDMWsH++DeekS0R1PmonrVacAbmb8Pcr3O9mZnzotjjw== X-Received: by 10.159.50.138 with SMTP id l10mr49935579uab.166.1483750102763; Fri, 06 Jan 2017 16:48:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.6.37 with HTTP; Fri, 6 Jan 2017 16:48:02 -0800 (PST) In-Reply-To: References: From: Bernard Aboba Date: Fri, 6 Jan 2017 16:48:02 -0800 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=f403045ddf7acf8ed60545767d23 Archived-At: Cc: Magnus Westerlund , "mmusic \(E-mail\)" , draft-ietf-rtcweb-jsep@tools.ietf.org, "rtcweb@ietf.org" , Colin Perkins , draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org Subject: Re: [MMUSIC] RTP demux in JSEP and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 07 Jan 2017 00:48:27 -0000 --f403045ddf7acf8ed60545767d23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter said: " In practice, I think this is mostly word smithing and doesn't require a virtual interim. The big questions, which perhaps to require a virtual interim, are: 1. Do we want to include PT demux in the algorithm (when neither SSRC nor MID match)? 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC table is loaded with signaled SSRCs)? " [BA] I believe that we need to cover both #1 and #2. 1. There have been bugs filed against implementations that relate to PT demux (e.g. SSRC change scenario). So IMHO covering PT demux is necessary. JSEP-17 was pretty close, but tere are a few issues that still need to be discussed: a. SSRC latching on a PT match. If the PT can change without SSRC changing (e.g. in a video scenario where all codecs have the same clockrate), it seems that latching could result in mis-routing. b. Whether the PT_table is filled if SSRCs are signaled in codecs and/or RTX/FEC. Implementations are doing different things here, and that is going to cause problems. 2. Including signaled SSRCs in the demux algorithm is a practical requirement because SSRC signaling is widely implemented and MID isn't yet. Also, when discussing RTCP segment routing, doesn't the SSRC_table come into play (e.g. in deciding which receiver to route a Sender Report to)? On Fri, Jan 6, 2017 at 2:49 PM, Peter Thatcher wrote= : > I made a PR for JSEP that incorporates your text *and* adds a more > specific algorithm which only uses MID and SSRC latching (my interpretati= on > of your text, which I'm still not sure is correct): > > https://github.com/rtcweb-wg/jsep/pull/489 > > > In practice, I think this is mostly word smithing and doesn't require a > virtual interim. The big questions, which perhaps to require a virtual > interim, are: > > 1. Do we want to include PT demux in the algorithm (when neither SSRC no= r > MID match)? > 2. Do we want to include signaled SSRCs in the demux algorithm (the SSRC > table is loaded with signaled SSRCs)? > > The question to both of those is "yes" in PR 411 and "no" in PR 489. > > On Fri, Jan 6, 2017 at 11:23 AM Peter Thatcher > wrote: > >> When I read your text, I get the impression that you want to simplify th= e >> algorithm to only supporting MIDs for demux with SSRC latching. No PT >> demux. No SSRC demux (except for ones latched by MID). In other word= s, >> if you want to use BUNDLE, you must use MID and only MID. >> >> But it's not clear if that's the case. Perhaps I missed something. I >> agree with others that a more explicit algorithm would make your intenti= on >> clear. >> >> To help, here is my interpretation of your text as an algorithm. Please >> let me know if it's a correct interpretation: >> >>
>> To prepare for demultiplexing RTP packets to the correct "m=3D" >> line, the following steps MUST be followed for each BUNDLE >> group. >> >> >> >> Construct a table mapping MID to "m=3D" line for each "m=3D= " >> line in this BUNDLE group. >> >> Construct an empty table mapping incoming SSRC to "m=3D" li= ne. >> >> >> >> >> As "m=3D" lines are added or removed from the BUNDLE groups, or >> their configurations are changed, the tables above must also be >> updated. >> >> For each RTP packet received, the following steps MUST be >> followed to route the packet to the correct "m=3D" section within >> a BUNDLE group: >> >> >> >> If the packet has a MID and that MID is not in the table >> mapping MID to "m=3D" line, drop the packet and stop. >> >> If the packet has a MID and that MID is in the table >> mapping MID to "m=3D" line, update the incoming SSRC mapping >> table to include an entry that maps the packet's SSRC to the >> "m=3D" line for that MID. >> >> If the packet's SSRC is in the incoming SSRC mapping >> table, route the packet to the associated "m=3D" line and >> stop. >> >> Otherwise, drop the packet. >> >> >> >> ... similar for RTCP ... >>
>> >> >> >> >> >> On Thu, Dec 8, 2016, 2:55 AM Colin Perkins wrote: >> >> Hi, >> >> [cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and B= UNDLE >> drafts] >> >> There=E2=80=99s been a lot of discussion on the lists, and at the meetin= g in >> Seoul, around how RTP streams are mapped onto higher-level, application >> meaningful, semantic roles. In particular, around how RTP streams map on= to >> JSEP objects for WebRTC. Magnus Westerlund and I would like to propose t= he >> following updates to JSEP and BUNDLE to try to clarify the behaviour. >> >> Comments and feedback very welcome. >> >> Cheers, >> Colin >> >> >> >> # Replacement for Section 6 of draft-ietf-rtcweb-jsep-17 >> >>
>> As described in , RTP packets are >> associated with RTP streams . Metadata >> about those streams, including source description information >> and reception quality feedback is conveyed in RTCP packets. >> Each RTP stream is identified by an SSRC, and each RTP packet >> carries an SSRC value that is used to associate the packet with >> the correct RTP stream. RTCP packets also use SSRCs to identify >> the RTP streams that the reports and metadata relate to. RTCP >> packets generally carry multiple SSRC values and report on, or >> deliver source description information relating to, several RTP >> streams. >> >> Each incoming RTP stream, identified by its SSRC, is mapped to >> an m=3D section in the SDP. The SDP m=3D sections then correspond to >> RtpReceiver objects. This allows each RTP stream to be associated >> with an RtpTransceiver. Further processing of the RTP stream can >> then be done at the RtpTransceiver level. This includes using >> RID to distinguish between >> multiple Encoded Streams, as well as determine which Source RTP >> stream should be repaired by a given Redundancy RTP stream. >> >> The process of mapping RTP streams onto m=3D sections depends on >> whether streams are bundled or not. If the SDP BUNDLE extension >> is in use, then RTP streams are mapped onto m=3D sections based on >> the MID values as described in >> . If the >> SDP BUNDLE extension is not in use, each m=3D section corresponds >> to a transport layer connection and the RTP streams received on >> that connection correspond to the m=3D section. >> >> Incoming RTCP packets contain metadata including reception >> quality feedback, source description information, and other >> signalling relating to RTP streams. The RTCP packets are parsed, >> the associated RTP streams are identified based on the included >> SSRC values, and the metadata relating to those RTP streams is >> updated (this might include updating the MID information, used >> to associate RTP streams with m=3D sections, if the SDP BUNDLE >> extension is in use). This updated metadata is available to the >> RtpTransceiver objects associated with those RTP streams. >> >>
>> >> >> >> # Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle- >> negotiation-36 >> >>
> title=3D"Associating RTP Streams With Correct SDP Media >> Description" >> toc=3D"default"> >> As described in > target=3D"RFC3550"/>, RTP packets are associated with RTP streams >> > format=3D"default" pageno=3D"false" target=3D"RFC7656"/>. Each RT= P >> stream is >> identified by an SSRC value, and each RTP packet carries an SSRC >> value >> that is used to associate the packet with the correct RTP stream. >> RTCP >> packets also uses SSRCs to identify on which RTP streams any >> report or >> feedback relate to. Thus, an RTCP packet will commonly carry >> multiple >> SSRC values, and might therefore be providing feedback or report = on >> multiple RTP streams. >> >> In order to be able to process received RTP packets correctly = it >> must be possible to associate an RTP stream with the correct "m= =3D" >> line, as the "m=3D" line and SDP attributes associated with the "= m=3D" >> line contain information needed to process the packets. >> >> As all RTP streams associated with a BUNDLE group are part of >> the >> same RTP session and using the same address:port combination for >> sending and receiving RTP/RTCP packets, the local address:port >> combination cannot be used to associate an RTP stream with the >> correct >> "m=3D" line. In addition, multiple RTP streams might be associate= d >> with >> the same "m=3D" line. >> >> Also, as described in > target=3D"sec-rtp-sessions-pt"/>, the same payload type value mig= ht >> be >> used by multiple RTP streams, in which case the payload type valu= e >> cannot be used to associate an RTP stream with the correct "m=3D" >> line. >> However, there are cases where each "m=3D" line has unique payloa= d >> type >> values, and then the payload type could serve as hint to the >> relevant >> "m=3D" line the RTP stream is associated with. >> >> An offerer and answerer can inform each other which SSRC value= s >> they will use for an RTP stream by using the SDP 'ssrc' attribute >> . H= owever, >> an >> offerer will not know which SSRC values the answerer will use unt= il >> the offerer has received the answer providing that information. >> Due to >> this, before the offerer has received the answer, the offerer wil= l >> not >> be able to associate an RTP stream with the correct "m=3D" line u= sing >> the SSRC value associated with the RTP stream. In addition, the >> offerer and answerer may start using new SSRC values mid-session, >> without informing each other using the SDP 'ssrc' attribute. >> >> In order for an offerer and answerer to always be able to >> associate >> an RTP stream with the correct "m=3D" line, the offerer and answe= rer >> using the BUNDLE extension MUST support the mechanism defined in >> > format=3D"default" pageno=3D"false" target=3D"sec-receiver-id"/>,= where >> the >> offerer and answerer includes the identification-tag (provided by >> the >> remote peer) associated with an "m=3D" line in the RTP Streams an= d in >> RTCP SDES packets part of a BUNDLE group. >> >> The mapping from an SSRC to an identification-tag is carried i= n >> RTCP SDES packets or in RTP header extensions (> format=3D"default" >> pageno=3D"false" target=3D"sec-receiver-id"/>). Since a compound = RTCP >> packet can contain multiple RTCP SDES packets, and each RTCP SDES >> packet can contain multiple chunks, an RTCP packet can contain >> several >> SSRC to identification-tag mappings. The offerer and answerer >> maintain >> tables mapping RTP streams identified by SSRC to "m=3D" lines >> identified >> by the identification-tag. >> When receiving an RTP packet carrying a MID header extension >> with the identification-tag, or an RTCP packet carrying one or >> more SDES MID items, the offerer or answerer creates a mapping >> table entry between the SSRC value and the identification-tag, >> in order to associate the RTP stream associated with that SSRC >> value with the "m=3D" line corresponding to the >> identification-tag. >> >> The mapping between the SSRC an identification-tag might chang= e >> mid-session if, for a given SSRC value, a different >> identification-tag >> is provided in an RTP or RTCP packet. In that case these tables a= re >> updated each time an RTP/RTCP packet containing a new mappings fr= om >> SSRC to identification-tag is received. Some considerations for >> avoiding update flaps are provided in Section 4.2.6 of > target=3D"RFC7941"/> which should be followed. >> >> If an offerer and answerer is not able to associate an RTP >> stream >> with an "m=3D" line (using the mechanisms described in this secti= on, >> or >> using other appropriate mechanism, e.g., based on the payload typ= e >> value if it is unique to a single "m=3D" line), it MUST either dr= op >> the >> RTP packets associated with the RTP stream, or process them in an >> application specific manner, once non-stream specific processing >> (e.g., related to congestion control) of the RTP packets have >> occurred. >> >> When compound RTCP packets are received, they are split >> into their component RTCP packets and those component RTCP >> packets are processed based on their RTCP packet type, in >> the order in which they were placed into the compound RTCP >> packet. Non-compound RTCP packets are processed based on >> their RTCP packet type, in the order they are received. Informati= on >> in each RTCP packet can relate to one or more RTP streams. >> For example, RTCP Sender Report (SR) and Receiver Report (RR) >> packets include an SSRC of sender field that indicates the >> identity of the participant that sent the RTCP packet, along >> with a list of Report Blocks. Each report contains data on the >> reception quality of a single RTP stream, identified by SSRC, >> as received by the SSRC that sent the RTCP packet. Other RTCP >> packet types similarly contain references to the SSRC of the >> sender of the RTCP packet, and the RTP streams to which it >> refers. >> >> It should always be possible to process RTCP packets, and >> store the received information in a data structure associated >> with an RTP stream, identified by SSRC, for later access and >> use. It is possible that RTCP packets relating to an SSRC can >> be received before RTP packets relating to that SSRC, so the >> data structures relating to an SSRC might need to be created >> before the corresponding RTP stream is received. >> >> Similarly, information relating to an RTP stream might be >> received before the data needed to map it onto an m=3D line is >> received. Information carried in RTCP packets relating to such >> an RTP stream that is application and/or "m=3D" line dependent >> MAY be dropped until the SSRCs is associated with a particular >> "m=3D" line. However, information to generate RTCP report blocks >> and other basic transport level feedback or reporting needs to >> be retained, so RTCP reports relating to the stream can be >> generated. >> >>
>> >> >> >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> _______________________________________________ >> 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 > > --f403045ddf7acf8ed60545767d23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Peter said:=C2=A0

"
In practice, I think this is mostly word smithing an= d doesn't require a virtual interim.=C2=A0 The big questions, which per= haps to require a virtual interim, are:

1.=C2=A0 Do we want to include = PT demux in the algorithm (when neither SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signaled SSRCs= in the demux algorithm (the SSRC table is loaded with signaled SSRCs)?
"

[BA] =C2=A0I believe that we need to= cover both #1 and #2.=C2=A0

1. There have been bu= gs filed against implementations that relate to PT demux (e.g. SSRC change = scenario).=C2=A0 So IMHO covering PT demux is necessary.=C2=A0 JSEP-17 was = pretty close, but tere are a few issues that still need to be discussed:
=C2=A0 =C2=A0 =C2=A0a.=C2=A0 SSRC latching on a PT match.=C2=A0 If = the PT can change without SSRC changing (e.g. in a video scenario where all= codecs have the same clockrate), it seems that latching could result in mi= s-routing.=C2=A0
=C2=A0 =C2=A0 =C2=A0b. Whether the PT_table is f= illed if SSRCs are signaled in codecs and/or RTX/FEC.=C2=A0 Implementations= are doing different things here, and that is going to cause problems. =C2= =A0

2. Including signaled SSRCs in the demux algor= ithm is a practical requirement because SSRC signaling is widely implemente= d and MID isn't yet.=C2=A0 Also, when discussing RTCP segment routing, = doesn't the SSRC_table come into play (e.g. in deciding which receiver = to route a Sender Report to)?=C2=A0
<= br>
On Fri, Jan 6, 2017 at 2:49 PM, Peter Thatche= r <pthatcher@google.com> wrote:
I made a PR for JSEP that incorporates your text = *and* adds a more specific algorithm which only uses MID and SSRC latching = (my interpretation of your text, which I'm still not sure is correct):<= div>
https://github.com/rtcweb-wg/jsep/pull/489


In practice, I think this is mostly w= ord smithing and doesn't require a virtual interim.=C2=A0 The big quest= ions, which perhaps to require a virtual interim, are:

=
1.=C2=A0 Do we want to include PT demux in the algorithm (when neither= SSRC nor MID match)? =C2=A0
2.=C2=A0 Do we want to include signa= led SSRCs in the demux algorithm (the SSRC table is loaded with signaled SS= RCs)?

The question to both of those is "yes&q= uot; in PR 411 and "no" in PR 489.

On Fri= , Jan 6, 2017 at 11:23 AM Peter Thatcher <pthatcher@google.com> wrote:
When I read your text, I get = the impression that you want to simplify the algorithm to only supporting M= IDs for demux with SSRC latching.=C2=A0 No PT demux. =C2=A0 No SSRC demux (= except for ones latched by MID). =C2=A0 In other words, if you want to use = BUNDLE, you must use MID and only MID.

But it's not = clear if that's the case.=C2=A0 Perhaps I missed something.=C2=A0 I agr= ee with others that a more explicit algorithm would make your intention cle= ar.

To help, here is my interpretation of your text as a= n algorithm.=C2=A0 Please let me know if it's a correct interpretation:=

=C2=A0 =C2=A0 <section title=3D"Appe= ndix B" anchor=3D"sec.appendix-b">
=C2=A0 =C2= =A0 =C2=A0 <t>To prepare for demultiplexing RTP packets to the correc= t "m=3D"
=C2=A0 =C2=A0 =C2=A0 line, the following steps= MUST be followed for each BUNDLE
=C2=A0 =C2=A0 =C2=A0 group.<= /t>

=C2=A0 =C2=A0 =C2=A0 <t>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <t>Construct a table mapping MID to "m=3D" line = for each "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 line= in this BUNDLE group.</t>

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 <t>Construct an empty table mapping incoming SSRC t= o "m=3D" line. </t>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &= lt;/list>
=C2=A0 =C2=A0 =C2=A0 </t>

=
=C2=A0 =C2=A0 =C2=A0 <t>As "m=3D" lines are added or r= emoved from the BUNDLE groups, or
=C2=A0 =C2=A0 =C2=A0 their conf= igurations are changed, the tables above must also be
=C2=A0 =C2= =A0 =C2=A0 updated.</t>

=C2=A0 =C2=A0 =C2=A0= <t>For each RTP packet received, the following steps MUST be
=C2=A0 =C2=A0 =C2=A0 followed to route the packet to the correct "m= =3D" section within
=C2=A0 =C2=A0 =C2=A0 a BUNDLE group:<= /t>

=C2=A0 =C2=A0 =C2=A0 <t>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 <list>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <t>If the packet has a MID and that MID is not in the tabl= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID to "m=3D&qu= ot; line, drop the packet and stop.</t>

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet has a MID and that M= ID is in the table
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mapping MID= to "m=3D" line, update the incoming SSRC mapping
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table to include an entry that maps the pac= ket's SSRC to the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "m= =3D" line for that MID.</t>

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <t>If the packet's SSRC is in the incomi= ng SSRC mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 table, route t= he packet to the associated "m=3D" line and
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 stop.</t>

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Otherwise, drop the packet.</t><= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </list>
=C2=A0 =C2=A0= =C2=A0 </t>

... similar for RTCP ...
<= div>=C2=A0 =C2=A0 </section>

<= div dir=3D"auto" class=3D"m_-8552972565696268422gmail_msg">



On Thu, Dec 8, 2016, 2:55 AM Colin Per= kins <csp@csperkins.org> wrote:
Hi,

[cc=E2=80=99ing RTCWEB and MMUSIC, since this relates to both JSEP and BUND= LE drafts]

There=E2=80=99s been a lot of discussion on the lists, and at the meeting i= n Seoul, around how RTP streams are mapped onto higher-level, application m= eaningful, semantic roles. In particular, around how RTP streams map onto J= SEP objects for WebRTC. Magnus Westerlund and I would like to propose the f= ollowing updates to JSEP and BUNDLE to try to clarify the behaviour.

Comments and feedback very welcome.

Cheers,
Colin



# Replacement for Section 6 of draft-ietf-rtcweb-jsep-17

=C2=A0<section title=3D"Processing RTP/RTCP" anchor=3D"se= c.rtp.demux">
=C2=A0 =C2=A0 <t>As described in <xref target=3D"RFC3550"= ;/>, RTP packets are
=C2=A0 =C2=A0 associated with RTP streams <xref target=3D"RFC7656&q= uot;/>. Metadata
=C2=A0 =C2=A0 about those streams, including source description information=
=C2=A0 =C2=A0 and reception quality feedback is conveyed in RTCP packets. =C2=A0 =C2=A0 Each RTP stream is identified by an SSRC, and each RTP packet=
=C2=A0 =C2=A0 carries an SSRC value that is used to associate the packet wi= th
=C2=A0 =C2=A0 the correct RTP stream. RTCP packets also use SSRCs to identi= fy
=C2=A0 =C2=A0 the RTP streams that the reports and metadata relate to.=C2= =A0 RTCP
=C2=A0 =C2=A0 packets generally carry multiple SSRC values and report on, o= r
=C2=A0 =C2=A0 deliver source description information relating to, several R= TP
=C2=A0 =C2=A0 streams.</t>

=C2=A0 =C2=A0 <t>Each incoming RTP stream, identified by its SSRC, is= mapped to
=C2=A0 =C2=A0 an m=3D section in the SDP. The SDP m=3D sections then corres= pond to
=C2=A0 =C2=A0 RtpReceiver objects. This allows each RTP stream to be associ= ated
=C2=A0 =C2=A0 with an RtpTransceiver. Further processing of the RTP stream = can
=C2=A0 =C2=A0 then be done at the RtpTransceiver level.=C2=A0 This includes= using
=C2=A0 =C2=A0 RID <xref target=3D"I-D.ietf-mmusic-rid"/> to= distinguish between
=C2=A0 =C2=A0 multiple Encoded Streams, as well as determine which Source R= TP
=C2=A0 =C2=A0 stream should be repaired by a given Redundancy RTP stream.&l= t;/t>

=C2=A0 =C2=A0 <t>The process of mapping RTP streams onto m=3D section= s depends on
=C2=A0 =C2=A0 whether streams are bundled or not. If the SDP BUNDLE extensi= on
=C2=A0 =C2=A0 is in use, then RTP streams are mapped onto m=3D sections bas= ed on
=C2=A0 =C2=A0 the MID values as described in
=C2=A0 =C2=A0 <xref target=3D"I-D.ietf-mmusic-sdp-bundle-negot= iation"/>.=C2=A0 If the
=C2=A0 =C2=A0 SDP BUNDLE extension is not in use, each m=3D section corresp= onds
=C2=A0 =C2=A0 to a transport layer connection and the RTP streams received = on
=C2=A0 =C2=A0 that connection correspond to the m=3D section.</t>

=C2=A0 =C2=A0 <t>Incoming RTCP packets contain metadata including rec= eption
=C2=A0 =C2=A0 quality feedback, source description information, and other =C2=A0 =C2=A0 signalling relating to RTP streams. The RTCP packets are pars= ed,
=C2=A0 =C2=A0 the associated RTP streams are identified based on the includ= ed
=C2=A0 =C2=A0 SSRC values, and the metadata relating to those RTP streams i= s
=C2=A0 =C2=A0 updated (this might include updating the MID information, use= d
=C2=A0 =C2=A0 to associate RTP streams with m=3D sections, if the SDP BUNDL= E
=C2=A0 =C2=A0 extension is in use). This updated metadata is available to t= he
=C2=A0 =C2=A0 RtpTransceiver objects associated with those RTP streams.
=C2=A0 =C2=A0 </t>
=C2=A0</section>



# Replacement text for section 10.2 of draft-ietf-mmusic-sdp-bundle-ne= gotiation-36

=C2=A0 =C2=A0 =C2=A0<section anchor=3D"sec-rtp-pt"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 title=3D"Associating = RTP Streams With Correct SDP Media Description"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 toc=3D"default"&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As described in <xref format=3D"= ;default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC3550"/>, RTP packets a= re associated with RTP streams <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"RFC7656"/>. Each RTP stream is
=C2=A0 =C2=A0 =C2=A0 =C2=A0identified by an SSRC value, and each RTP packet= carries an SSRC value
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is used to associate the packet with the co= rrect RTP stream. RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets also uses SSRCs to identify on which RTP= streams any report or
=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback relate to. Thus, an RTCP packet will co= mmonly carry multiple
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC values, and might therefore be providing fe= edback or report on
=C2=A0 =C2=A0 =C2=A0 =C2=A0multiple RTP streams. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order to be able to process received= RTP packets correctly it
=C2=A0 =C2=A0 =C2=A0 =C2=A0must be possible to associate an RTP stream with= the correct "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line, as the "m=3D" line and SDP attri= butes associated with the "m=3D"
=C2=A0 =C2=A0 =C2=A0 =C2=A0line contain information needed to process the p= ackets.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>As all RTP streams associated with a BU= NDLE group are part of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0same RTP session and using the same address:port= combination for
=C2=A0 =C2=A0 =C2=A0 =C2=A0sending and receiving RTP/RTCP packets, the loca= l address:port
=C2=A0 =C2=A0 =C2=A0 =C2=A0combination cannot be used to associate an RTP s= tream with the correct
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. In addition, multiple RTP= streams might be associated with
=C2=A0 =C2=A0 =C2=A0 =C2=A0the same "m=3D" line.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Also, as described in <xref format= =3D"default" pageno=3D"false"
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"sec-rtp-sessions-pt"/&g= t;, the same payload type value might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0used by multiple RTP streams, in which case the = payload type value
=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be used to associate an RTP stream with t= he correct "m=3D" line.
=C2=A0 =C2=A0 =C2=A0 =C2=A0However, there are cases where each "m=3D&q= uot; line has unique payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0values, and then the payload type could serve as= hint to the relevant
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;m=3D" line the RTP stream is associated with.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>An offerer and answerer can inform each= other which SSRC values
=C2=A0 =C2=A0 =C2=A0 =C2=A0they will use for an RTP stream by using the SDP= 'ssrc' attribute
=C2=A0 =C2=A0 =C2=A0 =C2=A0<xref format=3D"default" pageno=3D&= quot;false" target=3D"RFC5576"/>. However, an
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer will not know which SSRC values the answ= erer will use until
=C2=A0 =C2=A0 =C2=A0 =C2=A0the offerer has received the answer providing th= at information. Due to
=C2=A0 =C2=A0 =C2=A0 =C2=A0this, before the offerer has received the answer= , the offerer will not
=C2=A0 =C2=A0 =C2=A0 =C2=A0be able to associate an RTP stream with the corr= ect "m=3D" line using
=C2=A0 =C2=A0 =C2=A0 =C2=A0the SSRC value associated with the RTP stream. I= n addition, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer may start using new SSRC va= lues mid-session,
=C2=A0 =C2=A0 =C2=A0 =C2=A0without informing each other using the SDP '= ssrc' attribute.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>In order for an offerer and answerer to= always be able to associate
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream with the correct "m=3D" = line, the offerer and answerer
=C2=A0 =C2=A0 =C2=A0 =C2=A0using the BUNDLE extension MUST support the mech= anism defined in <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"default" pageno=3D"fals= e" target=3D"sec-receiver-id"/>, where the
=C2=A0 =C2=A0 =C2=A0 =C2=A0offerer and answerer includes the identification= -tag (provided by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote peer) associated with an "m=3D"= line in the RTP Streams and in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets part of a BUNDLE group.</t&= gt;

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping from an SSRC to an identifi= cation-tag is carried in
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTCP SDES packets or in RTP header extensions (&= lt;xref format=3D"default"
=C2=A0 =C2=A0 =C2=A0 =C2=A0pageno=3D"false" target=3D"sec-re= ceiver-id"/>). Since a compound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple RTCP SDES packets, a= nd each RTCP SDES
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet can contain multiple chunks, an RTCP pack= et can contain several
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag mappings. The offerer= and answerer maintain
=C2=A0 =C2=A0 =C2=A0 =C2=A0tables mapping RTP streams identified by SSRC to= "m=3D" lines identified
=C2=A0 =C2=A0 =C2=A0 =C2=A0by the identification-tag.
=C2=A0 =C2=A0 =C2=A0 =C2=A0When receiving an RTP packet carrying a MID head= er extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0with the identification-tag, or an RTCP packet c= arrying one or
=C2=A0 =C2=A0 =C2=A0 =C2=A0more SDES MID items, the offerer or answerer cre= ates a mapping
=C2=A0 =C2=A0 =C2=A0 =C2=A0table entry between the SSRC value and the ident= ification-tag,
=C2=A0 =C2=A0 =C2=A0 =C2=A0in order to associate the RTP stream associated = with that SSRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0value with the "m=3D" line correspondi= ng to the identification-tag.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>The mapping between the SSRC an identif= ication-tag might change
=C2=A0 =C2=A0 =C2=A0 =C2=A0mid-session if, for a given SSRC value, a differ= ent identification-tag
=C2=A0 =C2=A0 =C2=A0 =C2=A0is provided in an RTP or RTCP packet. In that ca= se these tables are
=C2=A0 =C2=A0 =C2=A0 =C2=A0updated each time an RTP/RTCP packet containing = a new mappings from
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC to identification-tag is received. Some con= siderations for
=C2=A0 =C2=A0 =C2=A0 =C2=A0avoiding update flaps are provided in Section 4.= 2.6 of <xref
=C2=A0 =C2=A0 =C2=A0 =C2=A0target=3D"RFC7941"/> which should b= e followed. </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>If an offerer and answerer is not able = to associate an RTP stream
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an "m=3D" line (using the mechani= sms described in this section, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0using other appropriate mechanism, e.g., based o= n the payload type
=C2=A0 =C2=A0 =C2=A0 =C2=A0value if it is unique to a single "m=3D&quo= t; line), it MUST either drop the
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTP packets associated with the RTP stream, or p= rocess them in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0application specific manner, once non-stream spe= cific processing
=C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., related to congestion control) of the RTP= packets have
=C2=A0 =C2=A0 =C2=A0 =C2=A0occurred.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>When compound RTCP packets are received= , they are split
=C2=A0 =C2=A0 =C2=A0 =C2=A0into their component RTCP packets and those comp= onent RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets are processed based on their RTCP packet= type, in
=C2=A0 =C2=A0 =C2=A0 =C2=A0the order in which they were placed into the com= pound RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet. Non-compound RTCP packets are processed = based on
=C2=A0 =C2=A0 =C2=A0 =C2=A0their RTCP packet type, in the order they are re= ceived. Information
=C2=A0 =C2=A0 =C2=A0 =C2=A0in each RTCP packet can relate to one or more RT= P streams.
=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, RTCP Sender Report (SR) and Receive= r Report (RR)
=C2=A0 =C2=A0 =C2=A0 =C2=A0packets include an SSRC of sender field that ind= icates the
=C2=A0 =C2=A0 =C2=A0 =C2=A0identity of the participant that sent the RTCP p= acket, along
=C2=A0 =C2=A0 =C2=A0 =C2=A0with a list of Report Blocks. Each report contai= ns data on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0reception quality of a single RTP stream, identi= fied by SSRC,
=C2=A0 =C2=A0 =C2=A0 =C2=A0as received by the SSRC that sent the RTCP packe= t. Other RTCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0packet types similarly contain references to the= SSRC of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0sender of the RTCP packet, and the RTP streams t= o which it
=C2=A0 =C2=A0 =C2=A0 =C2=A0refers.</t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>It should always be possible to process= RTCP packets, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0store the received information in a data structu= re associated
=C2=A0 =C2=A0 =C2=A0 =C2=A0with an RTP stream, identified by SSRC, for late= r access and
=C2=A0 =C2=A0 =C2=A0 =C2=A0use. It is possible that RTCP packets relating t= o an SSRC can
=C2=A0 =C2=A0 =C2=A0 =C2=A0be received before RTP packets relating to that = SSRC, so the
=C2=A0 =C2=A0 =C2=A0 =C2=A0data structures relating to an SSRC might need t= o be created
=C2=A0 =C2=A0 =C2=A0 =C2=A0before the corresponding RTP stream is received.= </t>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<t>Similarly, information relating to an R= TP stream might be
=C2=A0 =C2=A0 =C2=A0 =C2=A0received before the data needed to map it onto a= n m=3D line is
=C2=A0 =C2=A0 =C2=A0 =C2=A0received. Information carried in RTCP packets re= lating to such
=C2=A0 =C2=A0 =C2=A0 =C2=A0an RTP stream that is application and/or "m= =3D" line dependent
=C2=A0 =C2=A0 =C2=A0 =C2=A0MAY be dropped until the SSRCs is associated wit= h a particular
=C2=A0 =C2=A0 =C2=A0 =C2=A0"m=3D" line. However, information to g= enerate RTCP report blocks
=C2=A0 =C2=A0 =C2=A0 =C2=A0and other basic transport level feedback or repo= rting needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0be retained, so RTCP reports relating to the str= eam can be
=C2=A0 =C2=A0 =C2=A0 =C2=A0generated.</t>

=C2=A0 =C2=A0 =C2=A0</section>




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




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ie= tf.org/mailman/listinfo/mmusic
<= /div>

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

--f403045ddf7acf8ed60545767d23-- From nobody Mon Jan 9 14:09:26 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 1604D1295D5; Mon, 9 Jan 2017 14:09:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148399976207.24923.4744476696701777622.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2017 14:09:22 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:09:22 -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 of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-21.txt Pages : 25 Date : 2017-01-09 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-21 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 Tue Jan 10 05:18: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 B9D86129FB5 for ; Tue, 10 Jan 2017 05:18:10 -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 kIYhHJuPs5Zh for ; Tue, 10 Jan 2017 05:18:09 -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 C4959129C59 for ; Tue, 10 Jan 2017 05:18:07 -0800 (PST) X-AuditID: c1b4fb2d-e83ff7000000561e-75-5874df0c7e23 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 7D.AF.22046.C0FD4785; Tue, 10 Jan 2017 14:18:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Tue, 10 Jan 2017 14:18:04 +0100 From: Christer Holmberg To: Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" Thread-Index: AQHSa0P5xcKfDXqPnU6AtmFI3MJEjQ== Date: Tue, 10 Jan 2017 13:18:04 +0000 Message-ID: References: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> In-Reply-To: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7157B36F64AE7A468397E87BA6C0BAF9@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7qy7f/ZIIg7u7eC32/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjz8IH7AWL+SrOLu1lbGDcxd3FyMEhIWAi 0TxVsouRi0NIYB2jxLfzn5ggnCWMEkd/NzKDFLEJWEh0/9MGMUUE3CTmnUrvYuTkEBYIk9ix fS8TiC0iEC7x+XsDC4StJ3H00DlWEJtFQFViY/81sDivgLXEjxX7mEFsIQE7iTf7e8BsTgF7 iUn7loLZjAJiEt9PrQGbySwgLnHryXwwW0JAQGLJnvPMELaoxMvH/1hBzhEF2rXmfhjEJ0oS 07amQXTqSdyYOoUNwraWePT/MSOErS2xbOFrZohrBCVOznzCMoFRbBaSZbOQtM9C0j4LSfss JO0LGFlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG08Etv3V3MK5+7XiIUYCDUYmHt2Bp cYQQa2JZcWXuIUYJDmYlEd5pt0sihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliS mp2aWpBaBJNl4uCUamAsefs4ds3k9WEH0rxmvrmq9a/+QeEswXsMf49cSb26Izz6r7LFkYeG fR6NDQk5P1XedE0QqrleH7RXrWi5TahT4oOPefrmPtwe7AGfTzqwrNv7u/vk4SPBCybeLwmM nBedf25JmuWCKsuNOkfUli5hPshc0/HoZMnhjY/lst2tVHk0AoKnZzcrsRRnJBpqMRcVJwIA zjlEVqMCAAA= Archived-At: Subject: Re: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 13:18:11 -0000 Hi Adam, My suggestion would be alternative #2. Because, if an endpoint supports the attribute it doesn=B9t really matter what the port value is, so there i= s no need to reject the m- line. Regards, Christer On 29/12/16 23:15, "mmusic on behalf of Adam Roach" wrote: >We've recently come across an issue with the way the "bundle-only" >attribute is described in the current document. The current language >regarding port handling reads: > > The usage of the 'bundle-only' attribute is only defined for a > bundled "m=3D" line with a zero port value, within an offer. Other > usage is unspecified. > >Usually, when we have this kind of language, we still ensure that >behavior is well defined, to help avoid unnecessary interop failures. I >see a couple of different options here: > > 1. Remove the final sentence and add language saying that creators of > SDP MUST NOT include a "bundle-only" attribute in an m-section that > has a non-zero port, and that recipients of such SDP {SHOULD,MUST} > reject it; or > > 2. Retain language saying that including a "bundle-only" attribute in a > non-zero m-section is unspecified, but add normative language along > the lines of: "implementations that receive an m-section with a > non-zero port that also contains a 'bundle-only' attribute MUST > ignore the {attribute,port}." > >I don't have a preference between these choices, but I think we do need >clarity. To be absolutely clear, this feedback is based on actual >implementation interop failures in the field. This problem is not >theoretical. > >/a > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue Jan 10 06:52:13 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 90221129CF8; Tue, 10 Jan 2017 06:51:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148405991758.22274.13989082042251852430.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 06:51:57 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-16.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:51:57 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-16.txt Pages : 25 Date : 2017-01-10 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-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/ From nobody Tue Jan 10 07:03: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 EE809129422; Tue, 10 Jan 2017 07:03:39 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfbW4UGZMu8J; Tue, 10 Jan 2017 07:03:34 -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 25C351294F6; Tue, 10 Jan 2017 06:54:05 -0800 (PST) X-AuditID: c1b4fb2d-e83ff7000000561e-ba-5874f58c90de Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 89.69.22046.C85F4785; Tue, 10 Jan 2017 15:54:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Tue, 10 Jan 2017 15:54:48 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-dtls-sdp-16 Thread-Index: AQHSa1FhIfg7jzC4ZE++Dt2TyeRYXA== Date: Tue, 10 Jan 2017 14:54:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D49AC25F15627christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdVLfna0mEwbK7Chbnd65nspi6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyfs7YylowWbDi7b7pLA2Mj/m6GDk5JARMJC6ffMLW xcjFISSwjlFiz4SlTCAJIYEljBJfDkp0MXJwsAlYSHT/0wYJiwioS3zd28MMYjMLmEo8fLWG EcQWFtCVePX7EiNEjZHE4193mSBsPYlze7+xgIxhEVCV+N6qARLmFbCWOLjkEiuIzSggJvH9 1BomiJHiEreezGeCOE1AYsme88wQtqjEy8f/WEHGiAKNXHM/DMSUEFCUWN4vB2IyCyRITPvu CzFcUOLkzCcsExiFZyGZOQuhahaSKogSHYkFuz+xQdjaEssWvmaGsc8ceAzVai0x4VU+spIF jByrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQLj5+CW37o7GFe/djzEKMDBqMTDW7C0OEKI NbGsuDL3EKMEB7OSCK/Tx5IIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqem FqQWwWSZODilGhjj/wZ33pGdu3VpsVdP2nerzBfP83ab3Llu5TSjN0zX9zbrd+ezN6M+f76Y n6OieUd218eyKW7Ss4ulzu9kLS+XXrzNx8K39k9TUuLlT1vCnnKUZIZk8P+MCQ9daHCqxuL0 hDCen6GqS1i32xwXjC5YrOB5uWD2JkvDP/M1mH74O0xZfHv9W1clluKMREMt5qLiRAC0yX6W mwIAAA== Archived-At: Cc: "mmusic-chairs@ietf.org" Subject: [MMUSIC] Draft new version: draft-dtls-sdp-16 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 15:03:40 -0000 --_000_D49AC25F15627christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Nobody objected to making the dtls-id attribute value globally unique, so I= have submitted a new version (-16) of draft-ietf-mmusic-dtls-sdp in order = to reflex that. Now a DTLS association is only identified by the dtls-id attribute values o= f the offerer and answerer. The fingerprint is no longer used, as the previ= ous text was confusing to many (no matter how we tried to fix it). Regards, Christer --_000_D49AC25F15627christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <68263DC7D104D6458DC4B4E09FCC3651@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

Nobody objected to making the dtls-id attribute value globally unique,= so I have submitted a new version (-16) of draft-ietf-mmusic-dtls-sdp in order to = reflex that.

Now a DT= LS association is only identified by the dtls-id attribute values of the of= ferer and answerer. The fingerprint is no longer used, as the previous text= was confusing to many (no matter how we tried to fix it).

Regards,=

Christer=
--_000_D49AC25F15627christerholmbergericssoncom_-- From nobody Tue Jan 10 07:13:30 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 F41C112A00E; Tue, 10 Jan 2017 07:13:28 -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 HPygr5SU44ID; Tue, 10 Jan 2017 07:13:27 -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 5E3FD12951F; Tue, 10 Jan 2017 07:13:26 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-d6-5874fa15cc8c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B5.9E.22046.51AF4785; Tue, 10 Jan 2017 16:13:25 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:13:23 +0100 To: Eric Rescorla References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> From: Magnus Westerlund Message-ID: <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> Date: Tue, 10 Jan 2017 16:13:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7q67or5IIg5tnBC1WvD7HbjF1+WMW i7X/2tkdmD2WLPnJ5DH5cRtzAFMUl01Kak5mWWqRvl0CV8aNZTcYC77zVjQuXMXcwNjA3cXI ySEhYCIx9/lFti5GLg4hgXWMEtvm9TBBOMsZJT60TmIEqRIWcJA4tnMtC4gtIqAg8evPCTBb SGAKo8SEVwEgNrOAi8SFqY+ZQGw2AQuJmz8a2UBsXgF7iXXPJoLVswioSkybeRwsLioQI/F2 /XJ2iBpBiZMznwDVsHNwCgRK7MiFmGghMXP+eUYIW16ieetsZoit2hINTR2sExgFZiFpnoWk ZRaSlgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAsPz4JbfujsYV792PMQowMGoxMP7 4VtJhBBrYllxZe4hRgkOZiUR3u9fgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUw+mn7P1LbKe70kS2t+5BYq9Wk439j+ye8UPty84qQTjfnUt0fsyfM dVlv2rwsRNXf99GfhFu77wr+mGN7Isp8regj5r+128ouy5+Z013+SKWv2ctjr8Gx09UFxR68 7juTdixWm7QzoGJiCKPXkfSN9pW/v2r33P5qeXjL+RlS6y958STKPi/LVmIpzkg01GIuKk4E AJEvzr9LAgAA Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 15:13:29 -0000 Den 2016-12-22 kl. 18:30, skrev Eric Rescorla: > > > On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund > > Okay, I agree that having any rules for what you should offer here > based on what the actual outcome is not the best idea here. I think > the rules should be based on capability and intent. So if you only > are going offer TCP candidates, then you clearly should use TCP/…, > > > I'm going to push on this. If we've already agreed that mismatches are > normal, why should we do that? Wouldn't it be better to just effectively > deprecate this field? > So, my main argument for including any rules for how to set it, would be that the this part of the PROTO field still has meaning outside of WebRTC context. There one may actually have it to match what is goind to be used. Thus, it can provide some guidance to gateways on what to expect. It might be that we should actually set it to UDP for those not supporting ICE/TCP, and to TCP for the ones that supports both UDP and TCP. That would still provide information to the gateway. I think simple rules based on implementation capabilities for how to set it are better than no rules. Especially as it would carry some information, not zero, which is the result of no rules. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 10 07:44: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 AD0A8129507 for ; Tue, 10 Jan 2017 07:44:27 -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 tcIAm6V9xTs2 for ; Tue, 10 Jan 2017 07:44:26 -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 E621F129504 for ; Tue, 10 Jan 2017 07:44:25 -0800 (PST) X-AuditID: c1b4fb3a-46fff70000005d1c-e5-58750157b06e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id A5.96.23836.75105785; Tue, 10 Jan 2017 16:44:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.319.2; Tue, 10 Jan 2017 16:44:23 +0100 To: Harald Alvestrand , References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> From: Magnus Westerlund Message-ID: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> Date: Tue, 10 Jan 2017 16:44:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7pW4EY2mEwaJ2TotjfV1sFlOXP2Zx YPK4MuEKq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKmTlvPVLBRpKK5V6aBsVegi5GTQ0LAROL1 7t+MXYxcHEIC6xgltp+9ygSSEBJYzijxvbUUxBYWcJA4tnMtC4gtImAvMb9nOTtEw2lGiaO3 LzGCJNgELCRu/mhkA7F5gYp2ff0AFmcRUJV4deok2FBRgRiJt+tBmkFqBCVOznwCNpRTwFFi 95qzrF2MHBzMQL0PtpaBhJkF5CWat85mhrhHW6KhqYN1AiP/LCTdsxA6ZiHpWMDIvIpRtDi1 uDg33chIL7UoM7m4OD9PLy+1ZBMjMPQObvlttYPx4HPHQ4wCHIxKPLwfvpVECLEmlhVX5h5i lOBgVhLhjf0PFOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoFxbV54i0riJM281VL2vBZXNi24+CHtxh+OnS98p/4//su1aX/p0XNfD8+NclumOX2a2it5 y19xxkb/8+LU3jI5zbDI89mvdG3tjzRe0+O/8nx3sKyMSbEuecyjWMM1+4GT0kSp7JuNnx8/ n8pr6ltkc/veyt7OdZ949679suzH8kdzE5adtXCbq8RSnJFoqMVcVJwIAD/YoHw5AgAA Archived-At: Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 15:44:27 -0000 Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand: > Den 22. des. 2016 18:30, skrev Eric Rescorla: >> __ >> >> Okay, I agree that having any rules for what you should offer here >> based on what the actual outcome is not the best idea here. I think >> the rules should be based on capability and intent. So if you only >> are going offer TCP candidates, then you clearly should use TCP/…, >> >> >> I'm going to push on this. If we've already agreed that mismatches are >> normal, why should we do that? Wouldn't it be better to just effectively >> deprecate this field? >> > > Concur with EKR. > > This field (the TCP/UDP part of the protocol field) was defined in a way > that makes its original purpose (to negotiate profiles) not only > impossible while using ICE, but actively harmful, because you end up > telling lies in very many cases, so people will have to accept things > that don't match reality. > > Make the world as simple for implementors as possible: Send a fixed > string, and accept all strings. > Okay, can we please be precise with what is suggested here. Because what you write above, and what EKR proposed is not really the same thing. The issue proposed that it was fine to set either of the strings. You saying a fixed string. I want to ask you which UDP/... or TCP/..., or even ICE/DTLS/RTP/SAVPF? From a strict clarity issue using ICE/... would be my preferred. But, that is probably going to throw some implementations, especially gateways. It will also require us to actually go write the registration to explain what it is. Using UDP is likely the most compatible and will only fail in gateway cases where there are no UDP candidates and the gateway fail to pick that up. Using TCP when there are no TCP candidates are equally misleading to gateway cases. The above is why I proposed that implementation capabilities and any configuration to limit what functions being used would be an appropriate choice. I hope at least we can agree that an JSEP Answer MUST use the PROTO string of the OFFER? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 10 08:12: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 D0538129BC5 for ; Tue, 10 Jan 2017 08:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 FIUJdnn0wxHi for ; Tue, 10 Jan 2017 08:12:34 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAB71295DE for ; Tue, 10 Jan 2017 08:12:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5986C7C4E13; Tue, 10 Jan 2017 17:12:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q68jdpCpu8wt; Tue, 10 Jan 2017 17:12:31 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 6A7A07C4E12; Tue, 10 Jan 2017 17:12:31 +0100 (CET) To: Magnus Westerlund , mmusic@ietf.org References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> From: Harald Alvestrand Message-ID: <352cc52c-0c52-9332-a7ce-4533aed6c2fd@alvestrand.no> Date: Tue, 10 Jan 2017 17:12:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 16:12:37 -0000 Den 10. jan. 2017 16:44, skrev Magnus Westerlund: > Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand: >> Den 22. des. 2016 18:30, skrev Eric Rescorla: >>> __ >>> >>> Okay, I agree that having any rules for what you should offer here >>> based on what the actual outcome is not the best idea here. I think >>> the rules should be based on capability and intent. So if you only >>> are going offer TCP candidates, then you clearly should use TCP/…, >>> >>> >>> I'm going to push on this. If we've already agreed that mismatches are >>> normal, why should we do that? Wouldn't it be better to just effectively >>> deprecate this field? >>> >> >> Concur with EKR. >> >> This field (the TCP/UDP part of the protocol field) was defined in a way >> that makes its original purpose (to negotiate profiles) not only >> impossible while using ICE, but actively harmful, because you end up >> telling lies in very many cases, so people will have to accept things >> that don't match reality. >> >> Make the world as simple for implementors as possible: Send a fixed >> string, and accept all strings. >> > > Okay, can we please be precise with what is suggested here. Because what > you write above, and what EKR proposed is not really the same thing. The > issue proposed that it was fine to set either of the strings. You saying > a fixed string. I want to ask you which UDP/... or TCP/..., or even > ICE/DTLS/RTP/SAVPF? The current JSEP language is: 5.1.3. Profile Names and Interoperability For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer. For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they produce in an offer. Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually selecting either either UDP or TCP. The current proposal (as I interpret EKR) is to replace ....and MUST indicate one of these two profiles for each data m= line they produce in an offer. Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually selecting either either UDP or TCP. with ....and MUST indicate UDP/TLS/RTP/SAVPF for each data m= line they produce in an offer. Because ICE can select either TCP or UDP transport depending on network conditions, this consistent with ICE eventually selecting either either UDP or TCP. > > From a strict clarity issue using ICE/... would be my preferred. But, > that is probably going to throw some implementations, especially > gateways. It will also require us to actually go write the registration > to explain what it is. We lost clarity when ICE was introduced without redesigning the "protocol" field. Trying to get it back is not helping anyone. > > Using UDP is likely the most compatible and will only fail in gateway > cases where there are no UDP candidates and the gateway fail to pick > that up. > > Using TCP when there are no TCP candidates are equally misleading to > gateway cases. > > The above is why I proposed that implementation capabilities and any > configuration to limit what functions being used would be an appropriate > choice. > > I hope at least we can agree that an JSEP Answer MUST use the PROTO > string of the OFFER? We agreed on that long ago. Section 5.3.1 of JSEP: o The field MUST be set to exactly match the field for the corresponding m= line in the offer. From nobody Tue Jan 10 09:40:37 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 9E4BC129438 for ; Tue, 10 Jan 2017 09:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 AOsfufTFR7T2 for ; Tue, 10 Jan 2017 09:40:34 -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 979CF129516 for ; Tue, 10 Jan 2017 09:40:34 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-11v.sys.comcast.net with SMTP id R0PRcUDb46nWCR0PRcByKT; Tue, 10 Jan 2017 17:40:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484070033; bh=WFrZ/StRDaFExhGx1tQZ43KQkYFTP38rxLcs5jpn1x4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oWV5MB8z3rtwW+OMFZvXJPIqmoW20Szgmm7rNo6aAPLk3r3rM4U/OlV4QZYsV6ADT RavlSJ6PmUlC7edRBV9gn8CqjC8GzuDIUrkR04lqkFM5ykmGUKupTJRRmgQtYFCeci ay04Uh7mAggR4nSVU3ZnYo8h0TspBV/vUCWIITIxDjA+1m2rg+2/Ow3GRMMkl6htUd Xrc9SQLHQFVpDZq+qGzg2M9kiduC0nSdeDQptMCOVoAiQ8hCilOcfspoPpvZp28Vja D+MOfgSR8cj/ogCujrxYgU7UIEsOngz1vUaRdCyCGk3p4Nk7CtP4FdZi52KT8vU+5i VNzfHwQfOHSnA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-11v.sys.comcast.net with SMTP id R0PRcSjKCHSbBR0PRc0mm4; Tue, 10 Jan 2017 17:40:33 +0000 To: mmusic@ietf.org References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> From: Paul Kyzivat Message-ID: <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> Date: Tue, 10 Jan 2017 12:40:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfLYWlEDJCXaFZsPHc0NMdQo6wyUbTlVDQVWdfz7bMXQ5U13lMk7qAjK5IUWvdJcUve5L/RHPsPA/SQ/lvQoRdXWOjTuMNMfhDZlgad7SoU0uKEbBaCef llAgKJzjT6xcSjTeZ95CTM8OwGbfL/pfzMpFX/vEspoIiBMtmUDAe+7Lr1YKMSR0BCcW5xoulF6qww== Archived-At: Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 17:40:35 -0000 On 1/10/17 10:44 AM, Magnus Westerlund wrote: > From a strict clarity issue using ICE/... would be my preferred. But, +1 > that is probably going to throw some implementations, especially > gateways. It will also require us to actually go write the registration > to explain what it is. Having to write a registration to explain what it is would be a good thing! Thanks, Paul From nobody Tue Jan 10 09:49: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 0A15E129D5B; Tue, 10 Jan 2017 09:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVpCm8pIkZAN; Tue, 10 Jan 2017 09:49:21 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 661B9129D5D; Tue, 10 Jan 2017 09:49:11 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0AHibJg011298; Tue, 10 Jan 2017 12:49:08 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 27ttaqhsnr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 12:49:08 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 10 Jan 2017 11:49:07 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [rtcweb] [MMUSIC] JSEP Issue #394: What appears in m= lines. Thread-Index: AQHSa2LFsapXFV8lFEKmmkXm5smJ5qEyYYCA Date: Tue, 10 Jan 2017 17:49:06 +0000 Message-ID: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> In-Reply-To: <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <3C24D80C3F29D841961DF47FF611A815@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701100245 Archived-At: Cc: "rtcweb@ietf.org" , mmusic Subject: Re: [MMUSIC] [rtcweb] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 17:49:22 -0000 DQo+IE9uIEphbiAxMCwgMjAxNywgYXQgMTA6MTMgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiANCj4gRGVuIDIwMTYtMTItMjIg a2wuIDE4OjMwLCBza3JldiBFcmljIFJlc2NvcmxhOg0KPj4gDQo+PiANCj4+IE9uIFRodSwgRGVj IDIyLCAyMDE2IGF0IDc6MTUgQU0sIE1hZ251cyBXZXN0ZXJsdW5kDQo+PiANCj4+ICAgIE9rYXks IEkgYWdyZWUgdGhhdCBoYXZpbmcgYW55IHJ1bGVzIGZvciB3aGF0IHlvdSBzaG91bGQgb2ZmZXIg aGVyZQ0KPj4gICAgYmFzZWQgb24gd2hhdCB0aGUgYWN0dWFsIG91dGNvbWUgaXMgbm90IHRoZSBi ZXN0IGlkZWEgaGVyZS4gSSB0aGluaw0KPj4gICAgdGhlIHJ1bGVzIHNob3VsZCBiZSBiYXNlZCBv biBjYXBhYmlsaXR5IGFuZCBpbnRlbnQuIFNvIGlmIHlvdSBvbmx5DQo+PiAgICBhcmUgZ29pbmcg b2ZmZXIgVENQIGNhbmRpZGF0ZXMsIHRoZW4geW91IGNsZWFybHkgc2hvdWxkIHVzZSBUQ1Av4oCm LA0KPj4gDQo+PiANCj4+IEknbSBnb2luZyB0byBwdXNoIG9uIHRoaXMuIElmIHdlJ3ZlIGFscmVh ZHkgYWdyZWVkIHRoYXQgbWlzbWF0Y2hlcyBhcmUNCj4+IG5vcm1hbCwgd2h5IHNob3VsZCB3ZSBk byB0aGF0PyBXb3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8ganVzdCBlZmZlY3RpdmVseQ0KPj4gZGVw cmVjYXRlIHRoaXMgZmllbGQ/DQo+PiANCj4gDQo+IFNvLCBteSBtYWluIGFyZ3VtZW50IGZvciBp bmNsdWRpbmcgYW55IHJ1bGVzIGZvciBob3cgdG8gc2V0IGl0LCB3b3VsZCBiZSB0aGF0IHRoZSB0 aGlzIHBhcnQgb2YgdGhlIFBST1RPIGZpZWxkIHN0aWxsIGhhcyBtZWFuaW5nIG91dHNpZGUgb2Yg V2ViUlRDIGNvbnRleHQuIFRoZXJlIG9uZSBtYXkgYWN0dWFsbHkgaGF2ZSBpdCB0byBtYXRjaCB3 aGF0IGlzIGdvaW5kIHRvIGJlIHVzZWQuIFRodXMsIGl0IGNhbiBwcm92aWRlIHNvbWUgZ3VpZGFu Y2UgdG8gZ2F0ZXdheXMgb24gd2hhdCB0byBleHBlY3QuIEl0IG1pZ2h0IGJlIHRoYXQgd2Ugc2hv dWxkIGFjdHVhbGx5IHNldCBpdCB0byBVRFAgZm9yIHRob3NlIG5vdCBzdXBwb3J0aW5nIElDRS9U Q1AsIGFuZCB0byBUQ1AgZm9yIHRoZSBvbmVzIHRoYXQgc3VwcG9ydHMgYm90aCBVRFAgYW5kIFRD UC4gVGhhdCB3b3VsZCBzdGlsbCBwcm92aWRlIGluZm9ybWF0aW9uIHRvIHRoZSBnYXRld2F5Lg0K DQpJZiB5b3XigJlyZSB1c2luZyBJQ0UsIGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZXJlIGFyZSBv bmx5IHR3byBjYXNlcyB3aGVyZSB0aGUgdHJhbnNwb3J0IHBhcnRzIG9mIHRoZSBQUk9UTyBmaWVs ZCAoYW5kIHRoZSBtL2MgdHJhbnNwb3J0IHZhbHVlcykgYXJlIHN0aWxsIHJlbGV2YW50Og0KDQox LiBJZiB5b3XigJlyZSB0YWxraW5nIHRvIGFuIGVuZHBvaW50IHRoYXQgZG9lc27igJl0IGRvIElD RSwgaXQgdGVsbHMgdGhlIHBlZXIgd2hhdCB0aGUgZmFsbGJhY2sgcHJvdG9jb2wgc2hvdWxkIGJl LiAgVGhpcyBpc27igJl0IHJlbGV2YW50IGZvciBXZWJSVEMsIGJ1dCBzdGlsbCBpcyBmb3IgZ2Vu ZXJhbCBNTVVTSUMgY2FzZXMuDQoNCjIuIElmIHlvdSBoYXZlIGFuIFNEUC1pbnNwZWN0aW5nIG1p ZGRsZWJveCwgaXQgdGVsbHMgaXQgd2hhdCBtZWRpYSBwcm90b2NvbCB0byBsb29rIGZvciAoZm9y IGxhdGNoaW5nIGFuZCB0aGUgbGlrZSkuICBUaGlzIG1vc3RseSBpc27igJl0IG1lYW5pbmdmdWwg YmVmb3JlIElDRSBoYXMgY29uY2x1ZGVkLCBidXQgaXQgaXMgYWZ0ZXJ3YXJkLg0KDQpNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIFBST1RPIE1VU1QgbWF0Y2ggdGhlIGFjdGl2ZSBjYW5k aWRhdGUsIGlmIHlvdSBoYXZlIG9uZTsgb3RoZXJ3aXNlLCBpdCBNVVNUIG1hdGNoIHRoZSAoZm9y IFdlYlJUQywgZ2VuZXJhbGx5IGFyYml0cmFyaWx5LWNob3NlbikgZGVmYXVsdCBjYW5kaWRhdGUs IGlmIHlvdSBoYXZlIG9uZTsgb3RoZXJ3aXNlICh0aGUgaW5pdGlhbCBzdGF0ZSBvZiB0cmlja2xl KSBpdCBNVVNUIG1hdGNoIG9uZSBvZiB0aGUgcHJvdG9jb2xzIG9mIHRoZSBjYW5kaWRhdGVzIHlv deKAmXJlIGV4cGVjdGluZyB0byBnYXRoZXIgKGlkZWFsbHksIHRoZSBvbmUgdGhhdCB5b3XigJls bCBjaG9vc2UgYXMgdGhlIGRlZmF1bHQpLg0KDQpUaGlzIGJhc2ljYWxseSBtYXRjaGVzIHRoZSBy dWxlcyBmb3IgbS9jIHRyYW5zcG9ydCB2YWx1ZXMgYWxyZWFkeSBpbiBKU0VQLCBJIGJlbGlldmUu DQoNCk5vdywgdGhlIHRyaWNreSB0aGluZyBpcyBvZiBjb3Vyc2Ugd2hldGhlciB0aGlzIHdvcmtz IGZvciBhbnN3ZXJzIOKAlCB3aGV0aGVyIHRoZSBQUk9UTyBmb3IgdGhlIGFuc3dlciBoYXMgdG8g bWF0Y2ggdGhlIG9mZmVyLiAgQSBwcm9ibGVtIG9jY3VycyB3aGVuIHRoZSBhbnN3ZXJlciBpc27i gJl0IGV4cGVjdGluZyB0byBnYXRoZXIgYW55IGNhbmRpZGF0ZXMgdGhhdCB1c2UgdGhlIHByb3Rv Y29sIHVzZWQgYnkgdGhlIG9mZmVyZXLigJlzIGRlZmF1bHQgY2FuZGlkYXRlLg0KDQpNeSBzdWdn ZXN0aW9uIHdvdWxkIGJlIHRoYXQgdGhlIHJ1bGVzIEnigJl2ZSBzcGVjaWZpZWQgYXBwbHkgYW55 d2F5LCBhbmQgdGhhdCB0aGUgYW5zd2VyIFBST1RPIGRvZXNu4oCZdCBoYXZlIHRvIG1hdGNoIHRo ZSBvZmZlciBQUk9UTy4gIFRoaXMgd2lsbCBvbmx5IGNvbmZ1c2UgYW55IGluc3BlY3RpbmcgbWlk ZGxlYm94ZXMgdW50aWwgdGhlIG5leHQgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIG9jY3Vycy4= From nobody Tue Jan 10 10:08: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 944C1129D6B for ; Tue, 10 Jan 2017 10:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 aafj5Dyha5zS for ; Tue, 10 Jan 2017 10:08:10 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 52365129D65 for ; Tue, 10 Jan 2017 10:08:10 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so107023391qtc.2 for ; Tue, 10 Jan 2017 10:08:10 -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=GQXpkeSzjdZhAHHpGb8L0Wpv208N7sQwY1AKLQwa4Vg=; b=gObhM05ZQ/HhxTaYbCpx0AfsSmzzeepXtUUkUrkHgl62t0yRI9AV6szuVhLVgTWEG9 RssZ4NQsqUKu3saOoBgXu9By5muFbRl3gAH6MZU4z/BCjLGB9viwerEtJJF59J2gO3n9 UNjVV0l3cS6jl68cNPgIHj43O712mAZIwudMjYgl9sSdrbKEUicC4nm+qgCPUMoRp/Uy wZzZVFMWeQT/rzOWU9ScfwdS/C3SimzBNV/epL7SsPpoxaBqeyUq9ES1tgJ5B7c6qqyQ aVZKz3ji6vQayORtPXHVcufGt30GG2kRXrQqY8QyR0I7OdwoiOQBncCJH1B6glJgnYfO dtfQ== 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=GQXpkeSzjdZhAHHpGb8L0Wpv208N7sQwY1AKLQwa4Vg=; b=LPFnFGgYH21KSBjuvA2ODGtuOfWgQuQ4MRnVUyZszzsznSs7YtyuGt5BaTSifgcKft 8zl5Xlq9Vvc0vJCcN6UBldrqzAETfhyYXdARSHIF9svM8FhH+/7Qb9hfjQDrQzVoyHjE V1KPezL5lWk/JUvSEZPfFfexzuaJpqPdpf4qleypyv7Zs+sMY2+AdcAmJRp2pye8ibTt oWa+z/4lpmf+/wRaFRlv6+acQhisPl8Lhxwd9J3Q2DGW8vSSMv7VWB80f2CWyKRd/68D W4ttem073vOxbAg7z9RhOgmiapai3h6HMmYEXrOxZBM23I4CYuV6ky2j06EDaKFAafKn RA6Q== X-Gm-Message-State: AIkVDXKM/KL89LKZcZtYSirWxw9nDZP4Ml4ANwOtr/Ske9wNF3K91mEZTfvsXn5E88OifA== X-Received: by 10.237.37.50 with SMTP id v47mr3802298qtc.126.1484071689266; Tue, 10 Jan 2017 10:08:09 -0800 (PST) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com. [209.85.220.178]) by smtp.gmail.com with ESMTPSA id r15sm1987906qte.9.2017.01.10.10.08.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 10:08:09 -0800 (PST) Received: by mail-qk0-f178.google.com with SMTP id 11so84493648qkl.3 for ; Tue, 10 Jan 2017 10:08:08 -0800 (PST) X-Received: by 10.55.197.148 with SMTP id k20mr3963099qkl.34.1484071688427; Tue, 10 Jan 2017 10:08:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Tue, 10 Jan 2017 10:08:07 -0800 (PST) In-Reply-To: <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> From: Roman Shpount Date: Tue, 10 Jan 2017 13:08:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1149e640cf636b0545c15db7 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 18:08:11 -0000 --001a1149e640cf636b0545c15db7 Content-Type: text/plain; charset=UTF-8 We can do the registration for ICE transport tag in ICE-SIP-SDP. ICE tag will indicate that ICE is required for this offer/answer exchange to succeed. When ICE transport tag is used, c= and m= SDP line would carry no address information and will contain "c=IN IP4 0.0.0.0" and port 9 in the m= line. Also, if ICE/ transport tag is used, we should remove the requirement for a re-INVITE after ICE nomination process is complete, since it serves no purpose when no address is specified in c= and m= lines. If we are not going to define ICE/ transport, then I propose the following: 1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to port 9, so that these lines carry no valid address information as it is specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP or UDP/DTLS/SCTP for data 2. When c= line and m= line carry valid address information, protocol should match the candidate specified in c= and m= lines. 3. In cases when c= line and m= line carry valid address information, when initial offer and answer are generated, they must include UDP candidates and UDP candidates must be used as defaults. Once ICE nomination process is complete, only the active candidate pair MUST be included in SDP, and the transport for the active pair must be used. I am not sure about the proper procedure for c= and m= lines during the ICE nomination process, since active candidate can change during the offer/answer exchange which can cause protocol line mismatch. One option is to continue re-sending the initial offer and answer. P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it be "UDP/DTLS/RTP/SAVPF"? Regards, _____________ Roman Shpount --001a1149e640cf636b0545c15db7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We can do the registration for ICE transport tag in ICE-SI= P-SDP. ICE tag will indicate that ICE is required for this offer/answer exc= hange to succeed. When ICE transport tag is used, c=3D and m=3D SDP line wo= uld carry no address information and will contain "c=3DIN IP4 0.0.0.0&= quot; and port 9 in the m=3D line. Also, if ICE/ transport tag is used, we = should remove the requirement for a re-INVITE after ICE nomination process = is complete, since it serves no purpose when no address is specified in c= =3D and m=3D lines.

If we are not going to define ICE/ t= ransport, then I propose the following:

1. When c= =3D line is set to "IN IP4 0.0.0.0" and m=3D line is set to port = 9, so that these lines carry no valid address information as it is specifie= d in JSEP, protocol should be=C2=A0UDP/DTLS/SAVPF for RTP or=C2=A0UDP/DTLS/SCTP= for data

2= . When=C2=A0c=3D line and m=3D line carry valid address information,= protocol should match the candidate specified in c=3D and m=3D lines.=C2= =A0

3. In cases=C2=A0when=C2=A0c=3D line and m=3D line carry valid a= ddress information,=C2=A0when initial offer and answer are generated, they = must include UDP candidates and UDP candidates must be used as defaults. On= ce ICE nomination process is complete, only the active candidate pair MUST = be included in SDP, and the transport for the active pair must be used.

I am not sure about the proper procedure for c=3D and= m=3D lines during the ICE nomination process, since active candidate can c= hange during the offer/answer exchange which can cause protocol line mismat= ch. One option is to continue re-sending the initial offer and answer.

P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it be=C2=A0"UDP/DTLS/RTP/SAVPF"?
=

Regards, =C2=A0
_____________
Roman Shpount
--001a1149e640cf636b0545c15db7-- From nobody Tue Jan 10 11:28: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 0CF661297E8 for ; Tue, 10 Jan 2017 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 8h4D0PvUzyv3 for ; Tue, 10 Jan 2017 11:27:57 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 52F7C1297ED for ; Tue, 10 Jan 2017 11:27:57 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-02v.sys.comcast.net with SMTP id R25Mcg6yg9XRkR25McyEmO; Tue, 10 Jan 2017 19:27:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484076476; bh=Fs7luZtmLSrv3qKK9nWCUwYWSFl2kErDvG9pVjCD79c=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=a8dI8LVTFHHmWTnNLNbUq/wwMcGJyF/DyfpAjvyZganjHcQjEP4t9F6J8lX6MZM1G b9XPZlhHLGHaiBdjGwZzhjAPbT+U+tcqvuThd8UsrQZFTIrdNtra1nbpzsjNnHUpqz QOZd4+7bI01/D4/Zk10aFfuDk9GJuI+D7AK0pSkd46hyP+lXN/yT8mG58sqYlUq0Ax NSQqJC777kxYWvTxltktEp5wGnlOYw9TC7lU/nYgK/Mkyzgl9BfaXe1TQ5mejhDjNq 8I86V1EKl8c0RsjGrGD+64fgnz3ekfQsGsSxVRaLQO4PHASwIcodiKa6lHxmlnFc1T AEFE98qtEXHxQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-03v.sys.comcast.net with SMTP id R25LcKCf2OblgR25MchlyT; Tue, 10 Jan 2017 19:27:56 +0000 To: Roman Shpount References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> From: Paul Kyzivat Message-ID: <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net> Date: Tue, 10 Jan 2017 14:27:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfELgr0ClBTk45LmbVIefwtVGI8gEFLEZG0UkoiytEhDdCG1bv/APYa1PPhks+8t/fXDgHF9q6hvyEM4ygxYJF9WP6T72u1WLslTYwAk28pT2EJW+DGs8 oyOyOD2Xm1nVleKH+c1WISnp5KOKM6pM5cQAg0MqTs+uYhNnHNTcoYiDmfSvYSIXfClLsTsagtWCRIpHwsnjuxMNJ/GrtM4E5Us= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 19:27:59 -0000 On 1/10/17 1:08 PM, Roman Shpount wrote: > We can do the registration for ICE transport tag in ICE-SIP-SDP. ICE tag > will indicate that ICE is required for this offer/answer exchange to > succeed. When ICE transport tag is used, c= and m= SDP line would carry > no address information and will contain "c=IN IP4 0.0.0.0" and port 9 in > the m= line. Also, if ICE/ transport tag is used, we should remove the > requirement for a re-INVITE after ICE nomination process is complete, > since it serves no purpose when no address is specified in c= and m= lines. > > If we are not going to define ICE/ transport, then I propose the following: > > 1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to port 9, > so that these lines carry no valid address information as it is > specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP > or UDP/DTLS/SCTP for data To do this cleanly, IMO there should be no singling out of IP4. The fact is that in this case the c= line is not needed. (And this isn't the only case where it isn't. It also isn't needed for MSRP and for websockets - things that use URLs in attributes instead of c=.) So perhaps we should revise 4566bis to make c= optional for m= lines where it isn't needed. Or define a new addrtype for use in c= (e.g. simply "IP" or "IP4/6") and define a placeholder address value for this case. For example: c=IN IP - > 2. When c= line and m= line carry valid address information, protocol > should match the candidate specified in c= and m= lines. > > 3. In cases when c= line and m= line carry valid address > information, when initial offer and answer are generated, they must > include UDP candidates and UDP candidates must be used as defaults. Once > ICE nomination process is complete, only the active candidate pair MUST > be included in SDP, and the transport for the active pair must be used. I think this could be handled by having different values: ICE/DTLS DTLS over either UDP or TCP ICE/UDP/DTLS DTLS over only UDP ICE/TCP/DTLS DTLS over only TCP ICE/DTLS/RTP/SAVPF Like above, but for RTP/SAVPF ICE/UDP/DTLS/RTP/SAVPF " ICE/TCP/DTLS/RTP/SAVPF " So this allows restricting the type of candidates that are allowed, or not. And it avoids "lying" about the type that is to be used. Thanks, Paul From nobody Tue Jan 10 12:17: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 5562C129443; Tue, 10 Jan 2017 12:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 VkvwU9YiBm78; Tue, 10 Jan 2017 12:17:05 -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 6591F120727; Tue, 10 Jan 2017 12:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47598; q=dns/txt; s=iport; t=1484079425; x=1485289025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XWhq5eaa9K+x4mckfiOdKk/oFpuV31hCuixldInHA9k=; b=TT1HCXDYBGWYvv1Cs0WrXD5NSu2MAl1t8rHsU6nthovoHhar2a9YzTdf Cu2ESx5vypj6YtT98VPN13VuU3x54sK5XegmvQHtJw57Sk6hrRbeda+xH 4WgXVGt4hsyUW3ZtbOp9th/OAG6yCRntq1Gi2LvlTgB06QYdVaRYGTygD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAQA2QHVY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFJAQEBAQEfX4ENB4NIigiSKId/jSiCCAMfAQqFLkoCGoFpPxQ?= =?us-ascii?q?BAgEBAQEBAQFjKIRpAQEBBAEBIUsLEAIBCBEDAQIhAQYDAgICHwYLFAkIAgQBD?= =?us-ascii?q?QUbiDoDGA6wU4IlK4cXDYJIAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIRwiBUYE?= =?us-ascii?q?Ggk6BVEQWglItgjEFlSOFSDgBhlqGeIN/CoFtjmqIEIF7hECEEgEfOIFAFTgQA?= =?us-ascii?q?YYccwGGKIEwgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="370875217" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2017 20:17:04 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0AKH4DH026005 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2017 20:17:04 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 10 Jan 2017 14:17:03 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 10 Jan 2017 14:17:03 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount , Alan Ford , "Tom Kristensen (tomkrist)" , Tom Kristensen <2mkristensen@gmail.com> Thread-Topic: [bfcpbis] [MMUSIC] m= line protocol in case of ICE Thread-Index: AQHSZhtknFAwOo6gtkq09SOaLvmbNKEyD0MA Date: Tue, 10 Jan 2017 20:17:03 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BE3AE83@ESESSMB209.ericsson.se> <16B5D8FF-F132-4B09-84D6-AE964CA7858D@cisco.com> <64E8A5CF-89ED-4673-AF23-2C960395C3EF@cisco.com> <633D3491-83B1-421F-B48C-0A61B1314E99@cisco.com> <739486DE-BDFA-48FD-ACBA-41E45D208748@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/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.156.130.222] Content-Type: multipart/alternative; boundary="_000_E141AB908F354786B443DF7682F3D5FAciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ice@ietf.org" , "bfcpbis@ietf.org" , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] [bfcpbis] m= line protocol in case of ICE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 20:17:08 -0000 --_000_E141AB908F354786B443DF7682F3D5FAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9tYW4sDQoNClRoYW5rcyBmb3Igc2hhcmluZyB0aGlzIHZlcnkgY2xlYXIgcHJvcG9zYWwuIFVu bGVzcyBzb21lb25lIHNlZXMgYW4gaXNzdWUgd2l0aCBpdCwgSSB0aGluayBpdCBzaG91bGQgYmUg aW5jb3Jwb3JhdGVkIGludG8gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuIFN1cHBvcnQg Zm9yIERUTFMgaXMgcmVxdWlyZWQgYnkgZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODJiaXMgZm9y IHRyYW5zcG9ydCBvZiBCRkNQIG92ZXIgVURQLCBzbyByZXF1aXJpbmcgc3VwcG9ydCBmb3IgVURQ L0RUTFMvQkZDUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUgd2hlbiB1c2luZyBJQ0UgYW5kIERU TFMgYW5kIHJlcXVpcmluZyBzdXBwb3J0IGZvciBVRFAvQkZDUCBhcyB0aGUgZGVmYXVsdCBjYW5k aWRhdGUgb3RoZXJ3aXNlIHNob3VsZCBiZSBmaW5lLg0KDQpJIGJlbGlldmUgdGhlIGNoYW5nZXMg cmVxdWlyZWQgdG8gYWRkIHlvdXIgcHJvcG9zYWwgYXJlIGxpbWl0ZWQgdG8gZHJhZnQtaWV0Zi1i ZmNwYmlzLXJmYzQ1ODNiaXMuIFJvbWFuLCBjYW4geW91IHdvcmsgd2l0aCBUb20gS3Jpc3RlbnNl biB0byBtYWtlIHN1cmUgeW91ciBwcm9wb3NhbCBpcyBjYXB0dXJlZCBjb3JyZWN0bHkgaW4gdXBk YXRlIHRvIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzPw0KDQpDaGVlcnMsDQpDaGFybGVz DQoNCkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KRGF0ZTogVHVlc2Rh eSwgSmFudWFyeSAzLCAyMDE3IGF0IDM6NDQgUE0NClRvOiBBbGFuIEZvcmQgPGFsYW4uZm9yZEBn bWFpbC5jb20+DQpDYzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5jb20+LCAiYmZjcGJp c0BpZXRmLm9yZyIgPGJmY3BiaXNAaWV0Zi5vcmc+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiwgIm1tdXNpY0BpZXRmLm9yZyIgPG1tdXNpY0BpZXRm Lm9yZz4sICJpY2VAaWV0Zi5vcmciIDxpY2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2JmY3Bi aXNdIFtNTVVTSUNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KQWxhbiwNCg0K VENQL0JGQ1AgYW5kIFRMUy9CRkNQIHdpbGwgbm90IHdvcmsgd2l0aCBJQ0UuIE9yLCB0byBiZSBt b3JlIHByZWNpc2UsIHdpbGwgbm90IHdvcmsgd2l0aG91dCBzb21lIHNwZWNpZmljYXRpb24gY2hh bmdlcyBlaXRoZXIgaW4gSUNFIHRjcCBvciBpbiBCRkNQLg0KDQpPbmUgcGFpciBvZiBwcm90b2Nv bHMgd2hpY2ggd2lsbCB3b3JrIHdpdGggSUNFIGlzIFVEUC9EVExTL0JGQ1AgYW5kIFRDUC9EVExT L0JGQ1AuIEl0IHdpbGwgc3VwcG9ydCBib3RoIHRjcCBhbmQgdWRwIGNhbmRpZGF0ZXMuIEkgdGhp bmsgdGhpcyBwYWlyIHNob3VsZCBiZSByZWNvbW1lbmRlZCBzaW5jZSBpdCBwcm92aWRlcyBlbmNy eXB0aW9uLg0KDQpBbm90aGVyIHBhaXIgdGhhdCB3aWxsIHdvcmsgd2l0aCBJQ0UgaXMgVURQL0JG Q1AgYW5kIFRDUC9VRFAvQkZDUC4gSXQgd2lsbCBhbHNvIHN1cHBvcnQgdGNwIGFuZCB1ZHAgY2Fu ZGlkYXRlcy4gSXQgaXMgbm90IHNvbWV0aGluZyBJIHdvdWxkIHVzZSBvdmVyIHB1YmxpYyBpbnRl cm5ldCBzaW5jZSBpdCB3aWxsIHRyYW5zbWl0IGRhdGEgaW4gdGhlIGNsZWFyIHRleHQuDQoNCkZp bmFsbHksIEkgcHJlZmVyIHRoYXQgYW55IGVuZCBwb2ludCB3aGljaCBpbXBsZW1lbnQgQkZDUCBh bmQgc3VwcG9ydHMgSUNFIGFuZCBEVExTLCBNVVNUIHN1cHBvcnQgVURQL0RUTFMvQkZDUCBhbmQg dXNlIGl0IGZvciBkZWZhdWx0IGNhbmRpZGF0ZS4gQW55IGVuZHBvaW50IHdoaWNoIGltcGxlbWVu dHMgQkZDUCBhbmQgSUNFLCBidXQgZG9lcyBub3Qgc3VwcG9ydCBEVExTLCBNVVNUIHN1cHBvcnQg VURQL0JGQ1AgYW5kIHVzZSBpdCBhcyBhIGRlZmF1bHQgY2FuZGlkYXRlLg0KDQpPbmNlIHRoZSBJ Q0UgY2FuZGlkYXRlIHBhaXIgaXMgc2VsZWN0ZWQsIHRoZSB0cmFuc3BvcnQgbWF0Y2hpbmcgdGhl IHNlbGVjdGVkIGNhbmRpZGF0ZSBwYWlyIHNob3VsZCBiZSB1c2VkIGluIHRoZSBTRFAuDQoNClRo ZXJlIGlzIG5vIHByYWN0aWNhbCBuZWVkIGZvciB0aGUgYXN5bW1ldHJpYyB0cmFuc3BvcnQgdGFn cy4gSSB0aGluayB0aGUgd2hvbGUgdGhpbmcgaXMgY29taW5nIGZyb20gIHRoZSBjb25mdXNpb24g dGhhdCBUQ1AvQkZDUCBjYW4gYmUgdXNlZCB3aXRoIElDRSB0Y3AgY2FuZGlkYXRlcy4gSXQgY2Fu bm90IHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0aW9uIGNoYW5nZXMuIEFsc28sIHRoZXJlIGlzIG5v IHJlYXNvbiB0byB1c2UgVENQL0RUTFMvQkZDUCBvciBUQ1AvVURQL0JGQ1AsIHVubGVzcyBJQ0Ug aXMgdXNlZC4gQmVjYXVzZSBvZiB0aGlzLCB0aGVyZSBpcyBubyByZWFzb24gdG8gdXNlIGVpdGhl ciBvZiB0aG9zZSB0cmFuc3BvcnRzIGZvciBkZWZhdWx0IGNhbmRpZGF0ZSwgc2luY2UgZGVmYXVs dCBjYW5kaWRhdGUgaXMgc2VsZWN0ZWQgZm9yIGludGVyb3Agd2l0aCBlbmQgcG9pbnRzIG5vdCBz dXBwb3J0aW5nIElDRS4NCg0KUmVnYXJkcywNCg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3Vu dA0KDQpPbiBUdWUsIEphbiAzLCAyMDE3IGF0IDY6MjMgUE0sIEFsYW4gRm9yZCA8YWxhbi5mb3Jk QGdtYWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+IHdyb3RlOg0KUm9tYW4sDQoN CkRvIGFueSBvZiB0aG9zZSB3b3JrIGZvciBoYXZpbmcgYm90aCB0Y3AgYW5kIHVkcCBJQ0UgY2Fu ZGlkYXRlcz8gSSBhc3N1bWUgYW55IHdpdGggSUNFICgrIDQ1NzEgZnJhbWluZykgd291bGQgYmUg YWNjZXB0YWJsZSBmb3IgdGhhdCBjYXNlPw0KDQpJZGVhbGx5IHdlIG5lZWQgdG8gc3VwcG9ydCB0 aGUgY2FzZSB3aGVyZSBhbiBhbnN3ZXLigJlzIG0tbGluZSBwcm90b2NvbCBkb2VzIG5vdCBtYXRj aCBhbnkgb2YgdGhlIGNhbmRpZGF0ZXMsIHNvIHRoYXQgYW4gYW5zd2VyIGNvdWxkIG9ubHkgc3Vw cG9ydCBUQ1AgKHNheSkgd2hlbiB0aGUgb2ZmZXJlciBzdXBwb3J0ZWQgYm90aCAoYW5kIHVzZWQg YSBVRFAgbS1saW5lIHByb3RvY29sKS4gSWYgQ2hyaXN0ZXLigJlzIHByb3Bvc2VkIGNoYW5nZSB3 aGljaCBwZXJtaXR0ZWQgYW4gYW5zd2VyIG5vdCB0byBtYXRjaCB0aGUgbS1saW5lIHByb3RvY29s IGluIHRoZSBJQ0UgY2FuZGlkYXRlcyB3YXMgYWNjZXB0ZWQsIHRoYXQgd291bGQgcmVzb2x2ZSB0 aGlzIGNhc2UuIERvIHlvdSBzZWUgYW55IHByb2JsZW1zIGhlcmU/DQoNClJlZ2FyZHMsDQpBbGFu DQoNCk9uIDMgSmFuIDIwMTcsIGF0IDIwOjA4LCBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+PiB3cm90ZToNCg0KQ2hhcmxlcywNCg0KSSBk byBub3QgdGhpbmsgbm90IHN1cHBvcnRpbmcgSUNFIHRjcCBjYW5kaWRhdGVzIHdpbGwgcXVpdGUg d29yayBzaW5jZSBpdCB3aWxsIHJlZHVjZSB0aGUgdXNhYmlsaXR5IGNvbnNpZGVyYWJseS4gVGhl IHNpbXBsZXN0IHdheSB0byBtb3ZlIGZvcndhcmQgaXMgdG8gZGVmaW5lIGEgZGlmZmVyZW50IHRy YW5zcG9ydCB0YWcgZm9yIEJGQ1AgIHdpdGggUkZDIDQ1NzEgb3ZlciBUQ1Agbm90IHRvIGNvbmZ1 c2UgaXQgd2l0aCBUQ1AvQkZDUC4gSXQgY2FuIGJlIFRDUC9VRFAvQkZDUCAoSSBrbm93IHRoaXMg bG9va3Mgc3RyYW5nZSBhbmQgSSBhbSBvcGVuIHRvIG90aGVyIHN1Z2dlc3Rpb25zLCBzdWNoIGFz IGNhbGxpbmcgYWxsIHBhY2tldCBiYXNlZCBwcm90b2NvbHMgREJGQ1ApLg0KDQpJbiBnZW5lcmFs IHdoYXQgSSBhbSBwcm9wb3NpbmcgaXM6DQoNClRDUC9CRkNQIC0tIGV4aXN0aW5nIEJGQ1Agb3Zl ciBUQ1ANClRMUy9CRkNQIC0tIGV4aXNpdG5nIEJGQ1Agb3ZlciBUTFMNClVEUC9CRkNQIC0tIEJG Q1Agb3ZlciBVRFAgb3IgSUNFIHVkcCBjYW5kaWRhdGVzDQpUQ1AvVURQL0JGQ1AgLS0gQkZDUCB3 aXRoIFJGQyA0NTcxIGZyYW1pbmcgb3ZlciBUQ1Agb3Igb3ZlciBJQ0UgdGNwIGNhbmRpZGF0ZXMN ClVEUC9EVExTL0JGQ1AgLS0gQkZDUCBvdmVyIERUTFMgb3Igb3ZlciBJQ0UgdWRwIGNhbmRpZGF0 ZXMNClRDUC9EVExTL0JGQ1AgLS0gQkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5n IG92ZXIgVENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzDQoNCkxlZ2FjeSBCRkNQIG92ZXIg VENQIG9yIFRMUyBjYW5ub3Qgd29yayB3aXRoIElDRSBvciBOQVQuIE90aGVyIHByb3RvY29scyBj YW4gd29yayB3aXRoIE5BVCBvciBJQ0UgdXNpbmcgbm9ybWFsIElDRSBwcm9jZWR1cmVzLg0KDQpJ ZiB3ZSBjYWxsIGFsbCBwYWNrZXQgYmFzZWQgcHJvdG9jb2xzIERCRkNQIHRoZW4gdHJhbnNwb3J0 IHRhZ3Mgd2lsbCBiZToNCg0KVENQL0JGQ1AgLS0gZXhpc3RpbmcgQkZDUCBvdmVyIFRDUA0KVExT L0JGQ1AgLS0gZXhpc2l0bmcgQkZDUCBvdmVyIFRMUw0KVURQL0RCRkNQIC0tIERCRkNQIG92ZXIg VURQIG9yIElDRSB1ZHAgY2FuZGlkYXRlcw0KVENQL0RCRkNQIC0tIERCRkNQIHdpdGggUkZDIDQ1 NzEgZnJhbWluZyBvdmVyIFRDUCBvciBvdmVyIElDRSB0Y3AgY2FuZGlkYXRlcw0KVURQL0RUTFMv REJGQ1AgLS0gREJGQ1Agb3ZlciBEVExTIG9yIG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzDQpUQ1Av RFRMUy9EQkZDUCAtLSBEQkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5nIG92ZXIg VENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzDQoNClNpbmNlIEJGQ1Agb3ZlciBVRFAgKG9y IG90aGVyIHBhY2tldCBiYXNlZCBwcm90b2NvbHMpIGlzIHF1aXRlIGRpZmZlcmVudCBkdWUgdG8g dGltZXJzIGFuZCB0cmFuc21pc3Npb24gcmVzdHJpY3Rpb25zLCBpdCBjYW4gaGF2ZSBhIGRpZmZl cmVudCB0cmFuc3BvcnQgdGFnIGFuZCBldmVuIGJlIGRlZmluZWQgaW4gYSBzZXBhcmF0ZSBSRkMu DQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gVHVlLCBK YW4gMywgMjAxNyBhdCAyOjQzIFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSA8ZWNrZWxjdUBj aXNjby5jb208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4gd3JvdGU6DQpDcmlja2V0c+KApg0K SWYgbm8gb25lIGlzIG9yIGhhcyBwbGFucyBmb3IgdXNpbmcgSUNFIHdpdGggVENQL0JGQ1AsIHBl cmhhcHMgaXQgaXMgYmVzdCB0byBzdGF0ZSB0aGF0IGFzIG9mIHRoaXMgcmV2IG9mIHRoZSBCRkNQ IHNwZWMsIEJGQ1Agd2l0aCBUQ1AgY2FuZGlkYXRlcyBpcyBub3QgZGVmaW5lZC4gRnV0dXJlIHVw ZGF0ZXMgdG8gdGhlIHNwZWMgbWF5IGRlZmluZSB0aGlzIHVzYWdlLg0KDQpDaGVlcnMsDQpDaGFy bGVzDQoNCkZyb206IG1tdXNpYyA8bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIENoYXJsZXMgRWNrZWwgPGVja2VsY3VA Y2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+DQpEYXRlOiBGcmlkYXksIERlY2Vt YmVyIDIsIDIwMTYgYXQgNDowMSBQTQ0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+DQpDYzogImljZUBpZXRmLm9yZzxtYWlsdG86 aWNlQGlldGYub3JnPiIgPGljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3JnPj4sICJiZmNw YmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlzQGlldGYub3JnPiIgPGJmY3BiaXNAaWV0Zi5vcmc8 bWFpbHRvOmJmY3BiaXNAaWV0Zi5vcmc+PiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pj4sICJtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0 Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW2Jm Y3BiaXNdIG09IGxpbmUgcHJvdG9jb2wgaW4gY2FzZSBvZiBJQ0UNCg0KSSBoYXZlIG5vIGV4cGVy aWVuY2Ugd2l0aCBJQ0Ugd2l0aCBUQ1AgY2FuZGlkYXRlcyBzbyBob3BlZnVsbHkgb3RoZXJzIGNh biBjaGltZSBpbiBhcyB0byB3aGF0IHRoZXkgdGhpbmsgaXMgYSB3b3JrYWJsZSBzb2x1dGlvbi4N Cg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIERlY2VtYmVy IDEsIDIwMTYgYXQgMTI6MzQgUE0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNv bTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+Pg0KQ2M6IEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdt YWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+LCAiYmZjcGJpc0BpZXRmLm9yZzxt YWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iIDxiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlz QGlldGYub3JnPj4sICJpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0 Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Piwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10g W01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRQ0KDQpDaGFybGVzLA0KDQpS RkMgNjU0NCBTZW5kaW5nIE1lZGlhIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0 NCNzZWN0aW9uLTEwLjEpIHNheXMgdGhhdCAiVGhlIGZyYW1pbmcgZGVmaW5lZCBpbiBSRkMgNDU3 MTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MT4gTVVTVCBiZSB1c2VkIHdoZW4g c2VuZGluZyBtZWRpYS4iIFRoaXMgbWVhbnMgdGhlIHByb3RvY29sIHVzZWQgaXMgbm90IFRDUC9C RkNQIHdoaWNoIGlzIHVzaW5nIGFwcGxpY2F0aW9uIGxldmVsIGZyYW1pbmcuIEkgYmVsaWV2ZSB0 aGF0IFNUVU4vTWVkaWEgZGVtdWx0aXBsZXhpbmcgcmVxdWlyZW1lbnRzIHdvdWxkIHByZXZlbnQg dXNpbmcgVENQL0JGQ1AgZGlyZWN0bHkgd2l0aCBpY2UgdGNwIGNhbmRpZGF0ZXMgd2l0aG91dCBy ZWRlc2lnbiBvZiBlaXRoZXIgSUNFIFRDUCBvciBUQ1AvQkZDUC4NCg0KRnVydGhlcm1vcmUgdGhl cmUgYXJlIG90aGVyIGltcGxpZWQgSUNFIHJlcXVpcmVtZW50cyB0aGF0IEkgb3V0bGluZWQgYmVm b3JlIChzd2l0Y2hpbmcgYmV0d2VlbiB1ZHAgYW5kIHRwYyBjYW5kaWRhdGVzLCBleGlzdGVuY2Ug b2YgU0JDIHdoaWNoIHRlcm1pbmF0ZSBJQ0Ugb25seSBidXQgZG8gbm90IHN1cHBvcnQgdGhlIGVt YmVkZGVkIHByb3RvY29sKSBiZWNhdXNlIG9mIHdoaWNoIGljZSB0Y3AgaXMgY29uc2lkZXJlZCB1 bnJlbGlhYmxlIHRyYW5zcG9ydCBhbmQgd2lsbCByZXF1aXJlIGZyYWdtZW50YXRpb24gc3VwcG9y dCBhbmQgcmUtdHJhbnNtaXQgdGltZXJzIHRoYXQgYXJlIG5vdCBwYXJ0IG9mIFRDUC9CRkNQLg0K DQpSZWdhcmRzLA0KDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFRodSwgRGVj IDEsIDIwMTYgYXQgMzoxNyBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2VsY3VAY2lz Y28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KUm9tYW4sDQoNCldoeSB3 b3VsZCBzZWxlY3RpbmcgVENQL0JGQ1AgYXMgdHJhbnNwb3J0IHZpb2xhdGUgUkZDIDY1NDQ/IFBl cmhhcHMgaXQgZG9lcywgYnV0IGFmdGVyIGEgcXVpY2sgc2NhbiBJIGFtIG5vdCBzdXJlIHdoeS4N Cg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4 LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIg MjksIDIwMTYgYXQgMTA6MzggQU0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNv bTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+Pg0KQ2M6IEFsYW4gRm9yZCA8YWxhbi5mb3JkQGdt YWlsLmNvbTxtYWlsdG86YWxhbi5mb3JkQGdtYWlsLmNvbT4+LCAiYmZjcGJpc0BpZXRmLm9yZzxt YWlsdG86YmZjcGJpc0BpZXRmLm9yZz4iIDxiZmNwYmlzQGlldGYub3JnPG1haWx0bzpiZmNwYmlz QGlldGYub3JnPj4sICJpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0 Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Piwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbYmZjcGJpc10g W01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElDRQ0KDQpPbiBUdWUsIE5vdiAy OSwgMjAxNiBhdCAxMjo0OCBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2VsY3VAY2lz Y28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KSXQgc2VlbXMgdG8gbWUg dGhhdCB0aGUgbW9zdCBzdHJhaWdodGZvcndhcmQgYXBwcm9hY2ggd291bGQgYmUgdG8gbWFuZGF0 ZSBzdXBwb3J0IGZvciBCRkNQIG92ZXIgVURQIHdoZW4gdXNpbmcgSUNFLCB1c2UgVURQIGFzIHRo ZSBkZWZhdWx0IGNhbmRpZGF0ZSwgYW5kIHNpZ25hbCB0aGUgQkZDUCBtLWxpbmUgYXMgaWYgaXQg aXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVzZSBvZiBEVExTLCB0aGF0 IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLg0KVGhvdWdodHM/DQoNCg0KSSBhZ3JlZS4NCg0KVGhlIG9u bHkgaXNzdWUgdGhhdCBJIHN0aWxsIGhhdmUsIGlmIERUTFMgaXMgbm90IHVzZWQsIHdoYXQgcHJv dG9jb2wgaXMgdXNlZCB3aGVuIElDRSB0Y3AgY2FuZGlkYXRlIGlzIHNlbGVjdGVkIGZvciB0cmFu c3BvcnQuIElzIHRoaXMgVENQL0JGQ1AgKHdoaWNoIGdvZXMgYWdhaW5zdCBSRkM2NTQ0KSAgb3Ig aXMgaXQgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmc/IElmIGl0IGlzIFVEUC9CRkNQIHdp dGggUkZDNDU3MSBmcmFtaW5nLCB3aGF0IHRyYW5zcG9ydCB0YWcgc2hvdWxkIGJlIHVzZWQgaW4g dGhlIHJlLUlOVklURSB3aGljaCBpcyBzZW50IGFmdGVyIElDRSBub21pbmF0aW9uIHdpdGggb25s eSBzZWxlY3RlZCBjYW5kaWRhdGU/IFNob3VsZCBpdCBiZSBUQ1AvVURQL0JGQ1Agb3Igc29tZXRo aW5nIHNpbWlsYXI/DQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYmZj cGJpcyBtYWlsaW5nIGxpc3QNCmJmY3BiaXNAaWV0Zi5vcmc8bWFpbHRvOmJmY3BiaXNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCg0KDQo= --_000_E141AB908F354786B443DF7682F3D5FAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5027D39C22CEB444A67E2D8E12300CDD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGZvciBzaGFyaW5nIHRoaXMgdmVyeSBjbGVhciBwcm9wb3NhbC4gVW5sZXNzIHNvbWVv bmUgc2VlcyBhbiBpc3N1ZSB3aXRoIGl0LCBJIHRoaW5rIGl0IHNob3VsZCBiZSBpbmNvcnBvcmF0 ZWQgaW50byBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcy4gU3VwcG9ydCBmb3IgRFRMUyBp cyByZXF1aXJlZCBieSBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4MmJpcyBmb3IgdHJhbnNwb3J0 IG9mIEJGQ1ANCiBvdmVyIFVEUCwgc28gcmVxdWlyaW5nIHN1cHBvcnQgZm9yIFVEUC9EVExTL0JG Q1AgYXMgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIHdoZW4gdXNpbmcgSUNFIGFuZCBEVExTIGFuZCBy ZXF1aXJpbmcgc3VwcG9ydCBmb3IgVURQL0JGQ1AgYXMgdGhlIGRlZmF1bHQgY2FuZGlkYXRlIG90 aGVyd2lzZSBzaG91bGQgYmUgZmluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZl IHRoZSBjaGFuZ2VzIHJlcXVpcmVkIHRvIGFkZCB5b3VyIHByb3Bvc2FsIGFyZSBsaW1pdGVkIHRv IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLiBSb21hbiwgY2FuIHlvdSB3b3JrIHdpdGgg VG9tIEtyaXN0ZW5zZW4gdG8gbWFrZSBzdXJlIHlvdXIgcHJvcG9zYWwgaXMgY2FwdHVyZWQgY29y cmVjdGx5IGluIHVwZGF0ZSB0byBkcmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcz88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1s ZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmk7Y29sb3I6YmxhY2siPlJvbWFuIFNocG91bnQgJmx0O3JvbWFuQHRlbHVyaXguY29t Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDMsIDIwMTcgYXQgMzo0NCBQ TTxicj4NCjxiPlRvOiA8L2I+QWxhbiBGb3JkICZsdDthbGFuLmZvcmRAZ21haWwuY29tJmd0Ozxi cj4NCjxiPkNjOiA8L2I+Q2hhcmxlcyBFY2tlbCAmbHQ7ZWNrZWxjdUBjaXNjby5jb20mZ3Q7LCAm cXVvdDtiZmNwYmlzQGlldGYub3JnJnF1b3Q7ICZsdDtiZmNwYmlzQGlldGYub3JnJmd0OywgQ2hy aXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDssICZx dW90O21tdXNpY0BpZXRmLm9yZyZxdW90OyAmbHQ7bW11c2ljQGlldGYub3JnJmd0OywgJnF1b3Q7 aWNlQGlldGYub3JnJnF1b3Q7ICZsdDtpY2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDog PC9iPlJlOiBbYmZjcGJpc10gW01NVVNJQ10gbT0gbGluZSBwcm90b2NvbCBpbiBjYXNlIG9mIElD RTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWxhbiwgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj5UQ1AvQkZDUCBhbmQm bmJzcDtUTFMvQkZDUCB3aWxsIG5vdCB3b3JrIHdpdGggSUNFLiBPciwgdG8gYmUgbW9yZSBwcmVj aXNlLCB3aWxsIG5vdCB3b3JrIHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0aW9uIGNoYW5nZXMgZWl0 aGVyIGluIElDRSB0Y3Agb3IgaW4gQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41 cHQ7Y29sb3I6YmxhY2siPk9uZSBwYWlyIG9mIHByb3RvY29scyB3aGljaCB3aWxsIHdvcmsgd2l0 aCBJQ0UgaXMgVURQL0RUTFMvQkZDUCBhbmQmbmJzcDtUQ1AvRFRMUy9CRkNQLiBJdCB3aWxsIHN1 cHBvcnQgYm90aCB0Y3AgYW5kIHVkcCBjYW5kaWRhdGVzLiBJIHRoaW5rIHRoaXMgcGFpciBzaG91 bGQgYmUgcmVjb21tZW5kZWQgc2luY2UgaXQgcHJvdmlkZXMgZW5jcnlwdGlvbi4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPkFub3RoZXIgcGFpciB0 aGF0IHdpbGwgd29yayB3aXRoIElDRSBpcyZuYnNwO1VEUC9CRkNQIGFuZCZuYnNwO1RDUC9VRFAv QkZDUC4gSXQgd2lsbCBhbHNvIHN1cHBvcnQgdGNwIGFuZCB1ZHAgY2FuZGlkYXRlcy4gSXQgaXMg bm90IHNvbWV0aGluZyBJIHdvdWxkIHVzZSBvdmVyIHB1YmxpYyBpbnRlcm5ldCBzaW5jZSBpdCB3 aWxsIHRyYW5zbWl0IGRhdGEgaW4NCiB0aGUgY2xlYXIgdGV4dC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS41cHQ7Y29sb3I6YmxhY2siPkZpbmFsbHksIEkgcHJlZmVyIHRoYXQgYW55IGVu ZCBwb2ludCB3aGljaCBpbXBsZW1lbnQgQkZDUCBhbmQgc3VwcG9ydHMgSUNFIGFuZCBEVExTLCBN VVNUIHN1cHBvcnQmbmJzcDtVRFAvRFRMUy9CRkNQIGFuZCB1c2UgaXQmbmJzcDtmb3IgZGVmYXVs dCBjYW5kaWRhdGUuIEFueSBlbmRwb2ludCB3aGljaCBpbXBsZW1lbnRzJm5ic3A7QkZDUCBhbmQg SUNFLCBidXQNCiBkb2VzIG5vdCBzdXBwb3J0IERUTFMsIE1VU1Qgc3VwcG9ydCBVRFAvQkZDUCBh bmQgdXNlIGl0IGFzIGEgZGVmYXVsdCBjYW5kaWRhdGUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2NvbG9yOmJsYWNrIj5PbmNlIHRoZSBJQ0UgY2FuZGlkYXRlIHBhaXIg aXMgc2VsZWN0ZWQsIHRoZSB0cmFuc3BvcnQgbWF0Y2hpbmcgdGhlIHNlbGVjdGVkIGNhbmRpZGF0 ZSBwYWlyIHNob3VsZCBiZSB1c2VkIGluIHRoZSBTRFAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuNXB0O2NvbG9yOmJsYWNrIj5UaGVyZSBpcyBubyBwcmFjdGljYWwgbmVlZCBmb3IgdGhl IGFzeW1tZXRyaWMgdHJhbnNwb3J0IHRhZ3MuIEkgdGhpbmsgdGhlIHdob2xlIHRoaW5nIGlzIGNv bWluZyBmcm9tICZuYnNwO3RoZSBjb25mdXNpb24gdGhhdCBUQ1AvQkZDUCBjYW4gYmUgdXNlZCB3 aXRoIElDRSB0Y3AgY2FuZGlkYXRlcy4gSXQgY2Fubm90IHdpdGhvdXQgc29tZSBzcGVjaWZpY2F0 aW9uDQogY2hhbmdlcy4gQWxzbywgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHVzZSZuYnNwO1RDUC9E VExTL0JGQ1Agb3ImbmJzcDtUQ1AvVURQL0JGQ1AsIHVubGVzcyBJQ0UgaXMgdXNlZC4gQmVjYXVz ZSBvZiB0aGlzLCB0aGVyZSBpcyBubyByZWFzb24gdG8gdXNlIGVpdGhlciBvZiB0aG9zZSB0cmFu c3BvcnRzIGZvciBkZWZhdWx0IGNhbmRpZGF0ZSwgc2luY2UgZGVmYXVsdCBjYW5kaWRhdGUgaXMg c2VsZWN0ZWQgZm9yIGludGVyb3Agd2l0aCBlbmQgcG9pbnRzIG5vdCBzdXBwb3J0aW5nDQogSUNF Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFjayI+UmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFu IDMsIDIwMTcgYXQgNjoyMyBQTSwgQWxhbiBGb3JkICZsdDs8YSBocmVmPSJtYWlsdG86YWxhbi5m b3JkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFsYW4uZm9yZEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Um9tYW4sIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RG8gYW55IG9mIHRob3NlIHdvcmsgZm9yIGhhdmluZyBib3RoIHRjcCBhbmQgdWRwIElD RSBjYW5kaWRhdGVzPyBJIGFzc3VtZSBhbnkgd2l0aCBJQ0UgKCYjNDM7IDQ1NzEgZnJhbWluZykg d291bGQgYmUgYWNjZXB0YWJsZSBmb3IgdGhhdCBjYXNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZGVhbGx5IHdlIG5lZWQgdG8gc3VwcG9y dCB0aGUgY2FzZSB3aGVyZSBhbiBhbnN3ZXLigJlzIG0tbGluZSBwcm90b2NvbCBkb2VzIG5vdCBt YXRjaCBhbnkgb2YgdGhlIGNhbmRpZGF0ZXMsIHNvIHRoYXQgYW4gYW5zd2VyIGNvdWxkIG9ubHkg c3VwcG9ydCBUQ1AgKHNheSkgd2hlbiB0aGUgb2ZmZXJlciBzdXBwb3J0ZWQgYm90aCAoYW5kIHVz ZWQgYSBVRFAgbS1saW5lIHByb3RvY29sKS4gSWYgQ2hyaXN0ZXLigJlzIHByb3Bvc2VkDQogY2hh bmdlIHdoaWNoIHBlcm1pdHRlZCBhbiBhbnN3ZXIgbm90IHRvIG1hdGNoIHRoZSBtLWxpbmUgcHJv dG9jb2wgaW4gdGhlIElDRSBjYW5kaWRhdGVzIHdhcyBhY2NlcHRlZCwgdGhhdCB3b3VsZCByZXNv bHZlIHRoaXMgY2FzZS4gRG8geW91IHNlZSBhbnkgcHJvYmxlbXMgaGVyZT88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsYW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gMyBKYW4gMjAxNywgYXQgMjA6MDgsIFJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9 Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXgu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzLCA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5rIG5vdCBz dXBwb3J0aW5nIElDRSB0Y3AgY2FuZGlkYXRlcyB3aWxsIHF1aXRlIHdvcmsgc2luY2UgaXQgd2ls bCByZWR1Y2UgdGhlIHVzYWJpbGl0eSBjb25zaWRlcmFibHkuIFRoZSBzaW1wbGVzdCB3YXkgdG8g bW92ZSBmb3J3YXJkIGlzIHRvIGRlZmluZSBhIGRpZmZlcmVudCB0cmFuc3BvcnQgdGFnIGZvciBC RkNQICZuYnNwO3dpdGggUkZDIDQ1NzEgb3ZlciBUQ1Agbm90IHRvIGNvbmZ1c2UgaXQNCiB3aXRo IFRDUC9CRkNQLiBJdCBjYW4gYmUgVENQL1VEUC9CRkNQIChJIGtub3cgdGhpcyBsb29rcyBzdHJh bmdlIGFuZCBJIGFtIG9wZW4gdG8gb3RoZXIgc3VnZ2VzdGlvbnMsIHN1Y2ggYXMgY2FsbGluZyBh bGwgcGFja2V0IGJhc2VkIHByb3RvY29scyBEQkZDUCkuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGdlbmVyYWwgd2hhdCBJIGFt IHByb3Bvc2luZyBpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VENQL0JGQ1AgLS0gZXhpc3RpbmcgQkZDUCBvdmVyIFRDUDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VExTL0JGQ1AgLS0gZXhp c2l0bmcgQkZDUCBvdmVyIFRMUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VURQL0JGQ1AgLS0gQkZDUCBvdmVyIFVEUCBvciBJQ0UgdWRwIGNhbmRp ZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRDUC9VRFAvQkZDUCAtLSBCRkNQIHdpdGggUkZDIDQ1NzEgZnJhbWluZyZuYnNwO292ZXIgVENQ IG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VRFAvRFRMUy9CRkNQIC0tIEJGQ1Agb3ZlciBEVExTIG9y IG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AvRFRMUy9CRkNQIC0tIEJGQ1Agb3ZlciBEVExTIHdpdGgg UkZDIDQ1NzEgZnJhbWluZyZuYnNwO292ZXIgVENQIG9yIG92ZXIgSUNFIHRjcCBjYW5kaWRhdGVz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxl Z2FjeSBCRkNQIG92ZXIgVENQIG9yIFRMUyBjYW5ub3Qgd29yayB3aXRoIElDRSBvciBOQVQuIE90 aGVyIHByb3RvY29scyBjYW4gd29yayB3aXRoIE5BVCBvciBJQ0UgdXNpbmcgbm9ybWFsIElDRSBw cm9jZWR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JZiB3ZSBjYWxsIGFsbCBwYWNrZXQgYmFzZWQgcHJvdG9jb2xzIERCRkNQIHRoZW4g dHJhbnNwb3J0IHRhZ3Mgd2lsbCBiZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRDUC9CRkNQIC0tIGV4aXN0aW5nIEJGQ1Agb3Zl ciBUQ1A8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRMUy9CRkNQIC0tIGV4aXNpdG5nIEJGQ1Agb3ZlciBUTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVEUC9EQkZDUCAtLSBEQkZDUCBvdmVyIFVE UCBvciBJQ0UgdWRwIGNhbmRpZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRDUC9EQkZDUCAtLSBEQkZDUCB3aXRoIFJGQyA0NTcxIGZyYW1p bmcmbmJzcDtvdmVyIFRDUCBvciBvdmVyIElDRSB0Y3AgY2FuZGlkYXRlczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VURQL0RUTFMvREJGQ1AgLS0g REJGQ1Agb3ZlciBEVExTIG9yIG92ZXIgSUNFIHVkcCBjYW5kaWRhdGVzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UQ1AvRFRMUy9EQkZDUCAtLSBE QkZDUCBvdmVyIERUTFMgd2l0aCBSRkMgNDU3MSBmcmFtaW5nJm5ic3A7b3ZlciBUQ1Agb3Igb3Zl ciBJQ0UgdGNwIGNhbmRpZGF0ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5jZSBCRkNQIG92ZXIgVURQIChvciBvdGhlciBw YWNrZXQgYmFzZWQgcHJvdG9jb2xzKSBpcyBxdWl0ZSBkaWZmZXJlbnQgZHVlIHRvIHRpbWVycyBh bmQgdHJhbnNtaXNzaW9uIHJlc3RyaWN0aW9ucywgaXQgY2FuIGhhdmUgYSBkaWZmZXJlbnQgdHJh bnNwb3J0IHRhZyBhbmQgZXZlbiBiZSBkZWZpbmVkIGluIGEgc2VwYXJhdGUgUkZDLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAzLCAyMDE3 IGF0IDI6NDMgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Dcmlja2V0c+KApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JZiBubyBvbmUgaXMgb3IgaGFzIHBsYW5zIGZvciB1c2luZyBJQ0Ugd2l0 aCBUQ1AvQkZDUCwgcGVyaGFwcyBpdCBpcyBiZXN0IHRvIHN0YXRlIHRoYXQgYXMgb2YgdGhpcyBy ZXYgb2YgdGhlIEJGQ1Agc3BlYywgQkZDUCB3aXRoIFRDUCBjYW5kaWRhdGVzIGlzIG5vdCBkZWZp bmVkLiBGdXR1cmUgdXBkYXRlcw0KIHRvIHRoZSBzcGVjIG1heSBkZWZpbmUgdGhpcyB1c2FnZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkZy b206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5tbXVzaWMg Jmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIENoYXJsZXMg RWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCBE ZWNlbWJlciAyLCAyMDE2IGF0IDQ6MDEgUE08YnI+DQo8Yj5UbzogPC9iPlJvbWFuIFNocG91bnQg Jmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJv bWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1h aWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGll dGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwv YT4mZ3Q7LA0KIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtNTVVTSUNdIFtiZmNwYmlzXSBtPSBs aW5lIHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBubyBleHBl cmllbmNlIHdpdGggSUNFIHdpdGggVENQIGNhbmRpZGF0ZXMgc28gaG9wZWZ1bGx5IG90aGVycyBj YW4gY2hpbWUgaW4gYXMgdG8gd2hhdCB0aGV5IHRoaW5rIGlzIGEgd29ya2FibGUgc29sdXRpb24u DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hhcmxlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5Sb21h biBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0i X2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJz ZGF5LCBEZWNlbWJlciAxLCAyMDE2IGF0IDEyOjM0IFBNPGJyPg0KPGI+VG86IDwvYj5DaGFybGVz IEVja2VsICZsdDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5lY2tlbGN1QGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BbGFuIEZvcmQg Jmx0OzxhIGhyZWY9Im1haWx0bzphbGFuLmZvcmRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YWxhbi5mb3JkQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86YmZjcGJp c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJmY3BiaXNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86YmZjcGJpc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJmY3Bi aXNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmljZUBpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFp bHRvOmljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmljZUBpZXRmLm9yZzwvYT4mZ3Q7LCAm cXVvdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11 c2ljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7LCBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbYmZjcGJpc10gW01NVVNJQ10gbT0gbGluZSBwcm90b2Nv bCBpbiBjYXNlIG9mIElDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNoYXJsZXMsDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SRkMgNjU0NCBTZW5kaW5nIE1lZGlhICg8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9uLTEwLjEiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjU0NCNzZWN0aW9u LTEwLjE8L2E+KSZuYnNwO3NheXMgdGhhdCAmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+VGhlDQogZnJhbWluZyBkZWZpbmVkIGluIDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDU3MSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij5SRkMgNDU3MTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiBNVVNUIGJlIHVzZWQgd2hlbiBzZW5kaW5nIG1lZGlhLiZxdW90OyBUaGlzIG1l YW5zIHRoZSBwcm90b2NvbCB1c2VkIGlzIG5vdCBUQ1AvQkZDUCB3aGljaCBpcw0KIHVzaW5nIGFw cGxpY2F0aW9uIGxldmVsIGZyYW1pbmcuIEkgYmVsaWV2ZSB0aGF0IFNUVU4vTWVkaWEgZGVtdWx0 aXBsZXhpbmcgcmVxdWlyZW1lbnRzIHdvdWxkIHByZXZlbnQgdXNpbmcgVENQL0JGQ1AgZGlyZWN0 bHkgd2l0aCBpY2UgdGNwIGNhbmRpZGF0ZXMgd2l0aG91dCByZWRlc2lnbiBvZiBlaXRoZXIgSUNF IFRDUCBvciBUQ1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ RnVydGhlcm1vcmUmbmJzcDt0aGVyZSBhcmUgb3RoZXIgaW1wbGllZCBJQ0UgcmVxdWlyZW1lbnRz IHRoYXQgSSBvdXRsaW5lZCBiZWZvcmUgKHN3aXRjaGluZyBiZXR3ZWVuIHVkcCBhbmQgdHBjIGNh bmRpZGF0ZXMsIGV4aXN0ZW5jZSBvZiBTQkMgd2hpY2ggdGVybWluYXRlDQogSUNFIG9ubHkgYnV0 IGRvIG5vdCBzdXBwb3J0IHRoZSBlbWJlZGRlZCBwcm90b2NvbCkgYmVjYXVzZSBvZiB3aGljaCBp Y2UgdGNwIGlzIGNvbnNpZGVyZWQgdW5yZWxpYWJsZSB0cmFuc3BvcnQgYW5kIHdpbGwgcmVxdWly ZSBmcmFnbWVudGF0aW9uIHN1cHBvcnQgYW5kIHJlLXRyYW5zbWl0IHRpbWVycyB0aGF0IGFyZSBu b3QgcGFydCBvZiBUQ1AvQkZDUC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19fXzxicj4N ClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gVGh1LCBEZWMgMSwgMjAxNiBhdCAzOjE3IFBNLCBDaGFybGVzIEVja2VsIChl Y2tlbGN1KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZWNrZWxjdUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2h5IHdvdWxkIHNlbGVjdGluZyBUQ1AvQkZDUCBhcyB0cmFuc3BvcnQgdmlvbGF0ZSBS RkMgNjU0ND8gUGVyaGFwcyBpdCBkb2VzLCBidXQgYWZ0ZXIgYSBxdWljayBzY2FuIEkgYW0gbm90 IHN1cmUgd2h5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPlJvbWFuIFNocG91bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnJvbWFuQHRlbHVyaXguY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+VHVlc2RheSwgTm92ZW1iZXIgMjksIDIwMTYgYXQgMTA6MzggQU08YnI+DQo8Yj5UbzogPC9i PkNoYXJsZXMgRWNrZWwgJmx0OzxhIGhyZWY9Im1haWx0bzplY2tlbGN1QGNpc2NvLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPkFs YW4gRm9yZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsYW4uZm9yZEBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5hbGFuLmZvcmRAZ21haWwuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+YmZjcGJpc0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWNlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBo cmVmPSJtYWlsdG86aWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlQGlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2lj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDssIENocmlz dGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtiZmNwYmlzXSBbTU1VU0lDXSBtPSBsaW5l IHByb3RvY29sIGluIGNhc2Ugb2YgSUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g VHVlLCBOb3YgMjksIDIwMTYgYXQgMTI6NDggUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpICZs dDs8YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5lY2tl bGN1QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkl0 IHNlZW1zIHRvIG1lIHRoYXQgdGhlIG1vc3Qgc3RyYWlnaHRmb3J3YXJkIGFwcHJvYWNoIHdvdWxk IGJlIHRvIG1hbmRhdGUgc3VwcG9ydCBmb3IgQkZDUCBvdmVyIFVEUCB3aGVuIHVzaW5nIElDRSwg dXNlIFVEUCBhcyB0aGUgZGVmYXVsdCBjYW5kaWRhdGUsIGFuZCBzaWduYWwgdGhlIEJGQ1AgbS1s aW5lDQogYXMgaWYgaXQgaXMgQkZDUCBvdmVyIFVEUC4gSWYgd2UgY2FuIG1hbmRhdGUgdGhlIHVz ZSBvZiBEVExTLCB0aGF0IHdvdWxkIGJlIGV2ZW4gYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYWdyZWUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUg b25seSBpc3N1ZSB0aGF0IEkgc3RpbGwgaGF2ZSwgaWYgRFRMUyBpcyBub3QgdXNlZCwgd2hhdCBw cm90b2NvbCBpcyB1c2VkIHdoZW4gSUNFIHRjcCBjYW5kaWRhdGUgaXMmbmJzcDtzZWxlY3RlZCBm b3IgdHJhbnNwb3J0LiBJcyB0aGlzIFRDUC9CRkNQICh3aGljaCBnb2VzIGFnYWluc3QgUkZDNjU0 NCkgJm5ic3A7b3INCiBpcyBpdCBVRFAvQkZDUCB3aXRoIFJGQzQ1NzEgZnJhbWluZz8gSWYgaXQg aXMgVURQL0JGQ1Agd2l0aCBSRkM0NTcxIGZyYW1pbmcsIHdoYXQgdHJhbnNwb3J0IHRhZyBzaG91 bGQgYmUgdXNlZCBpbiB0aGUgcmUtSU5WSVRFIHdoaWNoIGlzIHNlbnQgYWZ0ZXIgSUNFIG5vbWlu YXRpb24gd2l0aCBvbmx5IHNlbGVjdGVkIGNhbmRpZGF0ZT8gU2hvdWxkIGl0IGJlIFRDUC9VRFAv QkZDUCBvciBzb21ldGhpbmcgc2ltaWxhcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19fX19fPGJy Pg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpiZmNwYmlzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpiZmNwYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+YmZjcGJpc0Bp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2JmY3BiaXMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JmY3BiaXM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E141AB908F354786B443DF7682F3D5FAciscocom_-- From nobody Tue Jan 10 12:35: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 A3A7B12954F for ; Tue, 10 Jan 2017 12:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 ndkA_KMwwnFJ for ; Tue, 10 Jan 2017 12:35:15 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 E197A1294B8 for ; Tue, 10 Jan 2017 12:35:14 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so110901069qtc.2 for ; Tue, 10 Jan 2017 12:35:14 -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=Hp4zqVqxIHGig+cDYqOF6/nI4NyENmxGYIc1gVZSguk=; b=sLG/Y3c/OsDbfVv9ut+ZrqDsrNECNjH1SZgvOB3zN2ELmpSvAjgr8B4Gq1LY0gZdbk s6lBfZIC05vHHTAs9upTPhOKo/BwpYqkTeynJPXameshRYrPJURv+6pQFUsg/ZXbbrtD Y1i7Hmx8zjWhXmhx+G3F1akKwx+u3H1kADq1Eil49dMdx1rt899bZOJHiFiwykDYRSn/ PERtWZTC/jyIW51wSm/oXrppLOZIWxc6MzqdNnv6S5z6caTiYcDovo0D9bT5nMMCiFuc kRqsvK9ZuH/Nq0nLNN/RPFkLgo1rhHDWvrbxLXIWSUmYE2gB1DBJBnbw9xdes/0sSkAQ 2otw== 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=Hp4zqVqxIHGig+cDYqOF6/nI4NyENmxGYIc1gVZSguk=; b=TpEQ9DwWzwl8sffyNjDk7Qi59i4iV3g4i0sGLbLQoKS8diOhy9+FZdaRkmTM0Ows/J 1APWpN57vQao742uRc4AUTw4vUewfXUGsHRvlJBuXysOVRaWUVBx3/xox2JGazexhLlM XCiczb6eNpc1kKOBH7fKgU9SD4C0FAtsSrYfmcHoTEykREecPeW2FPA8DQVRogf5rX7d Zn1Q78DYluCRhuUXiG4jnybGdT7rq3krLJ6JUCkxjFK9vzgQ309mFE9NhFQ37iPaDGbc E6tk/tAe8fpdymV73gfCtv3XK4ZzyB9GZ+UHq3MwLcM2eCP8h3t1BuNr/KGKmohy9NyR mCqg== X-Gm-Message-State: AIkVDXKXDadwuPJltwVPuwsAvUdq3GrTRbHPlwWsaVKEc2bhIL/NY4X3H8YzrFf/GXPprw== X-Received: by 10.200.51.26 with SMTP id t26mr5158320qta.106.1484080513802; Tue, 10 Jan 2017 12:35:13 -0800 (PST) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com. [209.85.220.181]) by smtp.gmail.com with ESMTPSA id j9sm2296845qtc.23.2017.01.10.12.35.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jan 2017 12:35:13 -0800 (PST) Received: by mail-qk0-f181.google.com with SMTP id 11so88971779qkl.3 for ; Tue, 10 Jan 2017 12:35:13 -0800 (PST) X-Received: by 10.55.161.212 with SMTP id k203mr5315286qke.234.1484080512974; Tue, 10 Jan 2017 12:35:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Tue, 10 Jan 2017 12:35:12 -0800 (PST) In-Reply-To: <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net> From: Roman Shpount Date: Tue, 10 Jan 2017 15:35:12 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c06e794cb4a530545c36bee Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 20:35:16 -0000 --94eb2c06e794cb4a530545c36bee Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat wrote: > On 1/10/17 1:08 PM, Roman Shpount wrote: > >> 1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to port 9, >> so that these lines carry no valid address information as it is >> specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP >> or UDP/DTLS/SCTP for data >> > > To do this cleanly, IMO there should be no singling out of IP4. The fact > is that in this case the c= line is not needed. (And this isn't the only > case where it isn't. It also isn't needed for MSRP and for websockets - > things that use URLs in attributes instead of c=.) So perhaps we should > revise 4566bis to make c= optional for m= lines where it isn't needed. Or > define a new addrtype for use in c= (e.g. simply "IP" or "IP4/6") and > define a placeholder address value for this case. For example: > > c=IN IP - It is cleaner, but this needs to be defined somewhere. Current JSEP uses "IN IP4 0.0.0.0" and port 9. 2. When c= line and m= line carry valid address information, protocol >> should match the candidate specified in c= and m= lines. >> >> 3. In cases when c= line and m= line carry valid address >> information, when initial offer and answer are generated, they must >> include UDP candidates and UDP candidates must be used as defaults. Once >> ICE nomination process is complete, only the active candidate pair MUST >> be included in SDP, and the transport for the active pair must be used. >> > > I think this could be handled by having different values: > > ICE/DTLS DTLS over either UDP or TCP > ICE/UDP/DTLS DTLS over only UDP > ICE/TCP/DTLS DTLS over only TCP > > ICE/DTLS/RTP/SAVPF Like above, but for RTP/SAVPF > ICE/UDP/DTLS/RTP/SAVPF " > ICE/TCP/DTLS/RTP/SAVPF " > > So this allows restricting the type of candidates that are allowed, or > not. And it avoids "lying" about the type that is to be used. > We can define it this way, but I am not sure defining anything beyond ICE/DTLS/RTP/SAVPF and ICE/DTLS/SCTP is actually needed. Once we specify that ICE is used, actual candidates can be examined to see which candidate types are supported. Regards, _____________ Roman Shpount --94eb2c06e794cb4a530545c36bee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <paul.kyzivat@co= mcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On = 1/10/17 1:08 PM, Roman Shpount wrote:
1. When c=3D line is set = to "IN IP4 0.0.0.0" and m=3D line is set to port 9,
so that these lines carry no valid address information as it is
specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP
or UDP/DTLS/SCTP for data

 To do this cleanly, IMO there should be no singling out of IP4. The fact is= that in this case the c=3D line is not needed. (And this isn't the onl= y case where it isn't. It also isn't needed for MSRP and for websoc= kets - things that use URLs in attributes instead of c=3D.) So perhaps we s= hould revise 4566bis to make c=3D optional for m=3D lines where it isn'= t needed. Or define a new addrtype for use in c=3D (e.g. simply "IP&qu= ot; or "IP4/6") and define a placeholder address value for this c= ase. For example:

=C2=A0 c=3DIN IP -

It is cleaner, but this = needs to be defined somewhere. Current JSEP uses "IN IP4 0.0.0.0"= and port 9.

2. When c=3D line and m=3D line carry valid address information, prot= ocol
should match the candidate specified in c=3D and m=3D lines.

3. In cases when c=3D line and m=3D line carry valid address
information, when initial offer and answer are generated, they must
include UDP candidates and UDP candidates must be used as defaults. Once ICE nomination process is complete, only the active candidate pair MUST
be included in SDP, and the transport for the active pair must be used.

 I think this could be handled by having different <proto> values:

ICE/DTLS=C2=A0 =C2=A0 =C2=A0 DTLS over either UDP or TCP
ICE/UDP/DTLS=C2=A0 DTLS over only UDP
ICE/TCP/DTLS=C2=A0 DTLS over only TCP

ICE/DTLS/RTP/SAVPF=C2=A0 =C2=A0 =C2=A0 Like above, but for RTP/SAVPF
ICE/UDP/DTLS/RTP/SAVPF=C2=A0 "
ICE/TCP/DTLS/RTP/SAVPF=C2=A0 "

So this allows restricting the type of candidates that are allowed, or not.= And it avoids "lying" about the type that is to be used.

We can define it this way, but I am not sure d= efining anything beyond ICE/DTLS/RTP/SAVPF and ICE/DTLS/SCTP is actually ne= eded. Once we specify that ICE is used, actual candidates can be examined t= o see which candidate types are supported.

Regards= ,
_____________
Roman Shpount
=C2=A0
--94eb2c06e794cb4a530545c36bee-- From nobody Tue Jan 10 14:18:04 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 1BBE412A05E for ; Tue, 10 Jan 2017 14:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 DMYeYsBAUlhK for ; Tue, 10 Jan 2017 14:18:01 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7A212A05A for ; Tue, 10 Jan 2017 14:18:01 -0800 (PST) X-AuditID: 1207440d-97fff70000000a35-f3-58755d97c442 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 54.81.02613.79D55785; Tue, 10 Jan 2017 17:18:00 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0AMHwwm020566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 17:17:59 -0500 To: Roman Shpount References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> <715b5012-0186-ea3b-08fb-954eae652c1d@comcast.net> From: Paul Kyzivat Message-ID: <01f63c15-f006-3b3e-59e1-d9bc2c568b43@alum.mit.edu> Date: Tue, 10 Jan 2017 17:17:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixO6iqDsjtjTC4NdXdoupyx+zWMy4MJXZ gcljyZKfTB63phQEMEVx2aSk5mSWpRbp2yVwZay9NImx4IVoxcYVM9gaGB/xdzFyckgImEhc nLGQsYuRi0NI4DKjROfG2VDOdSaJjkf/WUCqhAUcJI7tXAtmiwioSvz9PpkJougns8TBtl9g CWYBdYmJc28wgdhsAloScw5BNPMK2EvcWriGDcRmAWpec2IbI4gtKpAm8eDkVkaIGkGJkzOf gNVzCgRKLFr8GWqmmcS8zQ+ZIWx5ie1v5zBPYOSfhaRlFpKyWUjKFjAyr2KUS8wpzdXNTczM KU5N1i1OTszLSy3SNdLLzSzRS00p3cQICUneHYz/18kcYhTgYFTi4X3woiRCiDWxrLgy9xCj JAeTkiivlW1phBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3gMRQDnelMTKqtSifJiUNAeLkjiv 2hJ1PyGB9MSS1OzU1ILUIpisDAeHkgRvbAxQo2BRanpqRVpmTglCmomDE2Q4D9DwoyA1vMUF ibnFmekQ+VOMuhy3ji95yiTEkpeflyolztsMUiQAUpRRmgc3B5ZKXjGKA70lzDsVpIoHmIbg Jr0CWsIEtCTSrhhkSUkiQkqqgdH/eoTapNQfpqcCFn3ZcfMRk4KYkqUG99Hj7jH/Hx+58PjA to0nOiZf0OWpUxcW1XV9/lJu9VP7v8oSspxXJE5v3XP32i3/lp3P3l+41s2y+JzSwejXKpcE 9N42ynfEByqffCf9ViByNvszrvIwRjefxsJ/LiUnHH7yOn2+HS175qfjhsx2xkYlluKMREMt 5qLiRACpItEmAAMAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 22:18:03 -0000 On 1/10/17 3:35 PM, Roman Shpount wrote: > On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat > wrote: > > On 1/10/17 1:08 PM, Roman Shpount wrote: > > 1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to > port 9, > so that these lines carry no valid address information as it is > specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP > or UDP/DTLS/SCTP for data > > > To do this cleanly, IMO there should be no singling out of IP4. The > fact is that in this case the c= line is not needed. (And this isn't > the only case where it isn't. It also isn't needed for MSRP and for > websockets - things that use URLs in attributes instead of c=.) So > perhaps we should revise 4566bis to make c= optional for m= lines > where it isn't needed. Or define a new addrtype for use in c= (e.g. > simply "IP" or "IP4/6") and define a placeholder address value for > this case. For example: > > c=IN IP - > > > It is cleaner, but this needs to be defined somewhere. Current JSEP uses > "IN IP4 0.0.0.0" and port 9. 4566bis is still in progress, so it could be done there. > 2. When c= line and m= line carry valid address information, > protocol > should match the candidate specified in c= and m= lines. > > 3. In cases when c= line and m= line carry valid address > information, when initial offer and answer are generated, they must > include UDP candidates and UDP candidates must be used as > defaults. Once > ICE nomination process is complete, only the active candidate > pair MUST > be included in SDP, and the transport for the active pair must > be used. > > > I think this could be handled by having different values: > > ICE/DTLS DTLS over either UDP or TCP > ICE/UDP/DTLS DTLS over only UDP > ICE/TCP/DTLS DTLS over only TCP > > ICE/DTLS/RTP/SAVPF Like above, but for RTP/SAVPF > ICE/UDP/DTLS/RTP/SAVPF " > ICE/TCP/DTLS/RTP/SAVPF " > > So this allows restricting the type of candidates that are allowed, > or not. And it avoids "lying" about the type that is to be used. > > > We can define it this way, but I am not sure defining anything beyond > ICE/DTLS/RTP/SAVPF and ICE/DTLS/SCTP is actually needed. Once we specify > that ICE is used, actual candidates can be examined to see which > candidate types are supported. Perhaps choice of UDP/TCP/both can be left to the candidates. I guess if one side wants to restrict to one or the other it can offer only candidates of the type it wants. Thanks. Paul From nobody Wed Jan 11 00:31:07 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 C68DB129A97 for ; Wed, 11 Jan 2017 00:31:05 -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 kiUVAeZDFDdw for ; Wed, 11 Jan 2017 00:31:04 -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 34448129A8A for ; Wed, 11 Jan 2017 00:31:04 -0800 (PST) X-AuditID: c1b4fb2d-26a859800000561e-59-5875ed458bec Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 48.36.22046.54DE5785; Wed, 11 Jan 2017 09:31:02 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.319.2; Wed, 11 Jan 2017 09:30:34 +0100 To: Roman Shpount , Paul Kyzivat References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <9ff375eb-0efc-cb7e-6f26-c48f17c55275@comcast.net> From: Magnus Westerlund Message-ID: <3982a710-8b12-0ef1-6196-82affb50d3c5@ericsson.com> Date: Wed, 11 Jan 2017 09:30:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM2K7ma7b29IIg6lLuS2mLn/MYvHgRy+b xYwLU5kdmD0mP57D6LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyZk7czFhwlr1i56wZLA2M S9i6GDk5JARMJG7PXc3axcjFISSwjlGi48E/JpCEkMByRokpPRYgtrCAg8SxnWtZQGwRAT+J 0xO3s0A0/GWSWPf1C1ADBwezgLrE1cVBIDVsAhYSN380gi3gFbCXmNLWwwxiswioSrzYdw8s LioQI/F2/XJ2iBpBiZMzn4DN5xQIlPg85TkLxEh7iQdby0DCzALyEs1bZzNDnKYt0dDUwTqB UWAWku5ZCB2zkHQsYGRexShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYpAe3/Nbdwbj6teMh RgEORiUe3g/fSiKEWBPLiitzDzFKcDArifAue1UaIcSbklhZlVqUH19UmpNafIhRmoNFSZzX bOX9cCGB9MSS1OzU1ILUIpgsEwenVAOjyi6P3glzO+p3FC3/3nZOOpJxeoaut4qKwSsGg30t aoUyk4KDvN/mJy97YhK158qv9hViNvpKzWcOOfhPOn69JnnyZrOHG6zNkmVOxzcrp+1+57lt lTNPwN9sk1idX5NO34kQmHdE7ybv9sQlbX+N/Cbl2r4P8fZcveDW/lN+FpM8HsnYOK1TYinO SDTUYi4qTgQA9BODZE4CAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 08:31:06 -0000 Den 2017-01-10 kl. 19:08, skrev Roman Shpount: > P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it > be "UDP/DTLS/RTP/SAVPF"? No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over UDP with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" is not registered. So the alternatives for the dependency of default candidate protocol type in your proposal would be: UDP: "UDP/TLS/RTP/SAVPF" TCP: "TCP/DTLS/RTP/SAVPF" Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jan 11 13:01:39 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 33001129871 for ; Wed, 11 Jan 2017 13:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 0NRQTWRgFm5v for ; Wed, 11 Jan 2017 13:01:31 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 6B548129872 for ; Wed, 11 Jan 2017 13:01:31 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a20so27769qkc.1 for ; Wed, 11 Jan 2017 13:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=ogx+jTf1d3zkyjOL1ZEpStH0fCMp37v6aDzvNndgUMA=; b=PEhA7ZFuq9YcnD4ZrVklJsop/aTMO8KSo3eR+4KtAgHKmmMXE86L9+Ok0XHIasfpEm t4vJDSbBpcYevQ/KN14RFPc/0un3W0rcfJ4IAK7hZlrsH3Sof99MY++cHncumT4HYde1 zc8nyhZutqL6e51jEUY5FYDMtYFIGToA0KphjZs3sF4COOMgQw6wNH/TKed8ZNWVdpwh DK1AvSS32K2Cw9eREOqbxo4/fk8oYqwrXVEnSAXYT9e9DSrYkze7gh5Gpy9egAfk6VDt oR15Dc14L8qITSALWCBiBiidryNR/ibyc8H1igXLbrUBH8Y/u3n2s0JxjWwrDYV+nhRf ErkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ogx+jTf1d3zkyjOL1ZEpStH0fCMp37v6aDzvNndgUMA=; b=Bh3oAHno9TwR+WL8gtzuR0VfYlzELEAoI+GcvKpqB1jMmDgzr2JMZPs6FISGxJvg5S pBpxreGdXBq8wQ4DEYI27G/uksLUMTYRksAalZZbhHVydyLj6rBEfIg2+WlGOgDrEPXR +1Y+ydr2RMbShGpPjFqydHF33xK17ukbozsGwWewVcgnd4k++/NLET0p9HJOaQt3vI5e 3nhkbW1nsEclE8SQzzZGMsv07ojPzJdfoO/R+ZCEOOd+o1HvglvCTYxGkAWwrR2pKZ1v 2cJOlX93d2pn7T78DIDosibB0isVTuedfP+WCKTmjQgSB6iFas4vr4zC45ln74qn5u2z mD6A== X-Gm-Message-State: AIkVDXIWnIwlScqdXTZPGsfruJj8/n8qgFQ85D0X15mnra02sFa1Ke2XJ09Kek//Azyxpg== X-Received: by 10.55.198.149 with SMTP id s21mr11061933qkl.196.1484168490437; Wed, 11 Jan 2017 13:01:30 -0800 (PST) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com. [209.85.220.180]) by smtp.gmail.com with ESMTPSA id d15sm4974501qkb.10.2017.01.11.13.01.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 13:01:30 -0800 (PST) Received: by mail-qk0-f180.google.com with SMTP id u25so606372028qki.2 for ; Wed, 11 Jan 2017 13:01:30 -0800 (PST) X-Received: by 10.55.142.1 with SMTP id q1mr9597291qkd.225.1484168489566; Wed, 11 Jan 2017 13:01:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Wed, 11 Jan 2017 13:01:29 -0800 (PST) From: Roman Shpount Date: Wed, 11 Jan 2017 16:01:29 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c0830de9b8b150545d7e786 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 21:01:38 -0000 --94eb2c0830de9b8b150545d7e786 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What should we use for the new protocols that we are defining? Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP? Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP? I would like to see some consistency here. Regards, _____________ Roman Shpount On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-10 kl. 19:08, skrev Roman Shpount: > > P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it >> be "UDP/DTLS/RTP/SAVPF"? >> > > No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over > UDP with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" is no= t > registered. > > So the alternatives for the dependency of default candidate protocol type > in your proposal would be: > > UDP: "UDP/TLS/RTP/SAVPF" > TCP: "TCP/DTLS/RTP/SAVPF" > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c0830de9b8b150545d7e786 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What should we use for the new protocols that we are defin= ing?

Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP?
Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP?

I w= ould like to see some consistency here.

Regards,
_____________<= br>Roman Shpount

On Wed, Jan 11, 2017 at 3:30 AM, Magnus West= erlund <magnus.westerlund@ericsson.com> wrote:<= br>
Den 2017-01-10 kl. 19:08, skrev Roman Shpount:

P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", sh= ould it
be "UDP/DTLS/RTP/SAVPF"?

 No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over UDP= with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" = is not registered.

So the alternatives for the dependency of default candidate protocol type i= n your proposal would be:

UDP: "UDP/TLS/RTP/SAVPF"
TCP: "TCP/DTLS/RTP/SAVPF"


Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--94eb2c0830de9b8b150545d7e786-- From nobody Wed Jan 11 14:05:45 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 48D6A129DAA for ; Wed, 11 Jan 2017 14:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 oBhabF3VZ5YP for ; Wed, 11 Jan 2017 14:05:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92F6129851 for ; Wed, 11 Jan 2017 14:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15094; q=dns/txt; s=iport; t=1484172342; x=1485381942; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UhuJZ0ndxFSOvje8pCsEu1sOsJVkyBrInif7+Nvs1xE=; b=L460CDDWTWd1KzKuEbjxotSXAGtlTEy5eF8BfuuXX+9MPU8EfFsrv3a1 p9nnLol7DXX3dK4tplgEQSoF24HFUCd9SL/xSJGDZfA0V6NhQmAsdXKyC K/u2vbIGIDx7oIRwhYV/VVD0TACx/ulWpQmefhPue3kVQW0Nlj/beY0qh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQD4qnZY/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFKAQEBAQEfX4ENB4MCRooIkhKPfIMcgg+CDSqFeAIagW4/FAE?= =?us-ascii?q?CAQEBAQEBAWMohGkBAQEEDBdWDgICAQYCEQMBAigDAgICGRcUCQgCBAENBYkAD?= =?us-ascii?q?pMenU6CJSuJbgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYhCCIJXhF0JFoJSLYI?= =?us-ascii?q?xBYh1kjUBhlqKeJBlkmABHziBQRVKAYYec4dZgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208,217";a="371507792" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 22:05:41 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0BM5fwt019148 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jan 2017 22:05:41 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 16:05:41 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Wed, 11 Jan 2017 16:05:41 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount , Magnus Westerlund Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE3p2SC5GZHiXUyd4kk6fM3mOqEzs4yA Date: Wed, 11 Jan 2017 22:05:40 +0000 Message-ID: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.182.35] Content-Type: multipart/alternative; boundary="_000_6A083F674ECB4703A881EB2F074F309Eciscocom_" MIME-Version: 1.0 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 22:05:44 -0000 --_000_6A083F674ECB4703A881EB2F074F309Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZSBpcyB3aGF0IHdlIGhhdmUgZm9yIEJGQ1AgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2I3NlY3Rpb24tMTM6DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAg ICAgICAgICAgICAgICAgfCBWYWx1ZSAgICAgICAgfCBSZWZlcmVuY2UgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg ICAgICAgICAgfCBUQ1AvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgfCBUQ1AvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgfCBVRFAvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAg fCBVRFAvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBt bXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUm9tYW4gU2hwb3Vu dCA8cm9tYW5AdGVsdXJpeC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEphbnVhcnkgMTEsIDIwMTcg YXQgMTowMSBQTQ0KVG86IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20+DQpDYzogUGF1bCBLeXppdmF0IDxwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ+LCAi bW11c2ljQGlldGYub3JnIiA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogW01NVVNJQ10gVHJh bnNwb3J0IHRhZ3MNCg0KV2hhdCBzaG91bGQgd2UgdXNlIGZvciB0aGUgbmV3IHByb3RvY29scyB0 aGF0IHdlIGFyZSBkZWZpbmluZz8NCg0KU2hvdWxkIGl0IGJlIFVEUC9UTFMvU0NUUCBvciBVRFAv RFRMUy9TQ1RQPw0KU2hvdWxkIGl0IGJlIFVEUC9UTFMvQkZDUCBvciBVRFAvRFRMUy9CRkNQPw0K DQpJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgY29uc2lzdGVuY3kgaGVyZS4NCg0KUmVnYXJkcywN Cl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gV2VkLCBKYW4gMTEsIDIwMTcgYXQg MzozMCBBTSwgTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bTxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpEZW4gMjAx Ny0wMS0xMCBrbC4gMTk6MDgsIHNrcmV2IFJvbWFuIFNocG91bnQ6DQpQLlMuIEluIHRoZSBxdW90 ZWQgdGV4dCBzb21lb25lIG1lbnRpb25lZCAiVURQL1RMUy9SVFAvU0FWUEYiLCBzaG91bGQgaXQN CmJlICJVRFAvRFRMUy9SVFAvU0FWUEYiPw0KDQpObywgYWN0dWFsbHkgVURQL1RMUy9SVFAvU0FW UEYgaXMgd2hhdCBpcyByZWdpc3RlcmVkIGZvciBEVExTLVNSVFAgb3ZlciBVRFAgd2l0aCBSVFAg U0FWUEYgcHJvZmlsZS4gU2VlIFtSRkM1NzY0XS4gVGhlICJVRFAvRFRMUy9SVFAvU0FWUEYiIGlz IG5vdCByZWdpc3RlcmVkLg0KDQpTbyB0aGUgYWx0ZXJuYXRpdmVzIGZvciB0aGUgZGVwZW5kZW5j eSBvZiBkZWZhdWx0IGNhbmRpZGF0ZSBwcm90b2NvbCB0eXBlIGluIHlvdXIgcHJvcG9zYWwgd291 bGQgYmU6DQoNClVEUDogIlVEUC9UTFMvUlRQL1NBVlBGIg0KVENQOiAiVENQL0RUTFMvUlRQL1NB VlBGIg0KDQoNCkNoZWVycw0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpT ZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVB Qi9UWE0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25l ICArNDYgMTAgNzE0ODI4Nzx0ZWw6JTJCNDYlMjAxMCUyMDcxNDgyODc+DQpGw6Ryw7ZnYXRhbiA2 ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OTx0ZWw6JTJCNDYlMjA3MyUy MDA5NDkwNzk+DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53 ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= --_000_6A083F674ECB4703A881EB2F074F309Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGVyZSBpcyB3aGF0IHdlIGhhdmUgZm9yIEJGQ1AgaW4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2I3NlY3Rpb24t MTM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgVmFsdWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBSZWZl cmVuY2UmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVENQL0JGQ1AmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCBbUkZDIFhYWFhdIHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3wgVENQL1RMUy9CRkNQIHwg W1JGQyBYWFhYXSB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFVEUC9CRkNQJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwgW1JGQyBYWFhYXSB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFVEUC9UTFMvQkZDUCB8IFtS RkMgWFhYWF0gfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0t LS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYXJsZXM8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5tbXVzaWMgJmx0 O21tdXNpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUm9tYW4gU2hwb3VudCAm bHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSmFu dWFyeSAxMSwgMjAxNyBhdCAxOjAxIFBNPGJyPg0KPGI+VG86IDwvYj5NYWdudXMgV2VzdGVybHVu ZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+ UGF1bCBLeXppdmF0ICZsdDtwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQmZ3Q7LCAmcXVvdDttbXVz aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W01NVVNJQ10gVHJhbnNwb3J0IHRhZ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgc2hvdWxkIHdlIHVzZSBmb3Ig dGhlIG5ldyBwcm90b2NvbHMgdGhhdCB3ZSBhcmUgZGVmaW5pbmc/DQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNob3VsZCBpdCBiZSBVRFAvVExTL1NDVFAg b3IgVURQL0RUTFMvU0NUUD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNob3VsZCBpdCBiZSBVRFAvVExTL0JGQ1Agb3IgVURQL0RUTFMvQkZDUD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNvbnNpc3RlbmN5IGhlcmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsIDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAxMSwgMjAxNyBhdCAzOjMwIEFNLCBNYWdudXMgV2Vz dGVybHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gY2xhc3M9ImdtYWlsLSI+RGVuIDIw MTctMDEtMTAga2wuIDE5OjA4LCBza3JldiBSb21hbiBTaHBvdW50OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QLlMuIEluIHRoZSBxdW90 ZWQgdGV4dCBzb21lb25lIG1lbnRpb25lZCAmcXVvdDtVRFAvVExTL1JUUC9TQVZQRiZxdW90Oywg c2hvdWxkIGl0PGJyPg0KYmUgJnF1b3Q7VURQL0RUTFMvUlRQL1NBVlBGJnF1b3Q7PzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KTm8sIGFj dHVhbGx5IFVEUC9UTFMvUlRQL1NBVlBGIGlzIHdoYXQgaXMgcmVnaXN0ZXJlZCBmb3IgRFRMUy1T UlRQIG92ZXIgVURQIHdpdGggUlRQIFNBVlBGIHByb2ZpbGUuIFNlZSBbUkZDNTc2NF0uIFRoZSAm cXVvdDtVRFAvRFRMUy9SVFAvU0FWUEYmcXVvdDsgaXMgbm90IHJlZ2lzdGVyZWQuPGJyPg0KPGJy Pg0KU28gdGhlIGFsdGVybmF0aXZlcyBmb3IgdGhlIGRlcGVuZGVuY3kgb2YgZGVmYXVsdCBjYW5k aWRhdGUgcHJvdG9jb2wgdHlwZSBpbiB5b3VyIHByb3Bvc2FsIHdvdWxkIGJlOjxicj4NCjxicj4N ClVEUDogJnF1b3Q7VURQL1RMUy9SVFAvU0FWUEYmcXVvdDs8YnI+DQpUQ1A6ICZxdW90O1RDUC9E VExTL1JUUC9TQVZQRiZxdW90OyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpD aGVlcnM8YnI+DQo8YnI+DQpNYWdudXMgV2VzdGVybHVuZDxicj4NCjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJl c2VhcmNoIEVBQi9UWE08YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRXJpY3Nzb24gQUImbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wg UGhvbmUmbmJzcDsgPGEgaHJlZj0idGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3IiB0YXJnZXQ9Il9i bGFuayI+DQomIzQzOzQ2IDEwIDcxNDgyODc8L2E+PGJyPg0KRsOkcsO2Z2F0YW4gNiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBN b2JpbGUgPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzMlMjAwOTQ5MDc5IiB0YXJnZXQ9Il9ibGFuayI+ DQomIzQzOzQ2IDczIDA5NDkwNzk8L2E+PGJyPg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVu IHwgbWFpbHRvOiA8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+DQptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+PGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_6A083F674ECB4703A881EB2F074F309Eciscocom_-- From nobody Wed Jan 11 16:33: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 444111294BC for ; Wed, 11 Jan 2017 16:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 rT_zZg2iMSvY for ; Wed, 11 Jan 2017 16:33:15 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB347129542 for ; Wed, 11 Jan 2017 16:33:15 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id 11so4741364qkl.3 for ; Wed, 11 Jan 2017 16:33: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=SvKBFuWIqbG2DK2inFI/8/iOszjjgKM4Jg/pNRazE1w=; b=lq9/1CD5CcSbzpgX6JcwUNz9gvcMGLr96QaaURBsMuoCnS0b5SOndENhT7lCJ+5qwU WNZ22hHbTvS4VQPhaGOzXFBKdlHqTwT6IexMFzGfnvx61E7WznGLklUf3IDK02KSHMx4 qllivWxkvxIz5vDB6XSDhVk3zxHaug/VGTQJusa8fRPjsLruBCDEN2NDnKDubyqws+h1 wzLLDvMkhcO4SizFg/0jZbkJo55ShUijzzXUddTKLLUF0SxLYFSrTk3grE3IVfrIJKuq JWfskr+HaUAQu67H5Pwi0M0Qsxtp00YboQdkRgT2iNfJlIiccNQPPMtDJz5jJhZNYBxh Hfww== 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=SvKBFuWIqbG2DK2inFI/8/iOszjjgKM4Jg/pNRazE1w=; b=qdZgcb/lAUTyAI5qXlkUP0NDZZT7GdRnhFwy9pEanSiv/rNhwRY39Zjn/5AuLZbvFV KGqUS+gcxBHmoK+vgdSpNxlrpOZWrGLWaAOAGLFWYNbsmO51Q7zNhhBNfz3EeVS7V372 XGTyaUFM+lu75KEaQFeTbM33nFt7Y38zi9g0APznS7x04jrPYagzniuY8R76WFXMo6Mx L5ON7m7SFlfwRMhRlvT5RYekW8Kis13At+hBqRuCxylW7rf7hjSkj0aKqrO1eu5aQaBY RDB/Hn8/fHBtOo/vin13NVMe+3CFFIZ7bfgY0CtLl6Xkx6kUeDg6EgciE+yi2WNunfLJ Si9g== X-Gm-Message-State: AIkVDXLc7BQTJvWiPQXh43ogiIkoCqQmtcOj0tSiOg68aWxxd5Rc8D+2bLnPHtCNi1/FTQ== X-Received: by 10.55.128.3 with SMTP id b3mr10583295qkd.130.1484181194385; Wed, 11 Jan 2017 16:33:14 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com. [209.85.220.179]) by smtp.gmail.com with ESMTPSA id r131sm5368814qke.14.2017.01.11.16.33.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jan 2017 16:33:13 -0800 (PST) Received: by mail-qk0-f179.google.com with SMTP id s140so4939587qke.0 for ; Wed, 11 Jan 2017 16:33:13 -0800 (PST) X-Received: by 10.55.80.198 with SMTP id e189mr10595263qkb.222.1484181193675; Wed, 11 Jan 2017 16:33:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Wed, 11 Jan 2017 16:33:13 -0800 (PST) In-Reply-To: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> From: Roman Shpount Date: Wed, 11 Jan 2017 19:33:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a114a6f02d4db910545dadc38 Archived-At: Cc: Magnus Westerlund , Christer Holmberg , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 00:33:18 -0000 --001a114a6f02d4db910545dadc38 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I guess BFCP will need TCP/DTLS/BFCP added to the list. Should we correct draft-ietf-mmusic-sctp-sdp draft to match and change UDP/DTLS/SCTP to UDP/TLS/SCTP? Regards, _____________ Roman Shpount On Wed, Jan 11, 2017 at 5:05 PM, Charles Eckel (eckelcu) wrote: > Here is what we have for BFCP in https://tools.ietf.org/html/ > draft-ietf-bfcpbis-rfc4583bis-16#section-13: > > > > +--------------+------------+ > > | Value | Reference | > > +--------------+------------+ > > | TCP/BFCP | [RFC XXXX] | > > | TCP/TLS/BFCP | [RFC XXXX] | > > | UDP/BFCP | [RFC XXXX] | > > | UDP/TLS/BFCP | [RFC XXXX] | > > +--------------+------------+ > > > > Cheers, > > Charles > > > > *From: *mmusic on behalf of Roman Shpount < > roman@telurix.com> > *Date: *Wednesday, January 11, 2017 at 1:01 PM > *To: *Magnus Westerlund > *Cc: *Paul Kyzivat , "mmusic@ietf.org" < > mmusic@ietf.org> > *Subject: *[MMUSIC] Transport tags > > > > What should we use for the new protocols that we are defining? > > > > Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP? > > Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP? > > > > I would like to see some consistency here. > > > > Regards, > > _____________ > Roman Shpount > > > > On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > Den 2017-01-10 kl. 19:08, skrev Roman Shpount: > > P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it > be "UDP/DTLS/RTP/SAVPF"? > > > No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over > UDP with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" is no= t > registered. > > So the alternatives for the dependency of default candidate protocol type > in your proposal would be: > > UDP: "UDP/TLS/RTP/SAVPF" > TCP: "TCP/DTLS/RTP/SAVPF" > > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > > --001a114a6f02d4db910545dadc38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess BFCP will need TCP/DTLS/BFCP added to the list.

Should we correct draft-ietf-mmusic-sctp-sdp draft to match= and change UDP/DTLS/SCTP to UDP/TLS/SCTP?

Regards,

_____________
Roman Shpo= unt

On Wed, Jan 11, 2017 at 5:05 PM, Charles Eck= el (eckelcu) <eckelcu@cisco.com> wrote:

Here is what we have for BFCP in https://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-16#section-13:

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Reference=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | TCP/BFCP=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC XXXX] |

=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=C2=A0=C2=A0=C2=A0 =C2= =A0| TCP/TLS/BFCP | [RFC XXXX] |

=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=C2=A0=C2=A0=C2=A0=C2=A0= | UDP/BFCP=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC XXXX] |

=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=C2=A0=C2=A0=C2=A0=C2=A0= | UDP/TLS/BFCP | [RFC XXXX] |

=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=C2=A0=C2=A0=C2=A0=C2=A0= +--------------+------------+

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: mmusic <mmusic-bounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>
Date: Wednesday, January 11, 2017 at 1:01 PM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] Transport tags

=C2=A0

What should we use for the new protocols that we are= defining?

=C2=A0

Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP?

Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP?

=C2=A0

I would like to see some consistency here.=

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund &= lt;magn= us.westerlund@ericsson.com> wrote:

Den 2017-01-10 kl. 19:08, skrev Roman Shpount:

P.S. In the quoted text someone mentioned "UDP/= TLS/RTP/SAVPF", should it
be "UDP/DTLS/RTP/SAVPF"?


No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over UDP= with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" = is not registered.

So the alternatives for the dependency of default candidate protocol type i= n your proposal would be:

UDP: "UDP/TLS/RTP/SAVPF"
TCP: "TCP/DTLS/RTP/SAVPF"



Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

=C2=A0


--001a114a6f02d4db910545dadc38-- From nobody Wed Jan 11 21:04: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 4A3C7126FDC for ; Wed, 11 Jan 2017 21:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seGKg3lzerf1 for ; Wed, 11 Jan 2017 21:04:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A0012946B for ; Wed, 11 Jan 2017 21:04:06 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 13897B81A86; Wed, 11 Jan 2017 21:04:06 -0800 (PST) To: M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, fandreas@cisco.com, bo.burman@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170112050406.13897B81A86@rfc-editor.org> Date: Wed, 11 Jan 2017 21:04:06 -0800 (PST) Archived-At: Cc: block.rxckin.beats@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org Subject: [MMUSIC] [Editorial Errata Reported] RFC4566 (4903) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 05:04:13 -0000 The following errata report has been submitted for RFC4566, "SDP: Session Description Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=4903 -------------------------------------- Type: Editorial Reported by: Jxck Section: 9 Original Text ------------- ; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions connection-field = [%x63 "=" nettype SP addrtype SP connection-address CRLF] ;a connection field must be present ;in every media description or at the ;session-level media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields ) Corrected Text -------------- ; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields [connection-field] bandwidth-fields time-fields key-field attribute-fields media-descriptions connection-field = %x63 "=" nettype SP addrtype SP connection-address CRLF ;a connection field must be present ;in every media description or at the ;session-level media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields ) Notes ----- in BNF of SDP, connection-field itself is optional [0, 1], but media-description has multiple [0,) connection-field. it seems conflict, because multiple of optional fields doesn't finish because multiple filed can't find when to end. so change connection-field itself not optional (remove []) and, replace session-descriptions connection-field as optional. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4566 (draft-ietf-mmusic-sdp-new-26) -------------------------------------- Title : SDP: Session Description Protocol Publication Date : July 2006 Author(s) : M. Handley, V. Jacobson, C. Perkins Category : PROPOSED STANDARD Source : Multiparty Multimedia Session Control RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Wed Jan 11 23:49: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 9F1AF12943E for ; Wed, 11 Jan 2017 23:49:14 -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 6jjohYv9-aJM for ; Wed, 11 Jan 2017 23:49:13 -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 210C61270B4 for ; Wed, 11 Jan 2017 23:49:12 -0800 (PST) X-AuditID: c1b4fb3a-2f75798000002085-8a-587734f77864 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 79.2C.08325.7F437785; Thu, 12 Jan 2017 08:49:11 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Thu, 12 Jan 2017 08:49:21 +0100 To: Roman Shpount References: From: Magnus Westerlund Message-ID: Date: Thu, 12 Jan 2017 08:48:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM2K7t+53k/IIg1lf5CymLn/MYvHgRy+b xYwLU5kdmD0mP57D6LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgybvyaxliwSLRiw80ulgbG SwJdjBwcEgImEsveK3cxcnEICaxjlLiz9g0bhLOcUWLDz/vsXYycHMIC0hLzXm9lBbFFBFQl /n6fzARiCwkESBz6PoMZxGYWCJI4dbqTDcRmE7CQuPmjEczmFbCXmPNsCQuIzQLUO/XBArC4 qECMxNv1y9khagQlTs58AlbDKRAosWFFD9RMC4mZ888zQtjyEs1bZzND7NWWaGjqYJ3AKDAL SfssJC2zkLQsYGRexShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYqAe3/LbawXjwueMhRgEO RiUe3gKPsggh1sSy4srcQ4wSHMxKIrzuwDAX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzmu28n64 kEB6YklqdmpqQWoRTJaJg1OqgVHp2+7rVrk7HgaLXDbNVr8SuNTq2YINKQUPE6OMz3h/tX9c /rr3Mpfw1M3N7VaT37ceLGPZf9jcXnzuHZtvN02vTncq3WISdzVvIveSWoGJlamXdpQvU+Qw cn+mXHWvJ7c/2mvSsiPVmgcn7+j377wYtHVnw1Lph1YsQWVztx3N/7+HI/KGlZQSS3FGoqEW c1FxIgBbOwv4UAIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 07:49:14 -0000 Hi, I think one should actually use the DTLS or TLS depending on what one requires. It one requires DTLS, then use DTLS, if is working with plain TLS, then use TLS. The UDP/TLS/RTP/SAVPF is part of the first DTLS-SRTP registrations that was done. As plain TLS can't work in this particular combination due to UDP there is no actual risk for having to seperate between TLS and DTLS. However, if one stack is TCP/FRAMING/(D)TLS/FOO then there are potentially important differences if this is TLS or DTLS. Cheers Magnus Den 2017-01-11 kl. 22:01, skrev Roman Shpount: > What should we use for the new protocols that we are defining? > > Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP? > Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP? > > I would like to see some consistency here. > > Regards, > _____________ > Roman Shpount > > On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund > > > wrote: > > Den 2017-01-10 kl. 19:08, skrev Roman Shpount: > > P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", > should it > be "UDP/DTLS/RTP/SAVPF"? > > > No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP > over UDP with RTP SAVPF profile. See [RFC5764]. The > "UDP/DTLS/RTP/SAVPF" is not registered. > > So the alternatives for the dependency of default candidate protocol > type in your proposal would be: > > UDP: "UDP/TLS/RTP/SAVPF" > TCP: "TCP/DTLS/RTP/SAVPF" > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jan 12 06:33: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 514EA129417 for ; Thu, 12 Jan 2017 06:33:38 -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 TC73I1voTrhT for ; Thu, 12 Jan 2017 06:33:36 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 DD47D1293F0 for ; Thu, 12 Jan 2017 06:33:36 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with SMTP id RgRbct12brdcjRgRbcw76f; Thu, 12 Jan 2017 14:33:35 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-05v.sys.comcast.net with SMTP id RgRVcUUvrmBhGRgRWc0tju; Thu, 12 Jan 2017 14:33:33 +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 v0CEXTQZ000738; Thu, 12 Jan 2017 09:33:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0CEXRwf000734; Thu, 12 Jan 2017 09:33:27 -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: RFC Errata System In-Reply-To: <20170112050406.13897B81A86@rfc-editor.org> Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 12 Jan 2017 09:33:27 -0500 Message-ID: <87ziiw73go.fsf@hobgoblin.ariadne.com> Archived-At: Cc: ben@nostrum.com, block.rxckin.beats@gmail.com, mmusic@ietf.org, aamelnikov@fastmail.fm, fandreas@cisco.com, M.Handley@cs.ucl.ac.uk, csp@csperkins.org, van@packetdesign.com, rfc-editor@rfc-editor.org Subject: Re: [MMUSIC] [Editorial Errata Reported] RFC4566 (4903) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 14:33:38 -0000 RFC Errata System writes: > Original Text > connection-field = [%x63 "=" nettype SP addrtype SP > connection-address CRLF] > ;a connection field must be present > ;in every media description or at the > ;session-level > Corrected Text > connection-field = %x63 "=" nettype SP addrtype SP > connection-address CRLF > ;a connection field must be present > ;in every media description or at the > ;session-level > > in BNF of SDP, connection-field itself is optional [0, 1], but > media-description has multiple [0,) connection-field. it seems > conflict, because multiple of optional fields doesn't finish because > multiple filed can't find when to end. As a grammar, a set of BNF productions, the original text is correct. The erratum is correct that parser generators may have a difficult time processing that grammar, but strictly speaking, that is not a problem with the RFC. Personally, I do not like the style of the grammar, which is to present all of the alternatives as required and then each alternative contains its own optionality. That is, session-description = proto-version origin-field session-name-field information-field uri-field email-fields [...] information-field = [%x69 "=" text CRLF] uri-field = [%x75 "=" uri CRLF] email-fields = *(%x65 "=" email-address CRLF) I would prefer session-description = proto-version origin-field session-name-field [information-field] [uri-field] *email-field [...] information-field = %x69 "=" text CRLF uri-field = %x75 "=" uri CRLF email-field = %x65 "=" email-address CRLF But that is a style issue, and it is best to define connection-field using the same style as every other field. Dale From nobody Thu Jan 12 07:52:04 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 B1106129469 for ; Thu, 12 Jan 2017 07:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 muakg0blB_5j for ; Thu, 12 Jan 2017 07:51:59 -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 BE12412946A for ; Thu, 12 Jan 2017 07:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22218; q=dns/txt; s=iport; t=1484236318; x=1485445918; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+BUrtpA2TRlJ6jcXyOvHgrdInrUhopUwoLdWbo3ZocA=; b=Hj4uy3okVhTsKHLBY1L0En5bnpf3Vgw4Oz+UzKvCbMmRDUzyGmeiWZHU cS2wuFoj5k6ZbR8JGLTeLcfYFkaQ4mTFxxpMNysrUhi7YS+1tRhE9bou2 gBwKF4fHLMsSir9H49Fi+TGM8Q6dCk6DVzaUfOB9GkBPc9uYbclCtaFbt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCtpXdY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnJKAQEBAQEfX4EJB4MDRooIkhWTG4IPgg0qhXgCGoFnPxQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAwXVg4CAgEGAhEDAQIoAwICAhkXFAkIAgQOBYkADpJvn?= =?us-ascii?q?U6CJSuJaQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYhCCIJXhF0JFoJQLYIxBYh?= =?us-ascii?q?2jDKGBAGGWop7CpBgkmMBHziBRBU6EAGGHnOHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208,217";a="191773135" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 15:51:57 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0CFpvPI011103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2017 15:51:57 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 09:51:56 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Thu, 12 Jan 2017 09:51:56 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE3p2SC5GZHiXUyd4kk6fM3mOqEzs4yAgACvV4CAAHqSgA== Date: Thu, 12 Jan 2017 15:51:56 +0000 Message-ID: References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.182.35] Content-Type: multipart/alternative; boundary="_000_E0242B2A4F7E49158C73ED68AC69846Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: Magnus Westerlund , Christer Holmberg , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 15:52:02 -0000 --_000_E0242B2A4F7E49158C73ED68AC69846Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V29ya3MgZm9yIG1lLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoNCkZyb206IFJvbWFuIFNocG91bnQg PHJvbWFuQHRlbHVyaXguY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0 IDQ6MzMgUE0NClRvOiBDaGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNvbT4NCkNjOiBNYWdu dXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiwgUGF1bCBLeXpp dmF0IDxwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ+LCAibW11c2ljQGlldGYub3JnIiA8bW11c2lj QGlldGYub3JnPiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgdGFncw0KDQpJIGd1ZXNzIEJG Q1Agd2lsbCBuZWVkIFRDUC9EVExTL0JGQ1AgYWRkZWQgdG8gdGhlIGxpc3QuDQoNClNob3VsZCB3 ZSBjb3JyZWN0IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAtc2RwIGRyYWZ0IHRvIG1hdGNoIGFuZCBj aGFuZ2UgVURQL0RUTFMvU0NUUCB0byBVRFAvVExTL1NDVFA/DQoNClJlZ2FyZHMsDQoNCl9fX19f X19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gV2VkLCBKYW4gMTEsIDIwMTcgYXQgNTowNSBQ TSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tl bGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVyZSBpcyB3aGF0IHdlIGhhdmUgZm9yIEJGQ1AgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlz LTE2I3NlY3Rpb24tMTM6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgfCBWYWx1ZSAgICAgICAgfCBS ZWZlcmVuY2UgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgfCBUQ1AvQkZDUCAgICAgfCBbUkZDIFhY WFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBUQ1AvVExTL0JGQ1AgfCBbUkZDIFhYWFhd IHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBVRFAvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwN CiAgICAgICAgICAgICAgICAgICAgICAgfCBVRFAvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAg ICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KQ2hl ZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBtbXVzaWMgPG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb21hbiBTaHBvdW50 IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogV2Vk bmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDE6MDEgUE0NClRvOiBNYWdudXMgV2VzdGVybHVu ZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20+Pg0KQ2M6IFBhdWwgS3l6aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3Qu bmV0PG1haWx0bzpwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ+PiwgIm1tdXNpY0BpZXRmLm9yZzxt YWlsdG86bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGll dGYub3JnPj4NClN1YmplY3Q6IFtNTVVTSUNdIFRyYW5zcG9ydCB0YWdzDQoNCldoYXQgc2hvdWxk IHdlIHVzZSBmb3IgdGhlIG5ldyBwcm90b2NvbHMgdGhhdCB3ZSBhcmUgZGVmaW5pbmc/DQoNClNo b3VsZCBpdCBiZSBVRFAvVExTL1NDVFAgb3IgVURQL0RUTFMvU0NUUD8NClNob3VsZCBpdCBiZSBV RFAvVExTL0JGQ1Agb3IgVURQL0RUTFMvQkZDUD8NCg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21l IGNvbnNpc3RlbmN5IGhlcmUuDQoNClJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBv dW50DQoNCk9uIFdlZCwgSmFuIDExLCAyMDE3IGF0IDM6MzAgQU0sIE1hZ251cyBXZXN0ZXJsdW5k IDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KRGVuIDIwMTctMDEtMTAga2wuIDE5OjA4LCBza3JldiBS b21hbiBTaHBvdW50Og0KUC5TLiBJbiB0aGUgcXVvdGVkIHRleHQgc29tZW9uZSBtZW50aW9uZWQg IlVEUC9UTFMvUlRQL1NBVlBGIiwgc2hvdWxkIGl0DQpiZSAiVURQL0RUTFMvUlRQL1NBVlBGIj8N Cg0KTm8sIGFjdHVhbGx5IFVEUC9UTFMvUlRQL1NBVlBGIGlzIHdoYXQgaXMgcmVnaXN0ZXJlZCBm b3IgRFRMUy1TUlRQIG92ZXIgVURQIHdpdGggUlRQIFNBVlBGIHByb2ZpbGUuIFNlZSBbUkZDNTc2 NF0uIFRoZSAiVURQL0RUTFMvUlRQL1NBVlBGIiBpcyBub3QgcmVnaXN0ZXJlZC4NCg0KU28gdGhl IGFsdGVybmF0aXZlcyBmb3IgdGhlIGRlcGVuZGVuY3kgb2YgZGVmYXVsdCBjYW5kaWRhdGUgcHJv dG9jb2wgdHlwZSBpbiB5b3VyIHByb3Bvc2FsIHdvdWxkIGJlOg0KDQpVRFA6ICJVRFAvVExTL1JU UC9TQVZQRiINClRDUDogIlRDUC9EVExTL1JUUC9TQVZQRiINCg0KDQpDaGVlcnMNCg0KTWFnbnVz IFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3Jr IGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmlj c3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODc8dGVsOiUyQjQ2 JTIwMTAlMjA3MTQ4Mjg3Pg0KRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2JpbGUg KzQ2IDczIDA5NDkwNzk8dGVsOiUyQjQ2JTIwNzMlMjAwOTQ5MDc5Pg0KU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFp bHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= --_000_E0242B2A4F7E49158C73ED68AC69846Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <94ADADC846BC4F4C8FAB4E9537252EE8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0zOTM2MDQzMDE1NTE3OTQ3Mzg3Z21haWwtDQoJe21z by1zdHlsZS1uYW1lOm1fMzkzNjA0MzAxNTUxNzk0NzM4N2dtYWlsLTt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Xb3JrcyBmb3IgbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYXJsZXM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu Pg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Sb21h biBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2Vk bmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDQ6MzMgUE08YnI+DQo8Yj5UbzogPC9iPkNoYXJs ZXMgRWNrZWwgJmx0O2Vja2VsY3VAY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+TWFnbnVz IFdlc3Rlcmx1bmQgJmx0O21hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSZndDssIFBhdWwg S3l6aXZhdCAmbHQ7cGF1bC5reXppdmF0QGNvbWNhc3QubmV0Jmd0OywgJnF1b3Q7bW11c2ljQGll dGYub3JnJnF1b3Q7ICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZyAm bHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW01NVVNJQ10gVHJhbnNwb3J0IHRhZ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgQkZDUCB3aWxsIG5lZWQg VENQL0RUTFMvQkZDUCBhZGRlZCB0byB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U2hvdWxkIHdlIGNvcnJlY3QgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1z ZHAgZHJhZnQgdG8gbWF0Y2ggYW5kIGNoYW5nZSBVRFAvRFRMUy9TQ1RQIHRvIFVEUC9UTFMvU0NU UD8NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKYW4gMTEs IDIwMTcgYXQgNTowNSBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgJmx0OzxhIGhyZWY9Im1h aWx0bzplY2tlbGN1QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVja2VsY3VAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlcmUgaXMgd2hhdCB3ZSBoYXZlIGZvciBCRkNQIGlu DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1iZmNwYmlz LXJmYzQ1ODNiaXMtMTYjc2VjdGlvbi0xMyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2I3NlY3Rpb24t MTM8L2E+OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8IFZhbHVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwgUmVmZXJlbmNlJm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0t LS0tLSYjNDM7LS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUQ1AvQkZDUCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFtSRkMgWFhYWF0gfDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDt8 IFRDUC9UTFMvQkZDUCB8IFtSRkMgWFhYWF0gfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFVEUC9CRkNQ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgW1JGQyBYWFhYXSB8PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgVURQL1RMUy9CRkNQIHwgW1JGQyBYWFhYXSB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0t LS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5DaGFybGVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVm dDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbToN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si Pm1tdXNpYyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg Um9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJn ZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5X ZWRuZXNkYXksIEphbnVhcnkgMTEsIDIwMTcgYXQgMTowMSBQTTxicj4NCjxiPlRvOiA8L2I+TWFn bnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+UGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWlsdG86 cGF1bC5reXppdmF0QGNvbWNhc3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+cGF1bC5reXppdmF0QGNv bWNhc3QubmV0PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W01NVVNJQ10gVHJhbnNwb3J0IHRhZ3M8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPldoYXQgc2hvdWxkIHdlIHVzZSBmb3IgdGhlIG5ldyBwcm90b2NvbHMg dGhhdCB3ZSBhcmUgZGVmaW5pbmc/DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5TaG91bGQgaXQgYmUgVURQL1RMUy9TQ1RQIG9yIFVEUC9EVExTL1ND VFA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlNob3VsZCBpdCBiZSBVRFAvVExTL0JGQ1Agb3IgVURQL0RUTFMvQkZDUD88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGQgbGlr ZSB0byBzZWUgc29tZSBjb25zaXN0ZW5jeSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVnYXJkcywNCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5fX19fX19fX19f X19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEphbiAxMSwgMjAxNyBhdCAzOjMwIEFNLCBNYWdudXMg V2VzdGVybHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGNsYXNzPSJtMzkzNjA0 MzAxNTUxNzk0NzM4N2dtYWlsLSI+RGVuIDIwMTctMDEtMTAga2wuIDE5OjA4LCBza3JldiBSb21h biBTaHBvdW50Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QLlMuIElu IHRoZSBxdW90ZWQgdGV4dCBzb21lb25lIG1lbnRpb25lZCAmcXVvdDtVRFAvVExTL1JUUC9TQVZQ RiZxdW90Oywgc2hvdWxkIGl0PGJyPg0KYmUgJnF1b3Q7VURQL0RUTFMvUlRQL1NBVlBGJnF1b3Q7 PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YnI+DQpObywgYWN0dWFsbHkgVURQL1RMUy9SVFAvU0FWUEYgaXMgd2hhdCBpcyByZWdpc3RlcmVk IGZvciBEVExTLVNSVFAgb3ZlciBVRFAgd2l0aCBSVFAgU0FWUEYgcHJvZmlsZS4gU2VlIFtSRkM1 NzY0XS4gVGhlICZxdW90O1VEUC9EVExTL1JUUC9TQVZQRiZxdW90OyBpcyBub3QgcmVnaXN0ZXJl ZC48YnI+DQo8YnI+DQpTbyB0aGUgYWx0ZXJuYXRpdmVzIGZvciB0aGUgZGVwZW5kZW5jeSBvZiBk ZWZhdWx0IGNhbmRpZGF0ZSBwcm90b2NvbCB0eXBlIGluIHlvdXIgcHJvcG9zYWwgd291bGQgYmU6 PGJyPg0KPGJyPg0KVURQOiAmcXVvdDtVRFAvVExTL1JUUC9TQVZQRiZxdW90Ozxicj4NClRDUDog JnF1b3Q7VENQL0RUTFMvUlRQL1NBVlBGJnF1b3Q7IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCkNoZWVyczxicj4NCjxicj4NCk1hZ251 cyBXZXN0ZXJsdW5kPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClNlcnZpY2VzLCBNZWRp YSBhbmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTTxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+DQpFcmljc3NvbiBBQiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCBQaG9uZSZuYnNwOyA8YSBocmVmPSJ0 ZWw6JTJCNDYlMjAxMCUyMDcxNDgyODciIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgMTAgNzE0 ODI4NzwvYT48YnI+DQpGw6Ryw7ZnYXRhbiA2Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IE1vYmlsZSA8YSBocmVmPSJ0ZWw6JTJC NDYlMjA3MyUyMDA5NDkwNzkiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzMgMDk0OTA3OTwv YT48YnI+DQpTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IDxhIGhyZWY9Im1h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj4NCm1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E0242B2A4F7E49158C73ED68AC69846Aciscocom_-- From nobody Thu Jan 12 07:56: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 76D9912946F for ; Thu, 12 Jan 2017 07:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 OkPKMhIwSkI2 for ; Thu, 12 Jan 2017 07:56:46 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 465881293FB for ; Thu, 12 Jan 2017 07:56:46 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id s140so24939862qke.0 for ; Thu, 12 Jan 2017 07:56:46 -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=XPcWsevI28g9fExSanOrtXrzVhEUvJBKI9cN1p3kXnc=; b=G1vJpprFrjguTV5bu9Lk6GImdUzd+QMINsYCdgt0ndZ1B1VaGbZsh1ggqiKxO/8WCZ 7T/IJ8ANFjL/E4t1+qYeoSE5pFoL6P1D5IrjapqST/y2HAbBEthZm6CBy8NSWYICm671 J4e1BO2F+jm4tIoPBHTyuiy8xZZ6YkFx4WBueZXeNCN2+oUwPG0+DgnS1CiJcukfP7RZ oxzVZ2bk0fndrurOo5Fjf2hjmj6IzMwaBlxNXPMHFNYzBHNxPvdalXGR4qnP57In9epB mbnw70XBd29bBjTMMSEESeKMnBir2xIq+ZuGoX+77KKVajIEmMB7Shf+l+blIalAWKx2 KwXg== 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=XPcWsevI28g9fExSanOrtXrzVhEUvJBKI9cN1p3kXnc=; b=Uo3Lxk5oZhx+rItpyxOOK8VelMwEfWNd2igTgt1KmjPXstyuW746zKrIeqTnRL1v0q i6dWCbudzZUddxWSMqEkuDfZoUcU9K2YEZrzQrIw0XFOISYgJzMa7ZZVHbC0BcQ6Vr1o 5ivMAHAOI5Ji5DVhWT/9seE/TqkFGuYS/fnZgklFFJSfuIJ3fstdSWpL7E67jcxITNmC a/dyqxDCkF82oRBdpPxNoIz2pU2Uzg2RisLNyLn6vbl3YIg4eUgCyg8l9Y+PwrzajG/C MslDCUHkmhBFLx4pGMj9srQBAwdsy54zwFPVcYVNsLuUEU2gs/7KNYyiO9id3e3rA2gV DjkA== X-Gm-Message-State: AIkVDXJFQ3PUESkf2OAa05P+xUUPTYdfkflH/S+ePbT3BTD1GKfPrLZ/lHIdeZg/r+ZV+Q== X-Received: by 10.55.148.199 with SMTP id w190mr15314320qkd.9.1484236605214; Thu, 12 Jan 2017 07:56:45 -0800 (PST) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com. [209.85.220.182]) by smtp.gmail.com with ESMTPSA id d67sm6937424qkg.17.2017.01.12.07.56.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 07:56:44 -0800 (PST) Received: by mail-qk0-f182.google.com with SMTP id u25so24654483qki.2 for ; Thu, 12 Jan 2017 07:56:44 -0800 (PST) X-Received: by 10.233.232.202 with SMTP id a193mr13739029qkg.113.1484236604567; Thu, 12 Jan 2017 07:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Thu, 12 Jan 2017 07:56:44 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Thu, 12 Jan 2017 10:56:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=94eb2c033ce8940ac50545e7c3ae Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 15:56:48 -0000 --94eb2c033ce8940ac50545e7c3ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Magnus, Does it mean for the future protocols we should do DTLS? As in UDP/DTLS/BFCP and UDP/DTLS/SCTP? And we should consider UDP/TLS/RTP as legacy that does not follow the preferred rule. Regards, _____________ Roman Shpount On Thu, Jan 12, 2017 at 2:48 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I think one should actually use the DTLS or TLS depending on what one > requires. It one requires DTLS, then use DTLS, if is working with plain > TLS, then use TLS. The UDP/TLS/RTP/SAVPF is part of the first DTLS-SRTP > registrations that was done. As plain TLS can't work in this particular > combination due to UDP there is no actual risk for having to seperate > between TLS and DTLS. However, if one stack is TCP/FRAMING/(D)TLS/FOO the= n > there are potentially important differences if this is TLS or DTLS. > > Cheers > > Magnus > > Den 2017-01-11 kl. 22:01, skrev Roman Shpount: > >> What should we use for the new protocols that we are defining? >> >> Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP? >> Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP? >> >> I would like to see some consistency here. >> >> Regards, >> _____________ >> Roman Shpount >> >> On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund >> > >> wrote: >> >> Den 2017-01-10 kl. 19:08, skrev Roman Shpount: >> >> P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", >> should it >> be "UDP/DTLS/RTP/SAVPF"? >> >> >> No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP >> over UDP with RTP SAVPF profile. See [RFC5764]. The >> "UDP/DTLS/RTP/SAVPF" is not registered. >> >> So the alternatives for the dependency of default candidate protocol >> type in your proposal would be: >> >> UDP: "UDP/TLS/RTP/SAVPF" >> TCP: "TCP/DTLS/RTP/SAVPF" >> >> >> Cheers >> >> Magnus Westerlund >> >> ------------------------------------------------------------ >> ---------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ------------------------------------------------------------ >> ---------- >> Ericsson AB | Phone +46 10 7148287 >> >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> ------------------------------------------------------------ >> ---------- >> >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --94eb2c033ce8940ac50545e7c3ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Magnus,

Does it mean for the future pro= tocols we should do DTLS? As in=C2=A0UDP/DTLS/BFCP and UDP/DTLS/SCTP?
=

And we should consider UDP/TLS/RTP as legacy that does = not follow the preferred rule.

Regards,

_____________
Roman Shpount

On Thu, Jan 12, 2017 at 2:48 AM, Magnus West= erlund <magnus.westerlund@ericsson.com> wrote:<= br>
Hi,

I think one should actually use the DTLS or TLS depending on what one requi= res. It one requires DTLS, then use DTLS, if is working with plain TLS, the= n use TLS. The UDP/TLS/RTP/SAVPF is part of the first DTLS-SRTP registratio= ns that was done. As plain TLS can't work in this particular combinatio= n due to UDP there is no actual risk for having to seperate between TLS and= DTLS. However, if one stack is TCP/FRAMING/(D)TLS/FOO then there are poten= tially important differences if this is TLS or DTLS.

Cheers

Magnus

Den 2017-01-11 kl. 22:01, skrev Roman Shpount:
What should we use for the new protocols that we are defining?

Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP?
Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP?

I would like to see some consistency here.

Regards,
_____________
Roman Shpount

On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund
 <mag= nus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.co= m>>
wrote:

=C2=A0 =C2=A0 Den 2017-01-10 kl. 19:08, skrev Roman Shpount:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 P.S. In the quoted text someone mentioned "= ;UDP/TLS/RTP/SAVPF",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 should it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 be "UDP/DTLS/RTP/SAVPF"?


=C2=A0 =C2=A0 No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS= -SRTP
=C2=A0 =C2=A0 over UDP with RTP SAVPF profile. See [RFC5764]. The
=C2=A0 =C2=A0 "UDP/DTLS/RTP/SAVPF" is not registered.

=C2=A0 =C2=A0 So the alternatives for the dependency of default candidate p= rotocol
=C2=A0 =C2=A0 type in your proposal would be:

=C2=A0 =C2=A0 UDP: "UDP/TLS/RTP/SAVPF"
=C2=A0 =C2=A0 TCP: "TCP/DTLS/RTP/SAVPF"


=C2=A0 =C2=A0 Cheers

=C2=A0 =C2=A0 Magnus Westerlund

=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 Services, Media and Network features, Ericsson Research EAB/T= XM
=C2=A0 =C2=A0 --------------------------------------------------------= --------------
=C2=A0 =C2=A0 Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| Phone=C2=A0 +46 10 7148287
 =C2=A0 =C2=A0 <tel:%2B46%2010%207148287>
=C2=A0 =C2=A0 F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| Mobile +46 73 0949079
 =C2=A0 =C2=A0 <tel:%2B46%2073%200949079>
=C2=A0 =C2=A0 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=
=C2=A0 =C2=A0 <mailto:magnus.westerlund@ericsson.com>
=C2=A0 =C2=A0 --------------------------------------------------------= --------------




--

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----


--94eb2c033ce8940ac50545e7c3ae-- From nobody Thu Jan 12 08:09:26 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 7328C12948C for ; Thu, 12 Jan 2017 08:09:25 -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 qwWwKK3p1ycU for ; Thu, 12 Jan 2017 08:09:24 -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 B7717129481 for ; Thu, 12 Jan 2017 08:09:23 -0800 (PST) X-AuditID: c1b4fb2d-58ed898000002e13-9c-5877aa31333e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 01.96.11795.13AA7785; Thu, 12 Jan 2017 17:09:21 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.319.2; Thu, 12 Jan 2017 17:09:19 +0100 To: Roman Shpount References: From: Magnus Westerlund Message-ID: Date: Thu, 12 Jan 2017 17:09:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7lq7hqvIIg9fL1SymLn/MYvHgRy+b xYwLU5kdmD0mP57D6LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgydm6+y1Swn63i+I8JbA2M 81i7GDk5JARMJFY8WMHUxcjFISSwjlHi1IIZrBDOckaJBT82sYBUCQtIS8x7vRWsQ0RAVeLv 98lQHWcZJZp+T2UHSTALBEmcOt3JBmKzCVhI3PzRCGbzCthLNM84AtbMAtS8ZnIPM4gtKhAj 8Xb9cnaIGkGJkzOfgC3jFAiUON7/iglipoXEzPnnGSFseYnmrbPBeoUEtCUamjpYJzAKzELS PgtJyywkLQsYmVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBAbrwS2/dXcwrn7teIhRgINR iYe3wKMsQog1say4MvcQowQHs5IIb/jS8ggh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cL CaQnlqRmp6YWpBbBZJk4OKUaGAtdpqSwJD/8vaYm/8X8pnNfE44u+vbkVEzDy8K0BRJ7WMx6 bhnwrtl77UjP1Oc3pULOTn267MIrm0NypraLfz7X/1FUtaZqir7HhM+zjURfHxK7ddgy8clW v6iIQywbDZ0MPb1/W4g9mem6p/JJ9vtpDR3qO/iiQ14JB2x/86P2bYr0D6ew921KLMUZiYZa zEXFiQBO+hACUgIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 16:09:25 -0000 Den 2017-01-12 kl. 16:56, skrev Roman Shpount: > Magnus, > > Does it mean for the future protocols we should do DTLS? As > in UDP/DTLS/BFCP and UDP/DTLS/SCTP? Yes, I think so given that the protocol is DTLS and not TLS. > > And we should consider UDP/TLS/RTP as legacy that does not follow the > preferred rule. I would. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Jan 12 12:34: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 DDECE12946A for ; Thu, 12 Jan 2017 12:34:41 -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 BlUQH3V81vNN for ; Thu, 12 Jan 2017 12:34:39 -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 C6D8B129451 for ; Thu, 12 Jan 2017 12:34:38 -0800 (PST) X-AuditID: c1b4fb3a-f0bff70000002085-ad-5877e85c1567 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id DC.B6.08325.C58E7785; Thu, 12 Jan 2017 21:34:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 12 Jan 2017 21:34:36 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE4EIgYTLJ46IUOs37NybF5vwKEzxFEAgAApOYCAAQCwAIAAXbPA Date: Thu, 12 Jan 2017 20:34:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF6F650ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7lm7si/IIg2c+FptmfWGzmLr8MYvF gx+9bBYzLkxldmDxmPJ7I6vH5MdzGD2WLPnJ5HFrSkEASxSXTUpqTmZZapG+XQJXxqz2x6wF kzqZKnqm8jYwzmhi6mLk5JAQMJHo2PSKrYuRi0NIYB2jxLk5bawQzhJGiV3TtjJ3MXJwsAlY SHT/0wZpEBEIk2ibuokRpIZZoI1RYt/hf2wgCWEBFYl9LzayQBSpSqxaeIwRwnaTeDz3GTvI HBag+NYlVSBhXgFficetL9ghdv1llLj45xPYHE4BW4kPMy+A2YwCYhLfT60Bu5RZQFzi1pP5 UFcLSCzZc54ZwhaVePn4HyuErSSx9vB2Foj6fIlfa6ewQCwTlDg58wnLBEaRWUhGzUJSNgtJ 2SygU5kFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9 vNSSTYzA6Du45bfVDsaDzx0PMQpwMCrx8BZ4lEUIsSaWFVfmHmKU4GBWEuGd+6g8Qog3JbGy KrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQZGlZIjSxNzNhaWvW46 v+/y3ZDwtOR6qV9FTJc29Fw/OFNb94iG6jxeZbPPaz/IHlb74cUZ6PdZKEnYI7lcJ2962NwP 62+uZZhve+pKzyWvs8qSR/4lhep3L/1r6vkg5loB95veHSEHpj9oqt11LZhRulpAeauswkvl M1cdC5VVsma6m9ZtmS+gxFKckWioxVxUnAgA1JVs3LoCAAA= Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 20:34:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF6F650ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vdyBzdXJlIEkgZm9sbG93OiBXaGVyZSBUQ1Agd2l0aCBEVExTIGZvciBCRkNQIGRl ZmluZWQ/IERvZXNu4oCZdCBUQ1AgYmFzZWQgQkZDUCBydW4gb3ZlciBUTFM/DQoNClRoYXQgaXMg YWxzbyB3aGF0IGlzIHVzZWQgaW4gUkZDIDQ1ODMuDQoNCkFzIFJvbWFuIGhhcyBpbmRpY2F0ZWQs IFRDUC9CRkNQIGFuZCBUTFMvQkZDUCB3b27igJl0IHdvcmsgb24gSUNFLiBCdXQsIGlmIHlvdSB3 YW50IHRvIGZpeCwgZG9u4oCZdCB5b3UgdGhlbiBoYXZlIHRvIGRvIG1vcmUgdGhhbiBqdXN0IGNo YW5nZSB0aGUgbS0gcHJvdG8gdmFsdWU/IERvbuKAmXQgeW91IGhhdmUgdG8gZGVmaW5lIHVzYWdl IG9mIHRoZSBmcmFtaW5nIG1lY2hhbmlzbT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJv bTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NClNl bnQ6IDEyIEphbnVhcnkgMjAxNyAxNzo1Mg0KVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVy aXguY29tPg0KQ2M6IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20+OyBQYXVsIEt5eml2YXQgPHBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldD47IG1tdXNpY0Bp ZXRmLm9yZzsgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgdGFncw0KDQpXb3JrcyBmb3IgbWUu DQoNCkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJp eC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFy eSAxMSwgMjAxNyBhdCA0OjMzIFBNDQpUbzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5j b208bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4NCkNjOiBNYWdudXMgV2VzdGVybHVuZCA8bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20+PiwgUGF1bCBLeXppdmF0IDxwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ8bWFpbHRv OnBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldD4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVz aWNAaWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Piwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBU cmFuc3BvcnQgdGFncw0KDQpJIGd1ZXNzIEJGQ1Agd2lsbCBuZWVkIFRDUC9EVExTL0JGQ1AgYWRk ZWQgdG8gdGhlIGxpc3QuDQoNClNob3VsZCB3ZSBjb3JyZWN0IGRyYWZ0LWlldGYtbW11c2ljLXNj dHAtc2RwIGRyYWZ0IHRvIG1hdGNoIGFuZCBjaGFuZ2UgVURQL0RUTFMvU0NUUCB0byBVRFAvVExT L1NDVFA/DQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24g V2VkLCBKYW4gMTEsIDIwMTcgYXQgNTowNSBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVj a2VsY3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVyZSBp cyB3aGF0IHdlIGhhdmUgZm9yIEJGQ1AgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2I3NlY3Rpb24tMTM6DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAg ICAgICAgICAgfCBWYWx1ZSAgICAgICAgfCBSZWZlcmVuY2UgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAg ICAgfCBUQ1AvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAg fCBUQ1AvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBV RFAvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBVRFAv VExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBtbXVzaWMg PG1tdXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9t YW5AdGVsdXJpeC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDE6 MDEgUE0NClRvOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+Pg0KQ2M6IFBhdWwgS3l6 aXZhdCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0PG1haWx0bzpwYXVsLmt5eml2YXRAY29tY2Fz dC5uZXQ+PiwgIm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPiIgPG1tdXNp Y0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NClN1YmplY3Q6IFtNTVVTSUNdIFRy YW5zcG9ydCB0YWdzDQoNCldoYXQgc2hvdWxkIHdlIHVzZSBmb3IgdGhlIG5ldyBwcm90b2NvbHMg dGhhdCB3ZSBhcmUgZGVmaW5pbmc/DQoNClNob3VsZCBpdCBiZSBVRFAvVExTL1NDVFAgb3IgVURQ L0RUTFMvU0NUUD8NClNob3VsZCBpdCBiZSBVRFAvVExTL0JGQ1Agb3IgVURQL0RUTFMvQkZDUD8N Cg0KSSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNvbnNpc3RlbmN5IGhlcmUuDQoNClJlZ2FyZHMs DQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFdlZCwgSmFuIDExLCAyMDE3IGF0 IDM6MzAgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5j b208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KRGVuIDIw MTctMDEtMTAga2wuIDE5OjA4LCBza3JldiBSb21hbiBTaHBvdW50Og0KUC5TLiBJbiB0aGUgcXVv dGVkIHRleHQgc29tZW9uZSBtZW50aW9uZWQgIlVEUC9UTFMvUlRQL1NBVlBGIiwgc2hvdWxkIGl0 DQpiZSAiVURQL0RUTFMvUlRQL1NBVlBGIj8NCg0KTm8sIGFjdHVhbGx5IFVEUC9UTFMvUlRQL1NB VlBGIGlzIHdoYXQgaXMgcmVnaXN0ZXJlZCBmb3IgRFRMUy1TUlRQIG92ZXIgVURQIHdpdGggUlRQ IFNBVlBGIHByb2ZpbGUuIFNlZSBbUkZDNTc2NF0uIFRoZSAiVURQL0RUTFMvUlRQL1NBVlBGIiBp cyBub3QgcmVnaXN0ZXJlZC4NCg0KU28gdGhlIGFsdGVybmF0aXZlcyBmb3IgdGhlIGRlcGVuZGVu Y3kgb2YgZGVmYXVsdCBjYW5kaWRhdGUgcHJvdG9jb2wgdHlwZSBpbiB5b3VyIHByb3Bvc2FsIHdv dWxkIGJlOg0KDQpVRFA6ICJVRFAvVExTL1JUUC9TQVZQRiINClRDUDogIlRDUC9EVExTL1JUUC9T QVZQRiINCg0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K U2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBF QUIvVFhNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9u ZSAgKzQ2IDEwIDcxNDgyODc8dGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3Pg0KRsOkcsO2Z2F0YW4g NiAgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzk8dGVsOiUyQjQ2JTIwNzMl MjAwOTQ5MDc5Pg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMu d2VzdGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BF6F650ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0zOTM2MDQzMDE1NTE3 OTQ3Mzg3Z21haWwtDQoJe21zby1zdHlsZS1uYW1lOm1fMzkzNjA0MzAxNTUxNzk0NzM4N2dtYWls LTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcy LjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1H QiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+Tm93IHN1cmUgSSBmb2xsb3c6IFdoZXJlIFRDUCB3aXRoIERUTFMgZm9yIEJG Q1AgZGVmaW5lZD8gRG9lc27igJl0IFRDUCBiYXNlZCBCRkNQIHJ1biBvdmVyIFRMUz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYXQgaXMgYWxzbyB3aGF0IGlzIHVz ZWQgaW4gUkZDIDQ1ODMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B cyBSb21hbiBoYXMgaW5kaWNhdGVkLCBUQ1AvQkZDUCBhbmQgVExTL0JGQ1Agd29u4oCZdCB3b3Jr IG9uIElDRS4gQnV0LCBpZiB5b3Ugd2FudCB0byBmaXgsIGRvbuKAmXQgeW91IHRoZW4gaGF2ZSB0 byBkbyBtb3JlIHRoYW4ganVzdA0KIGNoYW5nZSB0aGUgbS0gcHJvdG8gdmFsdWU/IERvbuKAmXQg eW91IGhhdmUgdG8gZGVmaW5lIHVzYWdlIG9mIHRoZSBmcmFtaW5nIG1lY2hhbmlzbT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBDaGFybGVzIEVj a2VsIChlY2tlbGN1KSBbbWFpbHRvOmVja2VsY3VAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IDEyIEphbnVhcnkgMjAxNyAxNzo1Mjxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAm bHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYWdudXMgV2VzdGVybHVu ZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0OzsgUGF1bCBLeXppdmF0ICZs dDtwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQmZ3Q7OyBtbXVzaWNAaWV0Zi5vcmc7IENocmlzdGVy IEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgdGFnczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Xb3JrcyBm b3IgbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoYXJsZXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dDttYXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Sb21hbiBTaHBvdW50ICZsdDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cm9tYW5AdGVsdXJpeC5j b208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPldlZG5lc2RheSwgSmFudWFyeSAxMSwgMjAxNyBhdCA0OjMzIFBNPGJyPg0KPGI+VG86IDwv Yj5DaGFybGVzIEVja2VsICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28u Y29tIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+ZWNrZWxjdUBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5NYWdudXMgV2VzdGVybHVuZCAmbHQ7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7LA0KIFBhdWwgS3l6aXZhdCAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5wYXVsLmt5 eml2YXRAY29tY2FzdC5uZXQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 LCAmcXVvdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZx dW90Ow0KICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDssIENocmlzdGVyIEhvbG1iZXJnICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtNTVVTSUNdIFRyYW5zcG9ydCB0YWdzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIEJGQ1Agd2lsbCBu ZWVkIFRDUC9EVExTL0JGQ1AgYWRkZWQgdG8gdGhlIGxpc3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5TaG91bGQgd2UgY29ycmVjdCBkcmFmdC1pZXRmLW1tdXNpYy1zY3RwLXNk cCBkcmFmdCB0byBtYXRjaCBhbmQgY2hhbmdlIFVEUC9EVExTL1NDVFAgdG8gVURQL1RMUy9TQ1RQ Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEphbiAxMSwgMjAxNyBhdCA1OjA1IFBN LCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzplY2tl bGN1QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5lY2tlbGN1 QGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhlcmUgaXMgd2hhdCB3ZSBoYXZlIGZvciBCRkNQIGluDQo8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgz YmlzLTE2I3NlY3Rpb24tMTMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2 I3NlY3Rpb24tMTM8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj46PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8IFZhbHVlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwgUmVmZXJlbmNlJm5ic3A7IHw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLSYjNDM7LS0t LS0tLS0tLS0tJiM0Mzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCBUQ1AvQkZDUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFtSRkMg WFhYWF0gfDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDt8IFRDUC9UTFMvQkZDUCB8IFtSRkMgWFhYWF0gfDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFVEUC9CRkNQJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgW1JGQyBYWFhYXSB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVURQL1RMUy9CRkNQIHwgW1JGQyBYWFhY XSB8PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hh cmxlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5tbXVzaWMgJmx0Ozwv c3Bhbj48YSBocmVmPSJtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7DQogb24gYmVoYWxmIG9mIFJvbWFuIFNocG91bnQgJmx0 Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+cm9tYW5AdGVsdXJpeC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgSmFudWFyeSAxMSwg MjAxNyBhdCAxOjAxIFBNPGJyPg0KPGI+VG86IDwvYj5NYWdudXMgV2VzdGVybHVuZCAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+UGF1 bCBLeXppdmF0ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBhdWwua3l6aXZhdEBjb21jYXN0 Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5wYXVsLmt5eml2YXRAY29tY2FzdC5u ZXQ8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7LA0KICZxdW90Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZxdW90OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bTU1VU0lDXSBUcmFu c3BvcnQgdGFnczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IHNob3Vs ZCB3ZSB1c2UgZm9yIHRoZSBuZXcgcHJvdG9jb2xzIHRoYXQgd2UgYXJlIGRlZmluaW5nPw0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNob3VsZCBpdCBiZSBV RFAvVExTL1NDVFAgb3IgVURQL0RUTFMvU0NUUD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5TaG91 bGQgaXQgYmUgVURQL1RMUy9CRkNQIG9yIFVEUC9EVExTL0JGQ1A/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBsaWtlIHRvIHNlZSBz b21lIGNvbnNpc3RlbmN5IGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcywNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi Pl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEphbiAxMSwgMjAxNyBhdCAzOjMwIEFNLCBN YWdudXMgV2VzdGVybHVuZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+bWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFz cz0ibTM5MzYwNDMwMTU1MTc5NDczODdnbWFpbC0iPjxzcGFuIGxhbmc9IkVOLVVTIj5EZW4gMjAx Ny0wMS0xMCBrbC4gMTk6MDgsIHNrcmV2IFJvbWFuIFNocG91bnQ6PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5QLlMuIEluIHRoZSBxdW90ZWQgdGV4dCBzb21lb25lIG1lbnRpb25l ZCAmcXVvdDtVRFAvVExTL1JUUC9TQVZQRiZxdW90Oywgc2hvdWxkIGl0PGJyPg0KYmUgJnF1b3Q7 VURQL0RUTFMvUlRQL1NBVlBGJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCk5v LCBhY3R1YWxseSBVRFAvVExTL1JUUC9TQVZQRiBpcyB3aGF0IGlzIHJlZ2lzdGVyZWQgZm9yIERU TFMtU1JUUCBvdmVyIFVEUCB3aXRoIFJUUCBTQVZQRiBwcm9maWxlLiBTZWUgW1JGQzU3NjRdLiBU aGUgJnF1b3Q7VURQL0RUTFMvUlRQL1NBVlBGJnF1b3Q7IGlzIG5vdCByZWdpc3RlcmVkLjxicj4N Cjxicj4NClNvIHRoZSBhbHRlcm5hdGl2ZXMgZm9yIHRoZSBkZXBlbmRlbmN5IG9mIGRlZmF1bHQg Y2FuZGlkYXRlIHByb3RvY29sIHR5cGUgaW4geW91ciBwcm9wb3NhbCB3b3VsZCBiZTo8YnI+DQo8 YnI+DQpVRFA6ICZxdW90O1VEUC9UTFMvUlRQL1NBVlBGJnF1b3Q7PGJyPg0KVENQOiAmcXVvdDtU Q1AvRFRMUy9SVFAvU0FWUEYmcXVvdDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpDaGVl cnM8YnI+DQo8YnI+DQpNYWdudXMgV2VzdGVybHVuZDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2Vh cmNoIEVBQi9UWE08YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRXJpY3Nzb24gQUImbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgUGhv bmUmbmJzcDsgPC9zcGFuPjxhIGhyZWY9InRlbDolMkI0NiUyMDEwJTIwNzE0ODI4NyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj4mIzQzOzQ2IDEwIDcxNDgyODc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpGw6Ryw7ZnYXRhbiA2Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IE1vYmlsZSA8L3Nw YW4+PGEgaHJlZj0idGVsOiUyQjQ2JTIwNzMlMjAwOTQ5MDc5IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gbGFuZz0iRU4tVVMiPiYjNDM7NDYgNzMgMDk0OTA3OTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogPC9zcGFu PjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4BF6F650ESESSMB209erics_-- From nobody Thu Jan 12 12:46:07 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 1FC0712944C for ; Thu, 12 Jan 2017 12:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 PrE2sjDx5Wen for ; Thu, 12 Jan 2017 12:46:03 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 38D48129483 for ; Thu, 12 Jan 2017 12:46:03 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k15so29694910qtg.3 for ; Thu, 12 Jan 2017 12:46:03 -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=HnOjHPQCOqoOnpSXtvWNf7mNMtSM+EF3biobibvW2KY=; b=O1yzM6WQ2RUWLJuVDsfRATES+H5CmcqedXrYqS31yr/p77+eooOY3DAiCB1ynQm7us YW9+YMGEtp9E2lWqpk/Y2HXdfkN9XIbuIGifGnjPbZBOmX/lLuB/4m7VYFr5k4e0KKXW 2b7IFhf9b8jbk5fZOCqr68/Ce6cqJxB/E3mNvAv+n9JWVaZ/otHoM8dOQQvJqROa/d6i l+dttyjjundCuBdAHq7ohbRylSRkaJjDS/WbYg9QNdAjBJ8f+LDyFYZyPQkVFADF0O2j NB/uqnz2I8xwc+oImsrT1rVP5lxbQXV0UjyBm2eSLllNqx2Utu8wvHD8SVm/76IQ6q0E 24OQ== 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=HnOjHPQCOqoOnpSXtvWNf7mNMtSM+EF3biobibvW2KY=; b=EH/DgSQg940ZIuXXK1Q+9/7K67Mx2xjFoRJEmQyAbrYBxAuUDnYG8QTDgoKoRg645K 4+EOrqMx8m0NSZpnBzZsSXB7EPQp6kny16217kNTbjm7Y/GW0CPIy+JBhNMlRwibsxBn kmJu1di2GYZ9eLZZkcy4TVH638+QUhdCij9mTRx1axsiw/td+Jp/vPC+3BgK08YqAd27 HKfrJRA0shvyToPLacUfpffknYuWhqENqeF7dg9+XO6/Ep2TQd3srpTQinaC6OGqOL7z TgdcNLvYZHQUPFme0/tavC1QL3FBIDFse0U2091wrK/W57dVRtP6easDTeLg/oZvoKex Na0A== X-Gm-Message-State: AIkVDXJMY7RXBCU5/+C3BwV5+I+HhxryHIGywqO9WqvFsbCYONkb/LmaYP7qTVKwNXCsZQ== X-Received: by 10.200.48.65 with SMTP id g1mr14244406qte.94.1484253962120; Thu, 12 Jan 2017 12:46:02 -0800 (PST) Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com. [209.85.220.179]) by smtp.gmail.com with ESMTPSA id i1sm7381681qte.32.2017.01.12.12.46.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 12:46:01 -0800 (PST) Received: by mail-qk0-f179.google.com with SMTP id a20so33955884qkc.1 for ; Thu, 12 Jan 2017 12:46:01 -0800 (PST) X-Received: by 10.55.142.1 with SMTP id q1mr14418336qkd.225.1484253961285; Thu, 12 Jan 2017 12:46:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Thu, 12 Jan 2017 12:46:00 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 12 Jan 2017 15:46:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c0830de1e957f0545ebce2a Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 20:46:07 -0000 --94eb2c0830de1e957f0545ebce2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Christer, Definition for TCP/DTLS/BFCP needs to be added in draft-ietf-bfcpbis-rfc4583bis. This is BFCP over DTLS over TCP with RFC 4571 framing. UDP/DTLS/BFCP together with TCP/DTLS/BFCP will over ICE based on the mechanisms defined in draft-ietf-mmusic-dtls-sdp. Only UDP/DTLS/BFCP in combination with TCP/DTLS/BFCP will support ICE. TCP/BFCP and TLS/BFCP will not support ICE and will have two run with at least one end point on the public IP. I hope it makes sense. Regards, _____________ Roman Shpount On Thu, Jan 12, 2017 at 3:34 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Now sure I follow: Where TCP with DTLS for BFCP defined? Doesn=E2=80=99t = TCP based > BFCP run over TLS? > > > > That is also what is used in RFC 4583. > > > > As Roman has indicated, TCP/BFCP and TLS/BFCP won=E2=80=99t work on ICE. = But, if > you want to fix, don=E2=80=99t you then have to do more than just change = the m- > proto value? Don=E2=80=99t you have to define usage of the framing mechan= ism? > > > > Regards, > > > > Christer > > > > *From:* Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > *Sent:* 12 January 2017 17:52 > *To:* Roman Shpount > *Cc:* Magnus Westerlund ; Paul Kyzivat < > paul.kyzivat@comcast.net>; mmusic@ietf.org; Christer Holmberg < > christer.holmberg@ericsson.com> > > *Subject:* Re: [MMUSIC] Transport tags > > > > Works for me. > > > > Cheers, > > Charles > > > > *From: *Roman Shpount > *Date: *Wednesday, January 11, 2017 at 4:33 PM > *To: *Charles Eckel > *Cc: *Magnus Westerlund , Paul Kyzivat < > paul.kyzivat@comcast.net>, "mmusic@ietf.org" , Christer > Holmberg > *Subject: *Re: [MMUSIC] Transport tags > > > > I guess BFCP will need TCP/DTLS/BFCP added to the list. > > > > Should we correct draft-ietf-mmusic-sctp-sdp draft to match and change > UDP/DTLS/SCTP to UDP/TLS/SCTP? > > > > Regards, > > > _____________ > Roman Shpount > > > > On Wed, Jan 11, 2017 at 5:05 PM, Charles Eckel (eckelcu) < > eckelcu@cisco.com> wrote: > > Here is what we have for BFCP in https://tools.ietf.org/html/ > draft-ietf-bfcpbis-rfc4583bis-16#section-13: > > > > +--------------+------------+ > > | Value | Reference | > > +--------------+------------+ > > | TCP/BFCP | [RFC XXXX] | > > | TCP/TLS/BFCP | [RFC XXXX] | > > | UDP/BFCP | [RFC XXXX] | > > | UDP/TLS/BFCP | [RFC XXXX] | > > +--------------+------------+ > > > > Cheers, > > Charles > > > > *From: *mmusic on behalf of Roman Shpount < > roman@telurix.com> > *Date: *Wednesday, January 11, 2017 at 1:01 PM > *To: *Magnus Westerlund > *Cc: *Paul Kyzivat , "mmusic@ietf.org" < > mmusic@ietf.org> > *Subject: *[MMUSIC] Transport tags > > > > What should we use for the new protocols that we are defining? > > > > Should it be UDP/TLS/SCTP or UDP/DTLS/SCTP? > > Should it be UDP/TLS/BFCP or UDP/DTLS/BFCP? > > > > I would like to see some consistency here. > > > > Regards, > > _____________ > Roman Shpount > > > > On Wed, Jan 11, 2017 at 3:30 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > Den 2017-01-10 kl. 19:08, skrev Roman Shpount: > > P.S. In the quoted text someone mentioned "UDP/TLS/RTP/SAVPF", should it > be "UDP/DTLS/RTP/SAVPF"? > > > No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over > UDP with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" is no= t > registered. > > So the alternatives for the dependency of default candidate protocol type > in your proposal would be: > > UDP: "UDP/TLS/RTP/SAVPF" > TCP: "TCP/DTLS/RTP/SAVPF" > > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > > > > --94eb2c0830de1e957f0545ebce2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,

Definition for TCP/DTLS/BF= CP needs to be added in=C2=A0draft-ietf-bfcpbis-rfc4583bis.

<= /div>
This is BFCP over DTLS over TCP with RFC 4571 framing. UDP/DTLS/B= FCP together with TCP/DTLS/BFCP=C2=A0will over ICE based on the mechanisms = defined in draft-ietf-mmusic-dtls-sdp. Only UDP/DTLS/BFCP in combination wi= th TCP/DTLS/BFCP will support ICE. TCP/BFCP and TLS/BFCP will not support I= CE and will have two run with at least one end point on the public IP.

I hope it makes sense.

Regard= s,

_____________
Ro= man Shpount

On Thu, Jan 12, 2017 at 3:34 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

Now sure I follow: Where TCP with DTL= S for BFCP defined? Doesn=E2=80=99t TCP based BFCP run over TLS?<= /u>

=C2=A0

That is also what is used in RFC 4583= .

=C2=A0

As Roman has indicated, TCP/BFCP and = TLS/BFCP won=E2=80=99t work on ICE. But, if you want to fix, don=E2=80=99t = you then have to do more than just change the m- proto value? Don=E2=80=99t you have to define usage of the f= raming mechanism?

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: = Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 12 January 2017 17:52
To: Roman Shpount <roman@telurix.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>; Paul= Kyzivat <= paul.kyzivat@comcast.net>; mmusic@ietf.org; Christer Holmberg <christer.holmberg@ericsson.= com>


Subject: Re: [MMUSIC] Transport tags

=C2=A0

Works for me.

=C2=A0

Cheers,

Charles

=C2=A0

From: Roman Shpount <roman@telurix.com>
Date: Wednesday, January 11, 2017 at 4:33 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com<= /a>>, Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ietf.org= " <mmusic@ietf= .org>, Christer Holmberg <christer.holmberg@eric= sson.com>
Subject: Re: [MMUSIC] Transport tags

=C2=A0

I guess BFCP will need TCP/DTLS= /BFCP added to the list.

=C2=A0

Should we correct draft-ietf-mm= usic-sctp-sdp draft to match and change UDP/DTLS/SCTP to UDP/TLS/SCTP?

=C2=A0

Regards,


_____________
Roman Shpount

=C2=A0

On Wed, Jan 11, 2017 at 5:05 PM= , Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Here is what we have for BFCP i= n https://tools.ietf.o= rg/html/draft-ietf-bfcpbis-rfc4583bis-16#section-13:

=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Referen= ce=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=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 | TCP/BFCP=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC XXXX] |

=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=C2=A0=C2= =A0=C2=A0 =C2=A0| TCP/TLS/BFCP | [RFC XXXX] |

=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=C2=A0=C2= =A0=C2=A0=C2=A0 | UDP/BFCP=C2=A0=C2=A0=C2=A0=C2=A0 | [RFC XXXX] |

=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=C2=A0=C2= =A0=C2=A0=C2=A0 | UDP/TLS/BFCP | [RFC XXXX] |

=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=C2=A0=C2= =A0=C2=A0=C2=A0 +--------------+------------+

=C2=A0

Cheers,

Charles

=C2=A0

From: mmusic <mmusic-bounces@ietf.org> on behalf of Roman Shpount <roman@telurix.com>
Date: Wednesday, January 11, 2017 at 1:01 PM
To: Magnus Westerlund <magnus.westerlund@ericsson.com<= /a>>
Cc: Paul Kyzivat <paul.kyzivat@comcast.net>, "mmusic@ie= tf.org" <mmusic@ietf.org>
Subject: [MMUSIC] Transport tags<= u>

=C2=A0

What should we use for the new = protocols that we are defining?

=C2=A0

Should it be UDP/TLS/SCTP or UD= P/DTLS/SCTP?

Should it be UDP/TLS/BFCP or UD= P/DTLS/BFCP?

=C2=A0

I would like to see some consis= tency here.

=C2=A0

Regards,

_____________
Roman Shpount

=C2=A0

On Wed, Jan 11, 2017 at 3:30 AM= , Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Den 2017-01= -10 kl. 19:08, skrev Roman Shpount:

P.S. In the quoted text someone= mentioned "UDP/TLS/RTP/SAVPF", should it
be "UDP/DTLS/RTP/SAVPF"?


No, actually UDP/TLS/RTP/SAVPF is what is registered for DTLS-SRTP over UDP= with RTP SAVPF profile. See [RFC5764]. The "UDP/DTLS/RTP/SAVPF" = is not registered.

So the alternatives for the dependency of default candidate protocol type i= n your proposal would be:

UDP: "UDP/TLS/RTP/SAVPF"
TCP: "TCP/DTLS/RTP/SAVPF"

=

Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 <= span lang=3D"EN-US">+46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlun= d@ericsson.com
-----------------------------------------------------------------= -----

=C2=A0

=C2=A0


--94eb2c0830de1e957f0545ebce2a-- From nobody Thu Jan 12 13:09: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 CCF731294B7 for ; Thu, 12 Jan 2017 13:09:05 -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 03RIrkm03dKh for ; Thu, 12 Jan 2017 13:09:03 -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 CB223128B37 for ; Thu, 12 Jan 2017 13:09:02 -0800 (PST) X-AuditID: c1b4fb25-00bff700000042ea-73-5877f0693883 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id A1.03.17130.960F7785; Thu, 12 Jan 2017 22:09:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Thu, 12 Jan 2017 22:08:57 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE4EIgYTLJ46IUOs37NybF5vwKEzxFEAgAApOYCAAQCwAIAAXbPA///0dgCAABVIgA== Date: Thu, 12 Jan 2017 21:08:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF6F72CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7n27uh/IIg33n2S02zfrCZjF1+WMW iwc/etksZlyYyuzA4jHl90ZWj8mP5zB6LFnyk8nj1pSCAJYoLpuU1JzMstQifbsEroxzW++z Fty4xFRxf8sHpgbGNyeZuhg5OSQETCS2LV/K2sXIxSEksI5RYtLiuewQzhJGiZu9i4AyHBxs AhYS3f+0QRpEBFQl/n6fzARSwyywnVHi97uDLCAJYQEViX0vNrLAFK1aeIwRwg6TmHLnDhuI zQIUPzL5BthmXgFfic2Xj0Mt62CW2PehhxkkwSkQKPF90xFWEJtRQEzi+6k1YA3MAuISt57M hzpbQGLJnvPMELaoxMvH/1ghbCWJtYe3s0DU50s823GKHWKZoMTJmU9YJjCKzEIyahaSsllI ymYB/cwsoCmxfpc+RImixJTuh+wQtoZE65y57MjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp 5aWWbGIExuDBLb9VdzBefuN4iFGAg1GJh7fAoyxCiDWxrLgy9xCjBAezkggvy5vyCCHelMTK qtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoYfffK35xq+n79h7Ql 2odk86R0e41Z2r7zn/th73e03ufp+Xt9du2dJ1p3vJHpPrbTaNe75DnHX5ysOfHnPU/SOoEH al7md73tNq975WfmOe1yjfbpY5O/BQvPZLHe1182bZOszKKyzx1ZMq94r3D+EjN6celS940m s3+Hjhp0xvvxq4ix7nN6o8RSnJFoqMVcVJwIAAF3ndO9AgAA Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 21:09:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF6F72CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5EZWZpbml0aW9uIGZvciBUQ1AvRFRMUy9CRkNQIG5lZWRzIHRvIGJlIGFkZGVkIGlu IGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLg0KPg0KPlRoaXMgaXMgQkZDUCBvdmVyIERU TFMgb3ZlciBUQ1Agd2l0aCBSRkMgNDU3MSBmcmFtaW5nLg0KDQpDb3JyZWN0Lg0KDQo+VURQL0RU TFMvQkZDUCB0b2dldGhlciB3aXRoIFRDUC9EVExTL0JGQ1Agd2lsbCBvdmVyIElDRSBiYXNlZCBv biB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLiBP bmx5IFVEUC9EVExTL0JGQ1AgPmluIGNvbWJpbmF0aW9uIHdpdGggVENQL0RUTFMvQkZDUCB3aWxs IHN1cHBvcnQgSUNFLiBUQ1AvQkZDUCBhbmQgVExTL0JGQ1Agd2lsbCBub3Qgc3VwcG9ydCBJQ0Ug YW5kIHdpbGwgaGF2ZSB0d28gcnVuIHdpdGggYXQgbGVhc3Qgb25lIGVuZCBwb2ludCA+b24gdGhl IHB1YmxpYyBJUC4NCg0KSSBhZ3JlZSB3aXRoIGFsbCBvZiB0aGF0LCBidXQgdGhhdCB3YXMgbm90 IG15IGlzc3VlIDopDQoNCk15IGlzc3VlIHdhcyB0aGF0IGl0IGlzIG5vdCBlbm91Z2ggdG8gc2lt cGx5IGNoYW5nZSB0aGUgcHJvdG8gdmFsdWUgaW4gNDU4M2Jpcy4gWW91IGFsc28gbmVlZCB0byBk ZWZpbmUgdGhlIHVzYWdlIG9mIHRoZSBSRkMgNDU3MSBmcmFtaW5nIG1lY2hhbmlzbS4NCg0KQW5k LCBpZiB0aGF0IGlzIG5vdCBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggUkZDIDQ1ODMgKHdoaWNo IGRvZXMgTk9UIHVzZSA0NTcxIGZyYW1pbmcpLCB5b3UgbmVlZCB0byBhZGQgc29tZSB0ZXh0IGFi b3V0IHRoYXQgYWxzby4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpfX19fX19fX19fX19f DQpSb21hbiBTaHBvdW50DQoNCk9uIFRodSwgSmFuIDEyLCAyMDE3IGF0IDM6MzQgUE0sIENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCk5vdyBzdXJlIEkgZm9s bG93OiBXaGVyZSBUQ1Agd2l0aCBEVExTIGZvciBCRkNQIGRlZmluZWQ/IERvZXNu4oCZdCBUQ1Ag YmFzZWQgQkZDUCBydW4gb3ZlciBUTFM/DQoNClRoYXQgaXMgYWxzbyB3aGF0IGlzIHVzZWQgaW4g UkZDIDQ1ODMuDQoNCkFzIFJvbWFuIGhhcyBpbmRpY2F0ZWQsIFRDUC9CRkNQIGFuZCBUTFMvQkZD UCB3b27igJl0IHdvcmsgb24gSUNFLiBCdXQsIGlmIHlvdSB3YW50IHRvIGZpeCwgZG9u4oCZdCB5 b3UgdGhlbiBoYXZlIHRvIGRvIG1vcmUgdGhhbiBqdXN0IGNoYW5nZSB0aGUgbS0gcHJvdG8gdmFs dWU/IERvbuKAmXQgeW91IGhhdmUgdG8gZGVmaW5lIHVzYWdlIG9mIHRoZSBmcmFtaW5nIG1lY2hh bmlzbT8NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNr ZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbTxtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20+ XQ0KU2VudDogMTIgSmFudWFyeSAyMDE3IDE3OjUyDQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5A dGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkNjOiBNYWdudXMgV2VzdGVy bHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20+PjsgUGF1bCBLeXppdmF0IDxwYXVsLmt5eml2YXRAY29tY2FzdC5u ZXQ8bWFpbHRvOnBhdWwua3l6aXZhdEBjb21jYXN0Lm5ldD4+OyBtbXVzaWNAaWV0Zi5vcmc8bWFp bHRvOm1tdXNpY0BpZXRmLm9yZz47IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQoN ClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgdGFncw0KDQpXb3JrcyBmb3IgbWUuDQoN CkNoZWVycywNCkNoYXJsZXMNCg0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5j b208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAx MSwgMjAxNyBhdCA0OjMzIFBNDQpUbzogQ2hhcmxlcyBFY2tlbCA8ZWNrZWxjdUBjaXNjby5jb208 bWFpbHRvOmVja2VsY3VAY2lzY28uY29tPj4NCkNjOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20+PiwgUGF1bCBLeXppdmF0IDxwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQ8bWFpbHRvOnBh dWwua3l6aXZhdEBjb21jYXN0Lm5ldD4+LCAibW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNA aWV0Zi5vcmc+IiA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+PiwgQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBUcmFu c3BvcnQgdGFncw0KDQpJIGd1ZXNzIEJGQ1Agd2lsbCBuZWVkIFRDUC9EVExTL0JGQ1AgYWRkZWQg dG8gdGhlIGxpc3QuDQoNClNob3VsZCB3ZSBjb3JyZWN0IGRyYWZ0LWlldGYtbW11c2ljLXNjdHAt c2RwIGRyYWZ0IHRvIG1hdGNoIGFuZCBjaGFuZ2UgVURQL0RUTFMvU0NUUCB0byBVRFAvVExTL1ND VFA/DQoNClJlZ2FyZHMsDQoNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KT24gV2Vk LCBKYW4gMTEsIDIwMTcgYXQgNTowNSBQTSwgQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgPGVja2Vs Y3VAY2lzY28uY29tPG1haWx0bzplY2tlbGN1QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGVyZSBpcyB3 aGF0IHdlIGhhdmUgZm9yIEJGQ1AgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2I3NlY3Rpb24tMTM6DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAg ICAgICAgfCBWYWx1ZSAgICAgICAgfCBSZWZlcmVuY2UgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAg fCBUQ1AvQkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBU Q1AvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBVRFAv QkZDUCAgICAgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgfCBVRFAvVExT L0JGQ1AgfCBbUkZDIFhYWFhdIHwNCiAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLSsNCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBtbXVzaWMgPG1t dXNpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4+IG9u IGJlaGFsZiBvZiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86cm9tYW5A dGVsdXJpeC5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDE6MDEg UE0NClRvOiBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29t PG1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+Pg0KQ2M6IFBhdWwgS3l6aXZh dCA8cGF1bC5reXppdmF0QGNvbWNhc3QubmV0PG1haWx0bzpwYXVsLmt5eml2YXRAY29tY2FzdC5u ZXQ+PiwgIm1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPiIgPG1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NClN1YmplY3Q6IFtNTVVTSUNdIFRyYW5z cG9ydCB0YWdzDQoNCldoYXQgc2hvdWxkIHdlIHVzZSBmb3IgdGhlIG5ldyBwcm90b2NvbHMgdGhh dCB3ZSBhcmUgZGVmaW5pbmc/DQoNClNob3VsZCBpdCBiZSBVRFAvVExTL1NDVFAgb3IgVURQL0RU TFMvU0NUUD8NClNob3VsZCBpdCBiZSBVRFAvVExTL0JGQ1Agb3IgVURQL0RUTFMvQkZDUD8NCg0K SSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNvbnNpc3RlbmN5IGhlcmUuDQoNClJlZ2FyZHMsDQpf X19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCk9uIFdlZCwgSmFuIDExLCAyMDE3IGF0IDM6 MzAgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208 bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KRGVuIDIwMTct MDEtMTAga2wuIDE5OjA4LCBza3JldiBSb21hbiBTaHBvdW50Og0KUC5TLiBJbiB0aGUgcXVvdGVk IHRleHQgc29tZW9uZSBtZW50aW9uZWQgIlVEUC9UTFMvUlRQL1NBVlBGIiwgc2hvdWxkIGl0DQpi ZSAiVURQL0RUTFMvUlRQL1NBVlBGIj8NCg0KTm8sIGFjdHVhbGx5IFVEUC9UTFMvUlRQL1NBVlBG IGlzIHdoYXQgaXMgcmVnaXN0ZXJlZCBmb3IgRFRMUy1TUlRQIG92ZXIgVURQIHdpdGggUlRQIFNB VlBGIHByb2ZpbGUuIFNlZSBbUkZDNTc2NF0uIFRoZSAiVURQL0RUTFMvUlRQL1NBVlBGIiBpcyBu b3QgcmVnaXN0ZXJlZC4NCg0KU28gdGhlIGFsdGVybmF0aXZlcyBmb3IgdGhlIGRlcGVuZGVuY3kg b2YgZGVmYXVsdCBjYW5kaWRhdGUgcHJvdG9jb2wgdHlwZSBpbiB5b3VyIHByb3Bvc2FsIHdvdWxk IGJlOg0KDQpVRFA6ICJVRFAvVExTL1JUUC9TQVZQRiINClRDUDogIlRDUC9EVExTL1JUUC9TQVZQ RiINCg0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2Vy dmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIv VFhNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAg KzQ2IDEwIDcxNDgyODc8dGVsOiUyQjQ2JTIwMTAlMjA3MTQ4Mjg3Pg0KRsOkcsO2Z2F0YW4gNiAg ICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzk8dGVsOiUyQjQ2JTIwNzMlMjAw OTQ5MDc5Pg0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb208bWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4BF6F72CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u bTkyMDkwMzczMzc4MjY1MTQ5ODhtMzkzNjA0MzAxNTUxNzk0NzM4N2dtYWlsLQ0KCXttc28tc3R5 bGUtbmFtZTptXzkyMDkwMzczMzc4MjY1MTQ5ODhtMzkzNjA0MzAxNTUxNzk0NzM4N2dtYWlsLTt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDtEZWZpbml0aW9uIGZvciBUQ1AvRFRMUy9CRkNQIG5lZWRzIHRvIGJlIGFkZGVkIGluJm5i c3A7ZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VGhpcyBpcyBCRkNQIG92ZXIg RFRMUyBvdmVyIFRDUCB3aXRoIFJGQyA0NTcxIGZyYW1pbmcuIDxvOnA+DQo8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q29ycmVjdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDtVRFAvRFRMUy9CRkNQIHRvZ2V0aGVyIHdpdGggVENQL0RUTFMvQkZDUCZuYnNwO3dpbGwgb3Zl ciBJQ0UgYmFzZWQgb24gdGhlIG1lY2hhbmlzbXMgZGVmaW5lZCBpbiBkcmFmdC1pZXRmLW1tdXNp Yy1kdGxzLXNkcC4gT25seSBVRFAvRFRMUy9CRkNQICZndDtpbiBjb21iaW5hdGlvbiB3aXRoIFRD UC9EVExTL0JGQ1Agd2lsbCBzdXBwb3J0IElDRS4gVENQL0JGQ1AgYW5kIFRMUy9CRkNQIHdpbGwg bm90IHN1cHBvcnQgSUNFIGFuZA0KIHdpbGwgaGF2ZSB0d28gcnVuIHdpdGggYXQgbGVhc3Qgb25l IGVuZCBwb2ludCAmZ3Q7b24gdGhlIHB1YmxpYyBJUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHdpdGggYWxsIG9mIHRoYXQs IGJ1dCB0aGF0IHdhcyBub3QgbXkgaXNzdWUgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgaXNzdWUgd2Fz IHRoYXQgaXQgaXMgbm90IGVub3VnaCB0byBzaW1wbHkgY2hhbmdlIHRoZSBwcm90byB2YWx1ZSBp biA0NTgzYmlzLiBZb3UgYWxzbyBuZWVkIHRvIGRlZmluZSB0aGUgdXNhZ2Ugb2YgdGhlIFJGQyA0 NTcxIGZyYW1pbmcgbWVjaGFuaXNtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQsIGlmIHRoYXQgaXMgbm90 IGJhY2t3YXJkIGNvbXBhdGlibGUgd2l0aCBSRkMgNDU4MyAod2hpY2ggZG9lcyBOT1QgdXNlIDQ1 NzEgZnJhbWluZyksIHlvdSBuZWVkIHRvIGFkZCBzb21lIHRleHQgYWJvdXQgdGhhdCBhbHNvLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEph biAxMiwgMjAxNyBhdCAzOjM0IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Tm93IHN1cmUgSSBmb2xsb3c6IFdoZXJlIFRDUCB3aXRoIERUTFMg Zm9yIEJGQ1AgZGVmaW5lZD8gRG9lc27igJl0IFRDUCBiYXNlZCBCRkNQIHJ1biBvdmVyIFRMUz88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF0IGlzIGFs c28gd2hhdCBpcyB1c2VkIGluIFJGQyA0NTgzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkFzIFJvbWFuIGhhcyBpbmRpY2F0ZWQsIFRDUC9CRkNQIGFuZCBU TFMvQkZDUCB3b27igJl0IHdvcmsgb24gSUNFLiBCdXQsIGlmIHlvdSB3YW50IHRvIGZpeCwgZG9u 4oCZdCB5b3UNCiB0aGVuIGhhdmUgdG8gZG8gbW9yZSB0aGFuIGp1c3QgY2hhbmdlIHRoZSBtLSBw cm90byB2YWx1ZT8gRG9u4oCZdCB5b3UgaGF2ZSB0byBkZWZpbmUgdXNhZ2Ugb2YgdGhlIGZyYW1p bmcgbWVjaGFuaXNtPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxhIG5hbWU9Im1fOTIwOTAzNzMzNzgyNjUxNDk4OF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBDaGFybGVzDQogRWNrZWwgKGVja2VsY3UpIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmVja2VsY3VAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWNrZWxj dUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDEyIEphbnVhcnkgMjAxNyAxNzo1 Mjxicj4NCjxiPlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFu QHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb208L2E+Jmd0OzsgUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJtYWls dG86cGF1bC5reXppdmF0QGNvbWNhc3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+cGF1bC5reXppdmF0 QGNvbWNhc3QubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPjsgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBUcmFuc3BvcnQgdGFnczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5Xb3JrcyBmb3IgbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkNoYXJsZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Um9tYW4gU2hwb3VudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1 cml4LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5yb21hbkB0ZWx1cml4LmNvbTwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ V2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDQ6MzMgUE08YnI+DQo8Yj5UbzogPC9iPkNo YXJsZXMgRWNrZWwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNrZWxjdUBjaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZWNrZWxjdUBjaXNjby5jb208L3NwYW4+PC9h PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5NYWdudXMgV2Vz dGVybHVuZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0OywNCiBQ YXVsIEt5eml2YXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGF1bC5reXppdmF0QGNvbWNh c3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnBhdWwua3l6aXZhdEBjb21jYXN0 Lm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDssICZxdW90Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPm1tdXNpY0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZxdW90Ow0KICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tbXVzaWNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog W01NVVNJQ10gVHJhbnNwb3J0IHRhZ3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIEJGQ1Agd2lsbCBuZWVkIFRDUC9EVExTL0JGQ1Ag YWRkZWQgdG8gdGhlIGxpc3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ U2hvdWxkIHdlIGNvcnJlY3QgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAgZHJhZnQgdG8gbWF0 Y2ggYW5kIGNoYW5nZSBVRFAvRFRMUy9TQ1RQIHRvIFVEUC9UTFMvU0NUUD8NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyIGNsZWFyPSJhbGwiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBKYW4gMTEsIDIwMTcgYXQgNTowNSBQTSwg Q2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNrZWxj dUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ZWNrZWxjdUBj aXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7DQogd3JvdGU6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhlcmUgaXMgd2hhdCB3ZSBoYXZlIGZvciBCRkNQIGluDQo8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgz YmlzLTE2I3NlY3Rpb24tMTMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTE2 I3NlY3Rpb24tMTM8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tJiM0Mzst LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBWYWx1ZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFJlZmVyZW5jZSZuYnNw OyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUQ1Av QkZDUCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IFtSRkMgWFhYWF0gfDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7fCBUQ1AvVExTL0JGQ1AgfCBbUkZDIFhYWFhdIHw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVURQL0JGQ1AmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBbUkZDIFhYWFhdIHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgVURQL1RMUy9C RkNQIHwgW1JGQyBYWFhYXSB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5DaGFybGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNC NUM0REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPm1tdXNpYyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tbXVzaWMtYm91bmNlc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhhbGYg b2YgUm9tYW4gU2hwb3VudCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyb21hbkB0ZWx1cml4 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5yb21hbkB0ZWx1cml4LmNvbTwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2Vk bmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IGF0IDE6MDEgUE08YnI+DQo8Yj5UbzogPC9iPk1hZ251 cyBXZXN0ZXJsdW5kICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5k QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7 PGJyPg0KPGI+Q2M6IDwvYj5QYXVsIEt5eml2YXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cGF1bC5reXppdmF0QGNvbWNhc3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnBh dWwua3l6aXZhdEBjb21jYXN0Lm5ldDwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZndDssDQogJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bW11c2ljQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1t dXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tbXVzaWNAaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPltNTVVTSUNdIFRyYW5zcG9ydCB0YWdzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5XaGF0IHNob3VsZCB3ZSB1 c2UgZm9yIHRoZSBuZXcgcHJvdG9jb2xzIHRoYXQgd2UgYXJlIGRlZmluaW5nPw0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNob3VsZCBpdCBiZSBVRFAvVExT L1NDVFAgb3IgVURQL0RUTFMvU0NUUD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5TaG91bGQgaXQg YmUgVURQL1RMUy9CRkNQIG9yIFVEUC9EVExTL0JGQ1A/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBsaWtlIHRvIHNlZSBzb21lIGNv bnNpc3RlbmN5IGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+UmVnYXJkcywNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19f X19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQsIEphbiAxMSwgMjAxNyBhdCAzOjMwIEFNLCBNYWdudXMg V2VzdGVybHVuZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+bWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ow0K IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNt O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBjbGFzcz0ibTky MDkwMzczMzc4MjY1MTQ5ODhtMzkzNjA0MzAxNTUxNzk0NzM4N2dtYWlsLSI+PHNwYW4gbGFuZz0i RU4tVVMiPkRlbiAyMDE3LTAxLTEwIGtsLiAxOTowOCwgc2tyZXYgUm9tYW4gU2hwb3VudDo8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5QLlMuIEluIHRoZSBxdW90ZWQgdGV4dCBzb21lb25lIG1lbnRpb25lZCAmcXVvdDtVRFAv VExTL1JUUC9TQVZQRiZxdW90Oywgc2hvdWxkIGl0PGJyPg0KYmUgJnF1b3Q7VURQL0RUTFMvUlRQ L1NBVlBGJnF1b3Q7Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCk5vLCBhY3R1YWxseSBV RFAvVExTL1JUUC9TQVZQRiBpcyB3aGF0IGlzIHJlZ2lzdGVyZWQgZm9yIERUTFMtU1JUUCBvdmVy IFVEUCB3aXRoIFJUUCBTQVZQRiBwcm9maWxlLiBTZWUgW1JGQzU3NjRdLiBUaGUgJnF1b3Q7VURQ L0RUTFMvUlRQL1NBVlBGJnF1b3Q7IGlzIG5vdCByZWdpc3RlcmVkLjxicj4NCjxicj4NClNvIHRo ZSBhbHRlcm5hdGl2ZXMgZm9yIHRoZSBkZXBlbmRlbmN5IG9mIGRlZmF1bHQgY2FuZGlkYXRlIHBy b3RvY29sIHR5cGUgaW4geW91ciBwcm9wb3NhbCB3b3VsZCBiZTo8YnI+DQo8YnI+DQpVRFA6ICZx dW90O1VEUC9UTFMvUlRQL1NBVlBGJnF1b3Q7PGJyPg0KVENQOiAmcXVvdDtUQ1AvRFRMUy9SVFAv U0FWUEYmcXVvdDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQo8YnI+ DQpNYWdudXMgV2VzdGVybHVuZDxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpTZXJ2aWNl cywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE08 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KRXJpY3Nzb24gQUImbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgUGhvbmUmbmJzcDsgPC9z cGFuPjxhIGhyZWY9InRlbDolMkI0NiUyMDEwJTIwNzE0ODI4NyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIGxhbmc9IkVOLVVTIj4mIzQzOzQ2IDEwIDcxNDgyODc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVOLVVTIj48YnI+DQpGw6Ryw7ZnYXRhbiA2Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IE1vYmlsZSA8L3NwYW4+PGEgaHJlZj0i dGVsOiUyQjQ2JTIwNzMlMjAwOTQ5MDc5IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4t VVMiPiYjNDM7NDYgNzMgMDk0OTA3OTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N ClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJFTi1VUyI+bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BF6F72CESESSMB209erics_-- From nobody Thu Jan 12 13:28: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 68586129499 for ; Thu, 12 Jan 2017 13:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 IR9mhddlAZVX for ; Thu, 12 Jan 2017 13:27:59 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31741289B0 for ; Thu, 12 Jan 2017 13:27:59 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x49so30636965qtc.2 for ; Thu, 12 Jan 2017 13:27:59 -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=UnI8YyRRWCGNQWHQQXqC+7rxViA8ZQZF+MNmj8TONp4=; b=o90t1sqpdg61otAxfsfZiZvDP3bQN3I1RU7rUYrb1sNU+QR65SHz/Y7rQ/ZptrsOCd QstbVEj9k7TlVH2P0obTNdwsmp9rKjBg3kNFf5Be+VZWtSZyPyUv89HLeRFcTJKxCPTp MIzk88jJ/d/cLeJYbA+kdrDDxtP33DUMvY0sJM/5TznObcHMGNYJjHoQYrzKg+OinjTq T8Rh1EYHWeQ/8FBS0Xs4+wpHaCrlPlq6z1XL9n47XUnMB9HHXTuufBxFF98vv281OaOx VhJegdQm3KdFoN8t+l/IRRXli/yfehgJa+LPoddFdCO8uLa1QHCYmUERS6algl3nA8wW dGaw== 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=UnI8YyRRWCGNQWHQQXqC+7rxViA8ZQZF+MNmj8TONp4=; b=hO3CeUz74W7KidKSID2XxW0CMkmh12equ3HeLrA71xlM71N2XJrlEXtYfh/Uc0vbpG LZauA4LiSbGng8egHe1tkwRd87AhkrNyiYWd82mp9P7wn86tyOictXVj0aF0+LpwYljz /v+jwwFO1OtMNqDtqc4F8aYP9rLzO08jlAweQ8zh5Wzl0hy1M5FZtCLg0T8eAdMvxFA3 MsgUU/Bp10XPzGXglK1+UaEOSmiFbYxBBHp71A4V/bZ0d6qXGFC1wjkOID8MbbIYJbjf WCl7/JOktqQ9ArboyHrFuNixfMHJ+W2rIVsQ8gPzX0r9m+8mz9U+5pq5nINrZIM/BKI5 D3tA== X-Gm-Message-State: AIkVDXKcCqokUC3pjm6lEGmr+XqQ7qYHeNFdmlJVGumUYL25xVZALYOcB5PBtvyNVY6i0Q== X-Received: by 10.200.51.134 with SMTP id c6mr14350194qtb.258.1484256478496; Thu, 12 Jan 2017 13:27:58 -0800 (PST) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com. [209.85.220.180]) by smtp.gmail.com with ESMTPSA id e33sm7550752qtb.31.2017.01.12.13.27.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:27:58 -0800 (PST) Received: by mail-qk0-f180.google.com with SMTP id s140so35167151qke.0 for ; Thu, 12 Jan 2017 13:27:57 -0800 (PST) X-Received: by 10.55.11.13 with SMTP id 13mr16827769qkl.201.1484256477705; Thu, 12 Jan 2017 13:27:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Thu, 12 Jan 2017 13:27:57 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 12 Jan 2017 16:27:57 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114d7c7a1c04e00545ec64ed Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 21:28:01 -0000 --001a114d7c7a1c04e00545ec64ed Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 4:08 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > >Definition for TCP/DTLS/BFCP needs to be added in draft-ietf-bfcpbis- > rfc4583bis. > > > > > >This is BFCP over DTLS over TCP with RFC 4571 framing. > > > > Correct. > > > > >UDP/DTLS/BFCP together with TCP/DTLS/BFCP will over ICE based on the > mechanisms defined in draft-ietf-mmusic-dtls-sdp. Only UDP/DTLS/BFCP >in > combination with TCP/DTLS/BFCP will support ICE. TCP/BFCP and TLS/BFCP will > not support ICE and will have two run with at least one end point >on the > public IP. > > > > I agree with all of that, but that was not my issue :) > > > > My issue was that it is not enough to simply change the proto value in > 4583bis. You also need to define the usage of the RFC 4571 framing > mechanism. > > > > And, if that is not backward compatible with RFC 4583 (which does NOT use > 4571 framing), you need to add some text about that also. > > > I do not think TCP/DTLS/BFCP is defined anywhere, so it does not have to be backwards compatible. We are not changing the proto value, we should define a new one and explain how it works. This leaves TCP/BFCP and TLS/BFCP as they were previously defined and simply states that these transports cannot be used with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, with ICE not supported for all the other BFCP flavors. Only issue I see here is that an offer of BFCP with ICE will not be backwards compatible with RFC 4583 implementations, but considering that RFC4583 did not define BFCP over DTLS at all, we should be fine here. Regards, _____________ Roman Shpount --001a114d7c7a1c04e00545ec64ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 12, 2017 at 4:0= 8 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

Hi,

=C2=A0

>Definition for TCP/DTLS/BFCP needs to be added i= n=C2=A0draft-ietf-bfcpbis-rfc4583bis.

>=C2=A0

>This is BFCP over DTLS over TCP with RFC 4571 fr= aming.

=C2=A0

Correct.

=C2=A0

>UDP/DTLS/BFCP together with TCP/DTLS/BFCP=C2=A0w= ill over ICE based on the mechanisms defined in draft-ietf-mmusic-dtls-sdp.= Only UDP/DTLS/BFCP >in combination with TCP/DTLS/BFCP will support ICE.= TCP/BFCP and TLS/BFCP will not support ICE and will have two run with at least one end point >on the public IP.=

=C2=A0

I agree with all of that, but that was not my issue :)<= /u>

=C2=A0

My issue was that it is not enough to simply change the proto val= ue in 4583bis. You also need to define the usage of the RFC 4571 framing me= chanism.

=C2=A0

And, if that is not backward compatible with RFC 4583 (which does= NOT use 4571 framing), you need to add some text about that also.


I do not think TCP/DTLS/BFCP is defined anywhere, so it does n= ot have to be backwards compatible. We are not changing the proto value, we= should define a new one and explain how it works. This leaves TCP/BFCP and= TLS/BFCP as they were previously defined and simply states that these tran= sports cannot be used with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be= used with ICE, with ICE not supported for all the other BFCP flavors.=C2= =A0

Only issue I see here is that an offer of BFCP= with ICE will not be backwards compatible with RFC 4583 implementations, b= ut considering that RFC4583 did not define BFCP over DTLS at all, we should= be fine here.

Regards,
_____________
Roman Shpount
=C2=A0
<= /div>
--001a114d7c7a1c04e00545ec64ed-- From nobody Thu Jan 12 13: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 B212C129443 for ; Thu, 12 Jan 2017 13:45: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 dAn3VEMT9gae for ; Thu, 12 Jan 2017 13:45:23 -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 E9D931289C4 for ; Thu, 12 Jan 2017 13:45:22 -0800 (PST) X-AuditID: c1b4fb3a-2f75798000002085-9e-5877f8f106d5 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id F2.AC.08325.1F8F7785; Thu, 12 Jan 2017 22:45:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Thu, 12 Jan 2017 22:45:02 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE4EIgYTLJ46IUOs37NybF5vwKEzxFEAgAApOYCAAQCwAIAAXbPA///0dgCAABVIgP//9nGAgAAUD+A= Date: Thu, 12 Jan 2017 21:45:01 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BF6F797ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2J7lO7HH+URBhumClpsmvWFzWLq8scs Fg9+9LJZzLgwldmBxWPK742sHpMfz2H0WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBn7nlxg LThjWHFrwgGWBsYpBl2MnBwSAiYSMyb3MXcxcnEICaxjlJg39SI7hLOEUWLDw6lsXYwcHGwC FhLd/7RBGkQEVCX+fp/MBFLDLLCdUeL3u4MsIAlhARWJfS82ssAUrVp4jBHCTpJ49uULE4jN AhSf0/yGGcTmFfCVmLVqIiuILSQwmUVi5qRaEJtTIFDibNdNNhCbUUBM4vupNWC9zALiEree zGeCuFpAYsme88wQtqjEy8f/WCFsJYm1h7ezQNTnS/ybu5UdYpegxMmZT1gmMIrMQjJqFpKy WUjKZgG9zCygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMYoWpxYX56YbGemlFmUmFxfn 5+nlpZZsYgRG38Etv612MB587niIUYCDUYmHt8CjLEKINbGsuDL3EKMEB7OSCG/u1/IIId6U xMqq1KL8+KLSnNTiQ4zSHCxK4rxmK++HCwmkJ5akZqemFqQWwWSZODilGhjdb97coWQTnZzm FW/+U3nLkk9hwbuzVm0r4H080bjZKWb95T2rtmnOtPTQE/rqmnT1zuRv4uyKabN6HT5u4skw 2zvnT+ING6dm2RDFGb/+i7p63dxaMGlvoURLQlCQa57/mvuN5TNdLnx9FSE3PTHm/IT2W7m6 k0Kim9acuZZw/49U83fnCU+UWIozEg21mIuKEwEqh0QwugIAAA== Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 21:45:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BF6F797ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCuKApg0KDQo+SSBkbyBub3QgdGhpbmsgVENQL0RUTFMvQkZDUCBpcyBkZWZpbmVkIGFu eXdoZXJlLCBzbyBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlLiBX ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBwcm90byB2YWx1ZSwgd2Ugc2hvdWxkID5kZWZpbmUgYSBu ZXcgb25lIGFuZCBleHBsYWluIGhvdyBpdCB3b3Jrcy4gVGhpcyBsZWF2ZXMgVENQL0JGQ1AgYW5k IFRMUy9CRkNQIGFzIHRoZXkgd2VyZSBwcmV2aW91c2x5IGRlZmluZWQgYW5kIHNpbXBseSBzdGF0 ZXMgdGhhdCB0aGVzZSB0cmFuc3BvcnRzID5jYW5ub3QgYmUgdXNlZCB3aXRoIElDRS4gT25seSBV RFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQIGNhbiBiZSB1c2VkIHdpdGggSUNFLCB3aXRo IElDRSBub3Qgc3VwcG9ydGVkIGZvciBhbGwgdGhlIG90aGVyIEJGQ1AgZmxhdm9ycy4NCg0KT2ss IHNvIFRDUC9CRkNQIGFuZCBUTFMvQkZDUCB3aWxsIHN0aWxsIGJlIGtlcHQgaW4gNDU4M2Jpcywg YW5kIHNob3VsZCBiZSB1c2VkIHdoZW4gSUNFIGlzIG5vdCB1c2VkPw0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BF6F797ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmdtYWlsLQ0KCXttc28t c3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0O0kgZG8gbm90IHRoaW5rIFRDUC9EVExTL0JGQ1AgaXMgZGVmaW5lZCBhbnl3aGVy ZSwgc28gaXQgZG9lcyBub3QgaGF2ZSB0byBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZS4gV2UgYXJl IG5vdCBjaGFuZ2luZyB0aGUgcHJvdG8gdmFsdWUsIHdlIHNob3VsZCAmZ3Q7ZGVmaW5lIGEgbmV3 IG9uZSBhbmQgZXhwbGFpbiBob3cgaXQgd29ya3MuIFRoaXMgbGVhdmVzIFRDUC9CRkNQIGFuZCBU TFMvQkZDUCBhcyB0aGV5IHdlcmUNCiBwcmV2aW91c2x5IGRlZmluZWQgYW5kIHNpbXBseSBzdGF0 ZXMgdGhhdCB0aGVzZSB0cmFuc3BvcnRzICZndDtjYW5ub3QgYmUgdXNlZCB3aXRoIElDRS4gT25s eSBVRFAvRFRMUy9CRkNQIGFuZCBUQ1AvRFRMUy9CRkNQIGNhbiBiZSB1c2VkIHdpdGggSUNFLCB3 aXRoIElDRSBub3Qgc3VwcG9ydGVkIGZvciBhbGwgdGhlIG90aGVyIEJGQ1AgZmxhdm9ycy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Paywgc28gVENQL0JGQ1AgYW5kIFRMUy9CRkNQIHdpbGwgc3RpbGwgYmUga2VwdCBpbiA0NTgz YmlzLCBhbmQgc2hvdWxkIGJlIHVzZWQgd2hlbiBJQ0UgaXMgbm90IHVzZWQ/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BF6F797ESESSMB209erics_-- From nobody Thu Jan 12 14:15: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 E7AE71294B7 for ; Thu, 12 Jan 2017 14:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 LBCgGap1PZVh for ; Thu, 12 Jan 2017 14:15:06 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FA5129496 for ; Thu, 12 Jan 2017 14:15:05 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id l7so31895749qtd.1 for ; Thu, 12 Jan 2017 14:15:05 -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=DoNRKJqHCQg72N6HDC2TXULe/hpnWVHZgrQNfefE9QE=; b=FSs2+ZvBOmkIfvWw7h34sF8NOsVD4DWm3qVS5uEn6pldLUHX0fpBRHdjadMOqY/99C krx/GgsaNkNIHvDY+qze35mUYjjCBtobKY+qbAaVKD8uoLG14hV8vW2xT3T3fx2+7tFj cZqqnU+KFDLZzf2xOJDQ9b4CfpUQVA9DryZxrE+N2Y5iWu1SAxfDcUn0y2iGhN1aUWNb LYnmEVhwR4LRcaf0CUcgw7mhgbVIwPTmKcqFR+1KdEl1NfdZ3Qrv9DNKOU+ZLIhkE6aR /fmd8tekKQYiqD8Nq+pYEmFiys3opqzVVrQopejTes9+Lqwd9X3LsAhxy6xLdeEHAhg0 JScg== 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=DoNRKJqHCQg72N6HDC2TXULe/hpnWVHZgrQNfefE9QE=; b=fre3zCtO2FgdgSaa/MHYXoQBfV6PH+d2gG0QwtZcrqn/2WwugZ3G8wyDCmTJ+dbGVf nbuYNY65Y+xk7ApToCADLb6vYXyQPV11IGUydvkCaOMrewJTXHFU10BgXBEDGRJxtCVw Qv8hNPQKYbjmXNZOyQAOdfYPjcU1zaXbjNll/VOzJakPLrluDbBpz0s6yG2gRSBfjn3m xUERlsgn1+KOKUB5h+a1nXKM5xcjDTsh7kw76Pk3dmr7P14LZ644ZyRUo3MRBMGPJbED u/qbaly439Ir9/YHbnTwEKsEiNDeHIxvb2KoGZJrw9uwlJ8QlcnQayYvzb+kazVQK+va q+Mw== X-Gm-Message-State: AIkVDXKGusjnBw8Na8E/t3OgPurxTaTL7SK7XPUXUJag9m1KeMBIlFtojnK7FqdrybU4zw== X-Received: by 10.200.52.129 with SMTP id w1mr14253243qtb.43.1484259304790; Thu, 12 Jan 2017 14:15:04 -0800 (PST) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com. [209.85.220.175]) by smtp.gmail.com with ESMTPSA id 30sm7664065qth.14.2017.01.12.14.15.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 14:15:04 -0800 (PST) Received: by mail-qk0-f175.google.com with SMTP id 11so36040981qkl.3 for ; Thu, 12 Jan 2017 14:15:04 -0800 (PST) X-Received: by 10.55.197.148 with SMTP id k20mr14893713qkl.34.1484259304095; Thu, 12 Jan 2017 14:15:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Thu, 12 Jan 2017 14:15:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> From: Roman Shpount Date: Thu, 12 Jan 2017 17:15:03 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1149e64093561d0545ed0c50 Archived-At: Cc: Magnus Westerlund , "mmusic@ietf.org" , Paul Kyzivat Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 22:15:08 -0000 --001a1149e64093561d0545ed0c50 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >I do not think TCP/DTLS/BFCP is defined anywhere, so it does not have to > be backwards compatible. We are not changing the proto value, we should > >define a new one and explain how it works. This leaves TCP/BFCP and > TLS/BFCP as they were previously defined and simply states that these > transports >cannot be used with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP > can be used with ICE, with ICE not supported for all the other BFCP > flavors. > > > > Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and should be > used when ICE is not used? > > > TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only be used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two transport that can be used with or without ICE. Regards, _____________ Roman Shpount --001a1149e64093561d0545ed0c50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

>I do not think TCP/DTLS/BFCP is defined anywhere= , so it does not have to be backwards compatible. We are not changing the p= roto value, we should >define a new one and explain how it works. This l= eaves TCP/BFCP and TLS/BFCP as they were previously defined and simply states that these transports >cannot be u= sed with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, wi= th ICE not supported for all the other BFCP flavors.=C2=A0

=C2=A0

Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and s= hould be used when ICE is not used?



TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 45= 83bis and can only be used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS= /BFCP are two transport that can be used with or without ICE.
Regards,
_____________=
Roman Shpount
=C2=A0
--001a1149e64093561d0545ed0c50-- From nobody Thu Jan 12 14:25:26 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 BC081128BA2; Thu, 12 Jan 2017 14:25:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148425992476.2866.4340582151320850085.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 14:25:24 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:25:25 -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 of the IETF. Title : Connection-Oriented Media Transport over TLS in SDP Authors : Jonathan Lennox Christer Holmberg Filename : draft-ietf-mmusic-4572-update-11.txt Pages : 17 Date : 2017-01-12 Abstract: This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-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 Thu Jan 12 14:46:50 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 3F2CC129434 for ; Thu, 12 Jan 2017 14:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 plqXf9kR5BFG for ; Thu, 12 Jan 2017 14:46:47 -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 E447A127071 for ; Thu, 12 Jan 2017 14:46:46 -0800 (PST) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0CMkjdo010719 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Jan 2017 16:46:46 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at From: Adam Roach To: "mmusic@ietf.org" Message-ID: <739e4cfc-8baf-0979-8d23-ec3a605f8a3a@nostrum.com> Date: Thu, 12 Jan 2017 16:46:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] Review of draft-ietf-mmusic-ice-sip-sdp-10 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 22:46:49 -0000 I've done a review of draft-ietf-mmusic-ice-sip-sdp-10, and have a handful of comments. I've broken these down into three sections: big-picture questions, technical comments, and editorial comments. I apologize for the lateness in posting this review; the comments are substantial, and converting them into email form took far longer than I anticipated. Big Picture Questions The text in section 9, read literally, deprecates RFCs 4091 and 4092. If that is the actual intention, the abstract and "obsoletes" metadata need to be updated to reflect this fact. If the deprecation is qualified (e.g., the RFCs are still okay in other contexts, but should not be used in conjunction with ICE), then the text in section 9 needs to be much clearer. It's not clear to me what the relationship is between this document and RFC 5245 (and, for that matter, 6544). Is this supposed to obsolete RFC 5245? That appears to be the intention. It's also not clear why we would obsolete 5245 without also incorporating 6544 -- it seems that doing so leaves the use of ICE TCP with SIP to be kind of in limbo. Assuming the intention *is* to replace RFC 5245, the structure of this document seems to leave non-SIP uses of RFC3264 (e.g., WebRTC) stranded. If the intention is *not* to replace RFC 5245, the replication of all of the SDP syntax seems to be problematic: the the case of a conflict, which specification is intended to govern? In short, I think the relationship between this document, the contemporary work (e.g., ICE-BIS), and the historical work on which it is based needs to be made much clearer in the document itself, and we need to have a clear picture about how to handle SDP for non-SIP uses of ICE (e.g., by splitting this document into an SDP part and a SIP part, similar to how we split 3264 from 3261). Technical Comments I believe that the RECOMMENDED-strength normative statement in the final paragraph of 4.1.1.1 overstates things a bit. While this guidance makes set in certain circumstances. For example, for devices that are known to typically known to be on a single network with mutual routability, using a relayed candidate as a default will lead to calls being unnecessarily sent out of network and back. I strongly suggest that this paragraph be reworked to be a considered discussion of the different trade-offs involved in using each kind of candidate, with a non-normative suggestion to make the behavior configurable in user agents. What I want to avoid here is guidance which leads to devices behind a single ALG necessarily going through two relays by default when talking to each other (which is what the current guidance can lead to -- I can sketch this out in more detail if it's not obvious how this happens). Section 4.1.1.2 uses the word "media stream" in a way that's not consistent with the way that term is defined by RFC 7656, which could lead to confusion. In RFC 7656 terminology, "media stream" is an alias for "RTP stream," which is identified by a single SSRC. With technologies such as simulcast. A single m-line can contain multiple media streams. I think you want the term "source stream," with a citation of that term in RFC 7656. Section 4.1.1.2 discusses ice-options attributes in the terms of "support", without any discussion of activation. Although this is treated (somewhat lightly) later in the document, this smells like the same kind of potential morass we ran into with SIP options tags: the patchwork means of indicating feature *support* versus feature *activation* made it very difficult to specify and implement things in a consistent fashion. I strongly recommend that this document spend a bit more text discussing this distinction, and maybe even consider a formal syntax for distinguishing between supported and activated features. Section 4.1.3 should probably point out that, in the case of forking, the same local candidates are used for all branches of the fork. Section 4.2, section paragraph: replace "be rejected" with "fail" -- there are more ways to fail than rejection, and the action should be the same for rejection as for other failures. Section 4.2.1.2 should add motivation for the requirement imposed by its second paragraph, or the requirement should be removed. The need to do this is not obvious, and I suspect it may be unnecessary. Section 4.2.2.2.3 specifies, during offer processing, that the implementation "SHOULD wait for [ICE] checks to complete" before sending an answer. Keeping in mind that these updates typically happen with the SIP UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm concerned about the timing implications here. We should minimally point out that we're explicitly telling UAs to ignore this normative statement in RFC3261, and make sure that we've done the analysis to ensure that we're not going to cause problems for the SIP state machine (I'm concerned, in particular, about unnecessary SIP retransmissions here). Section 4.2.4.1.4: the final paragraph seems to reiterate behavior described in ICE-BIS. It's probably not ideal to describe this in two places, as any subtle difference can result in interop problems. Given the state of ICE today, I think the definition of "candidate" in section 5.1 should also include the syntax for TCP transports. Section 5.1, : the language in here that states "If the DNS query returns more than on IP address, on is chosen," implying that one is chosen at random. There are specific procedures for how this is done (especially with IPv6); the statement should point to the selection mechanisms. Section 11.2.1, final paragraph: We should have text in here addressing the fact that user agents that are not willing to receive non-ICE answers need to include "Require: ice" in their offer; and that clients that reject non-ICE offers should use the 421 response code to do so, and should indicate "Require: ice" in their rejections. Editorial Comments (of varying severity) The final sentence of the definition of "Default Destination/Candidate" is a bit difficult to follow. Suggest: ' For the RTCP component, the address and port are indicated using the "a=rtcp" attribute defined in [RFC3605], if present; otherwise, the RTCP component address is the same as the address of the RTP component, and its port is one greater than the port of the RTP component.' Section 3, final paragraph: remove "the" before "[ICE-BIS]". Section 4.1.3, second paragraph: eliminate the space before the first comma. Place a comma between "its role" and "and processes" Section 4.1.3, final paragraph: replace "complaint" with "compliant". The contents of section 4.1.5 appear to be completely redundant with the contents of section 4.1.5.1.1. I would recommend eliminating section 4.1.5. Also, the section numbering here is really baroque and unnecessarily deep. For example, section 4.1.5.1 contains no text and only one subsection; this is also true of section 4.1.5.2. The more I look at this, the more bizarre it appears. I think the correct thing to do here is: (a) Remove all the text currently in section 4.1.5. (b) Move the paragraph in section 4.1.5.1.1 and the two paragraphs in 4.1.5.2.1 into section 4.1.5 (c) Eliminate the (now empty) sections 4.1.5.1, 4.1.5.1.1, 4.1.5.2, and 4.1.5.2.1. Section 4.2.1.2.1, second paragraph says "The agent MAY include additional candidates it did not offer previously" before we explain how this can happen. I recommend adding a "(see section 4.2.4.1.1)" after "previously". Section 4.2.2.3, final paragraph: The second line has an "i" that has been separated from the rest of its word (which appears on the following line). Section 4.2.3: add commas: "being ICE-unaware, a subsequent" ... "this is done, this could result" ... "ICE-unaware, that answer would not" Section 4.2.3.1.1 should not rely on the section header exclusively for context here. The first sentence should read "If ICE support is indicated int he SIP answer and the offer was a restart..." Ditto for sections 4.2.3.1.3 (add "and ICE is running") and 4.2.3.1.3 ("and ICE is completed"). Section 5.1 indicates that ABNF is used for "candidate," but this is not repeated for (e.g.) sections 5.3. and 5.4. I would suggest moving the statement from 5.1 (and 5.2) into section 5 so that it applies to all syntax definitions. In all of section 5, the attributes really should include examples. Also, section 5 should indicate which exernally-defined ABNF constructs are being used in the document. This is done in some locations, but not others. Running the ABNF through a validator will highlight all externally-defined elements; it will also help uncover any other issues with the ABNF. All attributes are defined with ABNF of the form: "attribute-name" ":" -- this is unnecessary, and should be shortened to "attribute-name:". Section 5.1, under : change "using an A" to "using an A record." Section 5.1, under refers to specification of TCP with ICE in the future tense rather than the past. This should be reworked. Section 5.1, under , "...in the Frozen algorithm" should be followed by "defined in" and then a citation for where the Frozen algorithm is defined. Section 5.1, -- this just says it's an integer, without describing its meaning. Either explain what it means, or cite something that does so. Section 5.1, and : replace " and is equal" with " and are equal". Section 5.2, in the ABNF for "remote-candidate", indicate that component-ID is defined in RFC 4566. Section 5.4, final paragraph: this indicates that the grammar allows for "6 bits of randomness per character" -- this should indicate that it allows for "6 bits of information per character". Section 6: rewrite the first sentence using active voice so as to positively identify which entities the requirements apply to. Section 7.1: "Note that" is an awkward way to start a section; I suggest striking it. Section 7.1, first line: replace "may not" with "might not." I had to read this several times to realize that the intended meaning here was "might not." In colloquial usage, "may not" is a prohibition (e.g., "you may not take more than two cookies.") Section 8.1, first paragraph refers to "ringing the phone of the called party." Old-style telephones are only one use case for SIP; this should instead read "alerting the called user agent." Section 8.1.1 second paragraph is HUGE. Consider how to split it up to be less "wall of text"y. Section 8.1.1, fourth paragraph replace "each candidate" with "every candidate." Section 8.1.1, final paragraph: "it's a localized decision" is extremely informal and doesn't match the general style for RFCs. Please rephrase. Section 8.1.2, first paragraph describes a kind of difficult-to-follow situation in which an INVITE contains an offer, and the answer is provided in a PRACK response, resulting in an empty "200 OK." Two comments: (1) this would really benefit from a sequence diagram; and (2) are SBCs and ALGs likely to do the right thing with empty 200s? Section 8.1.2, second paragraph indicates that placing an offer in an INVITE the 2xx can cause substantial PDD and clipping; this is true regardless of whether ICE is in use. I think you mean to say that ICE can exacerbate PDD and clipping in this case rather than causing it. Sections 8.4, 9, and 11.1 -- remove the redundant RFC numbers (as in "defined in RFC 3312 [RFC3312]"). Section 10 refers to timer Ta without indicating where it is defined. Section 11.1: Replace "SIPS" with "TLS". As Olle is fond of noting, there are circumstances in which TLS is feasible but SIPS is not, and specifying "TLS" here is sufficient. Section 11.2: replace "stun" with "STUN." Section 11.2.1, final paragraph: replace "if its not used" with "if it's not used." Section 11.2.2 -- expand the acronym "NAT" on first use. Section 11.2.2, first paragraph: replace "application layer SIP" with "application-layer SIP" Section 12.1: Insert "The" at the very beginning of the first sentence. Section 12.2: Make "RFC 5245" a reference. Section 12.2, third paragraph should start "[RFC6679] defines the..." (add the word "the") Section 13: make "RFC 5245" and "RFC 6336" references. /a From nobody Thu Jan 12 14:50:05 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 F40E6129458; Thu, 12 Jan 2017 14:50:03 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148426140395.2891.15001251225927671086.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 14:50:03 -0800 Archived-At: Cc: Flemming Andreasen , ben@nostrum.com, draft-ietf-mmusic-4572-update@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Subject: [MMUSIC] Last Call: (Connection-Oriented Media Transport over TLS in SDP) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:50:04 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Connection-Oriented Media Transport over TLS in SDP' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 13 00:35: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 4358F129B32 for ; Fri, 13 Jan 2017 00:35:35 -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 b4eeu4m0RTvZ for ; Fri, 13 Jan 2017 00:35:33 -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 33963129B1B for ; Fri, 13 Jan 2017 00:35:33 -0800 (PST) X-AuditID: c1b4fb2d-1afff70000002e13-13-58789152d489 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id C2.4A.11795.25198785; Fri, 13 Jan 2017 09:35:31 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.319.2; Fri, 13 Jan 2017 09:35:29 +0100 To: Roman Shpount , Christer Holmberg References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> From: Magnus Westerlund Message-ID: <0e376a55-f20b-b589-104a-6e34df5767e9@ericsson.com> Date: Fri, 13 Jan 2017 09:35:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7lm7wxIoIgwMXFS02zfrCZjF1+WMW iwc/etksZlyYyuzA4jHl90ZWj8mP5zB6LFnyk8nj1pSCAJYoLpuU1JzMstQifbsEroz3XevY ChYIVTSuWMnSwLiUr4uRk0NCwERiw8VX7F2MXBxCAusYJX62LmKCcJYzSpx4M5sJpEpYQEXi 0uVz7CC2iEC0xOW2/8wgtpDAPFaJ95f8QGxmgUZGiSXv7EBsNgELiZs/GtlAbF4Be4ntfQtZ QWwWAVWJXbtngc0RFYiReLt+OTtEjaDEyZlPWEBsToFAid7W16wQMy0kZs4/zwhhy0s0b50N tVdboqGpg3UCo8AsJO2zkLTMQtKygJF5FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZg+B7c 8lt3B+Pq146HGAU4GJV4eAu4KiKEWBPLiitzDzFKcDArifCK9gCFeFMSK6tSi/Lji0pzUosP MUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYJz3oJDVqWWnmWxV4fTKkik1lSJzGm/q dG87y7KvK0N8ZyFX6xJJ+5DIu7MMlzAVTph360iM7O0jX/LebZE7t2HO73PatnYbld6EOJ8R UV11QX/zu62hKzg3zldmTtn5aebxszwG5jobz88MY1z75teV7f/7FN+rNmf+/mK3P+yEQ4Pv pxkePrlKLMUZiYZazEXFiQAk/+W3WwIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 08:35:35 -0000 Hi, A question, is the UDP/DTLS/BFCP only used with ICE, or are they also used without ICE support. I wonders how this relates to the discussion that the UDP/TCP destinction becomes mote when one actually are doing ICE/DTLS/BFCP, i.e. use ICE to agree on a datagram capable transport and then puts DTLS/BFCP over it, independent on what transport type the arrived candidate pairs are on. Is there a point to the BFCP usages to actually be explicit that we one only want to use ICE negotiated DTLS secured BFCP, and thus should have a PROTO value for that, i.e. ICE/DTLS/BFCP? Note, this is a question, not an actual proposal. Just an exploration so that you who use the protocol can consider if it makes sense. Cheers Magnus Den 2017-01-12 kl. 23:15, skrev Roman Shpount: > On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg > > > wrote: > > >I do not think TCP/DTLS/BFCP is defined anywhere, so it does not > have to be backwards compatible. We are not changing the proto > value, we should >define a new one and explain how it works. This > leaves TCP/BFCP and TLS/BFCP as they were previously defined and > simply states that these transports >cannot be used with ICE. Only > UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, with ICE not > supported for all the other BFCP flavors. > > __ > > __ __ > > Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and > should be used when ICE is not used?____ > > > > TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only be > used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two > transport that can be used with or without ICE. > > Regards, > _____________ > Roman Shpount > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 13 00:42: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 C7D4A129489 for ; Fri, 13 Jan 2017 00:42:25 -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 ewqXSY73ZjG2 for ; Fri, 13 Jan 2017 00:42:24 -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 1802A12943E for ; Fri, 13 Jan 2017 00:42:23 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-7b-587892eed40e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id CA.4A.31458.EE298785; Fri, 13 Jan 2017 09:42:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 09:41:59 +0100 From: Christer Holmberg To: Magnus Westerlund , Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE4EIgYTLJ46IUOs37NybF5vwKEzxFEAgAApOYCAAQCwAIAAXbPA///0dgCAABVIgP//9nGAgAAUD+D///kagAAVqx+AAARz8IA= Date: Fri, 13 Jan 2017 08:41:58 +0000 Message-ID: References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> <0e376a55-f20b-b589-104a-6e34df5767e9@ericsson.com> In-Reply-To: <0e376a55-f20b-b589-104a-6e34df5767e9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3E4A5F7A66BF044C99185B87CF19CD55@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7me67SRURBt8XSFtsmvWFzWLq8scs Fg9+9LJZzLgwldmBxWPK742sHpMfz2H0WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBmvfp5l KjgjWvF/1inWBsYOwS5GDg4JAROJ5jucXYxcHEIC6xgljs44zA7hLGGU2PpkCStIEZuAhUT3 P+0uRk4OEYFoicb2LlYQm1mgkVFiyTs7EFtYQEXi0uVz7BA1qhKrFh5jhLDLJGa9fwZmswDF J+z9wgRi8wpYS8y7uYoJYtcVVomPN66zgCQ4BRwkTt3qB7MZBcQkvp9awwSxTFzi1pP5YLaE gIDEkj3nmSFsUYmXj/+BHSQqoCex/PkaqLiSxI8Nl1ggevUkbkydwgZhW0v0PT8CNVNbYtnC 18wQBwlKnJz5hGUCo/gsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLSSy3KTC4uzs/T y0st2cQIjMqDW34b7GB8+dzxEKMAB6MSD28BV0WEEGtiWXFl7iFGCQ5mJRHekxOAQrwpiZVV qUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTAqR9pNLlP/dFw81fol p+iu4qUhuz91LWhY/C3iOI9p4MeDPvN/7UgX4WX30l3wodHyg4NjiraJkm2aKfcR3af6v5Su BTzL+affwDAjTd7f/en9a4FJBoL7vKvvlJ9/kPb24te80xvNY5q37W+LfNL18c3DVfmHq/dd +dSy/4Epb87+3/4zdCOUWIozEg21mIuKEwFhFY6RxgIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 08:42:25 -0000 Hi, I see no reason to use UDP/DTLS/BFCP only with ICE. The question to define an =B3ICE proto=B2 has came up before. It=B9s certai= nly an interesting idea, but I think it should be studied within a wider scope - not for a specific protocol. Regards, Christer On 13/01/17 10:35, "Magnus Westerlund" wrote: >Hi, > >A question, is the UDP/DTLS/BFCP only used with ICE, or are they also >used without ICE support. I wonders how this relates to the discussion >that the UDP/TCP destinction becomes mote when one actually are doing >ICE/DTLS/BFCP, i.e. use ICE to agree on a datagram capable transport and >then puts DTLS/BFCP over it, independent on what transport type the >arrived candidate pairs are on. > >Is there a point to the BFCP usages to actually be explicit that we one >only want to use ICE negotiated DTLS secured BFCP, and thus should have >a PROTO value for that, i.e. ICE/DTLS/BFCP? > >Note, this is a question, not an actual proposal. Just an exploration so >that you who use the protocol can consider if it makes sense. > >Cheers > >Magnus > >Den 2017-01-12 kl. 23:15, skrev Roman Shpount: >> On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg >> > >> wrote: >> >> >I do not think TCP/DTLS/BFCP is defined anywhere, so it does not >> have to be backwards compatible. We are not changing the proto >> value, we should >define a new one and explain how it works. This >> leaves TCP/BFCP and TLS/BFCP as they were previously defined and >> simply states that these transports >cannot be used with ICE. Only >> UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, with ICE not >> supported for all the other BFCP flavors. >> >> __ >> >> __ __ >> >> Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and >> should be used when ICE is not used?____ >> >> >> >> TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only be >> used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two >> transport that can be used with or without ICE. >> >> Regards, >> _____________ >> Roman Shpount >> > > >--=20 > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Fri Jan 13 03:32: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 137FF129B38 for ; Fri, 13 Jan 2017 03:32:43 -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 WM4UCntt-2to for ; Fri, 13 Jan 2017 03:32:41 -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 EDDEF129539 for ; Fri, 13 Jan 2017 03:32:40 -0800 (PST) X-AuditID: c1b4fb3a-2f75798000002085-a6-5878bad637ba Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id FE.0F.08325.6DAB8785; Fri, 13 Jan 2017 12:32:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 12:32:28 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer Thread-Index: AQHSbZC3rKfnMMWZkkWeC738BQ54bA== Date: Fri, 13 Jan 2017 11:32:27 +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.1.161129 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D49E87A915A0Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7pe61XRURBo9OmVtMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGc8mJxa0S1bM+/KbtYHxrUgXIyeHhICJxJXPT1i6GLk4hATW MUrcP7qHDcJZwijx5vMWIIeDg03AQqL7nzZIg4iAusTXvT3MIGFhgQyJgxMqIMK5EufPLwOr FhHQk/j4XRIkzCKgKnF/zXkmkDCvgLXE9dVpIGFGATGJ76fWMIHYzALiEreezGeCuEZAYsme 88wQtqjEy8f/WEFsUaCJy5+vgYorSuw8284M0Zsgcf5bNyOIzSsgKHFy5hOWCYxCs5CMnYWk bBaSMoi4gcT7c/OZIWxtiWULX0PZ+hIbv5xlhLCtJTp7jrAgq1nAyLGKUbQ4tbg4N93ISC+1 KDO5uDg/Ty8vtWQTIzBGDm75bbWD8eBzx0OMAhyMSjy8BVwVEUKsiWXFlbmHGCU4mJVEePO3 AYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgVN/JFvI0 O1NHa01vpHmBb/X/SK069jbZjBPvTGJu6Pv2WLcvFuhdHCGUc4T75+EVOQsN2d+s1Gus6XzL tSz51RmDZz9CN3/3dLtwaW/b4RDD1InRu29GvzknJdP5KP4cJ9fBskn6nS3WPjxlWgHSBw9x S/lGzZ5x9cJ212OH6l3E7EXn7O9WYinOSDTUYi4qTgQA5Cz76o0CAAA= Archived-At: Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 11:32:43 -0000 --_000_D49E87A915A0Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In Seoul we discussed a number of issues related to ICE-SDP. We made some d= ecisions, and I got action points to verify one of those on the list. The associated slides can be found here: https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.= pdf The issue (slides 4-6) was when an answerer receives an offer with a m- lin= e transport that it doesn=92t support. The current O/A rules say that the t= ransport in the answer must match the transport in the offer. However, if ICE is used, there may be transports (offered using ICE candida= tes) that the answerer DOES support. Based on the discussions, there was strong consensus to go for Alt#2, which= was allowing a transport in the m- line of the answer even if the answerer= doesn=92t support it, as ICE candidates will be used to determine the tran= sport. Does anyone object to Alt#2? Regards, Christer --_000_D49E87A915A0Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

In Seoul we discussed a number of issues related to ICE-SDP. We made s= ome decisions, and I got action points to verify one of those on the list.<= /div>

The associated slides can be found here:



The issue (slides 4-6) was when an answerer receives an offer with a m= - line transport that it doesn=92t support. The current O/A rules say that = the transport in the answer must match the transport in the offer.

However, if ICE is used, there may be transports (offered using ICE ca= ndidates) that the answerer DOES support.

Based on the discussions, there was strong consensus to go for Alt#2, = which was allowing a transport in the m- line of the answer even if the ans= werer doesn=92t support it, as ICE candidates will be used to determine the= transport.

Does anyone object to Alt#2?

Regards,

Christer








 



--_000_D49E87A915A0Cchristerholmbergericssoncom_-- From nobody Fri Jan 13 03: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 ABBC91295AF for ; Fri, 13 Jan 2017 03:59:10 -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 0wepHhfAlCoe for ; Fri, 13 Jan 2017 03:59:09 -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 ACD1C129563 for ; Fri, 13 Jan 2017 03:59:08 -0800 (PST) X-AuditID: c1b4fb30-d248a98000007ae2-46-5878c10a639c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id E4.E3.31458.A01C8785; Fri, 13 Jan 2017 12:59:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 12:59:05 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: ICE-SDP: Suggested text to clarify that an ICE transport switch does not require a new offer (in order to match the transport of the c/m- line with the transport of the new candidate) Thread-Index: AQHSbZRvyzLm+tL5jU+XInzXX2PHKw== Date: Fri, 13 Jan 2017 11:59:04 +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.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D49E8DE515A2Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ny7XwYoIg9st4hZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxukZe5kLOlQrXi3JaWC8ItfFyMEhIWAisXJlWRcjF4eQwDpG iVd3D7NAOEsYJVbf3MgEUsQmYCHR/U+7i5GTQ0RAXeLr3h5mkBphgSOMEjd33QJzRAROMkqc fn+IHaJKT2LRqeUsIDaLgKrE2gUXwWxeAWuJh51HWEFsRgExie+n1jCB2MwC4hK3nswHsyUE BCSW7DnPDGGLSrx8/A+sXhRo5vLna5ghrlaSmLY1DaI1QWL/u0OsEOMFJU7OfMIygVFoFpKp s5CUzUJSBhE3kHh/bj4zhK0tsWzhayhbX2Ljl7OMs4C2MQNdvex8AbKSBYwcqxhFi1OLk3LT jYz0Uosyk4uL8/P08lJLNjEC4+Tglt8GOxhfPnc8xCjAwajEw1vAVREhxJpYVlyZe4hRgoNZ SYT3yn6gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYxr pUU6sj7ndj8OCNr70GrWnNZ58V9ZW41Sziy+fCz96bYvAT/OXsvU3Np89b+9WO2WV8lfxCMn bBLYNvOOaPkB9yhxW5nP7dsZ3uu57M+5r20Qe2XV956ov54pGfpOdSuvclVqlGStZhBJNUuS /Ln2yEJuVknDxGuLFiSYK4SpFB6w0O7krlJiKc5INNRiLipOBAAjyYvijwIAAA== Archived-At: Subject: [MMUSIC] ICE-SDP: Suggested text to clarify that an ICE transport switch does not require a new offer (in order to match the transport of the c/m- line with the transport of the new candidate) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 11:59:11 -0000 --_000_D49E8DE515A2Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, One of the issues that we were going to discuss in Seoul, but didn=92t have= much time for, was whether we should clarify that a ICE transport switch (= using a previously exchanged and verified ICE candidate pair) does not requ= ire a new offer, in order to align the m- line with the new transport. I got an action point in Seoul to suggest text for draft-ice-sep, and below= is my initial suggestion: 4.2. Subsequent Offer/Answer Exchanges Either agent MAY generate a subsequent offer at any time allowed by [RFC3264]. The rules in Section 4.1.5 will cause the controlling agent to send an updated offer at the conclusion of ICE processing when ICE has selected different candidate pairs from the default pairs. This section defines rules for construction of subsequent offers and answers. Should a subsequent offer be rejected, ICE processing continues as if the subsequent offer had never been made. As described in section 4.1.5, when ICE concludes, a subsequent offer mi= ght be required in order to match the transport in the c/m- line of a media= stream with the transport of the the selected candidates. Once this has be= en done, if an endpoint later starts to send media using another candidate,= the endpoint does not need to send a subsequent offer (even if the transpo= rt in the c/m- line does no longer match the transport of the candidate). Regards, Christer --_000_D49E8DE515A2Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <04452FC8C0EED240AF3C1EF50355A000@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

One of the issues that we were going to discuss in Seoul, but didn=92t= have much time for, was whether we should clarify that a ICE transport swi= tch (using a previously exchanged and verified ICE candidate pair) does not= require a new offer, in order to align the m- line with the new transport.

I got an action point in Seoul to suggest text for draft-ice-sep, and = below is my initial suggestion:

4.2.  Subsequent Offer/Answer Exch=
anges

   Either agent MAY generate a subsequent offer at any time allowed by
   [RFC3264].  The rules in Section 4.1.5 will cause the controlling
   agent to send an updated offer at the conclusion of ICE processing
   when ICE has selected different candidate pairs from the default
   pairs.  This section defines rules for construction of subsequent
   offers and answers.

   Should a subsequent offer be rejected, ICE processing continues as if
   the subsequent offer had never been made.
   <new>
   As described in section 4.1.5, =
when ICE concludes, a subsequent offer might be required in order to match =
the transport in the c/m- line of a media stream with the transport of the =
the selected candidates. Once this has been done, if an endpoint later star=
ts to send media using another candidate, the endpoint does not need to sen=
d a subsequent offer (even if the transport in the c/m- line does no longer=
 match the transport of the candidate).
   </new>
Regards,
Christer
--_000_D49E8DE515A2Echristerholmbergericssoncom_-- From nobody Fri Jan 13 04:01: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 BD0F71295AF for ; Fri, 13 Jan 2017 04:00:59 -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 5YcrGRSl5M21 for ; Fri, 13 Jan 2017 04:00:58 -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 A0B5B129594 for ; Fri, 13 Jan 2017 04:00:57 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-4b-5878c177a823 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id B2.DE.17130.771C8785; Fri, 13 Jan 2017 13:00:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 13:00:38 +0100 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer Thread-Index: AQHSbZSn9K1k6WISUEK9WxSL0te/qg== Date: Fri, 13 Jan 2017 12:00: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.1.161129 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D49E8E2E15A34christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7pW75wYoIg9tfbCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP3HOlkLNqtXvJx6lbGB8ZRiFyMnh4SAicTC+VOZuhi5OIQE 1jFKfG7rYYRwljBKzFx2gbWLkYODTcBCovufNkiDiIC6xNe9PcwgtrBAqcT9O+/ZIeJlEtPf PoGy9SS2H38JVsMioCrx/dUpVhCbV8BaYtmyHWA1jAJiEt9PrWECsZkFxCVuPZnPBHGQgMSS PeeZIWxRiZeP/4H1igLNXP58DTPIORICShLTtqZBtCZInFh/ghlivKDEyZlPWCYwCs1CMnUW krJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpZYff0GK7KaBYwcqxhFi1OLk3LTjYz1 Uosyk4uL8/P08lJLNjECI+Xglt+qOxgvv3E8xCjAwajEw1vAVREhxJpYVlyZe4hRgoNZSYT3 yn6gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYxtJ2fI Cnw64fVkiUOQmXv2+rCC67enWV858rBnqr9T0MLmnMnz5Xd7Gko+O5XXq/w/2Vwt5XyI3MWS N8EntuSmOCjZC2tavrqs5Zu9QfTENM73p9N+JF75V+tUc/Do+mi/V5ZSk2XPmF91eiliVb3i Rm131b4k0+0S2RPUnq1QP7P4Un9Q3GElluKMREMt5qLiRADDGHVSkAIAAA== Archived-At: Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 12:01:00 -0000 --_000_D49E8E2E15A34christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The subject shall be ICE-SDP: Verify decision made=85 From: mmusic > on b= ehalf of Christer Holmberg > Date: Friday 13 January 2017 at 13:32 To: "mmusic@ietf.org" > Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supp= orted transport in m- line of answer Hi, In Seoul we discussed a number of issues related to ICE-SDP. We made some d= ecisions, and I got action points to verify one of those on the list. The associated slides can be found here: https://www.ietf.org/proceedings/97/slides/slides-97-mmusic-ice-sip-sdp-00.= pdf The issue (slides 4-6) was when an answerer receives an offer with a m- lin= e transport that it doesn=92t support. The current O/A rules say that the t= ransport in the answer must match the transport in the offer. However, if ICE is used, there may be transports (offered using ICE candida= tes) that the answerer DOES support. Based on the discussions, there was strong consensus to go for Alt#2, which= was allowing a transport in the m- line of the answer even if the answerer= doesn=92t support it, as ICE candidates will be used to determine the tran= sport. Does anyone object to Alt#2? Regards, Christer --_000_D49E8E2E15A34christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1E3D991DEF88DD438F6744DAE02CD588@ericsson.com> Content-Transfer-Encoding: quoted-printable
The subject shall be ICE-SDP: Verify decision made=85

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Friday 13 January 2017 at 13:= 32
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] SIP-SDP: Verify d= ecision made in Seoul regarding non-supported transport in m- line of answe= r

Hi,

In Seoul we discussed a number of issues related to ICE-SDP. We made s= ome decisions, and I got action points to verify one of those on the list.<= /div>

The associated slides can be found here:



The issue (slides 4-6) was when an answerer receives an offer with a m= - line transport that it doesn=92t support. The current O/A rules say that = the transport in the answer must match the transport in the offer.

However, if ICE is used, there may be transports (offered using ICE ca= ndidates) that the answerer DOES support.

Based on the discussions, there was strong consensus to go for Alt#2, = which was allowing a transport in the m- line of the answer even if the ans= werer doesn=92t support it, as ICE candidates will be used to determine the= transport.

Does anyone object to Alt#2?

Regards,

Christer








 



--_000_D49E8E2E15A34christerholmbergericssoncom_-- From nobody Fri Jan 13 06:24: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 069551295C9 for ; Fri, 13 Jan 2017 06:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 P8HqeSzoPMw1 for ; Fri, 13 Jan 2017 06:24:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5251E12007C for ; Fri, 13 Jan 2017 06:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4362; q=dns/txt; s=iport; t=1484317488; x=1485527088; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a9ryxwFg/eZXIBI8nEL0AM1UJtskbBuf4TmatCW6rDo=; b=QLRcL3ZdxOIOG65Yf3FMCLt2ywtU3PMikwX92ior3bbmLZBga6pFAnTw 2l3N6ADndK64DEOYGzjk9KfJ+soEg0gF3syGgbPBslcKrDUipqRiUaN20 FBHaU0AiYwUd/tHSMBx2P51jvrX0CQQWJ6ExlBnaumFE7M92oipN+hKgt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAgDX4nhY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnVKAQEBAQEfgWifbo9/gxyCD4INhiICghJAEwECAQEBAQEBAWM?= =?us-ascii?q?ohGoBBXkQAgEIBBQnBzIUEQIEDgWJA7J2igsBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdiEeCX4d5gjEFmzIBkVgKkGOSZAEgATaBRBVKAYYfc4hmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,221,1477958400"; d="scan'208,217";a="192633770" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2017 14:24:43 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0DEOh71026601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 14:24:43 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 08:24:42 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 13 Jan 2017 08:24:42 -0600 From: "Charles Eckel (eckelcu)" To: Roman Shpount Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE3p2SC5GZHiXUyd4kk6fM3mOqEzs4yAgACvV4CAAHqSgIAA1ReAgAADMACAAAZqgIAABU+AgAAExICAAAhlgIAAqlUq Date: Fri, 13 Jan 2017 14:24:42 +0000 Message-ID: References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_EBECE11584F34E9783E265439A2D65F0ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Magnus Westerlund , Paul Kyzivat , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 14:24:50 -0000 --_000_EBECE11584F34E9783E265439A2D65F0ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UDP/DTLS/BFCP is already defined in 4583bis, except we specified the tag as= UDP/TLS/BFCP. I agree it can be used with and without ICE. Cheers, Charles On Jan 12, 2017, at 2:15 PM, Roman Shpount > wrote: On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg > wrote: >I do not think TCP/DTLS/BFCP is defined anywhere, so it does not have to b= e backwards compatible. We are not changing the proto value, we should >def= ine a new one and explain how it works. This leaves TCP/BFCP and TLS/BFCP a= s they were previously defined and simply states that these transports >can= not be used with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with= ICE, with ICE not supported for all the other BFCP flavors. Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and should be u= sed when ICE is not used? TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only be use= d when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two transport t= hat can be used with or without ICE. Regards, _____________ Roman Shpount --_000_EBECE11584F34E9783E265439A2D65F0ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

UDP/DTLS/BFC= P is already defined in 4583bis, except we specified the tag as UDP/TL= S/BFCP. I agree it can be used with and without ICE. 

Cheers,
Charles

On Jan 12, 2017, at 2:15 PM, Roman Shpount <roman@telurix.com> wrote:

On Thu, Jan 12, 2017 at 4:45 PM, Christer Ho= lmberg <chr= ister.holmberg@ericsson.com> wrote:

>I do not think TCP/DTLS/BFCP is defined anywhere= , so it does not have to be backwards compatible. We are not changing the p= roto value, we should >define a new one and explain how it works. This l= eaves TCP/BFCP and TLS/BFCP as they were previously defined and simply states that these transports >cannot be u= sed with ICE. Only UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, wi= th ICE not supported for all the other BFCP flavors. 

 

Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and s= hould be used when ICE is not used?



TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only b= e used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two transp= ort that can be used with or without ICE.

Regards,
_____________
Roman Shpount
 
--_000_EBECE11584F34E9783E265439A2D65F0ciscocom_-- From nobody Fri Jan 13 06:28:29 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 B93B012963A for ; Fri, 13 Jan 2017 06:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 3TEsO5YsMt2X for ; Fri, 13 Jan 2017 06:28:26 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E41F12961A for ; Fri, 13 Jan 2017 06:28:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2694; q=dns/txt; s=iport; t=1484317706; x=1485527306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=72RAvMQZw5mrB4m0szVDe5Wdze5sfy48xNq+TbezcOs=; b=f7oUV1qTgyteyHOEhMcmWXf2kwNQMECVUUwKP+E2Uhtu73sZCPXBWi1W bszYbcxulDU0Fvq+B918GdPoHPtJnqSpO1YxOO+bbS2UM8iqZRV0kd5QX U3E8/40hwG6kN0zM/XhxbrmLH6O3qKLUHp3NSEnp72XmnPNpVdl3F4P/x 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgBM43hY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR+BaJ9ukxuCD4INhiICghJBEgECAQEBAQEBAWMohGk?= =?us-ascii?q?BAQEDAQxtBQkCAgEIGCcHGxcUEQIEDgWIewiyeYoLAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHQWIQoJfhEaDM4IxBYh4hmeLUwGRWJBtkmQBJgwlgUQVSgGGH3OIZgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.33,221,1477958400"; d="scan'208";a="372363083" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jan 2017 14:28:25 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0DESPCj016585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2017 14:28:25 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 13 Jan 2017 08:28:24 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Fri, 13 Jan 2017 08:28:24 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund Thread-Topic: [MMUSIC] Transport tags Thread-Index: AQHSbE3p2SC5GZHiXUyd4kk6fM3mOqEzs4yAgACvV4CAAHqSgIAA1ReAgAADMACAAAZqgIAABU+AgAAExICAAAhlgIAArViA///+Bo4= Date: Fri, 13 Jan 2017 14:28:24 +0000 Message-ID: References: <6A083F67-4ECB-4703-A881-EB2F074F309E@cisco.com> <7594FB04B1934943A5C02806D1A2204B4BF6F650@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F72C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BF6F797@ESESSMB209.ericsson.se> , <0e376a55-f20b-b589-104a-6e34df5767e9@ericsson.com> In-Reply-To: <0e376a55-f20b-b589-104a-6e34df5767e9@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] Transport tags X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 14:28:28 -0000 It is possible and people already do use UDP/TLS/BFCP with ICE and without = any TCP candidates.=20 Cheers, Charles > On Jan 13, 2017, at 12:35 AM, Magnus Westerlund wrote: >=20 > Hi, >=20 > A question, is the UDP/DTLS/BFCP only used with ICE, or are they also use= d without ICE support. I wonders how this relates to the discussion that th= e UDP/TCP destinction becomes mote when one actually are doing ICE/DTLS/BFC= P, i.e. use ICE to agree on a datagram capable transport and then puts DTLS= /BFCP over it, independent on what transport type the arrived candidate pai= rs are on. >=20 > Is there a point to the BFCP usages to actually be explicit that we one o= nly want to use ICE negotiated DTLS secured BFCP, and thus should have a PR= OTO value for that, i.e. ICE/DTLS/BFCP? >=20 > Note, this is a question, not an actual proposal. Just an exploration so = that you who use the protocol can consider if it makes sense. >=20 > Cheers >=20 > Magnus >=20 >> Den 2017-01-12 kl. 23:15, skrev Roman Shpount: >> On Thu, Jan 12, 2017 at 4:45 PM, Christer Holmberg >> > >> wrote: >>=20 >> >I do not think TCP/DTLS/BFCP is defined anywhere, so it does not >> have to be backwards compatible. We are not changing the proto >> value, we should >define a new one and explain how it works. This >> leaves TCP/BFCP and TLS/BFCP as they were previously defined and >> simply states that these transports >cannot be used with ICE. Only >> UDP/DTLS/BFCP and TCP/DTLS/BFCP can be used with ICE, with ICE not >> supported for all the other BFCP flavors. >>=20 >> __ >>=20 >> __ __ >>=20 >> Ok, so TCP/BFCP and TLS/BFCP will still be kept in 4583bis, and >> should be used when ICE is not used?____ >>=20 >>=20 >>=20 >> TCP/BFCP, TLS/BFCP and UDP/BFCP will be kept in 4583bis and can only be >> used when ICE is not used. UDP/DTLS/BFCP and TCP/DTLS/BFCP are two >> transport that can be used with or without ICE. >>=20 >> Regards, >> _____________ >> Roman Shpount >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Fri Jan 13 11:08: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 9C7AC129410 for ; Fri, 13 Jan 2017 11:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 2Ds16gIrNQb0 for ; Fri, 13 Jan 2017 11:08:52 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF6E129C3F for ; Fri, 13 Jan 2017 11:08:51 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id k15so56103800qtg.3 for ; Fri, 13 Jan 2017 11:08:51 -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=v2Ye2VFIN3AObU1Vzu3oLUtL7OwAT8u49HSecXfz5/E=; b=QSGg1rwIHwNd+o16Kxc/xCJxGlT2r58wkkEJoc0vEphgJjH3D0bz8zdvg4ml4RBs5G Mf3MtT399ASzoZfzOYJ4Mxz1Ev1FNnGUM3FNcigiCavyJdXY80GPm8sdP+0i6A41Opof X71oIRoDPikL5h3jUuxHESooA1+mB6bLntpXoPNOta5fPKlTTBndlwpkmORYn7EXu40J YQWcLEu60/2hgoFays21hKmHJFLuauOZsg08YRJMzQxTtbKHqPj1eiDT1YQTSCWWVWTJ UQ0721el4sTPR4lEE27IVUEiFXg8aTxUIUzzvhDgOTwGORYQtHast/6o0imxhTX600t5 cvVQ== 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=v2Ye2VFIN3AObU1Vzu3oLUtL7OwAT8u49HSecXfz5/E=; b=MdCm3tuWPS6UhZBVEMQ7R7dtpL7YWtpu4FqdFoSgiawqiREl4t8M3oqlcYaQeEef2I swFAqFdY8s23DZRg/6Pm62Lk+hOa6OTKUiNLyIIWZAGeUJJvzflrqIrh+ip30i1T+iPz q0IL2jAxb9v16wlmkqHjUjQZ1D6McCmcnS9JyHX8ASa58O9ochSt8/Vtli027OMf7RKa PiEsvW+0MsTG6DXM5mNT2gVN3nhUIPgfJPEBwvHrD7dZvrvldXUdNhJc3ziv4Id2QCEZ ZvQM2zkzFYK9NWn5cZHlnxEBSOzGvGOAmSc+Yp0ZEN5EymcXpyrgxzv9R7eiKtyCb1Jt /3dA== X-Gm-Message-State: AIkVDXImqnLOiroB8SRUEf9F8IP6ecGLGFRJWZ9cIOHvwy9ihgd3WRcSChdZIu1lU3gWUw== X-Received: by 10.200.34.12 with SMTP id o12mr14461085qto.93.1484334530685; Fri, 13 Jan 2017 11:08:50 -0800 (PST) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com. [209.85.220.182]) by smtp.gmail.com with ESMTPSA id 21sm9874992qkh.13.2017.01.13.11.08.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:08:50 -0800 (PST) Received: by mail-qk0-f182.google.com with SMTP id u25so63810251qki.2 for ; Fri, 13 Jan 2017 11:08:50 -0800 (PST) X-Received: by 10.55.197.148 with SMTP id k20mr18955371qkl.34.1484334529930; Fri, 13 Jan 2017 11:08:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Fri, 13 Jan 2017 11:08:49 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Fri, 13 Jan 2017 14:08:49 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1149e640627a750545fe9037 Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding non-supported transport in m- line of answer X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:08:55 -0000 --001a1149e640627a750545fe9037 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As I have mentioned before, I think ALT#1 is a better option: If we propose mandatory to implement UDP based protocol for each transport family, only use the mandatory to implement protocol for the default candidate, and the transport mismatch problem will never occur. As a bit of background, this issue appeared because of TCP/BFCP, which was assumed to be the default protocol for BFCP with ICE. Since then, I think we have decided that TCP/BFCP is not going to be used with ICE. For all the other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DTLS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based protocol should be used for backwards compatibility. I also do not see a use case which will require that only tcp based candidates would be included in the offer or the answer. Because of this, I think mandatory to implement transport is a better approach. This also have additional benefits of: 1. Providing m=3D and c=3D line information which will not cause the ICE mismatch with older implementations 2. Not supplying any on the path signaling devices with bogus address information required in ALT#2 answer 3. Improves general chances of negotiation succeeding with end points not supporting ICE by picking the protocol more likely to succeed (chance of TCP/RTP/AVP succeeding, for instance, are much lower then RTP/AVP). Regards, _____________ Roman Shpount On Fri, Jan 13, 2017 at 7:00 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > The subject shall be ICE-SDP: Verify decision made=E2=80=A6 > > From: mmusic on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > Date: Friday 13 January 2017 at 13:32 > To: "mmusic@ietf.org" > Subject: [MMUSIC] SIP-SDP: Verify decision made in Seoul regarding > non-supported transport in m- line of answer > > Hi, > > In Seoul we discussed a number of issues related to ICE-SDP. We made some > decisions, and I got action points to verify one of those on the list. > > The associated slides can be found here: > > https://www.ietf.org/proceedings/97/slides/slides- > 97-mmusic-ice-sip-sdp-00.pdf > > > The issue (slides 4-6) was when an answerer receives an offer with a m- > line transport that it doesn=E2=80=99t support. The current O/A rules say= that the > transport in the answer must match the transport in the offer. > > However, if ICE is used, there may be transports (offered using ICE > candidates) that the answerer DOES support. > > Based on the discussions, there was strong consensus to go for Alt#2, > which was allowing a transport in the m- line of the answer even if the > answerer doesn=E2=80=99t support it, as ICE candidates will be used to de= termine > the transport. > > Does anyone object to Alt#2? > > Regards, > > Christer > > > > > > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a1149e640627a750545fe9037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I have mentioned before, I think ALT#1 is a better opti= on: If we propose mandatory to implement UDP based protocol for each transp= ort family, only use the mandatory to implement protocol for the default ca= ndidate, and the transport mismatch problem will never occur.

As a bit of background, this issue appeared because of TCP/BFCP, whic= h was assumed to be the default protocol for BFCP with ICE. Since then, I t= hink we have decided that TCP/BFCP is not going to be used with ICE. For al= l the other protocols that I know (UDP/DTLS/SCTP, UDP/TLS/RTP/SAVPF, UDP/DT= LS/BFCP, RTP/AVP, etc) there is a clear preference that UDP based protocol = should be used for backwards compatibility. I also do not see a use case wh= ich will require that only tcp based candidates would be included in the of= fer or the answer. Because of this, I think mandatory to implement transpor= t is a better approach.

This also have additional = benefits of:=C2=A0

1. Providing m=3D and c=3D line= information which will not cause the ICE mismatch with older implementatio= ns
2. Not supplying any on the path signaling devices with bogus = address information required in ALT#2 answer
3. Improves general = chances of negotiation succeeding with end points not supporting ICE by pic= king the protocol more likely to succeed (chance of TCP/RTP/AVP succeeding,= for instance, are much lower then RTP/AVP).

Regar= ds,

_____________
Ro= man Shpount

On Fri, Jan 13, 2017 at 7:00 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
The subject shall be ICE-SDP: Verify decision made=E2=80=A6

From: mmusic <mmusic-bounces@ietf.org> = on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Friday 13 January 2017 at 13:= 32
To: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: [MMUSIC] SIP-SDP: Verify d= ecision made in Seoul regarding non-supported transport in m- line of answe= r

Hi,

In Seoul we discussed a number of issues related to ICE-SDP. We made s= ome decisions, and I got action points to verify one of those on the list.<= /div>

The associated slides can be found here:



The issue (slides 4-6) was when an answerer receives an offer with a m= - line transport that it doesn=E2=80=99t support. The current O/A rules say= that the transport in the answer must match the transport in the offer.

However, if ICE is used, there may be transports (offered using ICE ca= ndidates) that the answerer DOES support.

Based on the discussions, there was strong consensus to go for Alt#2, = which was allowing a transport in the m- line of the answer even if the ans= werer doesn=E2=80=99t support it, as ICE candidates will be used to determi= ne the transport.

Does anyone object to Alt#2?

Regards,

Christer








=C2=A0




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

--001a1149e640627a750545fe9037-- From nobody Fri Jan 13 11:12:50 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 7ECB4129D80 for ; Fri, 13 Jan 2017 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 kn-Xk7RstKsn for ; Fri, 13 Jan 2017 11:12:42 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 7A36F129410 for ; Fri, 13 Jan 2017 11:12:42 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so56199297qtg.3 for ; Fri, 13 Jan 2017 11:12:42 -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=rTZ1a2GM090zG5fdXd9OTyoUTDlqNfjozY/Ssg56NWo=; b=SLq6RXsKn2Ni8+AULjIdQ0D5Gl2lKBggHzBRVj+l6osUA3IM+zdyXNZCewlxIVHUun qYFTAM0Zri4OsOGfIYXXO1EYKkfC0LJrmqtxQBxh2Tlkpg3IwyhfFjweMgsoQcxxix9p 517nYObMHHIWm85Cs2p4VwX2E6NZCNz9KQYMVkC2bflTViKIe6gTcXvZ3CRM+cwVheDl 3Q6faNIDUSnhumXRx1doQ5VibYAoa654O+pSbR7LVfRmfWess02uf9DxXO11R8SLhlC9 2eUCWp+K8TGDfaCx8Rnsfjrbwp+edZE7z5HfQgo/SLbZX3P8McGUcnS6R+w1jfq2aTQM cRPA== 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=rTZ1a2GM090zG5fdXd9OTyoUTDlqNfjozY/Ssg56NWo=; b=WPMGhbgX0rOkUnYInuxzEsaQmkoz/Q7KjqkqCJyRpgU/8ZfcGPlVBpdDQctLw55CxC mWxwlHbUAqishU/YZOZJ6BeC0zdYhyQpS0mCEStU1Sm/QzriLmHJsALTFRHgSYDvCaEA BCPM89l+zSw+lm2QqqaoHI0wtlNybYXMFd8GHSgcCd3XMOuLJpIh1QvuieyEGKnijZT6 dax/P4DQJRZkyaJr4t+16sTkt6oNKsM0TGdABzDHI3Dj9xa/i5poQN2pc8tF10jPwchm rX6NPLaxwDy3lIV1ayrQxSVRZnJLb9W5VUKgNmlrDtmBUv4+HNOZMCLCiv9+v8oVn+vc r4zQ== X-Gm-Message-State: AIkVDXK28O9lOZYH4hgRb03pWWzMEas8y/YXjyV3nHGYZMr8HNDWu0ib3//Dxj7ktc4Jsg== X-Received: by 10.200.56.211 with SMTP id g19mr18718342qtc.177.1484334761375; Fri, 13 Jan 2017 11:12:41 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id h124sm5005533qke.40.2017.01.13.11.12.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:12:41 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id l7so56419717qtd.1 for ; Fri, 13 Jan 2017 11:12:40 -0800 (PST) X-Received: by 10.237.50.101 with SMTP id y92mr21540747qtd.179.1484334760752; Fri, 13 Jan 2017 11:12:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Fri, 13 Jan 2017 11:12:40 -0800 (PST) In-Reply-To: References: From: Roman Shpount Date: Fri, 13 Jan 2017 14:12:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114d7daa2481d50545fe9e6b Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] ICE-SDP: Suggested text to clarify that an ICE transport switch does not require a new offer (in order to match the transport of the c/m- line with the transport of the new candidate) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:12:48 -0000 --001a114d7daa2481d50545fe9e6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This looks good to me. One related question, what happens if another candidate pair is selected during the time this updated offer is processed? This can cause offer and answer contain candidates that do not form the pair and use different transports. Regards, _____________ Roman Shpount On Fri, Jan 13, 2017 at 6:59 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > One of the issues that we were going to discuss in Seoul, but didn=E2=80= =99t have > much time for, was whether we should clarify that a ICE transport switch > (using a previously exchanged and verified ICE candidate pair) does not > require a new offer, in order to align the m- line with the new transport= . > > I got an action point in Seoul to suggest text for draft-ice-sep, and > below is my initial suggestion: > > 4.2. Subsequent Offer/Answer Exchanges > > Either agent MAY generate a subsequent offer at any time allowed by > [RFC3264]. The rules in Section 4.1.5 will cause the controlling > agent to send an updated offer at the conclusion of ICE processing > when ICE has selected different candidate pairs from the default > pairs. This section defines rules for construction of subsequent > offers and answers. > > Should a subsequent offer be rejected, ICE processing continues as if > the subsequent offer had never been made. > > > > As described in section 4.1.5, when ICE concludes, a subsequent offer = might be required in order to match the transport in the c/m- line of a med= ia stream with the transport of the the selected candidates. Once this has = been done, if an endpoint later starts to send media using another candidat= e, the endpoint does not need to send a subsequent offer (even if the trans= port in the c/m- line does no longer match the transport of the candidate). > > > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --001a114d7daa2481d50545fe9e6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks good to me.

One related ques= tion, what happens if another candidate pair is selected during the time th= is updated offer is processed? This can cause offer and answer contain cand= idates that do not form the pair and use different transports.
Regards,

_= ____________
Roman Shpount

On Fri, Jan 13, 2017 at 6:59 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

One of the issues that we were going to discuss in Seoul, but didn=E2= =80=99t have much time for, was whether we should clarify that a ICE transp= ort switch (using a previously exchanged and verified ICE candidate pair) d= oes not require a new offer, in order to align the m- line with the new transport.

I got an action point in Seoul to suggest text for draft-ice-sep, and = below is my initial suggestion:

4.2.  Subsequent Offer/Answer Exchanges

   Either agent MAY generate a subsequent offer at any time allowed by
   [RFC3264].  The rules in Section 4.1.5 will cause the controlling
   agent to send an updated offer at the conclusion of ICE processing
   when ICE has selected different candidate pairs from the default
   pairs.  This section defines rules for construction of subsequent
   offers and answers.

   Should a subsequent offer be rejected, ICE processing continues as if
   the subsequent offer had never been made.
   <new>
   As described in section 4.1.5, when ICE concludes, a subsequ=
ent offer might be required in order to match the transport in the c/m- lin=
e of a media stream with the transport of the the selected candidates. Once=
 this has been done, if an endpoint later starts to send media using anothe=
r candidate, the endpoint does not need to send a subsequent offer (even if=
 the transport in the c/m- line does no longer match the transport of the c=
andidate).
   </new><=
/span>
Regards,<=
/pre>

Christer<=
/pre>

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

--001a114d7daa2481d50545fe9e6b-- From nobody Sun Jan 15 04:52:07 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 14C6F12943B; Sun, 15 Jan 2017 04:52:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148448472304.28589.3882803498707317905.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2017 04:52:03 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 12:52:03 -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 of the IETF. Title : SDP-based Data Channel Negotiation Authors : Keith Drage Maridi R. Makaraju Juergen Stoetzer-Bradler Richard Ejzak Jerome Marcon Filename : draft-ietf-mmusic-data-channel-sdpneg-11.txt Pages : 41 Date : 2017-01-15 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-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 Mon Jan 16 04:06: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 85A3512946D; Mon, 16 Jan 2017 04:05:59 -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 15Wo7uUB9azv; Mon, 16 Jan 2017 04:05:57 -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 246F4129463; Mon, 16 Jan 2017 04:05:53 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-aa-587cb26f6a45 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id D4.73.25710.F62BC785; Mon, 16 Jan 2017 12:45:51 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Jan 2017 12:46: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=jVIsINXnhxUGepzRqfxICq7T6nlxbdFEJpB/84t/f2c=; b=CoEEzGVm4aYAObQJjXcaAkcxcwWLxO3tzQjiZQzRRJQgEM9kYRjlOSAoQumdUo6JkbsyWrky/HuAyO11tW+rru1EeRUe/Aa1QG29JqZyjRRB4YaSzMb2HDWh1Gek6BgoKEURzVvVJg7UCxrqGHmZp2kK59JW42S8IE5L6SYDnyU= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2580.eurprd07.prod.outlook.com (10.173.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Mon, 16 Jan 2017 11:45:21 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.0860.008; Mon, 16 Jan 2017 11:45:21 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdJv7ZUuiNGS7gCVTiuOvOx9KcHY1A== Date: Mon, 16 Jan 2017 11:45:21 +0000 Message-ID: Accept-Language: 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.84] x-ms-office365-filtering-correlation-id: d89f3865-0ff2-4c07-00ce-08d43e052706 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0701MB2580; x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2580; 7:bn9cVno5+HwTNkyCNIPH8w/u4qhGQxLNRhiMOACzoFocIMb9Gnpj0FLYBqwL7m6grHSaMmaY20VxoWtm1t8rqkRQG6BYyQpp6MLUdNnaPxDcPCv5ks22gegVkKtVa5R5TDI8dXT+ibUAHkq7so/T6ngctebEgsQKDxRBL5qT3nIaFXrrr5Aruo4lBEDQs+KPfCLGudsgHfJubpooyHR8ErpoR9oJd+uFmO5eVG+1wZXHnTnvMq0DohWUYoyDGWfP3T0Vhe7uNP1qz6w142Xv62m+4FjveOBcZujJuPBVU1DmH6AaJVPthEpSiH/E+yIdIcqcnORxHgipQRU5qB76wN4BaACB6qlV9Kqx1+dgRgVeD7GvyQdCv8BOWXxpPIXwKcN2lNMY0II/lw8nEr+q9kY+nc7kLVCmfZwbdduaOdHOp6dN0wK/X4W4ryf1ws+b8DsO4hxNrDeYxE04vS7QdQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:AM5PR0701MB2580; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2580; x-forefront-prvs: 01894AD3B8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(199003)(606005)(25786008)(236005)(74316002)(9686003)(54356999)(101416001)(3660700001)(92566002)(3280700002)(97736004)(7906003)(7696004)(54896002)(6306002)(50986999)(110136003)(99286003)(55016002)(86362001)(5660300001)(6436002)(122556002)(33656002)(189998001)(450100001)(68736007)(6506006)(38730400001)(77096006)(106356001)(7736002)(6916009)(66066001)(8936002)(105586002)(102836003)(19609705001)(8676002)(2906002)(3846002)(790700001)(6116002)(81156014)(81166006)(230783001)(2900100001)(27001)(4326007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2580; H:AM5PR0701MB2577.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: multipart/alternative; boundary="_000_AM5PR0701MB2577808960A0AE88E584E3AB8D7D0AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2017 11:45:21.5685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2580 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUyM2K7vW7+ppoIg02ftS0WbdjKbDF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlPGh8y1rQp14xramfuYHxrWIXIweHhICJxL9rOV2M XBxCAusYJY5fuscG4ZxglFh4eyYLiMMi0Mss8fHWNxaIzAwmiYuvzjHBlZ2eOx0ow8nBJqAh MX/HXUYQW0TAQGL2yhlgNrNAvsTR7b/BbGEBJ4kff2+xQNS4SzT17WeDsPUkLh//yApiswio Sqzvu8sOYvMKJEgce78YLM4oICbx/dQaJoiZ4hK3nswHsyUEBCSW7DnPDGGLSrx8/A+qPlJi 8sSz7BBxBYlX3Q1sELavxOuXV6Hi/hLLFn5gBHlGQqCPRWL2gs1Qg/Ilrt7axwphe0sc2nOQ FaqISeLa+r9Qk2Qkdsx5zgaRuMgqMe/+MrDXhARSJZavbYV6WUri7pVOKFtG4sWdvaygoAcF y4vFChMY1WcheWgWQmYW2P+CEidnPmGBKNGRWLD7ExuErQ1092tmGPvMgcdMyOILGNlXMYoW pxYX56YbGeulFmUmFxfn5+nlpZZsYgQmnYNbfuvuYFz92vEQowAHoxIP74Zj1RFCrIllxZW5 hxglOJiVRHj3ra+JEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyW iYNTqoFRIlzzz/r0/xtLxH6lzoxb5erLe/y+gW1O9uHGiF/vvjxnZH3TLyyowj5pt7/sjYOq J5qF+H/YNXU4W/N0bq/PcvuSH7o76F/ag8QDwv+ZxIo4blyRZbOc0L/5RZrR0Ueeb04qWDa6 rf+xcO7Jq0zpDb9tmWZ9qEoRub/xT75Q0ov8GzGqp2crsRRnJBpqMRcVJwIAXW6QiDYDAAA= Archived-At: Cc: "draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org" Subject: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 12:05:59 -0000 --_000_AM5PR0701MB2577808960A0AE88E584E3AB8D7D0AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC, This email starts a one week WG last call on version -11 of this draft that= ends on January 23, 2017. There was a previous WG last call on version -09 that resulted in some mino= r document updates. The intended status of this document is standards track (Proposed Standard)= . Please review and provide any comments you may have on the document. Commen= ts should be sent to the document authors and the MMUSIC WG list. If you re= view the document but do not have any comments, please send a note to that = effect as well. Please also forward this WGLC to any other interested parties who may be ab= le to review the draft, asking them to also direct their comments to the au= thors and the list as above. The document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ Thank you! Bo Burman (MMUSIC co-chair) --_000_AM5PR0701MB2577808960A0AE88E584E3AB8D7D0AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

This email starts a one week WG last call on version= -11 of this draft that ends on January 23, 2017.

There was a previous WG last call on version -09 tha= t resulted in some minor document updates.


The intended status of this document is standards track (Proposed Standard)= .

Please review and provide any comments you may have on the document. Commen= ts should be sent to the document authors and the MMUSIC WG list. If you re= view the document but do not have any comments, please send a note to that = effect as well.

 

Please also forward this WGLC to any other intere= sted parties who may be able to review the draft, asking them to also direc= t their comments to the authors and the list as above.

 

The document can be retrieved here:

https://datatracker.ietf.org/doc/draft-ietf= -mmusic-data-channel-sdpneg/

 

Thank you!

 

        Bo Bur= man (MMUSIC co-chair)

 

--_000_AM5PR0701MB2577808960A0AE88E584E3AB8D7D0AM5PR0701MB2577_-- From nobody Mon Jan 16 05:18:37 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 DE77C129490 for ; Mon, 16 Jan 2017 05:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 1mKgpNFfIPgf for ; Mon, 16 Jan 2017 05:18:34 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 28962129487 for ; Mon, 16 Jan 2017 05:18:34 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id w75so68038637ywg.1 for ; Mon, 16 Jan 2017 05:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8hR5fGuuhvjfA4Xg63OIUmRPfrmValab4vDAiJYwiN4=; b=V++ve2tn4ga+onvl638FwlA7wKRsZ/kL+rSqgCuDs6VfSrs1aaiHztatNujV6jyy6Y /Zc3c4Act8LkFkejK194saGUOdONaCDMNR4FOksoeJwTi8xOcx5rMakSm8PqZpNGYz1J 6D4E806TyrU/jKuk13ayhEu9sUyAcnkx0W+kOlMC7Q3MChldNjOZuoA0xd2Vf4y1/Z7m WDhJGYz86BPTnl/I0AKcAUyxWzwfuLV5YFobZc8cZeQLs/VRdJSHJyHwCv5+TFuUzkxu R7/rotofy0lSNts1jEm0YdaQG4NufMYX/Z4iqhTLUucF0yh48SALiBj8QWp/Ryrm334b 2Z6Q== 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=8hR5fGuuhvjfA4Xg63OIUmRPfrmValab4vDAiJYwiN4=; b=pKKQznXjWAagfpudp1fJLzy5CVqk8NPEwh2gtv3L7/5Mi5TJ2r5fbAQ46fDmqUp6zL 5hdaSQyJsNQDzdjZHHl7N71cRTieH48j9L2Q/CgKvFhfeID/UWywAJBIQ2j4wLu/HOo4 B+MX8bfafPCubWTdgEWPwtycafPDK/rb/PxIrjOMczVy60EuDdkA+RgQVXhkYWZMz+Fp foxOtPXVBZAH10a3dOvxC7tHefMQuIVfGKHL1DA7zTsJAc+uee+duzXHrVActa1Zggdw lhRIjTORC6wMw6eaht0K//HGU9hwE2XyqOuLhrSsqI3nkhCTbMI8nehbgtDUdG+pwFOQ JuJQ== X-Gm-Message-State: AIkVDXK65W0l/fDd8jmEF4bkjcKIHerFNse9u2/+0ejrf8V66RGmerF8ywZsiALbppGaJFaEjve4+Cl/KYM3Ww== X-Received: by 10.129.53.134 with SMTP id c128mr25346206ywa.205.1484572713281; Mon, 16 Jan 2017 05:18:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 05:17:52 -0800 (PST) In-Reply-To: <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> From: Eric Rescorla Date: Mon, 16 Jan 2017 05:17:52 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a11409744382a3605463605d5 Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 13:18:36 -0000 --001a11409744382a3605463605d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 7:44 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand: > >> Den 22. des. 2016 18:30, skrev Eric Rescorla: >> >>> __ >>> >>> Okay, I agree that having any rules for what you should offer here >>> based on what the actual outcome is not the best idea here. I think >>> the rules should be based on capability and intent. So if you only >>> are going offer TCP candidates, then you clearly should use TCP/=E2= =80=A6, >>> >>> >>> I'm going to push on this. If we've already agreed that mismatches are >>> normal, why should we do that? Wouldn't it be better to just effectivel= y >>> deprecate this field? >>> >>> >> Concur with EKR. >> >> This field (the TCP/UDP part of the protocol field) was defined in a way >> that makes its original purpose (to negotiate profiles) not only >> impossible while using ICE, but actively harmful, because you end up >> telling lies in very many cases, so people will have to accept things >> that don't match reality. >> >> Make the world as simple for implementors as possible: Send a fixed >> string, and accept all strings. >> >> > Okay, can we please be precise with what is suggested here. Because what > you write above, and what EKR proposed is not really the same thing. The > issue proposed that it was fine to set either of the strings. You saying = a > fixed string. I want to ask you which UDP/... or TCP/..., or even > ICE/DTLS/RTP/SAVPF? > > From a strict clarity issue using ICE/... would be my preferred. But, tha= t > is probably going to throw some implementations, especially gateways. It > will also require us to actually go write the registration to explain wha= t > it is. > > Using UDP is likely the most compatible and will only fail in gateway > cases where there are no UDP candidates and the gateway fail to pick that > up. > > Using TCP when there are no TCP candidates are equally misleading to > gateway cases. > > The above is why I proposed that implementation capabilities and any > configuration to limit what functions being used would be an appropriate > choice. > > I hope at least we can agree that an JSEP Answer MUST use the PROTO strin= g > of the OFFER? Yes. I think implementations should offer UDP/ (ICE/ will cause problems) and in the answer echo the offer. -Ekr > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11409744382a3605463605d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 7:44 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Den 2017-01-02 kl. 14:42, skrev Harald Alvestrand:<= br>
Den 22. des. 2016 18:30, skrev Eric Rescorla:
=C2=A0 =C2=A0 =C2=A0__

=C2=A0 =C2=A0 Okay, I agree that having any rules for what you should offer= here
=C2=A0 =C2=A0 based on what the actual outcome is not the best idea here. I= think
=C2=A0 =C2=A0 the rules should be based on capability and intent. So if you= only
=C2=A0 =C2=A0 are going offer TCP candidates, then you clearly should use T= CP/=E2=80=A6,


I'm going to push on this. If we've already agreed that mismatches = are
normal, why should we do that? Wouldn't it be better to just effectivel= y
deprecate this field?


Concur with EKR.

This field (the TCP/UDP part of the protocol field) was defined in a way that makes its original purpose (to negotiate profiles) not only
impossible while using ICE, but actively harmful, because you end up
telling lies in very many cases, so people will have to accept things
that don't match reality.

Make the world as simple for implementors as possible: Send a fixed
string, and accept all strings.


 Okay, can we please be precise with what is suggested here. Because what yo= u write above, and what EKR proposed is not really the same thing. The issu= e proposed that it was fine to set either of the strings. You saying a fixe= d string. I want to ask you which UDP/... or TCP/..., or even ICE/DTLS/RTP/= SAVPF?

>From a strict clarity issue using ICE/... would be my preferred. But, that = is probably going to throw some implementations, especially gateways. It wi= ll also require us to actually go write the registration to explain what it= is.

Using UDP is likely the most compatible and will only fail in gateway cases= where there are no UDP candidates and the gateway fail to pick that up.
Using TCP when there are no TCP candidates are equally misleading to gatewa= y cases.

The above is why I proposed that implementation capabilities and any config= uration to limit what functions being used would be an appropriate choice.<= br>
I hope at least we can agree that an JSEP Answer MUST use the PROTO string = of the OFFER?

Yes. I think implementations = should offer UDP/ (ICE/ will cause problems) and in the answer echo the off= er.

-Ekr
=C2=A0


Cheers

Magnus Westerlund

-----------------------------------------------------------------= -----
Services, Media and Network features, Ericsson Research EAB/TXM
-----------------------------------------------------------------= -----
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
-----------------------------------------------------------------= -----

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

--001a11409744382a3605463605d5-- From nobody Mon Jan 16 05:28: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 8AD74129436 for ; Mon, 16 Jan 2017 05:28:45 -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 PDyBmyutv_v2 for ; Mon, 16 Jan 2017 05:28:44 -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 5AA9812896F for ; Mon, 16 Jan 2017 05:28:44 -0800 (PST) X-AuditID: c1b4fb25-9cfc898000002ee9-18-587cca8a4835 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 70.24.12009.A8ACC785; Mon, 16 Jan 2017 14:28:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Mon, 16 Jan 2017 14:28:40 +0100 From: Christer Holmberg To: Eric Rescorla , Magnus Westerlund Thread-Topic: [MMUSIC] JSEP Issue #394: What appears in m= lines. Thread-Index: AQHSXHlOCQ7BQRm6Y0eHkrCi1urD06ElMmaAgAy0twCACUUOAIAAJN0A Date: Mon, 16 Jan 2017 13:28:39 +0000 Message-ID: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.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.1.161129 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D4A2966B15C88christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7rm7XqZoIgxXvtS1WvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJXxZvIDpoIOsYqLBxaxNjAuFOpi5OSQEDCR WPjoPRuILSSwjlHiSEN4FyMXkL2EUeLXljamLkYODjYBC4nuf9ogNSICYRKrb51hBLGZBeQl LixZwwRiCws4SBzbuZYFosZRYte6LlaQVhEBN4lf//1BwiwCqhKvDsxnBAnzClhLvN7HDrHp BJPEvslvWUFqOAUCJU7eWsUMYjMKiEl8PwUxnllAXOLWk/lMECcLSCzZc54ZwhaVePn4H1iv qICexPLna6DiihIfX+2DOjNBYuq/NrA4r4CgxMmZT1gmMIrOQjJ2FpKyWUjKIOIGEu/PzWeG sLUlli18DWXrS2z8cpYRwraW+PfhD4qaBYwcqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjEC Y/Dglt+qOxgvv3E8xCjAwajEw7vhWHWEEGtiWXFl7iFGCQ5mJRHehOM1EUK8KYmVValF+fFF pTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwigsc+Pxrh8auoDqTJ2/mSFVI P178/8HTbrdnZxpUuT0+LloV9S/YzYrTxmjJ9UxVqzUPqy21X3R+e2d7OtSh736e2vapd/4n 2wikdwY2hp/++e2Kh7tMkbPukR1bWSb0vJq8ke/0qohtj4/OeX+p66tdtexvnZzEn0/zjjCI X7wpctb3iPT73UosxRmJhlrMRcWJAPUqi6a9AgAA Archived-At: Cc: mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 13:28:45 -0000 --_000_D4A2966B15C88christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, =85 >>I hope at least we can agree that an JSEP Answer MUST use the PROTO strin= g of the OFFER? > >Yes. I think implementations should offer UDP/ (ICE/ will cause problems) = and in the answer echo the offer. This is related to the generic issue I raised in Seoul, and sent an e-mail = about last week: is it ok to echo the transport in the m- line proto value = of the answer even if the answerer doesn=92t support the transport (alt #1)= ? OR, should we mandate a transport that everyone must support, and mandate t= o use that transport as m- line proto value in offers and answers (alt #2)? People in Seoul preferred alt #1, but I know that at least Roman prefers al= t #2. Regards, Christer --_000_D4A2966B15C88christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

=85

>>I hope at least we can agree that an JSEP Answer MUST use the = PROTO string of the OFFER?
>
>Yes. I think implementations should offer UDP/ (ICE/ will cause pr= oblems) and in the answer echo the offer.

This is related to the generic issue I raised in Seoul, and sent an e-= mail about last week: is it ok to echo the transport in the m- line proto v= alue of the answer even if the answerer doesn=92t support the transport (al= t #1)?

OR, should we mandate a transport that everyone must support, and mand= ate to use that transport as m- line proto value in offers and answers (alt= #2)?

People in Seoul preferred alt #1, but I know that at least Roman prefe= rs alt #2.

Regards,

Christer


 --_000_D4A2966B15C88christerholmbergericssoncom_-- From nobody Mon Jan 16 05:45: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 E5B1612942F for ; Mon, 16 Jan 2017 05:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 L2orjqrQKFt9 for ; Mon, 16 Jan 2017 05:45:48 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 8D550120725 for ; Mon, 16 Jan 2017 05:45:48 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id w194so30378159ybe.0 for ; Mon, 16 Jan 2017 05:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/g/Iy5oFu+GQ+JUC7VyFOGo/qrhfGtQRn5j64JLJxI=; b=ns3BBa3OnO5R+IBV6wiWstsrdg0MNpksICbYZFAk1IGljgSTOKo9El6RGXMu5YipFO etEZD3fMCYiirdzTSUfuMQU/TTwbXGSUpnva9tscOfk97S1Fuqgqq6enMjqajL3ZYpGC oJyI4SGjacq5LpNOIdRobJ8XHqO51SBseAuIuS5Fj51laMkkZ3JVCUZU+0jjmoSVmR5H H29uCiVsCwYvGh0y56JIb9zoZxqCLG2DC5DksI1/JzkOX0unw4p6tQPMW1/YINXD9mp+ /Yarq7W8dvqGpg05iS5eBTkQxD5tJSAGWZuNJ4mjySnJbyfrzkVEv6c7K2xaHWgNscmB DU1w== 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=F/g/Iy5oFu+GQ+JUC7VyFOGo/qrhfGtQRn5j64JLJxI=; b=Kg7ubuMsxNnBscNbdKFSTkP/idEdS9IqGKSFUD9dqChdl9g0VXsP/IaCEz/yhLEy2a IIlIAS5QI6gcEIZbrInRyB0i91a/aFlfAr6ak+7EfCpIy/WlNC8N0shls6vzb1JPhyid J3W7hP6w66iMUPTe+/qWBR4ZNI0je6GKDWjEu7FlF8xmaySY1WbvxkVfesYTot2updvn +QUK2162pADSiZr604H1HgYGg8M14Cdg2QGl6ch2b/FhUq7PXJrMl3awpol+o4UTSN8i 1zquEyIzcnhVBlyu/mfRHOchy5+XIHTUvj43jUTZkewHdOFciOLvCqpRjCuGsZZ50eZe eMWA== X-Gm-Message-State: AIkVDXKzSCEVYZOELSO9vmHfztTpOH5Nmnhc1+iX7MQkqh3L9jHgnCEOs5eB+zJQ1otIN4Vo3j1nT/dMwp/rsg== X-Received: by 10.37.201.196 with SMTP id z187mr3342161ybf.161.1484574347595; Mon, 16 Jan 2017 05:45:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 05:45:07 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> From: Eric Rescorla Date: Mon, 16 Jan 2017 05:45:07 -0800 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114d88eaa1cd38054636662f Archived-At: Cc: Magnus Westerlund , mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 13:45:50 -0000 --001a114d88eaa1cd38054636662f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2017 at 5:28 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > =E2=80=A6 > > >>I hope at least we can agree that an JSEP Answer MUST use the PROTO > string of the OFFER? > > > >Yes. I think implementations should offer UDP/ (ICE/ will cause problems= ) > and in the answer echo the offer. > > This is related to the generic issue I raised in Seoul, and sent an e-mai= l > about last week: is it ok to echo the transport in the m- line proto valu= e > of the answer even if the answerer doesn=E2=80=99t support the transport = (alt #1)? > > OR, should we mandate a transport that everyone must support, and mandate > to use that transport as m- line proto value in offers and answers (alt #= 2)? > > People in Seoul preferred alt #1, but I know that at least Roman prefers > alt #2. > I continue to support #1. We should just stop trying to pretend that this value has useful semantics. -Ekr > > Regards, > > Christer > > > --001a114d88eaa1cd38054636662f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 5:28 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi,

=E2=80=A6

>>I hope at least we can agree that an JSEP Answer MUST use the = PROTO string of the OFFER?
>
>Yes. I think implementations should offer UDP/ (ICE/ will cause pr= oblems) and in the answer echo the offer.

This is related to the generic issue I raised in Seoul, and sen= t an e-mail about last week: is it ok to echo the transport in the m- line = proto value of the answer even if the answerer doesn=E2=80=99t support the = transport (alt #1)?

OR, should we mandate a transport that everyone must support, and mand= ate to use that transport as m- line proto value in offers and answers (alt= #2)?

People in Seoul preferred alt #1, but I know that at least Roman prefe= rs alt #2.

I continue to suppor= t #1. We should just stop trying to pretend that this value has useful sema= ntics.

-Ekr
=C2=A0

Regards,

Christer

--001a114d88eaa1cd38054636662f-- From nobody Mon Jan 16 08:10:07 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 60EDA129588 for ; Mon, 16 Jan 2017 08:10: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_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 WdgjNAmteYj0 for ; Mon, 16 Jan 2017 08:10:05 -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 C046212958A for ; Mon, 16 Jan 2017 08:10:04 -0800 (PST) X-AuditID: c1b4fb30-3136f98000003c8a-40-587cf05a0ea8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 7A.8E.15498.A50FC785; Mon, 16 Jan 2017 17:10:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Mon, 16 Jan 2017 17:09:50 +0100 From: Christer Holmberg To: Eric Rescorla Thread-Topic: [MMUSIC] JSEP Issue #394: What appears in m= lines. Thread-Index: AQHSXHlOCQ7BQRm6Y0eHkrCi1urD06ElMmaAgAy0twCACUUOAIAAJN0A///iwICAADeE8A== Date: Mon, 16 Jan 2017 16:09:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7n27Uh5oIgwnvbSxWvD7HbjF1+WMW ByaPJUt+MnlMftzGHMAUxWWTkpqTWZZapG+XwJWx/VIbS8Eb7orfE5UbGI9wdzFyckgImEgs WP6BvYuRi0NIYB2jxN7WeSwQzhJGiQdPdzB1MXJwsAlYSHT/0wZpEBFQkPj15wQLiM0sECqx 6dU+MFtYwEFi06RJbBA1jhK71nWxQthhEtt2TwCrYRFQlVg/aQc7iM0r4Cvx5vsfqMUHmSXe 3+gFK+IUCJTY+mMBI4jNKCAm8f3UGiaIZeISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWwliUW3 P4PdzCygKbF+lz5Eq6LElO6HUHsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTc dCMjvdSizOTi4vw8vbzUkk2MwBg5uOW3wQ7Gl88dDzEKcDAq8fB+uF8TIcSaWFZcmXuIUYKD WUmEN/4FUIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbG tCbvza7Jm74tar6zO9Xv7uEFOx1n7188LU/AXOJVp2hrcfLGi4FluSqnc+Zdkxc937nGqtQ2 8OkGwddCH/x2fpdbx9v4RueE/NoSR+OMdWpaa/qEKy5dqrzc8y4ypziWMZpRdU5jz7r91Yw2 kgey4i4WtKk8MTV+z37JYk9JnG2zpaek5AolluKMREMt5qLiRAD5ptrejQIAAA== Archived-At: Cc: Magnus Westerlund , mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 16:10:06 -0000 SGksDQoNCuKApg0KDQo+Pj4+SSBob3BlIGF0IGxlYXN0IHdlIGNhbiBhZ3JlZSB0aGF0IGFuIEpT RVAgQW5zd2VyIE1VU1QgdXNlIHRoZSBQUk9UTyBzdHJpbmcgb2YgdGhlIE9GRkVSPw0KPj4+Pg0K Pj4+WWVzLiBJIHRoaW5rIGltcGxlbWVudGF0aW9ucyBzaG91bGQgb2ZmZXIgVURQLyAoSUNFLyB3 aWxsIGNhdXNlIHByb2JsZW1zKSBhbmQgaW4gdGhlIGFuc3dlciBlY2hvIHRoZSBvZmZlci4NCj4+ DQo+PiBUaGlzIGlzIHJlbGF0ZWQgdG8gdGhlIGdlbmVyaWMgaXNzdWUgSSByYWlzZWQgaW4gU2Vv dWwsIGFuZCBzZW50IGFuIGUtbWFpbCBhYm91dCBsYXN0IHdlZWs6IGlzIGl0IG9rIHRvIGVjaG8g DQo+PiB0aGUgdHJhbnNwb3J0IGluIHRoZSBtLSBsaW5lIHByb3RvIHZhbHVlIG9mIHRoZSBhbnN3 ZXIgZXZlbiBpZiB0aGUgYW5zd2VyZXIgZG9lc27igJl0IHN1cHBvcnQgdGhlIHRyYW5zcG9ydCAo YWx0ICMxKT8NCj4+DQo+PiBPUiwgc2hvdWxkIHdlIG1hbmRhdGUgYSB0cmFuc3BvcnQgdGhhdCBl dmVyeW9uZSBtdXN0IHN1cHBvcnQsIGFuZCBtYW5kYXRlIHRvIHVzZSB0aGF0IHRyYW5zcG9ydCBh cyBtLSBsaW5lIHByb3RvIHZhbHVlIGluIG9mZmVycyBhbmQgYW5zd2VycyAoYWx0ICMyKT8NCj4+ DQo+PiBQZW9wbGUgaW4gU2VvdWwgcHJlZmVycmVkIGFsdCAjMSwgYnV0IEkga25vdyB0aGF0IGF0 IGxlYXN0IFJvbWFuIHByZWZlcnMgYWx0ICMyLg0KPg0KPiBJIGNvbnRpbnVlIHRvIHN1cHBvcnQg IzEuIFdlIHNob3VsZCBqdXN0IHN0b3AgdHJ5aW5nIHRvIHByZXRlbmQgdGhhdCB0aGlzIHZhbHVl IGhhcyB1c2VmdWwgc2VtYW50aWNzLg0KDQpBcyAjMSB3YXMgYWxzbyB0aGUgb3V0Y29tZSBvZiBT ZW91bCwgSSB0aGluayB3ZSBzaG91bGQgbW92ZSBhaGVhZCB3aXRoIGl0LiBDaGFpcnM/DQoNCk5v dGUgdGhhdCAjMSBkb2VzIG5vdCBwcmV2ZW50IGluZGl2aWR1YWwgcHJvdG9jb2xzIGZyb20gZGVm aW5pbmcgTVRJIHRyYW5zcG9ydHMsIGRlZmF1bHQgbS0gbGluZSBwcm90byB2YWx1ZXMgZXRjLCAg YnV0IGl0IHdvdWxkIG5vdCBiZSBhIGdlbmVyYWwgcmVxdWlyZW1lbnQgdG8gZG8gc28uDQoNClJl Z2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From nobody Mon Jan 16 11:56:07 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 EFBB41299F6 for ; Mon, 16 Jan 2017 11:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 1apSNPcnlSXj for ; Mon, 16 Jan 2017 11:56:04 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 C37D41299F7 for ; Mon, 16 Jan 2017 11:56:04 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-05v.sys.comcast.net with SMTP id TDN3c6D3CMqbUTDNrcxHJ2; Mon, 16 Jan 2017 19:56:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484596563; bh=OGbC2nGYKDKOcuXtMdplCK9y6RfkWRy3qHUdT9DtLF4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MZvlkqRPL8fm+Cq79QJvZKvD1rmwCnjl2pyc1ZSNAxqKT9IOPJlLj60nYR8qJuc86 GQyDqpJDwoLgL1KNrl4VXV/8zEn3uLR5m6nMYpeXfP4iFiaZ6YsaXikG8imtNjzuga hl0aKQpSoTYHsx2m8j3rzXnD8CqKcG6pVPTKwsqzPowVOUSsCvH+K+gUtWaEXlv/oZ 2/X34C/cUothhQxIhZh8FapMkUK4Mff06vagQXo/3s2JGF7J5GqgqvSK3trMNrXi7M wwxHSt0unkk9t8r4lSjX1qKlOmAmgsZ1Oqb42H9B4Jc/LwYlge2u1UqWLe6mbWspSV NTXpFD1caVYSQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id TDNqcHNjNTnqpTDNrcETgC; Mon, 16 Jan 2017 19:56:03 +0000 To: mmusic@ietf.org References: From: Paul Kyzivat Message-ID: Date: Mon, 16 Jan 2017 14:56:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 19:56:06 -0000 I've followed this document closely throughout its development. In preparation for this message I reviewed the document again. I found some things that need to be addressed: 1) MAJOR: Section 5.1.1.3 and various other places: I can find nothing here or elsewhere in the document that says whether the the stream id in an offer is the id on which the offerer will receive, or the ID on which it will send. Of course this is irrelevant if both ends agree to use the same id, but that isn't required. For this to interact properly with attributes for individual streams (in dcsa) I think it will be necessary for this to be consistent with the say SDP negotiates media sections - namely that the SDP in an offer identifies where the offerer wants to *receive* the media. It will probably require changes in a variety of places to get this sorted out. 2) MINOR: Section 5.1.1 says: The intention in exchanging these attributes is to create, on two peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched pairs of oppositely directed data channels having the same set of attributes. It is assumed that the data channel properties (reliable/partially reliable, ordered/unordered) are suitable per the subprotocol transport requirements. In this, "matched pairs of oppositely directed data channels" is improper terminology. Each channel *is* a matched pair, of oppositely directed SCTP streams. 3) MINOR: Section 5.1.2 says: In the SDP, each data channel declaration MAY also be followed by other media level SDP attributes, ... I'm concerned with "followed", because that imposes an ordering requirement on attributes. Generally there is no ordering requirement on SDP attributes other than that they up front if they are session level or follow a particular m= line if they are media-level. Certainly it will be more readable to group these things in a logical way, but I don't think it should be required. So I suggest changing "followed" to "accompanied". 4) NIT: IdNits reports 1 error and 8 warnings. These need to be addressed. Thanks, Paul On 1/16/17 6:45 AM, Bo Burman wrote: > MMUSIC, > > > > This email starts a one week WG last call on version -11 of this draft > that ends on January 23, 2017. > > There was a previous WG last call on version -09 that resulted in some > minor document updates. > > > The intended status of this document is standards track (Proposed Standard). > > Please review and provide any comments you may have on the document. > Comments should be sent to the document authors and the MMUSIC WG list. > If you review the document but do not have any comments, please send a > note to that effect as well. > > > > Please also forward this WGLC to any other interested parties who may be > able to review the draft, asking them to also direct their comments to > the authors and the list as above. > > > > The document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ > > > > Thank you! > > > > Bo Burman (MMUSIC co-chair) > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Jan 16 15:37: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 6605B129442 for ; Mon, 16 Jan 2017 15:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 hxAlTUubt-3H for ; Mon, 16 Jan 2017 15:37:56 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 9486C1204D9 for ; Mon, 16 Jan 2017 15:37:56 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id k15so127991473qtg.3 for ; Mon, 16 Jan 2017 15:37:56 -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=FdhRRk/WVBg4NobVLpCrzyiYM1oRSb1SJQwZRJsPsXY=; b=Gp2kbI3xRklZRCunUAxaYDcOv5HnDhDF/t/wTjNP194/MhVDqUoVKUdhniuqzrtx6u IOVW6Ubo6FN8YKvMPtFGfVX7U78m5y4Eb1Cf23nO0sTGmNHIoWShB5oEWr7GHs2dZpRK 52s1uRkrSsOlZGQE+L4sVcKZLCNBXHlncAYb5oERC7cxkBeFPWJHWWMGD86CsRkhOQ1k cprre75+hoFjVuuxtRXDwz0hSDciBHpT8i+07iOGJebu4pO6oUTWNDuM6HRQ0iBVClZe odNqWoNLmbTSqnpBYF9phB4kOVBaaD4sFjxyHQpplRuGO9Z0DtlwZuib00n4LbmMjuAv +ydg== 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=FdhRRk/WVBg4NobVLpCrzyiYM1oRSb1SJQwZRJsPsXY=; b=dW8e/A4j2yYaAdBqjDk0P+3fXPG+sSl8o7OaBltd9suQg3mN7mgSvccViMIBuxZC17 KzLr8BU0rHNCpgpBIkwOgVYHOL3Y5ocEJ/rUWNLXxZCVoYW9zRUUldYB++M9e+/vVDju hHQ8X7h7v4/1vhieVJRcqQuAXUCJufYG2trdu0GLQVbkA/iWjjlECtIdfiIus/EwhwfC j6rSwWjYqpK7U9coYq8epfGPy5G/f4/WBL70sLT6Qscb+hjYNqFAAVHEMIyH/45yH/Zw EShmR1A/MS1Oxh0VJM8MtWjhVjF79InCB/LDebYDJKt6s9Ojs4roy3Q6AfBTHarNiNgs ttRA== X-Gm-Message-State: AIkVDXLUc/BAlQ1dVCuz4HattqLyGPkr68uO0yGdIfvyERIXGCLQizSVhL1KCcQq4KNVsw== X-Received: by 10.237.42.108 with SMTP id k41mr30247903qtf.81.1484609875662; Mon, 16 Jan 2017 15:37:55 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id i41sm17489900qtc.18.2017.01.16.15.37.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 15:37:54 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id v23so127822437qtb.0 for ; Mon, 16 Jan 2017 15:37:54 -0800 (PST) X-Received: by 10.55.161.212 with SMTP id k203mr35934153qke.234.1484609874682; Mon, 16 Jan 2017 15:37:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Mon, 16 Jan 2017 15:37:54 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Roman Shpount Date: Mon, 16 Jan 2017 18:37:54 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c06e79436062c05463eaca9 Archived-At: Cc: Magnus Westerlund , mmusic WG Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 23:37:58 -0000 --94eb2c06e79436062c05463eaca9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and UDP/DTLS/SCTP in both the offer and the answer? Is there a use case to offer only tcp candidates in offer or answer? Regards, _____________ Roman Shpount On Mon, Jan 16, 2017 at 11:09 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > =E2=80=A6 > > >>>>I hope at least we can agree that an JSEP Answer MUST use the PROTO > string of the OFFER? > >>>> > >>>Yes. I think implementations should offer UDP/ (ICE/ will cause > problems) and in the answer echo the offer. > >> > >> This is related to the generic issue I raised in Seoul, and sent an > e-mail about last week: is it ok to echo > >> the transport in the m- line proto value of the answer even if the > answerer doesn=E2=80=99t support the transport (alt #1)? > >> > >> OR, should we mandate a transport that everyone must support, and > mandate to use that transport as m- line proto value in offers and answer= s > (alt #2)? > >> > >> People in Seoul preferred alt #1, but I know that at least Roman > prefers alt #2. > > > > I continue to support #1. We should just stop trying to pretend that > this value has useful semantics. > > As #1 was also the outcome of Seoul, I think we should move ahead with it= . > Chairs? > > Note that #1 does not prevent individual protocols from defining MTI > transports, default m- line proto values etc, but it would not be a > general requirement to do so. > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c06e79436062c05463eaca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For JSEP, is there a reason not to require UDP/TLS/RTP/SAV= PF and UDP/DTLS/SCTP in both the offer and the answer?

I= s there a use case to offer only tcp candidates in offer or answer?

Regards,
_____________
Roman Shpount

On Mon, Jan 16, 2017 at 11:09 AM, Christer H= olmberg <christer.holmberg@ericsson.com> wrote:=
Hi,

=E2=80=A6

>>>>I hope at least we can agree that an JSEP Answer MUST use t= he PROTO string of the OFFER?
>>>>
>>>Yes. I think implementations should offer UDP/ (ICE/ will cause= problems) and in the answer echo the offer.
>>
>> This is related to the generic issue I raised in Seoul, and sent a= n e-mail about last week: is it ok to echo
>> the transport in the m- line proto value of the answer even if the= answerer doesn=E2=80=99t support the transport (alt #1)?
>>
>> OR, should we mandate a transport that everyone must support, and = mandate to use that transport as m- line proto value in offers and answers = (alt #2)?
>>
>> People in Seoul preferred alt #1, but I know that at least Roman p= refers alt #2.
>
> I continue to support #1. We should just stop trying to pretend that t= his value has useful semantics.

As #1 was also the outcome of Seoul, I think we should move ahead wi= th it. Chairs?

Note that #1 does not prevent individual protocols from defining MTI transp= orts, default m- line proto values etc,=C2=A0 but it would not be a general= requirement to do so.

Regards,

Christer


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

--94eb2c06e79436062c05463eaca9-- From nobody Mon Jan 16 16:00:03 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 E693B1298D0 for ; Mon, 16 Jan 2017 16:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 fXRQQsJTpnLT for ; Mon, 16 Jan 2017 16:00:00 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 2E84C1298C5 for ; Mon, 16 Jan 2017 16:00:00 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id w75so77798174ywg.1 for ; Mon, 16 Jan 2017 16:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BUzaf7ZUVas//3KkQh1DF+ao+dXHtt/7ISJtwrVmmsI=; b=idZQmJGRtFprM/Yi1105GAfxljERzsFxOLJw8JlfK/zrpNtrZduTmkz915iZnrnX6c qxM0+F8jYgORJUUoXm7RzdLKpJ9EPcYMcgXRvCi45TqwYeJhbGKoQoVJ+lSlekSba1J1 dz+hv8YqCiNDjmvMtvyyMD25BoxEGvoJNFb28p/jhDtebuLGs59yOCfF6N8aTdx2xO2l 3XEslBmij7fnlcpMUc7djVpfDCZYMPT70/r+IsPgRsB34bj4pqITwsRlkC/9sIBjdDgC Y3xTj8ziH4ROO/QWKP3qcITsaBNYsJgrxTOe9x4JwHyi+rQ5NZ4cOeAz2ZIAAfEvZawc mT9Q== 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=BUzaf7ZUVas//3KkQh1DF+ao+dXHtt/7ISJtwrVmmsI=; b=k6icqAFwqoyTF8Ratydp8/XuCYz7jBA/N+3LTGV9W0nW/E7Kkqqd9GrQOsVdGF4toD CatGHSr032UcwsGseSgAFGongNJ1UkCvpb7KC45cRrVixSWSSRlW5Cxqw+vfSFmPPBrL DxE/OWSXaC91In6fjz/M4jfF1oABAuxAOZENeK96Sz2Y5I1/HueK0krrzxzAH/fBEVXj bklZBwUkKX3FTBscIuvMYah+jAFovrZWjw0ThLEvbWt/uVY2F+Z6U/61OtFoZzLD4eq/ SH+CIhp6PDaK6R1nQvUzWiAjz/mnAN+7iFot3Hk8mJr5gE28yrChveeUNoC2a7MZvlHX jOrA== X-Gm-Message-State: AIkVDXKJmIpxG6v+Kn1vwnkxllPn2YvqjeTYba4qAyLdtNvL/OuDzsMmk0FQUrMKV2REqTDZeC2NfEnY8+E5yw== X-Received: by 10.129.46.213 with SMTP id u204mr27651143ywu.52.1484611199330; Mon, 16 Jan 2017 15:59:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 15:59:18 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 16 Jan 2017 15:59:18 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a11407e082afd6f05463efbf8 Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 00:00:02 -0000 --001a11407e082afd6f05463efbf8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 16, 2017 at 3:37 PM, Roman Shpount wrote: > For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and > UDP/DTLS/SCTP in both the offer and the answer? > > As an answerer, you may get TCP/ from non-JSEP endpoints and the consensus was that echoing them was better -Ekr Is there a use case to offer only tcp candidates in offer or answer? > > Regards, > _____________ > Roman Shpount > > On Mon, Jan 16, 2017 at 11:09 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> =E2=80=A6 >> >> >>>>I hope at least we can agree that an JSEP Answer MUST use the PROTO >> string of the OFFER? >> >>>> >> >>>Yes. I think implementations should offer UDP/ (ICE/ will cause >> problems) and in the answer echo the offer. >> >> >> >> This is related to the generic issue I raised in Seoul, and sent an >> e-mail about last week: is it ok to echo >> >> the transport in the m- line proto value of the answer even if the >> answerer doesn=E2=80=99t support the transport (alt #1)? >> >> >> >> OR, should we mandate a transport that everyone must support, and >> mandate to use that transport as m- line proto value in offers and answe= rs >> (alt #2)? >> >> >> >> People in Seoul preferred alt #1, but I know that at least Roman >> prefers alt #2. >> > >> > I continue to support #1. We should just stop trying to pretend that >> this value has useful semantics. >> >> As #1 was also the outcome of Seoul, I think we should move ahead with >> it. Chairs? >> >> Note that #1 does not prevent individual protocols from defining MTI >> transports, default m- line proto values etc, but it would not be a >> general requirement to do so. >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > --001a11407e082afd6f05463efbf8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 16, 2017 at 3:37 PM, Roman Shpount <roman@telurix.com> wrote:
For JSEP, is t= here a reason not to require UDP/TLS/RTP/SAVPF and UDP/DTLS/SCTP in both th= e offer and the answer?


As an answerer, you may get TCP/<blah> from non-JSEP endpoints and = the consensus was that echoing them was better

-Ek= r

=
Is there a use case to offer only tcp candidates in offer or ans= wer?

Regards,
_____________
Roman Shpount

On Mon, Jan 16, 2017 = at 11:09 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

=E2=80=A6

>>>>I hope at least we can agree that an JSEP Answer MUST use t= he PROTO string of the OFFER?
>>>>
>>>Yes. I think implementations should offer UDP/ (ICE/ will cause= problems) and in the answer echo the offer.
>>
>> This is related to the generic issue I raised in Seoul, and sent a= n e-mail about last week: is it ok to echo
>> the transport in the m- line proto value of the answer even if the= answerer doesn=E2=80=99t support the transport (alt #1)?
>>
>> OR, should we mandate a transport that everyone must support, and = mandate to use that transport as m- line proto value in offers and answers = (alt #2)?
>>
>> People in Seoul preferred alt #1, but I know that at least Roman p= refers alt #2.
>
> I continue to support #1. We should just stop trying to pretend that t= his value has useful semantics.

As #1 was also the outcome of Seoul, I think we should move ahead wi= th it. Chairs?

Note that #1 does not prevent individual protocols from defining MTI transp= orts, default m- line proto values etc,=C2=A0 but it would not be a general= requirement to do so.

Regards,

Christer


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


--001a11407e082afd6f05463efbf8-- From nobody Mon Jan 16 16:11: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 4A5121294BB for ; Mon, 16 Jan 2017 16:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_SBL=1.623, URIBL_SBL_A=0.1] 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 9fOg5ZJwudxO for ; Mon, 16 Jan 2017 16:11:25 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 30227126579 for ; Mon, 16 Jan 2017 16:11:25 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id v23so128916545qtb.0 for ; Mon, 16 Jan 2017 16:11:25 -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=hQ1iVkn5YsMrz9+KJ/ULSVxxmnPR/376lKq423K3Lh4=; b=mbPxzckq6UEJoe6QIwSMh92ImEoe2V4ZwD5n3m9SNyENJsKSjV8ErvAYobcM6Yc67d Nl1cJv2qVVaF+0VuRjiNpKtXQNjUHZN2HpXbZPTHodKpAp+YFnXOpjQUHIhmB4tmQQ1b qDzSSbpZkv4dOHn3PDe3Koc52Pf14/mAMMSxYZjsEnvor+jvSezblKHH2bhbiNcM0lYQ 7IMN7eIIPHlmP2gYM0QTb2toNaIOWIddwQ3/RdtXHXGOuVrjlH+t2L48B8xGlLn+SXZg DFvGsG8I207JS4n7CpBVF+d9to+otLf7fEmkgMSSiDvsWQRbjUKvxA1v/42F5IIawBiD pJgQ== 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=hQ1iVkn5YsMrz9+KJ/ULSVxxmnPR/376lKq423K3Lh4=; b=goVWqdcCRctJTxQHpzknCo3ViqWjkocA+FIdM2aPAs20b8QxRy958wNHitO9jCZVHW 0sNm3QGQ4sp184SSF4nB7LDdBBPjY/Q51EOEXy5WaUQRjZvjNg8ELFm+Gu/TTA34Aznv fEPJWe93KDR77hOdd7PuYQWNd9F8ZP6636JrFcmPMXre0UPHwVT+1+MZ1x2sw78NjX3c B3iRqdBrZDyjZpmuBc7DzA71ET10811OoH6v2LDVYBVKxdC9B8JfonBdVL9+XifNhMCs brtTTWayXPH/9tm3dgOwnJUL4g7Doi+6SsI2J9m7nNlaUiKHF5Y6iitLN0cs1C3sFFtB KmEA== X-Gm-Message-State: AIkVDXLmlyBOaBc9eoCf3g8iN9+eKnPj2NyKBHejSffXKINqDJ2W52y/jkNJSAJnkJQulA== X-Received: by 10.55.20.17 with SMTP id e17mr30324853qkh.96.1484611884210; Mon, 16 Jan 2017 16:11:24 -0800 (PST) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com. [209.85.216.175]) by smtp.gmail.com with ESMTPSA id l65sm17440266qte.45.2017.01.16.16.11.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 16:11:23 -0800 (PST) Received: by mail-qt0-f175.google.com with SMTP id v23so128916148qtb.0 for ; Mon, 16 Jan 2017 16:11:23 -0800 (PST) X-Received: by 10.55.139.5 with SMTP id n5mr10853187qkd.225.1484611883592; Mon, 16 Jan 2017 16:11:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Mon, 16 Jan 2017 16:11:23 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Roman Shpount Date: Mon, 16 Jan 2017 19:11:23 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114f8426f391cc05463f2372 Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 00:11:26 -0000 --001a114f8426f391cc05463f2372 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 6:59 PM, Eric Rescorla wrote: > On Mon, Jan 16, 2017 at 3:37 PM, Roman Shpount wrote: > >> For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and >> UDP/DTLS/SCTP in both the offer and the answer? >> >> > As an answerer, you may get TCP/ from non-JSEP endpoints and the > consensus was that echoing them was better > > Is there a reason why this would ever happen? You use ICE TCP to go through UDP firewalls when communicating with a server on a public IP. Why would you ever do only tcp candidates in offer or answer? This is inefficient and will work worse then offering both udp and tcp candidates. I am all for options, but they should have some reason for existence. I see no reason why TCP/anything would ever be used for JSEP offer/answer, unless ICE is complete and tcp candidate pair is selected. BTW, we made UDP required protocol for default candidates for UDP/DTLS/SCTP. I see no reason not to do the same thing for UDP/TLS/RTP/SAVPF at least in JSEP. It will only make things interop with non JSEP endpoints better. Regards, _____________ Roman Shpount --001a114f8426f391cc05463f2372 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 16, 2017 at 6:59 PM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
On Mon, Jan 16, 2017 at 3:37 P= M, Roman Shpount <roman@telurix.com> wrote:
For JSEP, is there a = reason not to require UDP/TLS/RTP/SAVPF and UDP/DTLS/SCTP in both the offer= and the answer?


As an answerer, you may get TCP/<blah> from non-JSEP endpoints and = the consensus was that echoing them was better


Is there a reason why this would= ever happen? You use ICE TCP to go through UDP firewalls when communicatin= g with a server on a public IP. Why would you ever do only tcp candidates i= n offer or answer? This is inefficient and will work worse then offering bo= th udp and tcp candidates. I am all for options, but they should have some = reason for existence. I see no reason why TCP/anything would ever be used f= or JSEP offer/answer, unless ICE is complete and tcp candidate pair is sele= cted.

BTW, we made UDP required protocol for defau= lt candidates for UDP/DTLS/SCTP. I see no reason not to do the same thing f= or UDP/TLS/RTP/SAVPF at least in JSEP. It will only make things interop wit= h non JSEP endpoints better.

Regards,
_____________
Roman Shpount
=C2=A0
--001a114f8426f391cc05463f2372-- From nobody Mon Jan 16 16:21:37 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 4B1A81293F0 for ; Mon, 16 Jan 2017 16:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_SBL=1.623, URIBL_SBL_A=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Pfe-oXiN6d55 for ; Mon, 16 Jan 2017 16:21:34 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 72EE4126579 for ; Mon, 16 Jan 2017 16:21:34 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id l19so78010726ywc.2 for ; Mon, 16 Jan 2017 16:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7tfgnRS/scN0YbnQJ6Ie2mYXS6PnVGtskz+zrQQTq4I=; b=rkQJx/brEvY+4ioObZQ/8g8vGPEu+7RIAkRUIDcI1kUCSLo8/02swmMPSsF8A1kT/w 9wUmhGRj6/XDAbElB13MCZkrQ4Q0+u9mg47zsZTC2zvUT5JKblgwYeagVXJXrdgo1tSy PsljcL1nIDfw0y3694RFvSHhP7CpwwE9OleDKbRE2uSkgfy1e+eSkPoO64OvHV6FZeXK oRPVHqnW9JSAXhYN86R4tGWHehx/z/dL4Gf/0n2AIhtqz/RzWl7Byxv389P1KPFIdfyQ X6vv4O8oMpGUMD6EEvyrV0KkggvTenKdJSohxlhIJ0QRvQ7erODvr5bFI/gFA1kySH0/ jybg== 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=7tfgnRS/scN0YbnQJ6Ie2mYXS6PnVGtskz+zrQQTq4I=; b=d5KQ7I/p3nCM8Kj2HqUd30qehmYgrSoKC9Z1uJnTCBypWUpkO5XgKMYIMlqpBO5uuX /HCI42z7CoPD/BIq+zkvmj1z7zT7fy2+J14mAS/SaC/PSQg/YJ5tTFdBBHNqchTkuhbl etyazV2RZPHTqGP9SThnB9z4UJ0R/xykJvj5EmkMK48T4M/BaMxFNuZJUe3qykeA4cIa SJrqwwJHCRijDr/Acrm//yHbr9faWl+TdURhGIxLAHxjkcwJmuaPDusPjPztpeTPT5mn hgUKrL9ZieOW3/zcmKkxsHDjEwDpJlfc6i8959wvNCZ2XvuUG85G74W86MMEH4mbOG++ thjQ== X-Gm-Message-State: AIkVDXLfAYi+JjLUY++miZyxztfbeolhCuuL6wsKP31TzYDOkHokvWb4JBqlbeuqbO0dP5g3jYnC6EJVTUIGYQ== X-Received: by 10.129.73.139 with SMTP id w133mr26751483ywa.146.1484612493769; Mon, 16 Jan 2017 16:21:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 16:20:53 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 16 Jan 2017 16:20:53 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=001a114dac0e5257b705463f481a Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 00:21:36 -0000 --001a114dac0e5257b705463f481a Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 4:11 PM, Roman Shpount wrote: > On Mon, Jan 16, 2017 at 6:59 PM, Eric Rescorla wrote: > >> On Mon, Jan 16, 2017 at 3:37 PM, Roman Shpount wrote: >> >>> For JSEP, is there a reason not to require UDP/TLS/RTP/SAVPF and >>> UDP/DTLS/SCTP in both the offer and the answer? >>> >>> >> As an answerer, you may get TCP/ from non-JSEP endpoints and the >> consensus was that echoing them was better >> >> > Is there a reason why this would ever happen? > It's permitted behavior. > You use ICE TCP to go through UDP firewalls when communicating with a > server on a public IP. Why would you ever do only tcp candidates in offer > or answer? This is inefficient and will work worse then offering both udp > and tcp candidates. I am all for options, but they should have some reason > for existence. I see no reason why TCP/anything would ever be used for JSEP > offer/answer, unless ICE is complete and tcp candidate pair is selected. > Well, as I stated above, this isn't about what JSEP endpoints offer but what they answer when other endpoints send TCP/, however foolish you might think it is. > BTW, we made UDP required protocol for default candidates for > UDP/DTLS/SCTP. I see no reason not to do the same thing for > UDP/TLS/RTP/SAVPF at least in JSEP. It will only make things interop with > non JSEP endpoints better. > What's the evidence that answering TCP/TLS/RTP/SAVP with UDP/TLS/RTP/SAVPF will improve interop? -Ekr > Regards, > _____________ > Roman Shpount > > --001a114dac0e5257b705463f481a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 4:11 PM, Roman Shpount <roman@telurix.com&= gt; wrote:
On Mon, Jan 16, 2017 at 6:59 PM, Eric Rescorla <ekr@rtfm.c= om> wrote:
<= span class=3D"">
On Mon, Jan 16, 2017 at 3:37 PM, Roman Sh= pount <roman@telurix.com> wrote:
For JSEP, is there a reason not = to require UDP/TLS/RTP/SAVPF and UDP/DTLS/SCTP in both the offer and the an= swer?


As an ans= werer, you may get TCP/<blah> from non-JSEP endpoints and the consens= us was that echoing them was better

<= /blockquote>

Is there a reason why this would eve= r happen?

It's= permitted behavior.

=C2=A0
You use ICE TCP to go through UDP firewalls when communicati= ng with a server on a public IP. Why would you ever do only tcp candidates = in offer or answer? This is inefficient and will work worse then offering b= oth udp and tcp candidates. I am all for options, but they should have some= reason for existence. I see no reason why TCP/anything would ever be used = for JSEP offer/answer, unless ICE is complete and tcp candidate pair is sel= ected.

Well, as I s= tated above, this isn't about what JSEP endpoints offer but what they a= nswer
when other endpoints send TCP/<blah>, however foolish= you might think it is.

=

BTW, we made UDP required protocol for default candidates f= or UDP/DTLS/SCTP. I see no reason not to do the same thing for UDP/TLS/RTP/= SAVPF at least in JSEP. It will only make things interop with non JSEP endp= oints better.

What&= #39;s the evidence that answering TCP/TLS/RTP/SAVP with UDP/TLS/RTP/SAVPF w= ill improve interop?

-Ekr


Regards,
_____________
Roman Shpount
= =C2=A0

--001a114dac0e5257b705463f481a-- From nobody Mon Jan 16 16:53: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 4925F12968D for ; Mon, 16 Jan 2017 16:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 AeNxllDSbyCJ for ; Mon, 16 Jan 2017 16:53:25 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 D1261129675 for ; Mon, 16 Jan 2017 16:53:24 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so130250226qtb.0 for ; Mon, 16 Jan 2017 16:53:24 -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=/fGoS2KmAszwCzCyMti+AW3DMWFd8QGqnr4DOaDESD4=; b=QyHnc8eA2g2SkLVtiDDeFKg89fHgumoF0MyUB92jsMRxSvfIL0HnEnuAE249IQdwD4 Tn7UHBtlPGFW4MPmvz/3Oty/FxirWCWooYod7Blqy/DHzNaIfA4FbZFVZ1LoAtgl47FW 8Q91Bc7Q/l+9Vzqdv+tXqS0qPdUZ2aYDReFv0HsYC5kc0X0A2p8WuFS66sEHmANFd1Qe W5Re84MFKsi10v4hPPGsxrwrPNPnvSzaS0/TvCmI77vq+57NzkdRPmXixJEp3+/J7vxe IkHEVV/KSP11R+5LdHXDJfFbEO9x4zwgtYqT3EjdgYY4AvsLRn7VC0UcR3pkjrZtIbqk +bTA== 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=/fGoS2KmAszwCzCyMti+AW3DMWFd8QGqnr4DOaDESD4=; b=tEyXovZYPs6EjuHN2zTlRV++3podd6YP7+zxADQ6ba1bed0X364V0lozWbc/tIAorx LChnybRAGX8nIalzmkDtcasZzU72LwBSuqbm4BE44o7AePqn7xFl8zn8sfpU5MK7evgZ 39BX0AYPOwzfh7UGvDh6Wd25DxiyY2+gPRjhyq234ddSa7F8lgS6f3LHgebk3I4uav6N hWIx3G+erHDzP1kdEdMDAQRK/AI1FpM7afsHawF5gnVeM2wznKhXChrQb6tZ1/nnVjtO B3HJRucHHBzaReoXs9E7N3uCwvPsmLjCU/DrMsOTyH4NZylxkHF/mOPyfj2o68FFbJUz QPtw== X-Gm-Message-State: AIkVDXKSg4bqbSMXMpmPKw636ohf1ofHrwwGvjCrc4mb2Bssc2lwlpsr2MBC/FqxnsDk9Q== X-Received: by 10.55.152.69 with SMTP id a66mr33196897qke.172.1484614403859; Mon, 16 Jan 2017 16:53:23 -0800 (PST) Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com. [209.85.216.171]) by smtp.gmail.com with ESMTPSA id w138sm17506064qka.27.2017.01.16.16.53.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 16:53:23 -0800 (PST) Received: by mail-qt0-f171.google.com with SMTP id k15so130414621qtg.3 for ; Mon, 16 Jan 2017 16:53:23 -0800 (PST) X-Received: by 10.200.47.129 with SMTP id l1mr31095385qta.148.1484614403178; Mon, 16 Jan 2017 16:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Mon, 16 Jan 2017 16:53:22 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Roman Shpount Date: Mon, 16 Jan 2017 19:53:22 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113776f221612a05463fbaea Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 00:53:26 -0000 --001a113776f221612a05463fbaea Content-Type: text/plain; charset=UTF-8 For clarity, this is what I would suggest for JSEP: JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF. If JSEP end point receives an offer with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF, it MUST respond with the same proto and MUST include udp candidates (and use udp as a default candidate if JSEP endpoint is providing default candidates). If JSEP end point receives an offer with TCP/DTLS/SCTP or TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto and MUST include tcp candidates (and use tcp as a default candidate if JSEP endpoint is providing default candidates). If non JSEP end point responds with a protocol that does not match the offer, this is considered an error regardless of the ICE candidate supplied in the answer. So, what I want is for JSEP not to generate offers with TCP/blah and not to generate answers were protocol does not match the protocol in the offer, or does not match ICE candidates provided. I think this will improve interop and can be satisfied by all existing implementations. Generic requirements for ICE outside of JSEP can be more complex since we need to explain what will happen when end point receives an offer with TCP/blah but does not support TCP candidates. Also, outside of JSEP, things like ICE mismatch come into play. This, of cause, can be discussed and decided elsewhere, not in JSEP. Regards, _____________ Roman Shpount --001a113776f221612a05463fbaea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For clarity, this is what I would suggest for JSEP:
JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/T= LS/RTP/SAVPF.

If JSEP end point receives an offer = with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF, it MUST respond with the same prot= o and MUST include udp candidates (and use udp as a default candidate if JS= EP endpoint is providing default candidates).=C2=A0

If JSEP end point receives an offer with TCP/DTLS/SCTP or TCP/DTLS/RT= P/SAVPF, it MUST respond with the same proto and MUST include tcp candidate= s (and use tcp as a default candidate if JSEP endpoint=C2=A0is providing de= fault candidates).=C2=A0

If non JSEP end point res= ponds with a protocol that does not match the offer, this is considered an = error regardless of the ICE candidate supplied in the answer.

So, what I want is fo= r JSEP not to generate offers with TCP/blah and not to generate answers wer= e protocol does not match the protocol in the offer, or does not match ICE = candidates provided. I think this will improve interop and can be satisfied= by all existing implementations.

Generic requirements for ICE outside of JSEP ca= n be more complex since we need to explain what will happen when end point = receives an offer with TCP/blah but does not support TCP candidates. Also, = outside of JSEP, things like ICE mismatch come into play. This, of cause, c= an be discussed and decided elsewhere, not in JSEP.

Regards,=C2=A0
_____________
Roman Shpount
=
--001a113776f221612a05463fbaea-- From nobody Mon Jan 16 17:15:50 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 CF8B812994F for ; Mon, 16 Jan 2017 17:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 oUBrWJI3SApE for ; Mon, 16 Jan 2017 17:15:47 -0800 (PST) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 549EF12994E for ; Mon, 16 Jan 2017 17:15:47 -0800 (PST) Received: by mail-yb0-x230.google.com with SMTP id j82so21832359ybg.1 for ; Mon, 16 Jan 2017 17:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=WJXS36BzfR6Bi/KYNzWob+Fkyg+k9loW6cQqGkpJhCcgUPTnq2ycjo7skXkTM6zq+C g0uuxLmpFFvg2Co9HtL4+rPmONGhGb0ygB1dhoUjOjXZt1jVGPdQ54U9FbTbl7kfvWyK k4XW4iMDzuuRDtLlriVRJdlWoNZPn0hOg19W8MX2/0jg57Ms56faCopaTyvvKrtJrHyh 3Pj+Zutwo3KFQHL1nlgIAuBDsjJA3xscVGX8OJRYnOoaTjALD85KdxUkLq8XTsPRnFQf bSsn9m7Y2YW1CqagITnHLAv+NI+l4mAzKibd2ButbSO31ZOm8e5L3/uJ5Tmb0V1ymjeD iKgw== 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=UY5zj/69JN/Ethnld32RAEimoahEYEBgaOIiHCxLpyw=; b=Ehm4yMUuk2+ci3/xSkdWicMN8EO5D2748GhHed4trHZCBzTQIXrNFCFPayjMCZFyFv gJL5k0tsLt43iyQ/NxSN9Kzj7r2gBWGYw59ZzQyTEWnBRsmXTNSrUEJUhQg16biw52Ks 8L/D55u3rF6UNFtx9PwAb5YwkzvCfC4nHSegNqw8aKeiW17WgbvMJqDljOEINdR9xg10 nc71cQrqhdot5UexJign9lyVxVdCrkROM+8PhcJ8GSTm0LstEnXPLvAhzJOeNAE+7FqE lINpA3RNvABxHfcxu0bRaJ/7rUJJsx6ea/CQktJX5YYK0rX7/BGj4XC3KPhgXEm28/xE syTQ== X-Gm-Message-State: AIkVDXL9EOZzv/TTX4GtTIVovx7ssQq1IxbmdswJ6NlWB2ceI6xKgW7QX6zGgAbrIY3XnfpEoKMjCSDuvX2nSw== X-Received: by 10.37.246.10 with SMTP id t10mr24590875ybd.107.1484615746608; Mon, 16 Jan 2017 17:15:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Mon, 16 Jan 2017 17:15:06 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Eric Rescorla Date: Mon, 16 Jan 2017 17:15:06 -0800 Message-ID: To: Roman Shpount Content-Type: multipart/alternative; boundary=f403045dc8583490b10546400ad7 Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 01:15:49 -0000 --f403045dc8583490b10546400ad7 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 16, 2017 at 4:53 PM, Roman Shpount wrote: > For clarity, this is what I would suggest for JSEP: > > JSEP end point MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF. > Yes. If JSEP end point receives an offer with UDP/DTLS/SCTP or > UDP/TLS/RTP/SAVPF, it MUST respond with the same proto > Yes. > and MUST include udp candidates (and use udp as a default candidate if > JSEP endpoint is providing default candidates). > No, I don't agree with this. It should offer whatever candidates it wants and/or are determined by policy. For example, if the implementation is set to relay-only, it will be restricted to whatever the TURN relay will do. If JSEP end point receives an offer with TCP/DTLS/SCTP or > TCP/DTLS/RTP/SAVPF, it MUST respond with the same proto > Yes. > and MUST include tcp candidates (and use tcp as a default candidate if > JSEP endpoint is providing default candidates). > No, I don't agree for the reasons above. If non JSEP end point responds with a protocol that does not match the > offer, this is considered an error regardless of the ICE candidate supplied > in the answer. > > So, what I want is for JSEP not to generate offers with TCP/blah and not > to generate answers were protocol does not match the protocol in the offer, > Yes. > or does not match ICE candidates provided. I think this will improve > interop and can be satisfied by all existing implementations. > I don't think trying to match the candidates to the proto line is useful, especially when you are doing trickle ICE. -Ekr Generic requirements for ICE outside of JSEP can be more complex since we > need to explain what will happen when end point receives an offer with > TCP/blah but does not support TCP candidates. Also, outside of JSEP, things > like ICE mismatch come into play. This, of cause, can be discussed and > decided elsewhere, not in JSEP. > > Regards, > _____________ > Roman Shpount > --f403045dc8583490b10546400ad7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 16, 2017 at 4:53 PM, Roman Shpount <roman@telurix.com&= gt; wrote:
For cl= arity, this is what I would suggest for JSEP:

JSEP end p= oint MUST send an offer with UDP/DTLS/SCTP and UDP/TLS/RTP/SAVPF.

Yes.


=
If JSEP end point rece= ives an offer with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF, it MUST respond with= the same proto

Yes.

=C2=A0
and MUST include udp candidates (and use udp as a default candidate i= f JSEP endpoint is providing default candidates).=C2=A0

No, I don't agree with this. It should off= er whatever candidates it wants and/or are determined by policy. For exampl= e, if the implementation is set to relay-only, it will be restricted to wha= tever the TURN relay will do.


If JSEP end point receives an of= fer with TCP/DTLS/SCTP or TCP/DTLS/RTP/SAVPF, it MUST respond with the same= proto

Yes.

=C2=A0
and = MUST include tcp candidates (and use tcp as a default candidate if JSEP end= point=C2=A0is providing default candidates).=C2=A0
=

No, I don't agree for the reasons above.
=
=C2=A0


If non JSEP end point responds with a p= rotocol that does not match the offer, this is considered an error regardle= ss of the ICE candidate supplied in the answer.

So, what I want is for JSEP not to = generate offers with TCP/blah and not to generate answers were protocol doe= s not match the protocol in the offer,
=
Yes.

=C2=A0
or does not = match ICE candidates provided. I think this will improve interop and can be= satisfied by all existing implementations.
<= div>
I don't think trying to match the candidates to the = proto line is useful, especially when you are doing trickle ICE.
=
-Ekr


Generic require= ments for ICE outside of JSEP can be more complex since we need to explain = what will happen when end point receives an offer with TCP/blah but does no= t support TCP candidates. Also, outside of JSEP, things like ICE mismatch c= ome into play. This, of cause, can be discussed and decided elsewhere, not = in JSEP.

Regards,=C2=A0
_____________
Roman Shpount

--f403045dc8583490b10546400ad7-- From nobody Mon Jan 16 17:35:48 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 E4D3112995F for ; Mon, 16 Jan 2017 17:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 9PtQmtv6mude for ; Mon, 16 Jan 2017 17:35:45 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 B482A129695 for ; Mon, 16 Jan 2017 17:35:45 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id l7so132054422qtd.1 for ; Mon, 16 Jan 2017 17:35:45 -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=zGH8ysqKv7rI8Fv4BamNofXOz4JzRUMdT7Dc3eRXViQ=; b=G9U8tEx6Yeu68iC5rjvaEO8E2HsmRBJChjAo2gFyGMR4w9PfnEUoXkuozl5Wc+THVT 7HqpE1t/8upMbsKUPpRQlwTUaSbqbt5xiMrwa/1SX+HyspeKSvj9a1WZqx1FCXrfu+YB +t2S+IYdJAPjqqNWeKctVA7sLsgvKS6RMO1XQYrzwHA8b7K6gnM3R2OORk5uPLKj/kFd +aHRa0l5zcZL6wBeECykL9voD/4hDW0lGiyoPDaG7Mxox8f/Goo30zYM0pbur0shxu/N hZRZT7hLsRaN8Il0qB7/x2GTy+jjqeODIU6Qt6QcdPyN5tMbhzHXAaSEsokorer8VxNv A6Hg== 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=zGH8ysqKv7rI8Fv4BamNofXOz4JzRUMdT7Dc3eRXViQ=; b=DBntZfD8AuJD1IcOLiDIiptJetY3aOBBrBTxDaMXzvj4HiC7i179hkc1u4WLdFsCJo WYzIzUItoTllp70qu/scpIrshDov8vOdHAv10iFewf0xOckUQDQpKNpSpq3G+Q3L+O1O MKmokXT4NKGDzvMXB01BbgFVyal43gHKjljfVXP60y/fOnWkoP/BfMBtgC1Uj3H73H83 7VFZiuOWscgEVCBH4CVfUotmyWOl9620EzH3Pwcl4EnLtbToyVJsje98DEuaDN9iiqsm 6QAnUYNrSQE7acegOzcAft+5upiPkfgFxHE3ZRE17Z1mFrpSMJqjQmzwnMxHcSuGqveY JZew== X-Gm-Message-State: AIkVDXKCYqs573sgWn7vudpfq0kbKh+x5vQHQXp1Udc0f/t32jsTQVP9ga49GusqN6KqFQ== X-Received: by 10.55.166.77 with SMTP id p74mr3981344qke.314.1484616944880; Mon, 16 Jan 2017 17:35:44 -0800 (PST) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com. [209.85.216.177]) by smtp.gmail.com with ESMTPSA id e33sm17592584qtb.31.2017.01.16.17.35.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jan 2017 17:35:44 -0800 (PST) Received: by mail-qt0-f177.google.com with SMTP id l7so132053945qtd.1 for ; Mon, 16 Jan 2017 17:35:44 -0800 (PST) X-Received: by 10.200.52.129 with SMTP id w1mr30396733qtb.43.1484616944089; Mon, 16 Jan 2017 17:35:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.79 with HTTP; Mon, 16 Jan 2017 17:35:43 -0800 (PST) In-Reply-To: References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <9110d772-9269-7fed-3ed4-5269d49acb84@alvestrand.no> <282955c7-d077-105b-6a99-a0f5ede87d91@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4BF78DE0@ESESSMB209.ericsson.se> From: Roman Shpount Date: Mon, 16 Jan 2017 20:35:43 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11479b4a94836c05464051e5 Archived-At: Cc: Magnus Westerlund , mmusic WG , Christer Holmberg Subject: Re: [MMUSIC] JSEP Issue #394: What appears in m= lines. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 17 Jan 2017 01:35:47 -0000 --001a11479b4a94836c05464051e5 Content-Type: text/plain; charset=UTF-8 After considering your arguments regarding trickle ICE argument I agree with you. To summarize, I can live with the following: 1. JSEP end point MUST send an offer with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF 2. If JSEP end point receives the offer, it MUST response with the same transport even if no ice candidate matching this protocol are present in the answer 3. If non JSEP end point responds with a protocol that does not match the offer, this is considered an error regardless of the ICE candidate supplied in the answer. I do agree to this only within the limit of JSEP. Outside of JSEP it needs to be discussed in more detail, since things like ICE mismatch will need to be considered. Regards, _____________ Roman Shpount --001a11479b4a94836c05464051e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After considering your arguments regarding trickle ICE argument I agre= e with you.

T= o summarize, I can live with the following:

1. JSEP end= point MUST send an offer with UDP/DTLS/SCTP or UDP/TLS/RTP/SAVPF
2. If JSEP end point receives the offer, it MUST res= ponse with the same transport even if no ice candidate matching this protoc= ol are present in the answer
3. If non JSEP= end point responds with a protocol that does not match the offer, this is = considered an error regardless of the ICE candidate supplied in the answer.=

I do = agree to this only within the limit of JSEP. Outside of JSEP it needs to be= discussed in more detail, since things like ICE mismatch will need to be c= onsidered.

Regards,
_____________
Roman= Shpount
=C2=A0
--001a11479b4a94836c05464051e5-- From nobody Wed Jan 18 14:24: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 2007A129485; Wed, 18 Jan 2017 14:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 IM5VZCS-xnYq; Wed, 18 Jan 2017 14:24:12 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA04E128E19; Wed, 18 Jan 2017 14:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=570; q=dns/txt; s=iport; t=1484778251; x=1485987851; h=from:subject:to:cc:message-id:date:mime-version: content-transfer-encoding; bh=njd9kDE7fGUJeEwO1pTjDjJl8iG6Nb8vgkba6fJwa3g=; b=AL/NrBfeODq6pEZox4C/G42ljR1YpyYvFvvNvCgy45pym4a/JpoWIOYs hwzyD2FSr4Hs59KF81n7XLIx2EZDFExZHWPGnsWLozWk+zh5062iKQWKn t1xvyOyvBFnD4d/DKl4QnorOU636sY4wih+h6zyPVzsPQPT11NTiA80Xd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCq6X9Y/5BdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgzkBAQEBAR9gKoQwigifPoUHWoIPggsshWwKggY/GAECAQEBAQEBAWM?= =?us-ascii?q?ohRMVQTUCJgJfDQgBAYhyDQ6wHoIlij8BAQEBAQEEAQEBAQEBHQWBC4VAggWFd?= =?us-ascii?q?YRDgl4FkCWLHIwfhUOBXxiFDoMqhj6Sbx84gScdFTqGUSCJNgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,250,1477958400"; d="scan'208";a="374291037" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 22:24:11 +0000 Received: from [10.98.149.200] (bxb-fandreas-8817.cisco.com [10.98.149.200]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0IMOAN8027382; Wed, 18 Jan 2017 22:24:10 GMT From: Flemming Andreasen To: mmusic Message-ID: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> Date: Wed, 18 Jan 2017 17:24:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 18 Jan 2017 22:24:13 -0000 Greetings We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however there has been some updates to the draft subsequently. We are hereby issuing a 1 week WGLC on the the changes from -14 to -16 only, as indicated by the following URL: https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-14&url2=draft-ietf-mmusic-dtls-sdp-16 If you have any comments on the updates, please provide those by Wednesday, January 25. Comments should be sent to the document authors and the MMUSIC WG list. Thanks -- Flemming (as MMUSIC co-chair) From nobody Thu Jan 19 04:31:50 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 6D22412007C for ; Thu, 19 Jan 2017 04:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 n0iTn5CeLXjW for ; Thu, 19 Jan 2017 04:31:46 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F441293FB for ; Thu, 19 Jan 2017 04:31:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 879197C5132 for ; Thu, 19 Jan 2017 13:31:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1-P3ccP_yRm for ; Thu, 19 Jan 2017 13:31:42 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:12:21bc:7c38:8de8:3573]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3954B7C512F for ; Thu, 19 Jan 2017 13:31:42 +0100 (CET) References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> To: "mmusic@ietf.org" From: Harald Alvestrand X-Forwarded-Message-Id: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> Message-ID: <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> Date: Thu, 19 Jan 2017 13:31:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> Content-Type: multipart/alternative; boundary="------------AF50912027E1AA8D98B48086" Archived-At: Subject: [MMUSIC] Modifying an approved document: MSID X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jan 2017 12:31:48 -0000 This is a multi-part message in MIME format. --------------AF50912027E1AA8D98B48086 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Ted pointed out to me that I sent this to the wrong group. Chairs and members, please advise. -------- Forwarded Message -------- Subject: [rtcweb] Modifying an approved document: MSID Date: Wed, 18 Jan 2017 23:22:14 +0100 From: Harald Alvestrand To: rtcweb@ietf.org When reviewing the implications of the PeerConnection API change to support AddTrack rather than AddStream, I found an issue. This issue concerns draft-ietf-rtcweb-msid, which is currently in REF-WAIT state (I believe). The issue is that it is possible to add a track without specifying a stream. Since the track's ID needs to be carried, we have to send an "a=msid" line, but the track's ID is the *second* field on that line, with the first being the stream's ID. This creates a problem. Suggested fix: Insert two lines in the document: 1) On SDP generation: "If there is no stream associated with the track, use the reserved ID value '-'" 2) On SDP parsing "If the stream ID is the reserved value '-', the track is not associated with a stream, and no stream is signalled or created." If this is OK with the community, I'll issue an updated draft with this change. -- Surveillance is pervasive. Go Dark. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------AF50912027E1AA8D98B48086 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Ted pointed out to me that I sent this to the wrong group.

Chairs and members, please advise.



-------- Forwarded Message --------
Subject: [rtcweb] Modifying an approved document: MSID
Date: Wed, 18 Jan 2017 23:22:14 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: rtcweb@ietf.org <rtcweb@ietf.org> 


When reviewing the implications of the PeerConnection API change to
support AddTrack rather than AddStream, I found an issue.

This issue concerns draft-ietf-rtcweb-msid, which is currently in
REF-WAIT state (I believe).

The issue is that it is possible to add a track without specifying a
stream. Since the track's ID needs to be carried, we have to send an
"a=msid" line, but the track's ID is the *second* field on that line,
with the first being the stream's ID.

This creates a problem.

Suggested fix: Insert two lines in the document:

1) On SDP generation:

"If there is no stream associated with the track, use the reserved ID
value '-'"

2) On SDP parsing

"If the stream ID is the reserved value '-', the track is not associated
with a stream, and no stream is signalled or created."

If this is OK with the community, I'll issue an updated draft with this
change.


-- 
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--------------AF50912027E1AA8D98B48086-- From nobody Thu Jan 19 10:57:10 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 1F080129407; Thu, 19 Jan 2017 10:57:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148485223012.10353.17558063209296624256.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 10:57:10 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, mmusic@ietf.org, ben@nostrum.com Subject: [MMUSIC] mmusic - New Meeting Session Request for IETF 98 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:57:10 -0000 A new meeting session request has just been submitted by Flemming Andreasen, a Chair of the mmusic working group. --------------------------------------------------------- Working Group Name: Multiparty Multimedia Session Control Area Name: Applications and Real-Time Area Session Requester: Flemming Andreasen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: quic perc tls ice httpbis rtcweb avtcore avtext sipcore dispatch payload core dots sipbrandy Second Priority: clue straw xrblock rmcat stir tram sfc Special Requests: --------------------------------------------------------- From nobody Thu Jan 19 22:54: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 957261299F9; Thu, 19 Jan 2017 22:54:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 G9Ev4kEiLC4c; Thu, 19 Jan 2017 22:54:07 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 80D321299F6; Thu, 19 Jan 2017 22:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=drf1H3GPtO2dKwm7pj+NIlYoKf+EsJo4H8wZTebcjL8=; b=woS3PvIznlXgRMZBPGNFT24HB3 5RQIjzOt6p4BdsIl3M2ND43hdAH28Cgh+DJ4/sfrAUaJ/9U4h34o0EHM4z4ZKB55GhMw79Jh9W7Jh Wbvkh++khZSM9dIqm/xZq72EoskXjLhxawl9KHcAjs/V73S+AfcDXfRrER0eIea0SIyZww7v84L6y Ykq7kgjM4wploVM8RGt4/uQXi2I+2LrHVixmH4RpgzumBjfs271ZS1kwyoM+/vYeb83cRaSU9wv3p DRKCfMFhaRfE2nwMMaZkZhxJVB48tEvdyG7wPznPEmBmR0M+Oj3Q7DlvoFePtZuK8j/rfFzZAjYh4 4jS23JaA==; Received: from ppp118-209-171-56.lns20.mel8.internode.on.net ([118.209.171.56]:49976 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUT5F-001DDm-4c; Fri, 20 Jan 2017 17:54:01 +1100 To: Flemming Andreasen , mmusic References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> From: Christian Groves Message-ID: Date: Fri, 20 Jan 2017 17:53:53 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 06:54:08 -0000 A couple of nits: Cl. 5.1 Extraneous ",": "...Endpoints MUST support the cipher suites as defined in [I-D.ietf-mmusic-4572-update].<,> Cl. 5.3 Para 2: The first sentence should probably use the same formulation as paragraph 3, "... that requires the establishment of..." Cl. 5.4 Note - Missing "s" : "...an answer that include.." Cl. 6 Para 1 - Spelling error: "mechansim" -> "mechanism" Otherwise OK. Regards, Christian On 19/01/2017 9:24 AM, Flemming Andreasen wrote: > Greetings > > We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however > there has been some updates to the draft subsequently. We are hereby > issuing a 1 week WGLC on the the changes from -14 to -16 only, as > indicated by the following URL: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-14&url2=draft-ietf-mmusic-dtls-sdp-16 > > > If you have any comments on the updates, please provide those by > Wednesday, January 25. Comments should be sent to the document authors > and the MMUSIC WG list. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Jan 19 23:17: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 93FB0129A26 for ; Thu, 19 Jan 2017 23:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 5AuKfyzs1p8Z for ; Thu, 19 Jan 2017 23:16:59 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 E6C6E12995F for ; Thu, 19 Jan 2017 23:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TtJp2rzESGP8ZtPjimEu8T9YKO1JUB39StKjF9O0jjU=; b=dzyhfjfer6FhTZld9jWnOXuIWm VFO38UJ+Ty0N0ZgEIqxUlPMeXjaYt3M2u+dr1/9miQfJVFKR5ADAMX/F2D5i5yD4SIIRyxz/6C4L5 Gs2ahyMGQoU1ABC3/E+cyYTbTwq/vrGLS0N7XL6mLmj4XiXVT2KlU94n/hbbVcBT61xhZ2OyHQ4x4 YNtOalxiwLNqZGHTzBTdGUZ3dAMWsHOmic4I8j0zKaAwmJa3y2tjEQoFe90N91fSUxPZzmPXr1nkv t8J2OyqEKpwQSpkGpfXBOJfY1kYVbTtRqwvprG8HZjqnfUc0LmLqYaRhFRACEQxLfiOO7bjOUGyck TWWjyjiQ==; Received: from ppp118-209-171-56.lns20.mel8.internode.on.net ([118.209.171.56]:50647 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUTRQ-001EoD-RR for mmusic@ietf.org; Fri, 20 Jan 2017 18:16:56 +1100 To: mmusic@ietf.org References: From: Christian Groves Message-ID: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com> Date: Fri, 20 Jan 2017 18:16:49 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 07:16:59 -0000 Hello Paul, Please see below. Regards, Christian On 17/01/2017 6:56 AM, Paul Kyzivat wrote: > I've followed this document closely throughout its development. > In preparation for this message I reviewed the document again. I found > some things that need to be addressed: > > 1) MAJOR: Section 5.1.1.3 and various other places: > > I can find nothing here or elsewhere in the document that says whether > the the stream id in an offer is the id on which the offerer will > receive, or the ID on which it will send. Of course this is irrelevant > if both ends agree to use the same id, but that isn't required. > > For this to interact properly with attributes for individual streams > (in dcsa) I think it will be necessary for this to be consistent with > the say SDP negotiates media sections - namely that the SDP in an > offer identifies where the offerer wants to *receive* the media. > > It will probably require changes in a variety of places to get this > sorted out. [CNG] There is some guidance in clause 5.2.1 around managing stream identifiers. Utilising the same Stream ID is required when supporting WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that the opposite datachannels have the same set of attributes. SCTP stream identifier being one of those. > > 2) MINOR: Section 5.1.1 says: > > The intention in exchanging these attributes is to create, on two > peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched > pairs of oppositely directed data channels having the same set of > attributes. It is assumed that the data channel properties > (reliable/partially reliable, ordered/unordered) are suitable per the > subprotocol transport requirements. > > In this, "matched pairs of oppositely directed data channels" is > improper terminology. Each channel *is* a matched pair, of oppositely > directed SCTP streams. [CNG] Yes I agree. > ..snip.. From nobody Thu Jan 19 23:48:29 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 A69E5129A40; Thu, 19 Jan 2017 23:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 72CG-jpZW0Aw; Thu, 19 Jan 2017 23:48:26 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 90D4E129894; Thu, 19 Jan 2017 23:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xcp2x1OXo2q9cc+OZetkuhSS5G//T+sArbiGHU3aU9I=; b=Qx1ujIbUbWrJu2GCyZw1+aJ06M sACwtXiEWqKasJTJ+S06GsGpDQ6n76CWZYRQ4eeK3HaiVTmsvCTAZgv1hO5RCgPUtADt9DN1jH6mQ YZYd/QqXV8pP/DEQ/Nk4G11Nxwy/rx8RyEEHoxb/XYgyHGRADGWXjbHN7boQr1vfQbXbVk0M91obS PER6g3so5CdA7x7r2bfcnIOlBlb5Kzs9itX3Wg0Fk54RM0uk/iK9KGqYBukmxgC9jBWDSLeFb8Kxb 4u/M/9M/bCKobx8fQfgNzEoQaHY8JaVI8gJuKoSYyKyY5OyL+7Es34cXjBmDfJcRydacDM/H+iiNN kvuudqLA==; Received: from ppp118-209-171-56.lns20.mel8.internode.on.net ([118.209.171.56]:51851 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUTvs-001I1o-If; Fri, 20 Jan 2017 18:48:24 +1100 To: Bo Burman , "mmusic (mmusic@ietf.org)" References: From: Christian Groves Message-ID: Date: Fri, 20 Jan 2017 18:48:17 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org" Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 07:48:28 -0000 Hello, I've reviewed it and I think its ready to progress. A minor NIT on the example in Appendix A. It should contain an "a=dtls-id:....." attribute as per other examples in the draft. Regards, Christian On 16/01/2017 10:45 PM, Bo Burman wrote: > > MMUSIC, > > This email starts a one week WG last call on version -11 of this draft > that ends on January 23, 2017. > > There was a previous WG last call on version -09 that resulted in some > minor document updates. > > > The intended status of this document is standards track (Proposed > Standard). > > Please review and provide any comments you may have on the document. > Comments should be sent to the document authors and the MMUSIC WG > list. If you review the document but do not have any comments, please > send a note to that effect as well. > > Please also forward this WGLC to any other interested parties who may > be able to review the draft, asking them to also direct their comments > to the authors and the list as above. > > The document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ > > Thank you! > > Bo Burman (MMUSIC co-chair) > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jan 19 23:58: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 2E6AB129894; Thu, 19 Jan 2017 23:58:56 -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 uaoyyMp7CeHn; Thu, 19 Jan 2017 23:58: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 24A64127058; Thu, 19 Jan 2017 23:58:53 -0800 (PST) X-AuditID: c1b4fb25-4ccfd980000066fb-12-5881c33c8691 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id BF.C6.26363.C33C1885; Fri, 20 Jan 2017 08:58:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Fri, 20 Jan 2017 08:57:40 +0100 From: Christer Holmberg To: Christian Groves , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) Thread-Index: AQHScdm55RHubnr5e0me78cQd5IDTqFA33WAgAAztgA= Date: Fri, 20 Jan 2017 07:57:39 +0000 Message-ID: References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0F1C41397DDFBD44B7DFB6F936A9B53E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7oK7N4cYIg+fbRCy+vG9ksfg/cT6r xfsLuhZTlz9mcWDxmPJ7I6vHkiU/mTxWnJ/JEsAcxWWTkpqTWZZapG+XwJUxcetDpoLT3BW3 5hQ0MG7m7GLk5JAQMJG43/ODqYuRi0NIYB2jxJn9m5lBEkICSxglVl3N6GLk4GATsJDo/qcN EhYRqJRo+HacEcRmFgiUOHejlR3EFhZIkPjx9gE7RE2ixIrZIDUcQLaVxIIzSSBhFgFVibPv j7KAhHkFrCWuvK+AWFQk8fXKdrAwp4CDxKqzFiBhRgExie+n1jBBLBKXuPVkPhPEwQISS/ac Z4awRSVePv7HCmKLCuhJLH++BiquKPHx1T6oI/UkbkydwgZhW0tMfNnPCmFrSyxb+BqsnldA UOLkzCcsExjFZyFZNwtJ+ywk7bOQtM9C0r6AkXUVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmAEHtzyW3UH4+U3jocYBTgYlXh4C640RAixJpYVV+YeYpTgYFYS4e1Z3xghxJuSWFmVWpQf X1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA6OPprDw+t/N8ydOVGdcnJTU +9x7gtRhtydyh3Xv3lXfefL5n9S6Mu3/xzSz2rnjEzs0p4f/0DCXNbC372dQVNZjYInXnXfZ KfNa2/ODr76mRX9fw/oiK8l6ZZxBYbnV9GerW+pyrfa8kThyzGe3/8S/Vg1dNScjVmknsjDU CItqdpkHOMrdU2Ipzkg01GIuKk4EABQe3eC8AgAA Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 07:58:56 -0000 Hi Christian, I=B9ll fix as suggested. Thanks! Regards, Christer On 20/01/17 08:53, "Christian Groves" wrote: >A couple of nits: > >Cl. 5.1 Extraneous ",": "...Endpoints MUST support the cipher suites as >defined in > [I-D.ietf-mmusic-4572-update].<,> > >Cl. 5.3 Para 2: The first sentence should probably use the same >formulation as paragraph 3, "... that requires the establishment of..." > >Cl. 5.4 Note - Missing "s" : "...an answer that include.." > >Cl. 6 Para 1 - Spelling error: "mechansim" -> "mechanism" > >Otherwise OK. > >Regards, Christian > > >On 19/01/2017 9:24 AM, Flemming Andreasen wrote: >> Greetings >> >> We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however >> there has been some updates to the draft subsequently. We are hereby >> issuing a 1 week WGLC on the the changes from -14 to -16 only, as >> indicated by the following URL: >> >>=20 >>https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-14&url2=3D= draf >>t-ietf-mmusic-dtls-sdp-16 >> >> >> If you have any comments on the updates, please provide those by >> Wednesday, January 25. Comments should be sent to the document authors >> and the MMUSIC WG list. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From nobody Fri Jan 20 00:20: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 3C9C0129A9B; Fri, 20 Jan 2017 00:20:17 -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 K045eIAvxR0f; Fri, 20 Jan 2017 00:20:16 -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 984421295A6; Fri, 20 Jan 2017 00:20:15 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-57-5881c83d0554 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by (Symantec Mail Security) with SMTP id CC.33.25710.D38C1885; Fri, 20 Jan 2017 09:20:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0319.002; Fri, 20 Jan 2017 09:18:41 +0100 From: Christer Holmberg To: Christer Holmberg , Christian Groves , Flemming Andreasen , mmusic Thread-Topic: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) Thread-Index: AQHScdm55RHubnr5e0me78cQd5IDTqFA33WAgAAztgD///RqAA== Date: Fri, 20 Jan 2017 08:17:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF81628@ESESSMB209.ericsson.se> References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdUdf2RGOEwd2/FhZf3jeyWPyfOJ/V 4v0FXYupyx+zOLB4TPm9kdVjyZKfTB4rzs9kCWCO4rJJSc3JLEst0rdL4MrYsPocW8FT/orO znlsDYytvF2MnBwSAiYS+98sYepi5OIQEljHKLH1+EFWCGcJo8SUn1tZuhg5ONgELCS6/2mD xEUE1jNKfHl6gAWkm1kgUOLcjVZ2EFtYIEHi+YvHrCC2iECixIrZxxkhbCeJqwengtWwCKhK XOvbxwxi8wr4SpzreYewbOu77UwgCU4BG4mrf5rBFjAKiEl8P7WGCWKZuMStJ/OZIM4WkFiy 5zwzhC0q8fLxP1YIW0lixfZLjBD1ehI3pk5hg7C1JZYtfA21WFDi5MwnLBMYRWchGTsLScss JC2zkLQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYRwe3/Nbdwbj6teMhRgEORiUe 3oIrDRFCrIllxZW5hxglOJiVRHjFjjdGCPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEgg PbEkNTs1tSC1CCbLxMEp1cAo8OP4jJhVrrKFr18sTtefk9rE0/w2xKtdIrJId//rQ3fnH6u8 s+vIhG+GRayb204dnFhzb9n2mzuOGmjuMj0qL7ly6wGdiC0Pih76rN52w+XDq/L7rBtZw2Km /OYqUm+tWdyT+ZN/7ed7WVPzjc2cWKqOvTxQxf5rrsz1B99Xt3xZI16+4HLqOSWW4oxEQy3m ouJEANnOPlWfAgAA Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 08:20:17 -0000 Pull request for the WGLC comments created: https://github.com/cdh4u/draft-dtls-sdp/pull/22 Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 20 January 2017 09:58 To: Christian Groves ; Flemming Andreasen ; mmusic Cc: draft-ietf-mmusic-dtls-sdp@ietf.org Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dt= ls-sdp (-14 to -16) Hi Christian, I=B9ll fix as suggested. Thanks! Regards, Christer On 20/01/17 08:53, "Christian Groves" wrote: >A couple of nits: > >Cl. 5.1 Extraneous ",": "...Endpoints MUST support the cipher suites=20 >as defined in > [I-D.ietf-mmusic-4572-update].<,> > >Cl. 5.3 Para 2: The first sentence should probably use the same=20 >formulation as paragraph 3, "... that requires the establishment of..." > >Cl. 5.4 Note - Missing "s" : "...an answer that include.." > >Cl. 6 Para 1 - Spelling error: "mechansim" -> "mechanism" > >Otherwise OK. > >Regards, Christian > > >On 19/01/2017 9:24 AM, Flemming Andreasen wrote: >> Greetings >> >> We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however=20 >> there has been some updates to the draft subsequently. We are hereby=20 >> issuing a 1 week WGLC on the the changes from -14 to -16 only, as=20 >> indicated by the following URL: >> >>=20 >>https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-14&url2=3D= d >>raf >>t-ietf-mmusic-dtls-sdp-16 >> >> >> If you have any comments on the updates, please provide those by=20 >> Wednesday, January 25. Comments should be sent to the document=20 >> authors and the MMUSIC WG list. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > From nobody Fri Jan 20 13:09: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 2379F12948C; Fri, 20 Jan 2017 13:09:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148494656114.13380.17394564597711814392.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2017 13:09:21 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 21:09:21 -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 of the IETF. Title : Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Authors : Marc Petit-Huguenin Ari Keranen Suhas Nandakumar Filename : draft-ietf-mmusic-ice-sip-sdp-11.txt Pages : 42 Date : 2017-01-20 Abstract: This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-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 Fri Jan 20 13:11: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 AADE412948C for ; Fri, 20 Jan 2017 13:11:47 -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 C5lLoeI_18pc for ; Fri, 20 Jan 2017 13:11:46 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 BCB84129493 for ; Fri, 20 Jan 2017 13:11:45 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id j82so71207619ybg.1 for ; Fri, 20 Jan 2017 13:11:45 -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; bh=nMQ/EazSf0I/ejTkMEFJI+M3ZRchFhgBqoVe7YADYSE=; b=kRdAY/9NdRGkcDXbjHw26oF3tfFxtoYjWwsYg+SBrvT4nuK0rQhxG/C6rGhSF6EQdT sPNLPfAVuTK4FFQ5zAOfVq8Nrg0hFGnObdYoctNBU/fxRDqKTf06uP40X9cSLxUQJ2ej jiRZBPbo6iEtMCSIz0B0T0NZKhDz8cAHAycavROUCUGw+lS555PiFi5rWEFkV8ltpyqI njX+Ojc/tN6CQErfm2iIls5v03hTY0CT0NM8KsN5wlJtAR/I7MZzEBy3gL+8ejDittZ+ cRTJFTmB+JtZHB0Rmqp3LqYeunAieqxQMiaEdQPz08zeW7LqsH3HpKjPV+DnbNONkmgt rTxQ== 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; bh=nMQ/EazSf0I/ejTkMEFJI+M3ZRchFhgBqoVe7YADYSE=; b=Njtyy/aLCUQJExeKRL1uILz3ihEt3GkGSt1bNdzpOQfZyc03WePfoHouq1AEhG618E 5OglgiR5hYBijP2C3SHsGKXFbZKsy4IktO2YIGd3Taam+lOZErZJfJoLbveHX6acM+ly zSxwZno5y+Fz3+/I+Pid7iRhL11cem8hZwES+QrB+KXfTu/XpCV8dpVBJO96eOb5qEML 7Kfu5Iw+CF1GHCFyRLtmRMM2iYLgJBT6/n1XjfJh7GoRLklghepPBJMPYzo270Q4KKS+ NlksqvfFokp6Le6fbznxVqqNDAPnO+NpaVjt4CatITYIYsuGw5EKUM2/qjaYTXHTBoch pYAw== X-Gm-Message-State: AIkVDXL0lU5w9ju2Yn3pEbgXxtDGHIAplXhrU9LEBQpG2v/rrzMJZciMfsGukokqHq+56AaToW4ehcgbmYvhqA== X-Received: by 10.237.36.129 with SMTP id t1mr13980659qtc.202.1484946704778; Fri, 20 Jan 2017 13:11:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.51.228 with HTTP; Fri, 20 Jan 2017 13:11:44 -0800 (PST) In-Reply-To: <148494656114.13380.17394564597711814392.idtracker@ietfa.amsl.com> References: <148494656114.13380.17394564597711814392.idtracker@ietfa.amsl.com> From: Suhas Nandakumar Date: Fri, 20 Jan 2017 13:11:44 -0800 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary=001a11406072d9497005468d1845 Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-ice-sip-sdp-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 21:11:47 -0000 --001a11406072d9497005468d1845 Content-Type: text/plain; charset=UTF-8 Hello All This is a keep alive version. We will follow with a new version once we discuss review feedback from Adam. Thanks Suhas On Fri, Jan 20, 2017 at 1:09 PM, wrote: > > 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 of > the IETF. > > Title : Using Interactive Connectivity Establishment > (ICE) with Session Description Protocol (SDP) offer/answer and Session > Initiation Protocol (SIP) > Authors : Marc Petit-Huguenin > Ari Keranen > Suhas Nandakumar > Filename : draft-ietf-mmusic-ice-sip-sdp-11.txt > Pages : 42 > Date : 2017-01-20 > > Abstract: > This document describes how Interactive Connectivity Establishment > (ICE) is used with Session Description Protocol (SDP) offer/answer > and Session Initiation Protocol (SIP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-ice-sip-sdp-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/ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a11406072d9497005468d1845 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0This is a keep alive ve= rsion. We will follow with a new version once we discuss review feedback fr= om Adam.

Thanks
Suhas

On Fri, Jan 20, 2017 at = 1:09 PM, <internet-drafts@ietf.org> wrote:

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 of t= he IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Using Interactive Connectivity Establishment (ICE) with Session Descriptio= n Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Marc= Petit-Huguenin
=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 Ari Keranen
=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 Suhas Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-mmusic-ice-sip-sdp-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 42
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-20

Abstract:
=C2=A0 =C2=A0This document describes how Interactive Connectivity Establish= ment
=C2=A0 =C2=A0(ICE) is used with Session Description Protocol (SDP) offer/an= swer
=C2=A0 =C2=A0and Session Initiation Protocol (SIP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc= /draft-ietf-mmusic-ice-sip-sdp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-i= etf-mmusic-ice-sip-sdp-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-ice-sip-sdp-11


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

--001a11406072d9497005468d1845-- From nobody Fri Jan 20 14:01: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 66A7D1294CA; Fri, 20 Jan 2017 14:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Lo9z5dKobKzq; Fri, 20 Jan 2017 14:01:54 -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 51F5F1294BF; Fri, 20 Jan 2017 14:01:51 -0800 (PST) Received: from [10.0.1.39] (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 v0KM1nbq029511 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Jan 2017 16:01:50 -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.39] From: "Ben Campbell" To: draft-ietf-mmusic-sctp-sdp.all@ietf.org, mmusic Date: Fri, 20 Jan 2017 16:01:49 -0600 Message-ID: <210416BF-6413-4F52-A33C-BBB17C26D470@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 22:01:55 -0000 Hi, This is my AD Evaluation of draft-ietf-mmusic-sctp-sdp-21. The draft is mostly in good shape, but I would like to at least discuss the substantive comments prior to IETF last call. Thanks! Ben. ---------------- Substantive Comments -1, first paragraph: RFC 5572-update is currently in IETF LC. Is there a reason not to reference it instead? -4.1, last paragraph: I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP or TCP/DTLS/SCTP, not fmt values in general. It would help to be explicit about that. (Also, it seem like this paragraph belongs in section 4.3). -4.5: The example is missing the sctp-port attribute. -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, SPECIAL means you need to refer to the rules in the protocol definition. But the text here basically say that the rules are undefined. -6.1: What is meant by saying an "endpoint MUST assume that larger ... will be rejected"? Can that be stated in terms of actual procedure (e.g. "endpoint MUST NOT send...larger"? -6.2, "Purpose" field: Please include the unit here, too. -9.1, 2nd paragraph: Don't the lower layers need to be established before the upper layers? Won't removal of the TCP connection or DTLS association break an existing SCTP association? -18.2: Seems like RFC0793 and RFC6544 should be normative references. Editorial Comments: -1, 2nd paragraph: Seems like SCTP is also used to transport data :-) -1, last paragraph: is "strongly RECOMMENDED" intended to be stronger than RECOMMENDED? Assuming you don't mean MUST, please consider dropping the adverb. -6.1, typo: thevmaximum -9.1, 2nd paragraph: s/mange/manage -9.3, last paragraph: What does "impact" mean in context? Change state? (It seems like these actions would likely cause data to be sent at the SCTP layer, which seems like a kind of impact.) -10.3: Does "identical" mean identical to that from the offer? -10.3, 8th paragraph: s/"closing establishing"/"closing or establishing" From nobody Fri Jan 20 15:35: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 03A201295AB for ; Fri, 20 Jan 2017 15:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 KcjH4SdX9IkM for ; Fri, 20 Jan 2017 15:35:45 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (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 83A1D129570 for ; Fri, 20 Jan 2017 15:35:45 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-11v.sys.comcast.net with SMTP id UiiXcHipJEHPfUiiecdd3d; Fri, 20 Jan 2017 23:35:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484955344; bh=Ma/bxFM1zSzOS+8u9t3xzVIk+DXPxgYznooMwFDNWFQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=UI66oqnbfCpIDKEn3v+wzLoHPoPfkf3OwhYRqNbg481REEYlJIjM0oC0f18POa4mp /S/BYUlxloAXPa5nwEYYppVQz1GBEG1J0CwZ3l8SeK75PY/YzkNBjYhGFRsm1VLb54 WQoC5acAWpyqwkzxwVSc9ixVb3NW7z6DdktTS7uKq85MGsaEiK5WyQsv5eAkN+uv1l nMf2zJjH75E+xJrXJ/p9KBpbS/64cN3QMRl8VFwwuedEf29Z57faQhIIlkTJH683qD SC22tctbVKDaf271OfhFRkMmJdqti4goWgorbRW2H10yKOdV4DBkjf5W3OCyQb9Mo3 RMqDwKnp/6gzg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-20v.sys.comcast.net with SMTP id Uiidc1fnSWJRIUiidcCRJb; Fri, 20 Jan 2017 23:35:43 +0000 To: mmusic@ietf.org References: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com> From: Paul Kyzivat Message-ID: <653b4a88-a6a6-35d4-29f3-8cbe2665d08c@comcast.net> Date: Fri, 20 Jan 2017 18:35:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <47cd76a1-e767-9bd4-9c96-047688751866@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBfa3q4c34Og94ohmcQ11bRD4a6R3iouoHuM06nZJP9CcLskK4mjdM0FvGxziqsY9sb4Hfo8/oJ3Yws+784YfRUokqTW0fdxTVGXa7i0rjcA38ahbVjg uMmYeRYx2UAiBqTqe84/5eJ11GSmKyQ9pwqT8ulRirhv6Vfrm5QLBeVGwZG3RwEGXOztdhh+e5mNpA== Archived-At: Subject: Re: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 23:35:47 -0000 On 1/20/17 2:16 AM, Christian Groves wrote: > Hello Paul, > > Please see below. > > Regards, Christian > > On 17/01/2017 6:56 AM, Paul Kyzivat wrote: >> I've followed this document closely throughout its development. >> In preparation for this message I reviewed the document again. I found >> some things that need to be addressed: >> >> 1) MAJOR: Section 5.1.1.3 and various other places: >> >> I can find nothing here or elsewhere in the document that says whether >> the the stream id in an offer is the id on which the offerer will >> receive, or the ID on which it will send. Of course this is irrelevant >> if both ends agree to use the same id, but that isn't required. >> >> For this to interact properly with attributes for individual streams >> (in dcsa) I think it will be necessary for this to be consistent with >> the say SDP negotiates media sections - namely that the SDP in an >> offer identifies where the offerer wants to *receive* the media. >> >> It will probably require changes in a variety of places to get this >> sorted out. > > [CNG] There is some guidance in clause 5.2.1 around managing stream > identifiers. Utilising the same Stream ID is required when supporting > WebRTC datachannel (see clause 6.4/draft-ietf-rtcweb-data-channel-13). > Clause 5.1.1 / ietf-mmusic-data-channel-sdpneg vaguely mentions that the > opposite datachannels have the same set of attributes. SCTP stream > identifier being one of those. I was taking that into account, and yet found it incomplete. However, upon rereading, I did find some language in section 5.2.3 that helps clarify this: The peer receiving such an SDP offer performs the following: ... o For accepted data channels, it creates peer instances for the data channels with the agent using the channel parameters described in the SDP offer. Note that the agent is asked to create data channels with SCTP stream identifiers contained in the SDP offer if the SDP offer is accepted. The "Note" is what resolves any ambiguity. But it is written as if it was an implication that is simply being noted, rather than being a normative statement. So I propose that it be revised as follows: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. Thanks, Paul >> 2) MINOR: Section 5.1.1 says: >> >> The intention in exchanging these attributes is to create, on two >> peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched >> pairs of oppositely directed data channels having the same set of >> attributes. It is assumed that the data channel properties >> (reliable/partially reliable, ordered/unordered) are suitable per the >> subprotocol transport requirements. >> >> In this, "matched pairs of oppositely directed data channels" is >> improper terminology. Each channel *is* a matched pair, of oppositely >> directed SCTP streams. > [CNG] Yes I agree. >> ..snip.. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Sat Jan 21 07:00: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 5E6E6129AD2; Sat, 21 Jan 2017 07:00:08 -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 Zqu9vkqZPomv; Sat, 21 Jan 2017 07:00: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 E2B2C129A97; Sat, 21 Jan 2017 07:00:06 -0800 (PST) X-AuditID: c1b4fb2d-9c7ff7000000646e-2a-58837774dbf3 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id D8.F6.25710.47773885; Sat, 21 Jan 2017 16:00:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Sat, 21 Jan 2017 15:56:41 +0100 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Thread-Topic: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments Thread-Index: AdJz9jWwROPiRnyVStmv+m9MppPSJg== Date: Sat, 21 Jan 2017 14:55:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF97506@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM2K7k25peXOEQctSXov5nafZLTb1b2Kx mLr8MYsDs8eSJT+ZPGbtfMISwBTFZZOSmpNZllqkb5fAlbF/7hK2gmP8FTfPzmVuYJzB08XI ySEhYCLx//ZD1i5GLg4hgXWMEk0vJjFDOIsZJVbtu83YxcjBwSZgIdH9TxskLiIwmVHicU8j C0i3sECQxKOTV5lAbBGBYIkdDfNYIWw9if7OB+wgNouAqsT+iy/A4rwCvhLf7+wEizMKiEl8 P7UGrJdZQFzi1pP5TBAXCUgs2XOeGcIWlXj5+B8rhK0ksej2Z6h6HYkFuz+xQdjaEssWvmaG mC8ocXLmE5YJjEKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQI DPWDW37r7mBc/drxEKMAB6MSD69BXFOEEGtiWXFl7iFGCQ5mJRHesOLmCCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4pRoYjbw3chzM3xvp1/bX8tWe+PS5 4k7FTsbf798s2Ll0zvLEpNTk8GtHp6laRRgYGipMruybrZqp0LYtg+XzlXDuyR5/pPmnTD/V 8fm83vs4S79rdlO/9e6NfKA01bFHl3PWyuQpFVpZ2vW/t1Qs+HM58RlnReXH0/eDExhW9dnK X8go375Y7t98JZbijERDLeai4kQAyj+JFHECAAA= Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jan 2017 15:00:08 -0000 Hi Ben, Thanks for your review! Please see inline for my replies to your EDITORIAL = comments (I'll address the technical ones in a separate e-mail). ---------------- Editorial Comments: > -1, 2nd paragraph: Seems like SCTP is also used to transport data :-) Occasionally, yes :) I suggest the following new text: "The Stream Control Transmission Protocol (SCTP) [RFC4960] is a reliable transport protocol used to transport data between two endpoints using SCTP associations." ---- > -1, last paragraph: is "strongly RECOMMENDED" intended to be stronger tha= n RECOMMENDED? Assuming you don't mean MUST, please consider dropping the a= dverb. I suggest to use "RECOMMENDED". ---- > -6.1, typo: thevmaximum Will be fixed. ---- >-9.1, 2nd paragraph: s/mange/manage Will be fixed. ---- >-9.3, last paragraph: What does "impact" mean in context? Change state?=20 >(It seems like these actions would likely cause data to be sent at the SCT= P layer, which seems like a kind of impact.) I am not sure I understand what you mean by "sent at the SCTP layer". If an= SCTP association is closed, no data can be sent on the STCP layer. The purpose of the text is to point out that the underlying DTLS associatio= n is not impacted/affected when closing/establishing SCTP associations usin= g the 'sctp-port' attribute. That also means that the state is not changed. ---- >-10.3: Does "identical" mean identical to that from the offer? Correct. Note that the bullet text refers to the text in the first paragrap= h, which talks about the m- line in the offer. But, if you think it is unclear, we could say: "with an m- line proto value [RFC3264] identical to the value in the offer.= " ---- >-10.3, 8th paragraph: s/"closing establishing"/"closing or establishing" I suggest to say: "for closing the currently used, and establishing a new, DTLS association" ---- Regards, Christer From nobody Sat Jan 21 12:26: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 5F591129C62; Sat, 21 Jan 2017 12:26:09 -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 GXIgIbakvsvX; Sat, 21 Jan 2017 12:26:07 -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 9576E126579; Sat, 21 Jan 2017 12:26:06 -0800 (PST) X-AuditID: c1b4fb3a-d001d98000007c71-10-5883c3dcd45a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 9A.13.31857.CD3C3885; Sat, 21 Jan 2017 21:26:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Sat, 21 Jan 2017 21:23:04 +0100 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic , "Roman Shpount" Thread-Topic: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fA== Date: Sat, 21 Jan 2017 20:23:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM2K7lu6dw80RBh8OCFrM7zzNbrGpfxOL xdTlj1ksZlyYyuzA4rFkyU8mj1k7n7B43JpSEMAcxWWTkpqTWZZapG+XwJVxamEXa0GPSMXe L4tYGxgP8HcxcnJICJhInF35kK2LkYtDSGAdo8TSa3MZIZzFjBKfXp0EynBwsAlYSHT/0waJ iwjsYpT4eGMDO0i3sECQxPdn61hAbBGBYIl/c7awQdh6EkeWL2cE6WURUJU43c4BEuYV8JXo WNXICmIzCohJfD+1hgnEZhYQl7j1ZD4TxEECEkv2nGeGsEUlXj7+xwphK0ms2H6JEaJeR2LB 7k9sELa2xLKFr5kh5gtKnJz5hGUCo9AsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz0Uosy k4uL8/P08lJLNjECQ//glt9WOxgPPnc8xCjAwajEw2sQ1xQhxJpYVlyZe4hRgoNZSYQ3Fhg5 QrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTB2GO2b9UPi 58qboacv6um/CKuVTUtQFDt8TfAwE4fNPUWPV/tk75u8v80q0tVs3vumO0/fucayN+/Kcfta ge+tX6XNyxfX3utJWP9W+t/Bk2LVHDJSBsxhvKu+XbpceDTkm4fQkW2vdCJDTuoKnqlqDE7+ cOgQ+wUxruwnui/MLXyDMpozDyixFGckGmoxFxUnAgDngh/4eQIAAA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jan 2017 20:26:09 -0000 Hi, Below are my replies to Ben's technical comments. ---------------- Substantive Comments > -1, first paragraph: RFC 5572-update is currently in IETF LC. Is there a = reason not to reference it instead? I assume you mean 4572-update :) I agree that we should reference that spec instead, and I'll fix that. ---- > -4.1, last paragraph: > I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP or T= CP/DTLS/SCTP,=20 > not fmt values in general. Correct.=20 > It would help to be explicit about that. The first sentence in section 4.1 does say: "This section defines the following new SDP Media Description (m- line) protocol identifiers (proto values) for describing an SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." > (Also, it seem like this paragraph belongs in section 4.3). I could move and combine it with the 4th paragraph of section 4.3: "The m- line fmt value, identifying the application-layer protocol, MUST be registered by IANA. Section 15.3 defines the IANA registry=20 for the media format namespace." ---- > -4.5: The example is missing the sctp-port attribute. I'll add it. ---- > -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, SPECIAL = means you need to refer > to the rules in the protocol definition. But the text here basically say = that the rules are undefined. I'm ok using CAUTION. I agree it might be more appropriate than SPECIAL. ---- > -6.1: What is meant by saying an "endpoint MUST assume that larger ...=20 > will be rejected"? Can that be stated in terms of actual procedure (e.g.= =20 > "endpoint MUST NOT send...larger"? I'd like Roman's input on this, in case he had some cases in mind where end= point will have to send larger messages. I guess we could say SHOULD NO send larger message, and explain that one ca= nnot assume that larger message (if sent for whatever reason) will be accep= ted by the peer. ---- > -6.2, "Purpose" field: Please include the unit here, too. I'll change to "maximum message size (indicated in bytes) that..." =20 ---- > -9.1, 2nd paragraph: Don't the lower layers need to be established before= the > upper layers? Won't removal of the TCP connection or DTLS association bre= ak=20 > an existing SCTP association? Roman had lots of input on this, so I'll let him reply. ---- > -18.2: Seems like RFC0793 and RFC6544 should be normative references. I'll fix that. Regards, Christer From nobody Mon Jan 23 03:51: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 219471295BB; Mon, 23 Jan 2017 03:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 uK1KYhiPuLqz; Mon, 23 Jan 2017 03:51:19 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685CE129574; Mon, 23 Jan 2017 03:51:16 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id c7so63723016itd.1; Mon, 23 Jan 2017 03:51: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; bh=ODQuMRVGdC174Tfyew6gIw1AL4/0wkRLBzwBg7rx1Fs=; b=LWuIEDEYuR7goDGPXBoYxmQ1hYVgGk6Mp9IPCn96WV+WwzjVfzTk+qoMydCt3QVR3x GcSW8WEEy/oQ/niCY2fZbyBcTnLElq60AqpYE0ovQWRGIMVUlIQIv5pxq9UfwwFDcEsL NI/CKaYPcKxhQ2faTsqV1phGvAuJ2s3+kIJKW+0H1nl7GMjZDhVRXVLbJ9IUzD/YOP3k Ot7SZ62sUycZ4+XedmRGcUA+kj/HGR85ENCwBOTTmeMxK0a4j7iGedK0mCp/jze6ilaS XW7P2kv2K1gcs1ySvK0PQG1zUDP2uhOcA1yl9aHTrR8qYvMNyQZqaY0aZRMHmHFHoOok 7hJw== 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; bh=ODQuMRVGdC174Tfyew6gIw1AL4/0wkRLBzwBg7rx1Fs=; b=fb5sijIfyDZLWIpwPJatbR5Q6k9a0oL7uej2nCTqpJRpD7n+xdXQDxxYh5vTOiOHRk 1peDdms8tJ24/PsWm2wIcMUXIHpPMX5hQPvzIMA3kpNajHcdRs/AI52u+MRB2c4TUrcr stKgXJmFPZGoL8qRc/EivfbQfuv5ovjE7ruecq5MMLjxSB+gP+G1k+0HcupQZtAc++VZ FjRMg0/XI36wSiTB1/CNeFZakf9zNu1FgCm0Cm5CukqJpWkc7PKqlMWObOHN1GOOM+Ww zNa7pVSRs5v/gFwQeMGH4CRUVOTIfyHjhU9SM4mGEXmIcvC6pFcoXMBEbcAEKrtRALy0 43sQ== X-Gm-Message-State: AIkVDXLcmWhWJsH9Kl6iAWdW6PKQPAzeoDA+OcopWJfX+YH01remS1O6eNDdXnxB1sQvMa9s8hbIDGoVfT8/nA== X-Received: by 10.36.165.79 with SMTP id w15mr13861819iti.77.1485172275476; Mon, 23 Jan 2017 03:51:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.140.71 with HTTP; Mon, 23 Jan 2017 03:51:14 -0800 (PST) In-Reply-To: <148516969384.29478.16962145399713084931.idtracker@ietfa.amsl.com> References: <148516969384.29478.16962145399713084931.idtracker@ietfa.amsl.com> From: Andy Hutton Date: Mon, 23 Jan 2017 11:51:14 +0000 Message-ID: To: mmusic-chairs@ietf.org, sipbrandy-chairs@ietf.org, Ben Campbell , mmusic@ietf.org Content-Type: multipart/alternative; boundary=f403045fb638e902d30546c19de1 Archived-At: Subject: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 11:51:23 -0000 --f403045fb638e902d30546c19de1 Content-Type: text/plain; charset=UTF-8 I have just submitted this draft. The draft is the result of discussion in the SIPBrandy working group regarding how to proceed with https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-01. The SIPBrandy WG was not able to progress the opportunistic SRTP work because it required an update to RFC 4568 which is not covered by the SIPBrandy charter. This short draft is therefore submitted to MMUSIC with a view to updating the relevant RFC's and progressing the OSRTP work in SIPBrandy. Regards Andy ---------- Forwarded message ---------- From: Date: Mon, Jan 23, 2017 at 11:08 AM Subject: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile Authors : Andrew Hutton Roland Jesske Alan Johnston Gonzalo Salgueiro Bernard Aboba Filename : draft-hutton-mmusic-opportunis tic-negotiation-00.txt Pages : 6 Date : 2017-01-23 Abstract: This document describes how the use of the Secure Real-time transport protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio Video Profile) defined in [RFC3551]. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/ AVPF) [RFC4585]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportu nistic-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-hutton-mmusic-opportunistic-negotiation-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --f403045fb638e902d30546c19de1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have just submitted this draft.

The draft is the result of discussion in the SIPBrandy= working group regarding how to proceed with=C2=A0https://tools.ietf.org/html/dr= aft-ietf-sipbrandy-osrtp-01.=C2=A0 The SIPBrandy WG was not able to pro= gress the opportunistic SRTP work because it required an update to RFC 4568= which is not covered by the SIPBrandy charter.

Th= is short draft is therefore submitted to MMUSIC with a view to updating the= relevant RFC's and progressing the OSRTP work in SIPBrandy.
=
Regards
Andy




---------- Forwarded message --= --------
From: <= internet-draf= ts@ietf.org>
Date: Mon, Jan 23, 2017 at 11:08 AM
Subjec= t: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.t= xt
To: i-d-an= nounce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andr= ew Hutton
=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 Roland Jesske
=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 Alan Johnston
=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 Gonzalo Salgueiro
=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 Bernard Aboba
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hut= ton-mmusic-opportunistic-negotiation-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-23

Abstract:
=C2=A0 =C2=A0This document describes how the use of the Secure Real-time tr= ansport
=C2=A0 =C2=A0protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Au= dio
=C2=A0 =C2=A0Video Profile) defined in [RFC3551].=C2=A0 Such a mechanism is= used to
=C2=A0 =C2=A0provide a means for encrypted media to be used in environments= where
=C2=A0 =C2=A0support for encryption is not known in advance, and not requir= ed.
=C2=A0 =C2=A0The same mechanism is also applied to negotiation of the Exten= ded RTP
=C2=A0 =C2=A0Profile for Real-time Transport Control Protocol Based Feedbac= k (RTP/
=C2=A0 =C2=A0AVPF) [RFC4585].


The IETF datatracker status page for this draft is:
https://datatracker.i= etf.org/doc/draft-hutton-mmusic-opportunistic-negotiation/
There's also a htmlized version available at:
https://tools.ietf.org/h= tml/draft-hutton-mmusic-opportunistic-negotiation-00


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/li= stinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--f403045fb638e902d30546c19de1-- From nobody Mon Jan 23 07:18: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 1B72C12961E; Mon, 23 Jan 2017 07:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Dek9RT9NV20f; Mon, 23 Jan 2017 07:18:13 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA003129615; Mon, 23 Jan 2017 07:18:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B25B27C51BC; Mon, 23 Jan 2017 16:18:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-h6vtJKTqvE; Mon, 23 Jan 2017 16:18:08 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4C42F7C51B9; Mon, 23 Jan 2017 16:18:08 +0100 (CET) To: mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> From: Harald Alvestrand Message-ID: <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> Date: Mon, 23 Jan 2017 16:18:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [MMUSIC] Modifying an approved document: MSID X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 15:18:15 -0000 Den 19. jan. 2017 13:31, skrev Harald Alvestrand: > Ted pointed out to me that I sent this to the wrong group. > > Chairs and members, please advise. My proposed change is here: https://github.com/alvestrand/rtcweb-msid/pull/16 The filed issue is here: https://github.com/alvestrand/rtcweb-msid/issues/15 (CCing RTCWEB - please keep discussion, if any, on mmusic) > > > > -------- Forwarded Message -------- > Subject: [rtcweb] Modifying an approved document: MSID > Date: Wed, 18 Jan 2017 23:22:14 +0100 > From: Harald Alvestrand > To: rtcweb@ietf.org > > > > When reviewing the implications of the PeerConnection API change to > support AddTrack rather than AddStream, I found an issue. > > This issue concerns draft-ietf-rtcweb-msid, which is currently in > REF-WAIT state (I believe). > > The issue is that it is possible to add a track without specifying a > stream. Since the track's ID needs to be carried, we have to send an > "a=msid" line, but the track's ID is the *second* field on that line, > with the first being the stream's ID. > > This creates a problem. > > Suggested fix: Insert two lines in the document: > > 1) On SDP generation: > > "If there is no stream associated with the track, use the reserved ID > value '-'" > > 2) On SDP parsing > > "If the stream ID is the reserved value '-', the track is not associated > with a stream, and no stream is signalled or created." > > If this is OK with the community, I'll issue an updated draft with this > change. > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Mon Jan 23 16:13:41 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 3D357129453; Mon, 23 Jan 2017 16:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 AdbTvLXDhcBq; Mon, 23 Jan 2017 16:13:40 -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 0D5BE12944D; Mon, 23 Jan 2017 16:13:39 -0800 (PST) Received: from [10.0.1.39] (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 v0O0DYWY072255 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Jan 2017 18:13:34 -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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 23 Jan 2017 18:13:33 -0600 Message-ID: <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 00:13:41 -0000 Thanks for the response. Replies inline. Ben. On 21 Jan 2017, at 14:23, Christer Holmberg wrote: > Hi, > > Below are my replies to Ben's technical comments. > > ---------------- > Substantive Comments > >> -1, first paragraph: RFC 5572-update is currently in IETF LC. Is >> there a reason not to reference it instead? > > I assume you mean 4572-update :) Yes :-) > > I agree that we should reference that spec instead, and I'll fix that. > > ---- > >> -4.1, last paragraph: >> I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP >> or TCP/DTLS/SCTP, >> not fmt values in general. > > Correct. > >> It would help to be explicit about that. > > The first sentence in section 4.1 does say: > > "This section defines the following new SDP Media Description (m- > line) protocol identifiers (proto values) for describing an SCTP > association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." I'm not sure all readers will see the connection between the first and last paragraph. I still think it would help to explicitly mention it. (Especially if it moves to 4.3) An alternative, if it were to stay in 4.1 would be to have the opening paragraph in 4.1 explicitly mention that it includes the fmt values to be used in the context of these new proto values. > >> (Also, it seem like this paragraph belongs in section 4.3). > > I could move and combine it with the 4th paragraph of section 4.3: > > "The m- line fmt value, identifying the application-layer protocol, > MUST be registered by IANA. Section 15.3 defines the IANA registry > for the media format namespace." > > ---- [...] > ---- > >> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, >> SPECIAL means you need to refer >> to the rules in the protocol definition. But the text here basically >> say that the rules are undefined. > > I'm ok using CAUTION. I agree it might be more appropriate than > SPECIAL. I'm glad we agree :-) This is probably a big enough change to make sure the workgroup also agrees, though. > > ---- > >> -6.1: What is meant by saying an "endpoint MUST assume that larger >> ... >> will be rejected"? Can that be stated in terms of actual procedure >> (e.g. >> "endpoint MUST NOT send...larger"? > > I'd like Roman's input on this, in case he had some cases in mind > where endpoint will have to send larger messages. > > I guess we could say SHOULD NO send larger message, and explain that > one cannot assume that larger message (if sent for whatever reason) > will be accepted by the peer. That would be reasonable if it is the right answer. I just want to avoid the vagueness of "MUST assume". > [...] > ---- > >> -9.1, 2nd paragraph: Don't the lower layers need to be established >> before the >> upper layers? Won't removal of the TCP connection or DTLS association >> break >> an existing SCTP association? > > Roman had lots of input on this, so I'll let him reply. Okay [...] From nobody Mon Jan 23 17:16: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 1DB54129504 for ; Mon, 23 Jan 2017 17:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 UwP87GU3GGBx for ; Mon, 23 Jan 2017 17:16:55 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 838A81294DB for ; Mon, 23 Jan 2017 17:16:55 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so155241687qtc.2 for ; Mon, 23 Jan 2017 17:16:55 -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=nlPJ6gR00G3RHtBVlAZNBnIc95mUhlNcLagFyGEuhCA=; b=MXC4ATUTOPg+ZVFtDrWiI6uIufTCEiZ8jb71wChRisRxISulVjxV7vM2Sy9UXUJ6ww V1enAyP1U/bkWj8I6E2PVQSqakW4A/IoEGoA52JG02tdtw0LUuCL5yxg2E7ae8JlF5H1 hCgRiw9cHYzd7nLPMI4yBAS5CgziIj66GgrDCf/DPD/+gu6/x52pLZ1bViIVaKi/WSDU g7bzDWhJUS6D+NXYhtNHBTsmgOpIR2aKQ9RoXnehTcGLyVIKBjHT5p9UrtpQ8DUDuyEt 2hf0orEjZZWva/LtY7tZmpIgj7I/qg1xrzzvJ9AbTPfDckftzhXte/N6n2oBbC4h5ZWY 7rdQ== 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=nlPJ6gR00G3RHtBVlAZNBnIc95mUhlNcLagFyGEuhCA=; b=dKbVUlT/OluBOexU0G+xUf7no9EKRSw1D+Vf9TbBIElfcqE6RKw9H0HgtNnlUAFoHk ohxv9gnOW5+A/HSZn9TdKd6qcVhVWF5/V5N/2l63owoqYSipy8uIjvaLKwM3//tX9GAR O3ZNASc2Li5Q8ELQ0qC6k8aL93jDp1HzatjWdODUtNIZk4XniNfDx7c9apIjTn5qXNDZ iDBsCwIpy7wQbzrT7kyvaBucMlfJ1cbijIm9Y4t3lL3xwJXy3TjtD4HG3s8YXQFNi/Vf Z+5jOo1EkTB53lLceCIkbVVyi3NCzSKYJGLf2gDfi8PxsI1noqBqBpgJc03pLIRBWaxJ mTXA== X-Gm-Message-State: AIkVDXJCX8eIMTh+dmLsqtx4Mwh5LHT4FaeC1H1Bf/Maf9/lFTjI7SrcqcVAqIN7fvKHsQ== X-Received: by 10.237.62.107 with SMTP id m40mr28794292qtf.196.1485220614615; Mon, 23 Jan 2017 17:16:54 -0800 (PST) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com. [209.85.216.177]) by smtp.gmail.com with ESMTPSA id q88sm14716725qkq.21.2017.01.23.17.16.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jan 2017 17:16:53 -0800 (PST) Received: by mail-qt0-f177.google.com with SMTP id v23so156124984qtb.0; Mon, 23 Jan 2017 17:16:53 -0800 (PST) X-Received: by 10.200.52.129 with SMTP id w1mr25576692qtb.43.1485220613552; Mon, 23 Jan 2017 17:16:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Mon, 23 Jan 2017 17:16:53 -0800 (PST) In-Reply-To: <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> From: Roman Shpount Date: Mon, 23 Jan 2017 20:16:53 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=001a11479b4a159f810546ccdf49 Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic , Christer Holmberg Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 01:16:57 -0000 --001a11479b4a159f810546ccdf49 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell wrote: > On 21 Jan 2017, at 14:23, Christer Holmberg wrote: > >> -9.1, 2nd paragraph: Don't the lower layers need to be established before >>> the >>> upper layers? Won't removal of the TCP connection or DTLS association >>> break >>> an existing SCTP association? >>> >> >> Roman had lots of input on this, so I'll let him reply. >> > > Okay > Replacing of TCP connection or DTLS association does not break the SCTP association. SCTP is designed to run over unreliable transports, so short term loss of connectivity when one TCP connection or one DTLS association is being replaced by the other would be handled by the SCTP re-transmit timers. Also, when ICE is used, switching from one ICE candidate to another, including switching between two ICE tcp candidates or switching from udp to tcp candidate, does not affect existing SCTP association. Existing SCTP association continues to run despite the underlying candidate switch and as far as SCTP association is concerned it is running over the same unreliable transport. Finally, DTLS association can be re-established to force re-keying the long running connection. This can be done without affecting SCTP association running on top of these DTLS associations. This is why we are saying that the SCTP association, the DTLS association and the TCP connection are managed independently from each other. Each can be established and closed without impacting others. Each protocol uses its own means to detect connection closure, failure or timeout. I am also cautious of immediately closing SCTP association on TCP connection or DTLS association closure. There are certain situations, when these connections would be closed due to 3pcc collisions only to be immediately opened again. I think, if SCTP association should be closed, it needs to be explicitly signaled at SCTP level. Regards, _____________ Roman Shpount --001a11479b4a159f810546ccdf49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 23, 2017 at 7:1= 3 PM, Ben Campbell <ben@nostrum.com> wrote:
On 21 Jan 2017, a= t 14:23, Christer Holmberg wrote:
-9.1, 2nd paragraph: Don't the lower layers need to be= established before the
upper layers? Won't removal of the TCP connection or DTLS association b= reak
an existing SCTP association?

Roman had lots of input on this, so I'll let him reply.

Okay

Replacing of TCP connection or DTL= S association does not break the SCTP association. SCTP is designed to run = over unreliable transports, so short term loss of connectivity when one TCP= connection or one DTLS association is being replaced by the other would be= handled by the SCTP re-transmit timers. Also, when ICE is used, switching = from one ICE candidate to another, including switching between two ICE tcp = candidates or switching from udp to tcp candidate, does not affect existing= SCTP association. Existing SCTP association continues to run despite the u= nderlying candidate switch and as far as SCTP association is concerned it i= s running over the same unreliable transport. Finally, DTLS association can= be re-established to force re-keying the long running connection. This can= be done without affecting SCTP association running on top of these DTLS as= sociations.

This is why we are saying that the SCTP association, t= he DTLS association and the TCP connection are=C2=A0managed independently f= rom each other.=C2=A0 Each can be established and=C2=A0 closed without impa= cting others. Each protocol uses its own means to detect connection closure= , failure or timeout.

I am also cautious of immediately closing SCTP association= on TCP connection or DTLS association closure. There are certain situation= s, when these connections would be closed due to 3pcc collisions only to be= immediately opened again. I think, if SCTP association should be closed, i= t needs to be explicitly signaled at SCTP level. =C2=A0

Regards,
= _____________
Roman Shpount
<= div>=C2=A0
--001a11479b4a159f810546ccdf49-- From nobody Mon Jan 23 18:25: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 D2C88129552; Mon, 23 Jan 2017 18:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 Nm3x_tZ83R9B; Mon, 23 Jan 2017 18:25:39 -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 ACA8F12954E; Mon, 23 Jan 2017 18:25:39 -0800 (PST) Received: from [10.0.1.39] (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 v0O2PY15084743 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Jan 2017 20:25:35 -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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 23 Jan 2017 20:25:34 -0600 Message-ID: <8CB4B344-CE21-4319-9C56-69F7CC4FB811@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF97506@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF97506@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 02:25:41 -0000 Thanks for the response. Replies inline. Ben. On 21 Jan 2017, at 8:55, Christer Holmberg wrote: > Hi Ben, > > Thanks for your review! Please see inline for my replies to your > EDITORIAL comments (I'll address the technical ones in a separate > e-mail). > > ---------------- > > Editorial Comments: > >> -1, 2nd paragraph: Seems like SCTP is also used to transport data :-) > > Occasionally, yes :) > > I suggest the following new text: > > "The Stream Control Transmission Protocol (SCTP) [RFC4960] is a > reliable transport protocol used to transport data between two > endpoints using SCTP associations." WFM. [...] > ---- > >> -9.3, last paragraph: What does "impact" mean in context? Change >> state? >> (It seems like these actions would likely cause data to be sent at >> the SCTP layer, which seems like a kind of impact.) > > I am not sure I understand what you mean by "sent at the SCTP layer". > If an SCTP association is closed, no data can be sent on the STCP > layer. Sorry, I meant sent at the DTLS layer. > > The purpose of the text is to point out that the underlying DTLS > association is not impacted/affected when closing/establishing SCTP > associations using the 'sctp-port' attribute. That also means that the > state is not changed. My point is that "impact" can mean many things. I think we are saying that the state of the DTLS security association is unchanged, right? > > ---- > >> -10.3: Does "identical" mean identical to that from the offer? > > Correct. Note that the bullet text refers to the text in the first > paragraph, which talks about the m- line in the offer. > > But, if you think it is unclear, we could say: > > "with an m- line proto value [RFC3264] identical to the value in the > offer." That would help. > > ---- > >> -10.3, 8th paragraph: s/"closing establishing"/"closing or >> establishing" > > I suggest to say: > > "for closing the currently used, and establishing a new, DTLS > association" WFM. From nobody Tue Jan 24 05:03: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 2D83E1295DE; Tue, 24 Jan 2017 05:03:16 -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 2GAMOJY7deJ2; Tue, 24 Jan 2017 05:03:15 -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 97C411270B4; Tue, 24 Jan 2017 05:03:14 -0800 (PST) X-AuditID: c1b4fb25-1dfff700000036c9-eb-58875090fbf0 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 7F.87.14025.09057885; Tue, 24 Jan 2017 14:03:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 14:03:12 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments Thread-Index: AdJz9jWwROPiRnyVStmv+m9MppPSJgB6oyYAABqCvIA= Date: Tue, 24 Jan 2017 13:03:11 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF97506@ESESSMB209.ericsson.se> <8CB4B344-CE21-4319-9C56-69F7CC4FB811@nostrum.com> In-Reply-To: <8CB4B344-CE21-4319-9C56-69F7CC4FB811@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9BAEC76A0DC516418FCC713733147F6F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7pe6EgPYIg8X9BhbzO0+zW2zq38Ri MXX5YxYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+P4tbdsBS8FKt7s6GFtYOzm7WLk 5JAQMJG4c/UzWxcjF4eQwDpGiQUf1zJCOIsZJf707WDvYuTgYBOwkOj+pw3SICKgJPG8eSsL iM0sUCyx+9BjMFtYIEji8uEFrBA1wRI7GuZB2VYSzd39zCA2i4CqxJVd99hBbF4Ba4lvX89C 7WpilGhvfAPWwClgL3H25SNGEJtRQEzi+6k1TBDLxCVuPZnPBHG1gMSSPeeZIWxRiZeP/4H1 igroSSx/vgYqrijR/rSBEaJXT+LG1ClsELa1xOllD5khbG2JZQtfM0McJChxcuYTlgmM4rOQ rJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw9g5u+a26g/Hy G8dDjAIcjEo8vAVSbRFCrIllxZW5hxglOJiVRHjT/NsjhHhTEiurUovy44tKc1KLDzFKc7Ao ifOarbwfLiSQnliSmp2aWpBaBJNl4uCUamDs8W4WfLFcXeXLlsWWx3fbePzM/SHIHj7FRzDg 5IxtmbvvcHk+5gp5b9wv9XerrNizeX9uXosqa9UKizhQuXkmb8irR5Lz18ZnnDu+dHrl5wX7 lHuT0vaF/7ndEVycpqjl8cTbWeOtXJWJqv3vs2Wpdq6pn1i2mx2p2fLFfcLqNHmnP3ed/s9V YinOSDTUYi4qTgQAnVoCebkCAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 13:03:16 -0000 Hi, ... >>> -9.3, last paragraph: What does "impact" mean in context? Change >>> state? >>> (It seems like these actions would likely cause data to be sent at >>> the SCTP layer, which seems like a kind of impact.) >> >> I am not sure I understand what you mean by "sent at the SCTP layer". >> If an SCTP association is closed, no data can be sent on the STCP >> layer. > >Sorry, I meant sent at the DTLS layer. > >> >> The purpose of the text is to point out that the underlying DTLS >> association is not impacted/affected when closing/establishing SCTP >> associations using the 'sctp-port' attribute. That also means that the >> state is not changed. > >My point is that "impact" can mean many things. I think we are saying >that the state of the DTLS security association is unchanged, right? Yes. So, would the following change address your issue? "NOTE: Closing and establishing a new SCTP association using the SDP 'sctp-port' attribute will not affect the state of the underlying DTLS association.=B2 The last bullet of section 10.5 contains similar text, and I assume you would have the same issue with that. If so, I could change it: "o NOTE: This specification does not define a mechanism for explicitly closing a DTLS association while maintaining the overlying SCTP association. However, if a DTLS association is closed and replaced with a new DTLS association, as a result of some other action [I-D.ietf-mmusic-dtls-sdp], the state of the SCTP association is not affected." Personally I think =B3affected=B2 fits better than =B3changed=B2, but if yo= u want to use =B3changed=B2 I won=B9t argue against you :) ---- >>> -10.3: Does "identical" mean identical to that from the offer? >> >> Correct. Note that the bullet text refers to the text in the first >> paragraph, which talks about the m- line in the offer. >> >> But, if you think it is unclear, we could say: >> >> "with an m- line proto value [RFC3264] identical to the value in the >> offer." > >That would help. I=B9ll change as suggested. Regards, Christer From nobody Tue Jan 24 05:21:37 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 73C5C1295DD; Tue, 24 Jan 2017 05:21:35 -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 6F0Q88V3HHjO; Tue, 24 Jan 2017 05:21:34 -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 DD4DF1294F8; Tue, 24 Jan 2017 05:21:33 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-09-588754db1a53 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 01.C6.16488.BD457885; Tue, 24 Jan 2017 14:21:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 14:20:47 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAB+8QwA= Date: Tue, 24 Jan 2017 13:20:46 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> In-Reply-To: <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1267E9D331C98C46909D9EB7CB1610B4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2J7iO6dkPYIgyNH2Szmd55mt9jUv4nF YuryxywWMy5MZXZg8Viy5CeTx6ydT1g8bk0pCGCO4rJJSc3JLEst0rdL4MrYduQPc8ErmYrd LdvYGhhPi3UxcnJICJhI3NzazQxiCwmsY5S41ObZxcgFZC9mlJgz/R97FyMHB5uAhUT3P22Q GhEBJYnnzVtZQGxmgVmMEs+/S4PYwgLREl/3v2aBqImROLtnMROEbSXRdmIhG4jNIqAq8X76 AkYQm1fAWuLv7A9sELuaGCWWnfvCDpLgFLCX+Hm5EayZUUBM4vupNUwQy8Qlbj2ZzwRxtIDE kj3nmSFsUYmXj/+xgtiiAnoSy5+vYQa5WQLo0Glb0yBaDSTen5vPDGFbS3w/sYYdwtaWWLbw NTPEPYISJ2c+YZnAKD4LybZZSNpnIWmfhaR9FpL2BYysqxhFi1OLi3PTjYz0Uosyk4uL8/P0 8lJLNjECI/Hglt9WOxgPPnc8xCjAwajEw1sg1RYhxJpYVlyZe4hRgoNZSYQ3zb89Qog3JbGy KrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbGNefkTbMiZgv7CD/w a7/uN0OqQ6dPPdPo/KxZgUsDXr0QMhX/E7jCIq6kiPlm6IX/IgdUv1gsltgXL6WUaP51Y3xC gJzJ19o3U0pfz3Vp77z3tpv70rqVOi66DL1y9lnmegekOxWMNyXov0q8s2XbigPBPstbTnev mjlPP/DHO8l5X14yVrkpsRRnJBpqMRcVJwIAQd0EQcACAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 13:21:35 -0000 Hi, ... >>> -4.1, last paragraph: >>> I assume this paragraph refers to fmt values used with UDP/DTLS/SCTP >>> or TCP/DTLS/SCTP, >>> not fmt values in general. >> >> Correct. >> >>> It would help to be explicit about that. >> >> The first sentence in section 4.1 does say: >> >> "This section defines the following new SDP Media Description (m- >> line) protocol identifiers (proto values) for describing an SCTP >> association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." > >I'm not sure all readers will see the connection between the first and >last paragraph. I still think it would help to explicitly mention it. >(Especially if it moves to 4.3) > >An alternative, if it were to stay in 4.1 would be to have the opening >paragraph in 4.1 explicitly mention that it includes the fmt values to >be used in the context of these new proto values. > >> >>> (Also, it seem like this paragraph belongs in section 4.3). >> >> I could move and combine it with the 4th paragraph of section 4.3: >> >> "The m- line fmt value, identifying the application-layer protocol, >> MUST be registered by IANA. Section 15.3 defines the IANA registry >> for the media format namespace." Ok, so my suggestion is to: 1) Move the paragraph to section 4.3, as described above 2) Modify the first paragraph in section 4.1: "This section defines the following new SDP Media Description (m- line) protocol identifiers (proto values) for describing an SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section also describes how an m- line, associated with the proto values, is created, and how the the media format (=8Cfmt=B9) values are used." ---- >>> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, >>> SPECIAL means you need to refer >>> to the rules in the protocol definition. But the text here basically >>> say that the rules are undefined. >> >> I'm ok using CAUTION. I agree it might be more appropriate than >> SPECIAL. > >I'm glad we agree :-) You only mentioned section 5.3, but I think the same applies also to section 6.3 (MUX category for the max-message-size-attribute), so I suggest to change both to CAUTION. >This is probably a big enough change to make sure the workgroup also >agrees, though. *Sounds of crickets* Yes, it does agree :) ---- >>> -6.1: What is meant by saying an "endpoint MUST assume that larger >>> ... >>> will be rejected"? Can that be stated in terms of actual procedure >>> (e.g. >>> "endpoint MUST NOT send...larger"? >> >> I'd like Roman's input on this, in case he had some cases in mind >> where endpoint will have to send larger messages. >> >> I guess we could say SHOULD NO send larger message, and explain that >> one cannot assume that larger message (if sent for whatever reason) >> will be accepted by the peer. > >That would be reasonable if it is the right answer. I just want to avoid >the vagueness of "MUST assume". I suggest the following modified text: "An SCTP endpoint SHOULD NOT send a SCTP user message with a message size that is larger than the maximum size indicated by the peer. If the SCTP endpoint needs (for whatever reason) to send a larger message, it cannot be assumed that the message will be accepted by the peer.=B2 ---- >>>-9.1, 2nd paragraph: Don't the lower layers need to be established >>> before the >>> upper layers? Won't removal of the TCP connection or DTLS association >>> break >>> an existing SCTP association? >> >> Roman had lots of input on this, so I'll let him reply. > >Okay See Roman=B9s reply. Regards, Christer From nobody Tue Jan 24 07:43: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 C72F4129A55; Tue, 24 Jan 2017 07:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 tsf6ctoKZF-1; Tue, 24 Jan 2017 07:43: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 B2467129607; Tue, 24 Jan 2017 07:43:43 -0800 (PST) Received: from [10.0.1.39] (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 v0OFhd3e079209 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 09:43: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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 24 Jan 2017 09:43:39 -0600 Message-ID: <208C3E09-31CD-4018-9ED3-3EBF99FE7AA6@nostrum.com> In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF97506@ESESSMB209.ericsson.se> <8CB4B344-CE21-4319-9C56-69F7CC4FB811@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - EDITORIAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:43:45 -0000 On 24 Jan 2017, at 7:03, Christer Holmberg wrote: > Hi, > > ... > >>>> -9.3, last paragraph: What does "impact" mean in context? Change >>>> state? >>>> (It seems like these actions would likely cause data to be sent at >>>> the SCTP layer, which seems like a kind of impact.) >>> >>> I am not sure I understand what you mean by "sent at the SCTP >>> layer". >>> If an SCTP association is closed, no data can be sent on the STCP >>> layer. >> >> Sorry, I meant sent at the DTLS layer. >> >>> >>> The purpose of the text is to point out that the underlying DTLS >>> association is not impacted/affected when closing/establishing SCTP >>> associations using the 'sctp-port' attribute. That also means that >>> the >>> state is not changed. >> >> My point is that "impact" can mean many things. I think we are saying >> that the state of the DTLS security association is unchanged, right? > > Yes. > > So, would the following change address your issue? > > "NOTE: Closing and establishing a new SCTP association using the SDP > 'sctp-port' attribute will not affect the state of the underlying > DTLS > association.² > > > The last bullet of section 10.5 contains similar text, and I assume > you > would have the same issue with that. If so, I could change it: > > "o NOTE: This specification does not define a mechanism for > explicitly closing a DTLS association while maintaining the > overlying SCTP association. However, if a DTLS association is > closed and replaced with a new DTLS association, as a result of > some other action [I-D.ietf-mmusic-dtls-sdp], the state of the > SCTP association is not affected." > Both work for me. > > Personally I think ³affected² fits better than ³changed², but if > you want > to use ³changed² I won¹t argue against you :) "Affected" is fine. It's the "...state of..." part that fixes it in my mind. :-) [...] Thanks! Ben. From nobody Tue Jan 24 07:48: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 E2AAE129607; Tue, 24 Jan 2017 07:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, 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 MB6n_jecQMHz; Tue, 24 Jan 2017 07:47:59 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4DF128AC9; Tue, 24 Jan 2017 07:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16902; q=dns/txt; s=iport; t=1485272878; x=1486482478; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=eBGSp1C9ZWhMGLexSXrn/18OINKuBc6DHXJtFOxIJc4=; b=LsLcAABHsYEoj8yc07yyfGgnp21CLtxVelKJP+H7SX5ZI3XkairV/Drb +ZCXpJfaz+xqBdq3UbzTWsk0OoI0B19GyZeEGZKwNY1eBz+ucAqSf540d xVFnn1BemySCjCF/0PsEIJzP2a2y3YilzmWteCcezEcXA/frnum7MCxa3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQBQdodY/4gNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9FAQEBAQEfYIEJB4NMigmSB4gGh32FK4INHwEMhXYCGoIAPxg?= =?us-ascii?q?BAgEBAQEBAQFiKIRpAQEBBAEBIUsbAgEGAhEDAQIoAwICAh8GCxQJCAIEARIJi?= =?us-ascii?q?HYDGA6QD51OgiUrhxANgw8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdiFCCaoJRghg?= =?us-ascii?q?WglAugjEFiQKSEzgBhmGHAoQIgXdShD2JaIggggAiiDQBDxA4gUgVGCIQAYRgg?= =?us-ascii?q?UhzAYZHgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,278,1477958400"; d="scan'208,217";a="197536755" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jan 2017 15:47:57 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0OFlvvn004919 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Jan 2017 15:47:57 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 24 Jan 2017 09:47:56 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Tue, 24 Jan 2017 09:47:57 -0600 From: "Charles Eckel (eckelcu)" To: Andy Hutton , "mmusic-chairs@ietf.org" , "sipbrandy-chairs@ietf.org" , Ben Campbell , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt Thread-Index: AQHSdlk7zD47ybXpiUuewms2ggT92g== Date: Tue, 24 Jan 2017 15:47:56 +0000 Message-ID: <6AD021E5-2C84-4BED-88D8-DFD5773C768B@cisco.com> References: <148516969384.29478.16962145399713084931.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.25.229] Content-Type: multipart/alternative; boundary="_000_6AD021E52C844BED88D8DFD5773C768Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:48:01 -0000 --_000_6AD021E52C844BED88D8DFD5773C768Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KSeKAmW0gZ2xhZCB0byBzZWUgdGhpcyBkcmFmdC4gT25lIGluaXRpYWwgY29t bWVudCBhZnRlciBhIHF1aWNrIHJldmlldyAtIGluIHNlY3Rpb24gNSwgdGhlIGFuc3dlcmVyIG11 c3QgYWxzbyBiZSBhbGxvd2VkIHRvIGluZGljYXRlIHRoZSBwcm9maWxlIGFzIEFWUCBvciBTQVZQ IHlldCBzdGlsbCBpbmNsdWRlIHRoZSAiYT1ydGNwLWZiIiBTRFAgYXR0cmlidXRlLiBUaGlzIGlz IG5vdCBhbGxvd2VkIGJ5IFJGQyA0NTg1LCBzbyBpdCBtdXN0IGJlIGRlc2NyaWJlZCBoZXJlIGFz IHdlbGwuDQpBbHNvLCBpdCB3b3VsZCBiZSBnb29kIHRvIHJlZmVyZW5jZSB0aGUgSU1UQyBiZXN0 IHByYWN0aWNlIGRvY3VtZW50IHRoYXQgcG9wdWxhcml6ZWQgdGhpcyByZWxheGF0aW9uIG9mIFJG QyA0NTg1OiBJTVRDIDEwMTUg4oCTIOKAnFNJUCBWaWRlbyBQcm9maWxlIEJlc3QgUHJhY3RpY2Vz 4oCdLg0KaHR0cDovL3d3dy5pbXRjLm9yZy9kb2N1bWVudHMvb2ZmaWNpYWwtZG9jdW1lbnRzLw0K DQpDaGVlcnMsDQpDaGFybGVzDQoNCkZyb206IG1tdXNpYyA8bW11c2ljLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBBbmR5IEh1dHRvbiA8YW5keWh1dHRvbi5pZXRmQGdtYWlsLmNvbT4N CkRhdGU6IE1vbmRheSwgSmFudWFyeSAyMywgMjAxNyBhdCAzOjUxIEFNDQpUbzogIm1tdXNpYy1j aGFpcnNAaWV0Zi5vcmciIDxtbXVzaWMtY2hhaXJzQGlldGYub3JnPiwgInNpcGJyYW5keS1jaGFp cnNAaWV0Zi5vcmciIDxzaXBicmFuZHktY2hhaXJzQGlldGYub3JnPiwgQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb20+LCAibW11c2ljQGlldGYub3JnIiA8bW11c2ljQGlldGYub3JnPg0KU3Vi amVjdDogW01NVVNJQ10gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1odXR0b24tbW11c2ljLW9wcG9y dHVuaXN0aWMtbmVnb3RpYXRpb24tMDAudHh0DQoNCg0KSSBoYXZlIGp1c3Qgc3VibWl0dGVkIHRo aXMgZHJhZnQuDQoNClRoZSBkcmFmdCBpcyB0aGUgcmVzdWx0IG9mIGRpc2N1c3Npb24gaW4gdGhl IFNJUEJyYW5keSB3b3JraW5nIGdyb3VwIHJlZ2FyZGluZyBob3cgdG8gcHJvY2VlZCB3aXRoIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMS4g IFRoZSBTSVBCcmFuZHkgV0cgd2FzIG5vdCBhYmxlIHRvIHByb2dyZXNzIHRoZSBvcHBvcnR1bmlz dGljIFNSVFAgd29yayBiZWNhdXNlIGl0IHJlcXVpcmVkIGFuIHVwZGF0ZSB0byBSRkMgNDU2OCB3 aGljaCBpcyBub3QgY292ZXJlZCBieSB0aGUgU0lQQnJhbmR5IGNoYXJ0ZXIuDQoNClRoaXMgc2hv cnQgZHJhZnQgaXMgdGhlcmVmb3JlIHN1Ym1pdHRlZCB0byBNTVVTSUMgd2l0aCBhIHZpZXcgdG8g dXBkYXRpbmcgdGhlIHJlbGV2YW50IFJGQydzIGFuZCBwcm9ncmVzc2luZyB0aGUgT1NSVFAgd29y ayBpbiBTSVBCcmFuZHkuDQoNClJlZ2FyZHMNCkFuZHkNCg0KDQoNCg0KLS0tLS0tLS0tLSBGb3J3 YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn PG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBKYW4gMjMsIDIw MTcgYXQgMTE6MDggQU0NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWh1dHRvbi1tbXVzaWMt b3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5v cmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4NCg0KDQoNCkEgTmV3IEludGVybmV0LURy YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IE5lZ290aWF0aW5nIFNSVFAgYW5k IFJUQ1AgRmVlZGJhY2sgdXNpbmcgdGhlIFJUUC9BVlAgUHJvZmlsZQ0KICAgICAgICBBdXRob3Jz ICAgICAgICAgOiBBbmRyZXcgSHV0dG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIFJvbGFu ZCBKZXNza2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQWxhbiBKb2huc3Rvbg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBHb256YWxvIFNhbGd1ZWlybw0KICAgICAgICAgICAgICAgICAg ICAgICAgICBCZXJuYXJkIEFib2JhDQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWh1 dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQNCiAgICAgICAgUGFn ZXMgICAgICAgICAgIDogNg0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE3LTAxLTIzDQoN CkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSB1c2Ugb2YgdGhl IFNlY3VyZSBSZWFsLXRpbWUgdHJhbnNwb3J0DQogICBwcm90b2NvbCAoU1JUUCkgW1JGQzM3MTFd LiBjYW4gYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgQVZQIChBdWRpbw0KICAgVmlkZW8gUHJvZmls ZSkgZGVmaW5lZCBpbiBbUkZDMzU1MV0uICBTdWNoIGEgbWVjaGFuaXNtIGlzIHVzZWQgdG8NCiAg IHByb3ZpZGUgYSBtZWFucyBmb3IgZW5jcnlwdGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJv bm1lbnRzIHdoZXJlDQogICBzdXBwb3J0IGZvciBlbmNyeXB0aW9uIGlzIG5vdCBrbm93biBpbiBh ZHZhbmNlLCBhbmQgbm90IHJlcXVpcmVkLg0KICAgVGhlIHNhbWUgbWVjaGFuaXNtIGlzIGFsc28g YXBwbGllZCB0byBuZWdvdGlhdGlvbiBvZiB0aGUgRXh0ZW5kZWQgUlRQDQogICBQcm9maWxlIGZv ciBSZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRyb2wgUHJvdG9jb2wgQmFzZWQgRmVlZGJhY2sgKFJU UC8NCiAgIEFWUEYpIFtSRkM0NTg1XS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWh1dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi8NCg0KVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9u LTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24g YW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0 Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93 Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCg== --_000_6AD021E52C844BED88D8DFD5773C768Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5J4oCZbSBnbGFkIHRvIHNlZSB0aGlzIGRyYWZ0LiBPbmUgaW5pdGlhbCBjb21tZW50IGFmdGVy IGEgcXVpY2sgcmV2aWV3IC0gaW4gc2VjdGlvbiA1LCB0aGUgYW5zd2VyZXIgbXVzdCBhbHNvIGJl IGFsbG93ZWQgdG8gaW5kaWNhdGUgdGhlIHByb2ZpbGUgYXMgQVZQIG9yIFNBVlAgeWV0IHN0aWxs IGluY2x1ZGUgdGhlICZxdW90O2E9cnRjcC1mYiZxdW90OyBTRFAgYXR0cmlidXRlLiBUaGlzIGlz IG5vdCBhbGxvd2VkIGJ5IFJGQyA0NTg1LA0KIHNvIGl0IG11c3QgYmUgZGVzY3JpYmVkIGhlcmUg YXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIGl0IHdv dWxkIGJlIGdvb2QgdG8gcmVmZXJlbmNlIHRoZSBJTVRDIGJlc3QgcHJhY3RpY2UgZG9jdW1lbnQg dGhhdCBwb3B1bGFyaXplZCB0aGlzIHJlbGF4YXRpb24gb2YgUkZDIDQ1ODU6IElNVEMgMTAxNSDi gJMg4oCcU0lQIFZpZGVvIFByb2ZpbGUgQmVzdCBQcmFjdGljZXPigJ0uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmltdGMub3JnL2RvY3Vt ZW50cy9vZmZpY2lhbC1kb2N1bWVudHMvIj5odHRwOi8vd3d3LmltdGMub3JnL2RvY3VtZW50cy9v ZmZpY2lhbC1kb2N1bWVudHMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4N CjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+bW11c2lj ICZsdDttbXVzaWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEFuZHkgSHV0dG9u ICZsdDthbmR5aHV0dG9uLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIEphbnVhcnkgMjMsIDIwMTcgYXQgMzo1MSBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7bW11 c2ljLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7bW11c2ljLWNoYWlyc0BpZXRmLm9yZyZndDss ICZxdW90O3NpcGJyYW5keS1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGJyYW5keS1jaGFp cnNAaWV0Zi5vcmcmZ3Q7LCBCZW4gQ2FtcGJlbGwgJmx0O2JlbkBub3N0cnVtLmNvbSZndDssICZx dW90O21tdXNpY0BpZXRmLm9yZyZxdW90OyAmbHQ7bW11c2ljQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5bTU1VU0lDXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWh1dHRvbi1tbXVz aWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBq dXN0IHN1Ym1pdHRlZCB0aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJhZnQgaXMgdGhlIHJlc3VsdCBvZiBkaXNjdXNz aW9uIGluIHRoZSBTSVBCcmFuZHkgd29ya2luZyBncm91cCByZWdhcmRpbmcgaG93IHRvIHByb2Nl ZWQgd2l0aCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNpcGJyYW5keS1vc3J0cC0wMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2lwYnJhbmR5LW9zcnRwLTAxPC9hPi4mbmJzcDsgVGhlIFNJUEJyYW5keQ0KIFdHIHdh cyBub3QgYWJsZSB0byBwcm9ncmVzcyB0aGUgb3Bwb3J0dW5pc3RpYyBTUlRQIHdvcmsgYmVjYXVz ZSBpdCByZXF1aXJlZCBhbiB1cGRhdGUgdG8gUkZDIDQ1Njggd2hpY2ggaXMgbm90IGNvdmVyZWQg YnkgdGhlIFNJUEJyYW5keSBjaGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNob3J0IGRyYWZ0IGlzIHRoZXJlZm9yZSBzdWJt aXR0ZWQgdG8gTU1VU0lDIHdpdGggYSB2aWV3IHRvIHVwZGF0aW5nIHRoZSByZWxldmFudCBSRkMn cyBhbmQgcHJvZ3Jlc3NpbmcgdGhlIE9TUlRQIHdvcmsgaW4gU0lQQnJhbmR5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tLS0gRm9yd2Fy ZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBNb24sIEphbiAyMywgMjAxNyBhdCAxMTowOCBBTTxi cj4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWh1dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3Rp Yy1uZWdvdGlhdGlvbi0wMC50eHQ8YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5j ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs6IE5lZ290aWF0aW5nIFNSVFAgYW5kIFJUQ1AgRmVlZGJhY2sg dXNpbmcgdGhlIFJUUC9BVlAgUHJvZmlsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogQW5kcmV3IEh1dHRv bjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSb2xhbmQgSmVzc2tlPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsYW4gSm9obnN0b248YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgR29uemFsbyBTYWxndWVpcm88YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQmVybmFyZCBBYm9iYTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA6IGRyYWZ0LWh1dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQ8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogNjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE3LTAx LTIzPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGhvdyB0aGUgdXNlIG9mIHRoZSBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydDxi cj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbCAoU1JUUCkgW1JGQzM3MTFdLiBjYW4gYmUgbmVnb3Rp YXRlZCB1c2luZyB0aGUgQVZQIChBdWRpbzxicj4NCiZuYnNwOyAmbmJzcDtWaWRlbyBQcm9maWxl KSBkZWZpbmVkIGluIFtSRkMzNTUxXS4mbmJzcDsgU3VjaCBhIG1lY2hhbmlzbSBpcyB1c2VkIHRv PGJyPg0KJm5ic3A7ICZuYnNwO3Byb3ZpZGUgYSBtZWFucyBmb3IgZW5jcnlwdGVkIG1lZGlhIHRv IGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzIHdoZXJlPGJyPg0KJm5ic3A7ICZuYnNwO3N1cHBvcnQg Zm9yIGVuY3J5cHRpb24gaXMgbm90IGtub3duIGluIGFkdmFuY2UsIGFuZCBub3QgcmVxdWlyZWQu PGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBzYW1lIG1lY2hhbmlzbSBpcyBhbHNvIGFwcGxpZWQgdG8g bmVnb3RpYXRpb24gb2YgdGhlIEV4dGVuZGVkIFJUUDxicj4NCiZuYnNwOyAmbmJzcDtQcm9maWxl IGZvciBSZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRyb2wgUHJvdG9jb2wgQmFzZWQgRmVlZGJhY2sg KFJUUC88YnI+DQombmJzcDsgJm5ic3A7QVZQRikgW1JGQzQ1ODVdLjxicj4NCjxicj4NCjxicj4N ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1dHRvbi1t bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odXR0b24tbW11c2ljLW9wcG9ydHVuaXN0 aWMtbmVnb3RpYXRpb24vPC9hPjxicj4NCjxicj4NClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl cnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1odXR0b24tbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24tMDAiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLW1t dXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTAwPC9hPjxicj4NCjxicj4NCjxicj4NClBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2VJbnRlcm5ldC1E cmFmdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaS1kLWFubm91bmNlPGJyPg0KSW50ZXJuZXQtRHJhZnQ8L2E+IGRpcmVjdG9yaWVzOiA8YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPjxicj4NCm9yIDxhIGhyZWY9ImZ0cDov L2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6AD021E52C844BED88D8DFD5773C768Bciscocom_-- From nobody Tue Jan 24 07:50: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 D231E129A90; Tue, 24 Jan 2017 07:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 j_897IqLPin9; Tue, 24 Jan 2017 07:50:38 -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 76D76129624; Tue, 24 Jan 2017 07:50:38 -0800 (PST) Received: from [10.0.1.39] (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 v0OFoY56079865 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 09:50:34 -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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 24 Jan 2017 09:50:33 -0600 Message-ID: <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 15:50:42 -0000 On 24 Jan 2017, at 7:20, Christer Holmberg wrote: > Hi, > > ... > > >>>> -4.1, last paragraph: >>>> I assume this paragraph refers to fmt values used with >>>> UDP/DTLS/SCTP >>>> or TCP/DTLS/SCTP, >>>> not fmt values in general. >>> >>> Correct. >>> >>>> It would help to be explicit about that. >>> >>> The first sentence in section 4.1 does say: >>> >>> "This section defines the following new SDP Media Description (m- >>> line) protocol identifiers (proto values) for describing an SCTP >>> association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." >> >> I'm not sure all readers will see the connection between the first >> and >> last paragraph. I still think it would help to explicitly mention it. >> (Especially if it moves to 4.3) >> >> An alternative, if it were to stay in 4.1 would be to have the >> opening >> paragraph in 4.1 explicitly mention that it includes the fmt values >> to >> be used in the context of these new proto values. >> >>> >>>> (Also, it seem like this paragraph belongs in section 4.3). >>> >>> I could move and combine it with the 4th paragraph of section 4.3: >>> >>> "The m- line fmt value, identifying the application-layer >>> protocol, >>> MUST be registered by IANA. Section 15.3 defines the IANA >>> registry >>> for the media format namespace." > > > Ok, so my suggestion is to: > > 1) Move the paragraph to section 4.3, as described above > 2) Modify the first paragraph in section 4.1: > > "This section defines the following new SDP Media Description (m- > line) protocol identifiers (proto values) for describing an SCTP > association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section also > describes how an m- line, associated with the proto values, is > created, and how the the media format (Œfmt¹) values are used." The change helps, but does it still make sense if the last paragraph of 4.1 moves to 4.3? > > > > ---- > > >>>> -5.3: Why is the mux-category SPECIAL rather than CAUTION? IIUC, >>>> SPECIAL means you need to refer >>>> to the rules in the protocol definition. But the text here >>>> basically >>>> say that the rules are undefined. >>> >>> I'm ok using CAUTION. I agree it might be more appropriate than >>> SPECIAL. >> >> I'm glad we agree :-) > > You only mentioned section 5.3, but I think the same applies also to > section 6.3 (MUX category for the max-message-size-attribute), so I > suggest to change both to CAUTION. > >> This is probably a big enough change to make sure the workgroup also >> agrees, though. > > > *Sounds of crickets* > > Yes, it does agree :) Ok, if no one objects before the IETF LC completes, we will assume agreement :-) > > > ---- > > >>>> -6.1: What is meant by saying an "endpoint MUST assume that larger >>>> ... >>>> will be rejected"? Can that be stated in terms of actual procedure >>>> (e.g. >>>> "endpoint MUST NOT send...larger"? >>> >>> I'd like Roman's input on this, in case he had some cases in mind >>> where endpoint will have to send larger messages. >>> >>> I guess we could say SHOULD NO send larger message, and explain that >>> one cannot assume that larger message (if sent for whatever reason) >>> will be accepted by the peer. >> >> That would be reasonable if it is the right answer. I just want to >> avoid >> the vagueness of "MUST assume". > > I suggest the following modified text: > > "An SCTP endpoint SHOULD NOT send a SCTP user message with a message > size > that is larger than the maximum size indicated by the peer. If the > SCTP > endpoint needs (for whatever reason) to send a larger message, it > cannot > be assumed that the message will be accepted by the peer.² I'm okay with that, but don't be surprised if we get questions about whether it ever would ever make sense to send a message that you can't assume the peer will accept. (I wonder if it's more a matter of "probably not accept", given the peer has already stated its preference. > > > ---- > > >>>> -9.1, 2nd paragraph: Don't the lower layers need to be established >>>> before the >>>> upper layers? Won't removal of the TCP connection or DTLS >>>> association >>>> break >>>> an existing SCTP association? >>> >>> Roman had lots of input on this, so I'll let him reply. >> >> Okay > > See Roman¹s reply. Thanks, I will reply there. Ben. From nobody Tue Jan 24 08:38:45 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 7A487129628 for ; Tue, 24 Jan 2017 08:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 epf4f9iBMKfA for ; Tue, 24 Jan 2017 08:38:41 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 CA1331295A6 for ; Tue, 24 Jan 2017 08:38:41 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-04v.sys.comcast.net with SMTP id W44jcZIuH9RIgW47FcOcWl; Tue, 24 Jan 2017 16:38:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485275921; bh=wecENAfjrnBJ8rfFT2unkkOdqp+PqOvP6OmmFai6Ks0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Us2iYhyY0/vSXLhAnZnJitoz8s9gx6QJdgbakHNFPPzMrDxjSJ+i2loGh/8+phvlq 7TqWNo07QfXo315UwTw4EPH/ZXUE+sNXyg7qoTVgEe4YqfILbunPGGDH+iyBXWzBdF IRfjdtUgYp+GhUfUX2pbaltDzm9xcxA5yw1LTHE9wcK2XACZjZp8uaVqEwdlr+H3uv 7qKf3U4hqjSZiLv/GasMlyDwbIQ1RJqvgxR4Lh+n/QgCLKfcOf9hQUvf/NSyDnnZM0 vTHnWO37VJPiOuro4nyaQTINqSu6vvD/qmf0cKK8UY8WqDWOT3LDVl4jujfS/Rrzg8 LNPS/pF77id1A== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id W47DcsGhhTnqpW47FcUaL6; Tue, 24 Jan 2017 16:38:41 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> From: Paul Kyzivat Message-ID: Date: Tue, 24 Jan 2017 11:38:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBNZpSP0OBIVou1xk85l2TUYAvHh+zuFJ8qV32lcDF+P7AQUq2JYmjdWwDEbEvhT8mboRnfwEzvPaSEKzTbc52FZnN1O97GnU0KG6dLh88rhKcVFTWpf oU//Lg26DXysvu5LJkjvQFNPaz4ssiaWGgx7JRhLv0f5ycebUSniJ4Q/b/ho3Y9D59NoeM6cSri7/Q== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 16:38:43 -0000 Roman, On 1/23/17 8:16 PM, Roman Shpount wrote: > > On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell > wrote: > > On 21 Jan 2017, at 14:23, Christer Holmberg wrote: > > -9.1, 2nd paragraph: Don't the lower layers need to be > established before the > upper layers? Won't removal of the TCP connection or DTLS > association break > an existing SCTP association? > > > Roman had lots of input on this, so I'll let him reply. > > > Okay > > > Replacing of TCP connection or DTLS association does not break the SCTP > association. SCTP is designed to run over unreliable transports, so > short term loss of connectivity when one TCP connection or one DTLS > association is being replaced by the other would be handled by the SCTP > re-transmit timers. Also, when ICE is used, switching from one ICE > candidate to another, including switching between two ICE tcp candidates > or switching from udp to tcp candidate, does not affect existing SCTP > association. Existing SCTP association continues to run despite the > underlying candidate switch and as far as SCTP association is concerned > it is running over the same unreliable transport. Finally, DTLS > association can be re-established to force re-keying the long running > connection. This can be done without affecting SCTP association running > on top of these DTLS associations. > > This is why we are saying that the SCTP association, the DTLS > association and the TCP connection are managed independently from each > other. Each can be established and closed without impacting others. > Each protocol uses its own means to detect connection closure, failure > or timeout. I can see that this can be a good thing when it is what you want/need. OTOH, if one of the two parties involved changes, and there is no state sharing, you need to establish a new SCTP association. This may turn out to be the case even when the offerer doesn't know that the other party has changed. So how are these two cases distinguished in the signaling? AFAICT the only thing available is sctp-port. If the offerer doesn't realize a change is coming, then it won't change its port. And in that case the answerer won't know what port its predecessor used, so it might choose the same value. Of course, this is largely a 3pcc scenario, and if it is initiated in the middle then the middle can probably know to change the port somewhere. But I'm not sure if that is the only case. Thanks, Paul From nobody Tue Jan 24 08:41: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 A5FF4129628 for ; Tue, 24 Jan 2017 08:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 mHJ2mHKs4iiX for ; Tue, 24 Jan 2017 08:41:10 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 A374C1295A6 for ; Tue, 24 Jan 2017 08:41:10 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with SMTP id W48AcDZVBdT7bW49ecvFAK; Tue, 24 Jan 2017 16:41:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485276070; bh=bFEbyYiBQQA3jzt8O4UUZKkvHcSsVxsVdbMkClXZEis=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=l+DfcVnRKkXfVn8kjdEtA8+VDTU63V1B3Z6TsYGqepNe3XaMOOuXIlLJJlYchByKR pc0wegraHSu4dm0omEoWc81H7JHXNuh6eLhPnONaSkBxW4wjzMEi6Ek086Wk+LdQl3 SamIMeeqxRdv0M0i7w28j1NC/LJgEBaIiwM8tXU6f7evhBLxf+JljU3+PZns5TDEny GKRmPO6QIFF+4fdPXD+EP54WipKT2njK/N3iY0JNWDxOXYORm9SRg4qZKIDRqw7slI S28il8L6u8VmQDfBGd6kLc1uizdrcihmGFftEX3coYYfweIt1jj6VdV9m+OBOaa4Ed 2Xiez+u4Ah9AQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-17v.sys.comcast.net with SMTP id W49dcclh6mqJQW49dcRd5m; Tue, 24 Jan 2017 16:41:09 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> From: Paul Kyzivat Message-ID: Date: Tue, 24 Jan 2017 11:41:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfG4uv+2X22e69WdbwNJ085PLdGoxM/7C2sf7q8dcyA274LJyM4eIgFXCSt1OwQlbh0CId7H4qjIyNJnLtJKTWlYmsl052MdD68YpXNO346X6Js55mU+7 T4uPzE/q/zcolLfZlLMNHXXYoyniwVnoSR/cH3CfaVWYS2z7N3GjGx4nc0B08MOtik3bqbTL3Ds5Og== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments: CAUTION X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 16:41:11 -0000 On 1/24/17 8:20 AM, Christer Holmberg wrote: > You only mentioned section 5.3, but I think the same applies also to > section 6.3 (MUX category for the max-message-size-attribute), so I > suggest to change both to CAUTION. > >> This is probably a big enough change to make sure the workgroup also >> agrees, though. > > > *Sounds of crickets* > > Yes, it does agree :) This change seems good to me. Thanks, Paul From nobody Tue Jan 24 11:16: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 CF6A412964E; Tue, 24 Jan 2017 11:16:14 -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 hL08XB2h8ZAP; Tue, 24 Jan 2017 11:16: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 647E9129655; Tue, 24 Jan 2017 11:16:13 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-25-5887a7fb466f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id A4.7D.28805.BF7A7885; Tue, 24 Jan 2017 20:16:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 20:16:02 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAB+8QwAAAP0rgAAJB1jQ Date: Tue, 24 Jan 2017 19:16:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> In-Reply-To: <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbE9XPf38vYIgxfP5Szmd55mt9jUv4nF YuryxywWMy5MZXZg8Viy5CeTx6ydT1g8bk0pCGCO4rJJSc3JLEst0rdL4MrofLqDtWCJasXU A+8YGxhXqHQxcnBICJhINHwS72Lk4hASWMco8fzmJLYuRk4gZzGjxPFfAiA1bAIWEt3/tEHC IgJKEs+bt7KA2MwCs4Dqv0uD2MIC0RKH3l5mhKiJkTi7ZzEThO0m8eZbL1icRUBVYsXEbrA4 r4CvxJ5pn1gg9r5klOg5vpwRZBengL1E+05WkBpGATGJ76fWMEHsEpe49WQ+mC0hICCxZM95 ZghbVOLl43+sELaSxKLbn5lAxjALaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOoshI5Z SDpmIelYwMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwdg5u+W2wg/Hlc8dDjAIcjEo8 vB+y2yOEWBPLiitzDzFKcDArifB2zQIK8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9 sSQ1OzW1ILUIJsvEwSnVwBg4h+NY386C5pju9PL8Ap+duUf7/obcS41ZGt3KpP9B5kOjyzun WP8QXq57t/3mJrZobNm0SXiHUk/YsY/TAy4yTHVuTJm5Wu2QTorOGXtRvqmd3DPnXngiMynM PkLj6s2Jr469lfzZturS7yu/2w7zKDWq+LSeVjc3aF27vv/Gi/Y556Wu/VNiKc5INNRiLipO BABumhh2mQIAAA== Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 19:16:15 -0000 SGksDQoNCj4+Pj4+IC00LjEsIGxhc3QgcGFyYWdyYXBoOg0KPj4+Pj4gSSBhc3N1bWUgdGhpcyBw YXJhZ3JhcGggcmVmZXJzIHRvIGZtdCB2YWx1ZXMgdXNlZCB3aXRoIA0KPj4+Pj4gVURQL0RUTFMv U0NUUCBvciBUQ1AvRFRMUy9TQ1RQLCBub3QgZm10IHZhbHVlcyBpbiBnZW5lcmFsLg0KPj4+Pg0K Pj4+PiBDb3JyZWN0Lg0KPj4+Pg0KPj4+Pj4gSXQgd291bGQgaGVscCB0byBiZSBleHBsaWNpdCBh Ym91dCB0aGF0Lg0KPj4+Pg0KPj4+PiBUaGUgZmlyc3Qgc2VudGVuY2UgaW4gc2VjdGlvbiA0LjEg ZG9lcyBzYXk6DQo+Pj4+DQo+Pj4+ICAgICJUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgZm9sbG93 aW5nIG5ldyBTRFAgTWVkaWEgRGVzY3JpcHRpb24gKG0tDQo+Pj4+ICAgIGxpbmUpIHByb3RvY29s IGlkZW50aWZpZXJzIChwcm90byB2YWx1ZXMpIGZvciBkZXNjcmliaW5nIGFuIFNDVFANCj4+Pj4g ICAgYXNzb2NpYXRpb246ICdVRFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1NDVFAnLiINCj4+ Pg0KPj4+IEknbSBub3Qgc3VyZSBhbGwgcmVhZGVycyB3aWxsIHNlZSB0aGUgY29ubmVjdGlvbiBi ZXR3ZWVuIHRoZSBmaXJzdCANCj4+PiBhbmQgbGFzdCBwYXJhZ3JhcGguIEkgc3RpbGwgdGhpbmsg aXQgd291bGQgaGVscCB0byBleHBsaWNpdGx5IG1lbnRpb24gDQo+Pj4gaXQuDQo+Pj4gKEVzcGVj aWFsbHkgaWYgaXQgbW92ZXMgdG8gNC4zKQ0KPj4+DQo+Pj4gQW4gYWx0ZXJuYXRpdmUsIGlmIGl0 IHdlcmUgdG8gc3RheSBpbiA0LjEgd291bGQgYmUgdG8gaGF2ZSB0aGUgDQo+Pj4gb3BlbmluZyBw YXJhZ3JhcGggaW4gNC4xIGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0IGl0IGluY2x1ZGVzIHRoZSBm bXQgDQo+Pj4gdmFsdWVzIHRvIGJlIHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlc2UgbmV3IHBy b3RvIHZhbHVlcy4NCj4+Pg0KPj4+Pg0KPj4+Pj4gKEFsc28sIGl0IHNlZW0gbGlrZSB0aGlzIHBh cmFncmFwaCBiZWxvbmdzIGluIHNlY3Rpb24gNC4zKS4NCj4+Pj4NCj4+Pj4gSSBjb3VsZCBtb3Zl IGFuZCBjb21iaW5lIGl0IHdpdGggdGhlIDR0aCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjM6DQo+ Pj4+DQo+Pj4+ICAgICJUaGUgbS0gbGluZSBmbXQgdmFsdWUsIGlkZW50aWZ5aW5nIHRoZSBhcHBs aWNhdGlvbi1sYXllciANCj4+Pj4gICAgcHJvdG9jb2wsIE1VU1QgYmUgcmVnaXN0ZXJlZCBieSBJ QU5BLiBTZWN0aW9uIDE1LjMgZGVmaW5lcyB0aGUgSUFOQSANCj4+Pj4gICAgcmVnaXN0cnkgZm9y IHRoZSBtZWRpYSBmb3JtYXQgbmFtZXNwYWNlLiINCj4+Pj4NCj4+Pj4NCj4+IE9rLCBzbyBteSBz dWdnZXN0aW9uIGlzIHRvOg0KPj4NCj4+IDEpIE1vdmUgdGhlIHBhcmFncmFwaCB0byBzZWN0aW9u IDQuMywgYXMgZGVzY3JpYmVkIGFib3ZlDQo+PiAyKSBNb2RpZnkgdGhlIGZpcnN0IHBhcmFncmFw aCBpbiBzZWN0aW9uIDQuMToNCj4+DQo+PiAiVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIGZvbGxv d2luZyBuZXcgU0RQIE1lZGlhIERlc2NyaXB0aW9uIChtLQ0KPj4gICAgbGluZSkgcHJvdG9jb2wg aWRlbnRpZmllcnMgKHByb3RvIHZhbHVlcykgZm9yIGRlc2NyaWJpbmcgYW4gU0NUUA0KPj4gICAg YXNzb2NpYXRpb246ICdVRFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1NDVFAnLiAgVGhlIHNl Y3Rpb24gYWxzbw0KPj4gICAgZGVzY3JpYmVzIGhvdyBhbiBtLSBsaW5lLCBhc3NvY2lhdGVkIHdp dGggdGhlIHByb3RvIHZhbHVlcywgaXMgDQo+PiAgICBjcmVhdGVkLCBhbmQgaG93IHRoZSB0aGUg bWVkaWEgZm9ybWF0ICjFkmZtdMK5KSB2YWx1ZXMgYXJlIHVzZWQuIg0KPg0KPiBUaGUgY2hhbmdl IGhlbHBzLCBidXQgZG9lcyBpdCBzdGlsbCBtYWtlIHNlbnNlIGlmIHRoZSBsYXN0IHBhcmFncmFw aCBvZg0KPiA0LjEgbW92ZXMgdG8gNC4zPw0KDQpTbywgeW91IHN1Z2dlc3QgdG8gbm90IG1vdmUg dGhlIGxhc3QgcGFyYWdyYXBoIHRvIDQuMz8NCg0KLS0tLQ0KDQoNCj4+Pj4+IC02LjE6IFdoYXQg aXMgbWVhbnQgYnkgc2F5aW5nIGFuICJlbmRwb2ludCBNVVNUIGFzc3VtZSB0aGF0IGxhcmdlciAN Cj4+Pj4+IC4uLg0KPj4+Pj4gd2lsbCBiZSByZWplY3RlZCI/IENhbiB0aGF0IGJlIHN0YXRlZCBp biB0ZXJtcyBvZiBhY3R1YWwgcHJvY2VkdXJlIA0KPj4+Pj4gKGUuZy4NCj4+Pj4+ICJlbmRwb2lu dCBNVVNUIE5PVCBzZW5kLi4ubGFyZ2VyIj8NCj4+Pj4NCj4+Pj4gSSdkIGxpa2UgUm9tYW4ncyBp bnB1dCBvbiB0aGlzLCBpbiBjYXNlIGhlIGhhZCBzb21lIGNhc2VzIGluIG1pbmQgDQo+Pj4+IHdo ZXJlIGVuZHBvaW50IHdpbGwgaGF2ZSB0byBzZW5kIGxhcmdlciBtZXNzYWdlcy4NCj4+Pj4NCj4+ Pj4gSSBndWVzcyB3ZSBjb3VsZCBzYXkgU0hPVUxEIE5PIHNlbmQgbGFyZ2VyIG1lc3NhZ2UsIGFu ZCBleHBsYWluIHRoYXQgDQo+Pj4+IG9uZSBjYW5ub3QgYXNzdW1lIHRoYXQgbGFyZ2VyIG1lc3Nh Z2UgKGlmIHNlbnQgZm9yIHdoYXRldmVyIHJlYXNvbikgDQo+Pj4+IHdpbGwgYmUgYWNjZXB0ZWQg YnkgdGhlIHBlZXIuDQo+Pj4NCj4+PiBUaGF0IHdvdWxkIGJlIHJlYXNvbmFibGUgaWYgaXQgaXMg dGhlIHJpZ2h0IGFuc3dlci4gSSBqdXN0IHdhbnQgdG8gDQo+Pj4gYXZvaWQgdGhlIHZhZ3VlbmVz cyBvZiAiTVVTVCBhc3N1bWUiLg0KPj4NCj4+IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIG1vZGlm aWVkIHRleHQ6DQo+Pg0KPj4gIkFuIFNDVFAgZW5kcG9pbnQgU0hPVUxEIE5PVCBzZW5kIGEgU0NU UCB1c2VyIG1lc3NhZ2Ugd2l0aCBhIG1lc3NhZ2UgDQo+PiBzaXplIHRoYXQgaXMgbGFyZ2VyIHRo YW4gdGhlIG1heGltdW0gc2l6ZSBpbmRpY2F0ZWQgYnkgdGhlIHBlZXIuIElmIA0KPj4gdGhlIFND VFAgZW5kcG9pbnQgbmVlZHMgKGZvciB3aGF0ZXZlciByZWFzb24pIHRvIHNlbmQgYSBsYXJnZXIg DQo+PiBtZXNzYWdlLCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IHRoZSBtZXNzYWdlIHdpbGwg YmUgYWNjZXB0ZWQgYnkgdGhlIA0KPj4gcGVlci4iDQo+DQo+IEknbSBva2F5IHdpdGggdGhhdCwg YnV0IGRvbid0IGJlIHN1cnByaXNlZCBpZiB3ZSBnZXQgcXVlc3Rpb25zIGFib3V0IHdoZXRoZXIg aXQgZXZlciB3b3VsZCBldmVyIG1ha2UNCj4gc2Vuc2UgdG8gc2VuZCBhIG1lc3NhZ2UgdGhhdCB5 b3UgY2FuJ3QgYXNzdW1lIHRoZSBwZWVyIHdpbGwgYWNjZXB0LiAoSSB3b25kZXIgaWYgaXQncyBt b3JlIGEgbWF0dGVyIA0KPiBvZiAicHJvYmFibHkgbm90IGFjY2VwdCIsIGdpdmVuIHRoZSBwZWVy IGhhcyBhbHJlYWR5IHN0YXRlZCBpdHMgcHJlZmVyZW5jZS4NCg0KSWYgbm9ib2R5IG9iamVjdHMs IEkgYW0gb2sgc2F5aW5nICJNVVNUIE5PVCBzZW5kIi4NCg0KQmVjYXVzZSwgaWYgdGhlcmUgaXMg YSBjYXNlIHdoZXJlIGl0IHdvdWxkIGJlIG5lZWRlZCwgdGhlIHBlZXJzIHNpbXBseSBuZWVkIHRv IHN1cHBvcnQgYW5kIG5lZ290aWF0ZSBhIGxhcmdlciB2YWx1ZS4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg== From nobody Tue Jan 24 11:18: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 E4B4212966C for ; Tue, 24 Jan 2017 11:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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] 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 vUzHi0IrHMG7 for ; Tue, 24 Jan 2017 11:18:45 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A1612966B for ; Tue, 24 Jan 2017 11:18:44 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id l23so100950104ybj.2 for ; Tue, 24 Jan 2017 11:18:44 -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=cWEao2wS1QEnrIorzpcnVxzduKreAVAQn3IwiMBfK4c=; b=N/l0pqg7b2uy/Tw6DWf01Z6WbRnDbyNsrZGCyjdzFBVv+9/cRwLuYMbHZDezyEUaYI QDo3hBVnwYlyiF+cJU+QndwPc6iA4HrcM0uArkTnHuF7pNeGHosuDEFjYmvaeZbdVHEV b4/3+aiFQrxSXZPNH9fcHCIhd9YwkN1vISREPpeLMXHrvpl0PjY7gEzo05Ulfr2VzBId WJvGxm+TyCq9Pb/fqWYPKOCBiTlocNfQ8MAry7eJvnCzTW//WyyT+Cxx6MJbGzvXIXlj 75AuYqGYkeNfTjgNU3HDKQX3MMh1mAYVyS1oCeuO2zUUiyWQ/hplWIy8KYmsZYxa+d5t TUew== 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=cWEao2wS1QEnrIorzpcnVxzduKreAVAQn3IwiMBfK4c=; b=dMrLUeyyGsgpqEu6lPabdG5TFyO8646mpATfRpe0kVGlhwv5Vx7szx3h8lYc43sX/p bJfFtRKbhzI1TzTTAVccJQ39oH6OWZEVo141hQR56H8d4JFw5J0FGucLMKGhHVt9ceQm fmVWBAx8GxUPpYiVw9bBlMhB3MFwbsoVAXqKKa3GQvP1zulkeXRk8KLbsNkV2TvNu5IU /LgIEVSDvJNzGBgYc5l92s3Qb+eXUJD/e2EAV9op0MeJXtLjvHaOz/TouiMx6JIu28G5 CjI154mTZGYMklRqlISfmG/Q1NFA76tKjhVYEiuIWlNPvEDXA9MfnkYMiGdUOEK+7hVB YGuA== X-Gm-Message-State: AIkVDXJdldexhsHHopvCCNDTM+LrEPkrBX96SnW69AIddodmyxOUo4RLcccYq7sapLhVpQ== X-Received: by 10.37.165.101 with SMTP id h92mr2323249ybi.83.1485285523946; Tue, 24 Jan 2017 11:18:43 -0800 (PST) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com. [209.85.216.176]) by smtp.gmail.com with ESMTPSA id c75sm10302725ywb.4.2017.01.24.11.18.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 11:18:43 -0800 (PST) Received: by mail-qt0-f176.google.com with SMTP id l7so201138608qtd.1 for ; Tue, 24 Jan 2017 11:18:43 -0800 (PST) X-Received: by 10.200.52.129 with SMTP id w1mr29029984qtb.43.1485285523230; Tue, 24 Jan 2017 11:18:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 24 Jan 2017 11:18:42 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> From: Roman Shpount Date: Tue, 24 Jan 2017 14:18:42 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11479b4a009e0b0546dbfc9f Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 19:18:46 -0000 --001a11479b4a009e0b0546dbfc9f Content-Type: text/plain; charset=UTF-8 On Tue, Jan 24, 2017 at 11:38 AM, Paul Kyzivat wrote: > Roman, > > On 1/23/17 8:16 PM, Roman Shpount wrote: > >> >> On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell > > wrote: >> >> On 21 Jan 2017, at 14:23, Christer Holmberg wrote: >> >> -9.1, 2nd paragraph: Don't the lower layers need to be >> established before the >> upper layers? Won't removal of the TCP connection or DTLS >> association break >> an existing SCTP association? >> >> >> Roman had lots of input on this, so I'll let him reply. >> >> >> Okay >> >> >> Replacing of TCP connection or DTLS association does not break the SCTP >> association. SCTP is designed to run over unreliable transports, so >> short term loss of connectivity when one TCP connection or one DTLS >> association is being replaced by the other would be handled by the SCTP >> re-transmit timers. Also, when ICE is used, switching from one ICE >> candidate to another, including switching between two ICE tcp candidates >> or switching from udp to tcp candidate, does not affect existing SCTP >> association. Existing SCTP association continues to run despite the >> underlying candidate switch and as far as SCTP association is concerned >> it is running over the same unreliable transport. Finally, DTLS >> association can be re-established to force re-keying the long running >> connection. This can be done without affecting SCTP association running >> on top of these DTLS associations. >> >> This is why we are saying that the SCTP association, the DTLS >> association and the TCP connection are managed independently from each >> other. Each can be established and closed without impacting others. >> Each protocol uses its own means to detect connection closure, failure >> or timeout. >> > > I can see that this can be a good thing when it is what you want/need. > > OTOH, if one of the two parties involved changes, and there is no state > sharing, you need to establish a new SCTP association. This may turn out to > be the case even when the offerer doesn't know that the other party has > changed. > > So how are these two cases distinguished in the signaling? AFAICT the only > thing available is sctp-port. If the offerer doesn't realize a change is > coming, then it won't change its port. And in that case the answerer won't > know what port its predecessor used, so it might choose the same value. > > Of course, this is largely a 3pcc scenario, and if it is initiated in the > middle then the middle can probably know to change the port somewhere. > > But I'm not sure if that is the only case. > We have considered that issue and assumed that selecting a random sctp-port is sufficient to determine if this is the same vs new connection. There is some possibility of collisions when answering party accidentally picks the same port as the one which was previously used for SCTP communications, but this is similar to ICE ufrag collisions, dtls-id collisions or to-tag collisions. I do agree that sctp-port has less random bits then ufrag, dtls-id, or to-tag, so it is more likely to collide. Please let us know if this is a sufficient point of concern to warrant adding more randomness by changing sctp-port definition (making it longer) or adding another attribute. Another solution would be to require SCTP association restart on DTLS association restart and use random bits in dtls-id minimize the chance of collision. In general, I am not strongly attached to not restarting SCTP association on underlying transport change. I am even less attached to restarting SCTP on DTLS restart. What I do feel strongly about is: 1. Keeping SCTP association when ICE candidates change 2. Keeping SCTP association on ICE restart Keeping SCTP association on ICE restart has exactly the same properties as keeping SCTP association on transport change (it is unclear if ICE restart was caused by the same endpoint or by endpoint change due to 3pcc). Since ICE restart and transport change are essentially the same thing, I proposed that SCTP association is preserved in both cases. If we tie SCTP association restart to DTLS association restart we will get the desired result for ICE only at the cost of loosing re-key ability for the existing SCTP association. So, my questions are: 1. Is possibility of sctp-port collision large enough concern to change when SCTP association is restarted? 2. Would it be acceptable to lose ability to re-key DTLS association while running the same SCTP assignations and force SCTP association restart on DTLS association restart? Regards, _____________ Roman Shpount --001a11479b4a009e0b0546dbfc9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 24, 2017 = at 11:38 AM, Paul Kyzivat <paul.kyzivat@comcast.net> = wrote:
Roman,

On 1/23/17 8:16 PM, Roman Shpount wrote:

On Mon, Jan 23, 2017 at 7:13 PM, Ben Campbell <ben@nostrum.com
<mailto:ben@nostrum= .com>> wrote:

=C2=A0 =C2=A0 On 21 Jan 2017, at 14:23, Christer Holmberg wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -9.1, 2nd paragraph: Don't th= e lower layers need to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 established before the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 upper layers? Won't removal o= f the TCP connection or DTLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 association break
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 an existing SCTP association?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Roman had lots of input on this, so I'll le= t him reply.


=C2=A0 =C2=A0 Okay


Replacing of TCP connection or DTLS association does not break the SCTP
association. SCTP is designed to run over unreliable transports, so
short term loss of connectivity when one TCP connection or one DTLS
association is being replaced by the other would be handled by the SCTP
re-transmit timers. Also, when ICE is used, switching from one ICE
candidate to another, including switching between two ICE tcp candidates or switching from udp to tcp candidate, does not affect existing SCTP
association. Existing SCTP association continues to run despite the
underlying candidate switch and as far as SCTP association is concerned
it is running over the same unreliable transport. Finally, DTLS
association can be re-established to force re-keying the long running
connection. This can be done without affecting SCTP association running
on top of these DTLS associations.

This is why we are saying that the SCTP association, the DTLS
association and the TCP connection are managed independently from each
other.=C2=A0 Each can be established and=C2=A0 closed without impacting oth= ers.
Each protocol uses its own means to detect connection closure, failure
or timeout.

I can see that this can be a good thing when it is what you want/need.

OTOH, if one of the two parties involved changes, and there is no state sha= ring, you need to establish a new SCTP association. This may turn out to be= the case even when the offerer doesn't know that the other party has c= hanged.

So how are these two cases distinguished in the signaling? AFAICT the only = thing available is sctp-port. If the offerer doesn't realize a change i= s coming, then it won't change its port. And in that case the answerer = won't know what port its predecessor used, so it might choose the same = value.

Of course, this is largely a 3pcc scenario, and if it is initiated in the m= iddle then the middle can probably know to change the port somewhere.

But I'm not sure if that is the only case.

We have considered that issue and assumed that selecting a random s= ctp-port is sufficient to determine if this is the same vs new connection. = There is some possibility of collisions when answering party accidentally p= icks the same port as the one which was previously used for SCTP communicat= ions, but this is similar to ICE ufrag collisions,=C2=A0dtls-id collisions = or to-tag collisions. I do agree that sctp-port has less random bits then u= frag, dtls-id, or to-tag, so it is more likely to collide. Please let us kn= ow if this is a sufficient point of concern to warrant adding more randomne= ss by changing sctp-port definition (making it longer) or adding another at= tribute. Another solution would be to require SCTP association restart on D= TLS association restart and use random bits in dtls-id minimize the chance = of collision.

In general, I am not strongly attach= ed to not restarting SCTP association on underlying transport change. I am = even less attached to restarting SCTP on DTLS restart.

=
What I do feel strongly about is:

1. Keeping = SCTP association when ICE candidates change
2. Keeping SCTP assoc= iation on ICE restart

Keeping SCTP association on = ICE restart has exactly the same properties as keeping SCTP association on = transport change (it is unclear if ICE restart was caused by the same endpo= int or by endpoint change due to 3pcc). Since ICE restart and transport cha= nge are essentially the same thing, I proposed that SCTP association is pre= served in both cases. If we tie SCTP association restart to DTLS associatio= n restart we will get the desired result for ICE only at the cost of loosin= g re-key ability for the existing SCTP association.

So, my questions are:
1. Is possibility of sctp-port collision = large enough concern to change when SCTP association is restarted?
2. Would it be acceptable to lose ability to re-key DTLS association whil= e running the same SCTP assignations and force SCTP association restart on = DTLS association restart?=C2=A0

Regards,
_____________
Roman Shpount
=C2=A0
--001a11479b4a009e0b0546dbfc9f-- From nobody Tue Jan 24 11:22: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 349B4129653; Tue, 24 Jan 2017 11:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 uQ30MiDXslNN; Tue, 24 Jan 2017 11:22:16 -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 E627312959B; Tue, 24 Jan 2017 11:22:15 -0800 (PST) Received: from [10.0.1.39] (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 v0OJMBoP099606 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 13:22:11 -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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 24 Jan 2017 13:22:11 -0600 Message-ID: <4D41BE8E-73C7-4976-AEB2-1A2EA0F60B53@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 19:22:20 -0000 On 24 Jan 2017, at 13:16, Christer Holmberg wrote: > Hi, > >>>>>> -4.1, last paragraph: >>>>>> I assume this paragraph refers to fmt values used with >>>>>> UDP/DTLS/SCTP or TCP/DTLS/SCTP, not fmt values in general. >>>>> >>>>> Correct. >>>>> >>>>>> It would help to be explicit about that. >>>>> >>>>> The first sentence in section 4.1 does say: >>>>> >>>>> "This section defines the following new SDP Media Description >>>>> (m- >>>>> line) protocol identifiers (proto values) for describing an >>>>> SCTP >>>>> association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." >>>> >>>> I'm not sure all readers will see the connection between the first >>>> and last paragraph. I still think it would help to explicitly >>>> mention >>>> it. >>>> (Especially if it moves to 4.3) >>>> >>>> An alternative, if it were to stay in 4.1 would be to have the >>>> opening paragraph in 4.1 explicitly mention that it includes the >>>> fmt >>>> values to be used in the context of these new proto values. >>>> >>>>> >>>>>> (Also, it seem like this paragraph belongs in section 4.3). >>>>> >>>>> I could move and combine it with the 4th paragraph of section 4.3: >>>>> >>>>> "The m- line fmt value, identifying the application-layer >>>>> protocol, MUST be registered by IANA. Section 15.3 defines the >>>>> IANA >>>>> registry for the media format namespace." >>>>> >>>>> >>> Ok, so my suggestion is to: >>> >>> 1) Move the paragraph to section 4.3, as described above >>> 2) Modify the first paragraph in section 4.1: >>> >>> "This section defines the following new SDP Media Description (m- >>> line) protocol identifiers (proto values) for describing an SCTP >>> association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section >>> also >>> describes how an m- line, associated with the proto values, is >>> created, and how the the media format (Œfmt¹) values are used." >> >> The change helps, but does it still make sense if the last paragraph >> of >> 4.1 moves to 4.3? > > So, you suggest to not move the last paragraph to 4.3? No, my suggestion is to either (put the additional sentence in the first paragraph of 4.1 and keep last paragraph in 4.1) _OR_ (move the paragraph to 4.3 and put the clarification in _that_ paragraph.) (Personally I like the latter, but either are okay.) > > ---- > > >>>>>> -6.1: What is meant by saying an "endpoint MUST assume that >>>>>> larger >>>>>> ... >>>>>> will be rejected"? Can that be stated in terms of actual >>>>>> procedure >>>>>> (e.g. >>>>>> "endpoint MUST NOT send...larger"? >>>>> >>>>> I'd like Roman's input on this, in case he had some cases in mind >>>>> where endpoint will have to send larger messages. >>>>> >>>>> I guess we could say SHOULD NO send larger message, and explain >>>>> that >>>>> one cannot assume that larger message (if sent for whatever >>>>> reason) >>>>> will be accepted by the peer. >>>> >>>> That would be reasonable if it is the right answer. I just want to >>>> avoid the vagueness of "MUST assume". >>> >>> I suggest the following modified text: >>> >>> "An SCTP endpoint SHOULD NOT send a SCTP user message with a message >>> size that is larger than the maximum size indicated by the peer. If >>> the SCTP endpoint needs (for whatever reason) to send a larger >>> message, it cannot be assumed that the message will be accepted by >>> the >>> peer." >> >> I'm okay with that, but don't be surprised if we get questions about >> whether it ever would ever make >> sense to send a message that you can't assume the peer will accept. >> (I wonder if it's more a matter >> of "probably not accept", given the peer has already stated its >> preference. > > If nobody objects, I am ok saying "MUST NOT send". > > Because, if there is a case where it would be needed, the peers simply > need to support and negotiate a larger value. Okay with me. If someone comes up with a plausible reason one might need to send larger messages, please speak up before the IETF LC completes. :-) Ben. From nobody Tue Jan 24 12:05: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 36A291296DA; Tue, 24 Jan 2017 12:05: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 p0cuEoD4khmJ; Tue, 24 Jan 2017 12:05:31 -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 78CB51296D4; Tue, 24 Jan 2017 12:05:30 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-4c-5887b388f359 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id F9.AA.32317.883B7885; Tue, 24 Jan 2017 21:05:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 21:04:19 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAB+8QwAAAP0rgAAJB1jQ///y5oD//+Z8QA== Date: Tue, 24 Jan 2017 20:04:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFB5800@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> <4D41BE8E-73C7-4976-AEB2-1A2EA0F60B53@nostrum.com> In-Reply-To: <4D41BE8E-73C7-4976-AEB2-1A2EA0F60B53@nostrum.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbHdTLdjc3uEQcNiZYv5nafZLTb1b2Kx mLr8MYvFjAtTmR1YPJYs+cnkMWvnExaPW1MKApijuGxSUnMyy1KL9O0SuDIed25iLFhkVLGr qYm1gfGPQRcjB4eEgInE5gMKXYxcHEIC6xgl3kx8zwjhLGaUOPXoHhtIEZuAhUT3P+0uRk4O EQEliefNW1lAbGaBWYwSz79Lg9jCAtESh95eZoSoiZE4u2cxE4QdJtHe8x/MZhFQlVizsJ8Z xOYV8JU4evcyO8SuR0wSuz//ZAfZxSlgL/GkB2wmo4CYxPdTa5ggdolL3HoyH8yWEBCQWLLn PDOELSrx8vE/VghbSWLR7c9MIGOYBTQl1u/Sh2hVlJjS/ZAdYq2gxMmZT1gmMIrOQjJ1FkLH LCQds5B0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGD0Ht/zW3cG4+rXjIUYBDkYl Ht4P2e0RQqyJZcWVuYcYJTiYlUR4u2YBhXhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQ nliSmp2aWpBaBJNl4uCUamDUkf24sbzPZenzb7fmLDTZbPyrMGzF/fdME2ev+jnzwr6dhjtu /Ghk6ppizfZiw7/JBwo6FnSe7tjY8e+AlmWz0MqDBQHTpEMSDtdeUgtzSPzcpLFQ4t7Hhpmq B3X4+0yClnWp66ebnlfb+KP+kOU2EfsbbMszjLuvaLsbe3qce8pq6J/b0HpIiaU4I9FQi7mo OBEAlK3eiJoCAAA= Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 20:05:32 -0000 SGksDQoNCj4+Pj4+Pj4gLTQuMSwgbGFzdCBwYXJhZ3JhcGg6DQo+Pj4+Pj4+IEkgYXNzdW1lIHRo aXMgcGFyYWdyYXBoIHJlZmVycyB0byBmbXQgdmFsdWVzIHVzZWQgd2l0aCANCj4+Pj4+Pj4gVURQ L0RUTFMvU0NUUCBvciBUQ1AvRFRMUy9TQ1RQLCBub3QgZm10IHZhbHVlcyBpbiBnZW5lcmFsLg0K Pj4+Pj4+DQo+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pg0KPj4+Pj4+PiBJdCB3b3VsZCBoZWxwIHRv IGJlIGV4cGxpY2l0IGFib3V0IHRoYXQuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgZmlyc3Qgc2VudGVu Y2UgaW4gc2VjdGlvbiA0LjEgZG9lcyBzYXk6DQo+Pj4+Pj4NCj4+Pj4+PiAgICAiVGhpcyBzZWN0 aW9uIGRlZmluZXMgdGhlIGZvbGxvd2luZyBuZXcgU0RQIE1lZGlhIERlc2NyaXB0aW9uDQo+Pj4+ Pj4gICAgICAobS0gbGluZSkgcHJvdG9jb2wgaWRlbnRpZmllcnMgKHByb3RvIHZhbHVlcykgZm9y IGRlc2NyaWJpbmcgYW4gDQo+Pj4+Pj4gICAgICBTQ1RQIGFzc29jaWF0aW9uOiAnVURQL0RUTFMv U0NUUCcgYW5kICdUQ1AvRFRMUy9TQ1RQJy4iDQo+Pj4+Pg0KPj4+Pj4gSSdtIG5vdCBzdXJlIGFs bCByZWFkZXJzIHdpbGwgc2VlIHRoZSBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGZpcnN0IA0KPj4+ Pj4gYW5kIGxhc3QgcGFyYWdyYXBoLiBJIHN0aWxsIHRoaW5rIGl0IHdvdWxkIGhlbHAgdG8gZXhw bGljaXRseSANCj4+Pj4+IG1lbnRpb24gaXQuDQo+Pj4+PiAoRXNwZWNpYWxseSBpZiBpdCBtb3Zl cyB0byA0LjMpDQo+Pj4+Pg0KPj4+Pj4gQW4gYWx0ZXJuYXRpdmUsIGlmIGl0IHdlcmUgdG8gc3Rh eSBpbiA0LjEgd291bGQgYmUgdG8gaGF2ZSB0aGUgDQo+Pj4+PiBvcGVuaW5nIHBhcmFncmFwaCBp biA0LjEgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgaXQgaW5jbHVkZXMgdGhlIA0KPj4+Pj4gZm10 IHZhbHVlcyB0byBiZSB1c2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZXNlIG5ldyBwcm90byB2YWx1 ZXMuDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+PiAoQWxzbywgaXQgc2VlbSBsaWtlIHRoaXMgcGFy YWdyYXBoIGJlbG9uZ3MgaW4gc2VjdGlvbiA0LjMpLg0KPj4+Pj4+DQo+Pj4+Pj4gSSBjb3VsZCBt b3ZlIGFuZCBjb21iaW5lIGl0IHdpdGggdGhlIDR0aCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjM6 DQo+Pj4+Pj4NCj4+Pj4+PiAgICAiVGhlIG0tIGxpbmUgZm10IHZhbHVlLCBpZGVudGlmeWluZyB0 aGUgYXBwbGljYXRpb24tbGF5ZXINCj4+Pj4+PiAgICBwcm90b2NvbCwgTVVTVCBiZSByZWdpc3Rl cmVkIGJ5IElBTkEuIFNlY3Rpb24gMTUuMyBkZWZpbmVzIHRoZSANCj4+Pj4+PiAgICBJQU5BIHJl Z2lzdHJ5IGZvciB0aGUgbWVkaWEgZm9ybWF0IG5hbWVzcGFjZS4iDQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+PiBPaywgc28gbXkgc3VnZ2VzdGlvbiBpcyB0bzoNCj4+Pj4NCj4+Pj4gMSkgTW92ZSB0aGUg cGFyYWdyYXBoIHRvIHNlY3Rpb24gNC4zLCBhcyBkZXNjcmliZWQgYWJvdmUNCj4+Pj4gMikgTW9k aWZ5IHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gc2VjdGlvbiA0LjE6DQo+Pj4+DQo+Pj4+ICJUaGlz IHNlY3Rpb24gZGVmaW5lcyB0aGUgZm9sbG93aW5nIG5ldyBTRFAgTWVkaWEgRGVzY3JpcHRpb24g KG0tDQo+Pj4+ICAgIGxpbmUpIHByb3RvY29sIGlkZW50aWZpZXJzIChwcm90byB2YWx1ZXMpIGZv ciBkZXNjcmliaW5nIGFuIFNDVFANCj4+Pj4gICAgYXNzb2NpYXRpb246ICdVRFAvRFRMUy9TQ1RQ JyBhbmQgJ1RDUC9EVExTL1NDVFAnLiAgVGhlIHNlY3Rpb24gDQo+Pj4+ICAgIGFsc28gZGVzY3Jp YmVzIGhvdyBhbiBtLSBsaW5lLCBhc3NvY2lhdGVkIHdpdGggdGhlIHByb3RvIHZhbHVlcywgaXMN Cj4+Pj4gICAgY3JlYXRlZCwgYW5kIGhvdyB0aGUgdGhlIG1lZGlhIGZvcm1hdCAoxZJmbXTCuSkg dmFsdWVzIGFyZSB1c2VkLiINCj4+Pg0KPj4+IFRoZSBjaGFuZ2UgaGVscHMsIGJ1dCBkb2VzIGl0 IHN0aWxsIG1ha2Ugc2Vuc2UgaWYgdGhlIGxhc3QgcGFyYWdyYXBoIA0KPj4+IG9mIDQuMSBtb3Zl cyB0byA0LjM/DQo+Pg0KPj4gU28sIHlvdSBzdWdnZXN0IHRvIG5vdCBtb3ZlIHRoZSBsYXN0IHBh cmFncmFwaCB0byA0LjM/DQo+DQo+IE5vLCBteSBzdWdnZXN0aW9uIGlzIHRvIGVpdGhlciAocHV0 IHRoZSBhZGRpdGlvbmFsIHNlbnRlbmNlIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgNC4xIGFu ZCBrZWVwIGxhc3QNCj4gcGFyYWdyYXBoIGluIDQuMSkgX09SXyAobW92ZSB0aGUgcGFyYWdyYXBo IHRvIDQuMyBhbmQgcHV0IHRoZSBjbGFyaWZpY2F0aW9uIGluIF90aGF0XyBwYXJhZ3JhcGguKQ0K DQpPaywgc286DQoNCjEpIERvbid0IG1vZGlmeSB0aGUgMXN0IHBhcmFncmFwaCBpbiA0LjENCjIp IE1vdmUgdGhlIGxhc3QgcGFyYWdyYXBoIHRvIDQuMw0KMykgTW9kaWZ5IHRoZSBwYXJhZ3JhcGgg aW4gNC4zOg0KDQogICAgICAiV2hlbiB0aGUgJ1VEUC9EVExTL1NDVFAnIGFuZCAnVENQL0RUTFMv U0NUUCcgcHJvdG8gdmFsdWVzLCANCiAgICAgICAgdGhlIG0tIGxpbmUgZm10IHZhbHVlLCBpZGVu dGlmeWluZyB0aGUgYXBwbGljYXRpb24tbGF5ZXINCiAgICAgICAgcm90b2NvbCwgTVVTVCBiZSBy ZWdpc3RlcmVkIGJ5IElBTkEuIFNlY3Rpb24gMTUuMyBkZWZpbmVzIHRoZSAgDQogICAgICAgIElB TkEgcmVnaXN0cnkgZm9yIHRoZSBtZWRpYSBmb3JtYXQgbmFtZXNwYWNlLiIgDQoNCi0tLS0NCg0K Pj4+Pj4+PiAtNi4xOiBXaGF0IGlzIG1lYW50IGJ5IHNheWluZyBhbiAiZW5kcG9pbnQgTVVTVCBh c3N1bWUgdGhhdCANCj4+Pj4+Pj4gbGFyZ2VyIC4uLg0KPj4+Pj4+PiB3aWxsIGJlIHJlamVjdGVk Ij8gQ2FuIHRoYXQgYmUgc3RhdGVkIGluIHRlcm1zIG9mIGFjdHVhbCANCj4+Pj4+Pj4gcHJvY2Vk dXJlIChlLmcuDQo+Pj4+Pj4+ICJlbmRwb2ludCBNVVNUIE5PVCBzZW5kLi4ubGFyZ2VyIj8NCj4+ Pj4+Pg0KPj4+Pj4+IEknZCBsaWtlIFJvbWFuJ3MgaW5wdXQgb24gdGhpcywgaW4gY2FzZSBoZSBo YWQgc29tZSBjYXNlcyBpbiBtaW5kIA0KPj4+Pj4+IHdoZXJlIGVuZHBvaW50IHdpbGwgaGF2ZSB0 byBzZW5kIGxhcmdlciBtZXNzYWdlcy4NCj4+Pj4+Pg0KPj4+Pj4+IEkgZ3Vlc3Mgd2UgY291bGQg c2F5IFNIT1VMRCBOTyBzZW5kIGxhcmdlciBtZXNzYWdlLCBhbmQgZXhwbGFpbiANCj4+Pj4+PiB0 aGF0IG9uZSBjYW5ub3QgYXNzdW1lIHRoYXQgbGFyZ2VyIG1lc3NhZ2UgKGlmIHNlbnQgZm9yIHdo YXRldmVyDQo+Pj4+Pj4gcmVhc29uKQ0KPj4+Pj4+IHdpbGwgYmUgYWNjZXB0ZWQgYnkgdGhlIHBl ZXIuDQo+Pj4+Pg0KPj4+Pj4gVGhhdCB3b3VsZCBiZSByZWFzb25hYmxlIGlmIGl0IGlzIHRoZSBy aWdodCBhbnN3ZXIuIEkganVzdCB3YW50IHRvIA0KPj4+Pj4gYXZvaWQgdGhlIHZhZ3VlbmVzcyBv ZiAiTVVTVCBhc3N1bWUiLg0KPj4+Pg0KPj4+PiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBtb2Rp ZmllZCB0ZXh0Og0KPj4+Pg0KPj4+PiAiQW4gU0NUUCBlbmRwb2ludCBTSE9VTEQgTk9UIHNlbmQg YSBTQ1RQIHVzZXIgbWVzc2FnZSB3aXRoIGEgbWVzc2FnZSANCj4+Pj4gc2l6ZSB0aGF0IGlzIGxh cmdlciB0aGFuIHRoZSBtYXhpbXVtIHNpemUgaW5kaWNhdGVkIGJ5IHRoZSBwZWVyLiBJZiANCj4+ Pj4gdGhlIFNDVFAgZW5kcG9pbnQgbmVlZHMgKGZvciB3aGF0ZXZlciByZWFzb24pIHRvIHNlbmQg YSBsYXJnZXIgDQo+Pj4+IG1lc3NhZ2UsIGl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgdGhlIG1l c3NhZ2Ugd2lsbCBiZSBhY2NlcHRlZCBieSANCj4+Pj4gdGhlIHBlZXIuIg0KPj4+DQo+Pj4gSSdt IG9rYXkgd2l0aCB0aGF0LCBidXQgZG9uJ3QgYmUgc3VycHJpc2VkIGlmIHdlIGdldCBxdWVzdGlv bnMgYWJvdXQgDQo+Pj4gd2hldGhlciBpdCBldmVyIHdvdWxkIGV2ZXIgbWFrZSBzZW5zZSB0byBz ZW5kIGEgbWVzc2FnZSB0aGF0IHlvdSANCj4+PiBjYW4ndCBhc3N1bWUgdGhlIHBlZXIgd2lsbCBh Y2NlcHQuDQo+Pj4gKEkgd29uZGVyIGlmIGl0J3MgbW9yZSBhIG1hdHRlcg0KPj4+IG9mICJwcm9i YWJseSBub3QgYWNjZXB0IiwgZ2l2ZW4gdGhlIHBlZXIgaGFzIGFscmVhZHkgc3RhdGVkIGl0cyAN Cj4+PiBwcmVmZXJlbmNlLg0KPj4NCj4+IElmIG5vYm9keSBvYmplY3RzLCBJIGFtIG9rIHNheWlu ZyAiTVVTVCBOT1Qgc2VuZCIuDQo+Pg0KPj4gQmVjYXVzZSwgaWYgdGhlcmUgaXMgYSBjYXNlIHdo ZXJlIGl0IHdvdWxkIGJlIG5lZWRlZCwgdGhlIHBlZXJzIHNpbXBseSANCj4+IG5lZWQgdG8gc3Vw cG9ydCBhbmQgbmVnb3RpYXRlIGEgbGFyZ2VyIHZhbHVlLg0KPg0KPiBPa2F5IHdpdGggbWUuIElm IHNvbWVvbmUgY29tZXMgdXAgd2l0aCBhIHBsYXVzaWJsZSByZWFzb24gb25lIG1pZ2h0IG5lZWQg dG8gc2VuZCBsYXJnZXIgbWVzc2FnZXMsIHBsZWFzZSBzcGVhayB1cCBiZWZvcmUgdGhlIElFVEYg TEMgY29tcGxldGVzLiA6LSkNCg0KU3VnZ2VzdGVkIG1vZGlmaWVkIHBhcmFncmFwaDoNCg0KICAg ICAgICAgIkFuIFNDVFAgZW5kcG9pbnQgTVVTVCBOT1Qgc2VuZCBhIFNDVFAgdXNlciBtZXNzYWdl IHdpdGggYSBtZXNzYWdlIA0KICAgICAgICAgIHNpemUgdGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUg bWF4aW11bSBzaXplIGluZGljYXRlZCBieSB0aGUgcGVlciwgYXMgaXQgDQogICAgICAgICAgY2Fu bm90IGJlIGFzc3VtZWQgdGhhdCB0aGUgcGVlciB3b3VsZCBhY2NlcHQgc3VjaCBtZXNzYWdlLiIN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg== From nobody Tue Jan 24 12:10:07 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 D46F31296EC; Tue, 24 Jan 2017 12:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 rwTyhMIfJSnX; Tue, 24 Jan 2017 12:10:04 -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 BEDFC1296EA; Tue, 24 Jan 2017 12:10:04 -0800 (PST) Received: from [10.0.1.39] (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 v0OKA0HK004361 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 14:10:01 -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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 24 Jan 2017 14:10:00 -0600 Message-ID: <7CD09AC0-6746-4C55-BB29-314393CA6BFE@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFB5800@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> <4D41BE8E-73C7-4976-AEB2-1A2EA0F60B53@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB5800@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 20:10:06 -0000 All looks good to me. Please submit a revision when you are ready, and I will request the IETF Last call. Thanks! Ben. On 24 Jan 2017, at 14:04, Christer Holmberg wrote: > Hi, > >>>>>>>> -4.1, last paragraph: >>>>>>>> I assume this paragraph refers to fmt values used with >>>>>>>> UDP/DTLS/SCTP or TCP/DTLS/SCTP, not fmt values in general. >>>>>>> >>>>>>> Correct. >>>>>>> >>>>>>>> It would help to be explicit about that. >>>>>>> >>>>>>> The first sentence in section 4.1 does say: >>>>>>> >>>>>>> "This section defines the following new SDP Media Description >>>>>>> (m- line) protocol identifiers (proto values) for >>>>>>> describing an >>>>>>> SCTP association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'." >>>>>> >>>>>> I'm not sure all readers will see the connection between the >>>>>> first >>>>>> and last paragraph. I still think it would help to explicitly >>>>>> mention it. >>>>>> (Especially if it moves to 4.3) >>>>>> >>>>>> An alternative, if it were to stay in 4.1 would be to have the >>>>>> opening paragraph in 4.1 explicitly mention that it includes the >>>>>> fmt values to be used in the context of these new proto values. >>>>>>> >>>>>>> >>>>>>>> (Also, it seem like this paragraph belongs in section 4.3). >>>>>>> >>>>>>> I could move and combine it with the 4th paragraph of section >>>>>>> 4.3: >>>>>>> >>>>>>> "The m- line fmt value, identifying the application-layer >>>>>>> protocol, MUST be registered by IANA. Section 15.3 defines >>>>>>> the >>>>>>> IANA registry for the media format namespace." >>>>>>> >>>>>>> >>>>> Ok, so my suggestion is to: >>>>> >>>>> 1) Move the paragraph to section 4.3, as described above >>>>> 2) Modify the first paragraph in section 4.1: >>>>> >>>>> "This section defines the following new SDP Media Description (m- >>>>> line) protocol identifiers (proto values) for describing an >>>>> SCTP >>>>> association: 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. The section >>>>> also describes how an m- line, associated with the proto >>>>> values, is >>>>> created, and how the the media format (Œfmt¹) values are >>>>> used." >>>> >>>> The change helps, but does it still make sense if the last >>>> paragraph >>>> of 4.1 moves to 4.3? >>> >>> So, you suggest to not move the last paragraph to 4.3? >> >> No, my suggestion is to either (put the additional sentence in the >> first paragraph of 4.1 and keep last >> paragraph in 4.1) _OR_ (move the paragraph to 4.3 and put the >> clarification in _that_ paragraph.) > > Ok, so: > > 1) Don't modify the 1st paragraph in 4.1 > 2) Move the last paragraph to 4.3 > 3) Modify the paragraph in 4.3: > > "When the 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP' proto values, > the m- line fmt value, identifying the application-layer > rotocol, MUST be registered by IANA. Section 15.3 defines the > IANA registry for the media format namespace." > > ---- > >>>>>>>> -6.1: What is meant by saying an "endpoint MUST assume that >>>>>>>> larger ... >>>>>>>> will be rejected"? Can that be stated in terms of actual >>>>>>>> procedure (e.g. >>>>>>>> "endpoint MUST NOT send...larger"? >>>>>>> >>>>>>> I'd like Roman's input on this, in case he had some cases in >>>>>>> mind >>>>>>> where endpoint will have to send larger messages. >>>>>>> >>>>>>> I guess we could say SHOULD NO send larger message, and explain >>>>>>> that one cannot assume that larger message (if sent for whatever >>>>>>> reason) >>>>>>> will be accepted by the peer. >>>>>> >>>>>> That would be reasonable if it is the right answer. I just want >>>>>> to >>>>>> avoid the vagueness of "MUST assume". >>>>> >>>>> I suggest the following modified text: >>>>> >>>>> "An SCTP endpoint SHOULD NOT send a SCTP user message with a >>>>> message >>>>> size that is larger than the maximum size indicated by the peer. >>>>> If >>>>> the SCTP endpoint needs (for whatever reason) to send a larger >>>>> message, it cannot be assumed that the message will be accepted by >>>>> the peer." >>>> >>>> I'm okay with that, but don't be surprised if we get questions >>>> about >>>> whether it ever would ever make sense to send a message that you >>>> can't assume the peer will accept. >>>> (I wonder if it's more a matter >>>> of "probably not accept", given the peer has already stated its >>>> preference. >>> >>> If nobody objects, I am ok saying "MUST NOT send". >>> >>> Because, if there is a case where it would be needed, the peers >>> simply >>> need to support and negotiate a larger value. >> >> Okay with me. If someone comes up with a plausible reason one might >> need to send larger messages, please speak up before the IETF LC >> completes. :-) > > Suggested modified paragraph: > > "An SCTP endpoint MUST NOT send a SCTP user message with a > message > size that is larger than the maximum size indicated by the > peer, as it > cannot be assumed that the peer would accept such message." > > Regards, > > Christer From nobody Tue Jan 24 12:17: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 96B601296F5; Tue, 24 Jan 2017 12:17: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_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 EU2VtuOmC_X9; Tue, 24 Jan 2017 12:17:54 -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 903C41296F9; Tue, 24 Jan 2017 12:17:53 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-04-5887b66ec60c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 05.4A.16488.E66B7885; Tue, 24 Jan 2017 21:17:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 21:16:57 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAB+8QwAAAP0rgAAJB1jQ///y5oD//+Z8QIAAJuAA///tveA= Date: Tue, 24 Jan 2017 20:16:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFB585B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <3E90B140-FFB0-4437-B8A3-ADFF3AA32DD1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB575B@ESESSMB209.ericsson.se> <4D41BE8E-73C7-4976-AEB2-1A2EA0F60B53@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4BFB5800@ESESSMB209.ericsson.se> <7CD09AC0-6746-4C55-BB29-314393CA6BFE@nostrum.com> In-Reply-To: <7CD09AC0-6746-4C55-BB29-314393CA6BFE@nostrum.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbHdVTd/W3uEwftT2hbzO0+zW2zq38Ri MXX5YxaLGRemMjuweCxZ8pPJY9bOJywet6YUBDBHcdmkpOZklqUW6dslcGV8b64oOGNesfv/ UrYGxilmXYycHBICJhJdHW9Zuhi5OIQE1jFK3Po9jwnCWcwo8aXjIZDDwcEmYCHR/U8bpEFE QEniefNWFhCbWWAWo8Tz79IgtrBAtMSht5cZIWpiJM7uWcwEYSdJ/HrVxQZiswioSpx8O50V xOYV8JX423IOrEZI4DazxIeJfCCrOAXsJbY9EgYJMwqISXw/tYYJYpW4xK0n85kgbhaQWLLn PDOELSrx8vE/VghbSWLR7c9gFzMLaEqs36UP0aooMaX7ITvEVkGJkzOfsExgFJ2FZOoshI5Z SDpmIelYwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwdg5u+W21g/Hgc8dDjAIcjEo8 vB+y2yOEWBPLiitzDzFKcDArifB2zQIK8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9 sSQ1OzW1ILUIJsvEwSnVwOjvr5Akvuvehwcl2k/vtyR9i2CeUZAixTgnbekHrXX6NdeNNx+Y 1GrZ5Kjatsq2VYh/knaMe/g7ER1mG6kMjgfnr3kaFzjHbjZnmBm3yGOB+maDj0k61SozjZg4 7Gwqzh2WeJfstUXKQppp+YoDW45uqfnhtDawbn/F3v4dM9oZ5mvdkPrdosRSnJFoqMVcVJwI AHGpuG+ZAgAA Archived-At: Cc: "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 20:17:55 -0000 DQo+QWxsIGxvb2tzIGdvb2QgdG8gbWUuIFBsZWFzZSBzdWJtaXQgYSByZXZpc2lvbiB3aGVuIHlv dSBhcmUgcmVhZHksIGFuZCBJIHdpbGwgcmVxdWVzdCA+dGhlIElFVEYgTGFzdCBjYWxsLg0KDQpJ J2xsIGRvIGl0IHRvbW9ycm93LiBUaGUgb3RoZXIgY2hhbmdlcyBhcmUgb24gYSBsb2NhbCBicmFu Y2ggb24gbXkgb2ZmaWNlIGNvbXB1dGVyLg0KDQpUaGFua3MhDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQoNCk9uIDI0IEphbiAyMDE3LCBhdCAxNDowNCwgQ2hyaXN0ZXIgSG9sbWJlcmcg d3JvdGU6DQoNCj4gSGksDQo+DQo+Pj4+Pj4+PiAtNC4xLCBsYXN0IHBhcmFncmFwaDoNCj4+Pj4+ Pj4+IEkgYXNzdW1lIHRoaXMgcGFyYWdyYXBoIHJlZmVycyB0byBmbXQgdmFsdWVzIHVzZWQgd2l0 aCANCj4+Pj4+Pj4+IFVEUC9EVExTL1NDVFAgb3IgVENQL0RUTFMvU0NUUCwgbm90IGZtdCB2YWx1 ZXMgaW4gZ2VuZXJhbC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4+IEl0IHdvdWxkIGhlbHAgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhhdC4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gVGhlIGZpcnN0IHNlbnRlbmNlIGluIHNlY3Rpb24gNC4xIGRvZXMgc2F5Og0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICAiVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIGZvbGxvd2luZyBuZXcgU0RQ IE1lZGlhIERlc2NyaXB0aW9uDQo+Pj4+Pj4+ICAgICAgKG0tIGxpbmUpIHByb3RvY29sIGlkZW50 aWZpZXJzIChwcm90byB2YWx1ZXMpIGZvciANCj4+Pj4+Pj4gZGVzY3JpYmluZyBhbg0KPj4+Pj4+ PiAgICAgIFNDVFAgYXNzb2NpYXRpb246ICdVRFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1ND VFAnLiINCj4+Pj4+Pg0KPj4+Pj4+IEknbSBub3Qgc3VyZSBhbGwgcmVhZGVycyB3aWxsIHNlZSB0 aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSANCj4+Pj4+PiBmaXJzdCBhbmQgbGFzdCBwYXJhZ3Jh cGguIEkgc3RpbGwgdGhpbmsgaXQgd291bGQgaGVscCB0byANCj4+Pj4+PiBleHBsaWNpdGx5IG1l bnRpb24gaXQuDQo+Pj4+Pj4gKEVzcGVjaWFsbHkgaWYgaXQgbW92ZXMgdG8gNC4zKQ0KPj4+Pj4+ DQo+Pj4+Pj4gQW4gYWx0ZXJuYXRpdmUsIGlmIGl0IHdlcmUgdG8gc3RheSBpbiA0LjEgd291bGQg YmUgdG8gaGF2ZSB0aGUgDQo+Pj4+Pj4gb3BlbmluZyBwYXJhZ3JhcGggaW4gNC4xIGV4cGxpY2l0 bHkgbWVudGlvbiB0aGF0IGl0IGluY2x1ZGVzIHRoZSANCj4+Pj4+PiBmbXQgdmFsdWVzIHRvIGJl IHVzZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhlc2UgbmV3IHByb3RvIHZhbHVlcy4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4+IChBbHNvLCBpdCBzZWVtIGxpa2UgdGhpcyBwYXJhZ3JhcGggYmVs b25ncyBpbiBzZWN0aW9uIDQuMykuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgY291bGQgbW92ZSBhbmQg Y29tYmluZSBpdCB3aXRoIHRoZSA0dGggcGFyYWdyYXBoIG9mIHNlY3Rpb24NCj4+Pj4+Pj4gNC4z Og0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAiVGhlIG0tIGxpbmUgZm10IHZhbHVlLCBpZGVudGlmeWlu ZyB0aGUgYXBwbGljYXRpb24tbGF5ZXINCj4+Pj4+Pj4gICAgcHJvdG9jb2wsIE1VU1QgYmUgcmVn aXN0ZXJlZCBieSBJQU5BLiBTZWN0aW9uIDE1LjMgZGVmaW5lcyANCj4+Pj4+Pj4gdGhlDQo+Pj4+ Pj4+ICAgIElBTkEgcmVnaXN0cnkgZm9yIHRoZSBtZWRpYSBmb3JtYXQgbmFtZXNwYWNlLiINCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+IE9rLCBzbyBteSBzdWdnZXN0aW9uIGlzIHRvOg0KPj4+Pj4N Cj4+Pj4+IDEpIE1vdmUgdGhlIHBhcmFncmFwaCB0byBzZWN0aW9uIDQuMywgYXMgZGVzY3JpYmVk IGFib3ZlDQo+Pj4+PiAyKSBNb2RpZnkgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDQu MToNCj4+Pj4+DQo+Pj4+PiAiVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIGZvbGxvd2luZyBuZXcg U0RQIE1lZGlhIERlc2NyaXB0aW9uIChtLQ0KPj4+Pj4gICAgbGluZSkgcHJvdG9jb2wgaWRlbnRp ZmllcnMgKHByb3RvIHZhbHVlcykgZm9yIGRlc2NyaWJpbmcgYW4gDQo+Pj4+PiBTQ1RQDQo+Pj4+ PiAgICBhc3NvY2lhdGlvbjogJ1VEUC9EVExTL1NDVFAnIGFuZCAnVENQL0RUTFMvU0NUUCcuICBU aGUgc2VjdGlvbg0KPj4+Pj4gICAgYWxzbyBkZXNjcmliZXMgaG93IGFuIG0tIGxpbmUsIGFzc29j aWF0ZWQgd2l0aCB0aGUgcHJvdG8gDQo+Pj4+PiB2YWx1ZXMsIGlzDQo+Pj4+PiAgICBjcmVhdGVk LCBhbmQgaG93IHRoZSB0aGUgbWVkaWEgZm9ybWF0ICjFkmZtdMK5KSB2YWx1ZXMgYXJlIHVzZWQu Ig0KPj4+Pg0KPj4+PiBUaGUgY2hhbmdlIGhlbHBzLCBidXQgZG9lcyBpdCBzdGlsbCBtYWtlIHNl bnNlIGlmIHRoZSBsYXN0IA0KPj4+PiBwYXJhZ3JhcGggb2YgNC4xIG1vdmVzIHRvIDQuMz8NCj4+ Pg0KPj4+IFNvLCB5b3Ugc3VnZ2VzdCB0byBub3QgbW92ZSB0aGUgbGFzdCBwYXJhZ3JhcGggdG8g NC4zPw0KPj4NCj4+IE5vLCBteSBzdWdnZXN0aW9uIGlzIHRvIGVpdGhlciAocHV0IHRoZSBhZGRp dGlvbmFsIHNlbnRlbmNlIGluIHRoZSANCj4+IGZpcnN0IHBhcmFncmFwaCBvZiA0LjEgYW5kIGtl ZXAgbGFzdCBwYXJhZ3JhcGggaW4gNC4xKSBfT1JfIChtb3ZlIHRoZSANCj4+IHBhcmFncmFwaCB0 byA0LjMgYW5kIHB1dCB0aGUgY2xhcmlmaWNhdGlvbiBpbiBfdGhhdF8gcGFyYWdyYXBoLikNCj4N Cj4gT2ssIHNvOg0KPg0KPiAxKSBEb24ndCBtb2RpZnkgdGhlIDFzdCBwYXJhZ3JhcGggaW4gNC4x DQo+IDIpIE1vdmUgdGhlIGxhc3QgcGFyYWdyYXBoIHRvIDQuMw0KPiAzKSBNb2RpZnkgdGhlIHBh cmFncmFwaCBpbiA0LjM6DQo+DQo+ICAgICAgICJXaGVuIHRoZSAnVURQL0RUTFMvU0NUUCcgYW5k ICdUQ1AvRFRMUy9TQ1RQJyBwcm90byB2YWx1ZXMsDQo+ICAgICAgICAgdGhlIG0tIGxpbmUgZm10 IHZhbHVlLCBpZGVudGlmeWluZyB0aGUgYXBwbGljYXRpb24tbGF5ZXINCj4gICAgICAgICByb3Rv Y29sLCBNVVNUIGJlIHJlZ2lzdGVyZWQgYnkgSUFOQS4gU2VjdGlvbiAxNS4zIGRlZmluZXMgdGhl DQo+ICAgICAgICAgSUFOQSByZWdpc3RyeSBmb3IgdGhlIG1lZGlhIGZvcm1hdCBuYW1lc3BhY2Uu Ig0KPg0KPiAtLS0tDQo+DQo+Pj4+Pj4+PiAtNi4xOiBXaGF0IGlzIG1lYW50IGJ5IHNheWluZyBh biAiZW5kcG9pbnQgTVVTVCBhc3N1bWUgdGhhdCANCj4+Pj4+Pj4+IGxhcmdlciAuLi4NCj4+Pj4+ Pj4+IHdpbGwgYmUgcmVqZWN0ZWQiPyBDYW4gdGhhdCBiZSBzdGF0ZWQgaW4gdGVybXMgb2YgYWN0 dWFsIA0KPj4+Pj4+Pj4gcHJvY2VkdXJlIChlLmcuDQo+Pj4+Pj4+PiAiZW5kcG9pbnQgTVVTVCBO T1Qgc2VuZC4uLmxhcmdlciI/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEknZCBsaWtlIFJvbWFuJ3MgaW5w dXQgb24gdGhpcywgaW4gY2FzZSBoZSBoYWQgc29tZSBjYXNlcyBpbiANCj4+Pj4+Pj4gbWluZCB3 aGVyZSBlbmRwb2ludCB3aWxsIGhhdmUgdG8gc2VuZCBsYXJnZXIgbWVzc2FnZXMuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IEkgZ3Vlc3Mgd2UgY291bGQgc2F5IFNIT1VMRCBOTyBzZW5kIGxhcmdlciBtZXNz YWdlLCBhbmQgZXhwbGFpbiANCj4+Pj4+Pj4gdGhhdCBvbmUgY2Fubm90IGFzc3VtZSB0aGF0IGxh cmdlciBtZXNzYWdlIChpZiBzZW50IGZvciB3aGF0ZXZlcg0KPj4+Pj4+PiByZWFzb24pDQo+Pj4+ Pj4+IHdpbGwgYmUgYWNjZXB0ZWQgYnkgdGhlIHBlZXIuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGF0IHdv dWxkIGJlIHJlYXNvbmFibGUgaWYgaXQgaXMgdGhlIHJpZ2h0IGFuc3dlci4gSSBqdXN0IHdhbnQg DQo+Pj4+Pj4gdG8gYXZvaWQgdGhlIHZhZ3VlbmVzcyBvZiAiTVVTVCBhc3N1bWUiLg0KPj4+Pj4N Cj4+Pj4+IEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIG1vZGlmaWVkIHRleHQ6DQo+Pj4+Pg0KPj4+ Pj4gIkFuIFNDVFAgZW5kcG9pbnQgU0hPVUxEIE5PVCBzZW5kIGEgU0NUUCB1c2VyIG1lc3NhZ2Ug d2l0aCBhIA0KPj4+Pj4gbWVzc2FnZSBzaXplIHRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIG1heGlt dW0gc2l6ZSBpbmRpY2F0ZWQgYnkgdGhlIA0KPj4+Pj4gcGVlci4NCj4+Pj4+IElmDQo+Pj4+PiB0 aGUgU0NUUCBlbmRwb2ludCBuZWVkcyAoZm9yIHdoYXRldmVyIHJlYXNvbikgdG8gc2VuZCBhIGxh cmdlciANCj4+Pj4+IG1lc3NhZ2UsIGl0IGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQgdGhlIG1lc3Nh Z2Ugd2lsbCBiZSBhY2NlcHRlZCBieSANCj4+Pj4+IHRoZSBwZWVyLiINCj4+Pj4NCj4+Pj4gSSdt IG9rYXkgd2l0aCB0aGF0LCBidXQgZG9uJ3QgYmUgc3VycHJpc2VkIGlmIHdlIGdldCBxdWVzdGlv bnMgDQo+Pj4+IGFib3V0IHdoZXRoZXIgaXQgZXZlciB3b3VsZCBldmVyIG1ha2Ugc2Vuc2UgdG8g c2VuZCBhIG1lc3NhZ2UgdGhhdCANCj4+Pj4geW91IGNhbid0IGFzc3VtZSB0aGUgcGVlciB3aWxs IGFjY2VwdC4NCj4+Pj4gKEkgd29uZGVyIGlmIGl0J3MgbW9yZSBhIG1hdHRlcg0KPj4+PiBvZiAi cHJvYmFibHkgbm90IGFjY2VwdCIsIGdpdmVuIHRoZSBwZWVyIGhhcyBhbHJlYWR5IHN0YXRlZCBp dHMgDQo+Pj4+IHByZWZlcmVuY2UuDQo+Pj4NCj4+PiBJZiBub2JvZHkgb2JqZWN0cywgSSBhbSBv ayBzYXlpbmcgIk1VU1QgTk9UIHNlbmQiLg0KPj4+DQo+Pj4gQmVjYXVzZSwgaWYgdGhlcmUgaXMg YSBjYXNlIHdoZXJlIGl0IHdvdWxkIGJlIG5lZWRlZCwgdGhlIHBlZXJzIA0KPj4+IHNpbXBseSBu ZWVkIHRvIHN1cHBvcnQgYW5kIG5lZ290aWF0ZSBhIGxhcmdlciB2YWx1ZS4NCj4+DQo+PiBPa2F5 IHdpdGggbWUuIElmIHNvbWVvbmUgY29tZXMgdXAgd2l0aCBhIHBsYXVzaWJsZSByZWFzb24gb25l IG1pZ2h0IA0KPj4gbmVlZCB0byBzZW5kIGxhcmdlciBtZXNzYWdlcywgcGxlYXNlIHNwZWFrIHVw IGJlZm9yZSB0aGUgSUVURiBMQyANCj4+IGNvbXBsZXRlcy4gOi0pDQo+DQo+IFN1Z2dlc3RlZCBt b2RpZmllZCBwYXJhZ3JhcGg6DQo+DQo+ICAgICAgICAgICJBbiBTQ1RQIGVuZHBvaW50IE1VU1Qg Tk9UIHNlbmQgYSBTQ1RQIHVzZXIgbWVzc2FnZSB3aXRoIGEgDQo+IG1lc3NhZ2UNCj4gICAgICAg ICAgIHNpemUgdGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgbWF4aW11bSBzaXplIGluZGljYXRlZCBi eSB0aGUgDQo+IHBlZXIsIGFzIGl0DQo+ICAgICAgICAgICBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0 IHRoZSBwZWVyIHdvdWxkIGFjY2VwdCBzdWNoIG1lc3NhZ2UuIg0KPg0KPiBSZWdhcmRzLA0KPg0K PiBDaHJpc3Rlcg0K From nobody Tue Jan 24 12:40: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 272E2129722; Tue, 24 Jan 2017 12:40:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Elwyn Davies To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148529043511.12735.9313753556504417778.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 12:40:35 -0800 Archived-At: Cc: draft-ietf-mmusic-4572-update.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Review of draft-ietf-mmusic-4572-update-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:40:35 -0000 Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-mmusic-4572-update-11 Reviewer: Elwyn Davies Review Date: 2017-01-24 IETF LC End Date: 2017-01-26 IESG Telechat date: Not scheduled for a telechat Summary: Ready. There are a couple of trivial nits mentioned below. Given that the draft has a minimal set of changes apart from the addition of two sections, I have not read the unchanged pieces in detail Major issues: None Minor issues: None Nits/editorial comments: s1, para 2: s/TLS protocol/The TLS protocol/ (as per RFC 4572) s4, para 2: s/a new protocol identifier/the protocol identifier/ (it isn't new any more) s5.1: Suggest s/m- line/"m" line/ for consistency with s3.4 s5.1, para 1: s/e.g./e.g.,/ s5.1, para 4: s/that each used certificate matches/that each certificate used matches/ s5.1, para 5: s/each used certificate matches/each certificate used matches/ s8, para 5: ' This specification creates a new IANA registry named "Hash Function Textual Names".' The registry is no longer new. Perhaps s/creates a new IANA registry/takes over the IANA registry from RFC 4572/ From nobody Tue Jan 24 13:10: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 0C0D71297CE for ; Tue, 24 Jan 2017 13:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 gtEYkuKvozdF for ; Tue, 24 Jan 2017 13:10:02 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 CBC551297CB for ; Tue, 24 Jan 2017 13:10:02 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-05v.sys.comcast.net with SMTP id W8KZcIw6lMqbUW8LqcJmJI; Tue, 24 Jan 2017 21:10:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485292202; bh=ie9UBeBgLbkN1JGt1+PrqLOGnoSw0gyTeu0FvxDK9B4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=EvRx8WIN5hdFIdQtOVcH4JQJ1fB2MzrD/6D+2kD4xgZvZsZej3mM8uMtgKQLnFKO4 vETIx1eVtk4IYIx4tYO8oxbnGOPeGwh+bTAaQqL2SuxL1SgBSyZzFPOSzFwXfl5dOk PVhmdiqtkBwpGSvDP5VZggE18wcsr0emo9BRib0pnJ/k9PuJmZ3jyIKvytSOziVnSL 29xrqbKpUhFn6yhDSis2nPcTwUTUv6qr2ihnMTxaE+55ljxTm5n8RTLydbsXIIcs8X SxC8u4kukgo9DCbTApbQCYBOrz19foMFTd++oC0CQUgH1vwQFntnXpf6u3iqVVit9f Zd3KXCJF6n5gA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-13v.sys.comcast.net with SMTP id W8Lpcu5AMxumkW8LpcV8A8; Tue, 24 Jan 2017 21:10:02 +0000 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> From: Paul Kyzivat Message-ID: <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> Date: Tue, 24 Jan 2017 16:10:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfE2/Nc+diHpgNzrUrv/qtFPrNzBbc3a5bsnZQ1qCDzwafnUWPcOLoPrKJ+jKkpqJQRB7Mt0W1nmHdPnEemcnBJUXUiMXbgI401aVAxBKlZrWdLTJwssK +8vWpdwTtVWjon1rxggzG0ZIpDT8sjBMt0YpLGqeNHCJKKG0ivyfWIp6Ii1+gfu3vAvvEHv0S+rAhxNtJEPoorCOO1/XUJ6zxLY= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 21:10:04 -0000 Roman, On 1/24/17 2:18 PM, Roman Shpount wrote: > Replacing of TCP connection or DTLS association does not break > the SCTP > association. SCTP is designed to run over unreliable transports, so > short term loss of connectivity when one TCP connection or one DTLS > association is being replaced by the other would be handled by > the SCTP > re-transmit timers. Also, when ICE is used, switching from one ICE > candidate to another, including switching between two ICE tcp > candidates > or switching from udp to tcp candidate, does not affect existing > SCTP > association. Existing SCTP association continues to run despite the > underlying candidate switch and as far as SCTP association is > concerned > it is running over the same unreliable transport. Finally, DTLS > association can be re-established to force re-keying the long > running > connection. This can be done without affecting SCTP association > running > on top of these DTLS associations. > > This is why we are saying that the SCTP association, the DTLS > association and the TCP connection are managed independently > from each > other. Each can be established and closed without impacting > others. > Each protocol uses its own means to detect connection closure, > failure > or timeout. > > > I can see that this can be a good thing when it is what you want/need. > > OTOH, if one of the two parties involved changes, and there is no > state sharing, you need to establish a new SCTP association. This > may turn out to be the case even when the offerer doesn't know that > the other party has changed. > > So how are these two cases distinguished in the signaling? AFAICT > the only thing available is sctp-port. If the offerer doesn't > realize a change is coming, then it won't change its port. And in > that case the answerer won't know what port its predecessor used, so > it might choose the same value. > > Of course, this is largely a 3pcc scenario, and if it is initiated > in the middle then the middle can probably know to change the port > somewhere. > > But I'm not sure if that is the only case. > > > We have considered that issue and assumed that selecting a random > sctp-port is sufficient to determine if this is the same vs new > connection. I see *no* mention that the sctp-port value should be chosen randomly. And IMO it is unnatural to suggest port values be random. There could be reasons for them not being random - for instance interop with SCTP over IP with well known ports. Also, while there is currently no spec for multiple SCTP associations in the same bundle, it is not hard to imagine that that might be a useful thing to do in the future. In that case random port numbers could be more troublesome. > There is some possibility of collisions when answering party > accidentally picks the same port as the one which was previously used > for SCTP communications, but this is similar to ICE ufrag > collisions, dtls-id collisions or to-tag collisions. But those all use values that are specified to be random. > I do agree that > sctp-port has less random bits then ufrag, dtls-id, or to-tag, so it is > more likely to collide. Please let us know if this is a sufficient point > of concern to warrant adding more randomness by changing sctp-port > definition (making it longer) That isn't possible, because the port number and its format are specified in the SCTP spec. > or adding another attribute. Another > solution would be to require SCTP association restart on DTLS > association restart and use random bits in dtls-id minimize the chance > of collision. The most straightforward way would be to follow the pattern used with comedia (rfv4145), with a=coonnection=new/existing. But that attribute couldn't be used, because it can already be in use for a TCP connection below it. Also, we have already abandoned using something akin to a=setup. Unfortunately the end result we have arrived add is, IMO, a one-off hack that doesn't follow established approaches. This has arisen because we are negotiated layered protocols and the established SDP mechanisms don't have provision for that. But I don't think there is the will to clean this up. > In general, I am not strongly attached to not restarting SCTP > association on underlying transport change. I am even less attached to > restarting SCTP on DTLS restart. Coupling SCTP restart with one of those is a simple answer. > What I do feel strongly about is: > > 1. Keeping SCTP association when ICE candidates change > 2. Keeping SCTP association on ICE restart > > Keeping SCTP association on ICE restart has exactly the same properties > as keeping SCTP association on transport change (it is unclear if ICE > restart was caused by the same endpoint or by endpoint change due to > 3pcc). Since ICE restart and transport change are essentially the same > thing, I proposed that SCTP association is preserved in both cases. If > we tie SCTP association restart to DTLS association restart we will get > the desired result for ICE only at the cost of loosing re-key ability > for the existing SCTP association. > > So, my questions are: > 1. Is possibility of sctp-port collision large enough concern to change > when SCTP association is restarted? > 2. Would it be acceptable to lose ability to re-key DTLS association > while running the same SCTP assignations and force SCTP association > restart on DTLS association restart? I'd like to hear what others have to say. Thanks, Paul From nobody Tue Jan 24 14:03:39 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 EE869129406 for ; Tue, 24 Jan 2017 14:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 b_3lV4fDd1w4 for ; Tue, 24 Jan 2017 14:03:35 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 1D6901293FE for ; Tue, 24 Jan 2017 14:03:35 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v200so346373ywc.3 for ; Tue, 24 Jan 2017 14:03:35 -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=z8xEDNVhmeEkv+lG1ynq4fyz/xwGfhBDfpr1vwzDSG4=; b=OTWA4XkhuHMsqy7Fqf7czs5pUHGrTAsaF+LAhJIjtYiP2NnF1r7V3Stp64tGTGLeJ9 zcwLS3MF9HdqseUgGEPwS67SXUILMAv5OrXEtAbkqMZgXCmpoUotJ4LAfI/2QyhhJC5z YkubGXKbXgNNGuWYuH1FFO0iPcpTtJwmzkWq1FEPeWetebILhjo35FjfG7r6NapU1qHS IMGQKcd9HH5QYsLeeu4euXNf4YAb/t/e+KmM9vnufU9XVRe8W4aW1mUZKl+g8s1iAh58 Z983rGKv7bpEm4NWPMq3Mc+T+MFI+USKxIEy4sSocHdwC2DPq8ZrsvBtaxK6X5i1AA6C j5Ww== 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=z8xEDNVhmeEkv+lG1ynq4fyz/xwGfhBDfpr1vwzDSG4=; b=ZVwbdvs8kGcczkTnQMo0SByvY8P3S47CFxAsZYD0yumTja93mGkacqz2eXPDIoTehs 3VFg7oPujBGHzh2670jAlhZZGBALU/ZOtBBaLiMwMCylUe8uv7KGENhBPtSB8PjdfUXq wsKx6ELkrPfVf+asBgJ6blHT0uFhgoXsOjyiN1FHkmNeNeq/rGefUj7paiG57rJPGkrb rf5lgt4GWtphkT95jMP4ljNoRiOIuUW3694cxAhN3hYm13K7GcrjUXiMbbqe6mswyAul +2GI4iBnTgqDI4da0SNGddMzpJaAkzmSFbSUe2oXxmgnevtF9NhT+n8EuiL/ebUwFD46 mmfw== X-Gm-Message-State: AIkVDXJOZ6l8oenNMFW4ZGw+z9rUhZNnRSRGDtv3iK/5IO0eXlIp+p0ujdHSAmuQ4ALwig== X-Received: by 10.129.89.70 with SMTP id n67mr27949952ywb.296.1485295374826; Tue, 24 Jan 2017 14:02:54 -0800 (PST) Received: from mail-yb0-f178.google.com (mail-yb0-f178.google.com. [209.85.213.178]) by smtp.gmail.com with ESMTPSA id 139sm10491081ywe.36.2017.01.24.14.02.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 14:02:54 -0800 (PST) Received: by mail-yb0-f178.google.com with SMTP id l23so487308ybj.2 for ; Tue, 24 Jan 2017 14:02:54 -0800 (PST) X-Received: by 10.55.47.69 with SMTP id v66mr31339793qkh.222.1485295359947; Tue, 24 Jan 2017 14:02:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Tue, 24 Jan 2017 14:02:39 -0800 (PST) In-Reply-To: <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> From: Roman Shpount Date: Tue, 24 Jan 2017 17:02:39 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114f4ec450fe690546de469b Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 24 Jan 2017 22:03:38 -0000 --001a114f4ec450fe690546de469b Content-Type: text/plain; charset=UTF-8 On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat wrote: > The most straightforward way would be to follow the pattern used with > comedia (rfv4145), with a=coonnection=new/existing. But that attribute > couldn't be used, because it can already be in use for a TCP connection > below it. Also, we have already abandoned using something akin to a=setup. > We have tried this approach with DTLS and we came to the conclusion that a=connection:new/existing does not work in combination with 3pcc. This is why we switched to dtls-id. So, two options that we have are to define sctp-id or restart based on dtls-id. Regards, _____________ Roman Shpount --001a114f4ec450fe690546de469b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <paul.kyzivat@co= mcast.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">The most straightforward w= ay would be to follow the pattern used with comedia (rfv4145), with a=3Dcoo= nnection=3Dnew/existing. But that attribute couldn't be used, because i= t can already be in use for a TCP connection below it. Also, we have alread= y abandoned using something akin to a=3Dsetup.

We have tried this approach with DTLS and we came to the conclusion= that a=3Dconnection:new/existing does not work in combination with 3pcc. T= his is why we switched to dtls-id. So, two options that we have are to defi= ne sctp-id or restart based on dtls-id.

Regards,
_____________
Roman Shpount
=C2=A0
--001a114f4ec450fe690546de469b-- From nobody Tue Jan 24 23:53: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 A78E3129875; Tue, 24 Jan 2017 23:53:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148533078767.12747.4338530120098082303.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 23:53:07 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-22.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 07:53:08 -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 of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-22.txt Pages : 25 Date : 2017-01-24 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-22 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 Tue Jan 24 23:55: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 16E9712987A; Tue, 24 Jan 2017 23:55:12 -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 bBoU8ugtgK92; Tue, 24 Jan 2017 23:55:10 -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 16D2E129878; Tue, 24 Jan 2017 23:55:09 -0800 (PST) X-AuditID: c1b4fb30-d53ff70000007085-80-588859db6d28 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id B7.1B.28805.BD958885; Wed, 25 Jan 2017 08:55:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 08:55:06 +0100 From: Christer Holmberg To: Ben Campbell , "draft-ietf-mmusic-sctp-sdp.all@ietf.org" , mmusic Thread-Topic: Draft new version: draft-sctp-sdp-22 [was: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments] Thread-Index: AQHSduBX+cJJ9cJKrEWVSJKgNkjY4g== Date: Wed, 25 Jan 2017 07:55:06 +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.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7ve6dyI4IgzcLhS3md55mt9jUv4nF YuryxywOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8bhHYYFt6wqdu9rYW1gnGHZxcjJ ISFgIrGyeT5zFyMXh5DAOkaJSx/3s0A4ixklVl/sZ+xi5OBgE7CQ6P6nDRIXEZjMKPG4p5EF pFtYoEriw7tFrCC2iEC9xLx/C8HqRQT0JBb9DAIJswioSrza+ZgJxOYVsJZ4efEQmM0oICbx /dQaMJtZQFzi1pP5TBAHCUgs2XOeGcIWlXj5+B/YeFGgkcufr4GKK0p8fLUPbBWzgKbE+l36 EGOsJT7unMAMYStKTOl+yA6xVlDi5MwnLBMYRWYh2TYLoXsWku5ZSLpnIelewMi6ilG0OLU4 KTfdyEgvtSgzubg4P08vL7VkEyMwVg5u+W2wg/Hlc8dDjAIcjEo8vB+y2yOEWBPLiitzDzFK cDArifDODemIEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyWiYNT qoExJpSjfd7pPr/kM0+kvONnOa9kijE5YzG5oYNlSc3C548s5q42PLL/Zk7+/2zD1ybnbX93 LGQ6X+D56eSXJqEv+ht2PTu972SqyrNjG7/dTHVbtC0hjm3WPCP1EyvnRfDMusqWXvnO8n6e WM+FDzafHk/f8PvE8X6hgjfZV1zsGw+v2id0Ne/VQSWW4oxEQy3mouJEAOHqsHKRAgAA Archived-At: Subject: [MMUSIC] Draft new version: draft-sctp-sdp-22 [was: AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 07:55:12 -0000 SGksDQoNClZlcnNpb24gLTIyIGhhcyBub3cgYmVlbiBzdWJtaXR0ZWQuDQoNClRoYW5rcyEgOikN Cg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAyNC8wMS8xNyAyMjoxNiwgIkNocmlzdGVy IEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj4N Cj4+QWxsIGxvb2tzIGdvb2QgdG8gbWUuIFBsZWFzZSBzdWJtaXQgYSByZXZpc2lvbiB3aGVuIHlv dSBhcmUgcmVhZHksIGFuZCBJDQo+PndpbGwgcmVxdWVzdCA+dGhlIElFVEYgTGFzdCBjYWxsLg0K Pg0KPkknbGwgZG8gaXQgdG9tb3Jyb3cuIFRoZSBvdGhlciBjaGFuZ2VzIGFyZSBvbiBhIGxvY2Fs IGJyYW5jaCBvbiBteSBvZmZpY2UNCj5jb21wdXRlci4NCj4NCj5UaGFua3MhDQo+DQo+UmVnYXJk cywNCj4NCj5DaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPk9uIDI0IEphbiAyMDE3LCBhdCAxNDowNCwg Q2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+DQo+PiBIaSwNCj4+DQo+Pj4+Pj4+Pj4gLTQuMSwg bGFzdCBwYXJhZ3JhcGg6DQo+Pj4+Pj4+Pj4gSSBhc3N1bWUgdGhpcyBwYXJhZ3JhcGggcmVmZXJz IHRvIGZtdCB2YWx1ZXMgdXNlZCB3aXRoDQo+Pj4+Pj4+Pj4gVURQL0RUTFMvU0NUUCBvciBUQ1Av RFRMUy9TQ1RQLCBub3QgZm10IHZhbHVlcyBpbiBnZW5lcmFsLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IENvcnJlY3QuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEl0IHdvdWxkIGhlbHAgdG8gYmUgZXhwbGlj aXQgYWJvdXQgdGhhdC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGUgZmlyc3Qgc2VudGVuY2UgaW4g c2VjdGlvbiA0LjEgZG9lcyBzYXk6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgIlRoaXMgc2VjdGlv biBkZWZpbmVzIHRoZSBmb2xsb3dpbmcgbmV3IFNEUCBNZWRpYSBEZXNjcmlwdGlvbg0KPj4+Pj4+ Pj4gICAgICAobS0gbGluZSkgcHJvdG9jb2wgaWRlbnRpZmllcnMgKHByb3RvIHZhbHVlcykgZm9y DQo+Pj4+Pj4+PiBkZXNjcmliaW5nIGFuDQo+Pj4+Pj4+PiAgICAgIFNDVFAgYXNzb2NpYXRpb246 ICdVRFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1NDVFAnLiINCj4+Pj4+Pj4NCj4+Pj4+Pj4g SSdtIG5vdCBzdXJlIGFsbCByZWFkZXJzIHdpbGwgc2VlIHRoZSBjb25uZWN0aW9uIGJldHdlZW4g dGhlDQo+Pj4+Pj4+IGZpcnN0IGFuZCBsYXN0IHBhcmFncmFwaC4gSSBzdGlsbCB0aGluayBpdCB3 b3VsZCBoZWxwIHRvDQo+Pj4+Pj4+IGV4cGxpY2l0bHkgbWVudGlvbiBpdC4NCj4+Pj4+Pj4gKEVz cGVjaWFsbHkgaWYgaXQgbW92ZXMgdG8gNC4zKQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBBbiBhbHRlcm5h dGl2ZSwgaWYgaXQgd2VyZSB0byBzdGF5IGluIDQuMSB3b3VsZCBiZSB0byBoYXZlIHRoZQ0KPj4+ Pj4+PiBvcGVuaW5nIHBhcmFncmFwaCBpbiA0LjEgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgaXQg aW5jbHVkZXMgdGhlDQo+Pj4+Pj4+IGZtdCB2YWx1ZXMgdG8gYmUgdXNlZCBpbiB0aGUgY29udGV4 dCBvZiB0aGVzZSBuZXcgcHJvdG8gdmFsdWVzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gKEFsc28sIGl0IHNlZW0gbGlrZSB0aGlzIHBhcmFncmFwaCBiZWxvbmdzIGluIHNlY3Rpb24g NC4zKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJIGNvdWxkIG1vdmUgYW5kIGNvbWJpbmUgaXQgd2l0 aCB0aGUgNHRoIHBhcmFncmFwaCBvZiBzZWN0aW9uDQo+Pj4+Pj4+PiA0LjM6DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gICAgIlRoZSBtLSBsaW5lIGZtdCB2YWx1ZSwgaWRlbnRpZnlpbmcgdGhlIGFwcGxp Y2F0aW9uLWxheWVyDQo+Pj4+Pj4+PiAgICBwcm90b2NvbCwgTVVTVCBiZSByZWdpc3RlcmVkIGJ5 IElBTkEuIFNlY3Rpb24gMTUuMyBkZWZpbmVzDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+ICAgIElB TkEgcmVnaXN0cnkgZm9yIHRoZSBtZWRpYSBmb3JtYXQgbmFtZXNwYWNlLiINCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+IE9rLCBzbyBteSBzdWdnZXN0aW9uIGlzIHRvOg0KPj4+Pj4+DQo+Pj4+ Pj4gMSkgTW92ZSB0aGUgcGFyYWdyYXBoIHRvIHNlY3Rpb24gNC4zLCBhcyBkZXNjcmliZWQgYWJv dmUNCj4+Pj4+PiAyKSBNb2RpZnkgdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDQuMToN Cj4+Pj4+Pg0KPj4+Pj4+ICJUaGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgZm9sbG93aW5nIG5ldyBT RFAgTWVkaWEgRGVzY3JpcHRpb24gKG0tDQo+Pj4+Pj4gICAgbGluZSkgcHJvdG9jb2wgaWRlbnRp ZmllcnMgKHByb3RvIHZhbHVlcykgZm9yIGRlc2NyaWJpbmcgYW4NCj4+Pj4+PiBTQ1RQDQo+Pj4+ Pj4gICAgYXNzb2NpYXRpb246ICdVRFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1NDVFAnLiAg VGhlIHNlY3Rpb24NCj4+Pj4+PiAgICBhbHNvIGRlc2NyaWJlcyBob3cgYW4gbS0gbGluZSwgYXNz b2NpYXRlZCB3aXRoIHRoZSBwcm90bw0KPj4+Pj4+IHZhbHVlcywgaXMNCj4+Pj4+PiAgICBjcmVh dGVkLCBhbmQgaG93IHRoZSB0aGUgbWVkaWEgZm9ybWF0ICjFkmZtdMK5KSB2YWx1ZXMgYXJlIHVz ZWQuIg0KPj4+Pj4NCj4+Pj4+IFRoZSBjaGFuZ2UgaGVscHMsIGJ1dCBkb2VzIGl0IHN0aWxsIG1h a2Ugc2Vuc2UgaWYgdGhlIGxhc3QNCj4+Pj4+IHBhcmFncmFwaCBvZiA0LjEgbW92ZXMgdG8gNC4z Pw0KPj4+Pg0KPj4+PiBTbywgeW91IHN1Z2dlc3QgdG8gbm90IG1vdmUgdGhlIGxhc3QgcGFyYWdy YXBoIHRvIDQuMz8NCj4+Pg0KPj4+IE5vLCBteSBzdWdnZXN0aW9uIGlzIHRvIGVpdGhlciAocHV0 IHRoZSBhZGRpdGlvbmFsIHNlbnRlbmNlIGluIHRoZQ0KPj4+IGZpcnN0IHBhcmFncmFwaCBvZiA0 LjEgYW5kIGtlZXAgbGFzdCBwYXJhZ3JhcGggaW4gNC4xKSBfT1JfIChtb3ZlIHRoZQ0KPj4+IHBh cmFncmFwaCB0byA0LjMgYW5kIHB1dCB0aGUgY2xhcmlmaWNhdGlvbiBpbiBfdGhhdF8gcGFyYWdy YXBoLikNCj4+DQo+PiBPaywgc286DQo+Pg0KPj4gMSkgRG9uJ3QgbW9kaWZ5IHRoZSAxc3QgcGFy YWdyYXBoIGluIDQuMQ0KPj4gMikgTW92ZSB0aGUgbGFzdCBwYXJhZ3JhcGggdG8gNC4zDQo+PiAz KSBNb2RpZnkgdGhlIHBhcmFncmFwaCBpbiA0LjM6DQo+Pg0KPj4gICAgICAgIldoZW4gdGhlICdV RFAvRFRMUy9TQ1RQJyBhbmQgJ1RDUC9EVExTL1NDVFAnIHByb3RvIHZhbHVlcywNCj4+ICAgICAg ICAgdGhlIG0tIGxpbmUgZm10IHZhbHVlLCBpZGVudGlmeWluZyB0aGUgYXBwbGljYXRpb24tbGF5 ZXINCj4+ICAgICAgICAgcm90b2NvbCwgTVVTVCBiZSByZWdpc3RlcmVkIGJ5IElBTkEuIFNlY3Rp b24gMTUuMyBkZWZpbmVzIHRoZQ0KPj4gICAgICAgICBJQU5BIHJlZ2lzdHJ5IGZvciB0aGUgbWVk aWEgZm9ybWF0IG5hbWVzcGFjZS4iDQo+Pg0KPj4gLS0tLQ0KPj4NCj4+Pj4+Pj4+PiAtNi4xOiBX aGF0IGlzIG1lYW50IGJ5IHNheWluZyBhbiAiZW5kcG9pbnQgTVVTVCBhc3N1bWUgdGhhdA0KPj4+ Pj4+Pj4+IGxhcmdlciAuLi4NCj4+Pj4+Pj4+PiB3aWxsIGJlIHJlamVjdGVkIj8gQ2FuIHRoYXQg YmUgc3RhdGVkIGluIHRlcm1zIG9mIGFjdHVhbA0KPj4+Pj4+Pj4+IHByb2NlZHVyZSAoZS5nLg0K Pj4+Pj4+Pj4+ICJlbmRwb2ludCBNVVNUIE5PVCBzZW5kLi4ubGFyZ2VyIj8NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBJJ2QgbGlrZSBSb21hbidzIGlucHV0IG9uIHRoaXMsIGluIGNhc2UgaGUgaGFkIHNv bWUgY2FzZXMgaW4NCj4+Pj4+Pj4+IG1pbmQgd2hlcmUgZW5kcG9pbnQgd2lsbCBoYXZlIHRvIHNl bmQgbGFyZ2VyIG1lc3NhZ2VzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEkgZ3Vlc3Mgd2UgY291bGQg c2F5IFNIT1VMRCBOTyBzZW5kIGxhcmdlciBtZXNzYWdlLCBhbmQgZXhwbGFpbg0KPj4+Pj4+Pj4g dGhhdCBvbmUgY2Fubm90IGFzc3VtZSB0aGF0IGxhcmdlciBtZXNzYWdlIChpZiBzZW50IGZvciB3 aGF0ZXZlcg0KPj4+Pj4+Pj4gcmVhc29uKQ0KPj4+Pj4+Pj4gd2lsbCBiZSBhY2NlcHRlZCBieSB0 aGUgcGVlci4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhdCB3b3VsZCBiZSByZWFzb25hYmxlIGlmIGl0 IGlzIHRoZSByaWdodCBhbnN3ZXIuIEkganVzdCB3YW50DQo+Pj4+Pj4+IHRvIGF2b2lkIHRoZSB2 YWd1ZW5lc3Mgb2YgIk1VU1QgYXNzdW1lIi4NCj4+Pj4+Pg0KPj4+Pj4+IEkgc3VnZ2VzdCB0aGUg Zm9sbG93aW5nIG1vZGlmaWVkIHRleHQ6DQo+Pj4+Pj4NCj4+Pj4+PiAiQW4gU0NUUCBlbmRwb2lu dCBTSE9VTEQgTk9UIHNlbmQgYSBTQ1RQIHVzZXIgbWVzc2FnZSB3aXRoIGENCj4+Pj4+PiBtZXNz YWdlIHNpemUgdGhhdCBpcyBsYXJnZXIgdGhhbiB0aGUgbWF4aW11bSBzaXplIGluZGljYXRlZCBi eSB0aGUNCj4+Pj4+PiBwZWVyLg0KPj4+Pj4+IElmDQo+Pj4+Pj4gdGhlIFNDVFAgZW5kcG9pbnQg bmVlZHMgKGZvciB3aGF0ZXZlciByZWFzb24pIHRvIHNlbmQgYSBsYXJnZXINCj4+Pj4+PiBtZXNz YWdlLCBpdCBjYW5ub3QgYmUgYXNzdW1lZCB0aGF0IHRoZSBtZXNzYWdlIHdpbGwgYmUgYWNjZXB0 ZWQgYnkNCj4+Pj4+PiB0aGUgcGVlci4iDQo+Pj4+Pg0KPj4+Pj4gSSdtIG9rYXkgd2l0aCB0aGF0 LCBidXQgZG9uJ3QgYmUgc3VycHJpc2VkIGlmIHdlIGdldCBxdWVzdGlvbnMNCj4+Pj4+IGFib3V0 IHdoZXRoZXIgaXQgZXZlciB3b3VsZCBldmVyIG1ha2Ugc2Vuc2UgdG8gc2VuZCBhIG1lc3NhZ2Ug dGhhdA0KPj4+Pj4geW91IGNhbid0IGFzc3VtZSB0aGUgcGVlciB3aWxsIGFjY2VwdC4NCj4+Pj4+ IChJIHdvbmRlciBpZiBpdCdzIG1vcmUgYSBtYXR0ZXINCj4+Pj4+IG9mICJwcm9iYWJseSBub3Qg YWNjZXB0IiwgZ2l2ZW4gdGhlIHBlZXIgaGFzIGFscmVhZHkgc3RhdGVkIGl0cw0KPj4+Pj4gcHJl ZmVyZW5jZS4NCj4+Pj4NCj4+Pj4gSWYgbm9ib2R5IG9iamVjdHMsIEkgYW0gb2sgc2F5aW5nICJN VVNUIE5PVCBzZW5kIi4NCj4+Pj4NCj4+Pj4gQmVjYXVzZSwgaWYgdGhlcmUgaXMgYSBjYXNlIHdo ZXJlIGl0IHdvdWxkIGJlIG5lZWRlZCwgdGhlIHBlZXJzDQo+Pj4+IHNpbXBseSBuZWVkIHRvIHN1 cHBvcnQgYW5kIG5lZ290aWF0ZSBhIGxhcmdlciB2YWx1ZS4NCj4+Pg0KPj4+IE9rYXkgd2l0aCBt ZS4gSWYgc29tZW9uZSBjb21lcyB1cCB3aXRoIGEgcGxhdXNpYmxlIHJlYXNvbiBvbmUgbWlnaHQN Cj4+PiBuZWVkIHRvIHNlbmQgbGFyZ2VyIG1lc3NhZ2VzLCBwbGVhc2Ugc3BlYWsgdXAgYmVmb3Jl IHRoZSBJRVRGIExDDQo+Pj4gY29tcGxldGVzLiA6LSkNCj4+DQo+PiBTdWdnZXN0ZWQgbW9kaWZp ZWQgcGFyYWdyYXBoOg0KPj4NCj4+ICAgICAgICAgICJBbiBTQ1RQIGVuZHBvaW50IE1VU1QgTk9U IHNlbmQgYSBTQ1RQIHVzZXIgbWVzc2FnZSB3aXRoIGENCj4+IG1lc3NhZ2UNCj4+ICAgICAgICAg ICBzaXplIHRoYXQgaXMgbGFyZ2VyIHRoYW4gdGhlIG1heGltdW0gc2l6ZSBpbmRpY2F0ZWQgYnkg dGhlDQo+PiBwZWVyLCBhcyBpdA0KPj4gICAgICAgICAgIGNhbm5vdCBiZSBhc3N1bWVkIHRoYXQg dGhlIHBlZXIgd291bGQgYWNjZXB0IHN1Y2ggbWVzc2FnZS4iDQo+Pg0KPj4gUmVnYXJkcywNCj4+ DQo+PiBDaHJpc3Rlcg0KDQo= From nobody Wed Jan 25 05:41: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 E9818129951; Wed, 25 Jan 2017 05:41:08 -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 1zISsiXK0Dpm; Wed, 25 Jan 2017 05:41:06 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D021298CE; Wed, 25 Jan 2017 05:41:06 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id j13so13485338iod.3; Wed, 25 Jan 2017 05:41:06 -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=1ZZXhApBLeJs/0JZg9Urd6n17EsNngzJnY6cMjOlZy4=; b=d9rocjnvU+f4d0fFEljKFp8sLP8PYEg14+fuJz1QK8BkrwuLcl9wSdlbRUTZgK7r1Q oxVnHK/QTNpRjwtOdCSl8HdV7ztgPdgmykqAMXPbxdFRfv87liSJq5McKAw+QmcFFtHS 0gRuHINK3jWIEk1CvZaWBZzkPG6TRZYsNkSc/dQiwjcsxQYUMkgxrYtq2ZxfUD6ajx2E TxF3pTaAjtUv6Dqx/vz/j/kPeQ0r3lvUqB1JV0FAo2ptRQbqLJy6Ov13Fa5IqUGUNEXG MQFLpaoRlHsYAMxj12CvUJUpTcOueN5vVoJHxaSJmx3HVR98ohu/msPX2dRTQwv3g8rC 9HYg== 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=1ZZXhApBLeJs/0JZg9Urd6n17EsNngzJnY6cMjOlZy4=; b=LQfBr1VwMo0xpTHAzVffRxddVBQjs6Gfb2Bs6sCZdG0qJfoTAGhdSVIRiEzgoI0zKZ uYsBIWSzuQO/21atHWEzOfhi4LOAFXSXdTH4oUHXQdrkk3KnOMtjXfvmPI6NgHIV7pNZ ZSeVjFi0NYSEvpvHoJUfJdEDjgMw/xbP73rmBzRvybynBDqhHnAG9KvqrLpR8vtrj02q EAR4OJDkxlqD8gw0k6tsnqaWv3oPmavQZadmKFUCYSjtPtzgZf0YuRvsmf9f5jZMJbce dnh8SVqL6+wuSxas/rtvf/1pazfNK/rX0up1BBuK1ildV9z/b6VpJ/c4Ze3DRdUXL8OP YK2A== X-Gm-Message-State: AIkVDXJHSh6+jHU3L28I+PZE+2DthYwEveLCsfPj/EgqXrhPeiLnUDadZDZoDjvYMA6m5hFiqN0Rwz9CUu02NQ== X-Received: by 10.107.12.150 with SMTP id 22mr32029532iom.138.1485351665622; Wed, 25 Jan 2017 05:41:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.140.71 with HTTP; Wed, 25 Jan 2017 05:41:05 -0800 (PST) In-Reply-To: <6AD021E5-2C84-4BED-88D8-DFD5773C768B@cisco.com> References: <148516969384.29478.16962145399713084931.idtracker@ietfa.amsl.com> <6AD021E5-2C84-4BED-88D8-DFD5773C768B@cisco.com> From: Andy Hutton Date: Wed, 25 Jan 2017 13:41:05 +0000 Message-ID: To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a113ee2f26569240546eb621d Archived-At: Cc: "mmusic-chairs@ietf.org" , "sipbrandy-chairs@ietf.org" , "mmusic@ietf.org" , Ben Campbell Subject: Re: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 13:41:09 -0000 --001a113ee2f26569240546eb621d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Charles, thanks for the comments and yes I agree will include some further text in section 5 and a reference to the IMTC spec in the next update. Andy On Tue, Jan 24, 2017 at 3:47 PM, Charles Eckel (eckelcu) wrote: > Hi Andy, > > > > I=E2=80=99m glad to see this draft. One initial comment after a quick rev= iew - in > section 5, the answerer must also be allowed to indicate the profile as A= VP > or SAVP yet still include the "a=3Drtcp-fb" SDP attribute. This is not > allowed by RFC 4585, so it must be described here as well. > > Also, it would be good to reference the IMTC best practice document that > popularized this relaxation of RFC 4585: IMTC 1015 =E2=80=93 =E2=80=9CSIP= Video Profile > Best Practices=E2=80=9D. > > http://www.imtc.org/documents/official-documents/ > > > > Cheers, > > Charles > > > > *From: *mmusic on behalf of Andy Hutton < > andyhutton.ietf@gmail.com> > *Date: *Monday, January 23, 2017 at 3:51 AM > *To: *"mmusic-chairs@ietf.org" , " > sipbrandy-chairs@ietf.org" , Ben Campbell < > ben@nostrum.com>, "mmusic@ietf.org" > *Subject: *[MMUSIC] Fwd: I-D Action: draft-hutton-mmusic- > opportunistic-negotiation-00.txt > > > > > > I have just submitted this draft. > > > > The draft is the result of discussion in the SIPBrandy working group > regarding how to proceed with https://tools.ietf.org/ > html/draft-ietf-sipbrandy-osrtp-01. The SIPBrandy WG was not able to > progress the opportunistic SRTP work because it required an update to RFC > 4568 which is not covered by the SIPBrandy charter. > > > > This short draft is therefore submitted to MMUSIC with a view to updating > the relevant RFC's and progressing the OSRTP work in SIPBrandy. > > > > Regards > > Andy > > > > > > > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jan 23, 2017 at 11:08 AM > Subject: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Negotiating SRTP and RTCP Feedback using the > RTP/AVP Profile > Authors : Andrew Hutton > Roland Jesske > Alan Johnston > Gonzalo Salgueiro > Bernard Aboba > Filename : draft-hutton-mmusic- > opportunistic-negotiation-00.txt > Pages : 6 > Date : 2017-01-23 > > Abstract: > This document describes how the use of the Secure Real-time transport > protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio > Video Profile) defined in [RFC3551]. Such a mechanism is used to > provide a means for encrypted media to be used in environments where > support for encryption is not known in advance, and not required. > The same mechanism is also applied to negotiation of the Extended RTP > Profile for Real-time Transport Control Protocol Based Feedback (RTP/ > AVPF) [RFC4585]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hutton-mmusic- > opportunistic-negotiation/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-hutton-mmusic- > opportunistic-negotiation-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > > > > --001a113ee2f26569240546eb621d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charles, thanks for the comments and yes I agree will i= nclude some further text in section 5 and a reference to the IMTC spec in t= he next update.

Andy

<= div class=3D"gmail_quote">On Tue, Jan 24, 2017 at 3:47 PM, Charles Eckel (e= ckelcu) <eckelcu@cisco.com> wrote:

Hi Andy,

=C2=A0

I=E2=80=99m glad to see this draft. One initial comm= ent after a quick review - in section 5, the answerer must also be allowed = to indicate the profile as AVP or SAVP yet still include the "a=3Drtcp= -fb" SDP attribute. This is not allowed by RFC 4585, so it must be described here as well.

Also, it would be good to reference the IMTC best pr= actice document that popularized this relaxation of RFC 4585: IMTC 1015 =E2= =80=93 =E2=80=9CSIP Video Profile Best Practices=E2=80=9D.

http://www.imtc.org/documents/official-doc= uments/

=C2=A0

Cheers,

Charles

=C2=A0

F= rom: mmusic <mmusic-bounces@ietf.org> on behalf of Andy Hutton <andyhutton.ietf@gmail.com>
Date: Monday, January 23, 2017 at 3:51 AM
To: "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "sipbrandy-chairs@ietf.org= " <sipbrandy-chairs@ietf.org>, Ben Campbell <ben@nostrum.com>, "mmusic@ietf.org" <mmusic@ietf.org> Subject: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportun= istic-negotiation-00.txt

=C2=A0

=C2=A0

I have just submitted this draft.

=C2=A0

The draft is the result of discussion in the SIPBran= dy working group regarding how to proceed with=C2=A0https://to= ols.ietf.org/html/draft-ietf-sipbrandy-osrtp-01.=C2=A0 The SI= PBrandy WG was not able to progress the opportunistic SRTP work because it require= d an update to RFC 4568 which is not covered by the SIPBrandy charter.

=C2=A0

This short draft is therefore submitted to MMUSIC wi= th a view to updating the relevant RFC's and progressing the OSRTP work= in SIPBrandy.

=C2=A0

Regards

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Jan 23, 2017 at 11:08 AM
Subject: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.= txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Andr= ew Hutton
=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 Roland Jesske
=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 Alan Johnston
=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 Gonzalo Salgueiro
=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 Bernard Aboba
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-hut= ton-mmusic-opportunistic-negotiation-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-23

Abstract:
=C2=A0 =C2=A0This document describes how the use of the Secure Real-time tr= ansport
=C2=A0 =C2=A0protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Au= dio
=C2=A0 =C2=A0Video Profile) defined in [RFC3551].=C2=A0 Such a mechanism is= used to
=C2=A0 =C2=A0provide a means for encrypted media to be used in environments= where
=C2=A0 =C2=A0support for encryption is not known in advance, and not requir= ed.
=C2=A0 =C2=A0The same mechanism is also applied to negotiation of the Exten= ded RTP
=C2=A0 =C2=A0Profile for Real-time Transport Control Protocol Based Feedbac= k (RTP/
=C2=A0 =C2=A0AVPF) [RFC4585].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-hutton-mmusic-opportunistic-negotiation/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-hutt= on-mmusic-opportunistic-negotiation-00


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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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

=C2=A0


--001a113ee2f26569240546eb621d-- From nobody Wed Jan 25 05:41: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 51554129951; Wed, 25 Jan 2017 05:41:28 -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 JRT5mUHCWGJ7; Wed, 25 Jan 2017 05:41:27 -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 6D2841298CE; Wed, 25 Jan 2017 05:41:26 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-4c-5888ab04e22b Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id CE.FE.28805.40BA8885; Wed, 25 Jan 2017 14:41:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 14:40:33 +0100 From: Christer Holmberg To: Elwyn Davies , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-4572-update-11 Thread-Index: AQHSdoIexBxSt+o33kK0m/85TkkEWaFJRV6A Date: Wed, 25 Jan 2017 13:40:32 +0000 Message-ID: References: <148529043511.12735.9313753556504417778.idtracker@ietfa.amsl.com> In-Reply-To: <148529043511.12735.9313753556504417778.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: <88571B48E596E3449D14B2D538C45CC0@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2K7qC7L6o4Ig6mr9S0+nLvKbrHtuKDF 1VefWSyebZzPYjF1+WMWB1aP4yt2snssWfKTKYApissmJTUnsyy1SN8ugStj7inpgqecFR86 ZrM2MF5h72Lk5JAQMJE4dH8zcxcjF4eQwDpGiYWbbzJBOIsZJf4+bgVyODjYBCwkuv9pgzSI CARKzFw9gRWkhllgOaPEg32fGEESwgLmEi9nHmWGKLKQ+DphOhuEbSTR8n0TmM0ioCoxZ3If mM0rYC3RunA62BVCAr4Sz7Z+B5vDKeAn8bDhHVgNo4CYxPdTa5hAbGYBcYlbT+YzQVwtILFk z3lmCFtU4uXjf6wgtqiAnsTy52ug4ooS7U8bGCF6DSTen5vPDGFbS1zuesAGYWtLLFv4mhni HkGJkzOfsExgFJ+FZN0sJO2zkLTPQtI+C0n7AkbWVYyixanFSbnpRkZ6qUWZycXF+Xl6eakl mxiBsXhwy2+DHYwvnzseYhTgYFTi4f2Q3R4hxJpYVlyZe4hRgoNZSYRXfGVHhBBvSmJlVWpR fnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTBycUg2ME0+xW6rwhuvNPlLrf6t7 2xNx7tyTVdrnbfRUs3V55PMmWWhN0BXQ7dS7y7TZ8fbC9LfZvizHFn9hjzsfa3304VZZEb6m bkmHG481lfjTpT4nHLbtXs2Zv8Jgilz5Em7HigATObWTArt/nc85/1Jw5u6yushu99+zbZm2 qPWZ7333gWX//A9KLMUZiYZazEXFiQD1aADtwQIAAA== Archived-At: Cc: "draft-ietf-mmusic-4572-update.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-4572-update-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 13:41:28 -0000 Hi Elwyn, Thanks for your review! See inline. Nits/editorial comments: >s1, para 2: s/TLS protocol/The TLS protocol/ (as per RFC 4572) I will fix as suggested. >s4, para 2: s/a new protocol identifier/the protocol identifier/ (it >isn't new any more) I am happy to remove =B3new=B2, but doesn=B9t =B3a=B2 still sound better th= an =B3the=B2? >s5.1: Suggest s/m- line/"m" line/ for consistency with s3.4 I will replace with single quotes (=8Cm=B9), for consistency with s3.4 and = s4. >s5.1, para 1: s/e.g./e.g.,/ I will fix as suggested. >s5.1, para 4: s/that each used certificate matches/that each >certificate used matches/ I will fix as suggested. >s5.1, para 5: s/each used certificate matches/each certificate used >matches/ I will fix as suggested. >s8, para 5: ' This specification creates a new IANA registry named >"Hash Function Textual Names".' >The registry is no longer new. Perhaps s/creates a new IANA >registry/takes over the IANA registry from RFC 4572/ I suggest: "This specification takes over the IANA registry named "Hash Function Textual Names=B2, that was created in RFC 4572. It will not be part of the SDP Parameters.=B2 Regards, Christer From nobody Wed Jan 25 07:14:07 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 96CB3129847; Wed, 25 Jan 2017 07:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 so6G2M39UtRK; Wed, 25 Jan 2017 07:13:53 -0800 (PST) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (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 9BE4F12998C; Wed, 25 Jan 2017 07:13:53 -0800 (PST) Received: from d.b.e.5.0.8.d.b.f.6.1.b.0.8.c.7.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:7c80:b16f:bd80:5ebd]) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cWObl-00013x-Nd; Wed, 25 Jan 2017 14:31:34 +0000 Date: Wed, 25 Jan 2017 14:31:29 +0000 Message-ID: Importance: normal From: Elwyn Davies To: Christer Holmberg , gen-art@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_6905722906156110" Archived-At: Cc: draft-ietf-mmusic-4572-update.all@ietf.org, ietf@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-4572-update-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 15:13:56 -0000 ----_com.samsung.android.email_6905722906156110 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIENocmlzdGVyLgpUaGFua3MgZm9yIHRoZSByYXBpZCByZXNwb25zZS4KVGhhdCdzIGFsbCBm aW5lLiDCoFJlIHM0LCBwYXJhIDI6IEZpcnN0LCBpIHJlYWxpc2VkIEkgbWlzc2VkIGFub3RoZXIg aW5zdGFuY2Ugb2YgJ25ldycgaW4gdGhlIGFic3RyYWN0LiDCoEkgdGhpbmsgdGhhdCAndGhlJyBp cyBjb3JyZWN0IGluIHRoZSBuZXcgW3NpY10gdmVyc2lvbiBpbiBib3RoIHBsYWNlcy4gwqBJdCdz IHBlcm5pY2tldHkgYnV0IHdoZW4gaXQgd2FzICdhIG5ldycgd2hhdCB5b3UgaGF2ZSBpcyBzaG9y dGhhbmQgZm9yICJhIG5ldyBwcm90b2NvbCBpZGVudGlmaWVyIHRvIGJlIGNhbGxlZCAnVENQL1RM UycuLi4iIMKgKGFuIGFkZGl0aW9uIHRvIHRoZSBleGlzdG5nIGxpc3QpIHdoZXJlYXMgYmVjYXVz ZSB0aGUgaWRlbnRpZmllciBpcyBubyBsb25nZXIgbmV3IHdlIG5vdyBoYXZlICJ0aGUgcHJvdG9j b2wgaWRlbnRpZmllciBbbmFtZWRdICdUQ1AvVExTJy4uLiIuIMKgwqAKQ2hlZXJzLEVsd3luClNl bnQgZnJvbSBTYW1zdW5nIHRhYmxldC4KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LUZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+ IERhdGU6IDI1LzAxLzIwMTcgIDEzOjQwICAoR01UKzAwOjAwKSBUbzogRWx3eW4gRGF2aWVzIDxl bHd5bmRAZGlhbC5waXBleC5jb20+LCBnZW4tYXJ0QGlldGYub3JnIENjOiBkcmFmdC1pZXRmLW1t dXNpYy00NTcyLXVwZGF0ZS5hbGxAaWV0Zi5vcmcsIGlldGZAaWV0Zi5vcmcsIG1tdXNpY0BpZXRm Lm9yZyBTdWJqZWN0OiBSZTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRl LTExIApIaSBFbHd5biwKClRoYW5rcyBmb3IgeW91ciByZXZpZXchIFNlZSBpbmxpbmUuCgpOaXRz L2VkaXRvcmlhbCBjb21tZW50czoKCj5zMSwgcGFyYSAyOiBzL1RMUyBwcm90b2NvbC9UaGUgVExT IHByb3RvY29sLyAoYXMgcGVyIFJGQyA0NTcyKQoKSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuCgoK PnM0LCBwYXJhIDI6IHMvYSBuZXcgcHJvdG9jb2wgaWRlbnRpZmllci90aGUgcHJvdG9jb2wgaWRl bnRpZmllci8gKGl0Cj5pc24ndCBuZXcgYW55IG1vcmUpCgpJIGFtIGhhcHB5IHRvIHJlbW92ZSDC s25ld8KyLCBidXQgZG9lc27CuXQgwrNhwrIgc3RpbGwgc291bmQgYmV0dGVyIHRoYW4gwrN0aGXC sj8KCgo+czUuMTogU3VnZ2VzdCBzL20tIGxpbmUvIm0iIGxpbmUvwqAgZm9yIGNvbnNpc3RlbmN5 IHdpdGggczMuNAoKSSB3aWxsIHJlcGxhY2Ugd2l0aCBzaW5nbGUgcXVvdGVzICjFkm3CuSksIGZv ciBjb25zaXN0ZW5jeSB3aXRoIHMzLjQgYW5kIHM0LgoKCj5zNS4xLCBwYXJhIDE6IHMvZS5nLi9l LmcuLC8KCkkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLgoKCj5zNS4xLCBwYXJhIDQ6IHMvdGhhdCBl YWNoIHVzZWQgY2VydGlmaWNhdGUgbWF0Y2hlcy90aGF0IGVhY2gKPmNlcnRpZmljYXRlIHVzZWQg bWF0Y2hlcy8KCkkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLgoKCj5zNS4xLCBwYXJhIDU6IHMvZWFj aCB1c2VkIGNlcnRpZmljYXRlIG1hdGNoZXMvZWFjaCBjZXJ0aWZpY2F0ZSB1c2VkCj5tYXRjaGVz LwoKSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuCgo+czgsIHBhcmEgNTogJyBUaGlzIHNwZWNpZmlj YXRpb24gY3JlYXRlcyBhIG5ldyBJQU5BIHJlZ2lzdHJ5IG5hbWVkCj4iSGFzaCBGdW5jdGlvbiBU ZXh0dWFsIE5hbWVzIi4nCj5UaGUgcmVnaXN0cnkgaXMgbm8gbG9uZ2VyIG5ldy7CoCBQZXJoYXBz IHMvY3JlYXRlcyBhIG5ldyBJQU5BCj5yZWdpc3RyeS90YWtlcyBvdmVyIHRoZSBJQU5BIHJlZ2lz dHJ5IGZyb20gUkZDIDQ1NzIvCgpJIHN1Z2dlc3Q6CgogIlRoaXMgc3BlY2lmaWNhdGlvbiB0YWtl cyBvdmVyIHRoZSBJQU5BIHJlZ2lzdHJ5IG5hbWVkICJIYXNoIEZ1bmN0aW9uCiBUZXh0dWFsIE5h bWVzwrIsIHRoYXQgd2FzIGNyZWF0ZWQgaW4gUkZDIDQ1NzIuwqAgSXQgd2lsbCBub3QgYmUgcGFy dCBvZgogdGhlIFNEUCBQYXJhbWV0ZXJzLsKyCgoKUmVnYXJkcywKCkNocmlzdGVyCgo= ----_com.samsung.android.email_6905722906156110 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkhpLCBDaHJpc3Rlci48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyBmb3IgdGhlIHJhcGlkIHJlc3BvbnNlLjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhdCdzIGFsbCBmaW5lLiAmbmJzcDtSZSBzNCwgcGFyYSAy OiBGaXJzdCwgaSByZWFsaXNlZCBJIG1pc3NlZCBhbm90aGVyIGluc3RhbmNlIG9mICduZXcnIGlu IHRoZSBhYnN0cmFjdC4gJm5ic3A7SSB0aGluayB0aGF0ICd0aGUnIGlzIGNvcnJlY3QgaW4gdGhl IG5ldyBbc2ljXSB2ZXJzaW9uIGluIGJvdGggcGxhY2VzLiAmbmJzcDtJdCdzIHBlcm5pY2tldHkg YnV0IHdoZW4gaXQgd2FzICdhIG5ldycgd2hhdCB5b3UgaGF2ZSBpcyBzaG9ydGhhbmQgZm9yICJh IG5ldyBwcm90b2NvbCBpZGVudGlmaWVyIHRvIGJlIGNhbGxlZCAnVENQL1RMUycuLi4iICZuYnNw OyhhbiBhZGRpdGlvbiB0byB0aGUgZXhpc3RuZyBsaXN0KSB3aGVyZWFzIGJlY2F1c2UgdGhlIGlk ZW50aWZpZXIgaXMgbm8gbG9uZ2VyIG5ldyB3ZSBub3cgaGF2ZSAidGhlIHByb3RvY29sIGlkZW50 aWZpZXIgW25hbWVkXSAnVENQL1RMUycuLi4iLiAmbmJzcDsmbmJzcDs8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PkNoZWVycyw8L2Rpdj48ZGl2PkVsd3luPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp diBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9y OiM1NzU3NTciIGRpcj0iYXV0byI+U2VudCBmcm9tIFNhbXN1bmcgdGFibGV0LjwvZGl2PjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAi PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3Jp Z2luYWxNZXNzYWdlIC0tPjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwv ZGl2PjxkaXY+RnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbSZndDsgPC9kaXY+PGRpdj5EYXRlOiAyNS8wMS8yMDE3ICAxMzo0MCAgKEdNVCsw MDowMCkgPC9kaXY+PGRpdj5UbzogRWx3eW4gRGF2aWVzICZsdDtlbHd5bmRAZGlhbC5waXBleC5j b20mZ3Q7LCBnZW4tYXJ0QGlldGYub3JnIDwvZGl2PjxkaXY+Q2M6IGRyYWZ0LWlldGYtbW11c2lj LTQ1NzItdXBkYXRlLmFsbEBpZXRmLm9yZywgaWV0ZkBpZXRmLm9yZywgbW11c2ljQGlldGYub3Jn IDwvZGl2PjxkaXY+U3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW1tdXNpYy00NTcy LXVwZGF0ZS0xMSA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj5IaSBFbHd5biw8YnI+PGJyPlRo YW5rcyBmb3IgeW91ciByZXZpZXchIFNlZSBpbmxpbmUuPGJyPjxicj5OaXRzL2VkaXRvcmlhbCBj b21tZW50czo8YnI+PGJyPiZndDtzMSwgcGFyYSAyOiBzL1RMUyBwcm90b2NvbC9UaGUgVExTIHBy b3RvY29sLyAoYXMgcGVyIFJGQyA0NTcyKTxicj48YnI+SSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQu PGJyPjxicj48YnI+Jmd0O3M0LCBwYXJhIDI6IHMvYSBuZXcgcHJvdG9jb2wgaWRlbnRpZmllci90 aGUgcHJvdG9jb2wgaWRlbnRpZmllci8gKGl0PGJyPiZndDtpc24ndCBuZXcgYW55IG1vcmUpPGJy Pjxicj5JIGFtIGhhcHB5IHRvIHJlbW92ZSDCs25ld8KyLCBidXQgZG9lc27CuXQgwrNhwrIgc3Rp bGwgc291bmQgYmV0dGVyIHRoYW4gwrN0aGXCsj88YnI+PGJyPjxicj4mZ3Q7czUuMTogU3VnZ2Vz dCBzL20tIGxpbmUvIm0iIGxpbmUvJm5ic3A7IGZvciBjb25zaXN0ZW5jeSB3aXRoIHMzLjQ8YnI+ PGJyPkkgd2lsbCByZXBsYWNlIHdpdGggc2luZ2xlIHF1b3RlcyAoxZJtwrkpLCBmb3IgY29uc2lz dGVuY3kgd2l0aCBzMy40IGFuZCBzNC48YnI+PGJyPjxicj4mZ3Q7czUuMSwgcGFyYSAxOiBzL2Uu Zy4vZS5nLiwvPGJyPjxicj5JIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC48YnI+PGJyPjxicj4mZ3Q7 czUuMSwgcGFyYSA0OiBzL3RoYXQgZWFjaCB1c2VkIGNlcnRpZmljYXRlIG1hdGNoZXMvdGhhdCBl YWNoPGJyPiZndDtjZXJ0aWZpY2F0ZSB1c2VkIG1hdGNoZXMvPGJyPjxicj5JIHdpbGwgZml4IGFz IHN1Z2dlc3RlZC48YnI+PGJyPjxicj4mZ3Q7czUuMSwgcGFyYSA1OiBzL2VhY2ggdXNlZCBjZXJ0 aWZpY2F0ZSBtYXRjaGVzL2VhY2ggY2VydGlmaWNhdGUgdXNlZDxicj4mZ3Q7bWF0Y2hlcy88YnI+ PGJyPkkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLjxicj48YnI+Jmd0O3M4LCBwYXJhIDU6ICcgVGhp cyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgSUFOQSByZWdpc3RyeSBuYW1lZDxicj4mZ3Q7 Ikhhc2ggRnVuY3Rpb24gVGV4dHVhbCBOYW1lcyIuJzxicj4mZ3Q7VGhlIHJlZ2lzdHJ5IGlzIG5v IGxvbmdlciBuZXcuJm5ic3A7IFBlcmhhcHMgcy9jcmVhdGVzIGEgbmV3IElBTkE8YnI+Jmd0O3Jl Z2lzdHJ5L3Rha2VzIG92ZXIgdGhlIElBTkEgcmVnaXN0cnkgZnJvbSBSRkMgNDU3Mi88YnI+PGJy Pkkgc3VnZ2VzdDo8YnI+PGJyPiAiVGhpcyBzcGVjaWZpY2F0aW9uIHRha2VzIG92ZXIgdGhlIElB TkEgcmVnaXN0cnkgbmFtZWQgIkhhc2ggRnVuY3Rpb248YnI+IFRleHR1YWwgTmFtZXPCsiwgdGhh dCB3YXMgY3JlYXRlZCBpbiBSRkMgNDU3Mi4mbmJzcDsgSXQgd2lsbCBub3QgYmUgcGFydCBvZjxi cj4gdGhlIFNEUCBQYXJhbWV0ZXJzLsKyPGJyPjxicj48YnI+UmVnYXJkcyw8YnI+PGJyPkNocmlz dGVyPGJyPjxicj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_6905722906156110-- From nobody Wed Jan 25 09:52: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 5EC83129A9A for ; Wed, 25 Jan 2017 09:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 vndJBvVr3jo3 for ; Wed, 25 Jan 2017 09:52:21 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E34712998D for ; Wed, 25 Jan 2017 09:52:21 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id k15so29449522qtg.3 for ; Wed, 25 Jan 2017 09:52:21 -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=7AdzkSAfqmfWQlV+azC68efBJUiDBq/Lf/lkDtJvoRc=; b=BIcKBkZlFArMmf9o5bKhdBrLuTU4LTQ+gKimAd6Liop+LyQYeWFjBuP57x100DFGbo MyAapBY/R5iBEzbI7Gnbw0B/bPmjYoHBJc7hZK9VPTRxFqa25yTmF+Hx4+s2Rh0lshdc LVlmtq+gfTK5ZyrvudPx4RqbRKs87xRDbx8dif0mAsLnYzGrhHzuWp77Hm8qo1Pc1AMo dEMlyFd4oZ+AZ0pXaCz9QAyJtGLx9CwhGCLd005HKCV54wSiy3TT2NOpI0ssVXMb/8j2 WqzzcOHj8N8dRgXhVxTkkbzRaHAehhCXAnRmOfXPXjWymYpsgOOralHPnp683EzZJFxJ NgAw== 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=7AdzkSAfqmfWQlV+azC68efBJUiDBq/Lf/lkDtJvoRc=; b=doXzMUUJGiVOVpQC2Ft9YMFyIhyjM72nKu/8g6ujIDT2bWwd35i51/AFnqIVdAIYrL XiVDxRjviELcDl3jYpQjutSORn7EW5JazohzMPip+Xqj863MSB6b5CcaOKx2O2PYHPsg C4H6QBHSLk4ZBoqv1BajRkIDHpeI3bNdFRHrmbDbPZR8hYofY/VvWGsTPKAHETNf+7br Nez6BsfQJU4Mk11aqaVdL4qLuZbYYnIOjFrCXMtDnFpaO96zeANxvkvnxzqFOfbcjRhv EbXoCDoD1O0W38sriFOyy+uZOIbol8BAdcaL6hyW7pj7buCjwqaBlZ44+Piv8Pr7zqv9 nMMQ== X-Gm-Message-State: AIkVDXLNd/c2iXi/aNCShoM5wglqK9a3YmA6SDPbr8snYoQdbS6her602ls4CYiP1QKAwQ== X-Received: by 10.200.42.200 with SMTP id c8mr37049954qta.156.1485366740294; Wed, 25 Jan 2017 09:52:20 -0800 (PST) Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com. [209.85.216.169]) by smtp.gmail.com with ESMTPSA id i1sm19443040qte.32.2017.01.25.09.52.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 09:52:19 -0800 (PST) Received: by mail-qt0-f169.google.com with SMTP id v23so29323061qtb.0 for ; Wed, 25 Jan 2017 09:52:19 -0800 (PST) X-Received: by 10.237.50.101 with SMTP id y92mr38235057qtd.179.1485366739492; Wed, 25 Jan 2017 09:52:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Wed, 25 Jan 2017 09:52:18 -0800 (PST) In-Reply-To: <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> From: Roman Shpount Date: Wed, 25 Jan 2017 12:52:18 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a114d7daade6bbb0546eee46e Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 17:52:22 -0000 --001a114d7daade6bbb0546eee46e Content-Type: text/plain; charset=UTF-8 One more clarification: On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat wrote: > I see *no* mention that the sctp-port value should be chosen randomly. And > IMO it is unnatural to suggest port values be random. There could be > reasons for them not being random - for instance interop with SCTP over IP > with well known ports. Also, while there is currently no spec for multiple > SCTP associations in the same bundle, it is not hard to imagine that that > might be a useful thing to do in the future. In that case random port > numbers could be more troublesome. > SCTP associations described in this document are always simultaneous open (active/active) associations. Because of this sctp-port values are effectively emulating ephemeral ports allocated on the host system. Such ports are randomly allocated. I do not think well known SCTP ports would work with simultaneous open. This does not effect the ability to run multiple SCTP associations over the same underlying transport, since all this means that end point needs to allocate two different random sctp-port values. In any case, the option I was thinking about regarding sctp-port extension is to modify it to add support for URL parameters and to be something like a=sctp-port:6400;branch=abc3dl. The numeric part will be used in SCTP packets and the branch parameter will be used to indicate new/existing connection setup. Regards, _____________ Roman Shpount --001a114d7daade6bbb0546eee46e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One = more clarification:

On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <paul.k= yzivat@comcast.net> wrote:
I see *no* mention that the= sctp-port value should be chosen randomly. And IMO it is unnatural to sugg= est port values be random. There could be reasons for them not being random= - for instance interop with SCTP over IP with well known ports. Also, whil= e there is currently no spec for multiple SCTP associations in the same bun= dle, it is not hard to imagine that that might be a useful thing to do in t= he future. In that case random port numbers could be more troublesome.
<= /div>

SCTP associations described in = this document are always simultaneous open (active/active) associations. Be= cause of this sctp-port values are effectively emulating ephemeral ports al= located on the host system. Such ports are randomly allocated. I do not thi= nk well known SCTP ports would work with simultaneous open. This does not e= ffect the ability to run multiple SCTP associations over the same underlyin= g transport, since all this means that end point needs to allocate two diff= erent random sctp-port values.

In any case, the op= tion I was thinking about regarding sctp-port extension is to modify it to = add support for URL parameters and to be something like=C2=A0a=3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will be used = in SCTP packets and the branch parameter will be used to indicate new/exist= ing connection setup.

Regards,
_= ____________
Roman Shpount
=C2=A0
--001a114d7daade6bbb0546eee46e-- From nobody Wed Jan 25 10:18:41 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 E5515129AC7 for ; Wed, 25 Jan 2017 10:18:39 -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 IM-2453HXkWn for ; Wed, 25 Jan 2017 10:18:38 -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 80EB1129AC2 for ; Wed, 25 Jan 2017 10:18:38 -0800 (PST) X-AuditID: c1b4fb25-1dfff700000036c9-53-5888ebfca278 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id 94.6D.14025.CFBE8885; Wed, 25 Jan 2017 19:18:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 19:18:36 +0100 From: Christer Holmberg To: Roman Shpount , Paul Kyzivat Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJw Date: Wed, 25 Jan 2017 18:18:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbE9UPfP644IgxsbjS2mLn/MYvHgRy+b xYwLU5kdmD0mP57D6LFkyU8mj1tTCgKYo7hsUlJzMstSi/TtErgyji7rYi/4JFTx5V1aA+MW oS5GDg4JAROJi1vDuhi5OIQE1jFKnN0ziQnCWcwo0bPhHTtIEZuAhUT3P+0uRk4OEQE/idMT t7OAhJkF1CWuLg4CCQsLREscenuZEaIkBmjMYiYIO0ri4cKTLCA2i4CqxO89H8BqeAV8Jfr+ zoJadZBZ4tjWx8wgCU6BQInGb/PAbEYBMYnvp9aADWIWEJe49WQ+mC0hICCxZM95ZghbVOLl 43+sELaSxIrtlxghbtOUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg6C8nUWQgds5B0zELSsYCR ZRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYMQc3PJbdQfj5TeOhxgFOBiVeHgL9nZECLEm lhVX5h5ilOBgVhLh/fEKKMSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILU IpgsEwenVAOj6cevzvdEn5cW3LNpCJ4X+fpUgsbx42JJZWobGC1/7tSbVTS/d+ES7oX7pjIy leTyzbZmTHPSvDgn81rhFM8V8UsDJom3Oxe/k56g820fD1NKfJtex7qufuF/dxQNRW6/vLX7 48qfvM/eyW1MUcnQSL+k6xt2P3/X4o8rl2l6HGyQ1NkVdN9ZiaU4I9FQi7moOBEAfsXex5QC AAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 18:18:40 -0000 SGksDQoNCj4+IEkgc2VlICpubyogbWVudGlvbiB0aGF0IHRoZSBzY3RwLXBvcnQgdmFsdWUgc2hv dWxkIGJlIGNob3NlbiByYW5kb21seS4gQW5kIElNTyBpdCBpcyB1bm5hdHVyYWwgdG8gc3VnZ2Vz dCBwb3J0IHZhbHVlcw0KPj4gYmUgcmFuZG9tLiBUaGVyZSBjb3VsZCBiZSByZWFzb25zIGZvciB0 aGVtIG5vdCBiZWluZyByYW5kb20gLSBmb3IgaW5zdGFuY2UgaW50ZXJvcCB3aXRoIFNDVFAgb3Zl ciBJUCB3aXRoIHdlbGwga25vd24gDQo+PiBwb3J0cy4gQWxzbywgd2hpbGUgdGhlcmUgaXMgY3Vy cmVudGx5IG5vIHNwZWMgZm9yIG11bHRpcGxlIFNDVFAgYXNzb2NpYXRpb25zIGluIHRoZSBzYW1l IGJ1bmRsZSwgaXQgaXMgbm90IGhhcmQgdG8gaW1hZ2luZSANCj4+IHRoYXQgdGhhdCBtaWdodCBi ZSBhIHVzZWZ1bCB0aGluZyB0byBkbyBpbiB0aGUgZnV0dXJlLiBJbiB0aGF0IGNhc2UgcmFuZG9t IHBvcnQgbnVtYmVycyBjb3VsZCBiZSBtb3JlIHRyb3VibGVzb21lLg0KPj4NCj4gU0NUUCBhc3Nv Y2lhdGlvbnMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgYXJlIGFsd2F5cyBzaW11bHRhbmVv dXMgb3BlbiAoYWN0aXZlL2FjdGl2ZSkgYXNzb2NpYXRpb25zLiBCZWNhdXNlIG9mDQo+IHRoaXMg c2N0cC1wb3J0IHZhbHVlcyBhcmUgZWZmZWN0aXZlbHkgZW11bGF0aW5nIGVwaGVtZXJhbCBwb3J0 cyBhbGxvY2F0ZWQgb24gdGhlIGhvc3Qgc3lzdGVtLiBTdWNoIHBvcnRzIGFyZSByYW5kb21seQ0K PiBhbGxvY2F0ZWQuIEkgZG8gbm90IHRoaW5rIHdlbGwga25vd24gU0NUUCBwb3J0cyB3b3VsZCB3 b3JrIHdpdGggc2ltdWx0YW5lb3VzIG9wZW4uIFRoaXMgZG9lcyBub3QgZWZmZWN0IHRoZSBhYmls aXR5IA0KPiB0byBydW4gbXVsdGlwbGUgU0NUUCBhc3NvY2lhdGlvbnMgb3ZlciB0aGUgc2FtZSB1 bmRlcmx5aW5nIHRyYW5zcG9ydCwgc2luY2UgYWxsIHRoaXMgbWVhbnMgdGhhdCBlbmQgcG9pbnQg bmVlZHMgdG8gDQo+IGFsbG9jYXRlIHR3byBkaWZmZXJlbnQgcmFuZG9tIHNjdHAtcG9ydCB2YWx1 ZXMuDQoNCkNvcnJlY3QuIFRoZSBzY3RwLXBvcnQgYXR0cmlidXRlIGRvZXMgbm90IGluZGljYXRl IGFuIElQIHBvcnQuDQoNCj4gSW4gYW55IGNhc2UsIHRoZSBvcHRpb24gSSB3YXMgdGhpbmtpbmcg YWJvdXQgcmVnYXJkaW5nIHNjdHAtcG9ydCBleHRlbnNpb24gaXMgdG8gbW9kaWZ5IGl0IHRvIGFk ZCBzdXBwb3J0IGZvciBVUkwgDQo+IHBhcmFtZXRlcnMgYW5kIHRvIGJlIHNvbWV0aGluZyBsaWtl wqBhPXNjdHAtcG9ydDo2NDAwO2JyYW5jaD1hYmMzZGwuIFRoZSBudW1lcmljIHBhcnQgd2lsbCBi ZSB1c2VkIGluIFNDVFAgcGFja2V0cyANCj4gYW5kIHRoZSBicmFuY2ggcGFyYW1ldGVyIHdpbGwg YmUgdXNlZCB0byBpbmRpY2F0ZSBuZXcvZXhpc3RpbmcgY29ubmVjdGlvbiBzZXR1cC4NCg0KTm8u IExldCdzIG5vdCBzdGFydCBtYWtpbmcgdGhpbmdzIGNvbXBsaWNhdGVkIGFnYWluLiBUaGUgZG9j dW1lbnQgaXMgaW4gZ29vZCBzaGFwZSBpbiBteSBvcGluaW9uLiBMZXQncyBwdWJsaXNoIGl0Lg0K DQpLZWVwIGluIG1pbmQgdGhhdCBub3RoaW5nIHByZXZlbnRzIGFuIGVuZHBvaW50IGZyb20gY2xv c2luZy9yZS1vcGVuaW5nIGFuIFNDVFAgYXNzb2NpYXRpb24gYXQgYW55IHRpbWUuIEFsbCB3ZSBh cmUgc2F5aW5nIGlzIHRoYXQgYSBEVExTIGNoYW5nZSBkb2VzIG5vdCBhdXRvbWF0aWNhbGx5IGFm ZmVjdCB0aGUgU0NUUCBhc3NvY2lhdGlvbi4gDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K From nobody Wed Jan 25 10:43: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 18AB2129ADC; Wed, 25 Jan 2017 10:43: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 qQwRGHhAkeIO; Wed, 25 Jan 2017 10:43:22 -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 54502129ADB; Wed, 25 Jan 2017 10:43:21 -0800 (PST) X-AuditID: c1b4fb2d-a9bff70000007e3d-a3-5888f1c52eaf Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id EB.68.32317.5C1F8885; Wed, 25 Jan 2017 19:43:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 19:43:17 +0100 From: Christer Holmberg To: Elwyn Davies , "gen-art@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-4572-update-11 Thread-Index: AQHSdxe3xBxSt+o33kK0m/85TkkEWaFJht9Q Date: Wed, 25 Jan 2017 18:43:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC08AC@ESESSMB209.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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFC08ACESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2J7iO7xjx0RBuv+yFt8OHeV3WLbcUGL q68+s1g82zifxWLq8scsDqwex1fsZPdYsuQnUwBTFJdNSmpOZllqkb5dAlfG6b4FzAXvCiq+ zfzM0sD4IreLkZNDQsBE4uTZXuYuRi4OIYF1jBLfLs1igXAWM0qcPdvI1MXIwcEmYCHR/U8b pEFEIFBi5uoJrCA1zALLGSUe7PvECJIQFjCXmPNiChNEkYXE1wnT2SBsI4mta+aygcxhEVCV OHM5EsTkFfCVaFvkAVIhJOAm8WrDFxYQm1PAXWLqs1tgExkFxCS+n1oDNpFZQFzi1pP5TBA3 C0gs2XOeGcIWlXj5+B8rhK0ksWL7JUaI+nyJiaf+gF3AKyAocXLmE5YJjCKzkIyahaRsFpKy WUDXMQtoSqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjKLFqcXFuelGxnqpRZnJxcX5eXp5 qSWbGIHxdnDLb90djKtfOx5iFOBgVOLhLdjbESHEmlhWXJl7iFGCg1lJhHf9e6AQb0piZVVq UX58UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjM1V/9jUxbfuVYifLP7k w4HqBYca54pX3vqgcULkFZPfjF/dPpIVZ15vK5vfuqDiIpO0pKHdNf/nQQlTTlzvF2SRPxVU c7Usa6db5mUNfuGU3J/P/z/P1N/bFBmyJe5xc++CDdn9mXG9V/cbZwUUWr23d/wxZ3VyZtWB fasic3rEBD+ZH9H9qMRSnJFoqMVcVJwIABvNK/mzAgAA Archived-At: Cc: "draft-ietf-mmusic-4572-update.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-4572-update-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 18:43:24 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFC08ACESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWx3eW4sDQoNCj5UaGF0J3MgYWxsIGZpbmUuICBSZSBzNCwgcGFyYSAyOiBGaXJzdCwgaSBy ZWFsaXNlZCBJIG1pc3NlZCBhbm90aGVyIGluc3RhbmNlIG9mICduZXcnIGluIHRoZSBhYnN0cmFj dC4NCj5JIHRoaW5rIHRoYXQgJ3RoZScgaXMgY29ycmVjdCBpbiB0aGUgbmV3IFtzaWNdIHZlcnNp b24gaW4gYm90aCBwbGFjZXMuICBJdCdzIHBlcm5pY2tldHkgYnV0IHdoZW4gaXQgd2FzDQo+J2Eg bmV3JyB3aGF0IHlvdSBoYXZlIGlzIHNob3J0aGFuZCBmb3IgImEgbmV3IHByb3RvY29sIGlkZW50 aWZpZXIgdG8gYmUgY2FsbGVkICdUQ1AvVExTJy4uLiIgIChhbg0KPmFkZGl0aW9uIHRvIHRoZSBl eGlzdG5nIGxpc3QpIHdoZXJlYXMgYmVjYXVzZSB0aGUgaWRlbnRpZmllciBpcyBubyBsb25nZXIg bmV3IHdlIG5vdyBoYXZlICJ0aGUgcHJvdG9jb2wNCj5pZGVudGlmaWVyIFtuYW1lZF0gJ1RDUC9U TFMnLi4uIi4NCg0KTXkgc3VnZ2VzdGlvbiB3YXMgdG8gZHJvcCDigJxuZXfigJ0sIGJ1dCB0byBr ZWVwIOKAnGHigJ06DQoNCuKAnGEgcHJvdG9jb2wgaWRlbnRpZmllciwgJ1RDUC9UTFMnLCB3aGlj aOKApuKAnQ0KDQpCdXQsIEnigJltIGZpbmUgdXNpbmcg4oCcdGhl4oCdIDopDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCg0KDQpTZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQuDQoNCi0tLS0tLS0t IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4+DQpEYXRlOiAyNS8wMS8yMDE3IDEzOjQwIChHTVQrMDA6MDApDQpUbzogRWx3eW4g RGF2aWVzIDxlbHd5bmRAZGlhbC5waXBleC5jb208bWFpbHRvOmVsd3luZEBkaWFsLnBpcGV4LmNv bT4+LCBnZW4tYXJ0QGlldGYub3JnPG1haWx0bzpnZW4tYXJ0QGlldGYub3JnPg0KQ2M6IGRyYWZ0 LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLmFsbEBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1t bXVzaWMtNDU3Mi11cGRhdGUuYWxsQGlldGYub3JnPiwgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0 ZkBpZXRmLm9yZz4sIG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZS0xMQ0KDQpI aSBFbHd5biwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyEgU2VlIGlubGluZS4NCg0KTml0cy9l ZGl0b3JpYWwgY29tbWVudHM6DQoNCj5zMSwgcGFyYSAyOiBzL1RMUyBwcm90b2NvbC9UaGUgVExT IHByb3RvY29sLyAoYXMgcGVyIFJGQyA0NTcyKQ0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4N Cg0KDQo+czQsIHBhcmEgMjogcy9hIG5ldyBwcm90b2NvbCBpZGVudGlmaWVyL3RoZSBwcm90b2Nv bCBpZGVudGlmaWVyLyAoaXQNCj5pc24ndCBuZXcgYW55IG1vcmUpDQoNCkkgYW0gaGFwcHkgdG8g cmVtb3ZlIMKzbmV3wrIsIGJ1dCBkb2VzbsK5dCDCs2HCsiBzdGlsbCBzb3VuZCBiZXR0ZXIgdGhh biDCs3RoZcKyPw0KDQoNCj5zNS4xOiBTdWdnZXN0IHMvbS0gbGluZS8ibSIgbGluZS8gIGZvciBj b25zaXN0ZW5jeSB3aXRoIHMzLjQNCg0KSSB3aWxsIHJlcGxhY2Ugd2l0aCBzaW5nbGUgcXVvdGVz ICjFkm3CuSksIGZvciBjb25zaXN0ZW5jeSB3aXRoIHMzLjQgYW5kIHM0Lg0KDQoNCj5zNS4xLCBw YXJhIDE6IHMvZS5nLi9lLmcuLC8NCg0KSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQoNCg0KPnM1 LjEsIHBhcmEgNDogcy90aGF0IGVhY2ggdXNlZCBjZXJ0aWZpY2F0ZSBtYXRjaGVzL3RoYXQgZWFj aA0KPmNlcnRpZmljYXRlIHVzZWQgbWF0Y2hlcy8NCg0KSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQu DQoNCg0KPnM1LjEsIHBhcmEgNTogcy9lYWNoIHVzZWQgY2VydGlmaWNhdGUgbWF0Y2hlcy9lYWNo IGNlcnRpZmljYXRlIHVzZWQNCj5tYXRjaGVzLw0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4N Cg0KPnM4LCBwYXJhIDU6ICcgVGhpcyBzcGVjaWZpY2F0aW9uIGNyZWF0ZXMgYSBuZXcgSUFOQSBy ZWdpc3RyeSBuYW1lZA0KPiJIYXNoIEZ1bmN0aW9uIFRleHR1YWwgTmFtZXMiLicNCj5UaGUgcmVn aXN0cnkgaXMgbm8gbG9uZ2VyIG5ldy4gIFBlcmhhcHMgcy9jcmVhdGVzIGEgbmV3IElBTkENCj5y ZWdpc3RyeS90YWtlcyBvdmVyIHRoZSBJQU5BIHJlZ2lzdHJ5IGZyb20gUkZDIDQ1NzIvDQoNCkkg c3VnZ2VzdDoNCg0KIlRoaXMgc3BlY2lmaWNhdGlvbiB0YWtlcyBvdmVyIHRoZSBJQU5BIHJlZ2lz dHJ5IG5hbWVkICJIYXNoIEZ1bmN0aW9uDQpUZXh0dWFsIE5hbWVzwrIsIHRoYXQgd2FzIGNyZWF0 ZWQgaW4gUkZDIDQ1NzIuICBJdCB3aWxsIG5vdCBiZSBwYXJ0IG9mDQp0aGUgU0RQIFBhcmFtZXRl cnMuwrINCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFC08ACESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEVsd3lu LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1RoYXQn cyBhbGwgZmluZS4gJm5ic3A7UmUgczQsIHBhcmEgMjogRmlyc3QsIGkgcmVhbGlzZWQgSSBtaXNz ZWQgYW5vdGhlciBpbnN0YW5jZSBvZiAnbmV3JyBpbiB0aGUgYWJzdHJhY3QuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9z cGFuPkkgdGhpbmsgdGhhdCAndGhlJyBpcyBjb3JyZWN0IGluIHRoZSBuZXcgW3NpY10gdmVyc2lv biBpbiBib3RoIHBsYWNlcy4gJm5ic3A7SXQncyBwZXJuaWNrZXR5IGJ1dCB3aGVuIGl0IHdhcw0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDs8L3NwYW4+J2EgbmV3JyB3aGF0IHlvdSBoYXZlIGlzIHNob3J0aGFuZCBmb3IgJnF1b3Q7YSBu ZXcgcHJvdG9jb2wgaWRlbnRpZmllciB0byBiZSBjYWxsZWQgJ1RDUC9UTFMnLi4uJnF1b3Q7ICZu YnNwOyhhbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDs8L3NwYW4+YWRkaXRpb24gdG8gdGhlIGV4aXN0bmcgbGlzdCkgd2hlcmVhcyBi ZWNhdXNlIHRoZSBpZGVudGlmaWVyIGlzIG5vIGxvbmdlciBuZXcgd2Ugbm93IGhhdmUgJnF1b3Q7 dGhlIHByb3RvY29sDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj5pZGVudGlmaWVyIFtuYW1lZF0gJ1RDUC9UTFMnLi4uJnF1 b3Q7LiAmbmJzcDsmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5NeSBzdWdnZXN0aW9uIHdh cyB0byBkcm9wIOKAnG5ld+KAnSwgYnV0IHRvIGtlZXAg4oCcYeKAnTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcYSBwcm90b2NvbCBpZGVudGlmaWVyLCAnVENQ L1RMUycsIHdoaWNo4oCm4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCwgSeKAmW0gZmluZSB1c2luZyDi gJx0aGXigJ0gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hyaXN0 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6IzU3NTc1NyI+U2VudCBmcm9t IFNhbXN1bmcgdGFibGV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5Gcm9tOiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tPC9hPiZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RGF0ZTogMjUvMDEvMjAx NyAxMzo0MCAoR01UJiM0MzswMDowMCkNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG86 IEVsd3luIERhdmllcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVsd3luZEBkaWFsLnBpcGV4LmNvbSI+ ZWx3eW5kQGRpYWwucGlwZXguY29tPC9hPiZndDssDQo8YSBocmVmPSJtYWlsdG86Z2VuLWFydEBp ZXRmLm9yZyI+Z2VuLWFydEBpZXRmLm9yZzwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5DYzogPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbW11c2ljLTQ1NzItdXBkYXRlLmFsbEBp ZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW1tdXNpYy00NTcyLXVwZGF0ZS5hbGxAaWV0Zi5vcmc8L2E+ LCA8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBpZXRmLm9yZzwvYT4sDQo8YSBo cmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+U3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLW1t dXNpYy00NTcyLXVwZGF0ZS0xMQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBFbHd5biw8YnI+DQo8YnI+DQpUaGFu a3MgZm9yIHlvdXIgcmV2aWV3ISBTZWUgaW5saW5lLjxicj4NCjxicj4NCk5pdHMvZWRpdG9yaWFs IGNvbW1lbnRzOjxicj4NCjxicj4NCiZndDtzMSwgcGFyYSAyOiBzL1RMUyBwcm90b2NvbC9UaGUg VExTIHByb3RvY29sLyAoYXMgcGVyIFJGQyA0NTcyKTxicj4NCjxicj4NCkkgd2lsbCBmaXggYXMg c3VnZ2VzdGVkLjxicj4NCjxicj4NCjxicj4NCiZndDtzNCwgcGFyYSAyOiBzL2EgbmV3IHByb3Rv Y29sIGlkZW50aWZpZXIvdGhlIHByb3RvY29sIGlkZW50aWZpZXIvIChpdDxicj4NCiZndDtpc24n dCBuZXcgYW55IG1vcmUpPGJyPg0KPGJyPg0KSSBhbSBoYXBweSB0byByZW1vdmUgwrNuZXfCsiwg YnV0IGRvZXNuwrl0IMKzYcKyIHN0aWxsIHNvdW5kIGJldHRlciB0aGFuIMKzdGhlwrI/PGJyPg0K PGJyPg0KPGJyPg0KJmd0O3M1LjE6IFN1Z2dlc3Qgcy9tLSBsaW5lLyZxdW90O20mcXVvdDsgbGlu ZS8mbmJzcDsgZm9yIGNvbnNpc3RlbmN5IHdpdGggczMuNDxicj4NCjxicj4NCkkgd2lsbCByZXBs YWNlIHdpdGggc2luZ2xlIHF1b3RlcyAoxZJtwrkpLCBmb3IgY29uc2lzdGVuY3kgd2l0aCBzMy40 IGFuZCBzNC48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7czUuMSwgcGFyYSAxOiBzL2UuZy4vZS5nLiwv PGJyPg0KPGJyPg0KSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0 O3M1LjEsIHBhcmEgNDogcy90aGF0IGVhY2ggdXNlZCBjZXJ0aWZpY2F0ZSBtYXRjaGVzL3RoYXQg ZWFjaDxicj4NCiZndDtjZXJ0aWZpY2F0ZSB1c2VkIG1hdGNoZXMvPGJyPg0KPGJyPg0KSSB3aWxs IGZpeCBhcyBzdWdnZXN0ZWQuPGJyPg0KPGJyPg0KPGJyPg0KJmd0O3M1LjEsIHBhcmEgNTogcy9l YWNoIHVzZWQgY2VydGlmaWNhdGUgbWF0Y2hlcy9lYWNoIGNlcnRpZmljYXRlIHVzZWQ8YnI+DQom Z3Q7bWF0Y2hlcy88YnI+DQo8YnI+DQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC48YnI+DQo8YnI+ DQomZ3Q7czgsIHBhcmEgNTogJyBUaGlzIHNwZWNpZmljYXRpb24gY3JlYXRlcyBhIG5ldyBJQU5B IHJlZ2lzdHJ5IG5hbWVkPGJyPg0KJmd0OyZxdW90O0hhc2ggRnVuY3Rpb24gVGV4dHVhbCBOYW1l cyZxdW90Oy4nPGJyPg0KJmd0O1RoZSByZWdpc3RyeSBpcyBubyBsb25nZXIgbmV3LiZuYnNwOyBQ ZXJoYXBzIHMvY3JlYXRlcyBhIG5ldyBJQU5BPGJyPg0KJmd0O3JlZ2lzdHJ5L3Rha2VzIG92ZXIg dGhlIElBTkEgcmVnaXN0cnkgZnJvbSBSRkMgNDU3Mi88YnI+DQo8YnI+DQpJIHN1Z2dlc3Q6PGJy Pg0KPGJyPg0KJnF1b3Q7VGhpcyBzcGVjaWZpY2F0aW9uIHRha2VzIG92ZXIgdGhlIElBTkEgcmVn aXN0cnkgbmFtZWQgJnF1b3Q7SGFzaCBGdW5jdGlvbjxicj4NClRleHR1YWwgTmFtZXPCsiwgdGhh dCB3YXMgY3JlYXRlZCBpbiBSRkMgNDU3Mi4mbmJzcDsgSXQgd2lsbCBub3QgYmUgcGFydCBvZjxi cj4NCnRoZSBTRFAgUGFyYW1ldGVycy7Csjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0K PGJyPg0KQ2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFC08ACESESSMB209erics_-- From nobody Wed Jan 25 11:12: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 B636A129AF8 for ; Wed, 25 Jan 2017 11:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 PjbeEI2CFpQZ for ; Wed, 25 Jan 2017 11:12:40 -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 93D06129AF7 for ; Wed, 25 Jan 2017 11:12:40 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-07v.sys.comcast.net with SMTP id WSzIc7wUkj8tqWSznciyVd; Wed, 25 Jan 2017 19:12:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485371559; bh=6tUFS7I7O4mzZ0NtebYPkxEOS31bKAO8QDTjtUVwD/s=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Mi7OHFXykp7k+yNs8qlEkGBEswOyuM8QpYUNMD9BkjPpIt8ge/f9xJBVpcGjZp/2f LmzD8/FJhkRojS91/xSryTcHSm5wwm+qEKhsPR13s9Knn8t5fJxrWgWM7JUP22HUqP YP1wsfA31lJLPJS6feu4rG6FNxcg31UXHUEvZNm4M4wivzA10/mdzWfGi4TeOs8ujs bmgj4TujquOSxwnYCIFtfYIh3DWb2DIrvEsGV7dcHxFZ0Eh4QQKgrklM3wB1UOOpT4 UbUpUPND+m3LDJER1ULEqngUafAj2EqGwjYrzXHg3+N6BxcGJTaPn89sg5J1P7Zm1Q de/aNY7EfiMOg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-09v.sys.comcast.net with SMTP id WSzncNYmbxFqGWSzncf6vU; Wed, 25 Jan 2017 19:12:39 +0000 To: Christer Holmberg , Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> Date: Wed, 25 Jan 2017 14:12:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfE5sC7cXQp5798eARgzrV7UC7CV+ehjSriQYw6uVP6wjQzbMOs9fqiE/WjI9wDdlY3EvhR9yauWh5CVGbJUwlVm/phXn+5Z/7zc+uyjBY3Y8HqkrgOnP r1igsrt8+TSBOmjMv7Q5GjR+DB+LxPcSu2lRencGnD99L6vDyCMycNGMI1u/2Xq2Rmkvt6Q+cXKRsmcnDHQ9kVVxlDMsq6ZZ07bsNxlISsbl4i3Kh3lT7zTb 8CW3x42YcG4s9bwJFgH7ww== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 19:12:42 -0000 On 1/25/17 1:18 PM, Christer Holmberg wrote: > No. Let's not start making things complicated again. The document is in good shape in my opinion. Let's publish it. > > Keep in mind that nothing prevents an endpoint from closing/re-opening an SCTP association at any time. All we are saying is that a DTLS change does not automatically affect the SCTP association. I agree that if an endpoint explicitly initiates the closing of an SCTP association, and the other end acknowledges that, they can then establish a new association. (IIUC it would take another O/A to trigger establishing the new one.) But it requires one of the endpoints to know that this is needed. Lets consider a 3pcc scenario, where A is in call with B via controller P, where P isn't proxying the media. Now suppose P wants to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward the resulting offer from A to C. In this case C can't resume the SCTP association that A has with B. But A doesn't know that a new association is needed. How can P resolve this? Thanks, Paul From nobody Wed Jan 25 11:54: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 32B90129B80 for ; Wed, 25 Jan 2017 11:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 m5F3O-L-Xoia for ; Wed, 25 Jan 2017 11:54:01 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 5F9F0129B86 for ; Wed, 25 Jan 2017 11:54:01 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so35616638qtb.0 for ; Wed, 25 Jan 2017 11:54:01 -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=H0ejECpGuTrEmevLdZv5gQFvfuGF8XhaZryZ7h23nag=; b=ZLjlE2pYl/EApM2Y/JxPSwotfS2zPMoE/G+xVNivfwl3m0OiFCTetzqEG2Abq1UaOD toJCrAhtXRbV1I8woBkeBceFScSFJWqnxhSxTu2y6reGRHz64KljATl2WnY9ZD7VdEWL hvHBl1EqpQmnXnpSynZkNMSzxHdvyWmpAepU5QMbLghezsHe5+yTCklZfQp7KhAkmDXB 5g3L71GlHOVFPGE2/6Na3WxGAm4gld2zew/NM7V3H33o46ETdaO4Ze2fL9OEqzvtC5au uvpEX06IS9btI4cjqr1YWbkraVZ6CP7rmO0i+zlWwBnuUghj0r4cDGHj3JdlU6KnlDFq 0EOA== 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=H0ejECpGuTrEmevLdZv5gQFvfuGF8XhaZryZ7h23nag=; b=TygTC/eDKPqweyDtyiDetuMa4HLONVAy1rXzjGpSpzzlTNiffXCo08L3S2vYtelA++ tnKcZWuGFphEkg2U9oSTK6aAynCct/I9I8xUD+8YVfiRcbceT+ofFL5aMXMgwwq1MyHM i5TjaILa+GaNHZZ2ChtUIsxOvMFi47+kKqk1vLVCmFQVjFeP14yvbFgBq1bc0JZ8dfPW zGNlMhgA3/IWNKvn+T7MpjW1zE37SWodkU4Eep7Lscs60KiT7ryFHc1m0KHNhAzB2OHg /ues8IkvHmgf4NsSWHlGxIllrL/deSvRj3+G2/PKuv+bW8HFERRpZfqnXUw29c/YdGyw BGqA== X-Gm-Message-State: AIkVDXLg2SnhBMg0ndsGRz5cL/WTCd08JA00WzH2WmnmK9PsScVsPlBPAIE0zdfAUsmakQ== X-Received: by 10.237.38.3 with SMTP id z3mr34700540qtc.22.1485374040459; Wed, 25 Jan 2017 11:54:00 -0800 (PST) Received: from mail-qt0-f175.google.com (mail-qt0-f175.google.com. [209.85.216.175]) by smtp.gmail.com with ESMTPSA id 7sm1189754qkx.49.2017.01.25.11.53.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:53:59 -0800 (PST) Received: by mail-qt0-f175.google.com with SMTP id v23so35615796qtb.0 for ; Wed, 25 Jan 2017 11:53:59 -0800 (PST) X-Received: by 10.55.184.3 with SMTP id i3mr32056534qkf.234.1485374039580; Wed, 25 Jan 2017 11:53:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Wed, 25 Jan 2017 11:53:59 -0800 (PST) In-Reply-To: <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> From: Roman Shpount Date: Wed, 25 Jan 2017 14:53:59 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=94eb2c05d26afd07070546f097f2 Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 19:54:06 -0000 --94eb2c05d26afd07070546f097f2 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 25, 2017 at 2:12 PM, Paul Kyzivat wrote: > On 1/25/17 1:18 PM, Christer Holmberg wrote: > > No. Let's not start making things complicated again. The document is in >> good shape in my opinion. Let's publish it. >> >> Keep in mind that nothing prevents an endpoint from closing/re-opening an >> SCTP association at any time. All we are saying is that a DTLS change does >> not automatically affect the SCTP association. >> > > I agree that if an endpoint explicitly initiates the closing of an SCTP > association, and the other end acknowledges that, they can then establish a > new association. (IIUC it would take another O/A to trigger establishing > the new one.) But it requires one of the endpoints to know that this is > needed. > > Lets consider a 3pcc scenario, where A is in call with B via controller P, > where P isn't proxying the media. Now suppose P wants to transfer the call, > replacing B with C. Typically it will do this by sending an offerless > invite to A, and then forward the resulting offer from A to C. > > In this case C can't resume the SCTP association that A has with B. But A > doesn't know that a new association is needed. > > How can P resolve this? > The assumption is that C will allocate a random sctp-port value. Since this value is different then the sctp-port value previously allocated by B, A will know this is a new SCTP association. C had no SCTP association, so it will start new SCTP association as well. The only issue here is that C accidentally allocates the same value as it was previously allocated by B. We have 1/65,535 chance of this happening. My question is: do you think the probably of collision is high enough that this needs to be fixed? For comparison, SIP to-tag which faces the same potential for collision (SIP call forks and ends up on two end points. Bad things happen if both terminating end points pick the same to-tag) and requires at least 32 bit of crypto randomness. Regards, _____________ Roman Shpount --94eb2c05d26afd07070546f097f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 25, 2017 at 2:12 PM, Paul Kyzivat <paul.kyzivat@comcast.net= > wrote:
On 1/25/17 1:18 PM, Christer = Holmberg wrote:

No. Let's not start making things complicated again. The document is in= good shape in my opinion. Let's publish it.

Keep in mind that nothing prevents an endpoint from closing/re-opening an S= CTP association at any time. All we are saying is that a DTLS change does n= ot automatically affect the SCTP association.

 I agree that if an endpoint explicitly initiates the closing of an SCTP ass= ociation, and the other end acknowledges that, they can then establish a ne= w association. (IIUC it would take another O/A to trigger establishing the = new one.) But it requires one of the endpoints to know that this is needed.=

Lets consider a 3pcc scenario, where A is in call with B via controller P, = where P isn't proxying the media. Now suppose P wants to transfer the c= all, replacing B with C. Typically it will do this by sending an offerless = invite to A, and then forward the resulting offer from A to C.

In this case C can't resume the SCTP association that A has with B. But= A doesn't know that a new association is needed.

How can P resolve this?

The assumption = is that C will allocate a random sctp-port value. Since this value is diffe= rent then the sctp-port value previously allocated by B, A will know this i= s a new SCTP association. C had no SCTP association, so it will start new S= CTP association as well. The only issue here is that C accidentally allocat= es the same value as it was previously allocated by B. We have 1/65,535 cha= nce of this happening.=C2=A0

My question is: do yo= u think the probably of collision is high enough that this needs to be fixe= d?

For comparison, SIP to-tag which faces the same= potential for collision (SIP call forks and ends up on two end points. Bad= things happen if both terminating end points pick the same to-tag) and req= uires at least 32 bit of crypto randomness.

Regard= s,
_____________
Roman Shpount
=C2=A0
--94eb2c05d26afd07070546f097f2-- From nobody Wed Jan 25 11:54:48 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 E446C129B87 for ; Wed, 25 Jan 2017 11:54:40 -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 QYKofMv4L0xr for ; Wed, 25 Jan 2017 11:54:38 -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 190CF129B80 for ; Wed, 25 Jan 2017 11:54:37 -0800 (PST) X-AuditID: c1b4fb30-d53ff70000007085-03-5889027b5c0f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 8A.5A.28805.B7209885; Wed, 25 Jan 2017 20:54:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 20:54:34 +0100 From: Christer Holmberg To: Paul Kyzivat , Roman Shpount Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJwAAANOgAAAlpGEA== Date: Wed, 25 Jan 2017 19:54:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> In-Reply-To: <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbHdT7eGqTPC4MJpOYupyx+zWDz40ctm MePCVGYHZo/Jj+cweixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MqdMXMRW84q3Ye/0nUwPj Ht4uRk4OCQETiQOfDrKD2EIC6xglDs0L72LkArIXM0os7Z3N3MXIwcEmYCHR/U8bxBQR8JO4 t7YMxGQWUJe4ujgIpFNYIFri0NvLjCC2iECMxNk9i5kg7CyJXef3gk1nEVCVWPPuMVicV8BX 4t+kvUwQm3axSJzacp4NJMEpYC9xdMlOsEGMAmIS30+tAWtgFhCXuPVkPhPEyQISS/acZ4aw RSVePv7HCmErSazYfokR4jZNifW79CFaFSWmdD9kh9grKHFy5hOWCYyis5BMnYXQMQtJxywk HQsYWVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbMwS2/DXYwvnzueIhRgINRiYe3YG9H hBBrYllxZe4hRgkOZiUR3pN/gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1O TS1ILYLJMnFwSjUwLrp5Voxt3YHmk6cP/Pqgfo7ty+4DMecvnTnw8ub/KxPsF2bMrJzw57Dh UavzT6tP5P9r+vZ9CSNDudSrz3fWM26QnKvjUl53/jTH049T7usv1GErMvixaM18JS2DO9d0 7nC+mGr+M8bM7ue6al/7J8oKRzwWP/LwXMtakMVgsPVCzbPq/CiWihNKLMUZiYZazEXFiQAF AS3NlAIAAA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 19:54:41 -0000 SGksDQoNCj4+IE5vLiBMZXQncyBub3Qgc3RhcnQgbWFraW5nIHRoaW5ncyBjb21wbGljYXRlZCBh Z2Fpbi4gVGhlIGRvY3VtZW50IGlzIGluIGdvb2Qgc2hhcGUgaW4gbXkgb3Bpbmlvbi4gTGV0J3Mg cHVibGlzaCBpdC4NCj4+DQo+PiBLZWVwIGluIG1pbmQgdGhhdCBub3RoaW5nIHByZXZlbnRzIGFu IGVuZHBvaW50IGZyb20gY2xvc2luZy9yZS1vcGVuaW5nIGFuIFNDVFAgYXNzb2NpYXRpb24gYXQg YW55IHRpbWUuIEFsbCANCj4+IHdlIGFyZSBzYXlpbmcgaXMgdGhhdCBhIERUTFMgY2hhbmdlIGRv ZXMgbm90IGF1dG9tYXRpY2FsbHkgYWZmZWN0IHRoZSBTQ1RQIGFzc29jaWF0aW9uLg0KPg0KPiBJ IGFncmVlIHRoYXQgaWYgYW4gZW5kcG9pbnQgZXhwbGljaXRseSBpbml0aWF0ZXMgdGhlIGNsb3Np bmcgb2YgYW4gU0NUUCBhc3NvY2lhdGlvbiwgYW5kIHRoZSBvdGhlciBlbmQgYWNrbm93bGVkZ2Vz IHRoYXQsIA0KPiB0aGV5IGNhbiB0aGVuIGVzdGFibGlzaCBhIG5ldyBhc3NvY2lhdGlvbi4gKElJ VUMgaXQgd291bGQgdGFrZSBhbm90aGVyIE8vQSB0byB0cmlnZ2VyIGVzdGFibGlzaGluZyB0aGUg bmV3IG9uZS4pIEJ1dCBpdCANCj4gcmVxdWlyZXMgb25lIG9mIHRoZSBlbmRwb2ludHMgdG8ga25v dyB0aGF0IHRoaXMgaXMgbmVlZGVkLg0KPg0KPiBMZXRzIGNvbnNpZGVyIGEgM3BjYyBzY2VuYXJp bywgd2hlcmUgQSBpcyBpbiBjYWxsIHdpdGggQiB2aWEgY29udHJvbGxlciBQLCB3aGVyZSBQIGlz bid0IHByb3h5aW5nIHRoZSBtZWRpYS4gTm93IHN1cHBvc2UgUCANCj4gd2FudHMgdG8gdHJhbnNm ZXIgdGhlIGNhbGwsIHJlcGxhY2luZyBCIHdpdGggQy4gVHlwaWNhbGx5IGl0IHdpbGwgZG8gdGhp cyBieSBzZW5kaW5nIGFuIG9mZmVybGVzcyBpbnZpdGUgdG8gQSwgYW5kIHRoZW4gZm9yd2FyZCAN Cj4gdGhlIHJlc3VsdGluZyBvZmZlciBmcm9tIEEgdG8gQy4NCj4NCj4gSW4gdGhpcyBjYXNlIEMg Y2FuJ3QgcmVzdW1lIHRoZSBTQ1RQIGFzc29jaWF0aW9uIHRoYXQgQSBoYXMgd2l0aCBCLiBCdXQg QSBkb2Vzbid0IGtub3cgdGhhdCBhIG5ldyBhc3NvY2lhdGlvbiBpcyBuZWVkZWQuDQoNCkFzc3Vt aW5nIEIgdGVybWluYXRlcyB0aGUgU0NUUCBhc3NvY2lhdGlvbiB3aXRoIEEgd2hlbiB0aGUgdHJh bnNmZXIgb2NjdXJzLCBBIHdpbGwga25vdy4NCg0KQnV0LCBpbiBhbnkgY2FzZSwgd2hlbiBDIGdl dHMgdGhlIG9mZmVyLCBpdCB3aWxsIHRyeSB0byBlc3RhYmxpc2ggYW4gU0NUUCBhc3NvY2lhdGlv biB3aXRoIEEuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Wed Jan 25 12:09: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 43BE8129BAE for ; Wed, 25 Jan 2017 12:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 fOZEUOHylUhq for ; Wed, 25 Jan 2017 12:08:41 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (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 64A0F129BAA for ; Wed, 25 Jan 2017 12:08:41 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-01v.sys.comcast.net with SMTP id WTpgcsTk5qjBEWTs0c0iJM; Wed, 25 Jan 2017 20:08:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485374920; bh=nQwA+nonLlePhTWEOCr9uUg5FCzZMQCHabcGISjGEaw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=SeqQDP4ZRYolmGo0CrtULNsuF/ZZ9kVjGDPyY2RSJG5ZjOc5njrjOyzZceVUW4Zps LrUTgSZaotJps2MlesKon0CGp5vmEwgE2ahYmQhI1mRRdkNoV2iBdKE2EWWHxcPb1B cvi1B8ehh74DbCvGyfheFiGOdZ/HswokMTrp7SXg1/Wc/7vTbzqQMvrsFW9yMD7dAw 10RZKE/CWAMtODJ9RUqqgd1o6VWRvRL1u76Zcx2mF/0TRY60zWyFxkth+i82B0R6Fd s6exA3KkExVSVYNMfq0WAuz3L7TIQnpYXDa4stW8HaZa5xYktZ6U7oSK7jbj/UXaBe 60xF+nQ+UshvA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-18v.sys.comcast.net with SMTP id WTrycb7hh9HUeWTrzc4QCD; Wed, 25 Jan 2017 20:08:40 +0000 To: Roman Shpount References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> From: Paul Kyzivat Message-ID: Date: Wed, 25 Jan 2017 15:08:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfDC1vQxcY2/pSCzv0tw7ubmFjq/ouYe7IWJ5ptT7OOdwoAnHdVZ8ihYPTP7YsxP4uSoxmg6mhG26WW3E6Db2kFveckCnA6xrJQYgZvA4CUAOkuxd/IjP qLdEGH5Fpj5xzhGfbTBuigB/0y5eFKY/ADK8viTevefNo8CWfCikCqvAXlY9dv0nzuWzwaTOEOBB0JmWeqROwu+6X85g+6Y4BygtwMMWOMMFYvmb3ihnO2QJ 6Uhxh3S32Tx0b2FxCLJ5Ng== Archived-At: Cc: "mmusic@ietf.org" , Christer Holmberg Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:08:59 -0000 On 1/25/17 2:53 PM, Roman Shpount wrote: > On Wed, Jan 25, 2017 at 2:12 PM, Paul Kyzivat > wrote: > > On 1/25/17 1:18 PM, Christer Holmberg wrote: > > No. Let's not start making things complicated again. The > document is in good shape in my opinion. Let's publish it. > > Keep in mind that nothing prevents an endpoint from > closing/re-opening an SCTP association at any time. All we are > saying is that a DTLS change does not automatically affect the > SCTP association. > > > I agree that if an endpoint explicitly initiates the closing of an > SCTP association, and the other end acknowledges that, they can then > establish a new association. (IIUC it would take another O/A to > trigger establishing the new one.) But it requires one of the > endpoints to know that this is needed. > > Lets consider a 3pcc scenario, where A is in call with B via > controller P, where P isn't proxying the media. Now suppose P wants > to transfer the call, replacing B with C. Typically it will do this > by sending an offerless invite to A, and then forward the resulting > offer from A to C. > > In this case C can't resume the SCTP association that A has with B. > But A doesn't know that a new association is needed. > > How can P resolve this? > > > The assumption is that C will allocate a random sctp-port value. Since > this value is different then the sctp-port value previously allocated by > B, A will know this is a new SCTP association. C had no SCTP > association, so it will start new SCTP association as well. The only > issue here is that C accidentally allocates the same value as it was > previously allocated by B. We have 1/65,535 chance of this happening. > > My question is: do you think the probably of collision is high enough > that this needs to be fixed? The chances are 1 in 2^16. That is high enough that it will happen regularly. Not everyone will encounter it, but there will be complaints - software will be accused of being "buggy". It is hard to guess how objectionable this will be without digging deeper into what the implications will be. If the error is handled gracefully then it might not be a problem. I can't judge at the moment whether it will be straightforward to handle this gracefully. Thanks, Paul > For comparison, SIP to-tag which faces the same potential for collision > (SIP call forks and ends up on two end points. Bad things happen if both > terminating end points pick the same to-tag) and requires at least 32 > bit of crypto randomness. > > Regards, > _____________ > Roman Shpount > From nobody Wed Jan 25 12:11:48 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 AA4F4129B8E for ; Wed, 25 Jan 2017 12:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 Sk1Uss6w2lp3 for ; Wed, 25 Jan 2017 12:11:42 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 4C575129B8B for ; Wed, 25 Jan 2017 12:11:42 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so36354426qtc.2 for ; Wed, 25 Jan 2017 12:11:42 -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=/ohMCxhcN1U0o6LLE2hOnW9R8/EcHPXd+SIOnJBf0cc=; b=AX3LjpWlB4PUhQbpt+OzQ1wq+oURPP8D9Jfg+IGUqvrgflAl44opQmtJrVAmADfd+O DMs4z7/jejEymVIt7spXwnR6mXmto9GB8IIq0I9pKENkmxFbY+D5ZvxJiSuC/q6m0g1H VKK0dmuOVNbDlBSUnnwAcXI5St9Ysi8WYuDNMYiWyODtlJSz8RTFvgEFRaFkpMbzZdcK NLuxWVA3lYczmbGTtyJqXluK+0rSsFU4GqyD9ZpfUfXRFzYWcuvUzSyPoGYr6WqGn5SZ LRp1FOKCiZNyBpjj8K8U5MMm6skagzEBcMtDpvA70iPtLv6CXuF6JHA5IGobcuHXvdJr tgAg== 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=/ohMCxhcN1U0o6LLE2hOnW9R8/EcHPXd+SIOnJBf0cc=; b=MpRye4KhWAwsH3BJdfyoIE/W5SuEEwRWWangEFPTMGCI69OnpIsn44Hw+Ep4GZCwBh 42f0WyzQl41eedzceAd4J+qWIBNF4yXbiip0FuoTcJQ6U2DZRLAwxmNUbbFdr47XcTva MY+5c6I+lxIsh0kLbVmkvRnSUNpdSlox8GuaxUw0QRuAKYa2996ZKcrJ4agsh1cHVNbt t/J2sN0gLJiLYwRNjFZFMQpwnLnNRngFfWWUE463LXuZFsSr6JFmURaDmom042uriZYX mZuv8TZXVEZ8E4SPutytrV158mEro+lie+HgKW/IW3QcXVLhRQ0emtVvbUSMC93ftNOO L0qA== X-Gm-Message-State: AIkVDXKwDv0oMEOavliXcQK00nu3+KUI5pJptF/XvwS4xdvvcDz0cM/zzSMvs2v/9xExIQ== X-Received: by 10.200.54.84 with SMTP id n20mr38809280qtb.79.1485375100680; Wed, 25 Jan 2017 12:11:40 -0800 (PST) Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com. [209.85.216.178]) by smtp.gmail.com with ESMTPSA id q145sm1148042qke.37.2017.01.25.12.11.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 12:11:40 -0800 (PST) Received: by mail-qt0-f178.google.com with SMTP id v23so36542270qtb.0 for ; Wed, 25 Jan 2017 12:11:40 -0800 (PST) X-Received: by 10.237.47.33 with SMTP id l30mr37240740qtd.62.1485375100063; Wed, 25 Jan 2017 12:11:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Wed, 25 Jan 2017 12:11:39 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 25 Jan 2017 15:11:39 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c12524632b9380546f0d7ba Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:11:47 -0000 --94eb2c12524632b9380546f0d7ba Content-Type: text/plain; charset=UTF-8 On Wed, Jan 25, 2017 at 2:54 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >> No. Let's not start making things complicated again. The document is in > good shape in my opinion. Let's publish it. > >> > >> Keep in mind that nothing prevents an endpoint from closing/re-opening > an SCTP association at any time. All > >> we are saying is that a DTLS change does not automatically affect the > SCTP association. > > > > I agree that if an endpoint explicitly initiates the closing of an SCTP > association, and the other end acknowledges that, > > they can then establish a new association. (IIUC it would take another > O/A to trigger establishing the new one.) But it > > requires one of the endpoints to know that this is needed. > > > > Lets consider a 3pcc scenario, where A is in call with B via controller > P, where P isn't proxying the media. Now suppose P > > wants to transfer the call, replacing B with C. Typically it will do > this by sending an offerless invite to A, and then forward > > the resulting offer from A to C. > > > > In this case C can't resume the SCTP association that A has with B. But > A doesn't know that a new association is needed. > > Assuming B terminates the SCTP association with A when the transfer > occurs, A will know. > > But, in any case, when C gets the offer, it will try to establish an SCTP > association with A. > > It does not quite works like this. In the described case, P first establishes a session between A and B which has an SCTP session. Then P sends an INVITE without SDP to A. A has no indication if new SCTP association is needed, so it continues to use current SCTP association, and sends an offer in the response to INVITE with SDP which contains current sctp-port. P then sends the offer received from A to C. C had no SCTP association running at that point, so it allocates new random sctp-port, sends an answer to P and attempts to initiate an SCTP association with A. P sends that answer to A, and if sctp-port in the answer is different A, will know this is a new SCTP association and attempts to initiate an SCTP association with C. If there is a random collision, A will think this is the existing SCTP association, C will think this is a new SCTP association, things break. Regards, _____________ Roman Shpount --94eb2c12524632b9380546f0d7ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 25, 2017 at 2:54 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

>> No. Let's not start making things complicated again. The docum= ent is in good shape in my opinion. Let's publish it.
>>
>> Keep in mind that nothing prevents an endpoint from closing/re-ope= ning an SCTP association at any time. All
>> we are saying is that a DTLS change does not automatically affect = the SCTP association.
>
> I agree that if an endpoint explicitly initiates the closing of an SCT= P association, and the other end acknowledges that,
> they can then establish a new association. (IIUC it would take another= O/A to trigger establishing the new one.) But it
> requires one of the endpoints to know that this is needed.
>
> Lets consider a 3pcc scenario, where A is in call with B via controlle= r P, where P isn't proxying the media. Now suppose P
> wants to transfer the call, replacing B with C. Typically it will do t= his by sending an offerless invite to A, and then forward
> the resulting offer from A to C.
>
> In this case C can't resume the SCTP association that A has with B= . But A doesn't know that a new association is needed.

Assuming B terminates the SCTP association with A when the transfer = occurs, A will know.

But, in any case, when C gets the offer, it will try to establish an SCTP a= ssociation with A.


It does not quite works like this. In = the described case, P first establishes a session between A and B which has= an SCTP session. Then P sends an INVITE without SDP to A. A has no indicat= ion if new SCTP association is needed, so it continues to use current SCTP = association, and sends an offer in the response to INVITE with SDP which co= ntains current sctp-port. P then sends the offer received from A to C. C ha= d no SCTP association running at that point, so it allocates new random sct= p-port, sends an answer to P and attempts to initiate an SCTP association w= ith A. P sends that answer to A, and if sctp-port in the answer is differen= t A, will know this is a new SCTP association and attempts to initiate an S= CTP association with C. If there is a random collision, A will think this i= s the existing SCTP association, C will think this is a new SCTP associatio= n, things break.

Regards,
_____________
Roman Shpount
=C2=A0
--94eb2c12524632b9380546f0d7ba-- From nobody Wed Jan 25 12:13:37 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 CFDD2129B8B for ; Wed, 25 Jan 2017 12:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Zz3jI4zHTTi6 for ; Wed, 25 Jan 2017 12:13:17 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (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 EB0BD129B96 for ; Wed, 25 Jan 2017 12:13:09 -0800 (PST) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-12v.sys.comcast.net with SMTP id WTv5cSUQxezrFWTwLcJ2k8; Wed, 25 Jan 2017 20:13:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485375189; bh=01Z5YzvIWzi3U1TNfKLgwVCab69lR+tPCajGiQyLPso=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ueb5r6zfqdcniud/W+SnA8WVyolb4dW0Sb8y5F2fDlc8n4nSQ1ME/kmIRwXVMY85S TOUo2bQu2dXmo4U5EXKcd6aqYZ9xmKSjbUniMtx6Rl9RZsX+APLwoZ2c6l4DSXGeMj 2kogJpuVJhtYdTkxUJOR15NhqFaFD1Q719F3VJAzZIOLpGgBaFpmqtRqM9Tb5Tp8sX 9WMik35j/2UfAu3FLHDkJLeRKZD1GWmuCXkGhCjeCHOQ0gTRswv2qTzmw4SXeMwum6 jzyxNKb87lt8lyCNw1YleymzvW66DbuXtSpk/jry8gprLMi+cbsPVaKOXjLBPHBeYW sYOXukP9XWClQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-19v.sys.comcast.net with SMTP id WTwKc2g14YZITWTwLcpzBA; Wed, 25 Jan 2017 20:13:09 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> Date: Wed, 25 Jan 2017 15:13:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfF9SBMq2ntwQqrc9BFQ2FshO+XJWiIISsWbwXXJkM/kGEJey9Ol/pg1TLHX94MEMq5Lt/0Eqi2UHjKtAUfmCVd/ZFfhHNMBiYkSiSOF68xvU3wdDFIuH MnSyLv5okhLRHdUHUfHhf1R63+3YhIpzzW+G3o+1pJh6XAH39Mk0PqvEPOD9AE0OcB80MdtszdhI8A== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:13:23 -0000 On 1/25/17 2:54 PM, Christer Holmberg wrote: > Hi, > >>> No. Let's not start making things complicated again. The document is in good shape in my opinion. Let's publish it. >>> >>> Keep in mind that nothing prevents an endpoint from closing/re-opening an SCTP association at any time. All >>> we are saying is that a DTLS change does not automatically affect the SCTP association. >> >> I agree that if an endpoint explicitly initiates the closing of an SCTP association, and the other end acknowledges that, >> they can then establish a new association. (IIUC it would take another O/A to trigger establishing the new one.) But it >> requires one of the endpoints to know that this is needed. >> >> Lets consider a 3pcc scenario, where A is in call with B via controller P, where P isn't proxying the media. Now suppose P >> wants to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward >> the resulting offer from A to C. >> >> In this case C can't resume the SCTP association that A has with B. But A doesn't know that a new association is needed. > > Assuming B terminates the SCTP association with A when the transfer occurs, A will know. > > But, in any case, when C gets the offer, it will try to establish an SCTP association with A. I agree that C will try that. I haven't done any digging into the details of the SCTP protocol, but it seems like A and C will be working at cross purposes. C will be trying to establish a new association, while A is trying to re-establish the existing SCTP association over a new DTLS association. Maybe it will just all work out, but I'm inclined to doubt it. It would help to have a expert on the SCTP protocol chime in at this point. Thanks, Paul From nobody Wed Jan 25 12:21:45 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 ADF59129B91 for ; Wed, 25 Jan 2017 12:21:20 -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 CNcxtrAk1pFi for ; Wed, 25 Jan 2017 12:21:14 -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 55D29129B8B for ; Wed, 25 Jan 2017 12:21:14 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-78-588908b7380b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 20.90.16488.7B809885; Wed, 25 Jan 2017 21:21:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 21:21:11 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJwAAANOgAAAlpGEP///auA///tTLA= Date: Wed, 25 Jan 2017 20:21:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC0AC3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdUncHR2eEwc1eBYupyx+zWDz40ctm MePCVGYHZo/Jj+cweixZ8pPJ49aUggDmKC6blNSczLLUIn27BK6MJW+OMRacEqrYMyWhgbFH qIuRk0NCwETi7uTTzF2MXBxCAusYJdYfnsAC4SxmlPi14weQw8HBJmAh0f1PG6RBREBV4u/3 yUwgNrNAkMSp051sILawQLTEobeXGSFqYiTO7lnMBGGXSWx5+YYdxGYB6u19tBfM5hXwlfh3 8hHUrqOsEnf39DCB7OIUCJRYtgtsDqOAmMT3U2ugdolL3HoynwniaAGJJXvOM0PYohIvH/9j hbCVJFZsv8QIMoZZQFNi/S59iFZFiSndD6HWCkqcnPmEZQKj6CwkU2chdMxC0jELSccCRpZV jKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIExc3DLb6sdjAefOx5iFOBgVOLhLdjbESHEmlhW XJl7iFGCg1lJhLeeqTNCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalF MFkmDk6pBkYxTX9ml9M2y5fOi54Sb22x+1Dg2qDle9/lC8dd2c6wtmf6BDs5Edk10y/4y67O DVJ+oq8ie6Uv/hXnrtbfNa9WuTV69LVdmWF5YZv6r2VO3foXUl7/MOtvlHX2uSi49d6VvRqe jVeOtZdH+f/Rn1N8L7c39/vjpZX7j/+ddsH14LR/YYb/vigrsRRnJBpqMRcVJwIAa5EFRJUC AAA= Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:21:21 -0000 SGksDQoNCuKApi4NCg0KPj4+IExldHMgY29uc2lkZXIgYSAzcGNjIHNjZW5hcmlvLCB3aGVyZSBB IGlzIGluIGNhbGwgd2l0aCBCIHZpYSBjb250cm9sbGVyIFAsIHdoZXJlIFAgaXNuJ3QgcHJveHlp bmcgdGhlIG1lZGlhLiBOb3cgc3VwcG9zZSBQDQo+Pj4gd2FudHMgdG8gdHJhbnNmZXIgdGhlIGNh bGwsIHJlcGxhY2luZyBCIHdpdGggQy4gVHlwaWNhbGx5IGl0IHdpbGwgZG8gdGhpcyBieSBzZW5k aW5nIGFuIG9mZmVybGVzcyBpbnZpdGUgdG8gQSwgYW5kIHRoZW4gZm9yd2FyZA0KPj4+IHRoZSBy ZXN1bHRpbmcgb2ZmZXIgZnJvbSBBIHRvIEMuDQo+Pj4NCj4+PiBJbiB0aGlzIGNhc2UgQyBjYW4n dCByZXN1bWUgdGhlIFNDVFAgYXNzb2NpYXRpb24gdGhhdCBBIGhhcyB3aXRoIEIuIEJ1dCBBIGRv ZXNuJ3Qga25vdyB0aGF0IGEgbmV3IGFzc29jaWF0aW9uIGlzIG5lZWRlZC4NCj4+DQo+PiBBc3N1 bWluZyBCIHRlcm1pbmF0ZXMgdGhlIFNDVFAgYXNzb2NpYXRpb24gd2l0aCBBIHdoZW4gdGhlIHRy YW5zZmVyIG9jY3VycywgQSB3aWxsIGtub3cuDQo+Pg0KPj4gQnV0LCBpbiBhbnkgY2FzZSwgd2hl biBDIGdldHMgdGhlIG9mZmVyLCBpdCB3aWxsIHRyeSB0byBlc3RhYmxpc2ggYW4gU0NUUCBhc3Nv Y2lhdGlvbiB3aXRoIEEuDQo+DQo+IEl0IGRvZXMgbm90IHF1aXRlIHdvcmtzIGxpa2UgdGhpcy4g SW4gdGhlIGRlc2NyaWJlZCBjYXNlLCBQIGZpcnN0IGVzdGFibGlzaGVzIGEgc2Vzc2lvbiBiZXR3 ZWVuIEEgYW5kIEIgd2hpY2ggaGFzIGFuIFNDVFAgc2Vzc2lvbi4gVGhlbiBQIHNlbmRzIGFuIElO VklURSB3aXRob3V0IFNEUCB0byBBLiBBID4gaGFzIG5vIGluZGljYXRpb24gaWYgbmV3IFNDVFAg YXNzb2NpYXRpb24gaXMgbmVlZGVkLCBzbyBpdCBjb250aW51ZXMgdG8gdXNlIGN1cnJlbnQgU0NU UCBhc3NvY2lhdGlvbiwgYW5kIHNlbmRzIGFuIG9mZmVyIGluIHRoZSByZXNwb25zZSB0byBJTlZJ VEUgd2l0aCBTRFAgd2hpY2ggY29udGFpbnMgDQo+IGN1cnJlbnQgc2N0cC1wb3J0LiBQIHRoZW4g c2VuZHMgdGhlIG9mZmVyIHJlY2VpdmVkIGZyb20gQSB0byBDLiBDIGhhZCBubyBTQ1RQIGFzc29j aWF0aW9uIHJ1bm5pbmcgYXQgdGhhdCBwb2ludCwgc28gaXQgYWxsb2NhdGVzIG5ldyByYW5kb20g c2N0cC1wb3J0LCBzZW5kcyBhbiBhbnN3ZXIgdG8gUCA+IGFuZCBhdHRlbXB0cyB0byBpbml0aWF0 ZSBhbiBTQ1RQIGFzc29jaWF0aW9uIHdpdGggQS4gUCBzZW5kcyB0aGF0IGFuc3dlciB0byBBLCBh bmQgaWYgc2N0cC1wb3J0IGluIHRoZSBhbnN3ZXIgaXMgZGlmZmVyZW50IEEsIHdpbGwga25vdyB0 aGlzIGlzIGEgbmV3IFNDVFAgYXNzb2NpYXRpb24gYW5kIA0KPiBhdHRlbXB0cyB0byBpbml0aWF0 ZSBhbiBTQ1RQIGFzc29jaWF0aW9uIHdpdGggQy4gSWYgdGhlcmUgaXMgYSByYW5kb20gY29sbGlz aW9uLCBBIHdpbGwgdGhpbmsgdGhpcyBpcyB0aGUgZXhpc3RpbmcgU0NUUCBhc3NvY2lhdGlvbiwg QyB3aWxsIHRoaW5rIHRoaXMgaXMgYSBuZXcgU0NUUCBhc3NvY2lhdGlvbiwgDQo+IHRoaW5ncyBi cmVhay4NCg0KSSB0aGluayB3ZSBjYW4gYXNzdW1lIHRoYXQgdGhlIHZlcmlmaWNhdGlvbiB0YWcg ZnJvbSBDIHdpbGwgYmUgZGlmZmVyZW50LCBjYW4ndCB3ZT8gQSB3aWxsIGtub3cgdGhhdCB0aGUg SU5JVCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIGV4aXN0aW5nIFNDVFAgYXNzb2NpYXRpb24uDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== From nobody Wed Jan 25 12:24: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 4DB0D129BBC for ; Wed, 25 Jan 2017 12:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] 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 OXTS-LrgCx8K for ; Wed, 25 Jan 2017 12:24:15 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 D50D9129B8B for ; Wed, 25 Jan 2017 12:24:14 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k15so37345587qtg.3 for ; Wed, 25 Jan 2017 12:24:14 -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=Wf0U+8EMP5UsRyUESAqAE6muQzv6YgJkBeLgLRaOa9g=; b=vtc0M0zJqSSNzOO0Ruknhzu/OZmDBAiVALPlpCKLtduAi81idUyXzMVu6MW2qV/9Yw Cac5vztN2UCpFvICvi3IZV8nFdJf23TGM491CQ/Jyj6TmWe+50zvdKM+R2oct2YPJlxX 983RKn2BW4hG4dmhWBItIYyJgbPoEmh9P3Wak/+46Ecx6s1I+Oao9mFU5Hh5GzbzisVF RsSO5xjaFxMsZwmqAzt2szncKgBByWDA6eNLUdmPRpfrGW8Gpd3L9mM6ZggBHEXTjrjf g3DW2JuzaZ/u0LrDGBhfcopOUB8im1eanvvTvL3GkScH/WSRp1jDzVcjJuHLdF5nQVqF 06gg== 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=Wf0U+8EMP5UsRyUESAqAE6muQzv6YgJkBeLgLRaOa9g=; b=EY6/2WpO6Q8IQftLHU+Ql7BDoZjgiv1SiHYnPFJq6LPiKhnNiemEUPQPfBk/yolJNI izpt302VG83Ytjs9qyiEp6f2Wkg/qj9hQjAJC9bNMPOODcq7SHrB5c15d6UdGF4ZZHe3 8Ya86VZHMKF8aiC8Ln4wRWDD3R7jUmb2pP7Js2E2MZyki1rIrBrGhxAnhhWfq7ud/2kf HHW+KGNqjcSRs/Zzf/LDjsoXhVaXK5FyObvubyC7MaesNI7Up51MHvoocNJbA1nnxHy8 GC2SVA9Nar4CSMgSB2N+Mp3AqOJRdmQ+Ig8pe2G3EKzoHIZijJkxhbejoU1gZuNT39OM dAVg== X-Gm-Message-State: AIkVDXK1rgbxpmb39qrrH22WYqx54ve1roh/Im3eRRxxkEQQVhEdFW3CtFEvZmMhF8CVUg== X-Received: by 10.200.41.175 with SMTP id 44mr37695027qts.53.1485375853884; Wed, 25 Jan 2017 12:24:13 -0800 (PST) Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com. [209.85.216.179]) by smtp.gmail.com with ESMTPSA id 12sm12815809qtv.31.2017.01.25.12.24.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 12:24:13 -0800 (PST) Received: by mail-qt0-f179.google.com with SMTP id l7so37410635qtd.1 for ; Wed, 25 Jan 2017 12:24:13 -0800 (PST) X-Received: by 10.237.47.33 with SMTP id l30mr37285877qtd.62.1485375853367; Wed, 25 Jan 2017 12:24:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Wed, 25 Jan 2017 12:24:12 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC0AC3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC0AC3@ESESSMB209.ericsson.se> From: Roman Shpount Date: Wed, 25 Jan 2017 15:24:12 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c12524619177e0546f10400 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:24:17 -0000 --94eb2c12524619177e0546f10400 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 25, 2017 at 3:21 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>> Lets consider a 3pcc scenario, where A is in call with B via > controller P, where P isn't proxying the media. Now suppose P > >>> wants to transfer the call, replacing B with C. Typically it will do > this by sending an offerless invite to A, and then forward > >>> the resulting offer from A to C. > >>> > >>> In this case C can't resume the SCTP association that A has with B. > But A doesn't know that a new association is needed. > >> > >> Assuming B terminates the SCTP association with A when the transfer > occurs, A will know. > >> > >> But, in any case, when C gets the offer, it will try to establish an > SCTP association with A. > > > > It does not quite works like this. In the described case, P first > establishes a session between A and B which has an SCTP session. Then P > sends an INVITE without SDP to A. A > has no indication if new SCTP > association is needed, so it continues to use current SCTP association, and > sends an offer in the response to INVITE with SDP which contains > > current sctp-port. P then sends the offer received from A to C. C had no > SCTP association running at that point, so it allocates new random > sctp-port, sends an answer to P > and attempts to initiate an SCTP > association with A. P sends that answer to A, and if sctp-port in the > answer is different A, will know this is a new SCTP association and > > attempts to initiate an SCTP association with C. If there is a random > collision, A will think this is the existing SCTP association, C will think > this is a new SCTP association, > > things break. > > I think we can assume that the verification tag from C will be different, > can't we? A will know that the INIT does not belong to the existing SCTP > association. > Upon checking with https://tools.ietf.org/html/rfc4960#section-5.2 establishing a new connection from C to A even before B have closed the connection should work. I would like somebody to double check this, but I think we can proceed with the document as is. Regards, _____________ Roman Shpount --94eb2c12524619177e0546f10400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 25, 2017 at 3:21 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
>>> Lets consider a 3pcc scenario, where A is in ca= ll with B via controller P, where P isn't proxying the media. Now suppo= se P
>>> wants to transfer the call, replacing B with C. Typically it w= ill do this by sending an offerless invite to A, and then forward
>>> the resulting offer from A to C.
>>>
>>> In this case C can't resume the SCTP association that A ha= s with B. But A doesn't know that a new association is needed.
>>
>> Assuming B terminates the SCTP association with A when the transfe= r occurs, A will know.
>>
>> But, in any case, when C gets the offer, it will try to establish = an SCTP association with A.
>
> It does not quite works like this. In the described case, P first esta= blishes a session between A and B which has an SCTP session. Then P sends a= n INVITE without SDP to A. A > has no indication if new SCTP association= is needed, so it continues to use current SCTP association, and sends an o= ffer in the response to INVITE with SDP which contains
> current sctp-port. P then sends the offer received from A to C. C had = no SCTP association running at that point, so it allocates new random sctp-= port, sends an answer to P > and attempts to initiate an SCTP associatio= n with A. P sends that answer to A, and if sctp-port in the answer is diffe= rent A, will know this is a new SCTP association and
> attempts to initiate an SCTP association with C. If there is a random = collision, A will think this is the existing SCTP association, C will think= this is a new SCTP association,
> things break.

I think we can assume that the verification tag from C will be diffe= rent, can't we? A will know that the INIT does not belong to the existi= ng SCTP association.

Upon checking with= https://tools.= ietf.org/html/rfc4960#section-5.2 establishing a new connection from C = to A even before B have closed the connection should work.

I would like somebody to double check this, but I think we can pro= ceed with the document as is.

Regards,=C2=A0
=
_____________
Roman Shpount

--94eb2c12524619177e0546f10400-- From nobody Wed Jan 25 12:35: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 142ED129BC4 for ; Wed, 25 Jan 2017 12:35:19 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUdvqG0RDedE for ; Wed, 25 Jan 2017 12:35:18 -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 57508129BBF for ; Wed, 25 Jan 2017 12:26:23 -0800 (PST) X-AuditID: c1b4fb2d-a87ff70000007e3d-37-588909ecbc18 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id 73.C2.32317.CE909885; Wed, 25 Jan 2017 21:26:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Wed, 25 Jan 2017 21:26:20 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJwAAANOgAAAlpGEP///hUA///szeA= Date: Wed, 25 Jan 2017 20:26:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> In-Reply-To: <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7k+5bzs4Igy3dwhZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4+WIDY8ExwYrPP5IbGN/wdjFyckgImEic vfySEcQWEljHKDHvfk0XIxeQvZhR4uiDbUAJDg42AQuJ7n/aIDUiAkEScxu/MIHYwgLREofe XmaEiMdInN2zmAnCLpN4daWTGcRmEVCVaJ6+CCzOK+ArsfZOFxvE/M2sEh1tB1hAEpwC9hK3 eg+ygdiMAmIS30+tAWtgFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSazYfokRol5HYsHu T2wQtrbEsoWvmSEWC0qcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uLc9ONjPVSizKT i4vz8/TyUks2MQKj4eCW37o7GFe/djzEKMDBqMTDW7C3I0KINbGsuDL3EKMEB7OSCG89U2eE EG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYytPRtVbh02 /cKjOdEh0F/3Ub+H1HbVHzrb3ZlfKpRnv9dzDeW6cCP4gLVBTsCKTZffbzt/wMTdR+X+1ee3 Uvr3yvgW/2Rm8pz4rm2+wdSKTcU5obe3iEQfbKlN8O7xOmtd9tZ42yT27IVvFNbEqzZk9XR8 fhoTXhPetrYpY92+P90LLHdsTlJiKc5INNRiLipOBACHnSzrggIAAA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:35:19 -0000 Hi, >>>> No. Let's not start making things complicated again. The document is i= n good shape in my opinion. Let's publish it. >>>> >>>> Keep in mind that nothing prevents an endpoint from=20 >>>> closing/re-opening an SCTP association at any time. All we are saying = is that a DTLS change does not automatically affect the SCTP association. >>> >>> I agree that if an endpoint explicitly initiates the closing of an=20 >>> SCTP association, and the other end acknowledges that, they can then=20 >>> establish a new association. (IIUC it would take another O/A to trigger= establishing the new one.) But it requires one of the endpoints to know th= at this is needed. >>> >>> Lets consider a 3pcc scenario, where A is in call with B via=20 >>> controller P, where P isn't proxying the media. Now suppose P wants=20 >>> to transfer the call, replacing B with C. Typically it will do this by = sending an offerless invite to A, and then forward the resulting offer from= A to C. >>> >>> In this case C can't resume the SCTP association that A has with B. But= A doesn't know that a new association is needed. >> >> Assuming B terminates the SCTP association with A when the transfer occu= rs, A will know. >> >> But, in any case, when C gets the offer, it will try to establish an SCT= P association with A. > > I agree that C will try that. I haven't done any digging into the details= of the SCTP protocol, but it seems like A and C will be working at cross p= urposes. C will be trying to=20 > establish a new association, while A is trying to re-establish the existi= ng SCTP association over a new DTLS association. Maybe it will just all wor= k out, but I'm inclined to=20 > doubt it. > > It would help to have a expert on the SCTP protocol chime in at this poin= t. We also of course have to assume that A, when it receives the offerless inv= ite, creates an offer that represents the ongoing associations (including t= he currently used sctp-port value), and not a new one (if A offers a new sc= tp-port value, there won't be an issue, because the INIT from C will be rec= eived on that port). But, that is a general problem with 3pcc, not specific= to SCTP. Regards, Christer From nobody Wed Jan 25 12:55: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 04AF9129BDD for ; Wed, 25 Jan 2017 12:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 ZCSsRuAE-cfG for ; Wed, 25 Jan 2017 12:55:19 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 95741129BE4 for ; Wed, 25 Jan 2017 12:55:17 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-03v.sys.comcast.net with SMTP id WUascY0HEIMkuWUb6cFzEO; Wed, 25 Jan 2017 20:55:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485377716; bh=AE9xGtnWIC7msoPMTL2SBZ5zVwhmSk1Cmvsa68z2C90=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=nQfYgUEwXN+XgdikDdXRgw1riXYqOLg5VZl4hbyHQovYTEmSMfxD3rkuZOJinISHQ GFOOsXcXvVukp+CLQeJYChroOzFrj77pfQ96pVxFxa8L6PTeaOQBKxoxJ6oZ3Ku0Dv aOe7ESH2jsaDT0MjE/Kofp+BnWtwpXNONtOMBNjbXz9i7fljt09nzN1D/xI2PYV3BZ TOmQNFol2dab7b+NsI8cot52/tEDj9mqBNTVWnhLyoDKt1VbKNZIe9YwAaVMUFk4jS M4qFNr7f5D7EtnPOHa4m5+2G3RJtN9umhGSMKQudD0WqfHsL5r4ZQjef1xzFRaf02l zUsH3wFO7NzxA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-16v.sys.comcast.net with SMTP id WUb5cKZfZKTTaWUb5c1gyS; Wed, 25 Jan 2017 20:55:16 +0000 To: Roman Shpount , Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC0AC3@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <36c0c979-4950-1372-924a-12c5692338a7@comcast.net> Date: Wed, 25 Jan 2017 15:55:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNaM9cMZpkj8QFHgynQ93Nf0zi/KKDU3s9dky/4wwKos1M/XgQcYnbqVPs7JOHCsV76QOibBuzXF5fh+CmoEXXegk/4LZ0poOL7fkwoxEX5MRggsg/FL cZHE4aQyWBAZIqMtYQRFrZAiBdJII+rB02bFt4asiRZ7vEAEBHriWM2loJGqXgMY3iybhrVhYUSdxJvf1rUnG3Km5mlKSxHncaCsYViQeQvE/w8FUJ/qkD4E 1pzm9GSVVn948vwSJfibcA== Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:55:27 -0000 On 1/25/17 3:24 PM, Roman Shpount wrote: > On Wed, Jan 25, 2017 at 3:21 PM, Christer Holmberg > > > wrote: > > >>> Lets consider a 3pcc scenario, where A is in call with B via controller P, where P isn't proxying the media. Now suppose P > >>> wants to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward > >>> the resulting offer from A to C. > >>> > >>> In this case C can't resume the SCTP association that A has with B. But A doesn't know that a new association is needed. > >> > >> Assuming B terminates the SCTP association with A when the transfer occurs, A will know. > >> > >> But, in any case, when C gets the offer, it will try to establish an SCTP association with A. > > > > It does not quite works like this. In the described case, P first establishes a session between A and B which has an SCTP session. Then P sends an INVITE without SDP to A. A > has no indication if new SCTP association is needed, so it continues to use current SCTP association, and sends an offer in the response to INVITE with SDP which contains > > current sctp-port. P then sends the offer received from A to C. C had no SCTP association running at that point, so it allocates new random sctp-port, sends an answer to P > and attempts to initiate an SCTP association with A. P sends that answer to A, and if sctp-port in the answer is different A, will know this is a new SCTP association and > > attempts to initiate an SCTP association with C. If there is a random collision, A will think this is the existing SCTP association, C will think this is a new SCTP association, > > things break. > > I think we can assume that the verification tag from C will be > different, can't we? A will know that the INIT does not belong to > the existing SCTP association. > > > Upon checking with https://tools.ietf.org/html/rfc4960#section-5.2 > establishing a new connection from C to A even before B have closed the > connection should work. > > I would like somebody to double check this, but I think we can proceed > with the document as is. I don't understand SCTP sufficiently to sort out what will happen. But I do think we need to find out. Thanks, Paul From nobody Wed Jan 25 12:58: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 1AF65129BDD for ; Wed, 25 Jan 2017 12:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 8hYClojlWqOF for ; Wed, 25 Jan 2017 12:57:55 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (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 06728129BF4 for ; Wed, 25 Jan 2017 12:57:54 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-04v.sys.comcast.net with SMTP id WUczcbO189RIgWUdecSgTj; Wed, 25 Jan 2017 20:57:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485377874; bh=+2a5I4Wnz7C+xdY8rhyfdzfC9ObwaIyJxYyCf1lBjXU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PLry//lrXtVUatxCXCLz+g/UA+6+90wZaQtaM/XD0dSSXjZd73sGIpLYJi+VjgCi6 HuGgkHmabF05of0gt5+NAw1eYK5s174/gBru6bN/UcJa1wds3rhxMxdFRG1AAC5oEL U6vLjZc7ZZtjo+8LAJohy/CPp3kya9mO6W7s/Fix9KNke0sb1XUSdGEX01MD5lfWgZ bRyfwPesw2zkKGlP/33BNjuKuUoZEY9lCd5RunE/8WYJ6VpxfUFPaMI/xWNHaWtXLI yD/ncZKBKh0BCHo2uSZGQL0/2xyy3ClxQ6yooPKoJyDz2EsYur+r4XPzE8VFV3s20k qcYV3xHKUKpVA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-04v.sys.comcast.net with SMTP id WUddcZJgMN4yaWUdecneq2; Wed, 25 Jan 2017 20:57:54 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> Date: Wed, 25 Jan 2017 15:57:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEcaL+OMI2T7nGAXmcIT2UzbGm0ch8qjxJak9orClUU2qn5rhkbzEnbvju9RSfrn3Jd8ecobS0jS7hNHW/aoW2/CbzOkpLR2ensuth/UMEbLpNyDiZih Xt8lVYfU7Sp3PxPrbSVmvXlfhleqK9XA67/n/fiJDe3Pse94p+DJaeiGQ9le94j6p/sgBFy6j52aXg== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 20:58:01 -0000 On 1/25/17 3:26 PM, Christer Holmberg wrote: > Hi, > >>>>> No. Let's not start making things complicated again. The document is in good shape in my opinion. Let's publish it. >>>>> >>>>> Keep in mind that nothing prevents an endpoint from >>>>> closing/re-opening an SCTP association at any time. All we are saying is that a DTLS change does not automatically affect the SCTP association. >>>> >>>> I agree that if an endpoint explicitly initiates the closing of an >>>> SCTP association, and the other end acknowledges that, they can then >>>> establish a new association. (IIUC it would take another O/A to trigger establishing the new one.) But it requires one of the endpoints to know that this is needed. >>>> >>>> Lets consider a 3pcc scenario, where A is in call with B via >>>> controller P, where P isn't proxying the media. Now suppose P wants >>>> to transfer the call, replacing B with C. Typically it will do this by sending an offerless invite to A, and then forward the resulting offer from A to C. >>>> >>>> In this case C can't resume the SCTP association that A has with B. But A doesn't know that a new association is needed. >>> >>> Assuming B terminates the SCTP association with A when the transfer occurs, A will know. >>> >>> But, in any case, when C gets the offer, it will try to establish an SCTP association with A. >> >> I agree that C will try that. I haven't done any digging into the details of the SCTP protocol, but it seems like A and C will be working at cross purposes. C will be trying to >> establish a new association, while A is trying to re-establish the existing SCTP association over a new DTLS association. Maybe it will just all work out, but I'm inclined to >> doubt it. >> >> It would help to have a expert on the SCTP protocol chime in at this point. > > We also of course have to assume that A, when it receives the offerless invite, creates an offer that represents the ongoing associations (including the currently used sctp-port value), and not a new one (if A offers a new sctp-port value, there won't be an issue, because the INIT from C will be received on that port). But, that is a general problem with 3pcc, not specific to SCTP. While (AFAIK) there are no SCTP-specific requirements pertaining to this, it is hard to imagine anyone concluding they should do otherwise. Thanks, Paul From nobody Wed Jan 25 18:40: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 9E9B5129447 for ; Wed, 25 Jan 2017 18:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 5-5sDeTplBZK for ; Wed, 25 Jan 2017 18:40:21 -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 7A463129441 for ; Wed, 25 Jan 2017 18:40:21 -0800 (PST) Received: from [10.0.1.39] (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 v0Q2e51j088258 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Jan 2017 20:40:06 -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.39] From: "Ben Campbell" To: "Paul Kyzivat" , "Christer Holmberg" , "Roman Shpount" , "Flemming Andreasen" Date: Wed, 25 Jan 2017 20:40:04 -0600 Message-ID: <9A5608A3-0AD5-4840-8852-6A166D72A7CE@nostrum.com> In-Reply-To: <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: mmusic@ietf.org Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 02:40:22 -0000 Hi, Given the discussion, it seems to make sense to go ahead and start the IETF LC, and to ask for a TSV review team review as part of that. Does that make sense? Thanks! Ben. On 25 Jan 2017, at 14:57, Paul Kyzivat wrote: > On 1/25/17 3:26 PM, Christer Holmberg wrote: >> Hi, >> >>>>>> No. Let's not start making things complicated again. The document >>>>>> is in good shape in my opinion. Let's publish it. >>>>>> >>>>>> Keep in mind that nothing prevents an endpoint from >>>>>> closing/re-opening an SCTP association at any time. All we are >>>>>> saying is that a DTLS change does not automatically affect the >>>>>> SCTP association. >>>>> >>>>> I agree that if an endpoint explicitly initiates the closing of an >>>>> SCTP association, and the other end acknowledges that, they can >>>>> then >>>>> establish a new association. (IIUC it would take another O/A to >>>>> trigger establishing the new one.) But it requires one of the >>>>> endpoints to know that this is needed. >>>>> >>>>> Lets consider a 3pcc scenario, where A is in call with B via >>>>> controller P, where P isn't proxying the media. Now suppose P >>>>> wants >>>>> to transfer the call, replacing B with C. Typically it will do >>>>> this by sending an offerless invite to A, and then forward the >>>>> resulting offer from A to C. >>>>> >>>>> In this case C can't resume the SCTP association that A has with >>>>> B. But A doesn't know that a new association is needed. >>>> >>>> Assuming B terminates the SCTP association with A when the transfer >>>> occurs, A will know. >>>> >>>> But, in any case, when C gets the offer, it will try to establish >>>> an SCTP association with A. >>> >>> I agree that C will try that. I haven't done any digging into the >>> details of the SCTP protocol, but it seems like A and C will be >>> working at cross purposes. C will be trying to >>> establish a new association, while A is trying to re-establish the >>> existing SCTP association over a new DTLS association. Maybe it will >>> just all work out, but I'm inclined to >>> doubt it. >>> >>> It would help to have a expert on the SCTP protocol chime in at this >>> point. >> >> We also of course have to assume that A, when it receives the >> offerless invite, creates an offer that represents the ongoing >> associations (including the currently used sctp-port value), and not >> a new one (if A offers a new sctp-port value, there won't be an >> issue, because the INIT from C will be received on that port). But, >> that is a general problem with 3pcc, not specific to SCTP. > > While (AFAIK) there are no SCTP-specific requirements pertaining to > this, it is hard to imagine anyone concluding they should do > otherwise. > > Thanks, > Paul > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jan 26 00:02: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 A79A51294C5 for ; Thu, 26 Jan 2017 00:02:16 -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 8Sm5s446v8b7 for ; Thu, 26 Jan 2017 00:02:15 -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 B23511294CD for ; Thu, 26 Jan 2017 00:02:14 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-bd-5889ad042f64 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id ED.FA.16488.40DA9885; Thu, 26 Jan 2017 09:02:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 09:02:11 +0100 From: Christer Holmberg To: Ben Campbell , Paul Kyzivat , Roman Shpount , Flemming Andreasen Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJwAAANOgAAAlpGEP///hUA///szeCAAB+zgIAAX5sAgAB79gA= Date: Thu, 26 Jan 2017 08:02:10 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> <9A5608A3-0AD5-4840-8852-6A166D72A7CE@nostrum.com> In-Reply-To: <9A5608A3-0AD5-4840-8852-6A166D72A7CE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <57A984A7FC5CF4499DE0E9DCAC04384E@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2K7qy7r2s4IgynfWC3md55mt3h/Qddi 6vLHLBYPfvSyWcy4MJXZgdVjyu+NrB6TH89h9Fiy5CeTx6ydT1g8bk0pCGCN4rJJSc3JLEst 0rdL4Mq43baZteCBeEXnkklsDYy/hboYOTkkBEwkPlzfx97FyMUhJLCOUeLV5klMIAkhgcWM Er17HboYOTjYBCwkuv9pg9SICMxklPh04CMLSJxZQF3i6uIgkHJhgWiJr/tfs4DYIgIxEmf3 LGaCqO9ilLh+dTkbSD2LgKrE9iN6IDW8AtYSU16cZILY+5BNov/cZVaQBKeAvcTJa9vBbmAU EJP4fmoNmM0sIC5x68l8JoijBSSW7DnPDGGLSrx8/A+sV1RAT2L58zVQcUWJj6/2MUL06kgs 2P2JDeJma4nG49oQYW2JZQtfM0PcIyhxcuYTlgmM4rOQbJuFpHsWQvcsJN2zkHQvYGRdxSha nFpcnJtuZKSXWpSZXFycn6eXl1qyiREYowe3/LbawXjwueMhRgEORiUe3oK9HRFCrIllxZW5 hxglOJiVRHjPr+6MEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBAemJJanZqakFqEUyW iYNTqoFROcg34Za70wmn6jeZHHoS15v287iGm7Xy2DE916ja8y7aXV7Jubh5YdVMG9eVXkFp wr8Wx+iqTUj9y59z73orX0ygC0vPzd/vxEteGzy//7nSI+lU+I6YjBjdW8oqHTV1+yr2GGju 9b/rN333slJJDQtvE+788M5lH6MDjN+IFJ769uiXvxJLcUaioRZzUXEiAMnLYY3NAgAA Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 08:02:17 -0000 Hi, >Given the discussion, it seems to make sense to go ahead and start the >IETF LC, and to ask for a TSV review team review as part of that. Does >that make sense? Sounds good to me. Regards, Christer >On 25 Jan 2017, at 14:57, Paul Kyzivat wrote: > >> On 1/25/17 3:26 PM, Christer Holmberg wrote: >>> Hi, >>> >>>>>>> No. Let's not start making things complicated again. The document >>>>>>> is in good shape in my opinion. Let's publish it. >>>>>>> >>>>>>> Keep in mind that nothing prevents an endpoint from >>>>>>> closing/re-opening an SCTP association at any time. All we are >>>>>>> saying is that a DTLS change does not automatically affect the >>>>>>> SCTP association. >>>>>> >>>>>> I agree that if an endpoint explicitly initiates the closing of an >>>>>> SCTP association, and the other end acknowledges that, they can >>>>>> then >>>>>> establish a new association. (IIUC it would take another O/A to >>>>>> trigger establishing the new one.) But it requires one of the >>>>>> endpoints to know that this is needed. >>>>>> >>>>>> Lets consider a 3pcc scenario, where A is in call with B via >>>>>> controller P, where P isn't proxying the media. Now suppose P >>>>>> wants >>>>>> to transfer the call, replacing B with C. Typically it will do >>>>>> this by sending an offerless invite to A, and then forward the >>>>>> resulting offer from A to C. >>>>>> >>>>>> In this case C can't resume the SCTP association that A has with >>>>>> B. But A doesn't know that a new association is needed. >>>>> >>>>> Assuming B terminates the SCTP association with A when the transfer >>>>> occurs, A will know. >>>>> >>>>> But, in any case, when C gets the offer, it will try to establish >>>>> an SCTP association with A. >>>> >>>> I agree that C will try that. I haven't done any digging into the >>>> details of the SCTP protocol, but it seems like A and C will be >>>> working at cross purposes. C will be trying to >>>> establish a new association, while A is trying to re-establish the >>>> existing SCTP association over a new DTLS association. Maybe it will >>>> just all work out, but I'm inclined to >>>> doubt it. >>>> >>>> It would help to have a expert on the SCTP protocol chime in at this >>>> point. >>> >>> We also of course have to assume that A, when it receives the >>> offerless invite, creates an offer that represents the ongoing >>> associations (including the currently used sctp-port value), and not >>> a new one (if A offers a new sctp-port value, there won't be an >>> issue, because the INIT from C will be received on that port). But, >>> that is a general problem with 3pcc, not specific to SCTP. >> >> While (AFAIK) there are no SCTP-specific requirements pertaining to >> this, it is hard to imagine anyone concluding they should do >> otherwise. >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jan 26 00:28: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 00E621294EA; Thu, 26 Jan 2017 00:28:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148541932599.16464.2878725420758491759.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 00:28:46 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-4572-update-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 08:28:46 -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 of the IETF. Title : Connection-Oriented Media Transport over TLS in SDP Authors : Jonathan Lennox Christer Holmberg Filename : draft-ietf-mmusic-4572-update-12.txt Pages : 17 Date : 2017-01-26 Abstract: This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. This document obsoletes RFC 4572, by clarifying the usage of multiple fingerprints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-4572-update-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-4572-update-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 Thu Jan 26 00:29: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 A97B81294EC for ; Thu, 26 Jan 2017 00:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, 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 irXf8rlFGLsn for ; Thu, 26 Jan 2017 00:29:43 -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 34BCE1294EA for ; Thu, 26 Jan 2017 00:29:43 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id 3so12724277pgj.3 for ; Thu, 26 Jan 2017 00:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nSHuHMmMJ2l6TJR6pfT/iUjuzeNxdQ1Dw1qOHbl5lmQ=; b=B3fOU4bxSOWLSX90HF2jj4aLavlV4x1/GUNg2YwRxjS8szHBFaOXSuQ6rTO5cKfWDe VVgj9cl+YFLztX0FlvUqVWEOFTavbJSjCDt7+vaxCuFeWjhrBOW9/UK+3fQhzHzA12sl j7QaNDruTvjLHYJzVc3vJkf5dIV/KTq891V/yYQBmdLWLeZfQKOFQCrrIsAKXJA80k6/ Pv6dk8xuowts7AxhtYYGUCD+nG7MOQNn3+lWQBxJrFAl+qSRwNlwbxe7Qe5jeMSBXvAu aMmG4MkmEZZYchco+QVRVlTnC+1QbOt1IBT63OrIgcZrA5FJ9tCgUsGQKdbwyZ5/40Do qNxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nSHuHMmMJ2l6TJR6pfT/iUjuzeNxdQ1Dw1qOHbl5lmQ=; b=Fu/OQ2ANgzPWRha2iLFT63mhxSDMjncwnQ0brFT5XGxm4HGzeSnRjsVVJXVkvE+l88 7frf9oizbcYTiRvtH6DYsOpXBp5Np03ExHCnqcX6OQQUpa0H0Iu+kMUnzlPBLg4T9uRS 5mOyNJ4oO2ULgKxKxjJrDD7k+r2m9hPRJ1MIquaYvpWBueh3LOfCDZznPsVDYjnB0YPx kVNGKWd3E3r4eoUPvPL2GxtXKX5BEFt/l4tBdFxKAxk6Q+fFo3QePn6lGoALlsnUjI/D qPP+xHipbsbumJpyruQWJWWP4b5qFcoxsu//a9A4tnmPARMtS+0H9qVSURqitSIIe5sT aPTw== X-Gm-Message-State: AIkVDXLH0uR4cyk0OBbTmaCLZ8Di/u0dgPefDHgPeusaGJ+KLOw+NMWe2I9paskYjtFY2w== X-Received: by 10.98.79.150 with SMTP id f22mr1774166pfj.55.1485419382692; Thu, 26 Jan 2017 00:29:42 -0800 (PST) Received: from [192.168.1.176] (c-24-19-245-25.hsd1.wa.comcast.net. [24.19.245.25]) by smtp.gmail.com with ESMTPSA id d78sm2009998pfb.43.2017.01.26.00.29.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 00:29:41 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E129E09D-7049-43A5-B074-9BF64AFDC29F Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPad Mail (14C92) In-Reply-To: Date: Thu, 26 Jan 2017 00:29:41 -0800 Content-Transfer-Encoding: 7bit Message-Id: <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> To: Roman Shpount Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 08:29:44 -0000 --Apple-Mail-E129E09D-7049-43A5-B074-9BF64AFDC29F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In working through the ORTC SctpTransport implementation some of the odditie= s of SO became apparent. AFAICT existing implementations assume that the loc= al and remote ports are the same and defaulting to 5000, which is funky. If o= ne assumes that the remote port needs to be provided before an SCTP Associat= ion can be initiated, then does SO really make sense? The Answerer will have= the Local and remote ports first, so it will initiate, but can the Offerer r= espond without receiving the Answer and the remote port? This doesn't seem l= ike active/active, really. > On Jan 25, 2017, at 09:52, Roman Shpount wrote: >=20 > One more clarification: >=20 >> On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat w= rote: >> I see *no* mention that the sctp-port value should be chosen randomly. An= d IMO it is unnatural to suggest port values be random. There could be reaso= ns for them not being random - for instance interop with SCTP over IP with w= ell known ports. Also, while there is currently no spec for multiple SCTP as= sociations in the same bundle, it is not hard to imagine that that might be a= useful thing to do in the future. In that case random port numbers could be= more troublesome. >=20 > SCTP associations described in this document are always simultaneous open (= active/active) associations. Because of this sctp-port values are effectivel= y emulating ephemeral ports allocated on the host system. Such ports are ran= domly allocated. I do not think well known SCTP ports would work with simult= aneous open. This does not effect the ability to run multiple SCTP associati= ons over the same underlying transport, since all this means that end point n= eeds to allocate two different random sctp-port values. >=20 > In any case, the option I was thinking about regarding sctp-port extension= is to modify it to add support for URL parameters and to be something like a= =3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will be used in SCTP pac= kets and the branch parameter will be used to indicate new/existing connecti= on setup. >=20 > Regards, > _____________ > Roman Shpount > =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail-E129E09D-7049-43A5-B074-9BF64AFDC29F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
In working through the ORTC= SctpTransport implementation some of the oddities of SO became apparent. AFA= ICT existing implementations assume that the local and remote ports are the s= ame and defaulting to 5000, which is funky. If one assumes that the remote p= ort needs to be provided before an SCTP Association can be initiated, then d= oes SO really make sense? The Answerer will have the Local and remote ports f= irst, so it will initiate, but can the Offerer respond without receiving the= Answer and the remote port?  This doesn't seem like active/active, rea= lly.

On Jan 25, 2017, at 09:52, Roman Shpount <roman@telurix.com> wrote:

One more clarification:

On Tue, Jan 24, 2017 at 4:10 PM, Paul K= yzivat <paul.kyzivat@comcast.net> wrote:
I see *no= * mention that the sctp-port value should be chosen randomly. And IMO it is u= nnatural to suggest port values be random. There could be reasons for them n= ot being random - for instance interop with SCTP over IP with well known por= ts. Also, while there is currently no spec for multiple SCTP associations in= the same bundle, it is not hard to imagine that that might be a useful thin= g to do in the future. In that case random port numbers could be more troubl= esome.

SCTP associations des= cribed in this document are always simultaneous open (active/active) associa= tions. Because of this sctp-port values are effectively emulating ephemeral p= orts allocated on the host system. Such ports are randomly allocated. I do n= ot think well known SCTP ports would work with simultaneous open. This does n= ot effect the ability to run multiple SCTP associations over the same underl= ying transport, since all this means that end point needs to allocate two di= fferent random sctp-port values.

In any case, the o= ption I was thinking about regarding sctp-port extension is to modify it to a= dd support for URL parameters and to be something like a=3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will be used in SC= TP packets and the branch parameter will be used to indicate new/existing co= nnection setup.

Regards,
__________= ___
Roman Shpount
 
____________________= ___________________________
mmusic mailing list
mmusic@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/mmusic">https://www.ietf.org= /mailman/listinfo/mmusic
= --Apple-Mail-E129E09D-7049-43A5-B074-9BF64AFDC29F-- From nobody Thu Jan 26 00:39:07 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 810171294F4 for ; Thu, 26 Jan 2017 00:39:05 -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 hoIMDQV2E8HQ for ; Thu, 26 Jan 2017 00:39:04 -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 C4F3B1294F2 for ; Thu, 26 Jan 2017 00:39:03 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-11-5889b5a5138e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 33.1D.28805.5A5B9885; Thu, 26 Jan 2017 09:39:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 09:39:01 +0100 From: Christer Holmberg To: Bernard Aboba , Roman Shpount Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAA= Date: Thu, 26 Jan 2017 08:39:01 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> In-Reply-To: <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D4AF8140166C9christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7me6yrZ0RBne3sFts2Pef2WLq8scs Fg9+9LJZzLgwldmBxWPy4zmMHjtn3WX3WLLkJ5PHrSkFASxRXDYpqTmZZalF+nYJXBn7X/5l KvjhWPGzN72Bcbd5FyMnh4SAicS6mx9Zuxi5OIQE1jFKPGubwwLhLGaUOPN3HpDDwcEmYCHR /U8bpEFEwE+ioeceO4jNLBAkcep0JxuILSwQLfF1/2sWiJoYibN7FjOBtIoIJEm8uhYHYrII qEos38MLUsErYC1xeMEsJohNX5glOs5/YwRJcArYShybfh7MZhQQk/h+ag0TxCpxiVtP5jNB 3CwgsWTPeWYIW1Ti5eN/rCC2qICexPLna6DiihI7z7YzQ/QmSMw43sEGsVhQ4uTMJywTGEVn IRk7C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4DNVrLXHqbT+KmgWMHKsYRYtTi5Ny042M 9FKLMpOLi/Pz9PJSSzYxAiP14JbfBjsYXz53PMQowMGoxMNbsLcjQog1say4MvcQowQHs5II 7/nVnRFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MCZz y4etXKA8LWfnU5Ud91hVr17mXWu/J/hno2pyQAZb7MG1y/le5NZtzPh7e/mX3XNuVVxP/3Pt SLk7x9mp1zOnuvTb7xK49+Cjz1zd1/e/prIvb2IW/qmr2FV/VjZTdarWLs4ZZhlb+S7oW8tP Yn+v1H3hi5bS4ul/057t6Z2x5q3ua6+A4holluKMREMt5qLiRAC3xvjV0AIAAA== Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 08:39:05 -0000 --_000_D4AF8140166C9christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >In working through the ORTC SctpTransport implementation some of the oddit= ies of SO became apparent. AFAICT existing implementations assume that the = local and remote ports are the same and defaulting to 5000, which is funky.= If >one assumes that the remote port needs to be provided before an SCTP Assoc= iation can be initiated, then does SO really make sense? The Answerer will = have the Local and remote ports first, so it will initiate, but can the Off= erer respond >without receiving the Answer and the remote port? This doesn't seem like = active/active, really. The offerer gets the port of the association initiated by the answerer in t= he INIT sent from the answerer. And, the spec says that the same ports must= be used for both associations. "When an SCTP association is established, both SCTP endpoints MUST initiate the SCTP association (i.e. both SCTP endpoints take the 'active' role), and MUST use the same SCTP port as client port and server port (in order to prevent two separate SCTP associations from being established)." But, the offerer does need to get SOMETHING (the answer and/or the INIT) fr= om the answerer before the offerer can initiate the association. Regards, Christer One more clarification: On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat > wrote: I see *no* mention that the sctp-port value should be chosen randomly. And = IMO it is unnatural to suggest port values be random. There could be reason= s for them not being random - for instance interop with SCTP over IP with w= ell known ports. Also, while there is currently no spec for multiple SCTP a= ssociations in the same bundle, it is not hard to imagine that that might b= e a useful thing to do in the future. In that case random port numbers coul= d be more troublesome. SCTP associations described in this document are always simultaneous open (= active/active) associations. Because of this sctp-port values are effective= ly emulating ephemeral ports allocated on the host system. Such ports are r= andomly allocated. I do not think well known SCTP ports would work with sim= ultaneous open. This does not effect the ability to run multiple SCTP assoc= iations over the same underlying transport, since all this means that end p= oint needs to allocate two different random sctp-port values. In any case, the option I was thinking about regarding sctp-port extension = is to modify it to add support for URL parameters and to be something like = a=3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will be used in SCTP p= ackets and the branch parameter will be used to indicate new/existing conne= ction setup. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_D4AF8140166C9christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <79F175913D4C6E49B03C9BCFFE7BDF14@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>In working through the ORTC SctpTransport implementation some of t= he oddities of SO became apparent. AFAICT existing implementations assume t= hat the local and remote ports are the same and defaulting to 5000, which i= s funky. If
>one assumes that the remote port needs to be provided before an SC= TP Association can be initiated, then does SO really make sense? The Answer= er will have the Local and remote ports first, so it will initiate, but can= the Offerer respond 
>without receiving the Answer and the remote port?  This doesn= 't seem like active/active, really.

The offerer gets the port of the association initiated by the answerer= in the INIT sent from the answerer. And, the spec says that the same ports= must be used for both associations.

   "When an SCTP association =
is established, both SCTP endpoints MUST
   initiate the SCTP association (i.e. both SCTP endpoints take the
   'active' role), and MUST use the same SCTP port as client port and
   server port (in order to prevent two separate SCTP associations from
   being established)."

But, the offerer does need to get SOMETHING (the answer and/or the INI= T) from the answerer before the offerer can initiate the association.

Regards,

Christer




One more clarification:

On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat <paul.kyzi= vat@comcast.net> wrote:
I see *no* mention that the sctp-port value should = be chosen randomly. And IMO it is unnatural to suggest port values be rando= m. There could be reasons for them not being random - for instance interop = with SCTP over IP with well known ports. Also, while there is currently no spec for multiple SCTP associatio= ns in the same bundle, it is not hard to imagine that that might be a usefu= l thing to do in the future. In that case random port numbers could be more= troublesome.

SCTP associations described in this document are always simultaneous o= pen (active/active) associations. Because of this sctp-port values are effe= ctively emulating ephemeral ports allocated on the host system. Such ports = are randomly allocated. I do not think well known SCTP ports would work with simultaneous open. This does n= ot effect the ability to run multiple SCTP associations over the same under= lying transport, since all this means that end point needs to allocate two = different random sctp-port values.

In any case, the option I was thinking about regarding sctp-port exten= sion is to modify it to add support for URL parameters and to be something = like a=3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will be used in SCTP packets and the branch parameter wil= l be used to indicate new/existing connection setup.

Regards,
_____________
Roman Shpount
 
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.= ietf.org/mailman/listinfo/mmusic
 --_000_D4AF8140166C9christerholmbergericssoncom_-- From nobody Thu Jan 26 03:58: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 78F81129542; Thu, 26 Jan 2017 03:58:22 -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 t6Vk9DrQQFLq; Thu, 26 Jan 2017 03:58:20 -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 5EA3612953D; Thu, 26 Jan 2017 03:58:19 -0800 (PST) X-AuditID: c1b4fb30-d67fb70000007085-2b-5889e4585879 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 9E.C2.28805.854E9885; Thu, 26 Jan 2017 12:58:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 12:58:13 +0100 From: Christer Holmberg To: Flemming Andreasen , mmusic Thread-Topic: 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) Thread-Index: AQHScdm55RHubnr5e0me78cQd5IDTqFKxG8A Date: Thu, 26 Jan 2017 11:58:12 +0000 Message-ID: References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> In-Reply-To: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7lm7kk84Ig+MtNhb/J85ntXh/Qddi 6vLHLA7MHlN+b2T1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxrUz3YwFT4Qqmq91sDYw/uXrYuTk kBAwkZj59BRjFyMXh5DAOkaJk5sXskM4ixkl7k47zNbFyMHBJmAh0f1PG6RBRMBV4sjCu0wg NrNAoMS5G63sILawQLjE19YlbBA1ERL9394yQthGEq9PvwSrYRFQlfiydCsLiM0rYC1x8/xs sHohARuJKSfaGEFWcQrYSnyYKQ8SZhQQk/h+ag3UKnGJW0/mM0HcLCCxZM95ZghbVOLl43+s ILaogJ7E8udroOKKEu1PGxghevUkbkydwgZhW0ss3PaXHcLWlli28DUzxDmCEidnPmGZwCg+ C8m6WUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAqPu4JbfBjsY Xz53PMQowMGoxMNbsLcjQog1say4MvcQowQHs5IIr8Sjzggh3pTEyqrUovz4otKc1OJDjNIc LErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGK2uHIrXmrOcqTz+XcKc83IJq5bqn1LmWXEp au1+8XMOSQaGU07v/t4Z58XPOKfk6GpfyW9XN9gINPF1RM26uH2ysP+Zzr41099o9K7Y9rTJ L6hyXf1kQ/Hmf3932ikK7zIrVt3Ofrh87xlGZ7uaO0nqigt7fjbuPbi2pWxNspDzY807CgsX zVZiKc5INNRiLipOBADb96iLtgIAAA== Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 11:58:22 -0000 Hi, Below are comments that my colleague Nevenka provided (she has subscribed to the list, but hasn=B9t been accepted yet). I=B9ll address them in a separate reply. ---------- Hello, =20 I reviewed draft-ietf-mmusic-dtls-sdp-16.txt and have the following comments: =20 - In Section 1 the following statement is not aligned with the recent change which made "dtls-id" attribute globally unique i.e. the pair of "dtls-id" attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association instead of the "dtls-id" attribute pair in combination with "fingerprint" attribute values (the attribute values of the offerer and the answerer). Thus the following sentence requires modification: "The =B9dtls-id=B9 attribute pair in combination with =B9fingerprint=B9 att= ribute values from offer and answer SDP uniquely identifies the DTLS association." - In section 4 there are contradicting statements related to a default value of "dtls-id" attribute: "Default Value: empty value " =20 But the text says: "No default value is defined for the SDP =B9dtls-id=B9 attribute. " =20 Based on the above text "empty value" should be replaced with "N/A=B2 =20 - I believe that RFC 4572 should be included in 14.2 since it is (and should be) referenced in sections 9.2 & 9.3 from old text in RFC 5763 and RFC 7345, but the new text requires modification and should refer to draft ietf-mmusic-4572-update (but currently still has reference to RFC 4572). =20 - In addition I also found some editorial nits that I have provided directly to the authors. =20 Kind regards, Nevenka -------- On 19/01/17 00:24, "Flemming Andreasen" wrote: >Greetings > >We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however >there has been some updates to the draft subsequently. We are hereby >issuing a 1 week WGLC on the the changes from -14 to -16 only, as >indicated by the following URL: > >https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-14&url2=3Dd= raft >-ietf-mmusic-dtls-sdp-16 > >If you have any comments on the updates, please provide those by >Wednesday, January 25. Comments should be sent to the document authors >and the MMUSIC WG list. > >Thanks > >-- Flemming (as MMUSIC co-chair) > > > > From nobody Thu Jan 26 04:10: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 1A636129544; Thu, 26 Jan 2017 04:10: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, 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 3u7ZbmUbHTcd; Thu, 26 Jan 2017 04:10:07 -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 5503D129543; Thu, 26 Jan 2017 04:10:07 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-03-5889e71db8e7 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 04.F5.14025.D17E9885; Thu, 26 Jan 2017 13:10:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 13:09:56 +0100 From: Christer Holmberg To: Christer Holmberg , Flemming Andreasen , mmusic Thread-Topic: 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) Thread-Index: AQHScdm55RHubnr5e0me78cQd5IDTqFKxG8AgAADRQA= Date: Thu, 26 Jan 2017 12:09:55 +0000 Message-ID: References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: <760C7A243EFBAD44A005188EEDCABECA@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7h67s884IgwfX1C3+T5zPavH+gq7F 1OWPWRyYPab83sjqsWTJT6YApigum5TUnMyy1CJ9uwSujCXHzAsui1W0brRrYGwR6mLk5JAQ MJE4+/sOYxcjF4eQwDpGiTnH3rCDJIQEFjNKtPy36GLk4GATsJDo/qcNEhYRqJZY/e4rE4jN LBAoce5GK1i5sEC4xNfWJWwQNRES/d/eMkLYVhLr2vcyg4xhEVCVmPZYGMTkFbCWOHGrBmJR nsT6qR1gUzgFbCRatk9mAbEZBcQkvp9aA7VJXOLWk/lMEBcLSCzZc54ZwhaVePn4HyuILSqg J7H8+RqwTRICihLL++UgWg0k3p+bzwxhW0vcmbELaqS2xLKFr8HivAKCEidnPmGZwCg+C8m2 WUjaZyFpn4WkfRaS9gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAmPt4JbfqjsYL79x PMQowMGoxMNbsLcjQog1say4MvcQowQHs5IIr/uTzggh3pTEyqrUovz4otKc1OJDjNIcLEri vGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGCdvzVVaqtHjG9bYbKo5SVNwWqp+2886Ed15LWq/ Y2L2LQ9Oec+54/KU434TyjhUy5iXSfyQtOYKaWy6uEjozRr9LEXhEhuhd9Na1G7vf76Y52rj n+n7JbWf1Dssq17f9CJ+zlSd/JTI565szeea+jpW9Dp8mKDh0B233nL5twD/nUqnQh9cUGIp zkg01GIuKk4EAB1GtOuxAgAA Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 12:10:09 -0000 Hi Chris=8A eeeh.. Nevenka, Thanks for your comments! Please see inline. >=20 >I reviewed draft-ietf-mmusic-dtls-sdp-16.txt and have the following >comments: > >=20 >- In Section 1 the following statement is not aligned with the >recent change which made "dtls-id" attribute globally unique i.e. the pair >of "dtls-id" attribute values (the attribute values of the offerer and the >answerer) uniquely identifies the DTLS association instead of the >"dtls-id" attribute pair in combination with "fingerprint" attribute >values (the attribute values of the offerer and the answerer). Thus the >following sentence requires modification: > >"The 'dtls-id' attribute pair in combination with =8Cfingerprint' attribut= e >values from offer and answer SDP uniquely identifies the DTLS >association." I will replace the sentence with the following: "The pair of SDP 'dtls-id' attribute values (the attribute values of the offerer and the answerer) uniquely identifies the DTLS association." >- In section 4 there are contradicting statements related to a >default value of "dtls-id" attribute: >"Default Value: empty value " >=20 >But the text says: >"No default value is defined for the SDP 'dtls-id' attribute. " >=20 > >Based on the above text "empty value" should be replaced with "N/A" I agree. I=B9ll replace =B3empty value=B2 with =B3N/A=B2. > >=20 >- I believe that RFC 4572 should be included in 14.2 since it is >(and should be) referenced in sections 9.2 & 9.3 from old text in RFC 5763 >and RFC 7345,=20 I will add a normative reference to RFC 4572 (even though the idnits tool will complain about the reference not being used in the main text). >but the new text requires modification and should refer to >draft ietf-mmusic-4572-update (but currently still has reference to RFC >4572). Good catch. I=B9ll replace the reference in the new text. >=20 >- In addition I also found some editorial nits that I have provided >directly to the authors. >=20 I=B9ll fix those (some are the same also found by Christian Groves). Thanks! Regards, Christer > >On 19/01/17 00:24, "Flemming Andreasen" wrote: > >>Greetings >> >>We previously completed WGLC on draft-ietf-mmusic-dtls-sdp, however >>there has been some updates to the draft subsequently. We are hereby >>issuing a 1 week WGLC on the the changes from -14 to -16 only, as >>indicated by the following URL: >> >>https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-14&url2=3D= draf >>t >>-ietf-mmusic-dtls-sdp-16 >> >>If you have any comments on the updates, please provide those by >>Wednesday, January 25. Comments should be sent to the document authors >>and the MMUSIC WG list. >> >>Thanks >> >>-- Flemming (as MMUSIC co-chair) >> >> >> >> > From nobody Thu Jan 26 05:08: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 82725129582; Thu, 26 Jan 2017 05:08:46 -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 1HAfa8W7wSD4; Thu, 26 Jan 2017 05:08:45 -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 8FD4A129583; Thu, 26 Jan 2017 05:08:44 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-04-5889f4da51cb Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id 71.36.32317.AD4F9885; Thu, 26 Jan 2017 14:08:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 14:08:32 +0100 From: Christer Holmberg To: Christer Holmberg , Flemming Andreasen , mmusic Thread-Topic: 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) Thread-Index: AQHScdm55RHubnr5e0me78cQd5IDTqFKxG8AgAADRQCAABBgAA== Date: Thu, 26 Jan 2017 13:08:32 +0000 Message-ID: References: <5dfe18ac-c502-c78b-d6c9-aa422db73468@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7se6tL50RBq+e61j8nzif1eL9BV2L qcsfszgwe0z5vZHVY8mSn0wBTFFcNimpOZllqUX6dglcGT+/L2IvOKRUsf3QHvYGxguKXYyc HBICJhKv1ixn7mLk4hASWMcosXnOYhYIZzGjxIpJHYxdjBwcbAIWEt3/tEEaRASqJVa/+8oE YjMLBEqcu9HKDmILC4RLfG1dwgZREyHR/+0tI4TtJLGw/y4LiM0ioCqx6u4RJpCRvALWErdO KkOsWsAoMbf3AthMTgEbiYfHP4PNYRQQk/h+ag3ULnGJW0/mM0EcLSCxZM95ZghbVOLl43+s ILaogJ7E8udroOJKEj82XGIB2cUsoCmxfpc+xBhrif/bf7BA2IoSU7ofgp3PKyAocXLmE5YJ jOKzkGybhdA9C0n3LCTds5B0L2BkXcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGHMHt/zW 3cG4+rXjIUYBDkYlHt6CvR0RQqyJZcWVuYcYJTiYlUR4N73tjBDiTUmsrEotyo8vKs1JLT7E KM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBUa7mwFbZzF/WsllyD1zsWoW2HX21Oubj yesua8+/+H2vQ7nhYHjHoprvvkdm2x8/f0u1m0Xpq+c2DqaT/4/Pna8urLF4c6/f2e+m13bl /au4fenr7Vvzkt3y44IdNr8ybVHTbDj47JRa+b8XLb8+SVVZrGJ6MOHBOlvPpPtTcj7x6KQH zCsKXq7EUpyRaKjFXFScCAAu/UMUtQIAAA== Archived-At: Cc: "draft-ietf-mmusic-dtls-sdp@ietf.org" Subject: Re: [MMUSIC] 1 week WGLC on recent changes to draft-ietf-mmusic-dtls-sdp (-14 to -16) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 13:08:46 -0000 UHVsbCByZXF1ZXN0IGhhcyBiZWVuIHVwZGF0ZWQgd2l0aCB0aGUgY2hhbmdlcyBiYXNlZCBvbiBO ZXZlbmth4oCZcyBjb21tZW50czoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0 bHMtc2RwL3B1bGwvMjINCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDI2LzAxLzE3 IDE0OjA5LCAiQ2hyaXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20+DQp3cm90ZToNCg0KPkhpIENocmlzxaAgZWVlaC4uIE5ldmVua2EsDQo+DQo+VGhhbmtzIGZv ciB5b3VyIGNvbW1lbnRzISBQbGVhc2Ugc2VlIGlubGluZS4NCj4NCj4+IA0KPj5JIHJldmlld2Vk IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTE2LnR4dCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5n DQo+PmNvbW1lbnRzOg0KPj4NCj4+IA0KPj4tICAgICAgICAgSW4gU2VjdGlvbiAxIHRoZSBmb2xs b3dpbmcgc3RhdGVtZW50IGlzIG5vdCBhbGlnbmVkIHdpdGggdGhlDQo+PnJlY2VudCBjaGFuZ2Ug d2hpY2ggbWFkZSAiZHRscy1pZCIgYXR0cmlidXRlIGdsb2JhbGx5IHVuaXF1ZSBpLmUuIHRoZQ0K Pj5wYWlyDQo+Pm9mICJkdGxzLWlkIiBhdHRyaWJ1dGUgdmFsdWVzICh0aGUgYXR0cmlidXRlIHZh bHVlcyBvZiB0aGUgb2ZmZXJlciBhbmQNCj4+dGhlDQo+PmFuc3dlcmVyKSB1bmlxdWVseSBpZGVu dGlmaWVzIHRoZSBEVExTIGFzc29jaWF0aW9uIGluc3RlYWQgb2YgdGhlDQo+PiJkdGxzLWlkIiBh dHRyaWJ1dGUgcGFpciBpbiBjb21iaW5hdGlvbiB3aXRoICJmaW5nZXJwcmludCIgYXR0cmlidXRl DQo+PnZhbHVlcyAodGhlIGF0dHJpYnV0ZSB2YWx1ZXMgb2YgdGhlIG9mZmVyZXIgYW5kIHRoZSBh bnN3ZXJlcikuIFRodXMgdGhlDQo+PmZvbGxvd2luZyBzZW50ZW5jZSByZXF1aXJlcyBtb2RpZmlj YXRpb246DQo+Pg0KPj4iVGhlICdkdGxzLWlkJyBhdHRyaWJ1dGUgcGFpciBpbiBjb21iaW5hdGlv biB3aXRoIMWSZmluZ2VycHJpbnQnIGF0dHJpYnV0ZQ0KPj52YWx1ZXMgZnJvbSBvZmZlciBhbmQg YW5zd2VyIFNEUCB1bmlxdWVseSBpZGVudGlmaWVzIHRoZSBEVExTDQo+PmFzc29jaWF0aW9uLiIN Cj4NCj5JIHdpbGwgcmVwbGFjZSB0aGUgc2VudGVuY2Ugd2l0aCB0aGUgZm9sbG93aW5nOg0KPg0K PiAgICJUaGUgcGFpciBvZiBTRFAgJ2R0bHMtaWQnIGF0dHJpYnV0ZSB2YWx1ZXMgKHRoZSBhdHRy aWJ1dGUgdmFsdWVzIG9mDQo+ICAgIHRoZSBvZmZlcmVyIGFuZCB0aGUgYW5zd2VyZXIpIHVuaXF1 ZWx5IGlkZW50aWZpZXMgdGhlIERUTFMNCj4gICAgYXNzb2NpYXRpb24uIg0KPg0KPg0KPg0KPj4t ICAgICAgICBJbiBzZWN0aW9uIDQgdGhlcmUgYXJlIGNvbnRyYWRpY3Rpbmcgc3RhdGVtZW50cyBy ZWxhdGVkIHRvIGENCj4+ZGVmYXVsdCB2YWx1ZSBvZiAiZHRscy1pZCIgYXR0cmlidXRlOg0KPj4i RGVmYXVsdCBWYWx1ZTogZW1wdHkgdmFsdWUgIg0KPj4gDQo+PkJ1dCB0aGUgdGV4dCBzYXlzOg0K Pj4iTm8gZGVmYXVsdCB2YWx1ZSBpcyBkZWZpbmVkIGZvciB0aGUgU0RQICdkdGxzLWlkJyBhdHRy aWJ1dGUuICINCj4+IA0KPj4NCj4+QmFzZWQgb24gdGhlIGFib3ZlIHRleHQgICJlbXB0eSB2YWx1 ZSIgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggIk4vQSINCj4NCj5JIGFncmVlLiBJwrlsbCByZXBs YWNlIMKzZW1wdHkgdmFsdWXCsiB3aXRoIMKzTi9BwrIuDQo+DQo+DQo+Pg0KPj4gDQo+Pi0gICAg ICAgIEkgYmVsaWV2ZSB0aGF0IFJGQyA0NTcyIHNob3VsZCBiZSBpbmNsdWRlZCBpbiAxNC4yIHNp bmNlIGl0IGlzDQo+PihhbmQgc2hvdWxkIGJlKSByZWZlcmVuY2VkIGluIHNlY3Rpb25zIDkuMiAm IDkuMyBmcm9tIG9sZCB0ZXh0IGluIFJGQw0KPj41NzYzDQo+PmFuZCBSRkMgNzM0NSwgDQo+DQo+ SSB3aWxsIGFkZCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDQ1NzIgKGV2ZW4gdGhvdWdo IHRoZSBpZG5pdHMgdG9vbA0KPndpbGwgY29tcGxhaW4gYWJvdXQgdGhlIHJlZmVyZW5jZSBub3Qg YmVpbmcgdXNlZCBpbiB0aGUgbWFpbiB0ZXh0KS4NCj4NCj4NCj4+YnV0IHRoZSBuZXcgdGV4dCBy ZXF1aXJlcyBtb2RpZmljYXRpb24gYW5kIHNob3VsZCByZWZlciB0bw0KPj5kcmFmdCBpZXRmLW1t dXNpYy00NTcyLXVwZGF0ZSAoYnV0IGN1cnJlbnRseSBzdGlsbCBoYXMgcmVmZXJlbmNlIHRvIFJG Qw0KPj40NTcyKS4NCj4NCj5Hb29kIGNhdGNoLiBJwrlsbCByZXBsYWNlIHRoZSByZWZlcmVuY2Ug aW4gdGhlIG5ldyB0ZXh0Lg0KPg0KPg0KPj4gDQo+Pi0gICAgICAgIEluIGFkZGl0aW9uIEkgYWxz byBmb3VuZCBzb21lIGVkaXRvcmlhbCBuaXRzIHRoYXQgSSBoYXZlDQo+PnByb3ZpZGVkDQo+PmRp cmVjdGx5IHRvIHRoZSBhdXRob3JzLg0KPj4gDQo+DQo+ScK5bGwgZml4IHRob3NlIChzb21lIGFy ZSB0aGUgc2FtZSBhbHNvIGZvdW5kIGJ5IENocmlzdGlhbiBHcm92ZXMpLg0KPg0KPg0KPlRoYW5r cyENCj4NCj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+DQo+DQo+DQo+Pg0KPj5PbiAxOS8wMS8x NyAwMDoyNCwgIkZsZW1taW5nIEFuZHJlYXNlbiIgPGZhbmRyZWFzQGNpc2NvLmNvbT4gd3JvdGU6 DQo+Pg0KPj4+R3JlZXRpbmdzDQo+Pj4NCj4+PldlIHByZXZpb3VzbHkgY29tcGxldGVkIFdHTEMg b24gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAsIGhvd2V2ZXINCj4+PnRoZXJlIGhhcyBiZWVu IHNvbWUgdXBkYXRlcyB0byB0aGUgZHJhZnQgc3Vic2VxdWVudGx5LiBXZSBhcmUgaGVyZWJ5DQo+ Pj5pc3N1aW5nIGEgMSB3ZWVrIFdHTEMgb24gdGhlIHRoZSBjaGFuZ2VzIGZyb20gLTE0IHRvIC0x NiBvbmx5LCBhcw0KPj4+aW5kaWNhdGVkIGJ5IHRoZSBmb2xsb3dpbmcgVVJMOg0KPj4+DQo+Pj5o dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1z ZHAtMTQmdXJsMj1kcmENCj4+PmYNCj4+PnQNCj4+Pi1pZXRmLW1tdXNpYy1kdGxzLXNkcC0xNg0K Pj4+DQo+Pj5JZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMgb24gdGhlIHVwZGF0ZXMsIHBsZWFzZSBw cm92aWRlIHRob3NlIGJ5DQo+Pj5XZWRuZXNkYXksIEphbnVhcnkgMjUuIENvbW1lbnRzIHNob3Vs ZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRob3JzDQo+Pj5hbmQgdGhlIE1NVVNJQyBXRyBs aXN0Lg0KPj4+DQo+Pj5UaGFua3MNCj4+Pg0KPj4+LS0gRmxlbW1pbmcgKGFzIE1NVVNJQyBjby1j aGFpcikNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4NCj4NCg0K From nobody Thu Jan 26 05:54: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 A1EB91295D8; Thu, 26 Jan 2017 05:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdYejVclr4LF; Thu, 26 Jan 2017 05:54:12 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4908B1295D6; Thu, 26 Jan 2017 05:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2652; q=dns/txt; s=iport; t=1485438852; x=1486648452; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=zOhJrrsxlHPExdvQUfJD3l1gW4WHyrUK8yCzW5qMmW4=; b=diszZyy/EnkSvJSqlnBmAJGahE1bkxgWFxhgC3a36HXJQvk3z5PVLJOW mPWWb9qlaKNzyUB4zV5e3k48Qbcw//tnFkXXRcI07G4lM2I/FQAgE3e6V keIrvJqZdOAS/WIVQK+ejV79DKLS8T7cjEcWoEGxfkueZkPX/PJUxr7F2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMAgAS/4lY/5FdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR9hgQmfYJc7HwuFLkoCghxCFQECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEDAQEBNi8HCwULHAMBAgEuJygDBQYBDAYCAQEQiUAFCA6wNIpyAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWGS4IFjHkfBZAtiyOGZYsRgXeFEoMqhj6IJIpXNSK?= =?us-ascii?q?BLh0VO4Q8HIF/IjWIeQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208";a="375686560" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 13:54:11 +0000 Received: from [10.98.149.200] (bxb-fandreas-8817.cisco.com [10.98.149.200]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0QDsAti025458; Thu, 26 Jan 2017 13:54:11 GMT To: Harald Alvestrand , mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Flemming Andreasen Message-ID: Date: Thu, 26 Jan 2017 08:54:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 13:54:13 -0000 Hi Harald Since the document is not yet in Auth48 and the change is relatively minor, it is possible to update it during Auth48. However, from an MMUSIC chair point of view, I would like to get positive confirmation from some of the stakeholders that this change is indeed desired. Similarly, if anybody has any concerns with the suggested change, please send an e-mail to that effect. Thanks -- Flemming (as MMUSIC co-chair) On 1/23/17 10:18 AM, Harald Alvestrand wrote: > Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >> Ted pointed out to me that I sent this to the wrong group. >> >> Chairs and members, please advise. > My proposed change is here: > > https://github.com/alvestrand/rtcweb-msid/pull/16 > > The filed issue is here: > > https://github.com/alvestrand/rtcweb-msid/issues/15 > > (CCing RTCWEB - please keep discussion, if any, on mmusic) > >> >> >> -------- Forwarded Message -------- >> Subject: [rtcweb] Modifying an approved document: MSID >> Date: Wed, 18 Jan 2017 23:22:14 +0100 >> From: Harald Alvestrand >> To: rtcweb@ietf.org >> >> >> >> When reviewing the implications of the PeerConnection API change to >> support AddTrack rather than AddStream, I found an issue. >> >> This issue concerns draft-ietf-rtcweb-msid, which is currently in >> REF-WAIT state (I believe). >> >> The issue is that it is possible to add a track without specifying a >> stream. Since the track's ID needs to be carried, we have to send an >> "a=msid" line, but the track's ID is the *second* field on that line, >> with the first being the stream's ID. >> >> This creates a problem. >> >> Suggested fix: Insert two lines in the document: >> >> 1) On SDP generation: >> >> "If there is no stream associated with the track, use the reserved ID >> value '-'" >> >> 2) On SDP parsing >> >> "If the stream ID is the reserved value '-', the track is not associated >> with a stream, and no stream is signalled or created." >> >> If this is OK with the community, I'll issue an updated draft with this >> change. >> >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> _______________________________________________ >> 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 Thu Jan 26 08:55:45 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 E16AA12988D for ; Thu, 26 Jan 2017 08:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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, RP_MATCHES_RCVD=-3.199, 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=comcast.net 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 OGYk6FP2UO5v for ; Thu, 26 Jan 2017 08:55:41 -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 4C25C1297F1 for ; Thu, 26 Jan 2017 08:55:41 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-11v.sys.comcast.net with SMTP id WnKjcqsyF6nWCWnKmcqywP; Thu, 26 Jan 2017 16:55:40 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485449740; bh=LJTvDXHeXeH0IpQJKuCOpGByY+IWAU/zct9mEdjLXrc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jHV5RaU7xbO01uyvKchacDj92DSkhmGHo/eD5mUTGntXl+abji0UUL9zETXCt0iMV e2jhHn+kVL6fC13cL8IR6B73BL5fyz9ZxpLaVySvsbhmXYS+fwWMvYOZxNIDnvTE6O Os6JgKw0Ejb8qt1VkkDHubP9A4KN+9pX6DPFeiF9mUug8FgOJW0lVEqfurmX4rEbMg 8SLp9o+PNuavYvznv5+sZq2avase4cRUU/VBtDPGcWbzXW+SGqCc9VB2/ifInVgLjR ugOjFvuHNsoGvGruIFvNiuFo8cyKArwibKZ4MBuK3gSlN6x1AA1zd/J0T8pRcivOOc uvq0s9xa0pk2g== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-04v.sys.comcast.net with SMTP id WnKlccpbrDXgCWnKmckqEj; Thu, 26 Jan 2017 16:55:40 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> From: Paul Kyzivat Message-ID: Date: Thu, 26 Jan 2017 11:55:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGK7wI8LgmmABYXrwfVQbsV9UYLCKQ8nphmEQMHOnNW86uQE3yowdyFM4orM1MjLEKCtOWmpIcj6ZnY7CGY+uPyjoZvEw9RFjIU66ydXM1vDpfoLU9km pNpd3uLZNNl87oXKgBYxcXDnnSdLCrcotXKYpTyKF16uHiYE20+Blr4nb00Ss/ZVbexLCJyTkyx9dA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 16:55:43 -0000 On 1/26/17 3:39 AM, Christer Holmberg wrote: > Hi, > >>In working through the ORTC SctpTransport implementation some of the oddities of SO became apparent. AFAICT existing implementations assume that the local and remote ports are the same and defaulting to 5000, which is funky. If >>one assumes that the remote port needs to be provided before an SCTP > Association can be initiated, then does SO really make sense? The > Answerer will have the Local and remote ports first, so it will > initiate, but can the Offerer respond >>without receiving the Answer and the remote port? This doesn't seem > like active/active, really. > > The offerer gets the port of the association initiated by the answerer > in the INIT sent from the answerer. And, the spec says that the same > ports must be used for both associations. > > "When an SCTP association is established, both SCTP endpoints MUST > initiate the SCTP association (i.e. both SCTP endpoints take the > 'active' role), and MUST use the same SCTP port as client port and > server port (in order to prevent two separate SCTP associations from > being established)." I hadn't noticed that. Given that, section 10.3 ought to have normative language to that effect. Right now, all it says is: o MUST associate an SDP 'sctp-port' attribute with the m- line. If the offer contained a new (different than the one currently used) SCTP port value the answerer MUST also associate a new SCTP port value. If the offer contained a zero SCTP port value, or if the answerer does not accept the SCTP association, the answerer MUST also associate a zero SCTP port value; and Also, while this constraint is workable with UDP/DTLS/SCTP and TCP/DTLS/SCTP, it wouldn't be workable for SCTP directly over IP using well known ports for *either* end, because it would limit a given pair of IP addresses to one SCTP association per well known port. (SCTP ports 9, 20,21,22 *have* been registered, so somebody thought they might be used.) That isn't technically a problem now since the scope of the draft no longer includes SCTP over IP. Thanks, Paul > But, the offerer does need to get SOMETHING (the answer and/or the INIT) > from the answerer before the offerer can initiate the association. > > Regards, > > Christer > > > > >> One more clarification: >> >> On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat >> > wrote: >> >> I see *no* mention that the sctp-port value should be chosen >> randomly. And IMO it is unnatural to suggest port values be >> random. There could be reasons for them not being random - for >> instance interop with SCTP over IP with well known ports. Also, >> while there is currently no spec for multiple SCTP associations in >> the same bundle, it is not hard to imagine that that might be a >> useful thing to do in the future. In that case random port numbers >> could be more troublesome. >> >> >> SCTP associations described in this document are always simultaneous >> open (active/active) associations. Because of this sctp-port values >> are effectively emulating ephemeral ports allocated on the host >> system. Such ports are randomly allocated. I do not think well known >> SCTP ports would work with simultaneous open. This does not effect the >> ability to run multiple SCTP associations over the same underlying >> transport, since all this means that end point needs to allocate two >> different random sctp-port values. >> >> In any case, the option I was thinking about regarding sctp-port >> extension is to modify it to add support for URL parameters and to be >> something like a=sctp-port:6400;branch=abc3dl. The numeric part will >> be used in SCTP packets and the branch parameter will be used to >> indicate new/existing connection setup. >> >> Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> 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 Thu Jan 26 09:24:37 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 118E61298A4 for ; Thu, 26 Jan 2017 09:24:36 -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 EvViP-bbsGY9 for ; Thu, 26 Jan 2017 09:24:34 -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 41F40129881 for ; Thu, 26 Jan 2017 09:24:34 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-2b-588a30d0ed5a Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id D7.FD.14025.0D03A885; Thu, 26 Jan 2017 18:24:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 18:24:26 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg Date: Thu, 26 Jan 2017 17:24:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2J7lO4Fg64Ig0+nVC2mLn/MYvHgRy+b A5PH5MdzGD2WLPnJFMAUxWWTkpqTWZZapG+XwJVx5pdvwX+Vih+tU1gaGK/KdjFyckgImEi8 WHWSvYuRi0NIYB2jxM3Ow1DOYkaJVf97WLoYOTjYBCwkuv9pgzSICARJzG38wgRiCwtESxx6 e5kRIh4jcXbPYiYIO09i0t0+ZhCbRUBV4vLKPnYQm1fAV+LxxGdsEPNvs0jM/f6bDWQ+p4C9 xM8LqSA1jAJiEt9PrQGbwywgLnHryXwmiEMFJJbsOc8MYYtKvHz8jxXCVpJYsf0SI0S9jsSC 3Z/YIGxtiWULXzND7BWUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnrpRZl JhcX5+fp5aWWbGIERsPBLb9VdzBefuN4iFGAg1GJh7dgb0eEEGtiWXFl7iFGCQ5mJRHe11pd EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwMl4872ch tfSO/67eu+9qMjVY7GLVmvI5yg7Pb7Oob2X5ocn/2Drk+PQL62dxTl6ww1zFiOOt+aVD3kF7 o7vMsmdUPDSMsrnpwPZybV27aZvw9qXrQtf6zYlXsH7NX/l61Q+r4Gn3vss73lKb8sH95IGN Fscylj5+6nvGWGynvO7h2dcSPO48VmIpzkg01GIuKk4EAOKQqhWCAgAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 17:24:36 -0000 Hi, >>>In working through the ORTC SctpTransport implementation some of the=20 >>>oddities of SO became apparent. AFAICT existing implementations assume=20 >>>that the local and remote ports are the same and defaulting to 5000,=20 >>>which is funky. If one assumes that the remote port needs to be=20 >>>provided before an SCTP >> Association can be initiated, then does SO really make sense? The=20 >> Answerer will have the Local and remote ports first, so it will=20 >> initiate, but can the Offerer respond >>without receiving the Answer and the remote port? This doesn't seem >> like active/active, really. >> >> The offerer gets the port of the association initiated by the answerer=20 >> in the INIT sent from the answerer. And, the spec says that the same=20 >> ports must be used for both associations. >> >> "When an SCTP association is established, both SCTP endpoints MUST >> initiate the SCTP association (i.e. both SCTP endpoints take the >> 'active' role), and MUST use the same SCTP port as client port and >> server port (in order to prevent two separate SCTP associations from >> being established)." > > I hadn't noticed that. Given that, section 10.3 ought to have normative l= anguage to that effect. Right now, all it says is: > > o MUST associate an SDP 'sctp-port' attribute with the m- line. If > the offer contained a new (different than the one currently used) > SCTP port value the answerer MUST also associate a new SCTP port > value. If the offer contained a zero SCTP port value, or if the > answerer does not accept the SCTP association, the answerer MUST > also associate a zero SCTP port value; and Section 10.3 is about the offer/answer procedures, including assigning the = sctp-port value, while the other text is related to the SCTP establishment. >Also, while this constraint is workable with UDP/DTLS/SCTP and TCP/DTLS/SC= TP, it wouldn't be workable for SCTP directly over IP using well known port= s for *either* end, >because it would limit a given pair of IP addresses to= one SCTP association per well known port. (SCTP ports 9, 20,21,22 *have* b= een registered, so somebody thought they >might be used.) > >That isn't technically a problem now since the scope of the draft no longe= r includes SCTP over IP. Correct.=20 Regards, Christer > But, the offerer does need to get SOMETHING (the answer and/or the=20 > INIT) from the answerer before the offerer can initiate the association. > > Regards, > > Christer > > > > >> One more clarification: >> >> On Tue, Jan 24, 2017 at 4:10 PM, Paul Kyzivat=20 >> > wrote: >> >> I see *no* mention that the sctp-port value should be chosen >> randomly. And IMO it is unnatural to suggest port values be >> random. There could be reasons for them not being random - for >> instance interop with SCTP over IP with well known ports. Also, >> while there is currently no spec for multiple SCTP associations in >> the same bundle, it is not hard to imagine that that might be a >> useful thing to do in the future. In that case random port numbers >> could be more troublesome. >> >> >> SCTP associations described in this document are always simultaneous=20 >> open (active/active) associations. Because of this sctp-port values=20 >> are effectively emulating ephemeral ports allocated on the host=20 >> system. Such ports are randomly allocated. I do not think well known=20 >> SCTP ports would work with simultaneous open. This does not effect=20 >> the ability to run multiple SCTP associations over the same=20 >> underlying transport, since all this means that end point needs to=20 >> allocate two different random sctp-port values. >> >> In any case, the option I was thinking about regarding sctp-port=20 >> extension is to modify it to add support for URL parameters and to be=20 >> something like a=3Dsctp-port:6400;branch=3Dabc3dl. The numeric part will= =20 >> be used in SCTP packets and the branch parameter will be used to=20 >> indicate new/existing connection setup. >> >> Regards, >> _____________ >> Roman Shpount >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > 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 Thu Jan 26 09:54: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 B2BB51298C8 for ; Thu, 26 Jan 2017 09:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 TMku0NcHmhu8 for ; Thu, 26 Jan 2017 09:54:29 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (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 801DE1298BA for ; Thu, 26 Jan 2017 09:54:29 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-08v.sys.comcast.net with SMTP id WoFXcdGJKq95BWoFgcKMeg; Thu, 26 Jan 2017 17:54:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485453268; bh=NsNnxdVt2BkRGcga43K2B0LNCY0xcRwfAdFoC2ful8o=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MHF6zVsZUxHrTGKjHQJxYBms+p+AN4v/uTHWL4o9pQGSu5+1SHWZbuiok2h50zaV3 bY0UpazRGfycfH3RJHYfJVp58ZZ8I74b/ftFfqMk8eziSpRxpQbtOp+XVVgjcQJxQ7 U+xSKmGdu7KjrHmUw+DvJKdZVlOeGJjpR2TppgZojWla0WczmjCrTPm8EaY1UYAiMg i1YWmKpgK1GeDz0aBrrvjW412OqXe2hWQona0txrgxj+cAZbSpOTJIvm6vl7dDFXnB wSe0Zoor+amlKkLZW9QUDuF/jsppTAINKMaYiKAwn5YIOmC0L40PzDTN/AGR6SwXoc bZf67NdMJiKqg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-09v.sys.comcast.net with SMTP id WoFfcD7XAcScxWoFgcgQFX; Thu, 26 Jan 2017 17:54:28 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> Date: Thu, 26 Jan 2017 12:54:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfCC5Dmf/QoEGYw5WCziVFtSeXhnteyHXcDaaO98g80DK7+AFgGTwI2w4eUiSNJL71cdhfLMCya2pSOgapDOIwZma95hT2ucRdfrQRWJnfP42C5DDGVK0 uuIqLO9pvBnaZuP1izLBeiTlcv3EN453kC/MquLNItVLugQN9rrUe9lCFuNh3ud/iZI29Z9btvaQcQ== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 17:54:31 -0000 On 1/26/17 12:24 PM, Christer Holmberg wrote: > Hi, > >>>> In working through the ORTC SctpTransport implementation some of the >>>> oddities of SO became apparent. AFAICT existing implementations assume >>>> that the local and remote ports are the same and defaulting to 5000, >>>> which is funky. If one assumes that the remote port needs to be >>>> provided before an SCTP >>> Association can be initiated, then does SO really make sense? The >>> Answerer will have the Local and remote ports first, so it will >>> initiate, but can the Offerer respond >>> without receiving the Answer and the remote port? This doesn't seem >>> like active/active, really. >>> >>> The offerer gets the port of the association initiated by the answerer >>> in the INIT sent from the answerer. And, the spec says that the same >>> ports must be used for both associations. >>> >>> "When an SCTP association is established, both SCTP endpoints MUST >>> initiate the SCTP association (i.e. both SCTP endpoints take the >>> 'active' role), and MUST use the same SCTP port as client port and >>> server port (in order to prevent two separate SCTP associations from >>> being established)." >> >> I hadn't noticed that. Given that, section 10.3 ought to have normative language to that effect. Right now, all it says is: >> >> o MUST associate an SDP 'sctp-port' attribute with the m- line. If >> the offer contained a new (different than the one currently used) >> SCTP port value the answerer MUST also associate a new SCTP port >> value. If the offer contained a zero SCTP port value, or if the >> answerer does not accept the SCTP association, the answerer MUST >> also associate a zero SCTP port value; and > > Section 10.3 is about the offer/answer procedures, including assigning the sctp-port value, while the other text is related to the SCTP establishment. Yes, but they need to be consistent. As currently written, it would be valid for the answerer to include a different sctp-port value in the answer, as long as it then ignores that and uses the value from the offer in the protocol. Thanks, Paul From nobody Thu Jan 26 10:03: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 546B0129952 for ; Thu, 26 Jan 2017 10:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 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, 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 rJ3tkk_bjl4d for ; Thu, 26 Jan 2017 10:03:32 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ABCD129951 for ; Thu, 26 Jan 2017 10:03:32 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id w194so154807860ybe.0 for ; Thu, 26 Jan 2017 10:03:32 -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=nwQTO9vX5SzIeQ55r1QeKlZLF1676bePP+m1U8Xrjss=; b=iZMJkYsOMP6kPklqRG0BdcAuIoWaMHJM+n1OrO3X0/lxtbE4uAv7VmWVcSHGiAgKA/ yW72yJpAvTzL0Ej1muNCkAW+3D8nZeULMSamMIxmogjnCyz/DnyxtEyZFQAjNpub069k z9F2kjTC0ZDq3F38dqMLnSxNumQDpcG31FtRHXWJAASrf2UsaSWtfXbcpDOGKXYIErA7 vdvPo9gNMdzv3BKpRwWsg2zNpAogcWCQJa2unLI9Uf0X0+08C+dIwmIwNOw0e7szXSfc mlqy969WEC7u6f6K4eiac1ej/JSfXQhboeYoyevuSfviNT4zvBg8iefZ2YCYgmVQeQIE aDCA== 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=nwQTO9vX5SzIeQ55r1QeKlZLF1676bePP+m1U8Xrjss=; b=eBudcMdBq4Xd0C9STyy3Eneo38ZyooKhyEBU1O1xTndtck5Yl7S8QlfrW6Qm3sSZ3i kARmVZBG4HQb2BV+3H47+3j/xit3CwwvrxoR1PjxQJN7fMquZaIlzYmRTM3hPeK0cJ4O OWMLyoeVqRhnmdyunrD7/xVLDP+cvrgwuAa+QNrsE6GDEEgEs7XBbGXVAn48eoDh/THd 15YxbaFp19A7HqPHT2HAZMJeLINIVqMXuFdB9tvZt3/iMTnbWjviuTfeVGtzpMJvL1AU Yb40KMJVn80MJ7RPUtGrk4JglDOGFWrFXq5Rn9Qrdj9F9e2MH7IMlDl9PVmk1V1EmPZd Nl3g== X-Gm-Message-State: AIkVDXJs77czo6x68JBh3cCXa+qlzoqwG/0/N7r9mJlT8xMwoaifgeY3iIhWjs3mpf2z4w== X-Received: by 10.129.84.68 with SMTP id i65mr2828790ywb.38.1485453811274; Thu, 26 Jan 2017 10:03:31 -0800 (PST) Received: from mail-yb0-f182.google.com (mail-yb0-f182.google.com. [209.85.213.182]) by smtp.gmail.com with ESMTPSA id c75sm1158250ywb.4.2017.01.26.10.03.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:03:30 -0800 (PST) Received: by mail-yb0-f182.google.com with SMTP id f67so48188958ybc.2 for ; Thu, 26 Jan 2017 10:03:30 -0800 (PST) X-Received: by 10.55.47.69 with SMTP id v66mr4060766qkh.222.1485453810360; Thu, 26 Jan 2017 10:03:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.131.66 with HTTP; Thu, 26 Jan 2017 10:03:29 -0800 (PST) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> From: Roman Shpount Date: Thu, 26 Jan 2017 13:03:29 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a114f4ec4b29e8d0547032a41 Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:03:33 -0000 --001a114f4ec4b29e8d0547032a41 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 26, 2017 at 3:39 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >In working through the ORTC SctpTransport implementation some of the > oddities of SO became apparent. AFAICT existing implementations assume that > the local and remote ports are the same and defaulting to 5000, which is > funky. If > >one assumes that the remote port needs to be provided before an SCTP > Association can be initiated, then does SO really make sense? The Answerer > will have the Local and remote ports first, so it will initiate, but can > the Offerer respond > >without receiving the Answer and the remote port? This doesn't seem like > active/active, really. > > The offerer gets the port of the association initiated by the answerer in > the INIT sent from the answerer. And, the spec says that the same ports > must be used for both associations. > > "When an SCTP association is established, both SCTP endpoints MUST > initiate the SCTP association (i.e. both SCTP endpoints take the > 'active' role), and MUST use the same SCTP port as client port and > server port (in order to prevent two separate SCTP associations from > being established)." > > I just wanted to double check, is everyone sure that SCTP client and server ports MUST be the same? If this is the case, sctp-port cannot be used to indicate that new SCTP association should be established. We need some additional indicate to signal this. Regards, _____________ Roman Shpount --001a114f4ec4b29e8d0547032a41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 26, 2017 at 3:39 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

>In working through the ORTC SctpTransport implementation some of t= he oddities of SO became apparent. AFAICT existing implementations assume t= hat the local and remote ports are the same and defaulting to 5000, which i= s funky. If
>one assumes that the remote port needs to be provided before an SC= TP Association can be initiated, then does SO really make sense? The Answer= er will have the Local and remote ports first, so it will initiate, but can= the Offerer respond=C2=A0
>without receiving the Answer and the remote port?=C2=A0 This doesn= 't seem like active/active, really.

The offerer gets the port of the association initiated by the a= nswerer in the INIT sent from the answerer. And, the spec says that the sam= e ports must be used for both associations.

   "When an SCTP association is established, both SCTP end=
points MUST
   initiate the SCTP association (i.e. both SCTP endpoints take the
   'active' role), and MUST use the same SCTP port as client port a=
nd
   server port (in order to prevent two separate SCTP associations from
   being established)."

<= div>I just wanted to double check, is everyone sure that SCTP client and se= rver ports MUST be the same? If this is the case, sctp-port cannot be used = to indicate that new SCTP association should be established. We need some a= dditional indicate to signal this.

Regards,
<= div>
_____________
Roman Shpount
=C2=A0
--001a114f4ec4b29e8d0547032a41-- From nobody Thu Jan 26 10:17:37 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 E01CC129964 for ; Thu, 26 Jan 2017 10:17:35 -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 K7SUttNaG9V2 for ; Thu, 26 Jan 2017 10: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 135EF129961 for ; Thu, 26 Jan 2017 10:17:32 -0800 (PST) X-AuditID: c1b4fb25-1cbff700000036c9-65-588a3d394f88 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 42.84.14025.93D3A885; Thu, 26 Jan 2017 19:17:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 19:17:28 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwA== Date: Thu, 26 Jan 2017 18:17:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> In-Reply-To: <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7q661bVeEweGbAhZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4s8G0YKNwxaKJug2My/m7GDk5JARMJJa/ nMXaxcjFISSwjlHiw7dudghnMaPEnn2rmbsYOTjYBCwkuv9pgzSICARJzG38wgRiCwtESxx6 e5kRIh4jcXbPYiYIu07i2/79bCCtLAKqEt++S4GEeQV8JZ61LWeEGH+FVeLcz+ssIDWcAvYS b7cng9QwCohJfD+1BmwMs4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSWLF9kuMEPU6Egt2 f2KDsLUlli18zQyxV1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYCQe3/FbdwXj5jeMhRgEORiUe3oK9HRFCrIllxZW5hxglOJiVRHhXG3VF CPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cBovHG2Qp2P z04vv17fM0H3tCXc5bYkK3z41WkTqrTrcZScDZOdjdFEy3UPN73Jf9fAznflkWTCk8m5rrae uxOPRvVkBT5Y8HyRydevRaeXhykWXW/dln/m992pjyO6fv7feFXQ4cAky8WakVURpzivZvfs fXstx2jGphq19vbj7ydktKV0h1xQYinOSDTUYi4qTgQAZT2slIACAAA= Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:17:36 -0000 Hi, >>>>> In working through the ORTC SctpTransport implementation some of=20 >>>>> the oddities of SO became apparent. AFAICT existing implementations=20 >>>>> assume that the local and remote ports are the same and defaulting=20 >>>>> to 5000, which is funky. If one assumes that the remote port needs=20 >>>>> to be provided before an SCTP >>>> Association can be initiated, then does SO really make sense? The=20 >>>> Answerer will have the Local and remote ports first, so it will=20 >>>> initiate, but can the Offerer respond without receiving the Answer=20 >>>> and the remote port? This doesn't seem like active/active, really. >>>> >>>> The offerer gets the port of the association initiated by the=20 >>>> answerer in the INIT sent from the answerer. And, the spec says that=20 >>>> the same ports must be used for both associations. >>>> >>>> "When an SCTP association is established, both SCTP endpoints MUST >>>> initiate the SCTP association (i.e. both SCTP endpoints take the >>>> 'active' role), and MUST use the same SCTP port as client port and >>>> server port (in order to prevent two separate SCTP associations fro= m >>>> being established)." >>> >>> I hadn't noticed that. Given that, section 10.3 ought to have normative= language to that effect. Right now, all it says is: >>> >>> o MUST associate an SDP 'sctp-port' attribute with the m- line. If >>> the offer contained a new (different than the one currently used) >>> SCTP port value the answerer MUST also associate a new SCTP port >>> value. If the offer contained a zero SCTP port value, or if the >>> answerer does not accept the SCTP association, the answerer MUST >>> also associate a zero SCTP port value; and >> >> Section 10.3 is about the offer/answer procedures, including assigning t= he sctp-port value, while the other text is related to the SCTP establishme= nt. > > Yes, but they need to be consistent. As currently written, it would be va= lid for the answerer to include a different sctp-port value in the answer, = as long as it then ignores=20 > that and uses the value from the offer in the protocol. It IS valid for the answerer the include a different sctp-port value. What the text means is that and endpoint needs to use the same local port f= or sending and receiving SCTP messages. But, both endpoints don't need to u= se the same port value. Regards, Christer =20 From nobody Thu Jan 26 10:19: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 2CE09129965 for ; Thu, 26 Jan 2017 10:19:31 -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 hRQjKFPQ6wX5 for ; Thu, 26 Jan 2017 10:19:29 -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 26874129961 for ; Thu, 26 Jan 2017 10:19:28 -0800 (PST) X-AuditID: c1b4fb25-1dfff700000036c9-ad-588a3dad38a6 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 30.B4.14025.DAD3A885; Thu, 26 Jan 2017 19:19:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 19:19:25 +0100 From: Christer Holmberg To: Roman Shpount Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAAD3f8gAACniTg Date: Thu, 26 Jan 2017 18:19:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4A75@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFC4A75ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7me56264Ig/5eOYsN+/4zW0xd/pjF 4sGPXjaLGRemMjuweEx+PIfRY+esu+weS5b8ZPK4NaUggCWKyyYlNSezLLVI3y6BK+PbmTNs BcvyK15M+M3ewLgkp4uRk0NCwETi8aw9bCC2kMA6Rok9HSJdjFxA9mJGiY4DZ4ESHBxsAhYS 3f+0QWpEBFQl/n6fzARiMwtUS/zrnsgIYgsLREscenuZEaImRuLsnsVMIK0iAnkSPRc4QEwW oNaJy9NBKngFfCW6ts5hh9j0lkXi+ofd7CAJToFAifYnC5hBbEYBMYnvp9ZArRKXuPVkPhPE yQISS/acZ4awRSVePv7HCmErSazYfokRoj5fYuqGTlaIZYISJ2c+YZnAKDILyahZSMpmISmb BXQqs4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eX WrKJERh3B7f8Vt3BePmN4yFGAQ5GJR7egr0dEUKsiWXFlbmHGCU4mJVEeFcbdUUI8aYkVlal FuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwFhhUij1/sKOvXUym6zZ b3x/tFxS0zCcvaxcf/Z1xv8sb2y6dM1WtgnyWQmbLnrWEnlZ4cf6VAt/mU0dkvKqpSoFZ/9E L6uc+K7i1M4J0mdfBqteZLeU4528Z8J+L6YX6RUHt8StDV8Rvs7FS/BfVZmvrmOWa/dP25nO U2WdKjSOmnJKGS7OUmIpzkg01GIuKk4EAJEtM/O3AgAA Archived-At: Cc: Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:19:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFC4A75ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoZSB0ZXh0IG1lYW5zIHRoYXQgZWFjaCBlbmRwb2ludCBtdXN0IHNlbmQgYW5kIHJl Y2VpdmUgU0NUUCBtZXNzYWdlcyBvbiB0aGUgc2FtZSBsb2NhbCBwb3J0LiBJdCBkb2VzIE5PVCBt ZWFuIHRoYXQgZWFjaCBlbmRwb2ludCBtdXN0IGFzc2lnbiB0aGUgc2FtZSBzY3RwLXBvcnQgdmFs dWUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFJvbWFuIFNocG91bnQgW21haWx0 bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IDI2IEphbnVhcnkgMjAxNyAyMDowMw0KVG86IENo cmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogQmVy bmFyZCBBYm9iYSA8YmVybmFyZC5hYm9iYUBnbWFpbC5jb20+OyBQYXVsIEt5eml2YXQgPHBhdWwu a3l6aXZhdEBjb21jYXN0Lm5ldD47IG1tdXNpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtNTVVT SUNdIEFEIEV2YWx1YXRpb24gb2YgZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAtMjEgLSBURUNI TklDQUwgY29tbWVudHMNCg0KT24gVGh1LCBKYW4gMjYsIDIwMTcgYXQgMzozOSBBTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPkluIHdvcmtpbmcgdGhy b3VnaCB0aGUgT1JUQyBTY3RwVHJhbnNwb3J0IGltcGxlbWVudGF0aW9uIHNvbWUgb2YgdGhlIG9k ZGl0aWVzIG9mIFNPIGJlY2FtZSBhcHBhcmVudC4gQUZBSUNUIGV4aXN0aW5nIGltcGxlbWVudGF0 aW9ucyBhc3N1bWUgdGhhdCB0aGUgbG9jYWwgYW5kIHJlbW90ZSBwb3J0cyBhcmUgdGhlIHNhbWUg YW5kIGRlZmF1bHRpbmcgdG8gNTAwMCwgd2hpY2ggaXMgZnVua3kuIElmDQo+b25lIGFzc3VtZXMg dGhhdCB0aGUgcmVtb3RlIHBvcnQgbmVlZHMgdG8gYmUgcHJvdmlkZWQgYmVmb3JlIGFuIFNDVFAg QXNzb2NpYXRpb24gY2FuIGJlIGluaXRpYXRlZCwgdGhlbiBkb2VzIFNPIHJlYWxseSBtYWtlIHNl bnNlPyBUaGUgQW5zd2VyZXIgd2lsbCBoYXZlIHRoZSBMb2NhbCBhbmQgcmVtb3RlIHBvcnRzIGZp cnN0LCBzbyBpdCB3aWxsIGluaXRpYXRlLCBidXQgY2FuIHRoZSBPZmZlcmVyIHJlc3BvbmQNCj53 aXRob3V0IHJlY2VpdmluZyB0aGUgQW5zd2VyIGFuZCB0aGUgcmVtb3RlIHBvcnQ/ICBUaGlzIGRv ZXNuJ3Qgc2VlbSBsaWtlIGFjdGl2ZS9hY3RpdmUsIHJlYWxseS4NCg0KVGhlIG9mZmVyZXIgZ2V0 cyB0aGUgcG9ydCBvZiB0aGUgYXNzb2NpYXRpb24gaW5pdGlhdGVkIGJ5IHRoZSBhbnN3ZXJlciBp biB0aGUgSU5JVCBzZW50IGZyb20gdGhlIGFuc3dlcmVyLiBBbmQsIHRoZSBzcGVjIHNheXMgdGhh dCB0aGUgc2FtZSBwb3J0cyBtdXN0IGJlIHVzZWQgZm9yIGJvdGggYXNzb2NpYXRpb25zLg0KDQoN CiAgICJXaGVuIGFuIFNDVFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQsIGJvdGggU0NUUCBl bmRwb2ludHMgTVVTVA0KDQogICBpbml0aWF0ZSB0aGUgU0NUUCBhc3NvY2lhdGlvbiAoaS5lLiBi b3RoIFNDVFAgZW5kcG9pbnRzIHRha2UgdGhlDQoNCiAgICdhY3RpdmUnIHJvbGUpLCBhbmQgTVVT VCB1c2UgdGhlIHNhbWUgU0NUUCBwb3J0IGFzIGNsaWVudCBwb3J0IGFuZA0KDQogICBzZXJ2ZXIg cG9ydCAoaW4gb3JkZXIgdG8gcHJldmVudCB0d28gc2VwYXJhdGUgU0NUUCBhc3NvY2lhdGlvbnMg ZnJvbQ0KDQogICBiZWluZyBlc3RhYmxpc2hlZCkuIg0KDQpJIGp1c3Qgd2FudGVkIHRvIGRvdWJs ZSBjaGVjaywgaXMgZXZlcnlvbmUgc3VyZSB0aGF0IFNDVFAgY2xpZW50IGFuZCBzZXJ2ZXIgcG9y dHMgTVVTVCBiZSB0aGUgc2FtZT8gSWYgdGhpcyBpcyB0aGUgY2FzZSwgc2N0cC1wb3J0IGNhbm5v dCBiZSB1c2VkIHRvIGluZGljYXRlIHRoYXQgbmV3IFNDVFAgYXNzb2NpYXRpb24gc2hvdWxkIGJl IGVzdGFibGlzaGVkLiBXZSBuZWVkIHNvbWUgYWRkaXRpb25hbCBpbmRpY2F0ZSB0byBzaWduYWwg dGhpcy4NCg0KUmVnYXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4BFC4A75ESESSMB209erics_ 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 c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmdtYWlsLQ0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgdGV4dCBtZWFucyB0aGF0IGVhY2gg ZW5kcG9pbnQgbXVzdCBzZW5kIGFuZCByZWNlaXZlIFNDVFAgbWVzc2FnZXMgb24gdGhlIHNhbWUg bG9jYWwgcG9ydC4gSXQgZG9lcyBOT1QgbWVhbiB0aGF0IGVhY2ggZW5kcG9pbnQgbXVzdA0KIGFz c2lnbiB0aGUgc2FtZSBzY3RwLXBvcnQgdmFsdWUuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9tYW4g U2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI2 IEphbnVhcnkgMjAxNyAyMDowMzxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0 O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEJlcm5h cmQgQWJvYmEgJmx0O2Jlcm5hcmQuYWJvYmFAZ21haWwuY29tJmd0OzsgUGF1bCBLeXppdmF0ICZs dDtwYXVsLmt5eml2YXRAY29tY2FzdC5uZXQmZ3Q7OyBtbXVzaWNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtNTVVTSUNdIEFEIEV2YWx1YXRpb24gb2YgZHJhZnQtaWV0Zi1tbXVz aWMtc2N0cC1zZHAtMjEgLSBURUNITklDQUwgY29tbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyNiwgMjAx NyBhdCAzOjM5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1i ZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZndDtJbiB3b3JraW5nIHRocm91Z2ggdGhlIE9SVEMgU2N0cFRyYW5zcG9ydCBpbXBs ZW1lbnRhdGlvbiBzb21lIG9mIHRoZSBvZGRpdGllcyBvZiBTTyBiZWNhbWUgYXBwYXJlbnQuIEFG QUlDVCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYXNzdW1lIHRoYXQgdGhlIGxvY2FsIGFuZA0K IHJlbW90ZSBwb3J0cyBhcmUgdGhlIHNhbWUgYW5kIGRlZmF1bHRpbmcgdG8gNTAwMCwgd2hpY2gg aXMgZnVua3kuIElmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jmd0O29uZSBhc3N1bWVzIHRoYXQgdGhlIHJlbW90ZSBwb3J0IG5lZWRzIHRvIGJlIHByb3Zp ZGVkIGJlZm9yZSBhbiBTQ1RQIEFzc29jaWF0aW9uIGNhbiBiZSBpbml0aWF0ZWQsIHRoZW4gZG9l cyBTTyByZWFsbHkgbWFrZSBzZW5zZT8gVGhlIEFuc3dlcmVyIHdpbGwgaGF2ZSB0aGUgTG9jYWwN CiBhbmQgcmVtb3RlIHBvcnRzIGZpcnN0LCBzbyBpdCB3aWxsIGluaXRpYXRlLCBidXQgY2FuIHRo ZSBPZmZlcmVyIHJlc3BvbmQmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZn dDt3aXRob3V0IHJlY2VpdmluZyB0aGUgQW5zd2VyIGFuZCB0aGUgcmVtb3RlIHBvcnQ/Jm5ic3A7 IFRoaXMgZG9lc24ndCBzZWVtIGxpa2UgYWN0aXZlL2FjdGl2ZSwgcmVhbGx5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5UaGUgb2ZmZXJlciBnZXRzIHRoZSBwb3J0IG9mIHRoZSBhc3NvY2lhdGlvbiBpbml0aWF0ZWQg YnkgdGhlIGFuc3dlcmVyIGluIHRoZSBJTklUIHNlbnQgZnJvbSB0aGUgYW5zd2VyZXIuIEFuZCwg dGhlIHNwZWMgc2F5cyB0aGF0IHRoZSBzYW1lIHBvcnRzIG11c3QgYmUgdXNlZCBmb3INCiBib3Ro IGFzc29jaWF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImZvbnQtdmFyaWFu dC1saWdhdHVyZXM6bm9ybWFsO3dvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13 cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAmcXVvdDtXaGVuIGFu IFNDVFAgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQsIGJvdGggU0NUUCBlbmRwb2ludHMgTVVT VDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBpbml0aWF0ZSB0aGUgU0NUUCBhc3NvY2lhdGlvbiAoaS5lLiBib3RoIFND VFAgZW5kcG9pbnRzIHRha2UgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICdhY3RpdmUnIHJvbGUpLCBhbmQgTVVT VCB1c2UgdGhlIHNhbWUgU0NUUCBwb3J0IGFzIGNsaWVudCBwb3J0IGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBz ZXJ2ZXIgcG9ydCAoaW4gb3JkZXIgdG8gcHJldmVudCB0d28gc2VwYXJhdGUgU0NUUCBhc3NvY2lh dGlvbnMgZnJvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBiZWluZyBlc3RhYmxpc2hlZCkuJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBqdXN0IHdhbnRlZCB0byBkb3VibGUgY2hlY2ssIGlzIGV2 ZXJ5b25lIHN1cmUgdGhhdCBTQ1RQIGNsaWVudCBhbmQgc2VydmVyIHBvcnRzIE1VU1QgYmUgdGhl IHNhbWU/IElmIHRoaXMgaXMgdGhlIGNhc2UsIHNjdHAtcG9ydCBjYW5ub3QgYmUgdXNlZCB0byBp bmRpY2F0ZSB0aGF0IG5ldyBTQ1RQIGFzc29jaWF0aW9uIHNob3VsZCBiZSBlc3RhYmxpc2hlZC4g V2UgbmVlZCBzb21lIGFkZGl0aW9uYWwgaW5kaWNhdGUNCiB0byBzaWduYWwgdGhpcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BFC4A75ESESSMB209erics_-- From nobody Thu Jan 26 10:54:03 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 996F612998C for ; Thu, 26 Jan 2017 10:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 6BGS0WHuK9pJ for ; Thu, 26 Jan 2017 10:54:00 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 80CF512996D for ; Thu, 26 Jan 2017 10:54:00 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-04v.sys.comcast.net with SMTP id WpBCczStIGIgtWpBHc5ETa; Thu, 26 Jan 2017 18:53:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485456839; bh=pEX5eRejCwxCZ7sKwLk8OoRY/+O9HINRyis8e4Nbt5M=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CXA6F7m0qGcph2HuJsL+6fsB9XqS7aFybynL+fpm8IePAN6h/VUcaEjB0C3vperYU IjEcc8dQaWdqQ+pCg1ia5rIxI2g0h6yedoEneA5WraeqiAL1ayETwYx9Z7Mf962Cd4 AF3WuTGFFa3qxpKuTknPYlEf8fwrDgN7hxoYOKF5HIkfV/1Ku9QyvNIFMgXJYxyrer r3V1wElOJJBThegwvUNjOLnwqFHrJ8LAIAVVR8ZCbmXR8G7+zemMeu0/88P/y/5PtN NOYfWr5Me3K/029ylODlohBxxaOzj8sCv2YsRnjPNGZG3eCAxDsVEKlvnrNE+GpjHS tG7q/tmtFfqKQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-15v.sys.comcast.net with SMTP id WpBGcHbBdwcMxWpBGckSGN; Thu, 26 Jan 2017 18:53:59 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 26 Jan 2017 13:53:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJV+sFb7ZjokfyXD6e4JUYaB6VGkRnuxkO7Q9sHFIwrCe4XdlyvViC1Sr4g7gZfDURz34HLNcuR06pSlwV7nr1Lq4U3tOpBOuq3qVcsnX/TNGqqCyzNh arjaHjGUqxiDhKXZ3KTxhfPuh7VQFrFBREOHWxE5JBbsPTn/0wOnhe/P3BSifJZ+bNhEd7JYZBckEsST8JyoepE0pPX6nxg/Y4dw++U/VLWpKDKV50J0njIA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:54:01 -0000 On 1/26/17 1:17 PM, Christer Holmberg wrote: > Hi, > >>>>>> In working through the ORTC SctpTransport implementation some of >>>>>> the oddities of SO became apparent. AFAICT existing implementations >>>>>> assume that the local and remote ports are the same and defaulting >>>>>> to 5000, which is funky. If one assumes that the remote port needs >>>>>> to be provided before an SCTP >>>>> Association can be initiated, then does SO really make sense? The >>>>> Answerer will have the Local and remote ports first, so it will >>>>> initiate, but can the Offerer respond without receiving the Answer >>>>> and the remote port? This doesn't seem like active/active, really. >>>>> >>>>> The offerer gets the port of the association initiated by the >>>>> answerer in the INIT sent from the answerer. And, the spec says that >>>>> the same ports must be used for both associations. >>>>> >>>>> "When an SCTP association is established, both SCTP endpoints MUST >>>>> initiate the SCTP association (i.e. both SCTP endpoints take the >>>>> 'active' role), and MUST use the same SCTP port as client port and >>>>> server port (in order to prevent two separate SCTP associations from >>>>> being established)." >>>> >>>> I hadn't noticed that. Given that, section 10.3 ought to have normative language to that effect. Right now, all it says is: >>>> >>>> o MUST associate an SDP 'sctp-port' attribute with the m- line. If >>>> the offer contained a new (different than the one currently used) >>>> SCTP port value the answerer MUST also associate a new SCTP port >>>> value. If the offer contained a zero SCTP port value, or if the >>>> answerer does not accept the SCTP association, the answerer MUST >>>> also associate a zero SCTP port value; and >>> >>> Section 10.3 is about the offer/answer procedures, including assigning the sctp-port value, while the other text is related to the SCTP establishment. >> >> Yes, but they need to be consistent. As currently written, it would be valid for the answerer to include a different sctp-port value in the answer, as long as it then ignores >> that and uses the value from the offer in the protocol. > > It IS valid for the answerer the include a different sctp-port value. > > What the text means is that and endpoint needs to use the same local port for sending and receiving SCTP messages. But, both endpoints don't need to use the same port value. You mean symmetric use of the sctp-port values? For instance, if A offers sctp-port:5000 and B offers sctp-port:6000, then messages sent from A to B must have 5000 as the from-port and 6000 as the to-port; and messages sent from B to A must have 6000 as the from-port and 5000 as the to-port. Given that was your point, lets go back to what you said that triggered this part of the thread: > The offerer gets the port of the association initiated by the answerer in the INIT sent from the answerer. And, the spec says that the same ports must be used for both associations. > > "When an SCTP association is established, both SCTP endpoints MUST > initiate the SCTP association (i.e. both SCTP endpoints take the > 'active' role), and MUST use the same SCTP port as client port and > server port (in order to prevent two separate SCTP associations from > being established)." > > But, the offerer does need to get SOMETHING (the answer and/or the INIT) from the answerer before the offerer can initiate the association. You are assuming here that there is only one SCTP association at a time over the lower layer (in this case DTLS). If there might be more than one such association then the offerer can't assume that the port number in the incoming INIT pertains to *this* association. After all, the *point* of port numbers is to demux sessions over the lower layer. Now this is a valid as long as multiple SCTP associations aren't bundled over the same DTLS UDP/TCP ports. Since doing such bundling is *currently* undefined, it can work for now. But it would make perfect sense to define bundlilng of multiple SCTP associations, using the sctp-port values for the demuxing. So in my opinion we ought not be spelling out procedures for SCTP association establishment that only work in this limited case. Hence it should be presumed that the offerer can't initiate the SCTP association until it receives the answer. Thanks, Paul From nobody Thu Jan 26 11:11: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 C7C10129980 for ; Thu, 26 Jan 2017 11:11:44 -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 hOf6BfRgrVav for ; Thu, 26 Jan 2017 11:11:42 -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 E2AAA1298C0 for ; Thu, 26 Jan 2017 11:11:41 -0800 (PST) X-AuditID: c1b4fb25-1dfff700000036c9-90-588a49ea2346 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by (Symantec Mail Security) with SMTP id B9.4A.14025.AE94A885; Thu, 26 Jan 2017 20:11:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 20:11:37 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwIAAJzWA///s1jA= Date: Thu, 26 Jan 2017 19:11:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7se5rz64Ig8OvbCymLn/MYvHgRy+b A5PH5MdzGD2WLPnJFMAUxWWTkpqTWZZapG+XwJXx4dAs5oKX6hWT3m5ibmA8It/FyMkhIWAi MWXfVaYuRi4OIYF1jBIzz01kg3AWM0psa9wK5HBwsAlYSHT/0wZpEBEIkpjb+IUJxBYWiJY4 9PYyI0Q8RuLsnsVgg0QEuhgl+ld+YATpZRFQldjdbAJSwyvgK7FnYRvUsrNsEi9637GBJDgF 7CVOPe9iAbEZBcQkvp9aA7aAWUBc4taT+UwQlwpILNlznhnCFpV4+fgfK4StJLFi+yVGiHod iQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMIrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03MtZL LcpMLi7Oz9PLSy3ZxAiMiINbfqvuYLz8xvEQowAHoxIPr4F7V4QQa2JZcWXuIUYJDmYlEd4d tkAh3pTEyqrUovz4otKc1OJDjNIcLErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGH0aTymy iwtdX+Fw78EFkc+/GPP33OC4r1Bu1XHn6Hq9snaJ3EX+hw+FHXpzQHZf1ZE5El0a5Vs/xv75 0bT5YGOV/9L1uZkLtk491DJFyuPGtfklWvU2zw337J3yr/uS/6r883nWNSEtCpkPnk6sXff5 27XXcWV3WFy4/vy9d+dbB3/G96pWtZ1KLMUZiYZazEXFiQA5sT1lhAIAAA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:11:45 -0000 Hi, >>>>>>> In working through the ORTC SctpTransport implementation some of=20 >>>>>>> the oddities of SO became apparent. AFAICT existing=20 >>>>>>> implementations assume that the local and remote ports are the=20 >>>>>>> same and defaulting to 5000, which is funky. If one assumes that=20 >>>>>>> the remote port needs to be provided before an SCTP >>>>>> Association can be initiated, then does SO really make sense? The=20 >>>>>> Answerer will have the Local and remote ports first, so it will=20 >>>>>> initiate, but can the Offerer respond without receiving the Answer=20 >>>>>> and the remote port? This doesn't seem like active/active, really. >>>>>> >>>>>> The offerer gets the port of the association initiated by the=20 >>>>>> answerer in the INIT sent from the answerer. And, the spec says=20 >>>>>> that the same ports must be used for both associations. >>>>>> >>>>>> "When an SCTP association is established, both SCTP endpoints MUS= T >>>>>> initiate the SCTP association (i.e. both SCTP endpoints take the >>>>>> 'active' role), and MUST use the same SCTP port as client port an= d >>>>>> server port (in order to prevent two separate SCTP associations f= rom >>>>>> being established)." >>>>> >>>>> I hadn't noticed that. Given that, section 10.3 ought to have normati= ve language to that effect. Right now, all it says is: >>>>> >>>>> o MUST associate an SDP 'sctp-port' attribute with the m- line. = If >>>>> the offer contained a new (different than the one currently use= d) >>>>> SCTP port value the answerer MUST also associate a new SCTP por= t >>>>> value. If the offer contained a zero SCTP port value, or if th= e >>>>> answerer does not accept the SCTP association, the answerer MUS= T >>>>> also associate a zero SCTP port value; and >>>> >>>> Section 10.3 is about the offer/answer procedures, including assigning= the sctp-port value, while the other text is related to the SCTP establish= ment. >>> >>> Yes, but they need to be consistent. As currently written, it would=20 >>> be valid for the answerer to include a different sctp-port value in the= answer, as long as it then ignores that and uses the value from the offer = in the protocol. >> >> It IS valid for the answerer the include a different sctp-port value. >> >> What the text means is that and endpoint needs to use the same local por= t for sending and receiving SCTP messages. But, both endpoints don't=20 >> need to use the same port value. > > You mean symmetric use of the sctp-port values? Correct. > For instance, if A offers sctp-port:5000 and B offers sctp-port:6000, the= n messages sent from A to B must=20 > have 5000 as the from-port and 6000 as the to-port; and messages sent fro= m B to A must have 6000 as the from-port and 5000 as the to-port. Yes. > Given that was your point, lets go back to what you said that triggered t= his part of the thread: > > The offerer gets the port of the association initiated by the answerer in= the INIT sent from the=20 > answerer. And, the spec says that the same ports must be used for both as= sociations. > > "When an SCTP association is established, both SCTP endpoints MUST > initiate the SCTP association (i.e. both SCTP endpoints take the > 'active' role), and MUST use the same SCTP port as client port and > server port (in order to prevent two separate SCTP associations from > being established)." > > But, the offerer does need to get SOMETHING (the answer and/or the INIT) = from the answerer before the offerer can initiate the association. > > You are assuming here that there is only one SCTP association at a time o= ver the lower layer (in this case DTLS). If there=20 > might be more than one such association then the offerer can't assume tha= t the port number in the incoming INIT pertains=20 > to *this* association. After all, the *point* of port numbers is to demux= sessions over the lower layer. > > Now this is a valid as long as multiple SCTP associations aren't bundled = over the same DTLS UDP/TCP ports. Since doing=20 > such bundling is *currently* undefined, it can work for now. But it would= make perfect sense to define bundlilng of multiple=20 > SCTP associations, using the sctp-port values for the demuxing. So in my = opinion we ought not be spelling out procedures for=20 > SCTP association establishment that only work in this limited case. Hence= it should be presumed that the offerer can't initiate=20 > the SCTP association until it receives the answer. We are assuming a single SCTP association, and that is also documented in t= he draft. Section 7 says: "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP associations on top of a single DTLS association, the procedures in this specification only support the negotiation of a single SCTP association on top of any given DTLS association." I do not think this is the time to change that assumption.=20 Regards, Christer From nobody Thu Jan 26 11:29: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 A86B81299D5 for ; Thu, 26 Jan 2017 11:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 geft1aAczc41 for ; Thu, 26 Jan 2017 11:29:29 -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 834481299C8 for ; Thu, 26 Jan 2017 11:29:29 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-01v.sys.comcast.net with SMTP id WpjRcqIL9RNZDWpjcc3nhX; Thu, 26 Jan 2017 19:29:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485458968; bh=L1ClIDwghZ4o/QQViP/iyqFmxo92g9oXSGppG9aCBgI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OzdV2cSiWYYSoWzwpnU+qK4nOG57Gp4ggnsSdBQd9IiSoEo8bDr9PR9hVYznnn0my IxSHC45v8YYz44sVjyWiswe7hF5Pep39WV6pG4IbNRy2GLTmKMmymdckeRRw/77u2l LzlQFIW9ZrcU0jDcc8wlAldSWSiL2pyO7MPhMy0m+Fi36eL0oYHaOmxbn80P1F9wAu lT93Fbe8xJsvBk8Jmr8FX7QfsID62iznPe9VSwFQJ7g8H5hDiLzxveMceCQPyxcdAL k49SJmMctRj/C3w5rkVrH7bjTI+/UVpJAmSmbgLygQfQnPpGXwel4d2djJgXVh5MDx 6dKXIa1T4ZxJA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-07v.sys.comcast.net with SMTP id Wpjbc5iAwaq1HWpjccrKrC; Thu, 26 Jan 2017 19:29:28 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> Date: Thu, 26 Jan 2017 14:29:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfNOJDAulWeMs+4hsTNpY0Ju0HnwAKeNcUyQ9qdTmOubEbOdfWHukZXQjPlNY//n/15vq3BruxT3D/o/py0mJFNWFCJ0OYX/2/j9bB0NR+N2Bb5Hpt4m9 ms3SfMtu5cvyrPK+FF7cGoKQd0jmyiq6OEBBXfGLmV/WKn/eHGz7vmtADenzsTE9dH2gSjxNpY7DWOZzY1fS/RsWG6PrigK7qCnGqTZ1KyhwLAsrX6vUrYcK Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:29:32 -0000 On 1/26/17 2:11 PM, Christer Holmberg wrote: > Hi, > >>>>>>>> In working through the ORTC SctpTransport implementation some of >>>>>>>> the oddities of SO became apparent. AFAICT existing >>>>>>>> implementations assume that the local and remote ports are the >>>>>>>> same and defaulting to 5000, which is funky. If one assumes that >>>>>>>> the remote port needs to be provided before an SCTP >>>>>>> Association can be initiated, then does SO really make sense? The >>>>>>> Answerer will have the Local and remote ports first, so it will >>>>>>> initiate, but can the Offerer respond without receiving the Answer >>>>>>> and the remote port? This doesn't seem like active/active, really. >>>>>>> >>>>>>> The offerer gets the port of the association initiated by the >>>>>>> answerer in the INIT sent from the answerer. And, the spec says >>>>>>> that the same ports must be used for both associations. >>>>>>> >>>>>>> "When an SCTP association is established, both SCTP endpoints MUST >>>>>>> initiate the SCTP association (i.e. both SCTP endpoints take the >>>>>>> 'active' role), and MUST use the same SCTP port as client port and >>>>>>> server port (in order to prevent two separate SCTP associations from >>>>>>> being established)." >>>>>> >>>>>> I hadn't noticed that. Given that, section 10.3 ought to have normative language to that effect. Right now, all it says is: >>>>>> >>>>>> o MUST associate an SDP 'sctp-port' attribute with the m- line. If >>>>>> the offer contained a new (different than the one currently used) >>>>>> SCTP port value the answerer MUST also associate a new SCTP port >>>>>> value. If the offer contained a zero SCTP port value, or if the >>>>>> answerer does not accept the SCTP association, the answerer MUST >>>>>> also associate a zero SCTP port value; and >>>>> >>>>> Section 10.3 is about the offer/answer procedures, including assigning the sctp-port value, while the other text is related to the SCTP establishment. >>>> >>>> Yes, but they need to be consistent. As currently written, it would >>>> be valid for the answerer to include a different sctp-port value in the answer, as long as it then ignores that and uses the value from the offer in the protocol. >>> >>> It IS valid for the answerer the include a different sctp-port value. >>> >>> What the text means is that and endpoint needs to use the same local port for sending and receiving SCTP messages. But, both endpoints don't >>> need to use the same port value. >> >> You mean symmetric use of the sctp-port values? > > Correct. > >> For instance, if A offers sctp-port:5000 and B offers sctp-port:6000, then messages sent from A to B must >> have 5000 as the from-port and 6000 as the to-port; and messages sent from B to A must have 6000 as the from-port and 5000 as the to-port. > > Yes. > >> Given that was your point, lets go back to what you said that triggered this part of the thread: >> >> The offerer gets the port of the association initiated by the answerer in the INIT sent from the >> answerer. And, the spec says that the same ports must be used for both associations. >> >> "When an SCTP association is established, both SCTP endpoints MUST >> initiate the SCTP association (i.e. both SCTP endpoints take the >> 'active' role), and MUST use the same SCTP port as client port and >> server port (in order to prevent two separate SCTP associations from >> being established)." >> >> But, the offerer does need to get SOMETHING (the answer and/or the INIT) from the answerer before the offerer can initiate the association. >> >> You are assuming here that there is only one SCTP association at a time over the lower layer (in this case DTLS). If there >> might be more than one such association then the offerer can't assume that the port number in the incoming INIT pertains >> to *this* association. After all, the *point* of port numbers is to demux sessions over the lower layer. >> >> Now this is a valid as long as multiple SCTP associations aren't bundled over the same DTLS UDP/TCP ports. Since doing >> such bundling is *currently* undefined, it can work for now. But it would make perfect sense to define bundlilng of multiple >> SCTP associations, using the sctp-port values for the demuxing. So in my opinion we ought not be spelling out procedures for >> SCTP association establishment that only work in this limited case. Hence it should be presumed that the offerer can't initiate >> the SCTP association until it receives the answer. > > We are assuming a single SCTP association, and that is also documented in the draft. Section 7 says: > > "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP > associations on top of a single DTLS association, the procedures in > this specification only support the negotiation of a single SCTP > association on top of any given DTLS association." > > I do not think this is the time to change that assumption. I'm not advocating changing that assumption, I don't think we should make decisions that preclude relaxing it in the future. Thanks, Paul From nobody Thu Jan 26 11:38: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 DD5F41299B6 for ; Thu, 26 Jan 2017 11:38:17 -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 UlL94xEI9kmj for ; Thu, 26 Jan 2017 11:38: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 53C081299B7 for ; Thu, 26 Jan 2017 11:38:16 -0800 (PST) X-AuditID: c1b4fb30-d67fb70000007085-b0-588a50245e56 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 0B.0C.28805.4205A885; Thu, 26 Jan 2017 20:38:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 20:38:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwIAAJzWA///s1jCAAB0VgP//7lzw Date: Thu, 26 Jan 2017 19:38:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> In-Reply-To: <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7ma5aQFeEwcWVshZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo48KSRpeAFe8WVA/tYGhgnsHUxcnJICJhI dPadYuli5OIQEljHKHHnYB8jhLOYUeLs3GfMXYwcHGwCFhLd/7RBGkQEgiTmNn5hArGFBaIl Dr29zAgRj5E4u2cxE0iviMA0RonfF5aCbWARUJX4/f0cO4jNK+ArcfNVLzPEgmPsEns2LmUG SXAK2Ets33MAbCqjgJjE91NrwGxmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaSxIrtlxgh 6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzEIydhaSlllIWmYhaVnAyLKKUbQ4tTgpN93I SC+1KDO5uDg/Ty8vtWQTIzAmDm75bbCD8eVzx0OMAhyMSjy8Bu5dEUKsiWXFlbmHGCU4mJVE eHfYAoV4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpgDDBe ecEpa4Zd/3bBk8dmdH84LJBTa3v7m7BfSbxS/fx5YkdmK2268SKi703r4TC+lysiWB9O3X5z 7tlbS/3uN026m3Xr3dK0ma0VlotWin2Y51jQELV5VsrHn1v0l75ny+pKU25RtOnk47vp8vO0 y+rDPwJEuTf6zi1q9zgWZvZco+dG4IoIRyWW4oxEQy3mouJEAGkiPgGFAgAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:38:18 -0000 Hi, ... >> We are assuming a single SCTP association, and that is also documented i= n the draft. Section 7 says: >> >> "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP >> associations on top of a single DTLS association, the procedures in >> this specification only support the negotiation of a single SCTP >> association on top of any given DTLS association." >> >> I do not think this is the time to change that assumption. > > I'm not advocating changing that assumption, I don't think we should make= decisions that preclude relaxing it in the future. If there is a need in the future, we'll deal with it. That may include some= kind of I-support-multiple-associations indicator, and procedures associat= ed with that. The only customer (that I am aware of) of this document is WebRTC, and with= QUIC on the horizon I am not sure there will be too many others (but, if t= here will be, we'll deal with it). Regards, Christer From nobody Thu Jan 26 11:59:30 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 3DD23129A47 for ; Thu, 26 Jan 2017 11:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 zOafdqVOx3Zq for ; Thu, 26 Jan 2017 11:59:28 -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 2B2DE129A45 for ; Thu, 26 Jan 2017 11:59:28 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-01v.sys.comcast.net with SMTP id WqCCcqKpDRNZDWqCdc3tX1; Thu, 26 Jan 2017 19:59:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485460767; bh=JKNErlssDKVH01RfbbTm1y4nV6cqkuljz+3TLZ/x8RA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WCcdidvWIfcaU3KDSHI8yiEkz2k2hFzkDcIL8UWm9QgenXu0i/2KiwohcyN5C2LuR 2nEsQeDBzjrRJIotroPXLaG1psPVdSex+RXaR2VLCksAIoWtVfoa1mmm8sZ+sVd4Al t49jrwwX06KP/JHNmiFqX1qqsHTtCkAnCswtZhr4R2OC1MetcWM3JZYXkrEqMdxEh2 Tg8Vh3Iet9I+s/KKjNySMgTXVNV1xiC3goxw87eVnS2/WERRksHtwqMRykaRvgURGB IXOgk2FgmXYER2IOh9ENr5fXoCwAuTdxIJ9aeMqeZMLQXLmiAoQBt9e+JG21xK0ROp Sh8Uh9KwxKqpQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-13v.sys.comcast.net with SMTP id WqCcctPtpmtGiWqCdcV5Rd; Thu, 26 Jan 2017 19:59:27 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> Date: Thu, 26 Jan 2017 14:59:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfL6frt6/0KkPmypm1CKGjlEhuKbdT1Yhhum6NkuDdXVN/E71LGalT2E4NkF/IrNZ4ncyz4m0bH5pawQ16XgF1PI1FTMbPI1U9vxrwdFR4J2ziuS8gc6+ weCBTkrHYXF7q4Y8O05JyoK5pOqcTkRf/TDlih/8TvH2QnigKcv0oaIKlAGUsXitmJL1vb2SCp6MUA== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:59:29 -0000 On 1/26/17 2:38 PM, Christer Holmberg wrote: > Hi, > > ... > >>> We are assuming a single SCTP association, and that is also documented in the draft. Section 7 says: >>> >>> "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP >>> associations on top of a single DTLS association, the procedures in >>> this specification only support the negotiation of a single SCTP >>> association on top of any given DTLS association." >>> >>> I do not think this is the time to change that assumption. >> >> I'm not advocating changing that assumption, I don't think we should make decisions that preclude relaxing it in the future. > > If there is a need in the future, we'll deal with it. That may include some kind of I-support-multiple-associations indicator, and procedures associated with that. > > The only customer (that I am aware of) of this document is WebRTC, and with QUIC on the horizon I am not sure there will be too many others (but, if there will be, we'll deal with it). In that case there is no need to negotiate sctp-port at all. It has ceased to mean anything like what it is intended to mean within the definition of SCTP. Pretending that we are negotiating it simply leads to confusion. Rather, what has been done is to agree to ignore the prt number as a mechanism for demultiplexing and repurpose the field in the protocol to carry a "establish new association" indicator. Thanks, Paul From nobody Thu Jan 26 12:13:07 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 F3008129A85 for ; Thu, 26 Jan 2017 12:13:05 -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 pDF3slPZC-GS for ; Thu, 26 Jan 2017 12:13:04 -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 3976B129A7F for ; Thu, 26 Jan 2017 12:13:04 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-91-588a584e79d5 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by (Symantec Mail Security) with SMTP id AF.17.32317.E485A885; Thu, 26 Jan 2017 21:13:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 21:12:39 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwIAAJzWA///s1jCAAB0VgP//7lzwAANAoQD//+1Q8A== Date: Thu, 26 Jan 2017 20:12:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> In-Reply-To: <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7ga5fRFeEwdFbIhZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY1fqasWA7T0Xv1y0sDYyvObsYOTkkBEwk frV/Ye5i5OIQEljHKDFz70ZWCGcxo8SzGyeAHA4ONgELie5/2iANIgJBEnMbvzCB2MIC0RKH 3l5mhIjHSJzds5gJpFdEYBmjxPyzK8ESLAKqEgv/3QVr4BXwlbh9+iwbxIIuDolHJx8wgyQ4 BewlHm++yAJiMwqISXw/tQasgVlAXOLWk/lMEKcKSCzZc54ZwhaVePn4HyuErSSxYvslRoh6 HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjCKzkIydhaRlFpKWWUhaFjCyrGIULU4tLs5NNzLW Sy3KTC4uzs/Ty0st2cQIjImDW37r7mBc/drxEKMAB6MSD6+Be1eEEGtiWXFl7iFGCQ5mJRFe +1CgEG9KYmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYz6Uc+e KAXIJ3Y3HDL1mmjtP8NEJbpzCs/DTTuPH2Esm50XZvq4ilmv1Et1jbeLqKX6DC2GPQlG1vqf Tzt9kncNt+vuNzePq5icVXHq0b6ZT48Xf2aSrGmVTzzgyi7xf0W9x6bCa95iV8Pmv+8ozc8v L/TyOFB9KXxb+fZFbCJTNvg0rebarMRSnJFoqMVcVJwIAMVMmE2FAgAA Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:13:06 -0000 Hi, ... >>>> We are assuming a single SCTP association, and that is also documented= in the draft. Section 7 says: >>>> >>>> "NOTE: While [I-D.ietf-tsvwg-sctp-dtls-encaps] allows multiple SCTP >>>> associations on top of a single DTLS association, the procedures in >>>> this specification only support the negotiation of a single SCTP >>>> association on top of any given DTLS association." >>>> >>>> I do not think this is the time to change that assumption. >>> >>> I'm not advocating changing that assumption, I don't think we should ma= ke decisions that preclude relaxing it in the future. >> >> If there is a need in the future, we'll deal with it. That may include s= ome kind of I-support-multiple-associations indicator, and procedures assoc= iated with that. >> >> The only customer (that I am aware of) of this document is WebRTC, and w= ith QUIC on the horizon I am not sure there will be=20 >> too many others (but, if there will be, we'll deal with it). > > In that case there is no need to negotiate sctp-port at all. It has cease= d to mean anything like what it is intended to mean within the > definition of SCTP. Pretending that we are negotiating it simply leads to= confusion. Rather, what has been done is to agree to ignore > the prt number as a mechanism for demultiplexing and repurpose the field = in the protocol to carry a "establish new association" indicator. The endpoints still need to know the port of the peer - even if they are on= ly going to initiate a single association. Regards, Christer =20 From nobody Thu Jan 26 12:35: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 09F6E1299BC for ; Thu, 26 Jan 2017 12:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Qz45afDgRO5y for ; Thu, 26 Jan 2017 12:35:32 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 EE9F71299AA for ; Thu, 26 Jan 2017 12:35:31 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-06v.sys.comcast.net with SMTP id Wqkacwqk9FWWvWqlWcIn9p; Thu, 26 Jan 2017 20:35:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485462930; bh=mzF9NIkH6PBrTumJkf0+mCUqeAGJsF6BbojagXbeN88=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=E+CrXLwSZtJkrc2oJ0kDBslrB60/b4U5XNI3wzNzSoV87AY50iiatkCmTs4hBx96z wgtx5bG1zmefbuXo5UlvXV5tv8t1ChToIX7H3fCBEHGNKauPnSGohilYNuDQlm+nh0 oCeoAmPm48MVRwy18L3y66rkRmq94ixeMh5ztK6RIsjTs01WkghD9Pr+5VJL0Z+2p9 89TjPxSWFvQ6xS/Bnm3ygNxBwQucptzb3JoavRBzJDU2TY2S59brG0zP67kkPmOXSO 9XgGoQrlkPAeLRos0/DcgRLkICu8QI90NZRNEpbp3qw7ZIrGn+tPfYhONiX9Vw2+g0 7qer1LVG68NlA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-05v.sys.comcast.net with SMTP id WqlVcYuzUmBhGWqlWcUzen; Thu, 26 Jan 2017 20:35:30 +0000 To: Christer Holmberg , "mmusic@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <03af77d1-dd43-132f-438a-f2495885adfb@comcast.net> Date: Thu, 26 Jan 2017 15:35:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfChW1Ri7CT3hzKeqoeemZhTyJBp7Iuk6pi3e+D+eBHli84SaTBdD6Do81bvFxF9ccniBYKXIItDsSzGUZ35w+TKVLJy8qcznZASnrGziU7XI4nDDsDgE sab7Ahoz76aNEJ8Jvq9UBaiQpxtLfSsipaCX0ti+iNEYSNtGmgMCwZ6LAV/KDFCzOQ/UnzkZSWNpm3WgcDMJC9YAIYtB344v5RbenluGqDwuQ+Y4dUw0nYCN Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:35:33 -0000 On 1/26/17 3:12 PM, Christer Holmberg wrote: >> In that case there is no need to negotiate sctp-port at all. It has ceased to mean anything like what it is intended to mean within the >> definition of SCTP. Pretending that we are negotiating it simply leads to confusion. Rather, what has been done is to agree to ignore >> the prt number as a mechanism for demultiplexing and repurpose the field in the protocol to carry a "establish new association" indicator. > > The endpoints still need to know the port of the peer - even if they are only going to initiate a single association. But, IIUC, *you* were suggesting that the offerer might discover the port from a received INIT message rather than waiting for the answer. *That* only works if the answerer only has one association at a time. As long as the offerer waits to get the sctp-port from the answer before sending any SCTP messages to the offerer. Thanks, Paul From nobody Thu Jan 26 12:47: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 45A0E129B46 for ; Thu, 26 Jan 2017 12:47: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 XcbK603Rv8E4 for ; Thu, 26 Jan 2017 12:47: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 42DE8129B44 for ; Thu, 26 Jan 2017 12:47:48 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-82-588a60725ff2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id E8.63.28805.2706A885; Thu, 26 Jan 2017 21:47:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 21:46:36 +0100 From: Christer Holmberg To: Paul Kyzivat , "mmusic@ietf.org" Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwIAAJzWA///s1jCAAB0VgP//7lzwAANAoQD//+1Q8P//4z2A//+1UkA= Date: Thu, 26 Jan 2017 20:46:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC4EAD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> <03af77d1-dd43-132f-438a-f2495885adfb@comcast.net> In-Reply-To: <03af77d1-dd43-132f-438a-f2495885adfb@comcast.net> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7um5RQleEwe+7ahZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq41NHIVjCBs+LlGZcGxoXsXYycHBICJhJX 315g7GLk4hASWMcosenFNmYIZzGjxO85V1i6GDk42AQsJLr/aYM0iAgEScxt/MIEYgsLREsc enuZESIeI3F2z2ImkF4RgU2MEk3TToFtYBFQlfjzdTJYEa+Ar8TWi/+ZIBa0c0i87ToHVsQp YC9xcOkKNhCbUUBM4vupNWAbmAXEJW49mc8EcaqAxJI955khbFGJl4//sULYShIrtl9ihKjX kViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTipNx0IyO9 1KLM5OLi/Dy9vNSSTYzAiDi45bfBDsaXzx0PMQpwMCrx8Bq4d0UIsSaWFVfmHmKU4GBWEuG1 DwUK8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwGjfvMv7 P/++w+K7Dh+R0+aVWfhwyorbs63dD0yIz5nwViCrq3Dp41U3S3NPtXnvcK/ZEz/p/V73Fa+Z 13sW7V0pb2urqiGR+OHhkbxPN7ayb+T5EzTbXzecRfWNzqSLReJWXALC80Mrrxuftd9Qwrnx T+bbl7VmLIUb5yz+s8vpicGbBVPntH5SYinOSDTUYi4qTgQA0Xagr4QCAAA= Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:47:57 -0000 Hi, >>> In that case there is no need to negotiate sctp-port at all. It has=20 >>> ceased to mean anything like what it is intended to mean within the=20 >>> definition of SCTP. Pretending that we are negotiating it simply leads = to confusion. Rather, what has been done is to agree to ignore the prt numb= er as a mechanism for >>> demultiplexing and repurpose the field in the pro= tocol to carry a "establish new association" indicator. >> >> The endpoints still need to know the port of the peer - even if they are= only going to initiate a single association. > > But, IIUC, *you* were suggesting that the offerer might discover the port= from a received INIT message rather than waiting for the answer.=20 Yes. But, if the offerer for whatever reason receives the answer before the= INIT, it allows the offerer to send its INIT. > *That* only works if the answerer only has one association at a time. Correct. If we in future define support for multiple associations that won'= t be enough. Perhaps we then need to signal multiple ports, and/or consider= e.g., the SCTP association ID too, etc etc etc.=20 Regards, Christer From nobody Thu Jan 26 13:01: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 1B6A8129B91 for ; Thu, 26 Jan 2017 13:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 7HiX6apnIHpy for ; Thu, 26 Jan 2017 13:01:38 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 66232129B81 for ; Thu, 26 Jan 2017 13:01:38 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with SMTP id WrAQcT8EOoFDdWrAocHVfs; Thu, 26 Jan 2017 21:01:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485464498; bh=X/dhPVSV0CYaB+UUo5VrGQVm5pYukqMEjwCvEHoZK84=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hhTDvBpcIIw2rbkIxb75wnboyamxFsII/YVv7ja2Yr2F+c6pCAk2EPuiEclpR0rzt 8Z/o4e/wxYWALLgWHnaoMDt6yQBh16jG0PDFDfD7oAY3VhFUT2Je0OEO++zbKnf6pG Z4IiVO4zyfoKeZEpXBUWL9D3/v+xF3DF4UPV6/faGdruu1qGv/Js/D4/Vc9jYs/q8M OpLohIbEGbe5NvSrbEvCvcsO2u1GM4SU1JEJUcIy4h/ATdPKBvBxvqZjmjeGo4qBRF HOXyPdF4HmUIBAagnBslXCYlPm3wUPMM+RO/fiTe+RALsBDfwjqKDo7AwmSbBGnYP/ GMJL2hux28LJA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-15v.sys.comcast.net with SMTP id WrAncrLULz1pFWrAncvBq8; Thu, 26 Jan 2017 21:01:38 +0000 To: mmusic@ietf.org References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> <03af77d1-dd43-132f-438a-f2495885adfb@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4EAD@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: Date: Thu, 26 Jan 2017 16:01:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFC4EAD@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAcMIzS5WZbAERWFunFzV4sx+Kvesm6cLh27MWue6empFwgUkELdmse+o1B0udkjC5arqQjXLRVvlblMX+0Ob6zzVu/joTBTWDtKPCVtmhM4XPa20ko4 MB0SpRaLjNQepAP+3+3apYDN1rGD4PqMi6N767pdLBf3ZHdKTB2yAWe7dkscfSWVpBFJwj0Gop/Sbg== Archived-At: Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 21:01:41 -0000 On 1/26/17 3:46 PM, Christer Holmberg wrote: > Hi, > >>>> In that case there is no need to negotiate sctp-port at all. It has >>>> ceased to mean anything like what it is intended to mean within the >>>> definition of SCTP. Pretending that we are negotiating it simply leads to confusion. Rather, what has been done is to agree to ignore the prt number as a mechanism for >>> demultiplexing and repurpose the field in the protocol to carry a "establish new association" indicator. >>> >>> The endpoints still need to know the port of the peer - even if they are only going to initiate a single association. >> >> But, IIUC, *you* were suggesting that the offerer might discover the port from a received INIT message rather than waiting for the answer. > > Yes. But, if the offerer for whatever reason receives the answer before the INIT, it allows the offerer to send its INIT. > >> *That* only works if the answerer only has one association at a time. > > Correct. If we in future define support for multiple associations that won't be enough. Perhaps we then need to signal multiple ports, and/or consider e.g., the SCTP association ID too, etc etc etc. In any case, this is mostly moot, because you need the IP address and UDP port before you can start to establish the association, and those also come in the answer. (Or from ICE after having received some candidates in the answer.) I guess the time when it might apply is when adding the SCTP to a preexisting bundle, and requiring it to be bundle-only. I guess if somebody wants to build an optimization based on all the necessary special cases applying then that is their business. But I wouldn't like to see that written down in the specs. Thanks, Paul From nobody Thu Jan 26 14:37: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 88F13129C11 for ; Thu, 26 Jan 2017 14:37:54 -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 sUi6QTlRcWSQ for ; Thu, 26 Jan 2017 14:37: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 B556E129C00 for ; Thu, 26 Jan 2017 14:37:52 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-d2-588a7a3eb08c Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 46.C2.16488.E3A7A885; Thu, 26 Jan 2017 23:37:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 23:38:47 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAAepGuAAASSMAAADRmBgAACsmbg///62oD//+lrwIAAJzWA///s1jCAAB0VgP//7lzwAANAoQD//+1Q8P//4z2A//+1UkD//3R/gP/+vVvU Date: Thu, 26 Jan 2017 22:37:47 +0000 Message-ID: <5A443B1E-FCAF-4D11-A4B7-56049EFB8A66@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <73CDCBCD-1005-4335-8A50-46DB004C4573@gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFC4960@ESESSMB209.ericsson.se> <96f2f9bf-3de9-256f-7494-9b58d4d75842@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4A3E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFC4B28@ESESSMB209.ericsson.se> <63cbfb97-786e-2f03-ff0d-2fad2b640758@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4BC1@ESESSMB209.ericsson.se> <200c7ff4-dcc9-864f-80c8-6f16d8659911@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4E0B@ESESSMB209.ericsson.se> <03af77d1-dd43-132f-438a-f2495885adfb@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC4EAD@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7t659VVeEwaV1XBZTlz9msXjwo5fN gclj8uM5jB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4ePwHW8E9wYr351gaGCfzdTFyckgImEjs vnSHEcQWEljHKPFsikIXIxeQvZhRYlrfY+YuRg4ONgELie5/2iA1IgLaEg8OL2YECTMLqEtc XRwEEhYWiJb4uv81C0RJjMTZPYuZQMaICOwDGnPwCTNIgkVAVaLt9kWwIl4Be4nX/S8ZIXZt 55A4NfESE0iCEyjx7+xUsIMYBcQkvp9aAxZnFhCXuPVkPhPE0QISS/acZ4awRSVePv7HClGj I7Fg9yc2CFtbYtnC18wQywQlTs58wjKBUWQWklGzkLTMQtIyC0nLAkaWVYyixanFxbnpRkZ6 qUWZycXF+Xl6eaklmxiB0XBwy2+rHYwHnzseYhTgYFTi4TVw74oQYk0sK67MPcQowcGsJMK7 tRQoxJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA2N4w41n 1/S+yvC+kE2ODtpU/OpBSegxq4a9mTHaB84fOhmqvLBRu+zNd+HLvNvnHjrAaLQ6+qOfwY7a eYvf9jEf2Mf2teSygs1787CJZumWM2a9ed0cnh9/Vc5COqtk0s+f+vk19ZUzFqYrTw3d0yy0 5OLud1f6N998sVe9XUy05NNvnt9Lzd8osRRnJBpqMRcVJwIApTT8JYICAAA= Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 22:37:54 -0000 Hi, You can add an SCTP association to an existing DTLS association, that has e= arlier been established e.g., for audio and video. Regards, Christer Sent from my iPhone > On 26 Jan 2017, at 23.01, Paul Kyzivat wrote: >=20 >> On 1/26/17 3:46 PM, Christer Holmberg wrote: >> Hi, >>=20 >>>>> In that case there is no need to negotiate sctp-port at all. It has >>>>> ceased to mean anything like what it is intended to mean within the >>>>> definition of SCTP. Pretending that we are negotiating it simply lead= s to confusion. Rather, what has been done is to agree to ignore the prt nu= mber as a mechanism for >>> demultiplexing and repurpose the field in the p= rotocol to carry a "establish new association" indicator. >>>>=20 >>>> The endpoints still need to know the port of the peer - even if they a= re only going to initiate a single association. >>>=20 >>> But, IIUC, *you* were suggesting that the offerer might discover the po= rt from a received INIT message rather than waiting for the answer. >>=20 >> Yes. But, if the offerer for whatever reason receives the answer before = the INIT, it allows the offerer to send its INIT. >>=20 >>> *That* only works if the answerer only has one association at a time. >>=20 >> Correct. If we in future define support for multiple associations that w= on't be enough. Perhaps we then need to signal multiple ports, and/or consi= der e.g., the SCTP association ID too, etc etc etc. >=20 > In any case, this is mostly moot, because you need the IP address and UDP= port before you can start to establish the association, and those also com= e in the answer. (Or from ICE after having received some candidates in the = answer.) >=20 > I guess the time when it might apply is when adding the SCTP to a preexis= ting bundle, and requiring it to be bundle-only. >=20 > I guess if somebody wants to build an optimization based on all the neces= sary special cases applying then that is their business. But I wouldn't lik= e to see that written down in the specs. >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jan 26 15:27:16 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 7ABE6129C4A; Thu, 26 Jan 2017 15:27:09 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148547322945.26971.5376787876967687385.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2017 15:27:09 -0800 Archived-At: Cc: fandreas@cisco.com, ben@nostrum.com, draft-ietf-mmusic-sctp-sdp@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org Subject: [MMUSIC] Last Call: (Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 23:27:09 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport.' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jan 26 15:28:03 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 DE0EB129C5F for ; Thu, 26 Jan 2017 15:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, 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 Qai7Vo391D_4 for ; Thu, 26 Jan 2017 15:28:00 -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 90194129C50 for ; Thu, 26 Jan 2017 15:27:57 -0800 (PST) Received: from [10.0.1.39] (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 v0QNReQr004972 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 26 Jan 2017 17:27: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.39] From: "Ben Campbell" To: "Christer Holmberg" Date: Thu, 26 Jan 2017 17:27:39 -0600 Message-ID: <976A9EC9-F15C-4AA5-A4A4-41212DDF827E@nostrum.com> In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> <9A5608A3-0AD5-4840-8852-6A166D72A7CE@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: Flemming Andreasen , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 23:28:02 -0000 Hi, I just requested the IETF last call on version 22. And then I noticed a bunch of conversation popped up today that I hadn't seen yet. Based on a quick scan, I think it is reasonable to go ahead with the IETF LC, and if any changes result from the ongoing conversation, they can be addressed as part of the LC. If anyone feels strongly otherwise, let me know and I can cancel the LC. Thanks! Ben. On 26 Jan 2017, at 2:02, Christer Holmberg wrote: > Hi, > >> Given the discussion, it seems to make sense to go ahead and start >> the >> IETF LC, and to ask for a TSV review team review as part of that. >> Does >> that make sense? > > Sounds good to me. > > Regards, > > Christer > > > > >> On 25 Jan 2017, at 14:57, Paul Kyzivat wrote: >> >>> On 1/25/17 3:26 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>>>>>> No. Let's not start making things complicated again. The >>>>>>>> document >>>>>>>> is in good shape in my opinion. Let's publish it. >>>>>>>> >>>>>>>> Keep in mind that nothing prevents an endpoint from >>>>>>>> closing/re-opening an SCTP association at any time. All we are >>>>>>>> saying is that a DTLS change does not automatically affect the >>>>>>>> SCTP association. >>>>>>> >>>>>>> I agree that if an endpoint explicitly initiates the closing of >>>>>>> an >>>>>>> SCTP association, and the other end acknowledges that, they can >>>>>>> then >>>>>>> establish a new association. (IIUC it would take another O/A to >>>>>>> trigger establishing the new one.) But it requires one of the >>>>>>> endpoints to know that this is needed. >>>>>>> >>>>>>> Lets consider a 3pcc scenario, where A is in call with B via >>>>>>> controller P, where P isn't proxying the media. Now suppose P >>>>>>> wants >>>>>>> to transfer the call, replacing B with C. Typically it will do >>>>>>> this by sending an offerless invite to A, and then forward the >>>>>>> resulting offer from A to C. >>>>>>> >>>>>>> In this case C can't resume the SCTP association that A has with >>>>>>> B. But A doesn't know that a new association is needed. >>>>>> >>>>>> Assuming B terminates the SCTP association with A when the >>>>>> transfer >>>>>> occurs, A will know. >>>>>> >>>>>> But, in any case, when C gets the offer, it will try to establish >>>>>> an SCTP association with A. >>>>> >>>>> I agree that C will try that. I haven't done any digging into the >>>>> details of the SCTP protocol, but it seems like A and C will be >>>>> working at cross purposes. C will be trying to >>>>> establish a new association, while A is trying to re-establish the >>>>> existing SCTP association over a new DTLS association. Maybe it >>>>> will >>>>> just all work out, but I'm inclined to >>>>> doubt it. >>>>> >>>>> It would help to have a expert on the SCTP protocol chime in at >>>>> this >>>>> point. >>>> >>>> We also of course have to assume that A, when it receives the >>>> offerless invite, creates an offer that represents the ongoing >>>> associations (including the currently used sctp-port value), and >>>> not >>>> a new one (if A offers a new sctp-port value, there won't be an >>>> issue, because the INIT from C will be received on that port). But, >>>> that is a general problem with 3pcc, not specific to SCTP. >>> >>> While (AFAIK) there are no SCTP-specific requirements pertaining to >>> this, it is hard to imagine anyone concluding they should do >>> otherwise. >>> >>> 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 Thu Jan 26 19:47: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 A093A12943F for ; Thu, 26 Jan 2017 19:47: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 iDkGJAkdwwty for ; Thu, 26 Jan 2017 19:47:20 -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 26B57129410 for ; Thu, 26 Jan 2017 19:47:19 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-86-588ac2c56761 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 96.02.32317.5C2CA885; Fri, 27 Jan 2017 04:47:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Fri, 27 Jan 2017 04:46:25 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments Thread-Index: AdJ0ILFiibP8Bb/uTmOrMFLsPov7fABrZ+iAAAI2PoAAIDE9gAAFlvUAAAPjGQAAK2MIAAACwQJwAAANOgAAAlpGEP///hUA///szeCAAB+zgIAAX5sAgAB79gCAAOCcgIAAWQ/V Date: Fri, 27 Jan 2017 03:46:24 +0000 Message-ID: <095595FA-FBA5-455A-9D70-6F1D7988D161@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B4BF9A860@ESESSMB209.ericsson.se> <18D6EC97-0A89-4139-834B-7E889CD8ECF1@nostrum.com> <57d1cc4c-2cb4-4b01-db13-41b64b455887@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC06F6@ESESSMB209.ericsson.se> <1b903af4-8d85-5d0a-b5b2-e3bdd0fd21fc@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0A13@ESESSMB209.ericsson.se> <74483dd6-bd2a-cb67-ba12-b5ebb96c0aca@comcast.net> <7594FB04B1934943A5C02806D1A2204B4BFC0AF1@ESESSMB209.ericsson.se> <856b91bd-27f0-8ef0-c247-be44a9a8114a@comcast.net> <9A5608A3-0AD5-4840-8852-6A166D72A7CE@nostrum.com> , <976A9EC9-F15C-4AA5-A4A4-41212DDF827E@nostrum.com> In-Reply-To: <976A9EC9-F15C-4AA5-A4A4-41212DDF827E@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGfG3RvfYoa4Ig109TBbzO0+zW7y/oGsx dfljFosHP3rZLGZcmMrswOox5fdGVo/Jj+cweixZ8pPJY9bOJywet6YUBLBGcdmkpOZklqUW 6dslcGVMeFNRcEWh4lCbcQPjUqkuRk4OCQETifs7zzB1MXJxCAmsZ5SYuPIXlLOYUeLW/B8s XYwcHGwCFhLd/7RBGkQElCSeN29lAalhFljAKNH5czU7SEJYIFri6/7XLBBFMRJn9yxmgrCn MUqsehcAYrMIqErs3XeJDcTmFbCX+PTkDzPIfCGBY+wS7VEgYU6g8Krf88HGMAqISXw/tQZs DLOAuMStJ/OZII4WkFiy5zwzhC0q8fLxP1aIGh2JBbs/sUHY2hLLFr5mhlglKHFy5hOWCYwi s5CMmoWkZRaSlllIWhYwsqxiFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyhg1t+6+5gXP3a 8RCjAAejEg+vgXtXhBBrYllxZe4hRgkOZiURXsEdQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 ZivvhwsJpCeWpGanphakFsFkmTg4pRoYJ4puTzuScf3e7UKT/PJO3z9/ebl+nNp7esmn63Eq 2pfZzFrKb5ic8Cn5zZ4yedvuC1dl60T3Wbtapj9ctrJBf87VtRGSnvaxiVHL9j+ts9T+YhC5 /KX1x81qXYr1bWznCtV3qt+6H3bDqSPnidusHRwCS0MTnUqDv6fE1Ulwz/lixSl6edIEJZbi jERDLeai4kQALeYFaZ0CAAA= Archived-At: Cc: Flemming Andreasen , Paul Kyzivat , "mmusic@ietf.org" Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sctp-sdp-21 - TECHNICAL comments X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 03:47:23 -0000 Hi, I think we can move ahead. Then, if the transport people find issues, we ma= y have to come back. Regards, Christer=20 Sent from my iPhone > On 27 Jan 2017, at 1.27, Ben Campbell wrote: >=20 > Hi, >=20 > I just requested the IETF last call on version 22. And then I noticed a b= unch of conversation popped up today that I hadn't seen yet. Based on a qui= ck scan, I think it is reasonable to go ahead with the IETF LC, and if any = changes result from the ongoing conversation, they can be addressed as part= of the LC. >=20 > If anyone feels strongly otherwise, let me know and I can cancel the LC. >=20 > Thanks! >=20 > Ben. >=20 >> On 26 Jan 2017, at 2:02, Christer Holmberg wrote: >>=20 >> Hi, >>=20 >>> Given the discussion, it seems to make sense to go ahead and start the >>> IETF LC, and to ask for a TSV review team review as part of that. Does >>> that make sense? >>=20 >> Sounds good to me. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>>> On 25 Jan 2017, at 14:57, Paul Kyzivat wrote: >>>>=20 >>>>> On 1/25/17 3:26 PM, Christer Holmberg wrote: >>>>> Hi, >>>>>=20 >>>>>>>>> No. Let's not start making things complicated again. The document >>>>>>>>> is in good shape in my opinion. Let's publish it. >>>>>>>>>=20 >>>>>>>>> Keep in mind that nothing prevents an endpoint from >>>>>>>>> closing/re-opening an SCTP association at any time. All we are >>>>>>>>> saying is that a DTLS change does not automatically affect the >>>>>>>>> SCTP association. >>>>>>>>=20 >>>>>>>> I agree that if an endpoint explicitly initiates the closing of an >>>>>>>> SCTP association, and the other end acknowledges that, they can >>>>>>>> then >>>>>>>> establish a new association. (IIUC it would take another O/A to >>>>>>>> trigger establishing the new one.) But it requires one of the >>>>>>>> endpoints to know that this is needed. >>>>>>>>=20 >>>>>>>> Lets consider a 3pcc scenario, where A is in call with B via >>>>>>>> controller P, where P isn't proxying the media. Now suppose P >>>>>>>> wants >>>>>>>> to transfer the call, replacing B with C. Typically it will do >>>>>>>> this by sending an offerless invite to A, and then forward the >>>>>>>> resulting offer from A to C. >>>>>>>>=20 >>>>>>>> In this case C can't resume the SCTP association that A has with >>>>>>>> B. But A doesn't know that a new association is needed. >>>>>>>=20 >>>>>>> Assuming B terminates the SCTP association with A when the transfer >>>>>>> occurs, A will know. >>>>>>>=20 >>>>>>> But, in any case, when C gets the offer, it will try to establish >>>>>>> an SCTP association with A. >>>>>>=20 >>>>>> I agree that C will try that. I haven't done any digging into the >>>>>> details of the SCTP protocol, but it seems like A and C will be >>>>>> working at cross purposes. C will be trying to >>>>>> establish a new association, while A is trying to re-establish the >>>>>> existing SCTP association over a new DTLS association. Maybe it will >>>>>> just all work out, but I'm inclined to >>>>>> doubt it. >>>>>>=20 >>>>>> It would help to have a expert on the SCTP protocol chime in at this >>>>>> point. >>>>>=20 >>>>> We also of course have to assume that A, when it receives the >>>>> offerless invite, creates an offer that represents the ongoing >>>>> associations (including the currently used sctp-port value), and not >>>>> a new one (if A offers a new sctp-port value, there won't be an >>>>> issue, because the INIT from C will be received on that port). But, >>>>> that is a general problem with 3pcc, not specific to SCTP. >>>>=20 >>>> While (AFAIK) there are no SCTP-specific requirements pertaining to >>>> this, it is hard to imagine anyone concluding they should do >>>> otherwise. >>>>=20 >>>> Thanks, >>>> Paul >>>>=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 Fri Jan 27 08:43:37 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 DD70612953E; Fri, 27 Jan 2017 08:43:35 -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, FILL_THIS_FORM=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 Zd5ODwIiCxGm; Fri, 27 Jan 2017 08:43:33 -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 8EEAE129525; Fri, 27 Jan 2017 08:43:32 -0800 (PST) X-AuditID: c1b4fb30-d53ff70000007085-4b-588b78b1a874 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id C2.8A.28805.1B87B885; Fri, 27 Jan 2017 17:43:30 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.319.2; Fri, 27 Jan 2017 17:44:29 +0100 From: Magnus Westerlund To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , Message-ID: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Date: Fri, 27 Jan 2017 17:43:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM2K7t+6miu4IgzXrTS2mz3rHZjG/Yx2b xdTlj1ks1v5rZ3dg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mt52H2EpaK+rOHH2DXMD 4/OoLkZODgkBE4n73z4ydzFycQgJrGOU6LtwiA0kISSwnFFi9hQOEJtNwELi5o9GNpAiEYEn jBL9Cx6zgCSEBVIl9u6YwQhi8wrYS7zetxBoEgcHi4CqxOMf/iBhUYEYibfrl7NDlAhKnJz5 hAWkhBmo/MHWMpAws4C8RPPW2cwQa7UlGpo6WCcw8s5C0jELoWMWko4FjMyrGEWLU4uTctON jPRSizKTi4vz8/TyUks2MQLD6+CW3wY7GF8+dzzEKMDBqMTDa+DeFSHEmlhWXJl7iFGCg1lJ hLc+vztCiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/ZyvvhQgLpiSWp2ampBalFMFkmDk6pBsa4 UrHXy5kXNrA8dn5qFWTklsDaf/XDlrDbV894c+Q83xm3X8DYa9q1+/NKelsmbdWtE2i4Hj7t 2OHlNXxLbz8Le3/tQ9Tqz23bdRM64xjkKrfNMWF1m2Do/Kr9/M3uCSonluffL3yUxFV+1XxV S7Xi9y/NF9uNI1sljL32MLHp8TB9N8+X+KTEUpyRaKjFXFScCAA/RaaoKwIAAA== Archived-At: Subject: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 16:43:36 -0000 MMUSIC and RTCWEB, Here is now a more complete text proposal that also considers the RTCP. It also goes further than what Appendix B defines in one aspect, namely explicitly considering third party RTCP reporting and what to do with it. Feedback is much appreciated. I plan to put this into a PR towards JSEP APPENDIX B on monday. If only to get the JSEP authors attention ;-). However, the text is really intended for the next version of BUNDLE. X. Associating RTP/RTCP With Correct SDP Media Description As described in [RFC3550], RTP packets are associated with RTP streams [RFC7656]. Each RTP stream is identified by an SSRC value, and each RTP packet carries an SSRC value that is used to associate the packet with the correct RTP stream. RTCP packets also uses SSRCs to identify on which RTP streams any report or feedback relate to. Thus, an RTCP packet will commonly carry multiple SSRC values, and might therefore be providing feedback or report on multiple RTP streams. In order to be able to process received RTP/RTCP packets correctly it must be possible to associate an RTP stream with the correct "m=" line, as the "m=" line and SDP attributes associated with the "m=" line contain information needed to process the packets. As all RTP streams associated with a BUNDLE group are part of the same RTP session and using the same address:port combination for sending and receiving RTP/RTCP packets, the local address:port combination cannot be used to associate an RTP stream with the correct "m=" line. In addition, multiple RTP streams might be associated with the same "m=" line. Also, as described in Section 10.1.1, the same payload type value might be used by multiple RTP streams, in which case the payload type value cannot be used to associate an RTP stream with the correct "m=" line. However, there are cases where each "m=" line has unique payload type values, and then the payload type could serve as indicator to the relevant "m=" line the RTP stream is associated with. An offerer and answerer can inform each other which SSRC values they will use for an RTP stream by using the SDP 'ssrc' attribute [RFC5576]. However, an offerer will not know which SSRC values the answerer will use until the offerer has received the answer providing Name Expires July 31, 2017 [Page 2] Internet-Draft Abbreviated-Title January 2017 that information. Due to this, before the offerer has received the answer, the offerer will not be able to associate an RTP stream with the correct "m=" line using the SSRC value associated with the RTP stream. In addition, the offerer and answerer may start using new SSRC values mid-session, without informing each other using the SDP 'ssrc' attribute. In order for an offerer and answerer to always be able to associate an RTP stream with the correct "m=" line, the offerer and answerer using the BUNDLE extension MUST support the mechanism defined in Section 14, where the offerer and answerer includes the identification-tag (provided by the remote peer) associated with an "m=" line in the RTP Streams and in RTCP SDES packets part of a BUNDLE group. The mapping from an SSRC to an identification-tag is carried in RTCP SDES packets or in RTP header extensions (Section 14). Since a compound RTCP packet can contain multiple RTCP SDES packets, and each RTCP SDES packet can contain multiple chunks, an RTCP packet can contain several SSRC to identification-tag mappings. The offerer and answerer maintain tables mapping RTP streams identified by SSRC to "m=" lines identified by the identification-tag. These tables are updated each time new information that affects how packets should be processed and routed are received. To prepare for demultiplexing RTP streams to the correct "m=" line, the following steps MUST be followed for each BUNDLE group based on the SDP signalling information. Construct a table mapping MID to "m=" line for each "m=" line in this BUNDLE group. Note that an "m=" line may only have one MID. Construct a table mapping incoming RTP streams (SSRCs) to their "m=" line for each "m=" line in this BUNDLE group and for each RTP stream explicitly signalled for receiving in that "m=" line. Construct a table mapping payload types to "m=" line for each "m=" line in the BUNDLE group and for each payload type configured for receiving in that "m=" line. If any payload type is configured for receiving in more than one "m=" line in the BUNDLE group, do not it include it in the table. Note that for each of these tables, there can only be one mapping for any given key (MID, SSRC, or PT). In other words, the tables are not multimaps. As "m=" lines are added or removed from the BUNDLE groups, or their configurations are changed, the tables above MUST also be updated. Name Expires July 31, 2017 [Page 3] Internet-Draft Abbreviated-Title January 2017 Received RTP packets that are syntactically correct are processed by the RTP/RTCP protocol implementation for statistics etc. After this processing they need to be routed to the higher layer context associated with the "m=" line within the BUNDLE group. Somewhere in the process where an received RTP packet is processed to be delivered to the higher layer by RTP the matching step below MUST be performed: 1. Reception of an RTP packet for an RTP stream that has an existing mapping in the RTP stream to m= line table. Before proceeding in delivering the packet to the higher layer context according to the RTP stream to "m=" line mapping table the following checks MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is not in the table mapping MID to "m=" line, then do not deliver the RTP packet to higher layers. B. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, and the value indicates a different "m=" line than the current RTP stream to "m=" line mapping table, then update the RTP stream to "m=" line mapping. 2. Reception of an RTP packet for an RTP stream that has no existing mapping to an m= line. In this case the following actions MUST be performed: A. If the packet carries an RTP header extension with a SDES MID value that is in the table mapping MID to "m=" line, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. B. If the packet carries a Payload Type that is in the payload type table, then create an entry in the RTP stream to "m=" line mapping table for this RTP stream (SSRC). Then deliver the RTP packet to the "m=" line context of the created mapping and stop. C. Otherwise do not deliver the RTP packet to higher layers. Note, this includes unknown MID values. For each RTCP packet received (including each RTCP packet that is part of a compound RTCP packet), the RTCP packet needs to be processed by the RTP/RTCP implementation and relevant information and data from the RTCP packets needs to be routed to the appropriate handler for the related RTP streams. The appropriate handler is determined by using the RTP stream to "m=" line mapping table. Name Expires July 31, 2017 [Page 4] Internet-Draft Abbreviated-Title January 2017 On reception of any compound RTCP packet prior to dispatching the received information and data, if there is an RTCP SDES packet included that SHOULD be processed first. If that SDES packet contains SDES MID entries, this can results in updates and additions to the RTP stream to "m=" line mapping table. Thus each of the SDES MID items are processed and the current table entries are checked if the corresponding MID value matches the current RTP stream to "m=" line mapping, else the entry is updated. If there is no RTP stream to "m=" line table mapping entry for the received SDES item's SSRC, such an entry is created. Note, that in the process of updating the table entries, update flap suppression as discussed in Section 4.2.6 of [RFC7941] should be considered. The various different RTCP packets as well as their various sub parts, such as the various RTCP Feedback message types, relates to the RTP streams in a couple of different ways. The currently known patterns are the following: Reports on outgoing RTP streams: For all RTP streams that this endpoint is the source of, it can expect to receive report blocks of several types identified as relating to an outgoing stream. The basic pattern for these blocks are that the RTCP packet header identifies the source of the reports, as identified by an SSRC, and containing one or more report blocks, where each report block identifies the RTP stream, using the SSRC, the report relates to. For this pattern the relevant report information is provided to the higher layer associated with the "m=" line the RTP Stream to "m=" line table identifies. The source SSRC as identifier of the endpoint that the report originates are relevant for interpreting the information, but not necessarily for routing. Example of this is pattern are: Sender Report (SR) and Receiver Report (RR) The basic receiver report blocks from RFC3550 start with the SSRC of the RTP stream they report on. Extended Reports (XR): RFC3611 is a framework that enables a large number of different reports. However, a large number of these report formats are reporting on specific RTP streams and thus each individual report of these types contains a SSRC field to identify the RTP stream. RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP feedback messages allow for a number of different type of feedback messages. However, the RTCP feedback message header contains the SSRC identifying the source of the feedback messages as well as the actual type of the feedback. Some of the feedback messages also uses the target SSRC field in the header to identify which Name Expires July 31, 2017 [Page 5] Internet-Draft Abbreviated-Title January 2017 RTP stream the feedback is related to. For these types all the FCI entries, if multiple ones are forwarded to the identified handler. Examples of this pattern are: Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, FMT=3). Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). Other feedback messages includes the target SSRC in the Feedback Control Information (FCI). Here each FCI needs to be processed and the SSRC field identified. And the individual FCI combined with the RTCP packet header context needs to be forwarded to the identified handler. Example of this pattern are: Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, FMT=5). Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] defined message (PT=PSFB, FMT=5) is actually a notifciation in response to a TSTR this endpoint sent using the SSRC the FCI identifies as source. H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, FMT=7). Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, FMT=TBD). Descriptive or Notifications for an incoming RTP stream: There exist some RTCP packet types that provides additional information or notifies about events related to the RTP stream identified. In these cases the RTP stream is identified using the SSRC field value, and the information is provided to the higher layer associated with the "m=" line for the incoming RTP stream as identified by the current RTP stream to "m=" line table. For this type of pattern it is common that the RTCP packets and information is repeated, either periodically (e.g. SDES items), or for a duration (e.g. BYE), thus suppression of repetitions can be considered. Examples of these are: Name Expires July 31, 2017 [Page 6] Internet-Draft Abbreviated-Title January 2017 Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol [RFC3550] defines SDES RTCP packets as a way of providing per source (SSRC) specific information about the source. An SDES packet contains zero or more chunks, where a chunk contains the SSRC for the source being described by the one or more items included in the chunk. Forward the SDES items in each chunk to the RTP stream's handler. Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] mechanism indicates that a particular RTP stream is leaving the RTP session. Thus, a most relevant event to inform the handler for this RTP steam of. Third Party Targeted Reports or Feedback: There exist some multiparty RTP Topologies that results in that an endpoint receives third party reports (SR [RFC3550], RR [RFC3550] or XR [RFC3611]) as well as Feedback Messages [RFC4585] that relates to or targets an SSRC that originates from another endpoint, and where the source of the RTCP packet is also another endpoint. This type of packets should be forwarded to the higher layer function dealing with the third party reporting. And if none exist then they can be suppressed. As the third party handler can be focused on determining the conditions for the source of the reports and feedback, or focused on how the RTP stream source progresses, or both recommendations can't be made. APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that enables experimentation. The APP packet only specifies the source of the packet. Thus this information can be related to any of the "m=" lines, thus deliver a copy of the packet to each "m=" line or an APP specific handler. -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 27 09:15:07 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 5038112969F; Fri, 27 Jan 2017 09:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 1hbo5CZD6nkE; Fri, 27 Jan 2017 09:14:59 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE66A12969C; Fri, 27 Jan 2017 09:14:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 7F2D97C5256; Fri, 27 Jan 2017 18:14:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFgXdJ7IafPg; Fri, 27 Jan 2017 18:14:33 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:c145:37:d66e:9253] (unknown [IPv6:2001:470:de0a:1:c145:37:d66e:9253]) by mork.alvestrand.no (Postfix) with ESMTPSA id 228507C5255; Fri, 27 Jan 2017 18:14:32 +0100 (CET) To: Flemming Andreasen , mmusic@ietf.org References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Harald Alvestrand Message-ID: <1df9ff00-e8e3-661a-9646-a4a8a6d8b3f8@alvestrand.no> Date: Fri, 27 Jan 2017 18:14:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 17:15:01 -0000 On 01/26/2017 02:54 PM, Flemming Andreasen wrote: > Hi Harald > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. Would it also be OK to submit an updated draft, so that the RFC Editor doesn't have to waste time incorporating the changes? > > However, from an MMUSIC chair point of view, I would like to get > positive confirmation from some of the stakeholders that this change > is indeed desired. Similarly, if anybody has any concerns with the > suggested change, please send an e-mail to that effect. I have poked a few people to give their opinion. Will poke again. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: >> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>> Ted pointed out to me that I sent this to the wrong group. >>> >>> Chairs and members, please advise. >> My proposed change is here: >> >> https://github.com/alvestrand/rtcweb-msid/pull/16 >> >> The filed issue is here: >> >> https://github.com/alvestrand/rtcweb-msid/issues/15 >> >> (CCing RTCWEB - please keep discussion, if any, on mmusic) >> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: [rtcweb] Modifying an approved document: MSID >>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>> From: Harald Alvestrand >>> To: rtcweb@ietf.org >>> >>> >>> >>> When reviewing the implications of the PeerConnection API change to >>> support AddTrack rather than AddStream, I found an issue. >>> >>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>> REF-WAIT state (I believe). >>> >>> The issue is that it is possible to add a track without specifying a >>> stream. Since the track's ID needs to be carried, we have to send an >>> "a=msid" line, but the track's ID is the *second* field on that line, >>> with the first being the stream's ID. >>> >>> This creates a problem. >>> >>> Suggested fix: Insert two lines in the document: >>> >>> 1) On SDP generation: >>> >>> "If there is no stream associated with the track, use the reserved ID >>> value '-'" >>> >>> 2) On SDP parsing >>> >>> "If the stream ID is the reserved value '-', the track is not >>> associated >>> with a stream, and no stream is signalled or created." >>> >>> If this is OK with the community, I'll issue an updated draft with this >>> change. >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> >>> _______________________________________________ >>> 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 >> . >> > -- Surveillance is pervasive. Go Dark. From nobody Fri Jan 27 09:41:48 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 AAD32129446; Fri, 27 Jan 2017 09:41:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148553890269.17882.14092038842834257086.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 09:41:42 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-17.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 17:41:43 -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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-17.txt Pages : 25 Date : 2017-01-27 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-17 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 Jan 27 09:53:37 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 A2BE51296B0; Fri, 27 Jan 2017 09:53: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 mRLk3CIU4yAG; Fri, 27 Jan 2017 09:53:32 -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 ECEE31296AB; Fri, 27 Jan 2017 09:53:31 -0800 (PST) X-AuditID: c1b4fb25-5ba3c980000036c9-5e-588b891a10b7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id C4.93.14025.9198B885; Fri, 27 Jan 2017 18:53:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Fri, 27 Jan 2017 18:52:56 +0100 From: Christer Holmberg To: Andy Hutton , "mmusic-chairs@ietf.org" , "sipbrandy-chairs@ietf.org" , Ben Campbell , "mmusic@ietf.org" Thread-Topic: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt - comments on the Abstract Thread-Index: AdJ4xi+AdpK4U6U5QM2/htWiy8OhmQ== Date: Fri, 27 Jan 2017 17:52:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFC7A6C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFC7A6CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RleqszvC4NwbPotL67YyWczvPM1u cX7neiaLqcsfs1hc69nI7sDqsXPWXXaPJUt+MnnM2vmEJYA5issmJTUnsyy1SN8ugSvj4MuD rAWTNjFWPDk+k72Bcctaxi5GTg4JAROJqT+nANlcHEIC6xklXqxaxQbhLGaUaFx2nbmLkYOD TcBCovufNkhcROARo8TNqSvA4sICVRJ/DteDDBIRqJaY+2QOI4StJ3HweAc7iM0ioCpxr+kU E4jNK+ArsafjElgNo4CYxPdTa8DizALiEreezGeCOEhAYsme88wQtqjEy8f/WCFsJYlFtz8z gaxlFsiXaLpiDTFSUOLkzCcsExgFZyGZNAuhahaSKoiwpsT6XfoQ1YoSU7ofskPYGhKtc+ay I4svYGRfxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYNQe3/FbdwXj5jeMhRgEORiUeXgP3 rggh1sSy4srcQ4wSHMxKIrx32rojhHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliS mp2aWpBaBJNl4uCUamAUOvrRMePbVNOIe/e3856ptOK5/eL734LaeNM2voQpsWxX+g5nX7hy y671v3ve8QNK7bmdaRrCl+PEkncVqHaYvjQquP3KsTcn7Kx7yRIvW6bXvx+yPblttGrTGu5M 77c8d77uc7fg+v29YKOc/5ol7zsNmHuq/qhMMrqo4bJh4+bkjTd3f3iuxFKckWioxVxUnAgA nM6qIJYCAAA= Archived-At: Subject: Re: [MMUSIC] Fwd: I-D Action: draft-hutton-mmusic-opportunistic-negotiation-00.txt - comments on the Abstract X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 17:53:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4BFC7A6CESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2lsbCByZWFkIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCBsYXRlciwgYnV0IGEg ZmV3IGluaXRpYWwgY29tbWVudHMgb24gdGhlIEFic3RyYWN0Og0KDQpUaGUgdGV4dCBzYXlzOg0K DQogICDigJxPU1JUUCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiBPcHBvcnR1bmlzdGljIFNlY3Vy aXR5LCBhcyBkZWZpbmVkIGluIFJGQyA3NDM1LuKAnQ0KDQpRMTogSSBzdWdnZXN0IHRvIHNheSDi gJzigKZvZiB0aGUgT3Bwb3J0dW5pc3RpYyBTZWN1cml0eSBtZWNoYW5pc20sIGRlZmluZWQgaW4g UkZDIDc0MzUsIGZvciBSVFAu4oCdDQoNClEyOiBJIHN1Z2dlc3QgdG8gcGxhY2UgdGhpcyBzZW50 ZW5jZSBmaXJzdCBpbiB0aGUgYWJzdHJhY3QuIEN1cnJlbnRseSB0aGUgZmlyc3Qgc2VudGVuY2Ug dGFsa3MgYWJvdXQgd2hhdCBPU1JUUCBkb2VzLCBiZWZvcmUgaXQgaGFzIGJlZW4gZXhwbGFpbmVk IHdoYXQgT1NSVFAgaXMuDQoNClRoZSB0ZXh0IHNheXM6DQoNCiAgIOKAnE9TUlRQIGRvZXMgbm90 IHJlcXVpcmUgYWR2YW5jZWQgU0RQIGV4dGVuc2lvbnMgb3IgZmVhdHVyZXMgYW5kIGlzDQogICBm dWxseSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIHNlY3VyZSBhbmQgaW5zZWN1 cmUNCiAgIGltcGxlbWVudGF0aW9ucy7igJ0NCg0KUTM6IEkgc3VnZ2VzdCB0byByZW1vdmUg4oCc YWR2YW5jZWTigJ0sIGJlY2F1c2UgSSBkb27igJl0IGtub3cgd2hhdCBhbiBhZHZhbmNlZCBTRFAg ZXh0ZW5zaW9uIGlzIDopDQoNClE0OiBXaGF0IGRvIHlvdSBtZWFuIGJ5IOKAnHNlY3VyZSBhbmQg aW5zZWN1cmUgaW1wbGVtZW50YXRpb25z4oCdPyBJIHRoaW5rIHNvbWUgcmUtd29yZGluZyBvciBj bGFyaWZpY2F0aW9uIGlzIG5lZWRlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog bW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5 IEh1dHRvbg0KU2VudDogMjMgSmFudWFyeSAyMDE3IDEzOjUxDQpUbzogbW11c2ljLWNoYWlyc0Bp ZXRmLm9yZzsgc2lwYnJhbmR5LWNoYWlyc0BpZXRmLm9yZzsgQmVuIENhbXBiZWxsIDxiZW5Abm9z dHJ1bS5jb20+OyBtbXVzaWNAaWV0Zi5vcmcNClN1YmplY3Q6IFtNTVVTSUNdIEZ3ZDogSS1EIEFj dGlvbjogZHJhZnQtaHV0dG9uLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTAwLnR4 dA0KDQoNCkkgaGF2ZSBqdXN0IHN1Ym1pdHRlZCB0aGlzIGRyYWZ0Lg0KDQpUaGUgZHJhZnQgaXMg dGhlIHJlc3VsdCBvZiBkaXNjdXNzaW9uIGluIHRoZSBTSVBCcmFuZHkgd29ya2luZyBncm91cCBy ZWdhcmRpbmcgaG93IHRvIHByb2NlZWQgd2l0aCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1zaXBicmFuZHktb3NydHAtMDEuICBUaGUgU0lQQnJhbmR5IFdHIHdhcyBub3Qg YWJsZSB0byBwcm9ncmVzcyB0aGUgb3Bwb3J0dW5pc3RpYyBTUlRQIHdvcmsgYmVjYXVzZSBpdCBy ZXF1aXJlZCBhbiB1cGRhdGUgdG8gUkZDIDQ1Njggd2hpY2ggaXMgbm90IGNvdmVyZWQgYnkgdGhl IFNJUEJyYW5keSBjaGFydGVyLg0KDQpUaGlzIHNob3J0IGRyYWZ0IGlzIHRoZXJlZm9yZSBzdWJt aXR0ZWQgdG8gTU1VU0lDIHdpdGggYSB2aWV3IHRvIHVwZGF0aW5nIHRoZSByZWxldmFudCBSRkMn cyBhbmQgcHJvZ3Jlc3NpbmcgdGhlIE9TUlRQIHdvcmsgaW4gU0lQQnJhbmR5Lg0KDQpSZWdhcmRz DQpBbmR5DQoNCg0KDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0K RnJvbTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPj4NCkRhdGU6IE1vbiwgSmFuIDIzLCAyMDE3IGF0IDExOjA4IEFNDQpTdWJqZWN0OiBJ LUQgQWN0aW9uOiBkcmFmdC1odXR0b24tbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24t MDAudHh0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0 Zi5vcmc+DQoNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUg b24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQoNCg0KICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBOZWdvdGlhdGluZyBTUlRQIGFuZCBSVENQIEZlZWRiYWNrIHVzaW5nIHRoZSBS VFAvQVZQIFByb2ZpbGUNCiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogQW5kcmV3IEh1dHRvbg0K ICAgICAgICAgICAgICAgICAgICAgICAgICBSb2xhbmQgSmVzc2tlDQogICAgICAgICAgICAgICAg ICAgICAgICAgIEFsYW4gSm9obnN0b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgR29uemFs byBTYWxndWVpcm8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgQmVybmFyZCBBYm9iYQ0KICAg ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1odXR0b24tbW11c2ljLW9wcG9ydHVuaXN0aWMt bmVnb3RpYXRpb24tMDAudHh0DQogICAgICAgIFBhZ2VzICAgICAgICAgICA6IDYNCiAgICAgICAg RGF0ZSAgICAgICAgICAgIDogMjAxNy0wMS0yMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIGhvdyB0aGUgdXNlIG9mIHRoZSBTZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9y dA0KICAgcHJvdG9jb2wgKFNSVFApIFtSRkMzNzExXS4gY2FuIGJlIG5lZ290aWF0ZWQgdXNpbmcg dGhlIEFWUCAoQXVkaW8NCiAgIFZpZGVvIFByb2ZpbGUpIGRlZmluZWQgaW4gW1JGQzM1NTFdLiAg U3VjaCBhIG1lY2hhbmlzbSBpcyB1c2VkIHRvDQogICBwcm92aWRlIGEgbWVhbnMgZm9yIGVuY3J5 cHRlZCBtZWRpYSB0byBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZQ0KICAgc3VwcG9ydCBm b3IgZW5jcnlwdGlvbiBpcyBub3Qga25vd24gaW4gYWR2YW5jZSwgYW5kIG5vdCByZXF1aXJlZC4N CiAgIFRoZSBzYW1lIG1lY2hhbmlzbSBpcyBhbHNvIGFwcGxpZWQgdG8gbmVnb3RpYXRpb24gb2Yg dGhlIEV4dGVuZGVkIFJUUA0KICAgUHJvZmlsZSBmb3IgUmVhbC10aW1lIFRyYW5zcG9ydCBDb250 cm9sIFByb3RvY29sIEJhc2VkIEZlZWRiYWNrIChSVFAvDQogICBBVlBGKSBbUkZDNDU4NV0uDQoN Cg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odXR0b24tbW11c2ljLW9wcG9y dHVuaXN0aWMtbmVnb3RpYXRpb24vDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1t bXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBp ZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVjdG9y aWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4BFC7A6CESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdpbGwgcmVhZCB0aGUgcmVz dCBvZiB0aGUgZG9jdW1lbnQgbGF0ZXIsIGJ1dCBhIGZldyBpbml0aWFsIGNvbW1lbnRzIG9uIHRo ZSBBYnN0cmFjdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSB0 ZXh0IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsm bmJzcDsg4oCcT1NSVFAgaXMgYW4gaW1wbGVtZW50YXRpb24gb2YgT3Bwb3J0dW5pc3RpYyBTZWN1 cml0eSwgYXMgZGVmaW5lZCBpbiBSRkMgNzQzNS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlExOiBJIHN1Z2dlc3QgdG8gc2F5IOKAnOKApm9mIHRoZSBPcHBvcnR1 bmlzdGljIFNlY3VyaXR5IG1lY2hhbmlzbSwgZGVmaW5lZCBpbiBSRkMgNzQzNSwgZm9yIFJUUC7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlEyOiBJIHN1Z2dlc3Qg dG8gcGxhY2UgdGhpcyBzZW50ZW5jZSBmaXJzdCBpbiB0aGUgYWJzdHJhY3QuIEN1cnJlbnRseSB0 aGUgZmlyc3Qgc2VudGVuY2UgdGFsa3MgYWJvdXQgd2hhdCBPU1JUUCBkb2VzLCBiZWZvcmUgaXQg aGFzDQogYmVlbiBleHBsYWluZWQgd2hhdCBPU1JUUCBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSB0ZXh0IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsg4oCcT1NSVFAgZG9lcyBub3QgcmVxdWlyZSBh ZHZhbmNlZCBTRFAgZXh0ZW5zaW9ucyBvciBmZWF0dXJlcyBhbmQgaXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IGZ1bGx5IGJhY2t3YXJk cyBjb21wYXRpYmxlIHdpdGggZXhpc3Rpbmcgc2VjdXJlIGFuZCBpbnNlY3VyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgaW1wbGVtZW50 YXRpb25zLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UTM6IEkgc3VnZ2VzdCB0byByZW1vdmUg4oCcYWR2YW5j ZWTigJ0sIGJlY2F1c2UgSSBkb27igJl0IGtub3cgd2hhdCBhbiBhZHZhbmNlZCBTRFAgZXh0ZW5z aW9uIGlzIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5RNDogV2hh dCBkbyB5b3UgbWVhbiBieSDigJxzZWN1cmUgYW5kIGluc2VjdXJlIGltcGxlbWVudGF0aW9uc+KA nT8gSSB0aGluayBzb21lIHJlLXdvcmRpbmcgb3IgY2xhcmlmaWNhdGlvbiBpcyBuZWVkZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21haWx0 bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5keSBIdXR0 b248YnI+DQo8Yj5TZW50OjwvYj4gMjMgSmFudWFyeSAyMDE3IDEzOjUxPGJyPg0KPGI+VG86PC9i PiBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBzaXBicmFuZHktY2hhaXJzQGlldGYub3JnOyBCZW4g Q2FtcGJlbGwgJmx0O2JlbkBub3N0cnVtLmNvbSZndDs7IG1tdXNpY0BpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBbTU1VU0lDXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWh1dHRvbi1tbXVz aWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBqdXN0IHN1Ym1pdHRlZCB0aGlzIGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZHJh ZnQgaXMgdGhlIHJlc3VsdCBvZiBkaXNjdXNzaW9uIGluIHRoZSBTSVBCcmFuZHkgd29ya2luZyBn cm91cCByZWdhcmRpbmcgaG93IHRvIHByb2NlZWQgd2l0aCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wMSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwLTAxPC9hPi4m bmJzcDsgVGhlIFNJUEJyYW5keQ0KIFdHIHdhcyBub3QgYWJsZSB0byBwcm9ncmVzcyB0aGUgb3Bw b3J0dW5pc3RpYyBTUlRQIHdvcmsgYmVjYXVzZSBpdCByZXF1aXJlZCBhbiB1cGRhdGUgdG8gUkZD IDQ1Njggd2hpY2ggaXMgbm90IGNvdmVyZWQgYnkgdGhlIFNJUEJyYW5keSBjaGFydGVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNo b3J0IGRyYWZ0IGlzIHRoZXJlZm9yZSBzdWJtaXR0ZWQgdG8gTU1VU0lDIHdpdGggYSB2aWV3IHRv IHVwZGF0aW5nIHRoZSByZWxldmFudCBSRkMncyBhbmQgcHJvZ3Jlc3NpbmcgdGhlIE9TUlRQIHdv cmsgaW4gU0lQQnJhbmR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZy b206ICZsdDs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQpEYXRlOiBNb24s IEphbiAyMywgMjAxNyBhdCAxMTowOCBBTTxicj4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0 LWh1dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQ8YnI+DQpUbzog PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmkt ZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMg ZGlyZWN0b3JpZXMuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IE5lZ290aWF0 aW5nIFNSVFAgYW5kIFJUQ1AgRmVlZGJhY2sgdXNpbmcgdGhlIFJUUC9BVlAgUHJvZmlsZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogQW5kcmV3IEh1dHRvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBSb2xhbmQgSmVzc2tlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IEFsYW4gSm9obnN0b248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgR29uemFsbyBTYWxndWVpcm88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgQmVybmFyZCBBYm9iYTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFt ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWh1dHRvbi1tbXVzaWMtb3Bwb3J0 dW5pc3RpYy1uZWdvdGlhdGlvbi0wMC50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogNjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE3LTAxLTIzPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0K Jm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0aGUgdXNlIG9mIHRoZSBT ZWN1cmUgUmVhbC10aW1lIHRyYW5zcG9ydDxicj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbCAoU1JU UCkgW1JGQzM3MTFdLiBjYW4gYmUgbmVnb3RpYXRlZCB1c2luZyB0aGUgQVZQIChBdWRpbzxicj4N CiZuYnNwOyAmbmJzcDtWaWRlbyBQcm9maWxlKSBkZWZpbmVkIGluIFtSRkMzNTUxXS4mbmJzcDsg U3VjaCBhIG1lY2hhbmlzbSBpcyB1c2VkIHRvPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3ZpZGUgYSBt ZWFucyBmb3IgZW5jcnlwdGVkIG1lZGlhIHRvIGJlIHVzZWQgaW4gZW52aXJvbm1lbnRzIHdoZXJl PGJyPg0KJm5ic3A7ICZuYnNwO3N1cHBvcnQgZm9yIGVuY3J5cHRpb24gaXMgbm90IGtub3duIGlu IGFkdmFuY2UsIGFuZCBub3QgcmVxdWlyZWQuPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBzYW1lIG1l Y2hhbmlzbSBpcyBhbHNvIGFwcGxpZWQgdG8gbmVnb3RpYXRpb24gb2YgdGhlIEV4dGVuZGVkIFJU UDxicj4NCiZuYnNwOyAmbmJzcDtQcm9maWxlIGZvciBSZWFsLXRpbWUgVHJhbnNwb3J0IENvbnRy b2wgUHJvdG9jb2wgQmFzZWQgRmVlZGJhY2sgKFJUUC88YnI+DQombmJzcDsgJm5ic3A7QVZQRikg W1JGQzQ1ODVdLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWh1dHRvbi1tbXVzaWMtb3Bwb3J0dW5pc3RpYy1uZWdvdGlhdGlv bi8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1odXR0b24tbW11c2ljLW9wcG9ydHVuaXN0aWMtbmVnb3RpYXRpb24vPC9hPjxicj4NCjxicj4N ClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odXR0b24tbW11c2ljLW9wcG9y dHVuaXN0aWMtbmVnb3RpYXRpb24tMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLW1tdXNpYy1vcHBvcnR1bmlzdGljLW5lZ290aWF0aW9u LTAwPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+ Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv PC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5JLUQtQW5ub3VuY2VAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2VJbnRlcm5ldC1EcmFmdCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPGJyPg0KSW50ZXJuZXQt RHJhZnQ8L2E+IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRv dy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s PC9hPjxicj4NCm9yIDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0 ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1z aXRlcy50eHQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4BFC7A6CESESSMB209erics_-- From nobody Fri Jan 27 10: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 052D91296C1; Fri, 27 Jan 2017 10:20:36 -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 AoPP6NJCFXIz; Fri, 27 Jan 2017 10:20:34 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 D7DFD1296C8; Fri, 27 Jan 2017 10:20:29 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id x75so180669954vke.2; Fri, 27 Jan 2017 10:20:29 -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=1ByUom2aAVza8IazdbFUD09On3hOjueBvpgX56bvwEo=; b=PYkc17HRU7Q/uVwMeDTn4lhwai77+2gu8VvZ+dcyZJKJFFxs3WwJIH+oQmKDZQjhRW /r+5gy2b8Pi7koEaqGTvzjBfsIrRqljPJPa3sim3tD9SaaqaWyrp2iJokRcg04GAFkAi cV0v+PXEp6ysW+kSXzV7x+cGERR0ZOopAwbOBlbZAHbn1u8mW54ZCsBvvwCOGUXfoARR CpGkKaStFgbRapr+/DbWHhKqfTUMj7HnRrqRo4vqhKJIkcSfLd1z3RQorfQ+5AbrVHBM CqWZcDpbEjNJE/AOwuwvONyM9JIleqQgGe+RYhaqO6rleS5g76efHztictAcZRIVVltT 0aqw== 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=1ByUom2aAVza8IazdbFUD09On3hOjueBvpgX56bvwEo=; b=GwikaBUphgdU+o0mLlAUIL2ixpWMgKuFlRRNzdj515/AulIBrBNU1IRYe9K+Hmb5xS kdloIjZB9UjgIO3czBd54vs6h2ed+JDTwhhi4bUoVoVWVvU10C0xJkzDzK79XtJXIVNh ObuTYzaVZV2dP2aS6LK0Bcn6GXM5pyZaHpV5XHTW78n8TlgshmEMpMogzWc3S0KLpLw5 IZv9tA1X63X5vdPNj2Z8TuN4CivkJYXM1+mIlQrolWuh1Ap81hwYd2qXYrwa0kpbcCfd WwkB1UKyGLOQ14+13plFjiBCOlbYzs//icWltpTyuRDtNuaifizGnNZwiCUQD5q2n9LB a0Eg== X-Gm-Message-State: AIkVDXKuGjDCm2lgYEnOql2vUTCFn0BEtunVFz1qv+vh9mPeVUtDxwUB6NwJWNQC/QVh6iFE4hjyJwb3QfpjQg== X-Received: by 10.31.98.196 with SMTP id w187mr4009274vkb.169.1485541228892; Fri, 27 Jan 2017 10:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Fri, 27 Jan 2017 10:20:08 -0800 (PST) In-Reply-To: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Bernard Aboba Date: Fri, 27 Jan 2017 10:20:08 -0800 Message-ID: To: Flemming Andreasen Content-Type: multipart/alternative; boundary=94eb2c07b57a3f5ccb0547178534 Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 18:20:36 -0000 --94eb2c07b57a3f5ccb0547178534 Content-Type: text/plain; charset=UTF-8 I am in favor of the change. On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen wrote: > Hi Harald > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. > > However, from an MMUSIC chair point of view, I would like to get positive > confirmation from some of the stakeholders that this change is indeed > desired. Similarly, if anybody has any concerns with the suggested change, > please send an e-mail to that effect. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: > >> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >> >>> Ted pointed out to me that I sent this to the wrong group. >>> >>> Chairs and members, please advise. >>> >> My proposed change is here: >> >> https://github.com/alvestrand/rtcweb-msid/pull/16 >> >> The filed issue is here: >> >> https://github.com/alvestrand/rtcweb-msid/issues/15 >> >> (CCing RTCWEB - please keep discussion, if any, on mmusic) >> >> >>> >>> -------- Forwarded Message -------- >>> Subject: [rtcweb] Modifying an approved document: MSID >>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>> From: Harald Alvestrand >>> To: rtcweb@ietf.org >>> >>> >>> >>> When reviewing the implications of the PeerConnection API change to >>> support AddTrack rather than AddStream, I found an issue. >>> >>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>> REF-WAIT state (I believe). >>> >>> The issue is that it is possible to add a track without specifying a >>> stream. Since the track's ID needs to be carried, we have to send an >>> "a=msid" line, but the track's ID is the *second* field on that line, >>> with the first being the stream's ID. >>> >>> This creates a problem. >>> >>> Suggested fix: Insert two lines in the document: >>> >>> 1) On SDP generation: >>> >>> "If there is no stream associated with the track, use the reserved ID >>> value '-'" >>> >>> 2) On SDP parsing >>> >>> "If the stream ID is the reserved value '-', the track is not associated >>> with a stream, and no stream is signalled or created." >>> >>> If this is OK with the community, I'll issue an updated draft with this >>> change. >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >>> >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >>> >>> >>> _______________________________________________ >>> 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 >> . >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c07b57a3f5ccb0547178534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of the change.

On Thu, Jan 26, 2017 at 5:54 AM, Flemming= Andreasen <fandreas@cisco.com> wrote:
Hi Harald

Since the document is not yet in Auth48 and the change is relatively minor,= it is possible to update it during Auth48.

However, from an MMUSIC chair point of view, I would like to get positive c= onfirmation from some of the stakeholders that this change is indeed desire= d. Similarly, if anybody has any concerns with the suggested change, please= send an e-mail to that effect.

Thanks

-- Flemming (as MMUSIC co-chair)



On 1/23/17 10:18 AM, Harald Alvestrand wrote:
Den 19. jan. 2017 13:31, skrev Harald Alvestrand:
Ted pointed out to me that I sent this to the wrong group.

Chairs and members, please advise.
My proposed change is here:

https://github.com/alvestrand/rtcweb-msid/pull= /16

The filed issue is here:

https://github.com/alvestrand/rtcweb-msid/is= sues/15

(CCing RTCWEB - please keep discussion, if any, on mmusic)



-------- Forwarded Message --------
Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 [rtcweb] Modifying an approved document= : MSID
Date:=C2=A0 =C2=A0Wed, 18 Jan 2017 23:22:14 +0100
From:=C2=A0 =C2=A0Harald Alvestrand <harald@alvestrand.no>
To:=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <rtcweb@ietf.org>



When reviewing the implications of the PeerConnection API change to
support AddTrack rather than AddStream, I found an issue.

This issue concerns draft-ietf-rtcweb-msid, which is currently in
REF-WAIT state (I believe).

The issue is that it is possible to add a track without specifying a
stream. Since the track's ID needs to be carried, we have to send an "a=3Dmsid" line, but the track's ID is the *second* field on = that line,
with the first being the stream's ID.

This creates a problem.

Suggested fix: Insert two lines in the document:

1) On SDP generation:

"If there is no stream associated with the track, use the reserved ID<= br> value '-'"

2) On SDP parsing

"If the stream ID is the reserved value '-', the track is not = associated
with a stream, and no stream is signalled or created."

If this is OK with the community, I'll issue an updated draft with this=
change.


--
Surveillance is pervasive. Go Dark.

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


_______________________________________________
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 .


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

--94eb2c07b57a3f5ccb0547178534-- From nobody Fri Jan 27 19:46: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 BAFAE129B84; Fri, 27 Jan 2017 19:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh1KJLIxq9uw; Fri, 27 Jan 2017 19:46:42 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d: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 BA695129B82; Fri, 27 Jan 2017 19:46:41 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id u25so81949610qki.2; Fri, 27 Jan 2017 19:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DFHFd6DZ9jAxdCCXPx83hThZFSdrasoOx+ssji+2ugo=; b=CjYtGkM2fUyH8ZSd8mEoluaP4SDHVc2WCzeSdNiEQs/zYZ+uuR/Cp8woxuc+ArWEzC VpCtQ9R9AcUf3sXoXN2IUwS0I4CpsX+crWDSO1YN8vhuQVFlDaOlNrPP6R7jCjUBhBj4 DjDIKtQPTQKGemRwFTTozx4Op7oCl34/eMUDdiySGS2WHF2xS5ncJrXp5LWC2DxgnaWr mRdYpu+9+UytBuhBNDk5PDNyQBoRD8bQ8o4qc6z01RL20WVeN8q71plO9amN2aQOKUec 2Lsd/MVTvj7m0hsI9qN+i3Twh5xNJ/gqVjMy77clW7GDmTNszEFcl5HWCyaznEFlt4Ri JXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DFHFd6DZ9jAxdCCXPx83hThZFSdrasoOx+ssji+2ugo=; b=OHjs3uSTfmzpKpLmuR99d3ZpKdiOF6TL7NaGS8K74gzLUajD9W0VlOrpCb0MuwnzSn GojcM+9mWGqZWMf3R9SWp52UGpcAlDUJQQULIEQVe5+c9+Te4CvlmE4LdHrzfBFI6tf8 mpyw8CHo4glgAPPQF/5s1+iPJcb7ZTtmur2DEwKuC9JvyWxdTk0yO6YhsU3zuj+Q8OYj 2oKRFJNQQJKwZKu2MAcAEgQ/5xOavatpijn/kAFYeaLbhYdj7ohsp4AKG5jrgRcO4Yoc LITR1ITVoKgt5ZW0UJUjGz9X7aGyEU8hDnJev6I/LJTpuTsXybfdA+9LpC7oORxEEd1E 9wZA== X-Gm-Message-State: AIkVDXKT2OdrHwNI1JFC4KNqKiUHvxfrKz1wLaI2dHGsgMIemC/wcHrmueH/Njq8Nas4J1SiiPB58cacxYjn/g== X-Received: by 10.55.21.84 with SMTP id f81mr11540349qkh.5.1485575200762; Fri, 27 Jan 2017 19:46:40 -0800 (PST) MIME-Version: 1.0 References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> In-Reply-To: From: Suhas Nandakumar Date: Sat, 28 Jan 2017 03:46:30 +0000 Message-ID: To: Bernard Aboba , Flemming Andreasen Content-Type: multipart/alternative; boundary=001a1147b90420ef1205471f6ede Archived-At: Cc: "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 28 Jan 2017 03:46:44 -0000 --001a1147b90420ef1205471f6ede Content-Type: text/plain; charset=UTF-8 +1 On Fri, Jan 27, 2017 at 10:20 AM Bernard Aboba wrote: > I am in favor of the change. > > On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen > wrote: > > Hi Harald > > > > > > Since the document is not yet in Auth48 and the change is relatively > minor, it is possible to update it during Auth48. > > > > > > However, from an MMUSIC chair point of view, I would like to get positive > confirmation from some of the stakeholders that this change is indeed > desired. Similarly, if anybody has any concerns with the suggested change, > please send an e-mail to that effect. > > > > > > Thanks > > > > > > -- Flemming (as MMUSIC co-chair) > > > > > > > > > > > > On 1/23/17 10:18 AM, Harald Alvestrand wrote: > > > > > Den 19. jan. 2017 13:31, skrev Harald Alvestrand: > > > > > Ted pointed out to me that I sent this to the wrong group. > > > > > > Chairs and members, please advise. > > > > > My proposed change is here: > > > > > > https://github.com/alvestrand/rtcweb-msid/pull/16 > > > > > > The filed issue is here: > > > > > > https://github.com/alvestrand/rtcweb-msid/issues/15 > > > > > > (CCing RTCWEB - please keep discussion, if any, on mmusic) > > > > > > > > > > > > > > -------- Forwarded Message -------- > > > Subject: [rtcweb] Modifying an approved document: MSID > > > Date: Wed, 18 Jan 2017 23:22:14 +0100 > > > From: Harald Alvestrand > > > To: rtcweb@ietf.org > > > > > > > > > > > > When reviewing the implications of the PeerConnection API change to > > > support AddTrack rather than AddStream, I found an issue. > > > > > > This issue concerns draft-ietf-rtcweb-msid, which is currently in > > > REF-WAIT state (I believe). > > > > > > The issue is that it is possible to add a track without specifying a > > > stream. Since the track's ID needs to be carried, we have to send an > > > "a=msid" line, but the track's ID is the *second* field on that line, > > > with the first being the stream's ID. > > > > > > This creates a problem. > > > > > > Suggested fix: Insert two lines in the document: > > > > > > 1) On SDP generation: > > > > > > "If there is no stream associated with the track, use the reserved ID > > > value '-'" > > > > > > 2) On SDP parsing > > > > > > "If the stream ID is the reserved value '-', the track is not associated > > > with a stream, and no stream is signalled or created." > > > > > > If this is OK with the community, I'll issue an updated draft with this > > > change. > > > > > > > > > -- > > > Surveillance is pervasive. Go Dark. > > > > > > _______________________________________________ > > > rtcweb mailing list > > > rtcweb@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtcweb > > > > > > > > > > > > _______________________________________________ > > > 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 > > > . > > > > > > > > > > > _______________________________________________ > > > 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 > > --001a1147b90420ef1205471f6ede Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1=C2=A0
On Fri, Jan 27, 2017 at 10= :20 AM Bernard Aboba <bernard= .aboba@gmail.com> wrote:
I am in favor of the change.

On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
Hi Harald
=




Since the document is not yet in Au= th48 and the change is relatively minor, it is possible to update it during= Auth48.





How= ever, from an MMUSIC chair point of view, I would like to get positive conf= irmation from some of the stakeholders that this change is indeed desired. = Similarly, if anybody has any concerns with the suggested change, please se= nd an e-mail to that effect.





Thanks





-- Flemming (as MMUSIC co-chair)










On 1/23/17 10:18 AM, Harald Alvestrand wrote:




= Den 19. jan. 2017 13:31, skrev Harald Alvestrand:



Ted pointed out to m= e that I sent this to the wrong group.





Chairs and members, please advise.




My proposed change is here:





https://github.com/alvestrand/rtcweb-msid/pull/16





The filed= issue is here:




=
https://github.com/alvest= rand/rtcweb-msid/issues/15





(CCing RTCWEB - please keep discussion, if any, on mmusi= c)












-------- Forwarded Message --------


Subject:=C2=A0 =C2=A0 =C2=A0 =C2=A0 [rtcweb] Modifyi= ng an approved document: MSID


Date:=C2=A0 = =C2=A0Wed, 18 Jan 2017 23:22:14 +0100


From:= =C2=A0 =C2=A0Harald Alvestrand <harald@alvestrand.no>


To:=C2=A0 =C2=A0 =C2=A0rtcweb@ietf.org <rtcweb@ie= tf.org>




<= br>





When rev= iewing the implications of the PeerConnection API change to


support AddTrack rather than AddStream, I found an issue.




This issue co= ncerns draft-ietf-rtcweb-msid, which is currently in


REF-WAIT state (I believe).





The issue is that it is possible to add a track wi= thout specifying a


stream. Since the track&#= 39;s ID needs to be carried, we have to send an

=
"a=3Dmsid" line, but the track's ID is the *second* field= on that line,


with the first being the stre= am's ID.




This creates a problem.





Suggested fix: Insert two lines in the document:





1) On SDP generation:





"If there = is no stream associated with the track, use the reserved ID


value '-'"





2) On SDP parsing




"If the stream ID is the reserved va= lue '-', the track is not associated

with a stream, and no stream is signalled or created."





If this is OK with the com= munity, I'll issue an updated draft with this

change.







--


Survei= llance is pervasive. Go Dark.





_______________________________________________


rtcweb mailing list


<= a href=3D"mailto:rtcweb@ietf.org" class=3D"gmail_msg" target=3D"_blank">rtc= web@ietf.org


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










_____________________________________= __________


mmusic mailing list


mmusic@ietf.org


https://www.ietf.org/mailman/listinfo/mmus= ic







_______________________________________________


mmusic mailing list


mmusic= @ietf.org


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


.




=





__________________= _____________________________


mmusic mailing= list


mmusic@ietf.org


https://www.ietf.org/mail= man/listinfo/mmusic


<= br class=3D"gmail_msg">


______________________________________= _________

mmusic mailing list

mmusic@ietf.org

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

--001a1147b90420ef1205471f6ede-- From nobody Sat Jan 28 09:10:43 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 9277212963C; Sat, 28 Jan 2017 09:10:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148562343759.17909.109780305593857821.idtracker@ietfa.amsl.com> Date: Sat, 28 Jan 2017 09:10:37 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-18.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 17:10: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 of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-18.txt Pages : 25 Date : 2017-01-28 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'dtls-id'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-18 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 Jan 30 05:19:04 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 77CA412949E; Mon, 30 Jan 2017 05:18:59 -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 UHMLn-JW5-hp; Mon, 30 Jan 2017 05:18: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 98FB8129499; Mon, 30 Jan 2017 05:18:56 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-23-588f3d3dc143 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id B3.FF.16488.D3D3F885; Mon, 30 Jan 2017 14:18:54 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.319.2; Mon, 30 Jan 2017 14:18:53 +0100 To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> From: Magnus Westerlund Message-ID: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Date: Mon, 30 Jan 2017 14:18:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM2K7va6dbX+Ewdp75hbTZ71js5jfsY7N YuryxywWa/+1szuweCxZ8pPJ48vlz2wBTFFcNimpOZllqUX6dglcGdM77zAWzG9irOiYe5Ct gXFfXBcjJ4eEgInExRfd7F2MXBxCAusYJVY17GEBSQgJLGeUuP2lDMQWFiiSOPCyjRmkSETg CaNE/4LHQEXsQEX2Eo+FQErYBCwkbv5oZAOxeYGiC9c2gdksAqoSs++uARspKhAj8Xb9cnaI GkGJkzOfgMU5BRwklnZOY+1i5OBgBup9sBVsK7OAvETz1tnMENdoSzQ0dbBOYOSfhaR7FkLH LCQdCxiZVzGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIEhuPBLb+tdjAefO54iFGAg1GJh3eD dV+EEGtiWXFl7iFGCQ5mJRHeSRb9EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8s Sc1OTS1ILYLJMnFwSjUwVl9ZZyXGZhK3ry8xYSZ72/4n31runLhvIrQlTmW226bZ85q2LC5b vT7U6KHA1bkCq59e4GtPUzyl+PwJY8xf/yJ9gfvrdp/WTj3T4RRffqhVxm2So4XG7KMyC+t7 TL+1LnqTyiu26dcttYeZ/1f7hLpmzH3+nvNbnJTbZ/bty+6ymp6r8Vc8rMRSnJFoqMVcVJwI AF2C9uFDAgAA Archived-At: Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 13:18:59 -0000 Hi, I have now generated a pull request for this text, with some very minor changes. https://github.com/rtcweb-wg/jsep/pull/538 Cheers Magnus Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: > MMUSIC and RTCWEB, > > Here is now a more complete text proposal that also considers the RTCP. > It also goes further than what Appendix B defines in one aspect, namely > explicitly considering third party RTCP reporting and what to do with it. > > Feedback is much appreciated. I plan to put this into a PR towards JSEP > APPENDIX B on monday. If only to get the JSEP authors attention ;-). > However, the text is really intended for the next version of BUNDLE. > > > X. Associating RTP/RTCP With Correct SDP Media Description > > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. > > In order to be able to process received RTP/RTCP packets correctly it > must be possible to associate an RTP stream with the correct "m=" > line, as the "m=" line and SDP attributes associated with the "m=" > line contain information needed to process the packets. > > As all RTP streams associated with a BUNDLE group are part of the > same RTP session and using the same address:port combination for > sending and receiving RTP/RTCP packets, the local address:port > combination cannot be used to associate an RTP stream with the > correct "m=" line. In addition, multiple RTP streams might be > associated with the same "m=" line. > > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=" > line. However, there are cases where each "m=" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=" line the RTP stream is associated > with. > > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing > > > > Name Expires July 31, 2017 [Page 2] > > Internet-Draft Abbreviated-Title January 2017 > > > that information. Due to this, before the offerer has received the > answer, the offerer will not be able to associate an RTP stream with > the correct "m=" line using the SSRC value associated with the RTP > stream. In addition, the offerer and answerer may start using new > SSRC values mid-session, without informing each other using the SDP > 'ssrc' attribute. > > In order for an offerer and answerer to always be able to associate > an RTP stream with the correct "m=" line, the offerer and answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. > > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. > > To prepare for demultiplexing RTP streams to the correct "m=" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. > > Construct a table mapping MID to "m=" line for each "m=" line in > this BUNDLE group. Note that an "m=" line may only have one MID. > > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=" line for each "m=" line in this BUNDLE group and for each RTP > stream explicitly signalled for receiving in that "m=" line. > > Construct a table mapping payload types to "m=" line for each "m=" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=" line. If any payload type is configured > for receiving in more than one "m=" line in the BUNDLE group, do > not it include it in the table. > > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. > > As "m=" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. > > > > Name Expires July 31, 2017 [Page 3] > > Internet-Draft Abbreviated-Title January 2017 > > > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: > > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m= line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=" line mapping table the following checks > MUST be performed: > > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=" line, then > do not deliver the RTP packet to higher layers. > > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=" line, and the > value indicates a different "m=" line than the current RTP > stream to "m=" line mapping table, then update the RTP stream > to "m=" line mapping. > > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m= line. In this case the following actions MUST > be performed: > > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=" line, then > create an entry in the RTP stream to "m=" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=" line context of the created mapping and stop. > > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=" line context of the created > mapping and stop. > > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. > > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=" line mapping table. > > > > Name Expires July 31, 2017 [Page 4] > > Internet-Draft Abbreviated-Title January 2017 > > > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=" > line mapping, else the entry is updated. If there is no RTP stream > to "m=" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. > > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: > > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=" line the RTP Stream to > "m=" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: > > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. > > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. > > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which > > > > Name Expires July 31, 2017 [Page 5] > > Internet-Draft Abbreviated-Title January 2017 > > > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: > > Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). > > Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). > > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, > FMT=3). > > Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). > > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: > > Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). > > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, > FMT=5). > > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=PSFB, FMT=5) is actually a notifciation in > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. > > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, > FMT=7). > > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, > FMT=TBD). > > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=" line for the incoming RTP stream as > identified by the current RTP stream to "m=" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: > > > > > > Name Expires July 31, 2017 [Page 6] > > Internet-Draft Abbreviated-Title January 2017 > > > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. > > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. > > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. > > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=" lines, thus deliver a copy of the packet to each "m=" line or > an APP specific handler. > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 30 05:29:03 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 BB51412945D; Mon, 30 Jan 2017 05:28:58 -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 mk-TdxHXH1pR; Mon, 30 Jan 2017 05:28:56 -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 7A25812941A; Mon, 30 Jan 2017 05:28:56 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id c85so214601500wmi.1; Mon, 30 Jan 2017 05:28:56 -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:content-transfer-encoding; bh=WCyemRK+F02X54eqUnDCZACYAffLtYoODkVIJbvR5sU=; b=VB76go4mAOHi8sOUkXq4pSCF5OzdBSZVsw0uPA9+O4chNL6VxZrCBKC47gXhAF7cDp jjtW0fJ6oYStMKJhuqvc78dXnQSmmjjroC2QVZjUIlWNVVhxoQcjkFsGx0JN+5nJAMdT yw1l1PK9w+QUA5SEatm9ZCvrM3FIeKawgm7nmldJZlmJH+NvXTwim3r8U5ikLhCTIHZI yYBSs9g1yC0kKyEMfclQY1xmA61ci2E5lz5gYc7DlPkwYWeVyfcabD0CIe3NGGewEKD7 L6OEQNUCPL1JxQyJg/1j14C1Afy1piu4B7jUQFPTwB+XOxrvQWbuoqZ3zYjVCE4ZuK5u gJBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WCyemRK+F02X54eqUnDCZACYAffLtYoODkVIJbvR5sU=; b=ixNfUMg5omvXLx9McikDcNZqGWKHk1rkMuw3X3XJquAv5a8J5PXV5FyO+qIlK77AFz 44Tt4XajTCTwN6NpTAInTBSDjB+G9f422YeCEDMXYeAF0b6AurlOjcBbzbZbOcM9jZHY o21lTwy955ofMaum56AFebMRdF4R781FFL2tp7KjtN1P1o2UG9fYAjRe0eNXXIzfrT1f nDsdWj++2phi4DiovcFv/XMpPo9nGKBs0uqrWZQS0rfdyNa3Qf77+ZFNbLqPYROuE43F PxZXpId5xa+t7IEQ+PvuVPpYgXu0oEmjPeA3m88cHERvBCd7/iuQ1fQDRPGsT+hQm1F1 Qg3A== X-Gm-Message-State: AIkVDXK8vcFUQXHbt1LkiKR08x3VCsUdW6vOVrDHHnU2zZ/VDXY9oskFz//fFRbVZJkFQExSAnWXnviPotpndA== X-Received: by 10.28.131.132 with SMTP id f126mr15327539wmd.61.1485782934868; Mon, 30 Jan 2017 05:28:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.145.237 with HTTP; Mon, 30 Jan 2017 05:28:54 -0800 (PST) In-Reply-To: References: <24b5eee4-29b1-33b0-ecea-58c766636311@alvestrand.no> <50b49dbf-7de1-a7c4-923f-f702ac14215e@alvestrand.no> <0df3cbb0-a3e7-011c-c4d5-63aad9350283@alvestrand.no> From: Victor Pascual Avila Date: Mon, 30 Jan 2017 14:28:54 +0100 Message-ID: To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Flemming Andreasen , "rtcweb@ietf.org" , mmusic WG Subject: Re: [MMUSIC] Change Alert [Re: Modifying an approved document: MSID] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 30 Jan 2017 13:28:59 -0000 fine with me On Fri, Jan 27, 2017 at 7:20 PM, Bernard Aboba wr= ote: > I am in favor of the change. > > On Thu, Jan 26, 2017 at 5:54 AM, Flemming Andreasen > wrote: >> >> Hi Harald >> >> Since the document is not yet in Auth48 and the change is relatively >> minor, it is possible to update it during Auth48. >> >> However, from an MMUSIC chair point of view, I would like to get positiv= e >> confirmation from some of the stakeholders that this change is indeed >> desired. Similarly, if anybody has any concerns with the suggested chang= e, >> please send an e-mail to that effect. >> >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> >> >> On 1/23/17 10:18 AM, Harald Alvestrand wrote: >>> >>> Den 19. jan. 2017 13:31, skrev Harald Alvestrand: >>>> >>>> Ted pointed out to me that I sent this to the wrong group. >>>> >>>> Chairs and members, please advise. >>> >>> My proposed change is here: >>> >>> https://github.com/alvestrand/rtcweb-msid/pull/16 >>> >>> The filed issue is here: >>> >>> https://github.com/alvestrand/rtcweb-msid/issues/15 >>> >>> (CCing RTCWEB - please keep discussion, if any, on mmusic) >>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: [rtcweb] Modifying an approved document: MSID >>>> Date: Wed, 18 Jan 2017 23:22:14 +0100 >>>> From: Harald Alvestrand >>>> To: rtcweb@ietf.org >>>> >>>> >>>> >>>> When reviewing the implications of the PeerConnection API change to >>>> support AddTrack rather than AddStream, I found an issue. >>>> >>>> This issue concerns draft-ietf-rtcweb-msid, which is currently in >>>> REF-WAIT state (I believe). >>>> >>>> The issue is that it is possible to add a track without specifying a >>>> stream. Since the track's ID needs to be carried, we have to send an >>>> "a=3Dmsid" line, but the track's ID is the *second* field on that line= , >>>> with the first being the stream's ID. >>>> >>>> This creates a problem. >>>> >>>> Suggested fix: Insert two lines in the document: >>>> >>>> 1) On SDP generation: >>>> >>>> "If there is no stream associated with the track, use the reserved ID >>>> value '-'" >>>> >>>> 2) On SDP parsing >>>> >>>> "If the stream ID is the reserved value '-', the track is not associat= ed >>>> with a stream, and no stream is signalled or created." >>>> >>>> If this is OK with the community, I'll issue an updated draft with thi= s >>>> change. >>>> >>>> >>>> -- >>>> Surveillance is pervasive. Go Dark. >>>> >>>> _______________________________________________ >>>> rtcweb mailing list >>>> rtcweb@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtcweb >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> . >>> >> >> _______________________________________________ >> 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 > --=20 Victor Pascual =C3=81vila From nobody Tue Jan 31 00:29: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 A954C129444; Tue, 31 Jan 2017 00:29: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 6lK1BrJj936R; Tue, 31 Jan 2017 00:29:49 -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 4800C129430; Tue, 31 Jan 2017 00:29:48 -0800 (PST) X-AuditID: c1b4fb3a-d4bff70000004068-39-58904af91fa5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id F8.D6.16488.9FA40985; Tue, 31 Jan 2017 09:29:46 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 09:29:35 +0100 To: "mmusic (E-mail)" , "rtcweb@ietf.org" , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" , References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> From: Magnus Westerlund Message-ID: <40af9040-0cd9-0c0c-b10d-ea3256491117@ericsson.com> Date: Tue, 31 Jan 2017 09:29:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2e0ea537-d03e-f263-ad64-cdd65ecd3fb5@ericsson.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7n+4vrwkRBk0HlCymz3rHZjG/Yx2b xdTlj1ks1v5rZ3dg8Viy5CeTx5fLn9kCmKK4bFJSczLLUov07RK4Mu78vs5WML2TseLWgols DYx7U7oYOTkkBEwkFq++wdTFyMUhJLCOUeLa8gZmCGc5o8Tj3W9YQaqEBaolNsz+CVYlIvCE UaJ/wWMWkISQQKnE+4lXwWw2AQuJmz8a2UBsXgF7iSULfjGD2CwCqhI7Hl1iB7FFBWIk3q5f zg5RIyhxcuYTsF5OAQeJh50LgZZxcDAD9T7YWgYSZhaQl2jeOpsZYpW2RENTB+sERv5ZSLpn IXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgUB7c8ttqB+PB546HGAU4GJV4 eA16+yOEWBPLiitzDzFKcDArifCqO0+IEOJNSaysSi3Kjy8qzUktPsQozcGiJM5rtvJ+uJBA emJJanZqakFqEUyWiYNTqoGRd/nVr7+83yelb8s82xS2nC/mn0uj4SSpEwl638PZG9wmad5a VG3uWCPg5qDzMjFA+Oe57u2p36JOzUvdv2Ra7bN5jieXnnCMVNnSfHmFXt6HPd+N1Lc5aLeG a0yN/id969Htr3K3Ys6KMLkskbsjzvR61fPqaSqza68dC65dEOvU1Gv8fHeZEktxRqKhFnNR cSIAdk9LjEYCAAA= Archived-At: Subject: Re: [MMUSIC] [rtcweb] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 08:29:52 -0000 Hi, There was a request for a readable diff on github, so I have produced one: http://www.denstore.se/IETF/Diff-jsep-18-part.html However, I will note that it is likely only relevant to see the changes up until the received RTP packet routing steps. Then the changes are so massive due to restructuring that the diff is not particularly useful. I will also note that the text on github has been improved with some language corrections proposed by Bernard Aboba. Cheers Magnus Den 2017-01-30 kl. 14:18, skrev Magnus Westerlund: > Hi, > > I have now generated a pull request for this text, with some very minor > changes. > > https://github.com/rtcweb-wg/jsep/pull/538 > > Cheers > > Magnus > > Den 2017-01-27 kl. 17:43, skrev Magnus Westerlund: >> MMUSIC and RTCWEB, >> >> Here is now a more complete text proposal that also considers the RTCP. >> It also goes further than what Appendix B defines in one aspect, namely >> explicitly considering third party RTCP reporting and what to do with it. >> >> Feedback is much appreciated. I plan to put this into a PR towards JSEP >> APPENDIX B on monday. If only to get the JSEP authors attention ;-). >> However, the text is really intended for the next version of BUNDLE. >> >> >> X. Associating RTP/RTCP With Correct SDP Media Description >> >> As described in [RFC3550], RTP packets are associated with RTP >> streams [RFC7656]. Each RTP stream is identified by an SSRC value, >> and each RTP packet carries an SSRC value that is used to associate >> the packet with the correct RTP stream. RTCP packets also uses SSRCs >> to identify on which RTP streams any report or feedback relate to. >> Thus, an RTCP packet will commonly carry multiple SSRC values, and >> might therefore be providing feedback or report on multiple RTP >> streams. >> >> In order to be able to process received RTP/RTCP packets correctly it >> must be possible to associate an RTP stream with the correct "m=" >> line, as the "m=" line and SDP attributes associated with the "m=" >> line contain information needed to process the packets. >> >> As all RTP streams associated with a BUNDLE group are part of the >> same RTP session and using the same address:port combination for >> sending and receiving RTP/RTCP packets, the local address:port >> combination cannot be used to associate an RTP stream with the >> correct "m=" line. In addition, multiple RTP streams might be >> associated with the same "m=" line. >> >> Also, as described in Section 10.1.1, the same payload type value >> might be used by multiple RTP streams, in which case the payload type >> value cannot be used to associate an RTP stream with the correct "m=" >> line. However, there are cases where each "m=" line has unique >> payload type values, and then the payload type could serve as >> indicator to the relevant "m=" line the RTP stream is associated >> with. >> >> An offerer and answerer can inform each other which SSRC values they >> will use for an RTP stream by using the SDP 'ssrc' attribute >> [RFC5576]. However, an offerer will not know which SSRC values the >> answerer will use until the offerer has received the answer providing >> >> >> >> Name Expires July 31, 2017 [Page 2] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> that information. Due to this, before the offerer has received the >> answer, the offerer will not be able to associate an RTP stream with >> the correct "m=" line using the SSRC value associated with the RTP >> stream. In addition, the offerer and answerer may start using new >> SSRC values mid-session, without informing each other using the SDP >> 'ssrc' attribute. >> >> In order for an offerer and answerer to always be able to associate >> an RTP stream with the correct "m=" line, the offerer and answerer >> using the BUNDLE extension MUST support the mechanism defined in >> Section 14, where the offerer and answerer includes the >> identification-tag (provided by the remote peer) associated with an >> "m=" line in the RTP Streams and in RTCP SDES packets part of a >> BUNDLE group. >> >> The mapping from an SSRC to an identification-tag is carried in RTCP >> SDES packets or in RTP header extensions (Section 14). Since a >> compound RTCP packet can contain multiple RTCP SDES packets, and each >> RTCP SDES packet can contain multiple chunks, an RTCP packet can >> contain several SSRC to identification-tag mappings. The offerer and >> answerer maintain tables mapping RTP streams identified by SSRC to >> "m=" lines identified by the identification-tag. These tables are >> updated each time new information that affects how packets should be >> processed and routed are received. >> >> To prepare for demultiplexing RTP streams to the correct "m=" line, >> the following steps MUST be followed for each BUNDLE group based on >> the SDP signalling information. >> >> Construct a table mapping MID to "m=" line for each "m=" line in >> this BUNDLE group. Note that an "m=" line may only have one MID. >> >> Construct a table mapping incoming RTP streams (SSRCs) to their >> "m=" line for each "m=" line in this BUNDLE group and for each RTP >> stream explicitly signalled for receiving in that "m=" line. >> >> Construct a table mapping payload types to "m=" line for each "m=" >> line in the BUNDLE group and for each payload type configured for >> receiving in that "m=" line. If any payload type is configured >> for receiving in more than one "m=" line in the BUNDLE group, do >> not it include it in the table. >> >> Note that for each of these tables, there can only be one mapping for >> any given key (MID, SSRC, or PT). In other words, the tables are not >> multimaps. >> >> As "m=" lines are added or removed from the BUNDLE groups, or their >> configurations are changed, the tables above MUST also be updated. >> >> >> >> Name Expires July 31, 2017 [Page 3] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> Received RTP packets that are syntactically correct are processed by >> the RTP/RTCP protocol implementation for statistics etc. After this >> processing they need to be routed to the higher layer context >> associated with the "m=" line within the BUNDLE group. Somewhere in >> the process where an received RTP packet is processed to be delivered >> to the higher layer by RTP the matching step below MUST be performed: >> >> 1. Reception of an RTP packet for an RTP stream that has an existing >> mapping in the RTP stream to m= line table. Before proceeding in >> delivering the packet to the higher layer context according to >> the RTP stream to "m=" line mapping table the following checks >> MUST be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is not in the table mapping MID to "m=" line, then >> do not deliver the RTP packet to higher layers. >> >> B. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, and the >> value indicates a different "m=" line than the current RTP >> stream to "m=" line mapping table, then update the RTP stream >> to "m=" line mapping. >> >> 2. Reception of an RTP packet for an RTP stream that has no existing >> mapping to an m= line. In this case the following actions MUST >> be performed: >> >> A. If the packet carries an RTP header extension with a SDES MID >> value that is in the table mapping MID to "m=" line, then >> create an entry in the RTP stream to "m=" line mapping table >> for this RTP stream (SSRC). Then deliver the RTP packet to >> the "m=" line context of the created mapping and stop. >> >> B. If the packet carries a Payload Type that is in the payload >> type table, then create an entry in the RTP stream to "m=" >> line mapping table for this RTP stream (SSRC). Then deliver >> the RTP packet to the "m=" line context of the created >> mapping and stop. >> >> C. Otherwise do not deliver the RTP packet to higher layers. >> Note, this includes unknown MID values. >> >> For each RTCP packet received (including each RTCP packet that is >> part of a compound RTCP packet), the RTCP packet needs to be >> processed by the RTP/RTCP implementation and relevant information and >> data from the RTCP packets needs to be routed to the appropriate >> handler for the related RTP streams. The appropriate handler is >> determined by using the RTP stream to "m=" line mapping table. >> >> >> >> Name Expires July 31, 2017 [Page 4] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> On reception of any compound RTCP packet prior to dispatching the >> received information and data, if there is an RTCP SDES packet >> included that SHOULD be processed first. If that SDES packet >> contains SDES MID entries, this can results in updates and additions >> to the RTP stream to "m=" line mapping table. Thus each of the SDES >> MID items are processed and the current table entries are checked if >> the corresponding MID value matches the current RTP stream to "m=" >> line mapping, else the entry is updated. If there is no RTP stream >> to "m=" line table mapping entry for the received SDES item's SSRC, >> such an entry is created. Note, that in the process of updating the >> table entries, update flap suppression as discussed in Section 4.2.6 >> of [RFC7941] should be considered. >> >> The various different RTCP packets as well as their various sub >> parts, such as the various RTCP Feedback message types, relates to >> the RTP streams in a couple of different ways. The currently known >> patterns are the following: >> >> Reports on outgoing RTP streams: For all RTP streams that this >> endpoint is the source of, it can expect to receive report blocks >> of several types identified as relating to an outgoing stream. >> The basic pattern for these blocks are that the RTCP packet header >> identifies the source of the reports, as identified by an SSRC, >> and containing one or more report blocks, where each report block >> identifies the RTP stream, using the SSRC, the report relates to. >> For this pattern the relevant report information is provided to >> the higher layer associated with the "m=" line the RTP Stream to >> "m=" line table identifies. The source SSRC as identifier of the >> endpoint that the report originates are relevant for interpreting >> the information, but not necessarily for routing. Example of this >> is pattern are: >> >> Sender Report (SR) and Receiver Report (RR) The basic receiver >> report blocks from RFC3550 start with the SSRC of the RTP >> stream they report on. >> >> Extended Reports (XR): RFC3611 is a framework that enables a >> large number of different reports. However, a large number of >> these report formats are reporting on specific RTP streams and >> thus each individual report of these types contains a SSRC >> field to identify the RTP stream. >> >> RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP >> feedback messages allow for a number of different type of feedback >> messages. However, the RTCP feedback message header contains the >> SSRC identifying the source of the feedback messages as well as >> the actual type of the feedback. Some of the feedback messages >> also uses the target SSRC field in the header to identify which >> >> >> >> Name Expires July 31, 2017 [Page 5] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> RTP stream the feedback is related to. For these types all the >> FCI entries, if multiple ones are forwarded to the identified >> handler. Examples of this pattern are: >> >> Picture Loss Indication (PLI): RFC 4585 (PT=PSFB, FMT=1). >> >> Slice Loss Indication (SLI): RFC 4585 (PT=PSFB, FMT=2). >> >> Reference Picture Selection Indication (RPSI): RFC 4585 (PT=PSFB, >> FMT=3). >> >> Generic NACK: [RFC4585] (PT=RTPFB and FMT=1). >> >> Other feedback messages includes the target SSRC in the Feedback >> Control Information (FCI). Here each FCI needs to be processed >> and the SSRC field identified. And the individual FCI combined >> with the RTCP packet header context needs to be forwarded to the >> identified handler. Example of this pattern are: >> >> Full Intra Request (FIR): [RFC5104] (PT=PSFB, FMT=4). >> >> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=PSFB, >> FMT=5). >> >> Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] >> defined message (PT=PSFB, FMT=5) is actually a notifciation in >> response to a TSTR this endpoint sent using the SSRC the FCI >> identifies as source. >> >> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=PSFB, >> FMT=7). >> >> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=PSFB, >> FMT=TBD). >> >> Descriptive or Notifications for an incoming RTP stream: There exist >> some RTCP packet types that provides additional information or >> notifies about events related to the RTP stream identified. In >> these cases the RTP stream is identified using the SSRC field >> value, and the information is provided to the higher layer >> associated with the "m=" line for the incoming RTP stream as >> identified by the current RTP stream to "m=" line table. For this >> type of pattern it is common that the RTCP packets and information >> is repeated, either periodically (e.g. SDES items), or for a >> duration (e.g. BYE), thus suppression of repetitions can be >> considered. Examples of these are: >> >> >> >> >> >> Name Expires July 31, 2017 [Page 6] >> >> Internet-Draft Abbreviated-Title January 2017 >> >> >> Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol >> [RFC3550] defines SDES RTCP packets as a way of providing per >> source (SSRC) specific information about the source. An SDES >> packet contains zero or more chunks, where a chunk contains the >> SSRC for the source being described by the one or more items >> included in the chunk. Forward the SDES items in each chunk to >> the RTP stream's handler. >> >> Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] >> mechanism indicates that a particular RTP stream is leaving the >> RTP session. Thus, a most relevant event to inform the handler >> for this RTP steam of. >> >> Third Party Targeted Reports or Feedback: There exist some >> multiparty RTP Topologies that results in that an endpoint >> receives third party reports (SR [RFC3550], RR [RFC3550] or XR >> [RFC3611]) as well as Feedback Messages [RFC4585] that relates to >> or targets an SSRC that originates from another endpoint, and >> where the source of the RTCP packet is also another endpoint. >> This type of packets should be forwarded to the higher layer >> function dealing with the third party reporting. And if none >> exist then they can be suppressed. As the third party handler can >> be focused on determining the conditions for the source of the >> reports and feedback, or focused on how the RTP stream source >> progresses, or both recommendations can't be made. >> >> APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that >> enables experimentation. The APP packet only specifies the source >> of the packet. Thus this information can be related to any of the >> "m=" lines, thus deliver a copy of the packet to each "m=" line or >> an APP specific handler. >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 31 01:24:39 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 EB03D129409; Tue, 31 Jan 2017 01:24:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148585467495.2564.11310576282898981929.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 01:24:34 -0800 Archived-At: Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 09:24: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 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-07.txt Pages : 35 Date : 2017-01-31 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-07 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 Tue Jan 31 01:34: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 E47271293F0 for ; Tue, 31 Jan 2017 01:34:34 -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 v5sqfEm_uaA4 for ; Tue, 31 Jan 2017 01:34:32 -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 A1EAB126D74 for ; Tue, 31 Jan 2017 01:34:31 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-97-58905a254700 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id C7.80.32317.52A50985; Tue, 31 Jan 2017 10:34:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.319.2; Tue, 31 Jan 2017 10:34:20 +0100 To: "mmusic (E-mail)" References: <148585467495.2564.11310576282898981929.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <7cc5671f-4b6a-becd-16ee-b23d1296649d@ericsson.com> Date: Tue, 31 Jan 2017 10:34:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148585467495.2564.11310576282898981929.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM2K7lq5q1IQIg1MLFS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL8rDzIW3Oau6D3Zy9LAeJizi5GDQ0LAROJbp0AXIxeHkMA6 RommdftYIZzljBI3F/xgBikSFrCX+PJAt4uRk0NEQF2idXMfK4gtJOArcXntQhYQm03AQuLm j0Y2EJsXqPzn7W/sIDaLgKrEsYvzGUFsUYEYibfrl7ND1AhKnJz5BKyXU8BPYtHEOWCrmIF6 H2wtAwkzC8hLNG+dzQyxSluioamDdQIj/ywk3bMQOmYh6VjAyLyKUbQ4tbg4N93IWC+1KDO5 uDg/Ty8vtWQTIzDIDm75rbuDcfVrx0OMAhyMSjy8Br39EUKsiWXFlbmHGCU4mJVEePP9JkQI 8aYkVlalFuXHF5XmpBYfYpTmYFES5zVbeT9cSCA9sSQ1OzW1ILUIJsvEwSnVwCiox/PbqfnJ vNc/M+8uvnoy5MSFO5a2aZuWmbuJr//ync+f58c2Aenz959HKDGreVm7NrOcE7yVukBj+oP/ Gs46PiIejctyDjdu3r5/7vrn3+++tTC54fTzHvvPW2WWR+ccLszcsP7Ai4VbW6a+130jwGyv k1pbeHqbzdvvDPKzNnFcmygl8tVTiaU4I9FQi7moOBEAi2BMpi4CAAA= Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-07.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 09:34:35 -0000 Hi WG, This updated version of simulcast contains some few changes as can also be seen from the diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-07 The changes are: - A scope clarification, as result of the discussion with Roni Even. - A Reformulation of the Identification requirements for simulcast stream. - Correcting the statement related to source specific signalling [RFC5576] to address Roni Even's comment. - Update of the last paragraph in Section 6.2 regarding simulcast streams differences as well as forbidding multiple instances of the same SCID within a single a=simulcast line. - Removal of note in Section 6.4 as result of issue raised by Roni Even. - Use of "m=" has been changed to media description and a few other editorial improvements and clarifications. With this Bo and I think this addresses all the issues raised on the WG last call on -05 version. Those who had issues, please review that your issue is resolved. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Jan 31 08:08:49 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 077781299B6; Tue, 31 Jan 2017 08:08:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 08:08:45 -0800 Archived-At: Cc: fandreas@cisco.com, mmusic-chairs@ietf.org, draft-ietf-mmusic-4572-update@ietf.org, mmusic@ietf.org Subject: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:08:47 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-mmusic-4572-update-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I've two (or 4 depending how you count:-) things I'd like to check here. Should be pretty easy to handle. (1) section 5: I'm wondering if we have the right set of hash functions here. Deprecating md2 and md5 is great, but I have a bunch of questions about the others: (1.1) why not also say that sha-1 MUST NOT be used for new things (or similar)? (1.2) do you really need sha-224 and 384? I think nobody uses those at all. (1.3) I'm a bit surprised you didn't add sha3 (and maybe remove sha-512 if that's not needed) Even if you don't encourage use of sha3, it might be good to include it in the abnf now in case it gets popular. (2) Wouldn't it be a good plan to say that TLS as-used MUST conform to BCP195? If not, why not? From nobody Tue Jan 31 09:23: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 75287129515; Tue, 31 Jan 2017 09:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKHki5-PWq3b; Tue, 31 Jan 2017 09:23:18 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (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 6E0D412948C; Tue, 31 Jan 2017 09:23:18 -0800 (PST) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0VHJRwo020041; Tue, 31 Jan 2017 12:23:14 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 288px82863-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jan 2017 12:23:14 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Jan 2017 11:23:13 -0600 From: Jonathan Lennox To: Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) Thread-Index: AQHSe9xP0bZ4yIUYgkq4TrgGIWp7sqFTOkcA Date: Tue, 31 Jan 2017 17:23:12 +0000 Message-ID: <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> In-Reply-To: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <046C4A595B17894EB4126DE0A9377BFC@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310147 Archived-At: Cc: Flemming Andreasen , "mmusic-chairs@ietf.org" , "draft-ietf-mmusic-4572-update@ietf.org" , The The IESG , mmusic Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 17:23:19 -0000 DQo+IE9uIEphbiAzMSwgMjAxNywgYXQgMTE6MDggQU0sIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhl bi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IERJU0NV U1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IA0KPiBJJ3ZlIHR3byAob3IgNCBkZXBlbmRpbmcg aG93IHlvdSBjb3VudDotKSB0aGluZ3MNCj4gSSdkIGxpa2UgdG8gY2hlY2sgaGVyZS4gU2hvdWxk IGJlIHByZXR0eSBlYXN5IHRvDQo+IGhhbmRsZS4NCj4gDQo+ICgxKSBzZWN0aW9uIDU6IEknbSB3 b25kZXJpbmcgaWYgd2UgaGF2ZSB0aGUgcmlnaHQNCj4gc2V0IG9mIGhhc2ggZnVuY3Rpb25zIGhl cmUuIERlcHJlY2F0aW5nIG1kMiBhbmQgbWQ1DQo+IGlzIGdyZWF0LCBidXQgSSBoYXZlIGEgYnVu Y2ggb2YgcXVlc3Rpb25zIGFib3V0IHRoZQ0KPiBvdGhlcnM6DQo+IA0KPiAoMS4xKSB3aHkgbm90 IGFsc28gc2F5IHRoYXQgc2hhLTEgTVVTVCBOT1QgYmUgdXNlZA0KPiBmb3IgbmV3IHRoaW5ncyAo b3Igc2ltaWxhcik/DQoNCldlIHNheSAoc2VjdGlvbiA1LjEpIHRoYXQgU0hBLTI1NiBNVVNUIGJl IHVzZWQgZm9yIG9uZSBvZiB0aGUgZmluZ2VycHJpbnRzOyBpbXBsZW1lbnRhdGlvbnMgTUFZIHNl bmQgYWRkaXRpb25hbCBmaW5nZXJwcmludHMgYXMgd2VsbC4NCg0KVGhlcmXigJlzIGNvbmNlcm4g dGhhdCB0aGVyZSBtYXkgYmUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIG5lZWRpbmcgU0hBLTEg KHNpbmNlIDQ1NzIgbWFkZSB0aGF0IHRoZSBNVEkgYWxnb3JpdGhtKS4gIFRoZSBuZWVkIGZvciBp bnRlcm9wIG1ha2VzIGRlZmluaW5nIOKAnG5ldyB0aGluZ3PigJ0gcmF0aGVyIGNvbXBsaWNhdGVk Lg0KDQpJcyB0aGF0IHN1ZmZpY2llbnQ/DQoNCg0KPiAoMS4yKSBkbyB5b3UgcmVhbGx5IG5lZWQg c2hhLTIyNCBhbmQgMzg0PyBJIHRoaW5rDQo+IG5vYm9keSB1c2VzIHRob3NlIGF0IGFsbC4NCj4g DQo+ICgxLjMpIEknbSBhIGJpdCBzdXJwcmlzZWQgeW91IGRpZG4ndCBhZGQgc2hhMyAoYW5kDQo+ IG1heWJlIHJlbW92ZSBzaGEtNTEyIGlmIHRoYXQncyBub3QgbmVlZGVkKSBFdmVuIGlmDQo+IHlv dSBkb24ndCBlbmNvdXJhZ2UgdXNlIG9mIHNoYTMsIGl0IG1pZ2h0IGJlIGdvb2QNCj4gdG8gaW5j bHVkZSBpdCBpbiB0aGUgYWJuZiBub3cgaW4gY2FzZSBpdCBnZXRzDQo+IHBvcHVsYXIuDQoNClRo ZSBwb2xpY3kgaXMgdGhhdCB0aGUgc2V0IG9mIGhhc2ggZnVuY3Rpb25zIHN1cHBvcnRlZCBjb3Jy ZXNwb25kcyB0byB0aGUgaGFzaCBmdW5jdGlvbnMgZGVmaW5lZCBmb3IgWC41MDkgY2VydGlmaWNh dGVzLiBVbmxlc3MgSeKAmW0gbWlzc2luZyBzb21ldGhpbmcsIHRoZXJl4oCZcyBubyBkZWZpbml0 aW9uIG9mIFNIQS0zIGZvciBYLjUwOSB5ZXQsIGlzIHRoZXJlPyAgKElmIEnigJl2ZSBvdmVybG9v a2VkIHNvbWV0aGluZywgcGxlYXNlIGxldCBtZSBrbm93LikgDQoNClRoZSBsaXN0IGlzIGFuIElB TkEgcmVnaXN0cnksIHNvIG9uY2UgU0hBLTMgaXMgZGVmaW5lZCBmb3IgWC41MDksIGl0IGNhbiBh bHNvIGJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeSB3aXRob3V0IG5lZWRpbmcgYW4gdXBkYXRlIHRv IHRoaXMgZG9jdW1lbnQuDQoNCkZvciB0aGUgc2FtZSByZWFzb24sIHRoaXMgaXMgd2h5IHdlIGlu Y2x1ZGVkIFNIQS0yMjQgYW5kIFNIQS0zODQuICBJZiBubyBvbmXigJlzIHVzaW5nIHRoZW0sIEni gJlkIHRoaW5rIGFuIHVwZGF0ZSB0byBSRkMgNDA1NSB3b3VsZCBiZSBpbiBvcmRlcj8NCg0KDQo+ ICgyKSBXb3VsZG4ndCBpdCBiZSBhIGdvb2QgcGxhbiB0byBzYXkgdGhhdCBUTFMNCj4gYXMtdXNl ZCBNVVNUIGNvbmZvcm0gdG8gQkNQMTk1PyBJZiBub3QsIHdoeSBub3Q/DQoNCk15IGluY2xpbmF0 aW9uIHdvdWxkIGJlIHRvIHNheSB5ZXMsIGJ1dCBJ4oCZbGwgbGV0IHBlb3BsZSB3aXRoIG1vcmUg b2YgdGhlIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBjb21tZW50IGZ1cnRoZXIgaW4gY2FzZSB0 aGVyZeKAmXMgc29tZSBpc3N1ZS4NCg0KDQoNCg== From nobody Tue Jan 31 09:43: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 339F412955B; Tue, 31 Jan 2017 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTXeXrp945tB; Tue, 31 Jan 2017 09:43:29 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 2EF6A129557; Tue, 31 Jan 2017 09:43:29 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0VHYpOi006529; Tue, 31 Jan 2017 12:43:26 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9q9vu7-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jan 2017 12:43:26 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Jan 2017 11:43:25 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTP9MA Date: Tue, 31 Jan 2017 17:43:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310149 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 17:43:31 -0000 In general, this looks good. I have one question, however. What should happen if an RTP packet (without= a MID) is received for a stream that has an existing mapping to an m=3D li= ne, but whose PT is not valid for that m=3D line? Should it 1. Cause the stream=92s mapping to be moved to another m=3D line, if the re= ceived PT is in the payload type table for some other m=3D line? or=20 2. Be an error? In other words, should it be possible for PT-mapping to cause streams to ch= ange their mappings? (Should this decision depend on what caused the stream to be mapped to its = current m=3D line?) > On Jan 27, 2017, at 11:43 AM, Magnus Westerlund wrote: >=20 > MMUSIC and RTCWEB, >=20 > Here is now a more complete text proposal that also considers the RTCP. I= t also goes further than what Appendix B defines in one aspect, namely expl= icitly considering third party RTCP reporting and what to do with it. >=20 > Feedback is much appreciated. I plan to put this into a PR towards JSEP A= PPENDIX B on monday. If only to get the JSEP authors attention ;-). However= , the text is really intended for the next version of BUNDLE. >=20 >=20 > X. Associating RTP/RTCP With Correct SDP Media Description >=20 > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. >=20 > In order to be able to process received RTP/RTCP packets correctly it > must be possible to associate an RTP stream with the correct "m=3D" > line, as the "m=3D" line and SDP attributes associated with the "m=3D" > line contain information needed to process the packets. >=20 > As all RTP streams associated with a BUNDLE group are part of the > same RTP session and using the same address:port combination for > sending and receiving RTP/RTCP packets, the local address:port > combination cannot be used to associate an RTP stream with the > correct "m=3D" line. In addition, multiple RTP streams might be > associated with the same "m=3D" line. >=20 > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=3D" > line. However, there are cases where each "m=3D" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=3D" line the RTP stream is associated > with. >=20 > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 2] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > that information. Due to this, before the offerer has received the > answer, the offerer will not be able to associate an RTP stream with > the correct "m=3D" line using the SSRC value associated with the RTP > stream. In addition, the offerer and answerer may start using new > SSRC values mid-session, without informing each other using the SDP > 'ssrc' attribute. >=20 > In order for an offerer and answerer to always be able to associate > an RTP stream with the correct "m=3D" line, the offerer and answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=3D" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. >=20 > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=3D" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. >=20 > To prepare for demultiplexing RTP streams to the correct "m=3D" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. >=20 > Construct a table mapping MID to "m=3D" line for each "m=3D" line in > this BUNDLE group. Note that an "m=3D" line may only have one MID. >=20 > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=3D" line for each "m=3D" line in this BUNDLE group and for each R= TP > stream explicitly signalled for receiving in that "m=3D" line. >=20 > Construct a table mapping payload types to "m=3D" line for each "m= =3D" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=3D" line. If any payload type is configured > for receiving in more than one "m=3D" line in the BUNDLE group, do > not it include it in the table. >=20 > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. >=20 > As "m=3D" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 3] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=3D" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: >=20 > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m=3D line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=3D" line mapping table the following checks > MUST be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=3D" line, then > do not deliver the RTP packet to higher layers. >=20 > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, and the > value indicates a different "m=3D" line than the current RTP > stream to "m=3D" line mapping table, then update the RTP stream > to "m=3D" line mapping. >=20 > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m=3D line. In this case the following actions MUST > be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, then > create an entry in the RTP stream to "m=3D" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=3D" line context of the created mapping and stop. >=20 > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=3D" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=3D" line context of the created > mapping and stop. >=20 > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. >=20 > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=3D" line mapping table. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 4] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=3D" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=3D" > line mapping, else the entry is updated. If there is no RTP stream > to "m=3D" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. >=20 > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: >=20 > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=3D" line the RTP Stream to > "m=3D" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: >=20 > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. >=20 > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. >=20 > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 5] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: >=20 > Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >=20 > Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >=20 > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, > FMT=3D3). >=20 > Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >=20 > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: >=20 > Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >=20 > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, > FMT=3D5). >=20 > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation i= n > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. >=20 > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, > FMT=3D7). >=20 > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, > FMT=3DTBD). >=20 > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=3D" line for the incoming RTP stream as > identified by the current RTP stream to "m=3D" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: >=20 >=20 >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 6] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. >=20 > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. >=20 > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. >=20 > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=3D" lines, thus deliver a copy of the packet to each "m=3D" line = or > an APP specific handler. >=20 > --=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Tue Jan 31 09:57: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 E8BD8129524; Tue, 31 Jan 2017 09:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.998 X-Spam-Level: X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B6mGbD-Qu6B; Tue, 31 Jan 2017 09:57:30 -0800 (PST) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 491211294A5; Tue, 31 Jan 2017 09:57:30 -0800 (PST) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0VHroDp021261; Tue, 31 Jan 2017 12:57:27 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 288n9q9xad-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 31 Jan 2017 12:57:27 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 31 Jan 2017 11:57:25 -0600 From: Jonathan Lennox To: Magnus Westerlund Thread-Topic: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description Thread-Index: AQHSe+hqNyVXjtU64EysMGTN3ByD2aFTQ7wA Date: Tue, 31 Jan 2017 17:57:25 +0000 Message-ID: References: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> In-Reply-To: <1f020dc6-1ac8-b71b-aee4-a711d15f1588@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-31_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701310151 Archived-At: Cc: "draft-ietf-rtcweb-jsep@tools.ietf.org" , "rtcweb@ietf.org" , mmusic , "draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org" Subject: Re: [MMUSIC] Text proposal for Bundle regarding Associating RTP/RTCP With Correct SDP Media Description X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 17:57:32 -0000 And one more question. This one has significant interop issues, I think. Should decoding contexts be assumed to be associated with streams independe= nt of m=3D lines, or with streams within m=3D lines? Specifically, if a sender moves a video stream from one m=3D line to anothe= r (maintaining its PT), must it send a fresh I-frame (keyframe) at the time= of the move, or can it continue sending inter frames? > On Jan 27, 2017, at 11:43 AM, Magnus Westerlund wrote: >=20 > MMUSIC and RTCWEB, >=20 > Here is now a more complete text proposal that also considers the RTCP. I= t also goes further than what Appendix B defines in one aspect, namely expl= icitly considering third party RTCP reporting and what to do with it. >=20 > Feedback is much appreciated. I plan to put this into a PR towards JSEP A= PPENDIX B on monday. If only to get the JSEP authors attention ;-). However= , the text is really intended for the next version of BUNDLE. >=20 >=20 > X. Associating RTP/RTCP With Correct SDP Media Description >=20 > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet carries an SSRC value that is used to associate > the packet with the correct RTP stream. RTCP packets also uses SSRCs > to identify on which RTP streams any report or feedback relate to. > Thus, an RTCP packet will commonly carry multiple SSRC values, and > might therefore be providing feedback or report on multiple RTP > streams. >=20 > In order to be able to process received RTP/RTCP packets correctly it > must be possible to associate an RTP stream with the correct "m=3D" > line, as the "m=3D" line and SDP attributes associated with the "m=3D" > line contain information needed to process the packets. >=20 > As all RTP streams associated with a BUNDLE group are part of the > same RTP session and using the same address:port combination for > sending and receiving RTP/RTCP packets, the local address:port > combination cannot be used to associate an RTP stream with the > correct "m=3D" line. In addition, multiple RTP streams might be > associated with the same "m=3D" line. >=20 > Also, as described in Section 10.1.1, the same payload type value > might be used by multiple RTP streams, in which case the payload type > value cannot be used to associate an RTP stream with the correct "m=3D" > line. However, there are cases where each "m=3D" line has unique > payload type values, and then the payload type could serve as > indicator to the relevant "m=3D" line the RTP stream is associated > with. >=20 > An offerer and answerer can inform each other which SSRC values they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer providing >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 2] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > that information. Due to this, before the offerer has received the > answer, the offerer will not be able to associate an RTP stream with > the correct "m=3D" line using the SSRC value associated with the RTP > stream. In addition, the offerer and answerer may start using new > SSRC values mid-session, without informing each other using the SDP > 'ssrc' attribute. >=20 > In order for an offerer and answerer to always be able to associate > an RTP stream with the correct "m=3D" line, the offerer and answerer > using the BUNDLE extension MUST support the mechanism defined in > Section 14, where the offerer and answerer includes the > identification-tag (provided by the remote peer) associated with an > "m=3D" line in the RTP Streams and in RTCP SDES packets part of a > BUNDLE group. >=20 > The mapping from an SSRC to an identification-tag is carried in RTCP > SDES packets or in RTP header extensions (Section 14). Since a > compound RTCP packet can contain multiple RTCP SDES packets, and each > RTCP SDES packet can contain multiple chunks, an RTCP packet can > contain several SSRC to identification-tag mappings. The offerer and > answerer maintain tables mapping RTP streams identified by SSRC to > "m=3D" lines identified by the identification-tag. These tables are > updated each time new information that affects how packets should be > processed and routed are received. >=20 > To prepare for demultiplexing RTP streams to the correct "m=3D" line, > the following steps MUST be followed for each BUNDLE group based on > the SDP signalling information. >=20 > Construct a table mapping MID to "m=3D" line for each "m=3D" line in > this BUNDLE group. Note that an "m=3D" line may only have one MID. >=20 > Construct a table mapping incoming RTP streams (SSRCs) to their > "m=3D" line for each "m=3D" line in this BUNDLE group and for each R= TP > stream explicitly signalled for receiving in that "m=3D" line. >=20 > Construct a table mapping payload types to "m=3D" line for each "m= =3D" > line in the BUNDLE group and for each payload type configured for > receiving in that "m=3D" line. If any payload type is configured > for receiving in more than one "m=3D" line in the BUNDLE group, do > not it include it in the table. >=20 > Note that for each of these tables, there can only be one mapping for > any given key (MID, SSRC, or PT). In other words, the tables are not > multimaps. >=20 > As "m=3D" lines are added or removed from the BUNDLE groups, or their > configurations are changed, the tables above MUST also be updated. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 3] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Received RTP packets that are syntactically correct are processed by > the RTP/RTCP protocol implementation for statistics etc. After this > processing they need to be routed to the higher layer context > associated with the "m=3D" line within the BUNDLE group. Somewhere in > the process where an received RTP packet is processed to be delivered > to the higher layer by RTP the matching step below MUST be performed: >=20 > 1. Reception of an RTP packet for an RTP stream that has an existing > mapping in the RTP stream to m=3D line table. Before proceeding in > delivering the packet to the higher layer context according to > the RTP stream to "m=3D" line mapping table the following checks > MUST be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is not in the table mapping MID to "m=3D" line, then > do not deliver the RTP packet to higher layers. >=20 > B. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, and the > value indicates a different "m=3D" line than the current RTP > stream to "m=3D" line mapping table, then update the RTP stream > to "m=3D" line mapping. >=20 > 2. Reception of an RTP packet for an RTP stream that has no existing > mapping to an m=3D line. In this case the following actions MUST > be performed: >=20 > A. If the packet carries an RTP header extension with a SDES MID > value that is in the table mapping MID to "m=3D" line, then > create an entry in the RTP stream to "m=3D" line mapping table > for this RTP stream (SSRC). Then deliver the RTP packet to > the "m=3D" line context of the created mapping and stop. >=20 > B. If the packet carries a Payload Type that is in the payload > type table, then create an entry in the RTP stream to "m=3D" > line mapping table for this RTP stream (SSRC). Then deliver > the RTP packet to the "m=3D" line context of the created > mapping and stop. >=20 > C. Otherwise do not deliver the RTP packet to higher layers. > Note, this includes unknown MID values. >=20 > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the RTCP packet needs to be > processed by the RTP/RTCP implementation and relevant information and > data from the RTCP packets needs to be routed to the appropriate > handler for the related RTP streams. The appropriate handler is > determined by using the RTP stream to "m=3D" line mapping table. >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 4] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > On reception of any compound RTCP packet prior to dispatching the > received information and data, if there is an RTCP SDES packet > included that SHOULD be processed first. If that SDES packet > contains SDES MID entries, this can results in updates and additions > to the RTP stream to "m=3D" line mapping table. Thus each of the SDES > MID items are processed and the current table entries are checked if > the corresponding MID value matches the current RTP stream to "m=3D" > line mapping, else the entry is updated. If there is no RTP stream > to "m=3D" line table mapping entry for the received SDES item's SSRC, > such an entry is created. Note, that in the process of updating the > table entries, update flap suppression as discussed in Section 4.2.6 > of [RFC7941] should be considered. >=20 > The various different RTCP packets as well as their various sub > parts, such as the various RTCP Feedback message types, relates to > the RTP streams in a couple of different ways. The currently known > patterns are the following: >=20 > Reports on outgoing RTP streams: For all RTP streams that this > endpoint is the source of, it can expect to receive report blocks > of several types identified as relating to an outgoing stream. > The basic pattern for these blocks are that the RTCP packet header > identifies the source of the reports, as identified by an SSRC, > and containing one or more report blocks, where each report block > identifies the RTP stream, using the SSRC, the report relates to. > For this pattern the relevant report information is provided to > the higher layer associated with the "m=3D" line the RTP Stream to > "m=3D" line table identifies. The source SSRC as identifier of the > endpoint that the report originates are relevant for interpreting > the information, but not necessarily for routing. Example of this > is pattern are: >=20 > Sender Report (SR) and Receiver Report (RR) The basic receiver > report blocks from RFC3550 start with the SSRC of the RTP > stream they report on. >=20 > Extended Reports (XR): RFC3611 is a framework that enables a > large number of different reports. However, a large number of > these report formats are reporting on specific RTP streams and > thus each individual report of these types contains a SSRC > field to identify the RTP stream. >=20 > RTCP Feedback Messages for outgoing RTP streams: The RFC 4585 RTCP > feedback messages allow for a number of different type of feedback > messages. However, the RTCP feedback message header contains the > SSRC identifying the source of the feedback messages as well as > the actual type of the feedback. Some of the feedback messages > also uses the target SSRC field in the header to identify which >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 5] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > RTP stream the feedback is related to. For these types all the > FCI entries, if multiple ones are forwarded to the identified > handler. Examples of this pattern are: >=20 > Picture Loss Indication (PLI): RFC 4585 (PT=3DPSFB, FMT=3D1). >=20 > Slice Loss Indication (SLI): RFC 4585 (PT=3DPSFB, FMT=3D2). >=20 > Reference Picture Selection Indication (RPSI): RFC 4585 (PT=3DPSFB, > FMT=3D3). >=20 > Generic NACK: [RFC4585] (PT=3DRTPFB and FMT=3D1). >=20 > Other feedback messages includes the target SSRC in the Feedback > Control Information (FCI). Here each FCI needs to be processed > and the SSRC field identified. And the individual FCI combined > with the RTCP packet header context needs to be forwarded to the > identified handler. Example of this pattern are: >=20 > Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >=20 > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, > FMT=3D5). >=20 > Temporal-Spatial Trade-off Notification (TSTN): This [RFC5104] > defined message (PT=3DPSFB, FMT=3D5) is actually a notifciation i= n > response to a TSTR this endpoint sent using the SSRC the FCI > identifies as source. >=20 > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, > FMT=3D7). >=20 > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, > FMT=3DTBD). >=20 > Descriptive or Notifications for an incoming RTP stream: There exist > some RTCP packet types that provides additional information or > notifies about events related to the RTP stream identified. In > these cases the RTP stream is identified using the SSRC field > value, and the information is provided to the higher layer > associated with the "m=3D" line for the incoming RTP stream as > identified by the current RTP stream to "m=3D" line table. For this > type of pattern it is common that the RTCP packets and information > is repeated, either periodically (e.g. SDES items), or for a > duration (e.g. BYE), thus suppression of repetitions can be > considered. Examples of these are: >=20 >=20 >=20 >=20 >=20 > Name Expires July 31, 2017 [Page 6] >=20 > Internet-Draft Abbreviated-Title January 2017 >=20 >=20 > Source Description (SDES) RTCP Packet: The base RTP/RTCP protocol > [RFC3550] defines SDES RTCP packets as a way of providing per > source (SSRC) specific information about the source. An SDES > packet contains zero or more chunks, where a chunk contains the > SSRC for the source being described by the one or more items > included in the chunk. Forward the SDES items in each chunk to > the RTP stream's handler. >=20 > Goodbye (BYE) RTCP Packet: This RTP/RTCP protocol [RFC3550] > mechanism indicates that a particular RTP stream is leaving the > RTP session. Thus, a most relevant event to inform the handler > for this RTP steam of. >=20 > Third Party Targeted Reports or Feedback: There exist some > multiparty RTP Topologies that results in that an endpoint > receives third party reports (SR [RFC3550], RR [RFC3550] or XR > [RFC3611]) as well as Feedback Messages [RFC4585] that relates to > or targets an SSRC that originates from another endpoint, and > where the source of the RTCP packet is also another endpoint. > This type of packets should be forwarded to the higher layer > function dealing with the third party reporting. And if none > exist then they can be suppressed. As the third party handler can > be focused on determining the conditions for the source of the > reports and feedback, or focused on how the RTP stream source > progresses, or both recommendations can't be made. >=20 > APP Packets: The RTCP APP Packets [RFC3550] are a mechanism that > enables experimentation. The APP packet only specifies the source > of the packet. Thus this information can be related to any of the > "m=3D" lines, thus deliver a copy of the packet to each "m=3D" line = or > an APP specific handler. >=20 > --=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 From nobody Tue Jan 31 14:59: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 C477F129642; Tue, 31 Jan 2017 14:59:05 -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 MnlriDRiXHm7; Tue, 31 Jan 2017 14:59:04 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 94289129BDD; Tue, 31 Jan 2017 14:59:04 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so249425936qtg.3; Tue, 31 Jan 2017 14:59:04 -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:content-transfer-encoding; bh=3NRiSmrQTamzeiuUiSCguZUwzI8opB5aBkWz0FSVIfc=; b=aXFZ7/aFzCuQqqRhedajOQViDSNoKHplQo/QZ61LolUJNxvMb72WqtjP+wQCVkDcHo HbRN3IwWCf3uOcFG37VMia54D6PMYDXQpKxOatVzKrbFAvq/SKDbdJkK/saJMK1nbz95 cMopgnoaPP/Qf9G516FYJfR/wQAwrCgVOCXQm4CKRQPi8VRtuLfg4gVm/motbbehluia 4vJ31y5mpr4rp2zjO1jPtrowYTDLdBEyurxL23BS1q62ETuyklusdl0Kt0HYw5nLeuwh N+5f4rCguBVWV2NvE3QMdiADrqw49s2cC7TRWX1Bh0dutBy7sA/IszIDK1/SZLU+8uo0 0nwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3NRiSmrQTamzeiuUiSCguZUwzI8opB5aBkWz0FSVIfc=; b=KsRnJBpE54Y4SnPOF8xsjACepcWICzrlpkLACO18Lp4P8Q+PXAMgs6YKYHe+AIZ0rE Z0vzL5OmDei8Xxly3Jpl7oRBa3yAgkgoF1N/1TKzoBiRtkg4UdxflW4YSZ1WVxUKOdV5 zW6EBpzR6qR8yCCUT68EEBDOX+gJ4DkYaGuXqKxpBNhAzRCVrZfphSDcucGdR+I/glUl 9JyYrt76s6tU53j7PwEhSozXHojB2BVC8FGIs+cHD7ytv6hAHnetG/i5Z8e8KcXtvfi+ l1mJhNF1y9kxhG4vbj4n6Q3eLPd2Upu4G5/iTfEZAwKLG6VmHTnUizcS85SDpK/a18Bz 0gsA== X-Gm-Message-State: AIkVDXKlQ6ESW7E2/q8QFLh0mYFGwuVl1kgQ85lcZu3qhIQcIHu7Y07BBvkKy3tnK98FrULLoHC4ub9XXNK40g== X-Received: by 10.200.55.112 with SMTP id p45mr29879758qtb.278.1485903543743; Tue, 31 Jan 2017 14:59:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 31 Jan 2017 14:59:03 -0800 (PST) In-Reply-To: <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> <3DCBB043-EF35-425A-A005-93488A726369@vidyo.com> From: Martin Thomson Date: Wed, 1 Feb 2017 09:59:03 +1100 Message-ID: To: Jonathan Lennox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "mmusic-chairs@ietf.org" , mmusic , Flemming Andreasen , The The IESG , "draft-ietf-mmusic-4572-update@ietf.org" , Stephen Farrell Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 22:59:06 -0000 On 1 February 2017 at 04:23, Jonathan Lennox wrote: >> (2) Wouldn't it be a good plan to say that TLS >> as-used MUST conform to BCP195? If not, why not? > > My inclination would be to say yes, but I=E2=80=99ll let people with more= of the existing implementations comment further in case there=E2=80=99s so= me issue. If we said MUST, I suspect that we'd end up making a whole lot of implementations non-compliant. There's a lot of DTLS 1.0 out there. That said, the same applies to SHA-1. I guess it depends on your stance regarding what is as opposed to what should be. FWIW, we didn't ask this sort of question because the intent was to clarify hash usage only, avoiding touching the rest of the document. From nobody Tue Jan 31 23:19:26 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 50F03129434 for ; Tue, 31 Jan 2017 23:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 5XocLVUWWRSE for ; Tue, 31 Jan 2017 23:19:23 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002: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 E8545129422 for ; Tue, 31 Jan 2017 23:19:22 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id v200so56272798ywc.3 for ; Tue, 31 Jan 2017 23:19:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HTQ7Z+IkqD/xnoR2QQEdQCqwI96g8LDH0FOd1SlLA+Y=; b=x0pwFDyD7ylykeSyoAi7b5VGk/WFJI06o/7iBEdmNyqVuf3oonnra1Px+E893efkOb m/h+qC6gYiSQu2BlYmh5ZagrQBszuHGWjEI8Z5ssf3RS/qzi8ohH3y6otgDTzIgwOUII 65oCdK8GzQsFYyN4bJnDHvDA/dxRRslRns65KxaRHlaTZBAKvd1gb3PPx5GVxlGLlwuF mvgXzan9A8C7E1Gq6HN9+Enx27wMKg/wFqD0FIDR34d222FOuKjQcTKVvK0D3kkDtIz1 Va+wOETOywt0NkHyWbsdyfxbDu/XPJoxdYZpLsB8GdN5Jauy591GDC/bodxL0b+KM5X8 SIww== 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=HTQ7Z+IkqD/xnoR2QQEdQCqwI96g8LDH0FOd1SlLA+Y=; b=kntTxyj6ZJnNui0Q9DVEtjnKGf/93e8/EA9HW8bcUY9XJIWZSMPhr7Z+2sQd/BZuaT MZw1sxuQUu+4AKY0PObkNmi9nsFnfGynmBj4nYlIdOOQoyM3d6NnPkKgN5Ms24mZOFjn yBMf4fVSG9njBcJLM/Kpqi26W0Czjvqk5FZHGXDn0OmMLWyu5d/x0Ip7Fl6c6QMwZFQM szs72SgNtvUisJSewwWbdM4W+PcPMHarvLd37omFuckJN+hR5aLImKT1OT+zwjJ7BPqN SCKhynyIqzMZf5PS4poH8tZOD/AW3mDBLJCfZW6Vewyoy6zQSMe3qj1tVMmMQY7T+Vnc HS+w== X-Gm-Message-State: AIkVDXLUClXPqoh3EROvu94MXT01HfwfSwcm++U+5DtrJ+cQK/Q96o79wHiFtOKrfJ4fOQ9INkthYUY3No4AQw== X-Received: by 10.129.162.130 with SMTP id z124mr886500ywg.276.1485933562188; Tue, 31 Jan 2017 23:19:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Tue, 31 Jan 2017 23:18:41 -0800 (PST) In-Reply-To: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> References: <148587892598.2448.6982128247176255180.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 1 Feb 2017 08:18:41 +0100 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c1292922284f9054772de37 Archived-At: Cc: Flemming Andreasen , mmusic-chairs@ietf.org, draft-ietf-mmusic-4572-update@ietf.org, The IESG , mmusic WG Subject: Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 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, 01 Feb 2017 07:19:25 -0000 --94eb2c1292922284f9054772de37 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-mmusic-4572-update-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I've two (or 4 depending how you count:-) things > I'd like to check here. Should be pretty easy to > handle. > > (1) section 5: I'm wondering if we have the right > set of hash functions here. Deprecating md2 and md5 > is great, but I have a bunch of questions about the > others: > > (1.1) why not also say that sha-1 MUST NOT be used > for new things (or similar)? > > (1.2) do you really need sha-224 and 384? I think > nobody uses those at all. > It's certainly not correct that nobody uses SHA-384. In fact, for TLS 1.3, you can't sign anything with P-384 without using SHA-384. -Ekr > (1.3) I'm a bit surprised you didn't add sha3 (and > maybe remove sha-512 if that's not needed) Even if > you don't encourage use of sha3, it might be good > to include it in the abnf now in case it gets > popular. > > (2) Wouldn't it be a good plan to say that TLS > as-used MUST conform to BCP195? If not, why not? > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c1292922284f9054772de37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 5:08 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:
Steph= en Farrell has entered the following ballot position for
draft-ietf-mmusic-4572-update-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-mmusic-4572-update/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----


I've two (or 4 depending how you count:-) things
I'd like to check here. Should be pretty easy to
handle.

(1) section 5: I'm wondering if we have the right
set of hash functions here. Deprecating md2 and md5
is great, but I have a bunch of questions about the
others:

(1.1) why not also say that sha-1 MUST NOT be used
for new things (or similar)?

(1.2) do you really need sha-224 and 384? I think
nobody uses those at all.

It's cert= ainly not correct that nobody uses SHA-384.

In fac= t, for TLS 1.3, you can't sign anything with P-384 without using SHA-38= 4.

-Ekr


(1.3) I'm a bit surprised you didn't add sha3 (and
maybe remove sha-512 if that's not needed) Even if
you don't encourage use of sha3, it might be good
to include it in the abnf now in case it gets
popular.

(2) Wouldn't it be a good plan to say that TLS
as-used MUST conform to BCP195? If not, why not?




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

--94eb2c1292922284f9054772de37--