From bernard_aboba@hotmail.com Thu Dec 5 19:19:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982541AE245 for ; Thu, 5 Dec 2013 19:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beJ7orSkhk3e for ; Thu, 5 Dec 2013 19:19:30 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDD51AE17F for ; Thu, 5 Dec 2013 19:19:30 -0800 (PST) Received: from BLU404-EAS197 ([65.55.111.73]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Dec 2013 19:19:27 -0800 X-TMN: [3MRvFtFkKNHVZhjLBqcUhwUeLON+bmBwDNkdnTMJjAk=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: Date: Thu, 5 Dec 2013 19:19:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CEF1EE.E9191A50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac7yLVpwq6gzZI/WSVaTLo/gIrjlmQ== Content-Language: en-us X-OriginalArrivalTime: 06 Dec 2013 03:19:27.0179 (UTC) FILETIME=[F833D9B0:01CEF231] Subject: Re: [payload] temporal scalability in draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 03:19:32 -0000 ------=_NextPart_000_0083_01CEF1EE.E9191A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 1 states: In summary, the payload format described in this document enables a number of features in VP8, including: * Temporal scalability. However, Section 6 doesn't include information on format parameters or O/A considerations relating to temporal scaling. It appears that VP8 transports all temporal layers in a single RTP session utilizing a single SSRC (e.g. Single Session Transport), correct? Other than the max-fr parameter, is there anything that provides an indication of the capabilities of the receiver? Or is the encoder free to utilize any configuration that fits within the max-fr parameter? For example, if the Offer includes max-fr=60, does that mean that the receiver is prepared to handle any of the following? a. T0 = 60 fps (no temporal scalability) b. T0 = 15 fps, T1 = 15 fps, T2=30 fps c. T0 = 7.5 fps, T1 = 7.5 fps, T2 = 15 fps, T3 = 30 fps ------=_NextPart_000_0083_01CEF1EE.E9191A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 1 states:

 

   In = summary, the payload format described in this document enables = a

   number = of features in VP8, including:

 

·        = Temporal = scalability.

 

However, Section = 6 doesn’t include information on format parameters or O/A = considerations relating to temporal scaling.

 

It appears = that VP8 transports all temporal layers in a single RTP session = utilizing a single SSRC (e.g. Single Session Transport), correct? =

 

Other than the max-fr parameter, is there anything = that provides an indication of the capabilities of the receiver?  = Or is the encoder free to utilize any configuration that fits within the = max-fr parameter?

 

For example, = if the Offer includes max-fr=3D60, does that mean that the receiver is = prepared to handle any of the following?

a.       T0 = =3D 60 fps (no temporal scalability)

b.      = T0 =3D 15 fps, T1 =3D 15 fps, T2=3D30 = fps

c.       T0 = =3D 7.5 fps, T1 =3D 7.5 fps, T2 =3D 15 fps, T3 =3D 30 = fps

 

 

 

 

 

 

------=_NextPart_000_0083_01CEF1EE.E9191A50-- From internet-drafts@ietf.org Mon Dec 9 02:48:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1401AE24D; Mon, 9 Dec 2013 02:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXgjMqU1nRz0; Mon, 9 Dec 2013 02:48:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED1D1ADEC4; Mon, 9 Dec 2013 02:48:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131209104837.11929.30990.idtracker@ietfa.amsl.com> Date: Mon, 09 Dec 2013 02:48:37 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-10.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:48:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-10.txt Pages : 59 Date : 2013-12-09 Abstract: This document contains information on how to best write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-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 magnus.westerlund@ericsson.com Mon Dec 9 02:56:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C7C1AE27D for ; Mon, 9 Dec 2013 02:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGYLUi0A26yJ for ; Mon, 9 Dec 2013 02:56:11 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 762FA1AE279 for ; Mon, 9 Dec 2013 02:56:10 -0800 (PST) X-AuditID: c1b4fb2d-b7f1c8e000005ceb-c6-52a5a1c4fc50 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.4B.23787.4C1A5A25; Mon, 9 Dec 2013 11:56:05 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.2.347.0; Mon, 9 Dec 2013 11:56:04 +0100 Message-ID: <52A5A1BC.8000808@ericsson.com> Date: Mon, 9 Dec 2013 11:55:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "payload@ietf.org" References: <20131209104837.11929.30990.idtracker@ietfa.amsl.com> In-Reply-To: <20131209104837.11929.30990.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvre7RhUuDDBb+57G4dPEskwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mp68P8NccEiu4vWlX4wNjEckuhg5OSQETCRad19ihLDFJC7c W8/WxcjFISRwiFFi8f35TBDOMkaJxm/T2UGqeAW0JeZMPMcKYrMIqEi8b3oOFmcTsJC4+aOR DcQWFQiWuNq7jhmiXlDi5MwnLF2MHBwiApoSj74LgYSFBWwkvp45yQJiCwk4Slzd/wJsJKeA k8S8yfsZQcolBMQlehqDQMLMAnoSU662MELY8hLNW2czQ7RqSzQ0dbBOYBSchWTZLCQts5C0 LGBkXsXInpuYmZNebriJERh8B7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwcp583WSQpFElIcD4psSvOD2zZ8OPu99zuhiO3DthIL3u4L6LZbOeycmG Fh/wmpG4oSnhV07tMrYGzlNbhBRjoowUNFiFl8yeY/89PpKRz1ewWff1M+Vpy/TXXl5t/OrT nxTR4/qNSwIWie2+fiM2/cy7Q3djVr0R1Xx91bN26+0Gxr3OrX8dlFiKMxINtZiLihMB3ceG WQwCAAA= Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-10.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 10:56:13 -0000 WG, As the diff shows this is mostly typos and making references show the relevant information. : http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-10 However, I would like to make you aware of the one major changes in this document related to our AD's comment regarding the codec format normative reference. Richard said: > General: It seems like it would be helpful for this draft to address > one other point that may not be clear to first-timers: The payload > specification does not need to describe the coding, and in fact we > have several (open) payload specs for proprietary (closed) protocols. > The codec itself can be treated as a black box, as long as the > payload format tells an implementation how to configure that box and > format its inputs/outputs. This has resulted in a new paragraph in Section 7.1: The actual specification of the RTP payload format generally uses normative references to the codec format specification to define how codec data elements are included in the payload format. This normative reference can be to anything that have sufficient stability for a normative reference. There exist no formal requirement on the codec format specification being publicly available or free to access. However, it significantly helps in the review process if that specification is made available to any reviewer. There exist RTP payload format RFCs for open source project specifications as well as an individual company's proprietary format, and a large variety of standards development organizations or industrial forums. I personally believe this document is now ready for IESG review. Cheers Magnus On 2013-12-09 11:48, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > Title : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-10.txt > Pages : 59 > Date : 2013-12-09 > > Abstract: > This document contains information on how to best write an RTP > payload format specification. It provides reading tips, design > practices, and practical tips on how to produce an RTP payload format > specification quickly and with good results. A template is also > included with instructions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-10 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From trac+payload@trac.tools.ietf.org Mon Dec 9 18:03:42 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBC51AE0D5 for ; Mon, 9 Dec 2013 18:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RgDFoYMrA2s for ; Mon, 9 Dec 2013 18:03:40 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8F73F1ADED7 for ; Mon, 9 Dec 2013 18:03:40 -0800 (PST) Received: from localhost ([127.0.0.1]:39639 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqCfa-0002Cd-34; Tue, 10 Dec 2013 03:03:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-vp8@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 02:03:29 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/1 Message-ID: <067.bf301a865afb75fe2990319d8b871d8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-vp8@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hlundin@google.com, patrik.westin@gmail.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:02 -0800 Cc: payload@ietf.org Subject: [payload] #1: Temporal scalability in VP8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:03:42 -0000 #1: Temporal scalability in VP8 Section 1 states: In summary, the payload format described in this document enables a number of features in VP8, including: · Temporal scalability. However, Section 6 doesn’t include information on format parameters or O/A considerations relating to temporal scaling. It appears that VP8 transports all temporal layers in a single RTP session utilizing a single SSRC (e.g. Single Session Transport), so that RFC 5583 does not apply, correct? Other than the max-fr parameter, is there anything that provides an indication of the capabilities of the receiver? Or is the encoder free to utilize any configuration that fits within the max-fr parameter? For example, if the Offer includes max-fr=60, does that mean that the receiver is prepared to handle any of the following? a. T0 = 60 fps (no temporal scalability) b. T0 = 30 fps, T1 = 30 fps c. T0 = 15 fps, T1 = 15 fps, T2=30 fps d. T0 = 7.5 fps, T1 = 7.5 fps, T2 = 15 fps, T3 = 30 fps -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | vp8@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: vp8 | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 18:13:55 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA11AE0F8 for ; Mon, 9 Dec 2013 18:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_Tw_mXVf_XC for ; Mon, 9 Dec 2013 18:13:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A0AF81AE100 for ; Mon, 9 Dec 2013 18:13:52 -0800 (PST) Received: from localhost ([127.0.0.1]:40229 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqCpK-0001Es-4M; Tue, 10 Dec 2013 03:13:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 02:13:34 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/2 Message-ID: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:02 -0800 Cc: payload@ietf.org Subject: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:13:55 -0000 #2: Section 8.2: Updates RFC 4585? Use of the RPSI feedback message as positive acknowledgement is deprecated. In other words, the RPSI feedback message MUST only be used as a reference picture selection request, such that it can also be used in multicast. This appears to update RFC 4585 Section 6.3.1.1 and yet the document does not have an Updates: RFC 4585 in the header. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 18:22:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253B81AE0CC for ; Mon, 9 Dec 2013 18:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWx-mAuU-vea for ; Mon, 9 Dec 2013 18:22:47 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 48E701ADF48 for ; Mon, 9 Dec 2013 18:22:47 -0800 (PST) Received: from localhost ([127.0.0.1]:40782 helo=grenache.tools.ietf.org) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqCxb-0005av-44; Tue, 10 Dec 2013 03:22:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 02:22:00 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/3 Message-ID: <067.b248031f1935054970148a6277414d8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:02 -0800 Cc: payload@ietf.org Subject: [payload] #3: Section 1.1.2: Temporal Scalability Support X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:22:49 -0000 #3: Section 1.1.2: Temporal Scalability Support HEVC includes an improved support of temporal scalability, by inclusion of the signaling of TemporalId in the NAL unit header, the restriction that pictures of a particular temporal sub-layer cannot be used for inter prediction reference by pictures of a higher temporal sub-layer, the sub-bitstream extraction process, and the requirement that each sub-bitstream extraction output be a conforming bitstream. Media-aware network elements (MANEs) can utilize the TemporalId in the NAL unit header for stream adaptation purposes based on temporal scalability. [BA] The wording is a bit confusing; this appears to say that pictures from a higher temporal layer cannot reference pictures of a lower temporal layer, which isn't right. As noted in the succeeding section: A TSA picture and pictures following the TSA picture in decoding order do not use pictures prior to the TSA picture in decoding order with TemporalId greater than or equal to that of the TSA picture for inter prediction reference. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 18:22:53 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C99C1AE029 for ; Mon, 9 Dec 2013 18:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDByiTbqjsja for ; Mon, 9 Dec 2013 18:22:52 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EF3501ADF48 for ; Mon, 9 Dec 2013 18:22:51 -0800 (PST) Received: from localhost ([127.0.0.1]:40810 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqCxo-0002Lh-FG; Tue, 10 Dec 2013 03:22:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 02:22:20 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/4 Message-ID: <067.6968ad477db45f08af306bb920e6ba83@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:02 -0800 Cc: payload@ietf.org Subject: [payload] #4: Section 1.1.2: Temporal Scalability Support X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:22:53 -0000 #4: Section 1.1.2: Temporal Scalability Support HEVC includes an improved support of temporal scalability, by inclusion of the signaling of TemporalId in the NAL unit header, the restriction that pictures of a particular temporal sub-layer cannot be used for inter prediction reference by pictures of a higher temporal sub-layer, the sub-bitstream extraction process, and the requirement that each sub-bitstream extraction output be a conforming bitstream. Media-aware network elements (MANEs) can utilize the TemporalId in the NAL unit header for stream adaptation purposes based on temporal scalability. [BA] The wording is a bit confusing; this appears to say that pictures from a higher temporal layer cannot reference pictures of a lower temporal layer, which isn't right. As noted in the succeeding section: A TSA picture and pictures following the TSA picture in decoding order do not use pictures prior to the TSA picture in decoding order with TemporalId greater than or equal to that of the TSA picture for inter prediction reference. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 18:39:08 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AA91AE107 for ; Mon, 9 Dec 2013 18:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6bJ_PgrTGOD for ; Mon, 9 Dec 2013 18:39:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B13331AE10C for ; Mon, 9 Dec 2013 18:39:06 -0800 (PST) Received: from localhost ([127.0.0.1]:41820 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqDDm-0007mD-Co; Tue, 10 Dec 2013 03:38:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 02:38:50 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/5 Message-ID: <067.deb530189c005f89f3e34082780e7491@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:03 -0800 Cc: payload@ietf.org Subject: [payload] #5: Section 3.1.2: "MANE" definition X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:39:09 -0000 #5: Section 3.1.2: "MANE" definition media aware network element (MANE): A network element, such as a middlebox or application layer gateway that is capable of parsing certain aspects of the RTP payload headers or the RTP payload and reacting to their contents. Informative note: The concept of a MANE goes beyond normal routers or gateways in that a MANE has to be aware of the signaling (e.g., to learn about the payload type mappings of the media streams), and in that it has to be trusted when working with SRTP. The advantage of using MANEs is that they allow packets to be dropped according to the needs of the media coding. For example, if a MANE has to drop packets due to congestion on a certain link, it can identify and remove those packets whose elimination produces the least adverse effect on the user experience. After dropping packets, MANEs must rewrite RTCP packets to match the changes to the RTP packet stream as specified in Section 7 of [RFC3550]. [BA] In draft-ietf-avtcore-rtp-topologies-update the term "Selective Forwarding Unit" is being used. Should SFU be substituted for MANE here? I'd prefer that, because the MANE definition is showing its age: a. Today's SFUs parse payload headers, but if an RTP extension were to expose scalability info (e.g. LayerId, TID) that might not be necessary. b. While SFUs do need info transported in signaling protocols (e.g. transport and demultiplexing info), this doesn't mean they need contain a signaling parser. c. The requirement for access to SRTP encryption session keys is not an architectural requirement but rather is a consequence of the design of encryption transports (which always depend on SSRC, and sometimes also other fields (e.g. f8 defined in RFC 3711 depends on PT, Sequence No, etc. in addition), SFU design choices (e.g. need to rewrite PTs, support for RTP/RTCP multiplexing (which implies access to SRTP master keys), support for SST vs. MST (which could avoid Sequence Number rewrites), allocation of SSRCs vs. "source projection" (which would avoid SSRC rewriting, etc.). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 19:27:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9A61AE153 for ; Mon, 9 Dec 2013 19:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8kgxvwyaGIs for ; Mon, 9 Dec 2013 19:27:57 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 284891AE133 for ; Mon, 9 Dec 2013 19:27:57 -0800 (PST) Received: from localhost ([127.0.0.1]:43794 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqDz0-0007MU-W4; Tue, 10 Dec 2013 04:27:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 03:27:38 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/6 Message-ID: <067.4adc9845007df5cfa594d162894a517a@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:03 -0800 Cc: payload@ietf.org Subject: [payload] #6: Section 4.4: SST vs. MST X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 03:27:59 -0000 #6: Section 4.4: SST vs. MST This memo enables transmission of an HEVC bitstream over a single RTP session or multiple RTP sessions. The concept and working principle is inherited from [RFC6190] and follows a similar design. If only one RTP session is used for transmission of the HEVC bitstream, the transmission mode is referred to as single-session transmission (SST); otherwise (more than one RTP session is used for transmission of the HEVC bitstream), the transmission mode is referred to as multi-session transmission (MST). [BA] This definition strikes me as inexact, because with BUNDLE, it is possible for RFC 5583 to be used to negotiate "MST" usage within a single RTP session. However, such an implementation sending multiple SSRCs on the same RTP session would not really be "SST", would it? In reality, the Multi-Session vs. Single-the distinction is not the salient one -- it is Single SSRC Transport vs. Multiple SSRC Transport. SST SHOULD be used for point-to-point unicast scenarios, while MST SHOULD be used for point-to-multipoint multicast scenarios where different receivers require different operation points of the same HEVC bitstream, to improve bandwidth utilizing efficiency. [BA] While "Multi-Session Transport" is indeed more appropriate for multicast scenarios, "Multi-SSRC Transport" is also used for unicast scenarios. So this aspect could also be better explained. In addition to the unicast vs. multicast distinction, I'd like to see the text go into the advantages/disadvantages of SST vs. MST in unicast scenarios. Advantages of MST include: a. Not requiring sequence number rewriting on layer drops b. Ability to utilize stream pause/resume RTCP messages c. Potential improvements in ability to utilize RTCP reports to diagnose SVC performance d. Ability to negotiate FEC on some layers but not all e. Explicit negotiation of layering in SDP There are also some disadvantages, such as: g. Need to utilize DON and/or timestamp for order recovery. The transmission mode is indicated by the tx-mode media parameter (see section 7.1). If tx-mode is equal to "SST", SST MUST be used. Otherwise (tx-mode is equal to "MST"), MST MUST be used. [BA] Overall, I'd like to see this document have a goal to make progress beyond RFC 6190 by eliminating interoperability failures between SST and MST transport implementations. IMHO, with WebRTC on the horizon (where there may be no SDP exchange), we are increasingly moving to codecs that "just work", rather than those that rely on O/A to negotiate "modes" (and sometimes failing to find common ground). Can we instead strive for interoperability by design? With the commendable reduction in packet formats (e.g. STAP-A/B & FU-A/B -> AP & FU) would it be possible to mandate support for both MST and SST or at least mandate support for one of them in unicast & multicast scenarios? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 19:49:41 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2C61AE182 for ; Mon, 9 Dec 2013 19:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FnNDAiEbW-b for ; Mon, 9 Dec 2013 19:49:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 025401AE17F for ; Mon, 9 Dec 2013 19:49:38 -0800 (PST) Received: from localhost ([127.0.0.1]:44356 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqEK2-0001iu-TF; Tue, 10 Dec 2013 04:49:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 03:49:22 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/7 Message-ID: <067.545a1702f51506376ab72ebd22e95325@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:03 -0800 Cc: payload@ietf.org Subject: [payload] #7: Section 7.2.4 Dependency Signaling X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 03:49:41 -0000 #7: Section 7.2.4 Dependency Signaling If MST is used, the rules on signaling media decoding dependency in SDP as defined in [RFC5583] apply. The rules on "hierarchical or layered encoding" with multicast in Section 5.7 of [RFC4566] do not apply, i.e., the notation for Connection Data "c=" SHALL NOT be used with more than one address. The order of session dependency is given from the RTP session containing the lowest temporal sub-layer to the RTP session containing the highest temporal sub-layer. [BA] The difference in O/A signaling between MST and SST is something we should be striving to eliminate long-term. With RFC 6190, it wasn't possible in SST to use RFC 5583 to negotiate layering in SDP since each layer was on the same RTP session and we couldn't have multiple m lines with the same port value. But now that we have BUNDLE that problem goes away, and if we have multiple SSRC on the same RTP session, then RFC 5583 with BUNDLE may be the preferred way to go. On the other hand, the SST approach has some advantages for a WebRTC application that doesn't use SDP at all. Can we find some common ground, at least for MST unicast uses? -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload From trac+payload@trac.tools.ietf.org Mon Dec 9 19:51:05 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654751AE183 for ; Mon, 9 Dec 2013 19:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T5Eb-mk57yN for ; Mon, 9 Dec 2013 19:51:03 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8396D1AE17F for ; Mon, 9 Dec 2013 19:51:03 -0800 (PST) Received: from localhost ([127.0.0.1]:44441 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqELT-00045r-D1; Tue, 10 Dec 2013 04:50:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Tue, 10 Dec 2013 03:50:51 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/2#comment:1 Message-ID: <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org> References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com X-Mailman-Approved-At: Mon, 09 Dec 2013 21:00:03 -0800 Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 03:51:05 -0000 #2: Section 8.2: Updates RFC 4585? Comment (by bernard_aboba@hotmail.com): Another reason for Updates: RFC 4585 is that Section 8.1 defines the SPLI Feedback Message. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From stewe@stewe.org Tue Dec 10 13:50:29 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236951AE181 for ; Tue, 10 Dec 2013 13:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXRpMMINO3j6 for ; Tue, 10 Dec 2013 13:50:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 09B181AE04B for ; Tue, 10 Dec 2013 13:50:24 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB362.namprd07.prod.outlook.com (10.141.75.21) with Microsoft SMTP Server (TLS) id 15.0.837.10; Tue, 10 Dec 2013 21:50:17 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.124]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.251]) with mapi id 15.00.0837.004; Tue, 10 Dec 2013 21:50:16 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "bernard_aboba@hotmail.com" Thread-Topic: [payload] #2: Section 8.2: Updates RFC 4585? Thread-Index: AQHO9U1zcHYGr4OueUOZ4kiWGcCrBZpMy26AgACnawA= Date: Tue, 10 Dec 2013 21:50:15 +0000 Message-ID: References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org> In-Reply-To: <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 005671E15D x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(24454002)(199002)(189002)(164054003)(51704005)(76796001)(80022001)(76786001)(56816005)(31966008)(87936001)(77096001)(77982001)(59766001)(69226001)(66066001)(65816001)(81542001)(76482001)(74662001)(50986001)(36756003)(79102001)(90146001)(54316002)(56776001)(74502001)(47736001)(74876001)(80976001)(47976001)(19580395003)(49866001)(19580405001)(74706001)(81342001)(74366001)(81686001)(85306002)(47446002)(81816001)(54356001)(87266001)(46102001)(4396001)(51856001)(83322001)(2656002)(85852003)(83072002)(53806001)(63696002)(42262001)(861004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB362; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8B7A0AC077A3764287ECBBF6DB3A33D6@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 21:50:29 -0000 Hi Bernard, I don=B9t think it would be a particularly good idea if every payload forma= t spec is marked as =B3updating=B2 a general purpose spec when *for that payl= oad only* the payload spec allows/disallows/modifies aspects of the general purpose spec. =20 Hi Chairs: any guidance? Thanks, Stephan =20 On 12.9.2013, 19:50 , "payload issue tracker" wrote: >#2: Section 8.2: Updates RFC 4585? > > >Comment (by bernard_aboba@hotmail.com): > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SPLI > Feedback Message. > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: minor | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Resolution: > Keywords: | >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > From yekuiw@qti.qualcomm.com Tue Dec 10 14:33:01 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DD41AE17C for ; Tue, 10 Dec 2013 14:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIYMgnopdieb for ; Tue, 10 Dec 2013 14:32:58 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6B46B1AE0FA for ; Tue, 10 Dec 2013 14:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386714774; x=1418250774; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aYLK4ByKkiyu0AvZOrJ/ycojNvyMkpAKtqcd5nSyTr4=; b=ti9Ti+03XO7/qPMxRrSuK/PU3bZLif2S+yhrtoyuj0iVaKO2d9eb2oiI XT8jKiu+0f0Q9ms6Ud4dmrFMW35tTfX8QU49WVFL6ypv+Fdy+vgzo6hNp 0OTUA3HHWWqnyFsxBSVzNFiFGazDQkfI6hkZqgdlD7JGW+96ZDeSySx6p Q=; X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="1215103" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 10 Dec 2013 14:32:53 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="560013891" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Dec 2013 14:32:52 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.173]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 14:32:52 -0800 From: "Wang, Ye-Kui" To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "bernard_aboba@hotmail.com" Thread-Topic: [payload] #3: Section 1.1.2: Temporal Scalability Support Thread-Index: AQHO9U6zqtPTl2dnv06Pf94hb5la6JpOA5Jw Date: Tue, 10 Dec 2013 22:32:51 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83386E4E17@nasanexd02f.na.qualcomm.com> References: <067.b248031f1935054970148a6277414d8b@trac.tools.ietf.org> In-Reply-To: <067.b248031f1935054970148a6277414d8b@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.56.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] #3: Section 1.1.2: Temporal Scalability Support X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:33:01 -0000 SGkgQmVybmFyZCwNCg0KVGhhbmtzIGZvciB0aGUgY2FyZWZ1bCByZWFkaW5nIGFuZCB5b3VyIGNv bW1lbnRzLiANCg0KR29vZCBjYXRjaC4gVGhlIGludGVudGlvbiB3YXMgdG8gc2F5IHRoYXQgYSBw aWN0dXJlIHdpdGggYSBwYXJ0aWN1bGFyIHZhbHVlIG9mIFRlbXBvcmFsSWQgY2Fubm90IGJlIHVz ZWQgZm9yIGludGVyIHByZWRpY3Rpb24gcmVmZXJlbmNlIGJ5IGFueSBvdGhlciBwaWN0dXJlIHdp dGggYSBsb3dlciB2YWx1ZSBvZiBUZW1wb3JhbElkLiBUaHVzLCB3ZSBuZWVkIHRvIGNoYW5nZSAi YnkgcGljdHVyZXMgb2YgYSBoaWdoZXIgdGVtcG9yYWwgc3ViLWxheWVyIiBpbiB0aGUgZmlyc3Qg cGFyYWdyYXBoIHRvICIgYnkgcGljdHVyZXMgb2YgYSBsb3dlciB0ZW1wb3JhbCBzdWItbGF5ZXIi Lg0KDQpXaWxsIGJlIGNvcnJlY3RlZCBpbiB0aGUgbmV4dCBzdWJtaXNzaW9uIGJ5IHRoaXMgRnJp ZGF5Lg0KDQpCUiwgWUsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBheWxv YWQgaXNzdWUgdHJhY2tlciBbbWFpbHRvOnRyYWMrcGF5bG9hZEB0cmFjLnRvb2xzLmlldGYub3Jn XSANClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDksIDIwMTMgNjoyMiBQTQ0KVG86IGRyYWZ0LWll dGYtcGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzsgYmVybmFyZF9hYm9iYUBob3RtYWls LmNvbQ0KQ2M6IHBheWxvYWRAaWV0Zi5vcmcNClN1YmplY3Q6IFtwYXlsb2FkXSAjMzogU2VjdGlv biAxLjEuMjogVGVtcG9yYWwgU2NhbGFiaWxpdHkgU3VwcG9ydA0KDQojMzogU2VjdGlvbiAxLjEu MjogIFRlbXBvcmFsIFNjYWxhYmlsaXR5IFN1cHBvcnQNCg0KIEhFVkMgIGluY2x1ZGVzICBhbiAg aW1wcm92ZWQgIHN1cHBvcnQgIG9mICB0ZW1wb3JhbCAgc2NhbGFiaWxpdHksICBieQ0KICAgIGlu Y2x1c2lvbiBvZiB0aGUgc2lnbmFsaW5nIG9mIFRlbXBvcmFsSWQgaW4gdGhlIE5BTCB1bml0IGhl YWRlciwgdGhlDQogICAgcmVzdHJpY3Rpb24gdGhhdCBwaWN0dXJlcyBvZiBhIHBhcnRpY3VsYXIg dGVtcG9yYWwgc3ViLWxheWVyIGNhbm5vdA0KICAgIGJlIHVzZWQgZm9yIGludGVyIHByZWRpY3Rp b24gcmVmZXJlbmNlIGJ5IHBpY3R1cmVzIG9mIGEgaGlnaGVyDQogICAgdGVtcG9yYWwgc3ViLWxh eWVyLCB0aGUgc3ViLWJpdHN0cmVhbSBleHRyYWN0aW9uIHByb2Nlc3MsIGFuZCB0aGUNCiAgICBy ZXF1aXJlbWVudCAgdGhhdCAgZWFjaCAgc3ViLWJpdHN0cmVhbSAgZXh0cmFjdGlvbiAgb3V0cHV0 ICBiZSAgYQ0KICAgIGNvbmZvcm1pbmcgYml0c3RyZWFtLiAgTWVkaWEtYXdhcmUgbmV0d29yayBl bGVtZW50cyAoTUFORXMpIGNhbg0KICAgIHV0aWxpemUgdGhlIFRlbXBvcmFsSWQgaW4gdGhlIE5B TCB1bml0IGhlYWRlciBmb3Igc3RyZWFtIGFkYXB0YXRpb24NCiAgICBwdXJwb3NlcyBiYXNlZCBv biB0ZW1wb3JhbCBzY2FsYWJpbGl0eS4NCg0KIFtCQV0gVGhlIHdvcmRpbmcgaXMgYSBiaXQgY29u ZnVzaW5nOyB0aGlzIGFwcGVhcnMgdG8gc2F5IHRoYXQgcGljdHVyZXMgIGZyb20gYSBoaWdoZXIg dGVtcG9yYWwgbGF5ZXIgY2Fubm90IHJlZmVyZW5jZSBwaWN0dXJlcyBvZiBhIGxvd2VyIHRlbXBv cmFsICBsYXllciwgd2hpY2ggaXNuJ3QgcmlnaHQuIEFzIG5vdGVkIGluIHRoZSBzdWNjZWVkaW5n IHNlY3Rpb246DQoNCiBBIFRTQSBwaWN0dXJlIGFuZA0KICAgIHBpY3R1cmVzIGZvbGxvd2luZyB0 aGUgVFNBIHBpY3R1cmUgaW4gZGVjb2Rpbmcgb3JkZXIgZG8gbm90IHVzZQ0KICAgIHBpY3R1cmVz IHByaW9yIHRvIHRoZSBUU0EgcGljdHVyZSBpbiBkZWNvZGluZyBvcmRlciB3aXRoIFRlbXBvcmFs SWQNCiAgICBncmVhdGVyICB0aGFuICBvciAgZXF1YWwgIHRvICB0aGF0ICBvZiAgdGhlICBUU0Eg IHBpY3R1cmUgIGZvciAgaW50ZXINCiAgICBwcmVkaWN0aW9uIHJlZmVyZW5jZS4NCg0KLS0gDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t DQogUmVwb3J0ZXI6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIE93bmVyOiAgZHJh ZnQtaWV0Zi1wYXlsb2FkLQ0KICBiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tICAgICAgICAgIHwg IHJ0cC1oMjY1QHRvb2xzLmlldGYub3JnDQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgICAgICAg ICAgICAgfCAgICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgICAgICAg ICAgICAgfCAgTWlsZXN0b25lOiAgbWlsZXN0b25lMQ0KQ29tcG9uZW50OiAgcnRwLWgyNjUgICAg ICAgICAgICAgICAgIHwgICAgVmVyc2lvbjogIDEuMA0KIFNldmVyaXR5OiAgQWN0aXZlIFdHIERv Y3VtZW50ICAgICAgIHwgICBLZXl3b3JkczoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90b29s cy5pZXRmLm9yZy93Zy9wYXlsb2FkL3RyYWMvdGlja2V0LzM+DQpwYXlsb2FkIDxodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcGF5bG9hZC8+DQoNCg== From bernard_aboba@hotmail.com Tue Dec 10 14:59:41 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085921AE277 for ; Tue, 10 Dec 2013 14:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV_S8TpYGZLg for ; Tue, 10 Dec 2013 14:59:38 -0800 (PST) Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by ietfa.amsl.com (Postfix) with ESMTP id A5F471A1F1A for ; Tue, 10 Dec 2013 14:59:38 -0800 (PST) Received: from BLU169-W46 ([65.55.111.137]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Dec 2013 14:59:33 -0800 X-TMN: [hhj5pGJKAOVAwzbapIDQAbbECT7hnUfC] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_7db9b801-03a7-4bcf-899a-cedf83571fb6_" From: Bernard Aboba To: Stephan Wenger , payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" Date: Tue, 10 Dec 2013 14:59:32 -0800 Importance: Normal In-Reply-To: References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org>, <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2013 22:59:33.0065 (UTC) FILETIME=[7D73A390:01CEF5FB] Cc: "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:59:41 -0000 --_7db9b801-03a7-4bcf-899a-cedf83571fb6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I didn't understand from the text that the modification was only for H.265.= I had assumed that the references to feedback messages (and new message = definition) was for all codecs. =20 =20 > From: stewe@stewe.org > To: trac+payload@trac.tools.ietf.org=3B draft-ietf-payload-rtp-h265@tools= .ietf.org=3B bernard_aboba@hotmail.com > CC: payload@ietf.org > Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? > Date: Tue=2C 10 Dec 2013 21:50:15 +0000 >=20 > Hi Bernard=2C >=20 > I don=B9t think it would be a particularly good idea if every payload for= mat > spec is marked as =B3updating=B2 a general purpose spec when *for that pa= yload > only* the payload spec allows/disallows/modifies aspects of the general > purpose spec. =20 >=20 > Hi Chairs: any guidance? >=20 > Thanks=2C > Stephan > =20 >=20 > On 12.9.2013=2C 19:50 =2C "payload issue tracker" > wrote: >=20 > >#2: Section 8.2: Updates RFC 4585? > > > > > >Comment (by bernard_aboba@hotmail.com): > > > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SP= LI > > Feedback Message. > > > >--=20 > >-------------------------------------+----------------------------------= -- > >- > > Reporter: | Owner: draft-ietf-payload- > > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > >Component: rtp-h265 | Version: 1.0 > > Severity: Active WG Document | Resolution: > > Keywords: | > >-------------------------------------+----------------------------------= -- > >- > > > >Ticket URL: > >payload > > >=20 = --_7db9b801-03a7-4bcf-899a-cedf83571fb6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I didn't understand from the tex= t that the modification was only for =3BH.265. =3B =3B =3BI= had assumed that the =3Breferences to feedback messages =3B(and ne= w message definition) was for all codecs. =3B =3B
 =3B
<= div>>=3B From: stewe@stewe.org
>=3B To: trac+payload@trac.tools.ietf= .org=3B draft-ietf-payload-rtp-h265@tools.ietf.org=3B bernard_aboba@hotmail= .com
>=3B CC: payload@ietf.org
>=3B Subject: Re: [payload] #2: Se= ction 8.2: Updates RFC 4585?
>=3B Date: Tue=2C 10 Dec 2013 21:50:15 += 0000
>=3B
>=3B Hi Bernard=2C
>=3B
>=3B I don=B9t thin= k it would be a particularly good idea if every payload format
>=3B sp= ec is marked as =B3updating=B2 a general purpose spec when *for that payloa= d
>=3B only* the payload spec allows/disallows/modifies aspects of the= general
>=3B purpose spec.
>=3B
>=3B Hi Chairs: any guid= ance?
>=3B
>=3B Thanks=2C
>=3B Stephan
>=3B
>= =3B
>=3B On 12.9.2013=2C 19:50 =2C "payload issue tracker"
>=3B = <=3Btrac+payload@trac.tools.ietf.org>=3B wrote:
>=3B
>=3B &g= t=3B#2: Section 8.2: Updates RFC 4585?
>=3B >=3B
>=3B >=3B>=3B >=3BComment (by bernard_aboba@hotmail.com):
>=3B >=3B
= >=3B >=3B Another reason for Updates: RFC 4585 is that Section 8.1 defi= nes the SPLI
>=3B >=3B Feedback Message.
>=3B >=3B
>=3B = >=3B--
>=3B >=3B-------------------------------------+-----------= -------------------------
>=3B >=3B-
>=3B >=3B Reporter: = | Owner: draft-ietf-payload-
>=3B >=3B = bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org
>=3B &g= t=3B Type: defect | Status: new
>=3B >= =3B Priority: minor | Milestone: milestone1
>= =3B >=3BComponent: rtp-h265 | Version: 1.0
>= =3B >=3B Severity: Active WG Document | Resolution:
>=3B >= =3B Keywords: |
>=3B >=3B-----------------= --------------------+------------------------------------
>=3B >=3B-=
>=3B >=3B
>=3B >=3BTicket URL: <=3Bhttp://tools.ietf.org/w= g/payload/trac/ticket/2#comment:1>=3B
>=3B >=3Bpayload <=3Bhttp:= //tools.ietf.org/payload/>=3B
>=3B >=3B
>=3B
= = --_7db9b801-03a7-4bcf-899a-cedf83571fb6_-- From yekuiw@qti.qualcomm.com Tue Dec 10 15:23:26 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17D31AE22A for ; Tue, 10 Dec 2013 15:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD3plEE3Zgz5 for ; Tue, 10 Dec 2013 15:23:24 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 244D81ADEA6 for ; Tue, 10 Dec 2013 15:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386717799; x=1418253799; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=faUjcLfB6BjvHaeXRBV9crdfHdyAdekbiZknSsDi84M=; b=rN5+Nyurm9qC5A+4V6CJtcTVvSw9aS2Ur2H2uO9GzynhVLyvoPzfSNzM kBndgNazvvzLYpisGwEY7OPGelko9Q7gVqg1OpXuYX32r5TG3YowvhnuI skAqTnsyGoCy9O1aGAzu6VNvHJTURmGQRq7jcZrWRmQSOyS4WTIq46IjT s=; X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="56354326" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 10 Dec 2013 15:23:19 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="560045390" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Dec 2013 15:23:18 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.173]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 15:23:18 -0800 From: "Wang, Ye-Kui" To: Bernard Aboba , Stephan Wenger , payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] #2: Section 8.2: Updates RFC 4585? Thread-Index: AQHO9U13qA4t0ILqhkW1NYZLcXdcyppNUYqAgAEtlYCAABNbAP//f/9w Date: Tue, 10 Dec 2013 23:23:17 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org>, <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.56.153] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0nasanexd02fnaqu_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:23:26 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0nasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We had the intention that those related to RFC 4585 in draft-ietf-payload-r= tp-h265 are only for H.265. OK, then I think we just need to make this intention clearly said in the dr= aft. Will include this clarification into the next version. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, December 10, 2013 3:00 PM To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? I didn't understand from the text that the modification was only for H.265.= I had assumed that the references to feedback messages (and new message = definition) was for all codecs. > From: stewe@stewe.org > To: trac+payload@trac.tools.ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com > CC: payload@ietf.org > Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? > Date: Tue, 10 Dec 2013 21:50:15 +0000 > > Hi Bernard, > > I don=B9t think it would be a particularly good idea if every payload for= mat > spec is marked as =B3updating=B2 a general purpose spec when *for that pa= yload > only* the payload spec allows/disallows/modifies aspects of the general > purpose spec. > > Hi Chairs: any guidance? > > Thanks, > Stephan > > > On 12.9.2013, 19:50 , "payload issue tracker" > > wrote: > > >#2: Section 8.2: Updates RFC 4585? > > > > > >Comment (by bernard_aboba@hotmail.com)= : > > > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SP= LI > > Feedback Message. > > > >-- > >-------------------------------------+----------------------------------= -- > >- > > Reporter: | Owner: draft-ietf-payload- > > bernard_aboba@hotmail.com | rtp-h265@= tools.ietf.org > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > >Component: rtp-h265 | Version: 1.0 > > Severity: Active WG Document | Resolution: > > Keywords: | > >-------------------------------------+----------------------------------= -- > >- > > > >Ticket URL: > >payload > > > --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0nasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We had the intention that= those related to RFC 4585 in draft-ietf-payload-rtp-h265 are only for H.26= 5.

 <= /p>

OK, then I think we just = need to make this intention clearly said in the draft. Will include this cl= arification into the next version.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h2= 65@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?=

 

I didn't understand from the text that the modification = was only for H.265.   I had assumed that the refer= ences to feedback messages (and new message definition) was for all co= decs.  
 

> From: stewe@stewe.org
> To: trac+p= ayload@trac.tools.ietf.org; draft-ietf-pa= yload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com<= br> > CC: payload@ietf.org
> Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?
> Date: Tue, 10 Dec 2013 21:50:15 +0000
>
> Hi Bernard,
>
> I don=B9t think it would be a particularly good idea if every payload = format
> spec is marked as =B3updating=B2 a general purpose spec when *for that= payload
> only* the payload spec allows/disallows/modifies aspects of the genera= l
> purpose spec.
>
> Hi Chairs: any guidance?
>
> Thanks,
> Stephan
>
>
> On 12.9.2013, 19:50 , "payload issue tracker"
> <trac+p= ayload@trac.tools.ietf.org> wrote:
>
> >#2: Section 8.2: Updates RFC 4585?
> >
> >
> >Comment (by bernard_a= boba@hotmail.com):
> >
> > Another reason for Updates: RFC 4585 is that Section 8.1 defines = the SPLI
> > Feedback Message.
> >
> >--
> >-------------------------------------+------------------------= ------------
> >-
> > Reporter: | Owner: draft-ietf-payload-
> > bernard_aboba@hotmai= l.com | rtp-h265@tools.ietf.org
> > Type: defect | Status: new
> > Priority: minor | Milestone: milestone1
> >Component: rtp-h265 | Version: 1.0
> > Severity: Active WG Document | Resolution:
> > Keywords: |
> >-------------------------------------+------------------------= ------------
> >-
> >
> >Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/2#comment:1= >
> >payload <http://tool= s.ietf.org/payload/>
> >
>

--_000_8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Tue Dec 10 16:14:34 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECE1ADF91 for ; Tue, 10 Dec 2013 16:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za6jOfIRojku for ; Tue, 10 Dec 2013 16:14:31 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 245781ADF5A for ; Tue, 10 Dec 2013 16:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386720866; x=1418256866; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TE9TIlOf2/sgJVqor/bQOHaVA7lvDinvQZG5jo/9BoQ=; b=ziqrzmHMGFuoqsuwAszIhCJuTGmvtc4CLK+trpehepfH7E+Z1U42gjRK pkfPF4nruxu8EcMh3A3o4lW+1EQIWzQQV5ZoiELIkp5mQDMIPoERfkGSc 6wOf+3OaMIKM76V0ymmFHb8oUDbZfkre5f7GxTy2lPt4K1iS3qA0S3asR o=; X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="56421429" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Dec 2013 16:14:26 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="23886397" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Dec 2013 16:14:24 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.173]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 16:14:24 -0800 From: "Wang, Ye-Kui" To: Bernard Aboba , Stephan Wenger , payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] #2: Section 8.2: Updates RFC 4585? Thread-Index: AQHO9U13qA4t0ILqhkW1NYZLcXdcyppNUYqAgAEtlYCAABNbAP//f/9wgAAM/rA= Date: Wed, 11 Dec 2013 00:14:24 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org>, <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org>, <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.56.153] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83386E5120nasanexd02fnaqu_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:14:34 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E5120nasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, Bernard, I replied too quickly. In the draft, we define the following in section 8: 1) The SPLI Feedback Message (in 8.1) 2) Use of HEVC with the RPSI Feedback Message (in 8.2) 3) Use of HEVC with the SPLI Feedback Message (in 8.3) Only items 2 and 3 are only for H.265, while the first item defined in sect= ion 8.1 also applies to other codecs, and we even have the following note i= ncluded in the section: Informative note: The SPLI message defined in this memo also applies to oth= er codecs, and may later be moved to another extension of RFC 4585. Thus, your suggestion still needs to be considered. Would it be sufficient to just add "Updates RFC 4585", or it would actually= better to document the SPLI feedback message in a non-codec-specific docum= ent? BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Tuesday, December 10, 2013 3:23 PM To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payloa= d-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? We had the intention that those related to RFC 4585 in draft-ietf-payload-r= tp-h265 are only for H.265. OK, then I think we just need to make this intention clearly said in the dr= aft. Will include this clarification into the next version. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, December 10, 2013 3:00 PM To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? I didn't understand from the text that the modification was only for H.265.= I had assumed that the references to feedback messages (and new message = definition) was for all codecs. > From: stewe@stewe.org > To: trac+payload@trac.tools.ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com > CC: payload@ietf.org > Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? > Date: Tue, 10 Dec 2013 21:50:15 +0000 > > Hi Bernard, > > I don=B9t think it would be a particularly good idea if every payload for= mat > spec is marked as =B3updating=B2 a general purpose spec when *for that pa= yload > only* the payload spec allows/disallows/modifies aspects of the general > purpose spec. > > Hi Chairs: any guidance? > > Thanks, > Stephan > > > On 12.9.2013, 19:50 , "payload issue tracker" > > wrote: > > >#2: Section 8.2: Updates RFC 4585? > > > > > >Comment (by bernard_aboba@hotmail.com)= : > > > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SP= LI > > Feedback Message. > > > >-- > >-------------------------------------+----------------------------------= -- > >- > > Reporter: | Owner: draft-ietf-payload- > > bernard_aboba@hotmail.com | rtp-h265@= tools.ietf.org > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > >Component: rtp-h265 | Version: 1.0 > > Severity: Active WG Document | Resolution: > > Keywords: | > >-------------------------------------+----------------------------------= -- > >- > > > >Ticket URL: > >payload > > > --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E5120nasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry, Bernard, I replied= too quickly.

 <= /p>

In the draft, we define t= he following in section 8:

1) = ;     The SPLI Feedback= Message (in 8.1)

2) = ;     Use of HEVC with = the RPSI Feedback Message (in 8.2)

3) = ;     Use of HEVC with = the SPLI Feedback Message (in 8.3)

 <= /p>

Only items 2 and 3 are on= ly for H.265, while the first item defined in section 8.1 also applies to o= ther codecs, and we even have the following note included in the section:

 <= /p>

Informative note: The SPL= I message defined in this memo also applies to other codecs, and may later = be moved to another extension of RFC 4585.

 <= /p>

Thus, your suggestion sti= ll needs to be considered.

 <= /p>

Would it be sufficient to= just add “Updates RFC 4585”, or it would actually better to do= cument the SPLI feedback message in a non-codec-specific document?

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Tuesday, December 10, 2013 3:23 PM
To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf= -payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?=

 

We had the intention that= those related to RFC 4585 in draft-ietf-payload-rtp-h265 are only for H.26= 5.

 <= /p>

OK, then I think we just = need to make this intention clearly said in the draft. Will include this cl= arification into the next version.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

 

I didn't understand from the text that the modification = was only for H.265.   I had assumed that the refer= ences to feedback messages (and new message definition) was for all co= decs.  
 

> From: stewe@stewe.org
> To: trac+p= ayload@trac.tools.ietf.org; draft-ietf-pa= yload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com<= br> > CC: payload@ietf.org
> Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?
> Date: Tue, 10 Dec 2013 21:50:15 +0000
>
> Hi Bernard,
>
> I don=B9t think it would be a particularly good idea if every payload = format
> spec is marked as =B3updating=B2 a general purpose spec when *for that= payload
> only* the payload spec allows/disallows/modifies aspects of the genera= l
> purpose spec.
>
> Hi Chairs: any guidance?
>
> Thanks,
> Stephan
>
>
> On 12.9.2013, 19:50 , "payload issue tracker"
> <trac+p= ayload@trac.tools.ietf.org> wrote:
>
> >#2: Section 8.2: Updates RFC 4585?
> >
> >
> >Comment (by bernard_a= boba@hotmail.com):
> >
> > Another reason for Updates: RFC 4585 is that Section 8.1 defines = the SPLI
> > Feedback Message.
> >
> >--
> >-------------------------------------+------------------------= ------------
> >-
> > Reporter: | Owner: draft-ietf-payload-
> > bernard_aboba@hotmai= l.com | rtp-h265@tools.ietf.org
> > Type: defect | Status: new
> > Priority: minor | Milestone: milestone1
> >Component: rtp-h265 | Version: 1.0
> > Severity: Active WG Document | Resolution:
> > Keywords: |
> >-------------------------------------+------------------------= ------------
> >-
> >
> >Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/2#comment:1= >
> >payload <http://tool= s.ietf.org/payload/>
> >
>

--_000_8BA7D4CEACFFE04BA2D902BF11719A83386E5120nasanexd02fnaqu_-- From stewe@stewe.org Tue Dec 10 19:05:53 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFCC1AE33D for ; Tue, 10 Dec 2013 19:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJf7MOu6Z6Yp for ; Tue, 10 Dec 2013 19:05:50 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2817F1AE343 for ; Tue, 10 Dec 2013 19:05:49 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 11 Dec 2013 03:05:35 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.124]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.251]) with mapi id 15.00.0837.004; Wed, 11 Dec 2013 03:05:35 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "bernard_aboba@hotmail.com" Thread-Topic: [payload] #5: Section 3.1.2: "MANE" definition Thread-Index: AQHO9VD7OTU+jONY/E2aZNOUPR3vUZpNyu0A Date: Wed, 11 Dec 2013 03:05:34 +0000 Message-ID: References: <067.deb530189c005f89f3e34082780e7491@trac.tools.ietf.org> In-Reply-To: <067.deb530189c005f89f3e34082780e7491@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0057EE387C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(24454002)(199002)(189002)(51704005)(90146001)(69226001)(2656002)(87936001)(87266001)(4396001)(66066001)(81686001)(56816005)(85852003)(83072002)(81816001)(63696002)(47976001)(80022001)(85306002)(49866001)(36756003)(81542001)(47446002)(74502001)(76796001)(77096001)(74662001)(81342001)(74366001)(83322001)(31966008)(76786001)(54356001)(19580405001)(74706001)(54316002)(59766001)(56776001)(65816001)(80976001)(19580395003)(53806001)(79102001)(50986001)(74876001)(51856001)(77982001)(47736001)(46102001)(76482001)(42262001)(861004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" Subject: Re: [payload] #5: Section 3.1.2: "MANE" definition X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 03:05:53 -0000 Hi Bernard, A global substitute may be the wrong thing to do. In many instances, an SFU can do what is attributed into a MANE=B9s operation. However, in section 4.8 (last paragraph) and section 9 (security) final paragraph, MANEs perform operations that are outside the scope of an SFU (at least as I understand the SFU). So here is what I suggest: 1. Add informative reference to topologies-update 2. Add definition of Selective Forwarding Unit (SFU), refer to topologies-update. 3. Keep definition of MANE. Add note indicating that an SFU is one form of a MANE. 4. Replace MANE with SFU in all instances except section 4.8 last paragraph and section 9 last paragraph Does that work? Stephan On 12.9.2013, 18:38 , "payload issue tracker" wrote: >#5: Section 3.1.2: "MANE" definition > > media aware network element (MANE): A network element, such as a > middlebox or application layer gateway that is capable of parsing > certain aspects of the RTP payload headers or the RTP payload and > reacting to their contents. > > Informative note: The concept of a MANE goes beyond normal > routers or gateways in that a MANE has to be aware of the > signaling (e.g., to learn about the payload type mappings of the > media streams), and in that it has to be trusted when working > with SRTP. The advantage of using MANEs is that they allow > packets to be dropped according to the needs of the media coding. > For example, if a MANE has to drop packets due to congestion on a > certain link, it can identify and remove those packets whose > elimination produces the least adverse effect on the user > experience. After dropping packets, MANEs must rewrite RTCP > packets to match the changes to the RTP packet stream as > specified in Section 7 of [RFC3550]. > > [BA] In draft-ietf-avtcore-rtp-topologies-update the term "Selective > Forwarding Unit" is being used. Should SFU be substituted for MANE here? > I'd prefer that, because the MANE definition is showing its age: > > a. Today's SFUs parse payload headers, but if an RTP extension were to > expose scalability info (e.g. LayerId, TID) that might not be necessary. > > b. While SFUs do need info transported in signaling protocols (e.g. > transport and demultiplexing info), this doesn't mean they need contain a > signaling parser. > > c. The requirement for access to SRTP encryption session keys is not an > architectural requirement but rather is a consequence of the design of > encryption transports (which always depend on SSRC, and sometimes also > other fields (e.g. f8 defined in RFC 3711 depends on PT, Sequence No, >etc. > in addition), SFU design choices (e.g. need to rewrite PTs, support for > RTP/RTCP multiplexing (which implies access to SRTP master keys), support > for SST vs. MST (which could avoid Sequence Number rewrites), allocation > of SSRCs vs. "source projection" (which would avoid SSRC rewriting, >etc.). > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > From bernard_aboba@hotmail.com Tue Dec 10 19:16:14 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C6B1AE10B for ; Tue, 10 Dec 2013 19:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ujoglLF_EWB for ; Tue, 10 Dec 2013 19:16:12 -0800 (PST) Received: from blu0-omc4-s3.blu0.hotmail.com (blu0-omc4-s3.blu0.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id 01CD01AE10F for ; Tue, 10 Dec 2013 19:16:11 -0800 (PST) Received: from BLU403-EAS197 ([65.55.111.136]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Dec 2013 19:16:05 -0800 X-TMN: [BAl4TIFla0kbisRSBtWFKTIFqn1xly+4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-3A1B2A5A-F235-4830-91D2-5FCAE01952FC" Content-Transfer-Encoding: 7bit References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> Date: Tue, 10 Dec 2013 19:16:02 -0800 To: "Wang, Ye-Kui" X-OriginalArrivalTime: 11 Dec 2013 03:16:05.0856 (UTC) FILETIME=[54452600:01CEF61F] Cc: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 03:16:14 -0000 --Apple-Mail-3A1B2A5A-F235-4830-91D2-5FCAE01952FC Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBvayB3aXRoIHdoYXRldmVyIHBhdGggeW91IGFuZCB0aGUgV0cgYWdyZWUgb24uIEhvd2V2 ZXIgaXQgaXMgYSBiaXQgb2JzY3VyZSB0byBhZGQgYSBnZW5lcmFsIGNhcGFiaWxpdHkgd2l0aGlu IGFuIEguMjY1IHBheWxvYWQgZG9jdW1lbnQsIHNvIGlmIHRoYXQgcGF0aCBpcyBjaG9zZW4sIHRo ZSBnZW5lcmFsaXR5IHNob3VsZCBiZSBtYWRlIGNsZWFyIGZvciBleGFtcGxlLCBpbiB0aGUgYWJz dHJhY3QuDQoNCj4gT24gRGVjIDEwLCAyMDEzLCBhdCA0OjE0IFBNLCAiV2FuZywgWWUtS3VpIiA8 eWVrdWl3QHF0aS5xdWFsY29tbS5jb20+IHdyb3RlOg0KPiANCj4gU29ycnksIEJlcm5hcmQsIEkg cmVwbGllZCB0b28gcXVpY2tseS4NCj4gIA0KPiBJbiB0aGUgZHJhZnQsIHdlIGRlZmluZSB0aGUg Zm9sbG93aW5nIGluIHNlY3Rpb24gODoNCj4gMSkgICAgICBUaGUgU1BMSSBGZWVkYmFjayBNZXNz YWdlIChpbiA4LjEpDQo+IDIpICAgICAgVXNlIG9mIEhFVkMgd2l0aCB0aGUgUlBTSSBGZWVkYmFj ayBNZXNzYWdlIChpbiA4LjIpDQo+IDMpICAgICAgVXNlIG9mIEhFVkMgd2l0aCB0aGUgU1BMSSBG ZWVkYmFjayBNZXNzYWdlIChpbiA4LjMpDQo+ICANCj4gT25seSBpdGVtcyAyIGFuZCAzIGFyZSBv bmx5IGZvciBILjI2NSwgd2hpbGUgdGhlIGZpcnN0IGl0ZW0gZGVmaW5lZCBpbiBzZWN0aW9uIDgu MSBhbHNvIGFwcGxpZXMgdG8gb3RoZXIgY29kZWNzLCBhbmQgd2UgZXZlbiBoYXZlIHRoZSBmb2xs b3dpbmcgbm90ZSBpbmNsdWRlZCBpbiB0aGUgc2VjdGlvbjoNCj4gIA0KPiBJbmZvcm1hdGl2ZSBu b3RlOiBUaGUgU1BMSSBtZXNzYWdlIGRlZmluZWQgaW4gdGhpcyBtZW1vIGFsc28gYXBwbGllcyB0 byBvdGhlciBjb2RlY3MsIGFuZCBtYXkgbGF0ZXIgYmUgbW92ZWQgdG8gYW5vdGhlciBleHRlbnNp b24gb2YgUkZDIDQ1ODUuDQo+ICANCj4gVGh1cywgeW91ciBzdWdnZXN0aW9uIHN0aWxsIG5lZWRz IHRvIGJlIGNvbnNpZGVyZWQuDQo+ICANCj4gV291bGQgaXQgYmUgc3VmZmljaWVudCB0byBqdXN0 IGFkZCDigJxVcGRhdGVzIFJGQyA0NTg14oCdLCBvciBpdCB3b3VsZCBhY3R1YWxseSBiZXR0ZXIg dG8gZG9jdW1lbnQgdGhlIFNQTEkgZmVlZGJhY2sgbWVzc2FnZSBpbiBhIG5vbi1jb2RlYy1zcGVj aWZpYyBkb2N1bWVudD8NCj4gIA0KPiBCUiwgWUsNCj4gIA0KPiBGcm9tOiBwYXlsb2FkIFttYWls dG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2FuZywgWWUtS3VpDQo+ IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDEwLCAyMDEzIDM6MjMgUE0NCj4gVG86IEJlcm5hcmQg QWJvYmE7IFN0ZXBoYW4gV2VuZ2VyOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZw0KPiBDYzogcGF5bG9hZEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW3BheWxvYWRdICMyOiBTZWN0aW9uIDguMjogVXBkYXRlcyBSRkMgNDU4 NT8NCj4gIA0KPiBXZSBoYWQgdGhlIGludGVudGlvbiB0aGF0IHRob3NlIHJlbGF0ZWQgdG8gUkZD IDQ1ODUgaW4gZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1IGFyZSBvbmx5IGZvciBILjI2NS4N Cj4gIA0KPiBPSywgdGhlbiBJIHRoaW5rIHdlIGp1c3QgbmVlZCB0byBtYWtlIHRoaXMgaW50ZW50 aW9uIGNsZWFybHkgc2FpZCBpbiB0aGUgZHJhZnQuIFdpbGwgaW5jbHVkZSB0aGlzIGNsYXJpZmlj YXRpb24gaW50byB0aGUgbmV4dCB2ZXJzaW9uLg0KPiAgDQo+IEJSLCBZSw0KPiAgDQo+IEZyb206 IHBheWxvYWQgW21haWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC ZXJuYXJkIEFib2JhDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDEwLCAyMDEzIDM6MDAgUE0N Cj4gVG86IFN0ZXBoYW4gV2VuZ2VyOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IGRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZw0KPiBDYzogcGF5bG9hZEBpZXRmLm9yZw0K PiBTdWJqZWN0OiBSZTogW3BheWxvYWRdICMyOiBTZWN0aW9uIDguMjogVXBkYXRlcyBSRkMgNDU4 NT8NCj4gIA0KPiBJIGRpZG4ndCB1bmRlcnN0YW5kIGZyb20gdGhlIHRleHQgdGhhdCB0aGUgbW9k aWZpY2F0aW9uIHdhcyBvbmx5IGZvciBILjI2NS4gICBJIGhhZCBhc3N1bWVkIHRoYXQgdGhlIHJl ZmVyZW5jZXMgdG8gZmVlZGJhY2sgbWVzc2FnZXMgKGFuZCBuZXcgbWVzc2FnZSBkZWZpbml0aW9u KSB3YXMgZm9yIGFsbCBjb2RlY3MuICAgDQo+ICANCj4gPiBGcm9tOiBzdGV3ZUBzdGV3ZS5vcmcN Cj4gPiBUbzogdHJhYytwYXlsb2FkQHRyYWMudG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGF5 bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzsgYmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbQ0K PiA+IENDOiBwYXlsb2FkQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtwYXlsb2FkXSAjMjog U2VjdGlvbiA4LjI6IFVwZGF0ZXMgUkZDIDQ1ODU/DQo+ID4gRGF0ZTogVHVlLCAxMCBEZWMgMjAx MyAyMTo1MDoxNSArMDAwMA0KPiA+IA0KPiA+IEhpIEJlcm5hcmQsDQo+ID4gDQo+ID4gSSBkb27C uXQgdGhpbmsgaXQgd291bGQgYmUgYSBwYXJ0aWN1bGFybHkgZ29vZCBpZGVhIGlmIGV2ZXJ5IHBh eWxvYWQgZm9ybWF0DQo+ID4gc3BlYyBpcyBtYXJrZWQgYXMgwrN1cGRhdGluZ8KyIGEgZ2VuZXJh bCBwdXJwb3NlIHNwZWMgd2hlbiAqZm9yIHRoYXQgcGF5bG9hZA0KPiA+IG9ubHkqIHRoZSBwYXls b2FkIHNwZWMgYWxsb3dzL2Rpc2FsbG93cy9tb2RpZmllcyBhc3BlY3RzIG9mIHRoZSBnZW5lcmFs DQo+ID4gcHVycG9zZSBzcGVjLiANCj4gPiANCj4gPiBIaSBDaGFpcnM6IGFueSBndWlkYW5jZT8N Cj4gPiANCj4gPiBUaGFua3MsDQo+ID4gU3RlcGhhbg0KPiA+IA0KPiA+IA0KPiA+IE9uIDEyLjku MjAxMywgMTk6NTAgLCAicGF5bG9hZCBpc3N1ZSB0cmFja2VyIg0KPiA+IDx0cmFjK3BheWxvYWRA dHJhYy50b29scy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4gDQo+ID4gPiMyOiBTZWN0aW9uIDguMjog VXBkYXRlcyBSRkMgNDU4NT8NCj4gPiA+DQo+ID4gPg0KPiA+ID5Db21tZW50IChieSBiZXJuYXJk X2Fib2JhQGhvdG1haWwuY29tKToNCj4gPiA+DQo+ID4gPiBBbm90aGVyIHJlYXNvbiBmb3IgVXBk YXRlczogUkZDIDQ1ODUgaXMgdGhhdCBTZWN0aW9uIDguMSBkZWZpbmVzIHRoZSBTUExJDQo+ID4g PiBGZWVkYmFjayBNZXNzYWdlLg0KPiA+ID4NCj4gPiA+LS0gDQo+ID4gPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPi0NCj4gPiA+IFJlcG9ydGVyOiB8IE93bmVyOiBkcmFmdC1pZXRmLXBheWxvYWQt DQo+ID4gPiBiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tIHwgcnRwLWgyNjVAdG9vbHMuaWV0Zi5v cmcNCj4gPiA+IFR5cGU6IGRlZmVjdCB8IFN0YXR1czogbmV3DQo+ID4gPiBQcmlvcml0eTogbWlu b3IgfCBNaWxlc3RvbmU6IG1pbGVzdG9uZTENCj4gPiA+Q29tcG9uZW50OiBydHAtaDI2NSB8IFZl cnNpb246IDEuMA0KPiA+ID4gU2V2ZXJpdHk6IEFjdGl2ZSBXRyBEb2N1bWVudCB8IFJlc29sdXRp b246DQo+ID4gPiBLZXl3b3JkczogfA0KPiA+ID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4tDQo+ ID4gPg0KPiA+ID5UaWNrZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3BheWxvYWQv dHJhYy90aWNrZXQvMiNjb21tZW50OjE+DQo+ID4gPnBheWxvYWQgPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9wYXlsb2FkLz4NCj4gPiA+DQo+ID4NCg== --Apple-Mail-3A1B2A5A-F235-4830-91D2-5FCAE01952FC Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSBhbSBv ayB3aXRoIHdoYXRldmVyIHBhdGggeW91IGFuZCB0aGUgV0cgYWdyZWUgb24uIEhvd2V2ZXIgaXQg aXMgYSBiaXQgb2JzY3VyZSB0byBhZGQgYSBnZW5lcmFsIGNhcGFiaWxpdHkgd2l0aGluIGFuIEgu MjY1IHBheWxvYWQgZG9jdW1lbnQsIHNvIGlmIHRoYXQgcGF0aCBpcyBjaG9zZW4sIHRoZSBnZW5l cmFsaXR5IHNob3VsZCBiZSBtYWRlIGNsZWFyIGZvciBleGFtcGxlLCBpbiB0aGUgYWJzdHJhY3Qu PC9kaXY+PGRpdj48YnI+T24gRGVjIDEwLCAyMDEzLCBhdCA0OjE0IFBNLCAiV2FuZywgWWUtS3Vp IiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlla3Vpd0BxdGkucXVhbGNvbW0uY29tIj55ZWt1aXdAcXRp LnF1YWxjb21tLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGRpdj4NCg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3Ii IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48 IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJn aW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTk4NDAwMjEyOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMzExMDM2NCA2NzY5ODcwNSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 XEYwQjc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQjc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0OlxGMEE3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIwODkyMzAyMjA7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NzMzOTk4OTggLTQ4NTY5NjM3 NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjI7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYw QTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpcRjBCNzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpcRjBCNzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6XEYwQTc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KDQoNCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+U29ycnksIEJlcm5hcmQsIEkgcmVwbGllZCB0b28gcXVpY2tseS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHRo ZSBkcmFmdCwgd2UgZGVmaW5lIHRoZSBmb2xsb3dpbmcgaW4gc2VjdGlvbiA4OjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IS0tW2lmICFzdXBwb3J0TGlzdHNd LS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZSBTUExJIEZlZWRiYWNrIE1lc3NhZ2UgKGluIDguMSk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCEtLVtpZiAhc3VwcG9ydExpc3Rz XS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Vc2Ugb2YgSEVWQyB3aXRoIHRoZSBSUFNJIEZlZWRiYWNrIE1lc3NhZ2Ug KGluIDguMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCEt LVtpZiAhc3VwcG9ydExpc3RzXS0tPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Vc2Ugb2YgSEVWQyB3aXRoIHRoZSBTUExJ IEZlZWRiYWNrIE1lc3NhZ2UgKGluIDguMyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9ubHkgaXRlbXMgMiBhbmQgMyBh cmUgb25seSBmb3IgSC4yNjUsIHdoaWxlIHRoZSBmaXJzdCBpdGVtIGRlZmluZWQgaW4gc2VjdGlv biA4LjEgYWxzbyBhcHBsaWVzIHRvIG90aGVyIGNvZGVjcywgYW5kIHdlIGV2ZW4gaGF2ZSB0aGUg Zm9sbG93aW5nIG5vdGUgaW5jbHVkZWQNCiBpbiB0aGUgc2VjdGlvbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi42aW4iPkluZm9ybWF0aXZlIG5vdGU6IFRoZSBT UExJIG1lc3NhZ2UgZGVmaW5lZCBpbiB0aGlzIG1lbW8gYWxzbyBhcHBsaWVzIHRvIG90aGVyIGNv ZGVjcywgYW5kIG1heSBsYXRlciBiZSBtb3ZlZCB0byBhbm90aGVyIGV4dGVuc2lvbiBvZiBSRkMg NDU4NS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGh1cywgeW91ciBzdWdnZXN0aW9uIHN0aWxsIG5lZWRzIHRvIGJlIGNvbnNpZGVy ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Xb3VsZCBpdCBiZSBzdWZmaWNpZW50IHRvIGp1c3QgYWRkIOKAnFVwZGF0 ZXMgUkZDIDQ1ODXigJ0sIG9yIGl0IHdvdWxkIGFjdHVhbGx5IGJldHRlciB0byBkb2N1bWVudCB0 aGUgU1BMSSBmZWVkYmFjayBtZXNzYWdlIGluIGEgbm9uLWNvZGVjLXNwZWNpZmljIGRvY3VtZW50 PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QlIsIFlLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gcGF5bG9hZCBbPGEgaHJlZj0i bWFpbHRvOnBheWxvYWQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnBheWxvYWQtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldhbmcsIFllLUt1aTxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBEZWNlbWJlciAxMCwgMjAxMyAzOjIzIFBNPGJyPg0KPGI+VG86PC9i PiBCZXJuYXJkIEFib2JhOyBTdGVwaGFuIFdlbmdlcjsgcGF5bG9hZCBpc3N1ZSB0cmFja2VyOyA8 YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYub3Jn Ij5kcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyI+cGF5bG9hZEBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXlsb2FkXSAjMjogU2VjdGlvbiA4LjI6 IFVwZGF0ZXMgUkZDIDQ1ODU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIGhh ZCB0aGUgaW50ZW50aW9uIHRoYXQgdGhvc2UgcmVsYXRlZCB0byBSRkMgNDU4NSBpbiBkcmFmdC1p ZXRmLXBheWxvYWQtcnRwLWgyNjUgYXJlIG9ubHkgZm9yIEguMjY1Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T0ssIHRo ZW4gSSB0aGluayB3ZSBqdXN0IG5lZWQgdG8gbWFrZSB0aGlzIGludGVudGlvbiBjbGVhcmx5IHNh aWQgaW4gdGhlIGRyYWZ0LiBXaWxsIGluY2x1ZGUgdGhpcyBjbGFyaWZpY2F0aW9uIGludG8gdGhl IG5leHQgdmVyc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLCBZSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHBheWxv YWQgWzxhIGhyZWY9Im1haWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpwYXls b2FkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZXJuYXJkIEFi b2JhPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDEwLCAyMDEzIDM6MDAgUE08 YnI+DQo8Yj5Ubzo8L2I+IFN0ZXBoYW4gV2VuZ2VyOyBwYXlsb2FkIGlzc3VlIHRyYWNrZXI7IDxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAdG9vbHMuaWV0Zi5vcmci Pg0KZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnPC9hPjxicj4NCjxi PkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBheWxvYWRAaWV0Zi5vcmciPnBheWxvYWRAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcGF5bG9hZF0gIzI6IFNlY3Rpb24gOC4y OiBVcGRhdGVzIFJGQyA0NTg1Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRpZG4ndCB1bmRlcnN0YW5kIGZyb20gdGhl IHRleHQgdGhhdCB0aGUgbW9kaWZpY2F0aW9uIHdhcyBvbmx5IGZvciZuYnNwO0guMjY1LiZuYnNw OyZuYnNwOyZuYnNwO0kgaGFkIGFzc3VtZWQgdGhhdCB0aGUmbmJzcDtyZWZlcmVuY2VzIHRvIGZl ZWRiYWNrIG1lc3NhZ2VzJm5ic3A7KGFuZCBuZXcgbWVzc2FnZSBkZWZpbml0aW9uKSB3YXMgZm9y IGFsbCBjb2RlY3MuJm5ic3A7Jm5ic3A7DQo8YnI+DQombmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBGcm9tOiA8 YSBocmVmPSJtYWlsdG86c3Rld2VAc3Rld2Uub3JnIj4NCnN0ZXdlQHN0ZXdlLm9yZzwvYT48YnI+ DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86dHJhYytwYXlsb2FkQHRyYWMudG9vbHMuaWV0Zi5v cmciPnRyYWMrcGF5bG9hZEB0cmFjLnRvb2xzLmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpkcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYt cGF5bG9hZC1ydHAtaDI2NUB0b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86YmVy bmFyZF9hYm9iYUBob3RtYWlsLmNvbSI+YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbTwvYT48YnI+ DQomZ3Q7IENDOiA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyI+cGF5bG9hZEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbcGF5bG9hZF0gIzI6IFNlY3Rpb24gOC4y OiBVcGRhdGVzIFJGQyA0NTg1Pzxicj4NCiZndDsgRGF0ZTogVHVlLCAxMCBEZWMgMjAxMyAyMTo1 MDoxNSArMDAwMDxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBCZXJuYXJkLDxicj4NCiZndDsgPGJy Pg0KJmd0OyBJIGRvbsK5dCB0aGluayBpdCB3b3VsZCBiZSBhIHBhcnRpY3VsYXJseSBnb29kIGlk ZWEgaWYgZXZlcnkgcGF5bG9hZCBmb3JtYXQ8YnI+DQomZ3Q7IHNwZWMgaXMgbWFya2VkIGFzIMKz dXBkYXRpbmfCsiBhIGdlbmVyYWwgcHVycG9zZSBzcGVjIHdoZW4gKmZvciB0aGF0IHBheWxvYWQ8 YnI+DQomZ3Q7IG9ubHkqIHRoZSBwYXlsb2FkIHNwZWMgYWxsb3dzL2Rpc2FsbG93cy9tb2RpZmll cyBhc3BlY3RzIG9mIHRoZSBnZW5lcmFsPGJyPg0KJmd0OyBwdXJwb3NlIHNwZWMuIDxicj4NCiZn dDsgPGJyPg0KJmd0OyBIaSBDaGFpcnM6IGFueSBndWlkYW5jZT88YnI+DQomZ3Q7IDxicj4NCiZn dDsgVGhhbmtzLDxicj4NCiZndDsgU3RlcGhhbjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IE9uIDEyLjkuMjAxMywgMTk6NTAgLCAicGF5bG9hZCBpc3N1ZSB0cmFja2VyIjxicj4NCiZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0cmFjK3BheWxvYWRAdHJhYy50b29scy5pZXRmLm9yZyI+ dHJhYytwYXlsb2FkQHRyYWMudG9vbHMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyMyOiBTZWN0aW9uIDguMjogVXBkYXRlcyBSRkMgNDU4NT88YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtDb21tZW50IChieSA8YSBocmVm PSJtYWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWlsLmNvbSI+YmVybmFyZF9hYm9iYUBob3RtYWls LmNvbTwvYT4pOjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBbm90aGVyIHJlYXNvbiBm b3IgVXBkYXRlczogUkZDIDQ1ODUgaXMgdGhhdCBTZWN0aW9uIDguMSBkZWZpbmVzIHRoZSBTUExJ PGJyPg0KJmd0OyAmZ3Q7IEZlZWRiYWNrIE1lc3NhZ2UuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7LS0gPGJyPg0KJmd0OyAmZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDst PGJyPg0KJmd0OyAmZ3Q7IFJlcG9ydGVyOiB8IE93bmVyOiBkcmFmdC1pZXRmLXBheWxvYWQtPGJy Pg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpiZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tIj5i ZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tPC9hPiB8IDxhIGhyZWY9Im1haWx0bzpydHAtaDI2NUB0 b29scy5pZXRmLm9yZyI+DQpydHAtaDI2NUB0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZn dDsgVHlwZTogZGVmZWN0IHwgU3RhdHVzOiBuZXc8YnI+DQomZ3Q7ICZndDsgUHJpb3JpdHk6IG1p bm9yIHwgTWlsZXN0b25lOiBtaWxlc3RvbmUxPGJyPg0KJmd0OyAmZ3Q7Q29tcG9uZW50OiBydHAt aDI2NSB8IFZlcnNpb246IDEuMDxicj4NCiZndDsgJmd0OyBTZXZlcml0eTogQWN0aXZlIFdHIERv Y3VtZW50IHwgUmVzb2x1dGlvbjo8YnI+DQomZ3Q7ICZndDsgS2V5d29yZHM6IHw8YnI+DQomZ3Q7 ICZndDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0Oy08YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDtUaWNrZXQgVVJMOiAmbHQ7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn L3dnL3BheWxvYWQvdHJhYy90aWNrZXQvMiNjb21tZW50OjEiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy93Zy9wYXlsb2FkL3RyYWMvdGlja2V0LzIjY29tbWVudDoxPC9hPiZndDs8YnI+DQomZ3Q7ICZn dDtwYXlsb2FkICZsdDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGF5bG9hZC8iPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9wYXlsb2FkLzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCg0K PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-3A1B2A5A-F235-4830-91D2-5FCAE01952FC-- From bernard_aboba@hotmail.com Wed Dec 11 00:10:00 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529F31AE3BC for ; Wed, 11 Dec 2013 00:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 RtSPx76_pRBS for ; Wed, 11 Dec 2013 00:09:57 -0800 (PST) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2D1AE3EC for ; Wed, 11 Dec 2013 00:09:57 -0800 (PST) Received: from BLU405-EAS288 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Dec 2013 00:09:51 -0800 X-TMN: [QaXbVMQPTU5kFv5Un/bSuXdzjfZ5bp7Y] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: MIME-Version: 1.0 From: Bernard Aboba To: "=?utf-8?Q?stewe@stewe.org?=" , =?utf-8?Q?payload_issue_tracker?= , "=?utf-8?Q?draft-ietf-payload-rtp-h265@tools.ietf.org?=" Importance: Normal Date: Wed, 11 Dec 2013 07:46:36 +0000 Content-Type: multipart/alternative; boundary="_4C2B032A-6140-43EC-8CE9-8A9B12BD47DC_" X-OriginalArrivalTime: 11 Dec 2013 08:09:51.0931 (UTC) FILETIME=[5E3AC0B0:01CEF648] Cc: "=?utf-8?Q?payload@ietf.org?=" Subject: Re: [payload] =?utf-8?b?IzU6IFNlY3Rpb24gMy4xLjI6ICAgIk1BTkUiIGRlZmlu?= =?utf-8?q?ition?= X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 08:10:00 -0000 --_4C2B032A-6140-43EC-8CE9-8A9B12BD47DC_ Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SSBhbSBvayB3aXRoIHVzaW5nIOKAnE1BTkXigJ0gZm9yIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBT ZWN0aW9uIDQuOCwgc2luY2UgcHJlc3VtYWJseSBhbiBTRlUgd2lsbCBub3QgZG8gTkFMIHJlLXBh Y2tldGl6YXRpb24uIA0KDQoNClRoZSBsYXN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDkgY2FuIGFs c28gdXNlIHRoZSB0ZXJtIE1BTkUgYnV0IGl0IG5lZWRzIGEgYml0IG9mIHdvcmRzbWl0aGluZywg cGVyaGFwcy4gICBXaGVuIGRlYWxpbmcgd2l0aCBTU1QsIGV2ZW4gZGlzY2FyZGluZyBwYWNrZXRz IHJlcXVpcmVzIHRoZSBTUlRQIGF1dGhlbnRpY2F0aW9uIHNlc3Npb24ga2V5LCBiZWNhdXNlIHRo ZSBzZXF1ZW5jZSBuby4gbmVlZHMgdG8gYmUgcmV3cml0dGVuICh0aGlzIGlzIG5vdCB0cnVlIGZv ciBNdWx0aS1TU1JDIHRyYW5zcG9ydCkuICBUaGUgbmVlZCBmb3IgdGhlIFNSVFAgZW5jcnlwdGlv biBzZXNzaW9uIGtleSBleGlzdHMgaWYgYSBmaWVsZCB1dGlsaXplZCBieSB0aGUgZW5jcnlwdGlv biB0cmFuc2Zvcm0gaXMgbW9kaWZpZWQuICBGb3IgZXhhbXBsZSwgaWYgdGhlIE1BTkUgY2hhbmdl cyB0aGUgUFQsIFNlcXVlbmNlIE5vLCBTU1JDIG9yIENTUkMgZmllbGRzIGFuZCB0aGUgZjggdHJh bnNmb3JtIChkZWZpbmVkIGluIFJGQyAzNzExKSBpcyBiZWluZyB1c2VkLCB0aGVuIHRoZSBwYWNr ZXQgd2lsbCBuZWVkIHRvIGJlIGRlY3J5cHRlZCBhbmQgZW5jcnlwdGVkLCBldmVuIGlmIGFsbCB0 aGUgaW5mb3JtYXRpb24gbmVlZGVkIHRvIGRlY2lkZSB0byBmb3J3YXJkIHRoZSBwYWNrZXQgd2Fz IHBsYWNlZCBvdXRzaWRlIHRoZSBwYXlsb2FkIChlLmcuIGluIGFuIFJUUCBleHRlbnNpb24pLiAg IEZvciBvdGhlciB0cmFuc2Zvcm1zLCBmZXdlciBmaWVsZHMgbWF5IHRyaWdnZXIgZGVjcnlwdC9l bmNyeXB0LCBidXQgYXZvaWRpbmcgaXQgZW50aXJlbHkgc2VlbXMgb25seSBwb3NzaWJsZSBmb3Ig 4oCcc291cmNlIHByb2plY3RpbmciIFNGVXMvTUFORXMgKHdoaWNoIGxldCB0aGUgU1NSQyBwYXNz IHRocm91Z2ggc2ltaWxhciB0byBhbiBSVFAgdHJhbnNsYXRvciksIHdoaWNoIHRvIG15IGtub3ds ZWRnZSBoYXZlIG5ldmVyIGJlZW4gaW1wbGVtZW50ZWQuIA0KDQoNCkFsc28sIGEgTUFORSBtdXN0 IGhhdmUgYWNjZXNzIHRvIFNSVENQIG1hc3RlciBrZXlzLCBzbyBpZiBSVENQL1JUUCBtdWx0aXBs ZXhpbmcgaXMgdXNlZCwgdGhlbiBhY2Nlc3MgdG8gU1JUUCBtYXN0ZXIga2V5cyBpcyBhIGdpdmVu LiANCg0KDQoNCg0KDQoNCkZyb206IHN0ZXdlQHN0ZXdlLm9yZw0KU2VudDog4oCOVHVlc2RheeKA jiwg4oCORGVjZW1iZXLigI4g4oCOMTDigI4sIOKAjjIwMTMg4oCON+KAjjrigI4wNeKAjiDigI5Q TQ0KVG86IHBheWxvYWQgaXNzdWUgdHJhY2tlciwgZHJhZnQtaWV0Zi1wYXlsb2FkLXJ0cC1oMjY1 QHRvb2xzLmlldGYub3JnLCBCZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tDQpDYzogcGF5bG9hZEBp ZXRmLm9yZywgV2FuZywgWWUtS3VpDQoNCg0KDQoNCg0KSGkgQmVybmFyZCwNCg0KQSBnbG9iYWwg c3Vic3RpdHV0ZSBtYXkgYmUgdGhlIHdyb25nIHRoaW5nIHRvIGRvLg0KDQpJbiBtYW55IGluc3Rh bmNlcywgYW4gU0ZVIGNhbiBkbyB3aGF0IGlzIGF0dHJpYnV0ZWQgaW50byBhIE1BTkXCuXMNCm9w ZXJhdGlvbi4gIEhvd2V2ZXIsIGluIHNlY3Rpb24gNC44IChsYXN0IHBhcmFncmFwaCkgYW5kIHNl Y3Rpb24gOQ0KKHNlY3VyaXR5KSBmaW5hbCBwYXJhZ3JhcGgsIE1BTkVzIHBlcmZvcm0gb3BlcmF0 aW9ucyB0aGF0IGFyZSBvdXRzaWRlIHRoZQ0Kc2NvcGUgb2YgYW4gU0ZVIChhdCBsZWFzdCBhcyBJ IHVuZGVyc3RhbmQgdGhlIFNGVSkuDQoNClNvIGhlcmUgaXMgd2hhdCBJIHN1Z2dlc3Q6DQoxLiBB ZGQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRvcG9sb2dpZXMtdXBkYXRlDQoyLiBBZGQgZGVm aW5pdGlvbiBvZiBTZWxlY3RpdmUgRm9yd2FyZGluZyBVbml0IChTRlUpLCByZWZlciB0bw0KdG9w b2xvZ2llcy11cGRhdGUuDQozLiBLZWVwIGRlZmluaXRpb24gb2YgTUFORS4gIEFkZCBub3RlIGlu ZGljYXRpbmcgdGhhdCBhbiBTRlUgaXMgb25lIGZvcm0NCm9mIGEgTUFORS4NCjQuIFJlcGxhY2Ug TUFORSB3aXRoIFNGVSBpbiBhbGwgaW5zdGFuY2VzIGV4Y2VwdCBzZWN0aW9uIDQuOCBsYXN0DQpw YXJhZ3JhcGggYW5kIHNlY3Rpb24gOSBsYXN0IHBhcmFncmFwaA0KDQpEb2VzIHRoYXQgd29yaz8N Cg0KU3RlcGhhbg0KDQoNCk9uIDEyLjkuMjAxMywgMTg6MzggLCAicGF5bG9hZCBpc3N1ZSB0cmFj a2VyIg0KPHRyYWMrcGF5bG9hZEB0cmFjLnRvb2xzLmlldGYub3JnPiB3cm90ZToNCg0KPiM1OiBT ZWN0aW9uIDMuMS4yOiAgICJNQU5FIiBkZWZpbml0aW9uDQo+DQo+IG1lZGlhIGF3YXJlIG5ldHdv cmsgZWxlbWVudCAoTUFORSk6IEEgbmV0d29yayBlbGVtZW50LCBzdWNoIGFzIGENCj4gICAgbWlk ZGxlYm94IG9yIGFwcGxpY2F0aW9uIGxheWVyIGdhdGV3YXkgdGhhdCBpcyBjYXBhYmxlIG9mIHBh cnNpbmcNCj4gICAgY2VydGFpbiBhc3BlY3RzIG9mIHRoZSBSVFAgcGF5bG9hZCBoZWFkZXJzIG9y IHRoZSBSVFAgcGF5bG9hZCBhbmQNCj4gICAgcmVhY3RpbmcgdG8gdGhlaXIgY29udGVudHMuDQo+ DQo+ICAgICAgIEluZm9ybWF0aXZlIG5vdGU6IFRoZSBjb25jZXB0IG9mIGEgTUFORSBnb2VzIGJl eW9uZCBub3JtYWwNCj4gICAgICAgcm91dGVycyBvciBnYXRld2F5cyBpbiB0aGF0IGEgTUFORSBo YXMgdG8gYmUgYXdhcmUgb2YgdGhlDQo+ICAgICAgIHNpZ25hbGluZyAoZS5nLiwgdG8gbGVhcm4g YWJvdXQgdGhlIHBheWxvYWQgdHlwZSBtYXBwaW5ncyBvZiB0aGUNCj4gICAgICAgbWVkaWEgc3Ry ZWFtcyksIGFuZCBpbiB0aGF0IGl0IGhhcyB0byBiZSB0cnVzdGVkIHdoZW4gd29ya2luZw0KPiAg ICAgICB3aXRoIFNSVFAuICBUaGUgYWR2YW50YWdlIG9mIHVzaW5nIE1BTkVzIGlzIHRoYXQgdGhl eSBhbGxvdw0KPiAgICAgICBwYWNrZXRzIHRvIGJlIGRyb3BwZWQgYWNjb3JkaW5nIHRvIHRoZSBu ZWVkcyBvZiB0aGUgbWVkaWEgY29kaW5nLg0KPiAgICAgICBGb3IgZXhhbXBsZSwgaWYgYSBNQU5F IGhhcyB0byBkcm9wIHBhY2tldHMgZHVlIHRvIGNvbmdlc3Rpb24gb24gYQ0KPiAgICAgICBjZXJ0 YWluIGxpbmssIGl0IGNhbiBpZGVudGlmeSBhbmQgcmVtb3ZlIHRob3NlIHBhY2tldHMgd2hvc2UN Cj4gICAgICAgZWxpbWluYXRpb24gIHByb2R1Y2VzICB0aGUgIGxlYXN0ICBhZHZlcnNlICBlZmZl Y3QgIG9uICB0aGUgIHVzZXINCj4gICAgICAgZXhwZXJpZW5jZS4gIEFmdGVyIGRyb3BwaW5nIHBh Y2tldHMsIE1BTkVzIG11c3QgcmV3cml0ZSBSVENQDQo+ICAgICAgIHBhY2tldHMgIHRvICBtYXRj aCAgdGhlICBjaGFuZ2VzICB0byAgdGhlICBSVFAgIHBhY2tldCAgc3RyZWFtICBhcw0KPiAgICAg ICBzcGVjaWZpZWQgaW4gU2VjdGlvbiA3IG9mIFtSRkMzNTUwXS4NCj4NCj4gW0JBXSBJbiBkcmFm dC1pZXRmLWF2dGNvcmUtcnRwLXRvcG9sb2dpZXMtdXBkYXRlIHRoZSB0ZXJtICJTZWxlY3RpdmUN Cj4gRm9yd2FyZGluZyBVbml0IiBpcyBiZWluZyB1c2VkLiAgU2hvdWxkIFNGVSBiZSBzdWJzdGl0 dXRlZCBmb3IgTUFORSBoZXJlPw0KPiBJJ2QgcHJlZmVyIHRoYXQsIGJlY2F1c2UgdGhlIE1BTkUg ZGVmaW5pdGlvbiBpcyBzaG93aW5nIGl0cyBhZ2U6DQo+DQo+IGEuIFRvZGF5J3MgU0ZVcyBwYXJz ZSBwYXlsb2FkIGhlYWRlcnMsIGJ1dCBpZiBhbiBSVFAgZXh0ZW5zaW9uIHdlcmUgdG8NCj4gZXhw b3NlIHNjYWxhYmlsaXR5IGluZm8gKGUuZy4gTGF5ZXJJZCwgVElEKSB0aGF0IG1pZ2h0IG5vdCBi ZSBuZWNlc3NhcnkuDQo+DQo+IGIuIFdoaWxlIFNGVXMgZG8gbmVlZCBpbmZvIHRyYW5zcG9ydGVk IGluIHNpZ25hbGluZyBwcm90b2NvbHMgKGUuZy4NCj4gdHJhbnNwb3J0IGFuZCBkZW11bHRpcGxl eGluZyBpbmZvKSwgdGhpcyBkb2Vzbid0IG1lYW4gdGhleSBuZWVkIGNvbnRhaW4gYQ0KPiBzaWdu YWxpbmcgcGFyc2VyLg0KPg0KPiBjLiBUaGUgcmVxdWlyZW1lbnQgZm9yIGFjY2VzcyB0byBTUlRQ IGVuY3J5cHRpb24gc2Vzc2lvbiBrZXlzIGlzIG5vdCBhbg0KPiBhcmNoaXRlY3R1cmFsIHJlcXVp cmVtZW50IGJ1dCByYXRoZXIgaXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgZGVzaWduIG9mDQo+IGVu Y3J5cHRpb24gdHJhbnNwb3J0cyAod2hpY2ggYWx3YXlzIGRlcGVuZCBvbiBTU1JDLCBhbmQgc29t ZXRpbWVzIGFsc28NCj4gb3RoZXIgZmllbGRzIChlLmcuIGY4IGRlZmluZWQgaW4gUkZDIDM3MTEg ZGVwZW5kcyBvbiBQVCwgU2VxdWVuY2UgTm8sDQo+ZXRjLg0KPiBpbiBhZGRpdGlvbiksICBTRlUg ZGVzaWduIGNob2ljZXMgKGUuZy4gbmVlZCB0byByZXdyaXRlIFBUcywgc3VwcG9ydCBmb3INCj4g UlRQL1JUQ1AgbXVsdGlwbGV4aW5nICh3aGljaCBpbXBsaWVzIGFjY2VzcyB0byBTUlRQIG1hc3Rl ciBrZXlzKSwgc3VwcG9ydA0KPiBmb3IgU1NUIHZzLiBNU1QgKHdoaWNoIGNvdWxkIGF2b2lkIFNl cXVlbmNlIE51bWJlciByZXdyaXRlcyksIGFsbG9jYXRpb24NCj4gb2YgU1NSQ3MgdnMuICJzb3Vy Y2UgcHJvamVjdGlvbiIgKHdoaWNoIHdvdWxkIGF2b2lkIFNTUkMgcmV3cml0aW5nLA0KPmV0Yy4p Lg0KPg0KPi0tIA0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+LQ0KPiBSZXBvcnRlcjogICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAgICAgT3duZXI6ICBkcmFmdC1pZXRmLXBheWxvYWQtDQo+ICBi ZXJuYXJkX2Fib2JhQGhvdG1haWwuY29tICAgICAgICAgIHwgIHJ0cC1oMjY1QHRvb2xzLmlldGYu b3JnDQo+ICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgIHwgICAgIFN0YXR1czog IG5ldw0KPiBQcmlvcml0eTogIG1ham9yICAgICAgICAgICAgICAgICAgICB8ICBNaWxlc3RvbmU6 ICBtaWxlc3RvbmUxDQo+Q29tcG9uZW50OiAgcnRwLWgyNjUgICAgICAgICAgICAgICAgIHwgICAg VmVyc2lvbjogIDEuMA0KPiBTZXZlcml0eTogIEFjdGl2ZSBXRyBEb2N1bWVudCAgICAgICB8ICAg S2V5d29yZHM6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4tDQo+DQo+VGlja2V0IFVSTDogPGh0dHA6 Ly90b29scy5pZXRmLm9yZy93Zy9wYXlsb2FkL3RyYWMvdGlja2V0LzU+DQo+cGF5bG9hZCA8aHR0 cDovL3Rvb2xzLmlldGYub3JnL3BheWxvYWQvPg0KPg== --_4C2B032A-6140-43EC-8CE9-8A9B12BD47DC_ Content-Transfer-Encoding: base64 Content-Type: text/html; charset="utf-8" CjxodG1sPgo8aGVhZD4KPG1ldGEgbmFtZT0iZ2VuZXJhdG9yIiBjb250ZW50PSJXaW5kb3dzIE1h aWwgMTcuNS45NjAwLjIwMzE1Ij4KPHN0eWxlPjwhLS0KLkVtYWlsUXVvdGUgewptYXJnaW4tbGVm dDoxcHQ7CnBhZGRpbmctbGVmdDo0cHQ7CmJvcmRlci1sZWZ0OiM4MDAwMDAgMnB4IHNvbGlkOwp9 Ci0tPjwvc3R5bGU+PHN0eWxlIGRhdGEtZXh0ZXJuYWxzdHlsZT0idHJ1ZSI+PCEtLQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoIHsK bWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJn aW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbCB7Cm1hcmdpbjowaW47Cm1hcmdpbi1ib3R0b206LjAwMDFw dDsKfQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNw Rmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCAKcC5Nc29MaXN0UGFyYWdyYXBo Q3hTcE1pZGRsZSwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGRpdi5Nc29MaXN0UGFy YWdyYXBoQ3hTcE1pZGRsZSwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0 UGFyYWdyYXBoQ3hTcExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4t dG9wOjBpbjsKbWFyZ2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0 Oi41aW47Cm1hcmdpbi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQotLT48L3N0 eWxlPjwvaGVhZD4KPGJvZHkgZGlyPSJsdHIiPgo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFs c2UiIGRpcj0ibHRyIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDYWxpYnJpJywgJ1NlZ29lIFVJJywg J01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5nSGVpIFVJJywg J01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZic7Zm9udC1zaXplOjEycHQ7Ij48ZGl2PkkgYW0g b2sgd2l0aCB1c2luZyZuYnNwO+KAnE1BTkXigJ0gZm9yIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBT ZWN0aW9uIDQuOCwgc2luY2UgcHJlc3VtYWJseSBhbiBTRlUgd2lsbCBub3QgZG8gTkFMIHJlLXBh Y2tldGl6YXRpb24uIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGxhc3QgcGFyYWdyYXBo IGluIFNlY3Rpb24gOSBjYW4gYWxzbyB1c2UgdGhlIHRlcm0gTUFORSBidXQgaXQgbmVlZHMgYSBi aXQgb2Ygd29yZHNtaXRoaW5nLCBwZXJoYXBzLiZuYnNwOyZuYnNwOyBXaGVuIGRlYWxpbmcgd2l0 aCBTU1QsIGV2ZW4gZGlzY2FyZGluZyBwYWNrZXRzIHJlcXVpcmVzIHRoZSBTUlRQIGF1dGhlbnRp Y2F0aW9uIHNlc3Npb24ga2V5LCBiZWNhdXNlIHRoZSBzZXF1ZW5jZSBuby4gbmVlZHMgdG8gYmUg cmV3cml0dGVuICh0aGlzIGlzIG5vdCB0cnVlIGZvciBNdWx0aS1TU1JDIHRyYW5zcG9ydCkuJm5i c3A7IFRoZSBuZWVkIGZvciB0aGUgU1JUUCBlbmNyeXB0aW9uIHNlc3Npb24ga2V5IGV4aXN0cyZu YnNwO2lmIGEgZmllbGQgdXRpbGl6ZWQgYnkgdGhlIGVuY3J5cHRpb24gdHJhbnNmb3JtIGlzIG1v ZGlmaWVkLiZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgdGhlIE1BTkUgY2hhbmdlcyB0aGUgUFQsIFNl cXVlbmNlIE5vLCBTU1JDIG9yIENTUkMgZmllbGRzIGFuZCB0aGUgZjggdHJhbnNmb3JtIChkZWZp bmVkIGluIFJGQyAzNzExKSBpcyBiZWluZyB1c2VkLCB0aGVuIHRoZSBwYWNrZXQgd2lsbCBuZWVk IHRvIGJlJm5ic3A7ZGVjcnlwdGVkIGFuZCBlbmNyeXB0ZWQsIGV2ZW4gaWYgYWxsIHRoZSBpbmZv cm1hdGlvbiBuZWVkZWQgdG8mbmJzcDtkZWNpZGUgdG8gZm9yd2FyZCB0aGUgcGFja2V0IHdhcyBw bGFjZWQgb3V0c2lkZSB0aGUgcGF5bG9hZCAoZS5nLiBpbiZuYnNwO2FuJm5ic3A7UlRQIGV4dGVu c2lvbikuICZuYnNwOyBGb3Igb3RoZXIgdHJhbnNmb3JtcywgZmV3ZXIgZmllbGRzIG1heSB0cmln Z2VyIGRlY3J5cHQvZW5jcnlwdCwgYnV0IGF2b2lkaW5nIGl0IGVudGlyZWx5IHNlZW1zIG9ubHkg cG9zc2libGUgZm9yJm5ic3A74oCcc291cmNlIHByb2plY3RpbmciIFNGVXMvTUFORXMgKHdoaWNo IGxldCB0aGUgU1NSQyBwYXNzIHRocm91Z2ggc2ltaWxhciB0byBhbiBSVFAgdHJhbnNsYXRvciks IHdoaWNoIHRvIG15IGtub3dsZWRnZSBoYXZlIG5ldmVyIGJlZW4gaW1wbGVtZW50ZWQuIDwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+QWxzbywgYSBNQU5FIG11c3QgaGF2ZSBhY2Nlc3MgdG8gU1JU Q1AgbWFzdGVyIGtleXMsIHNvIGlmIFJUQ1AvUlRQIG11bHRpcGxleGluZyBpcyB1c2VkLCB0aGVu IGFjY2VzcyB0byBTUlRQIG1hc3RlciBrZXlzIGlzIGEgZ2l2ZW4uIDwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7IGJvcmRlci10 b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBib3Jk ZXItdG9wLXN0eWxlOiBzb2xpZDsiPjxkaXY+PGZvbnQgZmFjZT0iICdDYWxpYnJpJywgJ1NlZ29l IFVJJywgJ01laXJ5bycsICdNaWNyb3NvZnQgWWFIZWkgVUknLCAnTWljcm9zb2Z0IEpoZW5nSGVp IFVJJywgJ01hbGd1biBHb3RoaWMnLCAnc2Fucy1zZXJpZiciIHN0eWxlPSdsaW5lLWhlaWdodDog MTVwdDsgbGV0dGVyLXNwYWNpbmc6IDAuMDJlbTsgZm9udC1mYW1pbHk6ICJDYWxpYnJpIiwgIlNl Z29lIFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5n SGVpIFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IGZvbnQtc2l6ZTogMTJwdDsn PjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzdGV3ZUBzdGV3ZS5vcmciIHRhcmdl dD0iX3BhcmVudCI+c3Rld2VAc3Rld2Uub3JnPC9hPjxicj48Yj5TZW50OjwvYj4mbmJzcDvigI5U dWVzZGF54oCOLCDigI5EZWNlbWJlcuKAjiDigI4xMOKAjiwg4oCOMjAxMyDigI434oCOOuKAjjA1 4oCOIOKAjlBNPGJyPjxiPlRvOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86dHJhYytwYXlsb2Fk QHRyYWMudG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+cGF5bG9hZCBpc3N1ZSB0cmFj a2VyPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaDI2NUB0b29s cy5pZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij5kcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVA dG9vbHMuaWV0Zi5vcmc8L2E+LCA8YSBocmVmPSJtYWlsdG86YmVybmFyZF9hYm9iYUBob3RtYWls LmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5CZXJuYXJkX0Fib2JhQGhvdG1haWwuY29tPC9hPjxicj48 Yj5DYzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnBheWxvYWRAaWV0Zi5vcmciIHRhcmdldD0i X3BhcmVudCI+cGF5bG9hZEBpZXRmLm9yZzwvYT4sIDxhIGhyZWY9Im1haWx0bzp5ZWt1aXdAcXRp LnF1YWxjb21tLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5XYW5nLCBZZS1LdWk8L2E+PC9mb250Pjwv ZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgZGlyPSIiPgo8ZGl2IGNsYXNzPSJQbGFpblRl eHQiPkhpIEJlcm5hcmQsPGJyPgo8YnI+CkEgZ2xvYmFsIHN1YnN0aXR1dGUgbWF5IGJlIHRoZSB3 cm9uZyB0aGluZyB0byBkby48YnI+Cjxicj4KSW4gbWFueSBpbnN0YW5jZXMsIGFuIFNGVSBjYW4g ZG8gd2hhdCBpcyBhdHRyaWJ1dGVkIGludG8gYSBNQU5FwrlzPGJyPgpvcGVyYXRpb24uJm5ic3A7 IEhvd2V2ZXIsIGluIHNlY3Rpb24gNC44IChsYXN0IHBhcmFncmFwaCkgYW5kIHNlY3Rpb24gOTxi cj4KKHNlY3VyaXR5KSBmaW5hbCBwYXJhZ3JhcGgsIE1BTkVzIHBlcmZvcm0gb3BlcmF0aW9ucyB0 aGF0IGFyZSBvdXRzaWRlIHRoZTxicj4Kc2NvcGUgb2YgYW4gU0ZVIChhdCBsZWFzdCBhcyBJIHVu ZGVyc3RhbmQgdGhlIFNGVSkuPGJyPgo8YnI+ClNvIGhlcmUgaXMgd2hhdCBJIHN1Z2dlc3Q6PGJy PgoxLiBBZGQgaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIHRvcG9sb2dpZXMtdXBkYXRlPGJyPgoy LiBBZGQgZGVmaW5pdGlvbiBvZiBTZWxlY3RpdmUgRm9yd2FyZGluZyBVbml0IChTRlUpLCByZWZl ciB0bzxicj4KdG9wb2xvZ2llcy11cGRhdGUuPGJyPgozLiBLZWVwIGRlZmluaXRpb24gb2YgTUFO RS4mbmJzcDsgQWRkIG5vdGUgaW5kaWNhdGluZyB0aGF0IGFuIFNGVSBpcyBvbmUgZm9ybTxicj4K b2YgYSBNQU5FLjxicj4KNC4gUmVwbGFjZSBNQU5FIHdpdGggU0ZVIGluIGFsbCBpbnN0YW5jZXMg ZXhjZXB0IHNlY3Rpb24gNC44IGxhc3Q8YnI+CnBhcmFncmFwaCBhbmQgc2VjdGlvbiA5IGxhc3Qg cGFyYWdyYXBoPGJyPgo8YnI+CkRvZXMgdGhhdCB3b3JrPzxicj4KPGJyPgpTdGVwaGFuPGJyPgo8 YnI+Cjxicj4KT24gMTIuOS4yMDEzLCAxODozOCAsICJwYXlsb2FkIGlzc3VlIHRyYWNrZXIiPGJy PgombHQ7dHJhYytwYXlsb2FkQHRyYWMudG9vbHMuaWV0Zi5vcmcmZ3Q7IHdyb3RlOjxicj4KPGJy PgomZ3Q7IzU6IFNlY3Rpb24gMy4xLjI6Jm5ic3A7Jm5ic3A7ICJNQU5FIiBkZWZpbml0aW9uPGJy PgomZ3Q7PGJyPgomZ3Q7IG1lZGlhIGF3YXJlIG5ldHdvcmsgZWxlbWVudCAoTUFORSk6IEEgbmV0 d29yayBlbGVtZW50LCBzdWNoIGFzIGE8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWlkZGxl Ym94IG9yIGFwcGxpY2F0aW9uIGxheWVyIGdhdGV3YXkgdGhhdCBpcyBjYXBhYmxlIG9mIHBhcnNp bmc8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2VydGFpbiBhc3BlY3RzIG9mIHRoZSBSVFAg cGF5bG9hZCBoZWFkZXJzIG9yIHRoZSBSVFAgcGF5bG9hZCBhbmQ8YnI+CiZndDsmbmJzcDsmbmJz cDsmbmJzcDsgcmVhY3RpbmcgdG8gdGhlaXIgY29udGVudHMuPGJyPgomZ3Q7PGJyPgomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluZm9ybWF0aXZlIG5vdGU6IFRoZSBj b25jZXB0IG9mIGEgTUFORSBnb2VzIGJleW9uZCBub3JtYWw8YnI+CiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcm91dGVycyBvciBnYXRld2F5cyBpbiB0aGF0IGEgTUFO RSBoYXMgdG8gYmUgYXdhcmUgb2YgdGhlPGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNpZ25hbGluZyAoZS5nLiwgdG8gbGVhcm4gYWJvdXQgdGhlIHBheWxvYWQg dHlwZSBtYXBwaW5ncyBvZiB0aGU8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbWVkaWEgc3RyZWFtcyksIGFuZCBpbiB0aGF0IGl0IGhhcyB0byBiZSB0cnVzdGVk IHdoZW4gd29ya2luZzxicj4KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3aXRoIFNSVFAuJm5ic3A7IFRoZSBhZHZhbnRhZ2Ugb2YgdXNpbmcgTUFORXMgaXMgdGhhdCB0 aGV5IGFsbG93PGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBh Y2tldHMgdG8gYmUgZHJvcHBlZCBhY2NvcmRpbmcgdG8gdGhlIG5lZWRzIG9mIHRoZSBtZWRpYSBj b2RpbmcuPGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBl eGFtcGxlLCBpZiBhIE1BTkUgaGFzIHRvIGRyb3AgcGFja2V0cyBkdWUgdG8gY29uZ2VzdGlvbiBv biBhPGJyPgomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNlcnRhaW4g bGluaywgaXQgY2FuIGlkZW50aWZ5IGFuZCByZW1vdmUgdGhvc2UgcGFja2V0cyB3aG9zZTxicj4K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbGltaW5hdGlvbiZuYnNw OyBwcm9kdWNlcyZuYnNwOyB0aGUmbmJzcDsgbGVhc3QmbmJzcDsgYWR2ZXJzZSZuYnNwOyBlZmZl Y3QmbmJzcDsgb24mbmJzcDsgdGhlJm5ic3A7IHVzZXI8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhwZXJpZW5jZS4mbmJzcDsgQWZ0ZXIgZHJvcHBpbmcgcGFj a2V0cywgTUFORXMgbXVzdCByZXdyaXRlIFJUQ1A8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgcGFja2V0cyZuYnNwOyB0byZuYnNwOyBtYXRjaCZuYnNwOyB0aGUm bmJzcDsgY2hhbmdlcyZuYnNwOyB0byZuYnNwOyB0aGUmbmJzcDsgUlRQJm5ic3A7IHBhY2tldCZu YnNwOyBzdHJlYW0mbmJzcDsgYXM8YnI+CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgc3BlY2lmaWVkIGluIFNlY3Rpb24gNyBvZiBbUkZDMzU1MF0uPGJyPgomZ3Q7PGJy PgomZ3Q7IFtCQV0gSW4gZHJhZnQtaWV0Zi1hdnRjb3JlLXJ0cC10b3BvbG9naWVzLXVwZGF0ZSB0 aGUgdGVybSAiU2VsZWN0aXZlPGJyPgomZ3Q7IEZvcndhcmRpbmcgVW5pdCIgaXMgYmVpbmcgdXNl ZC4mbmJzcDsgU2hvdWxkIFNGVSBiZSBzdWJzdGl0dXRlZCBmb3IgTUFORSBoZXJlPzxicj4KJmd0 OyBJJ2QgcHJlZmVyIHRoYXQsIGJlY2F1c2UgdGhlIE1BTkUgZGVmaW5pdGlvbiBpcyBzaG93aW5n IGl0cyBhZ2U6PGJyPgomZ3Q7PGJyPgomZ3Q7IGEuIFRvZGF5J3MgU0ZVcyBwYXJzZSBwYXlsb2Fk IGhlYWRlcnMsIGJ1dCBpZiBhbiBSVFAgZXh0ZW5zaW9uIHdlcmUgdG88YnI+CiZndDsgZXhwb3Nl IHNjYWxhYmlsaXR5IGluZm8gKGUuZy4gTGF5ZXJJZCwgVElEKSB0aGF0IG1pZ2h0IG5vdCBiZSBu ZWNlc3NhcnkuPGJyPgomZ3Q7PGJyPgomZ3Q7IGIuIFdoaWxlIFNGVXMgZG8gbmVlZCBpbmZvIHRy YW5zcG9ydGVkIGluIHNpZ25hbGluZyBwcm90b2NvbHMgKGUuZy48YnI+CiZndDsgdHJhbnNwb3J0 IGFuZCBkZW11bHRpcGxleGluZyBpbmZvKSwgdGhpcyBkb2Vzbid0IG1lYW4gdGhleSBuZWVkIGNv bnRhaW4gYTxicj4KJmd0OyBzaWduYWxpbmcgcGFyc2VyLjxicj4KJmd0Ozxicj4KJmd0OyBjLiBU aGUgcmVxdWlyZW1lbnQgZm9yIGFjY2VzcyB0byBTUlRQIGVuY3J5cHRpb24gc2Vzc2lvbiBrZXlz IGlzIG5vdCBhbjxicj4KJmd0OyBhcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50IGJ1dCByYXRoZXIg aXMgYSBjb25zZXF1ZW5jZSBvZiB0aGUgZGVzaWduIG9mPGJyPgomZ3Q7IGVuY3J5cHRpb24gdHJh bnNwb3J0cyAod2hpY2ggYWx3YXlzIGRlcGVuZCBvbiBTU1JDLCBhbmQgc29tZXRpbWVzIGFsc288 YnI+CiZndDsgb3RoZXIgZmllbGRzIChlLmcuIGY4IGRlZmluZWQgaW4gUkZDIDM3MTEgZGVwZW5k cyBvbiBQVCwgU2VxdWVuY2UgTm8sPGJyPgomZ3Q7ZXRjLjxicj4KJmd0OyBpbiBhZGRpdGlvbiks Jm5ic3A7IFNGVSBkZXNpZ24gY2hvaWNlcyAoZS5nLiBuZWVkIHRvIHJld3JpdGUgUFRzLCBzdXBw b3J0IGZvcjxicj4KJmd0OyBSVFAvUlRDUCBtdWx0aXBsZXhpbmcgKHdoaWNoIGltcGxpZXMgYWNj ZXNzIHRvIFNSVFAgbWFzdGVyIGtleXMpLCBzdXBwb3J0PGJyPgomZ3Q7IGZvciBTU1QgdnMuIE1T VCAod2hpY2ggY291bGQgYXZvaWQgU2VxdWVuY2UgTnVtYmVyIHJld3JpdGVzKSwgYWxsb2NhdGlv bjxicj4KJmd0OyBvZiBTU1JDcyB2cy4gInNvdXJjZSBwcm9qZWN0aW9uIiAod2hpY2ggd291bGQg YXZvaWQgU1NSQyByZXdyaXRpbmcsPGJyPgomZ3Q7ZXRjLikuPGJyPgomZ3Q7PGJyPgomZ3Q7LS0g PGJyPgomZ3Q7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+CiZndDstPGJyPgomZ3Q7IFJlcG9ydGVyOiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE93bmVyOiZuYnNwOyBkcmFmdC1pZXRmLXBheWxvYWQtPGJyPgomZ3Q7 Jm5ic3A7IGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBydHAtaDI2NUB0b29scy5pZXRm Lm9yZzxicj4KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlOiZuYnNwOyBkZWZlY3Qm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTdGF0dXM6Jm5ic3A7IG5ldzxicj4KJmd0OyBQcmlvcml0eTom bmJzcDsgbWFqb3ImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyBNaWxlc3RvbmU6Jm5ic3A7IG1pbGVzdG9uZTE8YnI+CiZndDtD b21wb25lbnQ6Jm5ic3A7IHJ0cC1oMjY1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsgVmVyc2lvbjombmJzcDsgMS4wPGJyPgomZ3Q7IFNl dmVyaXR5OiZuYnNwOyBBY3RpdmUgV0cgRG9jdW1lbnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBLZXl3b3Jkczo8YnI+CiZndDstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4KJmd0Oy08YnI+CiZndDs8YnI+CiZndDtUaWNrZXQgVVJMOiAmbHQ7PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL3BheWxvYWQvdHJhYy90aWNrZXQvNSIgdGFyZ2V0PSJf cGFyZW50Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvcGF5bG9hZC90cmFjL3RpY2tldC81PC9h PiZndDs8YnI+CiZndDtwYXlsb2FkICZsdDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv cGF5bG9hZC8iIHRhcmdldD0iX3BhcmVudCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3BheWxvYWQv PC9hPiZndDs8YnI+CiZndDs8YnI+Cjxicj4KPC9kaXY+CgoKPC9kaXY+PC9kaXY+CjwvYm9keT4K PC9odG1sPgo= --_4C2B032A-6140-43EC-8CE9-8A9B12BD47DC_-- From abegen@cisco.com Wed Dec 11 02:32:04 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E01AD83F for ; Wed, 11 Dec 2013 02:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfLtQBw4G-S3 for ; Wed, 11 Dec 2013 02:32:03 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBEF1ACCDC for ; Wed, 11 Dec 2013 02:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1749; q=dns/txt; s=iport; t=1386757918; x=1387967518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HKSsbw3UXtoldLzP3/WiU6mm+sQgbrVw6TrcOmIjKRE=; b=F/Fe6GJMKgDMzwgjRZ/B6u+DYA4aJNoaXx/Y3WQ89Jmm6ASUwuBYABNJ sAzJCdyOAZ6E7uNKovBxoM7nPhISLsKUGVhjNP+fano5GEEplS0Tuf1jH nQCjLSdoyND5QGcHLzuCH7eVNjYiBRG/X78tycvGbif6jQPwEBV9oZL7u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAD4+qFKtJXG9/2dsb2JhbABZgmYhOFOmL5ImToEgFnSCJQEBAQMBAQEBawsFCwIBCA4KLicLJQIEDgWHcAMJBgEMwTwXjHOBTRIzB4MhgRMEiQqNIIFqgTCLKgOFNoMpgio X-IronPort-AV: E=Sophos;i="4.93,870,1378857600"; d="scan'208";a="290894614" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 11 Dec 2013 10:31:57 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBBAVviV015478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 10:31:57 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 04:31:57 -0600 From: "Ali C. Begen (abegen)" To: Stephan Wenger Thread-Topic: [payload] #2: Section 8.2: Updates RFC 4585? Thread-Index: AQHO9WS1TXVTajmSMk2XxSrvEADsuppOXWmAgADUz4A= Date: Wed, 11 Dec 2013 10:31:57 +0000 Message-ID: References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org> <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , "bernard_aboba@hotmail.com" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:32:05 -0000 I agree with Stephan here. As long as these are h265 related, I dont think = we need to "update" 4585. On Dec 10, 2013, at 1:50 PM, Stephan Wenger wrote: > Hi Bernard, >=20 > I don=B9t think it would be a particularly good idea if every payload for= mat > spec is marked as =B3updating=B2 a general purpose spec when *for that pa= yload > only* the payload spec allows/disallows/modifies aspects of the general > purpose spec. =20 >=20 > Hi Chairs: any guidance? >=20 > Thanks, > Stephan >=20 >=20 > On 12.9.2013, 19:50 , "payload issue tracker" > wrote: >=20 >> #2: Section 8.2: Updates RFC 4585? >>=20 >>=20 >> Comment (by bernard_aboba@hotmail.com): >>=20 >> Another reason for Updates: RFC 4585 is that Section 8.1 defines the SPL= I >> Feedback Message. >>=20 >> --=20 >> -------------------------------------+----------------------------------= -- >> - >> Reporter: | Owner: draft-ietf-payload- >> bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org >> Type: defect | Status: new >> Priority: minor | Milestone: milestone1 >> Component: rtp-h265 | Version: 1.0 >> Severity: Active WG Document | Resolution: >> Keywords: | >> -------------------------------------+----------------------------------= -- >> - >>=20 >> Ticket URL: >> payload >>=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Wed Dec 11 03:35:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AFA1A1F7C for ; Wed, 11 Dec 2013 03:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdzVfJ5Pzphs for ; Wed, 11 Dec 2013 03:35:23 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 418AA1ABBB1 for ; Wed, 11 Dec 2013 03:35:23 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id o10so2858429eaj.4 for ; Wed, 11 Dec 2013 03:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=umCag9PnPWs6RJKd+R/t/eUk+106pqt4JjFYuw/unx8=; b=xI2Sm2fgDMkEEJ5/gnDFZEWztkfxULhL7jWiB4dmdLAxSWtiFoaiMGCLnCaFyFttHm RVNObFkV3u+F0ry0pujWIkzD5vbpFCAAuUWygMzWyc881mcBGd4AXPcmBAt/S0WmYVSO CqAUZYuInKL22Q2J7dJTDCvZduSnpKW61aq09gjhyVmBWkDY3Ctj1PT37AInB+R7XleV H3eRLMoyp3WVjgWmz7xqoi5NXuCBvrdgIUJT0h2VfIy/sxz9aTCW9Y0IJrmQ3Jt6d0vd BzbmaVLl38QXWcATM4QcuKqEBamw4+VYs/fJFDGU83wfaFKPf7Mu4xnTfyubOatTot7J pXDQ== X-Received: by 10.14.221.193 with SMTP id r41mr1319932eep.92.1386761717223; Wed, 11 Dec 2013 03:35:17 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id g47sm52573813eeo.19.2013.12.11.03.35.14 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 11 Dec 2013 03:35:16 -0800 (PST) From: "Roni Even" To: "'Wang, Ye-Kui'" , "'Bernard Aboba'" , "'Stephan Wenger'" , "'payload issue tracker'" , References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org>, <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org>, <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> Date: Wed, 11 Dec 2013 13:31:43 +0200 Message-ID: <004e01cef664$93a32c30$bae98490$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CEF675.572DD0F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIAtyV1bXh07XA0flWnOKOWrQdGfgIvmHYxARZbYowBmTdBrgGxEe1xAqIAoJuZocZeYA== Content-Language: en-us Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:35:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CEF675.572DD0F0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, My first comment is that the value 8 that you want for the SPLI message = is already assigned http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-p= ara meters-9 So ask an allocation from IANA. =20 As for Bernard comment. My view is that you should clarify the text in 8.2 to clarify that you = are not changing RFC 4585 (deprecate is not the right term) but only make a change for HEVC. As for the new message SPLI in section 8.1, if it is for all codec like = the section states it will be good to specify it very clearly that this is = the only update to RFC4585. Still I suggest that it will be clearer in a separate document that will be an update to RFC4585. =20 =20 Roni Even Payload co-chair =20 =20 From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, = Ye-Kui Sent: 11 December, 2013 2:14 AM To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? =20 Sorry, Bernard, I replied too quickly. =20 In the draft, we define the following in section 8: 1) The SPLI Feedback Message (in 8.1) 2) Use of HEVC with the RPSI Feedback Message (in 8.2) 3) Use of HEVC with the SPLI Feedback Message (in 8.3) =20 Only items 2 and 3 are only for H.265, while the first item defined in section 8.1 also applies to other codecs, and we even have the following note included in the section: =20 Informative note: The SPLI message defined in this memo also applies to other codecs, and may later be moved to another extension of RFC 4585. =20 Thus, your suggestion still needs to be considered. =20 Would it be sufficient to just add =93Updates RFC 4585=94, or it would = actually better to document the SPLI feedback message in a non-codec-specific document? =20 BR, YK =20 From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, = Ye-Kui Sent: Tuesday, December 10, 2013 3:23 PM To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? =20 We had the intention that those related to RFC 4585 in draft-ietf-payload-rtp-h265 are only for H.265. =20 OK, then I think we just need to make this intention clearly said in the draft. Will include this clarification into the next version. =20 BR, YK =20 From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Bernard = Aboba Sent: Tuesday, December 10, 2013 3:00 PM To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? =20 I didn't understand from the text that the modification was only for = H.265. I had assumed that the references to feedback messages (and new message definition) was for all codecs. =20 =20 > From: stewe@stewe.org > To: trac+payload@trac.tools.ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com > CC: payload@ietf.org > Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? > Date: Tue, 10 Dec 2013 21:50:15 +0000 >=20 > Hi Bernard, >=20 > I don=B9t think it would be a particularly good idea if every payload = format > spec is marked as =B3updating=B2 a general purpose spec when *for that = payload > only* the payload spec allows/disallows/modifies aspects of the = general > purpose spec.=20 >=20 > Hi Chairs: any guidance? >=20 > Thanks, > Stephan >=20 >=20 > On 12.9.2013, 19:50 , "payload issue tracker" > wrote: >=20 > >#2: Section 8.2: Updates RFC 4585? > > > > > >Comment (by bernard_aboba@hotmail.com): > > > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SPLI > > Feedback Message. > > > >--=20 > >-------------------------------------+----------------------------------= -- > >- > > Reporter: | Owner: draft-ietf-payload- > > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > >Component: rtp-h265 | Version: 1.0 > > Severity: Active WG Document | Resolution: > > Keywords: | > >-------------------------------------+----------------------------------= -- > >- > > > >Ticket URL: = > >payload > > >=20 ------=_NextPart_000_004F_01CEF675.572DD0F0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

My first comment is that the value 8 that you want for the SPLI = message is already assigned http://www.iana.org/assignments/rtp-parameters/rtp-p= arameters.xhtml#rtp-parameters-9

So ask an allocation from IANA.

 

As for Bernard comment.

My view is that you should clarify the text in 8.2 =A0to clarify that = you are not changing RFC 4585 (deprecate is not the right term) but only = make a change for HEVC.

As for the new message SPLI in section 8.1, if it is for all codec = like the section states it will be good to specify it very clearly that = this is the only update to RFC4585. Still I suggest =A0that it will be = clearer in a separate document that will be an update to RFC4585.=A0 =

 

Roni Even

Payload co-chair

 

 

From:= = payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, = Ye-Kui
Sent: 11 December, 2013 2:14 AM
To: Bernard = Aboba; Stephan Wenger; payload issue tracker; = draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: = payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: = Updates RFC 4585?

 

Sorry, Bernard, I replied too quickly.

 

In the draft, we define the following in section = 8:

1)      = The SPLI Feedback Message (in 8.1)

2)      = Use of HEVC with the RPSI Feedback Message (in = 8.2)

3)      = Use of HEVC with the SPLI Feedback Message (in = 8.3)

 

Only items 2 and 3 are only for H.265, while the first item defined = in section 8.1 also applies to other codecs, and we even have the = following note included in the section:

 

Informative note: The SPLI message defined in = this memo also applies to other codecs, and may later be moved to = another extension of RFC 4585.

 

Thus, your suggestion still needs to be = considered.

 

Would it be sufficient to just add =93Updates RFC 4585=94, or it = would actually better to document the SPLI feedback message in a = non-codec-specific document?

 

BR, YK

 

 

We had the intention that those related to RFC 4585 in = draft-ietf-payload-rtp-h265 are only for H.265.

 

OK, then I think we just need to make this intention clearly said in = the draft. Will include this clarification into the next = version.

 

BR, YK

 

 

I didn't understand from = the text that the modification was only = for H.265.   I had assumed that the references = to feedback messages (and new message definition) was for all = codecs.  
 

> From: stewe@stewe.org
> To: trac+payload@trac.tools.= ietf.org; draft-ietf-pay= load-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com> CC: payload@ietf.org
> Subject: = Re: [payload] #2: Section 8.2: Updates RFC 4585?
> Date: Tue, 10 = Dec 2013 21:50:15 +0000
>
> Hi Bernard,
>
> I = don=B9t think it would be a particularly good idea if every payload = format
> spec is marked as =B3updating=B2 a general purpose spec = when *for that payload
> only* the payload spec = allows/disallows/modifies aspects of the general
> purpose spec. =
>
> Hi Chairs: any guidance?
>
> = Thanks,
> Stephan
>
>
> On 12.9.2013, 19:50 , = "payload issue tracker"
> <trac+payload@trac.tools.= ietf.org> wrote:
>
> >#2: Section 8.2: Updates = RFC 4585?
> >
> >
> >Comment (by bernard_aboba@hotmail.com):=
> >
> > Another reason for Updates: RFC 4585 is that = Section 8.1 defines the SPLI
> > Feedback Message.
> = >
> >--
> = >-------------------------------------+-------------------------------= -----
> >-
> > Reporter: | Owner: = draft-ietf-payload-
> > bernard_aboba@hotmail.com = | rtp-h265@tools.ietf.org
&g= t; > Type: defect | Status: new
> > Priority: minor | = Milestone: milestone1
> >Component: rtp-h265 | Version: = 1.0
> > Severity: Active WG Document | Resolution:
> > = Keywords: |
> = >-------------------------------------+-------------------------------= -----
> >-
> >
> >Ticket URL: <http://= tools.ietf.org/wg/payload/trac/ticket/2#comment:1>
> = >payload <http://tools.ietf.org/payload/>
> >
> =

------=_NextPart_000_004F_01CEF675.572DD0F0-- From trac+payload@trac.tools.ietf.org Wed Dec 11 03:53:26 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10A61ACCF0 for ; Wed, 11 Dec 2013 03:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnAtslYkvErU for ; Wed, 11 Dec 2013 03:53:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 449511ACCDF for ; Wed, 11 Dec 2013 03:53:25 -0800 (PST) Received: from localhost ([127.0.0.1]:46773 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VqiLu-00008N-2I; Wed, 11 Dec 2013 12:53:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-vp8@tools.ietf.org, harald@alvestrand.no X-Trac-Project: payload Date: Wed, 11 Dec 2013 11:53:17 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/payload/trac/ticket/1#comment:1 Message-ID: <082.bc529ce051f5a437a2f2964c46363318@trac.tools.ietf.org> References: <067.bf301a865afb75fe2990319d8b871d8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <067.bf301a865afb75fe2990319d8b871d8b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-vp8@tools.ietf.org, harald@alvestrand.no, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hlundin@google.com, patrik.westin@gmail.com Cc: payload@ietf.org Subject: Re: [payload] #1: Temporal scalability in VP8 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:53:27 -0000 #1: Temporal scalability in VP8 Comment (by harald@alvestrand.no): As far as I understand, the temporal scalability is enabled by the features described in section 4.2, and all receivers of this format are required to handle all combinations of parameters used here. Thus, there is no need for signalling the actual scalability parameters used; it's an unilateral encoder choice. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | vp8@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: vp8 | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: payload From yekuiw@qti.qualcomm.com Wed Dec 11 10:16:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11A1ADBD1 for ; Wed, 11 Dec 2013 10:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWHp1EvC37QV for ; Wed, 11 Dec 2013 10:16:43 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0A01ADF5F for ; Wed, 11 Dec 2013 10:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1386785798; x=1418321798; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h9BFq1dO0+TgsGpvXJqxVKiqMony2Kvv6vsElhDWIFA=; b=fXzkTKg0g0Ku35MuQP45gqTOWDdJ/ABzJeMLvoBtTQUWO2UTk83HaYfn nRzVNEhySu9BrUILBDaQsbLxLvbz3YAIzN3ZSlYhcUimDEQWiuDCL2Z9x Uv2XukUFG+mlGwLQ2360Y1UrGHQkims8fg85Ol+QaFYckA67CbMB8GjVZ I=; X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="92245927" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 11 Dec 2013 10:16:37 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7285"; a="650143282" Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Dec 2013 10:16:37 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.173]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 10:16:37 -0800 From: "Wang, Ye-Kui" To: Roni Even , 'Bernard Aboba' , 'Stephan Wenger' , "'payload issue tracker'" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] #2: Section 8.2: Updates RFC 4585? Thread-Index: AQHO9U13qA4t0ILqhkW1NYZLcXdcyppNUYqAgAEtlYCAABNbAP//f/9wgAAM/rCAAUUsgP//6PyQ Date: Wed, 11 Dec 2013 18:16:34 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83386E652B@nasanexd02f.na.qualcomm.com> References: <067.f96a818e678cd1472f55875787a5583b@trac.tools.ietf.org>, <082.b7d8895fc7388fc8c9bbc677a874dddc@trac.tools.ietf.org>, <8BA7D4CEACFFE04BA2D902BF11719A83386E4FA0@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83386E5120@nasanexd02f.na.qualcomm.com> <004e01cef664$93a32c30$bae98490$@gmail.com> In-Reply-To: <004e01cef664$93a32c30$bae98490$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83386E652Bnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:16:49 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E652Bnasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for your advices. I will check how to get an allocation from IANA. On the SPLI in section 8.1, if we go with a separate document, should we ke= ep that in the PAYLOAD WG (as this part is now a part of an official draft = of the PAYLOAD WG), or make it to a different WG? And in either case, shoul= d it start with an individual draft or a WG draft? If the process is going to be complicated, maybe it would be easier just to= keep it here in this draft, but as Bernard and you suggested, say it clear= ly in the abstract that there is something that updates RFC 4585 here, and = clearly say in the text that there is only one aspect that updates RFC 458= 5. But we will surely follow whatever the WG agrees :) BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, December 11, 2013 3:32 AM To: Wang, Ye-Kui; 'Bernard Aboba'; 'Stephan Wenger'; 'payload issue tracker= '; draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? Hi, My first comment is that the value 8 that you want for the SPLI message is = already assigned http://www.iana.org/assignments/rtp-parameters/rtp-paramet= ers.xhtml#rtp-parameters-9 So ask an allocation from IANA. As for Bernard comment. My view is that you should clarify the text in 8.2 to clarify that you are= not changing RFC 4585 (deprecate is not the right term) but only make a ch= ange for HEVC. As for the new message SPLI in section 8.1, if it is for all codec like the= section states it will be good to specify it very clearly that this is the= only update to RFC4585. Still I suggest that it will be clearer in a sepa= rate document that will be an update to RFC4585. Roni Even Payload co-chair From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: 11 December, 2013 2:14 AM To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payloa= d-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? Sorry, Bernard, I replied too quickly. In the draft, we define the following in section 8: 1) The SPLI Feedback Message (in 8.1) 2) Use of HEVC with the RPSI Feedback Message (in 8.2) 3) Use of HEVC with the SPLI Feedback Message (in 8.3) Only items 2 and 3 are only for H.265, while the first item defined in sect= ion 8.1 also applies to other codecs, and we even have the following note i= ncluded in the section: Informative note: The SPLI message defined in this memo also applies to oth= er codecs, and may later be moved to another extension of RFC 4585. Thus, your suggestion still needs to be considered. Would it be sufficient to just add "Updates RFC 4585", or it would actually= better to document the SPLI feedback message in a non-codec-specific docum= ent? BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Wang, Ye-Kui Sent: Tuesday, December 10, 2013 3:23 PM To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payloa= d-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? We had the intention that those related to RFC 4585 in draft-ietf-payload-r= tp-h265 are only for H.265. OK, then I think we just need to make this intention clearly said in the dr= aft. Will include this clarification into the next version. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Tuesday, December 10, 2013 3:00 PM To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tool= s.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? I didn't understand from the text that the modification was only for H.265.= I had assumed that the references to feedback messages (and new message = definition) was for all codecs. > From: stewe@stewe.org > To: trac+payload@trac.tools.ietf.org; draft-ietf-payload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com > CC: payload@ietf.org > Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585? > Date: Tue, 10 Dec 2013 21:50:15 +0000 > > Hi Bernard, > > I don=B9t think it would be a particularly good idea if every payload for= mat > spec is marked as =B3updating=B2 a general purpose spec when *for that pa= yload > only* the payload spec allows/disallows/modifies aspects of the general > purpose spec. > > Hi Chairs: any guidance? > > Thanks, > Stephan > > > On 12.9.2013, 19:50 , "payload issue tracker" > > wrote: > > >#2: Section 8.2: Updates RFC 4585? > > > > > >Comment (by bernard_aboba@hotmail.com)= : > > > > Another reason for Updates: RFC 4585 is that Section 8.1 defines the SP= LI > > Feedback Message. > > > >-- > >-------------------------------------+----------------------------------= -- > >- > > Reporter: | Owner: draft-ietf-payload- > > bernard_aboba@hotmail.com | rtp-h265@= tools.ietf.org > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > >Component: rtp-h265 | Version: 1.0 > > Severity: Active WG Document | Resolution: > > Keywords: | > >-------------------------------------+----------------------------------= -- > >- > > > >Ticket URL: > >payload > > > --_000_8BA7D4CEACFFE04BA2D902BF11719A83386E652Bnasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 <= /p>

Thanks for your advices. = I will check how to get an allocation from IANA.

 <= /p>

On the SPLI in section 8.= 1, if we go with a separate document, should we keep that in the PAYLOAD WG= (as this part is now a part of an official draft of the PAYLOAD WG), or make it to a different WG? And in either case, should it s= tart with an individual draft or a WG draft?

 <= /p>

If the process is going t= o be complicated, maybe it would be easier just to keep it here in this dra= ft, but as Bernard and you suggested, say it clearly in the abstract that there is something that updates RFC 4585 here, and clear= ly say in the text that there is only one aspect that  updates RFC 458= 5.

 <= /p>

But we will surely follow= whatever the WG agrees J

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, December 11, 2013 3:32 AM
To: Wang, Ye-Kui; 'Bernard Aboba'; 'Stephan Wenger'; 'payload issue = tracker'; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?=

 

Hi,

My first comment is that = the value 8 that you want for the SPLI message is already assigned http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-par= ameters-9

So ask an allocation from= IANA.

 <= /p>

As for Bernard comment.

My view is that you shoul= d clarify the text in 8.2  to clarify that you are not changing RFC 45= 85 (deprecate is not the right term) but only make a change for HEVC.

As for the new message SP= LI in section 8.1, if it is for all codec like the section states it will b= e good to specify it very clearly that this is the only update to RFC4585. Still I suggest  that it will be clearer in a sepa= rate document that will be an update to RFC4585. 

 <= /p>

Roni Even

Payload co-chair

 <= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Wang, Ye-Kui
Sent: 11 December, 2013 2:14 AM
To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?=

 

Sorry, Bernard, I replied= too quickly.

 <= /p>

In the draft, we define t= he following in section 8:

1)      The SPLI Feedback Messag= e (in 8.1)

2)      Use of HEVC with the RPS= I Feedback Message (in 8.2)

3)      Use of HEVC with the SPL= I Feedback Message (in 8.3)

 <= /p>

Only items 2 and 3 are on= ly for H.265, while the first item defined in section 8.1 also applies to o= ther codecs, and we even have the following note included in the section:

 <= /p>

Informative note: The SPL= I message defined in this memo also applies to other codecs, and may later = be moved to another extension of RFC 4585.

 <= /p>

Thus, your suggestion sti= ll needs to be considered.

 <= /p>

Would it be sufficient to= just add “Updates RFC 4585”, or it would actually better to do= cument the SPLI feedback message in a non-codec-specific document?

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Wang, Ye-Kui
Sent: Tuesday, December 10, 2013 3:23 PM
To: Bernard Aboba; Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

 

We had the intention that= those related to RFC 4585 in draft-ietf-payload-rtp-h265 are only for H.26= 5.

 <= /p>

OK, then I think we just = need to make this intention clearly said in the draft. Will include this cl= arification into the next version.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Bernard Aboba
Sent: Tuesday, December 10, 2013 3:00 PM
To: Stephan Wenger; payload issue tracker; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?

 

I didn't understand from the text that the modification = was only for H.265.   I had assumed that the refer= ences to feedback messages (and new message definition) was for all co= decs.  
 

> From: stewe@stewe.org
> To: trac+p= ayload@trac.tools.ietf.org; draft-ietf-pa= yload-rtp-h265@tools.ietf.org; bernard_aboba@hotmail.com<= br> > CC: payload@ietf.org
> Subject: Re: [payload] #2: Section 8.2: Updates RFC 4585?
> Date: Tue, 10 Dec 2013 21:50:15 +0000
>
> Hi Bernard,
>
> I don=B9t think it would be a particularly good idea if every payload = format
> spec is marked as =B3updating=B2 a general purpose spec when *for that= payload
> only* the payload spec allows/disallows/modifies aspects of the genera= l
> purpose spec.
>
> Hi Chairs: any guidance?
>
> Thanks,
> Stephan
>
>
> On 12.9.2013, 19:50 , "payload issue tracker"
> <trac+p= ayload@trac.tools.ietf.org> wrote:
>
> >#2: Section 8.2: Updates RFC 4585?
> >
> >
> >Comment (by bernard_a= boba@hotmail.com):
> >
> > Another reason for Updates: RFC 4585 is that Section 8.1 defines = the SPLI
> > Feedback Message.
> >
> >--
> >-------------------------------------+------------------------= ------------
> >-
> > Reporter: | Owner: draft-ietf-payload-
> > bernard_aboba@hotmai= l.com | rtp-h265@tools.ietf.org
> > Type: defect | Status: new
> > Priority: minor | Milestone: milestone1
> >Component: rtp-h265 | Version: 1.0
> > Severity: Active WG Document | Resolution:
> > Keywords: |
> >-------------------------------------+------------------------= ------------
> >-
> >
> >Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/2#comment:1= >
> >payload <http://tool= s.ietf.org/payload/>
> >
>

--_000_8BA7D4CEACFFE04BA2D902BF11719A83386E652Bnasanexd02fnaqu_-- From internet-drafts@ietf.org Wed Dec 11 15:32:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1867C1AE114; Wed, 11 Dec 2013 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzILNnSDF3Zm; Wed, 11 Dec 2013 15:32:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9A1AE154; Wed, 11 Dec 2013 15:32:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211233226.9674.11311.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 15:32:26 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-g7110-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:32:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for G.711.0 Author(s) : Michael A. Ramalho Paul E. Jones Noboru Harada Muthu Arul Mozhi Perumal Lei Miao Filename : draft-ietf-payload-g7110-01.txt Pages : 27 Date : 2013-12-11 Abstract: This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-g7110 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-g7110-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-g7110-01 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 mramalho@cisco.com Wed Dec 11 15:34:35 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3811AE1A1 for ; Wed, 11 Dec 2013 15:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1kCF5MBQS94 for ; Wed, 11 Dec 2013 15:34:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2011AE19A for ; Wed, 11 Dec 2013 15:34:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7353; q=dns/txt; s=iport; t=1386804867; x=1388014467; h=from:to:subject:date:message-id:mime-version; bh=VfbbXTJEbjoK8UPEem8XwVP3auvLAYm0K/esDMzfQ7U=; b=GRgkBiqBljb342TMlRfUPFoJVTvOPx5r8U8QnSPAB8FnqlMbbcEJm7Cd 2E5MW9ikxlBUVlYo3LIw994skRfvxAixtcyZuY2M06zJClyquQsDjJbmd Lk79Y1YVr8PlOzoz1K46gZz1d6DsTOfr0Bog0jHuO2JVPeP9CiN9RdytI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8GAFj2qFKtJV2Y/2dsb2JhbABZgkNEOFOmOIlyiTGBGxZ0giUBAQEELV4BGQQBAQtWHQkBBBMIh3kBDaMcnwEXjiYRAR+DWYETBJlEkGODKYFxOQ X-IronPort-AV: E=Sophos;i="4.93,874,1378857600"; d="scan'208,217";a="290773221" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 11 Dec 2013 23:34:10 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBNYANd029090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Dec 2013 23:34:10 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.86]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 17:34:09 -0600 From: "Michael Ramalho (mramalho)" To: "payload@ietf.org" Thread-Topic: Toward WGLC on G.711.0 RTP Payload Spec Thread-Index: Ac66NIJIYK6mF56FR8aFqe5fsMHitg8koGrA Date: Wed, 11 Dec 2013 23:34:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.18.61] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B910322FED529xmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: [payload] Toward WGLC on G.711.0 RTP Payload Spec X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:34:35 -0000 --_000_D21571530BF9644D9A443D6BD95B910322FED529xmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I have refreshed the G.711.0 RTP Payload draft (draft-ietf-payload-g7110) t= o version "01" as requested by the Payload WG co-chair, Ali Begen. The present version was due to expire on December 22 and the chairs did not= want it to expire during the last call. I note that all who responded to the email in the thread below supported th= e last call on this payload specification. Regards, Michael Ramalho From: Michael Ramalho (mramalho) Sent: Wednesday, September 25, 2013 2:17 PM To: payload@ietf.org Subject: Toward WGLC on G.711.0 RTP Payload Spec All, The payload WG has a milestone to submit the RTP Payload Format for G.711.0= for proposed standard in December 2013 (http://datatracker.ietf.org/wg/pay= load/charter/ ). The current working group draft is draft-ietf-payload-g7110-00 ( http://dat= atracker.ietf.org/doc/draft-ietf-payload-g7110/ ). Although this working group document is a "00" draft, it spent much time an= d prior re-writes as an individual contribution draft known as draft-ramalh= o-payload-g7110-0X. I have not received any requests to change this document since the conversi= on of the individual contribution draft to the working group draft (which o= ccurred in June 2013). As I would like to ask the Payload chairs to last call this document at the= Vancouver IETF, please provide any input you have on this document to this= list (including if you think it is ready as it is). Thanks in advance, Michael A. Ramalho --_000_D21571530BF9644D9A443D6BD95B910322FED529xmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,=

 

I have refreshed the G= .711.0 RTP Payload draft (draft-ietf-payload-g7110) to version “01= 221; as requested by the Payload WG co-chair, Ali Begen.<= /p>

 

The present version wa= s due to expire on December 22 and the chairs did not want it to expire dur= ing the last call.

 

I note that all who re= sponded to the email in the thread below supported the last call on this pa= yload specification.

 

Regards,

 

Michael Ramalho

 

From: Michael = Ramalho (mramalho)
Sent: Wednesday, September 25, 2013 2:17 PM
To: payload@ietf.org
Subject: Toward WGLC on G.711.0 RTP Payload Spec

 

All,

 

The payload WG has a milestone to submit the RTP Pay= load Format for G.711.0 for proposed standard in December 2013 (http://datatracker.ietf.or= g/wg/payload/charter/ ).

 

The current working group draft is draft-ietf-payloa= d-g7110-00 ( http:= //datatracker.ietf.org/doc/draft-ietf-payload-g7110/ ).

 

Although this working group document is a “00&= #8221; draft, it spent much time and prior re-writes as an individual contr= ibution draft known as draft-ramalho-payload-g7110-0X.

 

I have not received any requests to change this docu= ment since the conversion of the individual contribution draft to the worki= ng group draft (which occurred in June 2013).

 

As I would like to ask the Payload chairs to last ca= ll this document at the Vancouver IETF, please provide any input you have o= n this document to this list (including if you think it is ready as it is).=

 

Thanks in advance,

 

Michael A. Ramalho

--_000_D21571530BF9644D9A443D6BD95B910322FED529xmbrcdx12ciscoc_-- From ron.even.tlv@gmail.com Tue Dec 17 03:19:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B001AE173 for ; Tue, 17 Dec 2013 03:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8C0gDQT8spp for ; Tue, 17 Dec 2013 03:19:54 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 607C11AE168 for ; Tue, 17 Dec 2013 03:19:54 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id d49so2740272eek.5 for ; Tue, 17 Dec 2013 03:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=4uRPwjKTJc/4NzVQASTLNuxmytL7eQ6T/adFxtXtwdw=; b=IbhYNdesYCXV+AoFswGF8dku+03Nf/9T5pgcMPYnK6nwpM3za7rR3Q0y6jCTBUQAnu omc97RHvKMALlnbhWR07GS/g6YSxwa2W3fdS91c+HVaIx1wLXgLTz88Z5hL+a2KCCoK9 I4y18MxRYSZG7Sv01bSoK4czEyKOyA982v9WDn/je8u03acAHv1jQz/54gP0HjmAzwg1 5vSQvT51GsaTPoTsYykjB1vk+WSBgl/cJ+NPSnudHEe25Lg4XmZnJcuQDMQ4bGmNphQd kKFLvBYa9/Htql4W3b8v0temhwvYHNihfCgmwhX6EHHsLzqnfjts0kgnECD13TwVW7Ab xWzA== X-Received: by 10.14.202.137 with SMTP id d9mr22016126eeo.23.1387279192935; Tue, 17 Dec 2013 03:19:52 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id 4sm52102724eed.14.2013.12.17.03.19.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 17 Dec 2013 03:19:52 -0800 (PST) From: "Roni Even" To: Date: Tue, 17 Dec 2013 13:16:16 +0200 Message-ID: <045b01cefb19$6a2f9320$3e8eb960$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_045C_01CEFB2A.2DB8D850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac77GUGSr8E1OSmfSnev4ZcnpJKtxQ== Content-Language: en-us Subject: [payload] WGLC for draft-ietf-payload-g7110-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 11:19:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_045C_01CEFB2A.2DB8D850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WG, This is to start the WGLC for the G.711.0 draft http://tools.ietf.org/html/draft-ietf-payload-g7110-01 . The WGLC is for three weeks hoping that we can get feedback during the holidays Please send your comments and approvals to the payload list by January 7th. Authors, please address the nits http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-payload -g7110-01.txt about the references but please wait till the WGLC ends for a revision. Authors, please let the WG chairs know if you are aware of any IPR related to this draft. It is needed for the publication request. Thanks Roni Even Payload co-chair ------=_NextPart_000_045C_01CEFB2A.2DB8D850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

This = is to start the WGLC for the G.711.0 draft http://to= ols.ietf.org/html/draft-ietf-payload-g7110-01 .

The WGLC is for three weeks hoping that we can get = feedback during the holidays

Please send your comments and approvals to the = payload list by January 7th.

 

Authors, please address the nits http://tools.ietf.org/idnits?url=3Dhttp://too= ls.ietf.org/id/draft-ietf-payload-g7110-01.txt about the references = but please wait till the WGLC ends for a revision.

 

Authors, please let the WG chairs know if you are = aware of any IPR related to this draft. It is needed for the publication = request.

Thanks

Roni Even

Payload co-chair

 

------=_NextPart_000_045C_01CEFB2A.2DB8D850-- From stewe@stewe.org Wed Dec 18 15:09:20 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0038B1AE272 for ; Wed, 18 Dec 2013 15:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccvMu5rr5zFd for ; Wed, 18 Dec 2013 15:09:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 42DCB1AE264 for ; Wed, 18 Dec 2013 15:09:12 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.842.7; Wed, 18 Dec 2013 23:09:08 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) with mapi id 15.00.0842.003; Wed, 18 Dec 2013 23:09:08 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "bernard_aboba@hotmail.com" Thread-Topic: [payload] #7: Section 7.2.4 Dependency Signaling Thread-Index: AQHO9VrVNsWEfdCkFES/x5CbX5xwappaG3aA Date: Wed, 18 Dec 2013 23:09:07 +0000 Message-ID: In-Reply-To: <067.545a1702f51506376ab72ebd22e95325@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(164054003)(199002)(189002)(24454002)(479174003)(51704005)(377454003)(76786001)(49866001)(74502001)(47446002)(31966008)(74662001)(81342001)(66066001)(85852003)(47976001)(47736001)(50986001)(76176001)(74366001)(76482001)(90146001)(83322001)(81816001)(56816005)(65816001)(46102001)(85306002)(81686001)(87936001)(87266001)(2656002)(56776001)(19580395003)(74876001)(54316002)(79102001)(54356001)(53806001)(69226001)(51856001)(80022001)(63696002)(36756003)(76796001)(4396001)(77982001)(59766001)(83072002)(19580405001)(74706001)(81542001)(77096001)(80976001)(42262001)(861004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <24FADA6FCF3CE74394110ECC10BCA8EC@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 23:09:20 -0000 Hi Bernard, all, On 12/9/13, 7:49 PM, "payload issue tracker" wrote: >#7: Section 7.2.4 Dependency Signaling > > If MST is used, the rules on signaling media decoding dependency in SDP >as > defined in [RFC5583] apply. The rules on "hierarchical or layered > encoding" with multicast in Section 5.7 of [RFC4566] do not > apply, i.e., the notation for Connection Data "c=3D" SHALL NOT be used wi= th > more than one address. The order of session dependency is given from the > RTP session containing the lowest temporal sub-layer to the RTP session > containing the highest temporal sub-layer. > > [BA] The difference in O/A signaling between MST and SST is something we > should be striving to eliminate long-term. With RFC 6190, it wasn't > possible in SST to use RFC 5583 to negotiate layering in SDP since each > layer was on the same RTP session and we couldn't have multiple m lines > with the same port value. But now that we have BUNDLE that problem goes > away, and if we have multiple SSRC on the same RTP session, then RFC 5583 > with BUNDLE may be the preferred way to go. On the other hand, the SST > approach has some advantages for a WebRTC application that doesn't use >SDP > at all. Can we find some common ground, at least for MST unicast uses? This is an interesting topic. I agree in principle that we should eliminate the differences in signaling for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST, and their associated signaling: BUNDLE), but because, architecturally, a payload format should be agnostic to such details in the first place. This is not an HEVC specific problem, and it wasn=B9t an H.264-SVC specific problem either. It=B9s just so that this area was (and is) underspecified, and during the SVC payload format design, we had to do something, somewhere, so we did what we did in the then open document. We appear to have a number of options: 1. Call this a long-term problem. Leave this area of the payload draft =B3as is=B2 (SST and MST with existing restrictions, that have served us we= ll in the pre-BUNDLE world). Deal with BUNDLE and multiplexing issues if/when they arrive in standardization space. Webrtc is currently not overly concerned with H.265, and the rest of the industry has very limited (if any) experience with BUNDLEing, so this strategy may well be more palatable that it sounds at the first glance. 2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). BUNDLE specific would here be using BUNDLE in a single session environment. We would be adding a normative reference dependency. 3. Essentially option 1, but commit ourselves to wait for the BUNDLE RFC (and perhaps some initial implementation experience in the intersection of BUNDLE and layered or multicast codecs), and only then publish something to address the SSRC mux/BUNDLE use case. Ideally, that =B3something=B2 wou= ld be one or more RFCs that describe layered and/or multicast codec use over SST classic, MST classic, SST w/ Bundle, MST w/ BUNDLE (does that make sense?), and whatever else is en vogue at that time. This RFC would update the H.265 payload RFC and potentially deprecate some of the signaling mechanisms and restrictions present therein. I can promise personal cycles (to the extent one can promise anything these days), but note that this is not exactly my center of expertise. 4. Restructure the signaling of this HEVC payload draft such that it becomes agnostic to the underlying structure of sessions and their multiplexing. We would be talking about serious surgery based on limited (if any) practical implementation experience. It=B9s not the first time that is done, but it=B9s risky nevertheless. And it would take years... My personal preference is option 1 or option 3. Option 4 takes too much time (we know that 3GPP wants a normative reference soon), and the risk is too high that we will get something wrong. Option 2 has the potential of perpetuating a bad architectural decision of the past, namely to specify differences between various transport and signaling modes in a payload format. Reactions? Thanks, Stephan > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > From stewe@stewe.org Wed Dec 18 15:31:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5521AE225 for ; Wed, 18 Dec 2013 15:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XMieMN804Ee for ; Wed, 18 Dec 2013 15:31:55 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3308A1AE214 for ; Wed, 18 Dec 2013 15:31:55 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.842.7; Wed, 18 Dec 2013 23:31:49 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) with mapi id 15.00.0842.003; Wed, 18 Dec 2013 23:31:49 +0000 From: Stephan Wenger To: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "bernard_aboba@hotmail.com" Thread-Topic: [payload] #6: Section 4.4: SST vs. MST Thread-Index: AQHO9VfMkF6AUmsndEegSHhjk1Gy/5paIdMA Date: Wed, 18 Dec 2013 23:31:47 +0000 Message-ID: In-Reply-To: <067.4adc9845007df5cfa594d162894a517a@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 0064B3273C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(479174003)(51704005)(52604005)(51884002)(199002)(189002)(24454002)(74366001)(80976001)(51856001)(19580395003)(69226001)(53806001)(49866001)(19580405001)(4396001)(79102001)(63696002)(81816001)(83322001)(50986001)(56816005)(47736001)(85306002)(81686001)(47976001)(54356001)(85852003)(59766001)(46102001)(65816001)(56776001)(54316002)(77096001)(90146001)(74662001)(83072002)(77982001)(76482001)(76786001)(81542001)(31966008)(87936001)(74502001)(47446002)(81342001)(36756003)(76796001)(80022001)(87266001)(74706001)(2656002)(76176001)(74876001)(66066001)(42262001)(861004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-ID: <17B84A48149996419328ED4C792A901A@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" Subject: Re: [payload] #6: Section 4.4: SST vs. MST X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 23:32:00 -0000 Hi Bernard, all, Bernard, thanks for writing up these detailed notes. They are quite helpful. As for the general philosophy on how to deal with multiplexing schemes and BUNDLE, please see my reply to Ticket #7. More details inline. On 12/9/13, 7:27 PM, "payload issue tracker" wrote: >#6: Section 4.4: SST vs. MST > > This memo enables transmission of an HEVC bitstream over a single > RTP session or multiple RTP sessions. The concept and working > principle is inherited from [RFC6190] and follows a similar design. > If only one RTP session is used for transmission of the HEVC > bitstream, the transmission mode is referred to as single-session > transmission (SST); otherwise (more than one RTP session is used for > transmission of the HEVC bitstream), the transmission mode is > referred to as multi-session transmission (MST). > > [BA] This definition strikes me as inexact, because with BUNDLE, it is > possible for RFC 5583 to be used to negotiate "MST" usage within a single > RTP session. However, such an implementation sending multiple SSRCs on > the same RTP session would not really be "SST", would it? In the pre-BUNDLE and SSRC mux age, the distinction made was solid and consistent. Are we sure that we are already in the post-BUNDLE age, when it comes to the use of H.265? Could we kick that can down the road? > > In reality, the Multi-Session vs. Single-the distinction is not the > salient one -- it is Single SSRC Transport vs. Multiple SSRC Transport. We could introduce the notion of SSRC multiplexing into the draft. Doing so has certain risks, the main one being that the amount of documented implementation experience in this field is limited--certainly for the case of layered or simulcast codecs and absolutely for H.265 in a layered mode. In the interest of full disclosure: we in Vidyo have been doing something like this ion the transport plane for ages, and we know it works in our application. However, until just recently we were quite lonely in this camp. Beyond that, to me, the tricky part is the signaling support. Implementation experience with BUNDLE in the layered codec case is limited. =20 > > SST SHOULD be used for point-to-point unicast scenarios, while MST > SHOULD be used for point-to-multipoint multicast scenarios where > different receivers require different operation points of the same > HEVC bitstream, to improve bandwidth utilizing efficiency. > > [BA] While "Multi-Session Transport" is indeed more appropriate for > multicast scenarios, "Multi-SSRC Transport" is also used for unicast > scenarios. So this aspect could also be better explained. It is, no doubt. Is the payload format the right place to document that? Was it at the time of RFC6190? As I said before in my response to Ticket #7: having now the benefit of hindsight, I=B9m quite certain that we made a serious mistake when we added the SST/MST differentiation into the SVC payload spec. I=B9m very reluctant to pile onto that mistake for the transport mode that is currently in fashion. OTOH, I=B9m also very reluctant to try to =B3clean up=B2 the signaling by ripping out all we have and start from fresh. I rather go conservative with a spec that works in all documented cases, and leave the design work towards new operation modes for other documents. > > In addition to the unicast vs. multicast distinction, I'd like to see the > text go into the advantages/disadvantages of SST vs. MST in unicast > scenarios. Advantages of MST include: > > a. Not requiring sequence number rewriting on layer drops > b. Ability to utilize stream pause/resume RTCP messages > c. Potential improvements in ability to utilize RTCP reports to diagnose > SVC performance > d. Ability to negotiate FEC on some layers but not all > e. Explicit negotiation of layering in SDP > > There are also some disadvantages, such as: > > g. Need to utilize DON and/or timestamp for order recovery. We could add those points. Thanks for writing them up. But again, this is stuff that is not really H.265 related (or related to any other specific scalable/simulcast payload), right? More and more reason to write up a general layered/simulcast (dare I add multiple description) transport architecture doc. > > The transmission mode is indicated by the tx-mode media parameter > (see section 7.1). If tx-mode is equal to "SST", SST MUST be used. > Otherwise (tx-mode is equal to "MST"), MST MUST be used. > > [BA] Overall, I'd like to see this document have a goal to make progress > beyond RFC 6190 by eliminating interoperability failures between SST and > MST transport implementations. > > IMHO, with WebRTC on the horizon (where there may be no SDP exchange), we > are increasingly moving to codecs that "just work", rather than those >that > rely on O/A to negotiate "modes" (and sometimes failing to find common > ground). Can we instead strive for interoperability by design? > > With the commendable reduction in packet formats (e.g. STAP-A/B & FU-A/B > -> AP & FU) would it be possible to mandate support for both MST and SST > or at least mandate support for one of them in unicast & multicast > scenarios? Enthusiastically agreed in spirit, and not only because of rtcweb. I personally have no objection to require all receivers to implement both MST and SST. But note though, that there are still a number of use cases where full capability exchange is available, and where users are (or pretend to be) worried about implementation complexity. I=B9m personally willing to push; let=B9s see what the group thinks. Regards, Stephan > >--=20 >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: blocker | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Candidate WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > From bernard_aboba@hotmail.com Thu Dec 19 13:23:33 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B591AE920 for ; Thu, 19 Dec 2013 13:23:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI74lbf7HFYf for ; Thu, 19 Dec 2013 13:23:30 -0800 (PST) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfa.amsl.com (Postfix) with ESMTP id A68C71AE91F for ; Thu, 19 Dec 2013 13:23:30 -0800 (PST) Received: from BLU406-EAS241 ([65.55.111.73]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Dec 2013 13:23:28 -0800 X-TMN: [S9KiKDIEhILkuUygMYtNuJMXRQkDCMEG] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b58e628f-40ab-445f-b097-d13b6a1c3bc8_" Date: Thu, 19 Dec 2013 16:23:25 -0500 From: Bernard Aboba To: Stephan Wenger MIME-Version: 1.0 X-OriginalArrivalTime: 19 Dec 2013 21:23:28.0743 (UTC) FILETIME=[8F5DA770:01CEFD00] Cc: Bernard Aboba , payload issue tracker , "payload@ietf.org" , "draft-ietf-payload-rtp-h265@tools.ietf.org" Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 21:23:33 -0000 --_b58e628f-40ab-445f-b097-d13b6a1c3bc8_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" My concern was more about the RTP payload interoperability issues of MST vs= . SST=2C though I certainly do understand the concern over a BUNDLE depend= ency (so I would lean more toward option 3 for signalling). In particular=2C with the good work done to simplify the NAL unit types=2C = it seems that we are getting closer with H.265 to achieving interop out of= the gate=2C particularly if implementers correctly support temporal scalab= ility so we can take that for granted. Should implementations be required to handle one (e.g. SST) or both modes a= t the payload level=2C or will groups like UCI Forum once again need to cre= ate transport profiles as is being done with H.264/SVC? On Dec 18=2C 2013 6:09 PM=2C Stephan Wenger wrote: Hi Bernard=2C all=2C On 12/9/13=2C 7:49 PM=2C "payload issue tracker" wrote: >#7: Section 7.2.4 Dependency Signaling > > If MST is used=2C the rules on signaling media decoding dependency in SDP >as > defined in [RFC5583] apply. The rules on "hierarchical or layered > encoding" with multicast in Section 5.7 of [RFC4566] do not > apply=2C i.e.=2C the notation for Connection Data "c=3D" SHALL NOT be use= d with > more than one address. The order of session dependency is given from the > RTP session containing the lowest temporal sub-layer to the RTP session > containing the highest temporal sub-layer. > > [BA] The difference in O/A signaling between MST and SST is something we > should be striving to eliminate long-term. With RFC 6190=2C it wasn't > possible in SST to use RFC 5583 to negotiate layering in SDP since each > layer was on the same RTP session and we couldn't have multiple m lines > with the same port value. But now that we have BUNDLE that problem goes > away=2C and if we have multiple SSRC on the same RTP session=2C then RFC = 5583 > with BUNDLE may be the preferred way to go. On the other hand=2C the SS= T > approach has some advantages for a WebRTC application that doesn't use >SDP > at all. Can we find some common ground=2C at least for MST unicast uses? This is an interesting topic. I agree in principle that we should eliminate the differences in signaling for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST=2C and their associated signaling: BUNDLE)=2C but because=2C architecturally=2C a payloa= d format should be agnostic to such details in the first place. This is not an HEVC specific problem=2C and it wasn=C2=B9t an H.264-SVC specific proble= m either. It=C2=B9s just so that this area was (and is) underspecified=2C an= d during the SVC payload format design=2C we had to do something=2C somewhere= =2C so we did what we did in the then open document. We appear to have a number of options: 1. Call this a long-term problem. Leave this area of the payload draft =C2=B3as is=C2=B2 (SST and MST with existing restrictions=2C that have serv= ed us well in the pre-BUNDLE world). Deal with BUNDLE and multiplexing issues if/when they arrive in standardization space. Webrtc is currently not overly concerned with H.265=2C and the rest of the industry has very limite= d (if any) experience with BUNDLEing=2C so this strategy may well be more palatable that it sounds at the first glance. 2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). BUNDLE specific would here be using BUNDLE in a single session environment. We would be adding a normative reference dependency. 3. Essentially option 1=2C but commit ourselves to wait for the BUNDLE RFC (and perhaps some initial implementation experience in the intersection of BUNDLE and layered or multicast codecs)=2C and only then publish something to address the SSRC mux/BUNDLE use case. Ideally=2C that =C2=B3something= =C2=B2 would be one or more RFCs that describe layered and/or multicast codec use over SST classic=2C MST classic=2C SST w/ Bundle=2C MST w/ BUNDLE (does that mak= e sense?)=2C and whatever else is en vogue at that time. This RFC would update the H.265 payload RFC and potentially deprecate some of the signaling mechanisms and restrictions present therein. I can promise personal cycles (to the extent one can promise anything these days)=2C but note that this is not exactly my center of expertise. 4. Restructure the signaling of this HEVC payload draft such that it becomes agnostic to the underlying structure of sessions and their multiplexing. We would be talking about serious surgery based on limited (if any) practical implementation experience. It=C2=B9s not the first tim= e that is done=2C but it=C2=B9s risky nevertheless. And it would take years.= .. My personal preference is option 1 or option 3. Option 4 takes too much time (we know that 3GPP wants a normative reference soon)=2C and the risk i= s too high that we will get something wrong. Option 2 has the potential of perpetuating a bad architectural decision of the past=2C namely to specify differences between various transport and signaling modes in a payload format. Reactions? Thanks=2C Stephan > >-- >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > --_b58e628f-40ab-445f-b097-d13b6a1c3bc8_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

My concern was more about the RTP payload interoperability i= ssues of MST vs. SST=2C though I certainly do understand the concern over&n= bsp=3B a BUNDLE dependency (so I would lean more toward option 3 for signal= ling).

In particular=2C with the good work done to simplify the NAL= unit types=2C =3B it seems that we are getting closer with H.265 to ac= hieving interop out of the gate=2C particularly if implementers correctly s= upport temporal scalability so we can take that for granted.

Should implementations be required to handle one (e.g. SST) = or both modes at the payload level=2C or will groups like UCI Forum once ag= ain need to create transport profiles as is being done with H.264/SVC?

On Dec 18=2C 2013 6:09 PM=2C Stephan Wenger <=3Bstew= e@stewe.org>=3B wrote:
Hi Bernard=2C all=2C

On 12/9/13=2C 7:49 PM=2C "=3Bpayload issue tracker"=3B
<=3Btrac+=3Bpayload@trac.tools.ietf.org>=3B wrote:

>=3B#7: Section 7.2.4 Dependency Signaling
>=3B
>=3B If MST is used=2C the rules on signaling media decoding dependency i= n SDP
>=3Bas
>=3B defined in [RFC5583] apply. =3B The rules on "=3Bhierarchica= l or layered
>=3B encoding"=3B with multicast in Section 5.7 of [RFC4566] do not >=3B apply=2C i.e.=2C the notation for Connection Data "=3Bc=3D"= =3B SHALL NOT be used with
>=3B more than one address. =3B The order of session dependency is gi= ven from the
>=3B RTP session containing the lowest temporal sub-layer to the RTP sess= ion
>=3B containing the highest temporal sub-layer.
>=3B
>=3B [BA] The difference in O/A signaling between MST and SST is somethin= g we
>=3B should be striving to eliminate long-term. With RFC 6190=2C it wasn'= t
>=3B possible in SST to use RFC 5583 to negotiate layering in SDP since e= ach
>=3B layer was on the same RTP session and we couldn't have multiple m li= nes
>=3B with the same port value. But now that we have BUNDLE that problem g= oes
>=3B away=2C and if we have multiple SSRC on the same RTP session=2C then= RFC 5583
>=3B with BUNDLE may be the preferred way to go. =3B =3B On the o= ther hand=2C the SST
>=3B approach has some advantages for a WebRTC application that doesn't u= se
>=3BSDP
>=3B at all. =3B Can we find some common ground=2C at least for MST u= nicast uses?

This is an interesting topic.

I agree in principle that we should eliminate the differences in signaling<= br> for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST=2C and their
associated signaling: BUNDLE)=2C but because=2C architecturally=2C a payloa= d
format should be agnostic to such details in the first place. =3B This = is not
an HEVC specific problem=2C and it wasn=C2=B9t an H.264-SVC specific proble= m
either. =3B It=C2=B9s just so that this area was (and is) underspecifie= d=2C and
during the SVC payload format design=2C we had to do something=2C somewhere= =2C
so we did what we did in the then open document.

We appear to have a number of options:

1. Call this a long-term problem. =3B Leave this area of the payload dr= aft
=C2=B3as is=C2=B2 (SST and MST with existing restrictions=2C that have serv= ed us well
in the pre-BUNDLE world). =3B Deal with BUNDLE and multiplexing issues<= br> if/when they arrive in standardization space. =3B Webrtc is currently n= ot
overly concerned with H.265=2C and the rest of the industry has very limite= d
(if any) experience with BUNDLEing=2C so this strategy may well be more
palatable that it sounds at the first glance.

2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). =3B BUNDLE specific would here be usi= ng
BUNDLE in a single session environment. We would be adding a normative
reference dependency.


3. Essentially option 1=2C but commit ourselves to wait for the BUNDLE RFC<= br> (and perhaps some initial implementation experience in the intersection of<= br> BUNDLE and layered or multicast codecs)=2C and only then publish something<= br> to address the SSRC mux/BUNDLE use case. =3B Ideally=2C that =C2=B3some= thing=C2=B2 would
be one or more RFCs that describe layered and/or multicast codec use over SST classic=2C MST classic=2C SST w/ Bundle=2C MST w/ BUNDLE (does that mak= e
sense?)=2C and whatever else is en vogue at that time. =3B This RFC wou= ld
update the H.265 payload RFC and potentially deprecate some of the
signaling mechanisms and restrictions present therein. =3B I can promis= e
personal cycles (to the extent one can promise anything these days)=2C but<= br> note that this is not exactly my center of expertise.

4. Restructure the signaling of this HEVC payload draft such that it
becomes agnostic to the underlying structure of sessions and their
multiplexing. =3B We would be talking about serious surgery based on li= mited
(if any) practical implementation experience. =3B =3B It=C2=B9s not= the first time
that is done=2C but it=C2=B9s risky nevertheless. =3B And it would take= years...

My personal preference is option 1 or option 3. =3B Option 4 takes too = much
time (we know that 3GPP wants a normative reference soon)=2C and the risk i= s
too high that we will get something wrong. =3B Option 2 has the potenti= al of
perpetuating a bad architectural decision of the past=2C namely to specify<= br> differences between various transport and signaling modes in a payload
format.

Reactions?

Thanks=2C
Stephan


>=3B
>=3B--
>=3B-------------------------------------+=3B-------------------------= -----------
>=3B-
>=3B Reporter: =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= | =3B =3B =3B =3B =3B Owner: =3B draft-ietf-payloa= d-
>=3B =3B bernard_aboba@hotmail.com =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B | =3B rtp-h265@tools.ietf.org
>=3B =3B =3B =3B =3B Type: =3B defect =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B | =3B =3B&nbs= p=3B =3B Status: =3B new
>=3B Priority: =3B major =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B | =3B Milestone: =3B milestone1 >=3BComponent: =3B rtp-h265 =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B | =3B =3B =3B Version: =3B 1.0
>=3B Severity: =3B Active WG Document =3B =3B =3B =3B=  =3B =3B | =3B =3B Keywords:
>=3B-------------------------------------+=3B-------------------------= -----------
>=3B-
>=3B
>=3BTicket URL: <=3Bhttp://tools.ietf.org/wg/payload/trac/ticket/7>=3B
>=3Bpayload <=3Bhttp://tools= .ietf.org/payload/>=3B
>=3B

--_b58e628f-40ab-445f-b097-d13b6a1c3bc8_-- From stewe@stewe.org Thu Dec 19 13:56:22 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243B11AC7F0 for ; Thu, 19 Dec 2013 13:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ID4rAQ5txbS for ; Thu, 19 Dec 2013 13:56:19 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC691A1F74 for ; Thu, 19 Dec 2013 13:56:18 -0800 (PST) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) with Microsoft SMTP Server (TLS) id 15.0.842.7; Thu, 19 Dec 2013 21:56:06 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.31]) with mapi id 15.00.0842.003; Thu, 19 Dec 2013 21:56:06 +0000 From: Stephan Wenger To: Bernard Aboba Thread-Topic: [payload] #7: Section 7.2.4 Dependency Signaling Thread-Index: AQHO/QCNNsWEfdCkFES/x5CbX5xwappbihiA Date: Thu, 19 Dec 2013 21:56:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.99] x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(479174003)(51704005)(189002)(199002)(24454002)(164054003)(76482001)(80976001)(56816005)(85306002)(51856001)(46102001)(90146001)(53806001)(47976001)(81686001)(66066001)(59766001)(87266001)(49866001)(19580395003)(63696002)(50986001)(81816001)(83322001)(19580405001)(56776001)(54356001)(15975445006)(77982001)(87936001)(65816001)(77096001)(69226001)(2656002)(54316002)(15202345003)(74366001)(74662001)(74502001)(74876001)(47446002)(81342001)(16236675002)(36756003)(76176001)(83072002)(76786001)(81542001)(76796001)(85852003)(79102001)(4396001)(31966008)(47736001)(80022001)(74706001)(42262001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB363; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:50.174.124.99; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_CED8A88B3DD9Astewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 21:56:22 -0000 --_000_CED8A88B3DD9Astewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Bernard, Please see inline. Stephan From: Bernard Aboba > Date: Thu, 19 Dec 2013 16:23:25 -0500 To: Stephan Wenger > Cc: "payload@ietf.org" >, Bernard Aboba >, payload issue tracker >, "draft-ietf-payload-rtp-h265@to= ols.ietf.org" > Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling My concern was more about the RTP payload interoperability issues of MST vs= . SST, though I certainly do understand the concern over a BUNDLE dependen= cy (so I would lean more toward option 3 for signalling). Speaking personally, I have no idea, yet. First, this is signaling, which = is not my center of expertise. For example, I don=92t even recall in all i= ts glory what technical reason made us distinguishing MST and SST in 6190. = And second and perhaps more importantly, my preference is to get some expe= rience with =93easy=94 use cases first, before tackling this potentially th= orny issue in a generic way. In particular, with the good work done to simplify the NAL unit types, it = seems that we are getting closer with H.265 to achieving interop out of the= gate, particularly if implementers correctly support temporal scalability = so we can take that for granted. Should implementations be required to handle one (e.g. SST) or both modes a= t the payload level, or will groups like UCI Forum once again need to creat= e transport profiles as is being done with H.264/SVC? As I believe I have pointed out in my reply to your ticket #6, I would have= no objection to require all receiver implementations to handle both the SS= T and the MST use case. As for the more general issue of profiling RFCs with optional code points i= n the IETF or elsewhere, I rather see that done in forums like UCIF or 3GPP= than watch an organization like the IETF, which has little or no experienc= e in dealing with it, to make an attempt. I see at least three reasons. F= irst, narrow profiles that serve certain industries only (in contrast to br= oadly applicable protocol RFCs) allow for cost efficient solutions, without= harming interoperability in that respective industry. If the industry is = sufficiently =93closed=94 (in the sense that interoperability to other indu= stry products is not that big an issue=97one that can easily be trusted to = gateways that may eb required anyway), that is not as bad a solution as it = initially sounds. Second, profiling organizations will create profiles any= way. Maybe not UCIF, but others almost certainly. And third, Rtcweb is IM= O a very good example why the IETF should not attempt system design and pro= filing. We are not good at it. Stephan On Dec 18, 2013 6:09 PM, Stephan Wenger > wrote: Hi Bernard, all, On 12/9/13, 7:49 PM, "payload issue tracker" >= wrote: >#7: Section 7.2.4 Dependency Signaling > > If MST is used, the rules on signaling media decoding dependency in SDP >as > defined in [RFC5583] apply. The rules on "hierarchical or layered > encoding" with multicast in Section 5.7 of [RFC4566] do not > apply, i.e., the notation for Connection Data "c=3D" SHALL NOT be used wi= th > more than one address. The order of session dependency is given from the > RTP session containing the lowest temporal sub-layer to the RTP session > containing the highest temporal sub-layer. > > [BA] The difference in O/A signaling between MST and SST is something we > should be striving to eliminate long-term. With RFC 6190, it wasn't > possible in SST to use RFC 5583 to negotiate layering in SDP since each > layer was on the same RTP session and we couldn't have multiple m lines > with the same port value. But now that we have BUNDLE that problem goes > away, and if we have multiple SSRC on the same RTP session, then RFC 5583 > with BUNDLE may be the preferred way to go. On the other hand, the SST > approach has some advantages for a WebRTC application that doesn't use >SDP > at all. Can we find some common ground, at least for MST unicast uses? This is an interesting topic. I agree in principle that we should eliminate the differences in signaling for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST, and their associated signaling: BUNDLE), but because, architecturally, a payload format should be agnostic to such details in the first place. This is not an HEVC specific problem, and it wasn=B9t an H.264-SVC specific problem either. It=B9s just so that this area was (and is) underspecified, and during the SVC payload format design, we had to do something, somewhere, so we did what we did in the then open document. We appear to have a number of options: 1. Call this a long-term problem. Leave this area of the payload draft =B3as is=B2 (SST and MST with existing restrictions, that have served us we= ll in the pre-BUNDLE world). Deal with BUNDLE and multiplexing issues if/when they arrive in standardization space. Webrtc is currently not overly concerned with H.265, and the rest of the industry has very limited (if any) experience with BUNDLEing, so this strategy may well be more palatable that it sounds at the first glance. 2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). BUNDLE specific would here be using BUNDLE in a single session environment. We would be adding a normative reference dependency. 3. Essentially option 1, but commit ourselves to wait for the BUNDLE RFC (and perhaps some initial implementation experience in the intersection of BUNDLE and layered or multicast codecs), and only then publish something to address the SSRC mux/BUNDLE use case. Ideally, that =B3something=B2 wou= ld be one or more RFCs that describe layered and/or multicast codec use over SST classic, MST classic, SST w/ Bundle, MST w/ BUNDLE (does that make sense?), and whatever else is en vogue at that time. This RFC would update the H.265 payload RFC and potentially deprecate some of the signaling mechanisms and restrictions present therein. I can promise personal cycles (to the extent one can promise anything these days), but note that this is not exactly my center of expertise. 4. Restructure the signaling of this HEVC payload draft such that it becomes agnostic to the underlying structure of sessions and their multiplexing. We would be talking about serious surgery based on limited (if any) practical implementation experience. It=B9s not the first time that is done, but it=B9s risky nevertheless. And it would take years... My personal preference is option 1 or option 3. Option 4 takes too much time (we know that 3GPP wants a normative reference soon), and the risk is too high that we will get something wrong. Option 2 has the potential of perpetuating a bad architectural decision of the past, namely to specify differences between various transport and signaling modes in a payload format. Reactions? Thanks, Stephan > >-- >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | = rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > --_000_CED8A88B3DD9Astewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <57E6C993B15C534E831BD6EE0194CCCE@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Bernard,
Please see inline.
Stephan

From: Bernard Aboba <bernard_aboba@hotmail.com>
Date: Thu, 19 Dec 2013 16:23:25 -05= 00
To: Stephan Wenger <stewe@stewe.org>
Cc: "payload@ietf.org" <payload@ietf.org>, Bernard Aboba <bernard_aboba@hotmail.com>, payload issue tracker <trac&#= 43;payload@trac.tools.ietf.org>, "draft-ietf-payload-rtp-h265@tools.ietf.org= " <draft-ietf-payload-rtp-h265@tools.ietf.org>
Subject: Re: [payload] #7: Section = 7.2.4 Dependency Signaling

My concern was more about the RTP payload interoperability i= ssues of MST vs. SST, though I certainly do understand the concern over&nbs= p; a BUNDLE dependency (so I would lean more toward option 3 for signalling= ).
Speaking personally, I have no idea, yet.  First, this is signali= ng, which is not my center of expertise.  For example, I don=92t even = recall in all its glory what technical reason made us distinguishing MST an= d SST in 6190.  And second and perhaps more importantly, my preference is to get some experience with =93easy=94 use c= ases first, before tackling this potentially thorny issue in a generic way.=

In particular, with the good work done to simplify the NAL u= nit types,  it seems that we are getting closer with H.265 to achievin= g interop out of the gate, particularly if implementers correctly support t= emporal scalability so we can take that for granted.

Should implementations be required to handle one (e.g. SST) = or both modes at the payload level, or will groups like UCI Forum once agai= n need to create transport profiles as is being done with H.264/SVC?
As I believe I have pointed out in my reply to your ticket #6, I would= have no objection to require all receiver implementations to handle both t= he SST and the MST use case.

As for the more general issue of profiling RFCs with optional code poi= nts in the IETF or elsewhere, I rather see that done in forums like UCIF or= 3GPP than watch an organization like the IETF, which has little or no expe= rience in dealing with it, to make an attempt.  I see at least three reasons.  First, narrow profil= es that serve certain industries only (in contrast to broadly applicable pr= otocol RFCs) allow for cost efficient solutions, without harming interopera= bility in that respective industry.  If the industry is sufficiently =93closed=94 (in the sense that interoperability = to other industry products is not that big an issue=97one that can easily b= e trusted to gateways that may eb required anyway), that is not as bad a so= lution as it initially sounds.  Second, profiling organizations will create profiles anyway.  Maybe not UCIF,= but others almost certainly.  And third, Rtcweb is IMO a very good ex= ample why the IETF should not attempt system design and profiling.  We= are not good at it.

Stephan

On Dec 18, 2013 6:09 PM, Stephan Wenger <stewe@stewe.org> wrote:
Hi Bernard, all,

On 12/9/13, 7:49 PM, "payload issue tracker"
<trac+payloa= d@trac.tools.ietf.org> wrote:

>#7: Section 7.2.4 Dependency Signaling
>
> If MST is used, the rules on signaling media decoding dependency in SD= P
>as
> defined in [RFC5583] apply.  The rules on "hierarchical or l= ayered
> encoding" with multicast in Section 5.7 of [RFC4566] do not
> apply, i.e., the notation for Connection Data "c=3D" SHALL N= OT be used with
> more than one address.  The order of session dependency is given = from the
> RTP session containing the lowest temporal sub-layer to the RTP sessio= n
> containing the highest temporal sub-layer.
>
> [BA] The difference in O/A signaling between MST and SST is something = we
> should be striving to eliminate long-term. With RFC 6190, it wasn't > possible in SST to use RFC 5583 to negotiate layering in SDP since eac= h
> layer was on the same RTP session and we couldn't have multiple m line= s
> with the same port value. But now that we have BUNDLE that problem goe= s
> away, and if we have multiple SSRC on the same RTP session, then RFC 5= 583
> with BUNDLE may be the preferred way to go.   On the other h= and, the SST
> approach has some advantages for a WebRTC application that doesn't use=
>SDP
> at all.  Can we find some common ground, at least for MST unicast= uses?

This is an interesting topic.

I agree in principle that we should eliminate the differences in signaling<= br> for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST, and their
associated signaling: BUNDLE), but because, architecturally, a payload
format should be agnostic to such details in the first place.  This is= not
an HEVC specific problem, and it wasn=B9t an H.264-SVC specific problem
either.  It=B9s just so that this area was (and is) underspecified, an= d
during the SVC payload format design, we had to do something, somewhere, so we did what we did in the then open document.

We appear to have a number of options:

1. Call this a long-term problem.  Leave this area of the payload draf= t
=B3as is=B2 (SST and MST with existing restrictions, that have served us we= ll
in the pre-BUNDLE world).  Deal with BUNDLE and multiplexing issues if/when they arrive in standardization space.  Webrtc is currently not=
overly concerned with H.265, and the rest of the industry has very limited<= br> (if any) experience with BUNDLEing, so this strategy may well be more
palatable that it sounds at the first glance.

2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today).  BUNDLE specific would here be using=
BUNDLE in a single session environment. We would be adding a normative
reference dependency.


3. Essentially option 1, but commit ourselves to wait for the BUNDLE RFC (and perhaps some initial implementation experience in the intersection of<= br> BUNDLE and layered or multicast codecs), and only then publish something to address the SSRC mux/BUNDLE use case.  Ideally, that =B3something= =B2 would
be one or more RFCs that describe layered and/or multicast codec use over SST classic, MST classic, SST w/ Bundle, MST w/ BUNDLE (does that make
sense?), and whatever else is en vogue at that time.  This RFC would update the H.265 payload RFC and potentially deprecate some of the
signaling mechanisms and restrictions present therein.  I can promise<= br> personal cycles (to the extent one can promise anything these days), but note that this is not exactly my center of expertise.

4. Restructure the signaling of this HEVC payload draft such that it
becomes agnostic to the underlying structure of sessions and their
multiplexing.  We would be talking about serious surgery based on limi= ted
(if any) practical implementation experience.   It=B9s not the fi= rst time
that is done, but it=B9s risky nevertheless.  And it would take years.= ..

My personal preference is option 1 or option 3.  Option 4 takes too mu= ch
time (we know that 3GPP wants a normative reference soon), and the risk is<= br> too high that we will get something wrong.  Option 2 has the potential= of
perpetuating a bad architectural decision of the past, namely to specify differences between various transport and signaling modes in a payload
format.

Reactions?

Thanks,
Stephan


>
>--
>-------------------------------------+-----------------------------= -------
>-
> Reporter:          &= nbsp;           &nbs= p;    |      Owner:  draft-iet= f-payload-
>  bernard_aboba@hotma= il.com          |  rtp-h265@tools.ietf.org
>     Type:  defect    &nbs= p;            &= nbsp; |     Status:  new
> Priority:  major        &= nbsp;           |  M= ilestone:  milestone1
>Component:  rtp-h265       &nbs= p;         |    Vers= ion:  1.0
> Severity:  Active WG Document      = |   Keywords:
>-------------------------------------+-----------------------------= -------
>-
>
>Ticket URL: <http://tools.ietf.org/wg/payload/trac/ticket/7>
>payload <http://tools.iet= f.org/payload/>
>

 --_000_CED8A88B3DD9Astewesteweorg_-- From bernard_aboba@hotmail.com Thu Dec 19 16:15:04 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB11AED81 for ; Thu, 19 Dec 2013 16:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7c4hX90qyov for ; Thu, 19 Dec 2013 16:15:01 -0800 (PST) Received: from blu0-omc4-s12.blu0.hotmail.com (blu0-omc4-s12.blu0.hotmail.com [65.55.111.151]) by ietfa.amsl.com (Postfix) with ESMTP id AC57A1AED80 for ; Thu, 19 Dec 2013 16:15:00 -0800 (PST) Received: from BLU406-EAS29 ([65.55.111.136]) by blu0-omc4-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Dec 2013 16:14:58 -0800 X-TMN: [CRYVtPMVUCuP0ZxZiNqm8Kt7qCyD1s+q] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_b6751faa-b9b7-4937-9b2e-6e474a2fce0c_" Date: Thu, 19 Dec 2013 19:14:55 -0500 From: Bernard Aboba To: Stephan Wenger MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2013 00:14:58.0717 (UTC) FILETIME=[84AB14D0:01CEFD18] Cc: payload issue tracker , "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" , Bernard Aboba Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 00:15:04 -0000 --_b6751faa-b9b7-4937-9b2e-6e474a2fce0c_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" If implementations could be required to support both SST and MST in H.265= =2C that would be a big win IMHO. Assuming that implementations correctly = handle DON=2C we should be most of the way there anyway. Given the inclusion of scalability support in the headers and simplificatio= ns=2C the goal of improved payload interop for H.265 seems attainable and w= ell worth shooting for. So while I can see the potential need for a bitstre= am profile along the lines of what UCI Forum did for H.264/SVC=2C it would = be great if no transport profile was needed. On Dec 19=2C 2013 4:56 PM=2C Stephan Wenger wrote: Hi Bernard=2C Please see inline. Stephan From: Bernard Aboba > Date: Thu=2C 19 Dec 2013 16:23:25 -0500 To: Stephan Wenger > Cc: "payload@ietf.org" >=2C Bernard Aboba >=2C payload issue tracker >=2C "draft-ietf-payload-rtp-h= 265@tools.ietf.org" > Subject: Re: [payload] #7: Section 7.2.4 Dependency Signaling My concern was more about the RTP payload interoperability issues of MST vs= . SST=2C though I certainly do understand the concern over a BUNDLE depend= ency (so I would lean more toward option 3 for signalling). Speaking personally=2C I have no idea=2C yet. First=2C this is signaling= =2C which is not my center of expertise. For example=2C I don=E2=80=99t ev= en recall in all its glory what technical reason made us distinguishing MST= and SST in 6190. And second and perhaps more importantly=2C my preference= is to get some experience with =E2=80=9Ceasy=E2=80=9D use cases first=2C b= efore tackling this potentially thorny issue in a generic way. In particular=2C with the good work done to simplify the NAL unit types=2C = it seems that we are getting closer with H.265 to achieving interop out of= the gate=2C particularly if implementers correctly support temporal scalab= ility so we can take that for granted. Should implementations be required to handle one (e.g. SST) or both modes a= t the payload level=2C or will groups like UCI Forum once again need to cre= ate transport profiles as is being done with H.264/SVC? As I believe I have pointed out in my reply to your ticket #6=2C I would ha= ve no objection to require all receiver implementations to handle both the = SST and the MST use case. As for the more general issue of profiling RFCs with optional code points i= n the IETF or elsewhere=2C I rather see that done in forums like UCIF or 3G= PP than watch an organization like the IETF=2C which has little or no exper= ience in dealing with it=2C to make an attempt. I see at least three reaso= ns. First=2C narrow profiles that serve certain industries only (in contra= st to broadly applicable protocol RFCs) allow for cost efficient solutions= =2C without harming interoperability in that respective industry. If the i= ndustry is sufficiently =E2=80=9Cclosed=E2=80=9D (in the sense that interop= erability to other industry products is not that big an issue=E2=80=94one t= hat can easily be trusted to gateways that may eb required anyway)=2C that = is not as bad a solution as it initially sounds. Second=2C profiling organ= izations will create profiles anyway. Maybe not UCIF=2C but others almost = certainly. And third=2C Rtcweb is IMO a very good example why the IETF sho= uld not attempt system design and profiling. We are not good at it. Stephan On Dec 18=2C 2013 6:09 PM=2C Stephan Wenger > wrote: Hi Bernard=2C all=2C On 12/9/13=2C 7:49 PM=2C "payload issue tracker" >= wrote: >#7: Section 7.2.4 Dependency Signaling > > If MST is used=2C the rules on signaling media decoding dependency in SDP >as > defined in [RFC5583] apply. The rules on "hierarchical or layered > encoding" with multicast in Section 5.7 of [RFC4566] do not > apply=2C i.e.=2C the notation for Connection Data "c=3D" SHALL NOT be use= d with > more than one address. The order of session dependency is given from the > RTP session containing the lowest temporal sub-layer to the RTP session > containing the highest temporal sub-layer. > > [BA] The difference in O/A signaling between MST and SST is something we > should be striving to eliminate long-term. With RFC 6190=2C it wasn't > possible in SST to use RFC 5583 to negotiate layering in SDP since each > layer was on the same RTP session and we couldn't have multiple m lines > with the same port value. But now that we have BUNDLE that problem goes > away=2C and if we have multiple SSRC on the same RTP session=2C then RFC = 5583 > with BUNDLE may be the preferred way to go. On the other hand=2C the SS= T > approach has some advantages for a WebRTC application that doesn't use >SDP > at all. Can we find some common ground=2C at least for MST unicast uses? This is an interesting topic. I agree in principle that we should eliminate the differences in signaling for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST=2C and their associated signaling: BUNDLE)=2C but because=2C architecturally=2C a payloa= d format should be agnostic to such details in the first place. This is not an HEVC specific problem=2C and it wasn=C2=B9t an H.264-SVC specific proble= m either. It=C2=B9s just so that this area was (and is) underspecified=2C an= d during the SVC payload format design=2C we had to do something=2C somewhere= =2C so we did what we did in the then open document. We appear to have a number of options: 1. Call this a long-term problem. Leave this area of the payload draft =C2=B3as is=C2=B2 (SST and MST with existing restrictions=2C that have serv= ed us well in the pre-BUNDLE world). Deal with BUNDLE and multiplexing issues if/when they arrive in standardization space. Webrtc is currently not overly concerned with H.265=2C and the rest of the industry has very limite= d (if any) experience with BUNDLEing=2C so this strategy may well be more palatable that it sounds at the first glance. 2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). BUNDLE specific would here be using BUNDLE in a single session environment. We would be adding a normative reference dependency. 3. Essentially option 1=2C but commit ourselves to wait for the BUNDLE RFC (and perhaps some initial implementation experience in the intersection of BUNDLE and layered or multicast codecs)=2C and only then publish something to address the SSRC mux/BUNDLE use case. Ideally=2C that =C2=B3something= =C2=B2 would be one or more RFCs that describe layered and/or multicast codec use over SST classic=2C MST classic=2C SST w/ Bundle=2C MST w/ BUNDLE (does that mak= e sense?)=2C and whatever else is en vogue at that time. This RFC would update the H.265 payload RFC and potentially deprecate some of the signaling mechanisms and restrictions present therein. I can promise personal cycles (to the extent one can promise anything these days)=2C but note that this is not exactly my center of expertise. 4. Restructure the signaling of this HEVC payload draft such that it becomes agnostic to the underlying structure of sessions and their multiplexing. We would be talking about serious surgery based on limited (if any) practical implementation experience. It=C2=B9s not the first tim= e that is done=2C but it=C2=B9s risky nevertheless. And it would take years.= .. My personal preference is option 1 or option 3. Option 4 takes too much time (we know that 3GPP wants a normative reference soon)=2C and the risk i= s too high that we will get something wrong. Option 2 has the potential of perpetuating a bad architectural decision of the past=2C namely to specify differences between various transport and signaling modes in a payload format. Reactions? Thanks=2C Stephan > >-- >-------------------------------------+------------------------------------ >- > Reporter: | Owner: draft-ietf-payload- > bernard_aboba@hotmail.com | = rtp-h265@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: milestone1 >Component: rtp-h265 | Version: 1.0 > Severity: Active WG Document | Keywords: >-------------------------------------+------------------------------------ >- > >Ticket URL: >payload > --_b6751faa-b9b7-4937-9b2e-6e474a2fce0c_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

If implementations could be required to support both SST and= MST in H.265=2C that would be a big win IMHO. =3B Assuming that implem= entations correctly handle DON=2C we should be most of the way there anyway= .

Given the inclusion of scalability support in the headers an= d simplifications=2C the goal of improved payload interop for H.265 seems a= ttainable and well worth shooting for. So while I can see the potential nee= d for a bitstream profile along the lines of what UCI Forum did for H.264/SVC=2C it would be great if no trans= port profile was needed.

On Dec 19=2C 2013 4:56 PM=2C Stephan Wenger <=3Bstew= e@stewe.org>=3B wrote:
Hi Bernard=2C
Please see inline.
Stephan

From: Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B Date: Thu=2C 19 Dec 2013 16:23:25 -= 0500
To: Stephan Wenger <=3Bstewe@stewe.org>=3B
Cc: "=3Bpayload@ietf.org"=3B <=3Bpayload@ietf.org>=3B=2C Bernard Aboba <=3Bbernard_aboba@hotmail.com>=3B=2C payload= issue tracker <=3Btr= ac+=3Bpayload@trac.tools.ietf.org>=3B=2C "=3Bdraft-ietf-payload-rtp-h265@to= ols.ietf.org"=3B <=3Bdraft-ietf-payload-rtp-h265@tools.ietf.org>=3B
Subject: Re: [payload] #7: Section = 7.2.4 Dependency Signaling

My concern was more about the RTP payload interoperability i= ssues of MST vs. SST=2C though I certainly do understand the concern over&n= bsp=3B a BUNDLE dependency (so I would lean more toward option 3 for signal= ling).
Speaking personally=2C I have no idea=2C yet.  =3BFirst=2C this is= signaling=2C which is not my center of expertise.  =3BFor example=2C I= don=E2=80=99t even recall in all its glory what technical reason made us d= istinguishing MST and SST in 6190.  =3BAnd second and perhaps more importantly=2C my preference is to get some experience with =E2=80=9Ceasy= =E2=80=9D use cases first=2C before tackling this potentially thorny issue = in a generic way.

In particular=2C with the good work done to simplify the NAL= unit types=2C =3B it seems that we are getting closer with H.265 to ac= hieving interop out of the gate=2C particularly if implementers correctly s= upport temporal scalability so we can take that for granted.

Should implementations be required to handle one (e.g. SST) = or both modes at the payload level=2C or will groups like UCI Forum once ag= ain need to create transport profiles as is being done with H.264/SVC?
As I believe I have pointed out in my reply to your ticket #6=2C I wou= ld have no objection to require all receiver implementations to handle both= the SST and the MST use case.

As for the more general issue of profiling RFCs with optional code poi= nts in the IETF or elsewhere=2C I rather see that done in forums like UCIF = or 3GPP than watch an organization like the IETF=2C which has little or no = experience in dealing with it=2C to make an attempt.  =3BI see at least three reasons.  =3BFirst=2C narrow = profiles that serve certain industries only (in contrast to broadly applica= ble protocol RFCs) allow for cost efficient solutions=2C without harming in= teroperability in that respective industry.  =3BIf the industry is sufficiently =E2=80=9Cclosed=E2=80=9D (in the sense that inter= operability to other industry products is not that big an issue=E2=80=94one= that can easily be trusted to gateways that may eb required anyway)=2C tha= t is not as bad a solution as it initially sounds.  =3BSecond=2C profiling organizations will create profiles anyway.  =3BMaybe not UCI= F=2C but others almost certainly.  =3BAnd third=2C Rtcweb is IMO a very= good example why the IETF should not attempt system design and profiling. =  =3BWe are not good at it.

Stephan

On Dec 18=2C 2013 6:09 PM=2C Stephan Wenger <=3Bstewe@stewe.org>=3B wrote:
Hi Bernard=2C all=2C

On 12/9/13=2C 7:49 PM=2C "=3Bpayload issue tracker"=3B
<=3Btrac+=3B= payload@trac.tools.ietf.org>=3B wrote:

>=3B#7: Section 7.2.4 Dependency Signaling
>=3B
>=3B If MST is used=2C the rules on signaling media decoding dependency i= n SDP
>=3Bas
>=3B defined in [RFC5583] apply. =3B The rules on "=3Bhierarchica= l or layered
>=3B encoding"=3B with multicast in Section 5.7 of [RFC4566] do not >=3B apply=2C i.e.=2C the notation for Connection Data "=3Bc=3D"= =3B SHALL NOT be used with
>=3B more than one address. =3B The order of session dependency is gi= ven from the
>=3B RTP session containing the lowest temporal sub-layer to the RTP sess= ion
>=3B containing the highest temporal sub-layer.
>=3B
>=3B [BA] The difference in O/A signaling between MST and SST is somethin= g we
>=3B should be striving to eliminate long-term. With RFC 6190=2C it wasn'= t
>=3B possible in SST to use RFC 5583 to negotiate layering in SDP since e= ach
>=3B layer was on the same RTP session and we couldn't have multiple m li= nes
>=3B with the same port value. But now that we have BUNDLE that problem g= oes
>=3B away=2C and if we have multiple SSRC on the same RTP session=2C then= RFC 5583
>=3B with BUNDLE may be the preferred way to go. =3B =3B On the o= ther hand=2C the SST
>=3B approach has some advantages for a WebRTC application that doesn't u= se
>=3BSDP
>=3B at all. =3B Can we find some common ground=2C at least for MST u= nicast uses?

This is an interesting topic.

I agree in principle that we should eliminate the differences in signaling<= br> for Single Session Transmission (SST) and Multi-Session Transmission MST. And not only for the reason you cited (the arrival of now widely accepted transport schemes that are neither full SST nor full MST=2C and their
associated signaling: BUNDLE)=2C but because=2C architecturally=2C a payloa= d
format should be agnostic to such details in the first place. =3B This = is not
an HEVC specific problem=2C and it wasn=C2=B9t an H.264-SVC specific proble= m
either. =3B It=C2=B9s just so that this area was (and is) underspecifie= d=2C and
during the SVC payload format design=2C we had to do something=2C somewhere= =2C
so we did what we did in the then open document.

We appear to have a number of options:

1. Call this a long-term problem. =3B Leave this area of the payload dr= aft
=C2=B3as is=C2=B2 (SST and MST with existing restrictions=2C that have serv= ed us well
in the pre-BUNDLE world). =3B Deal with BUNDLE and multiplexing issues<= br> if/when they arrive in standardization space. =3B Webrtc is currently n= ot
overly concerned with H.265=2C and the rest of the industry has very limite= d
(if any) experience with BUNDLEing=2C so this strategy may well be more
palatable that it sounds at the first glance.

2. Add BUNDLE-specific language (potentially as a third mode in addition to SST and MST as defined today). =3B BUNDLE specific would here be usi= ng
BUNDLE in a single session environment. We would be adding a normative
reference dependency.


3. Essentially option 1=2C but commit ourselves to wait for the BUNDLE RFC<= br> (and perhaps some initial implementation experience in the intersection of<= br> BUNDLE and layered or multicast codecs)=2C and only then publish something<= br> to address the SSRC mux/BUNDLE use case. =3B Ideally=2C that =C2=B3some= thing=C2=B2 would
be one or more RFCs that describe layered and/or multicast codec use over SST classic=2C MST classic=2C SST w/ Bundle=2C MST w/ BUNDLE (does that mak= e
sense?)=2C and whatever else is en vogue at that time. =3B This RFC wou= ld
update the H.265 payload RFC and potentially deprecate some of the
signaling mechanisms and restrictions present therein. =3B I can promis= e
personal cycles (to the extent one can promise anything these days)=2C but<= br> note that this is not exactly my center of expertise.

4. Restructure the signaling of this HEVC payload draft such that it
becomes agnostic to the underlying structure of sessions and their
multiplexing. =3B We would be talking about serious surgery based on li= mited
(if any) practical implementation experience. =3B =3B It=C2=B9s not= the first time
that is done=2C but it=C2=B9s risky nevertheless. =3B And it would take= years...

My personal preference is option 1 or option 3. =3B Option 4 takes too = much
time (we know that 3GPP wants a normative reference soon)=2C and the risk i= s
too high that we will get something wrong. =3B Option 2 has the potenti= al of
perpetuating a bad architectural decision of the past=2C namely to specify<= br> differences between various transport and signaling modes in a payload
format.

Reactions?

Thanks=2C
Stephan


>=3B
>=3B--
>=3B-------------------------------------+=3B-------------------------= -----------
>=3B-
>=3B Reporter: =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= | =3B =3B =3B =3B =3B Owner: =3B draft-ietf-payloa= d-
>=3B =3B bernard_aboba@h= otmail.com =3B =3B =3B =3B =3B =3B =3B = =3B =3B | =3B rtp-h265@tools.ietf.org
>=3B =3B =3B =3B =3B Type: =3B defect =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B =3B =3B =3B =3B =3B =3B | =3B =3B&nbs= p=3B =3B Status: =3B new
>=3B Priority: =3B major =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B | =3B Milestone: =3B milestone1 >=3BComponent: =3B rtp-h265 =3B =3B =3B =3B =3B&n= bsp=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B | =3B =3B =3B Version: =3B 1.0
>=3B Severity: =3B Active WG Document =3B =3B =3B =3B=  =3B =3B | =3B =3B Keywords:
>=3B-------------------------------------+=3B-------------------------= -----------
>=3B-
>=3B
>=3BTicket URL: <=3Bhttp://tools.ietf.org/wg/payload/trac/ticket/7>=3B
>=3Bpayload <=3Bhttp://tools= .ietf.org/payload/>=3B
>=3B

--_b6751faa-b9b7-4937-9b2e-6e474a2fce0c_-- From bernard_aboba@hotmail.com Fri Dec 20 09:39:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84A01AE0AB for ; Fri, 20 Dec 2013 09:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61os0WY1Wmr4 for ; Fri, 20 Dec 2013 09:39:13 -0800 (PST) Received: from blu0-omc4-s24.blu0.hotmail.com (blu0-omc4-s24.blu0.hotmail.com [65.55.111.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAE61AE043 for ; Fri, 20 Dec 2013 09:39:13 -0800 (PST) Received: from BLU169-W130 ([65.55.111.135]) by blu0-omc4-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Dec 2013 09:39:11 -0800 X-TMN: [vh277lAsMLVTgXkXYD8AA4+9CcLZUxnZ] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a48be14d-300e-455d-8bc7-a70fc604b964_" From: Bernard Aboba To: Stephan Wenger , "draft-ietf-payload-rtp-h265@tools.ietf.org" Date: Fri, 20 Dec 2013 09:39:10 -0800 Importance: Normal In-Reply-To: References: <067.4adc9845007df5cfa594d162894a517a@trac.tools.ietf.org>, MIME-Version: 1.0 X-OriginalArrivalTime: 20 Dec 2013 17:39:11.0107 (UTC) FILETIME=[64671D30:01CEFDAA] Cc: "payload@ietf.org" Subject: Re: [payload] #6: Section 4.4: SST vs. MST X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 17:39:16 -0000 --_a48be14d-300e-455d-8bc7-a70fc604b964_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > In the pre-BUNDLE and SSRC mux age=2C the distinction made was solid and > consistent. Are we sure that we are already in the post-BUNDLE age=2C wh= en > it comes to the use of H.265? Could we kick that can down the road? [BA] It is possible (and maybe even advisable) for the H.265 draft to avoid= a dependency on the BUNDLE and the appID drafts. That would imply using = the same SDP facilities as were utilized in the examples of RFC 6184 and 61= 90. But that seems ok.=20 > We could introduce the notion of SSRC multiplexing into the draft. Doing > so has certain risks=2C the main one being that the amount of documented > implementation experience in this field is limited--certainly for the cas= e > of layered or simulcast codecs and absolutely for H.265 in a layered mode= . > In the interest of full disclosure: we in Vidyo have been doing somethin= g > like this ion the transport plane for ages=2C and we know it works in our > application. However=2C until just recently we were quite lonely in this > camp. Beyond that=2C to me=2C the tricky part is the signaling support. [BA] In terms of RTP transport (e.g. use of DONL field)=2C the distinction = is really whether you have a single sequence number space (single SSRC) or = not (multiple SSRC=2C whether on a single RTP session or not). That much s= eems worth clarifying.=20 > I personally have no objection to require all receivers to implement both > MST and SST. But note though=2C that there are still a number of use case= s > where full capability exchange is available=2C and where users are (or > pretend to be) worried about implementation complexity. I=B9m personally > willing to push=3B let=B9s see what the group thinks. [BA] It seems like a useful goal to ensure that temporal scalability "just = works"=2C regardless of whether SST or MST transport is in use. For exampl= e=2C I noted with approval that the "mst-mode" parameter from RFC 6190 was = not included in this draft. =20 > More and more reason to write up a general layered/simulcast (dare I add = multiple description) > transport architecture doc. [BA] Not a bad idea.=20 = --_a48be14d-300e-455d-8bc7-a70fc604b964_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3B>=3B In the pre-B= UNDLE and SSRC mux age=2C the distinction made was solid and
>=3B cons= istent. Are we sure that we are already in the post-BUNDLE age=2C when
= >=3B it comes to the use of H.265? Could we kick that can down the road?=

[BA] It is possible (and maybe even advisable) fo= r the H.265 draft to avoid a dependency on the BUNDLE and the appID drafts.=  =3B That would imply using the same SDP facilities as were utilized i= n the examples of RFC 6184 and 6190. But that seems ok. =3B
<= br>
>=3B We could introduce the notion of SSRC multiplexing int= o the draft. Doing
>=3B so has certain risks=2C the main one being th= at the amount of documented
>=3B implementation experience in this fie= ld is limited--certainly for the case
>=3B of layered or simulcast cod= ecs and absolutely for H.265 in a layered mode.
>=3B In the interest = of full disclosure: we in Vidyo have been doing something
>=3B like th= is ion the transport plane for ages=2C and we know it works in our
>= =3B application. However=2C until just recently we were quite lonely in th= is
>=3B camp. Beyond that=2C to me=2C the tricky part is the signalin= g support.

[BA] In =3Bterms of RTP transport (e.g. use of DONL field)=2C the distinc= tion is really whether you have a single sequence number space (single SSRC= ) or not (multiple SSRC=2C whether on a single RTP session or not).  = =3BThat much seems worth clarifying. =3B

>=3B I personally have no objection to require all receivers to im= plement both
>=3B MST and SST. But note though=2C that there are still= a number of use cases
>=3B where full capability exchange is availabl= e=2C and where users are (or
>=3B pretend to be) worried about impleme= ntation complexity. I=B9m personally
>=3B willing to push=3B let=B9s s= ee what the group thinks.

[BA] It seems like a useful goa= l to ensure that =3Btemporal scalabi= lity "just works"=2C regardless of whether SST or MST transport is in use. =  =3BFor example=2C I noted with approval that the "mst-mode" parameter = from RFC 6190 was not included in this draft.  =3B

>=3B More and more reason to =3Bwrite up a general = layered/simulcast (dare I add multiple description)
>=3B transport arc= hitecture doc.

[BA] Not a bad idea. =3B
<= div>

= --_a48be14d-300e-455d-8bc7-a70fc604b964_-- From yekuiw@qti.qualcomm.com Mon Dec 23 11:51:00 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B381AE28F for ; Mon, 23 Dec 2013 11:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.838 X-Spam-Level: X-Spam-Status: No, score=-4.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hzC1GZFvKYS for ; Mon, 23 Dec 2013 11:50:56 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 476BA1AE289 for ; Mon, 23 Dec 2013 11:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1387828253; x=1419364253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yv4qJ5Yb2sEhq4yHBrW/fi1rZw4+TqY2YKNDQH8i8mQ=; b=nNneMz7esYya0wNrdQ1SP8xft4DYxUCn2sb3hiM0rJhNxFTgtXA3roI8 k4vxGl+lo4zvZPX0ksZcRg9z/7qx0EB7QLWp/u+nLq8zAf66PfTNQ/ZCu f3ot4+o4AiRBgtvksxXYbexbf/j0s3T8jJ+Mml/a4dtqBwqJTD1EUYqvM w=; X-IronPort-AV: E=McAfee;i="5400,1158,7298"; a="3559904" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 23 Dec 2013 11:50:52 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7298"; a="24722306" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Dec 2013 11:50:52 -0800 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.71]) by nasanexhc14.na.qualcomm.com ([172.30.48.23]) with mapi id 14.03.0158.001; Mon, 23 Dec 2013 11:50:51 -0800 From: "Wang, Ye-Kui" To: Bernard Aboba , Stephan Wenger , "draft-ietf-payload-rtp-h265@tools.ietf.org" Thread-Topic: [payload] #6: Section 4.4: SST vs. MST Thread-Index: AQHO9VfOFRzzj83gMEK/LMkZqkx3NZpbLg+AgALCJQCABEvLIA== Date: Mon, 23 Dec 2013 19:50:51 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833871AF1C@nasanexd02f.na.qualcomm.com> References: <067.4adc9845007df5cfa594d162894a517a@trac.tools.ietf.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.230.6] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A833871AF1Cnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] #6: Section 4.4: SST vs. MST X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 19:51:00 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A833871AF1Cnasanexd02fnaqu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to cover the discussions on issue #7 in another thread as well = (these two #6 and #7 are closed related anyway). One thing I am not clear is why there is an IOP issue with SST and MST for = H.265. In RFC 6190 (the SVC payload format), there could be such an issue a= s different sets of payload structures are used for SST and MST therein. Ho= wever, in the H.265 payload draft, SST and MST use the same set of payload = structures. From a full implementation point of view, SST is a subset of MS= T as MST implementation requires more code than SST for handling the differ= ence sources of the RTP streams. However, if purely from de-packetization p= oint of view, they are identical, as can be seen from the unique de-packeti= zation process in Section 6 of the draft. Thus, I think there won't be an I= OP issue even if not both SST and MST are required. On the other hand, I th= ink it actually makes sense to require the support of both SST and MST in t= his payload format due to that they use the same set of payload structures = and the same de-packetization process, also as Bernard correctly said, in a= similar spirit, in the other thread, "Assuming that implementations correc= tly handle DON, we should be most of the way there anyway." Thus, I'd sugge= st that we go ahead to do this, and I will include it into the next version= , unless there are other opinions expressed such that this cannot be consid= ered as a consensus. Another point of Bernard I have thought in a similar way is the following: [BA] In terms of RTP transport (e.g. use of DONL field), the distinction is= really whether you have a single sequence number space (single SSRC) or no= t (multiple SSRC, whether on a single RTP session or not). That much seems= worth clarifying. I was thinking if we specify SST and MST as "Single-Stream Transmission" an= d "Multi-Stream Transmission" instead of "Single-Session Transmission" and = "Multi-Session Transmission", then it would simply applies to whatever mult= iplexing scheme, multiple sessions or within one session, or even mixed. Fr= om de-packetization point of view, there is no difference among all these, = as they all just need to follow the simple, less-than-one-page de-packetzat= ion process specified in Section 6 of the draft. Is "RTP Stream" a correct = term to be used here? I'd admit I am not good at the terms of RTP session, = RTP stream, and so on. If we specify this way, using the correct term (what= ever that is), then the design can work with both pre-BUNDLE-and-SSRC-mux a= ge and post-BUNDLE-and-SSRC-mux age. And we don't have to let this payload = draft have a normative referencing dependency on the BUNDLE draft (and othe= r similar signalling drafts), rather they can be just mentioned as example = mux mechanisms used and included in informative references. Opinions? BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Friday, December 20, 2013 9:39 AM To: Stephan Wenger; draft-ietf-payload-rtp-h265@tools.ietf.org Cc: payload@ietf.org Subject: Re: [payload] #6: Section 4.4: SST vs. MST > In the pre-BUNDLE and SSRC mux age, the distinction made was solid and > consistent. Are we sure that we are already in the post-BUNDLE age, when > it comes to the use of H.265? Could we kick that can down the road? [BA] It is possible (and maybe even advisable) for the H.265 draft to avoid= a dependency on the BUNDLE and the appID drafts. That would imply using = the same SDP facilities as were utilized in the examples of RFC 6184 and 61= 90. But that seems ok. > We could introduce the notion of SSRC multiplexing into the draft. Doing > so has certain risks, the main one being that the amount of documented > implementation experience in this field is limited--certainly for the cas= e > of layered or simulcast codecs and absolutely for H.265 in a layered mode= . > In the interest of full disclosure: we in Vidyo have been doing something > like this ion the transport plane for ages, and we know it works in our > application. However, until just recently we were quite lonely in this > camp. Beyond that, to me, the tricky part is the signaling support. [BA] In terms of RTP transport (e.g. use of DONL field), the distinction is= really whether you have a single sequence number space (single SSRC) or no= t (multiple SSRC, whether on a single RTP session or not). That much seems= worth clarifying. > I personally have no objection to require all receivers to implement both > MST and SST. But note though, that there are still a number of use cases > where full capability exchange is available, and where users are (or > pretend to be) worried about implementation complexity. I=B9m personally > willing to push; let=B9s see what the group thinks. [BA] It seems like a useful goal to ensure that temporal scalability "just = works", regardless of whether SST or MST transport is in use. For example,= I noted with approval that the "mst-mode" parameter from RFC 6190 was not = included in this draft. > More and more reason to write up a general layered/simulcast (dare I add = multiple description) > transport architecture doc. [BA] Not a bad idea. --_000_8BA7D4CEACFFE04BA2D902BF11719A833871AF1Cnasanexd02fnaqu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am trying to cover the = discussions on issue #7 in another thread as well (these two #6 and #7 are = closed related anyway).

 <= /p>

One thing I am not clear = is why there is an IOP issue with SST and MST for H.265. In RFC 6190 (the S= VC payload format), there could be such an issue as different sets of payload structures are used for SST and MST therein. However, in t= he H.265 payload draft, SST and MST use the same set of payload structures.= From a full implementation point of view, SST is a subset of MST as MST im= plementation requires more code than SST for handling the difference sources of the RTP streams. However, = if purely from de-packetization point of view, they are identical, as can b= e seen from the unique de-packetization process in Section 6 of the draft. = Thus, I think there won’t be an IOP issue even if not both SST and MST are required. On the other hand, I = think it actually makes sense to require the support of both SST and MST in= this payload format due to that they use the same set of payload structure= s and the same de-packetization process, also as Bernard correctly said, in a similar spirit, in the other= thread, “Assuming that implementations correctly handle DON, we shou= ld be most of the way there anyway.” Thus, I’d suggest that we go ahead to do this, an= d I will include it into the next version, unless there are other opinions = expressed such that this cannot be considered as a consensus.

 <= /p>

Another point of Bernard = I have thought in a similar way is the following:

[BA] In terms of RTP tra= nsport (e.g. use of DONL field), the distinction is really whether you have= a single sequence number space (single SSRC) or not (multiple SSRC, whether on a single RTP session or not).  That much seems worth= clarifying. 

 <= /p>

I was thinking if we spec= ify SST and MST as “Single-Stream Transmission” and “Mult= i-Stream Transmission” instead of “Single-Session Transmission&= #8221; and “Multi-Session Transmission”, then it would simply applies to whatever multiplexing= scheme, multiple sessions or within one session, or even mixed. From de-pa= cketization point of view, there is no difference among all these, as they = all just need to follow the simple, less-than-one-page de-packetzation process specified in Section 6 of the draft. Is “RTP= Stream” a correct term to be used here? I’d admit I am not goo= d at the terms of RTP session, RTP stream, and so on. If we specify this wa= y, using the correct term (whatever that is), then the design can work with both pre-BUNDLE-and-SSRC-mux age and post-BUNDLE-= and-SSRC-mux age. And we don’t have to let this payload draft have a = normative referencing dependency on the BUNDLE draft (and other similar sig= nalling drafts), rather they can be just mentioned as example mux mechanisms used and included in informative refer= ences. Opinions?

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload = [mailto:payload-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Friday, December 20, 2013 9:39 AM
To: Stephan Wenger; draft-ietf-payload-rtp-h265@tools.ietf.org
Cc: payload@ietf.org
Subject: Re: [payload] #6: Section 4.4: SST vs. MST

 

 > In the pre-BUNDLE and SSRC mux age, the disti= nction made was solid and
> consistent. Are we sure that we are already in the post-BUNDLE age, wh= en
> it comes to the use of H.265? Could we kick that can down the road?

 

[BA] It is possible (and maybe even advisable) for the H= .265 draft to avoid a dependency on the BUNDLE and the appID drafts.  = That would imply using the same SDP facilities as were utilized in the examples of RFC 6184 and 6190. But that seems ok. <= /span>

 

> We could introduce the notion of SSRC multiplexing = into the draft. Doing
> so has certain risks, the main one being that the amount of documented=
> implementation experience in this field is limited--certainly for the = case
> of layered or simulcast codecs and absolutely for H.265 in a layered m= ode.
> In the interest of full disclosure: we in Vidyo have been doing someth= ing
> like this ion the transport plane for ages, and we know it works in ou= r
> application. However, until just recently we were quite lonely in this=
> camp. Beyond that, to me, the tricky part is the signaling support.

 

[BA] In terms of RTP transport (e.g. use of DONL fi= eld), the distinction is really whether you have a single sequence number s= pace (single SSRC) or not (multiple SSRC, whether on a single RTP session or not).  That much seems worth clarifying. 

 

> I personally have no= objection to require all receivers to implement both
> MST and SST. But note though, that there are still a number of use cas= es
> where full capability exchange is available, and where users are (or > pretend to be) worried about implementation complexity. I=B9m personal= ly
> willing to push; let=B9s see what the group thinks.<= /p>

[BA] It seems like a useful goal to ensure that tem= poral scalability "just works", regardless of whether SST or MST = transport is in use.  For example, I noted with approval that the &quo= t;mst-mode" parameter from RFC 6190 was not included in this draft.  <= /span>

 

> More and more reason to write up a general lay= ered/simulcast (dare I add multiple description)
> transport architecture doc.

 

[BA] Not a bad idea. 

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A833871AF1Cnasanexd02fnaqu_-- From bernard_aboba@hotmail.com Mon Dec 23 12:54:36 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602C21AE2BF for ; Mon, 23 Dec 2013 12:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJODLqZPFAqV for ; Mon, 23 Dec 2013 12:54:34 -0800 (PST) Received: from blu0-omc4-s19.blu0.hotmail.com (blu0-omc4-s19.blu0.hotmail.com [65.55.111.158]) by ietfa.amsl.com (Postfix) with ESMTP id BDFA41AE2AC for ; Mon, 23 Dec 2013 12:54:33 -0800 (PST) Received: from BLU404-EAS7 ([65.55.111.137]) by blu0-omc4-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Dec 2013 12:54:30 -0800 X-TMN: [eeNiKTEPofX4HQpHRJA0kNfGnW3D3NPb] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail-8B5C35A2-C903-4D91-88F1-E04FAA5B7D9C" Content-Transfer-Encoding: 7bit References: <067.4adc9845007df5cfa594d162894a517a@trac.tools.ietf.org> <8BA7D4CEACFFE04BA2D902BF11719A833871AF1C@nasanexd02f.na.qualcomm.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A833871AF1C@nasanexd02f.na.qualcomm.com> Date: Mon, 23 Dec 2013 15:54:26 -0500 To: "Wang, Ye-Kui" X-OriginalArrivalTime: 23 Dec 2013 20:54:30.0617 (UTC) FILETIME=[2D03AC90:01CF0021] Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] #6: Section 4.4: SST vs. MST X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 20:54:36 -0000 --Apple-Mail-8B5C35A2-C903-4D91-88F1-E04FAA5B7D9C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB1c2Ugb2YgdGhlIHRlcm1zICJzaW5nbGUgc3RyZWFtIiBhbmQgIm11bHRpcGxlIHN0 cmVhbSIgd291bGQgYmUgYW4gaW1wcm92ZW1lbnQuIEFsc28gYWdyZWUgd2l0aCB5b3VyIG90aGVy IHJlY29tbWVuZGF0aW9ucy4NCg0KPiBPbiBEZWMgMjMsIDIwMTMsIGF0IDI6NTAgUE0sICJXYW5n LCBZZS1LdWkiIDx5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+IA0KPiBJIGFtIHRy eWluZyB0byBjb3ZlciB0aGUgZGlzY3Vzc2lvbnMgb24gaXNzdWUgIzcgaW4gYW5vdGhlciB0aHJl YWQgYXMgd2VsbCAodGhlc2UgdHdvICM2IGFuZCAjNyBhcmUgY2xvc2VkIHJlbGF0ZWQgYW55d2F5 KS4NCj4gIA0KPiBPbmUgdGhpbmcgSSBhbSBub3QgY2xlYXIgaXMgd2h5IHRoZXJlIGlzIGFuIElP UCBpc3N1ZSB3aXRoIFNTVCBhbmQgTVNUIGZvciBILjI2NS4gSW4gUkZDIDYxOTAgKHRoZSBTVkMg cGF5bG9hZCBmb3JtYXQpLCB0aGVyZSBjb3VsZCBiZSBzdWNoIGFuIGlzc3VlIGFzIGRpZmZlcmVu dCBzZXRzIG9mIHBheWxvYWQgc3RydWN0dXJlcyBhcmUgdXNlZCBmb3IgU1NUIGFuZCBNU1QgdGhl cmVpbi4gSG93ZXZlciwgaW4gdGhlIEguMjY1IHBheWxvYWQgZHJhZnQsIFNTVCBhbmQgTVNUIHVz ZSB0aGUgc2FtZSBzZXQgb2YgcGF5bG9hZCBzdHJ1Y3R1cmVzLiBGcm9tIGEgZnVsbCBpbXBsZW1l bnRhdGlvbiBwb2ludCBvZiB2aWV3LCBTU1QgaXMgYSBzdWJzZXQgb2YgTVNUIGFzIE1TVCBpbXBs ZW1lbnRhdGlvbiByZXF1aXJlcyBtb3JlIGNvZGUgdGhhbiBTU1QgZm9yIGhhbmRsaW5nIHRoZSBk aWZmZXJlbmNlIHNvdXJjZXMgb2YgdGhlIFJUUCBzdHJlYW1zLiBIb3dldmVyLCBpZiBwdXJlbHkg ZnJvbSBkZS1wYWNrZXRpemF0aW9uIHBvaW50IG9mIHZpZXcsIHRoZXkgYXJlIGlkZW50aWNhbCwg YXMgY2FuIGJlIHNlZW4gZnJvbSB0aGUgdW5pcXVlIGRlLXBhY2tldGl6YXRpb24gcHJvY2VzcyBp biBTZWN0aW9uIDYgb2YgdGhlIGRyYWZ0LiBUaHVzLCBJIHRoaW5rIHRoZXJlIHdvbuKAmXQgYmUg YW4gSU9QIGlzc3VlIGV2ZW4gaWYgbm90IGJvdGggU1NUIGFuZCBNU1QgYXJlIHJlcXVpcmVkLiBP biB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayBpdCBhY3R1YWxseSBtYWtlcyBzZW5zZSB0byByZXF1 aXJlIHRoZSBzdXBwb3J0IG9mIGJvdGggU1NUIGFuZCBNU1QgaW4gdGhpcyBwYXlsb2FkIGZvcm1h dCBkdWUgdG8gdGhhdCB0aGV5IHVzZSB0aGUgc2FtZSBzZXQgb2YgcGF5bG9hZCBzdHJ1Y3R1cmVz IGFuZCB0aGUgc2FtZSBkZS1wYWNrZXRpemF0aW9uIHByb2Nlc3MsIGFsc28gYXMgQmVybmFyZCBj b3JyZWN0bHkgc2FpZCwgaW4gYSBzaW1pbGFyIHNwaXJpdCwgaW4gdGhlIG90aGVyIHRocmVhZCwg 4oCcQXNzdW1pbmcgdGhhdCBpbXBsZW1lbnRhdGlvbnMgY29ycmVjdGx5IGhhbmRsZSBET04sIHdl IHNob3VsZCBiZSBtb3N0IG9mIHRoZSB3YXkgdGhlcmUgYW55d2F5LuKAnSBUaHVzLCBJ4oCZZCBz dWdnZXN0IHRoYXQgd2UgZ28gYWhlYWQgdG8gZG8gdGhpcywgYW5kIEkgd2lsbCBpbmNsdWRlIGl0 IGludG8gdGhlIG5leHQgdmVyc2lvbiwgdW5sZXNzIHRoZXJlIGFyZSBvdGhlciBvcGluaW9ucyBl eHByZXNzZWQgc3VjaCB0aGF0IHRoaXMgY2Fubm90IGJlIGNvbnNpZGVyZWQgYXMgYSBjb25zZW5z dXMuDQo+ICANCj4gQW5vdGhlciBwb2ludCBvZiBCZXJuYXJkIEkgaGF2ZSB0aG91Z2h0IGluIGEg c2ltaWxhciB3YXkgaXMgdGhlIGZvbGxvd2luZzoNCj4gW0JBXSBJbiB0ZXJtcyBvZiBSVFAgdHJh bnNwb3J0IChlLmcuIHVzZSBvZiBET05MIGZpZWxkKSwgdGhlIGRpc3RpbmN0aW9uIGlzIHJlYWxs eSB3aGV0aGVyIHlvdSBoYXZlIGEgc2luZ2xlIHNlcXVlbmNlIG51bWJlciBzcGFjZSAoc2luZ2xl IFNTUkMpIG9yIG5vdCAobXVsdGlwbGUgU1NSQywgd2hldGhlciBvbiBhIHNpbmdsZSBSVFAgc2Vz c2lvbiBvciBub3QpLiAgVGhhdCBtdWNoIHNlZW1zIHdvcnRoIGNsYXJpZnlpbmcuIA0KPiAgDQo+ IEkgd2FzIHRoaW5raW5nIGlmIHdlIHNwZWNpZnkgU1NUIGFuZCBNU1QgYXMg4oCcU2luZ2xlLVN0 cmVhbSBUcmFuc21pc3Npb27igJ0gYW5kIOKAnE11bHRpLVN0cmVhbSBUcmFuc21pc3Npb27igJ0g aW5zdGVhZCBvZiDigJxTaW5nbGUtU2Vzc2lvbiBUcmFuc21pc3Npb27igJ0gYW5kIOKAnE11bHRp LVNlc3Npb24gVHJhbnNtaXNzaW9u4oCdLCB0aGVuIGl0IHdvdWxkIHNpbXBseSBhcHBsaWVzIHRv IHdoYXRldmVyIG11bHRpcGxleGluZyBzY2hlbWUsIG11bHRpcGxlIHNlc3Npb25zIG9yIHdpdGhp biBvbmUgc2Vzc2lvbiwgb3IgZXZlbiBtaXhlZC4gRnJvbSBkZS1wYWNrZXRpemF0aW9uIHBvaW50 IG9mIHZpZXcsIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYW1vbmcgYWxsIHRoZXNlLCBhcyB0aGV5 IGFsbCBqdXN0IG5lZWQgdG8gZm9sbG93IHRoZSBzaW1wbGUsIGxlc3MtdGhhbi1vbmUtcGFnZSBk ZS1wYWNrZXR6YXRpb24gcHJvY2VzcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA2IG9mIHRoZSBkcmFm dC4gSXMg4oCcUlRQIFN0cmVhbeKAnSBhIGNvcnJlY3QgdGVybSB0byBiZSB1c2VkIGhlcmU/IEni gJlkIGFkbWl0IEkgYW0gbm90IGdvb2QgYXQgdGhlIHRlcm1zIG9mIFJUUCBzZXNzaW9uLCBSVFAg c3RyZWFtLCBhbmQgc28gb24uIElmIHdlIHNwZWNpZnkgdGhpcyB3YXksIHVzaW5nIHRoZSBjb3Jy ZWN0IHRlcm0gKHdoYXRldmVyIHRoYXQgaXMpLCB0aGVuIHRoZSBkZXNpZ24gY2FuIHdvcmsgd2l0 aCBib3RoIHByZS1CVU5ETEUtYW5kLVNTUkMtbXV4IGFnZSBhbmQgcG9zdC1CVU5ETEUtYW5kLVNT UkMtbXV4IGFnZS4gQW5kIHdlIGRvbuKAmXQgaGF2ZSB0byBsZXQgdGhpcyBwYXlsb2FkIGRyYWZ0 IGhhdmUgYSBub3JtYXRpdmUgcmVmZXJlbmNpbmcgZGVwZW5kZW5jeSBvbiB0aGUgQlVORExFIGRy YWZ0IChhbmQgb3RoZXIgc2ltaWxhciBzaWduYWxsaW5nIGRyYWZ0cyksIHJhdGhlciB0aGV5IGNh biBiZSBqdXN0IG1lbnRpb25lZCBhcyBleGFtcGxlIG11eCBtZWNoYW5pc21zIHVzZWQgYW5kIGlu Y2x1ZGVkIGluIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMuIE9waW5pb25zPw0KPiAgDQo+IEJSLCBZ Sw0KPiAgDQo+IEZyb206IHBheWxvYWQgW21haWx0bzpwYXlsb2FkLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCZXJuYXJkIEFib2JhDQo+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMjAs IDIwMTMgOTozOSBBTQ0KPiBUbzogU3RlcGhhbiBXZW5nZXI7IGRyYWZ0LWlldGYtcGF5bG9hZC1y dHAtaDI2NUB0b29scy5pZXRmLm9yZw0KPiBDYzogcGF5bG9hZEBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW3BheWxvYWRdICM2OiBTZWN0aW9uIDQuNDogU1NUIHZzLiBNU1QNCj4gIA0KPiAgPiBJ biB0aGUgcHJlLUJVTkRMRSBhbmQgU1NSQyBtdXggYWdlLCB0aGUgZGlzdGluY3Rpb24gbWFkZSB3 YXMgc29saWQgYW5kDQo+ID4gY29uc2lzdGVudC4gQXJlIHdlIHN1cmUgdGhhdCB3ZSBhcmUgYWxy ZWFkeSBpbiB0aGUgcG9zdC1CVU5ETEUgYWdlLCB3aGVuDQo+ID4gaXQgY29tZXMgdG8gdGhlIHVz ZSBvZiBILjI2NT8gQ291bGQgd2Uga2ljayB0aGF0IGNhbiBkb3duIHRoZSByb2FkPw0KPiAgDQo+ IFtCQV0gSXQgaXMgcG9zc2libGUgKGFuZCBtYXliZSBldmVuIGFkdmlzYWJsZSkgZm9yIHRoZSBI LjI2NSBkcmFmdCB0byBhdm9pZCBhIGRlcGVuZGVuY3kgb24gdGhlIEJVTkRMRSBhbmQgdGhlIGFw cElEIGRyYWZ0cy4gICBUaGF0IHdvdWxkIGltcGx5IHVzaW5nIHRoZSBzYW1lIFNEUCBmYWNpbGl0 aWVzIGFzIHdlcmUgdXRpbGl6ZWQgaW4gdGhlIGV4YW1wbGVzIG9mIFJGQyA2MTg0IGFuZCA2MTkw LiBCdXQgdGhhdCBzZWVtcyBvay4gDQo+ICANCj4gPiBXZSBjb3VsZCBpbnRyb2R1Y2UgdGhlIG5v dGlvbiBvZiBTU1JDIG11bHRpcGxleGluZyBpbnRvIHRoZSBkcmFmdC4gRG9pbmcNCj4gPiBzbyBo YXMgY2VydGFpbiByaXNrcywgdGhlIG1haW4gb25lIGJlaW5nIHRoYXQgdGhlIGFtb3VudCBvZiBk b2N1bWVudGVkDQo+ID4gaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBpbiB0aGlzIGZpZWxkIGlz IGxpbWl0ZWQtLWNlcnRhaW5seSBmb3IgdGhlIGNhc2UNCj4gPiBvZiBsYXllcmVkIG9yIHNpbXVs Y2FzdCBjb2RlY3MgYW5kIGFic29sdXRlbHkgZm9yIEguMjY1IGluIGEgbGF5ZXJlZCBtb2RlLg0K PiA+IEluIHRoZSBpbnRlcmVzdCBvZiBmdWxsIGRpc2Nsb3N1cmU6IHdlIGluIFZpZHlvIGhhdmUg YmVlbiBkb2luZyBzb21ldGhpbmcNCj4gPiBsaWtlIHRoaXMgaW9uIHRoZSB0cmFuc3BvcnQgcGxh bmUgZm9yIGFnZXMsIGFuZCB3ZSBrbm93IGl0IHdvcmtzIGluIG91cg0KPiA+IGFwcGxpY2F0aW9u LiBIb3dldmVyLCB1bnRpbCBqdXN0IHJlY2VudGx5IHdlIHdlcmUgcXVpdGUgbG9uZWx5IGluIHRo aXMNCj4gPiBjYW1wLiBCZXlvbmQgdGhhdCwgdG8gbWUsIHRoZSB0cmlja3kgcGFydCBpcyB0aGUg c2lnbmFsaW5nIHN1cHBvcnQuDQo+ICANCj4gW0JBXSBJbiB0ZXJtcyBvZiBSVFAgdHJhbnNwb3J0 IChlLmcuIHVzZSBvZiBET05MIGZpZWxkKSwgdGhlIGRpc3RpbmN0aW9uIGlzIHJlYWxseSB3aGV0 aGVyIHlvdSBoYXZlIGEgc2luZ2xlIHNlcXVlbmNlIG51bWJlciBzcGFjZSAoc2luZ2xlIFNTUkMp IG9yIG5vdCAobXVsdGlwbGUgU1NSQywgd2hldGhlciBvbiBhIHNpbmdsZSBSVFAgc2Vzc2lvbiBv ciBub3QpLiAgVGhhdCBtdWNoIHNlZW1zIHdvcnRoIGNsYXJpZnlpbmcuIA0KPiAgDQo+ID4gSSBw ZXJzb25hbGx5IGhhdmUgbm8gb2JqZWN0aW9uIHRvIHJlcXVpcmUgYWxsIHJlY2VpdmVycyB0byBp bXBsZW1lbnQgYm90aA0KPiA+IE1TVCBhbmQgU1NULiBCdXQgbm90ZSB0aG91Z2gsIHRoYXQgdGhl cmUgYXJlIHN0aWxsIGEgbnVtYmVyIG9mIHVzZSBjYXNlcw0KPiA+IHdoZXJlIGZ1bGwgY2FwYWJp bGl0eSBleGNoYW5nZSBpcyBhdmFpbGFibGUsIGFuZCB3aGVyZSB1c2VycyBhcmUgKG9yDQo+ID4g cHJldGVuZCB0byBiZSkgd29ycmllZCBhYm91dCBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LiBJ wrltIHBlcnNvbmFsbHkNCj4gPiB3aWxsaW5nIHRvIHB1c2g7IGxldMK5cyBzZWUgd2hhdCB0aGUg Z3JvdXAgdGhpbmtzLg0KPiANCj4gW0JBXSBJdCBzZWVtcyBsaWtlIGEgdXNlZnVsIGdvYWwgdG8g ZW5zdXJlIHRoYXQgdGVtcG9yYWwgc2NhbGFiaWxpdHkgImp1c3Qgd29ya3MiLCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgU1NUIG9yIE1TVCB0cmFuc3BvcnQgaXMgaW4gdXNlLiAgRm9yIGV4YW1wbGUs IEkgbm90ZWQgd2l0aCBhcHByb3ZhbCB0aGF0IHRoZSAibXN0LW1vZGUiIHBhcmFtZXRlciBmcm9t IFJGQyA2MTkwIHdhcyBub3QgaW5jbHVkZWQgaW4gdGhpcyBkcmFmdC4gIA0KPiAgDQo+ID4gTW9y ZSBhbmQgbW9yZSByZWFzb24gdG8gd3JpdGUgdXAgYSBnZW5lcmFsIGxheWVyZWQvc2ltdWxjYXN0 IChkYXJlIEkgYWRkIG11bHRpcGxlIGRlc2NyaXB0aW9uKQ0KPiA+IHRyYW5zcG9ydCBhcmNoaXRl Y3R1cmUgZG9jLg0KPiAgDQo+IFtCQV0gTm90IGEgYmFkIGlkZWEuIA0KPiAgDQo+ICANCg== --Apple-Mail-8B5C35A2-C903-4D91-88F1-E04FAA5B7D9C Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SSB0aGlu ayB1c2Ugb2YgdGhlIHRlcm1zICJzaW5nbGUgc3RyZWFtIiBhbmQgIm11bHRpcGxlIHN0cmVhbSIg d291bGQgYmUgYW4gaW1wcm92ZW1lbnQuIEFsc28gYWdyZWUgd2l0aCB5b3VyIG90aGVyIHJlY29t bWVuZGF0aW9ucy48L2Rpdj48ZGl2Pjxicj5PbiBEZWMgMjMsIDIwMTMsIGF0IDI6NTAgUE0sICJX YW5nLCBZZS1LdWkiICZsdDs8YSBocmVmPSJtYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb20i Pnlla3Vpd0BxdGkucXVhbGNvbW0uY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KDQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5 cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCjxtZXRhIG5hbWU9 IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSki Pg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KDQoNCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSB0cnlpbmcgdG8gY292ZXIgdGhl IGRpc2N1c3Npb25zIG9uIGlzc3VlICM3IGluIGFub3RoZXIgdGhyZWFkIGFzIHdlbGwgKHRoZXNl IHR3byAjNiBhbmQgIzcgYXJlIGNsb3NlZCByZWxhdGVkIGFueXdheSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PbmUg dGhpbmcgSSBhbSBub3QgY2xlYXIgaXMgd2h5IHRoZXJlIGlzIGFuIElPUCBpc3N1ZSB3aXRoIFNT VCBhbmQgTVNUIGZvciBILjI2NS4gSW4gUkZDIDYxOTAgKHRoZSBTVkMgcGF5bG9hZCBmb3JtYXQp LCB0aGVyZSBjb3VsZCBiZSBzdWNoIGFuIGlzc3VlIGFzIGRpZmZlcmVudA0KIHNldHMgb2YgcGF5 bG9hZCBzdHJ1Y3R1cmVzIGFyZSB1c2VkIGZvciBTU1QgYW5kIE1TVCB0aGVyZWluLiBIb3dldmVy LCBpbiB0aGUgSC4yNjUgcGF5bG9hZCBkcmFmdCwgU1NUIGFuZCBNU1QgdXNlIHRoZSBzYW1lIHNl dCBvZiBwYXlsb2FkIHN0cnVjdHVyZXMuIEZyb20gYSBmdWxsIGltcGxlbWVudGF0aW9uIHBvaW50 IG9mIHZpZXcsIFNTVCBpcyBhIHN1YnNldCBvZiBNU1QgYXMgTVNUIGltcGxlbWVudGF0aW9uIHJl cXVpcmVzIG1vcmUgY29kZQ0KIHRoYW4gU1NUIGZvciBoYW5kbGluZyB0aGUgZGlmZmVyZW5jZSBz b3VyY2VzIG9mIHRoZSBSVFAgc3RyZWFtcy4gSG93ZXZlciwgaWYgcHVyZWx5IGZyb20gZGUtcGFj a2V0aXphdGlvbiBwb2ludCBvZiB2aWV3LCB0aGV5IGFyZSBpZGVudGljYWwsIGFzIGNhbiBiZSBz ZWVuIGZyb20gdGhlIHVuaXF1ZSBkZS1wYWNrZXRpemF0aW9uIHByb2Nlc3MgaW4gU2VjdGlvbiA2 IG9mIHRoZSBkcmFmdC4gVGh1cywgSSB0aGluayB0aGVyZSB3b27igJl0IGJlIGFuDQogSU9QIGlz c3VlIGV2ZW4gaWYgbm90IGJvdGggU1NUIGFuZCBNU1QgYXJlIHJlcXVpcmVkLiBPbiB0aGUgb3Ro ZXIgaGFuZCwgSSB0aGluayBpdCBhY3R1YWxseSBtYWtlcyBzZW5zZSB0byByZXF1aXJlIHRoZSBz dXBwb3J0IG9mIGJvdGggU1NUIGFuZCBNU1QgaW4gdGhpcyBwYXlsb2FkIGZvcm1hdCBkdWUgdG8g dGhhdCB0aGV5IHVzZSB0aGUgc2FtZSBzZXQgb2YgcGF5bG9hZCBzdHJ1Y3R1cmVzIGFuZCB0aGUg c2FtZSBkZS1wYWNrZXRpemF0aW9uDQogcHJvY2VzcywgYWxzbyBhcyBCZXJuYXJkIGNvcnJlY3Rs eSBzYWlkLCBpbiBhIHNpbWlsYXIgc3Bpcml0LCBpbiB0aGUgb3RoZXIgdGhyZWFkLCDigJxBc3N1 bWluZyB0aGF0IGltcGxlbWVudGF0aW9ucyBjb3JyZWN0bHkgaGFuZGxlIERPTiwgd2Ugc2hvdWxk IGJlIG1vc3Qgb2YgdGhlIHdheSB0aGVyZSBhbnl3YXku4oCdDQo8L3NwYW4+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaHVzLCBJ4oCZZCBzdWdnZXN0IHRoYXQgd2UgZ28gYWhlYWQgdG8g ZG8gdGhpcywgYW5kIEkgd2lsbCBpbmNsdWRlIGl0IGludG8gdGhlIG5leHQgdmVyc2lvbiwgdW5s ZXNzIHRoZXJlIGFyZSBvdGhlciBvcGluaW9ucyBleHByZXNzZWQgc3VjaCB0aGF0IHRoaXMgY2Fu bm90IGJlIGNvbnNpZGVyZWQgYXMgYSBjb25zZW5zdXMuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bbm90aGVyIHBvaW50IG9m IEJlcm5hcmQgSSBoYXZlIHRob3VnaHQgaW4gYSBzaW1pbGFyIHdheSBpcyB0aGUgZm9sbG93aW5n OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5bQkFdIEluJm5ic3A7dGVybXMgb2YgUlRQIHRyYW5z cG9ydCAoZS5nLiB1c2Ugb2YgRE9OTCBmaWVsZCksIHRoZSBkaXN0aW5jdGlvbiBpcyByZWFsbHkg d2hldGhlciB5b3UgaGF2ZSBhIHNpbmdsZSBzZXF1ZW5jZSBudW1iZXIgc3BhY2UgKHNpbmdsZSBT U1JDKSBvciBub3QgKG11bHRpcGxlDQogU1NSQywgd2hldGhlciBvbiBhIHNpbmdsZSBSVFAgc2Vz c2lvbiBvciBub3QpLiAmbmJzcDtUaGF0IG11Y2ggc2VlbXMgd29ydGggY2xhcmlmeWluZy4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgd2FzIHRoaW5raW5nIGlmIHdlIHNwZWNpZnkgU1NUIGFuZCBNU1QgYXMg 4oCcU2luZ2xlLVN0cmVhbSBUcmFuc21pc3Npb27igJ0gYW5kIOKAnE11bHRpLVN0cmVhbSBUcmFu c21pc3Npb27igJ0gaW5zdGVhZCBvZiDigJxTaW5nbGUtU2Vzc2lvbiBUcmFuc21pc3Npb27igJ0g YW5kIOKAnE11bHRpLVNlc3Npb24NCiBUcmFuc21pc3Npb27igJ0sIHRoZW4gaXQgd291bGQgc2lt cGx5IGFwcGxpZXMgdG8gd2hhdGV2ZXIgbXVsdGlwbGV4aW5nIHNjaGVtZSwgbXVsdGlwbGUgc2Vz c2lvbnMgb3Igd2l0aGluIG9uZSBzZXNzaW9uLCBvciBldmVuIG1peGVkLiBGcm9tIGRlLXBhY2tl dGl6YXRpb24gcG9pbnQgb2YgdmlldywgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBhbW9uZyBhbGwg dGhlc2UsIGFzIHRoZXkgYWxsIGp1c3QgbmVlZCB0byBmb2xsb3cgdGhlIHNpbXBsZSwgbGVzcy10 aGFuLW9uZS1wYWdlDQogZGUtcGFja2V0emF0aW9uIHByb2Nlc3Mgc3BlY2lmaWVkIGluIFNlY3Rp b24gNiBvZiB0aGUgZHJhZnQuIElzIOKAnFJUUCBTdHJlYW3igJ0gYSBjb3JyZWN0IHRlcm0gdG8g YmUgdXNlZCBoZXJlPyBJ4oCZZCBhZG1pdCBJIGFtIG5vdCBnb29kIGF0IHRoZSB0ZXJtcyBvZiBS VFAgc2Vzc2lvbiwgUlRQIHN0cmVhbSwgYW5kIHNvIG9uLiBJZiB3ZSBzcGVjaWZ5IHRoaXMgd2F5 LCB1c2luZyB0aGUgY29ycmVjdCB0ZXJtICh3aGF0ZXZlciB0aGF0IGlzKSwgdGhlbg0KIHRoZSBk ZXNpZ24gY2FuIHdvcmsgd2l0aCBib3RoIHByZS1CVU5ETEUtYW5kLVNTUkMtbXV4IGFnZSBhbmQg cG9zdC1CVU5ETEUtYW5kLVNTUkMtbXV4IGFnZS4gQW5kIHdlIGRvbuKAmXQgaGF2ZSB0byBsZXQg dGhpcyBwYXlsb2FkIGRyYWZ0IGhhdmUgYSBub3JtYXRpdmUgcmVmZXJlbmNpbmcgZGVwZW5kZW5j eSBvbiB0aGUgQlVORExFIGRyYWZ0IChhbmQgb3RoZXIgc2ltaWxhciBzaWduYWxsaW5nIGRyYWZ0 cyksIHJhdGhlciB0aGV5IGNhbiBiZSBqdXN0DQogbWVudGlvbmVkIGFzIGV4YW1wbGUgbXV4IG1l Y2hhbmlzbXMgdXNlZCBhbmQgaW5jbHVkZWQgaW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlcy4gT3Bp bmlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CUiwgWUs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBwYXlsb2FkIFs8YSBo cmVmPSJtYWlsdG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cGF5bG9hZC1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVybmFyZCBBYm9iYTxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDIwLCAyMDEzIDk6MzkgQU08YnI+DQo8Yj5U bzo8L2I+IFN0ZXBoYW4gV2VuZ2VyOyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1wYXlsb2Fk LXJ0cC1oMjY1QHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXBheWxvYWQtcnRwLWgyNjVAdG9v bHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBp ZXRmLm9yZyI+cGF5bG9hZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtw YXlsb2FkXSAjNjogU2VjdGlvbiA0LjQ6IFNTVCB2cy4gTVNUPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDsmZ3Q7IEluIHRoZSBwcmUtQlVORExFIGFuZCBTU1JDIG11eCBhZ2UsIHRoZSBkaXN0aW5jdGlv biBtYWRlIHdhcyBzb2xpZCBhbmQ8YnI+DQomZ3Q7IGNvbnNpc3RlbnQuIEFyZSB3ZSBzdXJlIHRo YXQgd2UgYXJlIGFscmVhZHkgaW4gdGhlIHBvc3QtQlVORExFIGFnZSwgd2hlbjxicj4NCiZndDsg aXQgY29tZXMgdG8gdGhlIHVzZSBvZiBILjI2NT8gQ291bGQgd2Uga2ljayB0aGF0IGNhbiBkb3du IHRoZSByb2FkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gSXQgaXMg cG9zc2libGUgKGFuZCBtYXliZSBldmVuIGFkdmlzYWJsZSkgZm9yIHRoZSBILjI2NSBkcmFmdCB0 byBhdm9pZCBhIGRlcGVuZGVuY3kgb24gdGhlIEJVTkRMRSBhbmQgdGhlIGFwcElEIGRyYWZ0cy4g Jm5ic3A7IFRoYXQgd291bGQgaW1wbHkgdXNpbmcgdGhlIHNhbWUgU0RQIGZhY2lsaXRpZXMgYXMg d2VyZSB1dGlsaXplZA0KIGluIHRoZSBleGFtcGxlcyBvZiBSRkMgNjE4NCBhbmQgNjE5MC4gQnV0 IHRoYXQgc2VlbXMgb2suJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmd0OyBXZSBjb3VsZCBpbnRyb2R1Y2UgdGhlIG5vdGlvbiBvZiBTU1JDIG11bHRpcGxleGluZyBp bnRvIHRoZSBkcmFmdC4gRG9pbmc8YnI+DQomZ3Q7IHNvIGhhcyBjZXJ0YWluIHJpc2tzLCB0aGUg bWFpbiBvbmUgYmVpbmcgdGhhdCB0aGUgYW1vdW50IG9mIGRvY3VtZW50ZWQ8YnI+DQomZ3Q7IGlt cGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgaW4gdGhpcyBmaWVsZCBpcyBsaW1pdGVkLS1jZXJ0YWlu bHkgZm9yIHRoZSBjYXNlPGJyPg0KJmd0OyBvZiBsYXllcmVkIG9yIHNpbXVsY2FzdCBjb2RlY3Mg YW5kIGFic29sdXRlbHkgZm9yIEguMjY1IGluIGEgbGF5ZXJlZCBtb2RlLjxicj4NCiZndDsgSW4g dGhlIGludGVyZXN0IG9mIGZ1bGwgZGlzY2xvc3VyZTogd2UgaW4gVmlkeW8gaGF2ZSBiZWVuIGRv aW5nIHNvbWV0aGluZzxicj4NCiZndDsgbGlrZSB0aGlzIGlvbiB0aGUgdHJhbnNwb3J0IHBsYW5l IGZvciBhZ2VzLCBhbmQgd2Uga25vdyBpdCB3b3JrcyBpbiBvdXI8YnI+DQomZ3Q7IGFwcGxpY2F0 aW9uLiBIb3dldmVyLCB1bnRpbCBqdXN0IHJlY2VudGx5IHdlIHdlcmUgcXVpdGUgbG9uZWx5IGlu IHRoaXM8YnI+DQomZ3Q7IGNhbXAuIEJleW9uZCB0aGF0LCB0byBtZSwgdGhlIHRyaWNreSBwYXJ0 IGlzIHRoZSBzaWduYWxpbmcgc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5bQkFdIEluJm5ic3A7dGVybXMgb2YgUlRQIHRyYW5zcG9ydCAoZS5nLiB1c2Ugb2YgRE9O TCBmaWVsZCksIHRoZSBkaXN0aW5jdGlvbiBpcyByZWFsbHkgd2hldGhlciB5b3UgaGF2ZSBhIHNp bmdsZSBzZXF1ZW5jZSBudW1iZXIgc3BhY2UgKHNpbmdsZSBTU1JDKSBvciBub3QgKG11bHRpcGxl IFNTUkMsIHdoZXRoZXIgb24gYSBzaW5nbGUNCiBSVFAgc2Vzc2lvbiBvciBub3QpLiAmbmJzcDtU aGF0IG11Y2ggc2VlbXMgd29ydGggY2xhcmlmeWluZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 IEkgcGVyc29uYWxseSBoYXZlIG5vIG9iamVjdGlvbiB0byByZXF1aXJlIGFsbCByZWNlaXZlcnMg dG8gaW1wbGVtZW50IGJvdGg8YnI+DQomZ3Q7IE1TVCBhbmQgU1NULiBCdXQgbm90ZSB0aG91Z2gs IHRoYXQgdGhlcmUgYXJlIHN0aWxsIGEgbnVtYmVyIG9mIHVzZSBjYXNlczxicj4NCiZndDsgd2hl cmUgZnVsbCBjYXBhYmlsaXR5IGV4Y2hhbmdlIGlzIGF2YWlsYWJsZSwgYW5kIHdoZXJlIHVzZXJz IGFyZSAob3I8YnI+DQomZ3Q7IHByZXRlbmQgdG8gYmUpIHdvcnJpZWQgYWJvdXQgaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eS4gScK5bSBwZXJzb25hbGx5PGJyPg0KJmd0OyB3aWxsaW5nIHRvIHB1 c2g7IGxldMK5cyBzZWUgd2hhdCB0aGUgZ3JvdXAgdGhpbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0g SXQgc2VlbXMgbGlrZSBhIHVzZWZ1bCBnb2FsIHRvIGVuc3VyZSB0aGF0Jm5ic3A7dGVtcG9yYWwg c2NhbGFiaWxpdHkgImp1c3Qgd29ya3MiLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgU1NUIG9yIE1T VCB0cmFuc3BvcnQgaXMgaW4gdXNlLiAmbmJzcDtGb3IgZXhhbXBsZSwgSSBub3RlZCB3aXRoIGFw cHJvdmFsIHRoYXQgdGhlICJtc3QtbW9kZSINCiBwYXJhbWV0ZXIgZnJvbSBSRkMgNjE5MCB3YXMg bm90IGluY2x1ZGVkIGluIHRoaXMgZHJhZnQuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBNb3JlIGFuZCBtb3JlIHJlYXNvbiB0byZuYnNwO3dy aXRlIHVwIGEgZ2VuZXJhbCBsYXllcmVkL3NpbXVsY2FzdCAoZGFyZSBJIGFkZCBtdWx0aXBsZSBk ZXNjcmlwdGlvbik8YnI+DQomZ3Q7IHRyYW5zcG9ydCBhcmNoaXRlY3R1cmUgZG9jLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPltCQV0gTm90IGEgYmFkIGlkZWEuJm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48L2Jv ZHk+PC9odG1sPg== --Apple-Mail-8B5C35A2-C903-4D91-88F1-E04FAA5B7D9C-- From trac+payload@trac.tools.ietf.org Fri Dec 27 14:40:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2E1AE7CE for ; Fri, 27 Dec 2013 14:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rr_T3vYzcha for ; Fri, 27 Dec 2013 14:40:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 659A91AE7CD for ; Fri, 27 Dec 2013 14:40:25 -0800 (PST) Received: from localhost ([127.0.0.1]:49915 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vwg4b-0000ad-LY; Fri, 27 Dec 2013 23:40:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "payload issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: payload Date: Fri, 27 Dec 2013 22:40:05 -0000 X-URL: http://tools.ietf.org/payload/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/payload/trac/ticket/8 Message-ID: <067.cadd8191e90ae283c51a09388559dc18@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-h265@tools.ietf.org, bernard_aboba@hotmail.com, payload@ietf.org X-SA-Exim-Mail-From: trac+payload@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: miska.hannuksela@nokia.com, stewe@stewe.org, ts@thomas-schierl.de, yago.sanchez@hhi.fraunhofer.de, yekuiw@qti.qualcomm.com Cc: payload@ietf.org Subject: [payload] #8: tx-mode: do we need this? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 22:40:27 -0000 #8: tx-mode: do we need this? Section 4.4 The transmission mode is indicated by the tx-mode media parameter (see section 7.1). If tx-mode is equal to "SST", SST MUST be used. Otherwise (tx-mode is equal to "MST"), MST MUST be used. Section 7.1 tx-mode: This parameter indicates whether the transmission mode is SST or MST. The value of tx-mode MUST be equal to either "MST" or "SST". When not present, the value of tx-mode is inferred to be equal to "SST". If the value is equal to "MST", MST MUST be in use. Otherwise (the value is equal to "SST"), SST MUST be in use. The value of tx-mode MUST be equal to "MST" for all RTP sessions in an MST. [BA] Is the tx-mode parameter needed? If we negotiate transport parameters in SDP (including potentially SSRCs, recv-appId and appId) and require the receiver to be able to handle either MST or SST (perhaps with some limits communicated), then the decision on whether to use MST or SST can be left to the sender. In such a situation, SDP need not include a "tx-mode" parameter, except perhaps as a preference that could be ignored, in which case the "MUST" language would not make sense. Note that I'm still assuming that O/A could utilize RFC 5583 to describe dependencies in MST (and utilize other parameters to describe SST settings). -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-payload- bernard_aboba@hotmail.com | rtp-h265@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-h265 | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: payload