From wwwrun@rfc-editor.org Tue May 3 17:20:11 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680BEE0618; Tue, 3 May 2011 17:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.935 X-Spam-Level: X-Spam-Status: No, score=-101.935 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S45ulCu-54vP; Tue, 3 May 2011 17:20:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD90E079C; Tue, 3 May 2011 17:20:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5036AE0780; Tue, 3 May 2011 17:20:10 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110504002010.5036AE0780@rfc-editor.org> Date: Tue, 3 May 2011 17:20:10 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6184 on RTP Payload Format for H.264 Video X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 00:20:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6184 Title: RTP Payload Format for H.264 Video Author: Y.-K. Wang, R. Even, T. Kristensen, R. Jesup Status: Standards Track Stream: IETF Date: May 2011 Mailbox: yekuiwang@huawei.com, even.roni@huawei.com, tom.kristensen@tandberg.com, rjesup@wgate.com Pages: 101 Characters: 250627 Obsoletes: RFC3984 I-D Tag: draft-ietf-avt-rtp-rfc3984bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc6184.txt This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Thu May 5 02:31:11 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4185E0722; Thu, 5 May 2011 02:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+e6wZbtI+Kw; Thu, 5 May 2011 02:31:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B24BE068B; Thu, 5 May 2011 02:31:11 -0700 (PDT) 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: 3.53 Message-ID: <20110505093111.13304.74145.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 02:31:11 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:31:11 -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 Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architectures for RTP Author(s) : Qin Wu Filename : draft-ietf-avtcore-monarch-01.txt Pages : 23 Date : 2011-05-05 This memo proposes an architecture for extending RTCP with a new RTCP XR (RFC3611) block type to report new metrics regarding media transmission or reception quality, as proposed in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt From sunseawq@huawei.com Thu May 5 02:44:21 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4876E0707 for ; Thu, 5 May 2011 02:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.031 X-Spam-Level: X-Spam-Status: No, score=-4.031 tagged_above=-999 required=5 tests=[AWL=1.683, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5q9N2c7d-H4 for ; Thu, 5 May 2011 02:44:20 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 11F6DE06E2 for ; Thu, 5 May 2011 02:44:19 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKP00IXIV0XY0@szxga04-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 17:43:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKP00MFQV0XIY@szxga04-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 17:43:45 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKP007PTV0X4L@szxml06-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 17:43:45 +0800 (CST) Date: Thu, 05 May 2011 17:47:16 +0800 From: Qin Wu To: avt@ietf.org Message-id: <02f601cc0b09$6b6dc930$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_QHb4HDTrYfO95Vv6J8Q6RA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [AVTCORE] New version of draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:44:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_QHb4HDTrYfO95Vv6J8Q6RA) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, folks: Following comments received in the last IETF meeting, we have updated draft-ietf-avtcore-monarch to version 01. The new version is available at: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-01 Your comments are welcome! Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Thursday, May 05, 2011 5:31 PM Subject: I-D Action: draft-ietf-avtcore-monarch-01.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Monitoring Architectures for RTP > Author(s) : Qin Wu > Filename : draft-ietf-avtcore-monarch-01.txt > Pages : 23 > Date : 2011-05-05 > > This memo proposes an architecture for extending RTCP with a new RTCP > XR (RFC3611) block type to report new metrics regarding media > transmission or reception quality, as proposed in RFC5968. This memo > suggests that a new block should contain a single metric or a small > number of metrics relevant to a single parameter of interest or > concern, rather than containing a number of metrics which attempt to > provide full coverage of all those parameters of concern to a > specific application. Applications may then "mix and match" to > create a set of blocks which covers their set of concerns. Where > possible, a specific block should be designed to be re-usable across > more than one application, for example, for all of voice, streaming > audio and video. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt > _______________________________________________ > 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 --Boundary_(ID_QHb4HDTrYfO95Vv6J8Q6RA) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Hi, folks:
Following comments received in the last IETF meeting, we have updated draft-ietf-avtcore-monarch to version 01. The
new version is available at:
Your comments are welcome!
 
Regards!
-Qin
----- Original Message -----
Sent: Thursday, May 05, 2011 5:31 PM
Subject: I-D Action: draft-ietf-avtcore-monarch-01.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.
>
> Title           : Monitoring Architectures for RTP
> Author(s)       : Qin Wu
> Filename        : draft-ietf-avtcore-monarch-01.txt
> Pages           : 23
> Date            : 2011-05-05
>
>   This memo proposes an architecture for extending RTCP with a new RTCP
>   XR (RFC3611) block type to report new metrics regarding media
>   transmission or reception quality, as proposed in RFC5968.  This memo
>   suggests that a new block should contain a single metric or a small
>   number of metrics relevant to a single parameter of interest or
>   concern, rather than containing a number of metrics which attempt to
>   provide full coverage of all those parameters of concern to a
>   specific application.  Applications may then &quot;mix and match&quot; to
>   create a set of blocks which covers their set of concerns.  Where
>   possible, a specific block should be designed to be re-usable across
>   more than one application, for example, for all of voice, streaming
>   audio and video.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-01.txt
> _______________________________________________
> 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 --Boundary_(ID_QHb4HDTrYfO95Vv6J8Q6RA)-- From sunseawq@huawei.com Thu May 5 04:25:57 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1ADE0854 for ; Thu, 5 May 2011 04:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZscRgp6PnoJ for ; Thu, 5 May 2011 04:25:56 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5EE075F for ; Thu, 5 May 2011 04:25:55 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKP009NFZPW6J@szxga05-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:25:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKP004P4ZPVUH@szxga05-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:25:07 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKP007H0ZPU7U@szxml06-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:25:07 +0800 (CST) Date: Thu, 05 May 2011 19:28:38 +0800 From: Qin Wu To: Jonathan Lennox , avt@ietf.org Message-id: <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:25:57 -0000 Some fairly minor comments below. Overall I think the document provides useful mechanism to deal with tradeoff between RTP header extension encryption and RTP header compression efficiency when we use multiple header extension. Section 3 Encryption Mechanism " To encrypt (or decrypt) an encrypted extension header, an SRTP participant first generates a keystream for the SRTP extension header. This keystream is generated in the same manner as the encryption keystream for the corresponding SRTP payload, except the the SRTP encryption and salting keys k_e and k_s are replaced by the keys k_he and k_hs, respectively. " [Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload to provide encryption for the payload of header extension element? What's the benefit to choose the different keystream and crypto-suite for header extension elements? Can we say the same keystream and crypto-suite for SRTP payload can be applied to header extension elements? Section 4: " Encrypted header extension elements are signaled in the SDP extmap attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt", followed by the URI of the header extension element being encrypted as well as any extensionattributes that extension normally takes. " [Qin]: Are you going to define new URI for Encryption of Header Extensions or use existing URI? Section 4: [Qin]: If one header extension has three elements, a) the header extension and elements header will not be encrypted, only payload of each elements need encryption b) or both elements header and elements payload will be encrypted? I believe it is former. [Qin]: If the number of header extension element included in each RTP packet changes during a stream, e.g., Firstly three header extension elements to be encrypted carried in the first RTP packet are sent to the receiver, and then, two header extension elements carried in the second RTP packet are sent to the same receiver, is the receiver aware of this change and choosing the right encryption mask? How? based on non-encrypted header? [Qin]: If there are no payload for header extension elements, i.e., the length of header extension elements is zero, the mechanism described in this document does not apply to this case, right? Regards! -Qin ----- Original Message ----- From: "Jonathan Lennox" To: Sent: Monday, March 28, 2011 5:08 PM Subject: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt Hello, all -- I've updated my draft on encrypting RTP header extensions, targeting the draft at the AVTCore WG, in the hope that the group will find it a suitable starting point for the WG milestone. This version of the draft has no substantial changes from draft-lennox-avt-srtp-encrypted-extension-headers-02, only the name change and some reference updates. Begin forwarded message: > From: "Internet-Drafts@ietf.org" > Date: March 28, 2011 11:00:01 AM GMT+02:00 > To: "i-d-announce@ietf.org" > Subject: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt > Reply-To: "internet-drafts@ietf.org" > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) > Author(s) : J. Lennox > Filename : draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt > Pages : 8 > Date : 2011-03-28 > > The Secure Real-Time Transport Protocol (SRTP) provides > authentication, but not encryption, of the headers of Real-Time > Transport Protocol (RTP) packets. However, RTP header extensions may > carry sensitive information for which participants in multimedia > sessions want confidentiality. This document provides a mechanism, > extending the mechanisms of SRTP, to selectively encrypt RTP header > extensions in SRTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -------------------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From sunseawq@huawei.com Thu May 5 04:53:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04351E086B for ; Thu, 5 May 2011 04:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.593 X-Spam-Level: X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[AWL=2.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctoIbR+24mzB for ; Thu, 5 May 2011 04:53:51 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D405AE0749 for ; Thu, 5 May 2011 04:53:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKQ003OS11DX2@szxga04-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:53:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKQ00E2U11DYH@szxga04-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:53:37 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKQ007JA11C7P@szxml06-in.huawei.com> for avt@ietf.org; Thu, 05 May 2011 19:53:37 +0800 (CST) Date: Thu, 05 May 2011 19:57:08 +0800 From: Qin Wu To: Roni Even , avt@ietf.org Message-id: <00e001cc0b1b$8fac7b90$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_yPnOOuXEGZIcQHAajWev2A)" X-Priority: 3 X-MSMail-priority: Normal References: <009801cbeeab$d3110f40$79332dc0$%roni@huawei.com> Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] Call for adoption of encryption header extensionsin SRTPdocument X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 11:53:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yPnOOuXEGZIcQHAajWev2A) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Sorry for late reply, I support adoption of this work. ----- Original Message ----- From: Roni Even To: avt@ietf.org Cc: 'Magnus Westerlund' Sent: Wednesday, March 30, 2011 3:26 PM Subject: [AVTCORE] Call for adoption of encryption header extensionsin SRTPdocument Hi, AVTCore has a mile stone for September 2011 for Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard There is an individual draft Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) http://tools.ietf.org/html/draft-lennox-avtcore-srtp-encrypted-header-ext-00 Based on the feedback in the AVTcore session in Prague this is a WG call to adopt the above text as baseline text for this milestone. This is an initial text and can be updated based on feedback once it is a WG document. Please respond by Thursday April 14th 2011 with your positions. Roni Even AVTCORE WG co-chair ------------------------------------------------------------------------------ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_yPnOOuXEGZIcQHAajWev2A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
Sorry for late reply, I support adoption of this work.
----- Original Message -----
From: Roni Even
Sent: Wednesday, March 30, 2011 3:26 PM
Subject: [AVTCORE] Call for adoption of encryption header extensionsin SRTPdocument

 

 

Hi,

AVTCore has a mile stone for September 2011 for Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP) for Proposed Standard

 

There is an individual draft Encryption of Header Extensions in the Secure  Real-Time Transport   Protocol (SRTP) http://tools.ietf.org/html/draft-lennox-avtcore-srtp-encrypted-header-ext-00

 

 

Based on the feedback in the AVTcore session in Prague this is a WG call  to adopt the above text as baseline text for this milestone. This is an initial text and can be updated based on feedback once it is a WG document.

 

 

Please respond by Thursday April 14th  2011 with your positions.

 

Roni Even

AVTCORE WG co-chair

 

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_yPnOOuXEGZIcQHAajWev2A)-- From jonathan@vidyo.com Thu May 5 08:34:40 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A086E08B9 for ; Thu, 5 May 2011 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpz3kBWKFMRW for ; Thu, 5 May 2011 08:34:39 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by ietfa.amsl.com (Postfix) with ESMTP id D2928E0775 for ; Thu, 5 May 2011 08:34:38 -0700 (PDT) Received: from st23.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id D5250416EFE; Thu, 5 May 2011 11:34:37 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 80623416ECE; Thu, 5 May 2011 11:34:21 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 5 May 2011 11:33:09 -0400 From: Jonathan Lennox To: Qin Wu Date: Thu, 5 May 2011 11:34:20 -0400 Thread-Topic: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcwLObyfA+1hTHBqQgeYOo7ibaJF4g== Message-ID: <7D66AF27-F3CD-4E02-849B-DB2D12F60799@vidyo.com> References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> In-Reply-To: <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 15:34:40 -0000 On May 5, 2011, at 7:28 AM, Qin Wu wrote: > Some fairly minor comments below. Overall I think the document provides = useful mechanism to deal with tradeoff between RTP header extension encrypt= ion and RTP header > compression efficiency when we use multiple header extension. That's good to hear! Responses inline. > Section 3 Encryption Mechanism > " > To encrypt (or decrypt) an encrypted extension header, an SRTP > participant first generates a keystream for the SRTP extension > header. This keystream is generated in the same manner as the > encryption keystream for the corresponding SRTP payload, except the > the SRTP encryption and salting keys k_e and k_s are replaced by the > keys k_he and k_hs, respectively. > " > [Qin]: Is it possible to use the same keystream and crypto-suite for SRTP= payload > to provide encryption for the payload of header extension element? > What's the benefit to choose the different keystream and crypto-suite for= header extension elements? > Can we say the same keystream and crypto-suite for SRTP payload can be a= pplied to header extension elements? It definitely uses the same cryptosuite, but it can't be the same keystream= -- if the payload and the extension elements are encrypted with the same k= eystream, you have a two-time-pad security failure. In principle you could use a different region of the same keystream, but th= ere's no obvious way to do that in a way that's backward-compatible with ex= isting SRTP. Since SRTP implementations are already generating six separate keys based o= n the master key (encryption, salting, and authentication for both RTP and = RTCP) and two keystreams (for RTP and RTCP), adding two additional keys and= one additional keystream doesn't seem like a particularly large implementa= tion burden. > Section 4: > " > Encrypted header extension elements are signaled in the SDP extmap > attribute, using the URI "urn:ietf:params:rtp-hdrext:encrypt", > followed by the URI of the header extension element being encrypted > as well as any extensionattributes that extension normally takes. > " > [Qin]: Are you going to define new URI for Encryption of Header Extension= s or use existing URI? The intention is that the new URI you quoted specifies generic encryption, = and the extmap attribute takes as a parameter the existing URI describing t= he header being encrypted. For example, encrypted SMPTE timecodes would be described as: a=3Dextmap:1 urn:ietf:params:rtp-hdrext:encrypt urn:ietf:params:rtp-hdrext:= smpte-tc 25@600/24=20 > Section 4: >=20 > [Qin]: If one header extension has three elements,=20 > a) the header extension and elements header will not be encrypted, only p= ayload of each elements need encryption=20 > b) or both elements header and elements payload will be encrypted? > I believe it is former. That's correct. > [Qin]: If the number of header extension element included in each RTP pac= ket changes during a stream, e.g., Firstly three header extension elements > to be encrypted carried in the first RTP packet are sent to the receiver,= and then, two header extension elements carried in=20 > the second RTP packet are sent to the same receiver, is the receiver awar= e of this change and choosing the right encryption mask? How? > based on non-encrypted header? The header extension elements are identified by the (unencrypted) header ex= tension element headers, and you know based on the SDP which ones are encry= pted. Thus, the encryption mask can be computed on a packet-by-packet basis= . > [Qin]: If there are no payload for header extension elements, i.e., the l= ength of header extension elements is zero, the mechanism described in this= document > does not apply to this case, right? For the one-byte-header form of header extension elements (0xBEDE), RFC 528= 5 doesn't support zero-length header extension elements, so it's moot. For the two-byte-header form of header extension elements (0x100x), indeed = this mechanism doesn't apply to zero-length extension elements. The mechan= ism also doesn't apply to the long-form extension's app bits (the unspecifi= ed four bits of the "specified by profile" field). > Regards! > -Qin > ----- Original Message -----=20 > From: "Jonathan Lennox" > To: > Sent: Monday, March 28, 2011 5:08 PM > Subject: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-he= ader-ext-00.txt >=20 >=20 > Hello, all -- >=20 > I've updated my draft on encrypting RTP header extensions, targeting the = draft at the AVTCore WG, in the hope that the group will find it a suitable= starting point for the WG milestone. >=20 > This version of the draft has no substantial changes from draft-lennox-av= t-srtp-encrypted-extension-headers-02, only the name change and some refere= nce updates. >=20 > Begin forwarded message: >=20 >> From: "Internet-Drafts@ietf.org" >> Date: March 28, 2011 11:00:01 AM GMT+02:00 >> To: "i-d-announce@ietf.org" >> Subject: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.tx= t >> Reply-To: "internet-drafts@ietf.org" >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >> Title : Encryption of Header Extensions in the Secure Real-Tim= e Transport Protocol (SRTP) >> Author(s) : J. Lennox >> Filename : draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt >> Pages : 8 >> Date : 2011-03-28 >>=20 >> The Secure Real-Time Transport Protocol (SRTP) provides >> authentication, but not encryption, of the headers of Real-Time >> Transport Protocol (RTP) packets. However, RTP header extensions may >> carry sensitive information for which participants in multimedia >> sessions want confidentiality. This document provides a mechanism, >> extending the mechanisms of SRTP, to selectively encrypt RTP header >> extensions in SRTP. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-lennox-avtcore-srtp-encrypted-= header-ext-00.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 -- Jonathan Lennox jonathan@vidyo.com From csp@csperkins.org Thu May 5 09:30:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50F0E07AC for ; Thu, 5 May 2011 09:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuKbRwT0H4zM for ; Thu, 5 May 2011 09:30:12 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF5E0694 for ; Thu, 5 May 2011 09:30:12 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QI1RL-0003Uz-Xb; Thu, 05 May 2011 16:30:11 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-78--111705722 From: Colin Perkins X-Priority: 3 In-Reply-To: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> Date: Thu, 5 May 2011 17:30:08 +0100 Message-Id: References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 16:30:17 -0000 --Apple-Mail-78--111705722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Apr 2011, at 11:05, Qin Wu wrote: > Hi,folks: > We have updated draft-ietf-avtcore-feedback-suppression-rtp to version = 01 to address the comments from Prague meeting and on the list. > The new version is available at: > = http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp= / > the diff from 00 is > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-feedback-supressio= n-rtp-01 > =20 > Also I recall in the meeting there was a comment about use case and we = have four use cases in the current draft and I would ask WG do people = think these use cases are clear and what use cases are missing and do = people think that use cases are needed. I have several comments on this draft that relate to the use cases, both = as written in Section 6, and elsewhere. The draft seems to be written as = if it were still generating a feedback suppression packet, rather than a = third-party loss report packet that happens to suppress feedback. 1) The title and abstract were appropriate when the draft was solely = aimed at feedback suppression, but should be updated now the focus is on = third-party loss reports.=20 2) The protocol overview in Section 3, in particular the 2nd to 5th = paragraphs, seems to have the use case for this third party report = backwards. If there is packet loss upstream of a middlebox, that = middlebox should send a NACK packet both upstream and downstream, to = indicate that it has noticed the loss, and to suppress feedback from = other downstream receivers. The third-party loss report is sent = downstream by the middlebox when downstream loss is reported to the = middlebox in a way that other downstream receivers are not aware of the = loss reports, to inform those receivers of the loss and suppress their = feedback. 3) The 6th paragraph of Section 3 also confuses this when it states = "replace it with a Third Party Loss Report message that reflects the = loss pattern they have themselves seen": if they have seen the loss, = then a NACK is appropriate. If they've been told about the loss, then a = third party loss report is needed. 4) Section 6.1, 2nd paragraph has a similar problem. Upstream loss will = cause an SSM Distribution Source to generate a NACK, which it sends = upstream and downstream. The third party loss report is used when one = downstream receiver reports loss, leaving the Distribution Source with = the responsibility of telling the other downstream receivers. Section = 6.1.1 gets this correct. 5) Section 6.1.2, 2nd paragraph: same problem. This section also needs = to talk about the need to generate and send downstream third party loss = reports in response to NACKs received from downstream. 6) Section 6.2: why does a BRS that detects loss send a third-party = report, rather than a NACK? The third-party report would be sent in = response to downstream receivers sending NACKs, to inform other = receivers, no? --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-78--111705722 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-sup= ression-rtp/
the diff from 00 is
 
Also I recall = in the meeting there was a comment about use case and we have four use = cases in the current draft and I would ask WG do people think these = use cases are clear and what use cases are missing and do = people think that use cases are = needed.

I have several comments on = this draft that relate to the use cases, both as written in Section 6, = and elsewhere. The draft seems to be written as if it were still = generating a feedback suppression packet, rather than a third-party loss = report packet that happens to suppress = feedback.

1) The title and abstract were = appropriate when the draft was solely aimed at feedback suppression, but = should be updated now the focus is on third-party loss = reports. 

2) The protocol overview in = Section 3, in particular the 2nd to 5th paragraphs, seems to have the = use case for this third party report backwards. If there is packet loss = upstream of a middlebox, that middlebox should send a NACK packet both = upstream and downstream, to indicate that it has noticed the loss, and = to suppress feedback from other downstream receivers. The third-party = loss report is sent downstream by the middlebox when downstream loss is = reported to the middlebox in a way that other downstream receivers are = not aware of the loss reports, to inform those receivers of the loss and = suppress their feedback.

3) The 6th paragraph = of Section 3 also confuses this when it states "replace it with a Third = Party Loss Report message that reflects the loss pattern they have = themselves seen": if they have seen the loss, then a NACK is = appropriate. If they've been told about the loss, then a third party = loss report is needed.

4) Section 6.1, 2nd = paragraph has a similar problem. Upstream loss will cause an SSM = Distribution Source to generate a NACK, which it sends upstream and = downstream. The third party loss report is used when one downstream = receiver reports loss, leaving the Distribution Source with the = responsibility of telling the other downstream receivers. Section 6.1.1 = gets this correct.

5) Section 6.1.2, 2nd = paragraph: same problem. This section also needs to talk about the need = to generate and send downstream third party loss reports in response to = NACKs received from downstream.

6) Section 6.2: = why does a BRS that detects loss send a third-party report, rather than = a NACK? The third-party report would be sent in response to downstream = receivers sending NACKs, to inform other receivers, = no?


http://csperkins.org/



= --Apple-Mail-78--111705722-- From sunseawq@huawei.com Thu May 5 18:22:19 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B00E06A8 for ; Thu, 5 May 2011 18:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=1.880, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb2Bh3CyMzIb for ; Thu, 5 May 2011 18:22:19 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BBEE8E0688 for ; Thu, 5 May 2011 18:22:18 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR005YN2H5MN@szxga04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:22:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00BGV2H5P8@szxga04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:22:17 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR007EI2H44O@szxml06-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:22:17 +0800 (CST) Date: Fri, 06 May 2011 09:25:48 +0800 From: Qin Wu To: Jonathan Lennox Message-id: <011e01cc0b8c$883392b0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> <7D66AF27-F3CD-4E02-849B-DB2D12F60799@vidyo.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 01:22:19 -0000 Thanks for clarification. I removed the fixed comments, please see inline. ----- Original Message ----- From: "Jonathan Lennox" To: "Qin Wu" Cc: Sent: Thursday, May 05, 2011 11:34 PM Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt > Section 3 Encryption Mechanism > " > To encrypt (or decrypt) an encrypted extension header, an SRTP > participant first generates a keystream for the SRTP extension > header. This keystream is generated in the same manner as the > encryption keystream for the corresponding SRTP payload, except the > the SRTP encryption and salting keys k_e and k_s are replaced by the > keys k_he and k_hs, respectively. > " > [Qin]: Is it possible to use the same keystream and crypto-suite for SRTP payload > to provide encryption for the payload of header extension element? > What's the benefit to choose the different keystream and crypto-suite for header extension elements? > Can we say the same keystream and crypto-suite for SRTP payload can be applied to header extension elements? It definitely uses the same cryptosuite, but it can't be the same keystream -- if the payload and the extension elements are encrypted with the same keystream, you have a two-time-pad security failure. [Qin]: I agree using the same keystream to encrypt twice will cause two-time pad security failure issue, i.e., first use the keystream to encrypt STRP payload, and then use the same keystream to encrypt header extension elements. However if we regard the payload of header extension elements and SRTP payload as a big payload, we only need to use the same keystream to encrypt this big payload once. there is no two-time pad security issue, right? In principle you could use a different region of the same keystream, but there's no obvious way to do that in a way that's backward-compatible with existing SRTP. Since SRTP implementations are already generating six separate keys based on the master key (encryption, salting, and authentication for both RTP and RTCP) and two keystreams (for RTP and RTCP), adding two additional keys and one additional keystream doesn't seem like a particularly large implementation burden. [Qin]: True. From jonathan@vidyo.com Thu May 5 18:29:29 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45EBE0759 for ; Thu, 5 May 2011 18:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojwmiE1YGIWG for ; Thu, 5 May 2011 18:29:29 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by ietfa.amsl.com (Postfix) with ESMTP id 438C5E06A5 for ; Thu, 5 May 2011 18:29:29 -0700 (PDT) Received: from st20.mx1.myoutlookonline.com (localhost [127.0.0.1]) by mx1.myoutlookonline.com (Postfix) with ESMTP id 97FE38BE1C8; Thu, 5 May 2011 21:29:28 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.myoutlookonline.com (Postfix) with ESMTPS id 389468BE1C1; Thu, 5 May 2011 21:29:28 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Thu, 5 May 2011 21:28:39 -0400 From: Jonathan Lennox To: Qin Wu Date: Thu, 5 May 2011 21:29:27 -0400 Thread-Topic: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcwLjN8rlOnewwcmSKSOoNw5VJ6XUA== Message-ID: References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> <7D66AF27-F3CD-4E02-849B-DB2D12F60799@vidyo.com> <011e01cc0b8c$883392b0$46298a0a@china.huawei.com> In-Reply-To: <011e01cc0b8c$883392b0$46298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 01:29:29 -0000 On May 5, 2011, at 9:25 PM, Qin Wu wrote: > [Qin]: I agree using the same keystream to encrypt twice will cause two-= time pad security failure issue, > i.e., first use the keystream to encrypt STRP payload, and then use the s= ame keystream to encrypt=20 > header extension elements. >=20 > However if we regard the payload of header extension elements and SRTP pa= yload as a big payload,=20 > we only need to use the same keystream to encrypt this big payload once. = there is no two-time pad=20 > security issue, right? That's true, but it wouldn't be backward-compatible with existing receivers= , which understand SRTP but ignore extension headers they're not familiar w= ith -- the keystream would start in the wrong place. -- Jonathan Lennox jonathan@vidyo.com From sunseawq@huawei.com Thu May 5 18:42:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656AAE0754 for ; Thu, 5 May 2011 18:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9-CZhaH65B2 for ; Thu, 5 May 2011 18:42:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1EE0688 for ; Thu, 5 May 2011 18:42:14 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR008P53EAIR@szxga05-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR006L03E93H@szxga05-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:10 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00M743E9CE@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:09 +0800 (CST) Date: Fri, 06 May 2011 09:45:41 +0800 From: Qin Wu To: Jonathan Lennox Message-id: <02b801cc0b8f$4f22c790$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> <7D66AF27-F3CD-4E02-849B-DB2D12F60799@vidyo.com> <011e01cc0b8c$883392b0$46298a0a@china.huawei.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 01:42:15 -0000 ----- Original Message ----- From: "Jonathan Lennox" To: "Qin Wu" Cc: Sent: Friday, May 06, 2011 9:29 AM Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt On May 5, 2011, at 9:25 PM, Qin Wu wrote: > [Qin]: I agree using the same keystream to encrypt twice will cause two-time pad security failure issue, > i.e., first use the keystream to encrypt STRP payload, and then use the same keystream to encrypt > header extension elements. > > However if we regard the payload of header extension elements and SRTP payload as a big payload, > we only need to use the same keystream to encrypt this big payload once. there is no two-time pad > security issue, right? That's true, but it wouldn't be backward-compatible with existing receivers, which understand SRTP but ignore extension headers they're not familiar with -- the keystream would start in the wrong place. [Qin]: So who will care header extension elements? the intermediary node or receiver who are signalled by SDP. -- Jonathan Lennox jonathan@vidyo.com From sunseawq@huawei.com Fri May 6 01:03:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E91E068C for ; Fri, 6 May 2011 01:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0ZOV1puLzNj for ; Fri, 6 May 2011 01:03:45 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B2D5AE0663 for ; Fri, 6 May 2011 01:03:44 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00MMJL16LB@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR007A7L16VJ@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:06 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00E44L16OB@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:03:06 +0800 (CST) Date: Fri, 06 May 2011 16:06:38 +0800 From: Qin Wu To: Colin Perkins Message-id: <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_DlOaV9uUCajbSntCL5v6Vg)" X-Priority: 3 X-MSMail-priority: Normal References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:03:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_DlOaV9uUCajbSntCL5v6Vg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thanks for your valuable comments, please see below. ----- Original Message ----- From: Colin Perkins To: Qin Wu Cc: avt@ietf.org ; magnus.westerlund@ericsson.com Sent: Friday, May 06, 2011 12:30 AM Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 On 15 Apr 2011, at 11:05, Qin Wu wrote: Hi,folks: We have updated draft-ietf-avtcore-feedback-suppression-rtp to version 01 to address the comments from Prague meeting and on the list. The new version is available at: http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/ the diff from 00 is http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-01 Also I recall in the meeting there was a comment about use case and we have four use cases in the current draft and I would ask WG do people think these use cases are clear and what use cases are missing and do people think that use cases are needed. I have several comments on this draft that relate to the use cases, both as written in Section 6, and elsewhere. The draft seems to be written as if it were still generating a feedback suppression packet, rather than a third-party loss report packet that happens to suppress feedback. 1) The title and abstract were appropriate when the draft was solely aimed at feedback suppression, but should be updated now the focus is on third-party loss reports. [Qin]: Good point, will reflect this update in the new version. 2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback. [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document. 3) The 6th paragraph of Section 3 also confuses this when it states "replace it with a Third Party Loss Report message that reflects the loss pattern they have themselves seen": if they have seen the loss, then a NACK is appropriate. If they've been told about the loss, then a third party loss report is needed. [Qin]: Okay. 4) Section 6.1, 2nd paragraph has a similar problem. Upstream loss will cause an SSM Distribution Source to generate a NACK, which it sends upstream and downstream. The third party loss report is used when one downstream receiver reports loss, leaving the Distribution Source with the responsibility of telling the other downstream receivers. Section 6.1.1 gets this correct. [Qin]: Okay. 5) Section 6.1.2, 2nd paragraph: same problem. This section also needs to talk about the need to generate and send downstream third party loss reports in response to NACKs received from downstream. [Qin]: Okay. 6) Section 6.2: why does a BRS that detects loss send a third-party report, rather than a NACK? The third-party report would be sent in response to downstream receivers sending NACKs, to inform other receivers, no? [Qin]: Okay, how about rephrase " a BRS that detects loss " as " a BRS that receives downstream loss report " In this case, BRS need to send handle third-party report rather than NACK.. -- Colin Perkins http://csperkins.org/ --Boundary_(ID_DlOaV9uUCajbSntCL5v6Vg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Thanks for your valuable comments, please see below.
----- Original Message -----
To: Qin Wu
Sent: Friday, May 06, 2011 12:30 AM
Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01

On 15 Apr 2011, at 11:05, Qin Wu wrote:
Hi,folks:
We have updated draft-ietf-avtcore-feedback-suppression-rtp to version 01 to address the comments from Prague meeting and on the list.
The new version is available at:
the diff from 00 is
 
Also I recall in the meeting there was a comment about use case and we have four use cases in the current draft and I would ask WG do people think these use cases are clear and what use cases are missing and do people think that use cases are needed.

I have several comments on this draft that relate to the use cases, both as written in Section 6, and elsewhere. The draft seems to be written as if it were still generating a feedback suppression packet, rather than a third-party loss report packet that happens to suppress feedback.

1) The title and abstract were appropriate when the draft was solely aimed at feedback suppression, but should be updated now the focus is on third-party loss reports. 
 
[Qin]: Good point, will reflect this update in the new version.

2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback.
 
[Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document.

3) The 6th paragraph of Section 3 also confuses this when it states "replace it with a Third Party Loss Report message that reflects the loss pattern they have themselves seen": if they have seen the loss, then a NACK is appropriate. If they've been told about the loss, then a third party loss report is needed.
 
[Qin]: Okay.

4) Section 6.1, 2nd paragraph has a similar problem. Upstream loss will cause an SSM Distribution Source to generate a NACK, which it sends upstream and downstream. The third party loss report is used when one downstream receiver reports loss, leaving the Distribution Source with the responsibility of telling the other downstream receivers. Section 6.1.1 gets this correct.
 
[Qin]: Okay.

5) Section 6.1.2, 2nd paragraph: same problem. This section also needs to talk about the need to generate and send downstream third party loss reports in response to NACKs received from downstream.
 
[Qin]: Okay.

6) Section 6.2: why does a BRS that detects loss send a third-party report, rather than a NACK? The third-party report would be sent in response to downstream receivers sending NACKs, to inform other receivers, no?
 
[Qin]: Okay, how about rephrase
"
a BRS that detects loss
"
as
"
a BRS that receives downstream loss report
"
In this case, BRS need to send handle third-party report rather than NACK..

-- 
Colin Perkins



--Boundary_(ID_DlOaV9uUCajbSntCL5v6Vg)-- From csp@csperkins.org Fri May 6 01:12:00 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71D0E068C for ; Fri, 6 May 2011 01:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt11Q2xgDCpB for ; Fri, 6 May 2011 01:12:00 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94FE067C for ; Fri, 6 May 2011 01:12:00 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QIG8j-0000ZR-ia; Fri, 06 May 2011 08:11:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> Date: Fri, 6 May 2011 09:11:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org> References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:12:01 -0000 On 6 May 2011, at 09:06, Qin Wu wrote: > Thanks for your valuable comments, please see below. > ----- Original Message ----- > From: Colin Perkins > To: Qin Wu > Cc: avt@ietf.org ; magnus.westerlund@ericsson.com > Sent: Friday, May 06, 2011 12:30 AM > Subject: Re: [AVTCORE] Fw: New Version Notification for = draft-ietf-avtcore-feedback-supression-rtp-01 >=20 > On 15 Apr 2011, at 11:05, Qin Wu wrote: >> Hi,folks: >> We have updated draft-ietf-avtcore-feedback-suppression-rtp to = version 01 to address the comments from Prague meeting and on the list. >> The new version is available at: >> = http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp= / >> the diff from 00 is >> = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-feedback-supressio= n-rtp-01 >> =20 >> Also I recall in the meeting there was a comment about use case and = we have four use cases in the current draft and I would ask WG do people = think these use cases are clear and what use cases are missing and do = people think that use cases are needed. >=20 > I have several comments on this draft that relate to the use cases, = both as written in Section 6, and elsewhere. The draft seems to be = written as if it were still generating a feedback suppression packet, = rather than a third-party loss report packet that happens to suppress = feedback. >=20 > 1) The title and abstract were appropriate when the draft was solely = aimed at feedback suppression, but should be updated now the focus is on = third-party loss reports.=20 > =20 > [Qin]: Good point, will reflect this update in the new version. >=20 > 2) The protocol overview in Section 3, in particular the 2nd to 5th = paragraphs, seems to have the use case for this third party report = backwards. If there is packet loss upstream of a middlebox, that = middlebox should send a NACK packet both upstream and downstream, to = indicate that it has noticed the loss, and to suppress feedback from = other downstream receivers. The third-party loss report is sent = downstream by the middlebox when downstream loss is reported to the = middlebox in a way that other downstream receivers are not aware of the = loss reports, to inform those receivers of the loss and suppress their = feedback. > =20 > [Qin]: Okay, you mention the middlebox send NACK upstream, it is about = packet loss recovery. I would like to leave this beyond scope of this = document. The NACK is a notification of loss: it's independent of the packet loss = recovery mechanism used. I do not believe this is out of scope of this = document. Colin= From sunseawq@huawei.com Fri May 6 01:23:37 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA830E06C8 for ; Fri, 6 May 2011 01:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.887 X-Spam-Level: X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=1.712, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3NM67-L8GiX for ; Fri, 6 May 2011 01:23:36 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A463BE0663 for ; Fri, 6 May 2011 01:23:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00MFELYMLB@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR003VTLYMGL@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00EJJLYMOB@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 16:23:10 +0800 (CST) Date: Fri, 06 May 2011 16:26:42 +0800 From: Qin Wu To: Colin Perkins Message-id: <039c01cc0bc7$54926720$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org> Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 08:23:37 -0000 > 2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback. > > [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document. The NACK is a notification of loss: it's independent of the packet loss recovery mechanism used. I do not believe this is out of scope of this document. Colin= [Qin]: But NACK also can be used for retransmission. Retransmission is one kind of packet loss repairement mechanism. And there was consensus that how to repair the packet loss should be beyond scope of this document. If I am wrong, please correct me. From csp@csperkins.org Fri May 6 02:04:22 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD05E06D1 for ; Fri, 6 May 2011 02:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRzd8UV1WpZ6 for ; Fri, 6 May 2011 02:04:21 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 23AA0E068C for ; Fri, 6 May 2011 02:04:20 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QIGvU-0005vv-ku; Fri, 06 May 2011 09:02:20 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins X-Priority: 3 In-Reply-To: <039c01cc0bc7$54926720$46298a0a@china.huawei.com> Date: Fri, 6 May 2011 10:02:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org> <039c01cc0bc7$54926720$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:04:23 -0000 On 6 May 2011, at 09:26, Qin Wu wrote: >> 2) The protocol overview in Section 3, in particular the 2nd to 5th = paragraphs, seems to have the use case for this third party report = backwards. If there is packet loss upstream of a middlebox, that = middlebox should send a NACK packet both upstream and downstream, to = indicate that it has noticed the loss, and to suppress feedback from = other downstream receivers. The third-party loss report is sent = downstream by the middlebox when downstream loss is reported to the = middlebox in a way that other downstream receivers are not aware of the = loss reports, to inform those receivers of the loss and suppress their = feedback. >>=20 >> [Qin]: Okay, you mention the middlebox send NACK upstream, it is = about packet loss recovery. I would like to leave this beyond scope of = this document. >=20 > The NACK is a notification of loss: it's independent of the packet = loss recovery mechanism used. I do not believe this is out of scope of = this document. >=20 > Colin=3D >=20 > [Qin]: But NACK also can be used for retransmission. Retransmission is = one kind of packet loss repairement mechanism. And there was consensus = that how to repair the packet loss should be beyond scope of this = document.=20 > If I am wrong, please correct me. According to RFC 4585, a "Generic NACK is used to indicate the loss of = one or more RTP packets". An endpoint that receives a NACK might decide = to retransmit the lost packet, but that's not required, and by sending a = NACK, we are not requiring retransmission.=20 --=20 Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Fri May 6 02:17:07 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC49E074F for ; Fri, 6 May 2011 02:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.973 X-Spam-Level: X-Spam-Status: No, score=-4.973 tagged_above=-999 required=5 tests=[AWL=1.626, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmmh2R9Z-aTW for ; Fri, 6 May 2011 02:17:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3515DE0751 for ; Fri, 6 May 2011 02:16:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR0029ROFTNK@szxga04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:16:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00EBDOFSYH@szxga04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:16:40 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00LBVOFSTT@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:16:40 +0800 (CST) Date: Fri, 06 May 2011 17:20:13 +0800 From: Qin Wu To: Colin Perkins Message-id: <03e701cc0bce$ce1fa290$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <03fa01cbfb54$b52f1f20$46298a0a@china.huawei.com> <038a01cc0bc4$870fffd0$46298a0a@china.huawei.com> <054B1A63-8659-4190-8C13-C9357128C6A8@csperkins.org> <039c01cc0bc7$54926720$46298a0a@china.huawei.com> Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] Fw: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:17:07 -0000 On 6 May 2011, at 09:26, Qin Wu wrote: >> 2) The protocol overview in Section 3, in particular the 2nd to 5th paragraphs, seems to have the use case for this third party report backwards. If there is packet loss upstream of a middlebox, that middlebox should send a NACK packet both upstream and downstream, to indicate that it has noticed the loss, and to suppress feedback from other downstream receivers. The third-party loss report is sent downstream by the middlebox when downstream loss is reported to the middlebox in a way that other downstream receivers are not aware of the loss reports, to inform those receivers of the loss and suppress their feedback. >> >> [Qin]: Okay, you mention the middlebox send NACK upstream, it is about packet loss recovery. I would like to leave this beyond scope of this document. > > The NACK is a notification of loss: it's independent of the packet loss recovery mechanism used. I do not believe this is out of scope of this document. > > Colin= > > [Qin]: But NACK also can be used for retransmission. Retransmission is one kind of packet loss repairement mechanism. And there was consensus that how to repair the packet loss should be beyond scope of this document. > If I am wrong, please correct me. According to RFC 4585, a "Generic NACK is used to indicate the loss of one or more RTP packets". An endpoint that receives a NACK might decide to retransmit the lost packet, but that's not required, and by sending a NACK, we are not requiring retransmission. -- Colin Perkins [Qin]: Okay. I tend to agree. From internet-drafts@ietf.org Fri May 6 02:39:33 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA32E0720; Fri, 6 May 2011 02:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ghMJT8mh372; Fri, 6 May 2011 02:39:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89532E072B; Fri, 6 May 2011 02:39:33 -0700 (PDT) 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: 3.53 Message-ID: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> Date: Fri, 06 May 2011 02:39:33 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:39:34 -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 Core Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-02.txt Pages : 18 Date : 2011-05-06 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a media source or middlebox may experience transient overload if some event causes a large number of receivers to send feedback at once. This feedback implosion can be mitigated if the device suffering from overload can send a third party loss report message to the receivers to inhibit further feedback. This memo defines RTCP Extension for third party loss report, to suppress NACK and FIR feedback requests. It also defines associated SDP signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-02.txt From sunseawq@huawei.com Fri May 6 02:49:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAE0E0723 for ; Fri, 6 May 2011 02:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.05 X-Spam-Level: X-Spam-Status: No, score=-5.05 tagged_above=-999 required=5 tests=[AWL=1.549, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvO1BubhzBsr for ; Fri, 6 May 2011 02:49:35 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0240BE067B for ; Fri, 6 May 2011 02:49:35 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR00K1QPYMCK@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:49:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR005TOPYLK7@szxga03-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:49:33 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR003T8PYLQS@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 17:49:33 +0800 (CST) Date: Fri, 06 May 2011 17:53:06 +0800 From: Qin Wu To: avt@ietf.org Message-id: <003001cc0bd3$66244600$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> Cc: magnus.westerlund@ericsson.com, Colin Perkins Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:49:35 -0000 Hi, The new version of draft-ietf-avtcore-feedback-suppression-rtp is available at http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt which address the recent comments from Colin on the list. The main change is to clarify the use of third party loss report and update the title and relevant sections to focus on third party loss report. The diff is at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-02 Please check if you are comfortable with the changes in this version. Any comments? Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Friday, May 06, 2011 5:39 PM Subject: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTCP Extension for Third-party Loss Report > Author(s) : Qin Wu > Frank Xia > Roni Even > Filename : draft-ietf-avtcore-feedback-supression-rtp-02.txt > Pages : 18 > Date : 2011-05-06 > > In a large RTP session using the RTCP feedback mechanism defined in > RFC 4585, a media source or middlebox may experience transient > overload if some event causes a large number of receivers to send > feedback at once. This feedback implosion can be mitigated if the > device suffering from overload can send a third party loss report > message to the receivers to inhibit further feedback. This memo > defines RTCP Extension for third party loss report, to suppress NACK > and FIR feedback requests. It also defines associated SDP signaling. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-02.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From olivier.crete@collabora.co.uk Fri May 6 17:51:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2E5E06B1 for ; Fri, 6 May 2011 17:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYcKH0PJb4WA for ; Fri, 6 May 2011 17:51:53 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC52E0676 for ; Fri, 6 May 2011 17:51:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id D4BCB6034EF From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: avt@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-oTjmmdH/KvJOjhIw9U6X" Organization: Collabora Date: Fri, 06 May 2011 20:51:50 -0400 Message-ID: <1304729510.32275.29.camel@TesterTop4> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Subject: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 00:51:54 -0000 --=-oTjmmdH/KvJOjhIw9U6X Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I've implemented the RTP/TFRC draft and it seems to work pretty well. That said, it also introduces some level of packet losses. Also, with some wifi connections, we have a relatively high rate of non-congestion packet loss. For both of these cases, I'd like to implement some kind of FEC, since losing a single packet tends to give nasty artifacts with video (especially using the free video codecs). It seems the current tendency in recent RFCs related to FEC is to send the FEC data as a separate stream from the main data. This seems to go against the intent of RTP/TFRC since using a second stream may effectively double the bandwidth share used by the video. Mixing both the video packets and the FEC packets in the same stream seems like a better idea to me for the unicast use-case. Is anyone implementing such an approach? Is there any standard around that? Or am I missing something? --=20 Olivier Cr=C3=AAte olivier.crete@collabora.co.uk --=-oTjmmdH/KvJOjhIw9U6X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3El6UACgkQHTiOWk7ZoruregCdHDQVZUbXC5rQ/BORGyxaMuKG uOgAn21q/qHfGUFS5drt+leTGax1wBlF =Nm7w -----END PGP SIGNATURE----- --=-oTjmmdH/KvJOjhIw9U6X-- From abegen@cisco.com Sat May 7 11:48:01 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE94BE06BA for ; Sat, 7 May 2011 11:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.403 X-Spam-Level: X-Spam-Status: No, score=-9.403 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0VuYh0EabO3 for ; Sat, 7 May 2011 11:48:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB4AE069E for ; Sat, 7 May 2011 11:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2312; q=dns/txt; s=iport; t=1304794081; x=1306003681; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=PblyVeTsgqTfnTHdHfisSgPYmzxY7uUBUbuRRW1HlSY=; b=Wnq5eM89mOCK1RxBHJTV8PzxVySQkxZ3bF3GUq8lsVCCd872B+FydMdW GGe6P5DvYj70r4ZyT2v96eP26L61F5o2chg/nMg8fHRVfgLmO26Jm3YkH xlcR+po3mrYDml2ink944qdPZxQmZAEiTuUR/qw99UZr3OplmYicnvfey 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUCAEKTxU2rRDoG/2dsb2JhbACEUpMgjT9zaA+IcZ0ijQKQI4Eqg2CBAgSGQI1Wikw X-IronPort-AV: E=Sophos;i="4.64,331,1301875200"; d="scan'208";a="310655096" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 07 May 2011 18:47:59 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p47IlxkY013167; Sat, 7 May 2011 18:47:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 7 May 2011 11:47:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 7 May 2011 11:47:07 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <1304729510.32275.29.camel@TesterTop4> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] RTP/TFRC + FEC ? Thread-Index: AcwMUP5s7FlApcjFTRa1joYn+cMNFAAlcRBQ References: <1304729510.32275.29.camel@TesterTop4> From: "Ali C. Begen (abegen)" To: =?UTF-8?B?T2xpdmllciBDcsOqdGU=?= , X-OriginalArrivalTime: 07 May 2011 18:47:59.0892 (UTC) FILETIME=[499D3540:01CC0CE7] Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 18:48:02 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogYXZ0LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9saXZpZXIg Q3LDqnRlDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDA2LCAyMDExIDg6NTIgUE0NCj4gVG86IGF2dEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbQVZUQ09SRV0gUlRQL1RGUkMgKyBGRUMgPw0KPiANCj4gSGks DQo+IA0KPiBJJ3ZlIGltcGxlbWVudGVkIHRoZSBSVFAvVEZSQyBkcmFmdCBhbmQgaXQgc2VlbXMg dG8gd29yayBwcmV0dHkgd2VsbC4NCj4gVGhhdCBzYWlkLCBpdCBhbHNvIGludHJvZHVjZXMgc29t ZSBsZXZlbCBvZiBwYWNrZXQgbG9zc2VzLiBBbHNvLCB3aXRoDQo+IHNvbWUgd2lmaSBjb25uZWN0 aW9ucywgd2UgaGF2ZSBhIHJlbGF0aXZlbHkgaGlnaCByYXRlIG9mIG5vbi1jb25nZXN0aW9uDQo+ IHBhY2tldCBsb3NzLiBGb3IgYm90aCBvZiB0aGVzZSBjYXNlcywgSSdkIGxpa2UgdG8gaW1wbGVt ZW50IHNvbWUga2luZCBvZg0KPiBGRUMsIHNpbmNlIGxvc2luZyBhIHNpbmdsZSBwYWNrZXQgdGVu ZHMgdG8gZ2l2ZSBuYXN0eSBhcnRpZmFjdHMgd2l0aA0KPiB2aWRlbyAoZXNwZWNpYWxseSB1c2lu ZyB0aGUgZnJlZSB2aWRlbyBjb2RlY3MpLg0KPiANCj4gSXQgc2VlbXMgdGhlIGN1cnJlbnQgdGVu ZGVuY3kgaW4gcmVjZW50IFJGQ3MgcmVsYXRlZCB0byBGRUMgaXMgdG8gc2VuZA0KPiB0aGUgRkVD IGRhdGEgYXMgYSBzZXBhcmF0ZSBzdHJlYW0gZnJvbSB0aGUgbWFpbiBkYXRhLiBUaGlzIHNlZW1z IHRvIGdvDQoNClRoYXQgaGFzIGEgbG90IGdvb2QgZmVhdHVyZXMuIFBsZWFzZSBzZWUgdGhlIGRy YWZ0cyBpbiBmZWNmcmFtZSB3Zy4gVGhlIGZlYyBmcmFtZXdvcmsgZHJhZnQgd2lsbCBhbHNvIHRl bGwgeW91IHRoYXQgYm90aCB0aGUgc291cmNlIGFuZCBmZWMgcGFja2V0cyBjYW4gYmUgc2VudCBp biB0aGVpciBvd24gUlRQIHN0cmVhbXMgKHdpdGggZGlmZmVyZW50IFNTUkNzKSBidXQgd2l0aGlu IHRoZSBzYW1lIFVEUCBmbG93LCBpZiB0aGF0IGlzIHdoYXQgeW91IGFyZSB3b3JyaWVkIGFib3V0 Lg0KDQo+IGFnYWluc3QgdGhlIGludGVudCBvZiBSVFAvVEZSQyBzaW5jZSB1c2luZyBhIHNlY29u ZCBzdHJlYW0gbWF5DQo+IGVmZmVjdGl2ZWx5IGRvdWJsZSB0aGUgYmFuZHdpZHRoIHNoYXJlIHVz ZWQgYnkgdGhlIHZpZGVvLiBNaXhpbmcgYm90aA0KDQpIdWg/IEl0IGRvZXMgbm90IG1hdHRlciBh dCBhbGwgZm9yIHRoZSBvdmVyaGVhZCB3aGV0aGVyIHlvdSBzZW5kIHRoZSBmZWMgcGFja2V0cyBz ZXBhcmF0ZWx5IG9yIGluLWJhbmQuIEFsc28sIEZFQyBkb2VzIG5vdCBuZWVkIHRvIGRvdWJsZSB0 aGUgYmFuZHdpZHRoLg0KDQotYWNiZWdlbg0KDQo+IHRoZSB2aWRlbyBwYWNrZXRzIGFuZCB0aGUg RkVDIHBhY2tldHMgaW4gdGhlIHNhbWUgc3RyZWFtIHNlZW1zIGxpa2UgYQ0KPiBiZXR0ZXIgaWRl YSB0byBtZSBmb3IgdGhlIHVuaWNhc3QgdXNlLWNhc2UuIElzIGFueW9uZSBpbXBsZW1lbnRpbmcg c3VjaA0KPiBhbiBhcHByb2FjaD8gSXMgdGhlcmUgYW55IHN0YW5kYXJkIGFyb3VuZCB0aGF0PyBP ciBhbSBJIG1pc3NpbmcNCj4gc29tZXRoaW5nPw0KPiANCj4gLS0NCj4gT2xpdmllciBDcsOqdGUN Cj4gb2xpdmllci5jcmV0ZUBjb2xsYWJvcmEuY28udWsNCg== From sunseawq@huawei.com Sun May 8 23:00:07 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE5E0686 for ; Sun, 8 May 2011 23:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.244 X-Spam-Level: X-Spam-Status: No, score=-4.244 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q78ixffAF0uR for ; Sun, 8 May 2011 23:00:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7DDE062A for ; Sun, 8 May 2011 23:00:02 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKW009L6ZBY98@szxga04-in.huawei.com> for avt@ietf.org; Mon, 09 May 2011 13:59:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKW00BH8ZBYP8@szxga04-in.huawei.com> for avt@ietf.org; Mon, 09 May 2011 13:59:58 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKW00G0KZBYCB@szxml06-in.huawei.com> for avt@ietf.org; Mon, 09 May 2011 13:59:58 +0800 (CST) Date: Mon, 09 May 2011 14:03:36 +0800 From: Qin Wu To: Magnus Westerlund , IETF AVTCore WG Message-id: <049401cc0e0e$d5b34b50$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <4DB9224E.8000900@ericsson.com> Subject: Re: [AVTCORE] Minutes for Prague IETF 80 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 06:00:07 -0000 T25lIHR5cG8gbmVlZHMgdG8gYmUgZml4ZWQgYXMgcmVnYXJkaW5nIHRvIGRyYWZ0LWh1bnQtYXZ0 Y29yZS1tb25hcmNoLTAxDQppZGVudGl0eSBpbmZvIHJlcGxldGlvbiAtLS0+IGlkZW50aXR5IGlu Zm8gcmVwZXRpdGlvbiANCg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQpGcm9tOiAiTWFnbnVzIFdlc3Rlcmx1bmQiIDxtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20+DQpUbzogIklFVEYgQVZUQ29yZSBXRyIgPGF2dEBpZXRmLm9yZz4NClNlbnQ6IFRo dXJzZGF5LCBBcHJpbCAyOCwgMjAxMSA0OjE2IFBNDQpTdWJqZWN0OiBbQVZUQ09SRV0gTWludXRl cyBmb3IgUHJhZ3VlIElFVEYgODANCg0KDQpIaSwNCg0KVGhlIG1pbnV0ZXMgb2YgdGhlIG1lZXRp bmcgYXJlIGF2YWlsYWJsZSBoZXJlOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84 MC9taW51dGVzL2F2dGNvcmUuaHRtDQoNClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgaWYgdGhl cmUgYXJlIGFueSBjbGFyaWZpY2F0aW9uL2ZpeGVzIHRoYXQgeW91DQp0aGluayBhcmUgbmVlZGVk Pw0KDQpDaGVlcnMNCg0KTWFnbnVzIFdlc3Rlcmx1bmQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KTXVsdGlt ZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UVk0NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpG 5HL2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0 IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 From sunseawq@huawei.com Mon May 9 01:08:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4154E07C2; Mon, 9 May 2011 01:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.069 X-Spam-Level: X-Spam-Status: No, score=-5.069 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGOhkwECNy2a; Mon, 9 May 2011 01:08:04 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9E974E06F4; Mon, 9 May 2011 01:08:03 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKX00B0X54PEC@szxga03-in.huawei.com>; Mon, 09 May 2011 16:05:13 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKX00IJ654P07@szxga03-in.huawei.com>; Mon, 09 May 2011 16:05:13 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKX00GTC54PSL@szxml04-in.huawei.com>; Mon, 09 May 2011 16:05:13 +0800 (CST) Date: Mon, 09 May 2011 16:08:51 +0800 From: Qin Wu To: avt@ietf.org, xrblock@ietf.org Message-id: <05e001cc0e20$5525ba60$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_TQJUNBu71w4rw48bTcrxxg)" X-Priority: 3 X-MSMail-priority: Normal Cc: magnus.westerlund@ericsson.com Subject: [AVTCORE] Open issue- identity info repetition in draft-ietf-avtcore-monarch X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 08:08:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TQJUNBu71w4rw48bTcrxxg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT In the last IETF meeting, there was discussion on identity info repetition or dupplication. However it was not clear whether new packet type for identity block is needed. Here is some clarification and prososal from my point of view. In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it is assumed there is an RTCP XR packet containing four metrics blocks, reporting on streams from two source. each source is associated with two meric block. In order to reduce overhead to carry duplicated data for all the metric block contained in the same RTCP XR packet, it was proposed by draft-ietf-avtcore-monarch that measurement identity information should be separated from metric block and form independent block. However this proposal save zero octets in figure 2. So the question is whether an identity block is actually needed if identity information only contain SSRC of stream souce, or if just stacking multiple XR Blocks is acceptable. However I re-check with RTCP XR Report Block for Measurement Identity defined in draft-ietf-avt-rtcp-xr-meas-identity-02, identity information included is more than SSRC of stream source. So it should be useful to define new packet type for identity block. However the example figure 2(i.e., only contain SSRC of stream souce) is actually not consistent with report block format defined in draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC of stream source). Also as we know, identity block work has just started from XRBlock WG, Therefore I suggest that the example (Figure 2, and the related discussion) is removed until the identity block is clearly defined in XRBLock. Any Comments or suggestion? Regards! -Qin --Boundary_(ID_TQJUNBu71w4rw48bTcrxxg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
In the last IETF meeting, there was discussion on identity info repetition or dupplication. However it
 was not clear whether new packet type for identity block is needed. Here is some clarification and
prososal from my point of view.
 
In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it is assumed there is an RTCP
 XR packet containing four metrics blocks, reporting on streams from two source.
each source is associated with two meric block.
 
In order to reduce overhead to carry duplicated data for all the metric block contained in
the same RTCP XR packet, it was proposed by draft-ietf-avtcore-monarch that measurement
identity information should be separated from metric block and form independent block.
 
However this proposal save zero octets in figure 2. So the question  is
whether an identity block is actually needed if identity information
only contain SSRC of stream souce, or if just stacking
multiple XR Blocks is acceptable.
 
However I re-check with RTCP XR Report Block for Measurement Identity defined in
draft-ietf-avt-rtcp-xr-meas-identity-02, identity information included is more than
SSRC of stream source. So it should be useful to define new packet type for identity block.
 
However the example figure 2(i.e., only contain SSRC of stream souce) is actually not consistent with report block format defined in
draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC of stream source).
 
Also as we know, identity block work has just started from XRBlock WG,
Therefore  I suggest that the example (Figure 2, and the related discussion) is removed until the identity block is clearly
defined in XRBLock.
 
Any Comments or suggestion?
 
Regards!
-Qin
 
--Boundary_(ID_TQJUNBu71w4rw48bTcrxxg)-- From john.elwell@siemens-enterprise.com Mon May 9 03:34:20 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F16DE07E8 for ; Mon, 9 May 2011 03:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.329 X-Spam-Level: X-Spam-Status: No, score=-105.329 tagged_above=-999 required=5 tests=[AWL=1.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9a4K0+zV0vb for ; Mon, 9 May 2011 03:34:19 -0700 (PDT) Received: from mail21.messagelabs.com (mail21.messagelabs.com [85.158.143.35]) by ietfa.amsl.com (Postfix) with SMTP id 1537BE068D for ; Mon, 9 May 2011 03:34:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-21.messagelabs.com!1304937242!43085192!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 18625 invoked from network); 9 May 2011 10:34:02 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-5.tower-21.messagelabs.com with SMTP; 9 May 2011 10:34:02 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id BB79623F03DB; Mon, 9 May 2011 12:34:17 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 9 May 2011 12:34:17 +0200 From: "Elwell, John" To: "avt@ietf.org" Date: Mon, 9 May 2011 12:34:16 +0200 Thread-Topic: Mandatory nature of RTCP Thread-Index: AcwOM3h+37XBoCL+T6yltj1OV9eVeg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Paul Kyzivat \(pkyzivat\)" Subject: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:34:20 -0000 I am sure I have heard many times experts say that RTCP is a mandatory part= of RTP. However, some people looking into RTP as part of work in the SIPRE= C WG have failed to find convincing normative statements in RFC 3550. Any p= ointers would be appreciated. Thanks, John = From albrecht.schwarz@alcatel-lucent.com Mon May 9 04:20:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CF1E06B5 for ; Mon, 9 May 2011 04:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZtcD5R1WhfQ for ; Mon, 9 May 2011 04:20:17 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 254CAE068D for ; Mon, 9 May 2011 04:20:15 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p49BJeA5000729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 May 2011 13:20:12 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.51]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 9 May 2011 13:20:05 +0200 From: "Schwarz, Albrecht (Albrecht)" To: "Elwell, John" , "avt@ietf.org" Date: Mon, 9 May 2011 13:20:14 +0200 Thread-Topic: Mandatory nature of RTCP Thread-Index: AcwOM3h+37XBoCL+T6yltj1OV9eVegAB2Uqg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "Paul Kyzivat \(pkyzivat\)" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 11:20:18 -0000 RTCP is NOT MANDATORY according RFC 3550. I fail to see any normative statement, too. I could also imagine RTP use cases which do not need at all RTCP.=20 --Albrecht > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Elwell, John > Sent: Montag, 9. Mai 2011 12:34 > To: avt@ietf.org > Cc: Paul Kyzivat (pkyzivat) > Subject: [AVTCORE] Mandatory nature of RTCP >=20 > I am sure I have heard many times experts say that RTCP is a=20 > mandatory part of RTP. However, some people looking into RTP=20 > as part of work in the SIPREC WG have failed to find=20 > convincing normative statements in RFC 3550. Any pointers=20 > would be appreciated. >=20 > Thanks, >=20 > John >=20 > =20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > = From magnus.westerlund@ericsson.com Mon May 9 05:29:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1367FE068D for ; Mon, 9 May 2011 05:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE2fap+1TcLZ for ; Mon, 9 May 2011 05:29:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DC6BAE0685 for ; Mon, 9 May 2011 05:29:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-dd-4dc7de2ab0fa Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CC.16.11171.A2ED7CD4; Mon, 9 May 2011 14:29:30 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 9 May 2011 14:29:29 +0200 Message-ID: <4DC7DE29.80602@ericsson.com> Date: Mon, 9 May 2011 14:29:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "Paul Kyzivat \(pkyzivat\)" , "avt@ietf.org" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 12:29:34 -0000 On 2011-05-09 13:20, Schwarz, Albrecht (Albrecht) wrote: > RTCP is NOT MANDATORY according RFC 3550. > I fail to see any normative statement, too. > I could also imagine RTP use cases which do not need at all RTCP. I think I agree that RTCP is not mandated directly. However, in reality it is required. Only in a few very limited usages can one skip to use RTCP. If one uses UDP as underlying transport then RTCP is needed to fulfill the congestion control requirements in RFC 3550 and the profiles (RFC3551). Both has a SHOULD requirement and that SHOULD exist to allow cases where you have dedicated resource. Then we have all the binding information that RTCP provides, like time synchronization (RTCP SR), which to be synchronized (SDES CNAME). Some single media applications can live without this, but any multi-media do need some of this. There is a reason why RTP doesn't contain so much hard requirements. RTP is a toolbox and applications are suppsed to pick the pieces it needs. And general RTCP is needed in most cases. So I would recommend any one deciding on RTP/RTCP should start with describing what application requirements they have. Then pick the RTP parts. But I will guess that SIPREC is likely to need RTCP. But please do your analysis of what you need. Cheers 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 albrecht.schwarz@alcatel-lucent.com Mon May 9 05:40:19 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0150E0693 for ; Mon, 9 May 2011 05:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfwrCdIfM4w6 for ; Mon, 9 May 2011 05:40:19 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id CB14FE0681 for ; Mon, 9 May 2011 05:40:17 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p49CbG2d001904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 May 2011 14:40:11 +0200 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.51]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 9 May 2011 14:39:52 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Magnus Westerlund Date: Mon, 9 May 2011 14:40:02 +0200 Thread-Topic: [AVTCORE] Mandatory nature of RTCP Thread-Index: AcwORMk5uQVkfApRQ6OREvUQyzs7qgAAP1Og Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9620B9D6789F@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> In-Reply-To: <4DC7DE29.80602@ericsson.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "Paul Kyzivat \(pkyzivat\)" , "avt@ietf.org" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 12:40:19 -0000 Fully agree to that view, Magnus! We may also consider the scenarios of "unidirectional RTP sessions", e.g., = just an RTP media flow from RTP endsystem A to RTP endsystem B, but not vic= e versa. There might be then an associated RTCP control flow, - a bidirectional RTCP= or again a unidirectional RTCP flow (e.g. just from B to A, but not vice v= ersa). Etc =20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Montag, 9. Mai 2011 14:29 > To: Schwarz, Albrecht (Albrecht) > Cc: Elwell, John; avt@ietf.org; Paul Kyzivat (pkyzivat) > Subject: Re: [AVTCORE] Mandatory nature of RTCP >=20 > On 2011-05-09 13:20, Schwarz, Albrecht (Albrecht) wrote: > > RTCP is NOT MANDATORY according RFC 3550. > > I fail to see any normative statement, too. > > I could also imagine RTP use cases which do not need at all RTCP.=20 >=20 > I think I agree that RTCP is not mandated directly. However,=20 > in reality it is required. Only in a few very limited usages=20 > can one skip to use RTCP. >=20 > If one uses UDP as underlying transport then RTCP is needed=20 > to fulfill the congestion control requirements in RFC 3550=20 > and the profiles (RFC3551). Both has a SHOULD requirement and=20 > that SHOULD exist to allow cases where you have dedicated resource. >=20 > Then we have all the binding information that RTCP provides,=20 > like time synchronization (RTCP SR), which to be synchronized=20 > (SDES CNAME). Some single media applications can live without=20 > this, but any multi-media do need some of this. >=20 > There is a reason why RTP doesn't contain so much hard=20 > requirements. RTP is a toolbox and applications are suppsed=20 > to pick the pieces it needs. > And general RTCP is needed in most cases. So I would=20 > recommend any one deciding on RTP/RTCP should start with=20 > describing what application requirements they have. Then pick=20 > the RTP parts. >=20 > But I will guess that SIPREC is likely to need RTCP. But=20 > please do your analysis of what you need. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > = From olivier.crete@collabora.co.uk Mon May 9 07:34:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFF4E07A1 for ; Mon, 9 May 2011 07:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKb+OX-Wi4aR for ; Mon, 9 May 2011 07:34:33 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC65E078C for ; Mon, 9 May 2011 07:34:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 9E588603304 From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: "Ali C. Begen (abegen)" Date: Mon, 09 May 2011 10:34:29 -0400 In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> Organization: Collabora Ltd Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TGyMPUtBSAiCxi+wE3Di" X-Mailer: Evolution 3.0.1 Message-ID: <1304951671.5654.12.camel@TesterBox.tester.ca> Mime-Version: 1.0 Cc: avt@ietf.org Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 14:34:34 -0000 --=-TGyMPUtBSAiCxi+wE3Di Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Sat, 2011-05-07 at 11:47 -0700, Ali C. Begen (abegen) wrote: > > I've implemented the RTP/TFRC draft and it seems to work pretty well. > > That said, it also introduces some level of packet losses. Also, with > > some wifi connections, we have a relatively high rate of non-congestion > > packet loss. For both of these cases, I'd like to implement some kind o= f > > FEC, since losing a single packet tends to give nasty artifacts with > > video (especially using the free video codecs). > >=20 > > It seems the current tendency in recent RFCs related to FEC is to send > > the FEC data as a separate stream from the main data. This seems to go >=20 > That has a lot good features. Please see the drafts in fecframe wg. > The fec framework draft will also tell you that both the source and > fec packets can be sent in their own RTP streams (with different > SSRCs) but within the same UDP flow, if that is what you are worried > about. I saw vague allusions to using different SSRCs, but I couldn't find anything to signal that using SIP/SDP ? > > against the intent of RTP/TFRC since using a second stream may > > effectively double the bandwidth share used by the video. Mixing both >=20 > Huh? It does not matter at all for the overhead whether you send the > fec packets separately or in-band. Also, FEC does not need to double > the bandwidth. It's not about overhead, it's about the fact that it will be two streams, each with its own TFRC state. And with TFRC I would assume that two streams would get roughly twice the bandwidth of one stream (and I guess that's not appropriate). --=20 Olivier Cr=EAte olivier.crete@collabora.co.uk Collabora Ltd --=-TGyMPUtBSAiCxi+wE3Di Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk3H+3UACgkQHTiOWk7ZorvkEACfWcn5oxAx1/NFOVjz8fOd978Q 7VwAniqavYqRnzAkgFn89Wx3CjZk3YW1 =mGG6 -----END PGP SIGNATURE----- --=-TGyMPUtBSAiCxi+wE3Di-- From pkyzivat@cisco.com Mon May 9 06:15:25 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAAAE0720 for ; Mon, 9 May 2011 06:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.351 X-Spam-Level: X-Spam-Status: No, score=-109.351 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQmytkvL9ltX for ; Mon, 9 May 2011 06:15:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (unknown [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6284AE072C for ; Mon, 9 May 2011 06:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2784; q=dns/txt; s=iport; t=1304946919; x=1306156519; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TJCVdTLCAwfPYUnK6Qg/RGYTCX3YvX7POLaW23kpFoI=; b=IbWOdeaqZyLPTKCIe/zv3QZdUGPuPFwhCpAuWkZVsi0dWHp8YPVLCG4p mlqXLw2EBOhel8Iwy60prLEf71oQ8RpAz6++c71W8N4plcfJiW8nJKs3S 1hNuiJVgnguEEkhaY5SsbGzK96hEE0LAqwZfGbJV0/vkuEpxTIRn+5FcA 4=; X-IronPort-AV: E=Sophos;i="4.64,340,1301875200"; d="scan'208";a="444179794" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-1.cisco.com with ESMTP; 09 May 2011 13:15:18 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p49DFH2h020458; Mon, 9 May 2011 13:15:18 GMT Message-ID: <4DC7E8E5.7080609@cisco.com> Date: Mon, 09 May 2011 09:15:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> In-Reply-To: <4DC7DE29.80602@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 09 May 2011 08:07:11 -0700 Cc: "avt@ietf.org" , "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 13:15:26 -0000 Magnus, IMO the first question in this area that comes up for siprec is: 1) must we be able to record the RTP of a call when that RTP doesn't have RTCP? I think the answer is clearly yes. There seems to be enough wiggle room in 3550 that we can't argue that the call is invalid and we don't need to record it. (And in general we should try to record calls even if they *are* invalid.) The next question that comes up is: 2) when recording a call with a media stream that doesn't have RTCP, must the siprec SRC synthesize RTCP in order that it will be available to the receiver? Or can we leave it to the siprec SRS to deal with it? I think we need AVTxxx input into siprec on such issues. Decisions on these things can potentially have significant architectural impact on the way recording is done. Thanks, Paul On 5/9/2011 8:29 AM, Magnus Westerlund wrote: > On 2011-05-09 13:20, Schwarz, Albrecht (Albrecht) wrote: >> RTCP is NOT MANDATORY according RFC 3550. >> I fail to see any normative statement, too. >> I could also imagine RTP use cases which do not need at all RTCP. > > I think I agree that RTCP is not mandated directly. However, in reality > it is required. Only in a few very limited usages can one skip to use RTCP. > > If one uses UDP as underlying transport then RTCP is needed to fulfill > the congestion control requirements in RFC 3550 and the profiles > (RFC3551). Both has a SHOULD requirement and that SHOULD exist to allow > cases where you have dedicated resource. > > Then we have all the binding information that RTCP provides, like time > synchronization (RTCP SR), which to be synchronized (SDES CNAME). Some > single media applications can live without this, but any multi-media do > need some of this. > > There is a reason why RTP doesn't contain so much hard requirements. RTP > is a toolbox and applications are suppsed to pick the pieces it needs. > And general RTCP is needed in most cases. So I would recommend any one > deciding on RTP/RTCP should start with describing what application > requirements they have. Then pick the RTP parts. > > But I will guess that SIPREC is likely to need RTCP. But please do your > analysis of what you need. > > Cheers > > 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 olivier.crete@collabora.co.uk Mon May 9 09:47:08 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A802DE06C3 for ; Mon, 9 May 2011 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yx5edVTA7QlI for ; Mon, 9 May 2011 09:47:08 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 87E74E062A for ; Mon, 9 May 2011 09:47:07 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 15037603471 From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: "Ali C. Begen (abegen)" References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-99xxRROCLJkdFS4/UZGZ" Organization: Collabora Date: Mon, 09 May 2011 12:47:03 -0400 Message-ID: <1304959623.32275.30.camel@TesterTop4> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Cc: avt@ietf.org Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:47:08 -0000 --=-99xxRROCLJkdFS4/UZGZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2011-05-09 at 10:34 -0400, Olivier Cr=C3=AAte wrote: > On Sat, 2011-05-07 at 11:47 -0700, Ali C. Begen (abegen) wrote: > > > I've implemented the RTP/TFRC draft and it seems to work pretty well. > > > That said, it also introduces some level of packet losses. Also, with > > > some wifi connections, we have a relatively high rate of non-congesti= on > > > packet loss. For both of these cases, I'd like to implement some kind= of > > > FEC, since losing a single packet tends to give nasty artifacts with > > > video (especially using the free video codecs). > > >=20 > > > It seems the current tendency in recent RFCs related to FEC is to sen= d > > > the FEC data as a separate stream from the main data. This seems to g= o > >=20 > > That has a lot good features. Please see the drafts in fecframe wg. > > The fec framework draft will also tell you that both the source and > > fec packets can be sent in their own RTP streams (with different > > SSRCs) but within the same UDP flow, if that is what you are worried > > about. >=20 > I saw vague allusions to using different SSRCs, but I couldn't find > anything to signal that using SIP/SDP ? Arg, I found a:ssrc-group.. seems like I'm not very good at reading. --=20 Olivier Cr=C3=AAte olivier.crete@collabora.co.uk --=-99xxRROCLJkdFS4/UZGZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk3IGocACgkQHTiOWk7Zortt3ACeMs77Qv8UaurP+2T0zp1w+wK6 Vm4An1yrAxKsmBnZ9La0FzRKlQmvYC2z =fsXi -----END PGP SIGNATURE----- --=-99xxRROCLJkdFS4/UZGZ-- From abegen@cisco.com Mon May 9 09:58:00 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83ACE07F4 for ; Mon, 9 May 2011 09:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.047 X-Spam-Level: X-Spam-Status: No, score=-9.047 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQwo+0FPPVnr for ; Mon, 9 May 2011 09:57:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id C7678E07F1 for ; Mon, 9 May 2011 09:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2535; q=dns/txt; s=iport; t=1304960279; x=1306169879; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5LQ3f7coP8O9GylPVWqFrJdwDy/E6SHdN0ZRaC9PmxA=; b=bwlt8QSoNghGUjTJIFmMCH3iRi5oMOpeda+vcUhdSxC0JOMZ6+qY/vpu 0628N7rAsXXLT0Qq2U+j1lD9QOhqOGVTW3wHd4xHArHRNGzO5JRfD4Mzc Wgt4clwfExAHNBKWKNumVRzzz17HhixfCe6fiTKbiZc+9YoetxbM5Cm6b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooCAAYcyE2rRDoI/2dsb2JhbACXUo4uaA+IcaBNnX+GDASGQI1Wikw X-IronPort-AV: E=Sophos;i="4.64,341,1301875200"; d="scan'208";a="353314577" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 09 May 2011 16:57:59 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p49Gvx49010496; Mon, 9 May 2011 16:57:59 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 May 2011 09:57:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2011 09:57:26 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EF518CE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <1304951671.5654.12.camel@TesterBox.tester.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] RTP/TFRC + FEC ? Thread-Index: AcwOVkrzKM1X2idiSAeRo8JaobjuXQAE3gZA References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> <1304951671.5654.12.camel@TesterBox.tester.ca> From: "Ali C. Begen (abegen)" To: =?iso-8859-15?Q?Olivier_Cr=EAte?= X-OriginalArrivalTime: 09 May 2011 16:57:59.0480 (UTC) FILETIME=[4049C380:01CC0E6A] Cc: avt@ietf.org Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 16:58:00 -0000 > -----Original Message----- > From: Olivier Cr=EAte [mailto:olivier.crete@collabora.co.uk] > Sent: Monday, May 09, 2011 10:34 AM > To: Ali C. Begen (abegen) > Cc: avt@ietf.org > Subject: RE: [AVTCORE] RTP/TFRC + FEC ? >=20 > On Sat, 2011-05-07 at 11:47 -0700, Ali C. Begen (abegen) wrote: > > > I've implemented the RTP/TFRC draft and it seems to work pretty = well. > > > That said, it also introduces some level of packet losses. Also, = with > > > some wifi connections, we have a relatively high rate of = non-congestion > > > packet loss. For both of these cases, I'd like to implement some = kind of > > > FEC, since losing a single packet tends to give nasty artifacts = with > > > video (especially using the free video codecs). > > > > > > It seems the current tendency in recent RFCs related to FEC is to = send > > > the FEC data as a separate stream from the main data. This seems = to go > > > > That has a lot good features. Please see the drafts in fecframe wg. > > The fec framework draft will also tell you that both the source and > > fec packets can be sent in their own RTP streams (with different > > SSRCs) but within the same UDP flow, if that is what you are worried > > about. >=20 > I saw vague allusions to using different SSRCs, but I couldn't find > anything to signal that using SIP/SDP ? RFC 5576 will help with that. =20 > > > against the intent of RTP/TFRC since using a second stream may > > > effectively double the bandwidth share used by the video. Mixing = both > > > > Huh? It does not matter at all for the overhead whether you send the > > fec packets separately or in-band. Also, FEC does not need to double > > the bandwidth. >=20 > It's not about overhead, it's about the fact that it will be two > streams, each with its own TFRC state. And with TFRC I would assume = that Yeah but I'd imagine you would want to optimize your source and FEC = bitrates somewhat jointly anyway. If your source rate is untouchable, = then only your FEC rate will be variable.=20 > two streams would get roughly twice the bandwidth of one stream (and I > guess that's not appropriate). You are right that it is not appropriate but I don't see why TFRC would = get roughly twice the bw of one stream if you use two TFRC states. You = can easily apply the TFRC limit on the source+FEC, and then try to = allocate that bw between the source and FEC. -acbegen >=20 > -- > Olivier Cr=EAte > olivier.crete@collabora.co.uk > Collabora Ltd From sunseawq@huawei.com Mon May 9 19:19:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B71E0808; Mon, 9 May 2011 19:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLewPDoLynFL; Mon, 9 May 2011 19:19:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B41CAE06B7; Mon, 9 May 2011 19:19:15 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY006WLJRZ2L@szxga03-in.huawei.com>; Tue, 10 May 2011 10:19:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKY00MXSJRYLL@szxga03-in.huawei.com>; Tue, 10 May 2011 10:19:10 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKY009QPJRYKH@szxml04-in.huawei.com>; Tue, 10 May 2011 10:19:10 +0800 (CST) Date: Tue, 10 May 2011 10:22:50 +0800 From: Qin Wu To: avt@ietf.org, xrblock@ietf.org Message-id: <02c801cc0eb9$29031bf0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_ef1CF06owHasyrAb5eJcXQ)" X-Priority: 3 X-MSMail-priority: Normal References: <05e001cc0e20$5525ba60$46298a0a@china.huawei.com> Subject: Re: [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 02:19:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ef1CF06owHasyrAb5eJcXQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Just make correction. My colleague reminds me that the example figure 2 does not conflict with report block format defined in draft-ietf-avt-rtcp-xr-meas-identity-02. Since the detailed measurement identity information following the field SSRC of stream source in the figure 2 is omitted. However as I mentioned, it is not clear how much information is included in identity block until identity block is clearly defined in XRBlock WG. That is why I propose to remove figure 2 and related text from this document. Regards! -Qin ----- Original Message ----- From: Qin Wu To: avt@ietf.org ; xrblock@ietf.org Cc: magnus.westerlund@ericsson.com Sent: Monday, May 09, 2011 4:08 PM Subject: [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch In the last IETF meeting, there was discussion on identity info repetition or dupplication. However it was not clear whether new packet type for identity block is needed. Here is some clarification and prososal from my point of view. In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it is assumed there is an RTCP XR packet containing four metrics blocks, reporting on streams from two source. each source is associated with two meric block. In order to reduce overhead to carry duplicated data for all the metric block contained in the same RTCP XR packet, it was proposed by draft-ietf-avtcore-monarch that measurement identity information should be separated from metric block and form independent block. However this proposal save zero octets in figure 2. So the question is whether an identity block is actually needed if identity information only contain SSRC of stream souce, or if just stacking multiple XR Blocks is acceptable. However I re-check with RTCP XR Report Block for Measurement Identity defined in draft-ietf-avt-rtcp-xr-meas-identity-02, identity information included is more than SSRC of stream source. So it should be useful to define new packet type for identity block. However the example figure 2(i.e., only contain SSRC of stream souce) is actually not consistent with report block format defined in draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC of stream source). Also as we know, identity block work has just started from XRBlock WG, Therefore I suggest that the example (Figure 2, and the related discussion) is removed until the identity block is clearly defined in XRBLock. Any Comments or suggestion? Regards! -Qin ------------------------------------------------------------------------------ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_ef1CF06owHasyrAb5eJcXQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTk5Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFEPg0K PEJPRFkgYmdDb2xvcj0jY2NlOGNmPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i Pkp1c3QgbWFrZSBjb3JyZWN0aW9uLiBNeSBjb2xsZWFndWUgcmVtaW5kcyBtZSANCnRoYXQgdGhl IGV4YW1wbGUgZmlndXJlIDImbmJzcDsgZG9lcyBub3QgY29uZmxpY3Qgd2l0aCByZXBvcnQgYmxv Y2sgZm9ybWF0IA0KZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWF2dC1ydGNwLXhyLW1lYXMtaWRlbnRp dHktMDIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlNp bmNlIHRoZSBkZXRhaWxlZCBtZWFzdXJlbWVudCBpZGVudGl0eSANCmluZm9ybWF0aW9uJm5ic3A7 Zm9sbG93aW5nIHRoZSBmaWVsZCBTU1JDIG9mIHN0cmVhbSBzb3VyY2UmbmJzcDtpbiB0aGUgZmln dXJlIDIgDQppcyBvbWl0dGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5Ib3dldmVyIGFzIEkgbWVudGlvbmVkLCBpdCBpcyBub3QgY2xlYXIgaG93IA0K bXVjaCBpbmZvcm1hdGlvbiBpcyBpbmNsdWRlZCBpbiBpZGVudGl0eSBibG9jayB1bnRpbCBpZGVu dGl0eSBibG9jayBpcyBjbGVhcmx5IA0KZGVmaW5lZCBpbiBYUkJsb2NrIFdHLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGF0IGlzIHdoeSBJIHByb3Bv c2UgdG8gcmVtb3ZlIGZpZ3VyZSAyIGFuZCANCnJlbGF0ZWQgdGV4dCBmcm9tIHRoaXMgZG9jdW1l bnQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRz ITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4tUWluPC9G T05UPjwvRElWPg0KPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPEJM T0NLUVVPVEUgDQpzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5H LUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4t UklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDLzszlOyBCQUNLR1JPVU5EOiAj ZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1zdW5z ZWF3cUBodWF3ZWkuY29tIGhyZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8 L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPlRvOjwvQj4g PEEgdGl0bGU9YXZ0QGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRA aWV0Zi5vcmc8L0E+IDsgPEEgdGl0bGU9eHJibG9ja0BpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRv OnhyYmxvY2tAaWV0Zi5vcmciPnhyYmxvY2tAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgy87M5SI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1tYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20gDQogIGhyZWY9Im1haWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvQT4gDQogIDwvRElWPg0KICA8 RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+PEI+U2VudDo8L0I+IE1vbmRheSwgTWF5IDA5LCAy MDExIDQ6MDggUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUiPjxCPlN1Ympl Y3Q6PC9CPiBbQVZUQ09SRV0gT3BlbiBpc3N1ZS0gaWRlbnRpdHkgaW5mbyANCiAgcmVwZXRpdGlv biBpbmRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0K ICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SW4gdGhlIGxhc3QgSUVURiBtZWV0 aW5nLCB0aGVyZSB3YXMgDQogIGRpc2N1c3Npb24gb24gaWRlbnRpdHkgaW5mbyByZXBldGl0aW9u IG9yIGR1cHBsaWNhdGlvbi4gSG93ZXZlciANCml0PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7d2FzIG5vdCBjbGVhciB3aGV0aGVyIG5ldyBw YWNrZXQgdHlwZSANCiAgZm9yIGlkZW50aXR5IGJsb2NrIGlzIG5lZWRlZC4gSGVyZSBpcyBzb21l IGNsYXJpZmljYXRpb24gYW5kIDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPnByb3Nvc2FsIGZyb20gbXkgcG9pbnQgb2Ygdmlldy48L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JbiB0aGUgZXhhbXBsZSBmaWd1 cmUgMiBvZiBzZWN0aW9uIDUuMiANCiAgaW4mbmJzcDtkcmF0LWlldGYtYXZ0Y29yZS1tb25hcmNo LCBpdCBpcyZuYnNwO2Fzc3VtZWQgdGhlcmUmbmJzcDtpcyZuYnNwO2FuIA0KICBSVENQPC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7WFIgcGFj a2V0IGNvbnRhaW5pbmcmbmJzcDtmb3VyIG1ldHJpY3MgDQogIGJsb2NrcywgcmVwb3J0aW5nIG9u IHN0cmVhbXMgZnJvbSZuYnNwO3R3byBzb3VyY2UuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ZWFjaCBzb3VyY2UgaXMgYXNzb2NpYXRlZCB3aXRoIHR3 byBtZXJpYyANCiAgYmxvY2suPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+SW4gb3JkZXIgdG8gcmVkdWNlIG92ZXJoZWFkIHRvIGNhcnJ5IA0KICBkdXBs aWNhdGVkIGRhdGEgZm9yJm5ic3A7YWxsIHRoZSBtZXRyaWMgYmxvY2sgY29udGFpbmVkIGluIDwv Rk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPnRoZSBzYW1l IFJUQ1AgWFIgcGFja2V0LCBpdCB3YXMgcHJvcG9zZWQgYnkgDQogIGRyYWZ0LWlldGYtYXZ0Y29y ZS1tb25hcmNoIHRoYXQmbmJzcDttZWFzdXJlbWVudCA8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5pZGVudGl0eSBpbmZvcm1hdGlvbiBzaG91bGQgYmUg c2VwYXJhdGVkIA0KICBmcm9tIG1ldHJpYyBibG9jayBhbmQgZm9ybSBpbmRlcGVuZGVudCBibG9j ay48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Ib3dl dmVyIHRoaXMgcHJvcG9zYWwgc2F2ZSZuYnNwO3plcm8gb2N0ZXRzIA0KICBpbiBmaWd1cmUgMi4g U28gdGhlIHF1ZXN0aW9uJm5ic3A7IGlzPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+d2hldGhlciBhbiBpZGVudGl0eSBibG9jayZuYnNwO2lzIGFjdHVh bGx5IA0KICBuZWVkZWQgaWYgaWRlbnRpdHkgaW5mb3JtYXRpb24gPC9GT05UPjwvRElWPg0KICA8 RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+b25seSBjb250YWluIFNTUkMgb2Ygc3Ry ZWFtIHNvdWNlLCBvciBpZiANCiAganVzdCBzdGFja2luZyA8L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5tdWx0aXBsZSBYUiBCbG9ja3MgDQogIGlzJm5i c3A7YWNjZXB0YWJsZS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5Ib3dldmVyIEkgcmUtY2hlY2sgd2l0aCBSVENQIFhSIFJlcG9ydCBCbG9jayANCiAg Zm9yIE1lYXN1cmVtZW50IElkZW50aXR5IGRlZmluZWQgaW48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5kcmFmdC1pZXRmLWF2dC1ydGNwLXhyLW1lYXMt aWRlbnRpdHktMDIsIA0KICBpZGVudGl0eSBpbmZvcm1hdGlvbiBpbmNsdWRlZCBpcyBtb3JlIHRo YW48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TU1JD IG9mIHN0cmVhbSBzb3VyY2UuIFNvIGl0IHNob3VsZCBiZSANCiAgdXNlZnVsIHRvIGRlZmluZSBu ZXcgcGFja2V0IHR5cGUgZm9yIGlkZW50aXR5IGJsb2NrLjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkhvd2V2ZXImbmJzcDt0aGUgZXhhbXBsZSBmaWd1 cmUgMihpLmUuLCBvbmx5IA0KICBjb250YWluIFNTUkMgb2Ygc3RyZWFtIHNvdWNlKSBpcyBhY3R1 YWxseSBub3QgY29uc2lzdGVudCB3aXRoIHJlcG9ydCBibG9jayANCiAgZm9ybWF0IGRlZmluZWQg aW4gPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PmRyYWZ0LWlldGYtYXZ0LXJ0Y3AteHItbWVhcy1pZGVudGl0eS0wMihpLmUuLCBjb250YWluIA0K ICBtb3JlIHRoYW4gU1NSQyBvZiBzdHJlYW0gc291cmNlKS48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5BbHNvIGFzIHdlIGtub3csJm5ic3A7aWRlbnRp dHkgYmxvY2sgd29yayANCiAgaGFzIGp1c3Qgc3RhcnRlZCBmcm9tIFhSQmxvY2sgV0csPC9GT05U PjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhlcmVmb3JlICZu YnNwO0kgc3VnZ2VzdCZuYnNwO3RoYXQgdGhlIA0KICBleGFtcGxlIDwvRk9OVD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPihGaWd1cmUgMiwgYW5kIHRoZSANCiAgcmVsYXRlZCZuYnNwO2Rp c2N1c3Npb24pIGlzIHJlbW92ZWQgdW50aWwgdGhlIGlkZW50aXR5IGJsb2NrIGlzIGNsZWFybHkg DQogIDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmRl ZmluZWQgaW4gWFJCTG9jay48L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5BbnkgQ29tbWVudHMgb3Igc3VnZ2VzdGlvbj88L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzITwvRk9OVD48L0RJVj4NCiAg PERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPi1RaW48L0ZPTlQ+PC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPFA+DQogIDxIUj4NCg0KICA8 UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ QXVkaW8vVmlkZW8gDQogIFRyYW5zcG9ydCBDb3JlIA0KICBNYWludGVuYW5jZTxCUj5hdnRAaWV0 Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ8QlI+PC9C TE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_ef1CF06owHasyrAb5eJcXQ)-- From john.elwell@siemens-enterprise.com Mon May 9 23:10:58 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A078E07DD for ; Mon, 9 May 2011 23:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.403 X-Spam-Level: X-Spam-Status: No, score=-105.403 tagged_above=-999 required=5 tests=[AWL=1.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zB4e6gp0-Iw for ; Mon, 9 May 2011 23:10:57 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id A3119E07F6 for ; Mon, 9 May 2011 23:10:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-5.tower-216.messagelabs.com!1305007854!4438178!1 X-StarScan-Version: 6.2.16; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 31123 invoked from network); 10 May 2011 06:10:54 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-5.tower-216.messagelabs.com with SMTP; 10 May 2011 06:10:54 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 24C541EB83ED; Tue, 10 May 2011 08:10:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 10 May 2011 08:10:54 +0200 From: "Elwell, John" To: Paul Kyzivat , Magnus Westerlund Date: Tue, 10 May 2011 08:10:52 +0200 Thread-Topic: [AVTCORE] Mandatory nature of RTCP Thread-Index: AcwOSyagjXNyOMJ8SOaOP9inuaP+kAAjTxBQ Message-ID: References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> <4DC7E8E5.7080609@cisco.com> In-Reply-To: <4DC7E8E5.7080609@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" , "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 06:10:58 -0000 Thanks, Magnus and Albrecht, for your responses to my questions, and thanks= , Paul, for these supplementary questions of relevance. Answers to these fr= om RTP experts would be appreciated. I suspect the answers depend on the RT= P role the SIPREC Session Recording Client takes, in mediating RTP between = the Communication Session being recorded and the Recording Session from the= Session Recording Client to the Session Recording Server. In addition, we anticipate having a short I-D in the coming weeks on RTP co= nsiderations for SIPREC, and we will socialize that on the AVTCORE list to = try to get the engagement of RTP experts. John > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 09 May 2011 14:15 > To: Magnus Westerlund > Cc: Schwarz, Albrecht (Albrecht); Elwell, John; avt@ietf.org > Subject: Re: [AVTCORE] Mandatory nature of RTCP >=20 > Magnus, >=20 > IMO the first question in this area that comes up for siprec is: >=20 > 1) must we be able to record the RTP of a call when that RTP > doesn't have RTCP? >=20 > I think the answer is clearly yes. > There seems to be enough wiggle room in 3550 that we can't > argue that the call is invalid and we don't need to record it. > (And in general we should try to record calls even if they > *are* invalid.) >=20 > The next question that comes up is: >=20 > 2) when recording a call with a media stream that doesn't have > RTCP, must the siprec SRC synthesize RTCP in order that it will be > available to the receiver? Or can we leave it to the siprec SRS > to deal with it? >=20 > I think we need AVTxxx input into siprec on such issues. > Decisions on these things can potentially have significant=20 > architectural=20 > impact on the way recording is done. >=20 > Thanks, > Paul >=20 > On 5/9/2011 8:29 AM, Magnus Westerlund wrote: > > On 2011-05-09 13:20, Schwarz, Albrecht (Albrecht) wrote: > >> RTCP is NOT MANDATORY according RFC 3550. > >> I fail to see any normative statement, too. > >> I could also imagine RTP use cases which do not need at all RTCP. > > > > I think I agree that RTCP is not mandated directly.=20 > However, in reality > > it is required. Only in a few very limited usages can one=20 > skip to use RTCP. > > > > If one uses UDP as underlying transport then RTCP is needed=20 > to fulfill > > the congestion control requirements in RFC 3550 and the profiles > > (RFC3551). Both has a SHOULD requirement and that SHOULD=20 > exist to allow > > cases where you have dedicated resource. > > > > Then we have all the binding information that RTCP=20 > provides, like time > > synchronization (RTCP SR), which to be synchronized (SDES=20 > CNAME). Some > > single media applications can live without this, but any=20 > multi-media do > > need some of this. > > > > There is a reason why RTP doesn't contain so much hard=20 > requirements. RTP > > is a toolbox and applications are suppsed to pick the=20 > pieces it needs. > > And general RTCP is needed in most cases. So I would=20 > recommend any one > > deciding on RTP/RTCP should start with describing what application > > requirements they have. Then pick the RTP parts. > > > > But I will guess that SIPREC is likely to need RTCP. But=20 > please do your > > analysis of what you need. > > > > Cheers > > > > Magnus Westerlund > > > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >=20 > ---------------------------------------------------------------------- > > > > > = From eve.m.schooler@intel.com Tue May 10 01:06:24 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8F7E079D for ; Tue, 10 May 2011 01:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOEUFTQvO7N9 for ; Tue, 10 May 2011 01:06:23 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id 45B13E06D3 for ; Tue, 10 May 2011 01:06:23 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 10 May 2011 01:06:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.64,345,1301900400"; d="scan'208";a="744925187" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by orsmga001.jf.intel.com with ESMTP; 10 May 2011 01:06:21 -0700 Received: from orsmsx504.amr.corp.intel.com ([10.22.226.207]) by orsmsx603.amr.corp.intel.com ([10.22.226.49]) with mapi; Tue, 10 May 2011 01:06:21 -0700 From: "Schooler, Eve M" To: Stephen Casner , Magnus Westerlund Date: Tue, 10 May 2011 01:06:19 -0700 Thread-Topic: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization Thread-Index: Acv+ADMGt7WqxbNfRZm07NheO85KvwQ5doRA Message-ID: References: <4DAC4F69.1080707@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 10 May 2011 01:51:49 -0700 Cc: "Schooler, Eve M" , IETF AVTCore WG Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:06:24 -0000 Unfortunately I don't remember much about the actual RTP implementation.=20 However a few additional details about the experiment were captured in an=20 earlier post to the [e2e] mailing list. http://www.postel.org/pipermail/end2end-interest/2001-August/001314.html As Steve points out, one focus of the work was to understand the proper hoo= ks=20 needed by a session orchestration protocol (pun intended!) to be able to=20 establish and negotiate synchronization constraints among session participa= nts. E. Eve M. Schooler, PhD Intel Labs, SC12-303 3600 Juliette Lane w: +1 408.765.1591 Santa Clara, CA 95054 f: +1 408.653.8511 -----Original Message----- From: Stephen Casner [mailto:casner@acm.org]=20 Sent: Monday, April 18, 2011 12:38 PM To: Magnus Westerlund Cc: IETF AVTCore WG; Schooler, Eve M Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media= synchronization At the 29th IETF in Seattle in 1994, Julio Escobar gave a presentation about the Flow Synchronization Protocol developed along with Craig Partridge and Debra Deutsch at BBN. This protocol was designed to support multiple synchronization goals including inter-destination media playout synchronization. The proceedings from that meeting say this: At the end of the second session, there were two additional presentations. Julio Escobar gave a report on the use of RTP to support the Synchronization Protocol developed at BBN. The only requirement not satisfied by RTP was the need to communicate the calculated synchronization delays among the destination processors; this could be added to the control packet as application-specific data. This was during the period when RTPv2 was being designed, so the important question was whether the base RTP protocol needed any additions. As the paragraph states, the conclusion was that all that was needed was some information in RTCP. As I recall, the decision at that time was not to define any specific RTCP packet types yet, but to just use the APP packet for experiments. Note that the Flow Synchronization Protocol also included messages of its own that would be used in conjunction with something more like a session establishment protocol. This protocol was used for a demonstration at the ACM Multimedia conference in October, 1994 of a distributed music trio. From the proceedings: This demonstration will show the ability to display (play out) a music orchestra at the conference site by remotely synchronizing the audio and video from musicians across the country. It will serve to demonstrate the current capabilities of multi-media synchronization. The demonstration will synchronize across the continental USA two live players and one repeater site, this delivering a synchronized music trio performance the the demo site in spite of delay variations through the internetworks that carry the aduio and video flows. The demonstration will also include Graphical User Interface displays of the measured and managed delays in the system to show in real-time the way in which the synchronization protocol operates. The audience will be able to experience the difference between synchronized and unsynchronized music performances. For this demonstration, the synchronization goal was different from synchronizing playout at multiple sites at the same time. Instead, it was to synchronize the mixing of multiple sound sources that were created at multiple sites at the same "logical" time. In this case, the piano part of a Haydn trio was pre-recorded and served as the conductor or metronome. It was originated from one network site and sent to three other sites where two live performers (Eve Schooler and Martha Steenstrup) listened to the piano part and played along the violin and cello parts that were transmitted in new streams, while the third site repeated (forwarded) the piano part. Then listeners in multiple other sites received the three streams and played them in sync. Playout could have been sychronized to be at the same time as well, but that goal was unnecessary for this demonstration. I apologize that I do not remember the details of the implementation that we did with RTP for this demo. Perhaps Eve remembers. I might be able to find something in old email if it turns out to be useful. I urge those who are interested in this synchronization work to take a look at the BBN Flow Synchronization Protocol, if you have not already done so, and to consider a more general set of synchronization goals. I found these references: A paper in IEEE/ACM Transactions on Networking from April, 1994, in the ACM Digital Library: http://portal.acm.org/citation.cfm?id=3D187042 An earlier paper from March, 1991 that is freely available: ftp://cs.ucl.ac.uk/nets/docs/distributed-systems/msfs.ps.Z Another free paper, undated but later than February 1992 based on a reference date: ftp://cs.ucl.ac.uk/mice/misc_papers/flow_sync_control.ps.gz A slide presentation by Eve Schooler from the Network Music Festival in Septemper 1993 that reported on an earlier demo of the same scenario for our funding sponsors is here: ftp://ftp.isi.edu//pub/hpcc-papers/mmc/NetMusicFest.ps Ghostscript barfed on that, but the Mac was able to translate to PDF, so I put it here: ftp://ftp.packetdesign.com/outgoing/casner/NetMusicFest.pdf -- Steve On Mon, 18 Apr 2011, Magnus Westerlund wrote: > WG, > > At the WG meeting in Prague we had a show of hands if we should create a > WG work item for RTCP for inter-destination media synchronization. Along > the lines described by > https://datatracker.ietf.org/doc/draft-brandenburg-avtcore-rtcp-for-idms/= . > > There where 5 persons in the room indicating interest. We now would like > to judge the interest on the mailing list for a new WG item. Please > indicate your support and willingness to contribute. If you think it > shouldn't be done please voice that opinion also. > > This call runs for 2 weeks until Wednesday the 4th of May. > > Regards > > Magnus Westerlund > > AVTCore chair > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From magnus.westerlund@ericsson.com Tue May 10 02:02:02 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFF8E094F for ; Tue, 10 May 2011 02:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvllrdzYhlkZ for ; Tue, 10 May 2011 02:02:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED4E0960 for ; Tue, 10 May 2011 02:02:00 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-1f-4dc8ff07f359 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.3B.28525.70FF8CD4; Tue, 10 May 2011 11:01:59 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 May 2011 11:01:56 +0200 Message-ID: <4DC8FF04.3090408@ericsson.com> Date: Tue, 10 May 2011 11:01:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Kyzivat References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> <4DC7E8E5.7080609@cisco.com> In-Reply-To: <4DC7E8E5.7080609@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 09:02:03 -0000 On 2011-05-09 15:15, Paul Kyzivat wrote: > Magnus, > > IMO the first question in this area that comes up for siprec is: > > 1) must we be able to record the RTP of a call when that RTP > doesn't have RTCP? > > I think the answer is clearly yes. > There seems to be enough wiggle room in 3550 that we can't > argue that the call is invalid and we don't need to record it. > (And in general we should try to record calls even if they > *are* invalid.) Agree that you will need to be able to record it. > > The next question that comes up is: > > 2) when recording a call with a media stream that doesn't have > RTCP, must the siprec SRC synthesize RTCP in order that it will be > available to the receiver? Or can we leave it to the siprec SRS > to deal with it? Looking at the architecture pictures in Section 3.1 in http://tools.ietf.org/html/draft-ietf-siprec-architecture-02 I get the impression that the RTP session between the SRC and the SRS appears to be a separate RTP session from the one that is being recorded. In those case I think it is important that the SRC monitors the media flow to the SRS to ensure that it is being delivered successfully and with sufficient quality without causing any persistent congestion. Thus I think a requirement on using RTCP between the SRC and SRS appears necessary. In that context you will have to answer the question what to do if the SRC sees persistent congestion on the path to the SRS. Can it do some media manipulation to reduce bit-rate, for example by repacketizing audion into multiple frames per packet to reduce packet overhead. At the minimal it may have to stop sending the recording stream if there are insufficient resources. > > I think we need AVTxxx input into siprec on such issues. > Decisions on these things can potentially have significant architectural > impact on the way recording is done. > We should do our best to provide feedback on such questions. Cheers 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 magnus.westerlund@ericsson.com Tue May 10 02:05:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DCCE096E for ; Tue, 10 May 2011 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LV8c39wc8Jz for ; Tue, 10 May 2011 02:05:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 498BBE0967 for ; Tue, 10 May 2011 02:05:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-85-4dc8ffc45c1f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 32.9F.11171.4CFF8CD4; Tue, 10 May 2011 11:05:08 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 May 2011 11:05:07 +0200 Message-ID: <4DC8FFC3.5060508@ericsson.com> Date: Tue, 10 May 2011 11:05:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> <1304951671.5654.12.camel@TesterBox.tester.ca> <04CAD96D4C5A3D48B1919248A8FE0D540EF518CE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540EF518CE@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: Colin Perkins , Ladan Gharai , "avt@ietf.org" Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 09:05:27 -0000 On 2011-05-09 18:57, Ali C. Begen (abegen) wrote: >> two streams would get roughly twice the bandwidth of one stream >> (and I guess that's not appropriate). > > You are right that it is not appropriate but I don't see why TFRC > would get roughly twice the bw of one stream if you use two TFRC > states. You can easily apply the TFRC limit on the source+FEC, and > then try to allocate that bw between the source and FEC. > I think this is a comment that the TFRC draft authors should take to heart that the document will need to have a discussion on how to aggregate multiple SSRCs into a single TFRC flow state. Cheers 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 magnus.westerlund@ericsson.com Tue May 10 02:25:08 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED006E06F2 for ; Tue, 10 May 2011 02:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwCLmooq+jLG for ; Tue, 10 May 2011 02:25:08 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3701BE06DC for ; Tue, 10 May 2011 02:25:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-e5-4dc904704032 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.AE.11171.07409CD4; Tue, 10 May 2011 11:25:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 10 May 2011 11:25:02 +0200 Message-ID: <4DC9046E.6060007@ericsson.com> Date: Tue, 10 May 2011 11:25:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Qin Wu References: <4DB9224E.8000900@ericsson.com> <049401cc0e0e$d5b34b50$46298a0a@china.huawei.com> In-Reply-To: <049401cc0e0e$d5b34b50$46298a0a@china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Minutes for Prague IETF 80 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 09:25:09 -0000 On 2011-05-09 08:03, Qin Wu wrote: > One typo needs to be fixed as regarding to draft-hunt-avtcore-monarch-01 > identity info repletion ---> identity info repetition Thanks, This is now fixed in the online version. Cheers 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 olivier.crete@collabora.co.uk Tue May 10 07:29:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2CE0767 for ; Tue, 10 May 2011 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ3nIH7JiRw6 for ; Tue, 10 May 2011 07:29:03 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id 78578E0748 for ; Tue, 10 May 2011 07:29:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 2031B11993AA From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: Magnus Westerlund Date: Tue, 10 May 2011 10:19:07 -0400 In-Reply-To: <4DC8FFC3.5060508@ericsson.com> References: <1304729510.32275.29.camel@TesterTop4> <04CAD96D4C5A3D48B1919248A8FE0D540EF516F0@xmb-sjc-215.amer.cisco.com> <1304951671.5654.12.camel@TesterBox.tester.ca> <04CAD96D4C5A3D48B1919248A8FE0D540EF518CE@xmb-sjc-215.amer.cisco.com> <4DC8FFC3.5060508@ericsson.com> Organization: Collabora Ltd Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-MzjnTkIuIAdgsLQ0zMvV" X-Mailer: Evolution 3.0.1 Message-ID: <1305037150.5654.15.camel@TesterBox.tester.ca> Mime-Version: 1.0 Cc: Ladan Gharai , "avt@ietf.org" , Colin Perkins Subject: Re: [AVTCORE] RTP/TFRC + FEC ? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 14:29:04 -0000 --=-MzjnTkIuIAdgsLQ0zMvV Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Tue, 2011-05-10 at 11:05 +0200, Magnus Westerlund wrote: > On 2011-05-09 18:57, Ali C. Begen (abegen) wrote: >=20 > >> two streams would get roughly twice the bandwidth of one stream > >> (and I guess that's not appropriate). > >=20 > > You are right that it is not appropriate but I don't see why TFRC > > would get roughly twice the bw of one stream if you use two TFRC > > states. You can easily apply the TFRC limit on the source+FEC, and > > then try to allocate that bw between the source and FEC. > >=20 >=20 > I think this is a comment that the TFRC draft authors should take to > heart that the document will need to have a discussion on how to > aggregate multiple SSRCs into a single TFRC flow state. Actually, aggregating multiple SSRCs into one RTP/TFRC stream is problematic as TFRC expects to have a linear sequence number. That means we need to put a TFRC seqnum inside the RTP header extension, can't use the RTP one. I noticed that Google is already doing something like that in their we-like-standards-but-not-quite RTP/TFRC implementation in Google Talk. --=20 Olivier Cr=EAte olivier.crete@collabora.co.uk Collabora Ltd --=-MzjnTkIuIAdgsLQ0zMvV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEABECAAYFAk3JSVsACgkQHTiOWk7ZoruZZACffapskKL1BogGKMJSxHxk/uXJ iJkAniX8cwes4xFAMo+2I9iV2ylDs+0s =yI5E -----END PGP SIGNATURE----- --=-MzjnTkIuIAdgsLQ0zMvV-- From csp@csperkins.org Wed May 11 09:04:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2092DE0848 for ; Wed, 11 May 2011 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ve7YiQ0KL+7 for ; Wed, 11 May 2011 09:04:53 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id C5C63E0849 for ; Wed, 11 May 2011 09:04:52 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QKBu7-0003vp-cR; Wed, 11 May 2011 16:04:51 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Colin Perkins X-Priority: 3 In-Reply-To: <003001cc0bd3$66244600$46298a0a@china.huawei.com> Date: Wed, 11 May 2011 17:04:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7C2CC5D8-ECB0-4D26-806D-990C2C56537B@csperkins.org> References: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> <003001cc0bd3$66244600$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 16:04:54 -0000 Qin, This version is better, but I'm still not sure it fully clarifies when = third-party loss reports should be sent in place of NACKs. In = particular: - The abstract still reads as-if the draft is solely focussed on = feedback suppression. I suggest it could be rephrased something like: = =93In a large RTP session using the RTCP feedback mechanism defined in = RFC 4585, a feedback target may experience transient overload if some = event causes a large number of receivers to send feedback at once. This = overload is usually avoided by ensuring that feedback reports are = forwarded to all receivers, allowing them to avoid sending duplicate = feedback reports. However, there are certain cases where it is not = possible to forward feedback reports, and this may allow feedback = implosion. This memo defines a new RTCP third-party loss report that can = be used to inform receivers that a feedback target is aware of some loss = event, allowing them to suppress feedback. Associated SDP signalling is = also defined.=94 - Section 3, 2nd paragraph: this doesn=92t clearly differentiate when a = third-party loss report should be used compared to a NACK. In = particular, the sentence =93Upon downstream loss is reported to the = intermediary, the intermediary SHOULD send the Third Party Loss report = to the other downstream receivers which are not aware of the loss = reports, to inform those receivers of the loss and suppress their = feedback=94 needs to be expanded to discuss what =93are not aware of the = loss reports=94 means in this context (i.e., when it's not possible to = distribute the NACKs to all receivers). - Section 3, 3rd paragraph: this would be much clearer if it discussed = when it=92s appropriate to monitor the feedback and send a third-party = loss report to downstream receivers, rather than just reflect NACKs back = downstream. - Section 6.1, 2nd paragraph: when in Simple Feedback Mode, NACKs are = reflected and there=92s no need for the third-party loss report. The = downstream third-party loss report is only generated when in = Distribution Source Feedback Summary mode. I=92m not sure it makes sense = to write generic rules in Section 6.1, instead of writing specific rules = for each of the two feedback modes in Section 61.1 and 6.1.2. Cheers, Colin On 6 May 2011, at 10:53, Qin Wu wrote: > Hi, > The new version of draft-ietf-avtcore-feedback-suppression-rtp is = available at > = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression= -rtp-02.txt > which address the recent comments from Colin on the list. > The main change is to clarify the use of third party loss report and = update the title and relevant sections=20 > to focus on third party loss report. > The diff is at: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-feedback-supressio= n-rtp-02 > Please check if you are comfortable with the changes in this version. > Any comments? >=20 > Regards! > -Qin > ----- Original Message -----=20 > From: > To: > Cc: > Sent: Friday, May 06, 2011 5:39 PM > Subject: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt >=20 >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >>=20 >> Title : RTCP Extension for Third-party Loss Report >> Author(s) : Qin Wu >> Frank Xia >> Roni Even >> Filename : draft-ietf-avtcore-feedback-supression-rtp-02.txt >> Pages : 18 >> Date : 2011-05-06 >>=20 >> In a large RTP session using the RTCP feedback mechanism defined in >> RFC 4585, a media source or middlebox may experience transient >> overload if some event causes a large number of receivers to send >> feedback at once. This feedback implosion can be mitigated if the >> device suffering from overload can send a third party loss report >> message to the receivers to inhibit further feedback. This memo >> defines RTCP Extension for third party loss report, to suppress NACK >> and FIR feedback requests. It also defines associated SDP = signaling. >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression= -rtp-02.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-02.txt >> _______________________________________________ >> 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 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Wed May 11 20:54:57 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32024E08CC for ; Wed, 11 May 2011 20:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.845 X-Spam-Level: X-Spam-Status: No, score=-4.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyu93-9-dwNv for ; Wed, 11 May 2011 20:54:55 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 60ED3E08A4 for ; Wed, 11 May 2011 20:54:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200GMADG7GV@szxga03-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 11:52:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL2002FUDG7U9@szxga03-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 11:52:55 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL2006LGDG7CI@szxml04-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 11:52:55 +0800 (CST) Date: Thu, 12 May 2011 11:56:34 +0800 From: Qin Wu To: Colin Perkins Message-id: <014f01cc1058$989a3070$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_z829NB1+aXzCTSXgE/AbvQ)" X-Priority: 3 X-MSMail-priority: Normal References: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> <003001cc0bd3$66244600$46298a0a@china.huawei.com> <7C2CC5D8-ECB0-4D26-806D-990C2C56537B@csperkins.org> Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 03:54:57 -0000 This is a multi-part message in MIME format. --Boundary_(ID_z829NB1+aXzCTSXgE/AbvQ) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 VGhpcyB2ZXJzaW9uIGlzIGJldHRlciwgYnV0IEknbSBzdGlsbCBub3Qgc3VyZSBpdCBmdWxseSBj bGFyaWZpZXMgd2hlbiB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydHMgc2hvdWxkIGJlIHNlbnQgaW4g cGxhY2Ugb2YgTkFDS3MuIEluIHBhcnRpY3VsYXI6DQoNCi0gVGhlIGFic3RyYWN0IHN0aWxsIHJl YWRzIGFzLWlmIHRoZSBkcmFmdCBpcyBzb2xlbHkgZm9jdXNzZWQgb24gZmVlZGJhY2sgc3VwcHJl c3Npb24uIEkgc3VnZ2VzdCBpdCBjb3VsZCBiZSByZXBocmFzZWQgc29tZXRoaW5nIGxpa2U6IJNJ biBhIGxhcmdlIFJUUCBzZXNzaW9uIHVzaW5nIHRoZSBSVENQIGZlZWRiYWNrIG1lY2hhbmlzbSBk ZWZpbmVkIGluIFJGQyA0NTg1LCBhIGZlZWRiYWNrIHRhcmdldCBtYXkgZXhwZXJpZW5jZSB0cmFu c2llbnQgb3ZlcmxvYWQgaWYgc29tZSBldmVudCBjYXVzZXMgYSBsYXJnZSBudW1iZXIgb2YgcmVj ZWl2ZXJzIHRvIHNlbmQgZmVlZGJhY2sgYXQgb25jZS4gVGhpcyBvdmVybG9hZCBpcyB1c3VhbGx5 IGF2b2lkZWQgYnkgZW5zdXJpbmcgdGhhdCBmZWVkYmFjayByZXBvcnRzIGFyZSBmb3J3YXJkZWQg dG8gYWxsIHJlY2VpdmVycywgYWxsb3dpbmcgdGhlbSB0byBhdm9pZCBzZW5kaW5nIGR1cGxpY2F0 ZSBmZWVkYmFjayByZXBvcnRzLiBIb3dldmVyLCB0aGVyZSBhcmUgY2VydGFpbiBjYXNlcyB3aGVy ZSBpdCBpcyBub3QgcG9zc2libGUgdG8gZm9yd2FyZCBmZWVkYmFjayByZXBvcnRzLCBhbmQgdGhp cyBtYXkgYWxsb3cgZmVlZGJhY2sgaW1wbG9zaW9uLiBUaGlzIG1lbW8gZGVmaW5lcyBhIG5ldyBS VENQIHRoaXJkLXBhcnR5IGxvc3MgcmVwb3J0IHRoYXQgY2FuIGJlIHVzZWQgdG8gaW5mb3JtIHJl Y2VpdmVycyB0aGF0IGEgZmVlZGJhY2sgdGFyZ2V0IGlzIGF3YXJlIG9mIHNvbWUgbG9zcyBldmVu dCwgYWxsb3dpbmcgdGhlbSB0byBzdXBwcmVzcyBmZWVkYmFjay4gQXNzb2NpYXRlZCBTRFAgc2ln bmFsbGluZyBpcyBhbHNvIGRlZmluZWQulA0KDQpbUWluXTogU29ycnksIEkgZm9yZ290IHRvIHVw ZGF0ZSB0aGUgYWJzdHJhY3QuDQpZZXMsIFlvdXIgcHJvcG9zZWQgY2hhbmdlIGlzIHJlc29uYWJs ZSBhbmQgY2xlYXIuIFRoYW5rcy4NCg0KLSBTZWN0aW9uIDMsIDJuZCBwYXJhZ3JhcGg6IHRoaXMg ZG9lc26SdCBjbGVhcmx5IGRpZmZlcmVudGlhdGUgd2hlbiBhIHRoaXJkLXBhcnR5IGxvc3MgcmVw b3J0IHNob3VsZCBiZSB1c2VkIGNvbXBhcmVkIHRvIGEgTkFDSy4gSW4gcGFydGljdWxhciwgdGhl IHNlbnRlbmNlIJNVcG9uIGRvd25zdHJlYW0gbG9zcyBpcyByZXBvcnRlZCB0byB0aGUgaW50ZXJt ZWRpYXJ5LCB0aGUgaW50ZXJtZWRpYXJ5IFNIT1VMRCBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3Nz IHJlcG9ydCB0byB0aGUgb3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMgd2hpY2ggYXJlIG5vdCBh d2FyZSBvZiB0aGUgbG9zcyByZXBvcnRzLCB0byBpbmZvcm0gdGhvc2UgcmVjZWl2ZXJzIG9mIHRo ZSBsb3NzIGFuZCBzdXBwcmVzcyB0aGVpciBmZWVkYmFja5QgbmVlZHMgdG8gYmUgZXhwYW5kZWQg dG8gZGlzY3VzcyB3aGF0IJNhcmUgbm90IGF3YXJlIG9mIHRoZSBsb3NzIHJlcG9ydHOUIG1lYW5z IGluIHRoaXMgY29udGV4dCAoaS5lLiwgd2hlbiBpdCdzIG5vdCBwb3NzaWJsZSB0byBkaXN0cmli dXRlIHRoZSBOQUNLcyB0byBhbGwgcmVjZWl2ZXJzKS4NCg0KW1Fpbl06IFllcywgeW91IGFyZSBj b3JyZWN0LiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyBwcm9wb3NhbDoNCiINCkhvd2V2ZXIsIGlu IHNvbWUgY2FzZXMgd2hlcmUgcGFja2V0IGxvc3Mgb2NjdXJzIGluIHRoZSBkb3duc3RyZWFtIG9m IHRoZXNlIGludGVybWVkaWF0ZXMsIA0KaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgaW50ZXJt ZWRpYXRlcyB0byBkaXN0cmlidXRlIHRoZSBOQUNLcyB0byBhbGwgcmVjZWl2ZXJzLiBJbiBzdWNo IGNhc2VzLCBkb3duc3RyZWFtIGxvc3MgbmVlZHMNCiB0byBiZSBmaXJzdGx5IHJlcG9ydGVkIHRv IHRoZSBpbnRlcm1lZGlhcnkgaW4gc29tZSB3YXkuIFVwb24gZG93bnN0cmVhbSBsb3NzIGlzIHJl cG9ydGVkIHRvIHRoZQ0KIGludGVybWVkaWFyeSwgdGhlIGludGVybWVkaWFyeSBTSE9VTEQgc2Vu ZCB0aGUgVGhpcmQgUGFydHkgTG9zcyByZXBvcnQgdG8gdGhlIG90aGVyIGRvd25zdHJlYW0gcmVj ZWl2ZXJzLg0KIg0KDQotIFNlY3Rpb24gMywgM3JkIHBhcmFncmFwaDogdGhpcyB3b3VsZCBiZSBt dWNoIGNsZWFyZXIgaWYgaXQgZGlzY3Vzc2VkIHdoZW4gaXSScyBhcHByb3ByaWF0ZSB0byBtb25p dG9yIHRoZSBmZWVkYmFjayBhbmQgc2VuZCBhIHRoaXJkLXBhcnR5IGxvc3MgcmVwb3J0IHRvIGRv d25zdHJlYW0gcmVjZWl2ZXJzLCByYXRoZXIgdGhhbiBqdXN0IHJlZmxlY3QgTkFDS3MgYmFjayBk b3duc3RyZWFtLg0KDQpbUWluXTogT2theS4gSSB0aGluayB0aGUgYW5zd2VyIHRvIHdoZW4gaXMg DQoiDQpVcG9uIHJlY2VpdmluZyBkb3duc3RyZWFtIGxvc3MgcmVwb3J0IGluIHRoZSB3YXkgb2Yg c3VjaCBmZWVkYmFjayByZXBvcnQgb25seSBkZXN0aW5lZCBmb3IgbWVkaWEgc291cmNlLCB0aGUg bWVkaWEgc291cmNlIFNIT1VMRCBzZW5kIHRoZSBUaGlyZA0KUGFydHkgTG9zcyBSZXBvcnQgbWVz c2FnZXMgdG8gdGhlIHJlY2VpdmVycy4NCiINCg0KLSBTZWN0aW9uIDYuMSwgMm5kIHBhcmFncmFw aDogd2hlbiBpbiBTaW1wbGUgRmVlZGJhY2sgTW9kZSwgTkFDS3MgYXJlIHJlZmxlY3RlZCBhbmQg dGhlcmWScyBubyBuZWVkIGZvciB0aGUgdGhpcmQtcGFydHkgbG9zcyByZXBvcnQuIFRoZSBkb3du c3RyZWFtIHRoaXJkLXBhcnR5IGxvc3MgcmVwb3J0IGlzIG9ubHkgZ2VuZXJhdGVkIHdoZW4gaW4g RGlzdHJpYnV0aW9uIFNvdXJjZSBGZWVkYmFjayBTdW1tYXJ5IG1vZGUuIEmSbSBub3Qgc3VyZSBp dCBtYWtlcyBzZW5zZSB0byB3cml0ZSBnZW5lcmljIHJ1bGVzIGluIFNlY3Rpb24gNi4xLCBpbnN0 ZWFkIG9mIHdyaXRpbmcgc3BlY2lmaWMgcnVsZXMgZm9yIGVhY2ggb2YgdGhlIHR3byBmZWVkYmFj ayBtb2RlcyBpbiBTZWN0aW9uIDYxLjEgYW5kIDYuMS4yLg0KDQpbUWluXTogWWVzLCBpdCBtb3Jl IG1ha2Ugc2Vuc2UgdG8gbWFrZSBpdCBpbiB0aGUgc2VjdGlvbiA2LjEuIEkgd2lsbCB1cGRhdGUg c2VjdGlvbiA2LjEsIHNlY3Rpb24gNi4xLjEgYW5kIHNlY3Rpb24gNi4xLjIgdG8gcmVmbGVjdCB0 aGlzLg0KDQpDaGVlcnMsDQpDb2xpbg0KDQoNCg0KDQpPbiA2IE1heSAyMDExLCBhdCAxMDo1Mywg UWluIFd1IHdyb3RlOg0KPiBIaSwNCj4gVGhlIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtYXZ0 Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1ydHAgaXMgYXZhaWxhYmxlIGF0DQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1z dXByZXNzaW9uLXJ0cC0wMi50eHQNCj4gd2hpY2ggYWRkcmVzcyB0aGUgcmVjZW50IGNvbW1lbnRz IGZyb20gQ29saW4gb24gdGhlIGxpc3QuDQo+IFRoZSBtYWluIGNoYW5nZSBpcyB0byBjbGFyaWZ5 IHRoZSB1c2Ugb2YgdGhpcmQgcGFydHkgbG9zcyByZXBvcnQgYW5kIHVwZGF0ZSB0aGUgdGl0bGUg YW5kIHJlbGV2YW50IHNlY3Rpb25zIA0KPiB0byBmb2N1cyBvbiB0aGlyZCBwYXJ0eSBsb3NzIHJl cG9ydC4NCj4gVGhlIGRpZmYgaXMgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyDQo+IFBs ZWFzZSBjaGVjayBpZiB5b3UgYXJlIGNvbWZvcnRhYmxlIHdpdGggdGhlIGNoYW5nZXMgaW4gdGhp cyB2ZXJzaW9uLg0KPiBBbnkgY29tbWVudHM/DQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+DQo+IFRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBDYzogPGF2dEBpZXRmLm9y Zz4NCj4gU2VudDogRnJpZGF5LCBNYXkgMDYsIDIwMTEgNTozOSBQTQ0KPiBTdWJqZWN0OiBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0 DQo+IA0KPiANCj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV29ya2lu ZyBHcm91cCBvZiB0aGUgSUVURi4NCj4+IA0KPj4gVGl0bGUgICAgICAgICAgIDogUlRDUCBFeHRl bnNpb24gZm9yIFRoaXJkLXBhcnR5IExvc3MgUmVwb3J0DQo+PiBBdXRob3IocykgICAgICAgOiBR aW4gV3UNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5rIFhpYQ0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgUm9uaSBFdmVuDQo+PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0DQo+PiBQYWdlcyAgICAgICAg ICAgOiAxOA0KPj4gRGF0ZSAgICAgICAgICAgIDogMjAxMS0wNS0wNg0KPj4gDQo+PiAgSW4gYSBs YXJnZSBSVFAgc2Vzc2lvbiB1c2luZyB0aGUgUlRDUCBmZWVkYmFjayBtZWNoYW5pc20gZGVmaW5l ZCBpbg0KPj4gIFJGQyA0NTg1LCBhIG1lZGlhIHNvdXJjZSBvciBtaWRkbGVib3ggbWF5IGV4cGVy aWVuY2UgdHJhbnNpZW50DQo+PiAgb3ZlcmxvYWQgaWYgc29tZSBldmVudCBjYXVzZXMgYSBsYXJn ZSBudW1iZXIgb2YgcmVjZWl2ZXJzIHRvIHNlbmQNCj4+ICBmZWVkYmFjayBhdCBvbmNlLiAgVGhp cyBmZWVkYmFjayBpbXBsb3Npb24gY2FuIGJlIG1pdGlnYXRlZCBpZiB0aGUNCj4+ICBkZXZpY2Ug c3VmZmVyaW5nIGZyb20gb3ZlcmxvYWQgY2FuIHNlbmQgYSB0aGlyZCBwYXJ0eSBsb3NzIHJlcG9y dA0KPj4gIG1lc3NhZ2UgdG8gdGhlIHJlY2VpdmVycyB0byBpbmhpYml0IGZ1cnRoZXIgZmVlZGJh Y2suICBUaGlzIG1lbW8NCj4+ICBkZWZpbmVzIFJUQ1AgRXh0ZW5zaW9uIGZvciB0aGlyZCBwYXJ0 eSBsb3NzIHJlcG9ydCwgdG8gc3VwcHJlc3MgTkFDSw0KPj4gIGFuZCBGSVIgZmVlZGJhY2sgcmVx dWVzdHMuICBJdCBhbHNvIGRlZmluZXMgYXNzb2NpYXRlZCBTRFAgc2lnbmFsaW5nLg0KPj4gDQo+ PiANCj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJl c3Npb24tcnRwLTAyLnR4dA0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPj4gDQo+PiBUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6 DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29y ZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0wMi50eHQNCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0 DQo+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rvcmllczog aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4gb3IgZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFu Y2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYXZ0DQoNCg0KDQotLSANCkNvbGluIFBlcmtpbnMNCmh0dHA6Ly9jc3BlcmtpbnMub3JnLw0K DQoNCg== --Boundary_(ID_z829NB1+aXzCTSXgE/AbvQ) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRP UiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTk5Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFk+DQo8RElWPlRoaXMgdmVyc2lvbiBpcyBiZXR0ZXIsIGJ1dCBJJ20gc3RpbGwg bm90IHN1cmUgaXQgZnVsbHkgY2xhcmlmaWVzIHdoZW4gDQp0aGlyZC1wYXJ0eSBsb3NzIHJlcG9y dHMgc2hvdWxkIGJlIHNlbnQgaW4gcGxhY2Ugb2YgTkFDS3MuIEluIHBhcnRpY3VsYXI6PC9ESVY+ DQo8RElWPjxCUj4tIFRoZSBhYnN0cmFjdCBzdGlsbCByZWFkcyBhcy1pZiB0aGUgZHJhZnQgaXMg c29sZWx5IGZvY3Vzc2VkIG9uIA0KZmVlZGJhY2sgc3VwcHJlc3Npb24uIEkgc3VnZ2VzdCBpdCBj b3VsZCBiZSByZXBocmFzZWQgc29tZXRoaW5nIGxpa2U6IJNJbiBhIA0KbGFyZ2UgUlRQIHNlc3Np b24gdXNpbmcgdGhlIFJUQ1AgZmVlZGJhY2sgbWVjaGFuaXNtIGRlZmluZWQgaW4gUkZDIDQ1ODUs IGEgDQpmZWVkYmFjayB0YXJnZXQgbWF5IGV4cGVyaWVuY2UgdHJhbnNpZW50IG92ZXJsb2FkIGlm IHNvbWUgZXZlbnQgY2F1c2VzIGEgbGFyZ2UgDQpudW1iZXIgb2YgcmVjZWl2ZXJzIHRvIHNlbmQg ZmVlZGJhY2sgYXQgb25jZS4gVGhpcyBvdmVybG9hZCBpcyB1c3VhbGx5IGF2b2lkZWQgDQpieSBl bnN1cmluZyB0aGF0IGZlZWRiYWNrIHJlcG9ydHMgYXJlIGZvcndhcmRlZCB0byBhbGwgcmVjZWl2 ZXJzLCBhbGxvd2luZyB0aGVtIA0KdG8gYXZvaWQgc2VuZGluZyBkdXBsaWNhdGUgZmVlZGJhY2sg cmVwb3J0cy4gSG93ZXZlciwgdGhlcmUgYXJlIGNlcnRhaW4gY2FzZXMgDQp3aGVyZSBpdCBpcyBu b3QgcG9zc2libGUgdG8gZm9yd2FyZCBmZWVkYmFjayByZXBvcnRzLCBhbmQgdGhpcyBtYXkgYWxs b3cgDQpmZWVkYmFjayBpbXBsb3Npb24uIFRoaXMgbWVtbyBkZWZpbmVzIGEgbmV3IFJUQ1AgdGhp cmQtcGFydHkgbG9zcyByZXBvcnQgdGhhdCANCmNhbiBiZSB1c2VkIHRvIGluZm9ybSByZWNlaXZl cnMgdGhhdCBhIGZlZWRiYWNrIHRhcmdldCBpcyBhd2FyZSBvZiBzb21lIGxvc3MgDQpldmVudCwg YWxsb3dpbmcgdGhlbSB0byBzdXBwcmVzcyBmZWVkYmFjay4gQXNzb2NpYXRlZCBTRFAgc2lnbmFs bGluZyBpcyBhbHNvIA0KZGVmaW5lZC6UPEJSPjwvRElWPg0KPERJVj5bUWluXTogU29ycnksIEkg Zm9yZ290IHRvIHVwZGF0ZSB0aGUgYWJzdHJhY3QuPC9ESVY+DQo8RElWPlllcywgWW91ciBwcm9w b3NlZCBjaGFuZ2UgaXMgcmVzb25hYmxlIGFuZCBjbGVhci4gVGhhbmtzLjwvRElWPg0KPERJVj48 QlI+LSBTZWN0aW9uIDMsIDJuZCBwYXJhZ3JhcGg6IHRoaXMgZG9lc26SdCBjbGVhcmx5IGRpZmZl cmVudGlhdGUgd2hlbiBhIA0KdGhpcmQtcGFydHkgbG9zcyByZXBvcnQgc2hvdWxkIGJlIHVzZWQg Y29tcGFyZWQgdG8gYSBOQUNLLiBJbiBwYXJ0aWN1bGFyLCB0aGUgDQpzZW50ZW5jZSCTVXBvbiBk b3duc3RyZWFtIGxvc3MgaXMgcmVwb3J0ZWQgdG8gdGhlIGludGVybWVkaWFyeSwgdGhlIGludGVy bWVkaWFyeSANClNIT1VMRCBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3NzIHJlcG9ydCB0byB0aGUg b3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMgd2hpY2ggDQphcmUgbm90IGF3YXJlIG9mIHRoZSBs b3NzIHJlcG9ydHMsIHRvIGluZm9ybSB0aG9zZSByZWNlaXZlcnMgb2YgdGhlIGxvc3MgYW5kIA0K c3VwcHJlc3MgdGhlaXIgZmVlZGJhY2uUIG5lZWRzIHRvIGJlIGV4cGFuZGVkIHRvIGRpc2N1c3Mg d2hhdCCTYXJlIG5vdCBhd2FyZSBvZiANCnRoZSBsb3NzIHJlcG9ydHOUIG1lYW5zIGluIHRoaXMg Y29udGV4dCAoaS5lLiwgd2hlbiBpdCdzIG5vdCBwb3NzaWJsZSB0byANCmRpc3RyaWJ1dGUgdGhl IE5BQ0tzIHRvIGFsbCByZWNlaXZlcnMpLjxCUj48L0RJVj4NCjxESVY+W1Fpbl06IFllcywgeW91 IGFyZSBjb3JyZWN0LiZuYnNwO0hvdyBhYm91dCB0aGUgZm9sbG93aW5nIHByb3Bvc2FsOjwvRElW Pg0KPERJVj4iPC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMC41cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogMTIuMHB0 OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNvLWZvbnQta2Vy bmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1VUz48Rk9OVCBz aXplPTM+SG93ZXZlciwgaW4gc29tZSBjYXNlcyB3aGVyZSBwYWNrZXQgbG9zcyBvY2N1cnMgaW4g dGhlIA0KZG93bnN0cmVhbSBvZiB0aGVzZSBpbnRlcm1lZGlhdGVzLCA8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7 IEZPTlQtU0laRTogMTAuNXB0OyBtc28tYmlkaS1mb250LXNpemU6IDEyLjBwdDsgbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1zby1mb250LWtlcm5pbmc6IDEuMHB0 OyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsg bXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiANCmxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0zPml0IGlz IG5vdCBwb3NzaWJsZSBmb3IgdGhlIGludGVybWVkaWF0ZXMgdG8gZGlzdHJpYnV0ZSANCnRoZSBO QUNLcyB0byBhbGwgcmVjZWl2ZXJzLiBJbiBzdWNoIGNhc2VzLCBkb3duc3RyZWFtIGxvc3MgDQpu ZWVkczwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIA0Kc3R5bGU9IkZPTlQtRkFNSUxZ OiAnVGltZXMgTmV3IFJvbWFuJzsgRk9OVC1TSVpFOiAxMC41cHQ7IG1zby1iaWRpLWZvbnQtc2l6 ZTogMTIuMHB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogJiMyMzQzNTsmIzIwMzA3OzsgbXNv LWZvbnQta2VybmluZzogMS4wcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiIA0KbGFuZz1FTi1V Uz48Rk9OVCBzaXplPTM+Jm5ic3A7dG8gYmUgZmlyc3RseSByZXBvcnRlZCB0byB0aGUmbmJzcDtp bnRlcm1lZGlhcnkgaW4gDQpzb21lIHdheS4gVXBvbiBkb3duc3RyZWFtIGxvc3MgaXMgcmVwb3J0 ZWQgdG8gdGhlPEJSPiZuYnNwO2ludGVybWVkaWFyeSwgdGhlIA0KaW50ZXJtZWRpYXJ5IFNIT1VM RCBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3NzJm5ic3A7cmVwb3J0IHRvIHRoZSBvdGhlciANCmRv d25zdHJlYW0gcmVjZWl2ZXJzLjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPiI8L0RJVj4NCjxE SVY+PEJSPi0gU2VjdGlvbiAzLCAzcmQgcGFyYWdyYXBoOiB0aGlzIHdvdWxkIGJlIG11Y2ggY2xl YXJlciBpZiBpdCBkaXNjdXNzZWQgDQp3aGVuIGl0knMgYXBwcm9wcmlhdGUgdG8gbW9uaXRvciB0 aGUgZmVlZGJhY2sgYW5kIHNlbmQgYSB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydCANCnRvIGRvd25z dHJlYW0gcmVjZWl2ZXJzLCByYXRoZXIgdGhhbiBqdXN0IHJlZmxlY3QgTkFDS3MgYmFjayANCmRv d25zdHJlYW0uPEJSPjwvRElWPg0KPERJVj5bUWluXTogT2theS4gSSB0aGluayB0aGUgYW5zd2Vy IHRvIHdoZW4gaXMgPC9ESVY+DQo8RElWPiI8L0RJVj4NCjxESVY+VXBvbiByZWNlaXZpbmcgZG93 bnN0cmVhbSBsb3NzIHJlcG9ydCBpbiB0aGUgd2F5IG9mIHN1Y2ggZmVlZGJhY2sgcmVwb3J0IA0K b25seSBkZXN0aW5lZCBmb3IgbWVkaWEgc291cmNlLCB0aGUgbWVkaWEgc291cmNlIFNIT1VMRCBz ZW5kIHRoZSBUaGlyZDxCUj5QYXJ0eSANCkxvc3MgUmVwb3J0IG1lc3NhZ2VzIHRvIHRoZSByZWNl aXZlcnMuPC9ESVY+DQo8RElWPiI8L0RJVj4NCjxESVY+PEJSPi0gU2VjdGlvbiA2LjEsIDJuZCBw YXJhZ3JhcGg6IHdoZW4gaW4gU2ltcGxlIEZlZWRiYWNrIE1vZGUsIE5BQ0tzIGFyZSANCnJlZmxl Y3RlZCBhbmQgdGhlcmWScyBubyBuZWVkIGZvciB0aGUgdGhpcmQtcGFydHkgbG9zcyByZXBvcnQu IFRoZSBkb3duc3RyZWFtIA0KdGhpcmQtcGFydHkgbG9zcyByZXBvcnQgaXMgb25seSBnZW5lcmF0 ZWQgd2hlbiBpbiBEaXN0cmlidXRpb24gU291cmNlIEZlZWRiYWNrIA0KU3VtbWFyeSBtb2RlLiBJ km0gbm90IHN1cmUgaXQgbWFrZXMgc2Vuc2UgdG8gd3JpdGUgZ2VuZXJpYyBydWxlcyBpbiBTZWN0 aW9uIDYuMSwgDQppbnN0ZWFkIG9mIHdyaXRpbmcgc3BlY2lmaWMgcnVsZXMgZm9yIGVhY2ggb2Yg dGhlIHR3byBmZWVkYmFjayBtb2RlcyBpbiBTZWN0aW9uIA0KNjEuMSBhbmQgNi4xLjIuPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5bUWluXTogWWVzLCBpdCBtb3JlIG1ha2Ugc2Vuc2Ug dG8gbWFrZSBpdCBpbiB0aGUgc2VjdGlvbiA2LjEuIEkgd2lsbCB1cGRhdGUgDQpzZWN0aW9uIDYu MSwgc2VjdGlvbiA2LjEuMSBhbmQgc2VjdGlvbiA2LjEuMiB0byByZWZsZWN0IA0KdGhpcy48QlI+ PEJSPkNoZWVycyw8QlI+Q29saW48QlI+PEJSPjxCUj48QlI+PEJSPk9uIDYgTWF5IDIwMTEsIGF0 IDEwOjUzLCBRaW4gV3UgDQp3cm90ZTo8QlI+Jmd0OyBIaSw8QlI+Jmd0OyBUaGUgbmV3IHZlcnNp b24gb2YgDQpkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcHJlc3Npb24tcnRwIGlzIGF2 YWlsYWJsZSBhdDxCUj4mZ3Q7IDxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4 dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3Jl LWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4dDwvQT48QlI+Jmd0OyANCndoaWNoIGFkZHJl c3MgdGhlIHJlY2VudCBjb21tZW50cyBmcm9tIENvbGluIG9uIHRoZSBsaXN0LjxCUj4mZ3Q7IFRo ZSBtYWluIA0KY2hhbmdlIGlzIHRvIGNsYXJpZnkgdGhlIHVzZSBvZiB0aGlyZCBwYXJ0eSBsb3Nz IHJlcG9ydCBhbmQgdXBkYXRlIHRoZSB0aXRsZSBhbmQgDQpyZWxldmFudCBzZWN0aW9ucyA8QlI+ Jmd0OyB0byBmb2N1cyBvbiB0aGlyZCBwYXJ0eSBsb3NzIHJlcG9ydC48QlI+Jmd0OyBUaGUgZGlm ZiANCmlzIGF0OjxCUj4mZ3Q7IDxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRi YWNrLXN1cHJlc3Npb24tcnRwLTAyPC9BPjxCUj4mZ3Q7IA0KUGxlYXNlIGNoZWNrIGlmIHlvdSBh cmUgY29tZm9ydGFibGUgd2l0aCB0aGUgY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24uPEJSPiZndDsg DQpBbnkgY29tbWVudHM/PEJSPiZndDsgPEJSPiZndDsgUmVnYXJkcyE8QlI+Jmd0OyAtUWluPEJS PiZndDsgLS0tLS0gT3JpZ2luYWwgDQpNZXNzYWdlIC0tLS0tIDxCUj4mZ3Q7IEZyb206ICZsdDs8 QSANCmhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzwvQT4mZ3Q7PEJSPiZndDsgDQpUbzogJmx0OzxBIA0KaHJlZj0ibWFpbHRvOmkt ZC1hbm5vdW5jZUBpZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9BPiZndDs8QlI+Jmd0 OyBDYzogDQombHQ7PEEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9B PiZndDs8QlI+Jmd0OyBTZW50OiBGcmlkYXksIE1heSANCjA2LCAyMDExIDU6MzkgUE08QlI+Jmd0 OyBTdWJqZWN0OiBJLUQgQWN0aW9uOiANCmRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBy ZXNzaW9uLXJ0cC0wMi50eHQ8QlI+Jmd0OyA8QlI+Jmd0OyA8QlI+Jmd0OyZndDsgDQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuIA0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXVkaW8v VmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV29ya2luZyANCkdyb3VwIG9mIHRoZSBJ RVRGLjxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgDQpUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFJUQ1AgDQpFeHRlbnNp b24gZm9yIFRoaXJkLXBhcnR5IExvc3MgUmVwb3J0PEJSPiZndDsmZ3Q7IA0KQXV0aG9yKHMpJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogUWluIA0KV3U8QlI+Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQpGcmFuayANClhpYTxCUj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANClJvbmkgRXZlbjxCUj4mZ3Q7Jmd0OyBGaWxl bmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IA0KZHJhZnQt aWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4dDxCUj4mZ3Q7Jmd0OyAN ClBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDogDQoxODxCUj4mZ3Q7Jmd0OyANCkRhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiANCjIwMTEtMDUt MDY8QlI+Jmd0OyZndDsgPEJSPiZndDsmZ3Q7Jm5ic3A7IEluIGEgbGFyZ2UgUlRQIHNlc3Npb24g dXNpbmcgdGhlIFJUQ1AgDQpmZWVkYmFjayBtZWNoYW5pc20gZGVmaW5lZCBpbjxCUj4mZ3Q7Jmd0 OyZuYnNwOyBSRkMgNDU4NSwgYSBtZWRpYSBzb3VyY2Ugb3IgDQptaWRkbGVib3ggbWF5IGV4cGVy aWVuY2UgdHJhbnNpZW50PEJSPiZndDsmZ3Q7Jm5ic3A7IG92ZXJsb2FkIGlmIHNvbWUgZXZlbnQg DQpjYXVzZXMgYSBsYXJnZSBudW1iZXIgb2YgcmVjZWl2ZXJzIHRvIHNlbmQ8QlI+Jmd0OyZndDsm bmJzcDsgZmVlZGJhY2sgYXQgDQpvbmNlLiZuYnNwOyBUaGlzIGZlZWRiYWNrIGltcGxvc2lvbiBj YW4gYmUgbWl0aWdhdGVkIGlmIHRoZTxCUj4mZ3Q7Jmd0OyZuYnNwOyANCmRldmljZSBzdWZmZXJp bmcgZnJvbSBvdmVybG9hZCBjYW4gc2VuZCBhIHRoaXJkIHBhcnR5IGxvc3MgDQpyZXBvcnQ8QlI+ Jmd0OyZndDsmbmJzcDsgbWVzc2FnZSB0byB0aGUgcmVjZWl2ZXJzIHRvIGluaGliaXQgZnVydGhl ciANCmZlZWRiYWNrLiZuYnNwOyBUaGlzIG1lbW88QlI+Jmd0OyZndDsmbmJzcDsgZGVmaW5lcyBS VENQIEV4dGVuc2lvbiBmb3IgdGhpcmQgDQpwYXJ0eSBsb3NzIHJlcG9ydCwgdG8gc3VwcHJlc3Mg TkFDSzxCUj4mZ3Q7Jmd0OyZuYnNwOyBhbmQgRklSIGZlZWRiYWNrIA0KcmVxdWVzdHMuJm5ic3A7 IEl0IGFsc28gZGVmaW5lcyBhc3NvY2lhdGVkIFNEUCBzaWduYWxpbmcuPEJSPiZndDsmZ3Q7IA0K PEJSPiZndDsmZ3Q7IDxCUj4mZ3Q7Jmd0OyBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBp czo8QlI+Jmd0OyZndDsgPEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0Ij5o dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtZmVl ZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0PC9BPjxCUj4mZ3Q7Jmd0OyANCjxCUj4mZ3Q7Jmd0 OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 PEJSPiZndDsmZ3Q7IA0KPEEgDQpocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L0E+PEJSPiZndDsmZ3Q7 IA0KPEJSPiZndDsmZ3Q7IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDo8 QlI+Jmd0OyZndDsgPEEgDQpocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0wMi50eHQiPmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNr LXN1cHJlc3Npb24tcnRwLTAyLnR4dDwvQT48QlI+Jmd0OyZndDsgDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7Jmd0OyBJLUQtQW5ub3VuY2Ug bWFpbGluZyANCmxpc3Q8QlI+Jmd0OyZndDsgPEEgDQpocmVmPSJtYWlsdG86SS1ELUFubm91bmNl QGlldGYub3JnIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L0E+PEJSPiZndDsmZ3Q7IDxBIA0KaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9BPjxCUj4m Z3Q7Jmd0OyANCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8QSANCmhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8 L0E+PEJSPiZndDsmZ3Q7IA0Kb3IgPEEgDQpocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8x c2hhZG93LXNpdGVzLnR4dCI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50 eHQ8L0E+PEJSPiZndDsgDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxCUj4mZ3Q7IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCANCkNvcmUgTWFpbnRlbmFuY2U8 QlI+Jmd0OyA8QSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L0E+PEJS PiZndDsgDQo8QSANCmhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v YXZ0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvQT48QlI+PEJS PjxCUj48QlI+LS0gDQo8QlI+Q29saW4gUGVya2luczxCUj48QSANCmhyZWY9Imh0dHA6Ly9jc3Bl cmtpbnMub3JnLyI+aHR0cDovL2NzcGVya2lucy5vcmcvPC9BPjxCUj48QlI+PEJSPjwvRElWPjwv Qk9EWT48L0hUTUw+DQo= --Boundary_(ID_z829NB1+aXzCTSXgE/AbvQ)-- From internet-drafts@ietf.org Wed May 11 23:35:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF1EE0700; Wed, 11 May 2011 23:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duVAEEPKtNZx; Wed, 11 May 2011 23:35:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF9FE06F9; Wed, 11 May 2011 23:35:26 -0700 (PDT) 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: 3.54 Message-ID: <20110512063526.16060.45411.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2011 23:35:26 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 06:35:27 -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 Core Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-03.txt Pages : 18 Date : 2011-05-11 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are certain cases where it is not possible to forward feedback reports, and this may allow feedback implosion. This memo defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-03.txt From sunseawq@huawei.com Wed May 11 23:44:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4349FE06F8 for ; Wed, 11 May 2011 23:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KygJ-1kdW-Ck for ; Wed, 11 May 2011 23:44:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 243C5E0675 for ; Wed, 11 May 2011 23:44:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL2007L1LBU9C@szxga04-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 14:43:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL200E8ILBUYH@szxga04-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 14:43:06 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL200EG0LBUBZ@szxml04-in.huawei.com> for avt@ietf.org; Thu, 12 May 2011 14:43:06 +0800 (CST) Date: Thu, 12 May 2011 14:46:49 +0800 From: Qin Wu To: avt@ietf.org Message-id: <01dc01cc1070$5eb3b940$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110512063526.16060.45411.idtracker@ietfa.amsl.com> Cc: magnus.westerlund@ericsson.com, Colin Perkins Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 06:44:54 -0000 Hi, Here is the new version of draft-ietf-avtcore-feedback-supression-rtp. This version address Colin's recent comments on use of Third Party Loss report. For diff, see: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-03 Let us know what is unclear. Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Thursday, May 12, 2011 2:35 PM Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTCP Extension for Third-party Loss Report > Author(s) : Qin Wu > Frank Xia > Roni Even > Filename : draft-ietf-avtcore-feedback-supression-rtp-03.txt > Pages : 18 > Date : 2011-05-11 > > In a large RTP session using the RTCP feedback mechanism defined in > RFC 4585, a feedback target may experience transient overload if some > event causes a large number of receivers to send feedback at once. > This overload is usually avoided by ensuring that feedback reports > are forwarded to all receivers, allowing them to avoid sending > duplicate feedback reports. However, there are certain cases where > it is not possible to forward feedback reports, and this may allow > feedback implosion. This memo defines a new RTCP third-party loss > report that can be used to inform receivers that a feedback target is > aware of some loss event, allowing them to suppress feedback. > Associated SDP signalling is also defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-03.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From pkyzivat@cisco.com Thu May 12 05:22:13 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2AE0770 for ; Thu, 12 May 2011 05:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0k1mmG+VVgl for ; Thu, 12 May 2011 05:22:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BE9F7E06D7 for ; Thu, 12 May 2011 05:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3026; q=dns/txt; s=iport; t=1305202929; x=1306412529; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=H2nvx8TO7Ts+c/LGC0M8+sQnitW8CCR7QmUS53tBFO0=; b=bBMTG0bw5rdLRqPUVqF+FjgAag+cfEdd8zzSV7ZLFnmmgFgpm9EIyNXW pHY5ZOuEBqjX+WB69aW3EZ7Zl/j0VIYo5CY18GHb205AdHhyQny6z6mTC lvoRjKrXNLSDXWFf+7/7+8PTRlVyju3gHNYoP9rFbwB5+dHzTau3YNVvf 4=; X-IronPort-AV: E=Sophos;i="4.64,358,1301875200"; d="scan'208";a="29908741" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 12 May 2011 12:22:08 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4CCM73Z001094; Thu, 12 May 2011 12:22:08 GMT Message-ID: <4DCBD0EF.5000203@cisco.com> Date: Thu, 12 May 2011 08:22:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <5F7BCCF5541B7444830A2288ABBEBC9620B9D67862@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <4DC7DE29.80602@ericsson.com> <4DC7E8E5.7080609@cisco.com> <4DC8FF04.3090408@ericsson.com> In-Reply-To: <4DC8FF04.3090408@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "avt@ietf.org" , "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [AVTCORE] Mandatory nature of RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 12:22:13 -0000 On 5/10/2011 5:01 AM, Magnus Westerlund wrote: > On 2011-05-09 15:15, Paul Kyzivat wrote: >> Magnus, >> >> IMO the first question in this area that comes up for siprec is: >> >> 1) must we be able to record the RTP of a call when that RTP >> doesn't have RTCP? >> >> I think the answer is clearly yes. >> There seems to be enough wiggle room in 3550 that we can't >> argue that the call is invalid and we don't need to record it. >> (And in general we should try to record calls even if they >> *are* invalid.) > > Agree that you will need to be able to record it. > >> The next question that comes up is: >> >> 2) when recording a call with a media stream that doesn't have >> RTCP, must the siprec SRC synthesize RTCP in order that it will be >> available to the receiver? Or can we leave it to the siprec SRS >> to deal with it? > > Looking at the architecture pictures in Section 3.1 in > http://tools.ietf.org/html/draft-ietf-siprec-architecture-02 > > I get the impression that the RTP session between the SRC and the SRS > appears to be a separate RTP session from the one that is being > recorded. In those case I think it is important that the SRC monitors > the media flow to the SRS to ensure that it is being delivered > successfully and with sufficient quality without causing any persistent > congestion. > > Thus I think a requirement on using RTCP between the SRC and SRS appears > necessary. This will need to be discussed/investigated further. We are discussing multiple models for how the SRC manages the RTP. For some of them the above may be feasible, and for others, not. There are others in siprec with a much better handle on the RTP side of things than I have. We need to arrange the right level of interaction among the right people. Thanks, Paul > In that context you will have to answer the question what to do if the > SRC sees persistent congestion on the path to the SRS. Can it do some > media manipulation to reduce bit-rate, for example by repacketizing > audion into multiple frames per packet to reduce packet overhead. At the > minimal it may have to stop sending the recording stream if there are > insufficient resources. > >> I think we need AVTxxx input into siprec on such issues. >> Decisions on these things can potentially have significant architectural >> impact on the way recording is done. >> > > We should do our best to provide feedback on such questions. > > Cheers > > 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 csp@csperkins.org Mon May 16 03:39:28 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277BBE0720; Mon, 16 May 2011 03:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.822 X-Spam-Level: X-Spam-Status: No, score=-102.822 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktc4NNRnF71a; Mon, 16 May 2011 03:39:27 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 15A88E0718; Mon, 16 May 2011 03:39:27 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QLvB3-0001Qb-ja; Mon, 16 May 2011 10:37:29 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-240-817534110 From: Colin Perkins X-Priority: 3 In-Reply-To: <02c801cc0eb9$29031bf0$46298a0a@china.huawei.com> Date: Mon, 16 May 2011 11:37:28 +0100 Message-Id: <1347F83C-BBEB-4503-9EE1-1EABF7090851@csperkins.org> References: <05e001cc0e20$5525ba60$46298a0a@china.huawei.com> <02c801cc0eb9$29031bf0$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: AVT WG , xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Open issue- identity info repetition indraft-ietf-avtcore-monarch X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 10:39:28 -0000 --Apple-Mail-240-817534110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qin, To my mind, the most important part of the identity block was the = correlation tag used to relate RTCP statistics to non-RTCP measurements = (draft-clark-avt-rtcphr-02 had something along these lines, although = more structured than needed). The tools to save space in RTCP XR packets = by removing duplicate identity information when stacking reports are = less compelling. Given this, I don't see much value in Section 5.2 of = draft-ietf-avtcore-monarch as currently written, and would prefer to see = the draft focus on ways to correlate RTP-layer identify information with = other identify data. I'd be interested to hear other opinions though. Colin On 10 May 2011, at 03:22, Qin Wu wrote: > Just make correction. My colleague reminds me that the example figure = 2 does not conflict with report block format defined in = draft-ietf-avt-rtcp-xr-meas-identity-02. > Since the detailed measurement identity information following the = field SSRC of stream source in the figure 2 is omitted. > However as I mentioned, it is not clear how much information is = included in identity block until identity block is clearly defined in = XRBlock WG. > That is why I propose to remove figure 2 and related text from this = document. > =20 > Regards! > -Qin > ----- Original Message ----- > From: Qin Wu > To: avt@ietf.org ; xrblock@ietf.org > Cc: magnus.westerlund@ericsson.com > Sent: Monday, May 09, 2011 4:08 PM > Subject: [AVTCORE] Open issue- identity info repetition = indraft-ietf-avtcore-monarch >=20 > In the last IETF meeting, there was discussion on identity info = repetition or dupplication. However it > was not clear whether new packet type for identity block is needed. = Here is some clarification and > prososal from my point of view. > =20 > In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, = it is assumed there is an RTCP > XR packet containing four metrics blocks, reporting on streams from = two source. > each source is associated with two meric block. > =20 > In order to reduce overhead to carry duplicated data for all the = metric block contained in > the same RTCP XR packet, it was proposed by draft-ietf-avtcore-monarch = that measurement > identity information should be separated from metric block and form = independent block. > =20 > However this proposal save zero octets in figure 2. So the question = is > whether an identity block is actually needed if identity information > only contain SSRC of stream souce, or if just stacking > multiple XR Blocks is acceptable. > =20 > However I re-check with RTCP XR Report Block for Measurement Identity = defined in > draft-ietf-avt-rtcp-xr-meas-identity-02, identity information included = is more than > SSRC of stream source. So it should be useful to define new packet = type for identity block. > =20 > However the example figure 2(i.e., only contain SSRC of stream souce) = is actually not consistent with report block format defined in > draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC = of stream source). > =20 > Also as we know, identity block work has just started from XRBlock WG, > Therefore I suggest that the example (Figure 2, and the related = discussion) is removed until the identity block is clearly > defined in XRBLock. > =20 > Any Comments or suggestion? > =20 > Regards! > -Qin > =20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-240-817534110 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Just make = correction. My colleague reminds me that the example figure 2  does = not conflict with report block format defined in = draft-ietf-avt-rtcp-xr-meas-identity-02.
Since the detailed measurement identity = information following the field SSRC of stream source in the = figure 2 is omitted.
However as I mentioned, it is not clear how much information is = included in identity block until identity block is clearly defined in = XRBlock WG.
That is why = I propose to remove figure 2 and related text from this = document.
 
Regards!
-Qin
----- Original Message = -----
From: Qin = Wu
Sent: Monday, May 09, 2011 4:08 = PM
Subject: [AVTCORE] Open issue- = identity info repetition = indraft-ietf-avtcore-monarch

In the last IETF meeting, there was discussion on identity = info repetition or dupplication. However it
 was not clear whether new packet type for = identity block is needed. Here is some clarification = and
prososal from my = point of view.
 
In the = example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it = is assumed there is an RTCP
 XR packet containing four metrics = blocks, reporting on streams from two = source.
each source is = associated with two meric block.
 
In = order to reduce overhead to carry duplicated data for all the = metric block contained in
the same RTCP XR packet, it was proposed by = draft-ietf-avtcore-monarch that measurement
identity information should be separated from = metric block and form independent block.
 
However this proposal save zero octets in figure 2. So the = question  is
whether an identity block is actually needed if identity = information
only contain = SSRC of stream souce, or if just stacking
multiple XR Blocks = is acceptable.
 
However I = re-check with RTCP XR Report Block for Measurement Identity defined = in
draft-ietf-avt-rtcp-xr-meas-identity-02, identity information = included is more than
SSRC of stream source. So it should be useful to define new = packet type for identity block.
 
However the example figure 2(i.e., only contain SSRC of = stream souce) is actually not consistent with report block format = defined in
draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than = SSRC of stream source).
 
Also as we = know, identity block work has just started from XRBlock = WG,
Therefore  I = suggest that the example (Figure 2, and the related discussion) is removed until = the identity block is clearly
defined in XRBLock.
 
Any = Comments or suggestion?
 
Regards!
-Qin
 


_________________________________= ______________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/ma= ilman/listinfo/avt
___________________________________= ____________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.or= g/mailman/listinfo/xrblock

-- 
Colin Perkins



= --Apple-Mail-240-817534110-- From csp@csperkins.org Mon May 16 04:14:26 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38B9E070E for ; Mon, 16 May 2011 04:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVdZWE0YMKio for ; Mon, 16 May 2011 04:14:25 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id F294DE06BF for ; Mon, 16 May 2011 04:14:24 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QLvkl-0002bh-fr; Mon, 16 May 2011 11:14:24 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-242-819749279 From: Colin Perkins X-Priority: 3 In-Reply-To: <014f01cc1058$989a3070$46298a0a@china.huawei.com> Date: Mon, 16 May 2011 12:14:23 +0100 Message-Id: References: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> <003001cc0bd3$66244600$46298a0a@china.huawei.com> <7C2CC5D8-ECB0-4D26-806D-990C2C56537B@csperkins.org> <014f01cc1058$989a3070$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 11:14:26 -0000 --Apple-Mail-242-819749279 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Qin, [I have fixed the quoting to me clear who wrote what] On 12 May 2011, at 04:56, Qin Wu wrote: > On 11 May 2011, at 17:04, Colin Perkins wrote: >> This version is better, but I'm still not sure it fully clarifies = when third-party loss reports should be sent in place of NACKs. In = particular: >>=20 >> - The abstract still reads as-if the draft is solely focussed on = feedback suppression. I suggest it could be rephrased something like: = =93In a large RTP session using the RTCP feedback mechanism defined in = RFC 4585, a feedback target may experience transient overload if some = event causes a large number of receivers to send feedback at once. This = overload is usually avoided by ensuring that feedback reports are = forwarded to all receivers, allowing them to avoid sending duplicate = feedback reports. However, there are certain cases where it is not = possible to forward feedback reports, and this may allow feedback = implosion. This memo defines a new RTCP third-party loss report that can = be used to inform receivers that a feedback target is aware of some loss = event, allowing them to suppress feedback. Associated SDP signalling is = also defined.=94 > [Qin]: Sorry, I forgot to update the abstract. > Yes, Your proposed change is resonable and clear. Thanks. >=20 >> - Section 3, 2nd paragraph: this doesn=92t clearly differentiate when = a third-party loss report should be used compared to a NACK. In = particular, the sentence =93Upon downstream loss is reported to the = intermediary, the intermediary SHOULD send the Third Party Loss report = to the other downstream receivers which are not aware of the loss = reports, to inform those receivers of the loss and suppress their = feedback=94 needs to be expanded to discuss what =93are not aware of the = loss reports=94 means in this context (i.e., when it's not possible to = distribute the NACKs to all receivers). > [Qin]: Yes, you are correct. How about the following proposal: > " > However, in some cases where packet loss occurs in the downstream of = these intermediates, > it is not possible for the intermediates to distribute the NACKs to = all receivers. In such cases, downstream loss needs > to be firstly reported to the intermediary in some way. Upon = downstream loss is reported to the > intermediary, the intermediary SHOULD send the Third Party Loss = report to the other downstream receivers. > " I don't think this, nor the text in = draft-ietf-avtcore-feedback-supressions-rtp-03 is correct. Section 3, = 2nd paragraph of the -03 draft says =93However, in some cases where = packet loss occurs in the downstream of these intermediates, it is not = possible for them to distribute the NACKs to all receivers since they = are unable to observe downstream loss. In such cases, downstream loss = needs to be firstly reported to the intermediary. When downstream loss = is reported to the intermediary, the intermediary SHOULD create and send = the Third Party Loss report to the other downstream receivers which are = not aware of the loss reports, to inform those receivers of the loss and = suppress their feedback. Therefore the intermediate node can be = reasonably certain that it will help the situation by sending a Third = Party Loss Report message to all the relevant receivers,=94. This makes = it sound like the intermediary always uses a third-party loss report to = tell other receivers about downstream loss. That=92s not the case. In = many scenarios, the intermediary can reflect NACKs it receives from one = downstream receiver to the other receivers without using a third party = loss report. The third-party loss report is only needed in those cases = where NACKs cannot be distributed to all receivers. >> - Section 3, 3rd paragraph: this would be much clearer if it = discussed when it=92s appropriate to monitor the feedback and send a = third-party loss report to downstream receivers, rather than just = reflect NACKs back downstream. > [Qin]: Okay. I think the answer to when is > " > Upon receiving downstream loss report in the way of such feedback = report only destined for media source, the media source SHOULD send the = Third > Party Loss Report messages to the receivers. > " I don't think that's correct. In most cases, loss feedback destined to = the sender should be reflected downstream to suppress further feedback. = This draft needs to discuss the scenarios, for example SSM sessions = using Distribution Source Feedback Summary mode, where this is not = possible. It is these scenarios where third party loss reports are = needed. >> - Section 6.1, 2nd paragraph: when in Simple Feedback Mode, NACKs are = reflected and there=92s no need for the third-party loss report. The = downstream third-party loss report is only generated when in = Distribution Source Feedback Summary mode. I=92m not sure it makes sense = to write generic rules in Section 6.1, instead of writing specific rules = for each of the two feedback modes in Section 61.1 and 6.1.2. > =20 > [Qin]: Yes, it more make sense to make it in the section 6.1. I will = update section 6.1, section 6.1.1 and section 6.1.2 to reflect this. >=20 >> Cheers, >> Colin >>=20 >=20 >=20 >=20 > On 6 May 2011, at 10:53, Qin Wu wrote: > > Hi, > > The new version of draft-ietf-avtcore-feedback-suppression-rtp is = available at > > = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression= -rtp-02.txt > > which address the recent comments from Colin on the list. > > The main change is to clarify the use of third party loss report and = update the title and relevant sections=20 > > to focus on third party loss report. > > The diff is at: > > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-feedback-supressio= n-rtp-02 > > Please check if you are comfortable with the changes in this = version. > > Any comments? > >=20 > > Regards! > > -Qin > > ----- Original Message -----=20 > > From: > > To: > > Cc: > > Sent: Friday, May 06, 2011 5:39 PM > > Subject: I-D Action: = draft-ietf-avtcore-feedback-supression-rtp-02.txt > >=20 > >=20 > >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. > >>=20 > >> Title : RTCP Extension for Third-party Loss Report > >> Author(s) : Qin Wu > >> Frank Xia > >> Roni Even > >> Filename : draft-ietf-avtcore-feedback-supression-rtp-02.txt > >> Pages : 18 > >> Date : 2011-05-06 > >>=20 > >> In a large RTP session using the RTCP feedback mechanism defined = in > >> RFC 4585, a media source or middlebox may experience transient > >> overload if some event causes a large number of receivers to send > >> feedback at once. This feedback implosion can be mitigated if the > >> device suffering from overload can send a third party loss report > >> message to the receivers to inhibit further feedback. This memo > >> defines RTCP Extension for third party loss report, to suppress = NACK > >> and FIR feedback requests. It also defines associated SDP = signaling. > >>=20 > >>=20 > >> A URL for this Internet-Draft is: > >> = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression= -rtp-02.txt > >>=20 > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >>=20 > >> This Internet-Draft can be retrieved at: > >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-02.txt > >> _______________________________________________ > >> 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 > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-242-819749279 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 11 May 2011, at 17:04, Colin = Perkins wrote:
This version is better, = but I'm still not sure it fully clarifies when third-party loss reports = should be sent in place of NACKs. In particular:

- The = abstract still reads as-if the draft is solely focussed on feedback = suppression. I suggest it could be rephrased something like: =93In a = large RTP session using the RTCP feedback mechanism defined in RFC 4585, = a feedback target may experience transient overload if some event causes = a large number of receivers to send feedback at once. This overload is = usually avoided by ensuring that feedback reports are forwarded to all = receivers, allowing them to avoid sending duplicate feedback reports. = However, there are certain cases where it is not possible to forward = feedback reports, and this may allow feedback implosion. This memo = defines a new RTCP third-party loss report that can be used to inform = receivers that a feedback target is aware of some loss event, allowing = them to suppress feedback. Associated SDP signalling is also = defined.=94
[Qin]: Sorry, I forgot to update = the abstract.
Yes, Your proposed change is resonable and = clear. Thanks.

- = Section 3, 2nd paragraph: this doesn=92t clearly differentiate when a = third-party loss report should be used compared to a NACK. In = particular, the sentence =93Upon downstream loss is reported to the = intermediary, the intermediary SHOULD send the Third Party Loss report = to the other downstream receivers which are not aware of the loss = reports, to inform those receivers of the loss and suppress their = feedback=94 needs to be expanded to discuss what =93are not aware of the = loss reports=94 means in this context (i.e., when it's not possible to = distribute the NACKs to all = receivers).
[Qin]: Yes, you are = correct. How about the following = proposal:
"
However, in = some cases where packet loss occurs in the downstream of these = intermediates,
it is not possible for the intermediates to distribute the = NACKs to all receivers. In such cases, downstream loss = needs
 to be = firstly reported to the intermediary in some way. Upon downstream = loss is reported to the
 intermediary, the intermediary SHOULD = send the Third Party Loss report to the other downstream = receivers.
"
<= br>
I don't think this, nor the text in = draft-ietf-avtcore-feedback-supressions-rtp-03 is correct. Section = 3, 2nd paragraph of the -03 draft says =93However, in some cases where = packet loss occurs in the downstream of these intermediates, it is = not possible for them to distribute the NACKs to all receivers = since they are unable to observe downstream loss.  In = such cases, downstream loss needs to be firstly reported to the = intermediary.  When downstream loss is reported to the = intermediary, the intermediary SHOULD create and send the Third = Party Loss report to the other downstream receivers which are = not aware of the loss reports, to inform those receivers of the = loss and suppress their feedback.  Therefore the = intermediate node can be reasonably certain that it will help the = situation by sending a Third Party Loss Report message to all the = relevant receivers,=94. This makes it sound like the intermediary = always uses a third-party loss report to tell other receivers about = downstream loss. That=92s not the case. In many scenarios, the = intermediary can reflect NACKs it receives from one downstream = receiver to the other receivers without using a third party loss = report. The third-party loss report is only needed in those = cases where NACKs cannot be distributed to all = receivers.


- Section 3, 3rd paragraph: this would be much = clearer if it discussed when it=92s appropriate to monitor the feedback = and send a third-party loss report to downstream receivers, rather than = just reflect NACKs back downstream.
[Qin]: = Okay. I think the answer to when is
"
Upon receiving = downstream loss report in the way of such feedback report only destined = for media source, the media source SHOULD send the Third
Party Loss = Report messages to the = receivers.
"

I = don't think that's correct. In most cases, loss feedback destined = to the sender should be reflected downstream to suppress further = feedback.  This draft needs to discuss the scenarios, = for example SSM sessions using Distribution Source Feedback = Summary mode, where this is not possible. It is these scenarios = where third party loss reports are needed.


- Section 6.1, 2nd = paragraph: when in Simple Feedback Mode, NACKs are reflected and there=92s= no need for the third-party loss report. The downstream third-party = loss report is only generated when in Distribution Source Feedback = Summary mode. I=92m not sure it makes sense to write generic rules in = Section 6.1, instead of writing specific rules for each of the two = feedback modes in Section 61.1 and = 6.1.2.
 
[Qin]: Yes, it more make = sense to make it in the section 6.1. I will update section 6.1, section = 6.1.1 and section 6.1.2 to reflect this.

Cheers,
Colin




On 6 May = 2011, at 10:53, Qin Wu wrote:
> Hi,
> The new version of = draft-ietf-avtcore-feedback-suppression-rtp is available at
> http://www.ietf.org/internet-drafts/draft-ietf-avtcor= e-feedback-supression-rtp-02.txt
> which address the recent = comments from Colin on the list.
> The main change is to clarify = the use of third party loss report and update the title and relevant = sections 
> to = focus on third party loss report.
> The diff is at:
> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-= feedback-supression-rtp-02
> Please check if you are = comfortable with the changes in this version.
> Any = comments?
> 
> Regards!
> = -Qin
> ----- Original Message ----- 
> From: <internet-drafts@ietf.org><= br>> To: <i-d-announce@ietf.org>
>= ; Cc: <avt@ietf.org>
> = Sent: Friday, May 06, 2011 5:39 PM
> Subject: I-D Action: = draft-ietf-avtcore-feedback-supression-rtp-02.txt
> 
> 
>> A New = Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF.
>> 
>> = Title           : RTCP = Extension for Third-party Loss Report
>> = Author(s)       : Qin = Wu
>>          =             &n= bsp;  Frank = Xia
>>          = ;            &= nbsp;  Roni Even
>> = Filename        : = draft-ietf-avtcore-feedback-supression-rtp-02.txt
>> = Pages           : = 18
>> = Date            : = 2011-05-06
>> 
>>  In a = large RTP session using the RTCP feedback mechanism defined = in
>>  RFC 4585, a media source or middlebox may = experience transient
>>  overload if some event causes a = large number of receivers to send
>>  feedback at = once.  This feedback implosion can be mitigated if = the
>>  device suffering from overload can send a third = party loss report
>>  message to the receivers to inhibit = further feedback.  This memo
>>  defines RTCP = Extension for third party loss report, to suppress = NACK
>>  and FIR feedback requests.  It also defines = associated SDP signaling.
>> 
>> 
>> A URL for this = Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avtcor= e-feedback-supression-rtp-02.txt
>> 
>> = Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-d= rafts/
>> 
>> This = Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-= feedback-supression-rtp-02.txt
>> = _______________________________________________
>> I-D-Announce = mailing list
>> I-D-Announce@ietf.org
>>= ; https://www.ie= tf.org/mailman/listinfo/i-d-announce
>> Internet-Draft = directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt
> = _______________________________________________
> Audio/Video = Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/avt



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


= _______________________________________________
Audio/Video Transport = Core Maintenance
avt@ietf.org
https://www.ietf.org/ma= ilman/listinfo/avt



-- 
Colin Perkins



= --Apple-Mail-242-819749279-- From sunseawq@huawei.com Mon May 16 20:57:29 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57799E0721; Mon, 16 May 2011 20:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBRZDHzEnEuG; Mon, 16 May 2011 20:57:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A269DE079F; Mon, 16 May 2011 20:57:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00CIGMZ0W2@szxga03-in.huawei.com>; Tue, 17 May 2011 11:57:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB003ZJMZ0OA@szxga03-in.huawei.com>; Tue, 17 May 2011 11:57:00 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLB00C7CMYZNF@szxml06-in.huawei.com>; Tue, 17 May 2011 11:57:00 +0800 (CST) Date: Tue, 17 May 2011 12:00:52 +0800 From: Qin Wu To: Colin Perkins Message-id: <009b01cc1447$03fd30a0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_wiTdelQSTeEflSL66ZCs/Q)" X-Priority: 3 X-MSMail-priority: Normal References: <05e001cc0e20$5525ba60$46298a0a@china.huawei.com> <02c801cc0eb9$29031bf0$46298a0a@china.huawei.com> <1347F83C-BBEB-4503-9EE1-1EABF7090851@csperkins.org> Cc: AVT WG , xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Open issue- identity info repetition indraft-ietf-avtcore-monarch X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 03:57:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_wiTdelQSTeEflSL66ZCs/Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Colin: It looks like to me we go back to the history and re-pickup the story of identity block again although I haven't gotten invloved into the historical discussion. However I do check with section 4.3 of draft-clark-avt-rtcphr-02 and compare it with measurement identity block specified in draft-ietf-avt-rtcp -xr-meas-identity. I think identity block has already considered the way on how to correlate RTP-layer identity information with other identity data. If you look at the format of identity block, you will see identity block defines the sub-identifier field to carry an additional identifier which can be useful in the context of a specific application, e.g., IMS Charging Identity,SIP Call-ID, all these additional identity can be included in the identity block. Using this application specific identity information, you can easily correlate RTP-layer identity information with other identity data. I think the only problem with measurement identity block is which kind of information should be included, which kind of information should not be included. Therefore it will be good to have a template for measurement identity block or any other new RTCP XR block. Regards! -Qin ----- Original Message ----- From: Colin Perkins To: Qin Wu Cc: AVT WG ; xrblock@ietf.org Sent: Monday, May 16, 2011 6:37 PM Subject: Re: [xrblock] [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch Qin, To my mind, the most important part of the identity block was the correlation tag used to relate RTCP statistics to non-RTCP measurements (draft-clark-avt-rtcphr-02 had something along these lines, although more structured than needed). The tools to save space in RTCP XR packets by removing duplicate identity information when stacking reports are less compelling. Given this, I don't see much value in Section 5.2 of draft-ietf-avtcore-monarch as currently written, and would prefer to see the draft focus on ways to correlate RTP-layer identify information with other identify data. I'd be interested to hear other opinions though. Colin On 10 May 2011, at 03:22, Qin Wu wrote: Just make correction. My colleague reminds me that the example figure 2 does not conflict with report block format defined in draft-ietf-avt-rtcp-xr-meas-identity-02. Since the detailed measurement identity information following the field SSRC of stream source in the figure 2 is omitted. However as I mentioned, it is not clear how much information is included in identity block until identity block is clearly defined in XRBlock WG. That is why I propose to remove figure 2 and related text from this document. Regards! -Qin ----- Original Message ----- From: Qin Wu To: avt@ietf.org ; xrblock@ietf.org Cc: magnus.westerlund@ericsson.com Sent: Monday, May 09, 2011 4:08 PM Subject: [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch In the last IETF meeting, there was discussion on identity info repetition or dupplication. However it was not clear whether new packet type for identity block is needed. Here is some clarification and prososal from my point of view. In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it is assumed there is an RTCP XR packet containing four metrics blocks, reporting on streams from two source. each source is associated with two meric block. In order to reduce overhead to carry duplicated data for all the metric block contained in the same RTCP XR packet, it was proposed by draft-ietf-avtcore-monarch that measurement identity information should be separated from metric block and form independent block. However this proposal save zero octets in figure 2. So the question is whether an identity block is actually needed if identity information only contain SSRC of stream souce, or if just stacking multiple XR Blocks is acceptable. However I re-check with RTCP XR Report Block for Measurement Identity defined in draft-ietf-avt-rtcp-xr-meas-identity-02, identity information included is more than SSRC of stream source. So it should be useful to define new packet type for identity block. However the example figure 2(i.e., only contain SSRC of stream souce) is actually not consistent with report block format defined in draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC of stream source). Also as we know, identity block work has just started from XRBlock WG, Therefore I suggest that the example (Figure 2, and the related discussion) is removed until the identity block is clearly defined in XRBLock. Any Comments or suggestion? Regards! -Qin -------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ xrblock mailing list xrblock@ietf.org https://www.ietf.org/mailman/listinfo/xrblock -- Colin Perkins http://csperkins.org/ --Boundary_(ID_wiTdelQSTeEflSL66ZCs/Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODk5OSI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIA0Kc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIiANCmJnQ29s b3I9I2NjZThjZj4NCjxESVY+SGksIENvbGluOjwvRElWPg0KPERJVj5JdCBsb29rcyBsaWtlIHRv IG1lIHdlIGdvIGJhY2sgdG8gdGhlIGhpc3RvcnkgYW5kIHJlLXBpY2t1cCB0aGUgc3Rvcnkgb2Yg DQppZGVudGl0eSBibG9jayBhZ2FpbiBhbHRob3VnaCBJIGhhdmVuJ3QgZ290dGVuIGludmxvdmVk IGludG8gdGhlIGhpc3RvcmljYWwgDQpkaXNjdXNzaW9uLjwvRElWPg0KPERJVj5Ib3dldmVyIEkg ZG8gY2hlY2sgd2l0aCBzZWN0aW9uIDQuMyBvZiBkcmFmdC1jbGFyay1hdnQtcnRjcGhyLTAyIGFu ZCANCmNvbXBhcmUgaXQgd2l0aCBtZWFzdXJlbWVudCBpZGVudGl0eSBibG9jayBzcGVjaWZpZWQg aW4gDQpkcmFmdC1pZXRmLWF2dC1ydGNwPC9ESVY+DQo8RElWPi14ci1tZWFzLWlkZW50aXR5LiA8 L0RJVj4NCjxESVY+SSB0aGluayBpZGVudGl0eSBibG9jayBoYXMgYWxyZWFkeSBjb25zaWRlcmVk IHRoZSB3YXkgb24gaG93IHRvIGNvcnJlbGF0ZSANClJUUC1sYXllciBpZGVudGl0eSBpbmZvcm1h dGlvbiB3aXRoIG90aGVyIGlkZW50aXR5IGRhdGEuIElmIHlvdSBsb29rIGF0IHRoZSANCmZvcm1h dDwvRElWPg0KPERJVj5vZiBpZGVudGl0eSBibG9jaywgeW91IHdpbGwgc2VlIGlkZW50aXR5IGJs b2NrIGRlZmluZXMgdGhlIHN1Yi1pZGVudGlmaWVyIA0KZmllbGQgdG8mbmJzcDtjYXJyeSBhbiBh ZGRpdGlvbmFsIGlkZW50aWZpZXIgd2hpY2gmbmJzcDtjYW4gYmUmbmJzcDt1c2VmdWwgaW4gDQp0 aGUgY29udGV4dCBvZiBhJm5ic3A7c3BlY2lmaWMgYXBwbGljYXRpb24sIGUuZy4sPC9ESVY+DQo8 RElWPklNUyBDaGFyZ2luZyBJZGVudGl0eSxTSVAgQ2FsbC1JRCwgYWxsIHRoZXNlIGFkZGl0aW9u YWwgaWRlbnRpdHkgY2FuIGJlIA0KaW5jbHVkZWQgaW4gdGhlIGlkZW50aXR5IGJsb2NrLiBVc2lu ZyB0aGlzIGFwcGxpY2F0aW9uIHNwZWNpZmljIGlkZW50aXR5IA0KaW5mb3JtYXRpb24sIDwvRElW Pg0KPERJVj55b3UgY2FuIGVhc2lseSBjb3JyZWxhdGUgUlRQLWxheWVyIGlkZW50aXR5IGluZm9y bWF0aW9uIHdpdGggb3RoZXIgaWRlbnRpdHkgDQpkYXRhLjwvRElWPg0KPERJVj5JIHRoaW5rIHRo ZSBvbmx5IHByb2JsZW0gd2l0aCBtZWFzdXJlbWVudCBpZGVudGl0eSBibG9jayBpcyB3aGljaCBr aW5kIG9mIA0KaW5mb3JtYXRpb24gc2hvdWxkIGJlIGluY2x1ZGVkLCB3aGljaCBraW5kIG9mIGlu Zm9ybWF0aW9uIHNob3VsZCBub3QgYmUgDQppbmNsdWRlZC48L0RJVj4NCjxESVY+VGhlcmVmb3Jl IGl0IHdpbGwgYmUgZ29vZCB0byBoYXZlIGEgdGVtcGxhdGUgZm9yIG1lYXN1cmVtZW50IGlkZW50 aXR5IGJsb2NrIA0Kb3IgYW55IG90aGVyIG5ldyBSVENQIFhSIGJsb2NrLjwvRElWPg0KPERJVj48 Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPlJlZ2FyZHMhPC9ESVY+DQo8RElWPi1RaW48L0RJVj4NCjxC TE9DS1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElO Ry1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lO LVJJR0hUOiAwcHgiIA0KZGlyPWx0cj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250 LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1jc3BAY3NwZXJraW5zLm9y ZyBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciPkNvbGluIFBlcmtpbnM8L0E+IA0KICA8 L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwv Qj4gPEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnN1bnNlYXdx QGh1YXdlaS5jb20iPlFpbiBXdTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAm IzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWF2dEBpZXRmLm9yZyANCiAgaHJl Zj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+QVZUIFdHPC9BPiA7IDxBIHRpdGxlPXhyYmxvY2tAaWV0 Zi5vcmcgDQogIGhyZWY9Im1haWx0bzp4cmJsb2NrQGlldGYub3JnIj54cmJsb2NrQGlldGYub3Jn PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxC PlNlbnQ6PC9CPiBNb25kYXksIE1heSAxNiwgMjAxMSA2OjM3IFBNPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFt4cmJs b2NrXSBbQVZUQ09SRV0gT3BlbiBpc3N1ZS0gDQogIGlkZW50aXR5IGluZm8gcmVwZXRpdGlvbiBp bmRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPlFpbiwN CiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+VG8gbXkgbWluZCwgdGhlIG1vc3QgaW1wb3J0YW50 IHBhcnQgb2YgdGhlIGlkZW50aXR5IGJsb2NrIHdhcyB0aGUgDQogIGNvcnJlbGF0aW9uIHRhZyB1 c2VkIHRvIHJlbGF0ZSBSVENQIHN0YXRpc3RpY3MgdG8gbm9uLVJUQ1AgbWVhc3VyZW1lbnRzIA0K ICAoZHJhZnQtY2xhcmstYXZ0LXJ0Y3Boci0wMiBoYWQgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxp bmVzLCBhbHRob3VnaCBtb3JlIA0KICBzdHJ1Y3R1cmVkIHRoYW4gbmVlZGVkKS4gVGhlIHRvb2xz IHRvIHNhdmUgc3BhY2UgaW4gUlRDUCBYUiBwYWNrZXRzIGJ5IA0KICByZW1vdmluZyBkdXBsaWNh dGUgaWRlbnRpdHkgaW5mb3JtYXRpb24gd2hlbiBzdGFja2luZyByZXBvcnRzIGFyZSBsZXNzIA0K ICBjb21wZWxsaW5nLiBHaXZlbiB0aGlzLCBJIGRvbid0IHNlZSBtdWNoIHZhbHVlIGluIFNlY3Rp b24gNS4yIG9mIA0KICBkcmFmdC1pZXRmLWF2dGNvcmUtbW9uYXJjaCBhcyBjdXJyZW50bHkgd3Jp dHRlbiwgYW5kIHdvdWxkIHByZWZlciB0byBzZWUgdGhlIA0KICBkcmFmdCBmb2N1cyBvbiB3YXlz IHRvIGNvcnJlbGF0ZSBSVFAtbGF5ZXIgaWRlbnRpZnkgaW5mb3JtYXRpb24gd2l0aCBvdGhlciAN CiAgaWRlbnRpZnkgZGF0YS48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+SSdkIGJl IGludGVyZXN0ZWQgdG8gaGVhciBvdGhlciBvcGluaW9ucyB0aG91Z2guPC9ESVY+DQogIDxESVY+ PEJSPjwvRElWPg0KICA8RElWPkNvbGluPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElW PjxCUj48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElW PjxCUj4NCiAgPERJVj4NCiAgPERJVj5PbiAxMCBNYXkgMjAxMSwgYXQgMDM6MjIsIFFpbiBXdSB3 cm90ZTo8L0RJVj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFNQQU4gDQogICAgc3R5bGU9 IldJRE9XUzogMjsgVEVYVC1UUkFOU0ZPUk06IG5vbmU7IFRFWFQtSU5ERU5UOiAwcHg7IEJPUkRF Ui1DT0xMQVBTRTogc2VwYXJhdGU7IEZPTlQ6IG1lZGl1bSAnTHVjaWRhIFNhbnMgVHlwZXdyaXRl cic7IFdISVRFLVNQQUNFOiBub3JtYWw7IE9SUEhBTlM6IDI7IExFVFRFUi1TUEFDSU5HOiBub3Jt YWw7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt ZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgDQogICAgY2xhc3M9QXBwbGUtc3R5 bGUtc3Bhbj4NCiAgICA8RElWIGJnY29sb3I9IiNjY2U4Y2YiPg0KICAgIDxESVY+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj5KdXN0IG1ha2UgY29ycmVjdGlvbi4gTXkgY29sbGVhZ3VlIHJl bWluZHMgDQogICAgbWUgdGhhdCB0aGUgZXhhbXBsZSBmaWd1cmUgMiZuYnNwOyBkb2VzIG5vdCBj b25mbGljdCB3aXRoIHJlcG9ydCBibG9jayANCiAgICBmb3JtYXQgZGVmaW5lZCBpbiBkcmFmdC1p ZXRmLWF2dC1ydGNwLXhyLW1lYXMtaWRlbnRpdHktMDIuPC9GT05UPjwvRElWPg0KICAgIDxESVY+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TaW5jZSB0aGUgZGV0YWlsZWQgbWVhc3VyZW1l bnQgaWRlbnRpdHkgDQogICAgaW5mb3JtYXRpb24mbmJzcDtmb2xsb3dpbmcgdGhlIGZpZWxkIFNT UkMgb2Ygc3RyZWFtIHNvdXJjZSZuYnNwO2luIHRoZSANCiAgICBmaWd1cmUgMiBpcyBvbWl0dGVk LjwvRk9OVD48L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SG93 ZXZlciBhcyBJIG1lbnRpb25lZCwgaXQgaXMgbm90IGNsZWFyIA0KICAgIGhvdyBtdWNoIGluZm9y bWF0aW9uIGlzIGluY2x1ZGVkIGluIGlkZW50aXR5IGJsb2NrIHVudGlsIGlkZW50aXR5IGJsb2Nr IGlzIA0KICAgIGNsZWFybHkgZGVmaW5lZCBpbiBYUkJsb2NrIFdHLjwvRk9OVD48L0RJVj4NCiAg ICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhhdCBpcyB3aHkgSSBwcm9wb3Nl IHRvIHJlbW92ZSBmaWd1cmUgMiANCiAgICBhbmQgcmVsYXRlZCB0ZXh0IGZyb20gdGhpcyBkb2N1 bWVudC48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+UmVnYXJkcyE8L0ZPTlQ+PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPi1RaW48L0ZPTlQ+PC9ESVY+DQogICAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tPC9ESVY+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9IkJPUkRFUi1MRUZUOiBy Z2IoMCwwLDApIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBw eDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgPERJViANCiAg ICAgIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjI4LDIyOCwyMjgpOyBGT05UOiA5cHQg 5a6L5L2TOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0 aWFsIj48Qj5Gcm9tOjwvQj48U1BBTiANCiAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFj ZT4mbmJzcDs8L1NQQU4+PEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgICAgIGhyZWY9 Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+PC9ESVY+DQogICAgICA8RElW IHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+PFNQQU4gDQogICAgICBjbGFzcz1B cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIHRpdGxlPWF2dEBpZXRmLm9yZyAN CiAgICAgIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT48U1BBTiAN CiAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+OzxTUEFOIA0K ICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSB0aXRsZT14 cmJsb2NrQGlldGYub3JnIA0KICAgICAgaHJlZj0ibWFpbHRvOnhyYmxvY2tAaWV0Zi5vcmciPnhy YmxvY2tAaWV0Zi5vcmc8L0E+PC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L 5L2TIj48Qj5DYzo8L0I+PFNQQU4gDQogICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9TUEFOPjxBIA0KICAgICAgdGl0bGU9bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24u Y29tIA0KICAgICAgaHJlZj0ibWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbSI+ bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPC9BPjwvRElWPg0KICAgICAgPERJViBzdHls ZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+U2VudDo8L0I+PFNQQU4gDQogICAgICBjbGFzcz1BcHBs ZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPk1vbmRheSwgTWF5IDA5LCAyMDExIDQ6MDgg DQpQTTwvRElWPg0KICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+U3ViamVj dDo8L0I+PFNQQU4gDQogICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9T UEFOPltBVlRDT1JFXSBPcGVuIGlzc3VlLSBpZGVudGl0eSANCiAgICAgIGluZm8gcmVwZXRpdGlv biBpbmRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJ Vj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JbiB0aGUgbGFzdCBJ RVRGIG1lZXRpbmcsIHRoZXJlIHdhcyANCiAgICAgIGRpc2N1c3Npb24gb24gaWRlbnRpdHkgaW5m byByZXBldGl0aW9uIG9yIGR1cHBsaWNhdGlvbi4gSG93ZXZlciANCiAgICAgIGl0PC9GT05UPjwv RElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwO3dhcyBu b3QgY2xlYXIgd2hldGhlciBuZXcgcGFja2V0IA0KICAgICAgdHlwZSBmb3IgaWRlbnRpdHkgYmxv Y2sgaXMgbmVlZGVkLiBIZXJlIGlzIHNvbWUgY2xhcmlmaWNhdGlvbiANCiAgICAgIGFuZDwvRk9O VD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5wcm9zb3Nh bCBmcm9tIG15IHBvaW50IG9mIA0KICAgICAgdmlldy48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAg PERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkluIHRoZSBleGFtcGxlIGZpZ3VyZSAy IG9mIHNlY3Rpb24gNS4yIA0KICAgICAgaW4mbmJzcDtkcmF0LWlldGYtYXZ0Y29yZS1tb25hcmNo LCBpdCBpcyZuYnNwO2Fzc3VtZWQgDQogICAgICB0aGVyZSZuYnNwO2lzJm5ic3A7YW4gUlRDUDwv Rk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDtYUiBwYWNrZXQgY29udGFpbmluZyZuYnNwO2ZvdXIgDQogICAgICBtZXRyaWNzIGJsb2Nrcywg cmVwb3J0aW5nIG9uIHN0cmVhbXMgZnJvbSZuYnNwO3R3byBzb3VyY2UuPC9GT05UPjwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmVhY2ggc291cmNlIGlzIGFz c29jaWF0ZWQgd2l0aCB0d28gbWVyaWMgDQogICAgICBibG9jay48L0ZPTlQ+PC9ESVY+DQogICAg ICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9GT05UPiZuYnNwOzwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkluIG9yZGVyIHRvIHJlZHVj ZSBvdmVyaGVhZCB0byBjYXJyeSANCiAgICAgIGR1cGxpY2F0ZWQgZGF0YSBmb3ImbmJzcDthbGwg dGhlIG1ldHJpYyBibG9jayBjb250YWluZWQgaW48L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+dGhlIHNhbWUgUlRDUCBYUiBwYWNrZXQsIGl0IHdh cyBwcm9wb3NlZCANCiAgICAgIGJ5IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoIHRoYXQmbmJz cDttZWFzdXJlbWVudDwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5pZGVudGl0eSBpbmZvcm1hdGlvbiBzaG91bGQgYmUgc2VwYXJhdGVkIA0KICAg ICAgZnJvbSBtZXRyaWMgYmxvY2sgYW5kIGZvcm0gaW5kZXBlbmRlbnQgYmxvY2suPC9GT05UPjwv RElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJz cDs8L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5Ib3dldmVy IHRoaXMgcHJvcG9zYWwgc2F2ZSZuYnNwO3plcm8gDQogICAgICBvY3RldHMgaW4gZmlndXJlIDIu IFNvIHRoZSBxdWVzdGlvbiZuYnNwOyBpczwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj53aGV0aGVyIGFuIGlkZW50aXR5IGJsb2NrJm5ic3A7aXMg DQogICAgICBhY3R1YWxseSBuZWVkZWQgaWYgaWRlbnRpdHkgaW5mb3JtYXRpb248L0ZPTlQ+PC9E SVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+b25seSBjb250YWlu IFNTUkMgb2Ygc3RyZWFtIHNvdWNlLCBvciBpZiANCiAgICAgIGp1c3Qgc3RhY2tpbmc8L0ZPTlQ+ PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+bXVsdGlwbGUg WFIgQmxvY2tzIA0KICAgICAgaXMmbmJzcDthY2NlcHRhYmxlLjwvRk9OVD48L0RJVj4NCiAgICAg IDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog ICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SG93ZXZlciBJIHJlLWNoZWNr IHdpdGggUlRDUCBYUiBSZXBvcnQgDQogICAgICBCbG9jayBmb3IgTWVhc3VyZW1lbnQgSWRlbnRp dHkgZGVmaW5lZCBpbjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj5kcmFmdC1pZXRmLWF2dC1ydGNwLXhyLW1lYXMtaWRlbnRpdHktMDIsIA0KICAg ICAgaWRlbnRpdHkgaW5mb3JtYXRpb24gaW5jbHVkZWQgaXMgbW9yZSB0aGFuPC9GT05UPjwvRElW Pg0KICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlNTUkMgb2Ygc3RyZWFt IHNvdXJjZS4gU28gaXQgc2hvdWxkIGJlIA0KICAgICAgdXNlZnVsIHRvIGRlZmluZSBuZXcgcGFj a2V0IHR5cGUgZm9yIGlkZW50aXR5IGJsb2NrLjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZP TlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICA8RElW PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SG93ZXZlciZuYnNwO3RoZSBleGFtcGxlIGZp Z3VyZSAyKGkuZS4sIA0KICAgICAgb25seSBjb250YWluIFNTUkMgb2Ygc3RyZWFtIHNvdWNlKSBp cyBhY3R1YWxseSBub3QgY29uc2lzdGVudCB3aXRoIHJlcG9ydCANCiAgICAgIGJsb2NrIGZvcm1h dCBkZWZpbmVkIGluPC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9OVCANCiAgICAgIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+ZHJhZnQtaWV0Zi1hdnQtcnRjcC14ci1tZWFzLWlkZW50aXR5LTAy KGkuZS4sIA0KICAgICAgY29udGFpbiBtb3JlIHRoYW4gU1NSQyBvZiBzdHJlYW0gc291cmNlKS48 L0ZPTlQ+PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PC9G T05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PkFsc28gYXMgd2Uga25vdywmbmJzcDtpZGVudGl0eSBibG9jayANCiAgICAgIHdvcmsgaGFzIGp1 c3Qgc3RhcnRlZCBmcm9tIFhSQmxvY2sgV0csPC9GT05UPjwvRElWPg0KICAgICAgPERJVj48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoZXJlZm9yZSAmbmJzcDtJIHN1Z2dlc3QmbmJzcDt0 aGF0IHRoZSANCiAgICAgIGV4YW1wbGU8U1BBTiBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+ Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCANCiAgICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ KEZpZ3VyZSAyLCBhbmQgdGhlIHJlbGF0ZWQmbmJzcDtkaXNjdXNzaW9uKSBpcyANCiAgICAgIHJl bW92ZWQgdW50aWwgdGhlIGlkZW50aXR5IGJsb2NrIGlzIGNsZWFybHk8L0ZPTlQ+PC9ESVY+DQog ICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ZGVmaW5lZCBpbiBYUkJMb2Nr LjwvRk9OVD48L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+QW55IENvbW1lbnRzIG9yIHN1Z2dlc3Rpb24/PC9GT05UPjwvRElWPg0KICAgICAgPERJVj48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgIDxE SVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5SZWdhcmRzITwvRk9OVD48L0RJVj4NCiAg ICAgIDxESVY+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4tUWluPC9GT05UPjwvRElWPg0K ICAgICAgPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KICAgICAgPERJVj48 QlIgY2xhc3M9d2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyPjwvRElWPg0KICAgICAgPEhSPg0KDQog ICAgICA8RElWPjxCUiANCiAgICAgIGNsYXNzPXdlYmtpdC1ibG9jay1wbGFjZWhvbGRlcj48L0RJ Vj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5BdWRp by9WaWRlbyANCiAgICAgIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlPEJSPjxBIA0KICAgICAg aHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPjxCUj48QSANCiAgICAg IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvQT48QlI+PC9CTE9DS1FVT1RFPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPnhyYmxvY2sg DQogICAgbWFpbGluZyBsaXN0PEJSPjxBIGhyZWY9Im1haWx0bzp4cmJsb2NrQGlldGYub3JnIj54 cmJsb2NrQGlldGYub3JnPC9BPjxCUj48QSANCiAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3hyYmxvY2siPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8veHJibG9jazwvQT48QlI+PC9ESVY+PC9TUEFOPjwvQkxPQ0tRVU9URT48L0RJVj4N CiAgPERJVj48U1BBTiANCiAgc3R5bGU9IldJRE9XUzogMjsgVEVYVC1UUkFOU0ZPUk06IG5vbmU7 IFRFWFQtSU5ERU5UOiAwcHg7IEJPUkRFUi1DT0xMQVBTRTogc2VwYXJhdGU7IEZPTlQ6IDlweCBB cmlhbDsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5v cm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRl ci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0 LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDAiIA0K ICBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhU LVRSQU5TRk9STTogbm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBh cmF0ZTsgRk9OVDogOXB4ICdMdWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5v cm1hbDsgT1JQSEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAs MCk7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt ZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgDQogIGNsYXNzPUFwcGxlLXN0eWxl LXNwYW4+PFNQQU4gDQogIHN0eWxlPSJXSURPV1M6IDI7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBU RVhULUlOREVOVDogMHB4OyBCT1JERVItQ09MTEFQU0U6IHNlcGFyYXRlOyBGT05UOiA5cHggJ0x1 Y2lkYSBTYW5zIFR5cGV3cml0ZXInOyBXSElURS1TUEFDRTogbm9ybWFsOyBPUlBIQU5TOiAyOyBM RVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFDSU5HOiAw cHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRl ci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZl Y3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0byIgDQogIGNsYXNzPUFwcGxl LXN0eWxlLXNwYW4+PFNQQU4gDQogIHN0eWxlPSJXSURPV1M6IDI7IFRFWFQtVFJBTlNGT1JNOiBu b25lOyBURVhULUlOREVOVDogMHB4OyBCT1JERVItQ09MTEFQU0U6IHNlcGFyYXRlOyBGT05UOiA5 cHggJ0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXInOyBXSElURS1TUEFDRTogbm9ybWFsOyBPUlBIQU5T OiAyOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09SRC1TUEFD SU5HOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0 LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1p bi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0byIgDQogIGNsYXNz PUFwcGxlLXN0eWxlLXNwYW4+PFNQQU4gDQogIHN0eWxlPSJXSURPV1M6IDI7IFRFWFQtVFJBTlNG T1JNOiBub25lOyBURVhULUlOREVOVDogMHB4OyBCT1JERVItQ09MTEFQU0U6IHNlcGFyYXRlOyBG T05UOiA5cHggJ0x1Y2lkYSBTYW5zIFR5cGV3cml0ZXInOyBXSElURS1TUEFDRTogbm9ybWFsOyBP UlBIQU5TOiAyOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBDT0xPUjogcmdiKDAsMCwwKTsgV09S RC1TUEFDSU5HOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAt d2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0 aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0byIgDQog IGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+DQogIDxESVY+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog bWVkaXVtIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPjxCUiANCiAgY2xhc3M9a2h0bWwtYmxvY2st cGxhY2Vob2xkZXI+PC9TUEFOPjwvRElWPg0KICA8RElWPi0tJm5ic3A7PC9ESVY+DQogIDxESVY+ PC9ESVY+DQogIDxESVY+Q29saW4gUGVya2luczwvRElWPg0KICA8RElWPjxBIA0KICBocmVmPSJo dHRwOi8vY3NwZXJraW5zLm9yZy8iPmh0dHA6Ly9jc3BlcmtpbnMub3JnLzwvQT48L0RJVj48L1NQ QU4+PC9TUEFOPjwvU1BBTj48QlIgDQogIGNsYXNzPUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmU+ PC9TUEFOPjxCUiANCiAgY2xhc3M9QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZT48L1NQQU4+PC9E SVY+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_wiTdelQSTeEflSL66ZCs/Q)-- From gwz@net-zen.net Mon May 16 23:47:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2AEE069E for ; Mon, 16 May 2011 23:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRUNQXRoMIMv for ; Mon, 16 May 2011 23:47:54 -0700 (PDT) Received: from smtpauth01.prod.mesa1.secureserver.net (smtpauth01.prod.mesa1.secureserver.net [64.202.165.181]) by ietfa.amsl.com (Postfix) with SMTP id 74D85E0682 for ; Mon, 16 May 2011 23:47:54 -0700 (PDT) Received: (qmail 8977 invoked from network); 17 May 2011 06:47:53 -0000 Received: from unknown (124.120.81.30) by smtpauth01.prod.mesa1.secureserver.net (64.202.165.181) with ESMTP; 17 May 2011 06:47:53 -0000 Message-ID: <4DD21A12.4080901@net-zen.net> Date: Tue, 17 May 2011 13:47:46 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avt@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------090706070508060801050200" Subject: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 06:47:55 -0000 This is a multi-part message in MIME format. --------------090706070508060801050200 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Section 10 says "Geoff Hunt and Philip Arden wrote the initial draft for this document". That being the case, they should be listed as authors or, at the very least, in a "Contributors" section; I much prefer the former, since there is no lack of space on the front page. In that same vein, I think that Qin Wu should be listed as "Editor". Also in Section 10: s/Acknowledgement/Acknowledgments/ s/Drage,Dan/Drage, Dan/ s/Begen, Roni/Begen and Roni/ s/early version/early versions/ --------------090706070508060801050200 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090706070508060801050200-- From magnus.westerlund@ericsson.com Mon May 16 23:59:56 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDEEE072D for ; Mon, 16 May 2011 23:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaT+HKRUf+Vx for ; Mon, 16 May 2011 23:59:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9298FE069E for ; Mon, 16 May 2011 23:59:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c86ae000000b90-39-4dd21ce93300 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DB.9B.02960.9EC12DD4; Tue, 17 May 2011 08:59:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 May 2011 08:59:51 +0200 Message-ID: <4DD21CE7.5030604@ericsson.com> Date: Tue, 17 May 2011 08:59:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Glen Zorn References: <4DD21A12.4080901@net-zen.net> In-Reply-To: <4DD21A12.4080901@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 06:59:56 -0000 On 2011-05-17 08:47, Glen Zorn wrote: > Section 10 says "Geoff Hunt and Philip Arden wrote the initial draft for > this document". That being the case, they should be listed as authors > or, at the very least, in a "Contributors" section; I much prefer the > former, since there is no lack of space on the front page. In that same > vein, I think that Qin Wu should be listed as "Editor". I agree that they need to be duly credited. However, unless they are at least somewhat active and willing to respond to some emails at least in the RFC-editor phase they need to be in the contributor section. Otherwise they are holding up the process and forces us and the AD to do extra process. > > Also in Section 10: > s/Acknowledgement/Acknowledgments/ > s/Drage,Dan/Drage, Dan/ > s/Begen, Roni/Begen and Roni/ > s/early version/early versions/ > Cheers 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 gwz@net-zen.net Tue May 17 00:16:10 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBEBE067F for ; Tue, 17 May 2011 00:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWIaZEcemZQW for ; Tue, 17 May 2011 00:16:09 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by ietfa.amsl.com (Postfix) with SMTP id C8B2FE07E4 for ; Tue, 17 May 2011 00:16:09 -0700 (PDT) Received: (qmail 16884 invoked from network); 17 May 2011 07:16:08 -0000 Received: from unknown (124.120.81.30) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 17 May 2011 07:16:08 -0000 Message-ID: <4DD220B4.1080002@net-zen.net> Date: Tue, 17 May 2011 14:16:04 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4DD21A12.4080901@net-zen.net> <4DD21CE7.5030604@ericsson.com> In-Reply-To: <4DD21CE7.5030604@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------010500000801060708050905" Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 07:16:10 -0000 This is a multi-part message in MIME format. --------------010500000801060708050905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 5/17/2011 1:59 PM, Magnus Westerlund wrote: > On 2011-05-17 08:47, Glen Zorn wrote: >> Section 10 says "Geoff Hunt and Philip Arden wrote the initial draft for >> this document". That being the case, they should be listed as authors >> or, at the very least, in a "Contributors" section; I much prefer the >> former, since there is no lack of space on the front page. In that same >> vein, I think that Qin Wu should be listed as "Editor". > > I agree that they need to be duly credited. However, unless they are at > least somewhat active and willing to respond to some emails at least in > the RFC-editor phase they need to be in the contributor section. > Otherwise they are holding up the process and forces us and the AD to do > extra process. But all they really need to do is respond to AUTH48, right? My view is that if they wrote the document then they need to be authors; if at the end they disappear (i.e., are unreachable), they can always be removed. --------------010500000801060708050905 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------010500000801060708050905-- From magnus.westerlund@ericsson.com Tue May 17 00:20:22 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD99CE07E4 for ; Tue, 17 May 2011 00:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t13K11u88FrE for ; Tue, 17 May 2011 00:20:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8996CE067F for ; Tue, 17 May 2011 00:20:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c86ae000000b90-7e-4dd221b46da5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 57.AF.02960.4B122DD4; Tue, 17 May 2011 09:20:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 May 2011 09:20:20 +0200 Message-ID: <4DD221B4.3000609@ericsson.com> Date: Tue, 17 May 2011 09:20:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Glen Zorn References: <4DD21A12.4080901@net-zen.net> <4DD21CE7.5030604@ericsson.com> <4DD220B4.1080002@net-zen.net> In-Reply-To: <4DD220B4.1080002@net-zen.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 07:20:22 -0000 On 2011-05-17 09:16, Glen Zorn wrote: > On 5/17/2011 1:59 PM, Magnus Westerlund wrote: > >> On 2011-05-17 08:47, Glen Zorn wrote: >>> Section 10 says "Geoff Hunt and Philip Arden wrote the initial draft for >>> this document". That being the case, they should be listed as authors >>> or, at the very least, in a "Contributors" section; I much prefer the >>> former, since there is no lack of space on the front page. In that same >>> vein, I think that Qin Wu should be listed as "Editor". >> >> I agree that they need to be duly credited. However, unless they are at >> least somewhat active and willing to respond to some emails at least in >> the RFC-editor phase they need to be in the contributor section. >> Otherwise they are holding up the process and forces us and the AD to do >> extra process. > > But all they really need to do is respond to AUTH48, right? My view is > that if they wrote the document then they need to be authors; if at the > end they disappear (i.e., are unreachable), they can always be removed. Yes, they need to respond to that, and ensure that they have a working email address in the draft. Otherwise I personally do have a preference for keeping them as authors, but please ensure that they are asked for their preference. Cheers 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 sunseawq@huawei.com Tue May 17 01:21:56 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30E7E072F for ; Tue, 17 May 2011 01:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TS7-1kz+G-rm for ; Tue, 17 May 2011 01:21:55 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7E540E06E9 for ; Tue, 17 May 2011 01:21:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00FNXZ51QX@szxga03-in.huawei.com> for avt@ietf.org; Tue, 17 May 2011 16:19:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLB00EGQZ51SS@szxga03-in.huawei.com> for avt@ietf.org; Tue, 17 May 2011 16:19:49 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLB00K5UZ51C0@szxml04-in.huawei.com> for avt@ietf.org; Tue, 17 May 2011 16:19:49 +0800 (CST) Date: Tue, 17 May 2011 16:23:42 +0800 From: Qin Wu To: Glen Zorn , avt@ietf.org Message-id: <021701cc146b$bb82cef0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4DD21A12.4080901@net-zen.net> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 08:21:56 -0000 Hi, Thank for your brief review. See inline. ----- Original Message ----- From: "Glen Zorn" To: Sent: Tuesday, May 17, 2011 2:47 PM Subject: [AVTCORE] Comments on draft-ietf-avtcore-monarch-01 > Section 10 says "Geoff Hunt and Philip Arden wrote the initial draft for > this document". That being the case, they should be listed as authors > or, at the very least, in a "Contributors" section; I much prefer the > former, since there is no lack of space on the front page. [Qin]: Good question, However it was not my intent to move them to acknowledgement section. Also I agree they did a lot of work. If WG think we should honor them, I can put them back in the new version. BTW: I do check with one of author of intial draft: Philip before. He said he will keep an eye on this work. >In that same > vein, I think that Qin Wu should be listed as "Editor". > Also in Section 10: > s/Acknowledgement/Acknowledgments/ > s/Drage,Dan/Drage, Dan/ > s/Begen, Roni/Begen and Roni/ > s/early version/early versions/ [Qin]: Thanks, Your proposed editorial changes will be reflected in the new version. -------------------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From mperumal@cisco.com Tue May 17 05:41:17 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014D4E0769 for ; Tue, 17 May 2011 05:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyQjWlCXJ2ON for ; Tue, 17 May 2011 05:41:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9848BE0766 for ; Tue, 17 May 2011 05:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=37685; q=dns/txt; s=iport; t=1305636074; x=1306845674; h=mime-version:subject:date:message-id:from:to:cc; bh=iFkbUX8/qZfXIRHK2ITQcRGsGqUcpbn1JVnO1Pw+wjA=; b=GAS8tk14o95148fhyXI7nZfPszhqenlOSFkEl4UCelcm23jI4k2/pzBt AN/3rJ8I7xYgulR/xPz3ph2ZrLRpivvYKUyotD1MVc9eDhNmFwFEoTWmC dXTsnNqHb6ecIcx3IUBGRskRZQxl628V4oDcb1eJMwfxG2h9pKYoxSrLU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH5s0k1Io8UR/2dsb2JhbACCZaM0d6oNniyGGQSGTo17ikU X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208,217";a="88966630" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 17 May 2011 12:41:12 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4HCfBib025410 for ; Tue, 17 May 2011 12:41:11 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 May 2011 18:11:11 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-CR-Hashedpuzzle: Z4k= AFsV AQ8s Aqgo A04X BFot CF0p C9x0 DCTt DC/1 FuOZ Ghgv H6RC H+7U IdMU Isem; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AE73E14D-7CF6-4ACF-9388-E09B87B77CEC}; bQBwAGUAcgB1AG0AYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Tue, 17 May 2011 12:41:06 GMT; TwBmAGYAZQByAC8AYQBuAHMAdwBlAHIAIABpAG4AdABlAHIAcAByAGUAdABhAHQAaQBvAG4AIABvAGYAIABhAG4AbgBlAHgAYQAvAGEAbgBuAGUAeABiACAAcABhAHIAYQBtAGUAdABlAHIAIABpAG4AIABSAEYAQwAgADQAOAA1ADYA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC148F.B3BE784E" X-CR-Puzzleid: {AE73E14D-7CF6-4ACF-9388-E09B87B77CEC} Content-class: urn:content-classes:message Date: Tue, 17 May 2011 18:11:06 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020570A4A1@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Offer/answer interpretation of annexa/annexb parameter in RFC 4856 Thread-Index: AcwUj7CarcYTSbxWRJyHKEmYAzM+Rw== From: "Muthu Arul Mozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 17 May 2011 12:41:11.0645 (UTC) FILETIME=[B3CEB8D0:01CC148F] Cc: "Flemming Andreasen \(fandreas\)" , "Parthasarathi R \(partr\)" , "Paul Kyzivat \(pkyzivat\)" Subject: [AVTCORE] Offer/answer interpretation of annexa/annexb parameter in RFC 4856 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 12:41:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC148F.B3BE784E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E as follows: =20 indicates that voice activity detection, is used or preferred. =20 Permissible values are "yes" and "no" (without the quotes);=20 "yes" is implied if this parameter is omitted. =20 However, it doesn't have any normative statement for the case where the value of this parameter doesn't match in the SDP offer and answer. If the offer has G729 with annexb=3Dyes and the answer has G729 with annexb=3Dno, common sense seems to suggest that: 1) The offerer and answerer should proceed as if G729 is negotiated with annexb=3Dno.=20 2) The parameter can be turned off by the answerer, but cannot be turned on (if the offerer had turned it off). =20 However, because RFC 4856 doesn't state it clearly, various implementations seem to have interpreted it in their own ways, including choosing a different codec to failing the call, if the parameter doesn't match in the offer/answer, as in: http://sipforum.org/pipermail/discussion/2008-January/004026.html =20 RFC 3264 has the following about fmtp parameters, which indicate the Annex B (or Annex A) capability in offer/answer: =20 The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer. =20 Ideally, RFC 4856 should have specified proper interpretation when the Annex B (or Annex A) capability specified in the fmtp parameter doesn't match in the offer/answer. =20 What would be the best way to fix this? By submitting a new draft clarifying the recommended behavior (BCP) or by submitting an errata against RFC 4856 and waiting for its next revision? =20 thanks, Muthu =20 =20 ------_=_NextPart_001_01CC148F.B3BE784E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 4856 describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E as follows:

 

    indicates that = voice activity detection, is used or preferred. 

    Permissible values = are "yes" and "no" (without the quotes); =

    "yes" is = implied if this parameter is omitted.

 

However, it doesn't have any normative statement = for the case where the value of this parameter doesn't match in the SDP offer and answer. If the offer has G729 with = annexb=3Dyes and the answer has G729 with annexb=3Dno, common sense seems to = suggest that:

1) The offerer and = answerer should proceed as if G729 is negotiated with = annexb=3Dno.

2) The parameter can be turned off by the = answerer, but cannot be turned on (if the offerer had = turned it off).

 

However, because RFC 4856 doesn't state it clearly, various implementations seem to have interpreted it in their own ways, including = choosing a different codec to failing the call, if the parameter doesn't match in = the offer/answer, as in:

http://sipforum.org/pipermail/discussion/2008-January/004026.html

 

RFC 3264 has the following about = fmtp parameters, which indicate the Annex B (or =  Annex A) capability in = offer/answer:

 

   The interpretation of = fmtp parameters in an offer depends on = the

   parameters.  In many cases, those parameters = describe specific

   configurations of the = media format, and should therefore be processed

   as the media format value = itself would be.  This means that = the same

   fmtp parameters with the same values MUST be present in the answer = if

   the media format they = describe is present in the answer.  Other fmtp

   parameters are more like parameters, for which it is perfectly

   acceptable for each agent = to use different values.  In that = case, the

   answer MAY contain fmtp parameters, and those MAY have the = same

   values as those in the = offer, or they MAY be different.  = SDP

   extensions that define = new parameters SHOULD specify the proper

   interpretation in = offer/answer.

 

Ideally, RFC 4856 should have specified proper = interpretation when the Annex B (or Annex A) capability specified in the fmtp parameter doesn't match in the offer/answer.

 

What = would be the best way to fix this? By submitting a new draft clarifying the = recommended behavior (BCP) or by submitting an errata = against RFC 4856 and waiting for its next = revision?

 

thanks,

Muthu

 

 

------_=_NextPart_001_01CC148F.B3BE784E-- From wwwrun@rfc-editor.org Tue May 17 10:57:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A64E0744; Tue, 17 May 2011 10:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.17 X-Spam-Level: X-Spam-Status: No, score=-102.17 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjASWxR-w8Cv; Tue, 17 May 2011 10:57:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 37209E0720; Tue, 17 May 2011 10:57:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 38F17E0742; Tue, 17 May 2011 10:57:25 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110517175725.38F17E0742@rfc-editor.org> Date: Tue, 17 May 2011 10:57:25 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6185 on RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 17:57:27 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6185 Title: RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video Author: T. Kristensen, P. Luthi Status: Standards Track Stream: IETF Date: May 2011 Mailbox: tom.kristensen@tandberg.com, patrick.luthi@tandberg.com Pages: 22 Characters: 55562 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-h264-rcdo-08.txt URL: http://www.rfc-editor.org/rfc/rfc6185.txt This document describes an RTP payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RCDO RTP payload format is based on the H.264 RTP payload format. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From magnus.westerlund@ericsson.com Thu May 19 00:30:36 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32386E0785 for ; Thu, 19 May 2011 00:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcnCcmjhjmND for ; Thu, 19 May 2011 00:30:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5EE077B for ; Thu, 19 May 2011 00:30:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-96-4dd4c71817cf Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.CC.20773.817C4DD4; Thu, 19 May 2011 09:30:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 19 May 2011 09:30:32 +0200 Message-ID: <4DD4C718.3020501@ericsson.com> Date: Thu, 19 May 2011 09:30:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF AVTCore WG , Peter Saint-Andre , Qiaobing.Xie@gmail.com X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 07:30:36 -0000 WG, Peter Saint-Andre has one part of his discuss which I believe we need WG input on. > 1) It is not clear to me why this document is registering 2 new MIME types, > instead of just registering a new optional parameter "forwardshift" for the > already registered audio/red MIME type. Handling of these 2 new MIME types > without the "forwardshift" parameter seems to be identical to the handling of > audio/red. I have discussed this discuss with Peter and clarified that there is one actual difference between the two approaches. Where using new mime types results in that one handles this as two independent media formats. Thus requiring two different payload types and negotiating them independently. And these two payload types is in fact resulting to a doubling of the number of payload types required in relation to the combination of primary secondary. This as each payload type only can carry one specific combination of redundancy. Using a optional parameter in the existing types has the result that one uses only one payload type and in a negotiation context, like SDP offer/answer one will use forward redundancy if both peers acknowledge the optional parameter, and if the other doesn't understand one gets automatic downgrade to RFC 2198 behavior. If this is the desired behavior my small concern is how well the implementations handle new optional parameters. They should but I have no knowledge how well people implements that handling. So the question to the WG is what behavior is really desired here? Please provide any feedback before the 2nd of June. Cheers 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 csp@csperkins.org Thu May 19 00:46:03 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD340E0681 for ; Thu, 19 May 2011 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPdMUWpTiGWS for ; Thu, 19 May 2011 00:46:02 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (unknown [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id AD950E067C for ; Thu, 19 May 2011 00:46:02 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.21]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QMxvl-0000nN-bn; Thu, 19 May 2011 07:46:01 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DD4C718.3020501@ericsson.com> Date: Thu, 19 May 2011 08:45:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DD4C718.3020501@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 07:46:03 -0000 On 19 May 2011, at 08:30, Magnus Westerlund wrote: > WG, >=20 > Peter Saint-Andre has one part of his discuss which I believe we need = WG input on. >=20 >> 1) It is not clear to me why this document is registering 2 new MIME = types, instead of just registering a new optional parameter = "forwardshift" for the already registered audio/red MIME type. Handling = of these 2 new MIME types without the "forwardshift" parameter seems to = be identical to the handling of audio/red. >=20 > I have discussed this discuss with Peter and clarified that there is = one actual difference between the two approaches. >=20 > Where using new mime types results in that one handles this as two = independent media formats. Thus requiring two different payload types = and negotiating them independently. And these two payload types is in = fact resulting to a doubling of the number of payload types required in = relation to the combination of primary secondary. This as each payload = type only can carry one specific combination of redundancy. >=20 > Using a optional parameter in the existing types has the result that = one uses only one payload type and in a negotiation context, like SDP = offer/answer one will use forward redundancy if both peers acknowledge = the optional parameter, and if the other doesn't understand one gets = automatic downgrade to RFC 2198 behavior. If this is the desired = behavior my small concern is how well the implementations handle new = optional parameters. They should but I have no knowledge how well people = implements that handling. >=20 > So the question to the WG is what behavior is really desired here? The problem with using an optional parameter is that the extension = changes the semantics and is not backwards compatible. This would break = older implementations that ignore the new parameter. A new payload type = will not be understood by old implementations, but at least it won't be = misinterpreted. Because of this, I think we want new media types. --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Thu May 19 01:13:23 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC5EE0713 for ; Thu, 19 May 2011 01:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.471 X-Spam-Level: X-Spam-Status: No, score=-106.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xImGoYqx0gzC for ; Thu, 19 May 2011 01:13:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 35853E0711 for ; Thu, 19 May 2011 01:13:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-44-4dd4d11f5091 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.B5.20773.F11D4DD4; Thu, 19 May 2011 10:13:19 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 19 May 2011 10:13:18 +0200 Message-ID: <4DD4D11E.30505@ericsson.com> Date: Thu, 19 May 2011 10:13:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Colin Perkins References: <4DD4C718.3020501@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 08:13:23 -0000 On 2011-05-19 09:45, Colin Perkins wrote: > On 19 May 2011, at 08:30, Magnus Westerlund wrote: > >> WG, >> >> Peter Saint-Andre has one part of his discuss which I believe we >> need WG input on. >> >>> 1) It is not clear to me why this document is registering 2 new >>> MIME types, instead of just registering a new optional parameter >>> "forwardshift" for the already registered audio/red MIME type. >>> Handling of these 2 new MIME types without the "forwardshift" >>> parameter seems to be identical to the handling of audio/red. >> >> I have discussed this discuss with Peter and clarified that there >> is one actual difference between the two approaches. >> >> Where using new mime types results in that one handles this as two >> independent media formats. Thus requiring two different payload >> types and negotiating them independently. And these two payload >> types is in fact resulting to a doubling of the number of payload >> types required in relation to the combination of primary secondary. >> This as each payload type only can carry one specific combination >> of redundancy. >> >> Using a optional parameter in the existing types has the result >> that one uses only one payload type and in a negotiation context, >> like SDP offer/answer one will use forward redundancy if both peers >> acknowledge the optional parameter, and if the other doesn't >> understand one gets automatic downgrade to RFC 2198 behavior. If >> this is the desired behavior my small concern is how well the >> implementations handle new optional parameters. They should but I >> have no knowledge how well people implements that handling. >> >> So the question to the WG is what behavior is really desired here? > > > The problem with using an optional parameter is that the extension > changes the semantics and is not backwards compatible. This would > break older implementations that ignore the new parameter. A new > payload type will not be understood by old implementations, but at > least it won't be misinterpreted. Because of this, I think we want > new media types. > I agree this is an issue for declarative usages when an end-point using a declarative SDP will think it understands the media format but it doesn't. But in negotiated usages this issue would not be present as the introducing part can only use the new semantics if the peer confirmed support. Cheers 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 qiaobing.xie@gmail.com Thu May 19 12:50:04 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AA8E0742 for ; Thu, 19 May 2011 12:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfVMUsQehNcp for ; Thu, 19 May 2011 12:50:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41C88E082C for ; Thu, 19 May 2011 12:50:03 -0700 (PDT) Received: by iyn15 with SMTP id 15so3020920iyn.31 for ; Thu, 19 May 2011 12:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZiEwcvjSZWnEZbWEYa7awKmvlYRSsHkCyoZlrVuYTmc=; b=J1NfdbxHBAkHMu/oLDPlAgp0HDhD6UFSit8Ifbmg21MnB6n7O1UCbIqgPl8QtETvS+ uKkIFeIEbLGxIK3ylX4JuowjwJl8TC4o6VVDDciZtTtvSKPYE43lO/QCqeoo0MTZcgcS wNmW3BJV+Z3Ihoasb4Zs7e6AjBobOoUFAmOpU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wjB6832EitukCUW5WoErTzf6hPbAQHI214vOqSZVeuUnQy1XUEw+mJ2xSrPgzaqs9I 2RWV1Nx746FzHGM6BX0b7NxNSLRNKxMrHlqFIPe/UaFYWonZHWRZjBDpQtWvMugKWrmA wct82TDmsgTL32RT6VikLbE3S4g2MxY5iLAlQ= Received: by 10.231.68.202 with SMTP id w10mr2657611ibi.63.1305834602635; Thu, 19 May 2011 12:50:02 -0700 (PDT) Received: from Qiaobing-Xies-Mac-Pro.local (24-171-17-53.dhcp.stls.mo.charter.com [24.171.17.53]) by mx.google.com with ESMTPS id c1sm1202968ibe.51.2011.05.19.12.50.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 12:50:01 -0700 (PDT) Message-ID: <4DD57467.4020701@gmail.com> Date: Thu, 19 May 2011 14:49:59 -0500 From: Qiaobing Xie User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Magnus Westerlund References: <4DD4C718.3020501@ericsson.com> In-Reply-To: <4DD4C718.3020501@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Discuss on draft-ietf-avt-forward-shifted-red-06 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 19:50:04 -0000 Magnus, I will be fine with either approach. From an implementation and documentation maintenance point of view, the "new optional parameter" approach is simpler. As for your concern "how well the implementations handle new optional parameters", I think the question actually applies to *any* new optional parameter introduced here. We must have tons of experiences for that from the field already. I would be shocked if this would be the first time a new optional parameter is introduced. -Q On 5/19/11 2:30 AM, Magnus Westerlund wrote: > WG, > > Peter Saint-Andre has one part of his discuss which I believe we need WG > input on. > >> 1) It is not clear to me why this document is registering 2 new MIME types, >> instead of just registering a new optional parameter "forwardshift" for the >> already registered audio/red MIME type. Handling of these 2 new MIME types >> without the "forwardshift" parameter seems to be identical to the handling of >> audio/red. > I have discussed this discuss with Peter and clarified that there is one > actual difference between the two approaches. > > Where using new mime types results in that one handles this as two > independent media formats. Thus requiring two different payload types > and negotiating them independently. And these two payload types is in > fact resulting to a doubling of the number of payload types required in > relation to the combination of primary secondary. This as each payload > type only can carry one specific combination of redundancy. > > Using a optional parameter in the existing types has the result that one > uses only one payload type and in a negotiation context, like SDP > offer/answer one will use forward redundancy if both peers acknowledge > the optional parameter, and if the other doesn't understand one gets > automatic downgrade to RFC 2198 behavior. If this is the desired > behavior my small concern is how well the implementations handle new > optional parameters. They should but I have no knowledge how well people > implements that handling. > > So the question to the WG is what behavior is really desired here? > > Please provide any feedback before the 2nd of June. > > Cheers > > 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 swc@iis.sinica.edu.tw Fri May 20 00:06:55 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A2FE06D7 for ; Fri, 20 May 2011 00:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqBhYxOQbnQH for ; Fri, 20 May 2011 00:06:50 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.10.76]) by ietfa.amsl.com (Postfix) with ESMTP id 39895E0686 for ; Fri, 20 May 2011 00:06:49 -0700 (PDT) Received: from DHCP-22023.iis.sinica.edu.tw (EHLO ErinPC) ([140.109.22.23]) by gate.sinica.edu.tw (MOS 4.1.10-GA FastPath queued) with ESMTP id AFC40139; Fri, 20 May 2011 15:06:45 +0800 (CST) From: "Sheng-Wei \(Kuan-Ta\) Chen" To: Date: Fri, 20 May 2011 15:06:34 +0800 Message-ID: <000f01cc16bc$74b455e0$5e1d01a0$@sinica.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcwWvHMd4bzHEWd5TiSSxOv3SmdvwA== Content-Language: zh-tw x-cr-hashedpuzzle: AC/t AI25 AzFI A2x5 A8Je B9+h Ed2t FhZ6 HOo2 ID0a IX3P I9Hu JG+u KS+s LM4M Lsz8; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {003633DB-546D-4C69-BE9A-AFCCC2920A14}; cwB3AGMAQABpAGkAcwAuAHMAaQBuAGkAYwBhAC4AZQBkAHUALgB0AHcA; Fri, 20 May 2011 07:06:32 GMT; TgBPAFMAUwBEAEEAVgAgADIAMAAxADEAIABDAGEAbABsACAAZgBvAHIAIABQAGEAcgB0AGkAYwBpAHAAYQB0AGkAbwBuAA== x-cr-puzzleid: {003633DB-546D-4C69-BE9A-AFCCC2920A14} Subject: [AVTCORE] NOSSDAV 2011 Call for Participation X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2011 07:06:55 -0000 [Apologies if you receive this more than once] ++++++++++++++++++++ [ NOSSDAV 2011 Call for Participation ] = ++++++++++++++++++++++ The 21th International Workshop on Network and Operating Systems Support for Digital Audio and Video =20 June 2 -- 3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ * Conference will start in two weeks! * We invite you to attend NOSSDAV 2011, the 21st anniversary of SIGMM's = leading=20 workshop on network and operating systems support for digital audio and video. The workshop, hosted at the University of British Columbia (UBC), = will continue to focus on emerging research topics, controversial ideas, and = future research directions in the area of multimedia systems research. As in previous years, we will maintain the focused single-track format a = setting that stimulates lively discussions among the senior and junior = participants. ** Technical Program:=20 http://nss.cs.ubc.ca/nossdav2011/program.html ** Registration: http://nss.cs.ubc.ca/nossdav2011/registration.html If you have any questions, please get in touch with the co-chairs: Charles "Buck" Krasic (Google Inc., USA) Kang Li (University of Georgia, USA) (kangli@cs.uga.edu) NOSSDAV 2011 PROGRAM AT A GLANCE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D ** June 1, 2011 ** 1700 - 1900 Reception at Computer Science lounge ** June 2, 2011 ** Keynote Speech Jim Bankoski (Google Inc.) - Topic: WebM/VP8 Session 1: Streaming - LAN-Awareness: Improved P2P Live Streaming=20 - In-Network Adaptation of H.264/SVC for HD Video Streaming over = 802.11g Networks - Media-aware Networking for SVC-based P2P Streaming Session 2: Wireless & Mobile Media Delivery - Mobile Video Streaming Using Location-Based Network Prediction and = Transparent Handover=20 - The Impact of Inter-layer Network Coding on the Relative Performance = of MRC/MDC WiFi Media Delivery - A Measurement Study of Resource Utilization in Internet Mobile = Streaming Session 3: Social Media - Understanding Demand Volatility in Large VoD Systems - Sharing Social Content from Home: A Measurement-driven Feasibility = Study - Load-Balanced Migration of Social Media to Content Clouds Banquet ** June 3, 2011 ** Session 4: Networking - Improving HTTP performance using "Stateless" TCP - A DTN Mode for Reliable Internet Telephony - Inferring the time-zones of Prefixes and Autonomous Systems by = monitoring game server discovery traffic Session 5: Systems=20 - GPU-based Fast Motion Estimation for On-the-Fly Encoding of = Computer-Generated Video Streams - SAS Kernel: Streaming as a Service Kernel for Correlated = Multi-Streaming - Managing Home and Network Storage of Television Recordings."I filled = my DVR again! Now what?" Session 6: Media Adaptation - Moving Beyond the Framebuffer - Systems Support for Stereoscopic Video Compression - Accurate and Low-Delay Seeking Within and Across Mash-Ups of = Highly-Compressed Videos Session 7: Foundation of Media Communication - Scalable Video Transmission: Packet Loss Induced Distortion Modeling = and Estimation - Energy-efficient video streaming from high-speed trains - Celerity: Towards Low-Delay Multi-Party Conferencing Concluding Remarks From csp@csperkins.org Mon May 23 04:21:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4187E0785; Mon, 23 May 2011 04:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.927 X-Spam-Level: X-Spam-Status: No, score=-101.927 tagged_above=-999 required=5 tests=[AWL=-1.365, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBVBEHuoL17r; Mon, 23 May 2011 04:21:33 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2A927E077D; Mon, 23 May 2011 04:21:33 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QOTAi-00040z-ja; Mon, 23 May 2011 11:19:40 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-436--722627241 From: Colin Perkins X-Priority: 3 In-Reply-To: <009b01cc1447$03fd30a0$46298a0a@china.huawei.com> Date: Mon, 23 May 2011 12:19:30 +0100 Message-Id: <10148F06-1E0C-4189-8238-8E025A92CDC2@csperkins.org> References: <05e001cc0e20$5525ba60$46298a0a@china.huawei.com> <02c801cc0eb9$29031bf0$46298a0a@china.huawei.com> <1347F83C-BBEB-4503-9EE1-1EABF7090851@csperkins.org> <009b01cc1447$03fd30a0$46298a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 23 May 2011 08:40:15 -0700 Cc: xrblock@ietf.org Subject: Re: [AVTCORE] [xrblock] Open issue- identity info repetition indraft-ietf-avtcore-monarch X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:21:34 -0000 --Apple-Mail-436--722627241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Qin, [bcc to avt, so replies go to the xrblock list only] The identity information in draft-ietf-avt-rtcp-xr-meas-identity-02 is = derived from that in draft-clark-avt-rtcphr-02, true. Both blocks = contain too much non-identity information for my taste, however. None of = this negates my comment on Section 5.2 of draft-ietf-avtcore-monarch-01, = which I think still focusses on the wrong things. I'd be interested to hear other opinions though. Colin On 17 May 2011, at 05:00, Qin Wu wrote: > Hi, Colin: > It looks like to me we go back to the history and re-pickup the story = of identity block again although I haven't gotten invloved into the = historical discussion. > However I do check with section 4.3 of draft-clark-avt-rtcphr-02 and = compare it with measurement identity block specified in = draft-ietf-avt-rtcp > -xr-meas-identity. > I think identity block has already considered the way on how to = correlate RTP-layer identity information with other identity data. If = you look at the format > of identity block, you will see identity block defines the = sub-identifier field to carry an additional identifier which can be = useful in the context of a specific application, e.g., > IMS Charging Identity,SIP Call-ID, all these additional identity can = be included in the identity block. Using this application specific = identity information, > you can easily correlate RTP-layer identity information with other = identity data. > I think the only problem with measurement identity block is which kind = of information should be included, which kind of information should not = be included. > Therefore it will be good to have a template for measurement identity = block or any other new RTCP XR block. > =20 > =20 > Regards! > -Qin > ----- Original Message ----- > From: Colin Perkins > To: Qin Wu > Cc: AVT WG ; xrblock@ietf.org > Sent: Monday, May 16, 2011 6:37 PM > Subject: Re: [xrblock] [AVTCORE] Open issue- identity info repetition = indraft-ietf-avtcore-monarch >=20 > Qin, >=20 > To my mind, the most important part of the identity block was the = correlation tag used to relate RTCP statistics to non-RTCP measurements = (draft-clark-avt-rtcphr-02 had something along these lines, although = more structured than needed). The tools to save space in RTCP XR packets = by removing duplicate identity information when stacking reports are = less compelling. Given this, I don't see much value in Section 5.2 of = draft-ietf-avtcore-monarch as currently written, and would prefer to see = the draft focus on ways to correlate RTP-layer identify information with = other identify data. >=20 > I'd be interested to hear other opinions though. >=20 > Colin >=20 >=20 >=20 >=20 >=20 > On 10 May 2011, at 03:22, Qin Wu wrote: >> Just make correction. My colleague reminds me that the example figure = 2 does not conflict with report block format defined in = draft-ietf-avt-rtcp-xr-meas-identity-02. >> Since the detailed measurement identity information following the = field SSRC of stream source in the figure 2 is omitted. >> However as I mentioned, it is not clear how much information is = included in identity block until identity block is clearly defined in = XRBlock WG. >> That is why I propose to remove figure 2 and related text from this = document. >> =20 >> Regards! >> -Qin >> ----- Original Message ----- >> From: Qin Wu >> To: avt@ietf.org ; xrblock@ietf.org >> Cc: magnus.westerlund@ericsson.com >> Sent: Monday, May 09, 2011 4:08 PM >> Subject: [AVTCORE] Open issue- identity info repetition = indraft-ietf-avtcore-monarch >>=20 >> In the last IETF meeting, there was discussion on identity info = repetition or dupplication. However it >> was not clear whether new packet type for identity block is needed. = Here is some clarification and >> prososal from my point of view. >> =20 >> In the example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, = it is assumed there is an RTCP >> XR packet containing four metrics blocks, reporting on streams from = two source. >> each source is associated with two meric block. >> =20 >> In order to reduce overhead to carry duplicated data for all the = metric block contained in >> the same RTCP XR packet, it was proposed by = draft-ietf-avtcore-monarch that measurement >> identity information should be separated from metric block and form = independent block. >> =20 >> However this proposal save zero octets in figure 2. So the question = is >> whether an identity block is actually needed if identity information >> only contain SSRC of stream souce, or if just stacking >> multiple XR Blocks is acceptable. >> =20 >> However I re-check with RTCP XR Report Block for Measurement Identity = defined in >> draft-ietf-avt-rtcp-xr-meas-identity-02, identity information = included is more than >> SSRC of stream source. So it should be useful to define new packet = type for identity block. >> =20 >> However the example figure 2(i.e., only contain SSRC of stream souce) = is actually not consistent with report block format defined in >> draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than SSRC = of stream source). >> =20 >> Also as we know, identity block work has just started from XRBlock = WG, >> Therefore I suggest that the example (Figure 2, and the related = discussion) is removed until the identity block is clearly >> defined in XRBLock. >> =20 >> Any Comments or suggestion? >> =20 >> Regards! >> -Qin >> =20 >>=20 >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> _______________________________________________ >> xrblock mailing list >> xrblock@ietf.org >> https://www.ietf.org/mailman/listinfo/xrblock >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-436--722627241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi, = Colin:
It looks like to me we go back to the history and = re-pickup the story of identity block again although I haven't gotten = invloved into the historical discussion.
However I do check = with section 4.3 of draft-clark-avt-rtcphr-02 and compare it with = measurement identity block specified in = draft-ietf-avt-rtcp
-xr-meas-identity.
I think = identity block has already considered the way on how to correlate = RTP-layer identity information with other identity data. If you look at = the format
of identity block, you will see identity block = defines the sub-identifier field to carry an additional identifier = which can be useful in the context of a specific = application, e.g.,
IMS Charging Identity,SIP Call-ID, all = these additional identity can be included in the identity block. Using = this application specific identity information,
you can easily = correlate RTP-layer identity information with other identity = data.
I think the only problem with measurement identity block = is which kind of information should be included, which kind of = information should not be included.
Therefore it will be good = to have a template for measurement identity block or any other new RTCP = XR block.
 
 
Regar= ds!
-Qin
----- Original Message -----
Sent: Monday, = May 16, 2011 6:37 PM
Subject: Re: [xrblock] [AVTCORE] = Open issue- identity info repetition = indraft-ietf-avtcore-monarch

Qin,

T= o my mind, the most important part of the identity block was the = correlation tag used to relate RTCP statistics to non-RTCP measurements = (draft-clark-avt-rtcphr-02 had something along these lines, although = more structured than needed). The tools to save space in RTCP XR packets = by removing duplicate identity information when stacking reports are = less compelling. Given this, I don't see much value in Section 5.2 of = draft-ietf-avtcore-monarch as currently written, and would prefer to see = the draft focus on ways to correlate RTP-layer identify information with = other identify data.

I'd be interested to hear = other opinions = though.

Colin


=



On 10 May 2011, at = 03:22, Qin Wu wrote:
Just make = correction. My colleague reminds me that the example figure 2  does = not conflict with report block format defined in = draft-ietf-avt-rtcp-xr-meas-identity-02.
Since the detailed measurement identity = information following the field SSRC of stream source in the = figure 2 is omitted.
However as I mentioned, it is not clear how much information is = included in identity block until identity block is clearly defined in = XRBlock WG.
That is why = I propose to remove figure 2 and related text from this = document.
 
Regards!
-Qin
----- Original Message = -----
Sent: Monday, May 09, 2011 4:08 = PM
Subject: [AVTCORE] Open issue- = identity info repetition = indraft-ietf-avtcore-monarch

In the last IETF meeting, there was discussion on identity = info repetition or dupplication. However it
 was not clear whether new packet type for = identity block is needed. Here is some clarification = and
prososal from my = point of view.
 
In the = example figure 2 of section 5.2 in drat-ietf-avtcore-monarch, it = is assumed there is an RTCP
 XR packet containing four metrics = blocks, reporting on streams from two = source.
each source is = associated with two meric block.
 
In = order to reduce overhead to carry duplicated data for all the = metric block contained in
the same RTCP XR packet, it was proposed by = draft-ietf-avtcore-monarch that measurement
identity information should be separated from = metric block and form independent block.
 
However this proposal save zero octets in figure 2. So the = question  is
whether an identity block is actually needed if identity = information
only contain = SSRC of stream souce, or if just stacking
multiple XR Blocks = is acceptable.
 
However I = re-check with RTCP XR Report Block for Measurement Identity defined = in
draft-ietf-avt-rtcp-xr-meas-identity-02, identity information = included is more than
SSRC of stream source. So it should be useful to define new = packet type for identity block.
 
However the example figure 2(i.e., only contain SSRC of = stream souce) is actually not consistent with report block format = defined in
draft-ietf-avt-rtcp-xr-meas-identity-02(i.e., contain more than = SSRC of stream source).
 
Also as we = know, identity block work has just started from XRBlock = WG,
Therefore  I = suggest that the example (Figure 2, and the related discussion) is removed until = the identity block is clearly
defined in XRBLock.
 
Any = Comments or suggestion?
 
Regards!
-Qin
 


_________________________________= ______________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/ma= ilman/listinfo/avt
___________________________________= ____________
xrblock mailing list
xrblock@ietf.org
https://www.ietf.or= g/mailman/listinfo/xrblock

-- 

__= _____________________________________________
Audio/Video Transport = Core Maintenance
avt@ietf.org
https://www.ietf.org/ma= ilman/listinfo/avt



-- 
Colin Perkins



= --Apple-Mail-436--722627241-- From sunseawq@huawei.com Mon May 23 23:05:12 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A867E069A for ; Mon, 23 May 2011 23:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.921 X-Spam-Level: X-Spam-Status: No, score=-4.921 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbHMBdpMzw42 for ; Mon, 23 May 2011 23:05:10 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DD951E0688 for ; Mon, 23 May 2011 23:05:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00F74RECCS@szxga04-in.huawei.com> for avt@ietf.org; Tue, 24 May 2011 14:01:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO008OBRECH9@szxga04-in.huawei.com> for avt@ietf.org; Tue, 24 May 2011 14:01:24 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLO0042BREBIQ@szxml06-in.huawei.com> for avt@ietf.org; Tue, 24 May 2011 14:01:24 +0800 (CST) Date: Tue, 24 May 2011 14:05:29 +0800 From: Qin Wu To: Colin Perkins Message-id: <026e01cc19d8$95a8cdc0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_h6aFQp1PUUqdHDG0S8KHQg)" X-Priority: 3 X-MSMail-priority: Normal References: <20110506093933.23798.54229.idtracker@ietfa.amsl.com> <003001cc0bd3$66244600$46298a0a@china.huawei.com> <7C2CC5D8-ECB0-4D26-806D-990C2C56537B@csperkins.org> <014f01cc1058$989a3070$46298a0a@china.huawei.com> Cc: magnus.westerlund@ericsson.com, avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:05:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_h6aFQp1PUUqdHDG0S8KHQg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 SGksIENvbGluOg0KUGxlYXNlIGNoZWNrIGlmIHRoZSBmb2xsb3dpbmcgY2hhbmdlcyBhZGRyZXNz IHlvdXIgY29tbWVudHMuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tIA0KICBGcm9tOiBDb2xpbiBQZXJraW5zIA0KICBUbzogUWluIFd1IA0KICBDYzogbWFn bnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIDsgYXZ0QGlldGYub3JnIA0KICBTZW50OiBNb25k YXksIE1heSAxNiwgMjAxMSA3OjE0IFBNDQogIFN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4dA0K DQoNCiAgUWluLA0KDQoNCiAgW0kgaGF2ZSBmaXhlZCB0aGUgcXVvdGluZyB0byBtZSBjbGVhciB3 aG8gd3JvdGUgd2hhdF0NCg0KDQogIE9uIDEyIE1heSAyMDExLCBhdCAwNDo1NiwgUWluIFd1IHdy b3RlOg0KICAgIE9uIDExIE1heSAyMDExLCBhdCAxNzowNCwgQ29saW4gUGVya2lucyB3cm90ZToN Cg0KICAgICAgLSBTZWN0aW9uIDMsIDJuZCBwYXJhZ3JhcGg6IHRoaXMgZG9lc26SdCBjbGVhcmx5 IGRpZmZlcmVudGlhdGUgd2hlbiBhIHRoaXJkLXBhcnR5IGxvc3MgcmVwb3J0IHNob3VsZCBiZSB1 c2VkIGNvbXBhcmVkIHRvIGEgTkFDSy4gSW4gcGFydGljdWxhciwgdGhlIHNlbnRlbmNlIJNVcG9u IGRvd25zdHJlYW0gbG9zcyBpcyByZXBvcnRlZCB0byB0aGUgaW50ZXJtZWRpYXJ5LCB0aGUgaW50 ZXJtZWRpYXJ5IFNIT1VMRCBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3NzIHJlcG9ydCB0byB0aGUg b3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMgd2hpY2ggYXJlIG5vdCBhd2FyZSBvZiB0aGUgbG9z cyByZXBvcnRzLCB0byBpbmZvcm0gdGhvc2UgcmVjZWl2ZXJzIG9mIHRoZSBsb3NzIGFuZCBzdXBw cmVzcyB0aGVpciBmZWVkYmFja5QgbmVlZHMgdG8gYmUgZXhwYW5kZWQgdG8gZGlzY3VzcyB3aGF0 IJNhcmUgbm90IGF3YXJlIG9mIHRoZSBsb3NzIHJlcG9ydHOUIG1lYW5zIGluIHRoaXMgY29udGV4 dCAoaS5lLiwgd2hlbiBpdCdzIG5vdCBwb3NzaWJsZSB0byBkaXN0cmlidXRlIHRoZSBOQUNLcyB0 byBhbGwgcmVjZWl2ZXJzKS4NCg0KICAgIFtRaW5dOiBZZXMsIHlvdSBhcmUgY29ycmVjdC4gSG93 IGFib3V0IHRoZSBmb2xsb3dpbmcgcHJvcG9zYWw6DQogICAgIg0KICAgIEhvd2V2ZXIsIGluIHNv bWUgY2FzZXMgd2hlcmUgcGFja2V0IGxvc3Mgb2NjdXJzIGluIHRoZSBkb3duc3RyZWFtIG9mIHRo ZXNlIGludGVybWVkaWF0ZXMsDQogICAgaXQgaXMgbm90IHBvc3NpYmxlIGZvciB0aGUgaW50ZXJt ZWRpYXRlcyB0byBkaXN0cmlidXRlIHRoZSBOQUNLcyB0byBhbGwgcmVjZWl2ZXJzLiBJbiBzdWNo IGNhc2VzLCBkb3duc3RyZWFtIGxvc3MgbmVlZHMNCiAgICAgdG8gYmUgZmlyc3RseSByZXBvcnRl ZCB0byB0aGUgaW50ZXJtZWRpYXJ5IGluIHNvbWUgd2F5LiBVcG9uIGRvd25zdHJlYW0gbG9zcyBp cyByZXBvcnRlZCB0byB0aGUNCiAgICAgaW50ZXJtZWRpYXJ5LCB0aGUgaW50ZXJtZWRpYXJ5IFNI T1VMRCBzZW5kIHRoZSBUaGlyZCBQYXJ0eSBMb3NzIHJlcG9ydCB0byB0aGUgb3RoZXIgZG93bnN0 cmVhbSByZWNlaXZlcnMuDQogICAgIg0KDQoNCiAgSSBkb24ndCB0aGluayB0aGlzLCBub3IgdGhl IHRleHQgaW4gZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb25zLXJ0cC0wMyBp cyBjb3JyZWN0LiBTZWN0aW9uIDMsIDJuZCBwYXJhZ3JhcGggb2YgdGhlIC0wMyBkcmFmdCBzYXlz IJNIb3dldmVyLCBpbiBzb21lIGNhc2VzIHdoZXJlIHBhY2tldCBsb3NzIG9jY3VycyBpbiB0aGUg ZG93bnN0cmVhbSBvZiB0aGVzZSBpbnRlcm1lZGlhdGVzLCBpdCBpcyBub3QgcG9zc2libGUgZm9y IHRoZW0gdG8gZGlzdHJpYnV0ZSB0aGUgTkFDS3MgdG8gYWxsIHJlY2VpdmVycyBzaW5jZSB0aGV5 IGFyZSB1bmFibGUgdG8gb2JzZXJ2ZSBkb3duc3RyZWFtIGxvc3MuICBJbiBzdWNoIGNhc2VzLCBk b3duc3RyZWFtIGxvc3MgbmVlZHMgdG8gYmUgZmlyc3RseSByZXBvcnRlZCB0byB0aGUgaW50ZXJt ZWRpYXJ5LiAgV2hlbiBkb3duc3RyZWFtIGxvc3MgaXMgcmVwb3J0ZWQgdG8gdGhlIGludGVybWVk aWFyeSwgdGhlIGludGVybWVkaWFyeSBTSE9VTEQgY3JlYXRlIGFuZCBzZW5kIHRoZSBUaGlyZCBQ YXJ0eSBMb3NzIHJlcG9ydCB0byB0aGUgb3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMgd2hpY2gg YXJlIG5vdCBhd2FyZSBvZiB0aGUgbG9zcyByZXBvcnRzLCB0byBpbmZvcm0gdGhvc2UgcmVjZWl2 ZXJzIG9mIHRoZSBsb3NzIGFuZCBzdXBwcmVzcyB0aGVpciBmZWVkYmFjay4gIFRoZXJlZm9yZSB0 aGUgaW50ZXJtZWRpYXRlIG5vZGUgY2FuIGJlIHJlYXNvbmFibHkgY2VydGFpbiB0aGF0IGl0IHdp bGwgaGVscCB0aGUgc2l0dWF0aW9uIGJ5IHNlbmRpbmcgYSBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9y dCBtZXNzYWdlIHRvIGFsbCB0aGUgcmVsZXZhbnQgcmVjZWl2ZXJzLJQuIFRoaXMgbWFrZXMgaXQg c291bmQgbGlrZSB0aGUgaW50ZXJtZWRpYXJ5IGFsd2F5cyB1c2VzIGEgdGhpcmQtcGFydHkgbG9z cyByZXBvcnQgdG8gdGVsbCBvdGhlciByZWNlaXZlcnMgYWJvdXQgZG93bnN0cmVhbSBsb3NzLiBU aGF0knMgbm90IHRoZSBjYXNlLiBJbiBtYW55IHNjZW5hcmlvcywgdGhlIGludGVybWVkaWFyeSBj YW4gcmVmbGVjdCBOQUNLcyBpdCByZWNlaXZlcyBmcm9tIG9uZSBkb3duc3RyZWFtIHJlY2VpdmVy IHRvIHRoZSBvdGhlciByZWNlaXZlcnMgd2l0aG91dCB1c2luZyBhIHRoaXJkIHBhcnR5IGxvc3Mg cmVwb3J0LiBUaGUgdGhpcmQtcGFydHkgbG9zcyByZXBvcnQgaXMgb25seSBuZWVkZWQgaW4gdGhv c2UgY2FzZXMgd2hlcmUgTkFDS3MgY2Fubm90IGJlIGRpc3RyaWJ1dGVkIHRvIGFsbCByZWNlaXZl cnMuDQoNCiAgW1Fpbl06IFlvdSBhcmUgcmlnaHQuIEFzIGZvciBkb3duc3RyZWFtIGxvc3MsIGlu IHNvbWUgY2FzZXMsIHRoZSBpbnRlcm1lZGlhcnkgbWF5IHNlbmQgTkFDSywgZS5nLiwgUlRDUC1T U00gaW4gU2ltcGxlIGZlZWRiYWNrIG1vZGVsLCBpbiBzb21lIGNhc2VzLCB0aGUgaW50ZXJtZWRp YXJ5IG11c3Qgc2VuZCB0aGUgdGhpcmQgcGFydHkgbG9zcyByZXBvcnQgaW5zdGVhZCBvZiBOQUNL LGUuZy4sIFJUQ1AtU1NNIGluIFN1bW1hcnkgRmVlZGJhY2sgTW9kZWwuIFRoZXJlZm9yZSBJIHBy b3Bvc2UgdGhlIGNoYW5nZXMgaW4gUGFyYWdyYXBoIDIsIHNlY3Rpb24gMyBvZiBkcmFmdC1pZXRm LWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAgYXMgZm9sbG93czoNCiAgT0xEIFRFWFQ6 DQogICINCiAgIFVwb24gb2JzZXJ2aW5nIChvciBzdXNwZWN0aW5nKSBhbiB1cHN0cmVhbSBsb3Nz LCB0aGUNCiAgICAgaW50ZXJtZWRpYXJ5IFNob3VsZCBzZW5kIE5BQ0sgYm90aCBkb3duc3RyZWFt IHRvd2FyZHMgdGhlIHJlY2VpdmVycw0KICAgICBhbmQgdXBzdHJlYW0gdG93YXJkcyB0aGUgbWVk aWEgc291cmNlLCB0byBpbmRpY2F0ZSB0aGF0IGl0IGhhcw0KICAgICBub3RpY2VkIHRoZSBsb3Nz LCBhbmQgdG8gc3VwcHJlc3MgZmVlZGJhY2sgZnJvbSBvdGhlciBkb3duc3RyZWFtDQogICAgIHJl Y2VpdmVycy4gIEhvd2V2ZXIsIGluIHNvbWUgY2FzZXMgd2hlcmUgcGFja2V0IGxvc3Mgb2NjdXJz IGluIHRoZQ0KICAgICBkb3duc3RyZWFtIG9mIHRoZXNlIGludGVybWVkaWF0ZXMsIGl0IGlzIG5v dCBwb3NzaWJsZSBmb3IgdGhlbSB0bw0KICAgICBkaXN0cmlidXRlIHRoZSBOQUNLcyB0byBhbGwg cmVjZWl2ZXJzIHNpbmNlIHRoZXkgYXJlIHVuYWJsZSB0bw0KICAgICBvYnNlcnZlIGRvd25zdHJl YW0gbG9zcy4gIEluIHN1Y2ggY2FzZXMsIGRvd25zdHJlYW0gbG9zcyBuZWVkcyB0byBiZQ0KICAg ICBmaXJzdGx5IHJlcG9ydGVkIHRvIHRoZSBpbnRlcm1lZGlhcnkuICBXaGVuIGRvd25zdHJlYW0g bG9zcyBpcw0KICAgICByZXBvcnRlZCB0byB0aGUgaW50ZXJtZWRpYXJ5LCB0aGUgaW50ZXJtZWRp YXJ5IFNIT1VMRCBjcmVhdGUgYW5kIHNlbmQNCiAgICAgdGhlIFRoaXJkIFBhcnR5IExvc3MgcmVw b3J0IHRvIHRoZSBvdGhlciBkb3duc3RyZWFtIHJlY2VpdmVycyB3aGljaA0KICAgICBhcmUgbm90 IGF3YXJlIG9mIHRoZSBsb3NzIHJlcG9ydHMsIHRvIGluZm9ybSB0aG9zZSByZWNlaXZlcnMgb2Yg dGhlDQogICAgIGxvc3MgYW5kIHN1cHByZXNzIHRoZWlyIGZlZWRiYWNrLiAgDQogICINCiAgTkVX IFRFWFQ6DQoNCiAgIg0KICAgICBJZiBhbiBpbnRlcm1lZGlhcnkgbm90aWNlcyB0aGUgbG9zcyBp dHNlbGYsIHRoZW4gaXQNCiAgICAgbWF5IHNlbmQgYSBOQUNLIGJvdGggZG93bnN0cmVhbSB0b3dh cmRzIHRoZSByZWNlaXZlcnMgYW5kIHVwc3RyZWFtDQogICAgIHRvd2FyZHMgdGhlIG1lZGlhIHNv dXJjZSwgdG8gaW5kaWNhdGUgdGhhdCBpdCBoYXMgbm90aWNlZCB0aGUgbG9zcywNCiAgICAgYW5k IHRvIHN1cHByZXNzIGZlZWRiYWNrIGZyb20gb3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMuICBJ ZiBhbg0KICAgICBpbnRlcm1lZGlhcnkgcmVjZWl2ZXMgYSBOQUNLIGZyb20gYW5vdGhlciBzeXN0 ZW0sIGl0IHNob3VsZA0KICAgICByZWRpc3RyaWJ1dGUgdGhhdCBOQUNLIHRvIGFsbCBvdGhlciBz eXN0ZW1zIHRoYXQgd291bGQgbm90IG90aGVyd2lzZQ0KICAgICByZWNlaXZlIGl0LiAgQW4gZXhh bXBsZSBvZiB0aGlzIGlzIFJUQ1AtU1NNIGluIHNpbXBsZSBmZWVkYmFjayBtb2RlbA0KICAgICBb UkZDNTc2MF0sIHdoZXJlIHRoZSBkaXN0cmlidXRpb24gc291cmNlIHJlZmxlY3RzIE5BQ0tzIHRv IG90aGVyDQogICAgIHN5c3RlbXMuICBJZiBhbiBpbnRlcm1lZGlhcnkgcmVjZWl2ZXMgYSBOQUNL IGZyb20gYW5vdGhlciBzeXN0ZW0sDQogICAgIGJ1dCwgZm9yIHNvbWUgcmVhc29uLCBjYW5ub3Qg cmVkaXN0cmlidXRlIHRoYXQgTkFDSywgdGhlbiBpdCBtYXkgc2VuZA0KICAgICBhIHRoaXJkLXBh cnR5IGxvc3MgcmVwb3J0IHRvIHRoZSBzeXN0ZW1zIHRoYXQgd2VyZSB1bmFibGUgdG8gcmVjZWl2 ZQ0KICAgICB0aGUgTkFDSywgYW5kIHdvbid0IHJlY2VpdmUgdGhlIE5BQ0sgdmlhIG90aGVyIG1l YW5zLiAgQW4gZXhhbXBsZQ0KICAgICB3b3VsZCBiZSBhIGRpc3RyaWJ1dGlvbiBzb3VyY2UgdXNp bmcgUlRDUC1TU00gaW4gRGlzdHJpYnV0aW9uIFNvdXJjZQ0KICAgICBGZWVkYmFjayBTdW1tYXJ5 IG1vZGVsIFtSRkM1NzYwXS4gDQogICINCg0KICAtIFNlY3Rpb24gMywgM3JkIHBhcmFncmFwaDog dGhpcyB3b3VsZCBiZSBtdWNoIGNsZWFyZXIgaWYgaXQgZGlzY3Vzc2VkIHdoZW4gaXSScyBhcHBy b3ByaWF0ZSB0byBtb25pdG9yIHRoZSBmZWVkYmFjayANCiAgYW5kIHNlbmQgYSB0aGlyZC1wYXJ0 eSBsb3NzIHJlcG9ydCB0byBkb3duc3RyZWFtIHJlY2VpdmVycywgcmF0aGVyIHRoYW4ganVzdCBy ZWZsZWN0IE5BQ0tzIGJhY2sgZG93bnN0cmVhbS4NCg0KICAgIFtRaW5dOiBPa2F5LiBJIHRoaW5r IHRoZSBhbnN3ZXIgdG8gd2hlbiBpcw0KICAgICINCiAgICBVcG9uIHJlY2VpdmluZyBkb3duc3Ry ZWFtIGxvc3MgcmVwb3J0IGluIHRoZSB3YXkgb2Ygc3VjaCBmZWVkYmFjayByZXBvcnQgb25seSBk ZXN0aW5lZCBmb3IgbWVkaWEgc291cmNlLCB0aGUgbWVkaWEgc291cmNlIFNIT1VMRCBzZW5kIHRo ZSBUaGlyZA0KICAgIFBhcnR5IExvc3MgUmVwb3J0IG1lc3NhZ2VzIHRvIHRoZSByZWNlaXZlcnMu DQogICAgIg0KDQoNCiAgSSBkb24ndCB0aGluayB0aGF0J3MgY29ycmVjdC4gSW4gbW9zdCBjYXNl cywgbG9zcyBmZWVkYmFjayBkZXN0aW5lZCB0byB0aGUgc2VuZGVyIHNob3VsZCBiZSByZWZsZWN0 ZWQgZG93bnN0cmVhbSB0byBzdXBwcmVzcyBmdXJ0aGVyIGZlZWRiYWNrLiAgDQogIFRoaXMgZHJh ZnQgbmVlZHMgdG8gZGlzY3VzcyB0aGUgc2NlbmFyaW9zLCBmb3IgZXhhbXBsZSBTU00gc2Vzc2lv bnMgdXNpbmcgRGlzdHJpYnV0aW9uIFNvdXJjZSBGZWVkYmFjayBTdW1tYXJ5IG1vZGUsIHdoZXJl IHRoaXMgaXMgbm90IHBvc3NpYmxlLiANCiAgSXQgaXMgdGhlc2Ugc2NlbmFyaW9zIHdoZXJlIHRo aXJkIHBhcnR5IGxvc3MgcmVwb3J0cyBhcmUgbmVlZGVkLg0KDQogIFtRaW5dOiBBZ3JlZSwgUHJv cG9zZWQgdGhlIGZvbGxvd2luZyBjaGFuZ2VzOg0KICBPTEQgVEVYVDoNCiAgIg0KICAgICBVcG9u IHJlY2VpdmluZw0KICAgICBkb3duc3RyZWFtIGxvc3MgcmVwb3J0IGluIHRoZSBmb3JtIG9mIHN1 Y2ggZmVlZGJhY2sgcmVwb3J0IHdoaWNoIGlzDQogICAgIG9ubHkgZGVzdGluZWQgZm9yIG1lZGlh IHNvdXJjZSwgdGhlIG1lZGlhIHNvdXJjZSBTSE9VTEQgY3JlYXRlIGFuZA0KICAgICBzZW5kIHRo ZSBUaGlyZCBQYXJ0eSBMb3NzIFJlcG9ydCBtZXNzYWdlcyB0byB0aGUgb3RoZXIgZG93bnN0cmVh bQ0KICAgICByZWNlaXZlcnMgd2hpY2ggYXJlIG5vdCBhd2FyZSBvZiB0aGUgbG9zcyByZXBvcnRz LCB0byBpbmZvcm0gdGhvc2UNCiAgICAgcmVjZWl2ZXJzIG9mIHRoZSBsb3NzIGFuZCBzdXBwcmVz cyB0aGVpciBmZWVkYmFjay4NCg0KICAiDQogIE5FVyBURVhUOg0KICAiDQogICAgIElmIHRoZSBt ZWRpYSBzb3VyY2UNCiAgICAgcmVjZWl2ZXMgYSBOQUNLIGZyb20gYW5vdGhlciBzeXN0ZW0sIGl0 IHNob3VsZCByZWRpc3RyaWJ1dGUgdGhhdCBOQUNLDQogICAgIHRvIGFsbCBvdGhlciBzeXN0ZW1z IHRoYXQgd291bGQgbm90IG90aGVyd2lzZSByZWNlaXZlIGl0LiAgQW4gZXhhbXBsZQ0KICAgICBv ZiB0aGlzIGlzIFJUQ1AtU1NNIGluIHNpbXBsZSBmZWVkYmFjayBtb2RlbCBbUkZDNTc2MF0sIHdo ZXJlIHRoZQ0KICAgICBkaXN0cmlidXRpb24gc291cmNlIHJlZmxlY3RzIE5BQ0tzIHRvIG90aGVy IHN5c3RlbXMuICBJZiBhbg0KICAgICBpbnRlcm1lZGlhcnkgcmVjZWl2ZXMgYSBOQUNLIGZyb20g YW5vdGhlciBzeXN0ZW0sIGJ1dCwgZm9yIHNvbWUNCiAgICAgcmVhc29uLCBjYW5ub3QgcmVkaXN0 cmlidXRlIHRoYXQgTkFDSywgdGhlbiBpdCBtYXkgc2VuZCBhIHRoaXJkLXBhcnR5DQogICAgIGxv c3MgcmVwb3J0IHRvIHRoZSBzeXN0ZW1zIHRoYXQgd2VyZSB1bmFibGUgdG8gcmVjZWl2ZSB0aGUg TkFDSywgYW5kDQogICAgIHdvbid0IHJlY2VpdmUgdGhlIE5BQ0sgdmlhIG90aGVyIG1lYW5zLiAg QW4gZXhhbXBsZSB3b3VsZCBiZSBhDQogICAgIGRpc3RyaWJ1dGlvbiBzb3VyY2UgdXNpbmcgUlRD UC1TU00gaW4gRGlzdHJpYnV0aW9uIFNvdXJjZSBGZWVkYmFjaw0KICAgICBTdW1tYXJ5IG1vZGVs IFtSRkM1NzYwXS4NCg0KICAiDQoNCiAgT24gNiBNYXkgMjAxMSwgYXQgMTA6NTMsIFFpbiBXdSB3 cm90ZToNCiAgPiBIaSwNCiAgPiBUaGUgbmV3IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1hdnRjb3Jl LWZlZWRiYWNrLXN1cHByZXNzaW9uLXJ0cCBpcyBhdmFpbGFibGUgYXQNCiAgPiBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3Vw cmVzc2lvbi1ydHAtMDIudHh0DQogID4gd2hpY2ggYWRkcmVzcyB0aGUgcmVjZW50IGNvbW1lbnRz IGZyb20gQ29saW4gb24gdGhlIGxpc3QuDQogID4gVGhlIG1haW4gY2hhbmdlIGlzIHRvIGNsYXJp ZnkgdGhlIHVzZSBvZiB0aGlyZCBwYXJ0eSBsb3NzIHJlcG9ydCBhbmQgdXBkYXRlIHRoZSB0aXRs ZSBhbmQgcmVsZXZhbnQgc2VjdGlvbnMgDQogID4gdG8gZm9jdXMgb24gdGhpcmQgcGFydHkgbG9z cyByZXBvcnQuDQogID4gVGhlIGRpZmYgaXMgYXQ6DQogID4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAt MDINCiAgPiBQbGVhc2UgY2hlY2sgaWYgeW91IGFyZSBjb21mb3J0YWJsZSB3aXRoIHRoZSBjaGFu Z2VzIGluIHRoaXMgdmVyc2lvbi4NCiAgPiBBbnkgY29tbWVudHM/DQogID4gDQogID4gUmVnYXJk cyENCiAgPiAtUWluDQogID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgPiBGcm9t OiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KICA+IFRvOiA8aS1kLWFubm91bmNlQGlldGYu b3JnPg0KICA+IENjOiA8YXZ0QGlldGYub3JnPg0KICA+IFNlbnQ6IEZyaWRheSwgTWF5IDA2LCAy MDExIDU6MzkgUE0NCiAgPiBTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUt ZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0DQogID4gDQogID4gDQogID4+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXVkaW8vVmlk ZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N CiAgPj4gDQogID4+IFRpdGxlICAgICAgICAgICA6IFJUQ1AgRXh0ZW5zaW9uIGZvciBUaGlyZC1w YXJ0eSBMb3NzIFJlcG9ydA0KICA+PiBBdXRob3IocykgICAgICAgOiBRaW4gV3UNCiAgPj4gICAg ICAgICAgICAgICAgICAgICAgICAgRnJhbmsgWGlhDQogID4+ICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbmkgRXZlbg0KICA+PiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNvcmUt ZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0DQogID4+IFBhZ2VzICAgICAgICAgICA6IDE4 DQogID4+IERhdGUgICAgICAgICAgICA6IDIwMTEtMDUtMDYNCiAgPj4gDQogID4+ICBJbiBhIGxh cmdlIFJUUCBzZXNzaW9uIHVzaW5nIHRoZSBSVENQIGZlZWRiYWNrIG1lY2hhbmlzbSBkZWZpbmVk IGluDQogID4+ICBSRkMgNDU4NSwgYSBtZWRpYSBzb3VyY2Ugb3IgbWlkZGxlYm94IG1heSBleHBl cmllbmNlIHRyYW5zaWVudA0KICA+PiAgb3ZlcmxvYWQgaWYgc29tZSBldmVudCBjYXVzZXMgYSBs YXJnZSBudW1iZXIgb2YgcmVjZWl2ZXJzIHRvIHNlbmQNCiAgPj4gIGZlZWRiYWNrIGF0IG9uY2Uu ICBUaGlzIGZlZWRiYWNrIGltcGxvc2lvbiBjYW4gYmUgbWl0aWdhdGVkIGlmIHRoZQ0KICA+PiAg ZGV2aWNlIHN1ZmZlcmluZyBmcm9tIG92ZXJsb2FkIGNhbiBzZW5kIGEgdGhpcmQgcGFydHkgbG9z cyByZXBvcnQNCiAgPj4gIG1lc3NhZ2UgdG8gdGhlIHJlY2VpdmVycyB0byBpbmhpYml0IGZ1cnRo ZXIgZmVlZGJhY2suICBUaGlzIG1lbW8NCiAgPj4gIGRlZmluZXMgUlRDUCBFeHRlbnNpb24gZm9y IHRoaXJkIHBhcnR5IGxvc3MgcmVwb3J0LCB0byBzdXBwcmVzcyBOQUNLDQogID4+ICBhbmQgRklS IGZlZWRiYWNrIHJlcXVlc3RzLiAgSXQgYWxzbyBkZWZpbmVzIGFzc29jaWF0ZWQgU0RQIHNpZ25h bGluZy4NCiAgPj4gDQogID4+IA0KICA+PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBp czoNCiAgPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1h dnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4dA0KICA+PiANCiAgPj4gSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICA+PiBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICA+PiANCiAgPj4gVGhpcyBJbnRl cm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Og0KICA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0 cC0wMi50eHQNCiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgPj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KICA+PiBJLUQtQW5ub3VuY2VA aWV0Zi5vcmcNCiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQt YW5ub3VuY2UNCiAgPj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWwNCiAgPj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRv dy1zaXRlcy50eHQNCiAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICA+IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQogID4g YXZ0QGlldGYub3JnDQogID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h dnQNCg0KDQoNCiAgLS0gDQogIENvbGluIFBlcmtpbnMNCiAgaHR0cDovL2NzcGVya2lucy5vcmcv DQoNCg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KICAgIGF2dEBp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoN Cg0KDQoNCg0KDQogIC0tIA0KICBDb2xpbiBQZXJraW5zDQogIGh0dHA6Ly9jc3BlcmtpbnMub3Jn Lw0KDQoNCg0KDQo= --Boundary_(ID_h6aFQp1PUUqdHDG0S8KHQg) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp bmRvd3MtMTI1MiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRP UiBjb250ZW50PSJNU0hUTUwgOC4wMC42MDAxLjE4OTk5Ij4NCjxTVFlMRT48L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgDQpzdHlsZT0iV09SRC1XUkFQOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UiIA0KYmdD b2xvcj0jY2NlOGNmPg0KPERJVj5IaSwgQ29saW46PC9ESVY+DQo8RElWPlBsZWFzZSBjaGVjayBp ZiB0aGUgZm9sbG93aW5nIGNoYW5nZXMgYWRkcmVzcyB5b3VyIGNvbW1lbnRzLjwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+UmVnYXJkcyE8L0RJVj4NCjxESVY+LVFpbjwvRElWPg0KPERJ Vj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHls ZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFE RElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIgDQpk aXI9bHRyPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgQkFDS0dS T1VORDogI2U0ZTRlNDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0 bGU9Y3NwQGNzcGVya2lucy5vcmcgaHJlZj0ibWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnIj5Db2xp biBQZXJraW5zPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1 OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogIGhy ZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+IDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1t YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20gDQogIGhyZWY9Im1haWx0bzptYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTwvQT4g DQogIDsgPEEgdGl0bGU9YXZ0QGlldGYub3JnIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2 dEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Qj5TZW50OjwvQj4gTW9uZGF5LCBNYXkgMTYsIDIwMTEgNzoxNCBQTTwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVjdDo8L0I+ IFJlOiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogDQogIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFj ay1zdXByZXNzaW9uLXJ0cC0wMi50eHQ8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+UWluLA0KICA8 RElWPjxCUj48L0RJVj4NCiAgPERJVj5bSSBoYXZlIGZpeGVkIHRoZSBxdW90aW5nIHRvIG1lIGNs ZWFyIHdobyB3cm90ZSB3aGF0XTwvRElWPg0KICA8RElWPjxCUj4NCiAgPERJVj4NCiAgPERJVj5P biAxMiBNYXkgMjAxMSwgYXQgMDQ6NTYsIFFpbiBXdSB3cm90ZTo8L0RJVj4NCiAgPEJMT0NLUVVP VEUgdHlwZT0iY2l0ZSI+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBtb25vc3BhY2UiIA0KICAg IGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+T24gMTEgTWF5IDIwMTEsIGF0IDE3OjA0LCBDb2xpbiBQ ZXJraW5zIA0KICAgIHdyb3RlOjwvU1BBTj48U1BBTiANCiAgICBzdHlsZT0iV0lET1dTOiAyOyBU RVhULVRSQU5TRk9STTogbm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBz ZXBhcmF0ZTsgRk9OVDogbWVkaXVtICdMdWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BB Q0U6IG5vcm1hbDsgT1JQSEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgV09SRC1TUEFD SU5HOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0 LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1p bi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4IiANCiAgICBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPjxCUj48 L0JMT0NLUVVPVEU+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgIDxESVY+DQogICAg PEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICA8RElWPi0gU2VjdGlvbiAzLCAybmQgcGFy YWdyYXBoOiB0aGlzIGRvZXNuknQgY2xlYXJseSBkaWZmZXJlbnRpYXRlIHdoZW4gYSANCiAgICAg IHRoaXJkLXBhcnR5IGxvc3MgcmVwb3J0IHNob3VsZCBiZSB1c2VkIGNvbXBhcmVkIHRvIGEgTkFD Sy4gSW4gcGFydGljdWxhciwgDQogICAgICB0aGUgc2VudGVuY2Ugk1Vwb24gZG93bnN0cmVhbSBs b3NzIGlzIHJlcG9ydGVkIHRvIHRoZSBpbnRlcm1lZGlhcnksIHRoZSANCiAgICAgIGludGVybWVk aWFyeSBTSE9VTEQgc2VuZCB0aGUgVGhpcmQgUGFydHkgTG9zcyByZXBvcnQgdG8gdGhlIG90aGVy IA0KICAgICAgZG93bnN0cmVhbSByZWNlaXZlcnMgd2hpY2ggYXJlIG5vdCBhd2FyZSBvZiB0aGUg bG9zcyByZXBvcnRzLCB0byBpbmZvcm0gDQogICAgICB0aG9zZSByZWNlaXZlcnMgb2YgdGhlIGxv c3MgYW5kIHN1cHByZXNzIHRoZWlyIGZlZWRiYWNrlCBuZWVkcyB0byBiZSANCiAgICAgIGV4cGFu ZGVkIHRvIGRpc2N1c3Mgd2hhdCCTYXJlIG5vdCBhd2FyZSBvZiB0aGUgbG9zcyByZXBvcnRzlCBt ZWFucyBpbiB0aGlzIA0KICAgICAgY29udGV4dCAoaS5lLiwgd2hlbiBpdCdzIG5vdCBwb3NzaWJs ZSB0byBkaXN0cmlidXRlIHRoZSBOQUNLcyB0byBhbGwgDQogICAgICByZWNlaXZlcnMpLjxCUj48 L0RJVj48L0JMT0NLUVVPVEU+DQogICAgPERJVj5bUWluXTogWWVzLCB5b3UgYXJlIGNvcnJlY3Qu Jm5ic3A7SG93IGFib3V0IHRoZSBmb2xsb3dpbmcgDQogICAgcHJvcG9zYWw6PC9ESVY+DQogICAg PERJVj4iPC9ESVY+DQogICAgPERJVj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nOyBGT05ULVNJWkU6IDEwLjVwdCIgDQogICAgbGFuZz1FTi1VUz48Rk9OVCBzaXpl PTM+SG93ZXZlciwgaW4gc29tZSBjYXNlcyB3aGVyZSBwYWNrZXQgbG9zcyBvY2N1cnMgaW4gDQog ICAgdGhlIGRvd25zdHJlYW0gb2YgdGhlc2UgaW50ZXJtZWRpYXRlcyw8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KICAgIDxESVY+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFu JzsgRk9OVC1TSVpFOiAxMC41cHQiIA0KICAgIGxhbmc9RU4tVVM+PEZPTlQgc2l6ZT0zPml0IGlz IG5vdCBwb3NzaWJsZSBmb3IgdGhlIGludGVybWVkaWF0ZXMgdG8gDQogICAgZGlzdHJpYnV0ZSB0 aGUgTkFDS3MgdG8gYWxsIHJlY2VpdmVycy4gSW4gc3VjaCBjYXNlcywgZG93bnN0cmVhbSBsb3Nz IA0KICAgIG5lZWRzPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICA8RElWPjxTUEFOIHN0eWxlPSJG T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IEZPTlQtU0laRTogMTAuNXB0IiANCiAgICBs YW5nPUVOLVVTPjxGT05UIHNpemU9Mz4mbmJzcDt0byBiZSBmaXJzdGx5IHJlcG9ydGVkIHRvIA0K ICAgIHRoZSZuYnNwO2ludGVybWVkaWFyeSBpbiBzb21lIHdheS4gVXBvbiBkb3duc3RyZWFtIGxv c3MgaXMgcmVwb3J0ZWQgdG8gDQogICAgdGhlPEJSPiZuYnNwO2ludGVybWVkaWFyeSwgdGhlIGlu dGVybWVkaWFyeSBTSE9VTEQgc2VuZCB0aGUgVGhpcmQgUGFydHkgDQogICAgTG9zcyZuYnNwO3Jl cG9ydCB0byB0aGUgb3RoZXIgZG93bnN0cmVhbSByZWNlaXZlcnMuPC9GT05UPjwvU1BBTj48L0RJ Vj4NCiAgICA8RElWPiI8L0RJVj48L0RJVj48L1NQQU4+PC9CTE9DS1FVT1RFPg0KICA8RElWPjxG T05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJ Vj5JIGRvbid0IHRoaW5rIHRoaXMsIG5vciB0aGUgdGV4dCBpbiANCiAgZHJhZnQtaWV0Zi1hdnRj b3JlLWZlZWRiYWNrLXN1cHJlc3Npb25zLXJ0cC0wMyBpcyBjb3JyZWN0LiZuYnNwO1NlY3Rpb24g MywgMm5kIA0KICBwYXJhZ3JhcGggb2YgdGhlIC0wMyBkcmFmdCBzYXlzIJNIb3dldmVyLCBpbiBz b21lIGNhc2VzIHdoZXJlIHBhY2tldCANCiAgbG9zcyZuYnNwO29jY3VycyBpbiB0aGUgZG93bnN0 cmVhbSBvZiB0aGVzZSBpbnRlcm1lZGlhdGVzLCBpdCBpcyBub3QgcG9zc2libGUgDQogIGZvciZu YnNwO3RoZW0gdG8gZGlzdHJpYnV0ZSB0aGUgTkFDS3MgdG8gYWxsIHJlY2VpdmVycyBzaW5jZSB0 aGV5IGFyZSB1bmFibGUgDQogIHRvJm5ic3A7b2JzZXJ2ZSBkb3duc3RyZWFtIGxvc3MuJm5ic3A7 Jm5ic3A7SW4gc3VjaCBjYXNlcywgZG93bnN0cmVhbSBsb3NzIA0KICBuZWVkcyB0byBiZSZuYnNw O2ZpcnN0bHkgcmVwb3J0ZWQgdG8gdGhlIGludGVybWVkaWFyeS4mbmJzcDsmbmJzcDtXaGVuIA0K ICBkb3duc3RyZWFtIGxvc3MgaXMgcmVwb3J0ZWQmbmJzcDt0byB0aGUgaW50ZXJtZWRpYXJ5LCB0 aGUgaW50ZXJtZWRpYXJ5IFNIT1VMRCANCiAgY3JlYXRlIGFuZCBzZW5kIHRoZSZuYnNwO1RoaXJk IFBhcnR5IExvc3MgcmVwb3J0IHRvIHRoZSBvdGhlciBkb3duc3RyZWFtIA0KICByZWNlaXZlcnMg d2hpY2ggYXJlIG5vdCZuYnNwO2F3YXJlIG9mIHRoZSBsb3NzIHJlcG9ydHMsIHRvIGluZm9ybSB0 aG9zZSANCiAgcmVjZWl2ZXJzIG9mIHRoZSBsb3NzIGFuZCZuYnNwO3N1cHByZXNzIHRoZWlyIGZl ZWRiYWNrLiZuYnNwOyZuYnNwO1RoZXJlZm9yZSANCiAgdGhlIGludGVybWVkaWF0ZSBub2RlIGNh biBiZSZuYnNwO3JlYXNvbmFibHkgY2VydGFpbiB0aGF0IGl0IHdpbGwgaGVscCB0aGUgDQogIHNp dHVhdGlvbiBieSBzZW5kaW5nIGEgVGhpcmQmbmJzcDtQYXJ0eSBMb3NzIFJlcG9ydCBtZXNzYWdl IHRvIGFsbCB0aGUgDQogIHJlbGV2YW50IHJlY2VpdmVycyyULiBUaGlzIG1ha2VzIGl0Jm5ic3A7 c291bmQgbGlrZSB0aGUgaW50ZXJtZWRpYXJ5IGFsd2F5cyANCiAgdXNlcyBhIHRoaXJkLXBhcnR5 IGxvc3MgcmVwb3J0IHRvIHRlbGwmbmJzcDtvdGhlciByZWNlaXZlcnMgYWJvdXQgZG93bnN0cmVh bSANCiAgbG9zcy4gVGhhdJJzIG5vdCB0aGUgY2FzZS4gSW4gbWFueSZuYnNwO3NjZW5hcmlvcywg dGhlIGludGVybWVkaWFyeSBjYW4gDQogIHJlZmxlY3QgTkFDS3MgaXQgcmVjZWl2ZXMgZnJvbSBv bmUmbmJzcDtkb3duc3RyZWFtIHJlY2VpdmVyIHRvIHRoZSBvdGhlciANCiAgcmVjZWl2ZXJzIHdp dGhvdXQgdXNpbmcgYSB0aGlyZCBwYXJ0eSZuYnNwO2xvc3MgcmVwb3J0LiBUaGUgdGhpcmQtcGFy dHkgbG9zcyANCiAgcmVwb3J0IGlzIG9ubHkgbmVlZGVkIGluIHRob3NlIGNhc2VzJm5ic3A7d2hl cmUgTkFDS3MgY2Fubm90IGJlIGRpc3RyaWJ1dGVkIHRvIA0KICBhbGwgcmVjZWl2ZXJzLjwvRElW Pg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNw OzwvRElWPg0KICA8RElWPltRaW5dOiBZb3UgYXJlIHJpZ2h0LiBBcyBmb3IgZG93bnN0cmVhbSBs b3NzLCBpbiBzb21lIGNhc2VzLCB0aGUgDQogIGludGVybWVkaWFyeSBtYXkgc2VuZCBOQUNLLCBl LmcuLCBSVENQLVNTTSBpbiBTaW1wbGUgZmVlZGJhY2sgbW9kZWwsIGluIHNvbWUgDQogIGNhc2Vz LCB0aGUgaW50ZXJtZWRpYXJ5IG11c3Qgc2VuZCB0aGUgdGhpcmQgcGFydHkgbG9zcyByZXBvcnQg aW5zdGVhZCBvZiANCiAgTkFDSyxlLmcuLCBSVENQLVNTTSBpbiBTdW1tYXJ5IEZlZWRiYWNrIE1v ZGVsLiBUaGVyZWZvcmUgSSBwcm9wb3NlIHRoZSBjaGFuZ2VzIA0KICBpbiBQYXJhZ3JhcGggMiwg c2VjdGlvbiAzIG9mIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cCBh cyANCiAgZm9sbG93czo8L0RJVj4NCiAgPERJVj5PTEQgVEVYVDo8L0RJVj4NCiAgPERJVj48Rk9O VCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PiI8L0ZPTlQ+PC9ESVY+DQogIDxESVY+Jm5i c3A7VXBvbiBvYnNlcnZpbmcgKG9yIHN1c3BlY3RpbmcpIGFuIHVwc3RyZWFtIGxvc3MsIA0KICB0 aGU8QlI+Jm5ic3A7Jm5ic3A7IGludGVybWVkaWFyeSBTaG91bGQgc2VuZCBOQUNLIGJvdGggZG93 bnN0cmVhbSB0b3dhcmRzIHRoZSANCiAgcmVjZWl2ZXJzPEJSPiZuYnNwOyZuYnNwOyBhbmQgdXBz dHJlYW0gdG93YXJkcyB0aGUgbWVkaWEgc291cmNlLCB0byBpbmRpY2F0ZSANCiAgdGhhdCBpdCBo YXM8QlI+Jm5ic3A7Jm5ic3A7IG5vdGljZWQgdGhlIGxvc3MsIGFuZCB0byBzdXBwcmVzcyBmZWVk YmFjayBmcm9tIA0KICBvdGhlciBkb3duc3RyZWFtPEJSPiZuYnNwOyZuYnNwOyByZWNlaXZlcnMu Jm5ic3A7IEhvd2V2ZXIsIGluIHNvbWUgY2FzZXMgd2hlcmUgDQogIHBhY2tldCBsb3NzIG9jY3Vy cyBpbiB0aGU8QlI+Jm5ic3A7Jm5ic3A7IGRvd25zdHJlYW0gb2YgdGhlc2UgaW50ZXJtZWRpYXRl cywgDQogIGl0IGlzIG5vdCBwb3NzaWJsZSBmb3IgdGhlbSB0bzxCUj4mbmJzcDsmbmJzcDsgZGlz dHJpYnV0ZSB0aGUgTkFDS3MgdG8gYWxsIA0KICByZWNlaXZlcnMgc2luY2UgdGhleSBhcmUgdW5h YmxlIHRvPEJSPiZuYnNwOyZuYnNwOyBvYnNlcnZlIGRvd25zdHJlYW0gDQogIGxvc3MuJm5ic3A7 IEluIHN1Y2ggY2FzZXMsIGRvd25zdHJlYW0gbG9zcyBuZWVkcyB0byBiZTxCUj4mbmJzcDsmbmJz cDsgZmlyc3RseSANCiAgcmVwb3J0ZWQgdG8gdGhlIGludGVybWVkaWFyeS4mbmJzcDsgV2hlbiBk b3duc3RyZWFtIGxvc3MgaXM8QlI+Jm5ic3A7Jm5ic3A7IA0KICByZXBvcnRlZCB0byB0aGUgaW50 ZXJtZWRpYXJ5LCB0aGUgaW50ZXJtZWRpYXJ5IFNIT1VMRCBjcmVhdGUgYW5kIA0KICBzZW5kPEJS PiZuYnNwOyZuYnNwOyB0aGUgVGhpcmQgUGFydHkgTG9zcyByZXBvcnQgdG8gdGhlIG90aGVyIGRv d25zdHJlYW0gDQogIHJlY2VpdmVycyB3aGljaDxCUj4mbmJzcDsmbmJzcDsgYXJlIG5vdCBhd2Fy ZSBvZiB0aGUgbG9zcyByZXBvcnRzLCB0byBpbmZvcm0gDQogIHRob3NlIHJlY2VpdmVycyBvZiB0 aGU8QlI+Jm5ic3A7Jm5ic3A7IGxvc3MgYW5kIHN1cHByZXNzIHRoZWlyIGZlZWRiYWNrLiZuYnNw OyANCiAgPC9ESVY+DQogIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz4i PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7JiMyMDMwNzs+ TkVXIFRFWFQ6PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPSYjMjM0MzU7 JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPiI8L0RJVj4NCiAgPERJVj4mbmJz cDsmbmJzcDsgSWYgYW4gaW50ZXJtZWRpYXJ5IG5vdGljZXMgdGhlIGxvc3MgaXRzZWxmLCB0aGVu IA0KICBpdDxCUj4mbmJzcDsmbmJzcDsgbWF5IHNlbmQgYSBOQUNLIGJvdGggZG93bnN0cmVhbSB0 b3dhcmRzIHRoZSByZWNlaXZlcnMgYW5kIA0KICB1cHN0cmVhbTxCUj4mbmJzcDsmbmJzcDsgdG93 YXJkcyB0aGUgbWVkaWEgc291cmNlLCB0byBpbmRpY2F0ZSB0aGF0IGl0IGhhcyANCiAgbm90aWNl ZCB0aGUgbG9zcyw8QlI+Jm5ic3A7Jm5ic3A7IGFuZCB0byBzdXBwcmVzcyBmZWVkYmFjayBmcm9t IG90aGVyIA0KICBkb3duc3RyZWFtIHJlY2VpdmVycy4mbmJzcDsgSWYgYW48QlI+Jm5ic3A7Jm5i c3A7IGludGVybWVkaWFyeSByZWNlaXZlcyBhIE5BQ0sgDQogIGZyb20gYW5vdGhlciBzeXN0ZW0s IGl0IHNob3VsZDxCUj4mbmJzcDsmbmJzcDsgcmVkaXN0cmlidXRlIHRoYXQgTkFDSyB0byBhbGwg DQogIG90aGVyIHN5c3RlbXMgdGhhdCB3b3VsZCBub3Qgb3RoZXJ3aXNlPEJSPiZuYnNwOyZuYnNw OyByZWNlaXZlIGl0LiZuYnNwOyBBbiANCiAgZXhhbXBsZSBvZiB0aGlzIGlzIFJUQ1AtU1NNIGlu IHNpbXBsZSBmZWVkYmFjayBtb2RlbDxCUj4mbmJzcDsmbmJzcDsgDQogIFtSRkM1NzYwXSwgd2hl cmUgdGhlIGRpc3RyaWJ1dGlvbiBzb3VyY2UgcmVmbGVjdHMgTkFDS3MgdG8gDQogIG90aGVyPEJS PiZuYnNwOyZuYnNwOyBzeXN0ZW1zLiZuYnNwOyBJZiBhbiBpbnRlcm1lZGlhcnkgcmVjZWl2ZXMg YSBOQUNLIGZyb20gDQogIGFub3RoZXIgc3lzdGVtLDxCUj4mbmJzcDsmbmJzcDsgYnV0LCBmb3Ig c29tZSByZWFzb24sIGNhbm5vdCByZWRpc3RyaWJ1dGUgdGhhdCANCiAgTkFDSywgdGhlbiBpdCBt YXkgc2VuZDxCUj4mbmJzcDsmbmJzcDsgYSB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydCB0byB0aGUg DQogIHN5c3RlbXMgdGhhdCB3ZXJlIHVuYWJsZSB0byByZWNlaXZlPEJSPiZuYnNwOyZuYnNwOyB0 aGUgTkFDSywgYW5kIHdvbid0IA0KICByZWNlaXZlIHRoZSBOQUNLIHZpYSBvdGhlciBtZWFucy4m bmJzcDsgQW4gZXhhbXBsZTxCUj4mbmJzcDsmbmJzcDsgd291bGQgYmUgYSANCiAgZGlzdHJpYnV0 aW9uIHNvdXJjZSB1c2luZyBSVENQLVNTTSBpbiBEaXN0cmlidXRpb24gU291cmNlPEJSPiZuYnNw OyZuYnNwOyANCiAgRmVlZGJhY2sgU3VtbWFyeSBtb2RlbCBbUkZDNTc2MF0uIDwvRElWPg0KICA8 RElWPiI8L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7Pjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJVj4tIFNlY3Rpb24gMywgM3JkIHBhcmFncmFwaDogdGhp cyB3b3VsZCBiZSBtdWNoIGNsZWFyZXIgaWYgaXQgZGlzY3Vzc2VkIA0KICB3aGVuIGl0knMgYXBw cm9wcmlhdGUgdG8gbW9uaXRvciB0aGUgZmVlZGJhY2sgPC9ESVY+DQogIDxESVY+YW5kIHNlbmQg YSB0aGlyZC1wYXJ0eSBsb3NzIHJlcG9ydCB0byBkb3duc3RyZWFtIHJlY2VpdmVycywgcmF0aGVy IHRoYW4gDQogIGp1c3QgcmVmbGVjdCBOQUNLcyBiYWNrIGRvd25zdHJlYW0uPEJSPjwvRElWPg0K ICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICA8RElWPg0KICAgIDxESVY+W1Fpbl06IE9r YXkuIEkgdGhpbmsgdGhlIGFuc3dlciB0byB3aGVuIGlzPC9ESVY+DQogICAgPERJVj4iPC9ESVY+ DQogICAgPERJVj5VcG9uIHJlY2VpdmluZyBkb3duc3RyZWFtIGxvc3MgcmVwb3J0IGluIHRoZSB3 YXkgb2Ygc3VjaCBmZWVkYmFjayANCiAgICByZXBvcnQgb25seSBkZXN0aW5lZCBmb3IgbWVkaWEg c291cmNlLCB0aGUgbWVkaWEgc291cmNlIFNIT1VMRCBzZW5kIHRoZSANCiAgICBUaGlyZDxCUj5Q YXJ0eSBMb3NzIFJlcG9ydCBtZXNzYWdlcyB0byB0aGUgcmVjZWl2ZXJzLjwvRElWPg0KICAgIDxE SVY+IjwvRElWPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+ SSBkb24ndCB0aGluayB0aGF0J3MgY29ycmVjdC4mbmJzcDtJbiBtb3N0IGNhc2VzLCBsb3NzIGZl ZWRiYWNrIGRlc3RpbmVkIA0KICB0byB0aGUgc2VuZGVyIHNob3VsZCBiZSByZWZsZWN0ZWQmbmJz cDtkb3duc3RyZWFtIHRvIHN1cHByZXNzIGZ1cnRoZXIgDQogIGZlZWRiYWNrLiAmbmJzcDs8L0RJ Vj4NCiAgPERJVj5UaGlzIGRyYWZ0IG5lZWRzIHRvIGRpc2N1c3MgdGhlIHNjZW5hcmlvcywgZm9y Jm5ic3A7ZXhhbXBsZSBTU00gc2Vzc2lvbnMgDQogIHVzaW5nIERpc3RyaWJ1dGlvbiBTb3VyY2Ug RmVlZGJhY2sgU3VtbWFyeSZuYnNwO21vZGUsIHdoZXJlIHRoaXMgaXMgbm90IA0KICBwb3NzaWJs ZS4gPC9ESVY+DQogIDxESVY+SXQgaXMgdGhlc2Ugc2NlbmFyaW9zIHdoZXJlIHRoaXJkIHBhcnR5 Jm5ic3A7bG9zcyByZXBvcnRzIGFyZSANCiAgbmVlZGVkLjwvRElWPg0KICA8RElWPiZuYnNwOzwv RElWPg0KICA8RElWPltRaW5dOiBBZ3JlZSwgUHJvcG9zZWQgdGhlIGZvbGxvd2luZyBjaGFuZ2Vz OjwvRElWPg0KICA8RElWPk9MRCBURVhUOjwvRElWPg0KICA8RElWPiI8L0RJVj4NCiAgPERJVj4m bmJzcDsmbmJzcDsgVXBvbiByZWNlaXZpbmc8QlI+Jm5ic3A7Jm5ic3A7IGRvd25zdHJlYW0gbG9z cyByZXBvcnQgaW4gdGhlIA0KICBmb3JtIG9mIHN1Y2ggZmVlZGJhY2sgcmVwb3J0IHdoaWNoIGlz PEJSPiZuYnNwOyZuYnNwOyBvbmx5IGRlc3RpbmVkIGZvciBtZWRpYSANCiAgc291cmNlLCB0aGUg bWVkaWEgc291cmNlIFNIT1VMRCBjcmVhdGUgYW5kPEJSPiZuYnNwOyZuYnNwOyBzZW5kIHRoZSBU aGlyZCANCiAgUGFydHkgTG9zcyBSZXBvcnQgbWVzc2FnZXMgdG8gdGhlIG90aGVyIGRvd25zdHJl YW08QlI+Jm5ic3A7Jm5ic3A7IHJlY2VpdmVycyANCiAgd2hpY2ggYXJlIG5vdCBhd2FyZSBvZiB0 aGUgbG9zcyByZXBvcnRzLCB0byBpbmZvcm0gdGhvc2U8QlI+Jm5ic3A7Jm5ic3A7IA0KICByZWNl aXZlcnMgb2YgdGhlIGxvc3MgYW5kIHN1cHByZXNzIHRoZWlyIGZlZWRiYWNrLjxCUj48L0RJVj4N CiAgPERJVj4iPC9ESVY+DQogIDxESVY+TkVXIFRFWFQ6PEJSPjxGT05UIHNpemU9MiBmYWNlPSYj MjM0MzU7JiMyMDMwNzs+IjwvRk9OVD48L0RJVj4NCiAgPERJVj4mbmJzcDsmbmJzcDsgSWYgdGhl IG1lZGlhIHNvdXJjZTxCUj4mbmJzcDsmbmJzcDsgcmVjZWl2ZXMgYSBOQUNLIGZyb20gDQogIGFu b3RoZXIgc3lzdGVtLCBpdCBzaG91bGQgcmVkaXN0cmlidXRlIHRoYXQgTkFDSzxCUj4mbmJzcDsm bmJzcDsgdG8gYWxsIG90aGVyIA0KICBzeXN0ZW1zIHRoYXQgd291bGQgbm90IG90aGVyd2lzZSBy ZWNlaXZlIGl0LiZuYnNwOyBBbiBleGFtcGxlPEJSPiZuYnNwOyZuYnNwOyANCiAgb2YgdGhpcyBp cyBSVENQLVNTTSBpbiBzaW1wbGUgZmVlZGJhY2sgbW9kZWwgW1JGQzU3NjBdLCB3aGVyZSANCiAg dGhlPEJSPiZuYnNwOyZuYnNwOyBkaXN0cmlidXRpb24gc291cmNlIHJlZmxlY3RzIE5BQ0tzIHRv IG90aGVyIHN5c3RlbXMuJm5ic3A7IA0KICBJZiBhbjxCUj4mbmJzcDsmbmJzcDsgaW50ZXJtZWRp YXJ5IHJlY2VpdmVzIGEgTkFDSyBmcm9tIGFub3RoZXIgc3lzdGVtLCBidXQsIA0KICBmb3Igc29t ZTxCUj4mbmJzcDsmbmJzcDsgcmVhc29uLCBjYW5ub3QgcmVkaXN0cmlidXRlIHRoYXQgTkFDSywg dGhlbiBpdCBtYXkgDQogIHNlbmQgYSB0aGlyZC1wYXJ0eTxCUj4mbmJzcDsmbmJzcDsgbG9zcyBy ZXBvcnQgdG8gdGhlIHN5c3RlbXMgdGhhdCB3ZXJlIHVuYWJsZSANCiAgdG8gcmVjZWl2ZSB0aGUg TkFDSywgYW5kPEJSPiZuYnNwOyZuYnNwOyB3b24ndCByZWNlaXZlIHRoZSBOQUNLIHZpYSBvdGhl ciANCiAgbWVhbnMuJm5ic3A7IEFuIGV4YW1wbGUgd291bGQgYmUgYTxCUj4mbmJzcDsmbmJzcDsg ZGlzdHJpYnV0aW9uIHNvdXJjZSB1c2luZyANCiAgUlRDUC1TU00gaW4gRGlzdHJpYnV0aW9uIFNv dXJjZSBGZWVkYmFjazxCUj4mbmJzcDsmbmJzcDsgU3VtbWFyeSBtb2RlbCANCiAgW1JGQzU3NjBd LjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT0mIzIzNDM1OyYjMjAzMDc7PiI8 L0ZPTlQ+PEJSPjxCUj5PbiA2IE1heSAyMDExLCBhdCAxMDo1MywgUWluIFd1IA0KICB3cm90ZTo8 QlI+Jmd0OyBIaSw8QlI+Jmd0OyBUaGUgbmV3IHZlcnNpb24gb2YgDQogIGRyYWZ0LWlldGYtYXZ0 Y29yZS1mZWVkYmFjay1zdXBwcmVzc2lvbi1ydHAgaXMgYXZhaWxhYmxlIGF0PEJSPiZndDs8U1BB TiANCiAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSANCiAgaHJl Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3Jl LWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAyLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRwLTAy LnR4dDwvQT48QlI+Jmd0OyANCiAgd2hpY2ggYWRkcmVzcyB0aGUgcmVjZW50IGNvbW1lbnRzIGZy b20gQ29saW4gb24gdGhlIGxpc3QuPEJSPiZndDsgVGhlIG1haW4gDQogIGNoYW5nZSBpcyB0byBj bGFyaWZ5IHRoZSB1c2Ugb2YgdGhpcmQgcGFydHkgbG9zcyByZXBvcnQgYW5kIHVwZGF0ZSB0aGUg dGl0bGUgDQogIGFuZCByZWxldmFudCBzZWN0aW9uczxTUEFOIGNsYXNzPUFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEJSPiZndDsgDQogIHRvIGZvY3VzIG9uIHRoaXJkIHBhcnR5 IGxvc3MgcmVwb3J0LjxCUj4mZ3Q7IFRoZSBkaWZmIGlzIGF0OjxCUj4mZ3Q7PFNQQU4gDQogIGNs YXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEEgDQogIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNr LXN1cHJlc3Npb24tcnRwLTAyIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0wMjwvQT48QlI+Jmd0OyAN CiAgUGxlYXNlIGNoZWNrIGlmIHlvdSBhcmUgY29tZm9ydGFibGUgd2l0aCB0aGUgY2hhbmdlcyBp biB0aGlzIHZlcnNpb24uPEJSPiZndDsgDQogIEFueSBjb21tZW50cz88QlI+Jmd0OzxTUEFOIGNs YXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEJSPiZndDsgDQogIFJlZ2Fy ZHMhPEJSPiZndDsgLVFpbjxCUj4mZ3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08U1BB TiANCiAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OyBG cm9tOiAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvQT4mZ3Q7PEJSPiZndDsgDQogIFRvOiAmbHQ7PEEgDQog IGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9y ZzwvQT4mZ3Q7PEJSPiZndDsgQ2M6IA0KICAmbHQ7PEEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9y ZyI+YXZ0QGlldGYub3JnPC9BPiZndDs8QlI+Jmd0OyBTZW50OiBGcmlkYXksIA0KICBNYXkgMDYs IDIwMTEgNTozOSBQTTxCUj4mZ3Q7IFN1YmplY3Q6IEktRCBBY3Rpb246IA0KICBkcmFmdC1pZXRm LWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0PEJSPiZndDs8U1BBTiANCiAg Y2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OzxTUEFOIA0K ICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxCUj4mZ3Q7Jmd0OyBB IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyANCiAgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayANCiAgaXRlbSBv ZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UgV29ya2luZyBHcm91 cCBvZiB0aGUgDQogIElFVEYuPEJSPiZndDsmZ3Q7PFNQQU4gY2xhc3M9QXBwbGUtY29udmVydGVk LXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OyZndDsgDQogIFRpdGxlJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogUlRDUCANCiAg RXh0ZW5zaW9uIGZvciBUaGlyZC1wYXJ0eSBMb3NzIFJlcG9ydDxCUj4mZ3Q7Jmd0OyANCiAgQXV0 aG9yKHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogUWluIA0KICBXdTxC Uj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgRnJhbmsgDQogIFhp YTxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgUm9uaSBFdmVu PEJSPiZndDsmZ3Q7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDogDQogIGRyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNzaW9uLXJ0cC0w Mi50eHQ8QlI+Jmd0OyZndDsgDQogIFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogDQogIDE4PEJSPiZndDsmZ3Q7IA0KICBE YXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogDQogIDIwMTEtMDUtMDY8QlI+Jmd0OyZndDs8U1BBTiANCiAgY2xhc3M9 QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OyZndDsmbmJzcDsgSW4g YSBsYXJnZSBSVFAgDQogIHNlc3Npb24gdXNpbmcgdGhlIFJUQ1AgZmVlZGJhY2sgbWVjaGFuaXNt IGRlZmluZWQgaW48QlI+Jmd0OyZndDsmbmJzcDsgUkZDIA0KICA0NTg1LCBhIG1lZGlhIHNvdXJj ZSBvciBtaWRkbGVib3ggbWF5IGV4cGVyaWVuY2UgdHJhbnNpZW50PEJSPiZndDsmZ3Q7Jm5ic3A7 IA0KICBvdmVybG9hZCBpZiBzb21lIGV2ZW50IGNhdXNlcyBhIGxhcmdlIG51bWJlciBvZiByZWNl aXZlcnMgdG8gDQogIHNlbmQ8QlI+Jmd0OyZndDsmbmJzcDsgZmVlZGJhY2sgYXQgb25jZS4mbmJz cDsgVGhpcyBmZWVkYmFjayBpbXBsb3Npb24gY2FuIGJlIA0KICBtaXRpZ2F0ZWQgaWYgdGhlPEJS PiZndDsmZ3Q7Jm5ic3A7IGRldmljZSBzdWZmZXJpbmcgZnJvbSBvdmVybG9hZCBjYW4gc2VuZCBh IA0KICB0aGlyZCBwYXJ0eSBsb3NzIHJlcG9ydDxCUj4mZ3Q7Jmd0OyZuYnNwOyBtZXNzYWdlIHRv IHRoZSByZWNlaXZlcnMgdG8gaW5oaWJpdCANCiAgZnVydGhlciBmZWVkYmFjay4mbmJzcDsgVGhp cyBtZW1vPEJSPiZndDsmZ3Q7Jm5ic3A7IGRlZmluZXMgUlRDUCBFeHRlbnNpb24gZm9yIA0KICB0 aGlyZCBwYXJ0eSBsb3NzIHJlcG9ydCwgdG8gc3VwcHJlc3MgTkFDSzxCUj4mZ3Q7Jmd0OyZuYnNw OyBhbmQgRklSIGZlZWRiYWNrIA0KICByZXF1ZXN0cy4mbmJzcDsgSXQgYWxzbyBkZWZpbmVzIGFz c29jaWF0ZWQgU0RQIHNpZ25hbGluZy48QlI+Jmd0OyZndDs8U1BBTiANCiAgY2xhc3M9QXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OyZndDs8U1BBTiANCiAgY2xhc3M9 QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Jmd0OyZndDsgQSBVUkwgZm9y IHRoaXMgDQogIEludGVybmV0LURyYWZ0IGlzOjxCUj4mZ3Q7Jmd0OzxTUEFOIA0KICBjbGFzcz1B cHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIA0KICBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3Vw cmVzc2lvbi1ydHAtMDIudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0PC9BPjxCUj4m Z3Q7Jmd0OzxTUEFOIA0KICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFO PjxCUj4mZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gDQogIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0OjxCUj4mZ3Q7Jmd0OzxTUEFOIA0KICBjbGFzcz1BcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIA0KICBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L0E+PEJS PiZndDsmZ3Q7PFNQQU4gDQogIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQ QU4+PEJSPiZndDsmZ3Q7IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIA0KICBiZSByZXRyaWV2ZWQg YXQ6PEJSPiZndDsmZ3Q7PFNQQU4gY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv U1BBTj48QSANCiAgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDIudHh0Ij5mdHA6Ly9mdHAu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXBy ZXNzaW9uLXJ0cC0wMi50eHQ8L0E+PEJSPiZndDsmZ3Q7IA0KICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7Jmd0OyBJLUQtQW5ub3VuY2UgDQog IG1haWxpbmcgbGlzdDxCUj4mZ3Q7Jmd0OzxTUEFOIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFj ZT4mbmJzcDs8L1NQQU4+PEEgDQogIGhyZWY9Im1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmci PkktRC1Bbm5vdW5jZUBpZXRmLm9yZzwvQT48QlI+Jmd0OyZndDs8U1BBTiANCiAgY2xhc3M9QXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9BPjxCUj4mZ3Q7Jmd0OyANCiAgSW50 ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6PFNQQU4gY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNl PiZuYnNwOzwvU1BBTj48QSANCiAgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bCI+aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvQT48QlI+Jmd0OyZndDsgDQogIG9y PFNQQU4gY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSANCiAgaHJl Zj0iZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQiPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9BPjxCUj4mZ3Q7IA0KICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4mZ3Q7IEF1ZGlvL1ZpZGVv IFRyYW5zcG9ydCANCiAgQ29yZSBNYWludGVuYW5jZTxCUj4mZ3Q7PFNQQU4gY2xhc3M9QXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSANCiAgaHJlZj0ibWFpbHRvOmF2dEBpZXRm Lm9yZyI+YXZ0QGlldGYub3JnPC9BPjxCUj4mZ3Q7PFNQQU4gDQogIGNsYXNzPUFwcGxlLWNvbnZl cnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2F2dDwvQT48QlI+PEJSPjxCUj48QlI+LS08U1BBTiANCiAgY2xhc3M9QXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QlI+Q29saW4gUGVya2luczxCUj48QSANCiAgaHJlZj0i aHR0cDovL2NzcGVya2lucy5vcmcvIj5odHRwOi8vY3NwZXJraW5zLm9yZy88L0E+PEJSPjxCUj48 QlI+PC9ESVY+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgIDxESVY+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+QXVkaW8vVmlkZW8gDQog ICAgVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2U8QlI+PEEgDQogICAgaHJlZj0ibWFpbHRvOmF2 dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9BPjxCUj48QSANCiAgICBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hdnQ8L0E+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+DQog IDxESVY+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB4IiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFu PjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9STTogbm9uZTsgVEVYVC1J TkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9OVDogOXB4ICdMdWNpZGEg U2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFOUzogMjsgTEVUVEVS LVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzogMHB4OyAt d2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVy dGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBu b25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBjbGFzcz1BcHBsZS1zdHls ZS1zcGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9STTogbm9uZTsg VEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9OVDogOXB4ICdM dWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFOUzogMjsg TEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BBQ0lORzog MHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3Jk ZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZm ZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBjbGFzcz1BcHBs ZS1zdHlsZS1zcGFuPjxTUEFOIA0KICBzdHlsZT0iV0lET1dTOiAyOyBURVhULVRSQU5TRk9STTog bm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExBUFNFOiBzZXBhcmF0ZTsgRk9OVDog OXB4ICdMdWNpZGEgU2FucyBUeXBld3JpdGVyJzsgV0hJVEUtU1BBQ0U6IG5vcm1hbDsgT1JQSEFO UzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgQ09MT1I6IHJnYigwLDAsMCk7IFdPUkQtU1BB Q0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtp dC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMt aW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG8iIA0KICBjbGFz cz1BcHBsZS1zdHlsZS1zcGFuPg0KICA8RElWPjxCUiBjbGFzcz1BcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lPjxCUiANCiAgY2xhc3M9a2h0bWwtYmxvY2stcGxhY2Vob2xkZXI+PC9ESVY+DQogIDxE SVY+LS0mbmJzcDs8L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj5Db2xpbiBQZXJraW5zPC9E SVY+DQogIDxESVY+PEEgDQogIGhyZWY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDovL2Nz cGVya2lucy5vcmcvPC9BPjwvRElWPjwvU1BBTj48L1NQQU4+PC9TUEFOPjxCUiANCiAgY2xhc3M9 QXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZT48L1NQQU4+PEJSIA0KICBjbGFzcz1BcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lPjwvRElWPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRN TD4NCg== --Boundary_(ID_h6aFQp1PUUqdHDG0S8KHQg)-- From kevin.gross@comcast.net Wed May 25 13:18:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60C1300C0 for ; Wed, 25 May 2011 13:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmGKscKUa2Zp for ; Wed, 25 May 2011 13:18:05 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id DB973130085 for ; Wed, 25 May 2011 13:18:04 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id nw1i1g0061wpRvQ5DwJ5tA; Wed, 25 May 2011 20:18:05 +0000 Received: from AVADesk2 ([76.120.76.232]) by omta18.westchester.pa.mail.comcast.net with comcast id nwHy1g03850jATQ3ewJ11W; Wed, 25 May 2011 20:18:02 +0000 From: "Kevin Gross" To: "'IETF AVTCore WG'" References: <4DAC4F69.1080707@ericsson.com> <001901cc00ed$602f1810$208d4830$@gross@comcast.net> In-Reply-To: <001901cc00ed$602f1810$208d4830$@gross@comcast.net> Date: Wed, 25 May 2011 14:17:55 -0600 Organization: AVA Networks Message-ID: <007601cc1b18$d7432a50$85c97ef0$@gross@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acv918tASfPd6jaNRZCwYXDe4G9XSADFV1UwBoXslKA= Content-Language: en-us Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:18:05 -0000 I have reviewed the draft and offer these comments: MSAS acronym is used on p.5 before its definition on p.7. IDMS is applicable to the commercial AV applications I work on - = stadiums, legislative, concerts, general public address, etc. I'd be happy to = provide a use case for section 4 if that would be helpful. Consider using the 64-bit NTP format for Packet Presented NTP timestamp. = The current 32-bit 15 microsecond resolution is longer than some audio = sample periods. The resolution could be a limitation in some use cases - stereo imaging and audio beam forming. Need clarification or cleanup of the last sentence of first paragraph in section 8. Synchronized clocks should not drift beyond the accuracy of = the synchronization mechanism. Move second paragraph in section 8 to section 4. This is a use-case discussion. Add comments on p.14 to explain what "gps", "gal" and "ptp" are. p.14: Format of ptp-id depends on the version of PTP in use. IEEE = 1588-2002 uses an ASCII string. IEEE 1588-2008 uses a 7-bit identifier. IEEE 802.1AS-2011 uses a 64-bit identifier. p.14: As per above, we probably need to add some means for identifying = PTP version/profile in use. p.14: Consider increased precision for last-synced. PTP can deliver = updates up to 100 times per second. Add justification to section 12 for new packet type. Why is the ETSI = TISPAN approach deficient? Section 13 does not give a complete enough description of how = presentation time alignment would be accomplished for us to verify whether the = protocol delivers enough information for it to be done accurately and reliably. = The Boronat2009 reference also does not provide the necessary details. How = does the system deal with changing latency due to changing network conditions = and media formats? How do we handle devices that don't output directly to = users (e.g. STB connected to HDTV with unknown delay in the HDTV)? Kevin Gross AVA Networks -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross Sent: Friday, April 22, 2011 7:01 AM To: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination = media synchronization This is of interest to me and I should be able to review it and = contribute comments. Kevin Gross AVA Networks -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund Sent: Monday, April 18, 2011 8:49 AM To: IETF AVTCore WG Subject: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization WG, At the WG meeting in Prague we had a show of hands if we should create a WG work item for RTCP for inter-destination media synchronization. Along the lines described by https://datatracker.ietf.org/doc/draft-brandenburg-avtcore-rtcp-for-idms/= . There where 5 persons in the room indicating interest. We now would like to judge the interest on the mailing list for a new WG item. Please indicate your support and willingness to contribute. If you think it shouldn't be done please voice that opinion also. This call runs for 2 weeks until Wednesday the 4th of May. Regards Magnus Westerlund AVTCore chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From ray.vanbrandenburg@tno.nl Thu May 26 00:04:50 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DAAE074C for ; Thu, 26 May 2011 00:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZwARaEBoozo for ; Thu, 26 May 2011 00:04:49 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id B6A0CE0706 for ; Thu, 26 May 2011 00:04:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,272,1304287200"; d="scan'208";a="52282592" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 26 May 2011 09:04:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0270.001; Thu, 26 May 2011 09:04:45 +0200 From: "Brandenburg, R. (Ray) van" To: 'Kevin Gross' , 'IETF AVTCore WG' Thread-Topic: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization Thread-Index: AQHMGxjpaXrquprW7Ey1A7k4oI3HwJSer0qA Date: Thu, 26 May 2011 07:04:44 +0000 Message-ID: References: <4DAC4F69.1080707@ericsson.com> <001901cc00ed$602f1810$208d4830$@gross@comcast.net> <007601cc1b18$d7432a50$85c97ef0$@gross@comcast.net> In-Reply-To: <007601cc1b18$d7432a50$85c97ef0$@gross@comcast.net> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 07:04:50 -0000 Hi Kevin, Thanks for your extensive review. Very helpful. We will start work on a new= version which incorporates your comments.=20 > IDMS is applicable to the commercial AV applications I work on - stadiums= , legislative, concerts, general public address, etc. I'd be happy to provi= de a use case for section 4 if that would be helpful. That would be great! Kind Regards, Ray van Brandenburg -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin= Gross Sent: woensdag 25 mei 2011 22:18 To: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media= synchronization I have reviewed the draft and offer these comments: MSAS acronym is used on p.5 before its definition on p.7. IDMS is applicable to the commercial AV applications I work on - stadiums, = legislative, concerts, general public address, etc. I'd be happy to provide= a use case for section 4 if that would be helpful. Consider using the 64-bit NTP format for Packet Presented NTP timestamp. Th= e current 32-bit 15 microsecond resolution is longer than some audio sample= periods. The resolution could be a limitation in some use cases - stereo i= maging and audio beam forming. Need clarification or cleanup of the last sentence of first paragraph in se= ction 8. Synchronized clocks should not drift beyond the accuracy of the sy= nchronization mechanism. Move second paragraph in section 8 to section 4. This is a use-case discuss= ion. Add comments on p.14 to explain what "gps", "gal" and "ptp" are. p.14: Format of ptp-id depends on the version of PTP in use. IEEE 1588-2002= uses an ASCII string. IEEE 1588-2008 uses a 7-bit identifier. IEEE 802.1AS-2011 uses a 64-bit identifier. p.14: As per above, we probably need to add some means for identifying PTP = version/profile in use. p.14: Consider increased precision for last-synced. PTP can deliver updates= up to 100 times per second. Add justification to section 12 for new packet type. Why is the ETSI TISPAN= approach deficient? Section 13 does not give a complete enough description of how presentation = time alignment would be accomplished for us to verify whether the protocol = delivers enough information for it to be done accurately and reliably. The Boronat2009 reference also does not provide the necessary details. How does= the system deal with changing latency due to changing network conditions a= nd media formats? How do we handle devices that don't output directly to us= ers (e.g. STB connected to HDTV with unknown delay in the HDTV)? Kevin Gross AVA Networks -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Kevin= Gross Sent: Friday, April 22, 2011 7:01 AM To: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Call for WG item on RTCP for inter-destination media= synchronization This is of interest to me and I should be able to review it and contribute = comments. Kevin Gross AVA Networks -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: Monday, April 18, 2011 8:49 AM To: IETF AVTCore WG Subject: [AVTCORE] Call for WG item on RTCP for inter-destination media syn= chronization WG, At the WG meeting in Prague we had a show of hands if we should create a WG= work item for RTCP for inter-destination media synchronization. Along the = lines described by https://datatracker.ietf.org/doc/draft-brandenburg-avtco= re-rtcp-for-idms/. There where 5 persons in the room indicating interest. We now would like to= judge the interest on the mailing list for a new WG item. Please indicate = your support and willingness to contribute. If you think it shouldn't be do= ne please voice that opinion also. This call runs for 2 weeks until Wednesday the 4th of May. Regards Magnus Westerlund AVTCore chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From abegen@cisco.com Thu May 26 07:29:40 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54534E06FE for ; Thu, 26 May 2011 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taJoRKTpD8gC for ; Thu, 26 May 2011 07:29:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id A160DE06B2 for ; Thu, 26 May 2011 07:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2998; q=dns/txt; s=iport; t=1306420179; x=1307629779; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=YOEEoeyREgyKSGf8Ff+ifneH2Tvqpg/FEIctBFAD5W4=; b=EoAoySMdnuudRrnDi6wCFoVIlcxdd+3bSL4Oig9yaKfNWCRjYkZJgdOB JwieFj6/P07LPonjlouLAQMx886iX14IEu99806bjiYtSujbAUEjJ9hOX 9ko5ih7i2vIlSCUdhNNrB6oAlJ2Xa834GxoZNyzAc+/bPqWGd3zZypiqn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAN9i3k2rRDoJ/2dsb2JhbABUhEmTG0CNHmt4qGONBpBUgSuDaoEHBIZhjhqKbg X-IronPort-AV: E=Sophos;i="4.65,273,1304294400"; d="scan'208";a="703805757" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 26 May 2011 14:29:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4QETdFH006695 for ; Thu, 26 May 2011 14:29:39 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 May 2011 07:29:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 26 May 2011 07:28:48 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F14CCC1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20110526140043.21799.62941.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification fordraft-vancaenegem-avtcore-retransmission-for-ssm-00.txt Thread-Index: AcwbrVIwJhK2TTQCRuCIhNNxAoeUYwAA5kIg References: <20110526140043.21799.62941.idtracker@ietfa.amsl.com> From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 26 May 2011 14:29:39.0143 (UTC) FILETIME=[584BDD70:01CC1BB1] Subject: [AVTCORE] FW: New Version Notification fordraft-vancaenegem-avtcore-retransmission-for-ssm-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 14:29:40 -0000 SGkgZXZlcnlvbmUsDQoNCkEgbmV3IGRyYWZ0IGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBkaXNjdXNz IHJldHJhbnNtaXNzaW9ucyBmb3IgU1NNLg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdmFuY2FlbmVnZW0tYXZ0Y29yZS1yZXRyYW5zbWlzc2lvbi1mb3Itc3NtLw0KDQpX ZSBoYXZlIGJlZW4gY29uc2lkZXJpbmcgdG8gcHV0IHN1Y2ggYSBkcmFmdCB0b2dldGhlciBmb3Ig c29tZSB0aW1lLiBDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KLWFjYmVnZW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgTWF5IDI2LCAyMDEx IDEwOjAxIEFNDQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpDYzogYmlsbHZzQGNpc2NvLmNv bTsgdG9tLnZhbl9jYWVuZWdlbUBhbGNhdGVsLWx1Y2VudC5jb207IEFsaSBDLiBCZWdlbiAoYWJl Z2VuKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0LXZhbmNhZW5l Z2VtLWF2dGNvcmUtcmV0cmFuc21pc3Npb24tZm9yLXNzbS0wMC50eHQNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXZhbmNhZW5lZ2VtLWF2dGNvcmUtcmV0cmFuc21pc3Npb24tZm9yLXNz bS0wMC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGkgQmVnZW4gYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXZhbmNh ZW5lZ2VtLWF2dGNvcmUtcmV0cmFuc21pc3Npb24tZm9yLXNzbQ0KUmV2aXNpb246CSAwMA0KVGl0 bGU6CQkgUmV0cmFuc21pc3Npb24gZm9yIFNvdXJjZS1TcGVjaWZpYyBNdWx0aWNhc3QgKFNTTSkg U2Vzc2lvbnMNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA1LTI2DQpXRyBJRDoJCSBJbmRpdmlkdWFs IFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjUNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBSVFAgcmV0cmFuc21pc3Npb24gZm9yIHNvdXJjZS1zcGVjaWZpYw0K ICAgbXVsdGljYXN0IChTU00pIGFyY2hpdGVjdHVyZXMgd2l0aCB1bmljYXN0IGZlZWRiYWNrLiAg UlRQIHBheWxvYWQNCiAgIGZvcm1hdCBmb3IgcmV0cmFuc21pc3Npb25zIGhhcyBiZWVuIGRlZmlu ZWQgaW4gUkZDIDQ1ODgsIHdoZXJlYXMgdGhlDQogICBSVFAgcHJvZmlsZSBhbiBSVFAgcmVjZWl2 ZXIgY291bGQgdXNlIHRvIGlzc3VlIFJUUCBDb250cm9sIFByb3RvY29sDQogICAoUlRDUCkgZmVl ZGJhY2sgbWVzc2FnZXMgYW5kIHRoZSBmb3JtYXQgb2YgdGhlc2UgZmVlZGJhY2sgbWVzc2FnZXMN CiAgIGhhdmUgYmVlbiBkZWZpbmVkIGluIFJGQyA0NTg1LiAgUkZDIDU3NjAgZGVmaW5lcyB0aGUg b3BlcmF0aW9uIGZvcg0KICAgU1NNIGFyY2hpdGVjdHVyZXMgd2l0aCB1bmljYXN0IGZlZWRiYWNr Lg0KDQogICBGaXJzdCwgd2UgZG9jdW1lbnQgcG90ZW50aWFsIGlzc3VlcyB0aGF0IGNvdWxkIGFy aXNlIHdoZW4gcHJvdmlkaW5nIGENCiAgIHJldHJhbnNtaXNzaW9uIHNlcnZpY2UgdXNpbmcgUlRQ IHJldHJhbnNtaXNzaW9uIChSRkMgNDU4OCBhbmQgUkZDDQogICA0NTg1KSBmb3IgUkZDIDU3NjAg YXJjaGl0ZWN0dXJlcyBiYXNlZCBvbiBydWxlcyBkZXNjcmliZWQgaW4gdGhlDQogICByZWxldmFu dCBSRkNzLiAgV2UgdGhlbiBwcmVzZW50IHNvbHV0aW9ucyB0aGF0IGFsbG93IHRvIGF2b2lkDQog ICB1bm5lY2Vzc2FyeSBmZWVkYmFjayBzdXBwcmVzc2lvbiwgcHJvdmlkZSBlbmhhbmNlZCByZXRy YW5zbWlzc2lvbg0KICAgc2VydmljZXMgYW5kIGFkZHJlc3MgY29uZ2VzdGlvbiBjb250cm9sIGZv ciByZXRyYW5zbWlzc2lvbiBpbiBhbiBTU00NCiAgIGVudmlyb25tZW50LiAgVGhlc2Ugc29sdXRp b25zIHNwZWNpZnkgY2VydGFpbiBydWxlcyB0aGF0IGFwcGx5IHRvIHRoZQ0KICAgZGlzdHJpYnV0 aW9uIHNvdXJjZSwgZmVlZGJhY2sgdGFyZ2V0KHMpLCByZXRyYW5zbWlzc2lvbiBzb3VyY2Uocykg YW5kDQogICBSVFAgcmVjZWl2ZXJzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From mpeck@mitre.org Thu May 26 10:26:50 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575B0E073F for ; Thu, 26 May 2011 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5SCHHnSR4su for ; Thu, 26 May 2011 10:26:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C4E0734 for ; Thu, 26 May 2011 10:26:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 777F521B09BB; Thu, 26 May 2011 13:26:46 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 71B2321B01D0; Thu, 26 May 2011 13:26:46 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 26 May 2011 13:26:46 -0400 From: "Peck, Michael A" To: "avt@ietf.org" Date: Thu, 26 May 2011 13:26:45 -0400 Thread-Topic: Suite B Profile for DTLS-SRTP Internet-Draft Thread-Index: AcwbyhYs5zIAleLAQGOjUzSfGjwzCA== Message-ID: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kmigoe@nsa.gov" Subject: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 17:26:50 -0000 Kevin Igoe and I have submitted draft-peck-suiteb-dtls-srtp-00, Suite B Pro= file for Datagram Transport Layer Security / Secure Real-time Transport Pro= tocol (DTLS-SRTP) as an independent submission. We would appreciate any co= mments. http://www.ietf.org/internet-drafts/draft-peck-suiteb-dtls-srtp-00.txt Abstract The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document describes the use of Suite B cryptography with the Datagram Transport Layer Security (DTLS) protocol, the Secure Real-Time Protocol (SRTP), and the Secure Real-Time Control Protocol (SRTCP) to provide a robust architecture for securing real-time data.=20 Thanks, Mike Peck From internet-drafts@ietf.org Thu May 26 19:21:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AAFE0771; Thu, 26 May 2011 19:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7phyy7e2K-0; Thu, 26 May 2011 19:21:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA98E066C; Thu, 26 May 2011 19:21:17 -0700 (PDT) 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: 3.55 Message-ID: <20110527022117.21794.58216.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 19:21:17 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 02:21:18 -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 Core Maintenanc= e Working Group of the IETF. Title : Monitoring Architectures for RTP Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-02.txt Pages : 22 Date : 2011-05-26 This memo proposes an architecture for extending RTCP with a new RTCP XR (RFC3611) block type to report new metrics regarding media transmission or reception quality, as proposed in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt From sunseawq@huawei.com Thu May 26 19:33:10 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29BAE0762; Thu, 26 May 2011 19:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euaKkSkFaMny; Thu, 26 May 2011 19:33:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2155BE075A; Thu, 26 May 2011 19:33:09 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00EXG1QBQL@szxga05-in.huawei.com>; Fri, 27 May 2011 10:32:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00KLX1QAE9@szxga05-in.huawei.com>; Fri, 27 May 2011 10:32:35 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLU00EQN1QA6B@szxml04-in.huawei.com>; Fri, 27 May 2011 10:32:34 +0800 (CST) Date: Fri, 27 May 2011 10:36:45 +0800 From: Qin Wu To: avt@ietf.org, xrblock@ietf.org Message-id: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: magnus.westerlund@ericsson.com Subject: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 02:33:10 -0000 Hi, This version addresses the open issues regarding identity information repetition and acknowledge section. http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02 Comments are welcome! Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Friday, May 27, 2011 10:21 AM Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Monitoring Architectures for RTP > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-02.txt > Pages : 22 > Date : 2011-05-26 > > This memo proposes an architecture for extending RTCP with a new RTCP > XR (RFC3611) block type to report new metrics regarding media > transmission or reception quality, as proposed in RFC5968. This memo > suggests that a new block should contain a single metric or a small > number of metrics relevant to a single parameter of interest or > concern, rather than containing a number of metrics which attempt to > provide full coverage of all those parameters of concern to a > specific application. Applications may then "mix and match" to > create a set of blocks which covers their set of concerns. Where > possible, a specific block should be designed to be re-usable across > more than one application, for example, for all of voice, streaming > audio and video. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From internet-drafts@ietf.org Thu May 26 19:46:45 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE714E0782; Thu, 26 May 2011 19:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XFou5nELUmh; Thu, 26 May 2011 19:46:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412DFE0762; Thu, 26 May 2011 19:46:45 -0700 (PDT) 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: 3.55 Message-ID: <20110527024645.21730.57407.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 19:46:45 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 02:46:46 -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 Core Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-04.txt Pages : 19 Date : 2011-05-26 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are certain cases where it is not possible to forward feedback reports, and this may allow feedback implosion. This memo defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-04.txt From sunseawq@huawei.com Thu May 26 19:56:28 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F86E076E for ; Thu, 26 May 2011 19:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.036 X-Spam-Level: X-Spam-Status: No, score=-4.036 tagged_above=-999 required=5 tests=[AWL=-1.437, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3MRhlvq0boX for ; Thu, 26 May 2011 19:56:27 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 643E7E075A for ; Thu, 26 May 2011 19:56:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00A9S2SQDB@szxga05-in.huawei.com> for avt@ietf.org; Fri, 27 May 2011 10:55:39 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLU00KRM2SQFV@szxga05-in.huawei.com> for avt@ietf.org; Fri, 27 May 2011 10:55:38 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LLU002V32SPEG@szxml06-in.huawei.com> for avt@ietf.org; Fri, 27 May 2011 10:55:38 +0800 (CST) Date: Fri, 27 May 2011 10:59:48 +0800 From: Qin Wu To: avt@ietf.org Message-id: <021501cc1c1a$2453a250$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: magnus.westerlund@ericsson.com Subject: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 02:56:28 -0000 Hi, This new version has just been submitted which clarifies the rules of using third party loss report. http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-04.txt The diff is: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-feedback-supression-rtp-04 Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Friday, May 27, 2011 10:46 AM Subject: I-D Action: draft-ietf-avtcore-feedback-supression-rtp-04.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTCP Extension for Third-party Loss Report > Author(s) : Qin Wu > Frank Xia > Roni Even > Filename : draft-ietf-avtcore-feedback-supression-rtp-04.txt > Pages : 19 > Date : 2011-05-26 > > In a large RTP session using the RTCP feedback mechanism defined in > RFC 4585, a feedback target may experience transient overload if some > event causes a large number of receivers to send feedback at once. > This overload is usually avoided by ensuring that feedback reports > are forwarded to all receivers, allowing them to avoid sending > duplicate feedback reports. However, there are certain cases where > it is not possible to forward feedback reports, and this may allow > feedback implosion. This memo defines a new RTCP third-party loss > report that can be used to inform receivers that a feedback target is > aware of some loss event, allowing them to suppress feedback. > Associated SDP signalling is also defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-04.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hoene@uni-tuebingen.de Fri May 27 22:35:39 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6DE0676 for ; Fri, 27 May 2011 22:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ygMas5Tsxsb for ; Fri, 27 May 2011 22:35:38 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2244CE064A for ; Fri, 27 May 2011 22:35:37 -0700 (PDT) Received: from hoeneT60 (p5B2003CE.dip0.t-ipconnect.de [91.32.3.206]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id p4S5ZKgo021021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 28 May 2011 07:35:27 +0200 From: "Christian Hoene" To: "Jean-Marc Valin" , "'Colin Perkins'" Date: Sat, 28 May 2011 07:35:20 +0200 Organization: =?us-ascii?Q?Universitat_Tubingen?= Message-ID: <000c01cc1cf9$0e6b28c0$2b417a40$@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: Acwc+PbkmpQ0zdyVR6GQ+3LHZNplDQ== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.1.2; host: mx05) Cc: avt@ietf.org, amw@cs.unc.edu Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-srtp-vbr-audio-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2011 05:35:39 -0000 Hi Collin and Jean-Marc, you might want to read http://www.cs.unc.edu/~amw/resources/hooktonfoniks.pdf which confirms your security concerns in respect to variable rate speech coding. With best regards, Christian Hoene > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, April 28, 2011 10:15 AM > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-srtp-vbr-audio-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance > Working Group of the IETF. > > > Title : Guidelines for the use of Variable Bit Rate Audio with > Secure RTP > Author(s) : C. Perkins, J. Valin > Filename : draft-ietf-avtcore-srtp-vbr-audio-02.txt > Pages : 7 > Date : 2011-04-28 > > This memo discusses potential security issues that arise when using > variable bit rate audio with the secure RTP profile. Guidelines to > mitigate these issues are suggested. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-vbr-audio-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From internet-drafts@ietf.org Tue May 31 00:50:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71385E0782; Tue, 31 May 2011 00:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXasJRDZ68qv; Tue, 31 May 2011 00:50:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12750E06DC; Tue, 31 May 2011 00:50:15 -0700 (PDT) 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: 3.55 Message-ID: <20110531075015.28779.24807.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 00:50:15 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 07:50:15 -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 Core Maintenanc= e Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : Magnus Westerlund Ingemar Johansson Colin Perkins Piers O'Hanlon Ken Carlberg Filename : draft-ietf-avtcore-ecn-for-rtp-02.txt Pages : 56 Date : 2011-05-31 This memo specifies how Explicit Congestion Notification (ECN) can be used with Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initilization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initilization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-02.txt From magnus.westerlund@ericsson.com Tue May 31 01:53:14 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48158E0706 for ; Tue, 31 May 2011 01:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.27 X-Spam-Level: X-Spam-Status: No, score=-106.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1vBDB1BVluq for ; Tue, 31 May 2011 01:53:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7054FE06D3 for ; Tue, 31 May 2011 01:53:13 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-2a-4de4ac785047 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 30.54.09774.87CA4ED4; Tue, 31 May 2011 10:53:12 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 31 May 2011 10:53:12 +0200 Message-ID: <4DE4AC77.9050501@ericsson.com> Date: Tue, 31 May 2011 10:53:11 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Peck, Michael A" References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> In-Reply-To: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" , "kmigoe@nsa.gov" Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 08:53:14 -0000 Hi, If I understand this document correctly there are actually three pieces to it: - The SuiteB Crypto algorithms for SRTP - The SuiteB specific DTLS-SRTP procedures - Registration of DTLS-SRTP protection profiles Thus in light of this document and also the ARIA SRTP registration I think we should discuss how to handle SRTP crypto algorithms and their connection to the keying mechanisms. SRTP has at least three different IETF define ways to be keyed: - DTLS-SRTP [RFC5764] - MIKEY [3830] - Security Descriptions [RFC 4568] And to my understanding they are all used somewhere. >From my perspective as WG chair I wonder if shouldn't require anyone that creates a new crypto suit for SRTP to also create the suite profiles / identifiers for all of these three keying mechanisms? Opinions? Secondly, as the part that define the SRTP crypto algorithm needs to go through this WG I would recommend the authors to submit their draft with a new filename that includes avtcore as the second part in the filename, for example as: draft-peck-avtcore-suiteb-dtls-srtp-00.txt Cheers Magnus Westerlund WG Chair On 2011-05-26 19:26, Peck, Michael A wrote: > Kevin Igoe and I have submitted draft-peck-suiteb-dtls-srtp-00, Suite B Profile for Datagram Transport Layer Security / Secure Real-time Transport Protocol (DTLS-SRTP) as an independent submission. We would appreciate any comments. > > http://www.ietf.org/internet-drafts/draft-peck-suiteb-dtls-srtp-00.txt > > Abstract > > The United States government has published guidelines for "NSA Suite > B Cryptography", which defines cryptographic algorithm policy for > national security applications. This document describes the use of > Suite B cryptography with the Datagram Transport Layer Security > (DTLS) protocol, the Secure Real-Time Protocol (SRTP), and the Secure > Real-Time Control Protocol (SRTCP) to provide a robust architecture > for securing real-time data. > > Thanks, > Mike Peck > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 kmigoe@nsa.gov Tue May 31 05:24:55 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F38E0714 for ; Tue, 31 May 2011 05:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFzGFYkURcTP for ; Tue, 31 May 2011 05:24:51 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE8BE06D4 for ; Tue, 31 May 2011 05:24:51 -0700 (PDT) Received: from MSCS-GH1-UEA03.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id p4VCO8rR010019; Tue, 31 May 2011 12:24:08 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA03.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 May 2011 08:24:08 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 31 May 2011 08:24:08 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B19@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <4DE4AC77.9050501@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft Thread-Index: AcwfcC4kJiuhlVKZSjeTuHQ/ihlL6wAG1oEA References: <4FD125153A070D45BC87645D3B880288025A13CACB@IMCMBX3.MITRE.ORG> <4DE4AC77.9050501@ericsson.com> From: "Igoe, Kevin M." To: "Magnus Westerlund" , "Peck, Michael A" X-OriginalArrivalTime: 31 May 2011 12:24:08.0159 (UTC) FILETIME=[A38BA6F0:01CC1F8D] X-Mailman-Approved-At: Tue, 31 May 2011 11:09:07 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 12:24:55 -0000 Magnus: Thanks for your input. We'll put this under avtcore per your request. As to allowing keying methods other than DTLS, we have no objections (obviously) to non-Suite B implementations using them, but in an effort to maximize interoperability betwixt Suite B SRTP implementations policy dictates that only DTLS keying will be allowed in Suite B mode. If another keying methods is used, it is by definition not Suite B = compliant. If you think it would be helpful, we could mention the existence of the = MIKEY=20 and Security description keying mechanisms, but only with the caveat = that their=20 use is forbidden when running in Suite B mode. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, May 31, 2011 4:53 AM > To: Peck, Michael A > Cc: avt@ietf.org; Igoe, Kevin M. > Subject: Re: [AVTCORE] Suite B Profile for DTLS-SRTP Internet-Draft >=20 > Hi, >=20 > If I understand this document correctly there are actually three = pieces > to it: >=20 > - The SuiteB Crypto algorithms for SRTP > - The SuiteB specific DTLS-SRTP procedures > - Registration of DTLS-SRTP protection profiles >=20 > Thus in light of this document and also the ARIA SRTP registration I > think we should discuss how to handle SRTP crypto algorithms and their > connection to the keying mechanisms. >=20 > SRTP has at least three different IETF define ways to be keyed: > - DTLS-SRTP [RFC5764] > - MIKEY [3830] > - Security Descriptions [RFC 4568] >=20 > And to my understanding they are all used somewhere. >=20 > From my perspective as WG chair I wonder if shouldn't require anyone > that creates a new crypto suit for SRTP to also create the suite > profiles / identifiers for all of these three keying mechanisms? >=20 > Opinions? >=20 >=20 > Secondly, as the part that define the SRTP crypto algorithm needs to = go > through this WG I would recommend the authors to submit their draft > with > a new filename that includes avtcore as the second part in the > filename, > for example as: draft-peck-avtcore-suiteb-dtls-srtp-00.txt >=20 > Cheers >=20 > Magnus Westerlund > WG Chair >=20 > On 2011-05-26 19:26, Peck, Michael A wrote: > > Kevin Igoe and I have submitted draft-peck-suiteb-dtls-srtp-00, = Suite > B Profile for Datagram Transport Layer Security / Secure Real-time > Transport Protocol (DTLS-SRTP) as an independent submission. We would > appreciate any comments. > > > > http://www.ietf.org/internet-drafts/draft-peck-suiteb-dtls-srtp- > 00.txt > > > > Abstract > > > > The United States government has published guidelines for "NSA > Suite > > B Cryptography", which defines cryptographic algorithm policy for > > national security applications. This document describes the use > of > > Suite B cryptography with the Datagram Transport Layer Security > > (DTLS) protocol, the Secure Real-Time Protocol (SRTP), and the > Secure > > Real-Time Control Protocol (SRTCP) to provide a robust > architecture > > for securing real-time data. > > > > Thanks, > > Mike Peck > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ----------------------------------------------------------------------