From stewe@stewe.org Fri Apr 1 03:45:26 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554533A67F5; Fri, 1 Apr 2011 03:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q+n+EXsCBEM; Fri, 1 Apr 2011 03:45:25 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0AFF73A67D3; Fri, 1 Apr 2011 03:45:24 -0700 (PDT) Received: from [130.129.83.67] (unverified [130.129.83.67]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4736-1743317 for multiple; Fri, 01 Apr 2011 12:47:03 +0200 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 01 Apr 2011 12:46:58 +0200 From: Stephan Wenger To: , , , Message-ID: Thread-Topic: Incoming liaison statement from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384506822_481335" X-Originating-IP: 130.129.83.67 X-Authenticated-User: stewe@stewe.org Subject: [AVTCORE] Incoming liaison statement from MPEG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 10:45:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384506822_481335 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from the MPEG meeting that took place last week. No action is requested from us. They have an initial draft for the profiles of their HTTP streaming project known as "DASH", which is in DIS state. In short, my reading is that they are currently considering one "simple" and one more complex profile for each MPEG-2 TS and ISO file format based mux structure, for a total of four profiles. The statement should appear on the IETF statement tracker shortly, but if you need a copy urgently, please send me a private email and I will forward. Thanks, Stephan --B_3384506822_481335 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
We have re= ceived a liaison statement from the MPEG meeting that took place last week. =  No action is requested from us.
They have an initial draft f= or the profiles of their HTTP streaming project known as "DASH", which is in= DIS state.  In short, my reading is that they are currently considerin= g one "simple" and one more complex profile for each MPEG-2 TS and ISO file = format based mux structure, for a total of four profiles.  The statemen= t should appear on the IETF statement tracker shortly, but if you need a cop= y urgently, please send me a private email and I will forward.
Tha= nks,
Stephan

--B_3384506822_481335-- From aallison@nab.org Fri Apr 1 09:14:03 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0FB3A68A2 for ; Fri, 1 Apr 2011 09:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv-+5nOl6OLJ for ; Fri, 1 Apr 2011 09:14:02 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by core3.amsl.com (Postfix) with ESMTP id 3B4BF3A6843 for ; Fri, 1 Apr 2011 09:14:01 -0700 (PDT) Received: from unknown [208.97.234.91] by p01c12o145.mxlogic.net(mxl_mta-6.9.0-2) with SMTP id e2af59d4.0.2230.00-388.5231.p01c12o145.mxlogic.net (envelope-from ); Fri, 01 Apr 2011 10:15:43 -0600 (MDT) X-MXL-Hash: 4d95fa2f3c599751-5c893d667183236a91a466de2daad9a187d6468a X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF088.0A01875F" Date: Fri, 1 Apr 2011 12:15:38 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC62202006890518@NABSREX027324.NAB.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Call for adoption of Monitoring Architectures for RTP Thread-Index: AcvvrtUJ76iIa4RoQVagGiMimOHzKAAM4FKQACln+1A= References: <009001cbef62$e1814510$a483cf30$%roni@huawei.com><5803904C-7287-4837-ACB2-3B74B52B93F9@csperkins.org> From: "Allison, Art" To: X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=1.0 c=1 a=k8R7QLe5NuYA:10 a=BLceEmwcHowA:10 a=tFGTPFZixT] X-AnalysisOut: [Z3yCXJchW01Q==:17 a=g0FpLpFZAAAA:8 a=48vgC7mUAAAA:8 a=vQ6d] X-AnalysisOut: [KL7GAAAA:8 a=Xf7j9UMJfMjXpSdESrMA:9 a=GI6SyJyJtazbYRRt3m4A] X-AnalysisOut: [:7 a=CjuIK1q_8ugA:10 a=8SgyfJxrfqYA:10 a=-9UqKSle32gA:10 a] X-AnalysisOut: [=Qd0007q6B0YA:10 a=lZB815dzVvQA:10 a=g2dtFRVzwTwSBCa5:21 a] X-AnalysisOut: [=EmY3AEqXsTosXO69:21 a=SSmOFEACAAAA:8 a=Y2VNeNrzAAAA:8 a=y] X-AnalysisOut: [MhMjlubAAAA:8 a=TW66zc2HAAAA:8 a=HQ31llbKAAAA:8 a=xT7ATutD] X-AnalysisOut: [e8SzRq3faDIA:7 a=bXeqki0SYRoBfwjS:21 a=m2-ujbZEZU3jLEyu:21] Subject: Re: [AVTCORE] Call for adoption of Monitoring Architectures for RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 16:14:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF088.0A01875F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 =20 Art Allison=20 Senior Director Advanced Engineering, Science and Technology=20 National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981=20 www.nab.org =20 Advocacy Education Innovation=20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Colin Perkins Sent: Thursday, March 31, 2011 10:20 AM To: Roni Even Cc: 'Magnus Westerlund'; avt@ietf.org Subject: Re: [AVTCORE] Call for adoption of Monitoring Architectures for RTP =20 I support adopting this document as a starting point for this milestone. =20 Colin =20 =20 On 31 Mar 2011, at 07:16, Roni Even wrote: Hi, AVTCore has a mile stone for February 2011 for Monitoring Architectures for RTP as Informational. =20 There is an individual draft Monitoring Architectures for RTP http://tools.ietf.org/id/draft-hunt-avtcore-monarch-02.txt=20 =20 =20 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. =20 =20 Please respond by Thursday April 14th 2011 with your positions. =20 Roni Even AVTCORE WG co-chair =20 =20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 ------_=_NextPart_001_01CBF088.0A01875F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

Art = Allison
Senior Director Advanced Engineering, Science and = Technology
National Association of Broadcasters
1771 N Street NW
Washington, = DC 20036
Phone  202 429 5418
Fax  202 775 4981

www.nab.org
Advocacy  Education  Innovation

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Colin Perkins
Sent: Thursday, March 31, = 2011 10:20 AM
To: Roni Even
Cc: 'Magnus Westerlund'; avt@ietf.org
Subject: Re: [AVTCORE] = Call for adoption of Monitoring Architectures for = RTP

 

I support adopting this document as a starting point for this milestone.

 

Colin

 

 

On 31 Mar 2011, at 07:16, Roni Even = wrote:

Hi,=

AVTCore has a mile stone for February 2011 for Monitoring Architectures for = RTP as = Informational.=

 =

There is an individual =
draft Monitoring Architectures for RTP  http:=
//tools.ietf.org/id/draft-hunt-avtcore-monarch-02.txt =

 =

 =

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/m= ailman/listinfo/avt

 

 

-- 

Colin Perkins



 

------_=_NextPart_001_01CBF088.0A01875F-- From Even.roni@huawei.com Fri Apr 1 05:10:48 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08BD628C39C; Fri, 1 Apr 2011 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.595 X-Spam-Level: X-Spam-Status: No, score=-100.595 tagged_above=-999 required=5 tests=[AWL=-2.255, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BELOW2=2.154, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0dVFtSOkaJp; Fri, 1 Apr 2011 05:10:34 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7EC1428D97A; Fri, 1 Apr 2011 05:05:58 -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 <0LIZ003V430GXM@szxga05-in.huawei.com>; Fri, 01 Apr 2011 20:07:28 +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 <0LIZ003KE30FWQ@szxga05-in.huawei.com>; Fri, 01 Apr 2011 20:07:28 +0800 (CST) Received: from windows8d787f9 (dhcp-44e0.meeting.ietf.org [130.129.68.224]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIZ00A722ZJ1A@szxml12-in.huawei.com>; Fri, 01 Apr 2011 20:07:26 +0800 (CST) Date: Fri, 01 Apr 2011 15:06:28 +0300 From: Roni Even To: payload@ietf.org, avt@ietf.org Message-id: <002a01cbf065$43b687b0$cb239710$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_t7AtPYrBJKKzLjH+GzWYzw)" Content-language: en-us Thread-index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIpRIcyxQgAB6IDA= X-Mailman-Approved-At: Fri, 01 Apr 2011 11:15:32 -0700 Cc: "'Botzko, Stephen'" , "'Patrick Luthi \(pluthi\)'" Subject: [AVTCORE] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 12:10:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_t7AtPYrBJKKzLjH+GzWYzw) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi, Sorry for the double posting. We found some issues with the text in RFC3984bis which affect also H264RCDO and SVC. The issues were discovered by the RFC editor so we can fix it by doing the changes marked bellow. I would like to start a two weeks WGLC on the text in this email in order to allow enough time for people to review. Please send any comments till April 15th. If there will have no more issues we will submit this changes to the RFC editor as part of the AUTH48. Thanks Roni Even This is the text from YK: Please find below the suggested changes for RFC3984bis with some informative notes added to the semantics of max-cpb, max-dpb, and max-cr. The added notes are all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared to the previous post). These additions should address the specific concerns expressed so far. I hope we can close the issue and let the RFC publication process to proceed. As I said earlier, the changes to the SVC and RCDO payload drafts are very similar. ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. NEW: (The nature of this change as follows. If the semantics remain unchanged while the reference to H.264 spec is the 2010 version, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the 2010 H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change hence there is no backward compatibility issue.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. Informative note: In RFC 3984, which this document obsoletes, the unit of this parameter was 1024 bytes. The unit has been changed to 8/3 macroblocks in this document. This reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition of color formats and bit depths not supported earlier. The changed semantics of this parameter keeps backward compatibility to RFC 3984 and supports all profiles defined in the 2010 version of the H.264 specification. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). . For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial) max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). . For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- Best Regards, Ye-Kui Wang --Boundary_(ID_t7AtPYrBJKKzLjH+GzWYzw) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable

Hi,

Sorry for the double = posting.

We found some issues with the text in RFC3984bis = which affect also H264RCDO and SVC. The issues were discovered by the = RFC editor so we can fix it by doing the changes marked bellow. I would = like to start a two weeks WGLC on the text in this email in order to = allow enough time for people to review.

Please send any comments = till April 15th. If there will have no more issues we will = submit this changes to the RFC editor as part of the = AUTH48.

Thanks

Roni = Even

 

This is the text from = YK:

Please find below the suggested changes for = RFC3984bis with some informative notes added to the semantics of = max-cpb, max-dpb, and max-cr. The added notes are all highlighted in = yellow. There are no other additional changes besides the addition of = these notes (compared to the previous post). These additions should = address the specific concerns expressed so far. I hope we can close the = issue and let the RFC publication process to proceed. =

 

As I said earlier, the = changes to the SVC and RCDO payload drafts are very similar. =

 

------------------------------------Start of = suggested changes = --------------------------------------

 

Section 8.1:

OLD:

      =
profile-level-id:
         A base16 =
[7] (hexadecimal) representation of the =
following
         three =
bytes in the sequence parameter set NAL unit is =
specified
         in [1]: 1) =
profile_idc, 2) a byte herein referred to as
         =
profile-iop, composed of the values of =
constraint_set0_flag,
         =
constraint_set1_flag,constraint_set2_flag,
         =
constraint_set3_flag, and reserved_zero_4bits in =
bit-
         =
significance order, starting from the most-significant bit, =
and
         3) =
level_idc.  Note =
that reserved_zero_4bits is required to be
         equal to 0 =
in [1], but other values for it may be specified =
in
         the future =
by ITU-T or ISO/IEC.

 NEW: (note that the change here = is purely editorial)

      = profile-level-id:

       &nbs= p; A base16 = [7] (hexadecimal) representation of the = following

       &nbs= p; three = bytes in the sequence parameter set NAL unit is = specified

       &nbs= p; in [1]: 1) = profile_idc, 2) a byte herein referred to as

       &nbs= p; = profile-iop, composed of the values of = constraint_set0_flag,

       &nbs= p; = constraint_set1_flag,constraint_set2_flag,

       &nbs= p; = constraint_set3_flag, constraint_set4_flag, = constraint_set5_flag,

 <= /span>and reserved_zero_2bits in bit-significance = order, starting from the most-significant bit, = and

       &nbs= p; 3) = level_idc.  Note that = reserved_zero_2bits is required to be

       &nbs= p; equal to 0 = in [1], but other values for it may be specified = in

         the future by ITU-T or = ISO/IEC.

 

OLD:

         For =
example, in the table above, profile_idc equal to =
58
         (Extended) =
with profile-iop equal to 11xx0000 indicates =
the
         same =
sub-profile corresponding to profile_idc equal to =
42
         (Baseline) =
with profile-iop equal to x1xx0000.  Note that other
         =
combinations of profile_idc and profile-iop (not listed =
in
         Table 5) =
may represent a sub-profile equivalent to the =
common
         subset of =
coding tools for more than one profile.  Note =
also
         that a =
decoder conforming to a certain profile may be able =
to
         decode =
bitstreams conforming to other profiles.  For example, =
a
     &nbs=
p;   =
decoder conforming to the High 4:4:4 profile, at a =
certain
     &nbs=
p;   =
level, must be able to decode bitstreams conforming to =
the
     &nbs=
p;   =
Constrained Baseline, Main, High, High 10, or High =
4:2:2
     &nbs=
p;   =
profile at the same or a lower level.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; For = example, in the table above, profile_idc equal to = 58

       &nbs= p; (Extended) = with profile-iop equal to 11xx0000 indicates the

       &nbs= p; same = sub-profile corresponding to profile_idc equal to = 42

       &nbs= p; (Baseline) = with profile-iop equal to x1xx0000.  Note that = other

       &nbs= p; = combinations of profile_idc and profile-iop (not listed = in

       &nbs= p; Table 5) = may represent a sub-profile equivalent to the = common

       &nbs= p; subset of = coding tools for more than one profile.  Note = also

         that a decoder conforming = to a certain profile may be able to

       &nbs= p; decode = bitstreams conforming to other profiles.

 

OLD:

         If the =
profile-level-id parameter is used for =
capability
         exchange =
or session setup procedure, it =
indicates the subset of
         coding =
tools, which is equal to the default sub-profile, =
that
         the codec =
supports for both receiving and sending.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; If the = profile-level-id parameter is used for = capability

       &nbs= p; exchange = or session setup, it indicates the subset of

       &nbs= p; coding = tools, which is equal to the default sub-profile, = that

       &nbs= p; the codec = supports for both receiving and sending.

 

OLD: =

      max-cpb: The value of = max-cpb is an integer indicating the maximum

       &nbs= p; coded = picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; parameters = (see A.3.1, item i of = [1]) and in units of 1200 bits

       &nbs= p; for the = NAL HRD parameters (see = A.3.1, item j of [1]).

NEW: (note that the change here = is purely editorial)

      max-cpb: The value of = max-cpb is an integer indicating the maximum

       &nbs= p; coded = picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; parameters = and in units of 1200 bits for the NAL HRD parameters.
       &nbs= p; Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

 

OLD:

      max-dpb: The value of = max-dpb is an integer indicating the maximum

       &nbs= p; decoded = picture buffer size in units of 1024 bytes.  The = max-

       &nbs= p; dpb = parameter signals that the receiver has more memory = than

       &nbs= p; the = minimum amount of decoded picture buffer memory required = by

       &nbs= p; the = signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; When = max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; NAL unit = streams that conform to the signaled highest = level,

       &nbs= p; with the = exception that the MaxDPB value in Table A-1 of = [1]

       &nbs= p; for the = signaled highest level is replaced with the value = of

       &nbs= p; = max-dpb.  Consequently, a receiver = that signals max-dpb MUST be

       &nbs= p; capable of = storing the following number of decoded frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; picture = buffer:

 

       &nbs= p;    Min(1024 * max-dpb / ( = PicWidthInMbs * FrameHeightInMbs *

       &nbs= p;    256 * ChromaFormatFactor = ), 16)

 

       &nbs= p; = PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor = are

         defined in = [1].

 

       &nbs= p; The value = of max-dpb MUST be greater than or equal to the = value

       &nbs= p; of MaxDPB = given in Table A-1 of [1] for the highest level.

       &nbs= p; Senders = MAY use this knowledge to construct coded video = streams

       &nbs= p; with = improved compression.

 

       &nbs= p;    Informative note: This = parameter was added primarily to

       &nbs= p;  =   complement a similar = codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture buffer = stores reconstructed samples.  = There

       &nbs= p;    is no relationship = between the size of the decoded picture

       &nbs= p;    buffer and the buffers = used in RTP, especially de-interleaving
 and de-jitter = buffers.

 

NEW: (The nature of this change = as follows. If the semantics remain unchanged while the reference to = H.264 spec  is the 2010 version, then the semantics of max-dpb is = simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are = not found in the 2010 H.264 spec any more. Note that compared to RFC = 3984, the bits on the wire do not change hence there is no backward = compatibility issue.)

      max-dpb: The value of = max-dpb is an integer indicating the maximum

       &nbs= p; decoded = picture buffer size in units of 8/3 = macroblocks.  The = max-

       &nbs= p; dpb = parameter signals that the receiver has more memory = than

       &nbs= p; the = minimum amount of decoded picture buffer memory required = by

       &nbs= p; the = signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; When = max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; NAL unit = streams that conform to the signaled highest = level,

       &nbs= p; with the = exception that the MaxDpbMbs value in = Table A-1 of [1]

 &= nbsp;       for the signaled highest level is replaced with the value = of

 &= nbsp;       max-dpb * 3 / 8.  Consequently, a receiver = that signals max-dpb MUST be

       &nbs= p; capable of = storing the following number of decoded frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; picture = buffer:

 

       &nbs= p;    Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

 &= nbsp;       Wherein PicWidthInMbs and FrameHeightInMbs are defined in = [1].

 

       &nbs= p; The value = of max-dpb MUST be greater than or equal to the = value

       &nbs= p; of MaxDpbMbs * 3 / 8, = wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest level.

       &nbs= p; Senders = MAY use this knowledge to construct coded video = streams

       &nbs= p; with = improved compression.

 

       &nbs= p;    Informative note: This = parameter was added primarily to

       &nbs= p;  =   complement a similar = codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture buffer = stores reconstructed samples.  = There

       &nbs= p;    is no relationship = between the size of the decoded picture

       &nbs= p;    buffer and the buffers = used in RTP, especially de-interleaving
 and de-jitter = buffers.

 

       &nbs= p;    Informative note: In = RFC 3984, which this document obsoletes,

 &= nbsp;          the unit of this parameter was 1024 bytes.  <= /span>The unit has been

 &= nbsp;          changed to 8/3 macroblocks in this document. <= /span> This reason for

 &= nbsp;          this change was due to the changes from the 2003 version of = the

 &= nbsp;          H.264 specification referenced by RFC 3984 to the 2010 = version

 &= nbsp;          of the H.264 specification referenced by this document, = particularly

 &= nbsp;          the changes to Table A-1 in the H.264 specification due to = addition

 &= nbsp;          of color formats and bit depths not supported earlier. =  <= /span>The

 &= nbsp;          changed semantics of this parameter keeps backward =

 &= nbsp;          compatibility to RFC 3984 and supports all profiles defined = in

 &= nbsp;          the 2010 version of the H.264 specification.

 

OLD:

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
(see A.3.1, item i of =
[1]) and in units of 1200 bits
         per second =
for the NAL HRD parameters (see A.3.1, item j =
of
         [1]).
<= pre>        

       &nbs= p; For = example, if a receiver signals capability for Level = 1.2

       &nbs= p; with = max-br equal to 1550, this indicates a maximum = video

       &nbs= p; bitrate of = 1550 kbits/sec for VCL HRD parameters, a maximum

       &nbs= p; video = bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB size of = 4036458 bits (1550000 / 384000 * 1000 * 1000).

NEW: (note that the change here = is purely editorial)

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
and in units of 1200 bits per second for the NAL HRD =
parameters.

       &nbs= p; Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

        

       &nbs= p; For = example, if a receiver signals capability for Main profile = Level 1.2

       &nbs= p; with = max-br equal to 1550, this indicates a maximum = video

       &nbs= p; bitrate of = 1550 kbits/sec for VCL HRD parameters, a maximum

       &nbs= p; video = bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB size of = 4036458 bits (1550000 / 384000 * 1000 * 1000).

 

------------------------------------End of = suggested changes = --------------------------------------

 

Best = Regards,

Ye-Kui Wang

 

 

= --Boundary_(ID_t7AtPYrBJKKzLjH+GzWYzw)-- From gwz@net-zen.net Sun Apr 3 04:15:53 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EE23A67AB for ; Sun, 3 Apr 2011 04:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h65fbf2aG1CE for ; Sun, 3 Apr 2011 04:15:52 -0700 (PDT) Received: from smtpauth23.prod.mesa1.secureserver.net (smtpauth23.prod.mesa1.secureserver.net [64.202.165.47]) by core3.amsl.com (Postfix) with SMTP id B3F513A659C for ; Sun, 3 Apr 2011 04:15:52 -0700 (PDT) Received: (qmail 6227 invoked from network); 3 Apr 2011 11:17:33 -0000 Received: from unknown (124.120.156.204) by smtpauth23.prod.mesa1.secureserver.net (64.202.165.47) with ESMTP; 03 Apr 2011 11:17:32 -0000 Message-ID: <4D985749.7020900@net-zen.net> Date: Sun, 03 Apr 2011 18:17:29 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: avt@ietf.org References: <009001cbef62$e1814510$a483cf30$%roni@huawei.com><5803904C-7287-4837-ACB2-3B74B52B93F9@csperkins.org> <71C9EC0544D1F64D8B7D91EDCC62202006890518@NABSREX027324.NAB.ORG> In-Reply-To: <71C9EC0544D1F64D8B7D91EDCC62202006890518@NABSREX027324.NAB.ORG> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] Call for adoption of Monitoring Architectures for RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2011 11:15:53 -0000 > On 31 Mar 2011, at 07:16, Roni Even wrote: > > Hi, > > AVTCore has a mile stone for February 2011 for Monitoring > Architectures for RTP as Informational. > > > > There is an individual draft Monitoring Architectures for RTP http://tools.ietf.org/id/draft-hunt-avtcore-monarch-02.txt > > > > > > 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 14^th 2011 with your positions. I support this. From Roland.Schott@telekom.de Sun Apr 10 12:15:01 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DBCC3A6953 for ; Sun, 10 Apr 2011 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt3gjWBbo2Cy for ; Sun, 10 Apr 2011 12:15:00 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 264193A68EC for ; Sun, 10 Apr 2011 12:14:58 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 10 Apr 2011 21:14:50 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.34]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Sun, 10 Apr 2011 21:14:49 +0200 From: To: , Date: Sun, 10 Apr 2011 21:14:47 +0200 Thread-Topic: [AVTCORE] Call for adoption of Monitoring Architectures for RTP Thread-Index: AcvvYttZq95ohdRBTkqX9CwqlfqxBQIUElWA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0185AD47AE@HE111648.emea1.cds.t-internal.com> References: <009001cbef62$e1814510$a483cf30$%roni@huawei.com> In-Reply-To: <009001cbef62$e1814510$a483cf30$%roni@huawei.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0185AD47AEHE111648emea1_" MIME-Version: 1.0 Cc: magnus.westerlund@ericsson.com Subject: Re: [AVTCORE] Call for adoption of Monitoring Architectures for RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2011 19:15:01 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0185AD47AEHE111648emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I support adopting this document as an initial starting point for a WG docu= ment. Roland Schott ________________________________ Von: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] Im Auftrag von Roni= Even Gesendet: Donnerstag, 31. M=E4rz 2011 07:17 An: avt@ietf.org Cc: 'Magnus Westerlund' Betreff: [AVTCORE] Call for adoption of Monitoring Architectures for RTP Hi, AVTCore has a mile stone for February 2011 for Monitoring Architectures for= RTP as Informational. There is an individual draft Monitoring Architectures for RTP http://tools= .ietf.org/id/draft-hunt-avtcore-monarch-02.txt Based on the feedback in the AVTcore session in Prague this is a WG call t= o adopt the above text as baseline text for this milestone. This is an init= ial 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 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0185AD47AEHE111648emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

I support=20 adopting=20 this=20 document=20 as an initial=20 starting=20 point=20 for a WG=20 document.

Roland Schott

 


Von: avt-bounces@ietf.org=20 [mailto:avt-bounces@ietf.org] Im Auftrag von Roni=20 Even
Gesendet: Donnerstag, 31. M=E4rz 2011 07:17
An:=20 avt@ietf.org
Cc: 'Magnus Westerlund'
Betreff: [AVTCORE]= Call=20 for adoption of Monitoring Architectures for RTP

Hi,

AVTCore has = a mile=20 stone for February 2011 for Monitoring=20 Architectures for RTP as Informat= ional.=20

 <= /o:p>

There is an individual draft Monitoring Architectures for R=
TP  http://t=
ools.ietf.org/id/draft-hunt-avtcore-monarch-02.txt 

 <= /o:p>

 <= /o:p>

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

 <= /o:p>

 <= /o:p>

Please r= espond=20 by Thursday April 14th  2011 with your positions.=20

 

Roni Even

AVTCORE WG=20 co-chair

 

 

--_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0185AD47AEHE111648emea1_-- From rjesup@wgate.com Tue Apr 12 07:42:18 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C2BDE079E for ; Tue, 12 Apr 2011 07:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG1-XCI+zyVy for ; Tue, 12 Apr 2011 07:42:16 -0700 (PDT) Received: from exchange10.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by ietfc.amsl.com (Postfix) with ESMTP id 95C3DE0705 for ; Tue, 12 Apr 2011 07:42:16 -0700 (PDT) Received: from jesup.eng.wgate.com (10.32.2.26) by exchange10.wgate.com (10.1.1.8) with Microsoft SMTP Server id 14.1.270.1; Tue, 12 Apr 2011 10:42:15 -0400 From: Randell Jesup To: Vikram Bhuskute References: Date: Tue, 12 Apr 2011 10:42:14 -0400 In-Reply-To: (Vikram Bhuskute's message of "Wed, 30 Mar 2011 11:04:18 +0530") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: avt@ietf.org Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:42:18 -0000 [Starting to contribute to AVT again after a *long* work crunch...] >I would like to know if standard puts a barrier on minimum interval required >between a silence (SID) packet and a voice packet. > >Our application is streaming RTP pakcets(G.729 ab coded) ,where voice >packet is followed by SID packets. As I know G.729 is a frame based >codec, here packetization time is 20ms that means voice is played out >at the rate of 20ms. > >The last voice packet before SID packet has less voice data i.e the >payload is less than 20ms,so our application ships out SID packet at >the almost same time, because there is still some space after the last >voice packet to fill in the 20ms frame. The G.729 encoding (as it is 10ms frame-based) can only be a multiple of 10ms. So in your case, the final frame must be 20ms or 10ms. The SID packet would thus begin (have a timestamp corresponding to) either 10 or 20ms (80 or 160 TS units) after the last G.729 packet. >*If we observe packets in wireshark, the time difference between last voice >packet and SID packet is in micro seconds. If this is transmission time in wireshark, that's fine. >**And that is creating problem at our customer place.* It shouldn't (if that's the issue, and you didn't mess up the TS values). >Is microsecond interval unacceptable ? . >I guess this is expected behavior Please comment. My guess is that you didn't set the timestamp values for the SID packet correctly. Alternatively, if you used a 10ms packet correctly, the receiver may not expect a change in 'ptime' (number of frames/packet). I'd recommend avoiding playing with ptime and encode the final talkspurt as 20ms even if it ends in the first 10ms. >I saw RFC 3551 section on G.729, it talks about 10 and 20 ms frames but dose >not talk about minimum interval. Easily found for google. Also: http://en.wikipedia.org/wiki/G.729 -- Randell Jesup, Worldgate (developers of the Ojo videophone) rjesup@wgate.com From rjesup@wgate.com Tue Apr 12 07:54:56 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74AEAE07EF for ; Tue, 12 Apr 2011 07:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idhcRvwoEOcy for ; Tue, 12 Apr 2011 07:54:55 -0700 (PDT) Received: from exchange10.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by ietfc.amsl.com (Postfix) with ESMTP id 86A6CE07DE for ; Tue, 12 Apr 2011 07:54:55 -0700 (PDT) Received: from jesup.eng.wgate.com (10.32.2.26) by exchange10.wgate.com (10.1.1.8) with Microsoft SMTP Server id 14.1.270.1; Tue, 12 Apr 2011 10:54:55 -0400 From: Randell Jesup To: Roni Even References: <021201cbefc3$a753f6b0$f5fbe410$%roni@huawei.com> <006f01cbf02b$0de65550$29b2fff0$%roni@huawei.com> Date: Tue, 12 Apr 2011 10:54:53 -0400 In-Reply-To: <006f01cbf02b$0de65550$29b2fff0$%roni@huawei.com> (Roni Even's message of "Fri, 1 Apr 2011 08:09:47 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: avt@ietf.org Subject: Re: [AVTCORE] Synchronization source for synchronizing stream changes? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 14:54:56 -0000 >> From: skillzero@gmail.com [mailto:skillzero@gmail.com] >> A separate ID in the payload can work. I was just thinking to reuse >> the SSRC since I'm not using it for anything else (and it seemed like >> this could be viewed as another synchronizing source becoming active). >> Using an ID in the payload also means I won't be able to use standard >> payload formats, unless they already have a ID in their specification. >Hi, >If it is a specific payload then the information can be in the payload headers or in some payload specific structure. >For general case look at rtp header extensions in rfc3550 and rfc5285 >Roni I agree with Roni: for your use-case, given using standard codecs and packetizations (H.263/264/etc), providing additional information that needs to be synchronized with the data stream on a frame-by-frame basis is best done through a header extension (if you want any level of compliance with the standards). This has the advantage that if you try to decode this with something that doesn't know your scheme it should just work. It's also more easily extendable than changing an SSRC (which normally has multiple other possible sources). If the bandwidth is an issue (hdr ext's don't use much) you could use some type of handshake over RTCP APP messages (or other back-channel) to indicate that notification of the 'new' state (rotation, etc) has been received and the sender can stop adding them. -- Randell Jesup, Worldgate (developers of the Ojo videophone) rjesup@wgate.com From kpfleming@digium.com Tue Apr 12 09:37:22 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BBF08E07C8 for ; Tue, 12 Apr 2011 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jkPUuWcQ19v for ; Tue, 12 Apr 2011 09:37:20 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfc.amsl.com (Postfix) with ESMTP id 3EDD8E07D8 for ; Tue, 12 Apr 2011 09:37:20 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Q9gad-00052R-1e for avt@ietf.org; Tue, 12 Apr 2011 11:37:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 0DB24D82A2 for ; Tue, 12 Apr 2011 11:37:19 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvfg8Sq8DdP1 for ; Tue, 12 Apr 2011 11:37:18 -0500 (CDT) Received: from [132.177.252.57] (unknown [132.177.252.57]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 7DFE6D82A0 for ; Tue, 12 Apr 2011 11:37:18 -0500 (CDT) Message-ID: <4DA47FBD.4080008@digium.com> Date: Tue, 12 Apr 2011 11:37:17 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: avt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet 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, 12 Apr 2011 16:37:22 -0000 On 04/12/2011 09:42 AM, Randell Jesup wrote: > My guess is that you didn't set the timestamp values for the SID packet > correctly. Alternatively, if you used a 10ms packet correctly, the > receiver may not expect a change in 'ptime' (number of frames/packet). > I'd recommend avoiding playing with ptime and encode the final talkspurt > as 20ms even if it ends in the first 10ms. Unless I am mistaken, the 'final talkspurt' packet can contain a 10ms G.729 audio frame followed by a 10ms G.729 SID frame (resulting in 12 bytes of G.729 payload). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From steveu@coppice.org Tue Apr 12 09:48:59 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DF40CE0800 for ; Tue, 12 Apr 2011 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij6PdGoz7TdH for ; Tue, 12 Apr 2011 09:48:58 -0700 (PDT) Received: from hanghau.pacific.net.hk (hanghau.pacific.net.hk [202.64.33.147]) by ietfc.amsl.com (Postfix) with ESMTP id 04BB1E07A0 for ; Tue, 12 Apr 2011 09:48:57 -0700 (PDT) Received: from i7.coppice.org (9.160.232.220.dyn.pacific.net.hk [220.232.160.9]) by hanghau.pacific.net.hk with ESMTP id p3CGmp7Q032737 for ; Wed, 13 Apr 2011 00:48:52 +0800 Message-ID: <4DA48272.7000408@coppice.org> Date: Wed, 13 Apr 2011 00:48:50 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.38.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: avt@ietf.org References: <4DA47FBD.4080008@digium.com> In-Reply-To: <4DA47FBD.4080008@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet 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, 12 Apr 2011 16:49:00 -0000 On 04/13/2011 12:37 AM, Kevin P. Fleming wrote: > On 04/12/2011 09:42 AM, Randell Jesup wrote: > >> My guess is that you didn't set the timestamp values for the SID packet >> correctly. Alternatively, if you used a 10ms packet correctly, the >> receiver may not expect a change in 'ptime' (number of frames/packet). >> I'd recommend avoiding playing with ptime and encode the final talkspurt >> as 20ms even if it ends in the first 10ms. > > Unless I am mistaken, the 'final talkspurt' packet can contain a 10ms > G.729 audio frame followed by a 10ms G.729 SID frame (resulting in 12 > bytes of G.729 payload). > Correct. The G.729 codec normally decides when to send SID, so it could be the first or the second frame of a 20ms ptime packet. The vagueness in the spec is that G.729 could potentially go speech SID speech SID speech on successive frames. You must end the RTP packet in the 2 byte SID frame, so you have to be prepared to send single frame packets. If ptime is maybe 40ms you could actually speed up the packet rate if there is rapid alternation between voice and SID. That sounds like a potential short term bandwidth issue, which I never figured out how to address well. Steve From kpfleming@digium.com Tue Apr 12 11:26:21 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7B2DE083C for ; Tue, 12 Apr 2011 11:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1U9Ut9jDEch for ; Tue, 12 Apr 2011 11:26:20 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfc.amsl.com (Postfix) with ESMTP id BCB22E0835 for ; Tue, 12 Apr 2011 11:26:20 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Q9iI7-0006nv-MH for avt@ietf.org; Tue, 12 Apr 2011 13:26:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id AECB9D82A1 for ; Tue, 12 Apr 2011 13:26:19 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofq0qcf90hfm for ; Tue, 12 Apr 2011 13:26:19 -0500 (CDT) Received: from [132.177.252.57] (unknown [132.177.252.57]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 30CFBD82A0 for ; Tue, 12 Apr 2011 13:26:19 -0500 (CDT) Message-ID: <4DA4994A.1070206@digium.com> Date: Tue, 12 Apr 2011 13:26:18 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: avt@ietf.org References: <4DA47FBD.4080008@digium.com> <4DA48272.7000408@coppice.org> In-Reply-To: <4DA48272.7000408@coppice.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet 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, 12 Apr 2011 18:26:21 -0000 On 04/12/2011 11:48 AM, Steve Underwood wrote: > On 04/13/2011 12:37 AM, Kevin P. Fleming wrote: >> On 04/12/2011 09:42 AM, Randell Jesup wrote: >> >>> My guess is that you didn't set the timestamp values for the SID packet >>> correctly. Alternatively, if you used a 10ms packet correctly, the >>> receiver may not expect a change in 'ptime' (number of frames/packet). >>> I'd recommend avoiding playing with ptime and encode the final talkspurt >>> as 20ms even if it ends in the first 10ms. >> >> Unless I am mistaken, the 'final talkspurt' packet can contain a 10ms >> G.729 audio frame followed by a 10ms G.729 SID frame (resulting in 12 >> bytes of G.729 payload). >> > Correct. The G.729 codec normally decides when to send SID, so it could > be the first or the second frame of a 20ms ptime packet. The vagueness > in the spec is that G.729 could potentially go speech SID speech SID > speech on successive frames. You must end the RTP packet in the 2 byte > SID frame, so you have to be prepared to send single frame packets. If > ptime is maybe 40ms you could actually speed up the packet rate if there > is rapid alternation between voice and SID. That sounds like a potential > short term bandwidth issue, which I never figured out how to address well. And it seems to defeat the purpose of using SID in the first place :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From carsten.waitzmann@alcatel-lucent.com Tue Apr 12 08:44:03 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 17EFDE07B2 for ; Tue, 12 Apr 2011 08:44:03 -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_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KctGoeoOHVkO for ; Tue, 12 Apr 2011 08:44:02 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfc.amsl.com (Postfix) with ESMTP id F3EC3E07A0 for ; Tue, 12 Apr 2011 08:44:01 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3CFhc6m012761 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 12 Apr 2011 17:43:59 +0200 Received: from [149.204.68.180] (135.120.57.7) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 12 Apr 2011 17:43:59 +0200 Message-ID: <4DA4733B.6010901@alcatel-lucent.com> Date: Tue, 12 Apr 2011 17:43:55 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Wed, 13 Apr 2011 08:07:35 -0700 Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet 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, 12 Apr 2011 15:44:03 -0000 Hello Randell, I think that at least only concern here is that if the two RTP packets (10ms voice, SID) contain the correct RTP TSs (80 TS units difference), but are being sent out almost at the same time ("the time difference between last voice packet and SID packet is in micro seconds"), the far-end jitter measurement will be impacted - right? Agree that this potential issue can be avoided as you suggested below: "encode the final talkspurt as 20ms even if it ends in the first 10ms." thanks Carsten On 12.04.2011 16:42, Randell Jesup wrote: > [Starting to contribute to AVT again after a *long* work crunch...] > >> I would like to know if standard puts a barrier on minimum interval required >> between a silence (SID) packet and a voice packet. >> >> Our application is streaming RTP pakcets(G.729 ab coded) ,where voice >> packet is followed by SID packets. As I know G.729 is a frame based >> codec, here packetization time is 20ms that means voice is played out >> at the rate of 20ms. >> >> The last voice packet before SID packet has less voice data i.e the >> payload is less than 20ms,so our application ships out SID packet at >> the almost same time, because there is still some space after the last >> voice packet to fill in the 20ms frame. > The G.729 encoding (as it is 10ms frame-based) can only be a multiple of > 10ms. So in your case, the final frame must be 20ms or 10ms. The SID > packet would thus begin (have a timestamp corresponding to) either 10 or > 20ms (80 or 160 TS units) after the last G.729 packet. > >> *If we observe packets in wireshark, the time difference between last voice >> packet and SID packet is in micro seconds. > If this is transmission time in wireshark, that's fine. > >> **And that is creating problem at our customer place.* > It shouldn't (if that's the issue, and you didn't mess up the TS > values). > >> Is microsecond interval unacceptable ? . >> I guess this is expected behavior Please comment. > My guess is that you didn't set the timestamp values for the SID packet > correctly. Alternatively, if you used a 10ms packet correctly, the > receiver may not expect a change in 'ptime' (number of frames/packet). > I'd recommend avoiding playing with ptime and encode the final talkspurt > as 20ms even if it ends in the first 10ms. > >> I saw RFC 3551 section on G.729, it talks about 10 and 20 ms frames but dose >> not talk about minimum interval. > Easily found for google. Also: > http://en.wikipedia.org/wiki/G.729 > -- Alcatel-Lucent Deutschland AG Sitz der Gesellschaft: Stuttgart · Amtsgericht Stuttgart HRB 4026 Vorsitzender des Aufsichtsrates: Michael Oppenhoff Vorstand: Alf Henryk Wulf (Vorsitzender) · Dr. Rainer Fechner · Peter Kury From abegen@cisco.com Thu Apr 14 04:37:23 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 819BBE06CA for ; Thu, 14 Apr 2011 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.592 X-Spam-Level: X-Spam-Status: No, score=-10.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WoUdSWlvNX6 for ; Thu, 14 Apr 2011 04:37:22 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 84268E0692 for ; Thu, 14 Apr 2011 04:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1383; q=dns/txt; s=iport; t=1302781042; x=1303990642; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=ivEYNZ2l6195YyTtjJaMfWIreRBrlnxYvYaqiMq4uo8=; b=dDrtG0fgn3DV4q9zcP/gRJ+Oa7BHRPpjyAAN5xVeqJzAEWSwe6e43aoz oZifrF2CuhX4101pTRWbmv+IZV6RP/WX9MR2qdQ5cKy4u+hRJ1aNZ9X8W VV1sVdKZPYYcQ/LKMFiWBKOqYcTSLdsHiDGgmxRS+EF81E4c5DR/7F6L+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYHALzbpk2rRDoH/2dsb2JhbACYOI09d6RqnHiFbgSFWowP X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="337116929" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 11:37:22 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3EBbMiY024889 for ; Thu, 14 Apr 2011 11:37:22 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); Thu, 14 Apr 2011 04:37:22 -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-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 04:36:27 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed text for draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 Thread-Index: Acv6l7xRHFcqN2HUTcW9XdLR65tZUA== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 14 Apr 2011 11:37:22.0062 (UTC) FILETIME=[5190FAE0:01CBFA98] Subject: [AVTCORE] Proposed text for draft-ietf-avtcore-ports-for-ucast-mcast-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, 14 Apr 2011 11:37:23 -0000 Based on a comment from IESG, we would like to propose the following = change to the Token draft. It is about increasing the length of the = Tokens. Currently, the length field is 1 byte, IESG recommends 2 bytes = with a warning sign. Please let us know if you do not want this change.=20 Link to the draft: = https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast= -rtp/?include_text=3D1 -acbegen New text for 4.2 Token Element (Variable size): Element that is used to carry the Token = generated by the server. This element is a 32-bit aligned Length-Value = element. The Length field, which is 16 bits, indicates the length (in = octets) of the Value field that follows the Length field. While a 16-bit = length allows for Tokens with a size of up to 65535 bytes, using Tokens = larger than 1000 bytes is generally a bad idea since this can easily = cause IP fragmentation. Note that a Token has to be transmitted in an = RTCP compound packet within a UDP packet, which often has an MTU of 1500 = bytes. =20 The length does not include any padding that is required for alignment. = The Value field carries the Token (or more accurately, the output of the = encoding process on the server). If the Token element does not fall on a = 32-bit boundary, the last word MUST be padded to the boundary using = further bits set to zero. From vikramb11@gmail.com Thu Apr 14 04:57:41 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C41BE06B1 for ; Thu, 14 Apr 2011 04:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fesSDJFVTxqQ for ; Thu, 14 Apr 2011 04:57:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfc.amsl.com (Postfix) with ESMTP id 25CA0E069F for ; Thu, 14 Apr 2011 04:57:41 -0700 (PDT) Received: by yic13 with SMTP id 13so837269yic.31 for ; Thu, 14 Apr 2011 04:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=VoEGudh0a0kqph52TDdZWA1GD3bWYdtUkG+XEeeQY9U=; b=vpO9byO/Q9fFfEdOLIu78lLNmzwJFyG0htcCWInvKRqWfysJFgIZE+WZMEe3vJSlnx OfyBDPaVKCpDTx/A1la+y0uc0OBkBcNAZLoCsQnYwhVyRbPqBN/wIeNOc5eGGj63S/hO nfeg6WEXKreODskh5YnakmgRPMsXivMOrb+CY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bEPRhiqrGFKD5tLz2fiBb6NTUizG99vfhkeMoAn4DfDXb7oxBWZMjOguzFOz02ESnS M5AMkg/3CffsMUJ01V0hYhPw2uY5UE1BsSUznE0iPL9B38p1ut9rz5Sogxmw5kXX6rha sJGEZwaq2S6YN3rm/Fzaqg5jisqExCFPgVppM= MIME-Version: 1.0 Received: by 10.91.16.27 with SMTP id t27mr1504339agi.72.1302782260745; Thu, 14 Apr 2011 04:57:40 -0700 (PDT) Received: by 10.90.120.6 with HTTP; Thu, 14 Apr 2011 04:57:40 -0700 (PDT) In-Reply-To: <4DA4733B.6010901@alcatel-lucent.com> References: <4DA4733B.6010901@alcatel-lucent.com> Date: Thu, 14 Apr 2011 17:27:40 +0530 Message-ID: From: Vikram Bhuskute To: avt@ietf.org Content-Type: multipart/alternative; boundary=0016363b8276df145504a0dfa11f Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet 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, 14 Apr 2011 11:57:41 -0000 --0016363b8276df145504a0dfa11f Content-Type: text/plain; charset=ISO-8859-1 Hi Randell, Thanks for the help. We are rightly setting the Timestamp. Regards, Vikram --0016363b8276df145504a0dfa11f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Randell,

Thanks for the help. We are rightly setting the Timestam= p.

Regards,
Vikram
=A0
--0016363b8276df145504a0dfa11f-- From magnus.westerlund@ericsson.com Thu Apr 14 05:02:28 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CBB4E06BA for ; Thu, 14 Apr 2011 05:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.547 X-Spam-Level: X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXaWoteELcPe for ; Thu, 14 Apr 2011 05:02:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 1858CE06B0 for ; Thu, 14 Apr 2011 05:02:26 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-59-4da6e252db2c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 92.36.09202.252E6AD4; Thu, 14 Apr 2011 14:02:26 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 14 Apr 2011 14:02:26 +0200 Message-ID: <4DA6E251.7020605@ericsson.com> Date: Thu, 14 Apr 2011 14:02:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: avt@ietf.org References: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] Proposed text for draft-ietf-avtcore-ports-for-ucast-mcast-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, 14 Apr 2011 12:02:28 -0000 Hi, I suggest the first paragraph is changed to: Token Element (Variable size): Element that is used to carry the Token generated by the server. This element is a 32-bit aligned Length-Value element. The Length field, which is 16 bits, indicates the length (in octets) of the Value field that follows the Length field. While a 16-bit length allows for Tokens with a size of up to 65535 bytes, using Tokens of sizes that make the RTCP compound packet larger than the MTU might have a negative impact on functionality because of IP fragmentation. Some NATs or other middleboxes do not pass IP fragments, thus a large Token can cause the whole mechanism to fail. In addition, fragmentation increases the risk for packet loss. Cheers Magnus Ali C. Begen (abegen) skrev 2011-04-14 13:36: > Based on a comment from IESG, we would like to propose the following > change to the Token draft. It is about increasing the length of the > Tokens. Currently, the length field is 1 byte, IESG recommends 2 > bytes with a warning sign. > > Please let us know if you do not want this change. Link to the draft: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/?include_text=1 > > -acbegen > > New text for 4.2 > > Token Element (Variable size): Element that is used to carry the > Token generated by the server. This element is a 32-bit aligned > Length-Value element. The Length field, which is 16 bits, indicates > the length (in octets) of the Value field that follows the Length > field. While a 16-bit length allows for Tokens with a size of up to > 65535 bytes, using Tokens larger than 1000 bytes is generally a bad > idea since this can easily cause IP fragmentation. Note that a Token > has to be transmitted in an RTCP compound packet within a UDP packet, > which often has an MTU of 1500 bytes. > > The length does not include any padding that is required for > alignment. The Value field carries the Token (or more accurately, the > output of the encoding process on the server). If the Token element > does not fall on a 32-bit boundary, the last word MUST be padded to > the boundary using further bits set to zero. > _______________________________________________ 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 abegen@cisco.com Thu Apr 14 05:05:52 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9545BE06E4 for ; Thu, 14 Apr 2011 05:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2PglnVNIvzW for ; Thu, 14 Apr 2011 05:05:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9314BE06B0 for ; Thu, 14 Apr 2011 05:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3466; q=dns/txt; s=iport; t=1302782751; x=1303992351; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ejV3KuX4rGqYZZm0BU2HQWmV5p4oNZTPB8k28VplYso=; b=Z/jah4JaRs7UBTG4SzwBR7QqYiY/triXqUKHUdVP/rpzasc7MjqqhTzq p2XNhr3ilouuWPepxErc+XUKCi0s10GY4QM6L8PAMOr0531yrQP2SwfCL MsyaprtO/nXZKhOn6JCUQz1kYLOWAHV6n1/3eBmI8Ff63PK4HHh6IHZO0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBAPXhpk2rRDoH/2dsb2JhbACXeY18d6RonHcChWwEhVqMDw X-IronPort-AV: E=Sophos;i="4.64,211,1301875200"; d="scan'208";a="429812868" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2011 12:05:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3EC5oeh020516; Thu, 14 Apr 2011 12:05:50 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 05:05:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 05:04:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1028@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4DA6E251.7020605@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Proposed textfor draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 Thread-Index: Acv6m92BMkRR28HvThuc3KlQhaeH9gAAEjsg References: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> <4DA6E251.7020605@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 14 Apr 2011 12:05:50.0722 (UTC) FILETIME=[4C01CE20:01CBFA9C] Subject: Re: [AVTCORE] Proposed textfor draft-ietf-avtcore-ports-for-ucast-mcast-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, 14 Apr 2011 12:05:52 -0000 Even better, thanks. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Thursday, April 14, 2011 8:02 AM > To: avt@ietf.org > Subject: Re: [AVTCORE] Proposed textfor = draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 >=20 > Hi, >=20 > I suggest the first paragraph is changed to: >=20 > Token Element (Variable size): Element that is used to carry the Token > generated by the server. This element is a 32-bit aligned Length-Value > element. The Length field, which is 16 bits, indicates the length (in > octets) of the Value field that follows the Length field. While a = 16-bit > length allows for Tokens with a size of up to 65535 bytes, using = Tokens > of sizes that make the RTCP compound packet larger than the MTU might > have a negative impact on functionality because of IP fragmentation. > Some NATs or other middleboxes do not pass IP fragments, thus a large > Token can cause the whole mechanism to fail. In addition, = fragmentation > increases the risk for packet loss. >=20 > Cheers >=20 > Magnus >=20 > Ali C. Begen (abegen) skrev 2011-04-14 13:36: > > Based on a comment from IESG, we would like to propose the following > > change to the Token draft. It is about increasing the length of the > > Tokens. Currently, the length field is 1 byte, IESG recommends 2 > > bytes with a warning sign. > > > > Please let us know if you do not want this change. Link to the = draft: > > = https://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast= -rtp/?include_text=3D1 > > > > -acbegen > > > > New text for 4.2 > > > > Token Element (Variable size): Element that is used to carry the > > Token generated by the server. This element is a 32-bit aligned > > Length-Value element. The Length field, which is 16 bits, indicates > > the length (in octets) of the Value field that follows the Length > > field. While a 16-bit length allows for Tokens with a size of up to > > 65535 bytes, using Tokens larger than 1000 bytes is generally a bad > > idea since this can easily cause IP fragmentation. Note that a Token > > has to be transmitted in an RTCP compound packet within a UDP = packet, > > which often has an MTU of 1500 bytes. > > > > The length does not include any padding that is required for > > alignment. The Value field carries the Token (or more accurately, = the > > output of the encoding process on the server). If the Token element > > does not fall on a 32-bit boundary, the last word MUST be padded to > > the boundary using further bits set to zero. > > _______________________________________________ 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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From gwz@net-zen.net Thu Apr 14 05:15:36 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 94962E08BE for ; Thu, 14 Apr 2011 05:15:36 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYvnIz2qltjI for ; Thu, 14 Apr 2011 05:15:36 -0700 (PDT) Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by ietfc.amsl.com (Postfix) with SMTP id E7F1FE0700 for ; Thu, 14 Apr 2011 05:15:35 -0700 (PDT) Received: (qmail 12146 invoked from network); 14 Apr 2011 12:15:34 -0000 Received: from unknown (110.168.101.239) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 14 Apr 2011 12:15:33 -0000 Message-ID: <4DA6E560.8060702@net-zen.net> Date: Thu, 14 Apr 2011 19:15:28 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540ECB1024@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------070803000008090205020005" Cc: avt@ietf.org Subject: Re: [AVTCORE] Proposed text for draft-ietf-avtcore-ports-for-ucast-mcast-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, 14 Apr 2011 12:15:36 -0000 This is a multi-part message in MIME format. --------------070803000008090205020005 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/14/2011 6:36 PM, Ali C. Begen (abegen) wrote: ,,, > While a 16-bit length allows for Tokens with a size of up to 65535 bytes, using Tokens larger than 1000 bytes is generally a bad idea since this can easily cause IP fragmentation. Note that a Token has to be transmitted in an RTCP compound packet within a UDP packet, which often has an MTU of 1500 bytes. How bad of an idea is it? SHOULD NOT? MUST NOT? Whatever? ... --------------070803000008090205020005 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 --------------070803000008090205020005-- From wwwrun@rfc-editor.org Thu Apr 14 11:26:26 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6154DE08E7; Thu, 14 Apr 2011 11:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbI0aADQSlDO; Thu, 14 Apr 2011 11:26:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfc.amsl.com (Postfix) with ESMTP id ED7FAE08E4; Thu, 14 Apr 2011 11:26:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7A763E0781; Thu, 14 Apr 2011 11:26:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110414182624.7A763E0781@rfc-editor.org> Date: Thu, 14 Apr 2011 11:26:24 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6222 on Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) 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, 14 Apr 2011 18:26:26 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6222 Title: Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) Author: A. Begen, C. Perkins, D. Wing Status: Standards Track Stream: IETF Date: April 2011 Mailbox: abegen@cisco.com, csp@csperkins.org, dwing@cisco.com Pages: 9 Characters: 20393 Updates: RFC3550 I-D Tag: draft-ietf-avt-rtp-cnames-05.txt URL: http://www.rfc-editor.org/rfc/rfc6222.txt The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs. [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 Even.roni@huawei.com Fri Apr 15 00:17:18 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8081DE077C for ; Fri, 15 Apr 2011 00:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=3.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU06lEwPQTmC for ; Fri, 15 Apr 2011 00:17:17 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 55839E0752 for ; Fri, 15 Apr 2011 00:16:46 -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 <0LJO003MJMRVKW@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 Apr 2011 15:14:20 +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 <0LJO00DQ9MRVKN@szxga03-in.huawei.com> for avt@ietf.org; Fri, 15 Apr 2011 15:14:19 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-50.red.bezeqint.net [79.178.14.50]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJO009JNMROJB@szxml11-in.huawei.com>; Fri, 15 Apr 2011 15:14:19 +0800 (CST) Date: Fri, 15 Apr 2011 10:13:30 +0300 From: Roni Even To: 'Jonathan Lennox' Message-id: <013b01cbfb3c$a442ec90$ecc8c5b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HoxEYdUX+PNM8xhrtQPoJQ)" Content-language: en-us Thread-index: Acv7PJ7E1Q5InS97Ts6Xs2hj52yM/A== Cc: 'Magnus Westerlund' , avt@ietf.org Subject: [AVTCORE] Accepting draft-lennox-avtcore-srtp-encrypted-header-ext-00 as a WG document 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, 15 Apr 2011 07:17:18 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HoxEYdUX+PNM8xhrtQPoJQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Jonathan, Since there were no objections or other proposals, please submit draft-lennox-avtcore-srtp-encrypted-header-ext-00 as an AVTcore WG document "draft-ietf-avtcore-srtp-encrypted-header-ext-00" Thanks Roni Even AVTcore co-chair --Boundary_(ID_HoxEYdUX+PNM8xhrtQPoJQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Jonathan,

Since there were no objections or other proposals, please submit draft-lennox-avtcore-srtp-encrypted-header-ext-00 as an AVTcore WG document  "draft-ietf-avtcore-srtp-encrypted-header-ext-00"

Thanks
Roni Even
AVTcore co-chair
 
 

 

 

--Boundary_(ID_HoxEYdUX+PNM8xhrtQPoJQ)-- From rjesup@wgate.com Fri Apr 15 01:16:56 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A0741E06E3 for ; Fri, 15 Apr 2011 01:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAuDmcyWh-hH for ; Fri, 15 Apr 2011 01:16:56 -0700 (PDT) Received: from exchange10.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by ietfc.amsl.com (Postfix) with ESMTP id 0ADABE065A for ; Fri, 15 Apr 2011 01:16:56 -0700 (PDT) Received: from jesup.eng.wgate.com (10.32.2.26) by exchange10.wgate.com (10.1.1.8) with Microsoft SMTP Server id 14.1.270.1; Fri, 15 Apr 2011 04:16:54 -0400 From: Randell Jesup To: Carsten Waitzmann References: <4DA4733B.6010901@alcatel-lucent.com> Date: Fri, 15 Apr 2011 04:16:53 -0400 In-Reply-To: <4DA4733B.6010901@alcatel-lucent.com> (Carsten Waitzmann's message of "Tue, 12 Apr 2011 17:43:55 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: avt@ietf.org Subject: Re: [AVTCORE] G729 RTP Min. interval between Voice and SID packet X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randell Jesup List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:16:56 -0000 >Hello Randell, > >I think that at least only concern here is that if the two RTP packets >(10ms voice, SID) contain the correct RTP TSs (80 TS units difference), >but are being sent out almost at the same time ("the time difference >between last voice packet and SID packet is in micro seconds"), the >far-end jitter measurement will be impacted - right? Yes - if you care. You probably shouldn't. The jitter measurement as defined is of limited use to begin with. (Duplicate packets from the network throws it off, etc.) -- Randell Jesup, Worldgate (developers of the Ojo videophone) rjesup@wgate.com From Internet-Drafts@ietf.org Fri Apr 15 03:00:02 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 59AB5E070E; Fri, 15 Apr 2011 03:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw32s5Z5nMj6; Fri, 15 Apr 2011 03:00:01 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C2288E065A; Fri, 15 Apr 2011 03:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415100001.27918.64781.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 03:00:01 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-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: Fri, 15 Apr 2011 10:00:02 -0000 --NextPart 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 Feedback Suppression Indication Author(s) : W. Wu, et al. Filename : draft-ietf-avtcore-feedback-supression-rtp-01.txt Pages : 17 Date : 2011-04-15 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 extensions 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-01.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-feedback-supression-rtp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-15025205.I-D@ietf.org> --NextPart-- From sunseawq@huawei.com Fri Apr 15 03:04:36 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1FFB2E07A9 for ; Fri, 15 Apr 2011 03:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=3.072, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR-wJCKcQyOR for ; Fri, 15 Apr 2011 03:04:35 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 9F2F5E065A for ; Fri, 15 Apr 2011 03:04:34 -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 <0LJO00GNMUL3PE@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Apr 2011 18:03:04 +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 <0LJO00F9MUL39H@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Apr 2011 18:03:03 +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 <0LJO00HEXUL3C2@szxml04-in.huawei.com> for avt@ietf.org; Fri, 15 Apr 2011 18:03:03 +0800 (CST) Date: Fri, 15 Apr 2011 18:05:53 +0800 From: Qin Wu To: avt@ietf.org Message-id: <03fa01cbfb54$b52f1f20$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_JqI8j4EHb8QGMRK3Ds99bw)" X-Priority: 3 X-MSMail-priority: Normal Cc: magnus.westerlund@ericsson.com Subject: [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, 15 Apr 2011 10:04:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JqI8j4EHb8QGMRK3Ds99bw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT 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. Regards! -Qin ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: ; Sent: Friday, April 15, 2011 5:52 PM Subject: New Version Notification for draft-ietf-avtcore-feedback-supression-rtp-01 > > A new version of I-D, draft-ietf-avtcore-feedback-supression-rtp-01.txt has been successfully submitted by Wenson Wu and posted to the IETF repository. > > Filename: draft-ietf-avtcore-feedback-supression-rtp > Revision: 01 > Title: RTCP Extension for Feedback Suppression Indication > Creation_date: 2011-04-15 > WG ID: avtcore > Number_of_pages: 17 > > Abstract: > 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 extensions for third party loss report, to suppress NACK > and FIR feedback requests. It also defines associated SDP signaling. > > > > The IETF Secretariat. > > --Boundary_(ID_JqI8j4EHb8QGMRK3Ds99bw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg5OTkiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWT4NCjxESVY+DQo8RElWPkhpLGZvbGtzOjwvRElWPg0KPERJVj5XZSBoYXZlIHVwZGF0 ZWQgZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHByZXNzaW9uLXJ0cCB0byB2ZXJzaW9u IDAxIA0KdG8gYWRkcmVzcyB0aGUgY29tbWVudHMmbmJzcDtmcm9tIFByYWd1ZSBtZWV0aW5nIGFu ZCBvbiB0aGUgbGlzdC4gPC9ESVY+DQo8RElWPlRoZSBuZXcgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6PC9ESVY+DQo8RElWPjxBIA0KaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAvIj5odHRwOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS1mZWVkYmFjay1zdXByZXNz aW9uLXJ0cC88L0E+PC9ESVY+DQo8RElWPnRoZSBkaWZmIGZyb20gMDAgaXMgPC9ESVY+DQo8RElW PjxBIA0KaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lvbi1ydHAtMDEiPmh0dHA6Ly90b29scy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNrLXN1cHJlc3Npb24tcnRw LTAxPC9BPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QWxzbyBJIHJlY2FsbCBpbiB0 aGUgbWVldGluZyB0aGVyZSB3YXMgYSBjb21tZW50IGFib3V0IHVzZSBjYXNlIGFuZCB3ZSBoYXZl IA0KZm91ciB1c2UgY2FzZXMgPC9ESVY+DQo8RElWPmluIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBJ IHdvdWxkIGFzayBXRyBkbyBwZW9wbGUgdGhpbmsgdGhlc2UgdXNlIA0KY2FzZXMmbmJzcDthcmUg Y2xlYXIgYW5kIDwvRElWPg0KPERJVj53aGF0IHVzZSBjYXNlcyZuYnNwO2FyZSBtaXNzaW5nIGFu ZCBkbyBwZW9wbGUgdGhpbmsgdGhhdCB1c2UgY2FzZXMgYXJlIA0KbmVlZGVkLjwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj5SZWdh cmRzITwvRElWPg0KPERJVj4tUWluJm5ic3A7PC9ESVY+PC9ESVY+DQo8RElWPi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gDQo8RElWPkZyb206ICJJRVRGIEktRCBTdWJtaXNzaW9uIFRvb2wi ICZsdDs8QSANCmhyZWY9Im1haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmciPmlkc3VibWlzc2lv bkBpZXRmLm9yZzwvQT4mZ3Q7PC9ESVY+DQo8RElWPlRvOiAmbHQ7PEEgDQpocmVmPSJtYWlsdG86 c3Vuc2Vhd3FAaHVhd2VpLmNvbSI+c3Vuc2Vhd3FAaHVhd2VpLmNvbTwvQT4mZ3Q7PC9ESVY+DQo8 RElWPkNjOiAmbHQ7PEEgDQpocmVmPSJtYWlsdG86eGlheWFuZ3NvbmdAaHVhd2VpLmNvbSI+eGlh eWFuZ3NvbmdAaHVhd2VpLmNvbTwvQT4mZ3Q7OyAmbHQ7PEEgDQpocmVmPSJtYWlsdG86RXZlbi5y b25pQGh1YXdlaS5jb20iPkV2ZW4ucm9uaUBodWF3ZWkuY29tPC9BPiZndDs8L0RJVj4NCjxESVY+ U2VudDogRnJpZGF5LCBBcHJpbCAxNSwgMjAxMSA1OjUyIFBNPC9ESVY+DQo8RElWPlN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJh Y2stc3VwcmVzc2lvbi1ydHAtMDE8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPiZndDsgPEJS PiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIA0KZHJhZnQtaWV0Zi1hdnRjb3JlLWZlZWRiYWNr LXN1cHJlc3Npb24tcnRwLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgDQpzdWJtaXR0ZWQg YnkgV2Vuc29uIFd1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48QlI+Jmd0OyA8 QlI+Jmd0OyANCkZpbGVuYW1lOiBkcmFmdC1pZXRmLWF2dGNvcmUtZmVlZGJhY2stc3VwcmVzc2lv bi1ydHA8QlI+Jmd0OyBSZXZpc2lvbjogDQowMTxCUj4mZ3Q7IFRpdGxlOiBSVENQIEV4dGVuc2lv biBmb3IgRmVlZGJhY2sgU3VwcHJlc3Npb24gSW5kaWNhdGlvbjxCUj4mZ3Q7IA0KQ3JlYXRpb25f ZGF0ZTogMjAxMS0wNC0xNTxCUj4mZ3Q7IFdHIElEOiBhdnRjb3JlPEJSPiZndDsgTnVtYmVyX29m X3BhZ2VzOiANCjE3PEJSPiZndDsgPEJSPiZndDsgQWJzdHJhY3Q6PEJSPiZndDsgSW4gYSBsYXJn ZSBSVFAgc2Vzc2lvbiB1c2luZyB0aGUgUlRDUCANCmZlZWRiYWNrIG1lY2hhbmlzbSBkZWZpbmVk IGluPEJSPiZndDsgUkZDIDQ1ODUsIGEgbWVkaWEgc291cmNlIG9yIG1pZGRsZWJveCBtYXkgDQpl eHBlcmllbmNlIHRyYW5zaWVudDxCUj4mZ3Q7IG92ZXJsb2FkIGlmIHNvbWUgZXZlbnQgY2F1c2Vz IGEgbGFyZ2UgbnVtYmVyIG9mIA0KcmVjZWl2ZXJzIHRvIHNlbmQ8QlI+Jmd0OyBmZWVkYmFjayBh dCBvbmNlLiZuYnNwOyBUaGlzIGZlZWRiYWNrIGltcGxvc2lvbiBjYW4gYmUgDQptaXRpZ2F0ZWQg aWYgdGhlPEJSPiZndDsgZGV2aWNlIHN1ZmZlcmluZyBmcm9tIG92ZXJsb2FkIGNhbiBzZW5kIGEg dGhpcmQgcGFydHkgDQpsb3NzIHJlcG9ydDxCUj4mZ3Q7IG1lc3NhZ2UgdG8gdGhlIHJlY2VpdmVy cyB0byBpbmhpYml0IGZ1cnRoZXIgZmVlZGJhY2suJm5ic3A7IA0KVGhpcyBtZW1vPEJSPiZndDsg ZGVmaW5lcyBSVENQIGV4dGVuc2lvbnMgZm9yIHRoaXJkIHBhcnR5IGxvc3MgcmVwb3J0LCB0byAN CnN1cHByZXNzIE5BQ0s8QlI+Jmd0OyBhbmQgRklSIGZlZWRiYWNrIHJlcXVlc3RzLiZuYnNwOyBJ dCBhbHNvIGRlZmluZXMgDQphc3NvY2lhdGVkIFNEUCANCnNpZ25hbGluZy48QlI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjxCUj4mZ3Q7IDxCUj4mZ3Q7IDxCUj4mZ3Q7IFRo ZSBJRVRGIFNlY3JldGFyaWF0LjxCUj4mZ3Q7IDxCUj4mZ3Q7PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_JqI8j4EHb8QGMRK3Ds99bw)-- From Internet-Drafts@ietf.org Fri Apr 15 06:45:07 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2DBCE0685; Fri, 15 Apr 2011 06:45:06 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUe0i-EzxUXC; Fri, 15 Apr 2011 06:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EB2CE06B6; Fri, 15 Apr 2011 06:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415134502.25718.15478.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 06:45:02 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-ports-for-ucast-mcast-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, 15 Apr 2011 13:45:07 -0000 --NextPart 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 : Port Mapping Between Unicast and Multicast RTP Sessions Author(s) : A. Begen, et al. Filename : draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt Pages : 37 Date : 2011-04-15 This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-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. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-15063216.I-D@ietf.org> --NextPart-- From Rea@worldcastsystems.com Fri Apr 15 08:15:48 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AEC64E0840 for ; Fri, 15 Apr 2011 08:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.816 X-Spam-Level: X-Spam-Status: No, score=0.816 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQBcSJZi6Ry2 for ; Fri, 15 Apr 2011 08:15:43 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfc.amsl.com (Postfix) with ESMTP id DE28CE0699 for ; Fri, 15 Apr 2011 08:15:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBFB7F.FB14669E" Date: Fri, 15 Apr 2011 16:15:40 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02626A4C@APTSBS.apt.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [AVT] draft-rea-avt-rtp-aptx-00.txt Thread-Index: Acv7f5kiKX2ve+vrQlyTWgKu0FEt3A== From: "Derrick Rea" To: Subject: [AVTCORE] [AVT] draft-rea-avt-rtp-aptx-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, 15 Apr 2011 15:20:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBFB7F.FB14669E" ------_=_NextPart_002_01CBFB7F.FB14669E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Chairman and members, Can I ask you to adopt the internet-draft "draft-rea-avt-rtp-aptx-00 - = RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs" for = discussion in the Audio /Video Transport Working Group, = (http://www.ietf.org/mail-archive/web/i-d-announce/current/msg37283.html = ). This internet draft has had two previous incarnations under = draft-gmassey-avt-rtp-aptx-02.txt, (expired - 04/06/2008) and = draft-trainor-avt-rtp-aptx-00.txt, (expired - 22/06/2010). I've added = and changed some sections in the internet-draft but others remain wholly = unchanged since the Trainor draft. =20 I apologize if any previous mailing list comments have not been acted = upon in this draft. I can only say that I'm new to submitting = internet-drafts and wasn't fully aware of the discussion mechanism = before I submitted this version. I'll trawl through the Audio /Video = Transport Discussion Archive over the next few weeks and cross reference = this new version against all previous comments against. =20 Regards,=20 Derrick Rea =20 =20 =20 =20 =20 Dr Derrick Rea Principal Engineer Tel : +44 (0) 28 9067 7200 Rea@worldcastsystems.com =20 Head office: 20, av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy 33700 Bordeaux-M=E9rignac - FRANCE=20 Tel: +33 557 928 928 - Fax: +33 557 928 929=20 APT office: Whiterock Business Park 729 Springfield Road - Belfast - BT12 7FP Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 677201=20 =20 =20 Avant d'imprimer cet email, r=E9fl=E9chissez =E0 l'impact sur = l'environnement, merci. Please, think about the impact on the environment before printing this = email. =20 ------_=_NextPart_002_01CBFB7F.FB14669E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear = Chairman and members,

Can I ask = you to adopt the internet-draft “draft-rea-avt-rtp-aptx-00 - = RTP Payload Format for Standard apt-X and Enhanced apt-X = Codecs” = for discussion in the Audio /Video Transport Working Group, = (http://www.ietf.org/mail-archive/web/i-d-announce/current/msg37283.html = ).

This = internet draft has had two previous incarnations under = draft-gmassey-avt-rtp-aptx-02.txt, (expired - 04/06/2008) and = draft-trainor-avt-rtp-aptx-00.txt, (expired - 22/06/2010). I’ve = added and changed some sections in the internet-draft but others remain = wholly unchanged since the Trainor draft.=A0

I apologize if any = previous mailing list comments have not been acted upon in this draft. I = can only say that I’m new to submitting internet-drafts and = wasn’t fully aware of the discussion mechanism before I submitted = this version. I’ll trawl through the Audio /Video Transport = Discussion Archive over the next few weeks and cross reference this new = version against all previous comments against. =A0

Regards, =

Derrick = Rea

 <= /o:p>

3D"Description:

 3D"Description:

3D"Description:

3D"Description:

Tel : +44 (0) 28 9067 7200

Rea@worldcastsystems.com

Dr Derrick Rea
Principal Engineer

Head office:
20, av Neil Armstrong, Parc d'Activit=E9s J.F. = Kennedy
33700 Bordeaux-M=E9rignac - FRANCE
Tel: +33 557 928 928 - = Fax: +33 557 928 929

APT office:
Whiterock Business Park
729 Springfield Road - = Belfast - BT12 7FP
Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 = 677201

 =

Avant d'imprimer cet email, r=E9fl=E9chissez =E0 = l'impact sur l'environnement, merci.
Please, think about the impact = on the environment before printing this = email.

3D"Description:

 

------_=_NextPart_002_01CBFB7F.FB14669E-- ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAPgD5AwERAAIRAQMRAf/EAKwAAAEEAwEAAAAAAAAAAAAA AAQCAwUGAAEHCAEAAgMBAQEAAAAAAAAAAAAAAQIAAwQFBgcQAAIBAgQCBQgIBQIFBQAAAAECAwQF ABESBiExQZEiEwdRYXGB0TJSFKGxQpIjUxUIwWJyMxbhgvCi4kOTJDQmFxgRAAEDAgQDBgUEAgEF AAAAAAEAEQIDBCExURJhExRBcZEiMgXwgaHB0bFSciThQmKCkiMzNP/aAAwDAQACEQMRAD8Ao11r Yg+RnhbIfYbP+Jx7wlfOrakWykoqS6oi6UIcj4eH1jA3LZG2JzU/tHYW+t5kyWW2a6QNpe4VDiOB SOY1sO0R0hATjJXvYUvUcV0Lf22U8sl063/tVukkStctxRQykdqOmp2kUHzO7xZ/dxzpe9Dsj9V0 Y+0gZlZXftcvVNEzWu+QVcg5RVETwA/7lab6sGHvUf8AaJVVX2cnKX0XOd0bN3htZtN6tclPCTpS rU95Ax6MpUBX1HI+bHUoXdOr6SuTce3zpHzZKuJW9vM5cPT7MXus5pYIgXBT9pQfQfbguquQliv4 f3Bl5l/6sR0po8PjwTclcx/7jepR7TiOmFEaIeSdyOch+6P4YCtjAcEM8jn7Mh9LAYiuERwTBd8+ MRPpc4CtYa/RYJCOcKD+ok4CBjxKcWpGXKIerEdKafekipaQ5KyKnSQp44DpzTERi7opJJGyGs5D +TIAdWC6zmIHZ9U7rYkKHZh08NIwJFNTiM2CNg4eXrGFdPKKOicAcGPpBwCoIoqJgB9o+vhhCroh FxOOgkehc8ISrQEQpz6foxVJXRwRcBIPHPFTq1SVNIVOfRiOoYupKGTMAg4BKAipCCQHLjhCUdqP hYcO0OrCFOAj4SPLhCmCMiPDhxxWU4RkLN5cIVaIojUcKiwXj6pliZv7in/YQceoK81TiR2fVNUc 9thrYpa6JaqljbVJTKSneZcQhcZlQx5kccuWK6jthmtlEYuQWVuqPFfxMvrxWqz1T0dMF7uks9lj eBEQckRYgZSB52OMUbSjDEseMlulcVZYBx3BS1BYf3HUOVbTQ3xBlqINRKzEeeJ3Yn0FcVmpanA7 EwhcDEGXx81aNt/uN3tYbglt3tbTUxpkJmZPla1B8WhgiP6Ml9OKqvtlOYemW+oRp384Fqg+mK79 Zb5tjeVh+aoZIbla6pdE0TgOAcuMcsbZ5MOkEY4tSnOlJjgQupCcZxcYgrgnjB4IiwJNuHbau1nB 1VlCO21MCffQ8zF5c+K+jl3fb/cd/kn6uw6rh+4e37RvgMO0LkKyH8x/Uhx2FwzHgPFTFBtvcFws tdeqSCWa227hW1GarozAPutk7c/sg4qlXhGQiT5irIWs5RMhEbRxH5TSbav8+3p9xR00z2amkEM1 XmgCyEqNOk5PzdejENeAnsfzJ4209m9ht1+ChqjbV9i27HuOSjkFlllNPHWF0CmUEjTpz1/ZPRic 6G/Y/mVot57N7eVQDzRdIX1scWEoxgexDtNHnw7oekk/wxUZjUK8UpaSShUxge9F6lJxN41CHIlo VLx7Y3JPtuXcqU3/AMfilFPJWgIB3pIGnTq182HHTirnxM9j49ys6eUY7m+qjo5DyBIy8gyxe6yy Cmtt7dv+47g1usdK9dWLGZmiDIp0KQC2blRzYdOKqtaNMPIsEaVvKoWiMVIbc2Tu3cT1C2W1zVvy jaah1KKiN8JZ2Vc/MDiutc04NuLOrqVtUk+0ZKwr4OeJyqWbb8xAGeXeQE8PMJMZ+uo6q/o6un6K vETU8rwTx9zNExSSOTNWVlORVgeRBxpE3yWYwbNFQyA5dpSfTiGRUiyLRyMu1liqUirQAiopM/tA 4qMirQApypsl2t1PR1NbAYYK9O9pHJU60yBzGkkjgw54oFQSJAOStNMgAkZrcXDlgkqBGU7NmPJh NysIClqXIj/XDAqsqRgAz/1xCi6koVXIfVhCoCjIVPDFZVgKPiQcM+vCFEST/djy4VNvK8dtESeA kI8zq+PTBedEu7wQdSFBIVHZvIdIxJHgtFPvCum2/ETdNqgis2x6EW6okUCaeCmWruFU/NmeRlfs 5+6iKAo8vPGCpawkd1Q/gLpRuZemmPyrfTeMHj3tVVrNwWyqrbcDnIK+hanGXmmRI9J9OfoxknaW 8/QceBWiNetH1jBdYsN88N/GrbkkNbRL87TqPmKObIVdKzcBJDKOJXPkw4H7Q6Mc+UattJwtYMKs WzXGpG3X4GeISoNVXYqvtAghY6ylByOa8lmiz6/5Tjq7o3dPJpD6H8LnbZW083iV6pttwtt6tMFd SOtTb6+ESRtwKvHIvIj0HIjHn5RMJMcCF1wQQ/YvIfjDsr/Dd5TUdPFILTWL81bpC4ACMe3H5fw2 4ejLHqLG6NWGOYzXmr+15c8GY8FZ/D2bLwO38yqTpZOBfnmidPRjPdn+zTWuyj/Xn8/0WrLKv/5k 3A4XPK6J2c8+PeU3Tg1P/sj/AB/KkI/1COP3CVDDDXft527TTrpiqdwpC6gZnS80qnLLzHCGTXUj /wAFfTg9vEcfunPF3d1Lsjdv+OWLblkWgpqWF1M9ujnkLOCSS5IzxXZ0OdDdKUndPc3EqUmiAzLN z7f25uO3+Ft5ktFPQ1O4a2OluyW+JaaOSMyKpzReXI8efH0YSFSVM1IgkiOTq4wExElnSd+eI9p2 l4h1+3/8OstXt+gCQ/LfKQxzurwK2ffENl2n+Dl14ahbmpSEt0tx4qmtc7J7WG1Jasoan9t98qaK lNBQy3wtTUZl7zuo2miKx95kMwo4csGDi5i+e1LUY25I1+6A8LorPbPCnd28mtdJcbvbpo4KU16C oiVW7ocEPDnKT1YN5UlKrGDkR4FJZwEacpM8lavATxGrdx72loJrTaKFFopZRNb6NaeXNXjGkuGP Z7XEYzXtERg4JOPaVdaXEpyYgZKKsk0sXgBu6SJzC5vOkuhKnIyU4yzBGL5l7iH8fyqnahP+R/Vc 823d9yU15pZrNU1DXRG/9KkRaZyxBBAjOsNwz4ZY21IxMSJZLn060t3lJJ8Vftk2fd9xvl73NWyU FNJQ6heJ77CDCJJACQ0IC6WAUHPhl68Y69SEYiAfHLatdCMzKUywbPcui7O/Sr5dGtlxqtrXammh k1UtspjHUZjLtBj0Dp6cYqxlEON4PErXRImWJhIcB/kqH2fFtqi2zcIqc22mvkVfLEau9xF4WgSU qgRyMvdGXA8888PW3SkMzFuxJR2xgcgXOfel3yzXm92CsaiqNvVkdCBUVK2iPROFUE+9lyyBOXTl iQlGMg4kH1UmJTiWMS2iL3xJaF2VtdauGWStegX5GVHCxoRHFqMin3s+jC0BLfJsnTV5R2RfNsFQ YVLZeTGsrKCyPhHrwqYFSNMMsujDBAqTgYcM+eCoyPgJJHlwpTKShYAefy4QqAIuI4rKsCezwqZl 5ANPIznSI2A+JcvqOPT7V5reAMXUXWwyI2oaUB48QcvrxXOJ7GC20pAqzbCuG/paxLBs6V4a+ubN 2o27mWQKM/xJ+DLGg45agvrxmrQgBuqMQFsozmSIwwXVE3j41eF9RTvvmE3nbFY4inkklWpK6h2g sx7QbTnksnZbjl5ccw06Nf8A9bRkF0RKpT9XmCVv6w0WwrzY/FbYWRsNdIhrqSJvwdFQNXYX7Mcy 5jT9hssugBbeZqxNKfqRqRECJjLtXRPHaw0G6fCuoulPlJJQRpdLfMACTHkC49DRMT1Yz2EzCsBr gnuoCVMqF/a9uOet2tX2OdixtUyyU2fRDUgtpHmWRGPrxo94pNMSH+32Wb22rugY/tW/3S2WGo2d b7xp/HttYE1gZnuqhSGH30TC+0zaoRqE3uMHpvoVw3YW/N3WCStorJTi409wQfOWyWlNTE4UZBjG vHkcj0Hpx2LmhTmQZliMuxcy1q1IAiAceKts3i54lUtrmpG2fQw2knvZ4GtMqU5IyOt0zCcNI4nG Y2lB33l/5LWK9dm2DwKpO7fFzcu5rdRWyVaSgttBL8xT0lti+WjEozyfIFuK6jlli6jbU4EkEyJ1 KrncVJBjgylKjx+3XXGJrnaLHcqmNBH85W0CzTMq8tTFvqGKI2UHYGUfmrjdyZyAVEX/AMYN2Xe7 WKvqRR06bcmWe1UNND3NKkiMrcUBzI7AGWfLllgdJCLg/wC3FE3UizBQe6b7fN23m4bmr4F7yd4/ m5qeNhAjaAiDMltOoR8Mzxw9OAiBELPUlKZMmUrtHxV3NtezVVloko7haKqQTTUNwgWphEnAFgpI 56R1Yqq28Zl+0aKylXlAMjrN4zbmt1bdXpKW1x0V57s1tm+UQ0JaJAgdYNXZJA7XHI9OKumjJnJw 4pzczDsBipmm8c90UkcwttustonqIzEauhoUgmCn4WDfWMWCxgcyW4lUzvqgyA8ELs3xIv8Atm3V dupPlau217iSoo6+ITxM4yGrIleJyGfoxpq2kKhBOY0WOneVKYIAcHUKx0PjJfqaVaijs9jpp0z7 ueCgVHUkZEqyvwxSbCBwMpeKtj7hVzER/wBpQth8SdzWqquc6TQVv6y5kuUFZGs0crnPtaQVy4HL LllhqtpAgdm3JlKN3UBJz3ZuFN0ni5uGn1tQW+02+eRCnzNLRrHIoPkIb68Z+jicyT81oF3UGQA+ Sa2/4gX6z2yS1qtNXUEshmMFbEJwJGObMMyOZ48enD1baJL5HglpV5xDM44hSr+JN8mt9TRU9PQW 6KsTu6h6OnELshBBGYJ6CejCi0i7kktqU0rqbMwD6BE2vf8Ae4rbTW6ano66lpF0U3zcAlZV5ZA5 jo4YBtYkuHD6Ii6lGIGBZRiKXZm0hcyTpHADM55DzYv2LPvRUcZ4YQwVgkjYRkPL5jgMnBRkOeY8 v0YUqwKUp2AGXAnpIwpQZStDR1NScoInk8pUZgek8hiqcgM08Yk5KVjt0MP/ALqqSNumKP8AEf8A 5eH04pMycgrdjZlOabV8c/3U9uB5uCnl4rx1Gcy2sH+U49YvKy4LJIi0Y1jNc82GQPDERjLHBW3w Z3da9p7/AKeuuI7u3zRSUs9QF4RCXIq5AGeQZRnl0Yw+4UDUpERzzXU9vrCE3kc8F3Dx13rsybw1 r6KO4UlfVXIRLb4IJI52LCRX7zJS2lVCnterHF9vt6nOBYgDNdi7qw5ZxzVP75of2q6Ln70z93b1 ccSPndUekf0qxHmxrb+75fn4LOT/AFcfjHBdFvkrWjwFkWt7M0dhjpmVhke9lp1iVcj06mAxgpDd dYfv+61VfLQL/t+y55+1SGc3DcU2R7lYqaMno1FpCPoGOh70cIjvWD2geo9yuf7krhDS+HYgcBpK ysgjjTp7GqQnqTGP2mL1n0C0+5n/AMJGq434e11c1gu1tgSnnWeeCZ6Ja79Mrm0KwDxzNlHJGufa Q58cjljsXcRvEjhhm24Ll2UzsMRjjlu2lWK20V0iuVLI1LX2mNZUL3IbkpH7hdXGRo5BocKOJU8+ WM85RMTiJcNhWuEZOHEo8d7qj2B7ZV7jvO1qqSKqob/PJBQ3QQqmitWVjSVKhV7KSMdLqOGlvNjV ViYwjMBjHMcO0KijMSnKBLiRz49hS7/Db7PX2TaMcdLKLTUxzX+pkA7qavkZe+ieQKW7inT8Lh/M csCkDMSqY+YYd35OalaYgY0x2HHvXRCvf3kx1kC0lrEzZyTz2KqtkcQJI1RCKCVqfLoVg+nlxxzp RG3U903++K6cZHdi7f8AS35VI8Pb1c02hua0WKopYrtJV0lTSQyilRJIkMiTmM1Q0NpBTgTnly6c bLinHfGUh5WOv2WK3nIRlGJ8z4fBTFpppv8A7Et0u9XtlTJLSTtFAJKMRLOsMgpEqDErUyMZdJGs EctWK6uNIimCIvx+fFXUsKgNQvNvBWCSOR7XdE3Ba4o6L5Co7uatr7ROEqO7JgMKUVNHP3veZBdD ZeXhiiMPMNub9gl91fOo0Tvybtb7KuNdJtv7O2ytiemgrq+OqnvEyxwTVBlWoMcSSNIjsiLEoKrw 5541ihvnLcMmbTJYZ3QpwiQc3dTFz3ddodvbfq6CSkguddHUteJ6empRNK8M5jhM2UZy/DHkGfPC 07QGUgRgGbEpanuAEYl/U74aImGalrrlsq51cNBLXVBlF0E3dwQymKoZYTVBFKqWTLtFOPDPCmkQ JgOwy8OxOLuBNMk+p/gq2rHVyw1a3GOWlpRTznVXzWippcxE2lWSnSGbMtloKHMHI4zbRg2J4bn+ q083VwOO1vpiuWwUz6VOno6eeOiaa5wuo8UdDTPwyXA5aPUxRsFM+fEcMAQUlXBGClKfMZAjhhis 7KQiQkZgYQohFRrl0erCFWxRdHR1VVMI6eF5pDyVFLH6MVTkBmtMATkpyKxpTZfqFXFSHpiT8eb7 icF/3HFBqP6Q6uFP9xZGQ1dqp+FHRGocf9+rOfHzRJkvWTisxkcz4KwSiMh4oh7rcKgBZZmEfRCu SRj0KuQwBTiFDMlGUdFVzLnHC7L8WWS9Z4YWUwO1AUzoi/0us+Ff/IntwnMCblleaBteYDID6Meo 5oXkeRLVK/xeU81+jE5oS8iWqZm2lIcyVz9WBzQrYUpaqQ23syztWD9Qt9dcSpzWiotCCQeR3Opw PLpHrxRWrSbymMeJW6hSi/mEpcAutLty4X6st1dvRKbb207Jpa2bf1qNRQZJ3gPRkPTlwA4k45PN jTBjSedSWcl1dk5kSqtCnHKP5UH4t7qrt4yQWSzxyfpEUgbPSe8qZuSZJzCrn2RzJ4+TGiwthR88 vV+iy390a3kh6f1XSfCXYa7N2qKacD9RrHNTXt5GIyWPPyIo688cu/uedUcekZLq2NuaVMA+rtXL PGe8vuu+RUdG2q1WvUsUg4iWZsu8cfyjLSvrx1/baPKg59UlxvdKxqy2x9MfqVUrV4dPX08szOsZ XWkSlGOqRUDDUwBVF7Q5+rG2pdCJZlgo2cpgnc2neiarwoqEbuBLHUVDHKAJ7r5jgvEe8WBAwgvQ cWYKw+3zjgJPLsRll2Vedv53SguFNTNKjxtUrF3ssMfa/EizRmRm7vIMna488V1K8KnlMT+VbTo1 aI3CQ72dhwQE3hjI1ma701QkyRTmCuDKyEMzdl4nfITKy8Tl2h0jFouwJ7SGww/zos0rOZhvEnxY /kaoau8LylQ0K1UZYzfLwM8MsZlYEBtOa8ANXPp6MQXYIduzgrhZSBbd2sMCPj7pM/hTPFKKZqqB 3cqYQFkKup05tmFIXTrHA88J1YIdirxaSiWcY/HyWSeFncSSJPWQxqimRX7uVtaIgkcgKp5Bh6cT q3yCPSGOcv1Sx4ZxQIk80w7tZhHKIoXdgmYzkU5Acm4K2ROALlywCadqwclStZ4WzUFxakmnhWLu 0mjqdL9pJGCR6ogO8RiWGasOGBG9EouAqZWJjJifn/hLj8OWAaSKaOReIjZUkGp11alOa9nLuzxb gcTqxop0Wh/VGJ4fKFkbv0YKrHUkcjaijaGXTp1Z6unlgdXwU6EY4/T5Jf8AgKwgSSSxRrlkWKOM n4dn3eI4+8OGB1boixEccB8vjxQ8dgb4cMaiApIyKxHL3cKaiPLRKWNvhwpqJxTRlLt2eVtMUTSN 5FBP1YrlVAzVkaZOSk4ts91xqZ44PKg/Ek+6mf0nFRr6B1dG3fMoqKitsP8AbpWqZPzKhsl/8cf8 WxWZyOZbuV/LjHIP3owJd6qPuItQh6Yade7jHpVAB14TyxxRG6XclQ7e0f35YofKuet/upqwDW0T cvVGxUFsi5pLUt0asok+jU2EMpHgmAiOKLiklj4U8EVOOhkUM33n1HCEPmXT7tME+KauqDm5ll85 JI9mA4CjEpf6XP8AlHA5gR2FUcbTPwfRjodQuf0wW/8AFD8H0YnUIdMFh2mfg+jB6hDpgmztA58F ywOoTCgi6PZtC7A1UzxH+WLvDl6dQ+rCyuZDJMLaJzVmtFFteyHvqOklqa0DITyKAw/pzyC+oYyV ZVKmBLBaqUaVPEAkoe/XK93WJqYD5Wjfg8aZlnHkZ/J5gMNRpwgXzKFWrKYbIKtDaC9CZegY19Qs nThOJtOQAquYB95RwBy8oxOoS9MlHasrHU+ZPlPE8PPidQEpt1o7XbSF46ByXoGfmxOoQ6ZKl25P LDFBIzNDDn3UZPZXUc20jkMzzwBXALpunJAHYEy+1S2ROZI5E8csHqE3TlJ/xMltTZlviJJPXic8 JuQUo7T1Els2J5k5k4HPU5JT1Pth4XWSMsrqwZSDyZTmp9RwDXBR5RTr7ZeSRpJM3kkOp3YksxPH Mk88DngIcgnFKTbLKCACAeBAJ4+nA56PIKcTbhBzAI9GfTgGuiKBTq7cZshpLZcBzPDA54R5BTyb XI95Qv8AUQMKbhNyCn027Tr7zFvMi/xb2YBrlHkBER2eJf7VMpPxPm56uC/RhTV1KYU9AnWtVS66 ZJNKfl55L91fZheYBkm5cjmsSx0689TnyKAo6zn9WAapVggAiI7YF/s06hviI1n/AJuH0YUz4qCL 9ica1VUgylchRyVmyH3R7MLzAMk5iTmlpaIF958/Mi/xOWIahQ2BPpQ0y8oS39bfwXLC7jqjtGid WJ19xEj/AKVGfWczgOjilGGV/fZm8xJwHCjErPlB5MTcptSNFs/MXqPswXko0dVmi2fmL1H2YjyU aOqzRbPzF6j7MR5INHVYUtf5i9R9mI8kWjqs0Wz8xeo+zEeSDR1WaLZ+YvUfZiPJRo6rNFs/MXqP sxHko0dVmi2fmL1H2YjyUaOq3ot35g6j7MR5KNHVKCUH5g6j7MR5ItHVYUt3TIvrH+mA8lGjqklL X8a9R9mC8lGitaLV+YvUfZiPJFo6rNFq/MHUfZiPJRo6rNFr/MXqPsxHko0dUoJbfzB1H2YDyUaO q3otvxjqPsxHko0VsLbviXqOJ5kWilqlD0OnVgPJFgtlKXLi/D0HL6sByowWgtB0MPp9mD5kGilq tJ0MvVgYosFsrT9L8PQcByiwWAUnxD6cTFDypain6GX/AI9OBimDLZVOljl68sRTBaC03xDqwcUM FsCn+LAxRwSh3HlH04GKOCUBF0EYmKOC2AvQerARW+Hn+nEUX//Z ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGQBlAwERAAIRAQMRAf/EAHkAAAMAAwEBAAAAAAAAAAAA AAADBAIFBgEHAQEBAQEBAQAAAAAAAAAAAAACAAEDBQQQAAICAQIFAgUFAQAAAAAAAAECAwQAERIh MRMFBkFxUSJCFAdhMmIjMyURAQEAAgEEAwAAAAAAAAAAAAABEQIDITESE0FRBP/aAAwDAQACEQMR AD8A+6QMfjnoV8PjFsTHBWyRXGcFbhSmGlDkwU4euGnDVw04yzGjJDJDJDJDJOLiTTPQrz5ssiAw UpaqiwU1KYa2HpgpxprfnfjNC59pdnmrSCZa3UlrWUh6rttUdYx9L5mPA7tMU4trMxezWXFeXPyP 4dRlux2Lr/8ANcxX5Y61mWKF1ALLJLHG0aldePzcMycG1+O7fdrM9eymp5t2a15VL42jgXFqQ3YJ CybJ45tx/qGu5iqpqeHLMvFZr5FOWXbx+cN400KxtK0irGmu9yQFG06HU/pnLDo9aSNWVWYKz8FB OhPtkmWSGSGScVEc9CvPi2FS3IE+3HBTi2KFxz4e+c7SxVCqB9Qw2lIcmg9cNOPnsf4O7BvjWS/Y mrR2Rb2PFWM7MsvVCNa6fWK7v5cuGd7+rb6cZ+bX7VR/i/uk8XklO136Wv2ryG/ZtS0qsUJ1hsBQ VaSaN3D6Lodp0w3nkxZOusKcFvlLem1b6LwWCp5DD3rtvcJ6brWr0bNYLFLHNBVJ6akyIzodGIJV hnO82dcWOvqxtmVd3XxuLuECQPLpGJJXkDIH1Ezbjt1I2sPpb0wa74dLCqnikcFmad7TydWYzbSD yLFiGJZtdd2hI04embd1hgviIWSjJ99KzU3Z2ZgSz6spXkwAKqiprodRl7GeLcdu7dWoVlggUAAD eRw3MFCliPidvHBbkpFOYnEwcxnoV8F7t/D/AI5897u5Y/dic6cnphpQ9MFOHrhpw1cNOMsxoyQy QyQyQyT/2Q== ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgADgBlAwERAAIRAQMRAf/EAIwAAAMAAgMAAAAAAAAAAAAA AAECBAMFAAYHAQADAQEBAAAAAAAAAAAAAAABAgQDAAUQAAEDAgQDBQgDAAAAAAAAAAIBEQMSEwAh BBQxQSJhMgUVFlGRocFCUiMGgdFiEQABAwIEBQMDBQEAAAAAAAABABECIRIxQaETUSIDBBTB0QVh cTLwkbFCotL/2gAMAwEAAhEDEQA/APfY9Y2UMQQp2JUXvXFxhxUN/ALMBmauRKXbgMucrFr/ABPZ WBGO4eoNQFHVERhUlVaRMuXJMef33e7NoZzIto+QJ0VnZ9pvXVYRH6zH8oafxzVSyxQBolGeUpEC 4SgCjEgqpCqhUr1t3cRw+SnMiIhzEyxLBotUUfPgq5dhGIMjPlDYBzV6YtlxVReK60Z49KGljk1R hJKoDN0IMaiLVKHeVS4Nh5951BIQEQZkE/lSjZtjVCPawtMjIiLgfjx+j4LFL+0TBNqY4tCUpaUh A40UlMjUUJRGgDDKpsyTE0/lJCUgIE20zd2ejAjVbw+PBAJk137akHRUxfsq7pY5tPt4BmsLLKpo rvSi5RrH1Lw68MPkedpRtjczl/8Alv8ASB7HlcG4s9G930RD9knWKDVFo0HRajUppQO68iKsixoS hS3FPuwB8hJhIx5JStxri2DeqY9kHMbuYRuwpg+L+i20mshjUK6vyGoCwqWYuqqrOyZccXy6oDPm VGOmTgkXxTRCYgRqhn3QUSRVfgyNzwvkQdnqm2Js64niejUlBDVTT6UEn9zY7yIOzrtiWKIeI6Y5 QiGtSkRx6C4ZK65ZJnzwR14kgB6/QoHoyAf1VONlkupRR6MUT8yyL7AFk95f1i4k8FAw4qmMo36Q /klzwpRBGSGu8vtBv7SR1fjrbvMvd7WxF3eww3WZ6PxVXbbznbd82SH6f20F6zYctvUzP9VL/HEv U8SyN1ttbfVlVDyby112fo6q8N8kri2ViumS1bpempLjN/pqu3Ddv47jbtdizcH5tcUvW32N92Tv 9qaYJpfTvmC3bG+qGrhXXlS7c+GM+p425W3ccfd8lrDf26XWaIr6U3q17bdXep6XvPz5VVfHGcvE vrZe/wDr3WkfJs/ta2nsjF6S3w29ru7q0NS911duVT4EfEvpZe+vujLybK3WtotlqNjQN+mitaX+ 7N/m+LepY3NxU0L3olk8u3Edyi+w2n4tnS3ywstu4OzoxvtLYJQ8r3PTbvure1+bfPAG1dRrkTuW 5smLy67G9Fxxttx4dPDBO24wdAXseCqxusV//9k= ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.jpg Content-Location: image004.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGABlAwERAAIRAQMRAf/EAHQAAAMBAQEBAAAAAAAAAAAA AAABAwQCBQgBAQEBAQAAAAAAAAAAAAAAAAABAgQQAAIBBAAEBAQGAwAAAAAAAAECAwAREgQhMRMF QVEiBnGBYhRhkbEyUhaCIzMRAQEBAQEBAQAAAAAAAAAAAAABERITAjH/2gAMAwEAAhEDEQA/APoB I55Td2dz5m5rt2Rw2WuNvbh0ColRiWBNgU5D8GZam6n4tod00tvPoliEiScki3okBI+fpNZrUTHu PUaCSXWgn2OlCs74qAFDpmoYk8OHlepjU+lP7V26JCZEkyjijmnC4kIJEEgHqZS3A+ArPNa7i590 aAlWOOHYmykECOiDFpSnUwGTLxxNZ4rXcWPujtq6sGyqu8c6sygYKwwOJDK7qeY8KzxWvSZqnbfc Or3De+3gU9NtePZhlIPqWQsCCLekrj4ml+MjXz9y16LbOuqhnkVFJIBYheI4HnWMb0fda3D/AHJx BYeochzPwq4ml95q5KnWTJgWUZDiBzI86Yaa7GuxVVlRi4uoDAkgeVTF1Sg8oROeZJro2ObKybXt /U2tj7hy6TFOmzRsVuoJIB/OnaeYX2zoLYQmaACJYT0pGXJEviG8+ZrPbXnHX9W7diyxmaCOSNYZ UikZVdEXFQ3+PCp2vnFG9sdsM/XQSRPiikI3pIiGK3BvyAtU7q+caB2PQ6wlxbMbJ3B6j/1KYX+F vCp1WuIzj2l2lQnT6sRVDHkkhBKF2exv9TmnpTyjTrdg7fqzQy63UhMEawhUdsWRL4hwf3WyNS/d qz4k/GqXR15UKOCVKuvPwkN2/SprWJP2rVZ2Y5Wds2S/Atcm/L6jTo5M9s1iWILLnnmAeYkNyD86 aY719GGBmcXeRyC7vYkkX48h/I8qWkjRUVPpDyFXWcPCmmHgaauHjQwWqKdqAoCgKAoCgKAoP//Z ------_=_NextPart_001_01CBFB7F.FB14669E Content-Type: image/jpeg; name="image005.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.jpg Content-Location: image005.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAACxQAABVAAAAbOAAAInP/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8IAEQgAHAAdAwERAAIR AQMRAf/EANEAAAMBAAAAAAAAAAAAAAAAAAYHCAkBAAMBAAMAAAAAAAAAAAAAAAUGBwQAAwgQAAED AwQDAAMAAAAAAAAAAAQCAwUBEgYhExQVABYHESIlEQAABAQEAwgBBQAAAAAAAAABAgMEERITBQAh FBVBMiQxUSJCUiMGFjMQYXFTJRIAAAQDBQUHBQAAAAAAAAAAAAERAjEDEyFBURIiYYEyBBRxkUJi giMzwaJDBRUTAQEAAgEEAQQDAQEAAAAAAAERACExQVFhcZHwgaHRELHxweH/2gAMAwEAAhEDEQAA AdwOkYjaOGWrYQe0qJzFIo2mfSBxgVBnHM3D/wA+TGMrbiPmqlVXPT1kR7dlw7Tarx7ta6ixf//a AAgBAQABBQKZngIIQPMsgnaz8rl0W/7qx6TmUxQjKcazRxB5RHFdbJeXE/QockXJZuM3PAMkUYI3 8qyBuHyboepnOj5fzP0Te08//9oACAECAAEFAk1/RyJBGbjgoslngO9lM1XfDiXhMt1cRVhHaIPA j0CvNPDKq0MiuUIqei+7G7L5Xkbulv8A/9oACAEDAAEFAiy2BGxJKpSVvKTXepszRn9SNNoryuir 68bJI93mRuniVVUriK2SNrZa6zdF4l2v5//aAAgBAgIGPwKpMPI0uI8A2bNmm+c4lyswuU7lIOZO 5dNtubvVCHQ5jRftxWEBI5Yjc+XJa17/ADG43R7iEt7iU2EpNt1tO3UfFpWy24Ja6SWFksu07w2Z 7ebo3EqWLUb9DRcB/Q5mRWY4iYZFEkVHH3iVzv63Vy7y8OEEPDAVZxU5SaSM7G3mhX7w1+X2mk4l Ql1ZboeGA0b+wO/nrl9VHblujHzKDq5Evpw3jYP/2gAIAQMCBj8CzzxUY1JRhWwFQUn/ABpAUvxj ymPUOrl2tBZYAmFxCn4lUH1HADprlHt/INo//9oACAEBAQY/AtS+OOcSoN0i1HDlQAiJEU+IhxHs DB1LRamDK3AIl3C5KuFvGHlSQRBDUKF4hEClHjhou1+TCsdxOkZN0hb27EridKiBWKTdRwsicomL KUTKAMBmx9s0/Uaalt+c2/anbNr9cd39vvlzw5brHEdOKrNkkMQJ0ZCCcs4iVIhnLk49ohHLC1rU dqMmV4OWmuWmqoxuE0BMFcgok1nIbISgaBu/AiHQOlIk1L5XdvkTgucwN2qZlU2oHAe+UPTh5bKb 6k1+eW280JkdbRf/ABi7O4y/iqbvba8P7cKradNZpc0juWhlDAUorHpg/QiYhiCqUxCmhHkH+cGc NE5TFExF0CZCUyZpJ05fOUQ7P2jho3Km5Wv7pYjBW12pkQLncXwiBEl3D44St0HSRimmGUeYeA4e q6y0jenrm2ORtfW7amhbEbumVqW7Ta0bgse7iYXUkoCQCyQGOFfsdHb5i/knqV86WjpdRrPRS8eA 277DSh4q+zaun5a03iqSwkq+9Dmx/m637FTUjv8AS3GnD3dv0/8AnSSc1H3JOfL9P//aAAgBAQMB PyGQm0CAGRJyIe14p8Bc9Crt/GCPTjHfpe9Bar0UguaPWPHer8BlgrX6AXMKdh3RkjKLU9WUGodn CR4E7RDDgOgomd7WuKzWj3vi6zXHuddL0QEJoCG4siKus76N2HOJeB3nWGJkSm4JrTyARt9dNl2f 0aL+dvZmrn7ohv8ADBV5mHxw+314tz//2gAIAQIDAT8h3BILOr1239sBihCWo0a0PPjJjpELQjy+ RHZJSZ36cdWN+FXHfAmjn4o2wCOtUN4Xn4mK0PABwjKSG2b70WXyvS4Dk26aOh3+gXG7D/qVgdu/ xiYHAsqGidwipMUN2tO3Quy87ac9dZQXb0OHLb1zd04fDuvjPafnl/Ya4efH0HX3n1ec/9oACAED AwE/IbJr2OcLuql50z+zCHse89jkTuI8M0qB4IfXOWgui/GbPr/Tks1TfjBAX3c87zcAyZ1H/Z+8 6I0zzS1nfuy/8/g//9oADAMBAAIRAxEAABAHh21ij5v/2gAIAQEDAT8QKMXDEtygUoBjgdWeocHk UHXO0G5LAAa5rlBqeocHFLxUJDdh17RMAcgsiZRIUakBxgP0rwAahVEoSOJXFECeiGRywfxBgM4U cKHMcEqFOBUmE15DjaHR3Nlgi0sonwFMwm9szAYzb+tCBIbFFeiP/wBrtkL4xvrZyfZLmn+THf5u 3Tzj4lTidL8Dxc//2gAIAQIDAT8QJIeJFQIi2U1SlnDHRzVIEoQRHOycLjqWKdms5wA0wWmQKrU7 QXZAdOU6JhdT2QA2YIxEaBSqBop2LVFRAkYYscQjKoczcSoB0LjVZTx/q10wjrwgvcbu4N6GIM96 WMwOprzyElHKKdRpyEgCIo0bUxXkBChJXoTo0dNB/wAit1daW/uZ5TT3Z9/x3kzyveTda9vHKcau fgfL95//2gAIAQMDAT8QRQIwKu0P7yGd26BHrXUfvzl+FjtwUTU7XX5zcjoJfeu3J8ecJXoym0Fe +3fOO1QQwCrdhd1y8uJeLoY8IeTnvMESkA6cOj8WZHippqCMm77wOYbvSlNTWmh4mIJbAddlr7mA PkiYTQJ+2eTa38Tz6++rnwkJPMnm5sfEbN/Dv17aucfGr8U/8z//2Q== ------_=_NextPart_001_01CBFB7F.FB14669E-- From dwing@cisco.com Fri Apr 15 08:26:45 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8308E070B; Fri, 15 Apr 2011 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.481 X-Spam-Level: X-Spam-Status: No, score=-110.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XfUX3oLUyU6; Fri, 15 Apr 2011 08:26:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 31654E066B; Fri, 15 Apr 2011 08:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=671; q=dns/txt; s=iport; t=1302881201; x=1304090801; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=e7ebCOubsbLVKytJC/ExgM/R5IAq/c8usRlxuT6QGYQ=; b=P6E1NPlse184hPtmKXkE8oxHopdk1LO3uZ5QqaFNK8nyvB5/gAmI8Gec I3aKMnTIXZ59AdIcz6lzOtHA+0poSxSs2Ja/BPJ50PWRkYXpsktTZrsXF rhkMziPfLNX5kYfux3gjmM/zk6zRjyyQ/S4/JsIjKu/mRLDMgzz66sqY8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACNjqE2rRDoI/2dsb2JhbACZZ4wcd6c1nH2FbgSFYA X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="338401021" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2011 15:26:40 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFQeYP021876; Fri, 15 Apr 2011 15:26:40 GMT From: "Dan Wing" To: , , Date: Fri, 15 Apr 2011 08:26:40 -0700 Message-ID: <012101cbfb81$84a04500$8de0cf00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv7gYRLEnMobebWS4+AhtzwAMK02A== Content-Language: en-us Cc: 'Magnus Westerlund' , avt@ietf.org Subject: [AVTCORE] RTP and UDP checksum=0 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, 15 Apr 2011 15:26:46 -0000 Observation: tunneled packets have two elements actively deciding checksum=0 is okay. Those elements are the tunnel encap and tunnel decap. Question: Should non-tunneled UDP flows, *established with explicit signaling*, also be allowed to decide that checksum=0 is okay? For example, an RTP-over-UDP flow established with RTSP or SIP signaling. Some RTP traffic includes its own checksum at the application layer (e.g., SRTP authentication) and gains little or no benefit to a UDP checksum. Near as I can discern, SIP-signaled flows meet all of the constraints discussed in http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 -d From abegen@cisco.com Fri Apr 15 08:28:10 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AB1A1E070B for ; Fri, 15 Apr 2011 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.593 X-Spam-Level: X-Spam-Status: No, score=-10.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xY62pmxHCjO for ; Fri, 15 Apr 2011 08:28:05 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 66434E06BA for ; Fri, 15 Apr 2011 08:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2634; q=dns/txt; s=iport; t=1302881285; x=1304090885; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=/zK5bec4LPRThMhxg/vYAqeNyRMuF9bi5X/Dg3eQlJU=; b=chEWHxsZjZoSFvPCWKrv9YvRY9WYGfYUsXY+aDcq400l7kEUX9PREClj oIi7MNxjASVGpUK+GIXkd82jWxMJz307IuvRBqmD5dQMwyt17DMZBx8lb kRI1wUeqOC03IhSEEAHm8VeiiuTkteAvBtIxhY33Yz29jViE/Kuq9JOOe c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwBAF9jqE2rRDoH/2dsb2JhbACYBI1/d6c2nH0ChWwEhWCMEw X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="430989771" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 15:28:04 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3FFS3SB032578; Fri, 15 Apr 2011 15:28:03 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); Fri, 15 Apr 2011 08:28:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 08:27:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540ECB149B@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] draft-rea-avt-rtp-aptx-00.txt Thread-Index: Acv7f5kiKX2ve+vrQlyTWgKu0FEt3AAAd0Nw From: "Ali C. Begen (abegen)" To: "Derrick Rea" , X-OriginalArrivalTime: 15 Apr 2011 15:28:03.0925 (UTC) FILETIME=[B65F6850:01CBFB81] Subject: Re: [AVTCORE] [AVT] draft-rea-avt-rtp-aptx-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, 15 Apr 2011 15:28:10 -0000 Derrick, The payload format drafts belong to the new PAYLOAD wg now. Please = subscribe to that list (if you have not done so), and send your email to = that list. http://datatracker.ietf.org/wg/payload/=20 -acbegen > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Derrick Rea > Sent: Friday, April 15, 2011 11:16 AM > To: avt@ietf.org > Subject: [AVTCORE] [AVT] draft-rea-avt-rtp-aptx-00.txt >=20 > Dear Chairman and members, >=20 > Can I ask you to adopt the internet-draft =93draft-rea-avt-rtp-aptx-00 = - RTP Payload Format for Standard apt-X and Enhanced > apt-X Codecs=94 for discussion in the Audio /Video Transport Working = Group, (http://www.ietf.org/mail-archive/web/i-d- > announce/current/msg37283.html ). >=20 > This internet draft has had two previous incarnations under = draft-gmassey-avt-rtp-aptx-02.txt, (expired - 04/06/2008) and > draft-trainor-avt-rtp-aptx-00.txt, (expired - 22/06/2010). I=92ve = added and changed some sections in the internet-draft but > others remain wholly unchanged since the Trainor draft. >=20 > I apologize if any previous mailing list comments have not been acted = upon in this draft. I can only say that I=92m new to > submitting internet-drafts and wasn=92t fully aware of the discussion = mechanism before I submitted this version. I=92ll trawl > through the Audio /Video Transport Discussion Archive over the next = few weeks and cross reference this new version against > all previous comments against. >=20 > Regards, >=20 > Derrick Rea >=20 >=20 >=20 > Description: Worldcast System >=20 > Description: APT >=20 > Description: Ecreso >=20 > Description: Audemat >=20 > Dr Derrick Rea > Principal Engineer >=20 > Tel : +44 (0) 28 9067 7200 >=20 > Rea@worldcastsystems.com >=20 > Head office: > 20, av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy > 33700 Bordeaux-M=E9rignac - FRANCE > Tel: +33 557 928 928 - Fax: +33 557 928 929 >=20 > APT office: > Whiterock Business Park > 729 Springfield Road - Belfast - BT12 7FP > Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 677201 >=20 >=20 >=20 > Description: C:\Documents and Settings\drea\Application = Data\Microsoft\Signatures\images\impression_papier.jpg >=20 > Avant d'imprimer cet email, r=E9fl=E9chissez =E0 l'impact sur = l'environnement, merci. > Please, think about the impact on the environment before printing this = email. >=20 >=20 From iesg-secretary@ietf.org Fri Apr 15 11:04:49 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AA923E08CB; Fri, 15 Apr 2011 11:04:49 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1ce0Oy0HsKf; Fri, 15 Apr 2011 11:04:45 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E60D1E08DC; Fri, 15 Apr 2011 11:04:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.51 Message-ID: <20110415180440.1248.49691.idtracker@ietfc.amsl.com> Date: Fri, 15 Apr 2011 11:04:40 -0700 Cc: avtcore chair , avtcore mailing list , RFC Editor Subject: [AVTCORE] Protocol Action: 'Port Mapping Between Unicast and Multicast RTP Sessions' to Proposed Standard (draft-ietf-avtcore-ports-for-ucast-mcast-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, 15 Apr 2011 18:04:49 -0000 The IESG has approved the following document: - 'Port Mapping Between Unicast and Multicast RTP Sessions' (draft-ietf-avtcore-ports-for-ucast-mcast-rtp-02.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ Technical Summary This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. Working Group Summary This document was discussed heavily in the AVT working group before moving to AVTCORE. There was a discussion if to use a token or cookie for the solution. The initial solution was based on a cookie but after a technical discussion in IETF78 and mailing list call for consensus the token based solution was selected. There was a consensus to use this approach. Document Quality This document received a high level of working group review over two last calls. Detailed reviews were received from several working group participants. Magnus Westerlund and Colin Perkins provided particularly extensive review comments. From Even.roni@huawei.com Fri Apr 15 22:46:47 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85E8EE0677; Fri, 15 Apr 2011 22:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.504 X-Spam-Level: X-Spam-Status: No, score=-104.504 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXI4iJJt9H+B; Fri, 15 Apr 2011 22:46:38 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfc.amsl.com (Postfix) with ESMTP id 1B4F6E0668; Fri, 15 Apr 2011 22:46:16 -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 <0LJQ00LT4DCZOU@szxga03-in.huawei.com>; Sat, 16 Apr 2011 13:46: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 <0LJQ00320DCZLC@szxga03-in.huawei.com>; Sat, 16 Apr 2011 13:46:11 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-50.red.bezeqint.net [79.178.14.50]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJQ00EADDC21Y@szxml12-in.huawei.com>; Sat, 16 Apr 2011 13:46:11 +0800 (CST) Date: Sat, 16 Apr 2011 08:44:45 +0300 From: Roni Even In-reply-to: To: 'Roni Even' , payload@ietf.org, avt@ietf.org, 'Robert Sparks' Message-id: <022601cbfbf9$6baba2b0$4302e810$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Cz/C4zFUj08iMrE/mUMpuQ)" Content-language: en-us Thread-index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIpRIcyxQgAB6IDCAFyl0YA== References: Cc: "'Botzko, Stephen'" , "'Patrick Luthi \(pluthi\)'" Subject: Re: [AVTCORE] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts - concluded 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, 16 Apr 2011 05:46:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Cz/C4zFUj08iMrE/mUMpuQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The WGLC is conclude. There were no objections noted, so please go ahead and submit the proposed changes to the RFC Editor for publication. Roni Even From: Roni Even [mailto:even.roni@huawei.com] Sent: Friday, April 01, 2011 3:06 PM To: 'payload@ietf.org'; 'avt@ietf.org' Cc: 'Ye-Kui Wang'; 'Ali C. Begen (abegen)'; 'Botzko, Stephen'; 'Patrick Luthi (pluthi)' Subject: WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts Hi, Sorry for the double posting. We found some issues with the text in RFC3984bis which affect also H264RCDO and SVC. The issues were discovered by the RFC editor so we can fix it by doing the changes marked bellow. I would like to start a two weeks WGLC on the text in this email in order to allow enough time for people to review. Please send any comments till April 15th. If there will have no more issues we will submit this changes to the RFC editor as part of the AUTH48. Thanks Roni Even This is the text from YK: Please find below the suggested changes for RFC3984bis with some informative notes added to the semantics of max-cpb, max-dpb, and max-cr. The added notes are all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared to the previous post). These additions should address the specific concerns expressed so far. I hope we can close the issue and let the RFC publication process to proceed. As I said earlier, the changes to the SVC and RCDO payload drafts are very similar. ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. NEW: (The nature of this change as follows. If the semantics remain unchanged while the reference to H.264 spec is the 2010 version, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the 2010 H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change hence there is no backward compatibility issue.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. Informative note: In RFC 3984, which this document obsoletes, the unit of this parameter was 1024 bytes. The unit has been changed to 8/3 macroblocks in this document. This reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition of color formats and bit depths not supported earlier. The changed semantics of this parameter keeps backward compatibility to RFC 3984 and supports all profiles defined in the 2010 version of the H.264 specification. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). . For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial) max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). . For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- Best Regards, Ye-Kui Wang --Boundary_(ID_Cz/C4zFUj08iMrE/mUMpuQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

The = WGLC is conclude. There were no objections noted, so please go ahead and = submit the proposed changes to the RFC Editor for = publication.

 

Roni = Even

 

From:= = Roni Even [mailto:even.roni@huawei.com]
Sent: Friday, April = 01, 2011 3:06 PM
To: 'payload@ietf.org'; = 'avt@ietf.org'
Cc: 'Ye-Kui Wang'; 'Ali C. Begen (abegen)'; = 'Botzko, Stephen'; 'Patrick Luthi (pluthi)'
Subject: WGLC on = Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

Hi,

Sorry for the double = posting.

We found some issues with the text in RFC3984bis = which affect also H264RCDO and SVC. The issues were discovered by the = RFC editor so we can fix it by doing the changes marked bellow. I would = like to start a two weeks WGLC on the text in this email in order to = allow enough time for people to review.

Please send any comments = till April 15th. If there will have no more issues we will = submit this changes to the RFC editor as part of the = AUTH48.

Thanks

Roni = Even

 

This is the text from = YK:

Please find below the suggested changes for = RFC3984bis with some informative notes added to the semantics of = max-cpb, max-dpb, and max-cr. The added notes are all highlighted in = yellow. There are no other additional changes besides the addition of = these notes (compared to the previous post). These additions should = address the specific concerns expressed so far. I hope we can close the = issue and let the RFC publication process to proceed. =

 

As I said earlier, the = changes to the SVC and RCDO payload drafts are very similar. =

 

------------------------------------Start of = suggested changes = --------------------------------------

 

Section 8.1:

OLD:

      =
profile-level-id:
         A base16 =
[7] (hexadecimal) representation of the =
following
         three =
bytes in the sequence parameter set NAL unit is =
specified
         in [1]: 1) =
profile_idc, 2) a byte herein referred to as
         =
profile-iop, composed of the values of =
constraint_set0_flag,
         =
constraint_set1_flag,constraint_set2_flag,
         =
constraint_set3_flag, and reserved_zero_4bits in =
bit-
         =
significance order, starting from the most-significant bit, =
and
         3) =
level_idc.  Note =
that reserved_zero_4bits is required to be
         equal to 0 =
in [1], but other values for it may be specified =
in
         the future =
by ITU-T or ISO/IEC.

 NEW: (note that the change here = is purely editorial)

      = profile-level-id:

       &nbs= p; = A base16 [7] (hexadecimal) representation of the = following

       &nbs= p; = three bytes in the sequence parameter set NAL unit is = specified

       &nbs= p; = in [1]: 1) profile_idc, 2) a byte herein referred to = as

       &nbs= p; = profile-iop, composed of the values of = constraint_set0_flag,

       &nbs= p; = constraint_set1_flag,constraint_set2_flag,

       &nbs= p; = constraint_set3_flag, constraint_set4_flag, = constraint_set5_flag,

 <= /span>and reserved_zero_2bits in = bit-significance order, starting from the most-significant bit, = and

       &nbs= p; = 3) level_idc.  Note that = reserved_zero_2bits is required to be

       &nbs= p; = equal to 0 in [1], but other values for it may be specified = in

        =  the future by = ITU-T or ISO/IEC.

 

OLD:

         For =
example, in the table above, profile_idc equal to =
58
         (Extended) =
with profile-iop equal to 11xx0000 indicates =
the
         same =
sub-profile corresponding to profile_idc equal to =
42
         (Baseline) =
with profile-iop equal to x1xx0000.  Note that other
         =
combinations of profile_idc and profile-iop (not listed =
in
         Table 5) =
may represent a sub-profile equivalent to the =
common
         subset of =
coding tools for more than one profile.  Note =
also
         that a =
decoder conforming to a certain profile may be able =
to
         decode =
bitstreams conforming to other profiles.  For example, =
a
     &nbs=
p;   =
decoder conforming to the High 4:4:4 profile, at a =
certain
     &nbs=
p;   =
level, must be able to decode bitstreams conforming to =
the
     &nbs=
p;   =
Constrained Baseline, Main, High, High 10, or High =
4:2:2
     &nbs=
p;   =
profile at the same or a lower level.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; = For example, in the table above, profile_idc equal to = 58

       &nbs= p; = (Extended) with profile-iop equal to 11xx0000 indicates = the

       &nbs= p; = same sub-profile corresponding to profile_idc equal to = 42

       &nbs= p; = (Baseline) with profile-iop equal to x1xx0000.  Note that = other

       &nbs= p; = combinations of profile_idc and profile-iop (not listed = in

       &nbs= p; = Table 5) may represent a sub-profile equivalent to the = common

       &nbs= p; = subset of coding tools for more than one profile.  Note = also

         that a decoder = conforming to a certain profile may be able to

       &nbs= p; = decode bitstreams conforming to other profiles.

 =

OLD:

         If the =
profile-level-id parameter is used for =
capability
         exchange =
or session setup procedure, it =
indicates the subset of
         coding =
tools, which is equal to the default sub-profile, =
that
         the codec =
supports for both receiving and sending.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; = If the profile-level-id parameter is used for = capability

       &nbs= p; = exchange or session setup, it indicates the subset = of

       &nbs= p; = coding tools, which is equal to the default sub-profile, = that

       &nbs= p; = the codec supports for both receiving and = sending.

 

OLD: =

      max-cpb: The = value of max-cpb is an integer indicating the = maximum

       &nbs= p; = coded picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; = parameters (see A.3.1, = item i of [1]) and in units of 1200 bits

       &nbs= p; = for the NAL HRD parameters (see A.3.1, item j of = [1]).

NEW: (note that the change here = is purely editorial)

      max-cpb: The = value of max-cpb is an integer indicating the = maximum

       &nbs= p; = coded picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; = parameters and in units of 1200 bits for the NAL HRD parameters. =
       &nbs= p; = Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

 =

OLD:

      max-dpb: The = value of max-dpb is an integer indicating the = maximum

       &nbs= p; = decoded picture buffer size in units of 1024 bytes.  The = max-

       &nbs= p; = dpb parameter signals that the receiver has more memory = than

       &nbs= p; = the minimum amount of decoded picture buffer memory required = by

       &nbs= p; = the signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; = When max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; = NAL unit streams that conform to the signaled highest = level,

       &nbs= p; = with the exception that the MaxDPB value in Table A-1 of = [1]

       &nbs= p; = for the signaled highest level is replaced with the value = of

       &nbs= p; = max-dpb.  Consequently, a = receiver that signals max-dpb MUST be

       &nbs= p; = capable of storing the following number of decoded = frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; = picture buffer:

 =

       &nbs= p;    Min(1024 * = max-dpb / ( PicWidthInMbs * FrameHeightInMbs *

       &nbs= p;    256 * = ChromaFormatFactor ), 16)

 =

       &nbs= p; = PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor = are

         defined in = [1].

 =

       &nbs= p; = The value of max-dpb MUST be greater than or equal to the = value

       &nbs= p; = of MaxDPB given in Table A-1 of [1] for the highest = level.

       &nbs= p; = Senders MAY use this knowledge to construct coded video = streams

       &nbs= p; = with improved compression.

 =

       &nbs= p;    Informative = note: This parameter was added primarily to

       &nbs= p;    complement a = similar codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture = buffer stores reconstructed samples.  = There

       &nbs= p;    is no = relationship between the size of the decoded = picture

       &nbs= p;    buffer and the = buffers used in RTP, especially de-interleaving
 and de-jitter = buffers.

 =

NEW: (The nature of this change = as follows. If the semantics remain unchanged while the reference to = H.264 spec  is the 2010 version, then the semantics of max-dpb is = simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are = not found in the 2010 H.264 spec any more. Note that compared to RFC = 3984, the bits on the wire do not change hence there is no backward = compatibility issue.)

      max-dpb: The = value of max-dpb is an integer indicating the = maximum

       &nbs= p; = decoded picture buffer size in units of 8/3 = macroblocks.  The = max-

       &nbs= p; = dpb parameter signals that the receiver has more memory = than

       &nbs= p; = the minimum amount of decoded picture buffer memory required = by

       &nbs= p; = the signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; = When max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; = NAL unit streams that conform to the signaled highest = level,

       &nbs= p; = with the exception that the MaxDpbMbs value in = Table A-1 of [1]

 &= nbsp;       for the signaled highest level is replaced with = the value of

 &= nbsp;       max-dpb * 3 / 8.  Consequently, a = receiver that signals max-dpb MUST be

       &nbs= p; = capable of storing the following number of decoded = frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; = picture buffer:

 =

       &nbs= p;    Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

 &= nbsp;       Wherein PicWidthInMbs and FrameHeightInMbs are = defined in [1].

 =

       &nbs= p; = The value of max-dpb MUST be greater than or equal to the = value

       &nbs= p; = of MaxDpbMbs * 3 = / 8, wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest = level.

       &nbs= p; = Senders MAY use this knowledge to construct coded video = streams

       &nbs= p; = with improved compression.

 =

       &nbs= p;    Informative = note: This parameter was added primarily to

       &nbs= p;    complement a = similar codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture = buffer stores reconstructed samples.  = There

       &nbs= p;    is no = relationship between the size of the decoded = picture

       &nbs= p;    buffer and the = buffers used in RTP, especially de-interleaving
 and de-jitter = buffers.

 =

       &nbs= p;    Informative note: In = RFC 3984, which this document obsoletes,

 &= nbsp;          the unit of this parameter was 1024 bytes. =  <= /span>The unit has been

 &= nbsp;          changed to 8/3 macroblocks in this = document. <= /span> This reason for

 &= nbsp;          this change was due to the changes from the 2003 = version of the

 &= nbsp;          H.264 specification referenced by RFC 3984 to the = 2010 version

 &= nbsp;          of the H.264 specification referenced by this = document, particularly

 &= nbsp;          the changes to Table A-1 in the H.264 = specification due to addition

 &= nbsp;          of color formats and bit depths not supported = earlier.  <= /span>The

 &= nbsp;          changed semantics of this parameter keeps = backward

 &= nbsp;          compatibility to RFC 3984 and supports all = profiles defined in

 &= nbsp;          the 2010 version of the H.264 = specification.

 =

OLD:

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
(see A.3.1, item i of =
[1]) and in units of 1200 bits
         per second =
for the NAL HRD parameters (see A.3.1, item j =
of
         [1]).
<= pre>        

       &nbs= p; = For example, if a receiver signals capability for Level = 1.2

       &nbs= p; = with max-br equal to 1550, this indicates a maximum = video

       &nbs= p; = bitrate of 1550 kbits/sec for VCL HRD parameters, a = maximum

       &nbs= p; = video bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB = size of 4036458 bits (1550000 / 384000 * 1000 * = 1000).

NEW: (note that the change here = is purely editorial)

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
and in units of 1200 bits per second for the NAL HRD =
parameters.

       &nbs= p; = Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

         

       &nbs= p; = For example, if a receiver signals capability for Main profile = Level 1.2

       &nbs= p; = with max-br equal to 1550, this indicates a maximum = video

       &nbs= p; = bitrate of 1550 kbits/sec for VCL HRD parameters, a = maximum

       &nbs= p; = video bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB = size of 4036458 bits (1550000 / 384000 * 1000 * = 1000).

 

------------------------------------End of = suggested changes = --------------------------------------

 

Best = Regards,

Ye-Kui Wang

 

 

= --Boundary_(ID_Cz/C4zFUj08iMrE/mUMpuQ)-- From Even.roni@huawei.com Fri Apr 15 22:48:15 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 032B0E06EA; Fri, 15 Apr 2011 22:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=-2.045, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpDxiFPbJa0Z; Fri, 15 Apr 2011 22:48:02 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id F1B8DE06C9; Fri, 15 Apr 2011 22:47:59 -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 <0LJQ008M3DFWUX@szxga05-in.huawei.com>; Sat, 16 Apr 2011 13:47:57 +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 <0LJQ00MRJDFVPL@szxga05-in.huawei.com>; Sat, 16 Apr 2011 13:47:56 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-50.red.bezeqint.net [79.178.14.50]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJQ00EBYDDT1Y@szxml12-in.huawei.com>; Sat, 16 Apr 2011 13:47:55 +0800 (CST) Date: Sat, 16 Apr 2011 08:45:50 +0300 From: Roni Even In-reply-to: To: 'Roni Even' , payload@ietf.org, avt@ietf.org, 'Robert Sparks' Message-id: <023101cbfbf9$a28673a0$e7935ae0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/bJYlFVwCQyUX8FD1CAjWw)" Content-language: en-us Thread-index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIpRIcyxQgAB6IDCAFyl0YA== References: Cc: "'Botzko, Stephen'" , "'Patrick Luthi \(pluthi\)'" Subject: Re: [AVTCORE] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts - concluded 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, 16 Apr 2011 05:48:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/bJYlFVwCQyUX8FD1CAjWw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The WGLC is conclude. There were no objections noted, so please go ahead and submit the proposed changes to the RFC Editor for publication. Roni Even From: Roni Even [mailto:even.roni@huawei.com] Sent: Friday, April 01, 2011 3:06 PM To: 'payload@ietf.org'; 'avt@ietf.org' Cc: 'Ye-Kui Wang'; 'Ali C. Begen (abegen)'; 'Botzko, Stephen'; 'Patrick Luthi (pluthi)' Subject: WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts Hi, Sorry for the double posting. We found some issues with the text in RFC3984bis which affect also H264RCDO and SVC. The issues were discovered by the RFC editor so we can fix it by doing the changes marked bellow. I would like to start a two weeks WGLC on the text in this email in order to allow enough time for people to review. Please send any comments till April 15th. If there will have no more issues we will submit this changes to the RFC editor as part of the AUTH48. Thanks Roni Even This is the text from YK: Please find below the suggested changes for RFC3984bis with some informative notes added to the semantics of max-cpb, max-dpb, and max-cr. The added notes are all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared to the previous post). These additions should address the specific concerns expressed so far. I hope we can close the issue and let the RFC publication process to proceed. As I said earlier, the changes to the SVC and RCDO payload drafts are very similar. ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. NEW: (The nature of this change as follows. If the semantics remain unchanged while the reference to H.264 spec is the 2010 version, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the 2010 H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change hence there is no backward compatibility issue.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. Informative note: In RFC 3984, which this document obsoletes, the unit of this parameter was 1024 bytes. The unit has been changed to 8/3 macroblocks in this document. This reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition of color formats and bit depths not supported earlier. The changed semantics of this parameter keeps backward compatibility to RFC 3984 and supports all profiles defined in the 2010 version of the H.264 specification. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). . For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial) max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). . For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- Best Regards, Ye-Kui Wang --Boundary_(ID_/bJYlFVwCQyUX8FD1CAjWw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

The = WGLC is conclude. There were no objections noted, so please go ahead and = submit the proposed changes to the RFC Editor for = publication.

 

Roni = Even

 

From:= = Roni Even [mailto:even.roni@huawei.com]
Sent: Friday, April = 01, 2011 3:06 PM
To: 'payload@ietf.org'; = 'avt@ietf.org'
Cc: 'Ye-Kui Wang'; 'Ali C. Begen (abegen)'; = 'Botzko, Stephen'; 'Patrick Luthi (pluthi)'
Subject: WGLC on = Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

Hi,

Sorry for the double = posting.

We found some issues with the text in RFC3984bis = which affect also H264RCDO and SVC. The issues were discovered by the = RFC editor so we can fix it by doing the changes marked bellow. I would = like to start a two weeks WGLC on the text in this email in order to = allow enough time for people to review.

Please send any comments = till April 15th. If there will have no more issues we will = submit this changes to the RFC editor as part of the = AUTH48.

Thanks

Roni = Even

 

This is the text from = YK:

Please find below the suggested changes for = RFC3984bis with some informative notes added to the semantics of = max-cpb, max-dpb, and max-cr. The added notes are all highlighted in = yellow. There are no other additional changes besides the addition of = these notes (compared to the previous post). These additions should = address the specific concerns expressed so far. I hope we can close the = issue and let the RFC publication process to proceed. =

 

As I said earlier, the = changes to the SVC and RCDO payload drafts are very similar. =

 

------------------------------------Start of = suggested changes = --------------------------------------

 

Section 8.1:

OLD:

      =
profile-level-id:
         A base16 =
[7] (hexadecimal) representation of the =
following
         three =
bytes in the sequence parameter set NAL unit is =
specified
         in [1]: 1) =
profile_idc, 2) a byte herein referred to as
         =
profile-iop, composed of the values of =
constraint_set0_flag,
         =
constraint_set1_flag,constraint_set2_flag,
         =
constraint_set3_flag, and reserved_zero_4bits in =
bit-
         =
significance order, starting from the most-significant bit, =
and
         3) =
level_idc.  Note =
that reserved_zero_4bits is required to be
         equal to 0 =
in [1], but other values for it may be specified =
in
         the future =
by ITU-T or ISO/IEC.

 NEW: (note that the change here = is purely editorial)

      = profile-level-id:

       &nbs= p; = A base16 [7] (hexadecimal) representation of the = following

       &nbs= p; = three bytes in the sequence parameter set NAL unit is = specified

       &nbs= p; = in [1]: 1) profile_idc, 2) a byte herein referred to = as

       &nbs= p; = profile-iop, composed of the values of = constraint_set0_flag,

       &nbs= p; = constraint_set1_flag,constraint_set2_flag,

       &nbs= p; = constraint_set3_flag, constraint_set4_flag, = constraint_set5_flag,

 <= /span>and reserved_zero_2bits in = bit-significance order, starting from the most-significant bit, = and

       &nbs= p; = 3) level_idc.  Note that = reserved_zero_2bits is required to be

       &nbs= p; = equal to 0 in [1], but other values for it may be specified = in

        =  the future by = ITU-T or ISO/IEC.

 

OLD:

         For =
example, in the table above, profile_idc equal to =
58
         (Extended) =
with profile-iop equal to 11xx0000 indicates =
the
         same =
sub-profile corresponding to profile_idc equal to =
42
         (Baseline) =
with profile-iop equal to x1xx0000.  Note that other
         =
combinations of profile_idc and profile-iop (not listed =
in
         Table 5) =
may represent a sub-profile equivalent to the =
common
         subset of =
coding tools for more than one profile.  Note =
also
         that a =
decoder conforming to a certain profile may be able =
to
         decode =
bitstreams conforming to other profiles.  For example, =
a
     &nbs=
p;   =
decoder conforming to the High 4:4:4 profile, at a =
certain
     &nbs=
p;   =
level, must be able to decode bitstreams conforming to =
the
     &nbs=
p;   =
Constrained Baseline, Main, High, High 10, or High =
4:2:2
     &nbs=
p;   =
profile at the same or a lower level.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; = For example, in the table above, profile_idc equal to = 58

       &nbs= p; = (Extended) with profile-iop equal to 11xx0000 indicates = the

       &nbs= p; = same sub-profile corresponding to profile_idc equal to = 42

       &nbs= p; = (Baseline) with profile-iop equal to x1xx0000.  Note that = other

       &nbs= p; = combinations of profile_idc and profile-iop (not listed = in

       &nbs= p; = Table 5) may represent a sub-profile equivalent to the = common

       &nbs= p; = subset of coding tools for more than one profile.  Note = also

         that a decoder = conforming to a certain profile may be able to

       &nbs= p; = decode bitstreams conforming to other profiles.

 =

OLD:

         If the =
profile-level-id parameter is used for =
capability
         exchange =
or session setup procedure, it =
indicates the subset of
         coding =
tools, which is equal to the default sub-profile, =
that
         the codec =
supports for both receiving and sending.

 NEW: (note that the change here = is purely editorial)

       &nbs= p; = If the profile-level-id parameter is used for = capability

       &nbs= p; = exchange or session setup, it indicates the subset = of

       &nbs= p; = coding tools, which is equal to the default sub-profile, = that

       &nbs= p; = the codec supports for both receiving and = sending.

 

OLD: =

      max-cpb: The = value of max-cpb is an integer indicating the = maximum

       &nbs= p; = coded picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; = parameters (see A.3.1, = item i of [1]) and in units of 1200 bits

       &nbs= p; = for the NAL HRD parameters (see A.3.1, item j of = [1]).

NEW: (note that the change here = is purely editorial)

      max-cpb: The = value of max-cpb is an integer indicating the = maximum

       &nbs= p; = coded picture buffer size in units of 1000 bits for the VCL = HRD

       &nbs= p; = parameters and in units of 1200 bits for the NAL HRD parameters. =
       &nbs= p; = Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

 =

OLD:

      max-dpb: The = value of max-dpb is an integer indicating the = maximum

       &nbs= p; = decoded picture buffer size in units of 1024 bytes.  The = max-

       &nbs= p; = dpb parameter signals that the receiver has more memory = than

       &nbs= p; = the minimum amount of decoded picture buffer memory required = by

       &nbs= p; = the signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; = When max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; = NAL unit streams that conform to the signaled highest = level,

       &nbs= p; = with the exception that the MaxDPB value in Table A-1 of = [1]

       &nbs= p; = for the signaled highest level is replaced with the value = of

       &nbs= p; = max-dpb.  Consequently, a = receiver that signals max-dpb MUST be

       &nbs= p; = capable of storing the following number of decoded = frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; = picture buffer:

 =

       &nbs= p;    Min(1024 * = max-dpb / ( PicWidthInMbs * FrameHeightInMbs *

       &nbs= p;    256 * = ChromaFormatFactor ), 16)

 =

       &nbs= p; = PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor = are

         defined in = [1].

 =

       &nbs= p; = The value of max-dpb MUST be greater than or equal to the = value

       &nbs= p; = of MaxDPB given in Table A-1 of [1] for the highest = level.

       &nbs= p; = Senders MAY use this knowledge to construct coded video = streams

       &nbs= p; = with improved compression.

 =

       &nbs= p;    Informative = note: This parameter was added primarily to

       &nbs= p;    complement a = similar codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture = buffer stores reconstructed samples.  = There

       &nbs= p;    is no = relationship between the size of the decoded = picture

       &nbs= p;    buffer and the = buffers used in RTP, especially de-interleaving
 and de-jitter = buffers.

 =

NEW: (The nature of this change = as follows. If the semantics remain unchanged while the reference to = H.264 spec  is the 2010 version, then the semantics of max-dpb is = simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are = not found in the 2010 H.264 spec any more. Note that compared to RFC = 3984, the bits on the wire do not change hence there is no backward = compatibility issue.)

      max-dpb: The = value of max-dpb is an integer indicating the = maximum

       &nbs= p; = decoded picture buffer size in units of 8/3 = macroblocks.  The = max-

       &nbs= p; = dpb parameter signals that the receiver has more memory = than

       &nbs= p; = the minimum amount of decoded picture buffer memory required = by

       &nbs= p; = the signaled highest level conveyed in the value of = the

       &nbs= p; = profile-level-id parameter or the max-recv-level = parameter.

       &nbs= p; = When max-dpb is signaled, the receiver MUST be able to = decode

       &nbs= p; = NAL unit streams that conform to the signaled highest = level,

       &nbs= p; = with the exception that the MaxDpbMbs value in = Table A-1 of [1]

 &= nbsp;       for the signaled highest level is replaced with = the value of

 &= nbsp;       max-dpb * 3 / 8.  Consequently, a = receiver that signals max-dpb MUST be

       &nbs= p; = capable of storing the following number of decoded = frames,

       &nbs= p; = complementary field pairs, and non-paired fields in its = decoded

       &nbs= p; = picture buffer:

 =

       &nbs= p;    Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

 &= nbsp;       Wherein PicWidthInMbs and FrameHeightInMbs are = defined in [1].

 =

       &nbs= p; = The value of max-dpb MUST be greater than or equal to the = value

       &nbs= p; = of MaxDpbMbs * 3 = / 8, wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest = level.

       &nbs= p; = Senders MAY use this knowledge to construct coded video = streams

       &nbs= p; = with improved compression.

 =

       &nbs= p;    Informative = note: This parameter was added primarily to

       &nbs= p;    complement a = similar codepoint in the ITU-T Recommendation

       &nbs= p;    H.245, so as to = facilitate signaling gateway designs.  = The

       &nbs= p;    decoded picture = buffer stores reconstructed samples.  = There

       &nbs= p;    is no = relationship between the size of the decoded = picture

       &nbs= p;    buffer and the = buffers used in RTP, especially de-interleaving
 and de-jitter = buffers.

 =

       &nbs= p;    Informative note: In = RFC 3984, which this document obsoletes,

 &= nbsp;          the unit of this parameter was 1024 bytes. =  <= /span>The unit has been

 &= nbsp;          changed to 8/3 macroblocks in this = document. <= /span> This reason for

 &= nbsp;          this change was due to the changes from the 2003 = version of the

 &= nbsp;          H.264 specification referenced by RFC 3984 to the = 2010 version

 &= nbsp;          of the H.264 specification referenced by this = document, particularly

 &= nbsp;          the changes to Table A-1 in the H.264 = specification due to addition

 &= nbsp;          of color formats and bit depths not supported = earlier.  <= /span>The

 &= nbsp;          changed semantics of this parameter keeps = backward

 &= nbsp;          compatibility to RFC 3984 and supports all = profiles defined in

 &= nbsp;          the 2010 version of the H.264 = specification.

 =

OLD:

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
(see A.3.1, item i of =
[1]) and in units of 1200 bits
         per second =
for the NAL HRD parameters (see A.3.1, item j =
of
         [1]).
<= pre>        

       &nbs= p; = For example, if a receiver signals capability for Level = 1.2

       &nbs= p; = with max-br equal to 1550, this indicates a maximum = video

       &nbs= p; = bitrate of 1550 kbits/sec for VCL HRD parameters, a = maximum

       &nbs= p; = video bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB = size of 4036458 bits (1550000 / 384000 * 1000 * = 1000).

NEW: (note that the change here = is purely editorial)

      max-br: The value of max-br =
is an integer indicating the maximum
         video =
bitrate in units of 1000 bits per second for the VCL =
HRD
         parameters =
and in units of 1200 bits per second for the NAL HRD =
parameters.

       &nbs= p; = Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in [1]).

         

       &nbs= p; = For example, if a receiver signals capability for Main profile = Level 1.2

       &nbs= p; = with max-br equal to 1550, this indicates a maximum = video

       &nbs= p; = bitrate of 1550 kbits/sec for VCL HRD parameters, a = maximum

       &nbs= p; = video bitrate of 1860 kbits/sec for NAL HRD parameters, and = a

         CPB = size of 4036458 bits (1550000 / 384000 * 1000 * = 1000).

 

------------------------------------End of = suggested changes = --------------------------------------

 

Best = Regards,

Ye-Kui Wang

 

 

= --Boundary_(ID_/bJYlFVwCQyUX8FD1CAjWw)-- From magnus.westerlund@ericsson.com Mon Apr 18 01:02:30 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1A392E07B0; Mon, 18 Apr 2011 01:02:30 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGjGGnz2r+My; Mon, 18 Apr 2011 01:02:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id C2781E0790; Mon, 18 Apr 2011 01:02:25 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-51-4dabf010adb7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F7.41.09202.010FBAD4; Mon, 18 Apr 2011 10:02:25 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Apr 2011 10:02:24 +0200 Message-ID: <4DABF00F.6080600@ericsson.com> Date: Mon, 18 Apr 2011 10:02:23 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing References: <012101cbfb81$84a04500$8de0cf00$@com> In-Reply-To: <012101cbfb81$84a04500$8de0cf00$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-6man-udpchecksums@tools.ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , "avt@ietf.org" , "ipv6@ietf.org" Subject: Re: [AVTCORE] RTP and UDP checksum=0 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, 18 Apr 2011 08:02:30 -0000 Dan Wing skrev 2011-04-15 17:26: > Observation: tunneled packets have two elements actively > deciding checksum=0 is okay. Those elements are the > tunnel encap and tunnel decap. > > Question: Should non-tunneled UDP flows, *established with > explicit signaling*, also be allowed to decide that checksum=0 > is okay? For example, an RTP-over-UDP flow established > with RTSP or SIP signaling. Some RTP traffic includes its > own checksum at the application layer (e.g., SRTP authentication) > and gains little or no benefit to a UDP checksum. Near as I > can discern, SIP-signaled flows meet all of the constraints > discussed in > http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 Dan, I agree that SRTP would be safe to use without checksum also in v6. However, using non-secured RTP without checksums are "a very bad idea" (TM). Also, if you are an end-point generating RTP flows then the UDP checksum overhead is generally not that big of an issue compared to all media processing. I think the only node that where this could make any significant difference are in a transport translator, which only relays an incoming packets to a number of other unicast addresses. I do however, see a need for a number of additional mechanisms, at least signalling if one wants do do this for RTP with SRTP integrity protection enabled. SIP/SDP signalling and maybe also an additional ICE STUN check to verify the capability prior to using it to avoid loss due to middleboxes that doesn't handle zero UDP checksum with v6. My general fear is that the usage of zero checksum for IPv6 is done without thinking and that it is similar in behavior to IPv4 which it clearly is not, but I guess that is difficult to ensure. Soo frankly, is it really worth it for RTP? I guess what you say comes down to if we should ensure that the text is generalized enough that it doesn't only apply to tunnel applications. To me the new specification text before the bullet list appears ok. If only give tunnels as an example. The bullet list also appears ok from a non-tunnel application perspective. So it is likely only the title and some of the introduction text that needs to be ensured that it doesn't only speak of tunneling. I think the authors should ensure this as it appears to be minor modifications and clearly we didn't mean this to only be applicable to one type of applications, but all that meets the considerations. 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 prz@mit.edu Mon Apr 18 01:52:43 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71482E066A; Mon, 18 Apr 2011 01:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8i+W2xIgWVH; Mon, 18 Apr 2011 01:52:38 -0700 (PDT) Received: from mail.philzimmermann.com (mail.philzimmermann.com [99.107.86.52]) by ietfc.amsl.com (Postfix) with ESMTP id 65816E06DB; Mon, 18 Apr 2011 01:52:38 -0700 (PDT) Received: from [192.168.1.146] (c-71-198-217-5.hsd1.ca.comcast.net [71.198.217.5]) (authenticated bits=0) by mail.philzimmermann.com (8.14.4/8.14.3) with ESMTP id p3I8qJ1F039094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2011 01:52:26 -0700 (PDT) (envelope-from prz@mit.edu) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Philip Zimmermann In-Reply-To: <4DABF00F.6080600@ericsson.com> Date: Mon, 18 Apr 2011 01:52:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD70F85-8B35-497C-9FE0-6CE52BE94F43@mit.edu> References: <012101cbfb81$84a04500$8de0cf00$@com> <4DABF00F.6080600@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-6man-udpchecksums@tools.ietf.org" , "draft-ietf-6man-udpzero@tools.ietf.org" , "avt@ietf.org" , Dan Wing , "ipv6@ietf.org" Subject: Re: [AVTCORE] RTP and UDP checksum=0 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, 18 Apr 2011 08:52:43 -0000 I think it should use the checksum field. It is generally a bad idea = for one layer to neglect its usual built-in error-checking duties = because it assumes another layer will handle it. Let me draw an analogy from the crypto world, we don't use weak 56-bit = DES as our PGP keys because we assume that the email message will pass = through a strong SSL tunnel, so why bother to work so hard to protect = the message with strong keys in PGP? We see to our own layer's = security, without getting lazy and letting another layer handle it. = What if the other layer is not used? What if the email is not passing = through SSL? Oops. Every layer should try to look after its own obligations to protect = packets. If UDP was originally designed to carry checksums, we should = generate them all the time in the UDP layer. Just my two cents. On Apr 18, 2011, at 1:02 AM, Magnus Westerlund wrote: > Dan Wing skrev 2011-04-15 17:26: >> Observation: tunneled packets have two elements actively=20 >> deciding checksum=3D0 is okay. Those elements are the=20 >> tunnel encap and tunnel decap. >>=20 >> Question: Should non-tunneled UDP flows, *established with=20 >> explicit signaling*, also be allowed to decide that checksum=3D0=20 >> is okay? For example, an RTP-over-UDP flow established=20 >> with RTSP or SIP signaling. Some RTP traffic includes its >> own checksum at the application layer (e.g., SRTP authentication) >> and gains little or no benefit to a UDP checksum. Near as I >> can discern, SIP-signaled flows meet all of the constraints >> discussed in=20 >> http://tools.ietf.org/html/draft-ietf-6man-udpzero-02#section-5.1 >=20 > Dan, >=20 > I agree that SRTP would be safe to use without checksum also in v6. > However, using non-secured RTP without checksums are "a very bad idea" > (TM). >=20 > Also, if you are an end-point generating RTP flows then the UDP = checksum > overhead is generally not that big of an issue compared to all media > processing. I think the only node that where this could make any > significant difference are in a transport translator, which only = relays > an incoming packets to a number of other unicast addresses. >=20 > I do however, see a need for a number of additional mechanisms, at = least > signalling if one wants do do this for RTP with SRTP integrity > protection enabled. SIP/SDP signalling and maybe also an additional = ICE > STUN check to verify the capability prior to using it to avoid loss = due > to middleboxes that doesn't handle zero UDP checksum with v6. >=20 > My general fear is that the usage of zero checksum for IPv6 is done > without thinking and that it is similar in behavior to IPv4 which it > clearly is not, but I guess that is difficult to ensure. Soo frankly, = is > it really worth it for RTP? >=20 > I guess what you say comes down to if we should ensure that the text = is > generalized enough that it doesn't only apply to tunnel applications. = To > me the new specification text before the bullet list appears ok. If = only > give tunnels as an example. The bullet list also appears ok from a > non-tunnel application perspective. So it is likely only the title and > some of the introduction text that needs to be ensured that it doesn't > only speak of tunneling. >=20 > I think the authors should ensure this as it appears to be minor > modifications and clearly we didn't mean this to only be applicable to > one type of applications, but all that meets the considerations. >=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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt ------------------------------------------------ Philip R Zimmermann prz@mit.edu (spelled with 2 n's) http://philzimmermann.com tel +1 831 425-7524 http://zfone.com From magnus.westerlund@ericsson.com Mon Apr 18 07:49:16 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0494EE0712 for ; Mon, 18 Apr 2011 07:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.558 X-Spam-Level: X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH3UKQBMQE47 for ; Mon, 18 Apr 2011 07:49:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfc.amsl.com (Postfix) with ESMTP id 26832E06D9 for ; Mon, 18 Apr 2011 07:49:14 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-3c-4dac4f696edb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.5B.09202.96F4CAD4; Mon, 18 Apr 2011 16:49:14 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Apr 2011 16:49:13 +0200 Message-ID: <4DAC4F69.1080707@ericsson.com> Date: Mon, 18 Apr 2011 16:49:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [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: Mon, 18 Apr 2011 14:49:16 -0000 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 ---------------------------------------------------------------------- From peter.musgrave@magorcorp.com Mon Apr 18 07:56:30 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 65D66E0712 for ; Mon, 18 Apr 2011 07:56:30 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJG+asWXUO2G for ; Mon, 18 Apr 2011 07:56:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfc.amsl.com (Postfix) with ESMTP id C200EE068E for ; Mon, 18 Apr 2011 07:56:29 -0700 (PDT) Received: by yxk30 with SMTP id 30so2156745yxk.31 for ; Mon, 18 Apr 2011 07:56:29 -0700 (PDT) Received: by 10.91.159.29 with SMTP id l29mr4435013ago.149.1303138587945; Mon, 18 Apr 2011 07:56:27 -0700 (PDT) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id 23sm5523267ano.33.2011.04.18.07.56.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2011 07:56:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Peter Musgrave In-Reply-To: <4DAC4F69.1080707@ericsson.com> Date: Mon, 18 Apr 2011 10:56:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DAC4F69.1080707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: 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: Mon, 18 Apr 2011 14:56:30 -0000 I am interested in the work and can continue to review subsequent = versions of the doc. Peter Musgrave On 2011-04-18, at 10:49 AM, Magnus Westerlund wrote: > WG, >=20 > 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/.= >=20 > 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. >=20 > This call runs for 2 weeks until Wednesday the 4th of May. >=20 > Regards >=20 > Magnus Westerlund >=20 > 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 From casner@acm.org Mon Apr 18 12:38:21 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 32335E0723 for ; Mon, 18 Apr 2011 12:38:21 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHfQZPGjgH4U for ; Mon, 18 Apr 2011 12:38:20 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfc.amsl.com (Postfix) with ESMTP id CE8CEE070C for ; Mon, 18 Apr 2011 12:38:19 -0700 (PDT) Received: from hsa.packetdesign.com (hsa.packetdesign.com [192.168.0.86]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p3IJcDe7010612; Mon, 18 Apr 2011 12:38:13 -0700 Date: Mon, 18 Apr 2011 12:38:13 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund In-Reply-To: <4DAC4F69.1080707@ericsson.com> Message-ID: References: <4DAC4F69.1080707@ericsson.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Mon, 18 Apr 2011 19:38:21 -0000 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=187042 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 rachel.huang@huawei.com Mon Apr 18 17:16:22 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 98D8CE0708 for ; Mon, 18 Apr 2011 17:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Adm31tKESHn9 for ; Mon, 18 Apr 2011 17:16:22 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfc.amsl.com (Postfix) with ESMTP id 0EF57E06EC for ; Mon, 18 Apr 2011 17:16:17 -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 <0LJV00JR4I31EI@szxga05-in.huawei.com> for avt@ietf.org; Tue, 19 Apr 2011 08:16:14 +0800 (CST) Received: from szxeml205-edg.china.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 <0LJV00D9CI31YH@szxga05-in.huawei.com> for avt@ietf.org; Tue, 19 Apr 2011 08:16:13 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 19 Apr 2011 08:16:09 +0800 Received: from SZXEML505-MBS.china.huawei.com ([169.254.1.24]) by SZXEML402-HUB.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 19 Apr 2011 08:16:08 +0800 Date: Tue, 19 Apr 2011 00:16:07 +0000 From: "Rachel Huang(yihong)" In-reply-to: <4DAC4F69.1080707@ericsson.com> X-Originating-IP: [10.138.41.55] To: Magnus Westerlund Message-id: <51E6A56BD6A85142B9D172C87FC3ABBB06ED52@SZXEML505-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization Thread-index: AQHL/diNNKvax3ngMkWr0VWEySgiwJRkUbiw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DAC4F69.1080707@ericsson.com> Cc: 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, 19 Apr 2011 00:16:22 -0000 SSdtIGludGVyZXN0ZWQgYW5kIHdvdWxkIGxpa2UgdG8gY29udHJpYnV0ZS4NCg0KQmVzdCBSZWdh cmRzIQ0KUmFjaGVsDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogYXZ0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hZ251 cyBXZXN0ZXJsdW5kDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQ05pyIMTjml6UgMjI6NDkNCuaUtuS7 tuS6ujogSUVURiBBVlRDb3JlIFdHDQrkuLvpopg6IFtBVlRDT1JFXSBDYWxsIGZvciBXRyBpdGVt IG9uIFJUQ1AgZm9yIGludGVyLWRlc3RpbmF0aW9uIG1lZGlhIHN5bmNocm9uaXphdGlvbg0KDQpX RywNCg0KQXQgdGhlIFdHIG1lZXRpbmcgaW4gUHJhZ3VlIHdlIGhhZCBhIHNob3cgb2YgaGFuZHMg aWYgd2Ugc2hvdWxkIGNyZWF0ZSBhDQpXRyB3b3JrIGl0ZW0gZm9yIFJUQ1AgZm9yIGludGVyLWRl c3RpbmF0aW9uIG1lZGlhIHN5bmNocm9uaXphdGlvbi4gQWxvbmcNCnRoZSBsaW5lcyBkZXNjcmli ZWQgYnkNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyYW5kZW5idXJn LWF2dGNvcmUtcnRjcC1mb3ItaWRtcy8uDQoNClRoZXJlIHdoZXJlIDUgcGVyc29ucyBpbiB0aGUg cm9vbSBpbmRpY2F0aW5nIGludGVyZXN0LiBXZSBub3cgd291bGQgbGlrZQ0KdG8ganVkZ2UgdGhl IGludGVyZXN0IG9uIHRoZSBtYWlsaW5nIGxpc3QgZm9yIGEgbmV3IFdHIGl0ZW0uIFBsZWFzZQ0K aW5kaWNhdGUgeW91ciBzdXBwb3J0IGFuZCB3aWxsaW5nbmVzcyB0byBjb250cmlidXRlLiBJZiB5 b3UgdGhpbmsgaXQNCnNob3VsZG4ndCBiZSBkb25lIHBsZWFzZSB2b2ljZSB0aGF0IG9waW5pb24g YWxzby4NCg0KVGhpcyBjYWxsIHJ1bnMgZm9yIDIgd2Vla3MgdW50aWwgV2VkbmVzZGF5IHRoZSA0 dGggb2YgTWF5Lg0KDQpSZWdhcmRzDQoNCk1hZ251cyBXZXN0ZXJsdW5kDQoNCkFWVENvcmUgY2hh aXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCk11bHRpbWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNl YXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8 IFBob25lICArNDYgMTAgNzE0ODI4Nw0KRsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1v YmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86 IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5z cG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYXZ0DQo= From Even.roni@huawei.com Mon Apr 18 23:44:43 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C9151E0680 for ; Mon, 18 Apr 2011 23:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovjr1bIteOHS for ; Mon, 18 Apr 2011 23:44:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 3D2C0E05F5 for ; Mon, 18 Apr 2011 23:44:42 -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 <0LJW0010T00ZP6@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Apr 2011 14:43:47 +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 <0LJW003X300ZM0@szxga04-in.huawei.com> for avt@ietf.org; Tue, 19 Apr 2011 14:43:47 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-29-160.red.bezeqint.net [79.181.29.160]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LJW00E7Z00QG1@szxml11-in.huawei.com>; Tue, 19 Apr 2011 14:43:47 +0800 (CST) Date: Tue, 19 Apr 2011 09:42:40 +0300 From: Roni Even To: 'Qin Wu' Message-id: <036301cbfe5d$004a15e0$00de41a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lEzY3M6dkPLiBwn48hdyYA)" Content-language: en-us Thread-index: Acv+XPjl1bj9a9qzSxKpS1wSJmekCA== Cc: 'Magnus Westerlund' , avt@ietf.org Subject: [AVTCORE] Accepting draft-hunt-avtcore-monarch-02 as a WG document 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, 19 Apr 2011 06:44:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_lEzY3M6dkPLiBwn48hdyYA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Qin, Since there was support and there were no objections or other proposals, please submit draft-hunt-avtcore-monarch-02 as an AVTcore WG document " draft-ietf-avtcore-monarch-00". Please remove Geoff Hunt and Philip Arden from the editor list and add a special acknowledgment about their contribution to the individual draft that enabled this WG document. Thanks Roni Even AVTcore co-chair --Boundary_(ID_lEzY3M6dkPLiBwn48hdyYA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = Qin,

Since there was support and = there were no objections or other proposals, please submit = draft-hunt-avtcore-monarch-02 as an AVTcore WG document =  " = draft-ietf-avtcore-monarch-00".=

Please  remove Geoff Hunt =
and Philip Arden from the editor list and add a special acknowledgment =
about their contribution to the individual draft that enabled this WG =
document.

&nbs= p;

Thanks
Roni Even
AVTcore co-chair

 

= --Boundary_(ID_lEzY3M6dkPLiBwn48hdyYA)-- From magnus.westerlund@ericsson.com Wed Apr 20 04:01:37 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 776B8E06A3 for ; Wed, 20 Apr 2011 04:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQlqGw8KNL6z for ; Wed, 20 Apr 2011 04:01:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id B19DAE0695 for ; Wed, 20 Apr 2011 04:01:36 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-5b-4daebd0fceb9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.CE.11171.F0DBEAD4; Wed, 20 Apr 2011 13:01:36 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Apr 2011 13:01:35 +0200 Message-ID: <4DAEBD0F.6040600@ericsson.com> Date: Wed, 20 Apr 2011 13:01:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Joerg Ott , Stephan Wenger , Noriyuki SATO , carsten.burmeister@eu.panasonic.com, Jose Rey , IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Oversigt regarding pmembers update in Section 3.5.3 in RFC 4585 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, 20 Apr 2011 11:01:37 -0000 Hi, A Colleague to mine that are doing an AVPF implementation raised a question which I personally believe is an oversight in RFC 4585. Section 3.5.3 says in the last paragraph: In all the four cases above (1, 2a, 2b, and 2c), allow_early MUST be set to TRUE (possibly after sending the Regular RTCP packet) and tp and tn MUST be updated following the rules of [1] except for the five second minimum. However, based on that the update of tp and tn is intended to make the rtcp sender behave as it sent an RTCP regular packet, independently if an actual packet was sent or not. Then the implementation should update the pmembers variable also, as this is what happens every time an regular RTCP packet is sent using only the RFC 3550 rules. Can the authors please confirm my reasoning? And if that is the case, we should submit an Errata. 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 Wed Apr 20 04:59:05 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 42E2AE0611 for ; Wed, 20 Apr 2011 04:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQU7-MsIp2NU for ; Wed, 20 Apr 2011 04:59:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id 0C485E05F5 for ; Wed, 20 Apr 2011 04:59:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-a4-4daeca87313a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 58.D7.11171.78ACEAD4; Wed, 20 Apr 2011 13:59:03 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Apr 2011 13:59:02 +0200 Message-ID: <4DAECA86.5080801@ericsson.com> Date: Wed, 20 Apr 2011 13:59:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] ECN for RTP: Packet loss counters 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, 20 Apr 2011 11:59:05 -0000 Hi, As discussed in Prague the preference to resolve the issue with packet loss counter saturation was to redefine the counters. We have a proposal for that ready. There is one potential issue that we in addition would like to get feedback on. Namely if the packet format with bad alignment is to ugly and if it is worth spending 4 more bytes on this to get alignment between the XR and RTCP feedback packet. The XR packet is proposed to look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Media Sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT (0) Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT (1) Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Counter | not-ECT Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Packet Counter | Duplication Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Variant 1 of the Feedback packet: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Highest Sequence Number | ECT (0) Ctr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT (0) Counter cont. | ECT (1) Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Counter | not-ECT Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Packet Counter | Duplication Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Variant 2 of the feedback packet: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Highest Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT (0) Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ECT (1) Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CE Counter | not-ECT Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Packet Counter | Duplication Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So variant 2 uses 4 bytes more. But has the advantage of being aligned with the XR format and not require bit-shifts to get to the values of ECT fields. I think going with alternative 2 is preferable. The field definitions are for variant 1: ECT(0) Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of ECT(0). The receiver should keep track of this value using a local representation that is at least 32-bits, and only include the 20-bits with least significance. In other words, the field will wrap if more than 1048576 packets have been received. ECT(1) Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of ECT(1). The receiver should keep track of this value using a local representation that is at least 32-bits, and only include the 20-bits with least significance. In other words, the field will wrap if more than 1048576 packets have been received. CE Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that were ECN-CE marked, including ECN-CE marks in any duplicate packets. The receiver should keep track of this value using a local representation that is longer than 16-bits, and only include the 16-bits with least significance. In other words, the field will wrap if more than 65535 packets has been received. not-ECT Counter: The cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of not-ECT. The receiver should keep track of this value using a local representation that is longer than 16- bits, and only include the 16-bits with least significance. In other words, the field will wrap if more than 65535 packets have been received. Lost Packets Counter: The cumulative number of RTP packets that the receiver expected to receive minus the number of packets it actually received that are not a duplicate of an already received packet, from this SSRC since the receiver joined the RTP session. Note that packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The receiver should keep track of this value using a local representation that is longer than 16-bits, and only include the 16-bits with least significance. In other words, the field will wrap if more than 65535 packets have been received. Duplication Counter: The cumulative number of RTP packets received that are a duplicate of an already received packet from this SSRC since the receiver joined the RTP session. The receiver should keep track of this value using a local representation that is longer than 16-bits, and only include the 16-bits with least significance. In other words, the field will wrap if more than 65535 packets have been received. Comments appreciated 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 Wed Apr 20 05:16:39 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 69114E0655 for ; Wed, 20 Apr 2011 05:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77-q996GGiFl for ; Wed, 20 Apr 2011 05:16:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfc.amsl.com (Postfix) with ESMTP id A4958E0611 for ; Wed, 20 Apr 2011 05:16:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-d9-4daecea52781 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E5.6A.11171.5AECEAD4; Wed, 20 Apr 2011 14:16:37 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Apr 2011 14:16:37 +0200 Message-ID: <4DAECEA5.2090305@ericsson.com> Date: Wed, 20 Apr 2011 14:16:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] ECN for RTP: Multiple SSRC init optimization 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, 20 Apr 2011 12:16:39 -0000 Hi, We had some discussion in Prague in the meeting session regarding what optimization one should do for using multiple SSRCs in one RTP session on one end-point, i.e. someone that sends multiple SSRCs from the same transport protocol, port and address when using unicast. It was clear that it was desirable to optimize this case. However, we appear to have issues finding an optimization that is generally applicable to the different potential deployments that can contain unicast. As WG editors we don't see much choice than to continue without an optimization. If someone has a good idea for how it could work please contribute it. 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 pieter.veenstra@kpn.com Wed Apr 20 13:22:47 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E77B1E0737 for ; Wed, 20 Apr 2011 13:22:47 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmJY8tKQkaWu for ; Wed, 20 Apr 2011 13:22:43 -0700 (PDT) Received: from smtpscan-nl3.aots.nl (smtpscan-nl3.aots.nl [145.7.191.45]) by ietfc.amsl.com (Postfix) with ESMTP id 479FCE0669 for ; Wed, 20 Apr 2011 13:22:43 -0700 (PDT) From: To: Date: Wed, 20 Apr 2011 22:22:40 +0200 Thread-Topic: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization Thread-Index: AQHL/djSAiA7aKm4B0GRehucJwgXnZRjt3RwgAN9X+A= Message-ID: Accept-Language: nl-NL Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CMAE-Score: 0 X-CMAE-Analysis: v=1.1 cv=8EiUMS7irBH4Q+Nyl/8reWEbgVzqKcR0l6IL9EroaOw= c=1 sm=1 a=7RHrJzGM7lUA:10 a=8nJEP1OIZ-IA:10 a=KSSv6u10oim6zqHvAvXvbw==:17 a=48vgC7mUAAAA:8 a=0FD05c-RAAAA:8 a=qI9UnlQA5IAaCCFXvOkA:9 a=wPNLvfGTeEIA:10 a=f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=flgbAj5NNrzMEus4:21 a=uFdhalSlLVVsxxa1:21 wl=host:4 a=KSSv6u10oim6zqHvAvXvbw==:117 Subject: [AVTCORE] FW: 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, 20 Apr 2011 20:25:07 -0000 Dear all, Herewith I would like to express my support for this new WG item on RTCP in= ter-destination media synchronization. Kind regards, Pieter Veenstra. On 2011-04-18, at 10:49 AM, Magnus Westerlund wrote: > WG, >=20 > At the WG meeting in Prague we had a show of hands if we should create=20 > a WG work item for RTCP for inter-destination media synchronization.=20 > Along the lines described by=20 > https://datatracker.ietf.org/doc/draft-brandenburg-avtcore-rtcp-for-idms/= . >=20 > There where 5 persons in the room indicating interest. We now would=20 > like to judge the interest on the mailing list for a new WG item.=20 > Please indicate your support and willingness to contribute. If you=20 > think it shouldn't be done please voice that opinion also. >=20 > This call runs for 2 weeks until Wednesday the 4th of May. >=20 > Regards >=20 > Magnus Westerlund >=20 > 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=20 > https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From kevin.gross@comcast.net Fri Apr 22 06:01:25 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 124ECE06E9 for ; Fri, 22 Apr 2011 06:01:25 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8B1NxOxUUhi for ; Fri, 22 Apr 2011 06:01:24 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfc.amsl.com (Postfix) with ESMTP id 0209DE067C for ; Fri, 22 Apr 2011 06:01:23 -0700 (PDT) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta10.emeryville.ca.mail.comcast.net with comcast id ad1N1g00217UAYkAAd1PGY; Fri, 22 Apr 2011 13:01:23 +0000 Received: from AVADesk2 ([76.120.76.232]) by omta13.emeryville.ca.mail.comcast.net with comcast id ad1L1g00Z50jATQ8Zd1MYA; Fri, 22 Apr 2011 13:01:22 +0000 From: "Kevin Gross" To: "'IETF AVTCore WG'" References: <4DAC4F69.1080707@ericsson.com> In-Reply-To: <4DAC4F69.1080707@ericsson.com> Date: Fri, 22 Apr 2011 07:01:19 -0600 Organization: AVA Networks Message-ID: <001901cc00ed$602f1810$208d4830$@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: Acv918tASfPd6jaNRZCwYXDe4G9XSADFV1Uw 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: Fri, 22 Apr 2011 13:01:25 -0000 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 From yuepeiyu@huawei.com Fri Apr 22 18:32:26 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8AF51E06A0 for ; Fri, 22 Apr 2011 18:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.051 X-Spam-Level: X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=3.548, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MSE3sgvzlYX for ; Fri, 22 Apr 2011 18:32:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 5BFDEE066B for ; Fri, 22 Apr 2011 18:32:25 -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 <0LK300CSC09VDI@szxga04-in.huawei.com> for avt@ietf.org; Sat, 23 Apr 2011 09:32:19 +0800 (CST) Received: from szxeml201-edg.china.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 <0LK300G9709UHA@szxga04-in.huawei.com> for avt@ietf.org; Sat, 23 Apr 2011 09:32:19 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 23 Apr 2011 09:32:22 +0800 Received: from SZXEML503-MBS.china.huawei.com ([169.254.3.46]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Sat, 23 Apr 2011 09:32:18 +0800 Date: Sat, 23 Apr 2011 01:32:17 +0000 From: "Roy Yue(PeiYu)" In-reply-to: <4DAC4F69.1080707@ericsson.com> X-Originating-IP: [10.138.73.89] To: Magnus Westerlund , IETF AVTCore WG Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [AVTCORE] Call for WG item on RTCP for inter-destination media synchronization Thread-index: Acv92GzH/vPsvI2yRH6howpER1UdNADfbdAw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4DAC4F69.1080707@ericsson.com> 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: Sat, 23 Apr 2011 01:32:26 -0000 SGVsbG8sDQoNCkkgd291bGQgbGlrZSB0byBzdXBwb3J0IHRoZSB3b3JrIGFuZCB3aWxsIGNvbnRy aWJ1dGUgd2l0aCBjb21tZW50cy4NCg0KQmVzdCByZWdhcmRzLA0KUm95DQoNCi0tLS0t6YKu5Lu2 5Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQt Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hZ251cyBXZXN0ZXJsdW5kDQrlj5HpgIHml7bpl7Q6 IDIwMTHlubQ05pyIMTjml6UgMjI6NDkNCuaUtuS7tuS6ujogSUVURiBBVlRDb3JlIFdHDQrkuLvp opg6IFtBVlRDT1JFXSBDYWxsIGZvciBXRyBpdGVtIG9uIFJUQ1AgZm9yIGludGVyLWRlc3RpbmF0 aW9uIG1lZGlhIHN5bmNocm9uaXphdGlvbg0KDQpXRywNCg0KQXQgdGhlIFdHIG1lZXRpbmcgaW4g UHJhZ3VlIHdlIGhhZCBhIHNob3cgb2YgaGFuZHMgaWYgd2Ugc2hvdWxkIGNyZWF0ZSBhDQpXRyB3 b3JrIGl0ZW0gZm9yIFJUQ1AgZm9yIGludGVyLWRlc3RpbmF0aW9uIG1lZGlhIHN5bmNocm9uaXph dGlvbi4gQWxvbmcNCnRoZSBsaW5lcyBkZXNjcmliZWQgYnkNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJyYW5kZW5idXJnLWF2dGNvcmUtcnRjcC1mb3ItaWRtcy8uDQoN ClRoZXJlIHdoZXJlIDUgcGVyc29ucyBpbiB0aGUgcm9vbSBpbmRpY2F0aW5nIGludGVyZXN0LiBX ZSBub3cgd291bGQgbGlrZQ0KdG8ganVkZ2UgdGhlIGludGVyZXN0IG9uIHRoZSBtYWlsaW5nIGxp c3QgZm9yIGEgbmV3IFdHIGl0ZW0uIFBsZWFzZQ0KaW5kaWNhdGUgeW91ciBzdXBwb3J0IGFuZCB3 aWxsaW5nbmVzcyB0byBjb250cmlidXRlLiBJZiB5b3UgdGhpbmsgaXQNCnNob3VsZG4ndCBiZSBk b25lIHBsZWFzZSB2b2ljZSB0aGF0IG9waW5pb24gYWxzby4NCg0KVGhpcyBjYWxsIHJ1bnMgZm9y IDIgd2Vla3MgdW50aWwgV2VkbmVzZGF5IHRoZSA0dGggb2YgTWF5Lg0KDQpSZWdhcmRzDQoNCk1h Z251cyBXZXN0ZXJsdW5kDQoNCkFWVENvcmUgY2hhaXINCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk11bHRpbWVk aWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KRsOk csO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0 IDgwIFN0b2NraG9sbSwgU3dlZGVufCBtYWlsdG86IG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= From mike@johasteener.com Sat Apr 23 00:08:09 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89EEDE06B8 for ; Sat, 23 Apr 2011 00:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wCuUbqNcPbP for ; Sat, 23 Apr 2011 00:08:08 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfc.amsl.com (Postfix) with ESMTP id 80ADFE0690 for ; Sat, 23 Apr 2011 00:08:08 -0700 (PDT) Received: by vxg33 with SMTP id 33so1040038vxg.31 for ; Sat, 23 Apr 2011 00:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johasteener.com; s=google; h=domainkey-signature:references:from:in-reply-to:mime-version:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Yy1aDT1kMDFM5YEl3d0B0+nXUNuufkrzHYG5ENor8Iw=; b=rAnBrak6QJgbITrZpkMLfIBwyP4yU8Z1DfBPOfch4PXYh/AvUpCBlG7/l02fqwoLOS FOQpzodTft5oBbg0Drl00NQzz0lLeNtaE37ZVtVSlLGiiPlVWBGR9BNU19oM6DPRUu18 uk8d2mfXC8VAv9WMxwEAlrPONKy16dTjRXVc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=johasteener.com; s=google; h=references:from:in-reply-to:mime-version:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ZWqWwQeKO0nHcu9ulZ41HVYCSdo4XP6JT+JFEGOwtN/T6zkP4VH7pwbpRP02p/luZZ q0IThaoNkQZFjbbIuv16EC5WkOaws8FJ9bg9tOfPtpNo4MXHFolkUiRpzSu4NrNV0vrI thLafv+nrFdI6y8bxoHR7jIf+3TSqtelelJsk= Received: by 10.52.96.234 with SMTP id dv10mr2785692vdb.19.1303542487660; Sat, 23 Apr 2011 00:08:07 -0700 (PDT) References: From: Michael Johas Teener In-Reply-To: Mime-Version: 1.0 (iPad Mail 8H7) Date: Sat, 23 Apr 2011 00:08:02 -0700 Message-ID: <-1949633842328437546@unknownmsgid> To: "avt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Apr 2011 03:27:07 -0700 Cc: Kevin Gross Subject: Re: [AVTCORE] avt Digest, Vol 84, Issue 15 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, 23 Apr 2011 07:08:09 -0000 I'm also interested and willing. --=20 >From myPad ... less terse than myPhone, but more terse than myBook http://Michael.Johas.Teener.myopenID.com On Apr 22, 2011, at 12:00, "avt-request@ietf.org" wr= ote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/avt > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send avt mailing list submissions to > avt@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/avt > or, via email, send a message with subject or body 'help' to > avt-request@ietf.org > > You can reach the person managing the list at > avt-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of avt digest..." > Today's Topics: > > 1. Re: Call for WG item on RTCP for inter-destination media > synchronization (Kevin Gross) > This is of interest to me and I should be able to review it and contribut= e > comments. > > Kevin Gross > AVA Networks > > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Mag= nus > 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 swc@iis.sinica.edu.tw Mon Apr 25 03:56:43 2011 Return-Path: X-Original-To: avt@ietfc.amsl.com Delivered-To: avt@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0EBE3E0613 for ; Mon, 25 Apr 2011 03:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDm8hVPb9Z+l for ; Mon, 25 Apr 2011 03:56:42 -0700 (PDT) Received: from gate.sinica.edu.tw (gate.sinica.edu.tw [140.109.10.76]) by ietfc.amsl.com (Postfix) with ESMTP id 8A54FE0732 for ; Mon, 25 Apr 2011 03:56:40 -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 ADG06587; Mon, 25 Apr 2011 18:56:36 +0800 (CST) From: "Sheng-Wei \(Kuan-Ta\) Chen" To: Date: Mon, 25 Apr 2011 18:56:34 +0800 Message-ID: <000401cc0337$712b4ed0$5381ec70$@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: AcwDN2/KCULOO5LUQey/lw7Z5r0QWQ== Content-Language: zh-tw x-cr-hashedpuzzle: SF4= ATwf AZjX BW/N DBqv DcvW ERP/ FI1H FKja FOct GeHc H5G5 IPTG Kk+R K5RO LXeR; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {1C968D54-9CD2-4C89-ABC7-67A50449F98F}; cwB3AGMAQABpAGkAcwAuAHMAaQBuAGkAYwBhAC4AZQBkAHUALgB0AHcA; Mon, 25 Apr 2011 10:56:32 GMT; TgBPAFMAUwBEAEEAVgAgADIAMAAxADEAIABDAGEAbABsACAAZgBvAHIAIABQAGEAcgB0AGkAYwBpAHAAYQB0AGkAbwBuAA== x-cr-puzzleid: {1C968D54-9CD2-4C89-ABC7-67A50449F98F} 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: Mon, 25 Apr 2011 10:56:43 -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 June 2 -- 3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ *Registration now open!* Early registration deadline: May 1, 2011 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=20 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=20 Transparent Handover=20 - The Impact of Inter-layer Network Coding on the Relative Performance=20 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=20 game server discovery traffic Session 5: Systems=20 - GPU-based Fast Motion Estimation for On-the-Fly Encoding of=20 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=20 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=20 Highly-Compressed Videos Session 7: Foundation of Media Communication - Scalable Video Transmission: Packet Loss Induced Distortion Modeling = and=20 Estimation - Energy-efficient video streaming from high-speed trains - Celerity: Towards Low-Delay Multi-Party Conferencing Concluding Remarks From wwwrun@rfc-editor.org Mon Apr 25 17:55: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 93F77E0663 for ; Mon, 25 Apr 2011 17:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, 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 oxNYs3LOqDIr for ; Mon, 25 Apr 2011 17:55:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id EBB35E062A for ; Mon, 25 Apr 2011 17:55:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5CA28E076F; Mon, 25 Apr 2011 17:55:33 -0700 (PDT) To: lazzaro@cs.berkeley.edu, johnw@cs.berkeley.edu, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20110426005533.5CA28E076F@rfc-editor.org> Date: Mon, 25 Apr 2011 17:55:33 -0700 (PDT) Cc: rfc-editor@rfc-editor.org, lazzaro@cs.berkeley.edu, avt@ietf.org Subject: [AVTCORE] [Technical Errata Reported] RFC4696 (2790) 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, 26 Apr 2011 00:55:34 -0000 The following errata report has been submitted for RFC4696, "An Implementation Guide for RTP MIDI". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4696&eid=2790 -------------------------------------- Type: Technical Reported by: John Lazzaro Section: 2 Original Text ------------- In Figure 1: rtp_maxptime=0; guardtime=44100; render=synthetic; rinit="audio/asc"; In Figure 2: rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit="audio/asc"; Corrected Text -------------- In Figure 1: rtp_maxptime=0; guardtime=44100; render=synthetic; rinit=audio/asc; In Figure 2: rtp_ptime=0; rtp_maxptime=0; render=synthetic; rinit=audio/asc; Notes ----- The double-quotes around audio/asc in the session descriptions shown in Figures 1 and 2 should not exist; the Corrected Text version shows the legal syntax for rinit assigns. This bug also appears in numerous examples in RFC 4695, an RFC that will soon be obsolete, and replaced with a new RFC whose examples also have this bug fixed (I'm an author of the RFCs). As we are not aware of implementations that use the rinit parameter, we do not expect interoperability concerns due to the buggy examples. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4696 (draft-ietf-avt-rtp-midi-guidelines-15) -------------------------------------- Title : An Implementation Guide for RTP MIDI Publication Date : November 2006 Author(s) : J. Lazzaro, J. Wawrzynek Category : INFORMATIONAL Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From csp@csperkins.org Wed Apr 27 09:51: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 4EC3AE0864 for ; Wed, 27 Apr 2011 09:51:17 -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 cO6lWRhmpzbv for ; Wed, 27 Apr 2011 09:51:16 -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 4F9D1E084A for ; Wed, 27 Apr 2011 09:51:16 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QF7xL-0004Hf-XO; Wed, 27 Apr 2011 16:51:15 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 27 Apr 2011 17:51:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B418AC4-F470-4A18-BB98-48191DA2B6DE@cisco.com> To: David McGrew X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-avtcore-srtp-vbr-audio@tools.ietf.org, AVT WG Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-vbr-audio 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, 27 Apr 2011 16:51:17 -0000 Hi, On 16 Mar 2011, at 13:33, David McGrew wrote: > this draft treats an important topic and is well written. I would = definitely like to see it advance. >=20 > I suggest that Section 5 include a more concrete recommendation on = padding, such as: the payload SHOULD be padded so that its length is a = multiple of 16 octets, which has been shown to greatly reduce the leak = of speech characteristics [spot-me, Section 4]. It depends somewhat on the packet sizes generated by the codec, but yes. = I've just submitted a -01 draft that tries to clarify this issue. > CBR should be defined (I assumed "constant bit rate") Fixed. Thanks for the feedback! --=20 Colin Perkins http://csperkins.org/ From Internet-Drafts@ietf.org Wed Apr 27 10:00: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 98107E0732; Wed, 27 Apr 2011 10:00:04 -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 aulKyHBFKCTN; Wed, 27 Apr 2011 10:00:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB13E06BC; Wed, 27 Apr 2011 10:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110427170003.2247.51618.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2011 10:00:03 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-srtp-vbr-audio-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: Wed, 27 Apr 2011 17:00:04 -0000 --NextPart 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-01.txt Pages : 7 Date : 2011-04-27 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-01.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-srtp-vbr-audio-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-27095130.I-D@ietf.org> --NextPart-- From Christopher.Koehnen@iem.th-mittelhessen.de Wed Apr 27 12:13: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 1CEAAE0769 for ; Wed, 27 Apr 2011 12:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 roC1rW7rfMaP for ; Wed, 27 Apr 2011 12:13:49 -0700 (PDT) Received: from mout2.fh-giessen.de (mout2.fh-giessen.de [212.201.18.46]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBBE06ED for ; Wed, 27 Apr 2011 12:13:48 -0700 (PDT) Received: from mx2.fh-giessen.de (mx2.fh-giessen.de [212.201.18.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mout2.fh-giessen.de (Postfix) with ESMTPS id 60C5CBA247 for ; Wed, 27 Apr 2011 21:13:45 +0200 (CEST) Received: from mailgate-2.its.fh-giessen.de ([212.201.18.14]:39405) by mx2.fh-giessen.de with esmtp (Exim 4.72) (envelope-from ) id 1QFABA-0007eH-95 for avt@ietf.org; Wed, 27 Apr 2011 21:13:40 +0200 Received: from ip-95-223-140-124.unitymediagroup.de ([95.223.140.124] helo=ckoehnenTHINK) by mailgate-2.its.fh-giessen.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1QFAB7-0005Zn-3o for avt@ietf.org; Wed, 27 Apr 2011 21:13:37 +0200 From: =?iso-8859-1?Q?Christopher_K=F6hnen?= To: Date: Wed, 27 Apr 2011 21:13:25 +0200 Message-ID: <00ae01cc050f$2ebfc5b0$8c3f5110$@iem.th-mittelhessen.de> MIME-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcwFDicBhlaDYQiKQEadJaqq9fW5uw== Content-Language: de Subject: [AVTCORE] WG: FW: 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, 27 Apr 2011 19:13:50 -0000 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggkDQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQpDb250ZW50LVRy YW5zZmVyLUVuY29kaW5nOiA4Yml0DQoNCkRlYXIgYWxsLA0KDQpJJ2QgbGlrZSB0byBleHByZXNz IG15IGludGVyZXN0IGFuZCB3aWxsaW5nbmVzcyB0byBzdXBwb3J0IHRvIFJUQ1AgZm9yDQppbnRl ci1kZXN0aW5hdGlvbiBtZWRpYSBzeW5jaHJvbml6YXRpb24uIFRoaXMgV0cgaXRlbSB3b3VsZCBm aWxsIGEgZ2FwIGluDQptdWx0aS1kZXZpY2UgbWVkaWEgc3luY2hyb25pemF0aW9uIGFuZCBjYW4g YXZvaWQgcHJvcHJpZXRhcnkgY2xvc2VkDQpzb2x1dGlvbnMuIEl0J3MgYSByZWFsbHkgbmVlZGVk IGVuYWJsaW5nIHRlY2hub2xvZ3kgZm9yIGh5YnJpZCBtZWRpYSBkZXZpY2UNCmVudmlyb25tZW50 cy4NCg0KS2luZCByZWdhcmRzDQpDaHJpc3RvcGhlciBL9mhuZW4NCg0KRGlwbC4tSW5nLiAoRkgp IENocmlzdG9waGVyIEv2aG5lbg0KVGVjaG5pc2NoZSBIb2Noc2NodWxlIE1pdHRlbGhlc3Nlbg0K VW5pdmVyc2l0eSBvZiBBcHBsaWVkIFNjaWVuY2VzDQpDYW1wdXMgRnJpZWRiZXJnDQpJbmZvcm1h dGlvbiBUZWNobm9sb2d5IHwgRWxlY3RyaWNhbCBFbmdpbmVlcmluZyB8IE1lY2hhdHJvbmljcw0K V2lsaGVsbS1MZXVzY2huZXItU3RyYXNzZSAxMw0KRC02MTE2OSBGcmllZGJlcmcNCg0KDQoNCk9u IDIwMTEtMDQtMTgsIGF0IDEwOjQ5IEFNLCBNYWdudXMgV2VzdGVybHVuZCB3cm90ZToNCg0KPiBX RywNCj4NCj4gQXQgdGhlIFdHIG1lZXRpbmcgaW4gUHJhZ3VlIHdlIGhhZCBhIHNob3cgb2YgaGFu ZHMgaWYgd2Ugc2hvdWxkIGNyZWF0ZQ0KPiBhIFdHIHdvcmsgaXRlbSBmb3IgUlRDUCBmb3IgaW50 ZXItZGVzdGluYXRpb24gbWVkaWEgc3luY2hyb25pemF0aW9uLg0KPiBBbG9uZyB0aGUgbGluZXMg ZGVzY3JpYmVkIGJ5DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJy YW5kZW5idXJnLWF2dGNvcmUtcnRjcC1mb3ItaWRtcy8uDQo+DQo+IFRoZXJlIHdoZXJlIDUgcGVy c29ucyBpbiB0aGUgcm9vbSBpbmRpY2F0aW5nIGludGVyZXN0LiBXZSBub3cgd291bGQNCj4gbGlr ZSB0byBqdWRnZSB0aGUgaW50ZXJlc3Qgb24gdGhlIG1haWxpbmcgbGlzdCBmb3IgYSBuZXcgV0cg aXRlbS4NCj4gUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9ydCBhbmQgd2lsbGluZ25lc3MgdG8g Y29udHJpYnV0ZS4gSWYgeW91DQo+IHRoaW5rIGl0IHNob3VsZG4ndCBiZSBkb25lIHBsZWFzZSB2 b2ljZSB0aGF0IG9waW5pb24gYWxzby4NCj4NCj4gVGhpcyBjYWxsIHJ1bnMgZm9yIDIgd2Vla3Mg dW50aWwgV2VkbmVzZGF5IHRoZSA0dGggb2YgTWF5Lg0KPg0KPiBSZWdhcmRzDQo+DQo+IE1hZ251 cyBXZXN0ZXJsdW5kDQo+DQo+IEFWVENvcmUgY2hhaXINCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBNdWx0 aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4 Mjg3DQo+IEbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5 DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBN YWludGVuYW5jZSBhdnRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hdnQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KAAAAAAAAoIISUjCCA58wggKHoAMCAQICASYwDQYJKoZI hvcNAQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAd BgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20g Um9vdCBDQSAyMB4XDTk5MDcwOTEyMTEwMFoXDTE5MDcwOTIzNTkwMFowcTELMAkGA1UEBhMCREUx HDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBD ZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAqwujNeCLKRSxFIWvPBDkOW81XUqu3ephjZVJ9G9koxpgZqSpQCKE 2dSl5XiTDmgBrblNXDrO07ioQkDfz6O6gllqkhusHJraCCslJ/lpI0fx4Ossepv1EwLQfjR8wp48 AFmr9doM9TI8K6xQ2tbD3oOUyqgMmTIOCEhWW2r72uFYWAFJX3JBPBUGAY5draq4k7TNnuun6Got UjTbOu9cdVHa2/Mx+e5xmDLEVBVEDPmbVe2t3xgIoKOGiknuUwWPGUzV3lh5m9JqHEKrxdWnz2gP luThYZh2YciRfNY+AOKRUIfhnQrmrZfSHcY6fcu82gM01Y5bAfVqB7cWtm5KfwIDAQABo0IwQDAd BgNVHQ4EFgQUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDwYDVR0TBAgwBgEB/wIBBTAOBgNVHQ8BAf8E BAMCAQYwDQYJKoZIhvcNAQEFBQADggEBAJRkWa05ZOcp6xP+WsOLE1fIBCTwdHfAYONn++mJpoO/ loJ8btTDPe+egG67KbSYerE7VOs5F0d+Go4L/B8xWTEEss4X8yzHYjZV4iLYiVW0mEiqZPrWHDbY RHhaWiM6V5f1ejBPrp9qTEsrjqAD4z7gqdTSe9KzqOJyPK2e/4BZ5JtFtPY7sM05GZgy5eohYZDk MSGONLH3LzVKhRDa54o3Ib5ZY+DyhYgxU9RUFIVwefQuBncndS8fuIr5/sW62Dbkg+znZbe/Y1rz Rq+BlDfUQYzWI9Yez/VoG0Rjolq6pzVZoeVwBZsOI1eZlAptujljKIaS8xiE2PvRzwVWZFcwggQh MIIDCaADAgECAgIAxzANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEcMBoGA1UEChMTRGV1 dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRydXN0IENlbnRlcjEjMCEGA1UE AxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMDYxMjE5MTAyOTAwWhcNMTkwNjMwMjM1 OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBL STEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTDllA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHi phTSUqAoI4SLdIkEXlvg4njBeMsWyyg1OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiL amgAmu7cT3ir0sYTm3at7t4m6O8Br3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0Qkj KpY1WCfTdsZxtpAdxO3/NYZ9bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h 1RM9ph8nMM1JVNvJEzSacXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4HZMIHWMHAG A1UdHwRpMGcwZaBjoGGGX2h0dHA6Ly9wa2kudGVsZXNlYy5kZS9jZ2ktYmluL3NlcnZpY2UvYWZf RG93bmxvYWRBUkwuY3JsPy1jcmxfZm9ybWF0PVhfNTA5Ji1pc3N1ZXI9RFRfUk9PVF9DQV8yMB0G A1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT1xfgiXotF2wK syudMzAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBAjANBgkqhkiG9w0BAQUFAAOC AQEAO+Fad8BIF9ypGOyBr1qJ8L0okqbKWRgScOwo8ueuf5Ys5/JdGTH2Eyt0vb2Asrn3Z8k5onk7 4RER7mt4kTN+O18mJ3VTZY4zY+7Pc8OwkiNJIVB1I6EfGOKUhT0/M+l3II2iveahhSlA9j9zMlgN CWum2oVswD+7jWZkViROrg0/MjUBW+mMgtlyWU+xhoXxdIVW5cP4XPON7kezUwVw5+VNimmDKOET CYaeXsjqWB4MH/mk1FoEaP0oPosCtli19qEsN1cAZ6sjaI1jpe+Za1z9S1b2q0CHNNQRkmzsh8UK CwczcrRvDB1ULNhRx8y/MNNDcvEyv4zOSWOoAPfyHDCCBSMwggQLoAMCAQICBAoMsYwwDQYJKoZI hvcNAQEFBQAwWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RG Ti1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0wNzAzMDYwOTI3 MjVaFw0xOTAzMDUwMDAwMDBaMIGTMQswCQYDVQQGEwJERTEpMCcGA1UEChMgRmFjaGhvY2hzY2h1 bGUgR2llc3Nlbi1GcmllZGJlcmcxMjAwBgNVBAMTKUZhY2hob2Noc2NodWxlIEdpZXNzZW4tRnJp ZWRiZXJnIENBIC0gRzAyMSUwIwYJKoZIhvcNAQkBFhZwa2ktZ2lmYkBmaC1naWVzc2VuLmRlMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsoA04nYbnooCxur4yevR/pNPuTC0dLzimPru AD/Xu/6XssfujONvnQfYIZpG6lR8PRvavPQ3eYaVssMiewAHjkshuJYloA9YyRXhLCFGAvV/8feY ZwZVU/kyiQy42MZS5dTsjEHP9dtpxvI9UnIz2UeXuFJMg2lJhXba+usdwJNzBJlqmJuyaoxnZesW EEMwiHuS1k+dHk5tSwSaTI7A2LCfXaGQYG5qgKdFGBvbosVmnbSriwX8gs5J4rUjtHXQ9N/zH0rp zViwhC+drmghaG0zfI1iS3RGTDd9FowjPSCP2HIdl2iNSf9fDZHfgaWdsmhYr04yAhBaLE83QCTR awIDAQABo4IBtTCCAbEwDwYDVR0TAQH/BAUwAwEB/zALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFDTU QsGTo7tXbAx37nyVH0ZDrzDWMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMCEGA1Ud EQQaMBiBFnBraS1naWZiQGZoLWdpZXNzZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8v Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdo dHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGi BggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9i YWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAy LnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3 DQEBBQUAA4IBAQAc13LNfKcg/1BjaBmljsToukjya2GNvOLEIBAh7TIR0EZAQLA3U18BnC/Wvqbz botZdDF1mqAa6Ox4D6oIMc0Kqpeh9YY0JYwSxxt2lOKokrhY3PGTgVPbEgtd5J3HakQCsPmzqM4/ JaEYgRyhofTo9SmwZTB1s4NNXde1l8AM+o+NEVpbU7yUR3FKNg1vLRqjC8os4R99Myj3npmok9bA QzdOl/dFTC0DU5hEP0v3q36iSWjqt9a/MNokFuiLAtMu5Fp+ZUAAEJ4jwxKZrQfMXaOLTpqlIlpY AtZHU8Sp8peyKqyRo4DwY4ty+SWeAoYRJ3kepi/HnY6xz43fl5wFMIIFXzCCBEegAwIBAgIEEbvV cjANBgkqhkiG9w0BAQUFADCBkzELMAkGA1UEBhMCREUxKTAnBgNVBAoTIEZhY2hob2Noc2NodWxl IEdpZXNzZW4tRnJpZWRiZXJnMTIwMAYDVQQDEylGYWNoaG9jaHNjaHVsZSBHaWVzc2VuLUZyaWVk YmVyZyBDQSAtIEcwMjElMCMGCSqGSIb3DQEJARYWcGtpLWdpZmJAZmgtZ2llc3Nlbi5kZTAeFw0x MTA0MDYxMjA5MDdaFw0xNDA0MDUxMjA5MDdaMGYxCzAJBgNVBAYTAkRFMSswKQYDVQQKEyJUZWNo bmlzY2hlIEhvY2hzY2h1bGUgTWl0dGVsaGVzc2VuMQwwCgYDVQQLEwNJRU0xHDAaBgNVBAMTE0No cmlzdG9waGVyIEtvZWhuZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDEjejosla5 XIYQnl+zTsEtxHGjSiXSLVzC4z8aEDJsWS4eWWvXmKf7o8UhiSakRr/FT1VNaE7MkqsqZAMpHnP/ dhpzOZ8vEXEEaI1mom/y9678w1t7qkNRphzrolT3A52bCGAUKRKWUBuGpPg2W3yn2/cks5GAXXI/ jpQ3fg9q9ghbP6zvbqSm7yav+Rnn+EaL457DE3JaaaXJ1Eqhn2pnOLLf4SB/Sbp4bWa9/Z/N5mQ5 fj1iNDQSKfrVivX1ZfF0jmwgHO6hWuNK1zgzi61BBPgmvl4y3BGXUq/kyfwxz+y/IgNU8mhVbBf/ RKSdGA12rG4Qxi8cGW1FaGI7Idb1AgMBAAGjggHlMIIB4TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF 4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYEFMKV r4EtyUHCH9gYYrrlEPWqu6/SMB8GA1UdIwQYMBaAFDTUQsGTo7tXbAx37nyVH0ZDrzDWMDUGA1Ud EQQuMCyBKkNocmlzdG9waGVyLktvZWhuZW5AaWVtLnRoLW1pdHRlbGhlc3Nlbi5kZTCBgwYDVR0f BHwwejA7oDmgN4Y1aHR0cDovL2NkcDEucGNhLmRmbi5kZS9maC1naWZiLWNhL3B1Yi9jcmwvZ19j YWNybC5jcmwwO6A5oDeGNWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZmgtZ2lmYi1jYS9wdWIvY3Js L2dfY2FjcmwuY3JsMIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcwAoY5aHR0cDovL2NkcDEu cGNhLmRmbi5kZS9maC1naWZiLWNhL3B1Yi9jYWNlcnQvZ19jYWNlcnQuY3J0MEUGCCsGAQUFBzAC hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2ZoLWdpZmItY2EvcHViL2NhY2VydC9nX2NhY2VydC5j cnQwDQYJKoZIhvcNAQEFBQADggEBAJ6d4GaRAR3GjIzGBB+Nyhc2SlRqWg8nMUu8vPKCYUAo3pAu IE/964wGvuCtJUsj2lP36+00DxdyUqHB0pu0n+D3NdHlqEiZ7s98ykYzBQNBP4Fwc8PCteAa/HLH bsrLip2lHBdxDo/WuJqYaJTVX4ejCoPa7YQKv79z4ez1NDl6nE8amSiaLoLblaf3K4QfbYS/YVLv KkRZdOJ3KvrUxDXS+Nmf38FYiW3/duBNELaiiuLfjAmVABChhaj0QpQDao3iEhGUSViKHLkXVO9l Iqj9pkUq7HnBSl+RwJ1psjoL8BvPfzh/XNaU/nBcQWv9wbPkwnznfevMCmdPjUUbC5UxggQ1MIIE MQIBATCBnDCBkzELMAkGA1UEBhMCREUxKTAnBgNVBAoTIEZhY2hob2Noc2NodWxlIEdpZXNzZW4t RnJpZWRiZXJnMTIwMAYDVQQDEylGYWNoaG9jaHNjaHVsZSBHaWVzc2VuLUZyaWVkYmVyZyBDQSAt IEcwMjElMCMGCSqGSIb3DQEJARYWcGtpLWdpZmJAZmgtZ2llc3Nlbi5kZQIEEbvVcjAJBgUrDgMC GgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA0Mjcx OTEzMjVaMCMGCSqGSIb3DQEJBDEWBBSSUO4M4YHUptQJuCTy2ApDHg5s0zCBqwYJKoZIhvcNAQkP MYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAEC MA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCBrQYJKwYBBAGC NxAEMYGfMIGcMIGTMQswCQYDVQQGEwJERTEpMCcGA1UEChMgRmFjaGhvY2hzY2h1bGUgR2llc3Nl bi1GcmllZGJlcmcxMjAwBgNVBAMTKUZhY2hob2Noc2NodWxlIEdpZXNzZW4tRnJpZWRiZXJnIENB IC0gRzAyMSUwIwYJKoZIhvcNAQkBFhZwa2ktZ2lmYkBmaC1naWVzc2VuLmRlAgQRu9VyMIGvBgsq hkiG9w0BCRACCzGBn6CBnDCBkzELMAkGA1UEBhMCREUxKTAnBgNVBAoTIEZhY2hob2Noc2NodWxl IEdpZXNzZW4tRnJpZWRiZXJnMTIwMAYDVQQDEylGYWNoaG9jaHNjaHVsZSBHaWVzc2VuLUZyaWVk YmVyZyBDQSAtIEcwMjElMCMGCSqGSIb3DQEJARYWcGtpLWdpZmJAZmgtZ2llc3Nlbi5kZQIEEbvV cjANBgkqhkiG9w0BAQEFAASCAQBxSp2wfoUHhMNp7vxJR/OmzmKNM+VkChnydL9TC3U8y9jNSzNE H7cEl2J8mXir9iSYeH+5AxBoti7snf7Sp8BV/x6pm+vHTSqCwOZwUd9ui77kLg5nWNR5ye1Tlao9 rajiV9p15vUDlcBoE9om3QgAaKSoyrXq4Y/F2utiaCqiOnZ3pkeuUog+TC/XjatExgkQVo/YvNjR kS/fqbANlACrLm8BKxuKuLOUMOPKiMWUMhfnVBDMMuMdxIwLNCnK80nWjm9Gnxa8WJsLUEpvtzg5 WYgFlow+QK+AJIl+yIn69iSHRqNpBcEDLU+L1bu9yQGFWOQFmJaalhzSfiybKCJzAAAAAAAA From Christopher.Koehnen@iem.th-mittelhessen.de Wed Apr 27 12:42: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 F0837E07F4 for ; Wed, 27 Apr 2011 12:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.742 X-Spam-Level: X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 4r+RRbRBU0ID for ; Wed, 27 Apr 2011 12:42:07 -0700 (PDT) Received: from mout2.fh-giessen.de (mout2.fh-giessen.de [212.201.18.46]) by ietfa.amsl.com (Postfix) with ESMTP id 58DAAE06ED for ; Wed, 27 Apr 2011 12:42:07 -0700 (PDT) Received: from mx1.fh-giessen.de (mx1.fh-giessen.de [212.201.18.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mout2.fh-giessen.de (Postfix) with ESMTPS id 90051BA247 for ; Wed, 27 Apr 2011 21:42:06 +0200 (CEST) Received: from mailgate-2.its.fh-giessen.de ([212.201.18.14]:43057) by mx1.fh-giessen.de with esmtp (Exim 4.72) (envelope-from ) id 1QFAcg-0006IC-Fv for avt@ietf.org; Wed, 27 Apr 2011 21:42:06 +0200 Received: from ip-95-223-140-124.unitymediagroup.de ([95.223.140.124] helo=ckoehnenTHINK) by mailgate-2.its.fh-giessen.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1QFAcg-0006Qw-C6 for avt@ietf.org; Wed, 27 Apr 2011 21:42:06 +0200 From: =?iso-8859-1?Q?Christopher_K=F6hnen?= To: References: In-Reply-To: Date: Wed, 27 Apr 2011 21:41:54 +0200 Message-ID: <00bb01cc0513$2987b9a0$7c972ce0$@iem.th-mittelhessen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL7LQ/Kee3KNgIBzCiydJnj4c590ZITy9bg Content-Language: de Subject: [AVTCORE] FW: 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, 27 Apr 2011 19:42:08 -0000 Dear all, I'd like to express my interest and willingness to support to RTCP for inter-destination media synchronization. This WG item would fill a gap = in multi-device media synchronization and can avoid proprietary closed solutions. It's a really needed enabling technology for hybrid media = device environments. Kind regards Christopher K=F6hnen Dipl.-Ing. (FH) Christopher K=F6hnen Technische Hochschule Mittelhessen University of Applied Sciences Campus Friedberg Information Technology | Electrical Engineering | Mechatronics Wilhelm-Leuschner-Strasse 13 D-61169 Friedberg On 2011-04-18, at 10:49 AM, 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=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 From Internet-Drafts@ietf.org Thu Apr 28 01:15: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 959A5E06A6; Thu, 28 Apr 2011 01:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 eSM96bVmEEWN; Thu, 28 Apr 2011 01:15:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA0E06AF; Thu, 28 Apr 2011 01:15:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110428081505.5080.25556.idtracker@ietfa.amsl.com> Date: Thu, 28 Apr 2011 01:15:05 -0700 Cc: avt@ietf.org Subject: [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: Thu, 28 Apr 2011 08:15:05 -0000 --NextPart 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. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-srtp-vbr-audio-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-28010805.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Thu Apr 28 01:16: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 E020AE06F1 for ; Thu, 28 Apr 2011 01:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 EPmdq27FUSqC for ; Thu, 28 Apr 2011 01:16:17 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E7223E06F8 for ; Thu, 28 Apr 2011 01:16:15 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-e0-4db9224e98ec Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.64.28525.E4229BD4; Thu, 28 Apr 2011 10:16:14 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Apr 2011 10:16:14 +0200 Message-ID: <4DB9224E.8000900@ericsson.com> Date: Thu, 28 Apr 2011 10:16:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [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: Thu, 28 Apr 2011 08:16:18 -0000 Hi, The minutes of the meeting are available here: http://www.ietf.org/proceedings/80/minutes/avtcore.htm Please review and comment if there are any clarification/fixes that you think are needed? 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 xavier.marjou@gmail.com Thu Apr 28 02:20: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 D1DDCE06EB for ; Thu, 28 Apr 2011 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 f-fn-VFyEDtH for ; Thu, 28 Apr 2011 02:20:27 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA1EFE067E for ; Thu, 28 Apr 2011 02:20:26 -0700 (PDT) Received: by vxg33 with SMTP id 33so2210849vxg.31 for ; Thu, 28 Apr 2011 02:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1w8OofyhQIlC8dRtqiIn78qYzr3eaMbAb8+0Ldhbt9k=; b=xan/UNA95TPc0W2Ftu8pbcyFbxaAStbjQM25vqcDfXkQWADvf0TiZZWh7r6W/8l2dq ovCZzRfYBcLvL7NZnXuXaUFDpHTCmukGimVRLSamX09k8IOyX3aWgKqFq0qonNHZ6K77 oHL/xa1AhzBAUoMmFPAMDuznBwtXdKhZ3P65k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EF8/BOXcPPBLzxnauh9urXKKg81crOVqZQfIhalbSkiqU3HABA9WdppQ5ATOrjD7mO WIfzMeFPBz9tkWXNVhf8cmCsKIXzzqtJDOl1Tnw65XS+9kc4N7sE/uP5EcCoPUwJbleC KNIrJ//212UsimdnD00+NYSehEcz2VHHc3pP0= MIME-Version: 1.0 Received: by 10.52.177.196 with SMTP id cs4mr4489173vdc.279.1303982426134; Thu, 28 Apr 2011 02:20:26 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.52.164.225 with HTTP; Thu, 28 Apr 2011 02:20:26 -0700 (PDT) In-Reply-To: <4DAC4F69.1080707@ericsson.com> References: <4DAC4F69.1080707@ericsson.com> Date: Thu, 28 Apr 2011 11:20:26 +0200 X-Google-Sender-Auth: VnjjSjMWTWux7EHFEECz-fA-zbo Message-ID: From: Xavier Marjou To: Magnus Westerlund Content-Type: multipart/alternative; boundary=20cf3071cbaa4d969a04a1f711cd Cc: 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: Thu, 28 Apr 2011 09:20:27 -0000 --20cf3071cbaa4d969a04a1f711cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support this work and will be happy to review the draft. Cheers, Xavier On Mon, Apr 18, 2011 at 4:49 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> 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=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 > --20cf3071cbaa4d969a04a1f711cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support this work and will be happy to review the draft.

Cheers,
Xavier

On Mon, Apr 1= 8, 2011 at 4:49 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> 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-branden= burg-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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--20cf3071cbaa4d969a04a1f711cd-- From magnus.westerlund@ericsson.com Thu Apr 28 02:29: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 5175EE0674 for ; Thu, 28 Apr 2011 02:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 0w3n8P4qDJ3W for ; Thu, 28 Apr 2011 02:29:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id F2D54E062A for ; Thu, 28 Apr 2011 02:29:15 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-18-4db9336af919 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B3.8D.28525.A6339BD4; Thu, 28 Apr 2011 11:29:14 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Apr 2011 11:29:14 +0200 Message-ID: <4DB9336A.1010909@ericsson.com> Date: Thu, 28 Apr 2011 11:29:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF AVTCore WG References: <4DAECEA5.2090305@ericsson.com> In-Reply-To: <4DAECEA5.2090305@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] ECN for RTP: Multiple SSRC init optimization 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, 28 Apr 2011 09:29:17 -0000 Magnus Westerlund skrev 2011-04-20 14:16: > Hi, > > We had some discussion in Prague in the meeting session regarding what > optimization one should do for using multiple SSRCs in one RTP session > on one end-point, i.e. someone that sends multiple SSRCs from the same > transport protocol, port and address when using unicast. > > It was clear that it was desirable to optimize this case. However, we > appear to have issues finding an optimization that is generally > applicable to the different potential deployments that can contain unicast. > > As WG editors we don't see much choice than to continue without an > optimization. If someone has a good idea for how it could work please > contribute it. Hi, I actually have thought a bit more about this and changed my mind about it. It appears that same CNAME is actually reasonable and the failure mode is when you have a decomposited design of a node. That is not common and it appears reasonable to lay the burden on them. Also the failure mode isn't that bad as the verification will detect if there is an issue. So I have written up text for this for Section 7.2.1: Determination of ECN Support: RTP is a group communication protocol, where members can join and leave the group at any time. This complicates the ECN initiation phase, since the sender must wait until it believes the group membership has stabilised before it can determine if the paths to all receivers support ECN (group membership changes after the ECN initiation phase has completed are discussed in Section 7.3). An RTP sender shall consider the group membership to be stable after it has been in the session and sending ECT-marked probe packets for at least three RTCP reporting intervals (i.e., after sending its third regularly scheduled RTCP packet), and when a complete RTCP reporting interval has passed without changes to the group membership. ECN initiation is considered successful when the group membership is stable, and all known participants have sent one or more RTCP ECN feedback packets indicating correct receipt of the ECT-marked RTP packets generated by the sender. As an optimisation, if an RTP sender is initiating ECN usage towards a unicast address, then it MAY treat the ECN initiation as provisionally successful if it receives RTCP ECN feedback report indicating successful receipt of the ECT-marked packets, with no negative indications, from a single RTP receiver. Where a single RTP receiver is considered as all SSRCs used by a single CNAME. After declaring provisional success, the sender MAY generate ECT- marked packets as described in Section 7.3, provided it continues to monitor the RTCP reports for a period of three RTCP reporting intervals from the time the ECN initiation started, to check if there is any other participants in the session. Thus as long as any additional SSRC that report on the ECN usage are using the same CNAME as the previous reports and they are all indicating functional ECN the sender may continue. If other participants are detected, i.e other CNAMEs, the sender MUST fallback to only ECT- marking a small fraction of its RTP packets, while it determines if ECN can be supported following the full procedure described above. Different CNAMEs received over an unicast transport may occur when using translators in a multi-party RTP session. Note: The above optimization support peer to peer unicast transport with several SSRCs multiplexed onto the same flow (e.g. SSRC multiplexed RTP retransmission [RFC4588]). It is desirable to be able to rapidly negotiate ECN support for such a session, but the optimisation above can fail if there are implementations that use the same CNAME for different parts of a distributed implementation that has different transport characteristics. ECN initiation is considered to have failed at the instant when any RTP session participant sends an RTCP packet that doesn't contain an RTCP ECN feedback report or ECN summary report, but has an RTCP RR with an extended RTP sequence number field that indicates that it should have received multiple (>3) ECT marked RTP packets. This can be due to failure to support the ECN feedback format by the receiver or some middlebox, or the loss of all ECT marked packets. Both indicate a lack of ECN support. If the ECN negotiation succeeds, this indicates that the path can pass some ECN-marked traffic, and that the receivers support ECN feedback. This does not necessarily imply that the path can robustly convey ECN feedback; Section 7.3 describes the ongoing monitoring that must be performed to ensure the path continues to robustly support ECN. When a sender or receiver detects ECN failures on paths they should log these to enable follow up and statistics gathering regarding broken paths. The logging mechanism used is implementation dependent. Comments are welcome. 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 ----------------------------------------------------------------------