From nobody Mon Jul 3 05:38:54 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 E7BB113146A for ; Mon, 3 Jul 2017 05:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 8saS3mIaB7dS for ; Mon, 3 Jul 2017 05:38:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BD212762F for ; Mon, 3 Jul 2017 05:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4707; q=dns/txt; s=iport; t=1499085530; x=1500295130; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=VeKiYAFa2+Qb7Vb8fV59ODvmPF9TZbTRfCZxZcD188U=; b=ZdkmyzYcFES0oi6JiQzNpQmt0UT1T6C9lxIq/9t8d50gt86yciL+fLse eW7Hf3nmNbp6yjEMsg4cuUrTbgeW4gikQrISVjGSN4cf8yFxF7klEfuRE ZbBlG5R2MpifUAlAp5utimnbpwepsNavwWtp0+w2hCmRdet+9LgIjW7Xd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAQC3OVpZ/4QNJK1cGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1ljgQ6OBZFukFKFK4IRIQEKhSFPAoJvPxgBAgEBAQEBAQFrKIUZAQEBAwE?= =?us-ascii?q?BbBsLBBQuJzAGDQYCAQGKHg0QsnIpiyMBAQEBAQEBAQEBAQEBAQEBAQEBGgWDJ?= =?us-ascii?q?4NMggyCeYpeBYcciSyON45OhTOCDIVKg06GeZUwHziBClIjFUmHMSQ2hk0Egjs?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.40,303,1496102400"; d="scan'208,217";a="447377352" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jul 2017 12:38:50 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v63CcntL007181 for ; Mon, 3 Jul 2017 12:38:49 GMT To: mmusic References: From: Flemming Andreasen Message-ID: Date: Mon, 3 Jul 2017 08:38:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------908A5637BF3834B5D73C53B1" Archived-At: Subject: Re: [MMUSIC] MMUSIC Agenda Requests for IETF 99 (Prague) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 12:38:53 -0000 This is a multi-part message in MIME format. --------------908A5637BF3834B5D73C53B1 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Please note that the Working Group agenda is due on Wednesday and we have yet to receive any agenda requests. If you have any items you would like to discuss in Prague, please let chairs note ASAP. If there are no items to discuss, we will plan on canceling the MMUSIC meeting instead. Thanks Bo & Flemming On 6/16/17 8:58 AM, Flemming Andreasen wrote: > Hi > > IETF99 in Prague will be here before you know it, and the MMUSIC WG > has asked for a 2.5 hour meeting this time. Draft submissions and WG > agendas are both due in less than 3 weeks, so now would be a good time > to start preparing and let the chairs know if you have anything you > would like to get on the agenda. > > As usual, we want to ensure we take advantage of our meeting time in a > productive manner. This means that we want presenters to come prepared > to discuss open issues that have already been raised on the mailing > list and ideally received some feedback. Priority will be given to > drafts that gather attention and discussion on the mailing list prior > to the meeting. We also aim to give adequate time for drafts holding > up progress elsewhere. To facilitate this, please specify in your > agenda request e-mail the following: > > - name of the draft and the presenter > - how much time you would like > - outline of major open issues; what needs to be discussed at the meeting > - dependencies to your draft (if any) > > Thanks > > Bo & Flemming (MMUSIC co-chairs) > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------908A5637BF3834B5D73C53B1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Please note that the Working Group agenda is due on Wednesday and we have yet to receive any agenda requests.

If you have any items you would like to discuss in Prague, please let chairs note ASAP. If there are no items to discuss, we will plan on canceling the MMUSIC meeting instead.

Thanks

    Bo & Flemming

On 6/16/17 8:58 AM, Flemming Andreasen wrote:
Hi

IETF99 in Prague will be here before you know it, and the MMUSIC WG has asked for a 2.5 hour meeting this time. Draft submissions and WG agendas are both due in less than 3 weeks, so now would be a good time to start preparing and let the chairs know if you have anything you would like to get on the agenda.

As usual, we want to ensure we take advantage of our meeting time in a productive manner. This means that we want presenters to come prepared to discuss open issues that have already been raised on the mailing list and ideally received some feedback. Priority will be given to drafts that gather attention and discussion on the mailing list prior to the meeting. We also aim to give adequate time for drafts holding up progress elsewhere. To facilitate this, please specify in your agenda request e-mail the following:

- name of the draft and the presenter
- how much time you would like
- outline of major open issues; what needs to be discussed at the meeting
- dependencies to your draft (if any)
 

Thanks

     Bo & Flemming (MMUSIC co-chairs)



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

--------------908A5637BF3834B5D73C53B1-- From nobody Mon Jul 3 16:28:52 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 E0DFB13171F; Mon, 3 Jul 2017 16:28:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-mmusic-dtls-sdp@ietf.org, ben@nostrum.com, fandreas@cisco.com, mmusic@ietf.org, mmusic-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149912452491.16196.17319237242904397284.idtracker@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:28:44 -0700 Archived-At: Subject: [MMUSIC] Last Call: (Using the SDP Offer/Answer Mechanism for DTLS) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:28:45 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Using the SDP Offer/Answer Mechanism for DTLS' 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-07-24. 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. Version 22 of this document was previously last called. The last call is being repeated due to material changes made by the working group since that previous last call. Please see section 14 for details. 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, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 3 16:57:57 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 D79C2131804; Mon, 3 Jul 2017 16:57:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149912626884.16124.18101327141067026799@ietfa.amsl.com> Date: Mon, 03 Jul 2017 16:57:48 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-09.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 23:57:49 -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-09.txt Pages : 36 Date : 2017-07-03 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-09 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-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 Jul 3 17:06: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 E911F1317D6; Mon, 3 Jul 2017 17:06:19 -0700 (PDT) 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, 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 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 aeXMRnH8pMbP; Mon, 3 Jul 2017 17:06:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43844131806; Mon, 3 Jul 2017 17:06:14 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-67-595adbf42734 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.EA.06959.4FBDA595; Tue, 4 Jul 2017 02:06:12 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 4 Jul 2017 02:06:11 +0200 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=fCMXiCRUy3+I1hu7/dQ9dr5MKtTZNl9Hzg0H+tHlO2A=; b=aZ5y5BPKb/M6WNrGfIQlYVnlpODzo2tIRgfJtNfF9azLhecmWxuCYLSb6D4GfZ3RwI0kgI3CqBmoiMAER0PyqqzskTVMx4LpqnL2w0MOZltHI+amXn7ohyiBrPt2DOJJ5Z7Dx/wlsBXfP1W6TKi8Mlm/TZgjVyzi9X00FYhGjsA= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2690.eurprd07.prod.outlook.com (10.173.93.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 00:06:10 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7%18]) with mapi id 15.01.1240.010; Tue, 4 Jul 2017 00:06:10 +0000 From: Bo Burman To: Cullen Jennings , "Multiparty Multimedia Session Control Discussion List" CC: "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-sdp-simulcast-08 Thread-Index: AQHSzZy+deg+ODzFskOkGmiRY5DQ8aJCcNVw Date: Tue, 4 Jul 2017 00:06:10 +0000 Message-ID: References: <0F8243F1-BA73-4814-A35B-6924B609AE29@iii.ca> In-Reply-To: <0F8243F1-BA73-4814-A35B-6924B609AE29@iii.ca> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iii.ca; dkim=none (message not signed) header.d=none;iii.ca; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [83.209.207.106] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2690; 7:MnD+NmoIDWHlRyFLqPJs+vg0U7/buTOtkws4kWPmbLUBGiUN0YBaLWgvvWzpZzsy0mhESorn1OORKiv9p6LjlthJE/iCgwrIK6CCOB8PzlrrCzYo7VMRUZvzVHpoQO4y2+GUKlRMt5FcIv0O0msAUXzklKJI8Oi/8VeiASo5aZjsXjiR8V2lAuSOZynpgiymJdDzGkjdKy77uot1Rnhr8Ds2OOweayiQRRYlvMw+jrN7empCvPmSwsbzHirw1sUVbihgB7NpToRBHteq7adbFbUQeDFveHjn0FSnXMWMJVkV8zyEX88hNB+ZJ+usKhTO9Uc7EBp5BiTC8aHySobLPC5fB1C7b2ZylvZ5wkVEClkY44GpzmSo8HxiYJZjkdheBaj33jX/Tqpi8QI5l0eLTtNLGfuasl6uurJrlvPo5HhahhRJKF1FcAiuOqZKKKB9OsmvloV3aWGZoPAJpt+wM9GUFdgYl61nqQ1+lXLAMS7bDTXsLfXo36G2UuGJvMPoPiVVTGqfGuwRoj2F0VB51SmMxMvfrxpL4fcNdWBBzh6Ahow48R0c8F1FZU6hltB4dW++9xXE0m5DPsZyHj6DZ8rIaq4Bq6AtwqLpSDWNzWL7OzDU1VXUitkTqt6dPpyDk590pQcsT/eSS4fg0Oe5BxcdOk3N/y0vzSQ+yKgBWlkXFNh7YfCDJQCS8hW7kRiGsO5hzeKyUakCJwP9ax8jxW3pduFbz5ZIaujSqjoIQ6IvHSFEcLDE4MgzQAFWnr83ucqfHlRo0rVTyado+DoRc3Vfr7/Deg3c4xdFYh5V9RM= x-ms-office365-filtering-correlation-id: f6a38989-88b1-4e4e-da70-08d4c2707a42 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2690; x-ms-traffictypediagnostic: AM5PR0701MB2690: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(236129657087228)(48057245064654)(148574349560750)(209349559609743)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910026)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2690; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2690; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(39840400002)(39410400002)(39850400002)(39400400002)(39450400003)(13464003)(478600001)(2906002)(3846002)(81166006)(54356999)(14454004)(50986999)(7736002)(3280700002)(86362001)(305945005)(5250100002)(53546010)(76176999)(8936002)(74316002)(3660700001)(5660300001)(345774005)(8676002)(7696004)(6506006)(2900100001)(6436002)(66066001)(4326008)(25786009)(6116002)(102836003)(189998001)(229853002)(33656002)(2950100002)(53936002)(38730400002)(230783001)(99286003)(55016002)(9686003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2690; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 00:06:10.8472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2690 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42KZGbFdV/fL7ahIg3cnVS323DnHYvFh/Q9G i6nLH7M4MHssWfKTyePy+Y+MAUxRXDYpqTmZZalF+nYJXBlTm6cxFbwPrNjz1LuBcYNDFyMn h4SAicSUzzeYQWwhgSOMEut3uHYxcgHZxxklrrx9yA7isAj0Mks0fXvCCpGZziTRcKybEaLl GaNE28pEEJtNQENi/o67QHEODhGBAol7e3VBwswC2RK7Hi5iB7GFBSwlfmxbxgJiiwhYSax5 eAvKNpLY/r4XzGYRUJFYc3852EW8AgkSHzc8YgIZKQTUu+NmNkiYE6i1/dpzsBJGAVmJ+9/v sUCsEpe49WQ+E8RjAhJL9pxnhrBFJV4+/gd2PqNAO6PEjlMTWCASShJrl06BKpKVuDQf5C0u IPsRm8T1nesYIRK+ElO2v2GBSDxhkljStxQqoSNx/etfdgg7X+Ju72aooj5Gie4ZXawQzlVW iSnvO6CqZCTObJ3IDJFYxirx81M74wRG7VlIjoewdSQW7P7EBmFrSyxb+Jp5Fjg8BCVOznzC soCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYAo5uOW31Q7Gg88dDzEKcDAq8fA+PhEV KcSaWFZcmXuIUYKDWUmEV6YHKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS1OzU 1ILUIpgsEwenVAOjc9xy0cshT22/dM7Ilzm/4YBm/rw1O1Rf7pqa8CNIKsB6yUHDzQHestn3 Dkx6bBAhfk0yPS/1uOx0PdVEnwan20oW0WHmnIfSmdWeHbTn0Si5q8/230D/ARfX/ecKyp6v Nj+TYmWL+cq+9KHb5QPNgVXhgsLcF37au3OU3OpqZJP6WR5xQEKJpTgj0VCLuag4EQC3ssrR HQMAAA== Archived-At: Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-simulcast-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 00:06:20 -0000 Cullen, Thank you for good and constructive comments! Please see my responses below= . Just posted an -09 that hopefully addresses most if not all of your comment= s. Cheers, /Bo (as individual) > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: den 15 maj 2017 19:00 > To: Multiparty Multimedia Session Control Discussion List > Cc: Bo Burman > Subject: Review of draft-ietf-mmusic-sdp-simulcast-08 >=20 >=20 > Overall the actually protocol described by the spec seems fine with a few= very small technical details. However, it is a bit > challenging to understand the basic overview of how it works - I have a = few suggestions that I think would be not much > work that would really help people get up to speed by moving some of the = later example text to closer to where the > overview section is now. >=20 >=20 > Technical Issues ----------- >=20 > Issue 1: Pause in an SDP re-offer >=20 > The pause in section 6.3.4 seems problematic. If A is sending a re-offer = to B, there is no real way to know the pause state > of a stream B is sending to A at that point without glare issues. Saying = A has to send something that matches a state on B > is not really possible to implement. [BoB] Agree. This is clearly flawed and must be changed. >=20 > I think this should be changed to say A sets the pause flags in the SDP f= or RIDs A is sending to match what A currently > thinks the state of them is, and A sets the the pause flags for the RIDs = A is receiving to what A wished they were. The > way that B processes the offer and creates the answer as well as the hand= ling of the answer by A would be the same as > the initial offer/answer. [BoB] OK. SDP information for send direction RIDs becomes a snapshot in tim= e at a session modification and should therefore be taken as informational.= A further consequence should reasonably be that, for send direction RID th= at uses initially paused streams, RFC 7728 signaling is already present in = the ongoing session and takes precedence in case of any ambiguity or confli= ct. Agree for receive direction RID. The only difference from an initial offer = would be if a receive direction RID is actually already paused by A (throug= h RFC 7728 signaling) at the time of sending the updated SDP offer. The (mi= nor) difference to an initial offer is then that pausing a receive directio= n RID in the initial offer would instead always cause the SDP answerer (RTP= sender) to put the stream in _unsolicited_ pause (if the SDP answerer is a= ccepting to pause). >=20 > Given the timing issues of RTCP near at the start of the call, if we don'= t make this change, it may take significant time to > un-pause a particular stream at the start of the call. The above change a= llows that to happen so that if a user joined a call > that perhaps had a paused presentation stream and wanted to un-pause that= right away, they could. [BoB] OK. Makes sense. >=20 >=20 > Issue 2: More than one simulcast line >=20 > Some SDP stacks to not preserve the order of a=3Dlines. I have no idea if= this is a bug in them or not. I think it would be > better to phrase this spec as each m=3D section MUST have at most one a= =3Dsimulcast line.=20 [BoB] OK > The current phrasing of receiver > ignores all but first just begs for people to put proprietary stuff in a = second simulcast line. [BoB] In that case, I assume it is better to say that simulcast is ignored = entirely (removed in answer) for a media description with multiple a=3Dsimu= lcast lines? >=20 >=20 > Issue 3: Relating simulcast streams using PT >=20 > When the PT are unique, they can be used instead of RID. Obviously, if th= ey are not unique they can't be used, but when > they are, they often result in being able to display the video sooner. Of= ten RID/MID will not be included in every RTP > packet because of the bandwidth usage and are instead sent periodically. = Being able to join a conference and start > displaying stuff right away is nice when possible >=20 > I think section 6.5 needs to be updated to be clear that "RTP "Simulcast = streams MUST be related on RTP level through > RID." still means it is fine for the RTP receiver to use the PT of the RT= P packet and if that uniquely maps to a RID in the > SDP, use that for the relation. [BoB] OK. That was already possible since before, but to be entirely clear = I'll add a note saying that. >=20 >=20 > Editorial ---------------- >=20 >=20 > The use cases and requirements go for awhile and the first thing that sta= rts to explain how this works is bullet point point > 4 in the overview section which says >=20 > o The codec configuration for a simulcast stream is expressed > through use of separately specified RTP payload format > restrictions [I-D.ietf-mmusic-rid] with an associated RTP-level > identification mechanism [I-D.ietf-avtext-rid] to identify which > RTP payload format restrictions an RTP stream adheres to. This > complements and effectively extends simulcast stream > identification and configuration possibilities that could be > provided by using only SDP formats as identifier. Use of multiple > RTP streams with the same (non-redundancy) media type in the > context of a single media source, where those RTP streams are > using different RtpStreamId, is a strong but not totally > unambiguous indication of those RTP streams being part of a > simulcast. >=20 > Have a skim of the draft up to that point and ask yourself how much sense= it would make it you get to this point? Or how > much you would understand about how the mechahims of this draft actually = worked before you got to the ABNF shortly > after this. I suspect that you will likely come to the conclusion that it= 's a bit hard to understand the big picture of how it > works. [BoB] OK, the above text is probably way too detailed to provide any benefi= t to the reader compared to just continue reading. >=20 > I really can't make head or tails of the paragraph I quoted above but the= draft would make more sense to me if we > removed that, along with rest of section 5.=20 [BoB] To be clear, do you mean remove the entire section 5, or just the two= last bullets? You mention below having an "overview" section. > From the bullet point above, the draft goes straight into the ABNF for th= e new > stuff. I think it would be easier to understand if we: Moved section 4 to= appendix, [BoB] OK, no problem. > Greatly shortened section 3. [BoB] Given the amount of discussion we have had to understand what "simulc= ast" is and why it is useful, I think the reader would benefit from this ba= ckground. I'm not inclined to remove any of the use cases or motivations, b= ut I'll consider shortening the text. > Then add > an overview that starts with showing the offer and answer from 6.6.1. and= explaining how the only thing this draft adds is > the a=3Dsimulcast line.=20 [BoB] OK. I'd assume that the examples from 6.6.1 are a bit too detailed an= d could be simplified a bit in such high-level overview? I'll at least star= t something to discuss more around. > Explain the one m line means one source concept. Then show how simulcast = line allows sending the > 1;2 RIDs. Then explain how alternatives work. From there jump into the de= tails. I don't think this would be much new text > and it would not change how anything works, just clear up the explanation= . [BoB] Yes, that would work. >=20 > Section 6.1. and 6.2 are confusing because they are written as if they ar= e not for offer/answer SDP. I think it would be > better to state up front as that this was offer/answer SDP only and write= theses sections to be clear about if they are > referring to offers or answers when talking about SDP.=20 [BoB] The intent is clearly that both 6.1 and 6.2 should describe aspects o= f a=3Dsimulcast that are generally true, independent from offer and answer.= Any text there that are applicable only to offer or answer is a mistake an= d should be moved into those sections. > As a specific example, the pause discussion on page 13 might be > correct for answers but looks less correct for offers. [BoB] I find nothing in that text that does not apply both to offer and ans= wer. The text was written to reflect the view of the sender of the SDP, in = terms of stream directions, which should probably be more clearly stated. I= f that clarification does not help, could you please elaborate? >=20 > The SCID is really confusing in the draft. The draft is never fully clear= about if this is a RID or not it calls them "identical too" > but that hard to see if they are different but same value or work the sam= e way or something else. I think we should > remove the term SCID from the draft and just use RID.=20 [BoB] I have no problem aligning identifiers, but "RID" does not exist. We = once thought it would be called "RID", similar to "MID" from BUNDLE, but it= didn't happen. "RID" also does not exist in draft-ietf-avtext-rid, where t= he information element ended up being called "RtpStreamId", both for the SD= ES Item and the RTP Header Extension carrying that SDES Item. The identifie= r on an "a=3Drid" line is called "rid-id" in draft-ietf-mmusic-rid, which i= s the very same value used on an "a=3Dsimulcast" line, so I assume this dra= ft should be changed to be consistent with that naming.=20 > Similarly, using RtpStreamID is confusing. I think we should just > refer to that as the header that carries the RID. [BoB] Formally, RtpStreamId is the name of the SDES Item in both RTCP and R= TP header extension. It can be seen as the "container" that carries RID, bu= t I don't think we can use RID as a name, as said above. >=20 > The example on the top of page 11 makes no sense without enough of the SD= P to see the rids and m lines etc and needs > to be broken apart to be a Offer example followed by the Answer back to t= hat offer. [BoB] OK, I expect that if any of the information around that example shoul= d be kept, it will likely best go into the new overview section you propose= above. >=20 > NIT - define SFM on first use [BoB] OK >=20 >=20 >=20 From nobody Tue Jul 4 03:44: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 3D8C2131DF8; Tue, 4 Jul 2017 03:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2xPw0JYWLMg; Tue, 4 Jul 2017 03:44:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24933131DEE; Tue, 4 Jul 2017 03:44:14 -0700 (PDT) X-AuditID: c1b4fb3a-803ff70000001b2f-36-595b717c1fbb Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.30.06959.C717B595; Tue, 4 Jul 2017 12:44:13 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 4 Jul 2017 12:44:12 +0200 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=RQ4Q7dzVCXZhwPBBiIfaLc0JrA7N0W6AFwuJT5Vr64s=; b=L9VNOYXwKI2nc1BBFvtDHNPs4D5Tqfa7Mx0lVIusrbHVmgtYQFFg3PhoVqWtdqdrqdiLOIa9VCm9Rh0vkh9KmJNLpNFrJDoxkBGzCMcby2VncCAXjgtGmU1lyb23WN8of70lAdTuBRbBGtBYGKMbKC3kYnE6KWuj3xTtZjsPoe4= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB1763.eurprd07.prod.outlook.com (10.167.215.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Tue, 4 Jul 2017 10:44:10 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7%18]) with mapi id 15.01.1240.013; Tue, 4 Jul 2017 10:44:11 +0000 From: Bo Burman To: Cullen Jennings , "Multiparty Multimedia Session Control Discussion List" CC: "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" Thread-Topic: Review of draft-ietf-mmusic-sdp-simulcast-08 Thread-Index: AQHSzZy+deg+ODzFskOkGmiRY5DQ8aJCcNVw Date: Tue, 4 Jul 2017 10:44:10 +0000 Message-ID: References: <0F8243F1-BA73-4814-A35B-6924B609AE29@iii.ca> In-Reply-To: <0F8243F1-BA73-4814-A35B-6924B609AE29@iii.ca> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iii.ca; dkim=none (message not signed) header.d=none;iii.ca; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1763; 7:O9eOh4TSTwEUKDunIdEl4p8RhMxiZhfd4XFgNaXtVsaf7rXR+vMOeyonmd6yte/0Y5Bz6kL80Kx8+1SUA3l6ufM5XHHVyIDu9EjzwRu4tPiSuw12YKWCfS111R8lOtDmFfRC4Lj9SsuMoKDAZpHqOW0A8Ec8GpTbLfuqJAcStCZY9jHKBSC+cF3iYgjKsVqolIEhpAo7+w4Ig6GeSxn+dxXCS8pxoBQvE4EdNxeK4/s5bMi6CeQcDySw0EYnNy3tfPiymqwQ1BWkasFk10uohGsbrBwlPTsW2sXKviIkfqVscoNvDh0sFSyjUogd8IR4gjD29DFxsfwcd4TN28HOY3/e0HwyhWdOnxMnMaNXccjjqPHIAD7BqDp2stkBsyVVk/2x85efHQ4Dvq1QnOIhdzWd92fZrzWkqLOOWHAY/HJFR4MtnuvVvClzejyLOG90vMbxPfb5vnGg63kPGMe/sjnc1IWeeAiAPKk9rQJjDbOED3cjMBLcPIhZTov61p4wckFW5WzhQpUVwErluS99jCCEWW7ArWbSWZeufzoe+sIlC8nGXoRuulJ+LL+cskevvJkOBLXTSW7TKg1TrkbGqHlblyoy56KN7+N0Z7qb2SMJSbGh8JBXdW9H0xqEToskxTR+k6hAFqsMNY3t4qmDCocrqmoT20m3HqtyvW5OICbeJjhL6gCvtjaZVSd/v9FXF5EFB0SYI1BnlScoUEWmfWLp2kOSpp/d1FH+7mmzLPLC+SESc6VTxc6PcypgR0Na6xjtZbtCLsegKBOvEoHGzkHlnSYHOTMIVOQMi4SP4ww= x-ms-office365-filtering-correlation-id: fa19b8e2-1469-4d60-f0ff-08d4c2c99af9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB1763; x-ms-traffictypediagnostic: AM5PR0701MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(236129657087228)(48057245064654)(148574349560750)(209349559609743)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB1763; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39850400002)(39400400002)(39860400002)(39410400002)(13464003)(345774005)(2906002)(38730400002)(102836003)(478600001)(6116002)(229853002)(3660700001)(3846002)(5250100002)(76176999)(2950100002)(54356999)(66066001)(6506006)(53546010)(7696004)(230783001)(6436002)(50986999)(33656002)(8936002)(7736002)(25786009)(81166006)(74316002)(5660300001)(14454004)(99286003)(3280700002)(55016002)(9686003)(2900100001)(8676002)(53936002)(4326008)(86362001)(189998001)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB1763; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2017 10:44:10.7376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1763 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42KZGbE9ULe2MDrS4NwaXos9d86xWHxY/4PR YuryxywOzB5Llvxk8rh8/iNjAFMUl01Kak5mWWqRvl0CV0bLZN2CXUEVf6c9Z21gfO3QxcjJ ISFgInHrx0KWLkYuDiGBI4wSnROuQDnHGSXmru9iA3FYBHqZJS4+aGSCyMxmkmj70scI4Txj lGh4/o4NZBibgIbE/B13gRIcHCICBRL39uqChJkFsiV2PVzEDmILC1hK/Ni2jAXEFhGwkljz 8BaUbSSx/X0vmM0ioCJxbv9BsHpegQSJm/tvMIOMFALq3XEzGyTMCdTafu05M4jNKCArcf/7 PRaIVeISt57MZ4J4TUBiyZ7zzBC2qMTLx/9YQU5mFGhnlNhxagILyEwJAQWJ+zejIGpkJS7N 72aEsB+xSVz6pwVh+0o0bvsE1ishcJlJYt3DeVBFOhKNc4+xQNj5EkenvmOGKOpjlOie0QXV cYxVYtYLmDNkJM5snQhVNZdV4v2ZpcwTGLVnITkdwtaRWLD7ExuErS2xbOFr5lng0BCUODnz CcsCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIEp5OCW31Y7GA8+dzzEKMDBqMTD25cY HSnEmlhWXJl7iFGCg1lJhHdeMlCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZ qakFqUUwWSYOTqkGxtR5HiHXrIUM7HZtvxnzZ6792h/RH41zUq/J9aiYveMorBE/M3U3u87q bIaSM25qBhlOBx/P2pvct6GnxKM4J7hij9VMixU53vvPBM6J/CPaybyJicP+ivwTgynJl8wW LUqNkFWKnHVH0dQhgrdv8fYPe3UCsjYqfOM3l17T/W8Sp+fE6ay6SizFGYmGWsxFxYkAqcif oh0DAAA= Archived-At: Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-simulcast-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jul 2017 10:44:18 -0000 Cullen, Thank you for good and constructive comments! Please see my responses below= . Just posted an -09 that hopefully addresses most if not all of your comment= s. Cheers, /Bo (as individual) > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@iii.ca] > Sent: den 15 maj 2017 19:00 > To: Multiparty Multimedia Session Control Discussion List > Cc: Bo Burman > Subject: Review of draft-ietf-mmusic-sdp-simulcast-08 >=20 >=20 > Overall the actually protocol described by the spec seems fine with a few= very small technical details. However, it is a bit > challenging to understand the basic overview of how it works - I have a = few suggestions that I think would be not much > work that would really help people get up to speed by moving some of the = later example text to closer to where the > overview section is now. >=20 >=20 > Technical Issues ----------- >=20 > Issue 1: Pause in an SDP re-offer >=20 > The pause in section 6.3.4 seems problematic. If A is sending a re-offer = to B, there is no real way to know the pause state > of a stream B is sending to A at that point without glare issues. Saying = A has to send something that matches a state on B > is not really possible to implement. [BoB] Agree. This is clearly flawed and must be changed. >=20 > I think this should be changed to say A sets the pause flags in the SDP f= or RIDs A is sending to match what A currently > thinks the state of them is, and A sets the the pause flags for the RIDs = A is receiving to what A wished they were. The > way that B processes the offer and creates the answer as well as the hand= ling of the answer by A would be the same as > the initial offer/answer. [BoB] OK. SDP information for send direction RIDs becomes a snapshot in tim= e at a session modification and should therefore be taken as informational.= A further consequence should reasonably be that, for send direction RID th= at uses initially paused streams, RFC 7728 signaling is already present in = the ongoing session and takes precedence in case of any ambiguity or confli= ct. Agree for receive direction RID. The only difference from an initial offer = would be if a receive direction RID is actually already paused by A (throug= h RFC 7728 signaling) at the time of sending the updated SDP offer. The (mi= nor) difference to an initial offer is then that pausing a receive directio= n RID in the initial offer would instead always cause the SDP answerer (RTP= sender) to put the stream in _unsolicited_ pause (if the SDP answerer is a= ccepting to pause). >=20 > Given the timing issues of RTCP near at the start of the call, if we don'= t make this change, it may take significant time to > un-pause a particular stream at the start of the call. The above change a= llows that to happen so that if a user joined a call > that perhaps had a paused presentation stream and wanted to un-pause that= right away, they could. [BoB] OK. Makes sense. >=20 >=20 > Issue 2: More than one simulcast line >=20 > Some SDP stacks to not preserve the order of a=3Dlines. I have no idea if= this is a bug in them or not. I think it would be > better to phrase this spec as each m=3D section MUST have at most one a= =3Dsimulcast line.=20 [BoB] OK > The current phrasing of receiver > ignores all but first just begs for people to put proprietary stuff in a = second simulcast line. [BoB] In that case, I assume it is better to say that simulcast is ignored = entirely (removed in answer) for a media description with multiple a=3Dsimu= lcast lines? >=20 >=20 > Issue 3: Relating simulcast streams using PT >=20 > When the PT are unique, they can be used instead of RID. Obviously, if th= ey are not unique they can't be used, but when > they are, they often result in being able to display the video sooner. Of= ten RID/MID will not be included in every RTP > packet because of the bandwidth usage and are instead sent periodically. = Being able to join a conference and start > displaying stuff right away is nice when possible >=20 > I think section 6.5 needs to be updated to be clear that "RTP "Simulcast = streams MUST be related on RTP level through > RID." still means it is fine for the RTP receiver to use the PT of the RT= P packet and if that uniquely maps to a RID in the > SDP, use that for the relation. [BoB] OK. That was already possible since before, but to be entirely clear = I'll add a note saying that. >=20 >=20 > Editorial ---------------- >=20 >=20 > The use cases and requirements go for awhile and the first thing that sta= rts to explain how this works is bullet point point > 4 in the overview section which says >=20 > o The codec configuration for a simulcast stream is expressed > through use of separately specified RTP payload format > restrictions [I-D.ietf-mmusic-rid] with an associated RTP-level > identification mechanism [I-D.ietf-avtext-rid] to identify which > RTP payload format restrictions an RTP stream adheres to. This > complements and effectively extends simulcast stream > identification and configuration possibilities that could be > provided by using only SDP formats as identifier. Use of multiple > RTP streams with the same (non-redundancy) media type in the > context of a single media source, where those RTP streams are > using different RtpStreamId, is a strong but not totally > unambiguous indication of those RTP streams being part of a > simulcast. >=20 > Have a skim of the draft up to that point and ask yourself how much sense= it would make it you get to this point? Or how > much you would understand about how the mechahims of this draft actually = worked before you got to the ABNF shortly > after this. I suspect that you will likely come to the conclusion that it= 's a bit hard to understand the big picture of how it > works. [BoB] OK, the above text is probably way too detailed to provide any benefi= t to the reader compared to just continue reading. >=20 > I really can't make head or tails of the paragraph I quoted above but the= draft would make more sense to me if we > removed that, along with rest of section 5.=20 [BoB] To be clear, do you mean remove the entire section 5, or just the two= last bullets? You mention below having an "overview" section. > From the bullet point above, the draft goes straight into the ABNF for th= e new > stuff. I think it would be easier to understand if we: Moved section 4 to= appendix, [BoB] OK, no problem. > Greatly shortened section 3. [BoB] Given the amount of discussion we have had to understand what "simulc= ast" is and why it is useful, I think the reader would benefit from this ba= ckground. I'm not inclined to remove any of the use cases or motivations, b= ut I'll consider shortening the text. > Then add > an overview that starts with showing the offer and answer from 6.6.1. and= explaining how the only thing this draft adds is > the a=3Dsimulcast line.=20 [BoB] OK. I'd assume that the examples from 6.6.1 are a bit too detailed an= d could be simplified a bit in such high-level overview? I'll at least star= t something to discuss more around. > Explain the one m line means one source concept. Then show how simulcast = line allows sending the > 1;2 RIDs. Then explain how alternatives work. From there jump into the de= tails. I don't think this would be much new text > and it would not change how anything works, just clear up the explanation= . [BoB] Yes, that would work. >=20 > Section 6.1. and 6.2 are confusing because they are written as if they ar= e not for offer/answer SDP. I think it would be > better to state up front as that this was offer/answer SDP only and write= theses sections to be clear about if they are > referring to offers or answers when talking about SDP.=20 [BoB] The intent is clearly that both 6.1 and 6.2 should describe aspects o= f a=3Dsimulcast that are generally true, independent from offer and answer.= Any text there that are applicable only to offer or answer is a mistake an= d should be moved into those sections. > As a specific example, the pause discussion on page 13 might be > correct for answers but looks less correct for offers. [BoB] I find nothing in that text that does not apply both to offer and ans= wer. The text was written to reflect the view of the sender of the SDP, in = terms of stream directions, which should probably be more clearly stated. I= f that clarification does not help, could you please elaborate? >=20 > The SCID is really confusing in the draft. The draft is never fully clear= about if this is a RID or not it calls them "identical too" > but that hard to see if they are different but same value or work the sam= e way or something else. I think we should > remove the term SCID from the draft and just use RID.=20 [BoB] I have no problem aligning identifiers, but "RID" does not exist. We = once thought it would be called "RID", similar to "MID" from BUNDLE, but it= didn't happen. "RID" also does not exist in draft-ietf-avtext-rid, where t= he information element ended up being called "RtpStreamId", both for the SD= ES Item and the RTP Header Extension carrying that SDES Item. The identifie= r on an "a=3Drid" line is called "rid-id" in draft-ietf-mmusic-rid, which i= s the very same value used on an "a=3Dsimulcast" line, so I assume this dra= ft should be changed to be consistent with that naming.=20 > Similarly, using RtpStreamID is confusing. I think we should just > refer to that as the header that carries the RID. [BoB] Formally, RtpStreamId is the name of the SDES Item in both RTCP and R= TP header extension. It can be seen as the "container" that carries RID, bu= t I don't think we can use RID as a name, as said above. >=20 > The example on the top of page 11 makes no sense without enough of the SD= P to see the rids and m lines etc and needs > to be broken apart to be a Offer example followed by the Answer back to t= hat offer. [BoB] OK, I expect that if any of the information around that example shoul= d be kept, it will likely best go into the new overview section you propose= above. >=20 > NIT - define SFM on first use [BoB] OK >=20 >=20 >=20 From nobody Thu Jul 6 04:49: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 4EA3C129B34; Thu, 6 Jul 2017 04:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrp2v895IgK6; Thu, 6 Jul 2017 04:49:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A6A129AF4; Thu, 6 Jul 2017 04:49:29 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-28-595e23c8ccaa Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.8B.07915.8C32E595; Thu, 6 Jul 2017 13:49:28 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 6 Jul 2017 13:49:27 +0200 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=FlM9JahFkVBZNZV6bcrwV+n9dufYzYJwaxzETzyBGkg=; b=dJiFfSW2/K7EqeLBa3Bx/KVcLRskKDCOZPTAq/33xH+9nTgSJoF6OGNqExXJQfFE7QP2dFIgO8J4kNrFzmtM/rKZ06fB8ZCbY2zJdmpM873c+JTDtYlTW0wEguhD2lcWqpH55qQdYRrnVDmMaH1YJ70dUc00VQIKMmyQEOBrhvs= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2625.eurprd07.prod.outlook.com (10.173.92.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 11:49:26 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7%18]) with mapi id 15.01.1240.013; Thu, 6 Jul 2017 11:49:26 +0000 From: Bo Burman To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Adam Roach (adam@nostrum.com)" CC: "mmusic (mmusic@ietf.org)" , "Taylor Brandstetter (deadbeef@google.com)" , "draft-ietf-mmusic-rid@ietf.org" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Thread-Topic: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast Thread-Index: AQHSmSRXaXEak/rxUUuXLqrZPXzB4qGOeTSAgAADuwCAADM6gIAAAMcAgAAFxYCAA7fx4IAALRSAgAANzbCAAAP1gIAAG7mwgAAEAICAtIzBMA== Date: Thu, 6 Jul 2017 11:49:26 +0000 Message-ID: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: aliax.net; dkim=none (message not signed) header.d=none;aliax.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2625; 7:Dgt7rAo0BaZuDpE5FDcEXFrD+Hhs0/yw/tTy0U9XCJMQSuUAEi8Cx0t/UrSc8SOoBfqhN/W+VhSZ21VNdOuUhHB5zWy6HmmztMGuQk5pDu08/c5ohZiZVKnafrTyO+xR172LaCyjShhfcnksF1LEKP580Y7p7V6Vvz27y/EP59/jRmNWiNELTGqXbN8jJ7t5caLWUliaT3YeWNYGh2Qpi+RjM5A3EbZn+SOm43htQ5XnLI+r3x8eUjvQw4H8GJgsohtcFQXdDkcjCWl+hXcOH2swe+IJ6vP3QmU/QuHevOT8HEtFPGHcajYIOhSzj95iF73FJYqkp+BcbK5RlM7YXqVvnDB5ltDZZmVNrszaYJ12yEDhAMHBb0yVlSdNmCjeRdSzSWbcrrVYsPySbVB1RsbOag+Hxvf81sEnRwJhgdEUwTeM1e1BPgGmRU1qeNZ1qLbj+h9hTtKPZn6zjpANaGt5n9PMV/kHU4+7MVUXxrbUnFDDNC+s3lv+ikmvffyaOkLK7Jnne1iYebVqrnWLZqGhVN90hPvlKMNNqa610Jsn/xwS84WGbEL/y4GHw2rGc+mGY7yUro/omHchvm62MEw63MJy0yjT8cEtDhP0LYGDJCgYBJler0wNdv9kc7S7EEvrNSGKTWzfukFybNrtW/4F3P9A34YbAPpSjih9++IJqXc119BjmO0dWZIeHDUkaSah6gb58v5J5S6+Oewi1Z7lYGe09SHfinleypxuTH2jzQss9CYJt2YsOY2xqPUUGocjmgS2IppQbA875vbLQRiJaiFnzj1ziYQ/yDE3LtE= x-ms-office365-filtering-correlation-id: ae9548a8-67fd-49ba-2a00-08d4c4650db0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2625; x-ms-traffictypediagnostic: AM5PR0701MB2625: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(133145235818549)(236129657087228)(211936372134217)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2625; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2625; x-forefront-prvs: 03607C04F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39400400002)(39410400002)(377424004)(74316002)(2950100002)(5250100002)(66066001)(54906002)(99286003)(55016002)(9686003)(6436002)(25786009)(33656002)(6246003)(6506006)(86362001)(38730400002)(53546010)(229853002)(14454004)(53936002)(4326008)(478600001)(2900100001)(5660300001)(6116002)(102836003)(3846002)(3280700002)(7696004)(2906002)(189998001)(3660700001)(305945005)(8936002)(54356999)(7736002)(50986999)(8676002)(76176999)(81166006)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2625; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 11:49:26.5378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2625 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOXf3bldpcVqKzyxDV4GWqWXBApHs00oqpSK1MlfepqVT7qak kQ0KDHU5c6aOYhLL0iLNklRMSAstybdZ5PIldaSGoonmu+Z2F/Ttd57f//A8z+HQPJGJcqfj lWqGVcoTJHxnsjjizZk9LdujIwNKv4ul9SuPBFLz00FKmlfxgpCOGEZJaWFDkLTgyTB5iC9r 00wKZCVVKTKTaYGQGWqtZBgZ5RwUyyTEpzKsf3CMc1xZ3iyZPLTt2t3FSkKDlj2ykBMNeD88 KCmispAzLcLvEdQVF1I2IcLNCJ5/zbAJEmt5UNnTJOBSRQQYWptJ7vATQctYE892hY+9wVjT h2zsglloq9HwbczDBQTM3T5u4834COimzXwucxSmMhccnAELz3SEjUm8A6Ys7fa6EMdAeWYO wTUb4MNQ/Yh9PiccDr2zM/bGCHvAwFw/yTVzA4vVSHDLYTDVt/M4doWx4VX7oghrEdyamyE5 4QkDi/mOkAd0GbORLQR4iA9rr3IdoWOQ0/vLIcwEtBd+ozjhC/MrekcoCao/NCGOM0CnmyW5 C18oGLdY+ZzYCg9fLgo48ZiCWWMppUO7Df/NbkD0OvtARZ0/V/YCffagwGB/j03wsdhKliCy HLmqGNXFRMW+QD+Gjb+kUiUp/ZSMugqt/513r5d21iDzeEgjwjSSbBBO8KIjRZQ8VZWW2IiA 5klchNXi9ZIwVp6WzrBJF9iUBEbViLbQpMRNGNLQESHCCrmaucowyQz7zxK0k7sGsYHB/flz tRWscrlJfK5HnhDb2tmhMGm9zaHzAeLV/riKzxaLeEB9Q62Y9gn0jS4d3Jiun5zpzn0r6068 k9w3ERXZfcB6Nnam63do4c3TRZ/Q6P3rqLcz/Z6X5/m16czJtRNdvUuHT5bmlv2p0urDtZf1 P5acVoNHTo1eORiBwiSkKk6+dxePVcn/AiilSiM3AwAA Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jul 2017 11:49:38 -0000 VG8gZm9sbG93IHVwIG9uIHRoaXMsIEkgc3VnZ2VzdCBtYWtpbmcgdGhlIGZvbGxvd2luZyBhZGRp dGlvbiB0byBkcmFmdC1pZXRmLW1tdXNpYy1yaWQ6DQoNCi0tLS0gQUZURVIgdGhpcyB0ZXh0IGlu IHNlY3Rpb24gNCAtLS0tDQoNCiAgIEFuICJhPXJpZCIgU0RQIG1lZGlhIGF0dHJpYnV0ZSBzcGVj aWZpZXMgcmVzdHJpY3Rpb25zIGRlZmluaW5nIGENCiAgIHVuaXF1ZSBSVFAgcGF5bG9hZCBjb25m aWd1cmF0aW9uIGlkZW50aWZpZWQgdmlhIHRoZSAicmlkLWlkIiBmaWVsZC4NCiAgIFRoaXMgdmFs dWUgYmluZHMgdGhlIHJlc3RyaWN0aW9uIHRvIHRoZSBSVFAgU3RyZWFtIGlkZW50aWZpZWQgYnkg aXRzDQogICBSVFAgU3RyZWFtIElkZW50aWZpZXIgU0RFUyBpdGVtIFtJLUQuaWV0Zi1hdnRleHQt cmlkXS4gIFRvIGJlIGNsZWFyLA0KICAgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlIHRoZSAiYT1y aWQiIHBhcmFtZXRlciBpbiBTRFAgTVVTVCBzdXBwb3J0DQogICB0aGUgUnRwU3RyZWFtSWQgU0RF UyBpdGVtIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtYXZ0ZXh0LXJpZF0uICBTdWNoDQogICBpbXBs ZW1lbnRhdGlvbnMgTVVTVCBzZW5kIGl0IGZvciBhbGwgc3RyZWFtcyBpbiBhbiBTRFAgbWVkaWEN CiAgIGRlc2NyaXB0aW9uICgibT0iKSB0aGF0IGhhdmUgImE9cmlkIiBsaW5lcyByZW1haW5pbmcg YWZ0ZXIgYXBwbHlpbmcNCiAgIHRoZSBydWxlcyBpbiBTZWN0aW9uIDYgYW5kIGl0cyBzdWJzZWN0 aW9ucy4NCg0KLS0tLSAuLi4gYWRkIHRoaXMgcHJvcG9zZWQsIG5ldyB0ZXh0IC0tLS0NCg0KICAg SW1wbGVtZW50YXRpb25zIHRoYXQgdXNlIHRoZSAiYT1yaWQiIHBhcmFtZXRlciBpbiBTRFAgYW5k IHRoYXQNCiAgIG1ha2UgdXNlIG9mIHJlZHVuZGFuY3kgUlRQIHN0cmVhbXMgW1JGQzc2NTZdLCBl LmcuIFJUUCBSVFgNCiAgIFtSRkM0NTg4XSBvciBGRUMgW1JGQzUxMDldW0ktRC5pZXRmLXBheWxv YWQtZmxleGlibGUtZmVjLXNjaGVtZV0sDQogICBmb3IgYW55IG9mIHRoZSBzb3VyY2UgUlRQIHN0 cmVhbXMgdGhhdCBoYXZlICJhPXJpZCIgbGluZXMgcmVtYWluaW5nDQogICBhZnRlciBhcHBseWlu ZyB0aGUgcnVsZXMgaW4gU2VjdGlvbiA2IGFuZCBpdHMgc3Vic2VjdGlvbnMsIE1VU1QNCiAgIHN1 cHBvcnQgYW5kIHVzZSBSZXBhaXJlZFJ0cFN0cmVhbUlkIFNERVMgaXRlbSBkZXNjcmliZWQgaW4N CiAgIFtJLUQuaWV0Zi1hdnRleHQtcmlkXSBmb3IgdGhvc2UgcmVkdW5kYW5jeSBSVFAgc3RyZWFt cy4gVGhpcyBwcm92aWRlcw0KICAgdGhlIGJpbmRpbmcgYmV0d2VlbiB0aGUgc291cmNlIFJUUCBz dHJlYW0gYW5kIHRoZSBjb3JyZXNwb25kaW5nDQogICByZWR1bmRhbmN5IFJUUCBzdHJlYW0sIGJ5 IHNldHRpbmcgUmVwYWlyZWRSdHBTdHJlYW1JZCB2YWx1ZSBmb3INCiAgIHRoZSByZWR1bmRhbmN5 IFJUUCBzdHJlYW0gdG8gdGhlIFJ0cFN0cmVhbUlkIHZhbHVlIG9mIHRoZSBzb3VyY2UNCiAgIFJU UCBzdHJlYW0uIFRoZSByZWR1bmRhbmN5IFJUUCBzdHJlYW0gTUFZIChidXQgbmVlZCBub3QpIGhh dmUgYW4NCiAgICJhPXJpZCIgbGluZSBvZiBpdHMgb3duLCBpbiB3aGljaCBjYXNlIHRoZSBSdHBT dHJlYW1JZCBTREVTIGl0ZW0gdmFsdWUNCiAgIHdpbGwgYmUgZGlmZmVyZW50IGZyb20gdGhlIGNv cnJlc3BvbmRpbmcgc291cmNlIFJUUCBzdHJlYW0uDQoNCi0tLS0gRW5kIGNoYW5nZXMgLS0tLQ0K DQpUaGUgLXNpbXVsY2FzdCBkcmFmdCB3b3VsZCBiZSBlbnRpcmVseSBhZ25vc3RpYyB0byB0aGlz IGNsYXJpZmljYXRpb24gb2YgImE9cmlkIiBhbmQgUmVwYWlyZWRSdHBTdHJlYW1JZCB1c2FnZSBh bmQgdGhlcmVieSB0cmFuc3BhcmVudGx5IGFsbG93IHVzaW5nIHJlZHVuZGFuY3kgUlRQIHN0cmVh bXMgd2l0aCBzaW11bGNhc3QuDQoNCi9Cbw0KKGFzIGluZGl2aWR1YWwpDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmli Y0BhbGlheC5uZXRdDQo+IFNlbnQ6IGRlbiAxMyBtYXJzIDIwMTcgMTQ6NDMNCj4gVG86IEJvIEJ1 cm1hbiA8Ym8uYnVybWFuQGVyaWNzc29uLmNvbT4NCj4gQ2M6IG1tdXNpYyAobW11c2ljQGlldGYu b3JnKSA8bW11c2ljQGlldGYub3JnPjsgVGF5bG9yIEJyYW5kc3RldHRlciAoZGVhZGJlZWZAZ29v Z2xlLmNvbSkNCj4gPGRlYWRiZWVmQGdvb2dsZS5jb20+OyBkcmFmdC1pZXRmLW1tdXNpYy1yaWRA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3RAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtNTVVTSUNdIEZXOiBbcnRjd2ViXSBIb3cgdG8gc2lnbmFsIFJUWCBTU1JDcyB3 aXRoIHNpbXVsY2FzdA0KPiANCj4gMjAxNy0wMy0xMyAxNDo0MSBHTVQrMDE6MDAgQm8gQnVybWFu IDxiby5idXJtYW5AZXJpY3Nzb24uY29tPjoNCj4gPiBbQm9CXSBVc2FnZSBvZiBSZXBhaXJlZFJ0 cFN0cmVhbUlkIGFuZCBSdHBTdHJlYW1JZCBhcmUgYWxyZWFkeSBkZWZpbmVkIG9uIFJUUCBsZXZl bCBieSAtYXZ0ZXh0LXJpZC4gSWYgd2UgaGF2ZQ0KPiBwcmVmZXJlbmNlcyBvbiBob3cgdG8gYmVz dCB1c2UgdGhlbSB3aXRoIHJlZHVuZGFuY3kgUlRQIHN0cmVhbXMgaW4gZ2VuZXJhbCwgSSBzdWdn ZXN0IHdlIGFkZCB0ZXh0IHRvIC1tbXVzaWMtcmlkDQo+IGFib3V0IGl0LiBUaGlzIHdvdWxkIGJl IHJlZ2FyZGxlc3MgaWYgd2UgZ28gZm9yIG9wdGlvbiBBIG9yIEIsIGJ1dCBkZWNpZGVkIG9uY2Ug YW5kIGZvciBhbGwsIHRodXMgYXBwbGljYWJsZSB0byBSRkMgNDU4OCBydHgNCj4gYW5kIEZMRVgt RkVDIGFsaWtlLg0KPiANCj4gQWdyZWVkLg0KPiANCj4gDQo+IC0tDQo+IEnDsWFraSBCYXogQ2Fz dGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo= From nobody Fri Jul 7 13:10: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 C2E32131780; Fri, 7 Jul 2017 13:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 O-snqgYZg7Ik; Fri, 7 Jul 2017 13:10:29 -0700 (PDT) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A396131781; Fri, 7 Jul 2017 13:10:25 -0700 (PDT) X-AuditID: 12074411-cebff700000033ea-af-595feab074b6 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 85.BE.13290.0BAEF595; Fri, 7 Jul 2017 16:10:24 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v67KANCr001805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 7 Jul 2017 16:10:24 -0400 From: Paul Kyzivat To: draft-ietf-mmusic-dtls-sdp.all@ietf.org Cc: General Area Review Team , IETF MMUSIC WG Message-ID: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> Date: Fri, 7 Jul 2017 16:10:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixO6iqLvhVXykwe/5+hY77u5gs7j66jOL xdTlj1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJUxY2FtwR6OitvPvzM3MD5m62Lk5JAQMJHo fvaMGcQWEtjBJDHveVkXIxeQfYVJovnXclaQBJuAlsScQ/9ZQGxhASeJG2+7weIiAtoSHZPb wGxmgSiJ45+XMIHYvAL2EkePzAerZxFQkWjbPxlsmahAmsSSW1OhagQlTs58wgLRayYxb/ND ZghbXOLWk/lMELa8RPPW2cwTGPlmIWmZhaRlFpKWWUhaFjCyrGKUS8wpzdXNTczMKU5N1i1O TszLSy3SNdXLzSzRS00p3cQICUfBHYwzTsodYhTgYFTi4TXoj48UYk0sK67MPcQoycGkJMr7 xgcoxJeUn1KZkVicEV9UmpNafIhRgoNZSYS32Rsox5uSWFmVWpQPk5LmYFES5+Vbou4nJJCe WJKanZpakFoEk5Xh4FCS4OV8CdQoWJSanlqRlplTgpBm4uAEGc4DNDz4KMjw4oLE3OLMdIj8 KUZdjl8zt35hEmLJy89LlRLnlX0BVCQAUpRRmgc3B5ZGXjGKA70lzOsKso4HmILgJr0CWsIE tESxMQZkSUkiQkqqgTHrbIXpfhGbKFFvw+xzdnqKc1+7Pwk7OJ//xWGfK35NJRJteXcLtCcG 7nqVMeHmyqeFL9pfL/nEsEH51tPESPfXOc3rC6ynCjybPH/lxHg3o+vL7X492C1jtmxbMX+r p3mj2JovxzU6efIatlyQqGqaMlXsR7Lg5uvTGe0t49YprP3ywbzwqKISS3FGoqEWc1FxIgDv EhMv/gIAAA== Archived-At: Subject: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:10:31 -0000 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 <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-dtls-sdp-26 Reviewer: Paul Kyzivat Review Date: 2017-07-07 IETF LC End Date: 2017-07-24 IESG Telechat date: TBD Summary: This draft is basically ready for publication, but has a few nits that should be fixed before publication. Issues: Major: 0 Minor: 0 Nits: 4 (1) NIT: Section 5.3: s/Eventhough/Even though/ (2) NIT: Section 8: s/aTLS/a TLS/ (3) NIT: Section 8: What is the point of including the example? I don't see how it adds anything. Perhaps worked out O/A examples contrasting the differences between the new and existing cases might be marginally helpful. (But IMO not enough to bother with.) (4) NIT: Section 10.3.2: s/Througout/throughout/ From nobody Mon Jul 10 01:08: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 B22521275AB; Mon, 10 Jul 2017 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGPINilPIaYE; Mon, 10 Jul 2017 01:08:31 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FF5126C3D; Mon, 10 Jul 2017 01:08:30 -0700 (PDT) X-AuditID: c1b4fb3a-bea2a9c000001b2f-be-596335fcc238 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.D0.06959.CF533695; Mon, 10 Jul 2017 10:08:28 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 10:08:24 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 Thread-Index: AQHS910XUh6Pan5Z40qWLa0ZRshaF6JMyUmA Date: Mon, 10 Jul 2017 08:08:24 +0000 Message-ID: References: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> In-Reply-To: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7ge4f0+RIg+2dWhY77u5gs7j66jOL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZfyd9Y+1oIu/4sq5VSwN jDf4uhg5OSQETCSmLetn6mLk4hASOMIo0XpjCzOEs5hRouF4I1CGg4NNwEKi+582SFxEoJFR onH6fmaQbmaBYIm9+7cxgtjCAm4Ss/cdZgexRQTcJW5cOs0CYRtJTH+1hg3EZhFQlVj9eh9Y L6+AtcSdl1vBbCEBe4lfh/eCzeEUcJCYvPYmE4jNKCAm8f3UGiaIXeISt57MZ4K4WkBiyZ7z zBC2qMTLx/9YQe4UFdCTeLffEyKsJPFjwyUWkDCzgKbE+l36EFOsJV683cgOYStKTOl+yA5x jaDEyZlPWCYwis9CsmwWQvcsJN2zkHTPQtK9gJF1FaNocWpxcW66kZFealFmcnFxfp5eXmrJ JkZg/B3c8ttqB+PB546HGAU4GJV4eHnlkyOFWBPLiitzDzFKcDArifDONAIK8aYkVlalFuXH F5XmpBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwMgyf6LGgk9m/qsf/v22aqZP 2gznmmr/DbGaRt/6hC7N+yu9MrdZrNkihnXNG9Y1mvz5QqcX7e6bwWHqdcpxVeete2t0QkWE PhZ/kX42N1nI0PZc4zuXZJWPDycoGxXv4TE7MlG+IV+jdfo2F4YYxy8x3K9fL8o9eejCG5mr 134tLlp/+F5FI7cSS3FGoqEWc1FxIgAMrntkuwIAAA== Archived-At: Subject: Re: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 08:08:32 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBpbmxpbmUuDQoN Cg0KPkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRo ZSBHZW5lcmFsIEFyZWENCj5SZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KPklFU0cgZm9yIHRoZSBJRVRGIENoYWly LiBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlcg0KPmxhc3Qg Y2FsbCBjb21tZW50cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBh dA0KPjzigItodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2Vu QXJ0ZmFxPi4NCj4NCj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjYNCj5S ZXZpZXdlcjogUGF1bCBLeXppdmF0DQo+UmV2aWV3IERhdGU6IDIwMTctMDctMDcNCj5JRVRGIExD IEVuZCBEYXRlOiAyMDE3LTA3LTI0DQo+SUVTRyBUZWxlY2hhdCBkYXRlOiBUQkQNCj4NCj5TdW1t YXJ5Og0KPg0KPlRoaXMgZHJhZnQgaXMgYmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwg YnV0IGhhcyBhIGZldyBuaXRzIHRoYXQNCj5zaG91bGQgYmUgZml4ZWQgYmVmb3JlIHB1YmxpY2F0 aW9uLg0KPg0KPklzc3VlczoNCj4NCj5NYWpvcjogMA0KPk1pbm9yOiAwDQo+Tml0czogIDQNCj4N Cj4oMSkgTklUOg0KPg0KPlNlY3Rpb24gNS4zOiBzL0V2ZW50aG91Z2gvRXZlbiB0aG91Z2gvDQoN CldpbGwgYmUgZml4ZWQuDQoNCj4oMikgTklUOg0KPg0KPlNlY3Rpb24gODogcy9hVExTL2EgVExT Lw0KDQpXaWxsIGJlIGZpeGVkLg0KDQo+KDMpIE5JVDoNCj4NCj5TZWN0aW9uIDg6IFdoYXQgaXMg dGhlIHBvaW50IG9mIGluY2x1ZGluZyB0aGUgZXhhbXBsZT8gSSBkb24ndCBzZWUgaG93DQo+aXQg YWRkcyBhbnl0aGluZy4gUGVyaGFwcyB3b3JrZWQgb3V0IE8vQSBleGFtcGxlcyBjb250cmFzdGlu ZyB0aGUNCj5kaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBuZXcgYW5kIGV4aXN0aW5nIGNhc2VzIG1p Z2h0IGJlIG1hcmdpbmFsbHkNCj5oZWxwZnVsLiAoQnV0IElNTyBub3QgZW5vdWdoIHRvIGJvdGhl ciB3aXRoLikNCg0KVGhlIGlkZWEgd2FzIHRvIHRha2UgdGhlIGV4aXN0aW5nIGV4YW1wbGUgZnJv bSBSRkMgNDU3MiAoSSBub3RlIHRoZQ0KcmVmZXJlbmNlIGlzIHdyb25nOiBzLzMyNjEvNDU3Miks IGFuZCBzaG93IGhvdyBpdCBsb29rcyB3aXRoIHRoZSB0bHMtaWQNCmF0dHJpYnV0ZS4NCg0KDQo+ KDQpIE5JVDoNCj4NCj5TZWN0aW9uIDEwLjMuMjogcy9UaHJvdWdvdXQvdGhyb3VnaG91dC8NCg0K V2lsbCBiZSBmaXhlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Mon Jul 10 02:03: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 31E4E129461; Mon, 10 Jul 2017 02:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STLt0hXTaJ5G; Mon, 10 Jul 2017 02:02:53 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A811713167B; Mon, 10 Jul 2017 02:02:52 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-b3-596342baa2f4 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.40.06959.AB243695; Mon, 10 Jul 2017 11:02:50 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Mon, 10 Jul 2017 11:02:50 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 Thread-Index: AQHS910XUh6Pan5Z40qWLa0ZRshaF6JMyUmAgAAPmYA= Date: Mon, 10 Jul 2017 09:02:50 +0000 Message-ID: References: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7k+4up+RIg2+TbSx23N3BZnH11WcW i6nLH7NYrNhwgNWBxePv+w9MHkuW/GQKYIrisklJzcksSy3St0vgyri08RV7wSqhimsfJjA2 ML4R7GLk5JAQMJFoXnKQsYuRi0NI4AijxLlDO9ghnMWMEr+a+oAcDg42AQuJ7n/aIHERga2M EiuebmcD6WYWCJbYu38bI4gtLOAmMXvfYXYQW0TAXeLGpdMsELaVROPSB8wgNouAqsTunrtg 9bwC1hK/dxxgBbGFBAolrp6/DraLU8BG4uPyApAwo4CYxPdTa5ggVolL3HoynwniaAGJJXvO M0PYohIvH/9jBWkVFdCTeLffEyKsKPHx1T5GkDCzgKbE+l36EFOsJV7cgjiMGahkSvdDdohj BCVOznzCMoFRfBaSZbMQumch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2 MQKj7+CW31Y7GA8+dzzEKMDBqMTD+9AiOVKINbGsuDL3EKMEB7OSCO9MI6AQb0piZVVqUX58 UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjJOybzYI/3reXezkd+D8g8I9 6hP0cjTtnrsZGP/prv0r/MuctWzlLfsbIh7bO4o2r77XweZ5X/T2PC2V0i3nL3BUvcziy5Fd mNhz9FSgtG9ErNI3Z8+4jylOr/L+PJZbw7pON3P2zG+Z6bM3d7kafDExjKy7f2XfwwkXIqM+ f6latLopXPKjhhJLcUaioRZzUXEiANDNASq6AgAA Archived-At: Subject: Re: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2017 09:02:55 -0000 UHVsbCByZXF1ZXN0OiBodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtZHRscy1zZHAvcHVs bC8zMw0KDQooSSBrZXB0IHRoZSBleGFtcGxlIGluIFNlY3Rpb24gOCwgYnV0IEkgZml4ZWQgdGhl IHJlZmVyZW5jZSkNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAxMC8wNy8xNyAxMTow OCwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0K d3JvdGU6DQoNCj5IaSBQYXVsLA0KPg0KPlRoYW5rcyBmb3IgeW91ciByZXZpZXchIFBsZWFzZSBz ZWUgaW5saW5lLg0KPg0KPg0KPj5JIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZv ciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhDQo+PlJldmlldyBUZWFtIChHZW4tQVJUKSBy ZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+PklFU0cg Zm9yIHRoZSBJRVRGIENoYWlyLiBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlcg0KPj5sYXN0IGNhbGwgY29tbWVudHMuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBw bGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4+POKAi2h0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2Fy ZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPj4NCj4+RG9jdW1lbnQ6IGRyYWZ0LWlldGYt bW11c2ljLWR0bHMtc2RwLTI2DQo+PlJldmlld2VyOiBQYXVsIEt5eml2YXQNCj4+UmV2aWV3IERh dGU6IDIwMTctMDctMDcNCj4+SUVURiBMQyBFbmQgRGF0ZTogMjAxNy0wNy0yNA0KPj5JRVNHIFRl bGVjaGF0IGRhdGU6IFRCRA0KPj4NCj4+U3VtbWFyeToNCj4+DQo+PlRoaXMgZHJhZnQgaXMgYmFz aWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBhIGZldyBuaXRzIHRoYXQNCj4+ c2hvdWxkIGJlIGZpeGVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCj4+DQo+Pklzc3VlczoNCj4+DQo+ Pk1ham9yOiAwDQo+Pk1pbm9yOiAwDQo+Pk5pdHM6ICA0DQo+Pg0KPj4oMSkgTklUOg0KPj4NCj4+ U2VjdGlvbiA1LjM6IHMvRXZlbnRob3VnaC9FdmVuIHRob3VnaC8NCj4NCj5XaWxsIGJlIGZpeGVk Lg0KPg0KPj4oMikgTklUOg0KPj4NCj4+U2VjdGlvbiA4OiBzL2FUTFMvYSBUTFMvDQo+DQo+V2ls bCBiZSBmaXhlZC4NCj4NCj4+KDMpIE5JVDoNCj4+DQo+PlNlY3Rpb24gODogV2hhdCBpcyB0aGUg cG9pbnQgb2YgaW5jbHVkaW5nIHRoZSBleGFtcGxlPyBJIGRvbid0IHNlZSBob3cNCj4+aXQgYWRk cyBhbnl0aGluZy4gUGVyaGFwcyB3b3JrZWQgb3V0IE8vQSBleGFtcGxlcyBjb250cmFzdGluZyB0 aGUNCj4+ZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgbmV3IGFuZCBleGlzdGluZyBjYXNlcyBtaWdo dCBiZSBtYXJnaW5hbGx5DQo+PmhlbHBmdWwuIChCdXQgSU1PIG5vdCBlbm91Z2ggdG8gYm90aGVy IHdpdGguKQ0KPg0KPlRoZSBpZGVhIHdhcyB0byB0YWtlIHRoZSBleGlzdGluZyBleGFtcGxlIGZy b20gUkZDIDQ1NzIgKEkgbm90ZSB0aGUNCj5yZWZlcmVuY2UgaXMgd3Jvbmc6IHMvMzI2MS80NTcy KSwgYW5kIHNob3cgaG93IGl0IGxvb2tzIHdpdGggdGhlIHRscy1pZA0KPmF0dHJpYnV0ZS4NCj4N Cj4NCj4+KDQpIE5JVDoNCj4+DQo+PlNlY3Rpb24gMTAuMy4yOiBzL1Rocm91Z291dC90aHJvdWdo b3V0Lw0KPg0KPldpbGwgYmUgZml4ZWQuDQo+DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rlcg0KPg0K DQo= From nobody Tue Jul 11 06:46: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 7B779129B55 for ; Tue, 11 Jul 2017 06:46:28 -0700 (PDT) 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 hJ074bsRFJRj for ; Tue, 11 Jul 2017 06:46:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689BD129B30 for ; Tue, 11 Jul 2017 06:46:26 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-37-5964d6b0bed2 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.5D.05732.0B6D4695; Tue, 11 Jul 2017 15:46:24 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Tue, 11 Jul 2017 15:46:23 +0200 From: Christer Holmberg To: Christer Holmberg , Adam Roach , "mmusic@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" Thread-Index: AQHSa0QA09pHndxnh0aKl8R4w17a+aJP0qmA Date: Tue, 11 Jul 2017 13:46:23 +0000 Message-ID: References: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="euc-kr" Content-ID: <8A2F1EC10E95C5469AEB8E568224BE9C@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7k+6GaymRBq/6VSz2/F3EbjF1+WMW ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj/Z2JTAUr5CqunPrN0sB4RLaLkZNDQsBE Yvf6ZWxdjFwcQgJHGCWm9ixngXAWM0osOjeNsYuRg4NNwEKi+582SIOIQI1Ex60DrCC2sECY xI7te5kg4uESn783sEDYRhIHus+BxVkEVCXef7wGFucVsJbY0dTDBmILCRRIvFryghHE5hSw kThyZgOYzSggJvH91BqwXmYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wgp4kK6Em82+8JEVaU +PhqHyNEq5bElx/72CBsa4lljRtYIGxFiSndD9khzhGUODnzCcsERrFZSLbNQtI+C0n7LCTt s5C0L2BkXcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGFUHt/w22MH48rnjIUYBDkYlHt4L +1MihVgTy4orcw8xSnAwK4nw/r4IFOJNSaysSi3Kjy8qzUktPsQozcGiJM7ruO9ChJBAemJJ anZqakFqEUyWiYNTqoHReeH6qc12nJxNQuuu+9wOkpO+NL1n6s47NvGbnV+HNd38vMXs6Sm7 4mvxHUVlr+wLNqx8v7h3bZPz9yxrxosNeR1saQsEtHPj5UuK/58SjDl29e1jy1nyB83fzZP8 KnNzQ/TeN/wKoduPqRzRTC01L+J86s/VlhuexeP1Y87MyxNk3zlmLElVYinOSDTUYi4qTgQA cecsNqYCAAA= Archived-At: Subject: Re: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2017 13:46:28 -0000 SGksDQoNCkl0IHRvb2sgYSB3aGlsZSwgYnV0IGhlcmUgaXMgbXkgc3VnZ2VzdGlvbiAoYmFzZWQg b24gYWx0ZXJuYXRpdmUgIzIpOg0KDQpPTEQgVEVYVDoNCg0KIlRoZSB1c2FnZSBvZiB0aGUgJ2J1 bmRsZS1vbmx5JyBhdHRyaWJ1dGUgaXMgb25seSBkZWZpbmVkIGZvciBhDQogICBidW5kbGVkICJt PSIgbGluZSB3aXRoIGEgemVybyBwb3J0IHZhbHVlLCB3aXRoaW4gYW4gb2ZmZXIuICBPdGhlcg0K ICAgdXNhZ2UgaXMgdW5zcGVjaWZpZWQuIg0KDQoNCk5FVyBURVhUOg0KDQoiVGhlIHVzYWdlIG9m IHRoZSAnYnVuZGxlLW9ubHknIGF0dHJpYnV0ZSBpcyBvbmx5IGRlZmluZWQgZm9yIGENCiAgIGJ1 bmRsZWQgIm09IiBsaW5lIHdpdGggYSB6ZXJvIHBvcnQgdmFsdWUsIHdpdGhpbiBhbiBvZmZlci4g IE90aGVyDQogICB1c2FnZSBpcyB1bnNwZWNpZmllZC4gSWYgYW4gaW1wbGVtZW50YXRpb24gcmVj ZWl2ZXMsIHdpdGhpbg0KYW4gb2ZmZXIgb3IgYW5zd2VyLCBhIGJ1bmRsZWQgIm09obAgbGluZSB3 aXRoIGEgbm9uLXplcm8gcG9ydCB2YWx1ZQ0KDQphbmQgYW4goa5idW5kbGUtb25seaGvIGF0dHJp YnV0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIKGwbT2hsCBsaW5lLCB0aGUNCmltcGxlbWVudGF0aW9u IE1VU1QgaWdub3JlIHRoZSBhdHRyaWJ1dGUuIg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Ck9uIDEwLzAxLzE3IDE1OjE4LCAibW11c2ljIG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVy ZyINCjxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5IaSBBZGFtLA0KPg0KPk15IHN1Z2dlc3Rpb24g d291bGQgYmUgYWx0ZXJuYXRpdmUgIzIuIEJlY2F1c2UsIGlmIGFuIGVuZHBvaW50IHN1cHBvcnRz DQo+dGhlIGF0dHJpYnV0ZSBpdCBkb2Vzbqn2dCByZWFsbHkgbWF0dGVyIHdoYXQgdGhlIHBvcnQg dmFsdWUgaXMsIHNvIHRoZXJlIGlzDQo+bm8gbmVlZCB0byByZWplY3QgdGhlIG0tIGxpbmUuDQo+ DQo+UmVnYXJkcywNCj4NCj5DaHJpc3Rlcg0KPg0KPg0KPk9uIDI5LzEyLzE2IDIzOjE1LCAibW11 c2ljIG9uIGJlaGFsZiBvZiBBZGFtIFJvYWNoIg0KPjxtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBv biBiZWhhbGYgb2YgYWRhbUBub3N0cnVtLmNvbT4gd3JvdGU6DQo+DQo+PldlJ3ZlIHJlY2VudGx5 IGNvbWUgYWNyb3NzIGFuIGlzc3VlIHdpdGggdGhlIHdheSB0aGUgImJ1bmRsZS1vbmx5Ig0KPj5h dHRyaWJ1dGUgaXMgZGVzY3JpYmVkIGluIHRoZSBjdXJyZW50IGRvY3VtZW50LiBUaGUgY3VycmVu dCBsYW5ndWFnZQ0KPj5yZWdhcmRpbmcgcG9ydCBoYW5kbGluZyByZWFkczoNCj4+DQo+PiAgICBU aGUgdXNhZ2Ugb2YgdGhlICdidW5kbGUtb25seScgYXR0cmlidXRlIGlzIG9ubHkgZGVmaW5lZCBm b3IgYQ0KPj4gICAgYnVuZGxlZCAibT0iIGxpbmUgd2l0aCBhIHplcm8gcG9ydCB2YWx1ZSwgd2l0 aGluIGFuIG9mZmVyLiBPdGhlcg0KPj4gICAgdXNhZ2UgaXMgdW5zcGVjaWZpZWQuDQo+Pg0KPj5V c3VhbGx5LCB3aGVuIHdlIGhhdmUgdGhpcyBraW5kIG9mIGxhbmd1YWdlLCB3ZSBzdGlsbCBlbnN1 cmUgdGhhdA0KPj5iZWhhdmlvciBpcyB3ZWxsIGRlZmluZWQsIHRvIGhlbHAgYXZvaWQgdW5uZWNl c3NhcnkgaW50ZXJvcCBmYWlsdXJlcy4gSQ0KPj5zZWUgYSBjb3VwbGUgb2YgZGlmZmVyZW50IG9w dGlvbnMgaGVyZToNCj4+DQo+PiAxLiBSZW1vdmUgdGhlIGZpbmFsIHNlbnRlbmNlIGFuZCBhZGQg bGFuZ3VhZ2Ugc2F5aW5nIHRoYXQgY3JlYXRvcnMgb2YNCj4+ICAgIFNEUCBNVVNUIE5PVCBpbmNs dWRlIGEgImJ1bmRsZS1vbmx5IiBhdHRyaWJ1dGUgaW4gYW4gbS1zZWN0aW9uIHRoYXQNCj4+ICAg IGhhcyBhIG5vbi16ZXJvIHBvcnQsIGFuZCB0aGF0IHJlY2lwaWVudHMgb2Ygc3VjaCBTRFAge1NI T1VMRCxNVVNUfQ0KPj4gICAgcmVqZWN0IGl0OyBvcg0KPj4NCj4+IDIuIFJldGFpbiBsYW5ndWFn ZSBzYXlpbmcgdGhhdCBpbmNsdWRpbmcgYSAiYnVuZGxlLW9ubHkiIGF0dHJpYnV0ZSBpbiBhDQo+ PiAgICBub24temVybyBtLXNlY3Rpb24gaXMgdW5zcGVjaWZpZWQsIGJ1dCBhZGQgbm9ybWF0aXZl IGxhbmd1YWdlIGFsb25nDQo+PiAgICB0aGUgbGluZXMgb2Y6ICJpbXBsZW1lbnRhdGlvbnMgdGhh dCByZWNlaXZlIGFuIG0tc2VjdGlvbiB3aXRoIGENCj4+ICAgIG5vbi16ZXJvIHBvcnQgdGhhdCBh bHNvIGNvbnRhaW5zIGEgJ2J1bmRsZS1vbmx5JyBhdHRyaWJ1dGUgTVVTVA0KPj4gICAgaWdub3Jl IHRoZSB7YXR0cmlidXRlLHBvcnR9LiINCj4+DQo+PkkgZG9uJ3QgaGF2ZSBhIHByZWZlcmVuY2Ug YmV0d2VlbiB0aGVzZSBjaG9pY2VzLCBidXQgSSB0aGluayB3ZSBkbyBuZWVkDQo+PmNsYXJpdHku IFRvIGJlIGFic29sdXRlbHkgY2xlYXIsIHRoaXMgZmVlZGJhY2sgaXMgYmFzZWQgb24gYWN0dWFs DQo+PmltcGxlbWVudGF0aW9uIGludGVyb3AgZmFpbHVyZXMgaW4gdGhlIGZpZWxkLiBUaGlzIHBy b2JsZW0gaXMgbm90DQo+PnRoZW9yZXRpY2FsLg0KPj4NCj4+L2ENCj4+DQo+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pm1tdXNpYyBtYWlsaW5nIGxp c3QNCj4+bW11c2ljQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW11c2ljDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+bW11c2ljQGlldGYub3JnDQo+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg0K From nobody Wed Jul 12 05:58: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 5269812EC0F; Wed, 12 Jul 2017 05:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z60tKTJS48fa; Wed, 12 Jul 2017 05:58:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBE01318AA; Wed, 12 Jul 2017 05:58:05 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-4e-59661cdb6ad2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.49.07915.BDC16695; Wed, 12 Jul 2017 14:58:03 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Wed, 12 Jul 2017 14:58:03 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 Thread-Index: AQHS910XUh6Pan5Z40qWLa0ZRshaF6JMyUmAgAAPmYCAA2ZpAA== Date: Wed, 12 Jul 2017 12:58:03 +0000 Message-ID: References: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="utf-8" Content-ID: <549240967A866F4B8DEE19095C5320B2@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7lu5tmbRIg5az1hY77u5gs7j66jOL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZax91MBe8EikYvmN+8wN jHNEuhg5OSQETCROn5rP2MXIxSEkcIRR4tTlOywgCSGBxYwS907ndzFycLAJWEh0/9MGqRER 2MooseLpdjaQGmaBYIm9+7cxgtjCAm4Ss/cdZgexRQTcJW5cOs0CYTtJTDz+lBXEZhFQlVg+ /TpYnFfAWmLr9ddMEIuBdk05+QCsmVPARmJ263Qwm1FATOL7qTVMEMvEJW49mc8EcbWAxJI9 55khbFGJl4//sYIcKiqgJ/FuvydEWFGi/WkDI0iYWUBTYv0ufYgp1hIL2layQNiKElO6H7JD nCMocXLmE5YJjOKzkCybhdA9C0n3LCTds5B0L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGH8Ht/xW3cF4+Y3jIUYBDkYlHt7+L6mRQqyJZcWVuYcYJTiYlUR4fYXTIoV4UxIrq1KL 8uOLSnNSiw8xSnOwKInzOu67ECEkkJ5YkpqdmlqQWgSTZeLglGpgDIsW9Xi5XLiWZVveGzUB j4exLuZGE2d/lOyLSvXl3eAldjwufcdK3t8L9s773xDmfmlO1NxJzP8V8x3zNlSIzdx1ufPe DqtV1Q1PvCSWbeN7u/gX15+ZPzUncjEss010Pdk8afPUCWcmz1p3mC3vxJHLbhJZz6adtpu5 le3N7bmPTrF9vCX4TUiJpTgj0VCLuag4EQChOdG6uwIAAA== Archived-At: Subject: Re: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 12:58:12 -0000 SGkgUGF1bCwNCg0KQXJlIHlvdSBvayB3aXRoIG15IHJlcGx5Pw0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCg0KT24gMTAvMDcvMTcgMTI6MDIsICJDaHJpc3RlciBIb2xtYmVyZyIgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCndyb3RlOg0KDQo+UHVsbCByZXF1ZXN0OiBodHRw czovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtZHRscy1zZHAvcHVsbC8zMw0KPg0KPihJIGtlcHQg dGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA4LCBidXQgSSBmaXhlZCB0aGUgcmVmZXJlbmNlKQ0KPg0K PlJlZ2FyZHMsDQo+DQo+Q2hyaXN0ZXINCj4NCj4NCj5PbiAxMC8wNy8xNyAxMTowOCwgIkNocmlz dGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPndyb3RlOg0K Pg0KPj5IaSBQYXVsLA0KPj4NCj4+VGhhbmtzIGZvciB5b3VyIHJldmlldyEgUGxlYXNlIHNlZSBp bmxpbmUuDQo+Pg0KPj4NCj4+PkkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9y IHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4+PlJldmlldyBUZWFtIChHZW4tQVJUKSBy ZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+Pj5JRVNH IGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlr ZSBhbnkgb3RoZXINCj4+Pmxhc3QgY2FsbCBjb21tZW50cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24s IHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0KPj4+POKAi2h0dHA6Ly93aWtpLnRvb2xzLmlldGYub3Jn L2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPj4+DQo+Pj5Eb2N1bWVudDogZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHAtMjYNCj4+PlJldmlld2VyOiBQYXVsIEt5eml2YXQNCj4+PlJl dmlldyBEYXRlOiAyMDE3LTA3LTA3DQo+Pj5JRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA3LTI0DQo+ Pj5JRVNHIFRlbGVjaGF0IGRhdGU6IFRCRA0KPj4+DQo+Pj5TdW1tYXJ5Og0KPj4+DQo+Pj5UaGlz IGRyYWZ0IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgYSBmZXcg bml0cyB0aGF0DQo+Pj5zaG91bGQgYmUgZml4ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPj4+DQo+ Pj5Jc3N1ZXM6DQo+Pj4NCj4+Pk1ham9yOiAwDQo+Pj5NaW5vcjogMA0KPj4+Tml0czogIDQNCj4+ Pg0KPj4+KDEpIE5JVDoNCj4+Pg0KPj4+U2VjdGlvbiA1LjM6IHMvRXZlbnRob3VnaC9FdmVuIHRo b3VnaC8NCj4+DQo+PldpbGwgYmUgZml4ZWQuDQo+Pg0KPj4+KDIpIE5JVDoNCj4+Pg0KPj4+U2Vj dGlvbiA4OiBzL2FUTFMvYSBUTFMvDQo+Pg0KPj5XaWxsIGJlIGZpeGVkLg0KPj4NCj4+PigzKSBO SVQ6DQo+Pj4NCj4+PlNlY3Rpb24gODogV2hhdCBpcyB0aGUgcG9pbnQgb2YgaW5jbHVkaW5nIHRo ZSBleGFtcGxlPyBJIGRvbid0IHNlZSBob3cNCj4+Pml0IGFkZHMgYW55dGhpbmcuIFBlcmhhcHMg d29ya2VkIG91dCBPL0EgZXhhbXBsZXMgY29udHJhc3RpbmcgdGhlDQo+Pj5kaWZmZXJlbmNlcyBi ZXR3ZWVuIHRoZSBuZXcgYW5kIGV4aXN0aW5nIGNhc2VzIG1pZ2h0IGJlIG1hcmdpbmFsbHkNCj4+ PmhlbHBmdWwuIChCdXQgSU1PIG5vdCBlbm91Z2ggdG8gYm90aGVyIHdpdGguKQ0KPj4NCj4+VGhl IGlkZWEgd2FzIHRvIHRha2UgdGhlIGV4aXN0aW5nIGV4YW1wbGUgZnJvbSBSRkMgNDU3MiAoSSBu b3RlIHRoZQ0KPj5yZWZlcmVuY2UgaXMgd3Jvbmc6IHMvMzI2MS80NTcyKSwgYW5kIHNob3cgaG93 IGl0IGxvb2tzIHdpdGggdGhlIHRscy1pZA0KPj5hdHRyaWJ1dGUuDQo+Pg0KPj4NCj4+Pig0KSBO SVQ6DQo+Pj4NCj4+PlNlY3Rpb24gMTAuMy4yOiBzL1Rocm91Z291dC90aHJvdWdob3V0Lw0KPj4N Cj4+V2lsbCBiZSBmaXhlZC4NCj4+DQo+PlJlZ2FyZHMsDQo+Pg0KPj5DaHJpc3Rlcg0KPj4NCj4N Cg0K From nobody Wed Jul 12 12:31: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 7526F131766 for ; Wed, 12 Jul 2017 12:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hqG2-QkDgIIt for ; Wed, 12 Jul 2017 12:31:35 -0700 (PDT) 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 6119C13178C for ; Wed, 12 Jul 2017 12:31:35 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-11v.sys.comcast.net with ESMTP id VNLkdSLXTyXIHVNMEdS3tO; Wed, 12 Jul 2017 19:31:34 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-09v.sys.comcast.net with SMTP id VNMDdbr42h8eeVNMEdDLNU; Wed, 12 Jul 2017 19:31:34 +0000 To: Christer Holmberg , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" Cc: General Area Review Team , IETF MMUSIC WG References: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Wed, 12 Jul 2017 15:31:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfIHRKjoIsKPle0FgjpkzBAB4KbE/FoFeMmiNx1BShndpGBgk6OfJsedJ+sm5ukcRejYDeoCgnrc9yHpr+t6a1rZIdfOxh3+0ZBuv+OknRDUz/qKYoR8h ijVJI34ur78b5DOi9Tjl02aHbdUiIrDER91CRvgy0RkBCO1lmhNJxnRY99xrSl3K/ytYGCYxr24vGu/6y/xm0FBF3crt5n2C6uA03BZ02Z6kOzO4/+TDkQ15 U6+kSU1PLBx/BjXk5oD9FuGepWifgZ3G2wA9jCJPydFER9FR2x6MMfkOha54RPB0 Archived-At: Subject: Re: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:31:36 -0000 On 7/12/17 8:58 AM, Christer Holmberg wrote: > Hi Paul, > > Are you ok with my reply? Yes. Thanks, Paul > Regards, > > Christer > > > > On 10/07/17 12:02, "Christer Holmberg" > wrote: > >> Pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/33 >> >> (I kept the example in Section 8, but I fixed the reference) >> >> Regards, >> >> Christer >> >> >> On 10/07/17 11:08, "Christer Holmberg" >> wrote: >> >>> Hi Paul, >>> >>> Thanks for your review! Please see inline. >>> >>> >>>> 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 >>>> <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> >>>> Document: draft-ietf-mmusic-dtls-sdp-26 >>>> Reviewer: Paul Kyzivat >>>> Review Date: 2017-07-07 >>>> IETF LC End Date: 2017-07-24 >>>> IESG Telechat date: TBD >>>> >>>> Summary: >>>> >>>> This draft is basically ready for publication, but has a few nits that >>>> should be fixed before publication. >>>> >>>> Issues: >>>> >>>> Major: 0 >>>> Minor: 0 >>>> Nits: 4 >>>> >>>> (1) NIT: >>>> >>>> Section 5.3: s/Eventhough/Even though/ >>> >>> Will be fixed. >>> >>>> (2) NIT: >>>> >>>> Section 8: s/aTLS/a TLS/ >>> >>> Will be fixed. >>> >>>> (3) NIT: >>>> >>>> Section 8: What is the point of including the example? I don't see how >>>> it adds anything. Perhaps worked out O/A examples contrasting the >>>> differences between the new and existing cases might be marginally >>>> helpful. (But IMO not enough to bother with.) >>> >>> The idea was to take the existing example from RFC 4572 (I note the >>> reference is wrong: s/3261/4572), and show how it looks with the tls-id >>> attribute. >>> >>> >>>> (4) NIT: >>>> >>>> Section 10.3.2: s/Througout/throughout/ >>> >>> Will be fixed. >>> >>> Regards, >>> >>> Christer >>> >> > From nobody Wed Jul 12 12:39: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 AC98712EC17; Wed, 12 Jul 2017 12:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGTqV9ViUqxO; Wed, 12 Jul 2017 12:39:14 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBAF12EA74; Wed, 12 Jul 2017 12:39:13 -0700 (PDT) X-AuditID: c1b4fb2d-7ebff70000005faa-20-59667adf0bf8 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7A.B0.24490.FDA76695; Wed, 12 Jul 2017 21:39:11 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.98]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Wed, 12 Jul 2017 21:39:10 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 Thread-Index: AQHS910XUh6Pan5Z40qWLa0ZRshaF6JMyUmAgAAPmYCAA2ZpAIAAO2OAgAAjmYA= Date: Wed, 12 Jul 2017 19:39:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC6012F@ESESSMB109.ericsson.se> References: <23fb3891-1d34-2e9e-42ac-99df18c0d5ed@alum.mit.edu> 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+NgFmplkeLIzCtJLcpLzFFi42KZGbHdW/d+VVqkwdw7chY77u5gs7j66jOL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZSw98Jix4Ix0xflF+g2M H6S6GDk5JARMJF5M2cXaxcjFISRwhFHi3r55zBDOYkaJ6ZO+sXcxcnCwCVhIdP/TBomLCDQy SjRO388M0s0sECyxd/82RhBbWMBNYs3N32wgtoiAu8SNS6dZIGw/iYd/FrKD2CwCqhJPDrwB i/MK+Er8vfGUHWJZN5PEgrdTwIo4BRwkbt1ZDTaIUUBM4vupNUwQy8Qlbj2ZzwRxtoDEkj3n mSFsUYmXj/+xQthKEo1LnrCCHM0soCmxfpc+RKuixJTuh+wQewUlTs58wjKBUXQWkqmzEDpm IemYhaRjASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAyDm45bfuDsbVrx0PMQpwMCrx 8BYUpkUKsSaWFVfmHmKU4GBWEuFVLwMK8aYkVlalFuXHF5XmpBYfYpTmYFES53XYdyFCSCA9 sSQ1OzW1ILUIJsvEwSnVwNj2QWH9hO4XvC7zfJQcBRqcNoRd/8CrcVo6fPWsjULP/x4MWfjw 2+87M27evNXDOjnubcz1hnWzhJbs7Tmnf/r9Z4HGqT9r7DJ8YzJUvu7zO67lvZZ5djD/q3vt epGRK9o/zprGu9P0+pfrfPOsnk7/M7NJM/m+1PKMtVISu39es+i7cGc/t8MjJZbijERDLeai 4kQAC7GDNJgCAAA= Archived-At: Subject: Re: [MMUSIC] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2017 19:39:16 -0000 VGhhbmtzISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1 XSANClNlbnQ6IDEyIEp1bHkgMjAxNyAyMTozMg0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC5h bGxAaWV0Zi5vcmcNCkNjOiBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5v cmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEdlbi1B UlQgTGFzdCBDYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNg0KDQpP biA3LzEyLzE3IDg6NTggQU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBIaSBQYXVsLA0K PiANCj4gQXJlIHlvdSBvayB3aXRoIG15IHJlcGx5Pw0KDQpZZXMuDQoNCglUaGFua3MsDQoJUGF1 bA0KDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiBPbiAxMC8wNy8x NyAxMjowMiwgIkNocmlzdGVyIEhvbG1iZXJnIiANCj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NCj4gd3JvdGU6DQo+IA0KPj4gUHVsbCByZXF1ZXN0OiBodHRwczovL2dpdGh1Yi5j b20vY2RoNHUvZHJhZnQtZHRscy1zZHAvcHVsbC8zMw0KPj4NCj4+IChJIGtlcHQgdGhlIGV4YW1w bGUgaW4gU2VjdGlvbiA4LCBidXQgSSBmaXhlZCB0aGUgcmVmZXJlbmNlKQ0KPj4NCj4+IFJlZ2Fy ZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4gT24gMTAvMDcvMTcgMTE6MDgsICJDaHJp c3RlciBIb2xtYmVyZyIgDQo+PiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4g d3JvdGU6DQo+Pg0KPj4+IEhpIFBhdWwsDQo+Pj4NCj4+PiBUaGFua3MgZm9yIHlvdXIgcmV2aWV3 ISBQbGVhc2Ugc2VlIGlubGluZS4NCj4+Pg0KPj4+DQo+Pj4+IEkgYW0gdGhlIGFzc2lnbmVkIEdl bi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWEgDQo+Pj4+IFJl dmlldyBUZWFtIChHZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgDQo+Pj4+IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNlIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSANCj4+Pj4gYW55IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIA0KPj4+PiBGQVEgYXQg POKAi2h0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRm YXE+Lg0KPj4+Pg0KPj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjYN Cj4+Pj4gUmV2aWV3ZXI6IFBhdWwgS3l6aXZhdA0KPj4+PiBSZXZpZXcgRGF0ZTogMjAxNy0wNy0w Nw0KPj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA3LTI0DQo+Pj4+IElFU0cgVGVsZWNoYXQg ZGF0ZTogVEJEDQo+Pj4+DQo+Pj4+IFN1bW1hcnk6DQo+Pj4+DQo+Pj4+IFRoaXMgZHJhZnQgaXMg YmFzaWNhbGx5IHJlYWR5IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBhIGZldyBuaXRzIA0KPj4+ PiB0aGF0IHNob3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+Pj4+DQo+Pj4+IElz c3VlczoNCj4+Pj4NCj4+Pj4gTWFqb3I6IDANCj4+Pj4gTWlub3I6IDANCj4+Pj4gTml0czogIDQN Cj4+Pj4NCj4+Pj4gKDEpIE5JVDoNCj4+Pj4NCj4+Pj4gU2VjdGlvbiA1LjM6IHMvRXZlbnRob3Vn aC9FdmVuIHRob3VnaC8NCj4+Pg0KPj4+IFdpbGwgYmUgZml4ZWQuDQo+Pj4NCj4+Pj4gKDIpIE5J VDoNCj4+Pj4NCj4+Pj4gU2VjdGlvbiA4OiBzL2FUTFMvYSBUTFMvDQo+Pj4NCj4+PiBXaWxsIGJl IGZpeGVkLg0KPj4+DQo+Pj4+ICgzKSBOSVQ6DQo+Pj4+DQo+Pj4+IFNlY3Rpb24gODogV2hhdCBp cyB0aGUgcG9pbnQgb2YgaW5jbHVkaW5nIHRoZSBleGFtcGxlPyBJIGRvbid0IHNlZSANCj4+Pj4g aG93IGl0IGFkZHMgYW55dGhpbmcuIFBlcmhhcHMgd29ya2VkIG91dCBPL0EgZXhhbXBsZXMgY29u dHJhc3RpbmcgDQo+Pj4+IHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBuZXcgYW5kIGV4aXN0 aW5nIGNhc2VzIG1pZ2h0IGJlIA0KPj4+PiBtYXJnaW5hbGx5IGhlbHBmdWwuIChCdXQgSU1PIG5v dCBlbm91Z2ggdG8gYm90aGVyIHdpdGguKQ0KPj4+DQo+Pj4gVGhlIGlkZWEgd2FzIHRvIHRha2Ug dGhlIGV4aXN0aW5nIGV4YW1wbGUgZnJvbSBSRkMgNDU3MiAoSSBub3RlIHRoZSANCj4+PiByZWZl cmVuY2UgaXMgd3Jvbmc6IHMvMzI2MS80NTcyKSwgYW5kIHNob3cgaG93IGl0IGxvb2tzIHdpdGgg dGhlIA0KPj4+IHRscy1pZCBhdHRyaWJ1dGUuDQo+Pj4NCj4+Pg0KPj4+PiAoNCkgTklUOg0KPj4+ Pg0KPj4+PiBTZWN0aW9uIDEwLjMuMjogcy9UaHJvdWdvdXQvdGhyb3VnaG91dC8NCj4+Pg0KPj4+ IFdpbGwgYmUgZml4ZWQuDQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gQ2hyaXN0ZXINCj4+ Pg0KPj4NCj4gDQoNCg== From nobody Thu Jul 13 11:25: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 559CB12EB4A for ; Thu, 13 Jul 2017 11:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5-DBGDUPU7q for ; Thu, 13 Jul 2017 11:25:05 -0700 (PDT) Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com [173.203.187.122]) (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 5500A129B77 for ; Thu, 13 Jul 2017 11:25:05 -0700 (PDT) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0167A5AB5; Thu, 13 Jul 2017 14:24:56 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 88A0C5A04; Thu, 13 Jul 2017 14:24:56 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 13 Jul 2017 14:24:56 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Thu, 13 Jul 2017 12:24:55 -0600 Cc: Adam Roach , "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <129EFD55-0FB2-43A3-88C0-F759B5BED602@iii.ca> References: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com> To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2017 18:25:07 -0000 That works for me.=20 > On Jul 11, 2017, at 7:46 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 > It took a while, but here is my suggestion (based on alternative #2): >=20 > OLD TEXT: >=20 > "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." >=20 >=20 > NEW TEXT: >=20 > "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. If an implementation receives, within > an offer or answer, a bundled "m=3D=E2=80=9C line with a non-zero port = value >=20 > and an =E2=80=98bundle-only=E2=80=99 attribute associated with the = =E2=80=9Cm=3D=E2=80=9C line, the > implementation MUST ignore the attribute." >=20 > Regards, >=20 > Christer >=20 >=20 > On 10/01/17 15:18, "mmusic on behalf of Christer Holmberg" > > wrote: >=20 >> Hi Adam, >>=20 >> My suggestion would be alternative #2. Because, if an endpoint = supports >> the attribute it doesn=C2=B9t really matter what the port value is, = so there is >> no need to reject the m- line. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> On 29/12/16 23:15, "mmusic on behalf of Adam Roach" >> wrote: >>=20 >>> 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: >>>=20 >>> 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. >>>=20 >>> 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: >>>=20 >>> 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 >>>=20 >>> 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}." >>>=20 >>> 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. >>>=20 >>> /a >>>=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 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri Jul 14 14:06:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85220131A95 for ; Fri, 14 Jul 2017 14:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, 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 Nba1_pNN53KF for ; Fri, 14 Jul 2017 14:06:53 -0700 (PDT) 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 5F851131A92 for ; Fri, 14 Jul 2017 14:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=693; q=dns/txt; s=iport; t=1500066413; x=1501276013; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=ZoGw0X2hA95Z/C7ZqpS88vvx0OMv2ajkyUkQQE8tSNM=; b=ktY1iOBUS0taNEjlbGg/A2Z+5muU/rnx+6wL1s0jztiTtvTfZzYosDEa LUr7f9kxjFI91rfqxm0/qhPO0HfN3AMU0rj8hRP2ZZ3DD05hI2Z+cXOTP V65BjLQ++NxIDxdgF6OUrHaX9mA3++QxoXfyiMmGfnowlWL/7bsinL49d Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BABQAPMmlZ/4oNJK1eHAEBBAEBCgEBg?= =?us-ascii?q?1qhQ5YmghGJaUAXAQIBAQEBAQEBayiFQhV2AiYCXw0IAQGKHg2uAYImix8BAQE?= =?us-ascii?q?HAiaBC4Idg02CDAuKa4JhAQSfMZQUggyFT4NThwCVViABNj9LUiMVhVwcggMkh?= =?us-ascii?q?msEgjsBAQE?= X-IronPort-AV: E=Sophos;i="5.40,360,1496102400"; d="scan'208";a="455570129" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Jul 2017 21:06:52 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6EL6qVN025761 for ; Fri, 14 Jul 2017 21:06:52 GMT To: mmusic From: Flemming Andreasen Message-ID: <84037f13-fbe3-6345-36b0-9859dbf61d8b@cisco.com> Date: Fri, 14 Jul 2017 17:06:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] MMUSIC Meeting Canceled - WG draft authors still to meet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2017 21:06:54 -0000 Hi We have not received any agenda requests for MMUSIC in Prague, and a check with the primary WG draft authors did not yield any discussion topics either so we are hereby canceling the meeting. However, we still have several WG drafts that have been around for a long time and are making very slow progress. We will be asking the draft authors to meet with the chairs and our AD to see how we can help move these drafts forward. This meeting is planned from 10-11 AM during the originally scheduled MMUSIC session (i.e. Thursday, but in a different room), so WG draft authors are hereby asked to please reserve that time. Thanks -- Flemming & Bo (MMUSIC co-chairs) From nobody Sun Jul 16 03:16: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 8A1D512EBF9 for ; Sun, 16 Jul 2017 03:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUxaaBzdRl6W for ; Sun, 16 Jul 2017 03:16:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6849D126DC2 for ; Sun, 16 Jul 2017 03:16:32 -0700 (PDT) Received: from dhcp-890b.meeting.ietf.org (dhcp-890b.meeting.ietf.org [31.133.137.11]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6GAGQsf018711 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 16 Jul 2017 05:16:28 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <84037f13-fbe3-6345-36b0-9859dbf61d8b@cisco.com> Date: Sun, 16 Jul 2017 12:16:25 +0200 Cc: Flemming Andreasen Content-Transfer-Encoding: quoted-printable Message-Id: <21AA060C-099F-4BB8-893B-5600339DAD0A@nostrum.com> References: <84037f13-fbe3-6345-36b0-9859dbf61d8b@cisco.com> To: mmusic X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] MMUSIC Meeting Canceled - WG draft authors still to meet X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2017 10:16:33 -0000 > On Jul 14, 2017, at 11:06 PM, Flemming Andreasen = wrote: >=20 > Hi >=20 > We have not received any agenda requests for MMUSIC in Prague, and a = check with the primary WG draft authors did not yield any discussion = topics either so we are hereby canceling the meeting. >=20 > However, we still have several WG drafts that have been around for a = long time and are making very slow progress. We will be asking the draft = authors to meet with the chairs and our AD to see how we can help move = these drafts forward. This meeting is planned from 10-11 AM during the = originally scheduled MMUSIC session (i.e. Thursday, but in a different = room), so WG draft authors are hereby asked to please reserve that time. That meeting will be in the Paris room (Lobby Level (L)), also known as = the IESG breakout room. Draft editors: please confirm that you are available to join. Thanks! Ben. From nobody Tue Jul 18 06:43: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 874E0131B5C for ; Tue, 18 Jul 2017 06:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK5Jxt-U5MYk for ; Tue, 18 Jul 2017 06:42:59 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE0A13172B for ; Tue, 18 Jul 2017 06:42:50 -0700 (PDT) Received: from [2001:67c:1232:144:1127:c67f:1462:7833] (port=57822) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dXSlu-0008TB-Iu; Tue, 18 Jul 2017 14:42:46 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> Date: Tue, 18 Jul 2017 15:42:35 +0200 Cc: "mmusic (E-mail)" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2017 13:43:04 -0000 Hi Christer, As discussed - pull request submitted. Colin > On 9 Apr 2017, at 08:54, Christer Holmberg = wrote: >=20 > Hi Colin, >=20 > Thanks for your input! >=20 > Would it be possible for you to create a pull request with your = suggested changes? >=20 > BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin = Perkins > Sent: 07 April 2017 20:06 > To: mmusic (E-mail) > Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling >=20 > I have some comments on BUNDLE -37 - apologies that I wasn=E2=80=99t = able to participate fully in the mailing list discussion before the = meeting.=20 >=20 > The current text is generally reasonably clear, and is certainly = precisely written, but I do think it has some problems. Most of these = relate to the issue of whether RTP packets or RTP streams are being = processed. I think it=E2=80=99s important that this draft is written in = terms of how to associate RTP streams with m=3D lines, rather than how = to route and demultiplex RTP packets, since RTP packet routing and = demultiplexing is already specified by the various RTP specifications. = In particular, there are some places where the draft as written = conflates the two layers in ways that conflict with the RTP and RTCP = specifications, that I=E2=80=99ve tried to correct by more cleanly = separating the layers.=20 >=20 > I=E2=80=99ve tried to write my suggestions in a prescriptive manner, = keeping to the style of the existing text where possible. Hopefully the = result is clear and understandable. >=20 > Comments line below: >=20 >> 10.2. Associating RTP/RTCP Streams With Correct SDP Media = Description >>=20 >> NOTE: The text in this section is copied from Appendix B of JSEP. >> The community has not yet agreed on the text. >>=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 includes an SSRC field that is used to = associate >> the packet with the correct RTP stream. RTCP packets also use = SSRCs >> to identify which RTP streams the packet relates to. However, a = RTCP >> packet can contain multiple SSRC fields, in the course of providing >> feedback or reports on different RTP streams, and therefore can be >> associated with multiple such 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" >>=20 >>=20 >>=20 >> Holmberg, et al. Expires October 2, 2017 [Page = 20] >> Internet-Draft Bundled media March = 2017 >>=20 >>=20 >> 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 use 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 >> 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 >> 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 insert the = identification- >> tag associated with an "m=3D" line (provided by the remote peer) = into >> RTP and RTCP packets associated with a BUNDLE group. >>=20 >> When using this mechanism, the mapping from an SSRC to an >> identification-tag is carried in RTP header extensions or RTCP SDES >> packets, as specified in section 14. Since a compound RTCP packet >> can contain multiple RTCP SDES packets, and each RTCP SDES packet = can >> contain multiple chunks, a single RTCP packet can contain several >> SSRC to identification-tag mappings. The offerer and answerer >> maintain tables used for routing that are updated each time an RTP/ >> RTCP packet contains new information that affects how packets = should >> be routed. >=20 > The text above looks good. In particular, it correctly focusses on = associating RTP streams with m=3D lines, which is the correct level of = abstraction.=20 >=20 >> However, some implementations of may not include this = identification- >> tag in their RTP and RTCP traffic when using the BUNDLE mechanism, >> and instead use a payload type based mechanism for demuxing. In = this >=20 > The term =E2=80=9Cdemuxing=E2=80=9D is unclear. For precision, I = suggest changing =E2=80=9Cuse a payload type based mechanisms for = demuxing=E2=80=9D to =E2=80=9Cuse a payload type based mechanism to = associate RTP streams with SDP m=3D lines=E2=80=9D. >=20 >> situation, each "m=3D" line MUST use unique payload type values, in >> order for the payload type to be a reliable indicator of the = relevant >> "m=3D" line for the RTP stream. Note that when using payload type >> based demuxing, >=20 > Similarly, for precision, I suggest changing =E2=80=9Cwhen using = payload type based demuxing=E2=80=9D to =E2=80=9Cwhen using the payload = type to associate RTP streams with m=3D lines=E2=80=9D. >=20 >> an SSRC will be mapped to an =E2=80=9Cm=3D=E2=80=9C = line >=20 > Suggest changing to =E2=80=9Can RTP stream, identified by SSRC, will = be mapped=E2=80=A6=E2=80=9D to be clear what=E2=80=99s being done. >=20 >> by the first >> packet with that SSRC, and the mapping will not be changed even if >=20 > Suggest changing to =E2=80=9Cwhen the first RTP packet of that RTP = stream is received, and=E2=80=A6=E2=80=9D to be clear, since there could = be RTCP packets with the same SSRC. >=20 >> the same SSRC is received with a different payload type. In other >=20 > Suggest changing to =E2=80=9Cthe payload type used by that RTP stream = changes. In other=E2=80=9D to be precise. >=20 >> words, the SSRC cannot to "move" to a different "m=3D" line simply = by >> changing the payload type. >>=20 >> Holmberg, et al. Expires October 2, 2017 [Page = 21] >> Internet-Draft Bundled media March = 2017 >>=20 >>=20 >> Applications can implement RTP stacks in many different ways. The >> algorithm below details one way that demultiplexing can be >> accomplished, but is not meant to be prescriptive about exactly how >=20 > To be clear about what is being demultiplexed, I suggest changing = =E2=80=9Cone way that demultiplexing can be accomplished=E2=80=9D to = =E2=80=9Cone way that RTP streams can be associated with m=3D lines=E2=80=9D= . >=20 >> an RTP stack needs to be implemented. Applications MAY use any >> algorithm that achieves equivalent results to those described in = the >> algorithm below. >>=20 >> To prepare for demultiplexing RTP/RTCP packets to the correct "m=3D" >> line, the following steps MUST be followed for each BUNDLE group. >=20 > I suggest changing =E2=80=9C=E2=80=A6prepare for demultiplexing = RTP/RTCP packets to the correct=E2=80=A6=E2=80=9D to =E2=80=9C=E2=80=A6pre= pare to associate RTP streams with the correct=E2=80=A6=E2=80=9D. RTP = and RTCP packets are not demultiplexed to m=3D lines, they=E2=80=99re = demultiplexed into RTP streams, and then those RTP streams are = associated with m=3D lines. The distinction is important, in order to = implement RTCP correctly.=20 >=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 SSRC to "m=3D" line for each = "m=3D" >> line in this BUNDLE group and for each SSRC configured for >> receiving in that =E2=80=9Cm=3D" line. >=20 > The SSRC is a property of an RTP stream, so I suggest changing = =E2=80=9Cmapping incoming SSRC to=E2=80=9D to =E2=80=9Cmapping SSRCs of = incoming RTP streams to=E2=80=9D. >=20 >> Construct a table mapping outgoing SSRC to "m=3Dline" for each = "m=3D" >> line in this BUNDLE group and for each SSRC configured for = sending >> in that =E2=80=9Cm=3D" line. >=20 > Similarly, change =E2=80=9Cmapping outgoing SSRC=E2=80=9D to = =E2=80=9Cmapping the SSRC of each outgoing RTP stream=E2=80=9D >=20 >> Construct a table mapping payload type 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, as it cannot be used to uniquely >> identify a "m=3D" line. >>=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 >> 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. >=20 > The goal is not to route RTP packets to m=3D lines, but rather to = associate the corresponding RTP streams with m=3D lines. This keeps the = distinction between RTP and RTCP processing that has to happen = irrespective of the m=3D line, and the application level processing that = depends on the choice of m=3D line. I suggest changing this sentence to: = =E2=80=9CWhen an RTP packet is received, it MUST be delivered to the RTP = stream corresponding to its SSRC. That RTP stream MUST then be = associated with the correct m=3D line within a BUNDLE group, according = to the following steps.=E2=80=9D >=20 >> Note that the phrase 'deliver a packet to the "m=3D" line' means to >> further process the packet as would normally happen with RTP/RTCP, = if >> it were received on a transport associated with that "m=3D" line >> outside of a BUNDLE group (i.e., if the "m=3D" line were not = BUNDLEd), >> including dropping an RTP packet if the packet's PT does not match >> any PT in the =E2=80=9Cm=3D" line. >=20 > Dropping RTP packets with unknown payload type breaks RTCP. The RTP = packet must be processed by the RTP layer as normal, updating the = statistics that are maintained by RTCP. The payload is then discarded, = because there=E2=80=99s no decoder associated with the payload type. I = suggest removing this part of the paragraph entirely. >=20 >> If the packet has a MID, and that MID is not in the table = mapping >> MID to =E2=80=9Cm=3D" line, drop the packet and stop. >=20 > Dropping the RTP packet will break the RTCP reports. The RTP packet = has to be processed as normal, but the corresponding RTP stream is not = decoded if it=E2=80=99s not associated with an =E2=80=9Cm=3D=E2=80=9C = line (i.e., you drop the payload, not the RTP packet). I suggest = replacing the above with something like: >=20 > If the MID associated with the RTP stream is not in the table = mapping=20 > MID to =E2=80=9Cm=3D=E2=80=9C line, then the RTP stream is not = decoded and the payload > data is discarded. >=20 >> If the packet has a MID, and the packet's extended sequence = number >> is greater than that of the last MID update, as discussed in >> [RFC7941], Section 4.2.6, update the incoming SSRC mapping table >> to include an entry that maps the packet's SSRC to the "m=3D" = line >> for that MID. >=20 > There are two things that need to be done here: update the MID = associated with the RTP stream to match that in the newly received RTP = packet, and update the mapping table. I suggest changing =E2=80=9Cupdate = the incoming SSRC mapping table to include an entry that maps the = packet=E2=80=99s SSRC to the =E2=80=9Cm=3D=E2=80=9C line for that MID=E2=80= =9D to =E2=80=9Cupdate the MID associated with the RTP stream to match = the MID carried in the RTP packet, then update the mapping tables to = include an entry that maps the SSRC of that RTP stream to the =E2=80=9Cm=3D= =E2=80=9C line for that MID=E2=80=9D. >=20 >> If the packet's SSRC is in the incoming SSRC mapping table, = check >> that the packet's PT matches a PT included on the associated = "m=3D" >> line. If so, route the packet to that associated "m=3D" line = and >> stop; otherwise drop the packet and stop. >=20 > Dropping the packet breaks RTCP. The RTP packet is processed as = normal, but the corresponding RTP stream is not decoded if it=E2=80=99s = not associated with an =E2=80=9Cm=3D=E2=80=9C line. I suggest replacing = the above with: >=20 > If the SSRC of the RTP stream is in the incoming SSRC mapping table,=20= > check that the payload type used by the RTP stream matches a payload > type included on the matching =E2=80=9Cm=3D=E2=80=9C line. If so, = associate the RTP > stream with that =E2=80=9Cm=3D=E2=80=9C line. Otherwise, the RTP = stream is not decoded > and the payload data is discarded. >=20 >> If the packet's payload type is in the payload type table, = update >> the the incoming SSRC mapping table to include an entry that = maps >> the packet's SSRC to the "m=3D" line for that payload type. In >> addition, route the packet to the associated =E2=80=9Cm=3D" line = and stop. >=20 > RTP packets correspond to RTP streams, and those RTP streams are = associated with m=3D lines. Suggest changing to: >=20 > If the payload type used by the RTP stream is in the payload type > table, update the incoming SSRC mapping table to include an entry > that maps the RTP stream=E2=80=99s SSRC to the =E2=80=9Cm=3D=E2=80=9C = line for that payload > type. Associate the RTP stream with the corresponding =E2=80=9Cm=3D=E2= =80=9C line. >=20 >> Otherwise, drop the packet. >=20 > The packet cannot be discarded without breaking RTCP. I suggest = replacing the above with: >=20 > Otherwise, mark the RTP stream as not for decoding and discard the=20= > payload.=20 >=20 >> For each RTCP packet received (including each RTCP packet that is >> part of a compound RTCP packet), the packet MUST be routed to the >> =E2=80=9Cm=3D=E2=80=9C line for the RTP streams it contains = information about. This >> routing is type-dependent, as each kind of RTCP packet has its own >> mechanism for associating it with the relevant RTP streams. >=20 > The first sentence might be clearer written =E2=80=9CFor each RTCP = packet received (including each RTCP packet that is part of a compound = RTCP packet), the packet is processed as usual by the RTP layer, then is = passed to the =E2=80=9Cm=3D=E2=80=9C lines corresponding to the RTP = streams it contains information about for further processing.=E2=80=9D >=20 >> Packets for which no appropriate "m=3D" line can be identified = (i.e., >> for unknown RTP streams) are not relevant in the context of this >> algorithm and MAY be dropped. This situation may occur with = certain >> multiparty RTP topologies. >=20 > These packets can=E2=80=99t be dropped. They setup state at the RTP = layer that might become relevant when further RTP/RTCP packets are = received (RTCP packets can round-robin SDES items, such as the MID, in = some cases, so these can potentially be important). I suggest changing = this to: >=20 > RTCP packets for which no appropriate =E2=80=9Cm=3D=E2=80=9C line = can be identified > MUST be processed as usual by the RTP layer, updating the metadata > associated with the corresponding RTP streams, but are not passed > to any =E2=80=9Cm=3D=E2=80=9C line. This situation can occur with = certain multiparty=20 > RTP topologies, or when RTCP packets are sent containing a subset=20 > of the SDES information. >=20 >> Rules for handling the various types of RTCP packets are explained >> below. >=20 > Perhaps change to =E2=80=9CRules for additional processing of the = various=E2=80=A6=E2=80=9D, to make it clear that this doesn=E2=80=99t = replace the usual RTCP processing. >=20 >> If the packet is of type SDES, for each chunk in the packet = whose >=20 > "If the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> SSRC is found in the incoming SSRC table, deliver a copy of the >> packet to the "m=3D" line associated with that SSRC. In = addition, >=20 > =E2=80=9Ca copy of the SDES packet=E2=80=9D presumably, since = otherwise it=E2=80=99s ambiguous if the entire compound RTCP packet is = delivered or just the SDES packet. >=20 >> for any SDES MID items contained in these chunks, if the MID is >> found in the table mapping MID to "m=3D" line, update the = incoming >> SSRC table to include an entry that maps the chunk=E2=80=99s = SSRC to the >=20 > =E2=80=9C=E2=80=A6maps the RTP stream associated with the chunk=E2=80=99= s SSRC to=E2=80=A6=E2=80=9D >=20 >> "m=3D" line associated with that MID, unless the packet is older >> than the packet that most recently updated the mapping for this >> SSRC, as discussed in [RFC7941], Section 4.2.6. >>=20 >> Note that if an SDES packet is received as part of a compound = RTCP >> packet, the SSRC to "m=3D" line mapping may not exist until the = SDES >> packet is handled (e.g., in the case where RTCP for a source is >> received before any RTP packets). Therefore, when processing a >> compound packet, any contained SDES packet MUST be handled = first. >=20 > It might be worth referencing RFC 3550 section 6.1, which says: >=20 > Each individual RTCP packet in the compound packet may be processed > independently with no requirements upon the order or combination of > packets. =20 >=20 > as justification for this. >=20 >> Holmberg, et al. Expires October 2, 2017 [Page = 23] >> Internet-Draft Bundled media March = 2017 >>=20 >>=20 >> If the packet is of type BYE, it indicates that the RTP streams >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> referenced in the packet are ending. Therefore, for each SSRC >> indicated in the packet that is found in the incoming SSRC = table, >=20 > =E2=80=9C=E2=80=A6in the BYE packet=E2=80=A6=E2=80=9D >=20 >> first deliver a copy of the packet to the =E2=80=9Cm=3D" line = associated >=20 > =E2=80=9C=E2=80=A6a copy of the BYE packet=E2=80=A6=E2=80=9D >=20 >> with that SSRC, but then remove the entry for that SSRC from the >> incoming SSRC table after an appropriate delay to account for >> "straggler packets", as specified in [RFC3550], Section 6.2.1. >>=20 >> If the packet is of type SR or RR, for each report block in the >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> report whose "SSRC of source" is found in the outgoing SSRC = table, >> deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line = associated with >=20 > =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe SR or RR packet=E2=80=9D= ? To avoid confusion when compound RTCP packets are used, I suggest the = latter phrasing here, and in the later sections. >=20 >> that SSRC. In addition, if the packet is of type SR, and the >> sender SSRC for the packet is found in the incoming SSRC table, >> deliver a copy of the packet to the =E2=80=9Cm=3D" line = associated with that >=20 > =E2=80=9Ca copy of the SR packet=E2=80=9D? >=20 >> SSRC. >>=20 >> If the implementation supports RTCP XR and the packet is of type >> XR, as defined in [RFC3611], for each report block in the report >> whose "SSRC of source" is is found in the outgoing SSRC table, >> deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line = associated with >=20 > =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe XR packet=E2=80=9D? >=20 >> that SSRC. In addition, if the sender SSRC for the packet is >> found in the incoming SSRC table, deliver a copy of the packet = to >=20 > =E2=80=9Cthe packet=E2=80=9D -> =E2=80=9Cthe RTCP packet=E2=80=9D or = =E2=80=9Cthe XR packet=E2=80=9D? >=20 >> the "m=3D" line associated with that SSRC. >>=20 >> If the packet is a feedback message of type RTPFB or PSFB, as >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> defined in [RFC4585], it will contain a media source SSRC, and >> this SSRC is used for routing certain subtypes of feedback >> messages. However, several subtypes of PSFB messages include >> target SSRC(s) in a section called Feedback Control Information >> (FCI). For these messages, the target SSRC(s) are used for >> routing. >>=20 >> If the packet is a feedback message that does not include target >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> SSRCs in its FCI section, and the media source SSRC is found in >> the outgoing SSRC table, deliver the packet to the =E2=80=9Cm=3D" = line >=20 > Which packet?=20 >=20 >> associated with that SSRC. RTPFB and PSFB types that are = handled >> in this way include: >>=20 >> Generic NACK: [RFC4585] (PT=3DRTPFB, FMT=3D1). >>=20 >> Picture Loss Indication (PLI): [RFC4585] (PT=3DPSFB, FMT=3D1). >>=20 >> Slice Loss Indication (SLI): [RFC4585] (PT=3DPSFB, FMT=3D2). >>=20 >> Reference Picture Selection Indication (RPSI): [RFC4585] >> (PT=3DPSFB, FMT=3D3). >>=20 >>=20 >>=20 >>=20 >>=20 >> Holmberg, et al. Expires October 2, 2017 [Page = 24] >> Internet-Draft Bundled media March = 2017 >>=20 >>=20 >> If the packet is a feedback message that does include target >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> SSRC(s) in its FCI section, it can either be a request or a >> notification. Requests reference a RTP stream that is being = sent >> by the message recipient, whereas notifications are responses to >> an earlier request, and therefore reference a RTP stream that is >> being received by the message recipient. >>=20 >> If the packet is a feedback request that includes target = SSRC(s), >=20 > =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >=20 >> for each target SSRC that is found in the outgoing SSRC table, >> deliver a copy of the RTCP packet to the "m=3D" line associated = with >> that SSRC. PSFB types that are handled in this way include: >>=20 >> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>=20 >> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, >> FMT=3D5). >>=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 >> If the packet is a feedback notification that include target >> SSRC(s), for each target SSRC that is found in the incoming SSRC >> table, deliver a copy of the RTCP packet to the "m=3D" line >> associated with that SSRC. PSFB types that are handled in this >=20 > =E2=80=9Cdeliver a copy of the RTCP packet to the =E2=80=9Cm=3D=E2=80=9C= line associated with the RTP stream with matching SSRC=E2=80=9D >=20 >> way include: >>=20 >> Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] >> (PT=3DPSFB, FMT=3D6). This message is a notification in = response >> to a prior TSTR. >>=20 >> If the packet is of type APP, the only routing information >> included is the source of the packet, and therefore the packet >> could be related to any existing "m=3D" line. Accordingly, = deliver >> a copy of the packet to each =E2=80=9Cm=3D" line. >=20 > Are APP packets exposed in the WebRTC APIs? Given that we have the = data channel, it=E2=80=99s not clear that we want to support arbitrary = application information passing via RTCP. It might be better to say that = APP packets are processed in an application specific manner, and if the = application doesn=E2=80=99t understand them, they=E2=80=99re not passed = to any m=3D line? >=20 > Finally, I note that this section of the draft doesn=E2=80=99t mention = the CSRC list anywhere, but should probably do so. As written, RTP = packets with a CSRC list will be delivered to the RTP stream matching = their SSRC in the usual way, then passed up to the m=3D line associated = with that RTP stream. That may well be sufficient, but if so it=E2=80=99s = likely useful to say that, to make the intent clear. >=20 > Colin >=20 >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > 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 Colin Perkins https://csperkins.org/ From nobody Wed Jul 19 00:37: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 3421A12ECC3 for ; Wed, 19 Jul 2017 00:37:12 -0700 (PDT) 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 GNVU7dtAzrLU for ; Wed, 19 Jul 2017 00:37:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F93127337 for ; Wed, 19 Jul 2017 00:37:08 -0700 (PDT) X-AuditID: c1b4fb30-aeec49c000001664-2e-596f0c227bd2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.EF.05732.22C0F695; Wed, 19 Jul 2017 09:37:06 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 09:36:54 +0200 From: Christer Holmberg To: Colin Perkins CC: "mmusic (E-mail)" Thread-Topic: [MMUSIC] Comments on BUNDLE -37 - RTP handling Thread-Index: AQHSr8FdWx51Nry6SECZI3BgadjWMKG8rSlggJ1pOYCAAU00gA== Date: Wed, 19 Jul 2017 07:36:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC8B423@ESESSMB109.ericsson.se> References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7uq4ST36kwc/bWhbLX55gtJi6/DGL A5PHtPv32TyWLPnJFMAUxWWTkpqTWZZapG+XwJVx7XoTW8GDbqaKtt6lrA2MH1qYuhg5OSQE TCR+/vkMZHNxCAkcYZSY/f04K4SzmFHi78enLF2MHBxsAhYS3f+0QRpEBFQldhz/xwhiMwuo S/T8bmEGsYUFrCW6731ghaixkWh6cRrKdpLYs/URmM0C1Hul8zlYL6+Ar0TX34UsELt2M0p8 nTWBBSTBKeAocbrjHdhQRgExie+n1jBBLBOXuPVkPtTVAhJL9pxnhrBFJV4+/scKYStJNC55 wgpyM7OApsT6XfoQrYoSU7ofskPsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uT ctONjPRSizKTi4vz8/TyUks2MQIj5eCW3wY7GF8+dzzEKMDBqMTDW/IlL1KINbGsuDL3EKME B7OSCO8O9vxIId6UxMqq1KL8+KLSnNTiQ4zSHCxK4ryO+y5ECAmkJ5akZqemFqQWwWSZODil GhhLNZTT8lfPn5nyUHzF9PPXf7hO/sTP4lASKVWSfF/X6+bOw0E633RObd3TOKNcrDdr9dGX 72t3C/eHnHgZ8PJpQVJFoUX7seK6yTtdjwY/nMqqO++34IXsojcODg8/6G3m+chhsVzK7dax JhfNbKkbn7QbpI8tT8kuYOPKtogSir34f3OQX6MSS3FGoqEWc1FxIgDSK9vrkAIAAA== Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 07:37:12 -0000 SGksDQoNClRoYW5rcyBDb2xpbiENCg0KSSBlbmNvdXJhZ2UgdGhvc2Ugd2hvIGhhdmUgYmVlbiBp bnZvbHZlZCBpbiB0aGUgUlRQLXRvLW0tbGluZS1tYXBwaW5nIGRpc2N1c3Npb24gdG8gdGFrZSBh IGxvb2sgYXQgdGhpcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9y Z10gDQpTZW50OiAxOCBKdWx5IDIwMTcgMTU6NDMNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KQ2M6IG1tdXNpYyAoRS1tYWlsKSA8bW11c2lj QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtNTVVTSUNdIENvbW1lbnRzIG9uIEJVTkRMRSAtMzcg LSBSVFAgaGFuZGxpbmcNCg0KSGkgQ2hyaXN0ZXIsDQoNCkFzIGRpc2N1c3NlZCAtIHB1bGwgcmVx dWVzdCBzdWJtaXR0ZWQuDQpDb2xpbg0KDQoNCg0KPiBPbiA5IEFwciAyMDE3LCBhdCAwODo1NCwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQo+IA0KPiBIaSBDb2xpbiwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBpbnB1dCENCj4gDQo+IFdv dWxkIGl0IGJlIHBvc3NpYmxlIGZvciB5b3UgdG8gY3JlYXRlIGEgcHVsbCByZXF1ZXN0IHdpdGgg eW91ciBzdWdnZXN0ZWQgY2hhbmdlcz8NCj4gDQo+IEJVTkRMRSBjYW4gYmUgZm91bmQgYXQ6IGh0 dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlDQo+IA0KPiBSZWdhcmRzLA0K PiANCj4gQ2hyaXN0ZXINCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IG1tdXNpYyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ29s aW4gUGVya2lucw0KPiBTZW50OiAwNyBBcHJpbCAyMDE3IDIwOjA2DQo+IFRvOiBtbXVzaWMgKEUt bWFpbCkgPG1tdXNpY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogW01NVVNJQ10gQ29tbWVudHMgb24g QlVORExFIC0zNyAtIFJUUCBoYW5kbGluZw0KPiANCj4gSSBoYXZlIHNvbWUgY29tbWVudHMgb24g QlVORExFIC0zNyAtIGFwb2xvZ2llcyB0aGF0IEkgd2FzbuKAmXQgYWJsZSB0byBwYXJ0aWNpcGF0 ZSBmdWxseSBpbiB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gYmVmb3JlIHRoZSBtZWV0aW5n LiANCj4gDQo+IFRoZSBjdXJyZW50IHRleHQgaXMgZ2VuZXJhbGx5IHJlYXNvbmFibHkgY2xlYXIs IGFuZCBpcyBjZXJ0YWlubHkgcHJlY2lzZWx5IHdyaXR0ZW4sIGJ1dCBJIGRvIHRoaW5rIGl0IGhh cyBzb21lIHByb2JsZW1zLiBNb3N0IG9mIHRoZXNlIHJlbGF0ZSB0byB0aGUgaXNzdWUgb2Ygd2hl dGhlciBSVFAgcGFja2V0cyBvciBSVFAgc3RyZWFtcyBhcmUgYmVpbmcgcHJvY2Vzc2VkLiBJIHRo aW5rIGl04oCZcyBpbXBvcnRhbnQgdGhhdCB0aGlzIGRyYWZ0IGlzIHdyaXR0ZW4gaW4gdGVybXMg b2YgaG93IHRvIGFzc29jaWF0ZSBSVFAgc3RyZWFtcyB3aXRoIG09IGxpbmVzLCByYXRoZXIgdGhh biBob3cgdG8gcm91dGUgYW5kIGRlbXVsdGlwbGV4IFJUUCBwYWNrZXRzLCBzaW5jZSBSVFAgcGFj a2V0IHJvdXRpbmcgYW5kIGRlbXVsdGlwbGV4aW5nIGlzIGFscmVhZHkgc3BlY2lmaWVkIGJ5IHRo ZSB2YXJpb3VzIFJUUCBzcGVjaWZpY2F0aW9ucy4gSW4gcGFydGljdWxhciwgdGhlcmUgYXJlIHNv bWUgcGxhY2VzIHdoZXJlIHRoZSBkcmFmdCBhcyB3cml0dGVuIGNvbmZsYXRlcyB0aGUgdHdvIGxh eWVycyBpbiB3YXlzIHRoYXQgY29uZmxpY3Qgd2l0aCB0aGUgUlRQIGFuZCBSVENQIHNwZWNpZmlj YXRpb25zLCB0aGF0IEnigJl2ZSB0cmllZCB0byBjb3JyZWN0IGJ5IG1vcmUgY2xlYW5seSBzZXBh cmF0aW5nIHRoZSBsYXllcnMuIA0KPiANCj4gSeKAmXZlIHRyaWVkIHRvIHdyaXRlIG15IHN1Z2dl c3Rpb25zIGluIGEgcHJlc2NyaXB0aXZlIG1hbm5lciwga2VlcGluZyB0byB0aGUgc3R5bGUgb2Yg dGhlIGV4aXN0aW5nIHRleHQgd2hlcmUgcG9zc2libGUuIEhvcGVmdWxseSB0aGUgcmVzdWx0IGlz IGNsZWFyIGFuZCB1bmRlcnN0YW5kYWJsZS4NCj4gDQo+IENvbW1lbnRzIGxpbmUgYmVsb3c6DQo+ IA0KPj4gMTAuMi4gIEFzc29jaWF0aW5nIFJUUC9SVENQIFN0cmVhbXMgV2l0aCBDb3JyZWN0IFNE UCBNZWRpYSBEZXNjcmlwdGlvbg0KPj4gDQo+PiAgIE5PVEU6IFRoZSB0ZXh0IGluIHRoaXMgc2Vj dGlvbiBpcyBjb3BpZWQgZnJvbSBBcHBlbmRpeCBCIG9mIEpTRVAuDQo+PiAgIFRoZSBjb21tdW5p dHkgaGFzIG5vdCB5ZXQgYWdyZWVkIG9uIHRoZSB0ZXh0Lg0KPj4gDQo+PiAgIEFzIGRlc2NyaWJl ZCBpbiBbUkZDMzU1MF0sIFJUUCBwYWNrZXRzIGFyZSBhc3NvY2lhdGVkIHdpdGggUlRQDQo+PiAg IHN0cmVhbXMgW1JGQzc2NTZdLiAgRWFjaCBSVFAgc3RyZWFtIGlzIGlkZW50aWZpZWQgYnkgYW4g U1NSQyB2YWx1ZSwNCj4+ICAgYW5kIGVhY2ggUlRQIHBhY2tldCBpbmNsdWRlcyBhbiBTU1JDIGZp ZWxkIHRoYXQgaXMgdXNlZCB0byBhc3NvY2lhdGUNCj4+ICAgdGhlIHBhY2tldCB3aXRoIHRoZSBj b3JyZWN0IFJUUCBzdHJlYW0uICBSVENQIHBhY2tldHMgYWxzbyB1c2UgU1NSQ3MNCj4+ICAgdG8g aWRlbnRpZnkgd2hpY2ggUlRQIHN0cmVhbXMgdGhlIHBhY2tldCByZWxhdGVzIHRvLiAgSG93ZXZl ciwgYSBSVENQDQo+PiAgIHBhY2tldCBjYW4gY29udGFpbiBtdWx0aXBsZSBTU1JDIGZpZWxkcywg aW4gdGhlIGNvdXJzZSBvZiBwcm92aWRpbmcNCj4+ICAgZmVlZGJhY2sgb3IgcmVwb3J0cyBvbiBk aWZmZXJlbnQgUlRQIHN0cmVhbXMsIGFuZCB0aGVyZWZvcmUgY2FuIGJlDQo+PiAgIGFzc29jaWF0 ZWQgd2l0aCBtdWx0aXBsZSBzdWNoIHN0cmVhbXMuDQo+PiANCj4+ICAgSW4gb3JkZXIgdG8gYmUg YWJsZSB0byBwcm9jZXNzIHJlY2VpdmVkIFJUUC9SVENQIHBhY2tldHMgY29ycmVjdGx5LA0KPj4g ICBpdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGFzc29jaWF0ZSBhbiBSVFAgc3RyZWFtIHdpdGggdGhl IGNvcnJlY3QgIm09Ig0KPj4gDQo+PiANCj4+IA0KPj4gSG9sbWJlcmcsIGV0IGFsLiAgICAgICAg IEV4cGlyZXMgT2N0b2JlciAyLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQo+PiBJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICBCdW5kbGVkIG1lZGlhICAgICAgICAgICAgICAgICAg IE1hcmNoIDIwMTcNCj4+IA0KPj4gDQo+PiAgIGxpbmUsIGFzIHRoZSAibT0iIGxpbmUgYW5kIFNE UCBhdHRyaWJ1dGVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09Ig0KPj4gICBsaW5lIGNvbnRhaW4g aW5mb3JtYXRpb24gbmVlZGVkIHRvIHByb2Nlc3MgdGhlIHBhY2tldHMuDQo+PiANCj4+ICAgQXMg YWxsIFJUUCBzdHJlYW1zIGFzc29jaWF0ZWQgd2l0aCBhIEJVTkRMRSBncm91cCB1c2UgdGhlIHNh bWUNCj4+ICAgYWRkcmVzczpwb3J0IGNvbWJpbmF0aW9uIGZvciBzZW5kaW5nIGFuZCByZWNlaXZp bmcgUlRQL1JUQ1AgcGFja2V0cywNCj4+ICAgdGhlIGxvY2FsIGFkZHJlc3M6cG9ydCBjb21iaW5h dGlvbiBjYW5ub3QgYmUgdXNlZCB0byBhc3NvY2lhdGUgYW4gUlRQDQo+PiAgIHN0cmVhbSB3aXRo IHRoZSBjb3JyZWN0ICJtPSIgbGluZS4gIEluIGFkZGl0aW9uLCBtdWx0aXBsZSBSVFAgc3RyZWFt cw0KPj4gICBtaWdodCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIHNhbWUgIm09IiBsaW5lLg0KPj4g DQo+PiAgIEFuIG9mZmVyZXIgYW5kIGFuc3dlcmVyIGNhbiBpbmZvcm0gZWFjaCBvdGhlciB3aGlj aCBTU1JDIHZhbHVlcyB0aGV5DQo+PiAgIHdpbGwgdXNlIGZvciBhbiBSVFAgc3RyZWFtIGJ5IHVz aW5nIHRoZSBTRFAgJ3NzcmMnIGF0dHJpYnV0ZQ0KPj4gICBbUkZDNTU3Nl0uICBIb3dldmVyLCBh biBvZmZlcmVyIHdpbGwgbm90IGtub3cgd2hpY2ggU1NSQyB2YWx1ZXMgdGhlDQo+PiAgIGFuc3dl cmVyIHdpbGwgdXNlIHVudGlsIHRoZSBvZmZlcmVyIGhhcyByZWNlaXZlZCB0aGUgYW5zd2VyIHBy b3ZpZGluZw0KPj4gICB0aGF0IGluZm9ybWF0aW9uLiAgRHVlIHRvIHRoaXMsIGJlZm9yZSB0aGUg b2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlDQo+PiAgIGFuc3dlciwgdGhlIG9mZmVyZXIgd2lsbCBu b3QgYmUgYWJsZSB0byBhc3NvY2lhdGUgYW4gUlRQIHN0cmVhbSB3aXRoDQo+PiAgIHRoZSBjb3Jy ZWN0ICJtPSIgbGluZSB1c2luZyB0aGUgU1NSQyB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIFJU UA0KPj4gICBzdHJlYW0uICBJbiBhZGRpdGlvbiwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIG1h eSBzdGFydCB1c2luZyBuZXcNCj4+ICAgU1NSQyB2YWx1ZXMgbWlkLXNlc3Npb24sIHdpdGhvdXQg aW5mb3JtaW5nIGVhY2ggb3RoZXIgdXNpbmcgdGhlIFNEUA0KPj4gICAnc3NyYycgYXR0cmlidXRl Lg0KPj4gDQo+PiAgIEluIG9yZGVyIGZvciBhbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciB0byBhbHdh eXMgYmUgYWJsZSB0byBhc3NvY2lhdGUNCj4+ICAgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBjb3Jy ZWN0ICJtPSIgbGluZSwgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyDQo+PiAgIHVzaW5nIHRoZSBC VU5ETEUgZXh0ZW5zaW9uIE1VU1Qgc3VwcG9ydCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4NCj4+ ICAgc2VjdGlvbiAxNCwgd2hlcmUgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIGluc2VydCB0aGUg aWRlbnRpZmljYXRpb24tDQo+PiAgIHRhZyBhc3NvY2lhdGVkIHdpdGggYW4gIm09IiBsaW5lIChw cm92aWRlZCBieSB0aGUgcmVtb3RlIHBlZXIpIGludG8NCj4+ICAgUlRQIGFuZCBSVENQIHBhY2tl dHMgYXNzb2NpYXRlZCB3aXRoIGEgQlVORExFIGdyb3VwLg0KPj4gDQo+PiAgIFdoZW4gdXNpbmcg dGhpcyBtZWNoYW5pc20sIHRoZSBtYXBwaW5nIGZyb20gYW4gU1NSQyB0byBhbg0KPj4gICBpZGVu dGlmaWNhdGlvbi10YWcgaXMgY2FycmllZCBpbiBSVFAgaGVhZGVyIGV4dGVuc2lvbnMgb3IgUlRD UCBTREVTDQo+PiAgIHBhY2tldHMsIGFzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDE0LiAgU2luY2Ug YSBjb21wb3VuZCBSVENQIHBhY2tldA0KPj4gICBjYW4gY29udGFpbiBtdWx0aXBsZSBSVENQIFNE RVMgcGFja2V0cywgYW5kIGVhY2ggUlRDUCBTREVTIHBhY2tldCBjYW4NCj4+ICAgY29udGFpbiBt dWx0aXBsZSBjaHVua3MsIGEgc2luZ2xlIFJUQ1AgcGFja2V0IGNhbiBjb250YWluIHNldmVyYWwN Cj4+ICAgU1NSQyB0byBpZGVudGlmaWNhdGlvbi10YWcgbWFwcGluZ3MuICBUaGUgb2ZmZXJlciBh bmQgYW5zd2VyZXINCj4+ICAgbWFpbnRhaW4gdGFibGVzIHVzZWQgZm9yIHJvdXRpbmcgdGhhdCBh cmUgdXBkYXRlZCBlYWNoIHRpbWUgYW4gUlRQLw0KPj4gICBSVENQIHBhY2tldCBjb250YWlucyBu ZXcgaW5mb3JtYXRpb24gdGhhdCBhZmZlY3RzIGhvdyBwYWNrZXRzIHNob3VsZA0KPj4gICBiZSBy b3V0ZWQuDQo+IA0KPiBUaGUgdGV4dCBhYm92ZSBsb29rcyBnb29kLiBJbiBwYXJ0aWN1bGFyLCBp dCBjb3JyZWN0bHkgZm9jdXNzZXMgb24gYXNzb2NpYXRpbmcgUlRQIHN0cmVhbXMgd2l0aCBtPSBs aW5lcywgd2hpY2ggaXMgdGhlIGNvcnJlY3QgbGV2ZWwgb2YgYWJzdHJhY3Rpb24uIA0KPiANCj4+ ICAgSG93ZXZlciwgc29tZSBpbXBsZW1lbnRhdGlvbnMgb2YgbWF5IG5vdCBpbmNsdWRlIHRoaXMg aWRlbnRpZmljYXRpb24tDQo+PiAgIHRhZyBpbiB0aGVpciBSVFAgYW5kIFJUQ1AgdHJhZmZpYyB3 aGVuIHVzaW5nIHRoZSBCVU5ETEUgbWVjaGFuaXNtLA0KPj4gICBhbmQgaW5zdGVhZCB1c2UgYSBw YXlsb2FkIHR5cGUgYmFzZWQgbWVjaGFuaXNtIGZvciBkZW11eGluZy4gIEluIHRoaXMNCj4gDQo+ IFRoZSB0ZXJtIOKAnGRlbXV4aW5n4oCdIGlzIHVuY2xlYXIuIEZvciBwcmVjaXNpb24sIEkgc3Vn Z2VzdCBjaGFuZ2luZyDigJx1c2UgYSBwYXlsb2FkIHR5cGUgYmFzZWQgbWVjaGFuaXNtcyBmb3Ig ZGVtdXhpbmfigJ0gdG8g4oCcdXNlIGEgcGF5bG9hZCB0eXBlIGJhc2VkIG1lY2hhbmlzbSB0byBh c3NvY2lhdGUgUlRQIHN0cmVhbXMgd2l0aCBTRFAgbT0gbGluZXPigJ0uDQo+IA0KPj4gICBzaXR1 YXRpb24sIGVhY2ggIm09IiBsaW5lIE1VU1QgdXNlIHVuaXF1ZSBwYXlsb2FkIHR5cGUgdmFsdWVz LCBpbg0KPj4gICBvcmRlciBmb3IgdGhlIHBheWxvYWQgdHlwZSB0byBiZSBhIHJlbGlhYmxlIGlu ZGljYXRvciBvZiB0aGUgcmVsZXZhbnQNCj4+ICAgIm09IiBsaW5lIGZvciB0aGUgUlRQIHN0cmVh bS4gIE5vdGUgdGhhdCB3aGVuIHVzaW5nIHBheWxvYWQgdHlwZQ0KPj4gICBiYXNlZCBkZW11eGlu ZywNCj4gDQo+IFNpbWlsYXJseSwgZm9yIHByZWNpc2lvbiwgSSBzdWdnZXN0IGNoYW5naW5nIOKA nHdoZW4gdXNpbmcgcGF5bG9hZCB0eXBlIGJhc2VkIGRlbXV4aW5n4oCdIHRvIOKAnHdoZW4gdXNp bmcgdGhlIHBheWxvYWQgdHlwZSB0byBhc3NvY2lhdGUgUlRQIHN0cmVhbXMgd2l0aCBtPSBsaW5l c+KAnS4NCj4gDQo+PiAgICAgICAgICAgICAgICAgICBhbiBTU1JDIHdpbGwgYmUgbWFwcGVkIHRv IGFuIOKAnG094oCcIGxpbmUNCj4gDQo+IFN1Z2dlc3QgY2hhbmdpbmcgdG8g4oCcYW4gUlRQIHN0 cmVhbSwgaWRlbnRpZmllZCBieSBTU1JDLCB3aWxsIGJlIG1hcHBlZOKApuKAnSB0byBiZSBjbGVh ciB3aGF04oCZcyBiZWluZyBkb25lLg0KPiANCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJ5IHRoZSBmaXJzdA0KPj4gICBwYWNrZXQg d2l0aCB0aGF0IFNTUkMsIGFuZCB0aGUgbWFwcGluZyB3aWxsIG5vdCBiZSBjaGFuZ2VkIGV2ZW4g aWYNCj4gDQo+IFN1Z2dlc3QgY2hhbmdpbmcgdG8g4oCcd2hlbiB0aGUgZmlyc3QgUlRQIHBhY2tl dCBvZiB0aGF0IFJUUCBzdHJlYW0gaXMgcmVjZWl2ZWQsIGFuZOKApuKAnSB0byBiZSBjbGVhciwg c2luY2UgdGhlcmUgY291bGQgYmUgUlRDUCBwYWNrZXRzIHdpdGggdGhlIHNhbWUgU1NSQy4NCj4g DQo+PiAgIHRoZSBzYW1lIFNTUkMgaXMgcmVjZWl2ZWQgd2l0aCBhIGRpZmZlcmVudCBwYXlsb2Fk IHR5cGUuICBJbiBvdGhlcg0KPiANCj4gU3VnZ2VzdCBjaGFuZ2luZyB0byDigJx0aGUgcGF5bG9h ZCB0eXBlIHVzZWQgYnkgdGhhdCBSVFAgc3RyZWFtIGNoYW5nZXMuIEluIG90aGVy4oCdIHRvIGJl IHByZWNpc2UuDQo+IA0KPj4gICB3b3JkcywgdGhlIFNTUkMgY2Fubm90IHRvICJtb3ZlIiB0byBh IGRpZmZlcmVudCAibT0iIGxpbmUgc2ltcGx5IGJ5DQo+PiAgIGNoYW5naW5nIHRoZSBwYXlsb2Fk IHR5cGUuDQo+PiANCj4+IEhvbG1iZXJnLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MiwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDIxXQ0KPj4gSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgQnVuZGxlZCBtZWRpYSAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDE3DQo+PiAN Cj4+IA0KPj4gICBBcHBsaWNhdGlvbnMgY2FuIGltcGxlbWVudCBSVFAgc3RhY2tzIGluIG1hbnkg ZGlmZmVyZW50IHdheXMuICBUaGUNCj4+ICAgYWxnb3JpdGhtIGJlbG93IGRldGFpbHMgb25lIHdh eSB0aGF0IGRlbXVsdGlwbGV4aW5nIGNhbiBiZQ0KPj4gICBhY2NvbXBsaXNoZWQsIGJ1dCBpcyBu b3QgbWVhbnQgdG8gYmUgcHJlc2NyaXB0aXZlIGFib3V0IGV4YWN0bHkgaG93DQo+IA0KPiBUbyBi ZSBjbGVhciBhYm91dCB3aGF0IGlzIGJlaW5nIGRlbXVsdGlwbGV4ZWQsIEkgc3VnZ2VzdCBjaGFu Z2luZyDigJxvbmUgd2F5IHRoYXQgZGVtdWx0aXBsZXhpbmcgY2FuIGJlIGFjY29tcGxpc2hlZOKA nSB0byDigJxvbmUgd2F5IHRoYXQgUlRQIHN0cmVhbXMgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBt PSBsaW5lc+KAnS4NCj4gDQo+PiAgIGFuIFJUUCBzdGFjayBuZWVkcyB0byBiZSBpbXBsZW1lbnRl ZC4gIEFwcGxpY2F0aW9ucyBNQVkgdXNlIGFueQ0KPj4gICBhbGdvcml0aG0gdGhhdCBhY2hpZXZl cyBlcXVpdmFsZW50IHJlc3VsdHMgdG8gdGhvc2UgZGVzY3JpYmVkIGluIHRoZQ0KPj4gICBhbGdv cml0aG0gYmVsb3cuDQo+PiANCj4+ICAgVG8gcHJlcGFyZSBmb3IgZGVtdWx0aXBsZXhpbmcgUlRQ L1JUQ1AgcGFja2V0cyB0byB0aGUgY29ycmVjdCAibT0iDQo+PiAgIGxpbmUsIHRoZSBmb2xsb3dp bmcgc3RlcHMgTVVTVCBiZSBmb2xsb3dlZCBmb3IgZWFjaCBCVU5ETEUgZ3JvdXAuDQo+IA0KPiBJ IHN1Z2dlc3QgY2hhbmdpbmcg4oCc4oCmcHJlcGFyZSBmb3IgZGVtdWx0aXBsZXhpbmcgUlRQL1JU Q1AgcGFja2V0cyB0byB0aGUgY29ycmVjdOKApuKAnSB0byDigJzigKZwcmVwYXJlIHRvIGFzc29j aWF0ZSBSVFAgc3RyZWFtcyB3aXRoIHRoZSBjb3JyZWN04oCm4oCdLiBSVFAgYW5kIFJUQ1AgcGFj a2V0cyBhcmUgbm90IGRlbXVsdGlwbGV4ZWQgdG8gbT0gbGluZXMsIHRoZXnigJlyZSBkZW11bHRp cGxleGVkIGludG8gUlRQIHN0cmVhbXMsIGFuZCB0aGVuIHRob3NlIFJUUCBzdHJlYW1zIGFyZSBh c3NvY2lhdGVkIHdpdGggbT0gbGluZXMuIFRoZSBkaXN0aW5jdGlvbiBpcyBpbXBvcnRhbnQsIGlu IG9yZGVyIHRvIGltcGxlbWVudCBSVENQIGNvcnJlY3RseS4gDQo+IA0KPj4gICAgICBDb25zdHJ1 Y3QgYSB0YWJsZSBtYXBwaW5nIE1JRCB0byAibT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGlu DQo+PiAgICAgIHRoaXMgQlVORExFIGdyb3VwLiAgTm90ZSB0aGF0IGFuICJtPSIgbGluZSBtYXkg b25seSBoYXZlIG9uZSBNSUQuDQo+PiANCj4+ICAgICAgQ29uc3RydWN0IGEgdGFibGUgbWFwcGlu ZyBpbmNvbWluZyBTU1JDIHRvICJtPSIgbGluZSBmb3IgZWFjaCAibT0iDQo+PiAgICAgIGxpbmUg aW4gdGhpcyBCVU5ETEUgZ3JvdXAgYW5kIGZvciBlYWNoIFNTUkMgY29uZmlndXJlZCBmb3INCj4+ ICAgICAgcmVjZWl2aW5nIGluIHRoYXQg4oCcbT0iIGxpbmUuDQo+IA0KPiBUaGUgU1NSQyBpcyBh IHByb3BlcnR5IG9mIGFuIFJUUCBzdHJlYW0sIHNvIEkgc3VnZ2VzdCBjaGFuZ2luZyDigJxtYXBw aW5nIGluY29taW5nIFNTUkMgdG/igJ0gdG8g4oCcbWFwcGluZyBTU1JDcyBvZiBpbmNvbWluZyBS VFAgc3RyZWFtcyB0b+KAnS4NCj4gDQo+PiAgICAgIENvbnN0cnVjdCBhIHRhYmxlIG1hcHBpbmcg b3V0Z29pbmcgU1NSQyB0byAibT1saW5lIiBmb3IgZWFjaCAibT0iDQo+PiAgICAgIGxpbmUgaW4g dGhpcyBCVU5ETEUgZ3JvdXAgYW5kIGZvciBlYWNoIFNTUkMgY29uZmlndXJlZCBmb3Igc2VuZGlu Zw0KPj4gICAgICBpbiB0aGF0IOKAnG09IiBsaW5lLg0KPiANCj4gU2ltaWxhcmx5LCBjaGFuZ2Ug 4oCcbWFwcGluZyBvdXRnb2luZyBTU1JD4oCdIHRvIOKAnG1hcHBpbmcgdGhlIFNTUkMgb2YgZWFj aCBvdXRnb2luZyBSVFAgc3RyZWFt4oCdDQo+IA0KPj4gICAgICBDb25zdHJ1Y3QgYSB0YWJsZSBt YXBwaW5nIHBheWxvYWQgdHlwZSB0byAibT0iIGxpbmUgZm9yIGVhY2ggIm09Ig0KPj4gICAgICBs aW5lIGluIHRoZSBCVU5ETEUgZ3JvdXAgYW5kIGZvciBlYWNoIHBheWxvYWQgdHlwZSBjb25maWd1 cmVkIGZvcg0KPj4gICAgICByZWNlaXZpbmcgaW4gdGhhdCAibT0iIGxpbmUuICBJZiBhbnkgcGF5 bG9hZCB0eXBlIGlzIGNvbmZpZ3VyZWQNCj4+ICAgICAgZm9yIHJlY2VpdmluZyBpbiBtb3JlIHRo YW4gb25lICJtPSIgbGluZSBpbiB0aGUgQlVORExFIGdyb3VwLCBkbw0KPj4gICAgICBub3QgaXQg aW5jbHVkZSBpdCBpbiB0aGUgdGFibGUsIGFzIGl0IGNhbm5vdCBiZSB1c2VkIHRvIHVuaXF1ZWx5 DQo+PiAgICAgIGlkZW50aWZ5IGEgIm09IiBsaW5lLg0KPj4gDQo+PiAgICAgIE5vdGUgdGhhdCBm b3IgZWFjaCBvZiB0aGVzZSB0YWJsZXMsIHRoZXJlIGNhbiBvbmx5IGJlIG9uZSBtYXBwaW5nDQo+ PiAgICAgIGZvciBhbnkgZ2l2ZW4ga2V5IChNSUQsIFNTUkMsIG9yIFBUKS4gIEluIG90aGVyIHdv cmRzLCB0aGUgdGFibGVzDQo+PiAgICAgIGFyZSBub3QgbXVsdGltYXBzLg0KPj4gDQo+PiAgIEFz ICJtPSIgbGluZXMgYXJlIGFkZGVkIG9yIHJlbW92ZWQgZnJvbSB0aGUgQlVORExFIGdyb3Vwcywg b3IgdGhlaXINCj4+ICAgY29uZmlndXJhdGlvbnMgYXJlIGNoYW5nZWQsIHRoZSB0YWJsZXMgYWJv dmUgTVVTVCBhbHNvIGJlIHVwZGF0ZWQuDQo+PiANCj4+ICAgRm9yIGVhY2ggUlRQIHBhY2tldCBy ZWNlaXZlZCwgdGhlIGZvbGxvd2luZyBzdGVwcyBNVVNUIGJlIGZvbGxvd2VkIHRvDQo+PiAgIHJv dXRlIHRoZSBwYWNrZXQgdG8gdGhlIGNvcnJlY3QgIm09IiBzZWN0aW9uIHdpdGhpbiBhIEJVTkRM RSBncm91cC4NCj4gDQo+IFRoZSBnb2FsIGlzIG5vdCB0byByb3V0ZSBSVFAgcGFja2V0cyB0byBt PSBsaW5lcywgYnV0IHJhdGhlciB0byBhc3NvY2lhdGUgdGhlIGNvcnJlc3BvbmRpbmcgUlRQIHN0 cmVhbXMgd2l0aCBtPSBsaW5lcy4gVGhpcyBrZWVwcyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBS VFAgYW5kIFJUQ1AgcHJvY2Vzc2luZyB0aGF0IGhhcyB0byBoYXBwZW4gaXJyZXNwZWN0aXZlIG9m IHRoZSBtPSBsaW5lLCBhbmQgdGhlIGFwcGxpY2F0aW9uIGxldmVsIHByb2Nlc3NpbmcgdGhhdCBk ZXBlbmRzIG9uIHRoZSBjaG9pY2Ugb2YgbT0gbGluZS4gSSBzdWdnZXN0IGNoYW5naW5nIHRoaXMg c2VudGVuY2UgdG86IOKAnFdoZW4gYW4gUlRQIHBhY2tldCBpcyByZWNlaXZlZCwgaXQgTVVTVCBi ZSBkZWxpdmVyZWQgdG8gdGhlIFJUUCBzdHJlYW0gY29ycmVzcG9uZGluZyB0byBpdHMgU1NSQy4g VGhhdCBSVFAgc3RyZWFtIE1VU1QgdGhlbiBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvcnJlY3Qg bT0gbGluZSB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAsIGFjY29yZGluZyB0byB0aGUgZm9sbG93aW5n IHN0ZXBzLuKAnQ0KPiANCj4+ICAgTm90ZSB0aGF0IHRoZSBwaHJhc2UgJ2RlbGl2ZXIgYSBwYWNr ZXQgdG8gdGhlICJtPSIgbGluZScgbWVhbnMgdG8NCj4+ICAgZnVydGhlciBwcm9jZXNzIHRoZSBw YWNrZXQgYXMgd291bGQgbm9ybWFsbHkgaGFwcGVuIHdpdGggUlRQL1JUQ1AsIGlmDQo+PiAgIGl0 IHdlcmUgcmVjZWl2ZWQgb24gYSB0cmFuc3BvcnQgYXNzb2NpYXRlZCB3aXRoIHRoYXQgIm09IiBs aW5lDQo+PiAgIG91dHNpZGUgb2YgYSBCVU5ETEUgZ3JvdXAgKGkuZS4sIGlmIHRoZSAibT0iIGxp bmUgd2VyZSBub3QgQlVORExFZCksDQo+PiAgIGluY2x1ZGluZyBkcm9wcGluZyBhbiBSVFAgcGFj a2V0IGlmIHRoZSBwYWNrZXQncyBQVCBkb2VzIG5vdCBtYXRjaA0KPj4gICBhbnkgUFQgaW4gdGhl IOKAnG09IiBsaW5lLg0KPiANCj4gRHJvcHBpbmcgUlRQIHBhY2tldHMgd2l0aCB1bmtub3duIHBh eWxvYWQgdHlwZSBicmVha3MgUlRDUC4gVGhlIFJUUCBwYWNrZXQgbXVzdCBiZSBwcm9jZXNzZWQg YnkgdGhlIFJUUCBsYXllciBhcyBub3JtYWwsIHVwZGF0aW5nIHRoZSBzdGF0aXN0aWNzIHRoYXQg YXJlIG1haW50YWluZWQgYnkgUlRDUC4gVGhlIHBheWxvYWQgaXMgdGhlbiBkaXNjYXJkZWQsIGJl Y2F1c2UgdGhlcmXigJlzIG5vIGRlY29kZXIgYXNzb2NpYXRlZCB3aXRoIHRoZSBwYXlsb2FkIHR5 cGUuIEkgc3VnZ2VzdCByZW1vdmluZyB0aGlzIHBhcnQgb2YgdGhlIHBhcmFncmFwaCBlbnRpcmVs eS4NCj4gDQo+PiAgICAgIElmIHRoZSBwYWNrZXQgaGFzIGEgTUlELCBhbmQgdGhhdCBNSUQgaXMg bm90IGluIHRoZSB0YWJsZSBtYXBwaW5nDQo+PiAgICAgIE1JRCB0byDigJxtPSIgbGluZSwgZHJv cCB0aGUgcGFja2V0IGFuZCBzdG9wLg0KPiANCj4gRHJvcHBpbmcgdGhlIFJUUCBwYWNrZXQgd2ls bCBicmVhayB0aGUgUlRDUCByZXBvcnRzLiBUaGUgUlRQIHBhY2tldCBoYXMgdG8gYmUgcHJvY2Vz c2VkIGFzIG5vcm1hbCwgYnV0IHRoZSBjb3JyZXNwb25kaW5nIFJUUCBzdHJlYW0gaXMgbm90IGRl Y29kZWQgaWYgaXTigJlzIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4g4oCcbT3igJwgbGluZSAoaS5l LiwgeW91IGRyb3AgdGhlIHBheWxvYWQsIG5vdCB0aGUgUlRQIHBhY2tldCkuIEkgc3VnZ2VzdCBy ZXBsYWNpbmcgdGhlIGFib3ZlIHdpdGggc29tZXRoaW5nIGxpa2U6DQo+IA0KPiAgIElmIHRoZSBN SUQgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAgc3RyZWFtIGlzIG5vdCBpbiB0aGUgdGFibGUgbWFw cGluZyANCj4gICBNSUQgdG8g4oCcbT3igJwgbGluZSwgdGhlbiB0aGUgUlRQIHN0cmVhbSBpcyBu b3QgZGVjb2RlZCBhbmQgdGhlIHBheWxvYWQNCj4gICBkYXRhIGlzIGRpc2NhcmRlZC4NCj4gDQo+ PiAgICAgIElmIHRoZSBwYWNrZXQgaGFzIGEgTUlELCBhbmQgdGhlIHBhY2tldCdzIGV4dGVuZGVk IHNlcXVlbmNlIG51bWJlcg0KPj4gICAgICBpcyBncmVhdGVyIHRoYW4gdGhhdCBvZiB0aGUgbGFz dCBNSUQgdXBkYXRlLCBhcyBkaXNjdXNzZWQgaW4NCj4+ICAgICAgW1JGQzc5NDFdLCBTZWN0aW9u IDQuMi42LCB1cGRhdGUgdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJsZQ0KPj4gICAgICB0 byBpbmNsdWRlIGFuIGVudHJ5IHRoYXQgbWFwcyB0aGUgcGFja2V0J3MgU1NSQyB0byB0aGUgIm09 IiBsaW5lDQo+PiAgICAgIGZvciB0aGF0IE1JRC4NCj4gDQo+IFRoZXJlIGFyZSB0d28gdGhpbmdz IHRoYXQgbmVlZCB0byBiZSBkb25lIGhlcmU6IHVwZGF0ZSB0aGUgTUlEIGFzc29jaWF0ZWQgd2l0 aCB0aGUgUlRQIHN0cmVhbSB0byBtYXRjaCB0aGF0IGluIHRoZSBuZXdseSByZWNlaXZlZCBSVFAg cGFja2V0LCBhbmQgdXBkYXRlIHRoZSBtYXBwaW5nIHRhYmxlLiBJIHN1Z2dlc3QgY2hhbmdpbmcg 4oCcdXBkYXRlIHRoZSBpbmNvbWluZyBTU1JDIG1hcHBpbmcgdGFibGUgdG8gaW5jbHVkZSBhbiBl bnRyeSB0aGF0IG1hcHMgdGhlIHBhY2tldOKAmXMgU1NSQyB0byB0aGUg4oCcbT3igJwgbGluZSBm b3IgdGhhdCBNSUTigJ0gdG8g4oCcdXBkYXRlIHRoZSBNSUQgYXNzb2NpYXRlZCB3aXRoIHRoZSBS VFAgc3RyZWFtIHRvIG1hdGNoIHRoZSBNSUQgY2FycmllZCBpbiB0aGUgUlRQIHBhY2tldCwgdGhl biB1cGRhdGUgdGhlIG1hcHBpbmcgdGFibGVzIHRvIGluY2x1ZGUgYW4gZW50cnkgdGhhdCBtYXBz IHRoZSBTU1JDIG9mIHRoYXQgUlRQIHN0cmVhbSB0byB0aGUg4oCcbT3igJwgbGluZSBmb3IgdGhh dCBNSUTigJ0uDQo+IA0KPj4gICAgICBJZiB0aGUgcGFja2V0J3MgU1NSQyBpcyBpbiB0aGUgaW5j b21pbmcgU1NSQyBtYXBwaW5nIHRhYmxlLCBjaGVjaw0KPj4gICAgICB0aGF0IHRoZSBwYWNrZXQn cyBQVCBtYXRjaGVzIGEgUFQgaW5jbHVkZWQgb24gdGhlIGFzc29jaWF0ZWQgIm09Ig0KPj4gICAg ICBsaW5lLiAgSWYgc28sIHJvdXRlIHRoZSBwYWNrZXQgdG8gdGhhdCBhc3NvY2lhdGVkICJtPSIg bGluZSBhbmQNCj4+ICAgICAgc3RvcDsgb3RoZXJ3aXNlIGRyb3AgdGhlIHBhY2tldCBhbmQgc3Rv cC4NCj4gDQo+IERyb3BwaW5nIHRoZSBwYWNrZXQgYnJlYWtzIFJUQ1AuIFRoZSBSVFAgcGFja2V0 IGlzIHByb2Nlc3NlZCBhcyBub3JtYWwsIGJ1dCB0aGUgY29ycmVzcG9uZGluZyBSVFAgc3RyZWFt IGlzIG5vdCBkZWNvZGVkIGlmIGl04oCZcyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIOKAnG094oCc IGxpbmUuIEkgc3VnZ2VzdCByZXBsYWNpbmcgdGhlIGFib3ZlIHdpdGg6DQo+IA0KPiAgIElmIHRo ZSBTU1JDIG9mIHRoZSBSVFAgc3RyZWFtIGlzIGluIHRoZSBpbmNvbWluZyBTU1JDIG1hcHBpbmcg dGFibGUsIA0KPiAgIGNoZWNrIHRoYXQgdGhlIHBheWxvYWQgdHlwZSB1c2VkIGJ5IHRoZSBSVFAg c3RyZWFtIG1hdGNoZXMgYSBwYXlsb2FkDQo+ICAgdHlwZSBpbmNsdWRlZCBvbiB0aGUgbWF0Y2hp bmcg4oCcbT3igJwgbGluZS4gSWYgc28sIGFzc29jaWF0ZSB0aGUgUlRQDQo+ICAgc3RyZWFtIHdp dGggdGhhdCDigJxtPeKAnCBsaW5lLiBPdGhlcndpc2UsIHRoZSBSVFAgc3RyZWFtIGlzIG5vdCBk ZWNvZGVkDQo+ICAgYW5kIHRoZSBwYXlsb2FkIGRhdGEgaXMgZGlzY2FyZGVkLg0KPiANCj4+ICAg ICAgSWYgdGhlIHBhY2tldCdzIHBheWxvYWQgdHlwZSBpcyBpbiB0aGUgcGF5bG9hZCB0eXBlIHRh YmxlLCB1cGRhdGUNCj4+ICAgICAgdGhlIHRoZSBpbmNvbWluZyBTU1JDIG1hcHBpbmcgdGFibGUg dG8gaW5jbHVkZSBhbiBlbnRyeSB0aGF0IG1hcHMNCj4+ICAgICAgdGhlIHBhY2tldCdzIFNTUkMg dG8gdGhlICJtPSIgbGluZSBmb3IgdGhhdCBwYXlsb2FkIHR5cGUuICBJbg0KPj4gICAgICBhZGRp dGlvbiwgcm91dGUgdGhlIHBhY2tldCB0byB0aGUgYXNzb2NpYXRlZCDigJxtPSIgbGluZSBhbmQg c3RvcC4NCj4gDQo+IFJUUCBwYWNrZXRzIGNvcnJlc3BvbmQgdG8gUlRQIHN0cmVhbXMsIGFuZCB0 aG9zZSBSVFAgc3RyZWFtcyBhcmUgYXNzb2NpYXRlZCB3aXRoIG09IGxpbmVzLiBTdWdnZXN0IGNo YW5naW5nIHRvOg0KPiANCj4gICBJZiB0aGUgcGF5bG9hZCB0eXBlIHVzZWQgYnkgdGhlIFJUUCBz dHJlYW0gaXMgaW4gdGhlIHBheWxvYWQgdHlwZQ0KPiAgIHRhYmxlLCB1cGRhdGUgdGhlIGluY29t aW5nIFNTUkMgbWFwcGluZyB0YWJsZSB0byBpbmNsdWRlIGFuIGVudHJ5DQo+ICAgdGhhdCBtYXBz IHRoZSBSVFAgc3RyZWFt4oCZcyBTU1JDIHRvIHRoZSDigJxtPeKAnCBsaW5lIGZvciB0aGF0IHBh eWxvYWQNCj4gICB0eXBlLiBBc3NvY2lhdGUgdGhlIFJUUCBzdHJlYW0gd2l0aCB0aGUgY29ycmVz cG9uZGluZyDigJxtPeKAnCBsaW5lLg0KPiANCj4+ICAgICAgT3RoZXJ3aXNlLCBkcm9wIHRoZSBw YWNrZXQuDQo+IA0KPiBUaGUgcGFja2V0IGNhbm5vdCBiZSBkaXNjYXJkZWQgd2l0aG91dCBicmVh a2luZyBSVENQLiBJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoZSBhYm92ZSB3aXRoOg0KPiANCj4gICBP dGhlcndpc2UsIG1hcmsgdGhlIFJUUCBzdHJlYW0gYXMgbm90IGZvciBkZWNvZGluZyBhbmQgZGlz Y2FyZCB0aGUgDQo+ICAgcGF5bG9hZC4gDQo+IA0KPj4gICBGb3IgZWFjaCBSVENQIHBhY2tldCBy ZWNlaXZlZCAoaW5jbHVkaW5nIGVhY2ggUlRDUCBwYWNrZXQgdGhhdCBpcw0KPj4gICBwYXJ0IG9m IGEgY29tcG91bmQgUlRDUCBwYWNrZXQpLCB0aGUgcGFja2V0IE1VU1QgYmUgcm91dGVkIHRvIHRo ZQ0KPj4gICDigJxtPeKAnCBsaW5lIGZvciB0aGUgUlRQIHN0cmVhbXMgaXQgY29udGFpbnMgaW5m b3JtYXRpb24gYWJvdXQuICBUaGlzDQo+PiAgIHJvdXRpbmcgaXMgdHlwZS1kZXBlbmRlbnQsIGFz IGVhY2gga2luZCBvZiBSVENQIHBhY2tldCBoYXMgaXRzIG93bg0KPj4gICBtZWNoYW5pc20gZm9y IGFzc29jaWF0aW5nIGl0IHdpdGggdGhlIHJlbGV2YW50IFJUUCBzdHJlYW1zLg0KPiANCj4gVGhl IGZpcnN0IHNlbnRlbmNlIG1pZ2h0IGJlIGNsZWFyZXIgd3JpdHRlbiDigJxGb3IgZWFjaCBSVENQ IHBhY2tldCByZWNlaXZlZCAoaW5jbHVkaW5nIGVhY2ggUlRDUCBwYWNrZXQgdGhhdCBpcyBwYXJ0 IG9mIGEgY29tcG91bmQgUlRDUCBwYWNrZXQpLCB0aGUgcGFja2V0IGlzIHByb2Nlc3NlZCBhcyB1 c3VhbCBieSB0aGUgUlRQIGxheWVyLCB0aGVuIGlzIHBhc3NlZCB0byB0aGUg4oCcbT3igJwgbGlu ZXMgY29ycmVzcG9uZGluZyB0byB0aGUgUlRQIHN0cmVhbXMgaXQgY29udGFpbnMgaW5mb3JtYXRp b24gYWJvdXQgZm9yIGZ1cnRoZXIgcHJvY2Vzc2luZy7igJ0NCj4gDQo+PiAgIFBhY2tldHMgZm9y IHdoaWNoIG5vIGFwcHJvcHJpYXRlICJtPSIgbGluZSBjYW4gYmUgaWRlbnRpZmllZCAoaS5lLiwN Cj4+ICAgZm9yIHVua25vd24gUlRQIHN0cmVhbXMpIGFyZSBub3QgcmVsZXZhbnQgaW4gdGhlIGNv bnRleHQgb2YgdGhpcw0KPj4gICBhbGdvcml0aG0gYW5kIE1BWSBiZSBkcm9wcGVkLiAgVGhpcyBz aXR1YXRpb24gbWF5IG9jY3VyIHdpdGggY2VydGFpbg0KPj4gICBtdWx0aXBhcnR5IFJUUCB0b3Bv bG9naWVzLg0KPiANCj4gVGhlc2UgcGFja2V0cyBjYW7igJl0IGJlIGRyb3BwZWQuIFRoZXkgc2V0 dXAgc3RhdGUgYXQgdGhlIFJUUCBsYXllciB0aGF0IG1pZ2h0IGJlY29tZSByZWxldmFudCB3aGVu IGZ1cnRoZXIgUlRQL1JUQ1AgcGFja2V0cyBhcmUgcmVjZWl2ZWQgKFJUQ1AgcGFja2V0cyBjYW4g cm91bmQtcm9iaW4gU0RFUyBpdGVtcywgc3VjaCBhcyB0aGUgTUlELCBpbiBzb21lIGNhc2VzLCBz byB0aGVzZSBjYW4gcG90ZW50aWFsbHkgYmUgaW1wb3J0YW50KS4gSSBzdWdnZXN0IGNoYW5naW5n IHRoaXMgdG86DQo+IA0KPiAgIFJUQ1AgcGFja2V0cyBmb3Igd2hpY2ggbm8gYXBwcm9wcmlhdGUg 4oCcbT3igJwgbGluZSBjYW4gYmUgaWRlbnRpZmllZA0KPiAgIE1VU1QgYmUgcHJvY2Vzc2VkIGFz IHVzdWFsIGJ5IHRoZSBSVFAgbGF5ZXIsIHVwZGF0aW5nIHRoZSBtZXRhZGF0YQ0KPiAgIGFzc29j aWF0ZWQgd2l0aCB0aGUgY29ycmVzcG9uZGluZyBSVFAgc3RyZWFtcywgYnV0IGFyZSBub3QgcGFz c2VkDQo+ICAgdG8gYW55IOKAnG094oCcIGxpbmUuIFRoaXMgc2l0dWF0aW9uIGNhbiBvY2N1ciB3 aXRoIGNlcnRhaW4gbXVsdGlwYXJ0eSANCj4gICBSVFAgdG9wb2xvZ2llcywgb3Igd2hlbiBSVENQ IHBhY2tldHMgYXJlIHNlbnQgY29udGFpbmluZyBhIHN1YnNldCANCj4gICBvZiB0aGUgU0RFUyBp bmZvcm1hdGlvbi4NCj4gDQo+PiAgIFJ1bGVzIGZvciBoYW5kbGluZyB0aGUgdmFyaW91cyB0eXBl cyBvZiBSVENQIHBhY2tldHMgYXJlIGV4cGxhaW5lZA0KPj4gICBiZWxvdy4NCj4gDQo+IFBlcmhh cHMgY2hhbmdlIHRvIOKAnFJ1bGVzIGZvciBhZGRpdGlvbmFsIHByb2Nlc3Npbmcgb2YgdGhlIHZh cmlvdXPigKbigJ0sIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGlzIGRvZXNu4oCZdCByZXBsYWNl IHRoZSB1c3VhbCBSVENQIHByb2Nlc3NpbmcuDQo+IA0KPj4gICAgICBJZiB0aGUgcGFja2V0IGlz IG9mIHR5cGUgU0RFUywgZm9yIGVhY2ggY2h1bmsgaW4gdGhlIHBhY2tldCB3aG9zZQ0KPiANCj4g IklmIHRoZSBSVENQIHBhY2tldCBpc+KApuKAnQ0KPiANCj4+ICAgICAgU1NSQyBpcyBmb3VuZCBp biB0aGUgaW5jb21pbmcgU1NSQyB0YWJsZSwgZGVsaXZlciBhIGNvcHkgb2YgdGhlDQo+PiAgICAg IHBhY2tldCB0byB0aGUgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGF0IFNTUkMuICBJbiBh ZGRpdGlvbiwNCj4gDQo+IOKAnGEgY29weSBvZiB0aGUgU0RFUyBwYWNrZXTigJ0gcHJlc3VtYWJs eSwgc2luY2Ugb3RoZXJ3aXNlIGl04oCZcyBhbWJpZ3VvdXMgaWYgdGhlIGVudGlyZSBjb21wb3Vu ZCBSVENQIHBhY2tldCBpcyBkZWxpdmVyZWQgb3IganVzdCB0aGUgU0RFUyBwYWNrZXQuDQo+IA0K Pj4gICAgICBmb3IgYW55IFNERVMgTUlEIGl0ZW1zIGNvbnRhaW5lZCBpbiB0aGVzZSBjaHVua3Ms IGlmIHRoZSBNSUQgaXMNCj4+ICAgICAgZm91bmQgaW4gdGhlIHRhYmxlIG1hcHBpbmcgTUlEIHRv ICJtPSIgbGluZSwgdXBkYXRlIHRoZSBpbmNvbWluZw0KPj4gICAgICBTU1JDIHRhYmxlIHRvIGlu Y2x1ZGUgYW4gZW50cnkgdGhhdCBtYXBzIHRoZSBjaHVua+KAmXMgU1NSQyB0byB0aGUNCj4gDQo+ IOKAnOKApm1hcHMgdGhlIFJUUCBzdHJlYW0gYXNzb2NpYXRlZCB3aXRoIHRoZSBjaHVua+KAmXMg U1NSQyB0b+KApuKAnQ0KPiANCj4+ICAgICAgIm09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0aGF0 IE1JRCwgdW5sZXNzIHRoZSBwYWNrZXQgaXMgb2xkZXINCj4+ICAgICAgdGhhbiB0aGUgcGFja2V0 IHRoYXQgbW9zdCByZWNlbnRseSB1cGRhdGVkIHRoZSBtYXBwaW5nIGZvciB0aGlzDQo+PiAgICAg IFNTUkMsIGFzIGRpc2N1c3NlZCBpbiBbUkZDNzk0MV0sIFNlY3Rpb24gNC4yLjYuDQo+PiANCj4+ ICAgICAgTm90ZSB0aGF0IGlmIGFuIFNERVMgcGFja2V0IGlzIHJlY2VpdmVkIGFzIHBhcnQgb2Yg YSBjb21wb3VuZCBSVENQDQo+PiAgICAgIHBhY2tldCwgdGhlIFNTUkMgdG8gIm09IiBsaW5lIG1h cHBpbmcgbWF5IG5vdCBleGlzdCB1bnRpbCB0aGUgU0RFUw0KPj4gICAgICBwYWNrZXQgaXMgaGFu ZGxlZCAoZS5nLiwgaW4gdGhlIGNhc2Ugd2hlcmUgUlRDUCBmb3IgYSBzb3VyY2UgaXMNCj4+ICAg ICAgcmVjZWl2ZWQgYmVmb3JlIGFueSBSVFAgcGFja2V0cykuICBUaGVyZWZvcmUsIHdoZW4gcHJv Y2Vzc2luZyBhDQo+PiAgICAgIGNvbXBvdW5kIHBhY2tldCwgYW55IGNvbnRhaW5lZCBTREVTIHBh Y2tldCBNVVNUIGJlIGhhbmRsZWQgZmlyc3QuDQo+IA0KPiBJdCBtaWdodCBiZSB3b3J0aCByZWZl cmVuY2luZyBSRkMgMzU1MCBzZWN0aW9uIDYuMSwgd2hpY2ggc2F5czoNCj4gDQo+ICAgRWFjaCBp bmRpdmlkdWFsIFJUQ1AgcGFja2V0IGluIHRoZSBjb21wb3VuZCBwYWNrZXQgbWF5IGJlIHByb2Nl c3NlZA0KPiAgIGluZGVwZW5kZW50bHkgd2l0aCBubyByZXF1aXJlbWVudHMgdXBvbiB0aGUgb3Jk ZXIgb3IgY29tYmluYXRpb24gb2YNCj4gICBwYWNrZXRzLiAgDQo+IA0KPiBhcyBqdXN0aWZpY2F0 aW9uIGZvciB0aGlzLg0KPiANCj4+IEhvbG1iZXJnLCBldCBhbC4gICAgICAgICBFeHBpcmVzIE9j dG9iZXIgMiwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0KPj4gSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgQnVuZGxlZCBtZWRpYSAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDE3 DQo+PiANCj4+IA0KPj4gICAgICBJZiB0aGUgcGFja2V0IGlzIG9mIHR5cGUgQllFLCBpdCBpbmRp Y2F0ZXMgdGhhdCB0aGUgUlRQIHN0cmVhbXMNCj4gDQo+IOKAnElmIHRoZSBSVENQIHBhY2tldCBp c+KApuKAnQ0KPiANCj4+ICAgICAgcmVmZXJlbmNlZCBpbiB0aGUgcGFja2V0IGFyZSBlbmRpbmcu ICBUaGVyZWZvcmUsIGZvciBlYWNoIFNTUkMNCj4+ICAgICAgaW5kaWNhdGVkIGluIHRoZSBwYWNr ZXQgdGhhdCBpcyBmb3VuZCBpbiB0aGUgaW5jb21pbmcgU1NSQyB0YWJsZSwNCj4gDQo+IOKAnOKA pmluIHRoZSBCWUUgcGFja2V04oCm4oCdDQo+IA0KPj4gICAgICBmaXJzdCBkZWxpdmVyIGEgY29w eSBvZiB0aGUgcGFja2V0IHRvIHRoZSDigJxtPSIgbGluZSBhc3NvY2lhdGVkDQo+IA0KPiDigJzi gKZhIGNvcHkgb2YgdGhlIEJZRSBwYWNrZXTigKbigJ0NCj4gDQo+PiAgICAgIHdpdGggdGhhdCBT U1JDLCBidXQgdGhlbiByZW1vdmUgdGhlIGVudHJ5IGZvciB0aGF0IFNTUkMgZnJvbSB0aGUNCj4+ ICAgICAgaW5jb21pbmcgU1NSQyB0YWJsZSBhZnRlciBhbiBhcHByb3ByaWF0ZSBkZWxheSB0byBh Y2NvdW50IGZvcg0KPj4gICAgICAic3RyYWdnbGVyIHBhY2tldHMiLCBhcyBzcGVjaWZpZWQgaW4g W1JGQzM1NTBdLCBTZWN0aW9uIDYuMi4xLg0KPj4gDQo+PiAgICAgIElmIHRoZSBwYWNrZXQgaXMg b2YgdHlwZSBTUiBvciBSUiwgZm9yIGVhY2ggcmVwb3J0IGJsb2NrIGluIHRoZQ0KPiANCj4g4oCc SWYgdGhlIFJUQ1AgcGFja2V0IGlz4oCm4oCdDQo+IA0KPj4gICAgICByZXBvcnQgd2hvc2UgIlNT UkMgb2Ygc291cmNlIiBpcyBmb3VuZCBpbiB0aGUgb3V0Z29pbmcgU1NSQyB0YWJsZSwNCj4+ICAg ICAgZGVsaXZlciBhIGNvcHkgb2YgdGhlIFJUQ1AgcGFja2V0IHRvIHRoZSDigJxtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGgNCj4gDQo+IOKAnHRoZSBSVENQIHBhY2tldOKAnSBvciDigJx0aGUgU1Ig b3IgUlIgcGFja2V04oCdPyBUbyBhdm9pZCBjb25mdXNpb24gd2hlbiBjb21wb3VuZCBSVENQIHBh Y2tldHMgYXJlIHVzZWQsIEkgc3VnZ2VzdCB0aGUgbGF0dGVyIHBocmFzaW5nIGhlcmUsIGFuZCBp biB0aGUgbGF0ZXIgc2VjdGlvbnMuDQo+IA0KPj4gICAgICB0aGF0IFNTUkMuICBJbiBhZGRpdGlv biwgaWYgdGhlIHBhY2tldCBpcyBvZiB0eXBlIFNSLCBhbmQgdGhlDQo+PiAgICAgIHNlbmRlciBT U1JDIGZvciB0aGUgcGFja2V0IGlzIGZvdW5kIGluIHRoZSBpbmNvbWluZyBTU1JDIHRhYmxlLA0K Pj4gICAgICBkZWxpdmVyIGEgY29weSBvZiB0aGUgcGFja2V0IHRvIHRoZSDigJxtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGggdGhhdA0KPiANCj4g4oCcYSBjb3B5IG9mIHRoZSBTUiBwYWNrZXTigJ0/ DQo+IA0KPj4gICAgICBTU1JDLg0KPj4gDQo+PiAgICAgIElmIHRoZSBpbXBsZW1lbnRhdGlvbiBz dXBwb3J0cyBSVENQIFhSIGFuZCB0aGUgcGFja2V0IGlzIG9mIHR5cGUNCj4+ICAgICAgWFIsIGFz IGRlZmluZWQgaW4gW1JGQzM2MTFdLCBmb3IgZWFjaCByZXBvcnQgYmxvY2sgaW4gdGhlIHJlcG9y dA0KPj4gICAgICB3aG9zZSAiU1NSQyBvZiBzb3VyY2UiIGlzIGlzIGZvdW5kIGluIHRoZSBvdXRn b2luZyBTU1JDIHRhYmxlLA0KPj4gICAgICBkZWxpdmVyIGEgY29weSBvZiB0aGUgUlRDUCBwYWNr ZXQgdG8gdGhlIOKAnG09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aA0KPiANCj4g4oCcdGhlIFJUQ1Ag cGFja2V04oCdIG9yIOKAnHRoZSBYUiBwYWNrZXTigJ0/DQo+IA0KPj4gICAgICB0aGF0IFNTUkMu ICBJbiBhZGRpdGlvbiwgaWYgdGhlIHNlbmRlciBTU1JDIGZvciB0aGUgcGFja2V0IGlzDQo+PiAg ICAgIGZvdW5kIGluIHRoZSBpbmNvbWluZyBTU1JDIHRhYmxlLCBkZWxpdmVyIGEgY29weSBvZiB0 aGUgcGFja2V0IHRvDQo+IA0KPiDigJx0aGUgcGFja2V04oCdIC0+IOKAnHRoZSBSVENQIHBhY2tl dOKAnSBvciDigJx0aGUgWFIgcGFja2V04oCdPw0KPiANCj4+ICAgICAgdGhlICJtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGggdGhhdCBTU1JDLg0KPj4gDQo+PiAgICAgIElmIHRoZSBwYWNrZXQgaXMg YSBmZWVkYmFjayBtZXNzYWdlIG9mIHR5cGUgUlRQRkIgb3IgUFNGQiwgYXMNCj4gDQo+IOKAnElm IHRoZSBSVENQIHBhY2tldCBpc+KApuKAnQ0KPiANCj4+ICAgICAgZGVmaW5lZCBpbiBbUkZDNDU4 NV0sIGl0IHdpbGwgY29udGFpbiBhIG1lZGlhIHNvdXJjZSBTU1JDLCBhbmQNCj4+ICAgICAgdGhp cyBTU1JDIGlzIHVzZWQgZm9yIHJvdXRpbmcgY2VydGFpbiBzdWJ0eXBlcyBvZiBmZWVkYmFjaw0K Pj4gICAgICBtZXNzYWdlcy4gIEhvd2V2ZXIsIHNldmVyYWwgc3VidHlwZXMgb2YgUFNGQiBtZXNz YWdlcyBpbmNsdWRlDQo+PiAgICAgIHRhcmdldCBTU1JDKHMpIGluIGEgc2VjdGlvbiBjYWxsZWQg RmVlZGJhY2sgQ29udHJvbCBJbmZvcm1hdGlvbg0KPj4gICAgICAoRkNJKS4gIEZvciB0aGVzZSBt ZXNzYWdlcywgdGhlIHRhcmdldCBTU1JDKHMpIGFyZSB1c2VkIGZvcg0KPj4gICAgICByb3V0aW5n Lg0KPj4gDQo+PiAgICAgIElmIHRoZSBwYWNrZXQgaXMgYSBmZWVkYmFjayBtZXNzYWdlIHRoYXQg ZG9lcyBub3QgaW5jbHVkZSB0YXJnZXQNCj4gDQo+IOKAnElmIHRoZSBSVENQIHBhY2tldCBpc+KA puKAnQ0KPiANCj4+ICAgICAgU1NSQ3MgaW4gaXRzIEZDSSBzZWN0aW9uLCBhbmQgdGhlIG1lZGlh IHNvdXJjZSBTU1JDIGlzIGZvdW5kIGluDQo+PiAgICAgIHRoZSBvdXRnb2luZyBTU1JDIHRhYmxl LCBkZWxpdmVyIHRoZSBwYWNrZXQgdG8gdGhlIOKAnG09IiBsaW5lDQo+IA0KPiBXaGljaCBwYWNr ZXQ/IA0KPiANCj4+ICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1NSQy4gIFJUUEZCIGFuZCBQ U0ZCIHR5cGVzIHRoYXQgYXJlIGhhbmRsZWQNCj4+ICAgICAgaW4gdGhpcyB3YXkgaW5jbHVkZToN Cj4+IA0KPj4gICAgICBHZW5lcmljIE5BQ0s6ICBbUkZDNDU4NV0gKFBUPVJUUEZCLCBGTVQ9MSku DQo+PiANCj4+ICAgICAgUGljdHVyZSBMb3NzIEluZGljYXRpb24gKFBMSSk6ICBbUkZDNDU4NV0g KFBUPVBTRkIsIEZNVD0xKS4NCj4+IA0KPj4gICAgICBTbGljZSBMb3NzIEluZGljYXRpb24gKFNM SSk6ICBbUkZDNDU4NV0gKFBUPVBTRkIsIEZNVD0yKS4NCj4+IA0KPj4gICAgICBSZWZlcmVuY2Ug UGljdHVyZSBTZWxlY3Rpb24gSW5kaWNhdGlvbiAoUlBTSSk6ICBbUkZDNDU4NV0NCj4+ICAgICAg ICAgKFBUPVBTRkIsIEZNVD0zKS4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBIb2xtYmVy ZywgZXQgYWwuICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIsIDIwMTcgICAgICAgICAgICAgICBb UGFnZSAyNF0NCj4+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJ1bmRsZWQgbWVkaWEg ICAgICAgICAgICAgICAgICAgTWFyY2ggMjAxNw0KPj4gDQo+PiANCj4+ICAgICAgSWYgdGhlIHBh Y2tldCBpcyBhIGZlZWRiYWNrIG1lc3NhZ2UgdGhhdCBkb2VzIGluY2x1ZGUgdGFyZ2V0DQo+IA0K PiDigJxJZiB0aGUgUlRDUCBwYWNrZXQgaXPigKbigJ0NCj4gDQo+PiAgICAgIFNTUkMocykgaW4g aXRzIEZDSSBzZWN0aW9uLCBpdCBjYW4gZWl0aGVyIGJlIGEgcmVxdWVzdCBvciBhDQo+PiAgICAg IG5vdGlmaWNhdGlvbi4gIFJlcXVlc3RzIHJlZmVyZW5jZSBhIFJUUCBzdHJlYW0gdGhhdCBpcyBi ZWluZyBzZW50DQo+PiAgICAgIGJ5IHRoZSBtZXNzYWdlIHJlY2lwaWVudCwgd2hlcmVhcyBub3Rp ZmljYXRpb25zIGFyZSByZXNwb25zZXMgdG8NCj4+ICAgICAgYW4gZWFybGllciByZXF1ZXN0LCBh bmQgdGhlcmVmb3JlIHJlZmVyZW5jZSBhIFJUUCBzdHJlYW0gdGhhdCBpcw0KPj4gICAgICBiZWlu ZyByZWNlaXZlZCBieSB0aGUgbWVzc2FnZSByZWNpcGllbnQuDQo+PiANCj4+ICAgICAgSWYgdGhl IHBhY2tldCBpcyBhIGZlZWRiYWNrIHJlcXVlc3QgdGhhdCBpbmNsdWRlcyB0YXJnZXQgU1NSQyhz KSwNCj4gDQo+IOKAnElmIHRoZSBSVENQIHBhY2tldCBpc+KApuKAnQ0KPiANCj4+ICAgICAgZm9y IGVhY2ggdGFyZ2V0IFNTUkMgdGhhdCBpcyBmb3VuZCBpbiB0aGUgb3V0Z29pbmcgU1NSQyB0YWJs ZSwNCj4+ICAgICAgZGVsaXZlciBhIGNvcHkgb2YgdGhlIFJUQ1AgcGFja2V0IHRvIHRoZSAibT0i IGxpbmUgYXNzb2NpYXRlZCB3aXRoDQo+PiAgICAgIHRoYXQgU1NSQy4gIFBTRkIgdHlwZXMgdGhh dCBhcmUgaGFuZGxlZCBpbiB0aGlzIHdheSBpbmNsdWRlOg0KPj4gDQo+PiAgICAgIEZ1bGwgSW50 cmEgUmVxdWVzdCAoRklSKTogIFtSRkM1MTA0XSAoUFQ9UFNGQiwgRk1UPTQpLg0KPj4gDQo+PiAg ICAgIFRlbXBvcmFsLVNwYXRpYWwgVHJhZGUtb2ZmIFJlcXVlc3QgKFRTVFIpOiAgW1JGQzUxMDRd IChQVD1QU0ZCLA0KPj4gICAgICAgICBGTVQ9NSkuDQo+PiANCj4+ICAgICAgSC4yNzEgVmlkZW8g QmFjayBDaGFubmVsIE1lc3NhZ2UgKFZCQ00pOiAgW1JGQzUxMDRdIChQVD1QU0ZCLA0KPj4gICAg ICAgICBGTVQ9NykuDQo+PiANCj4+ICAgICAgTGF5ZXIgUmVmcmVzaCBSZXF1ZXN0IChMUlIpOiAg W0ktRC5pZXRmLWF2dGV4dC1scnJdIChQVD1QU0ZCLA0KPj4gICAgICAgICBGTVQ9VEJEKS4NCj4+ IA0KPj4gICAgICBJZiB0aGUgcGFja2V0IGlzIGEgZmVlZGJhY2sgbm90aWZpY2F0aW9uIHRoYXQg aW5jbHVkZSB0YXJnZXQNCj4+ICAgICAgU1NSQyhzKSwgZm9yIGVhY2ggdGFyZ2V0IFNTUkMgdGhh dCBpcyBmb3VuZCBpbiB0aGUgaW5jb21pbmcgU1NSQw0KPj4gICAgICB0YWJsZSwgZGVsaXZlciBh IGNvcHkgb2YgdGhlIFJUQ1AgcGFja2V0IHRvIHRoZSAibT0iIGxpbmUNCj4+ICAgICAgYXNzb2Np YXRlZCB3aXRoIHRoYXQgU1NSQy4gIFBTRkIgdHlwZXMgdGhhdCBhcmUgaGFuZGxlZCBpbiB0aGlz DQo+IA0KPiDigJxkZWxpdmVyIGEgY29weSBvZiB0aGUgUlRDUCBwYWNrZXQgdG8gdGhlIOKAnG09 4oCcIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAgc3RyZWFtIHdpdGggbWF0Y2hpbmcgU1NS Q+KAnQ0KPiANCj4+ICAgICAgd2F5IGluY2x1ZGU6DQo+PiANCj4+ICAgICAgVGVtcG9yYWwtU3Bh dGlhbCBUcmFkZS1vZmYgTm90aWZpY2F0aW9uIChUU1ROKTogIFtSRkM1MTA0XQ0KPj4gICAgICAg ICAoUFQ9UFNGQiwgRk1UPTYpLiAgVGhpcyBtZXNzYWdlIGlzIGEgbm90aWZpY2F0aW9uIGluIHJl c3BvbnNlDQo+PiAgICAgICAgIHRvIGEgcHJpb3IgVFNUUi4NCj4+IA0KPj4gICAgICBJZiB0aGUg cGFja2V0IGlzIG9mIHR5cGUgQVBQLCB0aGUgb25seSByb3V0aW5nIGluZm9ybWF0aW9uDQo+PiAg ICAgIGluY2x1ZGVkIGlzIHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCwgYW5kIHRoZXJlZm9yZSB0 aGUgcGFja2V0DQo+PiAgICAgIGNvdWxkIGJlIHJlbGF0ZWQgdG8gYW55IGV4aXN0aW5nICJtPSIg bGluZS4gIEFjY29yZGluZ2x5LCBkZWxpdmVyDQo+PiAgICAgIGEgY29weSBvZiB0aGUgcGFja2V0 IHRvIGVhY2gg4oCcbT0iIGxpbmUuDQo+IA0KPiBBcmUgQVBQIHBhY2tldHMgZXhwb3NlZCBpbiB0 aGUgV2ViUlRDIEFQSXM/IEdpdmVuIHRoYXQgd2UgaGF2ZSB0aGUgZGF0YSBjaGFubmVsLCBpdOKA mXMgbm90IGNsZWFyIHRoYXQgd2Ugd2FudCB0byBzdXBwb3J0IGFyYml0cmFyeSBhcHBsaWNhdGlv biBpbmZvcm1hdGlvbiBwYXNzaW5nIHZpYSBSVENQLiBJdCBtaWdodCBiZSBiZXR0ZXIgdG8gc2F5 IHRoYXQgQVBQIHBhY2tldHMgYXJlIHByb2Nlc3NlZCBpbiBhbiBhcHBsaWNhdGlvbiBzcGVjaWZp YyBtYW5uZXIsIGFuZCBpZiB0aGUgYXBwbGljYXRpb24gZG9lc27igJl0IHVuZGVyc3RhbmQgdGhl bSwgdGhleeKAmXJlIG5vdCBwYXNzZWQgdG8gYW55IG09IGxpbmU/DQo+IA0KPiBGaW5hbGx5LCBJ IG5vdGUgdGhhdCB0aGlzIHNlY3Rpb24gb2YgdGhlIGRyYWZ0IGRvZXNu4oCZdCBtZW50aW9uIHRo ZSBDU1JDIGxpc3QgYW55d2hlcmUsIGJ1dCBzaG91bGQgcHJvYmFibHkgZG8gc28uIEFzIHdyaXR0 ZW4sIFJUUCBwYWNrZXRzIHdpdGggYSBDU1JDIGxpc3Qgd2lsbCBiZSBkZWxpdmVyZWQgdG8gdGhl IFJUUCBzdHJlYW0gbWF0Y2hpbmcgdGhlaXIgU1NSQyBpbiB0aGUgdXN1YWwgd2F5LCB0aGVuIHBh c3NlZCB1cCB0byB0aGUgbT0gbGluZSBhc3NvY2lhdGVkIHdpdGggdGhhdCBSVFAgc3RyZWFtLiBU aGF0IG1heSB3ZWxsIGJlIHN1ZmZpY2llbnQsIGJ1dCBpZiBzbyBpdOKAmXMgbGlrZWx5IHVzZWZ1 bCB0byBzYXkgdGhhdCwgdG8gbWFrZSB0aGUgaW50ZW50IGNsZWFyLg0KPiANCj4gQ29saW4NCj4g DQo+IA0KPiANCj4gDQo+IC0tIA0KPiBDb2xpbiBQZXJraW5zDQo+IGh0dHBzOi8vY3NwZXJraW5z Lm9yZy8NCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBtYWls aW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbW11c2ljDQoNCg0KDQotLSANCkNvbGluIFBlcmtpbnMNCmh0dHBzOi8vY3Nw ZXJraW5zLm9yZy8NCg0KDQoNCg0K From nobody Wed Jul 19 02:54: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 5B60F126C0F for ; Wed, 19 Jul 2017 02:54:45 -0700 (PDT) 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 Uq7BX1dbJBk5 for ; Wed, 19 Jul 2017 02:54:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE3E131C64 for ; Wed, 19 Jul 2017 02:54:41 -0700 (PDT) X-AuditID: c1b4fb30-71bff70000001664-1c-596f2c5fa11e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1C.EF.05732.F5C2F695; Wed, 19 Jul 2017 11:54:39 +0200 (CEST) Received: from [100.94.39.144] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 19 Jul 2017 11:54:38 +0200 To: Christer Holmberg , Colin Perkins CC: "mmusic (E-mail)" References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CC8B423@ESESSMB109.ericsson.se> From: Magnus Westerlund Message-ID: <0e1c94fe-baa2-e94f-298a-e95a8e6aee60@ericsson.com> Date: Wed, 19 Jul 2017 11:54:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CC8B423@ESESSMB109.ericsson.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000009060705020705090003" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbFdWjdeJz/S4EaTkMXylycYLaYuf8zi wOQx7f59No8lS34yBTBFcdmkpOZklqUW6dslcGX8bfzMUnC0i6li8YTtjA2M3dcYuxg5OSQE TCSOnO1h62Lk4hASOMIocfHoEXYIZxOjxIrZi9lAqoQFrCX+dfUD2RwcIgLREv97PUHCzALq Ej2/W5gh6v8zSmy/8ogVJMEmYCFx80cjWC+vgL3E8e8NzCA2i4CqxOyzd5lAbFGBGIlrM++w QtQISpyc+YQFxOYU8JPYf/QpC8hQZoFuRomelgNgDUIC2hINTR2sEGcrSVyfd51lAqPALCT9 s5D1zAK70Exi3uaHzBC2tsSyha+hbHGJpi8rWSFsa4kZvw6yQdiKElO6H7JD2KYSr49+ZISw jSTe7WlkX8DIuYpRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMGIObvltsIPx5XPHQ4wCHIxK PLybBPIjhVgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRHeDimgNG9KYmVValF+fFFpTmrxIUZp DhYlcV7HfRcihATSE0tSs1NTC1KLYLJMHJxSDYym3Js1i9a3Wi+5qJivr1KsUxZuz1ir16Go wyEYciVOfn35RIa68wItknOXhZkJn1owp++934l5ijc2r0nXspTXFJ9oVJg887DYPZuSxUKS 5QqJyq0Oqo/e/p4Y9ODH2zSRslm/3k+49afWnSn84wTL7HmHkyLURASXpQqYaoqsVuiT3J97 UImlOCPRUIu5qDgRAKg14S6gAgAA Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 09:54:45 -0000 --------------ms000009060705020705090003 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, I have reviewed the PR and find no issues and I think it does improve=20 the clarity and correctness in referring to RTP/RTCP terms. I support=20 this change. Cheers Magnus Westerlund Den 2017-07-19 kl. 09:36, skrev Christer Holmberg: > Hi, > > Thanks Colin! > > I encourage those who have been involved in the RTP-to-m-line-mapping d= iscussion to take a look at this. > > Regards, > > Christer > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 18 July 2017 15:43 > To: Christer Holmberg > Cc: mmusic (E-mail) > Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling > > Hi Christer, > > As discussed - pull request submitted. > Colin > > > >> On 9 Apr 2017, at 08:54, Christer Holmberg wrote: >> >> Hi Colin, >> >> Thanks for your input! >> >> Would it be possible for you to create a pull request with your sugges= ted changes? >> >> BUNDLE can be found at: https://github.com/cdh4u/draft-sdp-bundle >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perki= ns >> Sent: 07 April 2017 20:06 >> To: mmusic (E-mail) >> Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling >> >> I have some comments on BUNDLE -37 - apologies that I wasn=E2=80=99t a= ble to participate fully in the mailing list discussion before the meetin= g. >> >> The current text is generally reasonably clear, and is certainly preci= sely written, but I do think it has some problems. Most of these relate t= o the issue of whether RTP packets or RTP streams are being processed. I = think it=E2=80=99s important that this draft is written in terms of how t= o associate RTP streams with m=3D lines, rather than how to route and dem= ultiplex RTP packets, since RTP packet routing and demultiplexing is alre= ady specified by the various RTP specifications. In particular, there are= some places where the draft as written conflates the two layers in ways = that conflict with the RTP and RTCP specifications, that I=E2=80=99ve tri= ed to correct by more cleanly separating the layers. >> >> I=E2=80=99ve tried to write my suggestions in a prescriptive manner, k= eeping to the style of the existing text where possible. Hopefully the re= sult is clear and understandable. >> >> Comments line below: >> >>> 10.2. Associating RTP/RTCP Streams With Correct SDP Media Descriptio= n >>> >>> NOTE: The text in this section is copied from Appendix B of JSEP. >>> The community has not yet agreed on the text. >>> >>> 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 includes an SSRC field that is used to associa= te >>> the packet with the correct RTP stream. RTCP packets also use SSR= Cs >>> to identify which RTP streams the packet relates to. However, a R= TCP >>> packet can contain multiple SSRC fields, in the course of providin= g >>> feedback or reports on different RTP streams, and therefore can be= >>> associated with multiple such 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= =3D" >>> >>> >>> >>> Holmberg, et al. Expires October 2, 2017 [Page = 20] >>> Internet-Draft Bundled media March 2= 017 >>> >>> >>> 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 use the same >>> address:port combination for sending and receiving RTP/RTCP packet= s, >>> the local address:port combination cannot be used to associate an = RTP >>> stream with the correct "m=3D" line. In addition, multiple RTP st= reams >>> might be associated with the same "m=3D" line. >>> >>> An offerer and answerer can inform each other which SSRC values th= ey >>> will use for an RTP stream by using the SDP 'ssrc' attribute >>> [RFC5576]. However, an offerer will not know which SSRC values th= e >>> answerer will use until the offerer has received the answer provid= ing >>> that information. Due to this, before the offerer has received th= e >>> answer, the offerer will not be able to associate an RTP stream wi= th >>> the correct "m=3D" line using the SSRC value associated with the R= TP >>> stream. In addition, the offerer and answerer may start using new= >>> SSRC values mid-session, without informing each other using the SD= P >>> 'ssrc' attribute. >>> >>> In order for an offerer and answerer to always be able to associat= e >>> an RTP stream with the correct "m=3D" line, the offerer and answer= er >>> using the BUNDLE extension MUST support the mechanism defined in >>> section 14, where the offerer and answerer insert the identificati= on- >>> tag associated with an "m=3D" line (provided by the remote peer) i= nto >>> RTP and RTCP packets associated with a BUNDLE group. >>> >>> When using this mechanism, the mapping from an SSRC to an >>> identification-tag is carried in RTP header extensions or RTCP SDE= S >>> packets, as specified in section 14. Since a compound RTCP packet= >>> can contain multiple RTCP SDES packets, and each RTCP SDES packet = can >>> contain multiple chunks, a single RTCP packet can contain several >>> SSRC to identification-tag mappings. The offerer and answerer >>> maintain tables used for routing that are updated each time an RTP= / >>> RTCP packet contains new information that affects how packets shou= ld >>> be routed. >> The text above looks good. In particular, it correctly focusses on ass= ociating RTP streams with m=3D lines, which is the correct level of abstr= action. >> >>> However, some implementations of may not include this identificati= on- >>> tag in their RTP and RTCP traffic when using the BUNDLE mechanism,= >>> and instead use a payload type based mechanism for demuxing. In t= his >> The term =E2=80=9Cdemuxing=E2=80=9D is unclear. For precision, I sugge= st changing =E2=80=9Cuse a payload type based mechanisms for demuxing=E2=80= =9D to =E2=80=9Cuse a payload type based mechanism to associate RTP strea= ms with SDP m=3D lines=E2=80=9D. >> >>> situation, each "m=3D" line MUST use unique payload type values, i= n >>> order for the payload type to be a reliable indicator of the relev= ant >>> "m=3D" line for the RTP stream. Note that when using payload type= >>> based demuxing, >> Similarly, for precision, I suggest changing =E2=80=9Cwhen using paylo= ad type based demuxing=E2=80=9D to =E2=80=9Cwhen using the payload type t= o associate RTP streams with m=3D lines=E2=80=9D. >> >>> an SSRC will be mapped to an =E2=80=9Cm=3D=E2=80=9C= line >> Suggest changing to =E2=80=9Can RTP stream, identified by SSRC, will b= e mapped=E2=80=A6=E2=80=9D to be clear what=E2=80=99s being done. >> >>> by the firs= t >>> packet with that SSRC, and the mapping will not be changed even if= >> Suggest changing to =E2=80=9Cwhen the first RTP packet of that RTP str= eam is received, and=E2=80=A6=E2=80=9D to be clear, since there could be = RTCP packets with the same SSRC. >> >>> the same SSRC is received with a different payload type. In other= >> Suggest changing to =E2=80=9Cthe payload type used by that RTP stream = changes. In other=E2=80=9D to be precise. >> >>> words, the SSRC cannot to "move" to a different "m=3D" line simply= by >>> changing the payload type. >>> >>> Holmberg, et al. Expires October 2, 2017 [Page = 21] >>> Internet-Draft Bundled media March 2= 017 >>> >>> >>> Applications can implement RTP stacks in many different ways. The= >>> algorithm below details one way that demultiplexing can be >>> accomplished, but is not meant to be prescriptive about exactly ho= w >> To be clear about what is being demultiplexed, I suggest changing =E2=80= =9Cone way that demultiplexing can be accomplished=E2=80=9D to =E2=80=9Co= ne way that RTP streams can be associated with m=3D lines=E2=80=9D. >> >>> an RTP stack needs to be implemented. Applications MAY use any >>> algorithm that achieves equivalent results to those described in t= he >>> algorithm below. >>> >>> To prepare for demultiplexing RTP/RTCP packets to the correct "m=3D= " >>> line, the following steps MUST be followed for each BUNDLE group. >> I suggest changing =E2=80=9C=E2=80=A6prepare for demultiplexing RTP/RT= CP packets to the correct=E2=80=A6=E2=80=9D to =E2=80=9C=E2=80=A6prepare = to associate RTP streams with the correct=E2=80=A6=E2=80=9D. RTP and RTCP= packets are not demultiplexed to m=3D lines, they=E2=80=99re demultiplex= ed into RTP streams, and then those RTP streams are associated with m=3D = lines. The distinction is important, in order to implement RTCP correctly= =2E >> >>> Construct a table mapping MID to "m=3D" line for each "m=3D" li= ne in >>> this BUNDLE group. Note that an "m=3D" line may only have one = MID. >>> >>> Construct a table mapping incoming SSRC to "m=3D" line for each= "m=3D" >>> line in this BUNDLE group and for each SSRC configured for >>> receiving in that =E2=80=9Cm=3D" line. >> The SSRC is a property of an RTP stream, so I suggest changing =E2=80=9C= mapping incoming SSRC to=E2=80=9D to =E2=80=9Cmapping SSRCs of incoming R= TP streams to=E2=80=9D. >> >>> Construct a table mapping outgoing SSRC to "m=3Dline" for each = "m=3D" >>> line in this BUNDLE group and for each SSRC configured for send= ing >>> in that =E2=80=9Cm=3D" line. >> Similarly, change =E2=80=9Cmapping outgoing SSRC=E2=80=9D to =E2=80=9C= mapping the SSRC of each outgoing RTP stream=E2=80=9D >> >>> Construct a table mapping payload type to "m=3D" line for each = "m=3D" >>> line in the BUNDLE group and for each payload type configured f= or >>> receiving in that "m=3D" line. If any payload type is configur= ed >>> for receiving in more than one "m=3D" line in the BUNDLE group,= do >>> not it include it in the table, as it cannot be used to uniquel= y >>> identify a "m=3D" line. >>> >>> Note that for each of these tables, there can only be one mappi= ng >>> for any given key (MID, SSRC, or PT). In other words, the tabl= es >>> are not multimaps. >>> >>> As "m=3D" lines are added or removed from the BUNDLE groups, or th= eir >>> 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 gro= up. >> The goal is not to route RTP packets to m=3D lines, but rather to asso= ciate the corresponding RTP streams with m=3D lines. This keeps the disti= nction between RTP and RTCP processing that has to happen irrespective of= the m=3D line, and the application level processing that depends on the = choice of m=3D line. I suggest changing this sentence to: =E2=80=9CWhen a= n RTP packet is received, it MUST be delivered to the RTP stream correspo= nding to its SSRC. That RTP stream MUST then be associated with the corre= ct m=3D line within a BUNDLE group, according to the following steps.=E2=80= =9D >> >>> Note that the phrase 'deliver a packet to the "m=3D" line' means t= o >>> further process the packet as would normally happen with RTP/RTCP,= if >>> it were received on a transport associated with that "m=3D" line >>> outside of a BUNDLE group (i.e., if the "m=3D" line were not BUNDL= Ed), >>> including dropping an RTP packet if the packet's PT does not match= >>> any PT in the =E2=80=9Cm=3D" line. >> Dropping RTP packets with unknown payload type breaks RTCP. The RTP pa= cket must be processed by the RTP layer as normal, updating the statistic= s that are maintained by RTCP. The payload is then discarded, because the= re=E2=80=99s no decoder associated with the payload type. I suggest remov= ing this part of the paragraph entirely. >> >>> If the packet has a MID, and that MID is not in the table mappi= ng >>> MID to =E2=80=9Cm=3D" line, drop the packet and stop. >> Dropping the RTP packet will break the RTCP reports. The RTP packet ha= s to be processed as normal, but the corresponding RTP stream is not deco= ded if it=E2=80=99s not associated with an =E2=80=9Cm=3D=E2=80=9C line (i= =2Ee., you drop the payload, not the RTP packet). I suggest replacing the= above with something like: >> >> If the MID associated with the RTP stream is not in the table mappi= ng >> MID to =E2=80=9Cm=3D=E2=80=9C line, then the RTP stream is not deco= ded and the payload >> data is discarded. >> >>> If the packet has a MID, and the packet's extended sequence num= ber >>> is greater than that of the last MID update, as discussed in >>> [RFC7941], Section 4.2.6, update the incoming SSRC mapping tabl= e >>> to include an entry that maps the packet's SSRC to the "m=3D" l= ine >>> for that MID. >> There are two things that need to be done here: update the MID associa= ted with the RTP stream to match that in the newly received RTP packet, a= nd update the mapping table. I suggest changing =E2=80=9Cupdate the incom= ing SSRC mapping table to include an entry that maps the packet=E2=80=99s= SSRC to the =E2=80=9Cm=3D=E2=80=9C line for that MID=E2=80=9D to =E2=80=9C= update the MID associated with the RTP stream to match the MID carried in= the RTP packet, then update the mapping tables to include an entry that = maps the SSRC of that RTP stream to the =E2=80=9Cm=3D=E2=80=9C line for t= hat MID=E2=80=9D. >> >>> If the packet's SSRC is in the incoming SSRC mapping table, che= ck >>> that the packet's PT matches a PT included on the associated "m= =3D" >>> line. If so, route the packet to that associated "m=3D" line a= nd >>> stop; otherwise drop the packet and stop. >> Dropping the packet breaks RTCP. The RTP packet is processed as normal= , but the corresponding RTP stream is not decoded if it=E2=80=99s not ass= ociated with an =E2=80=9Cm=3D=E2=80=9C line. I suggest replacing the abov= e with: >> >> If the SSRC of the RTP stream is in the incoming SSRC mapping table= , >> check that the payload type used by the RTP stream matches a payloa= d >> type included on the matching =E2=80=9Cm=3D=E2=80=9C line. If so, a= ssociate the RTP >> stream with that =E2=80=9Cm=3D=E2=80=9C line. Otherwise, the RTP st= ream is not decoded >> and the payload data is discarded. >> >>> If the packet's payload type is in the payload type table, upda= te >>> the the incoming SSRC mapping table to include an entry that ma= ps >>> the packet's SSRC to the "m=3D" line for that payload type. In= >>> addition, route the packet to the associated =E2=80=9Cm=3D" lin= e and stop. >> RTP packets correspond to RTP streams, and those RTP streams are assoc= iated with m=3D lines. Suggest changing to: >> >> If the payload type used by the RTP stream is in the payload type >> table, update the incoming SSRC mapping table to include an entry >> that maps the RTP stream=E2=80=99s SSRC to the =E2=80=9Cm=3D=E2=80=9C= line for that payload >> type. Associate the RTP stream with the corresponding =E2=80=9Cm=3D= =E2=80=9C line. >> >>> Otherwise, drop the packet. >> The packet cannot be discarded without breaking RTCP. I suggest replac= ing the above with: >> >> Otherwise, mark the RTP stream as not for decoding and discard the >> payload. >> >>> For each RTCP packet received (including each RTCP packet that is >>> part of a compound RTCP packet), the packet MUST be routed to the >>> =E2=80=9Cm=3D=E2=80=9C line for the RTP streams it contains inform= ation about. This >>> routing is type-dependent, as each kind of RTCP packet has its own= >>> mechanism for associating it with the relevant RTP streams. >> The first sentence might be clearer written =E2=80=9CFor each RTCP pac= ket received (including each RTCP packet that is part of a compound RTCP = packet), the packet is processed as usual by the RTP layer, then is passe= d to the =E2=80=9Cm=3D=E2=80=9C lines corresponding to the RTP streams it= contains information about for further processing.=E2=80=9D >> >>> Packets for which no appropriate "m=3D" line can be identified (i.= e., >>> for unknown RTP streams) are not relevant in the context of this >>> algorithm and MAY be dropped. This situation may occur with certa= in >>> multiparty RTP topologies. >> These packets can=E2=80=99t be dropped. They setup state at the RTP la= yer that might become relevant when further RTP/RTCP packets are received= (RTCP packets can round-robin SDES items, such as the MID, in some cases= , so these can potentially be important). I suggest changing this to: >> >> RTCP packets for which no appropriate =E2=80=9Cm=3D=E2=80=9C line c= an be identified >> MUST be processed as usual by the RTP layer, updating the metadata >> associated with the corresponding RTP streams, but are not passed >> to any =E2=80=9Cm=3D=E2=80=9C line. This situation can occur with c= ertain multiparty >> RTP topologies, or when RTCP packets are sent containing a subset >> of the SDES information. >> >>> Rules for handling the various types of RTCP packets are explained= >>> below. >> Perhaps change to =E2=80=9CRules for additional processing of the vari= ous=E2=80=A6=E2=80=9D, to make it clear that this doesn=E2=80=99t replace= the usual RTCP processing. >> >>> If the packet is of type SDES, for each chunk in the packet who= se >> "If the RTCP packet is=E2=80=A6=E2=80=9D >> >>> SSRC is found in the incoming SSRC table, deliver a copy of the= >>> packet to the "m=3D" line associated with that SSRC. In additi= on, >> =E2=80=9Ca copy of the SDES packet=E2=80=9D presumably, since otherwis= e it=E2=80=99s ambiguous if the entire compound RTCP packet is delivered = or just the SDES packet. >> >>> for any SDES MID items contained in these chunks, if the MID is= >>> found in the table mapping MID to "m=3D" line, update the incom= ing >>> SSRC table to include an entry that maps the chunk=E2=80=99s SS= RC to the >> =E2=80=9C=E2=80=A6maps the RTP stream associated with the chunk=E2=80=99= s SSRC to=E2=80=A6=E2=80=9D >> >>> "m=3D" line associated with that MID, unless the packet is olde= r >>> than the packet that most recently updated the mapping for this= >>> SSRC, as discussed in [RFC7941], Section 4.2.6. >>> >>> Note that if an SDES packet is received as part of a compound R= TCP >>> packet, the SSRC to "m=3D" line mapping may not exist until the= SDES >>> packet is handled (e.g., in the case where RTCP for a source is= >>> received before any RTP packets). Therefore, when processing a= >>> compound packet, any contained SDES packet MUST be handled firs= t. >> It might be worth referencing RFC 3550 section 6.1, which says: >> >> Each individual RTCP packet in the compound packet may be processed= >> independently with no requirements upon the order or combination of= >> packets. >> >> as justification for this. >> >>> Holmberg, et al. Expires October 2, 2017 [Page = 23] >>> Internet-Draft Bundled media March 2= 017 >>> >>> >>> If the packet is of type BYE, it indicates that the RTP streams= >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> referenced in the packet are ending. Therefore, for each SSRC >>> indicated in the packet that is found in the incoming SSRC tabl= e, >> =E2=80=9C=E2=80=A6in the BYE packet=E2=80=A6=E2=80=9D >> >>> first deliver a copy of the packet to the =E2=80=9Cm=3D" line a= ssociated >> =E2=80=9C=E2=80=A6a copy of the BYE packet=E2=80=A6=E2=80=9D >> >>> with that SSRC, but then remove the entry for that SSRC from th= e >>> incoming SSRC table after an appropriate delay to account for >>> "straggler packets", as specified in [RFC3550], Section 6.2.1. >>> >>> If the packet is of type SR or RR, for each report block in the= >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> report whose "SSRC of source" is found in the outgoing SSRC tab= le, >>> deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line as= sociated with >> =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe SR or RR packet=E2=80= =9D? To avoid confusion when compound RTCP packets are used, I suggest th= e latter phrasing here, and in the later sections. >> >>> that SSRC. In addition, if the packet is of type SR, and the >>> sender SSRC for the packet is found in the incoming SSRC table,= >>> deliver a copy of the packet to the =E2=80=9Cm=3D" line associa= ted with that >> =E2=80=9Ca copy of the SR packet=E2=80=9D? >> >>> SSRC. >>> >>> If the implementation supports RTCP XR and the packet is of typ= e >>> XR, as defined in [RFC3611], for each report block in the repor= t >>> whose "SSRC of source" is is found in the outgoing SSRC table, >>> deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line as= sociated with >> =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe XR packet=E2=80=9D? >> >>> that SSRC. In addition, if the sender SSRC for the packet is >>> found in the incoming SSRC table, deliver a copy of the packet = to >> =E2=80=9Cthe packet=E2=80=9D -> =E2=80=9Cthe RTCP packet=E2=80=9D or =E2= =80=9Cthe XR packet=E2=80=9D? >> >>> the "m=3D" line associated with that SSRC. >>> >>> If the packet is a feedback message of type RTPFB or PSFB, as >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> defined in [RFC4585], it will contain a media source SSRC, and >>> this SSRC is used for routing certain subtypes of feedback >>> messages. However, several subtypes of PSFB messages include >>> target SSRC(s) in a section called Feedback Control Information= >>> (FCI). For these messages, the target SSRC(s) are used for >>> routing. >>> >>> If the packet is a feedback message that does not include targe= t >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> SSRCs in its FCI section, and the media source SSRC is found in= >>> the outgoing SSRC table, deliver the packet to the =E2=80=9Cm=3D= " line >> Which packet? >> >>> associated with that SSRC. RTPFB and PSFB types that are handl= ed >>> in this way include: >>> >>> Generic NACK: [RFC4585] (PT=3DRTPFB, FMT=3D1). >>> >>> Picture Loss Indication (PLI): [RFC4585] (PT=3DPSFB, FMT=3D1).= >>> >>> Slice Loss Indication (SLI): [RFC4585] (PT=3DPSFB, FMT=3D2). >>> >>> Reference Picture Selection Indication (RPSI): [RFC4585] >>> (PT=3DPSFB, FMT=3D3). >>> >>> >>> >>> >>> >>> Holmberg, et al. Expires October 2, 2017 [Page = 24] >>> Internet-Draft Bundled media March 2= 017 >>> >>> >>> If the packet is a feedback message that does include target >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> SSRC(s) in its FCI section, it can either be a request or a >>> notification. Requests reference a RTP stream that is being se= nt >>> by the message recipient, whereas notifications are responses t= o >>> an earlier request, and therefore reference a RTP stream that i= s >>> being received by the message recipient. >>> >>> If the packet is a feedback request that includes target SSRC(s= ), >> =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D >> >>> for each target SSRC that is found in the outgoing SSRC table, >>> deliver a copy of the RTCP packet to the "m=3D" line associated= with >>> that SSRC. PSFB types that are handled in this way include: >>> >>> Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >>> >>> Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSF= B, >>> FMT=3D5). >>> >>> H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB,= >>> FMT=3D7). >>> >>> Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB,= >>> FMT=3DTBD). >>> >>> If the packet is a feedback notification that include target >>> SSRC(s), for each target SSRC that is found in the incoming SSR= C >>> table, deliver a copy of the RTCP packet to the "m=3D" line >>> associated with that SSRC. PSFB types that are handled in this= >> =E2=80=9Cdeliver a copy of the RTCP packet to the =E2=80=9Cm=3D=E2=80=9C= line associated with the RTP stream with matching SSRC=E2=80=9D >> >>> way include: >>> >>> Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] >>> (PT=3DPSFB, FMT=3D6). This message is a notification in res= ponse >>> to a prior TSTR. >>> >>> If the packet is of type APP, the only routing information >>> included is the source of the packet, and therefore the packet >>> could be related to any existing "m=3D" line. Accordingly, del= iver >>> a copy of the packet to each =E2=80=9Cm=3D" line. >> Are APP packets exposed in the WebRTC APIs? Given that we have the dat= a channel, it=E2=80=99s not clear that we want to support arbitrary appli= cation information passing via RTCP. It might be better to say that APP p= ackets are processed in an application specific manner, and if the applic= ation doesn=E2=80=99t understand them, they=E2=80=99re not passed to any = m=3D line? >> >> Finally, I note that this section of the draft doesn=E2=80=99t mention= the CSRC list anywhere, but should probably do so. As written, RTP packe= ts with a CSRC list will be delivered to the RTP stream matching their SS= RC in the usual way, then passed up to the m=3D line associated with that= RTP stream. That may well be sufficient, but if so it=E2=80=99s likely u= seful to say that, to make the intent clear. >> >> Colin >> >> >> >> >> --=20 >> 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 > > --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms000009060705020705090003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA3MTkwOTU0MzdaMC8GCSqGSIb3DQEJBDEiBCBxom7DhkrMPMxNQmhD zVR4Of+0naLbBt5vG2AhairXbTBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAbYgMe/AncPTdwZHbDsaOlAOOS0NSHmOFE2Daae41B/Tyf21V fc23Ny/YEgrIlYRy0UZ3cqrIY9wLg5qJkmNJ2Wb1O2L9o0l2Nci8ACr/W9k4E4TE3rgK4OcC Pg+yu/X+LmVzNVU7yj7KtV8vH78970bxy7oiOtTKL9FCwKq08QGg7aI6QXpsSkaPGu6TNYMQ u4omEfyHZpIjcQ7lbPbyZ3idsZIE5LHeVe8+hKvG6nSnL/wUtvxgwBVQ4gCPM2rK3qS3IUW2 e//4ZyUfME6a8qO5KBQ1kH3uBMyTLq5EBcp/nzoHv7qibGCRxWB0XUBug/2+Zw8rj5SQk7lX TnMhCAAAAAAAAA== --------------ms000009060705020705090003-- From nobody Wed Jul 19 03:51:41 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 4988B131CA7; Wed, 19 Jul 2017 03:51:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.56.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150046148224.25273.2938922385750116892@ietfa.amsl.com> Date: Wed, 19 Jul 2017 03:51:22 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-rid-11.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:51: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 : RTP Payload Format Restrictions Authors : Peter Thatcher Mo Zanaty Suhas Nandakumar Bo Burman Adam Roach Byron Campen Filename : draft-ietf-mmusic-rid-11.txt Pages : 27 Date : 2017-07-19 Abstract: In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol. This framework defines a new "rid" SDP attribute to unambiguously identify the RTP Streams within a RTP Session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular Payload Types. This specification updates RFC4855 to give additional guidance on choice of Format Parameter (fmtp) names, and on their relation to the restrictions defined by this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rid/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-rid-11 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rid-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rid-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 19 03:53: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 0FEEA131C99; Wed, 19 Jul 2017 03:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu56na-7JY65; Wed, 19 Jul 2017 03:53:40 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5110412714F; Wed, 19 Jul 2017 03:53:40 -0700 (PDT) Received: from dhcp-8909.meeting.ietf.org (dhcp-8909.meeting.ietf.org [31.133.137.9]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6JArTk5033324 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 19 Jul 2017 05:53:31 -0500 (CDT) (envelope-from adam@nostrum.com) To: Bo Burman , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= Cc: "mmusic (mmusic@ietf.org)" , "Taylor Brandstetter (deadbeef@google.com)" , "draft-ietf-mmusic-rid@ietf.org" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: Adam Roach Message-ID: Date: Wed, 19 Jul 2017 12:53:28 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 10:53:42 -0000 Thanks! These changes look good to me, and I've added them to a -11 version of the document, and uploaded it to the i-d repository: https://www.ietf.org/id/draft-ietf-mmusic-rid-11.txt /a On 7/6/17 13:49, Bo Burman wrote: > To follow up on this, I suggest making the following addition to draft-ietf-mmusic-rid: > > ---- AFTER this text in section 4 ---- > > An "a=rid" SDP media attribute specifies restrictions defining a > unique RTP payload configuration identified via the "rid-id" field. > This value binds the restriction to the RTP Stream identified by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, > implementations that use the "a=rid" parameter in SDP MUST support > the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such > implementations MUST send it for all streams in an SDP media > description ("m=") that have "a=rid" lines remaining after applying > the rules in Section 6 and its subsections. > > ---- ... add this proposed, new text ---- > > Implementations that use the "a=rid" parameter in SDP and that > make use of redundancy RTP streams [RFC7656], e.g. RTP RTX > [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme], > for any of the source RTP streams that have "a=rid" lines remaining > after applying the rules in Section 6 and its subsections, MUST > support and use RepairedRtpStreamId SDES item described in > [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provides > the binding between the source RTP stream and the corresponding > redundancy RTP stream, by setting RepairedRtpStreamId value for > the redundancy RTP stream to the RtpStreamId value of the source > RTP stream. The redundancy RTP stream MAY (but need not) have an > "a=rid" line of its own, in which case the RtpStreamId SDES item value > will be different from the corresponding source RTP stream. > > ---- End changes ---- > > The -simulcast draft would be entirely agnostic to this clarification of "a=rid" and RepairedRtpStreamId usage and thereby transparently allow using redundancy RTP streams with simulcast. > > /Bo > (as individual) > >> -----Original Message----- >> From: Iñaki Baz Castillo [mailto:ibc@aliax.net] >> Sent: den 13 mars 2017 14:43 >> To: Bo Burman >> Cc: mmusic (mmusic@ietf.org) ; Taylor Brandstetter (deadbeef@google.com) >> ; draft-ietf-mmusic-rid@ietf.org; draft-ietf-mmusic-sdp-simulcast@ietf.org >> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast >> >> 2017-03-13 14:41 GMT+01:00 Bo Burman : >>> [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined on RTP level by -avtext-rid. If we have >> preferences on how to best use them with redundancy RTP streams in general, I suggest we add text to -mmusic-rid >> about it. This would be regardless if we go for option A or B, but decided once and for all, thus applicable to RFC 4588 rtx >> and FLEX-FEC alike. >> >> Agreed. >> >> >> -- >> Iñaki Baz Castillo >> From nobody Thu Jul 20 04:56:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1B1315FF for ; Thu, 20 Jul 2017 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Ix4BsrY2T67r for ; Thu, 20 Jul 2017 04:56:18 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5C112EC30 for ; Thu, 20 Jul 2017 04:56:18 -0700 (PDT) Received: from [2001:67c:370:128:94bf:510b:ac62:4222] (port=55289) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dYA3z-0002qw-2j for mmusic@ietf.org; Thu, 20 Jul 2017 12:56:16 +0100 From: Colin Perkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <3DB44F3A-F163-4054-B133-E8F946AF5D6E@csperkins.org> Date: Thu, 20 Jul 2017 13:56:12 +0200 To: "mmusic (E-mail)" X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: [MMUSIC] Comments on draft-ietf-mmusic-opportunistic-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 11:56:20 -0000 Hi, I was asked to review draft-ietf-mmusic-opportunistic-negotiation-00. I = have no objections to the draft. My only comment would be editorial: the = RTP profile names are RTP/AVP, RTP/SAVP, and RTP/SAVPF, and the draft = would be clearer if it used these, rather than AVP, etc. Cheers, Colin --=20 Colin Perkins https://csperkins.org/ From nobody Thu Jul 20 05:18:04 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 75768131761; Thu, 20 Jul 2017 05:18:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150055308241.16105.7253541441857829412@ietfa.amsl.com> Date: Thu, 20 Jul 2017 05:18:02 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:18:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : Using Simulcast in SDP and RTP Sessions Authors : Bo Burman Magnus Westerlund Suhas Nandakumar Mo Zanaty Filename : draft-ietf-mmusic-sdp-simulcast-10.txt Pages : 37 Date : 2017-07-20 Abstract: In some application scenarios it may be desirable to send multiple differently encoded versions of the same media source in different RTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in SDP. The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source, and makes an extension to SDP to relate those RTP streams as being different simulcast formats of that media source. The SDP extension consists of a new media level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-10 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-simulcast-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 Jul 20 05:29: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 8EA5F127058 for ; Thu, 20 Jul 2017 05:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkeP2BQsFC3I for ; Thu, 20 Jul 2017 05:29:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446ED129B43 for ; Thu, 20 Jul 2017 05:29:32 -0700 (PDT) X-AuditID: c1b4fb2d-857ff70000005f66-95-5970a22affd6 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 32.5C.24422.A22A0795; Thu, 20 Jul 2017 14:29:30 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 20 Jul 2017 14:29:29 +0200 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=P0I/P87X7dbDyqrLRXKNWaHIFIZznVIQjQjmna81mnk=; b=bLmL68XfHScU7corGPgoUWHx/1O5YebJy8TzNjfCYXkB9m0EEIjdvGxZb9FsUIQRUyyjGUlsHwo1iprAc2gampPDfNSo1R0Q4yFup9piAe+ND5Alkkzpg9+013trHVzBHELiS4i3JgcYxQSqDsDe0cAwJ1N6p46CO3voFlWXtwM= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2980.eurprd07.prod.outlook.com (10.168.156.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.4; Thu, 20 Jul 2017 12:29:29 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([fe80::ccac:2cc5:7789:e0a7%18]) with mapi id 15.01.1282.011; Thu, 20 Jul 2017 12:29:29 +0000 From: Bo Burman To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-10.txt Thread-Index: AQHTAVJWZLtRMeTaVkqYW2Vhw9aOtqJco0cQ Date: Thu, 20 Jul 2017 12:29:29 +0000 Message-ID: References: <150055308241.16105.7253541441857829412@ietfa.amsl.com> In-Reply-To: <150055308241.16105.7253541441857829412@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [212.121.133.36] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2980; 7:3oia8oKC1pmsPzRJ0/wmQM13iowcmupcmhlOGTD+yx7GkWR4f+rWXzthRobVBqMBn868yr4MqtGLGeAsSbla/TR8rwz6XhU1DlnLl9ExUKbdWrIDEx6i5hYyNZeZ5pr9pBjl+luOR8EQvHP8SMSzJOAuKRge88dEhGzyrgQvZJjAhjYOnX4f5i+wf8xE1nIrBEhp6wnbPBseNHldaSTbUtnHf2wj7j8jM/MrhJ5QnlnfAvxi8gV6aq+6vafFuopKFf3zqOhPThb/ew1BP4HlHIuIfhykZl4GdwKKuGUlLA1GHj9VrvwfcodGswyNNXwVyPIvbRXfxYOiWnqwIjiMzfEF8jHxeeRw5zaE4FHtVl0p8yRbCMk7F1WvnE8KF13Sglh707fHVjPcJCDO+n6QRllWNxjfWtgFd0fmodqEjFnUdzrDvBmq/TlCFcRI542Cr4iTe5R033s3zVwL1SnlUFv37xgt9yq8tM+waChS2o17aAt7nhdhw08w+GfiKjSmnJhprbKbmFHGzzI2hcyLKfynfFBiDm8E8X4I29ZyxEqujS09lRlRfo6JgaKFmjwSbBp/prvgZAQK0NxnZmbWd1ppzP1bBs2M25ZIGz4VGWr9LBEj0if/9weHMHWfELwY7SuL3x2vAAL+PsSp+3nm5dodl4GtT1iYw5vGSDeeePyE2PLQqPaNzewWlrB/hYejlagLzFiMZ73Y1IQeulr5xQQfymrj32ulCG+f6A6Zp88+olz9fqWy9bfdczCYNk2GDgqsnqD5L0tPICxmnA2eVfzAEfKIGej7Z8ASbxJpoOY= x-ms-office365-filtering-correlation-id: a36cd5de-7d67-479b-06e8-08d4cf6af788 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2980; x-ms-traffictypediagnostic: AM5PR0701MB2980: x-exchange-antispam-report-test: UriScan:(278178393323532)(120809045254105)(236129657087228)(148574349560750)(167848164394848)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(2017060910075)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2980; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2980; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(39400400002)(377424004)(13464003)(2501003)(966005)(66066001)(6506006)(5250100002)(102836003)(3846002)(6916009)(2950100002)(6116002)(53546010)(25786009)(2900100001)(2906002)(33656002)(8676002)(7736002)(5660300001)(6306002)(305945005)(14454004)(189998001)(7696004)(86362001)(6246003)(110136004)(478600001)(8936002)(99286003)(76176999)(3280700002)(54356999)(53936002)(74316002)(50986999)(9686003)(2351001)(5640700003)(81166006)(1730700003)(38730400002)(230783001)(6436002)(55016002)(3660700001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2980; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2017 12:29:29.1358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2980 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUyM2K7rq7WooJIgymzVSymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO/H+9gLdopWLG62bmA8JdDFyMkhIWAiseD6RbYuRi4OIYEj jBL33t2Ack4wSvz4/5QRxGER6GWWOHJ/NyNEZg6TxN8ri6Gc54wS5/Z8YQYZxiagITF/x11G EFtEQF3i694esLiwgIfE5Cuf2SDinhKvF/dC2UYSvW86wWpYBFQlzr26wQRi8wokSHT+uAFW IyTgLDF5+2WwmZwCLhJ7Nl8Hq2EUkJW4//0eC4jNLCAucevJfCaIhwQkluw5zwxhi0q8fPyP FeRQRoFuRokP865BFSlJtG29zgphy0pcmt8N9o2EwCM2iafzutghEr4Skxs2MUEkLjNJnHrY BNWhI9Fy5DhUxwRGiYnLr7JBJPIl5j3sYoZIXGWVmNa2iBEiISNxY81eqFFvWCWuPz7PCAkZ KYm7VzoZJzBqzULyCIStI7Fg9yc2CFtbYtnC18yzwIEjKHFy5hOWBYwsqxhFi1OLi3PTjYz1 Uosyk4uL8/P08lJLNjECk8XBLb91dzCufu14iFGAg1GJh1etvyBSiDWxrLgy9xCjBAezkgjv m0lAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhin8t7U DPi2SfnOzT2J0mt8RcptS99uMzremVrhtv7dMQ7johvXGZTveV6+NFdWY1W+EvMRDcGUyd+v P0g/acB7n/s896sFP/ViVdZtyZ0/I/dk0V/ltVKcjSHMP+4qRhk/XfFW8N2ffL8rWkUaGnMW nX+vtyhV725pm1+QxSQP7hv83cF5tsuUWIozEg21mIuKEwGkW8gdEgMAAA== Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-10.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:29:35 -0000 This update contains: o Amended overview section with a bit more explanation on the examples, and added an rid-id alternative for one of the streams. o Removed SCID also from the Terminology section, which was forgotten in -09 when changing SCID to rid-id. /Bo (as individual) > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org > Sent: den 20 juli 2017 14:18 > To: i-d-announce@ietf.org > Cc: mmusic@ietf.org > Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-10.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Multiparty Multimedia Session Control WG= of the IETF. >=20 > Title : Using Simulcast in SDP and RTP Sessions > Authors : Bo Burman > Magnus Westerlund > Suhas Nandakumar > Mo Zanaty > Filename : draft-ietf-mmusic-sdp-simulcast-10.txt > Pages : 37 > Date : 2017-07-20 >=20 > Abstract: > In some application scenarios it may be desirable to send multiple > differently encoded versions of the same media source in different > RTP streams. This is called simulcast. This document describes how > to accomplish simulcast in RTP and how to signal it in SDP. The > described solution uses an RTP/RTCP identification method to identify > RTP streams belonging to the same media source, and makes an > extension to SDP to relate those RTP streams as being different > simulcast formats of that media source. The SDP extension consists > of a new media level SDP attribute that expresses capability to send > and/or receive simulcast RTP streams. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-10 > https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-simulcast-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Jul 20 05:59:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FB3131471 for ; Thu, 20 Jul 2017 05:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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=-0.001, 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 tzlxATN3G2fz for ; Thu, 20 Jul 2017 05:59:12 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C1412EB99 for ; Thu, 20 Jul 2017 05:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=974; q=dns/txt; s=iport; t=1500555552; x=1501765152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dGOqa77hDNtH45m7mOApeCpotavcSrcsW8PBJSBo7f4=; b=ajFZSXy1+NDoqrJd4fn0s+608/qEu5f+YZuWCc6wrIlTZdn6gI1SQiiy SksrfQIIOzZL9cfV50rViRxBavQaTgkIvmENnpQDyZp7a6rs6dAEiXL8x Q35HJ8TN1CnyKYhOQ9fL+cGL2E8x/cvq/X9o1GeP3KRTBan0nj1n5NfCl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABBqHBZ/4oNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRQHjgSRaJYFghEhC4RMTwIag1o/GAECAQEBAQEBAWsohRg?= =?us-ascii?q?BAQEBAgEBASEROgsFCwIBCA4KAgImAgICJQsVEAIEDgWKJwgQsVmCJoshAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBC4Idg02BYSuCeYRqgxMwgjEFnz4Ch0mMTwy?= =?us-ascii?q?SKJVdAR84gQp1FUkSAYcDdohsgQ4BAQE?= X-IronPort-AV: E=Sophos;i="5.40,384,1496102400"; d="scan'208";a="453557572" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jul 2017 12:59:11 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v6KCxBPN020425 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jul 2017 12:59:11 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 20 Jul 2017 07:59:10 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Thu, 20 Jul 2017 07:59:10 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Colin Perkins CC: "mmusic (E-mail)" , Andrew Hutton Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-opportunistic-negotiation-00 Thread-Index: AQHTAU83fnSTD4Y2DkK18SpVpd0i26JdATKA Date: Thu, 20 Jul 2017 12:59:10 +0000 Message-ID: References: <3DB44F3A-F163-4054-B133-E8F946AF5D6E@csperkins.org> In-Reply-To: <3DB44F3A-F163-4054-B133-E8F946AF5D6E@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.252.213] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-opportunistic-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2017 12:59:14 -0000 VGhhbmtzLCBDb2xpbi4gV2XigJlsbCBtYWtlIHRoaXMgZWRpdG9yaWFsIGNoYW5nZSBpbiB0aGUg bmV4dCByZXZpc2lvbi4NCg0KQ2hlZXJzLA0KDQpHb256YWxvDQoNCj4gT24gSnVsIDIwLCAyMDE3 LCBhdCA3OjU2IEFNLCBDb2xpbiBQZXJraW5zIDxjc3BAY3NwZXJraW5zLm9yZz4gd3JvdGU6DQo+ IA0KPiBIaSwNCj4gDQo+IEkgd2FzIGFza2VkIHRvIHJldmlldyBkcmFmdC1pZXRmLW1tdXNpYy1v cHBvcnR1bmlzdGljLW5lZ290aWF0aW9uLTAwLiBJIGhhdmUgbm8gb2JqZWN0aW9ucyB0byB0aGUg ZHJhZnQuIE15IG9ubHkgY29tbWVudCB3b3VsZCBiZSBlZGl0b3JpYWw6IHRoZSBSVFAgcHJvZmls ZSBuYW1lcyBhcmUgUlRQL0FWUCwgUlRQL1NBVlAsIGFuZCBSVFAvU0FWUEYsIGFuZCB0aGUgZHJh ZnQgd291bGQgYmUgY2xlYXJlciBpZiBpdCB1c2VkIHRoZXNlLCByYXRoZXIgdGhhbiBBVlAsIGV0 Yy4NCj4gDQo+IENoZWVycywNCj4gQ29saW4NCj4gDQo+IA0KPiANCj4gDQo+IC0tIA0KPiBDb2xp biBQZXJraW5zDQo+IGh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4gDQo+IA0KPiANCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tdXNpYyBt YWlsaW5nIGxpc3QNCj4gbW11c2ljQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCg== From nobody Thu Jul 20 18:42: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 D91AC131C03 for ; Thu, 20 Jul 2017 18:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 ru1sqe_bCUD7 for ; Thu, 20 Jul 2017 18:42:00 -0700 (PDT) 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 4A627126D73 for ; Thu, 20 Jul 2017 18:42:00 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id r14so564709qte.4 for ; Thu, 20 Jul 2017 18:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=rIRQzhJqqRkr11aIFMYn9M1ML+fgv/0rpJ4HB5yoeMw=; b=jH+MupyTSu9SHcRGGDhdI3grC+2TmLoEJPZJtVPBWIVuunZaIukHJ33/Yef9+uIWtz YvGUmNaiIh/2g7g6DH7bNGetpvzJn8wqwR4dPl5Y/D6sAfk6OxUvEHIJmcV11W4U/crC eEYNMWeaHYqgpLXIlOi95ucWzBMSBQZABt/YF5lJ2JvneL5bBi2fd4DmKA95CZ1SdNQe Dnxa510QDwUd4al7+6cvr+c1ZkChg0Lc8TQQaLr4y7qvrBOlAaA+DZCyJzd0J7O+Jmdg xxMKMfLqbWvJyNWFLYfPvYTA3y175OEVaBJkFGK/wSHq6mHSWml5WCqaPFxPKgi0dUsh Cfsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rIRQzhJqqRkr11aIFMYn9M1ML+fgv/0rpJ4HB5yoeMw=; b=HKTnmapPBYFtMSs6G4qH/Tor1FPsBMdNWbv/O+50tibDJHK/fOD9HuEDTwNp/JgR+h bIDGuuolURAlNP1zEMqb4N/xUVf0A/tcT9bFSUa0imo0HQK+WxYe2FagxfLYSaoRxWgS QgSRB63f/i4lcIHcz5AslCrVWHmuji99Q6LZ+BomuMzPhVkVa1jqc8qCCvjj4i7nkglD 0awh3fKRgtfPmlNGAKRe8WNzN9niiol9Ji8Oc3bKAtqcZ9JJn9pTaWHK/BR4lyF1nGwG mnWZWfMfV+p3cl54DoQrvOZRtjr20pSpcEkGSH1RPocW9Tml5qGwFjSnZsnsjFRbpjXA J+zA== X-Gm-Message-State: AIVw1132o46mYoIrr/cPNrbOot+DsSE23RG9020AhcheN5obu03ORXvv 4dkvu0ZorxIvUHHyoHlpYlyDfJAmahw+siF8dQ== X-Received: by 10.200.39.227 with SMTP id x32mr1151017qtx.223.1500601319182; Thu, 20 Jul 2017 18:41:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.5 with HTTP; Thu, 20 Jul 2017 18:41:58 -0700 (PDT) From: Taylor Brandstetter Date: Thu, 20 Jul 2017 18:41:58 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="001a113ad8ec94c7fb0554c9f84a" Archived-At: Subject: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2017 01:42:02 -0000 --001a113ad8ec94c7fb0554c9f84a Content-Type: text/plain; charset="UTF-8" In the current state of WebRTC 1.0, track IDs are not guaranteed to be symmetrical between the sending and receiving PeerConnection. This is because "addTrack" not only creates an RtpSender, but a whole RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with a generated ID. So if "addTrack" is called, and a remote description is set later, it's the MID that correlates the "m=" section with the track, not the track ID, and the track ID in SDP is effectively ignored. This is all related to the "early media" functionality, and is explained further in a blog post by Jan-Ivar; see the "Correlate by transceiver.mid" section: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/ So, the question became "why signal track IDs at all?" This was brought up in a May virtual interim (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we decided to investigate removing them. To my knowledge this topic hasn't been brought up on this mailing list yet. Is this something still worth considering, or is it too late? "a=msid" would switch to only containing the stream ID, not the track ID. Implementers would presumably have a transitional period where they support parsing both forms of "a=msid", after which they start generating the new format, as we've done for other things. The benefits are that the SDP would be slightly smaller, and the complexity of the standards could be slightly reduced. The downside is that more applications that rely on track IDs would need to be updated (though many will need to be updated anyway). Regardless of the outcome of this decision, "mmusic-msid" really ought to be updated before publication. It's been out of sync with WebRTC 1.0 for about a year; here's the first editor's draft that broke the track ID symmetry: https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html --001a113ad8ec94c7fb0554c9f84a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the current state of WebRTC 1.0, track IDs are not guar= anteed to be symmetrical between the sending and receiving PeerConnection. = This is because "addTrack" not only creates an RtpSender, but a w= hole RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack= with a generated ID. So if "addTrack" is called, and a remote de= scription is set later, it's the MID that correlates the "m=3D&quo= t; section with the track, not the track ID, and the track ID in SDP is eff= ectively ignored.

This is all related to the "early= media" functionality, and is explained further in a blog post by Jan-= Ivar; see the "Correlate by transceiver.mid" section:=C2=A0https://blog= .mozilla.org/webrtc/the-evolution-of-webrtc/

S= o, the question became "why signal track IDs at all?" This was br= ought up in a May virtual interim (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017= ), and we decided to investigate removing them. To my knowledge this topic = hasn't been brought up on this mailing list yet.

Is this something still worth considering, or is it too late? "a=3D= msid" would switch to only containing the stream ID, not the track ID.= Implementers would presumably have a transitional period where they suppor= t parsing both forms of "a=3Dmsid", after which they start genera= ting the new format, as we've done for other things.

The benefits are that the SDP would be slightly smaller, and the com= plexity of the standards could be slightly reduced. The downside is that mo= re applications that rely on track IDs would need to be updated (though man= y will need to be updated anyway).

Regardless of t= he outcome of this decision, "mmusic-msid" really ought to be upd= ated before publication. It's been out of sync with WebRTC 1.0 for abou= t a year; here's the first editor's draft that broke the track ID s= ymmetry:=C2=A0https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html<= /a>
--001a113ad8ec94c7fb0554c9f84a-- From nobody Sat Jul 22 06:25:56 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 07CB8127058; Sat, 22 Jul 2017 06:25:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150072995498.20586.16848827881190223342@ietfa.amsl.com> Date: Sat, 22 Jul 2017 06:25:55 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-trickle-ice-sip-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 13:25:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control WG of the IETF. Title : A Session Initiation Protocol (SIP) usage for Trickle ICE Authors : Emil Ivov Thomas Stach Enrico Marocco Christer Holmberg Filename : draft-ietf-mmusic-trickle-ice-sip-08.txt Pages : 41 Date : 2017-07-22 Abstract: The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-08 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-08 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 Sat Jul 22 06:33: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 9723D12EC13; Sat, 22 Jul 2017 06:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFS4E-QB5oy8; Sat, 22 Jul 2017 06:33:34 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 9919B129AD1; Sat, 22 Jul 2017 06:33:34 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 33so34572265wrz.4; Sat, 22 Jul 2017 06:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=2EO9QP2Yk7re2I98EB5v4WYG6ixR9JiGL4Hmm42NsMQ=; b=sSyzecqSF6u4DHwJHFPmjarPd0JiNuzLYK3avkYBHe47DAtM9HiDBOcVGmx+ytPkBI 7+tujRjKms+Pd4yabKTXUqYcIRuXnTIdhSaSFbny8dv/Gbk8CbdLjDAXnNHJ2emZQ7v8 rdRc0ILLCWlHkjIowz3qDEUvFe6BxBD0fV56GF7YgqQ3xQRVmb+ZNLgTsR4IRvLGEspc 1Ed8aB62lCapXl1w5MxWdZY2ejTaonzi3HjaaS2Ga5Pn9r/zvCkCiMWVrWjXixMQJpgn 0O37JX46+vqDBry4TgDuSRbTpM6vP5dx+9/709ktCV6RE4UVx/H1uwtTwHd+dZPo1Hbc aFuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2EO9QP2Yk7re2I98EB5v4WYG6ixR9JiGL4Hmm42NsMQ=; b=gSClOs126bPGR/7mQ2U0JQ2VpLcMVO4pMTl64OEWr81WvzBKEoBH8l/HD7N6Q3+S9X 5kX5EZ53R3TmRKlfH1MOpbYC5CG7IbRN+/2PHeDNt9Te9bYygCAKSddHq3CBtOFobPHM HszUri2XRSGNsBu4mNifs8+zsS+doZkH9rbFLMEqH2sPreIB62VjkU1rV9BMTCrszxxS BiUU8Y+jeeCH6L68UcKfBWoiiQ0ShhgfZHfdLrwnG8mtvOfFyZBOzX2CkhujB8yKIC5e VjrhlUnM1W1PN84GWnv3oIAPAYGowka4L/Z/NKsziUB9YueCeQqdSRpiy34c9b8Sogy/ clDQ== X-Gm-Message-State: AIVw113atgFuHaAZsLev5Q5wzmhAXFPOU1QlJORAnV1dFlLU0DnZGHx3 xfUiL06Y2sIqOK3wjNw= X-Received: by 10.223.174.242 with SMTP id y105mr9849414wrc.262.1500730412857; Sat, 22 Jul 2017 06:33:32 -0700 (PDT) Received: from [192.168.2.114] ([62.218.68.72]) by smtp.googlemail.com with ESMTPSA id a14sm3718827wma.42.2017.07.22.06.33.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Jul 2017 06:33:32 -0700 (PDT) To: MMUSIC , "draft-ietf-mmusic-trickle-ice-sip@ietf.org" References: <150072995514.20586.18445079127337774642.idtracker@ietfa.amsl.com> From: Thomas Stach Message-ID: <61031b80-5ba4-a88c-e451-9c6eb25ec1b0@gmail.com> Date: Sat, 22 Jul 2017 15:33:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150072995514.20586.18445079127337774642.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-trickle-ice-sip-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jul 2017 13:33:37 -0000 All, this draft comprises the following changes from draft-ietf-mmusic-trickle-ice-sip-07 o editorial fixes o clarification on ordering of candidates for alignment with draft- ietf-ice-trickle-13 (although the draft text says -12) o O/A procedures for end-of-candidates attribute described here after corresponding procedures have been removed from draft-ietf- ice-trickle-11 o using IPv6 addresses in examples I'm not aware of any remaining issues. This version should be ready for WGLC. However, I would still be thankful if people go through this version and provide comments prior to WGLC. Regards Thomas On 2017-07-22 15:25, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-08.txt > has been successfully submitted by Thomas Stach and posted to the > IETF repository. > > Name: draft-ietf-mmusic-trickle-ice-sip > Revision: 08 > Title: A Session Initiation Protocol (SIP) usage for Trickle ICE > Document date: 2017-07-21 > Group: mmusic > Pages: 41 > URL: https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-08.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ > Htmlized: https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-08 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-trickle-ice-sip-08 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-08 > > Abstract: > The Interactive Connectivity Establishment (ICE) protocol describes a > Network Address Translator (NAT) traversal mechanism for UDP-based > multimedia sessions established with the Offer/Answer model. The ICE > extension for Incremental Provisioning of Candidates (Trickle ICE) > defines a mechanism that allows ICE agents to shorten session > establishment delays by making the candidate gathering and > connectivity checking phases of ICE non-blocking and by executing > them in parallel. > > This document defines usage semantics for Trickle ICE with the > Session Initiation Protocol (SIP). > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Mon Jul 24 07:44:59 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 C0DCB131D7F; Mon, 24 Jul 2017 07:44:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150090748573.31954.16277728009505676692@ietfa.amsl.com> Date: Mon, 24 Jul 2017 07:44:45 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-27.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2017 14:44: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 WG of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-27.txt Pages : 24 Date : 2017-07-24 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, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-27 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 26 09:21: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 E7CA7131CFD; Wed, 26 Jul 2017 09:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnM_wWEdxlat; Wed, 26 Jul 2017 09:21:36 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 C79211320A0; Wed, 26 Jul 2017 09:21:35 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id d29so111265836uai.2; Wed, 26 Jul 2017 09:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+p5hreK3PH0SUdqwKQYQywQcNEc+cEq3pdmKklDiCXw=; b=dYul1Z//S15qgjpSxvpeL2gTFwNrUfvcWPhUEpV/WrKmpipKBMp1A7jW9fzVKqmLlx DRfchg+i40gNM61jv0uuDN/ewiJfFDTTET4G9wWncJ6SfNDCTBv2lb2+4vn08PxnWl2I W+oZS14PnZ4kWafCG9AqpmubwMfYNAfRjVMvv6kDdrdp2CyHpWx4+ZG5+C2B5AlAdnfl aRc7fXTvTCx+WhNV2oNfgZPz8DfoJs0njODANls8rq64ANPUZtBScgNGETWWloTei1+d IlAY41gi8S+MuhXYf3pNzrmOjD3PieH8Ddg8+9+kypxUshOioBVAAhgGGSIciUvBFBmT pCqQ== 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=+p5hreK3PH0SUdqwKQYQywQcNEc+cEq3pdmKklDiCXw=; b=lQ3I1tuXDyKDOKN5qtsDCj5IVt95UVk9ke734e20e1W/zxhlrwdlKFhu0BNZjRyg0U 4jFRkHTw85EYxymkgMXXERzJUeL+bzzeQnRlT3lguqq+WBBOZ5HANKU/PMlma3uhNcxv Pr1YsIXcBgx4Dzss/HpJu/WoQRDKt0sDgQR3jxsFb/M8DNK17kvVnyDMdvMqqi/wFvIM NqZTF5mh4trmtkdcZtUG/prVzOPJ4tg2czjfEOpON0fuWrEd6//icANeIiU6jcvjoZnl V9Qm1ZW2kLLwXw1/gCAh3v3nqAWfnRXxmw7h363eVMYaYZ+ukl5pnFTW+FTAMbuBro40 ILbg== X-Gm-Message-State: AIVw111l2yKKl11y9t/7gg3Ki8+v+VaCmzIBPeGizpkH2bnu/L2rLwJS 6yKGN/J7uo+ySE1uCXZEIq9/KPlJSQ== X-Received: by 10.176.3.162 with SMTP id 31mr971832uau.149.1501086094704; Wed, 26 Jul 2017 09:21:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 09:21:14 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: Bernard Aboba Date: Wed, 26 Jul 2017 09:21:14 -0700 Message-ID: To: Bo Burman Cc: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "Adam Roach (adam@nostrum.com)" , "draft-ietf-mmusic-rid@ietf.org" , "mmusic (mmusic@ietf.org)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05ae0273c57305553ad70b" Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 16:21:39 -0000 --94eb2c05ae0273c57305553ad70b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why would a redundancy RTP stream have an "a=3Drid" line of its own? I am struggling to find a use case for this. On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman wrote: > To follow up on this, I suggest making the following addition to > draft-ietf-mmusic-rid: > > ---- AFTER this text in section 4 ---- > > An "a=3Drid" SDP media attribute specifies restrictions defining a > unique RTP payload configuration identified via the "rid-id" field. > This value binds the restriction to the RTP Stream identified by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, > implementations that use the "a=3Drid" parameter in SDP MUST support > the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such > implementations MUST send it for all streams in an SDP media > description ("m=3D") that have "a=3Drid" lines remaining after applyin= g > the rules in Section 6 and its subsections. > > ---- ... add this proposed, new text ---- > > Implementations that use the "a=3Drid" parameter in SDP and that > make use of redundancy RTP streams [RFC7656], e.g. RTP RTX > [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme], > for any of the source RTP streams that have "a=3Drid" lines remaining > after applying the rules in Section 6 and its subsections, MUST > support and use RepairedRtpStreamId SDES item described in > [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provides > the binding between the source RTP stream and the corresponding > redundancy RTP stream, by setting RepairedRtpStreamId value for > the redundancy RTP stream to the RtpStreamId value of the source > RTP stream. The redundancy RTP stream MAY (but need not) have an > "a=3Drid" line of its own, in which case the RtpStreamId SDES item val= ue > will be different from the corresponding source RTP stream. > > ---- End changes ---- > > The -simulcast draft would be entirely agnostic to this clarification of > "a=3Drid" and RepairedRtpStreamId usage and thereby transparently allow u= sing > redundancy RTP streams with simulcast. > > /Bo > (as individual) > > > -----Original Message----- > > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > > Sent: den 13 mars 2017 14:43 > > To: Bo Burman > > Cc: mmusic (mmusic@ietf.org) ; Taylor Brandstetter ( > deadbeef@google.com) > > ; draft-ietf-mmusic-rid@ietf.org; > draft-ietf-mmusic-sdp-simulcast@ietf.org > > Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulca= st > > > > 2017-03-13 14:41 GMT+01:00 Bo Burman : > > > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already define= d > on RTP level by -avtext-rid. If we have > > preferences on how to best use them with redundancy RTP streams in > general, I suggest we add text to -mmusic-rid > > about it. This would be regardless if we go for option A or B, but > decided once and for all, thus applicable to RFC 4588 rtx > > and FLEX-FEC alike. > > > > Agreed. > > > > > > -- > > I=C3=B1aki Baz Castillo > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c05ae0273c57305553ad70b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why would a redundancy RTP stream have an "a=3Drid&qu= ot; line of its own?=C2=A0 I am struggling to find a use case for this.=C2= =A0

On Thu, = Jul 6, 2017 at 4:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:
To follow up on this, I sugges= t making the following addition to draft-ietf-mmusic-rid:

---- AFTER this text in section 4 ----

=C2=A0 =C2=A0An "a=3Drid" SDP media attribute specifies restricti= ons defining a
=C2=A0 =C2=A0unique RTP payload configuration identified via the "rid-= id" field.
=C2=A0 =C2=A0This value binds the restriction to the RTP Stream identified = by its
=C2=A0 =C2=A0RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].=C2=A0 T= o be clear,
=C2=A0 =C2=A0implementations that use the "a=3Drid" parameter in = SDP MUST support
=C2=A0 =C2=A0the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].= =C2=A0 Such
=C2=A0 =C2=A0implementations MUST send it for all streams in an SDP media =C2=A0 =C2=A0description ("m=3D") that have "a=3Drid" l= ines remaining after applying
=C2=A0 =C2=A0the rules in Section 6 and its subsections.

---- ... add this proposed, new text ----

=C2=A0 =C2=A0Implementations that use the "a=3Drid" parameter in = SDP and that
=C2=A0 =C2=A0make use of redundancy RTP streams [RFC7656], e.g. RTP RTX
=C2=A0 =C2=A0[RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-= scheme],
=C2=A0 =C2=A0for any of the source RTP streams that have "a=3Drid"= ; lines remaining
=C2=A0 =C2=A0after applying the rules in Section 6 and its subsections, MUS= T
=C2=A0 =C2=A0support and use RepairedRtpStreamId SDES item described in
=C2=A0 =C2=A0[I-D.ietf-avtext-rid] for those redundancy RTP streams. This p= rovides
=C2=A0 =C2=A0the binding between the source RTP stream and the correspondin= g
=C2=A0 =C2=A0redundancy RTP stream, by setting RepairedRtpStreamId value fo= r
=C2=A0 =C2=A0the redundancy RTP stream to the RtpStreamId value of the sour= ce
=C2=A0 =C2=A0RTP stream. The redundancy RTP stream MAY (but need not) have = an
=C2=A0 =C2=A0"a=3Drid" line of its own, in which case the RtpStre= amId SDES item value
=C2=A0 =C2=A0will be different from the corresponding source RTP stream.
---- End changes ----

The -simulcast draft would be entirely agnostic to this clarification of &q= uot;a=3Drid" and RepairedRtpStreamId usage and thereby transparently a= llow using redundancy RTP streams with simulcast.

/Bo
(as individual)

> -----Original Message-----
> From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]
> Sent: den 13 mars 2017 14:43
> To: Bo Burman <bo.burman@= ericsson.com>
> Cc: mmusic (mmusic@ietf.org) &l= t;mmusic@ietf.org>; Taylor Brands= tetter (deadbeef@google.com)
> <deadbeef@google.com>= ; draft-ietf-mmusic-rid@i= etf.org; draft-ietf-mmusic-sdp-simulcast@ietf.org
> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulc= ast
>
> 2017-03-13 14:41 GMT+01= :00 Bo Burman <bo.burman@erics= son.com>:
> > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already de= fined on RTP level by -avtext-rid. If we have
> preferences on how to best use them with redundancy RTP streams in gen= eral, I suggest we add text to -mmusic-rid
> about it. This would be regardless if we go for option A or B, but dec= ided once and for all, thus applicable to RFC 4588 rtx
> and FLEX-FEC alike.
>
> Agreed.
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

--94eb2c05ae0273c57305553ad70b-- From nobody Wed Jul 26 09:30: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 4A9A5131D12; Wed, 26 Jul 2017 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MTNqj0cN9PJ; Wed, 26 Jul 2017 09:30:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85C6131D10; Wed, 26 Jul 2017 09:30:07 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6QGU08Z025788 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Jul 2017 11:30:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Bernard Aboba , Bo Burman Cc: =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "draft-ietf-mmusic-rid@ietf.org" , "mmusic (mmusic@ietf.org)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: Adam Roach Message-ID: Date: Wed, 26 Jul 2017 11:29:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ED5712AAF60391305E7F1F1B" Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 16:30:10 -0000 This is a multi-part message in MIME format. --------------ED5712AAF60391305E7F1F1B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Future-proofness. Recall that the original design here was to give redundancy streams the same ID as the stream they're repairing, but there were objections that doing so would preclude using the mechanism to talk about redundancy streams in SDP if such a need ever arose in the future. So, we allow for signaling of these IDs in SDP, but (since as you correctly point out there are no concrete use cases at the moment) do not require it. You seem to think this is a problem. Can you describe a scenario in which it causes interop issues or additional implementation complexity? /a On 7/26/17 11:21, Bernard Aboba wrote: > Why would a redundancy RTP stream have an "a=rid" line of its own? I > am struggling to find a use case for this. > > On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman > wrote: > > To follow up on this, I suggest making the following addition to > draft-ietf-mmusic-rid: > > ---- AFTER this text in section 4 ---- > > An "a=rid" SDP media attribute specifies restrictions defining a > unique RTP payload configuration identified via the "rid-id" field. > This value binds the restriction to the RTP Stream identified > by its > RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, > implementations that use the "a=rid" parameter in SDP MUST support > the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such > implementations MUST send it for all streams in an SDP media > description ("m=") that have "a=rid" lines remaining after applying > the rules in Section 6 and its subsections. > > ---- ... add this proposed, new text ---- > > Implementations that use the "a=rid" parameter in SDP and that > make use of redundancy RTP streams [RFC7656], e.g. RTP RTX > [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme], > for any of the source RTP streams that have "a=rid" lines remaining > after applying the rules in Section 6 and its subsections, MUST > support and use RepairedRtpStreamId SDES item described in > [I-D.ietf-avtext-rid] for those redundancy RTP streams. This > provides > the binding between the source RTP stream and the corresponding > redundancy RTP stream, by setting RepairedRtpStreamId value for > the redundancy RTP stream to the RtpStreamId value of the source > RTP stream. The redundancy RTP stream MAY (but need not) have an > "a=rid" line of its own, in which case the RtpStreamId SDES > item value > will be different from the corresponding source RTP stream. > > ---- End changes ---- > > The -simulcast draft would be entirely agnostic to this > clarification of "a=rid" and RepairedRtpStreamId usage and thereby > transparently allow using redundancy RTP streams with simulcast. > > /Bo > (as individual) > > > -----Original Message----- > > From: Iñaki Baz Castillo [mailto:ibc@aliax.net > ] > > Sent: den 13 mars 2017 14:43 > > To: Bo Burman > > > Cc: mmusic (mmusic@ietf.org ) > >; Taylor Brandstetter > (deadbeef@google.com ) > > >; > draft-ietf-mmusic-rid@ietf.org > ; > draft-ietf-mmusic-sdp-simulcast@ietf.org > > > Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with > simulcast > > > > 2017-03-13 14:41 GMT+01:00 Bo Burman >: > > > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already > defined on RTP level by -avtext-rid. If we have > > preferences on how to best use them with redundancy RTP streams > in general, I suggest we add text to -mmusic-rid > > about it. This would be regardless if we go for option A or B, > but decided once and for all, thus applicable to RFC 4588 rtx > > and FLEX-FEC alike. > > > > Agreed. > > > > > > -- > > Iñaki Baz Castillo > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > > --------------ED5712AAF60391305E7F1F1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Future-proofness.

Recall that the original design here was to give redundancy streams the same ID as the stream they're repairing, but there were objections that doing so would preclude using the mechanism to talk about redundancy streams in SDP if such a need ever arose in the future. So, we allow for signaling of these IDs in SDP, but (since as you correctly point out there are no concrete use cases at the moment) do not require it.

You seem to think this is a problem. Can you describe a scenario in which it causes interop issues or additional implementation complexity?

/a

On 7/26/17 11:21, Bernard Aboba wrote:
Why would a redundancy RTP stream have an "a=rid" line of its own?  I am struggling to find a use case for this. 

On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:
To follow up on this, I suggest making the following addition to draft-ietf-mmusic-rid:

---- AFTER this text in section 4 ----

   An "a=rid" SDP media attribute specifies restrictions defining a
   unique RTP payload configuration identified via the "rid-id" field.
   This value binds the restriction to the RTP Stream identified by its
   RTP Stream Identifier SDES item [I-D.ietf-avtext-rid].  To be clear,
   implementations that use the "a=rid" parameter in SDP MUST support
   the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].  Such
   implementations MUST send it for all streams in an SDP media
   description ("m=") that have "a=rid" lines remaining after applying
   the rules in Section 6 and its subsections.

---- ... add this proposed, new text ----

   Implementations that use the "a=rid" parameter in SDP and that
   make use of redundancy RTP streams [RFC7656], e.g. RTP RTX
   [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme],
   for any of the source RTP streams that have "a=rid" lines remaining
   after applying the rules in Section 6 and its subsections, MUST
   support and use RepairedRtpStreamId SDES item described in
   [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provides
   the binding between the source RTP stream and the corresponding
   redundancy RTP stream, by setting RepairedRtpStreamId value for
   the redundancy RTP stream to the RtpStreamId value of the source
   RTP stream. The redundancy RTP stream MAY (but need not) have an
   "a=rid" line of its own, in which case the RtpStreamId SDES item value
   will be different from the corresponding source RTP stream.

---- End changes ----

The -simulcast draft would be entirely agnostic to this clarification of "a=rid" and RepairedRtpStreamId usage and thereby transparently allow using redundancy RTP streams with simulcast.

/Bo
(as individual)

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
> Sent: den 13 mars 2017 14:43
> To: Bo Burman <bo.burman@ericsson.com>
> Cc: mmusic (mmusic@ietf.org) <mmusic@ietf.org>; Taylor Brandstetter (deadbeef@google.com)
> <deadbeef@google.com>; draft-ietf-mmusic-rid@ietf.org; draft-ietf-mmusic-sdp-simulcast@ietf.org
> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
>
> 2017-03-13 14:41 GMT+01:00 Bo Burman <bo.burman@ericsson.com>:
> > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined on RTP level by -avtext-rid. If we have
> preferences on how to best use them with redundancy RTP streams in general, I suggest we add text to -mmusic-rid
> about it. This would be regardless if we go for option A or B, but decided once and for all, thus applicable to RFC 4588 rtx
> and FLEX-FEC alike.
>
> Agreed.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------ED5712AAF60391305E7F1F1B-- From nobody Wed Jul 26 09:35: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 D0A58131D10; Wed, 26 Jul 2017 09:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWFcSqatpByc; Wed, 26 Jul 2017 09:35:16 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3232F1320AE; Wed, 26 Jul 2017 09:35:16 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id k43so84371186uaf.3; Wed, 26 Jul 2017 09:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IK5ABWMYmu4wCNQ2Rcr5cA4EUtDmjlCWHe1bnMzgI9U=; b=ZNQ1HwWABJ0UGZtz9zwEgIYWZ/ZnR9A6aTcciIXxNLHSopEPgOhHOH0AWE9xkfFVVu hSDU2gzBwfDHvqUM6hnMHqZwZpXLzUr6C3myavO0pOaPbuTJN9pswS71KZswhv+69ObE lvvxDaou/FVyehT0+kmouOdDr/aLnxANYC4SYKTxuW074jzdt4Wo2tdqvqDfFto6MaGz ymHb9C19bfoDGG3hCFg3svb0A30NqV0fI0uPOZ7nRlHw92mCdOp5Q1H0vtwEVaJpNZ2N 8CmbTyuWLNv0+LbqiCNYAobjui114sAYtcNzvADH+3PvSHE5Gcsk66BidCi8wYbxYdAL BB3Q== 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=IK5ABWMYmu4wCNQ2Rcr5cA4EUtDmjlCWHe1bnMzgI9U=; b=tXbPGe6C/VrKw5+UKRWJVRXZqout6x5TdMltb3Ck0piuKInP1sTBkX8SLVuEX4LTey /da4Klo/v0fPPOZPFBxl5nLxsfjOlEqioKPuoFCNP2fomBt8A0/41xdXibUnp41gM21A hpwGPWyskwvmavihYh4+I0ebW497ARk4Yw0bkNkyMGOmot6EEN0tc/HcjuAz0ccqlB92 TYdO+vgfewt+rQnxRS6ppu9h5sSBKO6YCmOQfNNzzme13cNpJpTbvAxnnnA6Z+WKtd6o MaXM5yObKmz1tJmaBWaQZZhb+YGKFuWq0f25oC6D+G5/nhOYdj59e+sYpwh+YZOABKcH vPEg== X-Gm-Message-State: AIVw110AAvoOW8ePDVjMpylNPPqDb2QVfUxPqeLXh3cdPl62qK/EHdPj uDZBZyh4BH3fDtUCta0jqbuQf1AEvkCsqZI= X-Received: by 10.159.52.79 with SMTP id s15mr1055958uab.157.1501086915069; Wed, 26 Jul 2017 09:35:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.36.111 with HTTP; Wed, 26 Jul 2017 09:34:54 -0700 (PDT) In-Reply-To: References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> From: Bernard Aboba Date: Wed, 26 Jul 2017 09:34:54 -0700 Message-ID: To: Adam Roach Cc: Bo Burman , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "draft-ietf-mmusic-rid@ietf.org" , "mmusic (mmusic@ietf.org)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Content-Type: multipart/alternative; boundary="f403043ed1d4598cfd05553b084d" Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 16:35:19 -0000 --f403043ed1d4598cfd05553b084d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Currently the WebRTC API only exposes RIDs used for media streams, not for redundancy streams and JSEP currently doesn't indicate whether it is permitted for redundancy streams to have their own RIDs. So adding this text creates a potential ambiguity. On Wed, Jul 26, 2017 at 9:29 AM, Adam Roach wrote: > Future-proofness. > > Recall that the original design here was to give redundancy streams the > same ID as the stream they're repairing, but there were objections that > doing so would preclude using the mechanism to talk about redundancy > streams in SDP if such a need ever arose in the future. So, we allow for > signaling of these IDs in SDP, but (since as you correctly point out ther= e > are no concrete use cases at the moment) do not require it. > > You seem to think this is a problem. Can you describe a scenario in which > it causes interop issues or additional implementation complexity? > > /a > > > On 7/26/17 11:21, Bernard Aboba wrote: > > Why would a redundancy RTP stream have an "a=3Drid" line of its own? I a= m > struggling to find a use case for this. > > On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman wrote: > >> To follow up on this, I suggest making the following addition to >> draft-ietf-mmusic-rid: >> >> ---- AFTER this text in section 4 ---- >> >> An "a=3Drid" SDP media attribute specifies restrictions defining a >> unique RTP payload configuration identified via the "rid-id" field. >> This value binds the restriction to the RTP Stream identified by its >> RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, >> implementations that use the "a=3Drid" parameter in SDP MUST support >> the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such >> implementations MUST send it for all streams in an SDP media >> description ("m=3D") that have "a=3Drid" lines remaining after applyi= ng >> the rules in Section 6 and its subsections. >> >> ---- ... add this proposed, new text ---- >> >> Implementations that use the "a=3Drid" parameter in SDP and that >> make use of redundancy RTP streams [RFC7656], e.g. RTP RTX >> [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme], >> for any of the source RTP streams that have "a=3Drid" lines remaining >> after applying the rules in Section 6 and its subsections, MUST >> support and use RepairedRtpStreamId SDES item described in >> [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provides >> the binding between the source RTP stream and the corresponding >> redundancy RTP stream, by setting RepairedRtpStreamId value for >> the redundancy RTP stream to the RtpStreamId value of the source >> RTP stream. The redundancy RTP stream MAY (but need not) have an >> "a=3Drid" line of its own, in which case the RtpStreamId SDES item va= lue >> will be different from the corresponding source RTP stream. >> >> ---- End changes ---- >> >> The -simulcast draft would be entirely agnostic to this clarification of >> "a=3Drid" and RepairedRtpStreamId usage and thereby transparently allow = using >> redundancy RTP streams with simulcast. >> >> /Bo >> (as individual) >> >> > -----Original Message----- >> > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] >> > Sent: den 13 mars 2017 14:43 >> > To: Bo Burman >> > Cc: mmusic (mmusic@ietf.org) ; Taylor Brandstetter ( >> deadbeef@google.com) >> > ; draft-ietf-mmusic-rid@ietf.org; >> draft-ietf-mmusic-sdp-simulcast@ietf.org >> > Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with >> simulcast >> > >> > 2017-03-13 14:41 GMT+01:00 Bo Burman : >> > > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already >> defined on RTP level by -avtext-rid. If we have >> > preferences on how to best use them with redundancy RTP streams in >> general, I suggest we add text to -mmusic-rid >> > about it. This would be regardless if we go for option A or B, but >> decided once and for all, thus applicable to RFC 4588 rtx >> > and FLEX-FEC alike. >> > >> > Agreed. >> > >> > >> > -- >> > I=C3=B1aki Baz Castillo >> > >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > --f403043ed1d4598cfd05553b084d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently the WebRTC API only exposes RIDs used for media = streams, not for redundancy streams and JSEP currently doesn't indicate= whether it is permitted for redundancy streams to have their own RIDs.=C2= =A0

So adding this text creates a potential ambiguity. = =C2=A0

On Wed, Jul 26, 2017 at 9:29 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
Future-proofness.
Recall that the original design here was to give redundancy streams the same ID as the stream they're repairing, but there were objections that doing so would preclude using the mechanism to talk about redundancy streams in SDP if such a need ever arose in the future. So, we allow for signaling of these IDs in SDP, but (since as you correctly point out there are no concrete use cases at the moment) do not require it.

You seem to think this is a problem. Can you describe a scenario in which it causes interop issues or additional implementation complexity?

/a


On 7/26/17 11:21, Bernard Aboba wrote:
Why would a redundancy RTP stream have an "a=3D= rid" line of its own?=C2=A0 I am struggling to find a use case for this.= =C2=A0

On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:
To follow up on this, I suggest making the following addition to draft-ietf-mmusic-rid:

---- AFTER this text in section 4 ----

=C2=A0 =C2=A0An "a=3Drid" SDP media attribute specifi= es restrictions defining a
=C2=A0 =C2=A0unique RTP payload configuration identified via th= e "rid-id" field.
=C2=A0 =C2=A0This value binds the restriction to the RTP Stream identified by its
=C2=A0 =C2=A0RTP Stream Identifier SDES item [I-D.ietf-avtext-r= id].=C2=A0 To be clear,
=C2=A0 =C2=A0implementations that use the "a=3Drid" p= arameter in SDP MUST support
=C2=A0 =C2=A0the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].=C2=A0 Such
=C2=A0 =C2=A0implementations MUST send it for all streams in an= SDP media
=C2=A0 =C2=A0description ("m=3D") that have "a= =3Drid" lines remaining after applying
=C2=A0 =C2=A0the rules in Section 6 and its subsections.

---- ... add this proposed, new text ----

=C2=A0 =C2=A0Implementations that use the "a=3Drid" p= arameter in SDP and that
=C2=A0 =C2=A0make use of redundancy RTP streams [RFC7656], e.g.= RTP RTX
=C2=A0 =C2=A0[RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme],
=C2=A0 =C2=A0for any of the source RTP streams that have "= a=3Drid" lines remaining
=C2=A0 =C2=A0after applying the rules in Section 6 and its subsections, MUST
=C2=A0 =C2=A0support and use RepairedRtpStreamId SDES item desc= ribed in
=C2=A0 =C2=A0[I-D.ietf-avtext-rid] for those redundancy RTP str= eams. This provides
=C2=A0 =C2=A0the binding between the source RTP stream and the corresponding
=C2=A0 =C2=A0redundancy RTP stream, by setting RepairedRtpStrea= mId value for
=C2=A0 =C2=A0the redundancy RTP stream to the RtpStreamId value= of the source
=C2=A0 =C2=A0RTP stream. The redundancy RTP stream MAY (but nee= d not) have an
=C2=A0 =C2=A0"a=3Drid" line of its own, in which case= the RtpStreamId SDES item value
=C2=A0 =C2=A0will be different from the corresponding source RT= P stream.

---- End changes ----

The -simulcast draft would be entirely agnostic to this clarification of "a=3Drid" and RepairedRtpStreamId us= age and thereby transparently allow using redundancy RTP streams with simulcast.

/Bo
(as individual)

> -----Original Message-----
> From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]
> Sent: den 13 mars 2017 14:43
> To: Bo Burman <bo.burman@ericsson.com>
> Cc: mmusic (mmusic@ietf.org) <mmusic@ietf.org>; Taylor Brandstetter (deadbeef@google.com)
> <deadbeef@google.com>; draft-ietf-mmusic-rid@ietf.org; draft-ietf-mmusic-sdp-simulcast@ietf.org
> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
>
> 2017-03-13 14:41 = GMT+01:00 Bo Burman <bo.burman@ericsson.com>:
> > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined on RTP level by -avtext-rid. If we have
> preferences on how to best use them with redundancy RTP streams in general, I suggest we add text to -mmusic-rid
> about it. This would be regardless if we go for option A or B, but decided once and for all, thus applicable to RFC 4588 rtx
> and FLEX-FEC alike.
>
> Agreed.
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
_______________________________________________
mmusic mailing list
mmusic= @ietf.org
https://www.ietf.org/mailman/listin= fo/mmusic



--f403043ed1d4598cfd05553b084d-- From nobody Wed Jul 26 09:48: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 7A70C1320BA for ; Wed, 26 Jul 2017 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iscgnVvQ7pYy for ; Wed, 26 Jul 2017 09:48:21 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 BCA56131D28 for ; Wed, 26 Jul 2017 09:48:21 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id x3so81006513oia.1 for ; Wed, 26 Jul 2017 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=COxc6C3OvAtAX7LUeUNhnq/cCykIFdL15B3KqL58g4c=; b=HLygUPVWiyxSZlyivw88TAnPmdVpL/EbpeoHjs4PyTSeBfQxGDv3Jn1XNSHqs6Rifk KOQNvfVU2mBZP2h3JLXldN+5974Lfj44SusH3GkGsa3pyXtEbLcg9OoZl60WOV06KJnz 3ePg3OAbyYc2clpSND506Kr6Vr7GEd/Y/uZtPqCjyJZW/IAm1EH2pjyim9M7Y9IJbS4W A0tnNUbe7IBWGg0DrNOa0IlyzgbQHeI125j2llEv7f0KBItihefhMx908WZv4MryPnBM LSIPiL0wcOKB73LIm2FBNN6OWjCuD+jiRsf/haj7RhpQI338EHRfqxNupoPcVtAmPXuh miBg== 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=COxc6C3OvAtAX7LUeUNhnq/cCykIFdL15B3KqL58g4c=; b=dI8YbPj0KI0aTSyJgPthfY+EQA+mRdf3bWKBFb3c6cOc97FIR4uqVgI93LNBZI/8hl vDhJJbOGptXSj0MDikrQNRoOHZoKDE8eRK+kZn5EcJOshkuFkYCR5NG4elGRhTZwDrSJ luXPYpstw+yjdkhwVn8WrVV2RzjFyfHRQhx+y8unCsygPPUseYszt3+N0aXYaurDM2lx 3J6NaTXjtoEHOKT7MUbz+ycr9vTWUFKQi/qKLX/F7uJDz7Dvr7FclXVkgNZ61YWlUy9J Ajw6J0UKGJC8WL6T1C5gmcGGcC0QGxlPqpN7/3ipxvOIgEfEIr7iST/eelKAScMVNCNv JFZw== X-Gm-Message-State: AIVw112TC3ykuTt8N2G4oFElWPVYhF3tIg3ZuoGxhmA0Cbb4YrY8Sp8Z OC+oYTOdHRXcBRSGz7xCk95WMkHY37dJ X-Received: by 10.202.230.212 with SMTP id d203mr1620805oih.59.1501087700644; Wed, 26 Jul 2017 09:48:20 -0700 (PDT) MIME-Version: 1.0 References: <3A98F0E8-772E-40E3-A872-5414AC8FDF35@iii.ca> <12EA18B8-39F0-491F-92B6-D41F3D640209@iii.ca> In-Reply-To: From: Peter Thatcher Date: Wed, 26 Jul 2017 16:48:09 +0000 Message-ID: To: Bernard Aboba , Adam Roach Cc: Bo Burman , =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= , "draft-ietf-mmusic-rid@ietf.org" , "mmusic (mmusic@ietf.org)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" Content-Type: multipart/alternative; boundary="001a1141aede2ccf4805553b37ea" Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 16:48:26 -0000 --001a1141aede2ccf4805553b37ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RSIDs on source streams and RRIDs on repair streams make sense. While we included the ability to have RSIDs on repair streams into the header extensions, I don't see any use for them in the SDP and calling them "a=3Drid" is just confusing. If anything, they should be called something else, like "a=3Drsid". But again, I don't see any point. On Wed, Jul 26, 2017 at 9:35 AM Bernard Aboba wrote: > Currently the WebRTC API only exposes RIDs used for media streams, not fo= r > redundancy streams and JSEP currently doesn't indicate whether it is > permitted for redundancy streams to have their own RIDs. > > So adding this text creates a potential ambiguity. > > On Wed, Jul 26, 2017 at 9:29 AM, Adam Roach wrote: > >> Future-proofness. >> >> Recall that the original design here was to give redundancy streams the >> same ID as the stream they're repairing, but there were objections that >> doing so would preclude using the mechanism to talk about redundancy >> streams in SDP if such a need ever arose in the future. So, we allow for >> signaling of these IDs in SDP, but (since as you correctly point out the= re >> are no concrete use cases at the moment) do not require it. >> >> You seem to think this is a problem. Can you describe a scenario in whic= h >> it causes interop issues or additional implementation complexity? >> >> /a >> >> >> On 7/26/17 11:21, Bernard Aboba wrote: >> >> Why would a redundancy RTP stream have an "a=3Drid" line of its own? I = am >> struggling to find a use case for this. >> >> On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman wrote= : >> >>> To follow up on this, I suggest making the following addition to >>> draft-ietf-mmusic-rid: >>> >>> ---- AFTER this text in section 4 ---- >>> >>> An "a=3Drid" SDP media attribute specifies restrictions defining a >>> unique RTP payload configuration identified via the "rid-id" field. >>> This value binds the restriction to the RTP Stream identified by its >>> RTP Stream Identifier SDES item [I-D.ietf-avtext-rid]. To be clear, >>> implementations that use the "a=3Drid" parameter in SDP MUST support >>> the RtpStreamId SDES item described in [I-D.ietf-avtext-rid]. Such >>> implementations MUST send it for all streams in an SDP media >>> description ("m=3D") that have "a=3Drid" lines remaining after apply= ing >>> the rules in Section 6 and its subsections. >>> >>> ---- ... add this proposed, new text ---- >>> >>> Implementations that use the "a=3Drid" parameter in SDP and that >>> make use of redundancy RTP streams [RFC7656], e.g. RTP RTX >>> [RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexible-fec-scheme], >>> for any of the source RTP streams that have "a=3Drid" lines remainin= g >>> after applying the rules in Section 6 and its subsections, MUST >>> support and use RepairedRtpStreamId SDES item described in >>> [I-D.ietf-avtext-rid] for those redundancy RTP streams. This provide= s >>> the binding between the source RTP stream and the corresponding >>> redundancy RTP stream, by setting RepairedRtpStreamId value for >>> the redundancy RTP stream to the RtpStreamId value of the source >>> RTP stream. The redundancy RTP stream MAY (but need not) have an >>> "a=3Drid" line of its own, in which case the RtpStreamId SDES item v= alue >>> will be different from the corresponding source RTP stream. >>> >>> ---- End changes ---- >>> >>> The -simulcast draft would be entirely agnostic to this clarification o= f >>> "a=3Drid" and RepairedRtpStreamId usage and thereby transparently allow= using >>> redundancy RTP streams with simulcast. >>> >>> /Bo >>> (as individual) >>> >>> > -----Original Message----- >>> > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] >>> > Sent: den 13 mars 2017 14:43 >>> > To: Bo Burman >>> > Cc: mmusic (mmusic@ietf.org) ; Taylor Brandstetter ( >>> deadbeef@google.com) >>> > ; draft-ietf-mmusic-rid@ietf.org; >>> draft-ietf-mmusic-sdp-simulcast@ietf.org >>> > Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with >>> simulcast >>> > >>> > 2017-03-13 14:41 GMT+01:00 Bo Burman : >>> > > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already >>> defined on RTP level by -avtext-rid. If we have >>> > preferences on how to best use them with redundancy RTP streams in >>> general, I suggest we add text to -mmusic-rid >>> > about it. This would be regardless if we go for option A or B, but >>> decided once and for all, thus applicable to RFC 4588 rtx >>> > and FLEX-FEC alike. >>> > >>> > Agreed. >>> > >>> > >>> > -- >>> > I=C3=B1aki Baz Castillo >>> > >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> >> > --001a1141aede2ccf4805553b37ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
RSIDs on source streams and RRIDs on repair streams make s= ense.

While we included the ability to have RSIDs on rep= air streams into the header extensions, I don't see any use for them in= the SDP and calling them "a=3Drid" is just confusing.=C2=A0 If a= nything, they should be called something else, like "a=3Drsid".= =C2=A0 But again, I don't see any point. =C2=A0

On Wed, Jul 26, 2017 at 9:35 AM Bernard= Aboba <bernard.aboba@gmail.c= om> wrote:
= Currently the WebRTC API only exposes RIDs used for media streams, not for = redundancy streams and JSEP currently doesn't indicate whether it is pe= rmitted for redundancy streams to have their own RIDs.=C2=A0

=
So adding this text creates a potential ambiguity. =C2=A0
<= div class=3D"gmail_extra">
On Wed, Jul 26, 20= 17 at 9:29 AM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
Future-proofness.

Recall that the original design here was to give redundancy streams the same ID as the stream they're repairing, but there were objections that doing so would preclude using the mechanism to talk about redundancy streams in SDP if such a need ever arose in the future. So, we allow for signaling of these IDs in SDP, but (since as you correctly point out there are no concrete use cases at the moment) do not require it.

You seem to think this is a problem. Can you describe a scenario in which it causes interop issues or additional implementation complexity?

/a


On 7/26/17 11:21, Bernard Aboba wrote:
Why would a redundancy RTP stream have an "a=3D= rid" line of its own?=C2=A0 I am struggling to find a use case for this.= =C2=A0

On Thu, Jul 6, 2017 at 4:49 AM, Bo Burman <bo.burman@ericsson.com> wrote:
To follow up on this, I suggest making the following addition to draft-ietf-mmusic-rid:

---- AFTER this text in section 4 ----

=C2=A0 =C2=A0An "a=3Drid" SDP media attribute specifi= es restrictions defining a
=C2=A0 =C2=A0unique RTP payload configuration identified via th= e "rid-id" field.
=C2=A0 =C2=A0This value binds the restriction to the RTP Stream identified by its
=C2=A0 =C2=A0RTP Stream Identifier SDES item [I-D.ietf-avtext-r= id].=C2=A0 To be clear,
=C2=A0 =C2=A0implementations that use the "a=3Drid" p= arameter in SDP MUST support
=C2=A0 =C2=A0the RtpStreamId SDES item described in [I-D.ietf-avtext-rid].=C2=A0 Such
=C2=A0 =C2=A0implementations MUST send it for all streams in an= SDP media
=C2=A0 =C2=A0description ("m=3D") that have "a= =3Drid" lines remaining after applying
=C2=A0 =C2=A0the rules in Section 6 and its subsections.

---- ... add this proposed, new text ----

=C2=A0 =C2=A0Implementations that use the "a=3Drid" p= arameter in SDP and that
=C2=A0 =C2=A0make use of redundancy RTP streams [RFC7656], e.g.= RTP RTX
=C2=A0 =C2=A0[RFC4588] or FEC [RFC5109][I-D.ietf-payload-flexib= le-fec-scheme],
=C2=A0 =C2=A0for any of the source RTP streams that have "= a=3Drid" lines remaining
=C2=A0 =C2=A0after applying the rules in Section 6 and its subsections, MUST
=C2=A0 =C2=A0support and use RepairedRtpStreamId SDES item desc= ribed in
=C2=A0 =C2=A0[I-D.ietf-avtext-rid] for those redundancy RTP str= eams. This provides
=C2=A0 =C2=A0the binding between the source RTP stream and the corresponding
=C2=A0 =C2=A0redundancy RTP stream, by setting RepairedRtpStrea= mId value for
=C2=A0 =C2=A0the redundancy RTP stream to the RtpStreamId value= of the source
=C2=A0 =C2=A0RTP stream. The redundancy RTP stream MAY (but nee= d not) have an
=C2=A0 =C2=A0"a=3Drid" line of its own, in which case= the RtpStreamId SDES item value
=C2=A0 =C2=A0will be different from the corresponding source RT= P stream.

---- End changes ----

The -simulcast draft would be entirely agnostic to this clarification of "a=3Drid" and RepairedRtpStreamId us= age and thereby transparently allow using redundancy RTP streams with simulcast.

/Bo
(as individual)

> -----Original Message-----
> From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]
> Sent: den 13 m= ars 2017 14:43
> To: Bo Burman <bo.burman@ericsson.com>
> Cc: mmusic (mmusic@ietf.org) <mmusic@ietf.org>; Taylor Brandstetter (deadbeef@google.com)
> <deadbeef@google.com>; draft-ietf-mmusic-rid@ietf.org; draft-ietf-mmusic-sdp-simulcast@ietf.org
> Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast
>
= > 2017-03-13 14:41 GMT+01:00 Bo Burman <bo.burman@ericsson.com>:
> > [BoB] Usage of RepairedRtpStreamId and RtpStreamId are already defined on RTP level by -avtext-rid. If we have
> preferences on how to best use them with redundancy RTP streams in general, I suggest we add text to -mmusic-rid
> about it. This would be regardless if we go for option A or B, but decided once and for all, thus applicable to RFC 4588 rtx
> and FLEX-FEC alike.
>
> Agreed.
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
_______________________________________________
mmusic mailing list
mmusic= @ietf.org
https://www.ietf.org/mailman/listinfo/mm= usic



--001a1141aede2ccf4805553b37ea-- From nobody Wed Jul 26 10:01: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 919D01320B9; Wed, 26 Jul 2017 10:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQIyBOnFrjaQ; Wed, 26 Jul 2017 10:01:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837E0131D69; Wed, 26 Jul 2017 10:01:39 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v6QH1XQF031474 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Jul 2017 12:01:33 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Bernard Aboba Cc: Bo Burman , =?UTF-8?Q?I=c3=b1aki_Baz_Castillo?= , "draft-ietf-mmusic-rid@ietf.org" , "mmusic (mmusic@ietf.org)" , "draft-ietf-mmusic-sdp-simulcast@ietf.org" References: From: Adam Roach Message-ID: <6580c4d8-4d07-a741-bd48-09a7a6024921@nostrum.com> Date: Wed, 26 Jul 2017 12:01:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [MMUSIC] FW: [rtcweb] How to signal RTX SSRCs with simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jul 2017 17:01:40 -0000 On 7/26/17 11:34, Bernard Aboba wrote: > Currently the WebRTC API only exposes RIDs used for media streams, not > for redundancy streams and JSEP currently doesn't indicate whether it > is permitted for redundancy streams to have their own RIDs. Not all SDP attributes are exposed or controllable through the WebRTC API, mostly because there's an SDP world outside WebRTC. For example, CLUE adds new group types to SDP, but we don't fret about surfacing them in web browsers. I think we can safely say that your typical WebRTC implementation will neither produce nor consume these; they'll just be safely ignored. Well, right up until the moment that you find a use case that requires them, at least. /a From nobody Wed Jul 26 17: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 30940131F0D for ; Wed, 26 Jul 2017 17:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 RqH93E3BddDP for ; Wed, 26 Jul 2017 17:23:17 -0700 (PDT) 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 0756B131F0A for ; Wed, 26 Jul 2017 17:23:17 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id p3so53243895qtg.2 for ; Wed, 26 Jul 2017 17:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7NEgK1ZmaIBNVknTHdFHHE/4RN/mJQWmJmC4PsJXBi4=; b=OV8zm06ZykgecuFc4Or7fP16hD0JV8JkGxOcMRD81bqkj72XMWw7MVvaeCgGWrpSYN FaAHV+2V0VnS9FXGK0xyBPa8hhUkydpY07aIQek19qv6h7nvLk1QJYtajVrRMMTf+uuJ +ZVWTx1awn+gb41a2On6T4ekcr0O9ngWf4vsve2hsGFLSV81IgSpsZIiRYL20F+AE7Tu U31ICeqJ+kYxTl808uDietaR0cu/1Yl1Figvfpiu3y4+ZduphXkge3EtNEC4+9NVVDTi 61DWn/PeXhuCwQEmVEFX7eIn1lMX1sOArG4NW0lTn8B6m7c7Y2NBqW1E7h/RIweRiHkA fyag== 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=7NEgK1ZmaIBNVknTHdFHHE/4RN/mJQWmJmC4PsJXBi4=; b=iz/OJln1F+ndIhKgi1AUGcbqvs0QmJ64Osv6OJLdWy2t2o3pk8iu/ubol/risVofrK Qj6S5TMk55tY0BVaUr6bruqQCguYLfOjo+W0ODxcC8FB1wG/X8IMiF2huEBQEfQPZhmY GwnkaFc26qmIv3f3vTbCLMUCv/ZVincykp7OTXalO6g/t8Z2xqKAe0iTAH6h+XY3hWEo pkzDeuPs5Ru5XKG/vp0rTzq3QVzEtWCt/QZ9KS5G94ut4hOlouRJA8Wsvz/lr1cTqpDZ 5W9DtzUe1MFNUwBpKrk6v97aZl1hRssjYs7LYHYEWajtNfuHNbCdJS802g8INqMPxcGX MBPA== X-Gm-Message-State: AIVw112gfZIFLolo8qtbvaNdjJoZD99MXYOhmN0G64MVnfbZM92h57ZR j4hVI6mZVdnFGUekRCPPMKyfXdI6KOUcLvw= X-Received: by 10.200.52.100 with SMTP id v33mr3930669qtb.67.1501114995933; Wed, 26 Jul 2017 17:23:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.163.5 with HTTP; Wed, 26 Jul 2017 17:23:15 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Wed, 26 Jul 2017 17:23:15 -0700 Message-ID: To: mmusic WG Content-Type: multipart/alternative; boundary="001a1143b9281a0afc055541924c" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 00:23:19 -0000 --001a1143b9281a0afc055541924c Content-Type: text/plain; charset="UTF-8" Ping. Harald (the author of this document) is on sabbatical, so I'd appreciate some guidance from someone else familiar with IETF processes. It's already in the RFC editor queue, which seems like a problem. On Thu, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter wrote: > In the current state of WebRTC 1.0, track IDs are not guaranteed to be > symmetrical between the sending and receiving PeerConnection. This is > because "addTrack" not only creates an RtpSender, but a whole > RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with > a generated ID. So if "addTrack" is called, and a remote description is set > later, it's the MID that correlates the "m=" section with the track, not > the track ID, and the track ID in SDP is effectively ignored. > > This is all related to the "early media" functionality, and is explained > further in a blog post by Jan-Ivar; see the "Correlate by transceiver.mid" > section: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/ > > So, the question became "why signal track IDs at all?" This was brought up > in a May virtual interim (https://www.w3.org/2011/04/ > webrtc/wiki/May_2_2017), and we decided to investigate removing them. To > my knowledge this topic hasn't been brought up on this mailing list yet. > > Is this something still worth considering, or is it too late? "a=msid" > would switch to only containing the stream ID, not the track ID. > Implementers would presumably have a transitional period where they support > parsing both forms of "a=msid", after which they start generating the new > format, as we've done for other things. > > The benefits are that the SDP would be slightly smaller, and the > complexity of the standards could be slightly reduced. The downside is that > more applications that rely on track IDs would need to be updated (though > many will need to be updated anyway). > > Regardless of the outcome of this decision, "mmusic-msid" really ought to > be updated before publication. It's been out of sync with WebRTC 1.0 for > about a year; here's the first editor's draft that broke the track ID > symmetry: https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html > --001a1143b9281a0afc055541924c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ping. Harald (the author of this document) is on sabbatica= l, so I'd appreciate some guidance from someone else familiar with IETF= processes. It's already in the RFC editor queue, which seems like a pr= oblem.

On Th= u, Jul 20, 2017 at 6:41 PM, Taylor Brandstetter <deadbeef@google.com= > wrote:
In th= e current state of WebRTC 1.0, track IDs are not guaranteed to be symmetric= al between the sending and receiving PeerConnection. This is because "= addTrack" not only creates an RtpSender, but a whole RtpTransceiver, w= hich has an RtpReceiver, which has a MediaStreamTrack with a generated ID. = So if "addTrack" is called, and a remote description is set later= , it's the MID that correlates the "m=3D" section with the tr= ack, not the track ID, and the track ID in SDP is effectively ignored.
=
This is all related to the "early media" functiona= lity, and is explained further in a blog post by Jan-Ivar; see the "Co= rrelate by transceiver.mid" section:=C2=A0https://blog.moz= illa.org/webrtc/the-evolution-of-webrtc/

=
So, the question became "why signal track IDs at all?" This = was brought up in a May virtual interim (https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we decided to investigate removing them= . To my knowledge this topic hasn't been brought up on this mailing lis= t yet.

Is this something still worth considering, = or is it too late? "a=3Dmsid" would switch to only containing the= stream ID, not the track ID. Implementers would presumably have a transiti= onal period where they support parsing both forms of "a=3Dmsid", = after which they start generating the new format, as we've done for oth= er things.

The benefits are that the SDP would be = slightly smaller, and the complexity of the standards could be slightly red= uced. The downside is that more applications that rely on track IDs would n= eed to be updated (though many will need to be updated anyway).
<= br>
Regardless of the outcome of this decision, "mmusic-msid= " really ought to be updated before publication. It's been out of = sync with WebRTC 1.0 for about a year; here's the first editor's dr= aft that broke the track ID symmetry:=C2=A0https://w3c.git= hub.io/webrtc-pc/archives/20160722/webrtc.html

--001a1143b9281a0afc055541924c-- From nobody Thu Jul 27 12:28: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 71F15131C31 for ; Thu, 27 Jul 2017 12:28:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 3BoLlwCBGRBp for ; Thu, 27 Jul 2017 12:28:31 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 1171913216E for ; Thu, 27 Jul 2017 12:28:31 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id e124so155754619oig.2 for ; Thu, 27 Jul 2017 12:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=7uY25eg0w/aBDGMJ8RxewstCYzFEpmaYjgerR+Dv8Sg=; b=vsavCs536gKuyllYf/0rzOjRobep8YP5S/ILYDcq/mPvRNEmnVJdSqH7/1pzaFCDMr Y/iod0+43K3zMsSZyL4qYwtiVsHRmb5M77sqUxdY3/h7tUPzH/yLo8A0R9g3vBQeIymS XZ1wEQeTkSZm74Fu2puybpYjNis8dlrPrPba3Z5fgNgrT7eNjTQwYwrNkZbm+nyzkZLS WVLNXDXo6SE+wmZqLEyf19fs2mQPoZSAqEacpgqqdbxsUv0pYWIKIwTB6QNvMNw8LA5c LD4EkgHnBRYSwhRjtQlQo9/Lo131ubpblIUhCz2F1qm1/KZ+dFp/sGlnzUzLX/j6zG4t +tKA== 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; bh=7uY25eg0w/aBDGMJ8RxewstCYzFEpmaYjgerR+Dv8Sg=; b=srF7JswziNUkf9R61P7iVM2u9Xh7GbdX4l0A+9OgtRJOJQadUYkgP2fFC3ShUFijcB XJJVy2lRFFWpijOK3mDjbkSVsjOeA7WVh5KsZaHV3UxqJ/3GJFPthcUDIFwrKnRz8Ksy bmDJKeukOWGb1WDAx6oiXtTMC+yAMGxwQ4R5IKy+RwqWu3AOXDaH0p3ZlUeiQecDXbu+ sVYeh66MVJC6lvs50eBtl9bojbwYMx0S7sDhYxgfg2WUyVLOjX5JuJ6FCq04RudKP6it v9kVdwkBOJni+oS/fdSpzILGY7Jg3iaDt8cyDLucyvurXepnoyc+3hJux4sNp36NIUhi al4g== X-Gm-Message-State: AIVw110+Bh3cSg8TrGnCM+YamM5RZ7DFfuc+zhFe+nOHUu/3NMpM0Jlh K6NYblS7VX5VhpJLsSOY+uFA7DVNZiNX X-Received: by 10.202.230.212 with SMTP id d203mr5813639oih.59.1501183710272; Thu, 27 Jul 2017 12:28:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Thatcher Date: Thu, 27 Jul 2017 19:28:18 +0000 Message-ID: To: Taylor Brandstetter , mmusic WG Content-Type: multipart/alternative; boundary="001a1141aedecb859c05555191f9" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jul 2017 19:28:33 -0000 --001a1141aedecb859c05555191f9 Content-Type: text/plain; charset="UTF-8" So is the summary that you propose we remove the track ID from the MSID attribute? If so, I'm in favor. On Thu, Jul 20, 2017 at 6:42 PM Taylor Brandstetter wrote: > In the current state of WebRTC 1.0, track IDs are not guaranteed to be > symmetrical between the sending and receiving PeerConnection. This is > because "addTrack" not only creates an RtpSender, but a whole > RtpTransceiver, which has an RtpReceiver, which has a MediaStreamTrack with > a generated ID. So if "addTrack" is called, and a remote description is set > later, it's the MID that correlates the "m=" section with the track, not > the track ID, and the track ID in SDP is effectively ignored. > > This is all related to the "early media" functionality, and is explained > further in a blog post by Jan-Ivar; see the "Correlate by transceiver.mid" > section: https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/ > > So, the question became "why signal track IDs at all?" This was brought up > in a May virtual interim ( > https://www.w3.org/2011/04/webrtc/wiki/May_2_2017), and we decided to > investigate removing them. To my knowledge this topic hasn't been brought > up on this mailing list yet. > > Is this something still worth considering, or is it too late? "a=msid" > would switch to only containing the stream ID, not the track ID. > Implementers would presumably have a transitional period where they support > parsing both forms of "a=msid", after which they start generating the new > format, as we've done for other things. > > The benefits are that the SDP would be slightly smaller, and the > complexity of the standards could be slightly reduced. The downside is that > more applications that rely on track IDs would need to be updated (though > many will need to be updated anyway). > > Regardless of the outcome of this decision, "mmusic-msid" really ought to > be updated before publication. It's been out of sync with WebRTC 1.0 for > about a year; here's the first editor's draft that broke the track ID > symmetry: https://w3c.github.io/webrtc-pc/archives/20160722/webrtc.html > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1141aedecb859c05555191f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So is the summary that you propose we remove the track ID = from the MSID attribute?

If so, I'm in favor.
On Thu, Jul 20, 2017 at 6:42 P= M Taylor Brandstetter <deadbeef@g= oogle.com> wrote:
In the current state of WebRTC 1.0, track IDs are not guaranteed t= o be symmetrical between the sending and receiving PeerConnection. This is = because "addTrack" not only creates an RtpSender, but a whole Rtp= Transceiver, which has an RtpReceiver, which has a MediaStreamTrack with a = generated ID. So if "addTrack" is called, and a remote descriptio= n is set later, it's the MID that correlates the "m=3D" secti= on with the track, not the track ID, and the track ID in SDP is effectively= ignored.

This is all related to the "early media&q= uot; functionality, and is explained further in a blog post by Jan-Ivar; se= e the "Correlate by transceiver.mid" section:=C2=A0ht= tps://blog.mozilla.org/webrtc/the-evolution-of-webrtc/

So, the question became "why signal track IDs at all?" T= his was brought up in a May virtual interim (https://www.w3.org/2011/0= 4/webrtc/wiki/May_2_2017), and we decided to investigate removing them.= To my knowledge this topic hasn't been brought up on this mailing list= yet.

Is this something still worth considering, o= r is it too late? "a=3Dmsid" would switch to only containing the = stream ID, not the track ID. Implementers would presumably have a transitio= nal period where they support parsing both forms of "a=3Dmsid", a= fter which they start generating the new format, as we've done for othe= r things.

The benefits are that the SDP would be s= lightly smaller, and the complexity of the standards could be slightly redu= ced. The downside is that more applications that rely on track IDs would ne= ed to be updated (though many will need to be updated anyway).
Regardless of the outcome of this decision, "mmusic-msid&= quot; really ought to be updated before publication. It's been out of s= ync with WebRTC 1.0 for about a year; here's the first editor's dra= ft that broke the track ID symmetry:=C2=A0https://w3c.gith= ub.io/webrtc-pc/archives/20160722/webrtc.html
_______________________________________________
mmusic mailing list
mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
--001a1141aedecb859c05555191f9-- From nobody Thu Jul 27 19:00: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 5FC19126C23; Thu, 27 Jul 2017 19:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 nMxx8Nvi0q5T; Thu, 27 Jul 2017 19:00:41 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id A88FA131EDA; Thu, 27 Jul 2017 19:00:39 -0700 (PDT) X-AuditID: 1207440c-c4bff70000000b4f-74-597a9ac7d51b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 01.24.02895.7CA9A795; Thu, 27 Jul 2017 22:00:39 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6S20bwh026224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Jul 2017 22:00:38 -0400 From: Paul Kyzivat To: draft-ietf-mmusic-dtls-sdp.all@ietf.org Cc: General Area Review Team , IETF MMUSIC WG Message-ID: Date: Thu, 27 Jul 2017 22:00:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixO6iqHt8VlWkwfKtfBY77u5gs7j66jOL xdTlj1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJVx6mA/S8Fxzoq7t96yNTDeZe9i5OSQEDCR mDJ7GnMXIxeHkMAOJomjH3exQThXmSQezT/DClLFJqAlMefQfxYQW1jAR+JOczMziC0ioC3R MbkNrIZZIEri+OclTCA2r4C9xLNF28DqWQRUJX60TACrFxVIk5jx/TozRI2gxMmZT1gges0k 5m1+yAxhi0vcejKfCcKWl2jeOpt5AiPfLCQts5C0zELSMgtJywJGllWMcok5pbm6uYmZOcWp ybrFyYl5ealFuoZ6uZkleqkppZsYISHJs4Px2zqZQ4wCHIxKPLwPPlZGCrEmlhVX5h5ilORg UhLlnWRaESnEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPf15KpIId6UxMqq1KJ8mJQ0B4uSOK/q EnU/IYH0xJLU7NTUgtQimKwMB4eSBG/ETKBGwaLU9NSKtMycEoQ0EwcnyHAeoOFxIDW8xQWJ ucWZ6RD5U4y6HL9mbv3CJMSSl5+XKiXOe3kGUJEASFFGaR7cHFgqecUoDvSWMK8DyCgeYBqC m/QKaAkT0JKJTZUgS0oSEVJSDYzT+pofThMMv2y6kbE6yDfj5PyGK6EfQo/6BP1lcLO8Mq2h cO8z+dRTM97FXbO9dOlv8oyYuKzD1+eHPE3tF7x73HTf9De3otlf/XlnGbxy1+e7Yc6lC6QD ClLUZxyS3mnFY71/nRXDtmaGKcYrH774/zCuSuX1NWld51s+bbPFd61asuLdzf0SSizFGYmG WsxFxYkAIuQ65gADAAA= Archived-At: Subject: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 02:00:42 -0000 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-dtls-sdp-27 Reviewer: Paul Kyzivat Review Date: 2017-07-07 IETF LC End Date: 2017-07-24 IESG Telechat date: 2017-08-15 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. (These nits were reported by IdNits. I apologize for not noticing these during my Last Call review.) Issues: Major: 0 Minor: 0 Nits: 2 (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. (2) NIT: Obsolete informational reference (is this intentional?): RFC 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. From nobody Fri Jul 28 16:07: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 1EA9C131BFE; Fri, 28 Jul 2017 16:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zpmKbeeig1X; Fri, 28 Jul 2017 16:07:09 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7EC131D1E; Fri, 28 Jul 2017 16:07:09 -0700 (PDT) X-AuditID: c1b4fb25-607ff70000001eeb-57-597bc39a0c05 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.28.07915.A93CB795; Sat, 29 Jul 2017 01:07:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Sat, 29 Jul 2017 01:07:06 +0200 From: Christer Holmberg To: Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2g Date: Fri, 28 Jul 2017 23:07:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdT3f24epIg2uHWSx23N3BZnH11WcW i6nLH7NYrNhwgNWBxePv+w9MHkuW/GQKYIrisklJzcksSy3St0vgyrjblFAwSbDiY5dAA+MN gS5GTg4JAROJjtttLF2MXBxCAkcYJd6/u8AE4SxmlHi9egdzFyMHB5uAhUT3P22QuIhAI6NE 4/T9zCDdzALBEnv3b2MEsYUFgiS+/l0JZosAxZsePoWyjSR+3exnB7FZBFQl9h3awA4yk1fA V+L/G1OQsJCAvcTkGzOZQGxOAQeJqwuvgJUzCohJfD+1hglilbjErSfzmSCOFpBYsuc8M4Qt KvHy8T9WCFtJYu3h7Swg45kFNCXW79KHaFWUmNL9EGwkr4CgxMmZT1gmMIrOQjJ1FkLHLCQd s5B0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGDMHt/xW3cF4+Y3jIUYBDkYlHl7J 3dWRQqyJZcWVuYcYJTiYlUR43x8ECvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEk NTs1tSC1CCbLxMEp1cBoypSZObHnv1Gm/vvpKyY/C3Z6mLpprouilNedxtbaWM+PmXO6ihPX vL+eZjczWnHh1Uvslffs2sPEGubr6yx/r8AmzJB3XlGAjbf++N5Vc6+aqnVPnD6HIalVY179 iz9rfzdLrny5N/L6vdawPWfPzXSQfjAhtYUj9fvVfRF3209L3dq8Tu2FEktxRqKhFnNRcSIA N0DqgpUCAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 23:07:13 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJJ2xsIGZpeCByZWZlcmVuY2VzLg0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1XSANClNlbnQ6IDI4 IEp1bHkgMjAxNyAwNDowMQ0KVG86IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRm Lm9yZw0KQ2M6IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSA8Z2VuLWFydEBpZXRmLm9yZz47IElF VEYgTU1VU0lDIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbR2VuLWFydF0gR2VuLUFS VCBMYXN0IENhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTI3DQoNCkkg YW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5l cmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuIFBsZWFzZSB3 YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkIG9yIEFEIGJlZm9y ZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBGb3IgbW9yZSBpbmZvcm1hdGlv biwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0IDzigItodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9h cmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbW11 c2ljLWR0bHMtc2RwLTI3DQpSZXZpZXdlcjogUGF1bCBLeXppdmF0DQpSZXZpZXcgRGF0ZTogMjAx Ny0wNy0wNw0KSUVURiBMQyBFbmQgRGF0ZTogMjAxNy0wNy0yNA0KSUVTRyBUZWxlY2hhdCBkYXRl OiAyMDE3LTA4LTE1DQoNClN1bW1hcnk6DQoNClRoaXMgZHJhZnQgaXMgYmFzaWNhbGx5IHJlYWR5 IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBuaXRzIHRoYXQgc2hvdWxkIGJlIGZpeGVkIGJlZm9y ZSBwdWJsaWNhdGlvbi4NCg0KKFRoZXNlIG5pdHMgd2VyZSByZXBvcnRlZCBieSBJZE5pdHMuIEkg YXBvbG9naXplIGZvciBub3Qgbm90aWNpbmcgdGhlc2UgZHVyaW5nIG15IExhc3QgQ2FsbCByZXZp ZXcuKQ0KDQpJc3N1ZXM6DQoNCk1ham9yOiAwDQpNaW5vcjogMA0KTml0czogIDINCg0KKDEpIE5J VDogVW51c2VkIFJlZmVyZW5jZTogJ1JGQzUyNDUnIGlzIGRlZmluZWQgb24gbGluZSAxMDY1LCBi dXQgbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KDQpUaGlzIGlz IG5vdyByZWR1bmRhbnQgYmVjYXVzZSBhbGwgdGhlIHJlZmVyZW5jZXMgaW4gdGhlIHRleHQgaGF2 ZSBiZWVuIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy4NCg0KKDIpIE5JVDog T2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50ZW50aW9uYWw/KTog UkZDIDQ1NzINCg0KVGhpcyBpcyBub3cgb2Jzb2xldGUgYmVjYXVzZSBpdCBoYXMgYmVlbiByZXBs YWNlZCBieSBSRkM4MTIyLiBUaGlzIGRyYWZ0IHNob3VsZCBub3cgYmUgcmVmZXJlbmNpbmcgdGhh dC4NCg== From nobody Fri Jul 28 16:23: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 F333A131DFE; Fri, 28 Jul 2017 16:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWmJjJFEWKQY; Fri, 28 Jul 2017 16:23:35 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630E2131DB2; Fri, 28 Jul 2017 16:23:34 -0700 (PDT) X-AuditID: c1b4fb3a-81bff70000001b2f-aa-597bc7743727 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.84.06959.477CB795; Sat, 29 Jul 2017 01:23:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Sat, 29 Jul 2017 01:23:32 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" CC: General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pA= Date: Fri, 28 Jul 2017 23:23:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbHdW7fkeHWkwbKF2hY77u5gs7j66jOL xdTlj1ksVmw4wOrA4vH3/QcmjyVLfjIFMEVx2aSk5mSWpRbp2yVwZTz8fJix4Jh4xerHa1ga GH+IdTFyckgImEh8+XyYtYuRi0NI4AijxLEf/YwQzmJGieuHFzN1MXJwsAlYSHT/0waJiwhs ZZRY8XQ7G0g3s0CwxN792xhBbGGBIImvf1eC2SJA8aaHT6FsK4kFS1pZQWwWAVWJSb+vsIPY vAK+EhcuXQazhQSaGSV2Xc0DsTkF/CRO7H4DVs8oICbx/dQaJohd4hK3nsxngrhaQGLJnvPM ELaoxMvH/1ghbCWJtYe3s4DczCygKbF+lz5Eq6LElO6HUGsFJU7OfMIygVF0FpKpsxA6ZiHp mIWkYwEjyypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwMg5uOW31Q7Gg88dDzEKcDAq8fDu 31sdKcSaWFZcmXuIUYKDWUmE98gRoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNL UrNTUwtSi2CyTBycUg2Mq12bdkoy3eqU9ohObIl7UPnIQuTv3SbpPU5xk31sBBR+XrrO2PLg 9TXtzGvct5/++7I3t1ViZvTjGMFMH9UpD2rsvBLlV2gLy+Zz/D/3SbjLbEerb9Xx1PfznPdK eGlc6O7qPnrR3754yvLwGW+/3rrY6rD7bXrvpzKZKp+/NkInDvU/E9qixFKckWioxVxUnAgA bHFALpgCAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jul 2017 23:23:37 -0000 SGkgUGF1bCwNCg0KUmVnYXJkaW5nIHRoZSByZWZlcmVuY2UgdG8gUkZDIDQ1NzIsIHRoZSBuZXcg dGV4dCBpbiBzZWN0aW9uIDEwLjIuMSByZWZlcmVuY2VzIFJGQyA0NTcyLiBXZSBlYXJsaWVyIGFn cmVlZCB3ZSB3ZXJlIG5vdCBnb2luZyB0byB1cGRhdGUgdGhhdCB0ZXh0LCBhbmQga2VlcCBhbiBp bmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDQ1NzIuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBb bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0gDQpTZW50OiAyOSBKdWx5IDIw MTcgMDE6MDcNClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZw0KQ2M6IEdlbmVyYWwgQXJlYSBSZXZp ZXcgVGVhbSA8Z2VuLWFydEBpZXRmLm9yZz47IElFVEYgTU1VU0lDIFdHIDxtbXVzaWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogW0dlbi1hcnRdIEdlbi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZiBk cmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNw0KDQpIaSBQYXVsLA0KDQpUaGFua3MgZm9yIHRo ZSByZXZpZXcuIEknbGwgZml4IHJlZmVyZW5jZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHVdIA0KU2VudDogMjggSnVseSAyMDE3IDA0OjAxDQpUbzogZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnDQpDYzogR2VuZXJhbCBBcmVhIFJl dmlldyBUZWFtIDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgPG1tdXNpY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCg0KSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2Vu LUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHIGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlv dXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBv ZiB0aGUgZHJhZnQuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQg POKAi2h0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRm YXE+Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNClJldmlld2Vy OiBQYXVsIEt5eml2YXQNClJldmlldyBEYXRlOiAyMDE3LTA3LTA3DQpJRVRGIExDIEVuZCBEYXRl OiAyMDE3LTA3LTI0DQpJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTctMDgtMTUNCg0KU3VtbWFyeToN Cg0KVGhpcyBkcmFmdCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFz IG5pdHMgdGhhdCBzaG91bGQgYmUgZml4ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQooVGhlc2Ug bml0cyB3ZXJlIHJlcG9ydGVkIGJ5IElkTml0cy4gSSBhcG9sb2dpemUgZm9yIG5vdCBub3RpY2lu ZyB0aGVzZSBkdXJpbmcgbXkgTGFzdCBDYWxsIHJldmlldy4pDQoNCklzc3VlczoNCg0KTWFqb3I6 IDANCk1pbm9yOiAwDQpOaXRzOiAgMg0KDQooMSkgTklUOiBVbnVzZWQgUmVmZXJlbmNlOiAnUkZD NTI0NScgaXMgZGVmaW5lZCBvbiBsaW5lIDEwNjUsIGJ1dCBubyBleHBsaWNpdCByZWZlcmVuY2Ug d2FzIGZvdW5kIGluIHRoZSB0ZXh0DQoNClRoaXMgaXMgbm93IHJlZHVuZGFudCBiZWNhdXNlIGFs bCB0aGUgcmVmZXJlbmNlcyBpbiB0aGUgdGV4dCBoYXZlIGJlZW4gY2hhbmdlZCB0byBkcmFmdC1p ZXRmLWljZS1yZmM1MjQ1YmlzLg0KDQooMikgTklUOiBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJl ZmVyZW5jZSAoaXMgdGhpcyBpbnRlbnRpb25hbD8pOiBSRkMgNDU3Mg0KDQpUaGlzIGlzIG5vdyBv YnNvbGV0ZSBiZWNhdXNlIGl0IGhhcyBiZWVuIHJlcGxhY2VkIGJ5IFJGQzgxMjIuIFRoaXMgZHJh ZnQgc2hvdWxkIG5vdyBiZSByZWZlcmVuY2luZyB0aGF0Lg0K From nobody Fri Jul 28 17:34: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 AE2A3131723; Fri, 28 Jul 2017 17:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Jyn3iWNdo6y3; Fri, 28 Jul 2017 17:33:56 -0700 (PDT) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77505126C83; Fri, 28 Jul 2017 17:33:56 -0700 (PDT) X-AuditID: 12074414-555ff70000000ac3-00-597bd7f31dfe Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id FF.11.02755.3F7DB795; Fri, 28 Jul 2017 20:33:55 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6T0Xs6O027091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 28 Jul 2017 20:33:54 -0400 To: Christer Holmberg , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" Cc: General Area Review Team , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Fri, 28 Jul 2017 20:33:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixO6iqPv5enWkweUrihYXZh5mtNhxdweb xdVXn1kspi5/zOLA4vHr61U2jyVLfjIFMEVx2aSk5mSWpRbp2yVwZUzrfc9Y8FekYveaRqYG xv8CXYycHBICJhK3bnxk72Lk4hAS2MEksX/9aVYI5yqTxLMPh1hBqoQFgiTuHJkBViUiMI1R 4tKhnewgCWaBKInjn5cwQXQcZ5SY8OoPE0iCTUBLYs6h/ywgNq+AvUT77wtgcRYBVYmVE3uZ QWxRgTSJGd+vM0PUCEqcnPkErJ5TwE9i28tmRogFZhLzNj9khrDFJW49mc8EYctLNG+dzTyB UWAWkvZZSFpmIWmZhaRlASPLKka5xJzSXN3cxMyc4tRk3eLkxLy81CJdC73czBK91JTSTYyQ 0BbZwXjkpNwhRgEORiUeXo/K6kgh1sSy4srcQ4ySHExKorz/VwGF+JLyUyozEosz4otKc1KL DzFKcDArifBGXAHK8aYkVlalFuXDpKQ5WJTEeb8tVvcTEkhPLEnNTk0tSC2CycpwcChJ8NZe A2oULEpNT61Iy8wpQUgzcXCCDOcBGn4KpIa3uCAxtzgzHSJ/ilGX49fMrV+YhFjy8vNSpcR5 d10FKhIAKcoozYObA0tJrxjFgd4S5uUAJighHmA6g5v0CmgJE9CSiU2VIEtKEhFSUg2MxatE NmXW/b0asFs3SEhO8T9Hotv11gtW74v1551jt/s6hVOXPfie7K8rZrI7j++/Nu95malYr1jg 2asdml8TWxW2ywdtLNs/VfGyj3p26UNeKe76ojUbd/fNOpXu+u/LbD0512OanW1zp339PWcX 7+xll2tP9O9+z7k/uCBQ/0J3iULMEuc4JZbijERDLeai4kQABoDDWCQDAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 00:33:59 -0000 On 7/28/17 7:23 PM, Christer Holmberg wrote: > Hi Paul, > > Regarding the reference to RFC 4572, the new text in section 10.2.1 references RFC 4572. We earlier agreed we were not going to update that text, and keep an informative reference to RFC 4572. OK, I guess I remember that now. Is it considered acceptable to issue a new document with a reference to an obsolete document when it isn't to highlight a difference from the current document? Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 29 July 2017 01:07 > To: Paul Kyzivat ; draft-ietf-mmusic-dtls-sdp.all@ietf.org > Cc: General Area Review Team ; IETF MMUSIC WG > Subject: RE: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 > > Hi Paul, > > Thanks for the review. I'll fix references. > > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 28 July 2017 04:01 > To: draft-ietf-mmusic-dtls-sdp.all@ietf.org > Cc: General Area Review Team ; IETF MMUSIC WG > Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 > > 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-mmusic-dtls-sdp-27 > Reviewer: Paul Kyzivat > Review Date: 2017-07-07 > IETF LC End Date: 2017-07-24 > IESG Telechat date: 2017-08-15 > > Summary: > > This draft is basically ready for publication, but has nits that should be fixed before publication. > > (These nits were reported by IdNits. I apologize for not noticing these during my Last Call review.) > > Issues: > > Major: 0 > Minor: 0 > Nits: 2 > > (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no explicit reference was found in the text > > This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. > > (2) NIT: Obsolete informational reference (is this intentional?): RFC 4572 > > This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. > From nobody Fri Jul 28 21:33: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 25860131F08; Fri, 28 Jul 2017 21:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8TFAcGw0-gf; Fri, 28 Jul 2017 21:33:00 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE7F131E80; Fri, 28 Jul 2017 21:33:00 -0700 (PDT) Received: from [10.0.1.63] (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 v6T4WoU5020038 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Jul 2017 23:32:51 -0500 (CDT) (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.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Fri, 28 Jul 2017 23:32:49 -0500 Cc: Christer Holmberg , "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> To: Paul Kyzivat X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 04:33:02 -0000 > On Jul 28, 2017, at 7:33 PM, Paul Kyzivat = wrote: >=20 > On 7/28/17 7:23 PM, Christer Holmberg wrote: >> Hi Paul, >> Regarding the reference to RFC 4572, the new text in section 10.2.1 = references RFC 4572. We earlier agreed we were not going to update that = text, and keep an informative reference to RFC 4572. >=20 > OK, I guess I remember that now. Is it considered acceptable to issue = a new document with a reference to an obsolete document when it isn't to = highlight a difference from the current document? >=20 > Since this is a review for the teleconference, I'll just leave that = for the IESG folk to decide. As far as I know, there=E2=80=99s no hard and fast rule about this. It = really depends on whether the difference between the new and obsolete = dependencies are material to the draft. I do think we (i.e. the IESG) = would favor referencing the new RFC, but would be open to arguments = about why a WG chose to reference the obsolete version Does anyone recall the reasoning in this instance? Thanks! Ben. >=20 > Thanks, > Paul >=20 >> Regards, >> Christer >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 29 July 2017 01:07 >> To: Paul Kyzivat ; = draft-ietf-mmusic-dtls-sdp.all@ietf.org >> Cc: General Area Review Team ; IETF MMUSIC WG = >> Subject: RE: [Gen-art] Gen-ART Last Call review of = draft-ietf-mmusic-dtls-sdp-27 >> Hi Paul, >> Thanks for the review. I'll fix references. >> Regards, >> Christer >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 28 July 2017 04:01 >> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org >> Cc: General Area Review Team ; IETF MMUSIC WG = >> Subject: [Gen-art] Gen-ART Last Call review of = draft-ietf-mmusic-dtls-sdp-27 >> 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 wait for direction from your document = shepherd or AD before posting a new version of the draft. For more = information, please see the FAQ at = <=E2=80=8Bhttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> Document: draft-ietf-mmusic-dtls-sdp-27 >> Reviewer: Paul Kyzivat >> Review Date: 2017-07-07 >> IETF LC End Date: 2017-07-24 >> IESG Telechat date: 2017-08-15 >> Summary: >> This draft is basically ready for publication, but has nits that = should be fixed before publication. >> (These nits were reported by IdNits. I apologize for not noticing = these during my Last Call review.) >> Issues: >> Major: 0 >> Minor: 0 >> Nits: 2 >> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no = explicit reference was found in the text >> This is now redundant because all the references in the text have = been changed to draft-ietf-ice-rfc5245bis. >> (2) NIT: Obsolete informational reference (is this intentional?): RFC = 4572 >> This is now obsolete because it has been replaced by RFC8122. This = draft should now be referencing that. >=20 From nobody Sat Jul 29 11:03: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 38D20131CED; Sat, 29 Jul 2017 11:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[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 K5sGDUCdfv0u; Sat, 29 Jul 2017 11:03:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C144A131C88; Sat, 29 Jul 2017 11:03:09 -0700 (PDT) X-AuditID: c1b4fb2d-857ff70000005f66-d2-597ccddb5145 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.E5.24422.BDDCC795; Sat, 29 Jul 2017 20:03:07 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 29 Jul 2017 20:03:06 +0200 From: Christer Holmberg To: Ben Campbell , Paul Kyzivat CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pD///QEgIAAQsKAgAEBLjA= Date: Sat, 29 Jul 2017 18:03:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> In-Reply-To: <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@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+NgFupjkeLIzCtJLcpLzFFi42KZGbFdVPf22ZpIg6ZD2hbzO0+zW+y4u4PN 4uqrzywWU5c/ZrFYseEAqwOrx9/3H5g8liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6Mj1de MRVMUq/ofN3E1sA4Qa2LkZNDQsBEYseBhcwgtpDAEUaJnScruhi5gOzFjBK7D2xg72Lk4GAT sJDo/qcNUiMi4CEx6+E5VpAaZoFVjBLrWxsYQRLCAkESX/+uZIQoCpZoeviUEaRXRMBP4tB7 ZZAwi4CqxL73L1hAbF4BX4nWzgZWiF2bmCTuXn/EBJLgFLCXaPq1GKyIUUBM4vupNWBxZgFx iVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ksSi25+ZQPYyC2hKrN+lD9GqKDGl+yE7xF5BiZMz n7BMYBSdhWTqLISOWUg6ZiHpWMDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMJYObvmt u4Nx9WvHQ4wCHIxKPLxRu2oihVgTy4orcw8xSnAwK4nwqmwDCvGmJFZWpRblxxeV5qQWH2KU 5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cC4ROrrhmwXruQb3pbpixc+Uwli+7/9XMgh 5qR7zHvyfh/rEWUW04/3Ohm+w+SVoJHJdak58zPTDyh0rFod+zPrkZ/O+xeVPzoi/746avmR d+6fAxYiPb/mzT3x89muGYEL45tKlzf/euWzQPWd7sqXcqlXdSfcnfHJ9YxsbGXqfjXnacmf DVp0lViKMxINtZiLihMBBvThmaECAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 18:03:12 -0000 SGksDQoNCj4+PiBSZWdhcmRpbmcgdGhlIHJlZmVyZW5jZSB0byBSRkMgNDU3MiwgdGhlIG5ldyB0 ZXh0IGluIHNlY3Rpb24gMTAuMi4xIHJlZmVyZW5jZXMgUkZDIDQ1NzIuIFdlIGVhcmxpZXIgYWdy ZWVkIHdlIA0KPj4+IHdlcmUgbm90IGdvaW5nIHRvIHVwZGF0ZSB0aGF0IHRleHQsIGFuZCBrZWVw IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNDU3Mi4NCj4+IA0KPj4gT0ssIEkgZ3Vl c3MgSSByZW1lbWJlciB0aGF0IG5vdy4gSXMgaXQgY29uc2lkZXJlZCBhY2NlcHRhYmxlIHRvIGlz c3VlIGEgbmV3IGRvY3VtZW50IHdpdGggYSByZWZlcmVuY2UgdG8gYW4gDQo+PiBvYnNvbGV0ZSBk b2N1bWVudCB3aGVuIGl0IGlzbid0IHRvIGhpZ2hsaWdodCBhIGRpZmZlcmVuY2UgZnJvbSB0aGUg Y3VycmVudCBkb2N1bWVudD8NCj4+IA0KPj4gU2luY2UgdGhpcyBpcyBhIHJldmlldyBmb3IgdGhl IHRlbGVjb25mZXJlbmNlLCBJJ2xsIGp1c3QgbGVhdmUgdGhhdCBmb3IgdGhlIElFU0cgZm9sayB0 byBkZWNpZGUuDQo+DQo+IEFzIGZhciBhcyBJIGtub3csIHRoZXJl4oCZcyBubyBoYXJkIGFuZCBm YXN0IHJ1bGUgYWJvdXQgdGhpcy4gSXQgcmVhbGx5IGRlcGVuZHMgb24gd2hldGhlciB0aGUgZGlm ZmVyZW5jZSBiZXR3ZWVuIHRoZSANCj4gbmV3IGFuZCBvYnNvbGV0ZSBkZXBlbmRlbmNpZXMgYXJl IG1hdGVyaWFsIHRvIHRoZSBkcmFmdC4gSSBkbyB0aGluayB3ZSAoaS5lLiB0aGUgSUVTRykgd291 bGQgZmF2b3IgcmVmZXJlbmNpbmcgdGhlIA0KPiBuZXcgUkZDLCBidXQgd291bGQgYmUgb3BlbiB0 byBhcmd1bWVudHMgYWJvdXQgd2h5IGEgV0cgY2hvc2UgdG8gcmVmZXJlbmNlIHRoZSBvYnNvbGV0 ZSB2ZXJzaW9uDQo+DQo+IERvZXMgYW55b25lIHJlY2FsbCB0aGUgcmVhc29uaW5nIGluIHRoaXMg aW5zdGFuY2U/DQoNCkp1c3QgdG8gbWFrZSBzdXJlIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLCB0 aGVyZSBhcmUgVFdPIHJlZmVyZW5jZXMgdG8gUkZDIDQ1NzIgaW4gdGhlIGRyYWZ0Lg0KDQpUaGUg RklSU1QgcmVmZXJlbmNlIGlzIGluIHNlY3Rpb24gOCwgd2hlcmUgaXQgaXMgdXNlZCB0byByZWZl cmVuY2UgYW4gZXhhbXBsZSBpbiBSRkMgNDU3Mi4gVGhlIHNhbWUgZXhhbXBsZSBleGlzdHMgaW4g UkZDIDgxMjIsIHNvIHdlIGNhbiBjaGFuZ2UgdGhhdCByZWZlcmVuY2UuDQoNClRoZSBTRUNPTkQg cmVmZXJlbmNlIGlzIGluIHNlY3Rpb24gMTAuMi4xLCBhcyBwYXJ0IG9mIHRoZSB1cGRhdGVkIHRl eHQgZm9yIFJGQyA1NzYzLiBOb3csIFJGQyA1NzYzIHJlZmVyZW5jZXMgUkZDIDQ1NzIgaW4gNCBk aWZmZXJlbmNlIHBsYWNlcywgc28gaWYgd2UgY2hhbmdlIHRoZSByZWZlcmVuY2UgdG8gUkZDIDgx MjIgaW4gdGhlIHRleHQgdXBkYXRlZCBieSB0aGUgZHJhZnQgd2Ugd291bGQgYWxzbyBoYXZlIHRv IGRvIGl0IGluIGV2ZXJ5IG90aGVyIHBsYWNlLiBUaGF0IHdhcyB0aGUgcmVhc29uIHdlIGRlY2lk ZWQgbm90IHRvIGRvIGl0IChJIGhhdmUgbm8gcHJvYmxlbSBkb2luZyBpdCB0aGF0J3Mgd2hhdCBJ RVNHIHdhbnRzLCB0aG91Z2gpLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo+PiBTZW50OiAyOSBKdWx5IDIw MTcgMDE6MDcNCj4+IFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IA0K Pj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnDQo+PiBDYzogR2VuZXJh bCBBcmVhIFJldmlldyBUZWFtIDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgDQo+ PiA8bW11c2ljQGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFtHZW4tYXJ0XSBHZW4tQVJUIExh c3QgQ2FsbCByZXZpZXcgb2YgDQo+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNyBIaSBQ YXVsLCBUaGFua3MgZm9yIHRoZSByZXZpZXcuIEknbGwgDQo+PiBmaXggcmVmZXJlbmNlcy4NCj4+ IFJlZ2FyZHMsDQo+PiBDaHJpc3Rlcg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4+IFNl bnQ6IDI4IEp1bHkgMjAxNyAwNDowMQ0KPj4gVG86IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LmFsbEBpZXRmLm9yZw0KPj4gQ2M6IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSA8Z2VuLWFydEBp ZXRmLm9yZz47IElFVEYgTU1VU0lDIFdHIA0KPj4gPG1tdXNpY0BpZXRmLm9yZz4NCj4+IFN1Ympl Y3Q6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YgDQo+PiBkcmFmdC1pZXRm LW1tdXNpYy1kdGxzLXNkcC0yNyBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2VyIGZv ciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJUKSByZXZp ZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRo ZSBJRVRGIENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVu dCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFm dC4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCA84oCLaHR0cDov L3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+PiBE b2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCj4+IFJldmlld2VyOiBQYXVs IEt5eml2YXQNCj4+IFJldmlldyBEYXRlOiAyMDE3LTA3LTA3DQo+PiBJRVRGIExDIEVuZCBEYXRl OiAyMDE3LTA3LTI0DQo+PiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTctMDgtMTUNCj4+IFN1bW1h cnk6DQo+PiBUaGlzIGRyYWZ0IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1 dCBoYXMgbml0cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+PiAo VGhlc2Ugbml0cyB3ZXJlIHJlcG9ydGVkIGJ5IElkTml0cy4gSSBhcG9sb2dpemUgZm9yIG5vdCBu b3RpY2luZyANCj4+IHRoZXNlIGR1cmluZyBteSBMYXN0IENhbGwgcmV2aWV3LikNCj4+IElzc3Vl czoNCj4+IE1ham9yOiAwDQo+PiBNaW5vcjogMA0KPj4gTml0czogIDINCj4+ICgxKSBOSVQ6IFVu dXNlZCBSZWZlcmVuY2U6ICdSRkM1MjQ1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTA2NSwgYnV0IG5v IA0KPj4gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dCBUaGlzIGlzIG5v dyByZWR1bmRhbnQgYmVjYXVzZSBhbGwgdGhlIHJlZmVyZW5jZXMgaW4gdGhlIHRleHQgaGF2ZSBi ZWVuIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy4NCj4+ICgyKSBOSVQ6IE9i c29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IFJG QyANCj4+IDQ1NzIgVGhpcyBpcyBub3cgb2Jzb2xldGUgYmVjYXVzZSBpdCBoYXMgYmVlbiByZXBs YWNlZCBieSBSRkM4MTIyLiBUaGlzIGRyYWZ0IHNob3VsZCBub3cgYmUgcmVmZXJlbmNpbmcgdGhh dC4NCj4gDQoNCg== From nobody Sat Jul 29 14:09: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 D15BF131E9A; Sat, 29 Jul 2017 14:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 gZ2FENUh6nkj; Sat, 29 Jul 2017 14:09:06 -0700 (PDT) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5508C131E2A; Sat, 29 Jul 2017 14:09:06 -0700 (PDT) X-AuditID: 12074412-0c7ff70000000b4e-61-597cf9713bf0 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id DC.4B.02894.179FC795; Sat, 29 Jul 2017 17:09:05 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6TL925T017318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Jul 2017 17:09:03 -0400 To: Christer Holmberg , Ben Campbell Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: Date: Sat, 29 Jul 2017 17:09:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixO6iqFv4sybS4G2HvMX8ztPsFhdmHma0 2HF3B5vF1VefWSymLn/M4sDq8evrVTaPJUt+MnnM2vmEJYA5issmJTUnsyy1SN8ugSvj/kab gsVKFftWn2NsYHwu3cXIySEhYCJxbu5f5i5GLg4hgR1MEpN3/WIDSQgJXGWS6O/yA7GFBYIk 7hyZwQ5iiwjESyz/v50RpIFZYBejxPOWdYwQ3d+YJFbsWcMCUsUmoCUx59B/MJtXwF7ixMOd jCA2i4CqxJytvWC2qECaxIzv15khagQlTs58AlbPKeAnsbBnO5jNLGAmMW/zQ2YIW1zi1pP5 TBC2vETz1tnMExgFZiFpn4WkZRaSlllIWhYwsqxilEvMKc3VzU3MzClOTdYtTk7My0st0jXT y80s0UtNKd3ECAl1oR2M60/KHWIU4GBU4uGVOFYTKcSaWFZcmXuIUZKDSUmU98ksoBBfUn5K ZUZicUZ8UWlOavEhRgkOZiUR3q/fgXK8KYmVValF+TApaQ4WJXHen4vV/YQE0hNLUrNTUwtS i2CyMhwcShK8zSCNgkWp6akVaZk5JQhpJg5OkOE8QMO1foAMLy5IzC3OTIfIn2LU5fg1c+sX JiGWvPy8VClx3jnfgIoEQIoySvPg5sBS1CtGcaC3hHm/g6zjAaY3uEmvgJYwAS2Z2FQJsqQk ESEl1cBYmlNvvdvCuC7Mz/fHCq2zHgf+rtz1Nm+C6wGXE8Y9FpECTK3f93rtrvnYfcHJdeHe K68PmNqf1WQV97Zwnr7q4lq/jJ8fczbxPln44vrEQNvui5knIzkyDx9dwTmf449+zhy1e2qH Cj9/fco3dZnqpSVp2h/UH37zzYiM/fjXfwH7TSe/CfasSizFGYmGWsxFxYkAJRpWqSwDAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 21:09:08 -0000 On 7/29/17 2:03 PM, Christer Holmberg wrote: > Hi, > >>>> Regarding the reference to RFC 4572, the new text in section 10.2.1 references RFC 4572. We earlier agreed we >>>> were not going to update that text, and keep an informative reference to RFC 4572. >>> >>> OK, I guess I remember that now. Is it considered acceptable to issue a new document with a reference to an >>> obsolete document when it isn't to highlight a difference from the current document? >>> >>> Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide. >> >> As far as I know, there’s no hard and fast rule about this. It really depends on whether the difference between the >> new and obsolete dependencies are material to the draft. I do think we (i.e. the IESG) would favor referencing the >> new RFC, but would be open to arguments about why a WG chose to reference the obsolete version >> >> Does anyone recall the reasoning in this instance? > > Just to make sure we are on the same page, there are TWO references to RFC 4572 in the draft. > > The FIRST reference is in section 8, where it is used to reference an example in RFC 4572. The same example exists in RFC 8122, so we can change that reference. > > The SECOND reference is in section 10.2.1, as part of the updated text for RFC 5763. Now, RFC 5763 references RFC 4572 in 4 difference places, so if we change the reference to RFC 8122 in the text updated by the draft we would also have to do it in every other place. That was the reason we decided not to do it (I have no problem doing it that's what IESG wants, though). Thanks for pointing that out. I just looked at that to size up the situation. Of those four references, three of them are in section 5 and will all be replaced by the new text in this document. The remaining reference is simply a general one in the introduction. And then in addition there is the actual reference text in the normative references. ISTM that it would be sufficient to update the reference in the new text for section 5 and then add a general statement to update all references to 4572 to refer to 8122. But again, this is really an IESG issue at this point. Thanks, Paul > Regards, > > Christer > > > > >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: 29 July 2017 01:07 >>> To: Paul Kyzivat ; >>> draft-ietf-mmusic-dtls-sdp.all@ietf.org >>> Cc: General Area Review Team ; IETF MMUSIC WG >>> >>> Subject: RE: [Gen-art] Gen-ART Last Call review of >>> draft-ietf-mmusic-dtls-sdp-27 Hi Paul, Thanks for the review. I'll >>> fix references. >>> Regards, >>> Christer >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: 28 July 2017 04:01 >>> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org >>> Cc: General Area Review Team ; IETF MMUSIC WG >>> >>> Subject: [Gen-art] Gen-ART Last Call review of >>> draft-ietf-mmusic-dtls-sdp-27 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> Document: draft-ietf-mmusic-dtls-sdp-27 >>> Reviewer: Paul Kyzivat >>> Review Date: 2017-07-07 >>> IETF LC End Date: 2017-07-24 >>> IESG Telechat date: 2017-08-15 >>> Summary: >>> This draft is basically ready for publication, but has nits that should be fixed before publication. >>> (These nits were reported by IdNits. I apologize for not noticing >>> these during my Last Call review.) >>> Issues: >>> Major: 0 >>> Minor: 0 >>> Nits: 2 >>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no >>> explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. >>> (2) NIT: Obsolete informational reference (is this intentional?): RFC >>> 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. >> > From nobody Sat Jul 29 14:37:54 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 67D64131F12; Sat, 29 Jul 2017 14:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[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 2bPOznlbpRsZ; Sat, 29 Jul 2017 14:37:46 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484B0131CBD; Sat, 29 Jul 2017 14:37:46 -0700 (PDT) X-AuditID: c1b4fb2d-86fff70000005f66-ea-597d00287abb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 26.D2.24422.8200D795; Sat, 29 Jul 2017 23:37:44 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Sat, 29 Jul 2017 23:37:44 +0200 From: Christer Holmberg To: Paul Kyzivat , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pD///QEgIAAQsKAgAEBLjCAABUpAIAAKPpA Date: Sat, 29 Jul 2017 21:37:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdVFeDoTbS4NVhRYv5nafZLXbc3cFm cfXVZxaLqcsfs1is2HCA1YHV4+/7D0weS5b8ZPKYtfMJSwBzFJdNSmpOZllqkb5dAldG5/6b zAVr9CvW7L7I3sA4Qa+LkZNDQsBEYv+dD4wgtpDAEUaJpp/RXYxcQPZiRomHr86xdDFycLAJ WEh0/9MGqRER8JBYMeUxK0gNs8AqRon1rQ1gzcICQRJf/65khCgKlmh6+JQRpFdEIEpiydFQ kDCLgKrE1sX3wEp4BXwlurvvskDsWsMscfTATnaQBKeAg8SdDZPBbEYBMYnvp9YwgdjMAuIS t57MZ4I4WkBiyZ7zzBC2qMTLx/9YIWwlicYlT1hB9jILaEqs36UP0aooMaX7ITvEXkGJkzOf sExgFJ2FZOoshI5ZSDpmIelYwMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwlg5u+a27 g3H1a8dDjAIcjEo8vMEfaiKFWBPLiitzDzFKcDArifB+/Q4U4k1JrKxKLcqPLyrNSS0+xCjN waIkzuuw70KEkEB6YklqdmpqQWoRTJaJg1OqgTHTd4HctF9Me1fMOBIVyh4ivGLD75Lq5z/u 7n/jnKH5S3tB+cOQF78VnzuscNUvz6zseHDZ2SaQ+2+tiLfwE1fhRwGadxa/FK7Sj1MuPrM8 QnSB+IILFztYZjuvvnaOm+/O8f3tt8/ZLdO0SKk40/pAVbX+5POVtsVyZyqVPwZ/jxC5skNw xiYlluKMREMt5qLiRABo8UXAoQIAAA== Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2017 21:37:48 -0000 SGksDQoNCj4+Pj4+IFJlZ2FyZGluZyB0aGUgcmVmZXJlbmNlIHRvIFJGQyA0NTcyLCB0aGUgbmV3 IHRleHQgaW4gc2VjdGlvbiAxMC4yLjEgDQo+Pj4+PiByZWZlcmVuY2VzIFJGQyA0NTcyLiBXZSBl YXJsaWVyIGFncmVlZCB3ZSB3ZXJlIG5vdCBnb2luZyB0byB1cGRhdGUgdGhhdCB0ZXh0LCBhbmQg a2VlcCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDQ1NzIuDQo+Pj4+DQo+Pj4+IE9L LCBJIGd1ZXNzIEkgcmVtZW1iZXIgdGhhdCBub3cuIElzIGl0IGNvbnNpZGVyZWQgYWNjZXB0YWJs ZSB0byANCj4+Pj4gaXNzdWUgYSBuZXcgZG9jdW1lbnQgd2l0aCBhIHJlZmVyZW5jZSB0byBhbiBv YnNvbGV0ZSBkb2N1bWVudCB3aGVuIGl0IGlzbid0IHRvIGhpZ2hsaWdodCBhIGRpZmZlcmVuY2Ug ZnJvbSB0aGUgY3VycmVudCBkb2N1bWVudD8NCj4+Pj4NCj4+Pj4gU2luY2UgdGhpcyBpcyBhIHJl dmlldyBmb3IgdGhlIHRlbGVjb25mZXJlbmNlLCBJJ2xsIGp1c3QgbGVhdmUgdGhhdCBmb3IgdGhl IElFU0cgZm9sayB0byBkZWNpZGUuDQo+Pj4NCj4+PiBBcyBmYXIgYXMgSSBrbm93LCB0aGVyZeKA mXMgbm8gaGFyZCBhbmQgZmFzdCBydWxlIGFib3V0IHRoaXMuIEl0IHJlYWxseSANCj4+PiBkZXBl bmRzIG9uIHdoZXRoZXIgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmV3IGFuZCBvYnNvbGV0 ZSANCj4+PiBkZXBlbmRlbmNpZXMgYXJlIG1hdGVyaWFsIHRvIHRoZSBkcmFmdC4gSSBkbyB0aGlu ayB3ZSAoaS5lLiB0aGUgSUVTRykgDQo+Pj4gd291bGQgZmF2b3IgcmVmZXJlbmNpbmcgdGhlIG5l dyBSRkMsIGJ1dCB3b3VsZCBiZSBvcGVuIHRvIGFyZ3VtZW50cyANCj4+PiBhYm91dCB3aHkgYSBX RyBjaG9zZSB0byByZWZlcmVuY2UgdGhlIG9ic29sZXRlIHZlcnNpb24NCj4+Pg0KPj4+IERvZXMg YW55b25lIHJlY2FsbCB0aGUgcmVhc29uaW5nIGluIHRoaXMgaW5zdGFuY2U/DQo+PiANCj4+IEp1 c3QgdG8gbWFrZSBzdXJlIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdlLCB0aGVyZSBhcmUgVFdPIHJl ZmVyZW5jZXMgdG8gUkZDIDQ1NzIgaW4gdGhlIGRyYWZ0Lg0KPj4gDQo+PiBUaGUgRklSU1QgcmVm ZXJlbmNlIGlzIGluIHNlY3Rpb24gOCwgd2hlcmUgaXQgaXMgdXNlZCB0byByZWZlcmVuY2UgYW4g ZXhhbXBsZSBpbiBSRkMgNDU3Mi4gVGhlIHNhbWUgZXhhbXBsZSANCj4+IGV4aXN0cyBpbiBSRkMg ODEyMiwgc28gd2UgY2FuIGNoYW5nZSB0aGF0IHJlZmVyZW5jZS4NCj4+IA0KPj4gVGhlIFNFQ09O RCByZWZlcmVuY2UgaXMgaW4gc2VjdGlvbiAxMC4yLjEsIGFzIHBhcnQgb2YgdGhlIHVwZGF0ZWQg dGV4dCBmb3IgUkZDIDU3NjMuIE5vdywgUkZDIDU3NjMgDQo+PiByZWZlcmVuY2VzIFJGQyA0NTcy IGluIDQgZGlmZmVyZW5jZSBwbGFjZXMsIHNvIGlmIHdlIGNoYW5nZSB0aGUgPnJlZmVyZW5jZSB0 byBSRkMgODEyMiBpbiB0aGUgdGV4dCANCj4+IHVwZGF0ZWQgYnkgdGhlIGRyYWZ0IHdlIHdvdWxk IGFsc28gaGF2ZSB0byBkbyBpdCBpbiBldmVyeSBvdGhlciBwbGFjZS4gVGhhdCB3YXMgdGhlIHJl YXNvbiB3ZSBkZWNpZGVkIA0KPj4gbm90IHRvIGRvIGl0IChJIGhhdmUgbm8gcHJvYmxlbSBkb2lu ZyBpdCB0aGF0J3Mgd2hhdCBJRVNHIHdhbnRzLCB0aG91Z2gpLg0KPg0KPiBUaGFua3MgZm9yIHBv aW50aW5nIHRoYXQgb3V0LiBJIGp1c3QgbG9va2VkIGF0IHRoYXQgdG8gc2l6ZSB1cCB0aGUgc2l0 dWF0aW9uLiBPZiB0aG9zZSBmb3VyIHJlZmVyZW5jZXMsIHRocmVlIG9mIHRoZW0gYXJlDQo+IGlu IHNlY3Rpb24gNSBhbmQgd2lsbCBhbGwgYmUgcmVwbGFjZWQgYnkgdGhlIG5ldyB0ZXh0IGluIHRo aXMgZG9jdW1lbnQuIFRoZSByZW1haW5pbmcgcmVmZXJlbmNlIGlzIHNpbXBseSBhIGdlbmVyYWwg b25lDQo+IGluIHRoZSBpbnRyb2R1Y3Rpb24uIEFuZCB0aGVuIGluIGFkZGl0aW9uIHRoZXJlIGlz IHRoZSBhY3R1YWwgcmVmZXJlbmNlIHRleHQgaW4gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLg0K Pg0KPiBJU1RNIHRoYXQgaXQgd291bGQgYmUgc3VmZmljaWVudCB0byB1cGRhdGUgdGhlIHJlZmVy ZW5jZSBpbiB0aGUgbmV3IHRleHQgZm9yIHNlY3Rpb24gNSBhbmQgdGhlbiBhZGQgYSBnZW5lcmFs IHN0YXRlbWVudCANCj4gdG8gdXBkYXRlIGFsbCByZWZlcmVuY2VzIHRvIDQ1NzIgdG8gcmVmZXIg dG8gODEyMi4NCj4NCj4gQnV0IGFnYWluLCB0aGlzIGlzIHJlYWxseSBhbiBJRVNHIGlzc3VlIGF0 IHRoaXMgcG9pbnQuDQoNCk9yLCB3ZSBjb3VsZCBqdXN0IGdvIGFoZWFkIGFuZCBkbyBpdCA6KQ0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo+IA0KPiANCj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NCj4+PiBTZW50OiAyOSBKdWx5IDIwMTcgMDE6MDcNCj4+ PiBUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyANCj4+PiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcC5hbGxAaWV0Zi5vcmcNCj4+PiBDYzogR2VuZXJhbCBBcmVhIFJl dmlldyBUZWFtIDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgDQo+Pj4gPG1tdXNp Y0BpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSRTogW0dlbi1hcnRdIEdlbi1BUlQgTGFzdCBDYWxs IHJldmlldyBvZg0KPj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTI3IEhpIFBhdWwsIFRo YW5rcyBmb3IgdGhlIHJldmlldy4gSSdsbCANCj4+PiBmaXggcmVmZXJlbmNlcy4NCj4+PiBSZWdh cmRzLA0KPj4+IENocmlzdGVyDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBG cm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+Pj4gU2Vu dDogMjggSnVseSAyMDE3IDA0OjAxDQo+Pj4gVG86IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LmFsbEBpZXRmLm9yZw0KPj4+IENjOiBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRA aWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+PiA8bW11c2ljQGlldGYub3JnPg0KPj4+IFN1 YmplY3Q6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YNCj4+PiBkcmFmdC1p ZXRmLW1tdXNpYy1kdGxzLXNkcC0yNyBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmlld2Vy IGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJUKSBy ZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9y IHRoZSBJRVRGIENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1 bWVudCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBk cmFmdC4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdCA84oCLaHR0 cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFydGZhcT4uDQo+ Pj4gRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTI3DQo+Pj4gUmV2aWV3ZXI6 IFBhdWwgS3l6aXZhdA0KPj4+IFJldmlldyBEYXRlOiAyMDE3LTA3LTA3DQo+Pj4gSUVURiBMQyBF bmQgRGF0ZTogMjAxNy0wNy0yNA0KPj4+IElFU0cgVGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0xNQ0K Pj4+IFN1bW1hcnk6DQo+Pj4gVGhpcyBkcmFmdCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgZml4ZWQgYmVmb3JlIHB1YmxpY2F0 aW9uLg0KPj4+IChUaGVzZSBuaXRzIHdlcmUgcmVwb3J0ZWQgYnkgSWROaXRzLiBJIGFwb2xvZ2l6 ZSBmb3Igbm90IG5vdGljaW5nIA0KPj4+IHRoZXNlIGR1cmluZyBteSBMYXN0IENhbGwgcmV2aWV3 LikNCj4+PiBJc3N1ZXM6DQo+Pj4gTWFqb3I6IDANCj4+PiBNaW5vcjogMA0KPj4+IE5pdHM6ICAy DQo+Pj4gKDEpIE5JVDogVW51c2VkIFJlZmVyZW5jZTogJ1JGQzUyNDUnIGlzIGRlZmluZWQgb24g bGluZSAxMDY1LCBidXQgbm8gDQo+Pj4gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0 aGUgdGV4dCBUaGlzIGlzIG5vdyByZWR1bmRhbnQgYmVjYXVzZSBhbGwgdGhlIHJlZmVyZW5jZXMg aW4gdGhlIHRleHQgaGF2ZSBiZWVuIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJp cy4NCj4+PiAoMikgTklUOiBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSAoaXMgdGhp cyBpbnRlbnRpb25hbD8pOiANCj4+PiBSRkMNCj4+PiA0NTcyIFRoaXMgaXMgbm93IG9ic29sZXRl IGJlY2F1c2UgaXQgaGFzIGJlZW4gcmVwbGFjZWQgYnkgUkZDODEyMi4gVGhpcyBkcmFmdCBzaG91 bGQgbm93IGJlIHJlZmVyZW5jaW5nIHRoYXQuDQo+Pg0KPiANCg0K From nobody Sun Jul 30 13:45: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 0595512EC2B; Sun, 30 Jul 2017 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b3N8JQ09MuB; Sun, 30 Jul 2017 13:44:56 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B881129AC4; Sun, 30 Jul 2017 13:44:55 -0700 (PDT) X-AuditID: c1b4fb30-703ff70000001664-c4-597e4545da57 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.D8.05732.5454E795; Sun, 30 Jul 2017 22:44:53 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sun, 30 Jul 2017 22:44:52 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pD///QEgIAAQsKAgAEBLjCAABUpAIAAKPpAgAGEIyA= Date: Sun, 30 Jul 2017 20:44:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdWtfVtS7S4MZzXov5nafZLXbc3cFm cfXVZxaLqcsfs1is2HCA1YHV4+/7D0weS5b8ZPKYtfMJSwBzFJdNSmpOZllqkb5dAlfG5N+/ WQsumVQ8/HKRsYFxiXEXIyeHhICJxMpVW1i7GLk4hASOMEo0djZBOYsZJeb2dTN3MXJwsAlY SHT/0wZpEBGok9j68QlYDbPAKkaJ9a0NjCAJYYEgia9/VzJCFAVLND18CmUnSSz+85QVxGYR UJVYvLWZDWQmr4CvRPeySohdH5glbuzawwZSwyngJzFxbguYzSggJvH91BomEJtZQFzi1pP5 TBBXC0gs2XOeGcIWlXj5+B8rhK0ksfbwdhaQ+cwCmhLrd+lDtCpKTOl+yA5i8woISpyc+YRl AqPoLCRTZyF0zELSMQtJxwJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgdF0cMtvgx2M L587HmIU4GBU4uH9a1AXKcSaWFZcmXuIUYKDWUmEd48NUIg3JbGyKrUoP76oNCe1+BCjNAeL kjiv474LEUIC6YklqdmpqQWpRTBZJg5OqQbGKo7NzdtZlBbHxP+a+si/Z4fqkbOTooNl8qdP 9wiz+GZ6K0nH3qnpi8SlveZVGmvEmA/lGF06m7b/v5zUxD82xyV1NyY2nTSW1Zdaqc34Sf3D Ww6RcJWUUzVTD0u/P+Sws+OIwL9HzyLEazonBb61jp2425uH2eGw2Qpf5RUd0ueNP2zxeLpN iaU4I9FQi7moOBEAp7QXIqICAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 20:44:58 -0000 UFIgY3JlYXRlZDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0bHMtc2RwL3B1 bGwvMzQNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tXSANClNlbnQ6IDI5IEp1bHkgMjAxNyAyMzozOA0KVG86IFBhdWwgS3l6aXZhdCA8 cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpD YzogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnOyBHZW5lcmFsIEFyZWEg UmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11c2ljQGll dGYub3JnPg0KU3ViamVjdDogUkU6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcg b2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCg0KSGksDQoNCj4+Pj4+IFJlZ2FyZGlu ZyB0aGUgcmVmZXJlbmNlIHRvIFJGQyA0NTcyLCB0aGUgbmV3IHRleHQgaW4gc2VjdGlvbiANCj4+ Pj4+IDEwLjIuMSByZWZlcmVuY2VzIFJGQyA0NTcyLiBXZSBlYXJsaWVyIGFncmVlZCB3ZSB3ZXJl IG5vdCBnb2luZyB0byB1cGRhdGUgdGhhdCB0ZXh0LCBhbmQga2VlcCBhbiBpbmZvcm1hdGl2ZSBy ZWZlcmVuY2UgdG8gUkZDIDQ1NzIuDQo+Pj4+DQo+Pj4+IE9LLCBJIGd1ZXNzIEkgcmVtZW1iZXIg dGhhdCBub3cuIElzIGl0IGNvbnNpZGVyZWQgYWNjZXB0YWJsZSB0byANCj4+Pj4gaXNzdWUgYSBu ZXcgZG9jdW1lbnQgd2l0aCBhIHJlZmVyZW5jZSB0byBhbiBvYnNvbGV0ZSBkb2N1bWVudCB3aGVu IGl0IGlzbid0IHRvIGhpZ2hsaWdodCBhIGRpZmZlcmVuY2UgZnJvbSB0aGUgY3VycmVudCBkb2N1 bWVudD8NCj4+Pj4NCj4+Pj4gU2luY2UgdGhpcyBpcyBhIHJldmlldyBmb3IgdGhlIHRlbGVjb25m ZXJlbmNlLCBJJ2xsIGp1c3QgbGVhdmUgdGhhdCBmb3IgdGhlIElFU0cgZm9sayB0byBkZWNpZGUu DQo+Pj4NCj4+PiBBcyBmYXIgYXMgSSBrbm93LCB0aGVyZeKAmXMgbm8gaGFyZCBhbmQgZmFzdCBy dWxlIGFib3V0IHRoaXMuIEl0IA0KPj4+IHJlYWxseSBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmV3IGFuZCANCj4+PiBvYnNvbGV0ZSBkZXBlbmRlbmNpZXMg YXJlIG1hdGVyaWFsIHRvIHRoZSBkcmFmdC4gSSBkbyB0aGluayB3ZSAoaS5lLiANCj4+PiB0aGUg SUVTRykgd291bGQgZmF2b3IgcmVmZXJlbmNpbmcgdGhlIG5ldyBSRkMsIGJ1dCB3b3VsZCBiZSBv cGVuIHRvIA0KPj4+IGFyZ3VtZW50cyBhYm91dCB3aHkgYSBXRyBjaG9zZSB0byByZWZlcmVuY2Ug dGhlIG9ic29sZXRlIHZlcnNpb24NCj4+Pg0KPj4+IERvZXMgYW55b25lIHJlY2FsbCB0aGUgcmVh c29uaW5nIGluIHRoaXMgaW5zdGFuY2U/DQo+PiANCj4+IEp1c3QgdG8gbWFrZSBzdXJlIHdlIGFy ZSBvbiB0aGUgc2FtZSBwYWdlLCB0aGVyZSBhcmUgVFdPIHJlZmVyZW5jZXMgdG8gUkZDIDQ1NzIg aW4gdGhlIGRyYWZ0Lg0KPj4gDQo+PiBUaGUgRklSU1QgcmVmZXJlbmNlIGlzIGluIHNlY3Rpb24g OCwgd2hlcmUgaXQgaXMgdXNlZCB0byByZWZlcmVuY2UgYW4gDQo+PiBleGFtcGxlIGluIFJGQyA0 NTcyLiBUaGUgc2FtZSBleGFtcGxlIGV4aXN0cyBpbiBSRkMgODEyMiwgc28gd2UgY2FuIGNoYW5n ZSB0aGF0IHJlZmVyZW5jZS4NCj4+IA0KPj4gVGhlIFNFQ09ORCByZWZlcmVuY2UgaXMgaW4gc2Vj dGlvbiAxMC4yLjEsIGFzIHBhcnQgb2YgdGhlIHVwZGF0ZWQgDQo+PiB0ZXh0IGZvciBSRkMgNTc2 My4gTm93LCBSRkMgNTc2MyByZWZlcmVuY2VzIFJGQyA0NTcyIGluIDQgZGlmZmVyZW5jZSANCj4+ IHBsYWNlcywgc28gaWYgd2UgY2hhbmdlIHRoZSA+cmVmZXJlbmNlIHRvIFJGQyA4MTIyIGluIHRo ZSB0ZXh0IA0KPj4gdXBkYXRlZCBieSB0aGUgZHJhZnQgd2Ugd291bGQgYWxzbyBoYXZlIHRvIGRv IGl0IGluIGV2ZXJ5IG90aGVyIHBsYWNlLiBUaGF0IHdhcyB0aGUgcmVhc29uIHdlIGRlY2lkZWQg bm90IHRvIGRvIGl0IChJIGhhdmUgbm8gcHJvYmxlbSBkb2luZyBpdCB0aGF0J3Mgd2hhdCBJRVNH IHdhbnRzLCB0aG91Z2gpLg0KPg0KPiBUaGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0LiBJIGp1 c3QgbG9va2VkIGF0IHRoYXQgdG8gc2l6ZSB1cCB0aGUgDQo+IHNpdHVhdGlvbi4gT2YgdGhvc2Ug Zm91ciByZWZlcmVuY2VzLCB0aHJlZSBvZiB0aGVtIGFyZSBpbiBzZWN0aW9uIDUgDQo+IGFuZCB3 aWxsIGFsbCBiZSByZXBsYWNlZCBieSB0aGUgbmV3IHRleHQgaW4gdGhpcyBkb2N1bWVudC4gVGhl IHJlbWFpbmluZyByZWZlcmVuY2UgaXMgc2ltcGx5IGEgZ2VuZXJhbCBvbmUgaW4gdGhlIGludHJv ZHVjdGlvbi4gQW5kIHRoZW4gaW4gYWRkaXRpb24gdGhlcmUgaXMgdGhlIGFjdHVhbCByZWZlcmVu Y2UgdGV4dCBpbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+DQo+IElTVE0gdGhhdCBpdCB3 b3VsZCBiZSBzdWZmaWNpZW50IHRvIHVwZGF0ZSB0aGUgcmVmZXJlbmNlIGluIHRoZSBuZXcgDQo+ IHRleHQgZm9yIHNlY3Rpb24gNSBhbmQgdGhlbiBhZGQgYSBnZW5lcmFsIHN0YXRlbWVudCB0byB1 cGRhdGUgYWxsIHJlZmVyZW5jZXMgdG8gNDU3MiB0byByZWZlciB0byA4MTIyLg0KPg0KPiBCdXQg YWdhaW4sIHRoaXMgaXMgcmVhbGx5IGFuIElFU0cgaXNzdWUgYXQgdGhpcyBwb2ludC4NCg0KT3Is IHdlIGNvdWxkIGp1c3QgZ28gYWhlYWQgYW5kIGRvIGl0IDopDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCj4gDQo+IA0KPiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZy b206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tXQ0KPj4+IFNlbnQ6IDI5IEp1bHkgMjAxNyAwMTowNw0KPj4+IFRvOiBQYXVsIEt5eml2YXQg PHBreXppdmF0QGFsdW0ubWl0LmVkdT47IA0KPj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LmFsbEBpZXRmLm9yZw0KPj4+IENjOiBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRA aWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+PiA8bW11c2ljQGlldGYub3JnPg0KPj4+IFN1 YmplY3Q6IFJFOiBbR2VuLWFydF0gR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mDQo+Pj4gZHJh ZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcgSGkgUGF1bCwgVGhhbmtzIGZvciB0aGUgcmV2aWV3 LiBJJ2xsIA0KPj4+IGZpeCByZWZlcmVuY2VzLg0KPj4+IFJlZ2FyZHMsDQo+Pj4gQ2hyaXN0ZXIN Cj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IFBhdWwgS3l6aXZhdCBb bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdV0NCj4+PiBTZW50OiAyOCBKdWx5IDIwMTcgMDQ6 MDENCj4+PiBUbzogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnDQo+Pj4g Q2M6IEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSA8Z2VuLWFydEBpZXRmLm9yZz47IElFVEYgTU1V U0lDIFdHIA0KPj4+IDxtbXVzaWNAaWV0Zi5vcmc+DQo+Pj4gU3ViamVjdDogW0dlbi1hcnRdIEdl bi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZg0KPj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2Rw LTI3IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRo ZSBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuIFBs ZWFzZSB3YWl0IGZvciBkaXJlY3Rpb24gZnJvbSB5b3VyIGRvY3VtZW50IHNoZXBoZXJkIG9yIEFE IGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LiBGb3IgbW9yZSBpbmZv cm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0IDzigItodHRwOi8vd2lraS50b29scy5pZXRm Lm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCj4+PiBEb2N1bWVudDogZHJhZnQt aWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCj4+PiBSZXZpZXdlcjogUGF1bCBLeXppdmF0DQo+Pj4g UmV2aWV3IERhdGU6IDIwMTctMDctMDcNCj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA3LTI0 DQo+Pj4gSUVTRyBUZWxlY2hhdCBkYXRlOiAyMDE3LTA4LTE1DQo+Pj4gU3VtbWFyeToNCj4+PiBU aGlzIGRyYWZ0IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0 cyB0aGF0IHNob3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+Pj4gKFRoZXNlIG5p dHMgd2VyZSByZXBvcnRlZCBieSBJZE5pdHMuIEkgYXBvbG9naXplIGZvciBub3Qgbm90aWNpbmcg DQo+Pj4gdGhlc2UgZHVyaW5nIG15IExhc3QgQ2FsbCByZXZpZXcuKQ0KPj4+IElzc3VlczoNCj4+ PiBNYWpvcjogMA0KPj4+IE1pbm9yOiAwDQo+Pj4gTml0czogIDINCj4+PiAoMSkgTklUOiBVbnVz ZWQgUmVmZXJlbmNlOiAnUkZDNTI0NScgaXMgZGVmaW5lZCBvbiBsaW5lIDEwNjUsIGJ1dCBubyAN Cj4+PiBleHBsaWNpdCByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0IFRoaXMgaXMgbm93 IHJlZHVuZGFudCBiZWNhdXNlIGFsbCB0aGUgcmVmZXJlbmNlcyBpbiB0aGUgdGV4dCBoYXZlIGJl ZW4gY2hhbmdlZCB0byBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLg0KPj4+ICgyKSBOSVQ6IE9i c29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6IA0K Pj4+IFJGQw0KPj4+IDQ1NzIgVGhpcyBpcyBub3cgb2Jzb2xldGUgYmVjYXVzZSBpdCBoYXMgYmVl biByZXBsYWNlZCBieSBSRkM4MTIyLiBUaGlzIGRyYWZ0IHNob3VsZCBub3cgYmUgcmVmZXJlbmNp bmcgdGhhdC4NCj4+DQo+IA0KDQo= From nobody Sun Jul 30 14:26: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 92121126CD8; Sun, 30 Jul 2017 14:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pdg8fe6s0pjx; Sun, 30 Jul 2017 14:26:30 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 241F5131C6E; Sun, 30 Jul 2017 14:26:30 -0700 (PDT) X-AuditID: 12074413-66dff70000000aee-5c-597e4f04bbbb Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AC.4D.02798.40F4E795; Sun, 30 Jul 2017 17:26:28 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6ULQQsJ010652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Jul 2017 17:26:26 -0400 To: Christer Holmberg , Ben Campbell Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> Date: Sun, 30 Jul 2017 17:26:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixO6iqMviXxdp0Hyd32J+52l2iwszDzNa 7Li7g83i6qvPLBZTlz9mcWD1+PX1KpvHkiU/mTxm7XzCEsAcxWWTkpqTWZZapG+XwJVxcZ5h wWXNih2fepgbGP8odjFyckgImEicvX2EsYuRi0NIYAeTRFPbcnYI5yqTxIOLzcwgVcICQRJ3 jsxgB7FFBOIllv/fDtbBLLCLUeJ5yzqo9i0sEnMfzAarYhPQkphz6D8LiM0rYC/xZNkNMJtF QFXi+/TJbCC2qECaxIzv15khagQlTs58AlbDKeAncWLrPzCbWcBMYt7mh8wQtrjErSfzmSBs eYnmrbOZJzAKzELSPgtJyywkLbOQtCxgZFnFKJeYU5qrm5uYmVOcmqxbnJyYl5dapGuul5tZ opeaUrqJERLswjsYd52UO8QowMGoxMNbcKImUog1say4MvcQoyQHk5Io7zru2kghvqT8lMqM xOKM+KLSnNTiQ4wSHMxKIrx7bOoihXhTEiurUovyYVLSHCxK4rxqS9T9hATSE0tSs1NTC1KL YLIyHBxKErzTfIEaBYtS01Mr0jJzShDSTBycIMN5gIavAqnhLS5IzC3OTIfIn2LU5fg1c+sX JiGWvPy8VClx3hM+QEUCIEUZpXlwc2BJ6hWjONBbwrwnQUbxABMc3KRXQEuYgJZIltaCLClJ REhJNTAWBE/v/KFk4c68y+4od8gnxd7UnOstLdtWSTySmH7qcpNiS8OuwONmQXmzSv5nyS1z /hCUs6SyykWq9NJRC+Ys3s+xS+wajZ/MO+DtVeYxe0Fm6uzp0gKzQixuqP6T5pQrbo2rXzfp hMTiw/k79Lg+VV4Pc3DR7fW/wKN2SzV1Utim2daz9ZRYijMSDbWYi4oTAS3GjKwtAwAA Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2017 21:26:33 -0000 Christer, On 7/30/17 4:44 PM, Christer Holmberg wrote: > PR created: > > https://github.com/cdh4u/draft-dtls-sdp/pull/34 This leaves RFC5763 in an inconsistent state: - the reference to 8122 in section 5 isn't backed up with an entry in the references section - there is still a reference to 4572 in the introduction. Otherwise looks right. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 29 July 2017 23:38 > To: Paul Kyzivat ; Ben Campbell > Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team ; IETF MMUSIC WG > Subject: RE: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 > > Hi, > >>>>>> Regarding the reference to RFC 4572, the new text in section >>>>>> 10.2.1 references RFC 4572. We earlier agreed we were not going to update that text, and keep an informative reference to RFC 4572. >>>>> >>>>> OK, I guess I remember that now. Is it considered acceptable to >>>>> issue a new document with a reference to an obsolete document when it isn't to highlight a difference from the current document? >>>>> >>>>> Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide. >>>> >>>> As far as I know, there’s no hard and fast rule about this. It >>>> really depends on whether the difference between the new and >>>> obsolete dependencies are material to the draft. I do think we (i.e. >>>> the IESG) would favor referencing the new RFC, but would be open to >>>> arguments about why a WG chose to reference the obsolete version >>>> >>>> Does anyone recall the reasoning in this instance? >>> >>> Just to make sure we are on the same page, there are TWO references to RFC 4572 in the draft. >>> >>> The FIRST reference is in section 8, where it is used to reference an >>> example in RFC 4572. The same example exists in RFC 8122, so we can change that reference. >>> >>> The SECOND reference is in section 10.2.1, as part of the updated >>> text for RFC 5763. Now, RFC 5763 references RFC 4572 in 4 difference >>> places, so if we change the >reference to RFC 8122 in the text >>> updated by the draft we would also have to do it in every other place. That was the reason we decided not to do it (I have no problem doing it that's what IESG wants, though). >> >> Thanks for pointing that out. I just looked at that to size up the >> situation. Of those four references, three of them are in section 5 >> and will all be replaced by the new text in this document. The remaining reference is simply a general one in the introduction. And then in addition there is the actual reference text in the normative references. >> >> ISTM that it would be sufficient to update the reference in the new >> text for section 5 and then add a general statement to update all references to 4572 to refer to 8122. >> >> But again, this is really an IESG issue at this point. > > Or, we could just go ahead and do it :) > > Regards, > > Christer > >> >> >> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: 29 July 2017 01:07 >>>> To: Paul Kyzivat ; >>>> draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>> >>>> Subject: RE: [Gen-art] Gen-ART Last Call review of >>>> draft-ietf-mmusic-dtls-sdp-27 Hi Paul, Thanks for the review. I'll >>>> fix references. >>>> Regards, >>>> Christer >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 28 July 2017 04:01 >>>> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>> >>>> Subject: [Gen-art] Gen-ART Last Call review of >>>> draft-ietf-mmusic-dtls-sdp-27 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>> Document: draft-ietf-mmusic-dtls-sdp-27 >>>> Reviewer: Paul Kyzivat >>>> Review Date: 2017-07-07 >>>> IETF LC End Date: 2017-07-24 >>>> IESG Telechat date: 2017-08-15 >>>> Summary: >>>> This draft is basically ready for publication, but has nits that should be fixed before publication. >>>> (These nits were reported by IdNits. I apologize for not noticing >>>> these during my Last Call review.) >>>> Issues: >>>> Major: 0 >>>> Minor: 0 >>>> Nits: 2 >>>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but no >>>> explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. >>>> (2) NIT: Obsolete informational reference (is this intentional?): >>>> RFC >>>> 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. >>> >> > From nobody Mon Jul 31 01:05: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 33B1A12EC13; Mon, 31 Jul 2017 01:05:25 -0700 (PDT) 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 vVCp0Bbf-FIE; Mon, 31 Jul 2017 01:05:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0E2128961; Mon, 31 Jul 2017 01:05:22 -0700 (PDT) X-AuditID: c1b4fb25-5efff70000001eeb-aa-597ee4c02e46 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.ED.07915.0C4EE795; Mon, 31 Jul 2017 10:05:21 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Mon, 31 Jul 2017 10:05:20 +0200 From: Christer Holmberg To: Paul Kyzivat , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pD///QEgIAAQsKAgAEBLjCAABUpAIAAKPpAgAGEIyD//+oVAIAA0u4g Date: Mon, 31 Jul 2017 08:05:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> In-Reply-To: <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> 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+NgFupnkeLIzCtJLcpLzFFi42KZGbE9RPfgk7pIg8Xr2Szmd55mt9hxdweb xdVXn1kspi5/zGKxYsMBVgdWj7/vPzB5LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZfaeO sRc8s6q4cOg7YwPjEssuRk4OCQETicfdvawgtpDAEUaJFWf5uxi5gOzFjBIbD11g6WLk4GAT sJDo/qcNUiMi4CGxYspjVpAaZoFVjBLrWxsYQRLCAkESX/+uZIQoCpZoevgUys6T+LfrJguI zSKgKrHw5EmwOK+Ar8SzuVOZIZa9YpH4NGUeWBGngIPE3F/zwWxGATGJ76fWMIHYzALiEree zGeCuFpAYsme88wQtqjEy8f/WCFsJYnGJU9YQY5mFtCUWL9LH6JVUWJK90N2iL2CEidnPmGZ wCg6C8nUWQgds5B0zELSsYCRZRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYDQd3PJbdQfj 5TeOhxgFOBiVeHidbtZFCrEmlhVX5h5ilOBgVhLhfb8bKMSbklhZlVqUH19UmpNafIhRmoNF SZzXcd+FCCGB9MSS1OzU1ILUIpgsEwenVAOjk/G/emf5eb2RTa67JRdqO93Zrd9++KHj947T v8/lNWXsWV7u/O1+XHGb91RWgaA1f3XuLXnJ8jFMjUs3cJbOzmrLxGN1c7JCg5fEVl/W/zm5 IDNwlnDE7XirkzbZFj982S6Z9fc5/5TWjfz5vIXPhE3hfp/2D9WJfbGxZR5lS77cNm1y/KvE UpyRaKjFXFScCACPB7K5ogIAAA== Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 08:05:25 -0000 SGkgUGF1bCwNCg0KPj4gUFIgY3JlYXRlZDoNCj4+IA0KPj4gaHR0cHM6Ly9naXRodWIuY29tL2Nk aDR1L2RyYWZ0LWR0bHMtc2RwL3B1bGwvMzQNCj4NCj5UaGlzIGxlYXZlcyBSRkM1NzYzIGluIGFu IGluY29uc2lzdGVudCBzdGF0ZToNCj4tIHRoZSByZWZlcmVuY2UgdG8gODEyMiBpbiBzZWN0aW9u IDUgaXNuJ3QgYmFja2VkIHVwIHdpdGggYW4gZW50cnkgaW4gdGhlIHJlZmVyZW5jZXMgc2VjdGlv bg0KDQpJbiB0aGUgUFIsIEkgRE8gYWRkIDgxMjIgdG8gdGhlIHJlZmVyZW5jZSBzZWN0aW9uIG9m IDU3NjMgOikNCg0KPi0gdGhlcmUgaXMgc3RpbGwgYSByZWZlcmVuY2UgdG8gNDU3MiBpbiB0aGUg aW50cm9kdWN0aW9uLg0KDQpJIGNvdWxkIGFkZCBhIHN0YXRlbWVudCwgc2F5aW5nIHRoYXQgdGhl IHJlZmVyZW5jZSBpbiB0aGUgSW50cm9kdWN0aW9uIGlzIHVwZGF0ZWQuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCg0KDQoNCk90aGVyd2lzZSBsb29rcyByaWdodC4NCg0KCVRoYW5rcywNCglQ YXVsDQoNCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGVyaWNzc29uLmNvbV0NCj4gU2VudDogMjkgSnVseSAyMDE3IDIzOjM4DQo+IFRvOiBQ YXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IEJlbiBDYW1wYmVsbCANCj4gPGJl bkBub3N0cnVtLmNvbT4NCj4gQ2M6IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRm Lm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIA0KPiA8Z2VuLWFydEBpZXRmLm9yZz47IElF VEYgTU1VU0lDIFdHIDxtbXVzaWNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbR2VuLWFydF0g R2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mIA0KPiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC0yNw0KPiANCj4gSGksDQo+IA0KPj4+Pj4+IFJlZ2FyZGluZyB0aGUgcmVmZXJlbmNlIHRvIFJG QyA0NTcyLCB0aGUgbmV3IHRleHQgaW4gc2VjdGlvbg0KPj4+Pj4+IDEwLjIuMSByZWZlcmVuY2Vz IFJGQyA0NTcyLiBXZSBlYXJsaWVyIGFncmVlZCB3ZSB3ZXJlIG5vdCBnb2luZyB0byB1cGRhdGUg dGhhdCB0ZXh0LCBhbmQga2VlcCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDQ1NzIu DQo+Pj4+Pg0KPj4+Pj4gT0ssIEkgZ3Vlc3MgSSByZW1lbWJlciB0aGF0IG5vdy4gSXMgaXQgY29u c2lkZXJlZCBhY2NlcHRhYmxlIHRvIA0KPj4+Pj4gaXNzdWUgYSBuZXcgZG9jdW1lbnQgd2l0aCBh IHJlZmVyZW5jZSB0byBhbiBvYnNvbGV0ZSBkb2N1bWVudCB3aGVuIGl0IGlzbid0IHRvIGhpZ2hs aWdodCBhIGRpZmZlcmVuY2UgZnJvbSB0aGUgY3VycmVudCBkb2N1bWVudD8NCj4+Pj4+DQo+Pj4+ PiBTaW5jZSB0aGlzIGlzIGEgcmV2aWV3IGZvciB0aGUgdGVsZWNvbmZlcmVuY2UsIEknbGwganVz dCBsZWF2ZSB0aGF0IGZvciB0aGUgSUVTRyBmb2xrIHRvIGRlY2lkZS4NCj4+Pj4NCj4+Pj4gQXMg ZmFyIGFzIEkga25vdywgdGhlcmXigJlzIG5vIGhhcmQgYW5kIGZhc3QgcnVsZSBhYm91dCB0aGlz LiBJdCANCj4+Pj4gcmVhbGx5IGRlcGVuZHMgb24gd2hldGhlciB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSBuZXcgYW5kIA0KPj4+PiBvYnNvbGV0ZSBkZXBlbmRlbmNpZXMgYXJlIG1hdGVyaWFs IHRvIHRoZSBkcmFmdC4gSSBkbyB0aGluayB3ZSAoaS5lLg0KPj4+PiB0aGUgSUVTRykgd291bGQg ZmF2b3IgcmVmZXJlbmNpbmcgdGhlIG5ldyBSRkMsIGJ1dCB3b3VsZCBiZSBvcGVuIHRvIA0KPj4+ PiBhcmd1bWVudHMgYWJvdXQgd2h5IGEgV0cgY2hvc2UgdG8gcmVmZXJlbmNlIHRoZSBvYnNvbGV0 ZSB2ZXJzaW9uDQo+Pj4+DQo+Pj4+IERvZXMgYW55b25lIHJlY2FsbCB0aGUgcmVhc29uaW5nIGlu IHRoaXMgaW5zdGFuY2U/DQo+Pj4NCj4+PiBKdXN0IHRvIG1ha2Ugc3VyZSB3ZSBhcmUgb24gdGhl IHNhbWUgcGFnZSwgdGhlcmUgYXJlIFRXTyByZWZlcmVuY2VzIHRvIFJGQyA0NTcyIGluIHRoZSBk cmFmdC4NCj4+Pg0KPj4+IFRoZSBGSVJTVCByZWZlcmVuY2UgaXMgaW4gc2VjdGlvbiA4LCB3aGVy ZSBpdCBpcyB1c2VkIHRvIHJlZmVyZW5jZSANCj4+PiBhbiBleGFtcGxlIGluIFJGQyA0NTcyLiBU aGUgc2FtZSBleGFtcGxlIGV4aXN0cyBpbiBSRkMgODEyMiwgc28gd2UgY2FuIGNoYW5nZSB0aGF0 IHJlZmVyZW5jZS4NCj4+Pg0KPj4+IFRoZSBTRUNPTkQgcmVmZXJlbmNlIGlzIGluIHNlY3Rpb24g MTAuMi4xLCBhcyBwYXJ0IG9mIHRoZSB1cGRhdGVkIA0KPj4+IHRleHQgZm9yIFJGQyA1NzYzLiBO b3csIFJGQyA1NzYzIHJlZmVyZW5jZXMgUkZDIDQ1NzIgaW4gNCBkaWZmZXJlbmNlIA0KPj4+IHBs YWNlcywgc28gaWYgd2UgY2hhbmdlIHRoZSA+cmVmZXJlbmNlIHRvIFJGQyA4MTIyIGluIHRoZSB0 ZXh0IA0KPj4+IHVwZGF0ZWQgYnkgdGhlIGRyYWZ0IHdlIHdvdWxkIGFsc28gaGF2ZSB0byBkbyBp dCBpbiBldmVyeSBvdGhlciBwbGFjZS4gVGhhdCB3YXMgdGhlIHJlYXNvbiB3ZSBkZWNpZGVkIG5v dCB0byBkbyBpdCAoSSBoYXZlIG5vIHByb2JsZW0gZG9pbmcgaXQgdGhhdCdzIHdoYXQgSUVTRyB3 YW50cywgdGhvdWdoKS4NCj4+DQo+PiBUaGFua3MgZm9yIHBvaW50aW5nIHRoYXQgb3V0LiBJIGp1 c3QgbG9va2VkIGF0IHRoYXQgdG8gc2l6ZSB1cCB0aGUgDQo+PiBzaXR1YXRpb24uIE9mIHRob3Nl IGZvdXIgcmVmZXJlbmNlcywgdGhyZWUgb2YgdGhlbSBhcmUgaW4gc2VjdGlvbiA1IA0KPj4gYW5k IHdpbGwgYWxsIGJlIHJlcGxhY2VkIGJ5IHRoZSBuZXcgdGV4dCBpbiB0aGlzIGRvY3VtZW50LiBU aGUgcmVtYWluaW5nIHJlZmVyZW5jZSBpcyBzaW1wbHkgYSBnZW5lcmFsIG9uZSBpbiB0aGUgaW50 cm9kdWN0aW9uLiBBbmQgdGhlbiBpbiBhZGRpdGlvbiB0aGVyZSBpcyB0aGUgYWN0dWFsIHJlZmVy ZW5jZSB0ZXh0IGluIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcy4NCj4+DQo+PiBJU1RNIHRoYXQg aXQgd291bGQgYmUgc3VmZmljaWVudCB0byB1cGRhdGUgdGhlIHJlZmVyZW5jZSBpbiB0aGUgbmV3 IA0KPj4gdGV4dCBmb3Igc2VjdGlvbiA1IGFuZCB0aGVuIGFkZCBhIGdlbmVyYWwgc3RhdGVtZW50 IHRvIHVwZGF0ZSBhbGwgcmVmZXJlbmNlcyB0byA0NTcyIHRvIHJlZmVyIHRvIDgxMjIuDQo+Pg0K Pj4gQnV0IGFnYWluLCB0aGlzIGlzIHJlYWxseSBhbiBJRVNHIGlzc3VlIGF0IHRoaXMgcG9pbnQu DQo+IA0KPiBPciwgd2UgY291bGQganVzdCBnbyBhaGVhZCBhbmQgZG8gaXQgOikNCj4gDQo+IFJl Z2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4+DQo+Pg0KPj4NCj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgW21haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb21dDQo+Pj4+IFNlbnQ6IDI5IEp1bHkgMjAxNyAwMTow Nw0KPj4+PiBUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyANCj4+Pj4g ZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnDQo+Pj4+IENjOiBHZW5lcmFs IEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+ Pj4gPG1tdXNpY0BpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUkU6IFtHZW4tYXJ0XSBHZW4tQVJU IExhc3QgQ2FsbCByZXZpZXcgb2YNCj4+Pj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcg SGkgUGF1bCwgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBJJ2xsIA0KPj4+PiBmaXggcmVmZXJlbmNl cy4NCj4+Pj4gUmVnYXJkcywNCj4+Pj4gQ2hyaXN0ZXINCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1XQ0KPj4+PiBTZW50OiAyOCBKdWx5IDIwMTcgMDQ6MDENCj4+Pj4gVG86IGRyYWZ0LWll dGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZw0KPj4+PiBDYzogR2VuZXJhbCBBcmVhIFJl dmlldyBUZWFtIDxnZW4tYXJ0QGlldGYub3JnPjsgSUVURiBNTVVTSUMgV0cgDQo+Pj4+IDxtbXVz aWNAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCBy ZXZpZXcgb2YNCj4+Pj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcgSSBhbSB0aGUgYXNz aWduZWQgR2VuLUFSVCByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYSBS ZXZpZXcgVGVhbSAoR2VuLUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHIGZvciB0aGUgSUVURiBDaGFpci4gUGxlYXNlIHdhaXQgZm9yIGRp cmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3JlIHBvc3Rpbmcg YSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ug c2VlIHRoZSBGQVEgYXQgPOKAi2h0dHA6Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3Ry YWMvd2lraS9HZW5BcnRmYXE+Lg0KPj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRs cy1zZHAtMjcNCj4+Pj4gUmV2aWV3ZXI6IFBhdWwgS3l6aXZhdA0KPj4+PiBSZXZpZXcgRGF0ZTog MjAxNy0wNy0wNw0KPj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA3LTI0DQo+Pj4+IElFU0cg VGVsZWNoYXQgZGF0ZTogMjAxNy0wOC0xNQ0KPj4+PiBTdW1tYXJ5Og0KPj4+PiBUaGlzIGRyYWZ0 IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNo b3VsZCBiZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+Pj4+IChUaGVzZSBuaXRzIHdlcmUg cmVwb3J0ZWQgYnkgSWROaXRzLiBJIGFwb2xvZ2l6ZSBmb3Igbm90IG5vdGljaW5nIA0KPj4+PiB0 aGVzZSBkdXJpbmcgbXkgTGFzdCBDYWxsIHJldmlldy4pDQo+Pj4+IElzc3VlczoNCj4+Pj4gTWFq b3I6IDANCj4+Pj4gTWlub3I6IDANCj4+Pj4gTml0czogIDINCj4+Pj4gKDEpIE5JVDogVW51c2Vk IFJlZmVyZW5jZTogJ1JGQzUyNDUnIGlzIGRlZmluZWQgb24gbGluZSAxMDY1LCBidXQgDQo+Pj4+ IG5vIGV4cGxpY2l0IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQgVGhpcyBpcyBub3cg cmVkdW5kYW50IGJlY2F1c2UgYWxsIHRoZSByZWZlcmVuY2VzIGluIHRoZSB0ZXh0IGhhdmUgYmVl biBjaGFuZ2VkIHRvIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMuDQo+Pj4+ICgyKSBOSVQ6IE9i c29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6DQo+ Pj4+IFJGQw0KPj4+PiA0NTcyIFRoaXMgaXMgbm93IG9ic29sZXRlIGJlY2F1c2UgaXQgaGFzIGJl ZW4gcmVwbGFjZWQgYnkgUkZDODEyMi4gVGhpcyBkcmFmdCBzaG91bGQgbm93IGJlIHJlZmVyZW5j aW5nIHRoYXQuDQo+Pj4NCj4+DQo+IA0KDQo= From nobody Mon Jul 31 09:03: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 70C19132555; Mon, 31 Jul 2017 09:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 nznGehB_RvSw; Mon, 31 Jul 2017 09:03:16 -0700 (PDT) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E523131723; Mon, 31 Jul 2017 09:03:16 -0700 (PDT) X-AuditID: 1207440c-c4bff70000000b4f-8c-597f54c3c7f2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id DA.0B.02895.3C45F795; Mon, 31 Jul 2017 12:03:15 -0400 (EDT) Received: from [192.168.1.110] (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v6VG3CIZ031965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Jul 2017 12:03:13 -0400 To: Christer Holmberg , Ben Campbell Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se> From: Paul Kyzivat Message-ID: <6cf88d1c-526a-ccf2-0103-7822d81a2690@alum.mit.edu> Date: Mon, 31 Jul 2017 12:03:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixO6iqHs4pD7S4N0fdYv5nafZLS7MPMxo sePuDjaLq68+s1hMXf6YxYHV49fXq2weS5b8ZPKYtfMJSwBzFJdNSmpOZllqkb5dAldG38nH TAU3dCr2nv3G3MC4SqWLkZNDQsBE4nn7d8YuRi4OIYEdTBKNVx9DOVeZJL6dvcwKUiUsECRx 58gMdhBbRCBeYvn/7WBFzAK7GCWet6yD6ljHKtF/ZhFYB5uAlsScQ/9ZQGxeAXuJnceaGUFs FgFViR33roHZogJpEjO+X2eGqBGUODnzCVg9p4CfxKK3zWA2s4CZxLzND5khbHGJW0/mM0HY 8hLNW2czT2AUmIWkfRaSlllIWmYhaVnAyLKKUS4xpzRXNzcxM6c4NVm3ODkxLy+1SNdQLzez RC81pXQTIyTceXYwflsnc4hRgINRiYf3gXl9pBBrYllxZe4hRkkOJiVR3jNSQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivOsNgXK8KYmVValF+TApaQ4WJXFe1SXqfkIC6YklqdmpqQWpRTBZ GQ4OJQleoSCgRsGi1PTUirTMnBKENBMHJ8hwHqDhH4NBhhcXJOYWZ6ZD5E8x6nL8mrn1C5MQ S15+XqqUOO98kEECIEUZpXlwc2Bp6hWjONBbwrwFIKN4gCkObtIroCVMQEskS2tBlpQkIqSk Ghhdj1eaCew5KHj27Ym4cF3ZSUUtN2usN2qJ9HWc+flqcshBvstGe1o0/+yvT3gpoyV3+5Xo 3JkCSk97c7YLPirIfP42fsNu3dUCc1gv3pgn2up2pcX53tLwXuZG5gctj84dFa1Y+mdm86eH J7cFJ+1etumAi4cX+7EAk/V9upuDXLnMn98VNGdXYinOSDTUYi4qTgQACWuPei4DAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 16:03:19 -0000 On 7/31/17 4:05 AM, Christer Holmberg wrote: > Hi Paul, > >>> PR created: >>> >>> https://github.com/cdh4u/draft-dtls-sdp/pull/34 >> >> This leaves RFC5763 in an inconsistent state: >> - the reference to 8122 in section 5 isn't backed up with an entry in the references section > > In the PR, I DO add 8122 to the reference section of 5763 :) Oh, sorry. >> - there is still a reference to 4572 in the introduction. > > I could add a statement, saying that the reference in the Introduction is updated. That works for me. Thanks, Paul > Regards, > > Christer > > > > > Otherwise looks right. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: 29 July 2017 23:38 >> To: Paul Kyzivat ; Ben Campbell >> >> Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; General Area Review Team >> ; IETF MMUSIC WG >> Subject: RE: [Gen-art] Gen-ART Last Call review of >> draft-ietf-mmusic-dtls-sdp-27 >> >> Hi, >> >>>>>>> Regarding the reference to RFC 4572, the new text in section >>>>>>> 10.2.1 references RFC 4572. We earlier agreed we were not going to update that text, and keep an informative reference to RFC 4572. >>>>>> >>>>>> OK, I guess I remember that now. Is it considered acceptable to >>>>>> issue a new document with a reference to an obsolete document when it isn't to highlight a difference from the current document? >>>>>> >>>>>> Since this is a review for the teleconference, I'll just leave that for the IESG folk to decide. >>>>> >>>>> As far as I know, there’s no hard and fast rule about this. It >>>>> really depends on whether the difference between the new and >>>>> obsolete dependencies are material to the draft. I do think we (i.e. >>>>> the IESG) would favor referencing the new RFC, but would be open to >>>>> arguments about why a WG chose to reference the obsolete version >>>>> >>>>> Does anyone recall the reasoning in this instance? >>>> >>>> Just to make sure we are on the same page, there are TWO references to RFC 4572 in the draft. >>>> >>>> The FIRST reference is in section 8, where it is used to reference >>>> an example in RFC 4572. The same example exists in RFC 8122, so we can change that reference. >>>> >>>> The SECOND reference is in section 10.2.1, as part of the updated >>>> text for RFC 5763. Now, RFC 5763 references RFC 4572 in 4 difference >>>> places, so if we change the >reference to RFC 8122 in the text >>>> updated by the draft we would also have to do it in every other place. That was the reason we decided not to do it (I have no problem doing it that's what IESG wants, though). >>> >>> Thanks for pointing that out. I just looked at that to size up the >>> situation. Of those four references, three of them are in section 5 >>> and will all be replaced by the new text in this document. The remaining reference is simply a general one in the introduction. And then in addition there is the actual reference text in the normative references. >>> >>> ISTM that it would be sufficient to update the reference in the new >>> text for section 5 and then add a general statement to update all references to 4572 to refer to 8122. >>> >>> But again, this is really an IESG issue at this point. >> >> Or, we could just go ahead and do it :) >> >> Regards, >> >> Christer >> >>> >>> >>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: 29 July 2017 01:07 >>>>> To: Paul Kyzivat ; >>>>> draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>>> >>>>> Subject: RE: [Gen-art] Gen-ART Last Call review of >>>>> draft-ietf-mmusic-dtls-sdp-27 Hi Paul, Thanks for the review. I'll >>>>> fix references. >>>>> Regards, >>>>> Christer >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: 28 July 2017 04:01 >>>>> To: draft-ietf-mmusic-dtls-sdp.all@ietf.org >>>>> Cc: General Area Review Team ; IETF MMUSIC WG >>>>> >>>>> Subject: [Gen-art] Gen-ART Last Call review of >>>>> draft-ietf-mmusic-dtls-sdp-27 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>> Document: draft-ietf-mmusic-dtls-sdp-27 >>>>> Reviewer: Paul Kyzivat >>>>> Review Date: 2017-07-07 >>>>> IETF LC End Date: 2017-07-24 >>>>> IESG Telechat date: 2017-08-15 >>>>> Summary: >>>>> This draft is basically ready for publication, but has nits that should be fixed before publication. >>>>> (These nits were reported by IdNits. I apologize for not noticing >>>>> these during my Last Call review.) >>>>> Issues: >>>>> Major: 0 >>>>> Minor: 0 >>>>> Nits: 2 >>>>> (1) NIT: Unused Reference: 'RFC5245' is defined on line 1065, but >>>>> no explicit reference was found in the text This is now redundant because all the references in the text have been changed to draft-ietf-ice-rfc5245bis. >>>>> (2) NIT: Obsolete informational reference (is this intentional?): >>>>> RFC >>>>> 4572 This is now obsolete because it has been replaced by RFC8122. This draft should now be referencing that. >>>> >>> >> > From nobody Mon Jul 31 10:20: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 D83AF132702; Mon, 31 Jul 2017 10:20:31 -0700 (PDT) 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 GcFMz90-LqJO; Mon, 31 Jul 2017 10:20:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99124132701; Mon, 31 Jul 2017 10:20:28 -0700 (PDT) X-AuditID: c1b4fb2d-c3b2c9c000005f66-fa-597f66daa973 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.41.24422.AD66F795; Mon, 31 Jul 2017 19:20:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Mon, 31 Jul 2017 19:19:39 +0200 From: Christer Holmberg To: Paul Kyzivat , Ben Campbell CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , General Area Review Team , IETF MMUSIC WG Thread-Topic: [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 Thread-Index: AQHTB0VTgKnrsM/ZrUePhRU1wUhw6qJp3c2ggAAC0pD///QEgIAAQsKAgAEBLjCAABUpAIAAKPpAgAGEIyD//+oVAIAA0u4ggABlFwCAADbsMA== Date: Mon, 31 Jul 2017 17:19:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CCA52CE@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CCA1616@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA1662@ESESSMB109.ericsson.se> <73BB780D-2A87-4C6E-BF8A-9976BCB953E1@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CCA2017@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA234E@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CCA35FF@ESESSMB109.ericsson.se> <2aac65f2-ea15-3825-b9f9-917ddc935578@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B4CCA42A8@ESESSMB109.ericsson.se> <6cf88d1c-526a-ccf2-0103-7822d81a2690@alum.mit.edu> In-Reply-To: <6cf88d1c-526a-ccf2-0103-7822d81a2690@alum.mit.edu> 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+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ve6ttPpIgxl9lhbzO0+zW+y4u4PN 4uqrzywWU5c/ZrFYseEAqwOrx9/3H5g8liz5yeQxa+cTlgDmKC6blNSczLLUIn27BK6M3WuX MhfMc6p4tXMbYwPjEYcuRk4OCQETicX7t7N3MXJxCAkcYZRY9nYhK4SzmFFi67JdTF2MHBxs AhYS3f+0QRpEBDwkVkx5DFbDLLCKUWJ9awMjSEJYIEji69+VjBBFwRJND59C2XUSH6ZOYAex WQRUJW4+/skMYvMK+Eo8OLSaEWLZE1aJjomzwRo4BRwk7hz5DGYzCohJfD+1hgnEZhYQl7j1 ZD4TxNkCEkv2nGeGsEUlXj7+xwphK0ksuv0Z7GhmAU2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJ jKKzkEydhdAxC0nHLCQdCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtPBLb91dzCu fu14iFGAg1GJh9ferz5SiDWxrLgy9xCjBAezkgivRTxQiDclsbIqtSg/vqg0J7X4EKM0B4uS OK/DvgsRQgLpiSWp2ampBalFMFkmDk6pBsbaDeIX6v/usJS8caDkStf5z28qXN8YpW/mjr7K dW5tyuOjZpFd2wNKc9dbfpXf4vbgR0eClTXj/m9XGdm0fCR6U5Zb8P/r/fEoWnrG1ksVW+XX yHc2Vna5eaZyvmh8dHeugfUZ470Jgib/bv74x3hx7jRTl/9h078X/uJ5seLh5MMB06a97j6u xFKckWioxVxUnAgAXUhAN6MCAAA= Archived-At: Subject: Re: [MMUSIC] [Gen-art] Gen-ART Last Call review of draft-ietf-mmusic-dtls-sdp-27 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2017 17:20:32 -0000 UFIgdXBkYXRlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVk dV0gDQpTZW50OiAzMSBKdWx5IDIwMTcgMTg6MDMNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5j b20+DQpDYzogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAuYWxsQGlldGYub3JnOyBHZW5lcmFs IEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11 c2ljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCBy ZXZpZXcgb2YgZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCg0KT24gNy8zMS8xNyA0OjA1 IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGkgUGF1bCwNCj4gDQo+Pj4gUFIgY3Jl YXRlZDoNCj4+Pg0KPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1kdGxzLXNkcC9w dWxsLzM0DQo+Pg0KPj4gVGhpcyBsZWF2ZXMgUkZDNTc2MyBpbiBhbiBpbmNvbnNpc3RlbnQgc3Rh dGU6DQo+PiAtIHRoZSByZWZlcmVuY2UgdG8gODEyMiBpbiBzZWN0aW9uIDUgaXNuJ3QgYmFja2Vk IHVwIHdpdGggYW4gZW50cnkgaW4gDQo+PiB0aGUgcmVmZXJlbmNlcyBzZWN0aW9uDQo+IA0KPiBJ biB0aGUgUFIsIEkgRE8gYWRkIDgxMjIgdG8gdGhlIHJlZmVyZW5jZSBzZWN0aW9uIG9mIDU3NjMg OikNCg0KT2gsIHNvcnJ5Lg0KDQo+PiAtIHRoZXJlIGlzIHN0aWxsIGEgcmVmZXJlbmNlIHRvIDQ1 NzIgaW4gdGhlIGludHJvZHVjdGlvbi4NCj4gDQo+IEkgY291bGQgYWRkIGEgc3RhdGVtZW50LCBz YXlpbmcgdGhhdCB0aGUgcmVmZXJlbmNlIGluIHRoZSBJbnRyb2R1Y3Rpb24gaXMgdXBkYXRlZC4N Cg0KVGhhdCB3b3JrcyBmb3IgbWUuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+IFJlZ2FyZHMsDQo+ IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPiANCj4gT3RoZXJ3aXNlIGxvb2tzIHJpZ2h0Lg0K PiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4gDQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVy DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IENocmlzdGVyIEhv bG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KPj4gU2VudDog MjkgSnVseSAyMDE3IDIzOjM4DQo+PiBUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1p dC5lZHU+OyBCZW4gQ2FtcGJlbGwgDQo+PiA8YmVuQG5vc3RydW0uY29tPg0KPj4gQ2M6IGRyYWZ0 LWlldGYtbW11c2ljLWR0bHMtc2RwLmFsbEBpZXRmLm9yZzsgR2VuZXJhbCBBcmVhIFJldmlldyBU ZWFtIA0KPj4gPGdlbi1hcnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyA8bW11c2ljQGlldGYu b3JnPg0KPj4gU3ViamVjdDogUkU6IFtHZW4tYXJ0XSBHZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcg b2YNCj4+IGRyYWZ0LWlldGYtbW11c2ljLWR0bHMtc2RwLTI3DQo+Pg0KPj4gSGksDQo+Pg0KPj4+ Pj4+PiBSZWdhcmRpbmcgdGhlIHJlZmVyZW5jZSB0byBSRkMgNDU3MiwgdGhlIG5ldyB0ZXh0IGlu IHNlY3Rpb24NCj4+Pj4+Pj4gMTAuMi4xIHJlZmVyZW5jZXMgUkZDIDQ1NzIuIFdlIGVhcmxpZXIg YWdyZWVkIHdlIHdlcmUgbm90IGdvaW5nIHRvIHVwZGF0ZSB0aGF0IHRleHQsIGFuZCBrZWVwIGFu IGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNDU3Mi4NCj4+Pj4+Pg0KPj4+Pj4+IE9LLCBJ IGd1ZXNzIEkgcmVtZW1iZXIgdGhhdCBub3cuIElzIGl0IGNvbnNpZGVyZWQgYWNjZXB0YWJsZSB0 byANCj4+Pj4+PiBpc3N1ZSBhIG5ldyBkb2N1bWVudCB3aXRoIGEgcmVmZXJlbmNlIHRvIGFuIG9i c29sZXRlIGRvY3VtZW50IHdoZW4gaXQgaXNuJ3QgdG8gaGlnaGxpZ2h0IGEgZGlmZmVyZW5jZSBm cm9tIHRoZSBjdXJyZW50IGRvY3VtZW50Pw0KPj4+Pj4+DQo+Pj4+Pj4gU2luY2UgdGhpcyBpcyBh IHJldmlldyBmb3IgdGhlIHRlbGVjb25mZXJlbmNlLCBJJ2xsIGp1c3QgbGVhdmUgdGhhdCBmb3Ig dGhlIElFU0cgZm9sayB0byBkZWNpZGUuDQo+Pj4+Pg0KPj4+Pj4gQXMgZmFyIGFzIEkga25vdywg dGhlcmXigJlzIG5vIGhhcmQgYW5kIGZhc3QgcnVsZSBhYm91dCB0aGlzLiBJdCANCj4+Pj4+IHJl YWxseSBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbmV3IGFu ZCANCj4+Pj4+IG9ic29sZXRlIGRlcGVuZGVuY2llcyBhcmUgbWF0ZXJpYWwgdG8gdGhlIGRyYWZ0 LiBJIGRvIHRoaW5rIHdlIChpLmUuDQo+Pj4+PiB0aGUgSUVTRykgd291bGQgZmF2b3IgcmVmZXJl bmNpbmcgdGhlIG5ldyBSRkMsIGJ1dCB3b3VsZCBiZSBvcGVuIA0KPj4+Pj4gdG8gYXJndW1lbnRz IGFib3V0IHdoeSBhIFdHIGNob3NlIHRvIHJlZmVyZW5jZSB0aGUgb2Jzb2xldGUgDQo+Pj4+PiB2 ZXJzaW9uDQo+Pj4+Pg0KPj4+Pj4gRG9lcyBhbnlvbmUgcmVjYWxsIHRoZSByZWFzb25pbmcgaW4g dGhpcyBpbnN0YW5jZT8NCj4+Pj4NCj4+Pj4gSnVzdCB0byBtYWtlIHN1cmUgd2UgYXJlIG9uIHRo ZSBzYW1lIHBhZ2UsIHRoZXJlIGFyZSBUV08gcmVmZXJlbmNlcyB0byBSRkMgNDU3MiBpbiB0aGUg ZHJhZnQuDQo+Pj4+DQo+Pj4+IFRoZSBGSVJTVCByZWZlcmVuY2UgaXMgaW4gc2VjdGlvbiA4LCB3 aGVyZSBpdCBpcyB1c2VkIHRvIHJlZmVyZW5jZSANCj4+Pj4gYW4gZXhhbXBsZSBpbiBSRkMgNDU3 Mi4gVGhlIHNhbWUgZXhhbXBsZSBleGlzdHMgaW4gUkZDIDgxMjIsIHNvIHdlIGNhbiBjaGFuZ2Ug dGhhdCByZWZlcmVuY2UuDQo+Pj4+DQo+Pj4+IFRoZSBTRUNPTkQgcmVmZXJlbmNlIGlzIGluIHNl Y3Rpb24gMTAuMi4xLCBhcyBwYXJ0IG9mIHRoZSB1cGRhdGVkIA0KPj4+PiB0ZXh0IGZvciBSRkMg NTc2My4gTm93LCBSRkMgNTc2MyByZWZlcmVuY2VzIFJGQyA0NTcyIGluIDQgDQo+Pj4+IGRpZmZl cmVuY2UgcGxhY2VzLCBzbyBpZiB3ZSBjaGFuZ2UgdGhlID5yZWZlcmVuY2UgdG8gUkZDIDgxMjIg aW4gDQo+Pj4+IHRoZSB0ZXh0IHVwZGF0ZWQgYnkgdGhlIGRyYWZ0IHdlIHdvdWxkIGFsc28gaGF2 ZSB0byBkbyBpdCBpbiBldmVyeSBvdGhlciBwbGFjZS4gVGhhdCB3YXMgdGhlIHJlYXNvbiB3ZSBk ZWNpZGVkIG5vdCB0byBkbyBpdCAoSSBoYXZlIG5vIHByb2JsZW0gZG9pbmcgaXQgdGhhdCdzIHdo YXQgSUVTRyB3YW50cywgdGhvdWdoKS4NCj4+Pg0KPj4+IFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhh dCBvdXQuIEkganVzdCBsb29rZWQgYXQgdGhhdCB0byBzaXplIHVwIHRoZSANCj4+PiBzaXR1YXRp b24uIE9mIHRob3NlIGZvdXIgcmVmZXJlbmNlcywgdGhyZWUgb2YgdGhlbSBhcmUgaW4gc2VjdGlv biA1IA0KPj4+IGFuZCB3aWxsIGFsbCBiZSByZXBsYWNlZCBieSB0aGUgbmV3IHRleHQgaW4gdGhp cyBkb2N1bWVudC4gVGhlIHJlbWFpbmluZyByZWZlcmVuY2UgaXMgc2ltcGx5IGEgZ2VuZXJhbCBv bmUgaW4gdGhlIGludHJvZHVjdGlvbi4gQW5kIHRoZW4gaW4gYWRkaXRpb24gdGhlcmUgaXMgdGhl IGFjdHVhbCByZWZlcmVuY2UgdGV4dCBpbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMuDQo+Pj4N Cj4+PiBJU1RNIHRoYXQgaXQgd291bGQgYmUgc3VmZmljaWVudCB0byB1cGRhdGUgdGhlIHJlZmVy ZW5jZSBpbiB0aGUgbmV3IA0KPj4+IHRleHQgZm9yIHNlY3Rpb24gNSBhbmQgdGhlbiBhZGQgYSBn ZW5lcmFsIHN0YXRlbWVudCB0byB1cGRhdGUgYWxsIHJlZmVyZW5jZXMgdG8gNDU3MiB0byByZWZl ciB0byA4MTIyLg0KPj4+DQo+Pj4gQnV0IGFnYWluLCB0aGlzIGlzIHJlYWxseSBhbiBJRVNHIGlz c3VlIGF0IHRoaXMgcG9pbnQuDQo+Pg0KPj4gT3IsIHdlIGNvdWxkIGp1c3QgZ28gYWhlYWQgYW5k IGRvIGl0IDopDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+Pg0KPj4+ DQo+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBDaHJp c3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NCj4+ Pj4+IFNlbnQ6IDI5IEp1bHkgMjAxNyAwMTowNw0KPj4+Pj4gVG86IFBhdWwgS3l6aXZhdCA8cGt5 eml2YXRAYWx1bS5taXQuZWR1PjsgDQo+Pj4+PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC5h bGxAaWV0Zi5vcmcNCj4+Pj4+IENjOiBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1hcnRA aWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+Pj4+IDxtbXVzaWNAaWV0Zi5vcmc+DQo+Pj4+ PiBTdWJqZWN0OiBSRTogW0dlbi1hcnRdIEdlbi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZg0KPj4+ Pj4gZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcgSGkgUGF1bCwgVGhhbmtzIGZvciB0aGUg cmV2aWV3LiBJJ2xsIA0KPj4+Pj4gZml4IHJlZmVyZW5jZXMuDQo+Pj4+PiBSZWdhcmRzLA0KPj4+ Pj4gQ2hyaXN0ZXINCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9t OiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHVdDQo+Pj4+PiBTZW50 OiAyOCBKdWx5IDIwMTcgMDQ6MDENCj4+Pj4+IFRvOiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNk cC5hbGxAaWV0Zi5vcmcNCj4+Pj4+IENjOiBHZW5lcmFsIEFyZWEgUmV2aWV3IFRlYW0gPGdlbi1h cnRAaWV0Zi5vcmc+OyBJRVRGIE1NVVNJQyBXRyANCj4+Pj4+IDxtbXVzaWNAaWV0Zi5vcmc+DQo+ Pj4+PiBTdWJqZWN0OiBbR2VuLWFydF0gR2VuLUFSVCBMYXN0IENhbGwgcmV2aWV3IG9mDQo+Pj4+ PiBkcmFmdC1pZXRmLW1tdXNpYy1kdGxzLXNkcC0yNyBJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJU IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChH ZW4tQVJUKSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhl IElFU0cgZm9yIHRoZSBJRVRGIENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20g eW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9u IG9mIHRoZSBkcmFmdC4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBh dCA84oCLaHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9nZW4vdHJhYy93aWtpL0dlbkFy dGZhcT4uDQo+Pj4+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi1tbXVzaWMtZHRscy1zZHAtMjcNCj4+ Pj4+IFJldmlld2VyOiBQYXVsIEt5eml2YXQNCj4+Pj4+IFJldmlldyBEYXRlOiAyMDE3LTA3LTA3 DQo+Pj4+PiBJRVRGIExDIEVuZCBEYXRlOiAyMDE3LTA3LTI0DQo+Pj4+PiBJRVNHIFRlbGVjaGF0 IGRhdGU6IDIwMTctMDgtMTUNCj4+Pj4+IFN1bW1hcnk6DQo+Pj4+PiBUaGlzIGRyYWZ0IGlzIGJh c2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1dCBoYXMgbml0cyB0aGF0IHNob3VsZCBi ZSBmaXhlZCBiZWZvcmUgcHVibGljYXRpb24uDQo+Pj4+PiAoVGhlc2Ugbml0cyB3ZXJlIHJlcG9y dGVkIGJ5IElkTml0cy4gSSBhcG9sb2dpemUgZm9yIG5vdCBub3RpY2luZyANCj4+Pj4+IHRoZXNl IGR1cmluZyBteSBMYXN0IENhbGwgcmV2aWV3LikNCj4+Pj4+IElzc3VlczoNCj4+Pj4+IE1ham9y OiAwDQo+Pj4+PiBNaW5vcjogMA0KPj4+Pj4gTml0czogIDINCj4+Pj4+ICgxKSBOSVQ6IFVudXNl ZCBSZWZlcmVuY2U6ICdSRkM1MjQ1JyBpcyBkZWZpbmVkIG9uIGxpbmUgMTA2NSwgYnV0IA0KPj4+ Pj4gbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dCBUaGlzIGlzIG5v dyByZWR1bmRhbnQgYmVjYXVzZSBhbGwgdGhlIHJlZmVyZW5jZXMgaW4gdGhlIHRleHQgaGF2ZSBi ZWVuIGNoYW5nZWQgdG8gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy4NCj4+Pj4+ICgyKSBOSVQ6 IE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6 DQo+Pj4+PiBSRkMNCj4+Pj4+IDQ1NzIgVGhpcyBpcyBub3cgb2Jzb2xldGUgYmVjYXVzZSBpdCBo YXMgYmVlbiByZXBsYWNlZCBieSBSRkM4MTIyLiBUaGlzIGRyYWZ0IHNob3VsZCBub3cgYmUgcmVm ZXJlbmNpbmcgdGhhdC4NCj4+Pj4NCj4+Pg0KPj4NCj4gDQoNCg==