From Even.roni@huawei.com Fri Apr 1 05:10:48 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@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 05:38:25 -0700 Cc: "'Botzko, Stephen'" , "'Patrick Luthi \(pluthi\)'" Subject: [payload] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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 zfang@qualcomm.com Tue Apr 5 13:26:19 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02B628B797 for ; Tue, 5 Apr 2011 13:26:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfiPt0n93q71 for ; Tue, 5 Apr 2011 13:26:17 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id B6AC63A63D3 for ; Tue, 5 Apr 2011 13:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1302035280; x=1333571280; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20|To:=20Chu ng=20Cheung=20Chu=20,=20"p ayload@ietf.org"=0D=0A=09|Date:=20Tue, =205=20Apr=202011=2013:27:55=20-0700|Subject:=20RE:=20Mod e=20request=20support=20in=20draft=20"draft-ietf-avt-rtp- evrc-nw-02"|Thread-Topic:=20Mode=20request=20support=20in =20draft=20"draft-ietf-avt-rtp-evrc-nw-02"|Thread-Index: =20AcvvrsOOKjHekr+TTpqDngi/h7BZbgEIOfyA|Message-ID:=20<90 9F74681826104B8F3162A1A782323B511417E0E9@NALASEXMB13.na.q ualcomm.com>|References:=20<26490BBDEEACA14EA1A0070367B3A DBDB75A7D5FE4@EUSAACMS0702.eamcs.ericsson.se> |In-Reply-To:=20<26490BBDEEACA14EA1A0070367B3ADBDB75A7D5F E4@EUSAACMS0702.eamcs.ericsson.se>|Accept-Language:=20en- US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_909F74681826104B8F3162A1A782323B511417E0E9NALAS EXMB13na_"|MIME-Version:=201.0; bh=T5awYqCiJpVG+jXgNQ7S1dqNd4KegOe0tmsjnTBKhdU=; b=Jcc10OC9c5yrHIVWVe8wmVljC+QBs1JkgYqsvybqxwUZPWEKx0q8uKl+ uVdXKPnIgNJVBUDrPi1/0tiaxfoFPPZFmcyPzqV8nBlET1mmo/Gq/USSI lssEp3NI0U5K35eD5IBY7myhb4ged/zRJGpmq081iPpLUgzxbKhCZzW9r Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6307"; a="84146140" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 05 Apr 2011 13:27:59 -0700 X-IronPort-AV: E=Sophos;i="4.63,304,1299484800"; d="scan'208,217";a="30938" Received: from nalasexhc05.na.qualcomm.com ([10.47.27.139]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/AES128-SHA; 05 Apr 2011 13:27:59 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by NALASEXHC05.na.qualcomm.com (10.47.27.139) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 5 Apr 2011 13:27:59 -0700 Received: from NALASEXMB13.na.qualcomm.com ([10.47.6.158]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 5 Apr 2011 13:27:58 -0700 From: "Fang, Zheng" To: Chung Cheung Chu , "payload@ietf.org" Date: Tue, 5 Apr 2011 13:27:55 -0700 Thread-Topic: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02" Thread-Index: AcvvrsOOKjHekr+TTpqDngi/h7BZbgEIOfyA Message-ID: <909F74681826104B8F3162A1A782323B511417E0E9@NALASEXMB13.na.qualcomm.com> References: <26490BBDEEACA14EA1A0070367B3ADBDB75A7D5FE4@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDB75A7D5FE4@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_909F74681826104B8F3162A1A782323B511417E0E9NALASEXMB13na_" MIME-Version: 1.0 Subject: Re: [payload] Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 20:26:19 -0000 --_000_909F74681826104B8F3162A1A782323B511417E0E9NALASEXMB13na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chung Cheung, Thanks for the comments. I agree with the clarification you proposed. I w= ill adopt these changes into the next revision. Best Regards, Zheng From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] Sent: Thursday, March 31, 2011 7:20 AM To: payload@ietf.org; Fang, Zheng Subject: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02" Background Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and c= orresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.= S0014-D]. EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2. Th= is codec supports a total of 8 modes of operation for narrowband and wideba= nd voice band traffic compression. Mode-0 is for wideband compression. Mo= de-1 to mode-7 are for narrowband compression where mode-4 is defined as th= e default mode. The average encoding rate for narrowband operation is decr= eased with increasing operating mode from mode-1 to mode-7. Three media subtype payload formats are defined in this draft. They are EV= RCNW, EVRCNW0 and EVRCNW1. This email concerns with operations associated = with the media subtype EVRCNW payload format definition. Media subtype EVRCNW payload format is defined with a payload header which = consists of a 3-bit mode request field "MMM" and other payload related para= meters [Ref. RFC3558]. Per MMM definition in RFC3558, EVRCNW traffic recei= ver uses this field to request an EVRCNW encoding mode to be used by the EV= RCNW traffic generator for new traffic in the reverse path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header [4] | +=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+ |R|R| LLL | NNN | MMM | Count | TOC | ... | TOC |padding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more codec data frames, one per TOC entry | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Per draft "draft-ietf-avt-rtp-evrc-nw-02", EVRCNW operates in narrowband mo= de-4 by default. EVRCNW encoder operates in wideband mode only when an EVR= CNW encoder receives indication of the EVRCNW wideband decoding capability = and preference from the other side. The draft adopts an optional SDP attr= ibute "mode-set-recv" to indicate EVRCNW wideband decoding capability and p= reference. The indication of EVRCNW wideband decoding capability and prefe= rence can also be communicated to the other side via the mode request field= "MMM" during an active session. Proposal RFC3558 recommends that mode change request is applicable to two-party call= s only and not to multi-party calls. (Section 10) The Mode Request signal requests a particular encoding mode for the speech = encoding in the reverse direction. All implementations are RECOMMENDED to = honor the Mode Request signal. The Mode Request signal SHOULD only be used= in one-to-one sessions. In multi-party sessions, any received Mode Reques= t signals SHOULD be ignored. It is believed that mode request should be applicable to EVRCNW operation i= n both two-party and conference calls. In particular, mode request is nece= ssary to activate EVRCNW narrowband-to-wideband and wideband-to-narrowband = switching during an active two-party or conference call session. It is proposed that the following texts for mode request usage be considere= d for media subtype EVRCNW payload format. Original text: Section 6 Three RTP packet formats are supported for the EVRC-NW codec - the inter= leaved/bundled packet format, the header-free packet format and the compact= bundled packet format. For all these formats, the operational details and= capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are= exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3]= , except that the mode change request field in the ToC MUST be interpreted = according to the definition of the RATE_REDUC parameter as defined in EVRC-= NW [4]. The media type audio/EVRCNW maps to the interleaved/bundled packet = format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCN= W1 maps to the compact bundled packet format. Suggested text: Section 6 Three RTP packet formats are supported for the EVRC-NW codec - the inter= leaved/bundled packet format, the header-free packet format and the compact= bundled packet format. For all these formats, the operational details and= capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are= exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3]= , except that (1) the mode change request field in the ToC interleaved/bund= led packet format MUST be interpreted according to the definition of the RA= TE_REDUC parameter as defined in EVRC-NW [4] and (2) the mode change reques= t field in interleaved/bundled packet format SHOULD be honored by an EVRCNW= encoding end point in an one-to-one session with a dedicated EVRCNW decodi= ng end point such as in a two-party call or in a conference leg. The media = type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRC= NW0 maps to the header-free packet format and audio/EVRCNW1 maps to the com= pact bundled packet format. The suggested changes are for media subtype EVRCNW payload format only. Th= ey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats = where the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_909F74681826104B8F3162A1A782323B511417E0E9NALASEXMB13na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chung Cheung,

 

Thanks for the comments.  I agree with the clarificatio= n you proposed.  I will adopt these changes into the next revision.

 

Best Regards,

Zheng

 

From: Chung Cheung = Chu [mailto:chung.cheung.chu@ericsson.com]
Sent: Thursday, March 31, 2011 7:20 AM
To: payload@ietf.org; Fang, Zheng
Subject: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02"

 

 = ;

Background

 

Draft "dra= ft-ietf-avt-rtp-evrc-nw-02" defines = the RTP payload formats and corresponding media type registrations for CDMA cod= ec EVRC-NW [Ref. 3GPP2 C.S0014-D].  EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2.  This codec supports a total of 8 modes of operation for narrowband and wideband voice band traffic compression.  Mode-0 is for wideband compression.  Mode-1 to mode-7 are for narrowba= nd compression where mode-4 is defined as the default mode.  The average encoding rate for narrowband operation is decreased with increasing operati= ng mode from mode-1 to mode-7.

 

Three media subtype payload formats are defined in this draft.  They are EVR= CNW, EVRCNW0 and EVRCNW1.  This email concerns with operations associated w= ith the media subtype EVRCNW payload format definition.

 

Media subtype EVRCNW payload format is defined with a payload header which consis= ts of a 3-bit mode request field "MMM" and other payload related parameters [Ref. RFC3558].  Per MMM definition in RFC3558, EVRCNW traf= fic receiver uses this field to request an EVRCNW encoding mode to be used by t= he EVRCNW traffic generator for new traffic in the reverse path.

 

    0            &n= bsp;      1            &n= bsp;      2            &n= bsp;      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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |            &n= bsp;         RTP Header [4]            =             &nb= sp;  |=

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

   |R|R| LLL | NNN | MMM |  Count  |  TOC  |  ...&nbs= p; |  TOC  |padding|

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |        one or more codec data frames, = one per TOC entry       |

   |            &n= bsp;            = ;    ....            = ;            &n= bsp;     |=

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

Per draft "", EVRCNW operates in narrowband mode-4 by default.  EVRCNW encoder operates in wideband mode only when an EVRCNW encoder receives indication of the EVRCNW wideband decoding capability and preference from the other side.  = ; The draft adopts an optional SDP attribute "mode-set-recv" to ind= icate EVRCNW wideband decoding capability and preference.  The indication of EVRCNW wideband decoding capability and preference can also be communicated= to the other side via the mode request field "MMM" during an active session.=

 

Proposal

 

RFC3558 recommends that mode change request is applicable to two-party calls only a= nd not to multi-party calls. 

 

(Section 10)

The Mode Request signal requests a particular encoding mode for the speech enco= ding in the reverse direction.  All implementations are RECOMMENDED to hono= r the Mode Request signal.  The Mode Request signal SHOULD only be used = in one-to-one sessions.  In multi-party sessions, any received Mode Reque= st signals SHOULD be ignored.

 

 

It is believed that mode request should be applicable to EVRCNW operation in b= oth two-party and conference calls.  In particular, mode request is necess= ary to activate EVRCNW narrowband-to-wideband and wideband-to-narrowband switch= ing during an active two-party or conference call session.

 

It is proposed that the following texts for mode request usage be considered f= or media subtype EVRCNW payload format.

 

 

 

Original text: Section 6=

 

   Three RTP packet formats are supported for the EVRC-NW codec - the interleaved/bundled packet format, the header-free packet format and the compact bundled packet format.  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are exactly the same as those of EVRC-B and EVRC-WB, as defined in = [2] and [3], except that the mode change request field in the ToC MUST be interpreted according to the definition of the RATE_REDUC parameter as defi= ned in EVRC-NW [4]. The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format and audi= o/EVRCNW1 maps to the compact bundled packet format.

 

Suggested text: Section 6=

 

   Three RTP packet formats are supported for the EVRC-NW codec - the interleaved/bundled packet format, the header-free packet format and the compact bundled packet format.  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are exactly the same as those of EVRC-B and EVRC-WB, as defined in = [2] and [3], except that (1) the mode change request field in the ToC interleaved/bundled packet format MUST be inter= preted according to the definition of the RATE_REDUC parameter as defined in EVRC-= NW [4] and (2) the mode change request field in interleaved/bundled packet format SHOULD be honored by an EVRCNW encoding e= nd point in an one-to-one session with a dedicated EVRCNW decoding end point s= uch as in a two-party call or in a conference leg. The media type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 m= aps to the header-free packet format and audio/EVRCNW1 maps to the compact bund= led packet format.=

 

 

 

 

 

The suggested changes are for media subtype EVRCNW payload format only.  T= hey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats whe= re the MMM mode request field is not supported. 

 

 

 

Regards,

 

CC

 

Chung-Cheung Chu

Media Gateway DSP Design<= o:p>

BCAM - Ericsson

+514 345-7900 (x46489)

This Communication= is Confidential.  We only send and receive email on the basis of the terms set out at = www.ericsson.com/email_disclaimer.

 

 

 

--_000_909F74681826104B8F3162A1A782323B511417E0E9NALASEXMB13na_-- From harald@alvestrand.no Tue Apr 12 08:36:24 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 82E77E07EA for ; Tue, 12 Apr 2011 08:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tyd7RgwUEdHv for ; Tue, 12 Apr 2011 08:36:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfc.amsl.com (Postfix) with ESMTP id 66689E07AE for ; Tue, 12 Apr 2011 08:36:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4567739E16F for ; Tue, 12 Apr 2011 17:35:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-VchmqwarTk for ; Tue, 12 Apr 2011 17:35:40 +0200 (CEST) Received: from [192.168.1.58] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 5B56939E15D for ; Tue, 12 Apr 2011 17:35:40 +0200 (CEST) Message-ID: <4DA47175.4090709@alvestrand.no> Date: Tue, 12 Apr 2011 17:36:21 +0200 From: Harald Alvestrand 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: payload@ietf.org References: <009d01cbeeac$b1776a90$14663fb0$%roni@huawei.com> In-Reply-To: <009d01cbeeac$b1776a90$14663fb0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------080102000907030200010509" Subject: Re: [payload] Call for adoption of RRP payload format to VP8 document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 15:36:24 -0000 This is a multi-part message in MIME format. --------------080102000907030200010509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/30/11 09:32, Roni Even wrote: > > Hi, > > Payload WG has a milestone forAugust 2011 for RTP Payload Format for VP8 Video for Proposed Standard > > There is an individual draft titledProposal for the IETF on "RTP Payload Format for VP8 Video" http://tools.ietf.org/html/draft-westin-payload-vp8-02 > > 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. > I support the adoption of this draft as the basis for a WG document. (I assume mail to the list is the conventional method of indicating support...) > > Please respond by Thursday April 14^th 2011 with your positions. > > Roni Even > > PAYLOAD WG co-chair > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --------------080102000907030200010509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/30/11 09:32, Roni Even wrote:

Hi,

Payload WG has a milestone for August 2011 for RTP Payload Format for VP8 Video for Proposed Standard

 

 

There is an individual draft titled Proposal for the IETF on "RTP Payload Format for VP8 Video"   http://tools.ietf.org/html/draft-westin-payload-vp8-02  

 

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.

I support the adoption of this draft as the basis for a WG document.
(I assume mail to the list is the conventional method of indicating support...)

 

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

 

Roni Even

PAYLOAD WG co-chair

 

 


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

--------------080102000907030200010509-- From Even.roni@huawei.com Fri Apr 15 00:21:14 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EA756E0686 for ; Fri, 15 Apr 2011 00:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.072 X-Spam-Level: X-Spam-Status: No, score=-105.072 tagged_above=-999 required=5 tests=[AWL=1.526, 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 V83zYxJr3HgC for ; Fri, 15 Apr 2011 00:21:14 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfc.amsl.com (Postfix) with ESMTP id 460CFE0693 for ; Fri, 15 Apr 2011 00:21:14 -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 <0LJO003SXN185G@szxga04-in.huawei.com> for payload@ietf.org; Fri, 15 Apr 2011 15:19:56 +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 <0LJO00A1SN18VT@szxga04-in.huawei.com> for payload@ietf.org; Fri, 15 Apr 2011 15:19:56 +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 <0LJO0092DN10JB@szxml11-in.huawei.com>; Fri, 15 Apr 2011 15:19:56 +0800 (CST) Date: Fri, 15 Apr 2011 10:19:05 +0300 From: Roni Even To: patrik.westin@gmail.com, hlundin@google.com Message-id: <014601cbfb3d$6ccd93e0$4668bba0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2vcC7hP7iFbs9JLS/kUIWA)" Content-language: en-us Thread-index: Acv7PWcVO3PJW/KTScWS9l9e8iAzRw== Cc: payload@ietf.org Subject: [payload] Accepting draft-westin-payload-vp8-02 as a Payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:21:15 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2vcC7hP7iFbs9JLS/kUIWA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi guys, Since there were no objections or other proposal please submit draft-westin-payload-vp8-02 as a Payload working group document " draft-ietf-payload-vp8-00" Thanks Roni Even Payload co-chair --Boundary_(ID_2vcC7hP7iFbs9JLS/kUIWA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi guys,

Since there were no objections or other proposal please submit draft-westin-payload-vp8-02 as a Payload working group document " draft-ietf-payload-vp8-00"

 

Thanks

Roni Even

Payload co-chair

 

 

--Boundary_(ID_2vcC7hP7iFbs9JLS/kUIWA)-- From chung.cheung.chu@ericsson.com Fri Apr 15 06:53:07 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B71D6E06A2 for ; Fri, 15 Apr 2011 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 Ag9QR0URA48M for ; Fri, 15 Apr 2011 06:53:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 35AABE071E for ; Fri, 15 Apr 2011 06:53:00 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FDqvEb017980; Fri, 15 Apr 2011 08:53:00 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 15 Apr 2011 09:52:57 -0400 From: Chung Cheung Chu To: "payload@ietf.org" , "zfang@qualcomm.com" Date: Fri, 15 Apr 2011 09:52:56 -0400 Thread-Topic: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Thread-Index: Acv1Jb8riP8RBI1FS1qqLbHSHs3ktgGTpXNA Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDB77844F033@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB77844F033EUSAACMS0702e_" MIME-Version: 1.0 Subject: [payload] Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:06:37 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844F033EUSAACMS0702e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Background Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and c= orresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.= S0014-D]. EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2. Th= is codec supports a total of 8 modes of operation for narrowband and wideba= nd voice band traffic compression. Mode-0 is for wideband compression. Mo= de-1 to mode-7 are for narrowband compression where mode-4 is defined as th= e default mode. The average encoding rate for narrowband operation is decr= eased with increasing operating mode from mode-1 to mode-7. Three media subtype payload formats are defined in this draft. They are EV= RCNW, EVRCNW0 and EVRCNW1. This email concerns with operations associated = with the media subtype EVRCNW payload format definition. Media subtype EVRCNW payload format is defined with a payload header which = consists of a 3-bit mode request field "MMM" and other payload related para= meters [Ref. RFC3558]. Per MMM definition by RFC3558, EVRCNW traffic recei= ver uses this field to request an EVRCNW encoding mode to be used by the EV= RCNW traffic generator for new traffic in the reverse path. Draft "draft-ietf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes "m= ode-set-recv" and "sendmode" from RFC5188. Attribute "mode-set-recv" is us= ed to indicate the preferred mode of bearer traffic supported by an EVRCNW = receiver. This attribute can assume a set of values 0, 1, ..., 7 denoting = mode-0, mode-1, ..., mode-7 support, respectively. Attribute "sendmode" is= used to announce the current EVRCNW encoding mode by an EVRCNW encoder. The draft states that in absence of mode-0 specification in "mode-set-recv"= or in absence of the attribute, an EVRCNW encoder at the other side can on= ly operate in narrowband mode. In absence of attribute "sendmode", the enc= oding mode is mode-4. Proposal It is understood that an EVRCNW encoder cannot autonomously generate and se= nd EVRC-NW mode-0 (wideband) traffic to the partner in absence of the partn= er's mode-0 (wideband) decoding capability. However, a user capable of dec= oding mode-0 (wideband) traffic should be allowed to request for mode-0 (wi= deband) traffic from the partner using the MMM field in the RTP RFC header.= Such an in-band request is an implicit indication of mode-0 (wideband) de= coding capability of the originator. Upon receiving the mode-0 (wideband) = request, a mode-0 (wideband) capable partner should be allowed to generate = and send EVRC-NW wideband encoded traffic to the request originator, regard= less of the SDP attribute "mode-set-recv". A partner not capable of wideba= nd encoding can ignore the request and should use a narrowband mode. An example where the MMM mode change request field facilitates narrowband-t= o-wideband and wideband-to-narrowband operation switching is as follows: An EVRCNW transcoding free (TrFO) call is established in a session between = mobile-A in a circuit switched network and mobile-B in a 4G network via a c= ommunication node in the core network, such as a media gateway. In this e= xample, mobile-A supports EVRCNW without wideband compression capability, a= nd mobile-B supports EVRCNW with wideband compression capability. The medi= a gateway sends at call setup time SDP mode-set-recv attribute to mobile-B = specifying only narrowband mode support in light of mobile-A EVRCNW wideban= d incapability. During the call, a call transfer (or call waiting) takes p= lace replacing mobile-A with an EVRCNW wideband capable device, mobile-C. = In this example, the media gateway does not update the optional SDP mode-se= t-recv attribute on the stationary side to mobile-B. In this scenario, EVRCNW wideband operation is allowed between mobile-C and= the media gateway but not feasible between the media gateway and mobile-B = according to the mode-set-recv definition in the current draft. This could= result in end-to-end EVRCNW operation in narrowband mode only. If MMM mod= e change requests for mode-0 traffic relayed from mobile-C is allowed and s= upported by mobile-B, end-to-end EVRCNW transcoding free operation would be= re-established in wideband mode. Conversely, when the wideband support capability is terminated during an ac= tive call session, for example due to a call transfer (or call waiting) bac= k from mobile-C to mobile-A, mode change requests relayed from mobile-A for= narrowband operation should be considered as a preference indication that = narrowband traffic is desired by the originator. Mobile-B should honor the= request and return narrowband compressed traffic. This is required even i= f the mode-set-recv SDP attribute from the media gateway to mobile-B includ= es mode-0 support. It is proposed that the following texts for media subtype EVRCNW SDP attrib= utes "mode-set-recv" and "sendmode" be clarified: Original text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. Suggested text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. During an active call session, the MMM mode request received from a communi= cation partner complements the mode set information in mode-set-recv. A mo= de request with MMM=3D0 from a communication partner is an implicit indicat= ion of the partner's EVRCNW wideband decoding capability and preference. A= n EVRCNW wideband capable node receiving the request can operate in wideban= d mode. A mode request with MMM=3D1, 2, ..., or 7 from a communication par= tner is an implicit indication of the partner's EVRCNW narrowband decoding = capability and preference. An EVRCNW node receiving the request should hon= or the request and operate in narrowband mode. Original text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter, an encod= er at the other side shall not operate in mode 0. Suggested text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter and in th= e MMM mode request field in media subtype EVRCNW payload format, an encoder= at the other side shall not operate in mode 0. Original text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. Suggested text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. It is not necessary to send this optional SDP attribute when an EVRCNW e= ncoder updates its encoding mode during an active call session such as in r= esponse to requests in the MMM mode request field from the other side. Conv= ersely, absence of this SDP attribute should not be interpreted as an indic= ation the encoder operates only in default mode-4. The suggested changes are for media subtype EVRCNW payload format only. Th= ey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats = where the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844F033EUSAACMS0702e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Background
 
Draft "dra= ft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and= corresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 = C.S0014-D].  EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2.  This codec supports a total of 8 modes of ope= ration for narrowband and wideband voice band traffic compression.  Mo= de-0 is for wideband compression.  Mode-1 to mode-7 are for narrowband= compression where mode-4 is defined as the default mode.  The average encoding rate for narrowband operation is decreased= with increasing operating mode from mode-1 to mode-7.
 
Three media subtype payload formats are defined in th= is draft.  They are EVRCNW, EVRCNW0 and EVRCNW1.  This email conc= erns with operations associated with the media subtype EVRCNW payload forma= t definition.
 
Media subtype EVRCNW payload format is defined with a= payload header which consists of a 3-bit mode request field "MMM"= ; and other payload related parameters [Ref. RFC3558].  Per MMM defini= tion by RFC3558, EVRCNW traffic receiver uses this field to request an EVRCNW encoding mode to be used by the EVRCNW traffic g= enerator for new traffic in the reverse path.
 
Draft "dra= ft-ietf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes = "mode-set-recv" and "sendmode" from RFC5188.  Attr= ibute "mode-set-recv" is used to indicate the preferred mode of b= earer traffic supported by an EVRCNW receiver.  This attribute can assume a = set of values 0, 1, …, 7 denoting mode-0, mode-1, …, mode-7 sup= port, respectively.  Attribute "sendmode" is used to announc= e the current EVRCNW encoding mode by an EVRCNW encoder.
 
The draft states that in absence of mode-0 specificat= ion in "mode-set-recv" or in absence of the attribute, an EVRCNW = encoder at the other side can only operate in narrowband mode.  In abs= ence of attribute "sendmode", the encoding mode is mode-4.
 
 
Proposal
 
It is understood that an E= VRCNW encoder cannot autonomously generate and send EVRC-NW mode-0 (wideban= d) traffic to the partner in absence of the partner's mode-0 (wideband) dec= oding capability.  However, a user capable of decoding mode-0 (wideband) traffic should be allowed to request for mode= -0 (wideband) traffic from the partner using the MMM field in the RTP RFC h= eader.  Such an in-band request is an implicit indication of mode-0 (w= ideband) decoding capability of the originator.  Upon receiving the mode-0 (wideband) request, a mode-0 (wideband) capable p= artner should be allowed to generate and send EVRC-NW wideband encoded traf= fic to the request originator, regardless of the SDP attribute "mode-s= et-recv".  A partner not capable of wideband encoding can ignore the request and should use a narrowband mode. 
 
An example where the MMM m= ode change request field facilitates narrowband-to-wideband and wideband-to= -narrowband operation switching is as follows:
 
An EVRCNW transcoding free= (TrFO) call is established in a session between mobile-A in a circuit swit= ched network and mobile-B in a 4G network via a communication node in the c= ore network, such as a media gateway.   In this example, mobile-A supports EVRCNW without wideband compression capa= bility, and mobile-B supports EVRCNW with wideband compression capability.&= nbsp; The media gateway sends at call setup time SDP mode-set-recv attribut= e to mobile-B specifying only narrowband mode support in light of mobile-A EVRCNW wideband incapability.  Durin= g the call, a call transfer (or call waiting) takes place replacing mobile-= A with an EVRCNW wideband capable device, mobile-C.  In this example, = the media gateway does not update the optional SDP mode-set-recv attribute on the stationary side to mobile-B. 
 
In this scenario, EVRCNW w= ideband operation is allowed between mobile-C and the media gateway but not= feasible between the media gateway and mobile-B according to the mode-set-= recv definition in the current draft.  This could result in end-to-end EVRCNW operation in narrowband mode only.&n= bsp; If MMM mode change requests for mode-0 traffic relayed from mobile-C i= s allowed and supported by mobile-B, end-to-end EVRCNW transcoding free ope= ration would be re-established in wideband mode.
 
Conversely, when the wideb= and support capability is terminated during an active call session, for exa= mple due to a call transfer (or call waiting) back from mobile-C to mobile-= A, mode change requests relayed from mobile-A for narrowband operation should be considered as a preference indi= cation that narrowband traffic is desired by the originator.  Mobile-B= should honor the request and return narrowband compressed traffic.  T= his is required even if the mode-set-recv SDP attribute from the media gateway to mobile-B includes mode-0 support.
 
 
 
It is proposed that the following texts for media sub= type EVRCNW SDP attributes "mode-set-recv" and "sendmode&quo= t; be clarified:
 
 
Original text: Sec= tion 9.1.1
mode-set-recv: A subs= et of EVRC-NW modes.  Possible values are a comma separated list of mo= des from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D)= .  A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes.&nbs= p; Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.
 
Suggested text: Se= ction 9.1.1
mode-set-recv: A subs= et of EVRC-NW modes.  Possible values are a comma separated list of mo= des from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D)= .  A decoder can use this attribute to inform an encoder of its preference to operate in a specified subset of modes.&nbs= p; Absence of this parameter signals the mode set {1,2,3,4,5,6,7}.
 
Dur= ing an active call session, the MMM mode request received from a communicat= ion partner complements the mode set information in mode-set-recv.  A = mode request with MMM=3D0 from a communication partner is an implicit indication of the partner's EVRCNW wideband decoding= capability and preference.  An EVRCNW wideband capable node receiving= the request can operate in wideband mode.  A mode request with MMM=3D= 1, 2, …, or 7 from a communication partner is an implicit indication of the partner's EVRCNW narrowband decoding capabili= ty and preference.  An EVRCNW node receiving the request should honor = the request and operate in narrowband mode.
 
 
 
Original text: Sec= tion 10
   1. = To inform the capability of wideband mode support: A decoder can always de= code all the narrowband modes (modes 1 to 7).  Unless the decoder indi= cates the support of mode 0 (i.e., preference) in this parameter, an encoder at the other side shall not operate in mode 0.
 
Suggested text: Se= ction 10
   1. = To inform the capability of wideband mode support: A decoder can always de= code all the narrowband modes (modes 1 to 7).  Unless the decoder indi= cates the support of mode 0 (i.e., preference) in this parameter and in the MMM mode request field in media subtype = EVRCNW payload format, an encoder at the other side shall not operat= e in mode 0.
 
 
 
Original text: Sec= tion 9.1.1
   sendmode= : A mode of the EVRC-NW codec.  An encoder can use this to signal its = current mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see T= able 2.6.1.2-4 in 3GPP2 C.S0014-D).  Absence of this parameter signals mode 4.
 
Suggested text: Se= ction 9.1.1
   sendmode= : A mode of the EVRC-NW codec.  An encoder can use this to signal its = current mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see T= able 2.6.1.2-4 in 3GPP2 C.S0014-D).  A= bsence of this parameter signals mode 4.
&nb= sp;  It is not necessary to send this optional SDP attribute when an E= VRCNW encoder updates its encoding mode during an active call session such = as in response to requests in the MMM mode request field from the other side. Conversely, absence of this SDP attribute should= not be interpreted as an indication the encoder operates only in default m= ode-4.
 
 
The suggested changes are = for media subtype EVRCNW payload format only.  They are not applicable= to media subtype EVRCNW0 and EVRCNW1 payload formats where the MMM mode re= quest field is not supported. 
 
 
 
Regards,
 
CC
 
Chung-Cheung Chu
Media Gateway DSP Design
BCAM - Ericsson
+514 345-7900 (x46489)
This Communication= is Confidential.  We only send and receive email on the basis of the = terms set out at www.ericsson.com/email_disclaimer<= i>.
 
 
 --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844F033EUSAACMS0702e_-- From chung.cheung.chu@ericsson.com Fri Apr 15 06:22:11 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5666FE0719 for ; Fri, 15 Apr 2011 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, 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 Nxo3i4kJscNE for ; Fri, 15 Apr 2011 06:22:09 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id A6E4CE070A for ; Fri, 15 Apr 2011 06:22:09 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3FDLqBT013060; Fri, 15 Apr 2011 08:22:09 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 15 Apr 2011 09:21:48 -0400 From: Chung Cheung Chu To: "payload@ietf.org" , "zfang@qualcomm.com" Date: Fri, 15 Apr 2011 09:21:48 -0400 Thread-Topic: Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02" Thread-Index: Acv7cBLQOXCKYLYoShWDuO6AxsjItQ== Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6EUSAACMS0702e_" MIME-Version: 1.0 Subject: [payload] Mode request support in draft "draft-ietf-avt-rtp-evrc-nw-02" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:06:54 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6EUSAACMS0702e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Background Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and c= orresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.= S0014-D]. EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2. Th= is codec supports a total of 8 modes of operation for narrowband and wideba= nd voice band traffic compression. Mode-0 is for wideband compression. Mo= de-1 to mode-7 are for narrowband compression where mode-4 is defined as th= e default mode. The average encoding rate for narrowband operation is decr= eased with increasing operating mode from mode-1 to mode-7. Three media subtype payload formats are defined in this draft. They are EV= RCNW, EVRCNW0 and EVRCNW1. This email concerns with operations associated = with the media subtype EVRCNW payload format definition. Media subtype EVRCNW payload format is defined with a payload header which = consists of a 3-bit mode request field "MMM" and other payload related para= meters [Ref. RFC3558]. Per MMM definition in RFC3558, EVRCNW traffic recei= ver uses this field to request an EVRCNW encoding mode to be used by the EV= RCNW traffic generator for new traffic in the reverse path. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header [4] | +=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+ |R|R| LLL | NNN | MMM | Count | TOC | ... | TOC |padding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | one or more codec data frames, one per TOC entry | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Per draft "draft-ietf-avt-rtp-evrc-nw-02", EVRCNW operates in narrowband mo= de-4 by default. EVRCNW encoder operates in wideband mode only when an EVR= CNW encoder receives indication of the EVRCNW wideband decoding capability = and preference from the other side. The draft adopts an optional SDP attr= ibute "mode-set-recv" to indicate EVRCNW wideband decoding capability and p= reference. The indication of EVRCNW wideband decoding capability and prefe= rence can also be communicated to the other side via the mode request field= "MMM" during an active session. Proposal RFC3558 recommends that mode change request is applicable to two-party call= s only and not to multi-party calls. (Section 10) The Mode Request signal requests a particular encoding mode for the speech = encoding in the reverse direction. All implementations are RECOMMENDED to = honor the Mode Request signal. The Mode Request signal SHOULD only be used= in one-to-one sessions. In multi-party sessions, any received Mode Reques= t signals SHOULD be ignored. It is believed that mode request should be applicable to EVRCNW operation i= n both two-party and conference calls. In particular, mode request is nece= ssary to activate EVRCNW narrowband-to-wideband and wideband-to-narrowband = switching during an active two-party or conference call session. It is proposed that the following texts for mode request usage be considere= d for media subtype EVRCNW payload format. Original text: Section 6 Three RTP packet formats are supported for the EVRC-NW codec - the inter= leaved/bundled packet format, the header-free packet format and the compact= bundled packet format. For all these formats, the operational details and= capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are= exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3]= , except that the mode change request field in the ToC MUST be interpreted = according to the definition of the RATE_REDUC parameter as defined in EVRC-= NW [4]. The media type audio/EVRCNW maps to the interleaved/bundled packet = format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCN= W1 maps to the compact bundled packet format. Suggested text: Section 6 Three RTP packet formats are supported for the EVRC-NW codec - the inter= leaved/bundled packet format, the header-free packet format and the compact= bundled packet format. For all these formats, the operational details and= capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW are= exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and [3]= , except that (1) the mode change request field in the ToC interleaved/bund= led packet format MUST be interpreted according to the definition of the RA= TE_REDUC parameter as defined in EVRC-NW [4] and (2) the mode change reques= t field in interleaved/bundled packet format SHOULD be honored by an EVRCNW= encoding end point in an one-to-one session with a dedicated EVRCNW decodi= ng end point such as in a two-party call or in a conference leg. The media = type audio/EVRCNW maps to the interleaved/bundled packet format, audio/EVRC= NW0 maps to the header-free packet format and audio/EVRCNW1 maps to the com= pact bundled packet format. The suggested changes are for media subtype EVRCNW payload format only. Th= ey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats = where the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6EUSAACMS0702e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Background
 
Draft "draft-ietf-avt-rtp-e= vrc-nw-02" defines the RTP payload formats and corresponding me= dia type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.S0014-D]. = EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2.  This codec supports a total of 8 modes of operation for nar= rowband and wideband voice band traffic compression.  Mode-0 is for wi= deband compression.  Mode-1 to mode-7 are for narrowband compression w= here mode-4 is defined as the default mode.  The average encoding rate for narrowband operation is decreased with increasing= operating mode from mode-1 to mode-7.
 
Three media subtype payload formats are defined in this draft.  T= hey are EVRCNW, EVRCNW0 and EVRCNW1.  This email concerns with operati= ons associated with the media subtype EVRCNW payload format definition.
 
Media subtype EVRCNW payload format is defined with a payload header w= hich consists of a 3-bit mode request field "MMM" and other paylo= ad related parameters [Ref. RFC3558].  Per MMM definition in RFC3558, = EVRCNW traffic receiver uses this field to request an EVRCNW encoding mode to be used by the EVRCNW traffic generator for new = traffic in the reverse path.
 
    0  =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   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
   +-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+
   |   =             &nb= sp;      RTP Header [4]    &nb= sp;            =           |
   +=3D+=3D= 3;=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= 3;=3D+=3D+
   |R|R| LLL | NNN | M= MM |  Count  |  TOC  |  ...  |  TOC = ; |padding|
   +-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+
   |   =      one or more codec data frames, one per TOC entry&n= bsp;      |
   |   =             &nb= sp;            = ....           &nbs= p;            &= nbsp;     |
   +-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+
 
 
Per draft "draft-ietf-avt-r= tp-evrc-nw-02", EVRCNW operates in narrowband mode-4 by default= .  EVRCNW encoder operates in wideband mode only when an EVRCNW encode= r receives indication of the EVRCNW wideband decoding capability and preference from the other side.   The draft adopts= an optional SDP attribute "mode-set-recv" to indicate EVRCNW wid= eband decoding capability and preference.  The indication of EVRCNW wi= deband decoding capability and preference can also be communicated to the other side via the mode request field "MMM" during an acti= ve session.
 
Proposal
 
RFC3558 recommends that mode change request is applicable to two-party= calls only and not to multi-party calls. 
 
(Section 10)
The Mode Request signal requests= a particular encoding mode for the speech encoding in the reverse directio= n.  All implementations are RECOMMENDED to honor the Mode Request sign= al.  The Mode Request signal SHOULD only be used in one-to-one sessions.  In multi-party sessions, any received= Mode Request signals SHOULD be ignored.
 
 
It is believed that mode request should be applicable to EVRCNW operat= ion in both two-party and conference calls.  In particular, mode reque= st is necessary to activate EVRCNW narrowband-to-wideband and wideband-to-n= arrowband switching during an active two-party or conference call session.
 
It is proposed that the following texts for mode request usage be cons= idered for media subtype EVRCNW payload format.
 
 
 
Original text: Section 6<= /font>
 
   Three RTP packet fo= rmats are supported for the EVRC-NW codec - the interleaved/bundled packet = format, the header-free packet format and the compact bundled packet format= .  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW = are exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and = [3], except that the mode change request field in the ToC MUST be interpret= ed according to the definition of the RATE_REDUC parameter as defined in EVRC-NW [4]. The media type audio/EV= RCNW maps to the interleaved/bundled packet format, audio/EVRCNW0 maps to t= he header-free packet format and audio/EVRCNW1 maps to the compact bundled = packet format.
 
Suggested text: Section 6=
 
   Three RTP packet fo= rmats are supported for the EVRC-NW codec - the interleaved/bundled packet = format, the header-free packet format and the compact bundled packet format= .  For all these formats, the operational details and capabilities, such as ToC, interleaving, DTX, and bundling, of EVRC-NW = are exactly the same as those of EVRC-B and EVRC-WB, as defined in [2] and = [3], except that (1) the mode change request= field in the ToC interleaved/bundled packet form= at MUST be interpreted according to the definition of the RATE_REDUC= parameter as defined in EVRC-NW [4] and (2) the mo= de change request field in interleaved/bundled packet format SHOULD be honored by an EVRCNW encoding end point in an one-t= o-one session with a dedicated EVRCNW decoding end point such as in a two-p= arty call or in a conference leg. The media type audio/EVRCNW maps t= o the interleaved/bundled packet format, audio/EVRCNW0 maps to the header-free packet format and audio/EVRCN= W1 maps to the compact bundled packet format.
 
 
 
 
 
The suggested changes are for media subtype EVRCNW payload format only= .  They are not applicable to media subtype EVRCNW0 and EVRCNW1 payloa= d formats where the MMM mode request field is not supported. 
 
 
 
Regards,
 
CC
 
 
Chung-Cheung Chu
Media Gateway DSP Design
BCAM - Ericsson
+514 345-7900 (x46489)
This Communication= is Confidential.  We only send and receive email on the basis of the = terms set out at www.ericsson.com/email_disclaimer<= i>.
 
 
 --_000_26490BBDEEACA14EA1A0070367B3ADBDB77844EFD6EUSAACMS0702e_-- From Rea@worldcastsystems.com Fri Apr 15 08:51:45 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5CEC1E08F3 for ; Fri, 15 Apr 2011 08:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, 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 HzySDjusQp8o for ; Fri, 15 Apr 2011 08:51:40 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfc.amsl.com (Postfix) with ESMTP id 61FF4E06A9 for ; Fri, 15 Apr 2011 08:51:39 -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_01CBFB85.0169C58E" Date: Fri, 15 Apr 2011 16:47:34 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02626A4F@APTSBS.apt.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: draft-rea-avt-rtp-aptx-00.txt Thread-Index: Acv7hIzQy7CFA0mAQDmAq0oRY52rlw== From: "Derrick Rea" To: Subject: [payload] draft-rea-avt-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 15:51:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFB85.0169C58E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBFB85.0169C58E" ------_=_NextPart_002_01CBFB85.0169C58E 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), submitted to = the Audio /Video Transport Working Group. 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. =20 Regards,=20 Derrick Rea =20 =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_01CBFB85.0169C58E 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/msg3728= 3.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), submitted to the Audio /Video Transport Working Group. = I’ve added and changed some sections in the internet-draft but = others remain wholly unchanged since the Trainor draft.  =

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.  

Regards, =

Derrick = Rea

 

 

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_01CBFB85.0169C58E-- ------_=_NextPart_001_01CBFB85.0169C58E 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_01CBFB85.0169C58E 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_01CBFB85.0169C58E 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_01CBFB85.0169C58E 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_01CBFB85.0169C58E 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_01CBFB85.0169C58E-- From Rea@worldcastsystems.com Fri Apr 15 09:37:57 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A75B8E06BA for ; Fri, 15 Apr 2011 09:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, 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 Y2k60cV26GzU for ; Fri, 15 Apr 2011 09:37:52 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfc.amsl.com (Postfix) with ESMTP id 85055E06A9 for ; Fri, 15 Apr 2011 09:37:51 -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_01CBFB8B.75D4F5A2" Date: Fri, 15 Apr 2011 17:33:31 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02626A50@APTSBS.apt.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Re: draft-rea-avt-rtp-aptx-00.txt Thread-Index: Acv7im3E8ni2KLbMSxu9xCWp77aY7A== From: "Derrick Rea" To: Subject: Re: [payload] draft-rea-avt-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:37:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFB8B.75D4F5A2 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBFB8B.75D4F5A2" ------_=_NextPart_002_01CBFB8B.75D4F5A2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry I'm meant to say -: =20 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 Payloads Working Group.=20 =20 Can this document also appear on the = http://datatracker.ietf.org/wg/payload/ webpage as a related document? =20 Regards, Derrick =20 From: Derrick Rea=20 Sent: 15 April 2011 16:48 To: 'payload@ietf.org' Subject: draft-rea-avt-rtp-aptx-00.txt =20 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), submitted to = the Audio /Video Transport Working Group. 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. =20 Regards,=20 Derrick Rea =20 =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_01CBFB8B.75D4F5A2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry = I’m meant to say -:

 

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 Payloads Working = Group.

 

Can this document also appear on the http://datatracker.ietf.= org/wg/payload/ webpage as a related document?

 

Regards,

Derrick

 

From: Derrick Rea
Sent: 15 April 2011 = 16:48
To: 'payload@ietf.org'
Subject: = draft-rea-avt-rtp-aptx-00.txt

 

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/msg3728= 3.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), submitted to the Audio /Video Transport Working Group. = I’ve added and changed some sections in the internet-draft but = others remain wholly unchanged since the Trainor draft.  =

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.  

Regards, =

Derrick = Rea

 

 

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

 =

3D"Description:

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.

 

------_=_NextPart_002_01CBFB8B.75D4F5A2-- ------_=_NextPart_001_01CBFB8B.75D4F5A2 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_01CBFB8B.75D4F5A2 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_01CBFB8B.75D4F5A2 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_01CBFB8B.75D4F5A2 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_01CBFB8B.75D4F5A2 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_01CBFB8B.75D4F5A2-- From hlundin@google.com Fri Apr 15 14:18:41 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE9C4E07D2 for ; Fri, 15 Apr 2011 14:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KRYztn5QvrD0 for ; Fri, 15 Apr 2011 14:18:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfc.amsl.com (Postfix) with ESMTP id B7AF6E0674 for ; Fri, 15 Apr 2011 14:18:40 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p3FLIdLP019258 for ; Fri, 15 Apr 2011 14:18:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1302902320; bh=VtuYErq8Vcr91HXpBozK/fjlBC8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=S9QwGE264Xs1jDNm61bGLVakPa6EvOIEHexcMQ8Rli7QyLG6FIT6r76Y5fSotxk/I 9rDQgvrYKAcn7H65A/PwQ== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by hpaq13.eem.corp.google.com with ESMTP id p3FLI8a6019327 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 15 Apr 2011 14:18:38 -0700 Received: by gyf1 with SMTP id 1so1176564gyf.20 for ; Fri, 15 Apr 2011 14:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2JyhnAupFxv34iSe6KLf90sE+P5QQZ5YN/iI64ohjVI=; b=sPkQYl0Ly+eYKohh6YZBm7gWE2hyb0zh1evmHjv9XBNPwNBBMsF7G1j5a9PJzOX2Ka /ty1Pnx7mEtFkiC1G/+A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i7GcFMGAYonvAN/Big8kEQ2f8Dp5JHZH43APo386bROQDkEAqoNwr75EmgUpsq+zB4 qk/DL6zb3pPS+FitHTnA== MIME-Version: 1.0 Received: by 10.101.206.36 with SMTP id i36mr1439818anq.4.1302902317986; Fri, 15 Apr 2011 14:18:37 -0700 (PDT) Received: by 10.100.136.12 with HTTP; Fri, 15 Apr 2011 14:18:37 -0700 (PDT) In-Reply-To: <014601cbfb3d$6ccd93e0$4668bba0$%roni@huawei.com> References: <014601cbfb3d$6ccd93e0$4668bba0$%roni@huawei.com> Date: Fri, 15 Apr 2011 23:18:37 +0200 Message-ID: From: Henrik Lundin To: Roni Even Content-Type: multipart/alternative; boundary=0016e68ee3e5d732fd04a0fb9517 X-System-Of-Record: true Cc: payload@ietf.org, patrik.westin@gmail.com Subject: Re: [payload] Accepting draft-westin-payload-vp8-02 as a Payload WG document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:18:41 -0000 --0016e68ee3e5d732fd04a0fb9517 Content-Type: text/plain; charset=ISO-8859-1 Hi Roni, We will submit it next week. Thanks, /Henrik Lundin On Fri, Apr 15, 2011 at 9:19 AM, Roni Even wrote: > Hi guys, > > Since there were no objections or other proposal please submit draft-westin-payload-vp8-02 > as a Payload working group document " draft-ietf-payload-vp8-00" > > > > Thanks > > Roni Even > > Payload co-chair > > > > > --0016e68ee3e5d732fd04a0fb9517 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roni,

We will submit it next week.

Thanks,
/Henrik Lundin



On Fri, Apr 15, 2011 at 9:19 AM, Roni Even <Even.roni@huawei.com= > wrote:

Hi guys,

Sinc= e there were no objections or other proposal please submit draft-westin-payload-vp8-02 as a Payload working group document " dr= aft-ietf-payload-vp8-00"

=A0

Thanks

Roni Even

Payload co= -chair

=A0

=A0


--0016e68ee3e5d732fd04a0fb9517-- From Even.roni@huawei.com Fri Apr 15 22:46:47 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@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: [payload] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts - concluded X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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: payload@ietfc.amsl.com Delivered-To: payload@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: [payload] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts - concluded X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Rea@worldcastsystems.com Mon Apr 18 02:57:54 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 64FC0E0754 for ; Mon, 18 Apr 2011 02:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_05=-1.11, 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 jjWJskUl-3r3 for ; Mon, 18 Apr 2011 02:57:53 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfc.amsl.com (Postfix) with ESMTP id 589F0E0707 for ; Mon, 18 Apr 2011 02:57:52 -0700 (PDT) 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_01CBFDAF.14B97B65" Date: Mon, 18 Apr 2011 10:57:51 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02626A54@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-rea-avt-rtp-aptx-00 renamed draft-rea-payload-rtp-aptx-00 Thread-Index: Acv9rGa399ZJHh1kSUOOxIEli5DCzg== From: "Derrick Rea" To: Subject: [payload] draft-rea-avt-rtp-aptx-00 renamed draft-rea-payload-rtp-aptx-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 09:57:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFDAF.14B97B65 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've renamed and re-submitted draft-rea-avt-rtp-aptx-00 as draft-rea-payload-rtp-aptx-00 so that it can be associated with the Audio/Video Transport Payloads working group. Can all future discussions refer to the new draft-rea-payload-rtp-aptx-00 document.=20 Regards, Derrick Rea ------_=_NextPart_001_01CBFDAF.14B97B65 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve = renamed and re-submitted draft-rea-avt-rtp-aptx-00 as = draft-rea-payload-rtp-aptx-00 so that it can be associated with the = Audio/Video Transport Payloads working = group. Can all future discussions refer to the new = draft-rea-payload-rtp-aptx-00 document.

Regards,

Derrick = Rea

------_=_NextPart_001_01CBFDAF.14B97B65-- From zfang@qualcomm.com Wed Apr 20 19:25:07 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 53B13E0712 for ; Wed, 20 Apr 2011 19:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.600, 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 E9z89fMBkXPs for ; Wed, 20 Apr 2011 19:24:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfc.amsl.com (Postfix) with ESMTP id CC181E06DB for ; Wed, 20 Apr 2011 19:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1303352697; x=1334888697; h=from:to:date:subject:thread-topic:thread-index: message-id:references:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Fang,=20Zheng"=20|To:=20Chu ng=20Cheung=20Chu=20,=20"p ayload@ietf.org"=0D=0A=09|Date:=20Wed, =2020=20Apr=202011=2019:24:55=20-0700|Subject:=20RE:=20Ch ange=20proposal=20to=20draft=20"draft-ietf-avt-rtp-evrc-n w-02"|Thread-Topic:=20Change=20proposal=20to=20draft=20"d raft-ietf-avt-rtp-evrc-nw-02"|Thread-Index:=20Acv1Jb8riP8 RBI1FS1qqLbHSHs3ktgGTpXNAARNZY2AAAMekMA=3D=3D|Message-ID: =20<909F74681826104B8F3162A1A782323B5114E8AA86@NALASEXMB1 3.na.qualcomm.com>|References:=20<26490BBDEEACA14EA1A0070 367B3ADBDB77844F033@EUSAACMS0702.eamcs.ericsson.se>=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:=20yes|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20multipart/mixed =3B=0D=0A=09boundary=3D"_004_909F74681826104B8F3162A1A782 323B5114E8AA86NALASEXMB13na_"|MIME-Version:=201.0; bh=uZuileaNFCPWvbknIBngOpqK9OPwL9fOlMbXlMw5sos=; b=LOE5N3lyPY2dyANeFL0aiDw1LOktUhOeD2My5auBirCLSKjsoGbGiJqj 3EIkXRS3IrYgmbmeXtwxDdDlHrOFMTlcxDQAxaik2ZwS5VAQ6UwSuc1Pf lia7Z95n5e0mFx3MGA7MY4cdgewwQEgmxJnMvBJ/Ozpv4dmZ3qIQ0Ti+Z E=; X-IronPort-AV: E=McAfee;i="5400,1158,6322"; a="87015797" Received: from ironmsg03-lv.qualcomm.com ([10.47.202.181]) by wolverine01.qualcomm.com with ESMTP; 20 Apr 2011 19:24:56 -0700 X-IronPort-AV: E=Sophos;i="4.64,247,1301900400"; d="diff'?scan'208,217";a="40945" Received: from nalasexhc07.na.qualcomm.com ([10.47.27.141]) by ironmsg03-lv.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Apr 2011 19:24:56 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by NALASEXHC07.na.qualcomm.com (10.47.27.141) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 20 Apr 2011 19:24:56 -0700 Received: from NALASEXMB13.na.qualcomm.com ([10.47.6.157]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 20 Apr 2011 19:24:56 -0700 From: "Fang, Zheng" To: Chung Cheung Chu , "payload@ietf.org" Date: Wed, 20 Apr 2011 19:24:55 -0700 Thread-Topic: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Thread-Index: Acv1Jb8riP8RBI1FS1qqLbHSHs3ktgGTpXNAARNZY2AAAMekMA== Message-ID: <909F74681826104B8F3162A1A782323B5114E8AA86@NALASEXMB13.na.qualcomm.com> References: <26490BBDEEACA14EA1A0070367B3ADBDB77844F033@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_" MIME-Version: 1.0 Subject: Re: [payload] Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 02:25:07 -0000 --_004_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_ Content-Type: multipart/alternative; boundary="_000_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_" --_000_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chung Cheung, Thanks for your comments (in this email and the previous one "Mode request = support in draft-ietf-avt-rtp-evrc-nw-02"). I adopted the changes accordingly. The diff is attached. Basically, 1) The clarifications regarding mode request support are adopted as you sug= gested. There are some wording differences, but those are inconsequential. 2) For the changes related to "sendmode", I instead would like to propose d= eprecating this parameter in EVRC-NW. I believe, by deprecating the "sendmo= de" parameter, this not only addresses the concerns you had, but also avoid= s further confusion in other usage scenarios which were not covered in your= emails. As an result, the "sendmode" attribute is removed from all the examples= as well. Please let me know if you have any additional comments; otherwise, I will s= ubmit this new version to the I-D repository later. Thanks, Zheng From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] Sent: Friday, April 15, 2011 6:53 AM To: payload@ietf.org; Fang, Zheng Subject: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Background Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and c= orresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.= S0014-D]. EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2. Th= is codec supports a total of 8 modes of operation for narrowband and wideba= nd voice band traffic compression. Mode-0 is for wideband compression. Mo= de-1 to mode-7 are for narrowband compression where mode-4 is defined as th= e default mode. The average encoding rate for narrowband operation is decr= eased with increasing operating mode from mode-1 to mode-7. Three media subtype payload formats are defined in this draft. They are EV= RCNW, EVRCNW0 and EVRCNW1. This email concerns with operations associated = with the media subtype EVRCNW payload format definition. Media subtype EVRCNW payload format is defined with a payload header which = consists of a 3-bit mode request field "MMM" and other payload related para= meters [Ref. RFC3558]. Per MMM definition by RFC3558, EVRCNW traffic recei= ver uses this field to request an EVRCNW encoding mode to be used by the EV= RCNW traffic generator for new traffic in the reverse path. Draft "draft-ietf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes "m= ode-set-recv" and "sendmode" from RFC5188. Attribute "mode-set-recv" is us= ed to indicate the preferred mode of bearer traffic supported by an EVRCNW = receiver. This attribute can assume a set of values 0, 1, ..., 7 denoting = mode-0, mode-1, ..., mode-7 support, respectively. Attribute "sendmode" is= used to announce the current EVRCNW encoding mode by an EVRCNW encoder. The draft states that in absence of mode-0 specification in "mode-set-recv"= or in absence of the attribute, an EVRCNW encoder at the other side can on= ly operate in narrowband mode. In absence of attribute "sendmode", the enc= oding mode is mode-4. Proposal It is understood that an EVRCNW encoder cannot autonomously generate and se= nd EVRC-NW mode-0 (wideband) traffic to the partner in absence of the partn= er's mode-0 (wideband) decoding capability. However, a user capable of dec= oding mode-0 (wideband) traffic should be allowed to request for mode-0 (wi= deband) traffic from the partner using the MMM field in the RTP RFC header.= Such an in-band request is an implicit indication of mode-0 (wideband) de= coding capability of the originator. Upon receiving the mode-0 (wideband) = request, a mode-0 (wideband) capable partner should be allowed to generate = and send EVRC-NW wideband encoded traffic to the request originator, regard= less of the SDP attribute "mode-set-recv". A partner not capable of wideba= nd encoding can ignore the request and should use a narrowband mode. An example where the MMM mode change request field facilitates narrowband-t= o-wideband and wideband-to-narrowband operation switching is as follows: An EVRCNW transcoding free (TrFO) call is established in a session between = mobile-A in a circuit switched network and mobile-B in a 4G network via a c= ommunication node in the core network, such as a media gateway. In this e= xample, mobile-A supports EVRCNW without wideband compression capability, a= nd mobile-B supports EVRCNW with wideband compression capability. The medi= a gateway sends at call setup time SDP mode-set-recv attribute to mobile-B = specifying only narrowband mode support in light of mobile-A EVRCNW wideban= d incapability. During the call, a call transfer (or call waiting) takes p= lace replacing mobile-A with an EVRCNW wideband capable device, mobile-C. = In this example, the media gateway does not update the optional SDP mode-se= t-recv attribute on the stationary side to mobile-B. In this scenario, EVRCNW wideband operation is allowed between mobile-C and= the media gateway but not feasible between the media gateway and mobile-B = according to the mode-set-recv definition in the current draft. This could= result in end-to-end EVRCNW operation in narrowband mode only. If MMM mod= e change requests for mode-0 traffic relayed from mobile-C is allowed and s= upported by mobile-B, end-to-end EVRCNW transcoding free operation would be= re-established in wideband mode. Conversely, when the wideband support capability is terminated during an ac= tive call session, for example due to a call transfer (or call waiting) bac= k from mobile-C to mobile-A, mode change requests relayed from mobile-A for= narrowband operation should be considered as a preference indication that = narrowband traffic is desired by the originator. Mobile-B should honor the= request and return narrowband compressed traffic. This is required even i= f the mode-set-recv SDP attribute from the media gateway to mobile-B includ= es mode-0 support. It is proposed that the following texts for media subtype EVRCNW SDP attrib= utes "mode-set-recv" and "sendmode" be clarified: Original text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. Suggested text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. During an active call session, the MMM mode request received from a communi= cation partner complements the mode set information in mode-set-recv. A mo= de request with MMM=3D0 from a communication partner is an implicit indicat= ion of the partner's EVRCNW wideband decoding capability and preference. A= n EVRCNW wideband capable node receiving the request can operate in wideban= d mode. A mode request with MMM=3D1, 2, ..., or 7 from a communication par= tner is an implicit indication of the partner's EVRCNW narrowband decoding = capability and preference. An EVRCNW node receiving the request should hon= or the request and operate in narrowband mode. Original text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter, an encod= er at the other side shall not operate in mode 0. Suggested text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter and in th= e MMM mode request field in media subtype EVRCNW payload format, an encoder= at the other side shall not operate in mode 0. Original text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. Suggested text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. It is not necessary to send this optional SDP attribute when an EVRCNW e= ncoder updates its encoding mode during an active call session such as in r= esponse to requests in the MMM mode request field from the other side. Conv= ersely, absence of this SDP attribute should not be interpreted as an indic= ation the encoder operates only in default mode-4. The suggested changes are for media subtype EVRCNW payload format only. Th= ey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats = where the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chung = Cheung,

 <= /span>

Thanks for your comments (in this ema= il and the previous one “Mode request support in draft-ietf-avt-rtp-e= vrc-nw-02").

&nb= sp;

I adopted the changes accor= dingly. The diff is attached.

 

Basically,

= 1) The clarifications regarding mode request support are adopted as you sug= gested. There are some wording differences, but those are inconsequential.<= o:p>

2) For the changes related= to “sendmode”, I instead would like to propose deprecating thi= s parameter in EVRC-NW. I believe, by deprecating the “sendmode”= ; parameter, this not only addresses the concerns you had, but also avoids = further confusion in other usage scenarios which were not covered in your e= mails.  

    As an result, the “sendmode&= #8221; attribute is removed from all the examples as well.

 

Please let me know if you have any additional comments; other= wise, I will submit this new version to the I-D repository later.

 

Thanks,

Zheng

 =

 

From: Chung Cheung Chu [mailto:chung.cheung.chu@er= icsson.com]
Sent: Friday, April 15, 2011 6:53 AM
To: p= ayload@ietf.org; Fang, Zheng
Subject: Change proposal to draft &q= uot;draft-ietf-avt-rtp-evrc-nw-02"

 

 

 

Background

 

Draft "draft-ietf-avt-rtp-evrc-nw-02<= /span>&qu= ot; defines the RTP payload formats and corresponding media type registrati= ons for CDMA codec EVRC-NW [Ref. 3GPP2 C.S0014-D].  EVRC-NW is a multi= -rate low bit rate codec adopted by 3GPP2.  This codec supports a tota= l of 8 modes of operation for narrowband and wideband voice band traffic co= mpression.  Mode-0 is for wideband compression.  Mode-1 to mode-7= are for narrowband compression where mode-4 is defined as the default mode= .  The average encoding rate for narrowband operation is decreased wit= h increasing operating mode from mode-1 to mode-7.

 <= /span>

Three media subtype payload formats are de= fined in this draft.  They are EVRCNW, EVRCNW0 and EVRCNW1.  This= email concerns with operations associated with the media subtype EVRCNW pa= yload format definition.

 

Media subtype EVRCNW payload format is defined with a payload heade= r which consists of a 3-bit mode request field "MMM" and other pa= yload related parameters [Ref. RFC3558].  Per MMM definition by RFC355= 8, EVRCNW traffic receiver uses this field to request an EVRCNW encoding mo= de to be used by the EVRCNW traffic generator for new traffic in the revers= e path.<= /span>

 

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Draft &quo= t;draft-i= etf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes "mode-se= t-recv" and "sendmode" from RFC5188.  Attribute "m= ode-set-recv" is used to indicate the preferred mode of bearer traffic= supported by an EVRCNW receiver.  This attribute can assume a set of = values 0, 1, …, 7 denoting mode-0, mode-1, …, mode-7 support, r= espectively.  Attribute "sendmode" is used to announce the c= urrent EVRCNW encoding mode by an EVRCNW encoder.

=  

The draft states that in absence of mode-0 = specification in "mode-set-recv" or in absence of the attribute, = an EVRCNW encoder at the other side can only operate in narrowband mode.&nb= sp; In absence of attribute "sendmode", the encoding mode is mode= -4.

 

 <= span style=3D'font-family:"Arial","sans-serif"'>

Proposal

 

<= div>

It is understood that an EVRCNW encoder cannot autonomously= generate and send EVRC-NW mode-0 (wideband) traffic to the partner in abse= nce of the partner's mode-0 (wideband) decoding capability.  However, = a user capable of decoding mode-0 (wideband) traffic should be allowed to r= equest for mode-0 (wideband) traffic from the partner using the MMM field i= n the RTP RFC header.  Such an in-band request is an implicit indicati= on of mode-0 (wideband) decoding capability of the originator.  Upon r= eceiving the mode-0 (wideband) request, a mode-0 (wideband) capable partner= should be allowed to generate and send EVRC-NW wideband encoded traffic to= the request originator, regardless of the SDP attribute "mode-set-rec= v".  A partner not capable of wideband encoding can ignore the re= quest and should use a narrowband mode. 

&nb= sp;

An example where the MMM mode change request f= ield facilitates narrowband-to-wideband and wideband-to-narrowband operatio= n switching is as follows:

 

An EVRCNW transcoding free (TrFO) call is established in a session= between mobile-A in a circuit switched network and mobile-B in a 4G networ= k via a communication node in the core network, such as a media gateway.&nb= sp;  In this example, mobile-A supports EVRCNW without wideband compre= ssion capability, and mobile-B supports EVRCNW with wideband compression ca= pability.  The media gateway sends at call setup time SDP mode-set-rec= v attribute to mobile-B specifying only narrowband mode support in light of= mobile-A EVRCNW wideband incapability.  During the call, a call trans= fer (or call waiting) takes place replacing mobile-A with an EVRCNW wideban= d capable device, mobile-C.  In this example, the media gateway does n= ot update the optional SDP mode-set-recv attribute on the stationary side t= o mobile-B.  <= o:p>

 

In this scenario, EVRCNW wideband operation is allowed between mobile-C an= d the media gateway but not feasible between the media gateway and mobile-B= according to the mode-set-recv definition in the current draft.  This= could result in end-to-end EVRCNW operation in narrowband mode only. = If MMM mode change requests for mode-0 traffic relayed from mobile-C is al= lowed and supported by mobile-B, end-to-end EVRCNW transcoding free operati= on would be re-established in wideband mode.

 = ;=

Conversely, when the wideband support capability= is terminated during an active call session, for example due to a call tra= nsfer (or call waiting) back from mobile-C to mobile-A, mode change request= s relayed from mobile-A for narrowband operation should be considered as a = preference indication that narrowband traffic is desired by the originator.=   Mobile-B should honor the request and return narrowband compressed t= raffic.  This is required even if the mode-set-recv SDP attribute from= the media gateway to mobile-B includes mode-0 support.

 

 

 =

It is proposed that the following t= exts for media subtype EVRCNW SDP attributes "mode-set-recv" and = "sendmode" be clarified:

 

=

 

Original text: Section 9.1.1

mode-set-recv: A subset of EVRC-NW modes.  Possib= le values are a comma separated list of modes from the set {0,1,2,3,4,5,6,7= } (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can use this at= tribute to inform an encoder of its preference to operate in a specified su= bset of modes.  Absence of this parameter signals the mode set {1,2,3,= 4,5,6,7}.

 

Suggested text: Sec= tion 9.1.1=

mode-set-recv: A subset of EVRC-NW modes.&= nbsp; Possible values are a comma separated list of modes from the set {0,1= ,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A decoder can= use this attribute to inform an encoder of its preference to operate in a = specified subset of modes.  Absence of this parameter signals the mode= set {1,2,3,4,5,6,7}.

 

During an active call session, the MMM mode request received from a commun= ication partner complements the mode set information in mode-set-recv. = ; A mode request with MMM=3D0 from a communication partner is an implicit i= ndication of the partner's EVRCNW wideband decoding capability and preferen= ce.  An EVRCNW wideband capable node receiving the request can operate= in wideband mode.  A mode request with MMM=3D1, 2, …, or 7 from= a communication partner is an implicit indication of the partner's EVRCNW = narrowband decoding capability and preference.  An EVRCNW node receivi= ng the request should honor the request and operate in narrowband mode.  =

 

 

=

Original text: Section 10

=

 

Suggested text: Section 10

   1.  To inform the capability of wideban= d mode support: A decoder can always decode all the narrowband modes (modes= 1 to 7).  Unless the decoder indicates the support of mode 0 (i.e., p= reference) in this parameter and in the MMM mode= request field in media subtype EVRCNW payload format, an encoder at= the other side shall not operate in mode 0.

 

 =

 

Original = text: Section 9.1.1

   sendmode: A mode of = the EVRC-NW codec.  An encoder can use this to signal its current mode= of operation.  Possible values are 0,1,2,3,4,5,6,7 (see Table 2.6.1.2= -4 in 3GPP2 C.S0014-D).  Absence of this parameter signals mode 4.

<= /div>

 

Suggested text: Section 9.1.1=

   sendmode: A mode of the EVRC-NW codec.&nbs= p; An encoder can use this to signal its current mode of operation.  P= ossible values are 0,1,2,3,4,5,6,7 (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D)= .  Absence of this parameter signals mod= e 4.

   It is not necessa= ry to send this optional SDP attribute when an EVRCNW encoder updates its e= ncoding mode during an active call session such as in response to requests = in the MMM mode request field from the other side. Conversely, absence of t= his SDP attribute should not be interpreted as an indication the encoder op= erates only in default mode-4.

 

 <= /span>

The suggested changes are for media subtyp= e EVRCNW payload format only.  They are not applicable to media subtyp= e EVRCNW0 and EVRCNW1 payload formats where the MMM mode request field is n= ot supported. 

 

 

 

Regards= ,=

 

CC

=

 <= o:p>

Chung-Cheung Chu

<= p class=3DMsoNormal>Media Gateway DSP Design

BCAM - Ericsso= n=

+514 345-7900 (x46489)

This Communication is Confiden= tial.  We only send and receive email on the basis of the terms set ou= t at www.ericsson.com/email_disclaimer.

=

 

<= /div>

 

= --_000_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_-- --_004_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_ Content-Type: application/octet-stream; name="draft-ietf-avt-rtp-evrc-nw-03-from-2.diff" Content-Description: draft-ietf-avt-rtp-evrc-nw-03-from-2.diff Content-Disposition: attachment; filename="draft-ietf-avt-rtp-evrc-nw-03-from-2.diff"; size=16426; creation-date="Wed, 20 Apr 2011 19:22:57 GMT"; modification-date="Wed, 20 Apr 2011 19:22:07 GMT" Content-Transfer-Encoding: base64 LS0tIDEvZHJhZnQtaWV0Zi1hdnQtcnRwLWV2cmMtbnctMDIudHh0CTIwMTEtMDQtMjAgMTk6MjI6 MDcuOTUyMzg0OTk1IC0wNzAwCisrKyAyL2RyYWZ0LWlldGYtYXZ0LXJ0cC1ldnJjLW53LTAzLnR4 dAkyMDExLTA0LTIwIDE5OjIyOjA3Ljk2MjM4NTQ5OCAtMDcwMApAQCAtODMsMjMgKzgzLDMxIEBA CiAgICB0YWxrc3B1cnQuICBGb3IgYWxsIG90aGVyIHBhY2tldHMgdGhlIG1hcmtlciBiaXQgU0hB TEwgYmUgc2V0IHRvIHplcm8KICAgIChNPTApLgogCiA2LiAgUGF5bG9hZCBmb3JtYXQKIAogICAg VGhyZWUgUlRQIHBhY2tldCBmb3JtYXRzIGFyZSBzdXBwb3J0ZWQgZm9yIHRoZSBFVlJDLU5XIGNv ZGVjIC0gdGhlCiAgICBpbnRlcmxlYXZlZC9idW5kbGVkIHBhY2tldCBmb3JtYXQsIHRoZSBoZWFk ZXItZnJlZSBwYWNrZXQgZm9ybWF0IGFuZAogICAgdGhlIGNvbXBhY3QgYnVuZGxlZCBwYWNrZXQg Zm9ybWF0LiAgRm9yIGFsbCB0aGVzZSBmb3JtYXRzLCB0aGUKICAgIG9wZXJhdGlvbmFsIGRldGFp bHMgYW5kIGNhcGFiaWxpdGllcywgc3VjaCBhcyBUb0MsIGludGVybGVhdmluZywgRFRYLAogICAg YW5kIGJ1bmRsaW5nLCBvZiBFVlJDLU5XIGFyZSBleGFjdGx5IHRoZSBzYW1lIGFzIHRob3NlIG9m IEVWUkMtQiBhbmQKLSAgIEVWUkMtV0IsIGFzIGRlZmluZWQgaW4gWzJdIGFuZCBbM10sIGV4Y2Vw dCB0aGF0IHRoZSBtb2RlIGNoYW5nZQotICAgcmVxdWVzdCBmaWVsZCBpbiB0aGUgVG9DIE1VU1Qg YmUgaW50ZXJwcmV0ZWQgYWNjb3JkaW5nIHRvIHRoZQotICAgZGVmaW5pdGlvbiBvZiB0aGUgUkFU RV9SRURVQyBwYXJhbWV0ZXIgYXMgZGVmaW5lZCBpbiBFVlJDLU5XIFs0XS4KKyAgIEVWUkMtV0Is IGFzIGRlZmluZWQgaW4gWzJdIGFuZCBbM10sIGV4Y2VwdCB0aGF0CisKKyAgIDEuICB0aGUgbW9k ZSBjaGFuZ2UgcmVxdWVzdCBmaWVsZCBpbiB0aGUgaW50ZXJsZWF2ZWQvYnVuZGxlZCBwYWNrZXQK KyAgICAgICBmb3JtYXQgTVVTVCBiZSBpbnRlcnByZXRlZCBhY2NvcmRpbmcgdG8gdGhlIGRlZmlu aXRpb24gb2YgdGhlCisgICAgICAgUkFURV9SRURVQyBwYXJhbWV0ZXIgYXMgZGVmaW5lZCBpbiBF VlJDLU5XIFs0XS4KKworICAgMi4gIHRoZSBtb2RlIGNoYW5nZSByZXF1ZXN0IGZpZWxkIGluIHRo ZSBpbnRlcmxlYXZlZC9idW5kbGVkIHBhY2tldAorICAgICAgIGZvcm1hdCBTSE9VTEQgYmUgaG9u b3JlZCBieSBhbiBFVlJDTlcgZW5jb2RpbmcgZW5kIHBvaW50IGluIGFuCisgICAgICAgb25lLXRv LW9uZSBzZXNzaW9uIHdpdGggYSBkZWRpY2F0ZWQgRVZSQ05XIGRlY29kaW5nIGVuZCBwb2ludAor ICAgICAgIHN1Y2ggYXMgaW4gYSB0d28tcGFydHkgY2FsbCBvciBpbiBhIGNvbmZlcmVuY2UgbGVn LgorCiAgICBUaGUgbWVkaWEgdHlwZSBhdWRpby9FVlJDTlcgbWFwcyB0byB0aGUgaW50ZXJsZWF2 ZWQvYnVuZGxlZCBwYWNrZXQKICAgIGZvcm1hdCwgYXVkaW8vRVZSQ05XMCBtYXBzIHRvIHRoZSBo ZWFkZXItZnJlZSBwYWNrZXQgZm9ybWF0IGFuZAogICAgYXVkaW8vRVZSQ05XMSBtYXBzIHRvIHRo ZSBjb21wYWN0IGJ1bmRsZWQgcGFja2V0IGZvcm1hdC4KIAogNy4gIENvbmdlc3Rpb24gQ29udHJv bCBDb25zaWRlcmF0aW9ucwogCiAgICBDb25nZXN0aW9uIGNvbnRyb2wgZm9yIFJUUCBTSEFMTCBi ZSB1c2VkIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzU1MAogICAgWzVdLCBhbmQgd2l0aCBhbnkg YXBwbGljYWJsZSBSVFAgcHJvZmlsZTsgZS5nLiwgUkZDIDM1NTEgWzZdLgogCiAgICBEdWUgdG8g dGhlIGhlYWRlciBvdmVyaGVhZCwgdGhlIG51bWJlciBvZiBmcmFtZXMgZW5jYXBzdWxhdGVkIGlu IGVhY2gKQEAgLTE1MCwyNCArMTU4LDIyIEBACiAKICAgIFRoZXNlIHBhcmFtZXRlcnMgYXBwbHkg dG8gUlRQIHRyYW5zZmVyIG9ubHkuCiAKICAgIG1vZGUtc2V0LXJlY3Y6IEEgc3Vic2V0IG9mIEVW UkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgIGNvbW1hIHNlcGFyYXRlZCBs aXN0IG9mIG1vZGVzIGZyb20gdGhlIHNldCB7MCwxLDIsMyw0LDUsNiw3fSAoc2VlCiAgICBUYWJs ZSAyLjYuMS4yLTQgaW4gM0dQUDIgQy5TMDAxNC1EKS4gIEEgZGVjb2RlciBjYW4gdXNlIHRoaXMK ICAgIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4gZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5jZSB0byBv cGVyYXRlIGluIGEKICAgIHNwZWNpZmllZCBzdWJzZXQgb2YgbW9kZXMuICBBYnNlbmNlIG9mIHRo aXMgcGFyYW1ldGVyIHNpZ25hbHMgdGhlCiAgICBtb2RlIHNldCB7MSwyLDMsNCw1LDYsN30uCiAK LSAgIHNlbmRtb2RlOiBBIG1vZGUgb2YgdGhlIEVWUkMtTlcgY29kZWMuICBBbiBlbmNvZGVyIGNh biB1c2UgdGhpcyB0bwotICAgc2lnbmFsIGl0cyBjdXJyZW50IG1vZGUgb2Ygb3BlcmF0aW9uLiAg UG9zc2libGUgdmFsdWVzIGFyZQotICAgMCwxLDIsMyw0LDUsNiw3IChzZWUgVGFibGUgMi42LjEu Mi00IGluIDNHUFAyIEMuUzAwMTQtRCkuICBBYnNlbmNlIG9mCi0gICB0aGlzIHBhcmFtZXRlciBz aWduYWxzIG1vZGUgNC4KKyAgIHNlbmRtb2RlOiBUaGUgInNlbmRtb2RlIiBwYXJhbWV0ZXIgaXMg ZGVwcmVjYXRlZCBmb3IgRVZSQ05XLiAgQW4KKyAgIEVWUkNOVyByZWNlaXZlciBNVVNUIGlnbm9y ZSB0aGlzIHBhcmFtZXRlciBpZiBwcmVzZW50LgogCiAgICBwdGltZTogc2VlIFJGQyA0NTY2IFs5 XS4KIAogICAgbWF4cHRpbWU6IHNlZSBSRkMgNDU2Ni4KIAogICAgbWF4aW50ZXJsZWF2ZTogTWF4 aW11bSBudW1iZXIgZm9yIGludGVybGVhdmluZyBsZW5ndGggKGZpZWxkIExMTCBpbgogICAgdGhl IEludGVybGVhdmluZyBPY3RldClbMC4uN10uICBUaGUgaW50ZXJsZWF2aW5nIGxlbmd0aHMgdXNl ZCBpbiB0aGUKICAgIGVudGlyZSBzZXNzaW9uIE1VU1QgTk9UIGV4Y2VlZCB0aGlzIG1heGltdW0g dmFsdWUuICBJZiBub3Qgc2lnbmFsZWQsCiAgICB0aGUgbWF4aW50ZXJsZWF2ZSBsZW5ndGggTVVT VCBiZSA1LgogCkBAIC0yNDksMjQgKzI1NSwyMiBAQAogCiAgICBUaGVzZSBwYXJhbWV0ZXJzIGFw cGx5IHRvIFJUUCB0cmFuc2ZlciBvbmx5LgogCiAgICBtb2RlLXNldC1yZWN2OiBBIHN1YnNldCBv ZiBFVlJDLU5XIG1vZGVzLiAgUG9zc2libGUgdmFsdWVzIGFyZSBhCiAgICBjb21tYSBzZXBhcmF0 ZWQgbGlzdCBvZiBtb2RlcyBmcm9tIHRoZSBzZXQgezAsMSwyLDMsNCw1LDYsN30gKHNlZQogICAg VGFibGUgMi42LjEuMi00IGluIDNHUFAyIEMuUzAwMTQtRCkuICBBIGRlY29kZXIgY2FuIHVzZSB0 aGlzCiAgICBhdHRyaWJ1dGUgdG8gaW5mb3JtIGFuIGVuY29kZXIgb2YgaXRzIHByZWZlcmVuY2Ug dG8gb3BlcmF0ZSBpbiBhCiAgICBzcGVjaWZpZWQgc3Vic2V0IG9mIG1vZGVzLiAgQWJzZW5jZSBv ZiB0aGlzIHBhcmFtZXRlciBzaWduYWxzIHRoZQogICAgbW9kZSBzZXQgezEsMiwzLDQsNSw2LDd9 LgogCi0gICBzZW5kbW9kZTogQSBtb2RlIG9mIHRoZSBFVlJDLU5XIGNvZGVjLiAgQW4gZW5jb2Rl ciBjYW4gdXNlIHRoaXMgdG8KLSAgIHNpZ25hbCBpdHMgY3VycmVudCBtb2RlIG9mIG9wZXJhdGlv bi4gIFBvc3NpYmxlIHZhbHVlcyBhcmUKLSAgIDAsMSwyLDMsNCw1LDYsNyAoc2VlIFRhYmxlIDIu Ni4xLjItNCBpbiAzR1BQMiBDLlMwMDE0LUQpLiAgQWJzZW5jZSBvZgotICAgdGhpcyBwYXJhbWV0 ZXIgc2lnbmFscyBtb2RlIDQuCisgICBzZW5kbW9kZTogVGhlICJzZW5kbW9kZSIgcGFyYW1ldGVy IGlzIGRlcHJlY2F0ZWQgZm9yIEVWUkNOVy4gIEFuCisgICBFVlJDTlcgcmVjZWl2ZXIgTVVTVCBp Z25vcmUgdGhpcyBwYXJhbWV0ZXIgaWYgcHJlc2VudC4KIAogICAgcHRpbWU6IHNlZSBSRkMgNDU2 Ni4KIAogICAgc2lsZW5jZXN1cHA6IHNlZSBTZWN0aW9uIDYuMSBpbiBSRkMgNDc4OC4KIAogICAg ZHR4bWF4OiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCiAKICAgIGR0eG1pbjogc2VlIFNl Y3Rpb24gNi4xIGluIFJGQyA0Nzg4LgogCiAgICBoYW5nb3Zlcjogc2VlIFNlY3Rpb24gNi4xIGlu IFJGQyA0Nzg4LgpAQCAtMzI5LDI4ICszMzQsMjIgQEAKICAgIG1vZGUtc2V0LXJlY3Y6IEEgc3Vi c2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgIGNvbW1hIHNl cGFyYXRlZCBsaXN0IG9mIG1vZGVzIGZyb20gdGhlIHNldCB7MCwxfSAoc2VlIFRhYmxlIDIuNi4x LjItNAogICAgaW4gM0dQUDIgQy5TMDAxNC1EKS4gIEEgZGVjb2RlciBjYW4gdXNlIHRoaXMgYXR0 cmlidXRlIHRvIGluZm9ybSBhbgogICAgZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5jZSB0byBvcGVy YXRlIGluIGEgc3BlY2lmaWVkIHN1YnNldCBvZiBtb2Rlcy4KICAgIEEgdmFsdWUgb2YgMCBzaWdu YWxzIHRoZSBzdXBwb3J0IGZvciB3aWRlYmFuZCBmaXhlZCByYXRlIChmdWxsIG9yCiAgICBoYWxm IHJhdGUsIGRlcGVuZGluZyBvbiB0aGUgdmFsdWUgb2YgJ2ZpeGVkcmF0ZScgcGFyYW1ldGVyKS4g IEEgdmFsdWUKICAgIG9mIDEgc2lnbmFscyBuYXJyb2JhbmQgZml4ZWQgcmF0ZSAoZnVsbCBvciBo YWxmIHJhdGUsIGRlcGVuZGluZyBvbgogICAgdGhlIHZhbHVlIG9mICdmaXhlZHJhdGUnIHBhcmFt ZXRlcikuICBBYnNlbmNlIG9mIHRoaXMgcGFyYW1ldGVyCiAgICBzaWduYWxzIHRoZSBtb2RlIDEu CiAKLSAgIHNlbmRtb2RlOiBBIG1vZGUgb2YgdGhlIEVWUkMtTlcgY29kZWMuICBBbiBlbmNvZGVy IGNhbiB1c2UgdGhpcyB0bwotICAgc2lnbmFsIGl0cyBjdXJyZW50IG1vZGUgb2Ygb3BlcmF0aW9u LiAgUG9zc2libGUgdmFsdWVzIGFyZSAwLDEgKHNlZQotICAgVGFibGUgMi42LjEuMi00IGluIDNH UFAyIEMuUzAwMTQtRCkuICdzZW5kbW9kZScgd2l0aCB2YWx1ZSAwIHNpZ25hbHMKLSAgIHdpZGVi YW5kIGZpeGVkIHJhdGUgb3BlcmF0aW9uIChmdWxsIG9yIGhhbGYgcmF0ZSwgZGVwZW5kaW5nIG9u IHRoZQotICAgdmFsdWUgb2YgdGhlICdmaXhlZHJhdGUnIHBhcmFtZXRlcikuICdzZW5kbW9kZScg d2l0aCB2YWx1ZSAxIHNpZ25hbHMKLSAgIG5hcnJvd2JhbmQgZml4ZWQgcmF0ZSBvcGVyYXRpb24g KGZ1bGwgb3IgaGFsZiByYXRlLCBkZXBlbmRpbmcgb24gdGhlCi0gICB2YWx1ZSBvZiB0aGUgJ2Zp eGVkcmF0ZScgcGFyYW1ldGVyKS4gIEFic2VuY2Ugb2YgdGhpcyBwYXJhbWV0ZXIKLSAgIHNpZ25h bHMgbW9kZSAxLgorICAgc2VuZG1vZGU6IFRoZSAic2VuZG1vZGUiIHBhcmFtZXRlciBpcyBkZXBy ZWNhdGVkIGZvciBFVlJDTlcuICBBbgorICAgRVZSQ05XIHJlY2VpdmVyIE1VU1QgaWdub3JlIHRo aXMgcGFyYW1ldGVyIGlmIHByZXNlbnQuCiAKICAgIHB0aW1lOiBzZWUgUkZDIDQ1NjYuCiAKICAg IG1heHB0aW1lOiBzZWUgUkZDIDQ1NjYuCiAKICAgIGZpeGVkcmF0ZTogSW5kaWNhdGVzIHRoZSBF VlJDLU5XIHJhdGUgb2YgdGhlIHNlc3Npb24gd2hpbGUgaW4gc2luZ2xlCiAgICByYXRlIG9wZXJh dGlvbi4gIFZhbGlkIHZhbHVlcyBpbmNsdWRlOiAwLjUgYW5kIDEsIHdoZXJlIGEgdmFsdWUgb2YK ICAgIDAuNSBpbmRpY2F0ZXMgdGhlIDEvMiByYXRlIHdoaWxlIGEgdmFsdWUgb2YgMSBpbmRpY2F0 ZXMgdGhlIGZ1bGwKICAgIHJhdGUuICBJZiB0aGlzIHBhcmFtZXRlciBpcyBub3QgcHJlc2VudCwg MS8yIHJhdGUgaXMgYXNzdW1lZC4KIApAQCAtNDEwLDM0ICs0MDksNDEgQEAKIAogICAgJ21vZGUt c2V0LXJlY3YnIGNhbiBiZSB1c2VkIGJ5IGEgZGVjb2RlciB0byBpbmZvcm0gYW4gZW5jb2RlciBv ZiBpdHMKICAgIHByZWZlcmVuY2UgdG8gb3BlcmF0ZSBpbiBhIHNwZWNpZmllZCBzdWJzZXQgb2Yg bW9kZXMuICBOb3RlIHRoYXQKICAgIGluZGljYXRpbmcgYSBwcmVmZXJlbmNlLCBpbXBsaWNpdGx5 IGluZGljYXRlcyBzdXBwb3J0IGZvciB0aGF0CiAgICBjYXBhYmlsaXR5LiAgQ29udmVyc2VseSwg aWYgbW9kZSAwIGlzIG5vdCBwcmVmZXJyZWQsIHRoZW4gdGhlcmUgaXMgbm8KICAgIGluZGljYXRp b24gdGhhdCBtb2RlIDAgaXMgc3VwcG9ydGVkLgogCiAgICAxLiAgVG8gaW5mb3JtIHRoZSBjYXBh YmlsaXR5IG9mIHdpZGViYW5kIG1vZGUgc3VwcG9ydDogQSBkZWNvZGVyIGNhbgogICAgICAgIGFs d2F5cyBkZWNvZGUgYWxsIHRoZSBuYXJyb3diYW5kIG1vZGVzIChtb2RlcyAxIHRvIDcpLiAgVW5s ZXNzCiAgICAgICAgdGhlIGRlY29kZXIgaW5kaWNhdGVzIHRoZSBzdXBwb3J0IG9mIG1vZGUgMCAo aS5lLiwgcHJlZmVyZW5jZSkgaW4KLSAgICAgICB0aGlzIHBhcmFtZXRlciwgYW4gZW5jb2RlciBh dCB0aGUgb3RoZXIgc2lkZSBzaGFsbCBub3Qgb3BlcmF0ZSBpbgotICAgICAgIG1vZGUgMC4KKyAg ICAgICB0aGlzIHBhcmFtZXRlciBvciBpbiB0aGUgTU1NIG1vZGUgcmVxdWVzdCBmaWVsZCBpbiBp bnRlcmxlYXZlZC8KKyAgICAgICBidW5kbGVkIHBheWxvYWQgZm9ybWF0LCBhbiBlbmNvZGVyIGF0 IHRoZSBvdGhlciBzaWRlIHNoYWxsIG5vdAorICAgICAgIG9wZXJhdGUgaW4gbW9kZSAwLgogCiAg ICAyLiAgVG8gaW5mb3JtIHRoZSBwcmVmZXJlbmNlIHRvIG9wZXJhdGUgaW4gYSBzdWJzZXQgb2Yg bW9kZXM6IEEgc2V0CiAgICAgICAgaGFzIGJlZW4gZGVmaW5lZCBzbyB0aGF0IHNldmVyYWwgbW9k ZXMgY2FuIGJlIGV4cHJlc3NlZCBhcyBhCiAgICAgICAgcHJlZmVyZW5jZSBpbiBvbmUgYXR0ZW1w dC4gIEZvciBpbnN0YW5jZSwgdGhlIHNldCB7NCw1LDYsN30KICAgICAgICBzaWduYWxzIHRoYXQg dGhlIHJlY2VpdmVyIHBlcmZlcnMgdGhlIHNlbmRlciB0byBvcGVyYXRlIGluCiAgICAgICAgYmFu ZHdpZHRoLWVmZmljaWVudCBuYXJyb3diYW5kIG1vZGVzIG9mIEVWUkMtTlcuCiAKLSAgICdzZW5k bW9kZScgY2FuIGJlIHVzZWQgYnkgYSBzZW5kZXIgdG8gYW5ub3VuY2UgaXRzIGVuY29kZXIncyBj dXJyZW50Ci0gICBtb2RlIG9mIG9wZXJhdGlvbi4gIEEgc2VuZGVyIGNhbiBjaGFuZ2UgaXRzIG1v ZGUgYW1vbmcgbW9kZXMgMSB0byA3Ci0gICAob3IgYW1vbmcgbW9kZXMgMCB0byA3IGlmIHRoZSBy ZWNlaXZlciBzdXBwb3J0cyB3aWRlYmFuZCBtb2RlKQotICAgYW55dGltZSBhbmQgdGhpcyBkb2Vz IG5vdCBjYXVzZSBhbnkgZGVjb2RpbmcgcHJvYmxlbXMgYXQgdGhlCi0gICByZWNlaXZlci4KKyAg IE5vdGUsIGR1cmluZyBhbiBhY3RpdmUgY2FsbCBzZXNzaW9uIHVzaW5nIHRoZSBpbnRlcmxlYXZl ZC9idW5kbGVkCisgICBwYWNrZXQgZm9ybWF0LCB0aGUgTU1NIG1vZGUgcmVxdWVzdCByZWNlaXZl ZCBmcm9tIGEgY29tbXVuaWNhdGlvbgorICAgcGFydG5lciBjb21wbGVtZW50cyB0aGUgbW9kZSBz ZXQgaW5mb3JtYXRpb24gaW4gbW9kZS1zZXQtcmVjdi4gIEEKKyAgIG1vZGUgcmVxdWVzdCB3aXRo IE1NTT0wIGZyb20gYSBjb21tdW5pY2F0aW9uIHBhcnRuZXIgaXMgYW4gaW1wbGljaXQKKyAgIGlu ZGljYXRpb24gb2YgdGhlIHBhcnRuZXIncyBFVlJDTlcgd2lkZWJhbmQgZGVjb2RpbmcgY2FwYWJp bGl0eSBhbmQKKyAgIHByZWZlcmVuY2UuICBBbiBFVlJDTlcgd2lkZWJhbmQgY2FwYWJsZSBub2Rl IHJlY2VpdmluZyB0aGUgcmVxdWVzdAorICAgY2FuIG9wZXJhdGUgaW4gd2lkZWJhbmQgbW9kZS4g IEEgbW9kZSByZXF1ZXN0IHdpdGggTU1NPTEsIDIsIC4uLiwgb3IKKyAgIDcgZnJvbSBhIGNvbW11 bmljYXRpb24gcGFydG5lciBpcyBhbiBpbXBsaWNpdCBpbmRpY2F0aW9uIG9mIHRoZQorICAgcGFy dG5lcidzIEVWUkNOVyBuYXJyb3diYW5kIGRlY29kaW5nIHByZWZlcmVuY2UuICBUaGUgZW5jb2Rl ciBvZiBhbgorICAgRVZSQ05XIG5vZGUgcmVjZWl2aW5nIHRoZSByZXF1ZXN0IHNob3VsZCBob25v ciB0aGUgcmVxdWVzdCBhbmQKKyAgIG9wZXJhdGUgaW4gbmFycm93YmFuZCBtb2RlLgogCiAxMS4g IE1hcHBpbmcgRVZSQy1OVyBtZWRpYSB0eXBlIHBhcmFtZXRlcnMgaW50byBTRFAKIAogICAgSW5m b3JtYXRpb24gY2FycmllZCBpbiB0aGUgbWVkaWEgdHlwZSBzcGVjaWZpY2F0aW9uIGhhcyBhIHNw ZWNpZmljCiAgICBtYXBwaW5nIHRvIGZpZWxkcyBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQ cm90b2NvbCAoU0RQKSBbOV0sCiAgICB3aGljaCBpcyBjb21tb25seSB1c2VkIHRvIGRlc2NyaWJl IFJUUCBzZXNzaW9ucy4gIFdoZW4gU0RQIGlzIHVzZWQgdG8KICAgIHNwZWNpZnkgc2Vzc2lvbnMg ZW1wbG95aW5nIEVWUkMtTlcgZW5jb2RlZCBzcGVlY2gsIHRoZSBtYXBwaW5nIGlzIGFzCiAgICBm b2xsb3dzLgogCiAgICBvICBUaGUgbWVkaWEgdHlwZSAoImF1ZGlvIikgZ29lcyBpbiBTRFAgIm09 IiBhcyB0aGUgbWVkaWEgbmFtZS4KQEAgLTQ2NSw2NSArNDcxLDU1IEBACiAgICAgICAibT1hdWRp byIgbGluZXMsIHdpdGggRVZSQy1OVyBhcyB0aGUgcHJlZmVycmVkIGNvZGVjLiAgVGhpcyB3aWxs CiAgICAgICBhbGxvdyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggYW4gYW5zd2VyZXIgd2hpY2ggc3Vw cG9ydHMgb25seSBFVlJDLUIKICAgICAgIGFuZC9vciBFVlJDLVdCLgogCiAgICBCZWxvdyBpcyBh biBleGFtcGxlIG9mIHN1Y2ggYW4gb2ZmZXI6CiAKICAgICAgICAgICBtPWF1ZGlvIDU1OTU0IFJU UC9BVlAgOTggOTkgMTAwCiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ05XMC8xNjAwMAogICAg ICAgICAgIGE9cnRwbWFwOjk5IEVWUkNXQjAvMTYwMDAKICAgICAgICAgICBhPXJ0cG1hcDoxMDAg RVZSQ0IwLzgwMDAKLSAgICAgICAgICBhPWZtdHA6OTggbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQs NSw2O3NlbmRtb2RlPTAKLSAgICAgICAgICBhPWZtdHA6OTkgbW9kZS1zZXQtcmVjdj0wLDQ7c2Vu ZG1vZGU9MAotICAgICAgICAgIGE9Zm10cDoxMDAgcmVjdm1vZGU9MDtzZW5kbW9kZT00CisgICAg ICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0LDUsNgorICAgICAgICAgIGE9 Zm10cDo5OSBtb2RlLXNldC1yZWN2PTAsNAorICAgICAgICAgIGE9Zm10cDoxMDAgcmVjdm1vZGU9 MAogCiAgICBJZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgRVZSQy1OVyB0aGVuIHRoZSBhbnN3ZXJl ciBjYW4ga2VlcCB0aGUKICAgIHBheWxvYWQgdHlwZSA5OCBpbiBpdHMgYW5zd2VyIGFuZCB0aGUg Y29udmVyc2F0aW9uIGNhbiBiZSBkb25lIHVzaW5nCiAgICBFVlJDLU5XLiAgRWxzZSwgaWYgdGhl IGFuc3dlcmVyIHN1cHBvcnRzIG9ubHkgRVZSQy1XQiBhbmQvb3IgRVZSQy1CCiAgICB0aGVuIHRo ZSBhbnN3ZXJlciB3aWxsIGxlYXZlIG9ubHkgdGhlIHBheWxvYWQgdHlwZSA5OSBhbmQvb3IgMTAw CiAgICByZXNwZWN0aXZlbHkgaW4gaXRzIGFuc3dlciBhbmQgdGhlIGNvbnZlcnNhdGlvbiB3aWxs IGJlIGRvbmUgdXNpbmcKICAgIEVWUkMtV0IgYW5kL29yIEVWUkMtQiByZXNwZWN0aXZlbHkuCiAK ICAgIEFuIGV4YW1wbGUgYW5zd2VyIGZvciB0aGUgYWJvdmUgb2ZmZXI6CiAKICAgICAgICAgICBt PWF1ZGlvIDU1OTU0IFJUUC9BVlAgOTgKICAgICAgICAgICBhPXJ0cG1hcDo5OCBFVlJDTlcwLzE2 MDAwCi0gICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9NDtzZW5kbW9kZT00CisgICAg ICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9NAogCiAgICBvICAnbW9kZS1zZXQtcmVjdicg aXMgYSB1bmktZGlyZWN0aW9uYWwgcmVjZWl2ZSBvbmx5IHBhcmFtZXRlci4KIAotICAgbyAgJ3Nl bmRtb2RlJyBpcyBhIHVuaS1kaXJlY3Rpb25hbCBzZW5kIG9ubHkgcGFyYW1ldGVyLgotCi0gICBv ICBVc2luZyAnc2VuZG1vZGUnLCBhIHNlbmRlciBjYW4gc2lnbmFsIGl0cyBjdXJyZW50IG1vZGUg b2YKLSAgICAgIG9wZXJhdGlvbi4gIE5vdGUgdGhhdCBhIHJlY2VpdmVyIG1heSByZWNlaXZlIFJU UCBtZWRpYSB3ZWxsIGJlZm9yZQotICAgICAgdGhlIGFycml2YWwgb2YgU0RQIHdpdGggYSAoZmly c3QgdGltZSwgb3IgdXBkYXRlZCkgJ3NlbmRtb2RlJwotICAgICAgcGFyYW1ldGVyLgotCiAgICBv ICBBbiBvZmZlcmVyIGNhbiB1c2UgJ21vZGUtc2V0LXJlY3YnIHRvIHJlcXVlc3QgdGhhdCB0aGUg cmVtb3RlCiAgICAgICBzZW5kZXIncyBlbmNvZGVyIGJlIGxpbWl0ZWQgdG8gdGhlIGxpc3Qgb2Yg bW9kZXMgc2lnbmFsZWQgaW4KICAgICAgICdtb2RlLXNldC1yZWN2Jy4gIEEgcmVtb3RlIHNlbmRl ciBNQVkgaWdub3JlICdtb2RlLXNldC1yZWN2JwogICAgICAgcmVxdWVzdHMuICBIb3dldmVyLCBh IHJlbW90ZSBzZW5kZXIgc2hhbGwgbm90IGFzc3VtZSB0aGUgb3RoZXIKICAgICAgIHNpZGUgY2Fu IHN1cHBvcnQgbW9kZSAwLCB1bmxlc3MgdGhlIG9mZmVyIGluY2x1ZGVzIG1vZGUgMAogICAgICAg ZXhwbGljaXRseSBpbiAnbW9kZS1zZXQtcmVjdicuCiAKICAgIG8gIFRoZSBwYXJhbWV0ZXJzICdt YXhwdGltZScgYW5kICdwdGltZScgd2lsbCBpbiBtb3N0IGNhc2VzIG5vdAogICAgICAgYWZmZWN0 IGludGVyb3BlcmFiaWxpdHksIGhvd2V2ZXIgdGhlIHNldHRpbmcgb2YgdGhlIHBhcmFtZXRlcnMg Y2FuCiAgICAgICBhZmZlY3QgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBhcHBsaWNhdGlvbi4gIFRo ZSBTRFAgb2ZmZXItYW5zd2VyCiAgICAgICBoYW5kbGluZyBvZiB0aGUgJ3B0aW1lJyBwYXJhbWV0 ZXIgaXMgZGVzY3JpYmVkIGluIFJGQyAzMjY0IFsxMV0uCiAgICAgICBUaGUgJ21heHB0aW1lJyBw YXJhbWV0ZXIgTVVTVCBiZSBoYW5kbGVkIGluIHRoZSBzYW1lIHdheS4KIAogICAgbyAgRm9yIGEg c2VuZG9ubHkgc3RyZWFtLCB0aGUgJ21vZGUtc2V0LXJlY3YnIHBhcmFtZXRlciBpcyBub3QgdXNl ZnVsCiAgICAgICBhbmQgU0hPVUxEIE5PVCBiZSB1c2VkLgogCi0gICBvICBGb3IgYSByZWN2b25s eSBzdHJlYW0sIHRoZSAnc2VuZG1vZGUnIHBhcmFtZXRlciBpcyBub3QgdXNlZnVsIGFuZAotICAg ICAgU0hPVUxEIE5PVCBiZSB1c2VkLgotCiAgICBvICBXaGVuIHVzaW5nIEVWUkNOVzEsIHRoZSBl bnRpcmUgc2Vzc2lvbiBNVVNUIHVzZSB0aGUgc2FtZSBmaXhlZAogICAgICAgcmF0ZSBhbmQgbW9k ZSAoMC1XaWRlYmFuZCBvciAxLU5hcnJvd2JhbmQpLgogCiAgICBvICBGb3IgYWRkaXRpb25hbCBy dWxlcyB3aGljaCBNVVNUIGJlIGZvbGxvd2VkIHdoaWxlIG5lZ290aWF0aW5nIERUWAogICAgICAg cGFyYW1ldGVycywgc2VlIFNlY3Rpb24gNi44IGluIFJGQyA0Nzg4IFsyXS4KIAogICAgbyAgQW55 IHVua25vd24gcGFyYW1ldGVyIGluIGFuIFNEUCBvZmZlciBNVVNUIGJlIGlnbm9yZWQgYnkgdGhl CiAgICAgICByZWNlaXZlciBhbmQgTVVTVCBOT1QgYmUgaW5jbHVkZWQgaW4gdGhlIFNEUCBhbnN3 ZXIuCiAKIDEzLiAgRGVjbGFyYXRpdmUgU0RQIENvbnNpZGVyYXRpb25zCkBAIC01NTEsMTE5ICs1 NDcsMTE5IEBACiAgICBpZ25vcmVkLiAgTm90ZSB0aGF0IG1lZGlhIHN1YnR5cGUgbmFtZXMgYXJl IGNhc2UtaW5zZW5zaXRpdmUuCiAgICBQYXJhbWV0ZXIgbmFtZXMgYXJlIGNhc2UtaW5zZW5zaXRp dmUgYm90aCBpbiBtZWRpYSB0eXBlcyBhbmQgaW4gdGhlCiAgICBtYXBwaW5nIHRvIHRoZSBTRFAg YT1mbXRwIGF0dHJpYnV0ZS4KIAogICAgRXhhbXBsZSB1c2FnZSBvZiBFVlJDTlcgaWYgd2lkZWJh bmQgbW9kZSBpcyBzdXBwb3J0ZWQ6CiAKICAgICAgICAgICBtPWF1ZGlvIDQ5MTIwIFJUUC9BVlAg OTcgOTggOTkKICAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcvMTYwMDAKICAgICAgICAgICBh PXJ0cG1hcDo5OCBFVlJDV0IvMTYwMDAKICAgICAgICAgICBhPXJ0cG1hcDo5OSBFVlJDQi84MDAw Ci0gICAgICAgICAgYT1mbXRwOjk3IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0LDUsNjtzZW5kbW9k ZT0wCi0gICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCw0O3NlbmRtb2RlPTAKLSAg ICAgICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MDtzZW5kbW9kZT0wCisgICAgICAgICAgYT1mbXRw Ojk3IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0LDUsNgorICAgICAgICAgIGE9Zm10cDo5OCBtb2Rl LXNldC1yZWN2PTAsNAorICAgICAgICAgIGE9Zm10cDo5OSByZWN2bW9kZT0wCiAgICAgICAgICAg YT1tYXhwdGltZToxMjAKIAogICAgRXhhbXBsZSB1c2FnZSBvZiBFVlJDTlcgaWYgd2lkZWJhbmQg bW9kZSBpcyBub3Qgc3VwcG9ydGVkOgogCiAgICAgICAgICAgbT1hdWRpbyA0OTEyMCBSVFAvQVZQ IDk3IDk4IDk5CiAgICAgICAgICAgYT1ydHBtYXA6OTcgRVZSQ05XLzE2MDAwCiAgICAgICAgICAg YT1ydHBtYXA6OTggRVZSQ1dCLzE2MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTkgRVZSQ0IvODAw MAotICAgICAgICAgIGE9Zm10cDo5NyBtb2RlLXNldC1yZWN2PTEsMiwzLDQsNSw2O3NlbmRtb2Rl PTQKLSAgICAgICAgICBhPWZtdHA6OTggbW9kZS1zZXQtcmVjdj00O3NlbmRtb2RlPTQKLSAgICAg ICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MDtzZW5kbW9kZT0wCisgICAgICAgICAgYT1mbXRwOjk3 IG1vZGUtc2V0LXJlY3Y9MSwyLDMsNCw1LDYKKyAgICAgICAgICBhPWZtdHA6OTggbW9kZS1zZXQt cmVjdj00CisgICAgICAgICAgYT1mbXRwOjk5IHJlY3Ztb2RlPTAKICAgICAgICAgICBhPW1heHB0 aW1lOjEyMAogCiAgICBFeGFtcGxlIHVzYWdlIG9mIEVWUkNOVzA6CiAKICAgICAgICAgICBtPWF1 ZGlvIDQ5MTIwIFJUUC9BVlAgOTcgOTggOTkKICAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcw LzE2MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dCMC8xNjAwMAogICAgICAgICAgIGE9 cnRwbWFwOjk5IEVWUkNCMC84MDAwCi0gICAgICAgICAgYT1mbXRwOjk3IG1vZGUtc2V0LXJlY3Y9 MCwxLDIsMyw0LDUsNjtzZW5kbW9kZT0wCi0gICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJl Y3Y9MCw0O3NlbmRtb2RlPTAKLSAgICAgICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MDtzZW5kbW9k ZT0wCisgICAgICAgICAgYT1mbXRwOjk3IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0LDUsNgorICAg ICAgICAgIGE9Zm10cDo5OCBtb2RlLXNldC1yZWN2PTAsNAorICAgICAgICAgIGE9Zm10cDo5OSBy ZWN2bW9kZT0wCiAKICAgIEV4YW1wbGUgU0RQIGFuc3dlciBmcm9tIGEgbWVkaWEgZ2F0ZXdheSBy ZXF1ZXN0aW5nIGEgdGVybWluYWwgdG8KICAgIGxpbWl0IGl0cyBlbmNvZGVyIG9wZXJhdGlvbiB0 byBFVlJDLU5XIG1vZGUgNC4KIAogICAgICAgICAgIG09YXVkaW8gNDkxMjAgUlRQL0FWUCA5Nwog ICAgICAgICAgIGE9cnRwbWFwOjk3IEVWUkNOVzAvMTYwMDAKLSAgICAgICAgICBhPWZtdHA6OTcg bW9kZS1zZXQtcmVjdj00O3NlbmRtb2RlPTQKKyAgICAgICAgICBhPWZtdHA6OTcgbW9kZS1zZXQt cmVjdj00CiAgICBFeGFtcGxlIHVzYWdlIG9mIEVWUkNOVzE6CiAKICAgICAgICAgICBtPWF1ZGlv IDQ5MTIwIFJUUC9BVlAgOTcgOTggOTkKICAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcxLzE2 MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dCMS8xNjAwMAogICAgICAgICAgIGE9cnRw bWFwOjk5IEVWUkNCMS84MDAwCiAgICAgICAgICAgYT1mbXRwOjk3IGZpeGVkcmF0ZT0wLjUKICAg ICAgICAgICBhPWZtdHA6OTggZml4ZWRyYXRlPTAuNQogICAgICAgICAgIGE9Zm10cDo5OSBmaXhl ZHJhdGU9MC41CiAgICAgICAgICAgYT1tYXhwdGltZToxMDAKIAogICAgRXhhbXBsZSB1c2FnZSBv ZiBFVlJDTlcgd2l0aCBEVFggd2l0aCBzaWxlbmNlc3VwcD0xOgogCiAgICAgICAgICAgbT1hdWRp byA0OTEyMCBSVFAvQVZQIDk3IDk4IDk5CiAgICAgICAgICAgYT1ydHBtYXA6OTcgRVZSQ05XLzE2 MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dCLzE2MDAwCiAgICAgICAgICAgYT1ydHBt YXA6OTkgRVZSQ0IvODAwMAotICAgICAgICAgIGE9Zm10cDo5NyBzaWxlbmNlc3VwcD0xO2R0eG1h eD0zMjtkdHhtaW49MTI7aGFuZ292ZXI9MSBcCi0gICAgICAgICAgbW9kZS1zZXQtcmVjdj0wLDEs MiwzLDQsNSw2O3NlbmRtb2RlPTAKLSAgICAgICAgICBhPWZtdHA6OTggc2lsZW5jZXN1cHA9MTtk dHhtYXg9MzI7ZHR4bWluPTEyO2hhbmdvdmVyPTEgXAotICAgICAgICAgIG1vZGUtc2V0LXJlY3Y9 MCw0O3NlbmRtb2RlPTAKLSAgICAgICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MDtzZW5kbW9kZT0w CisgICAgICAgICAgYT1mbXRwOjk3IHNpbGVuY2VzdXBwPTE7ZHR4bWF4PTMyO2R0eG1pbj0xMjto YW5nb3Zlcj0xOyBcCisgICAgICAgICAgbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2CisgICAg ICAgICAgYT1mbXRwOjk4IHNpbGVuY2VzdXBwPTE7ZHR4bWF4PTMyO2R0eG1pbj0xMjtoYW5nb3Zl cj0xOyBcCisgICAgICAgICAgbW9kZS1zZXQtcmVjdj0wLDQKKyAgICAgICAgICBhPWZtdHA6OTkg cmVjdm1vZGU9MAogICAgICAgICAgIGE9bWF4cHRpbWU6MTIwCiAKICAgIEV4YW1wbGVzIHVzYWdl IG9mIEVWUkNOVyB3aXRoIERUWCB3aXRoIHNpbGVuY2VzdXBwPTA6CiAKICAgICAgICAgICBtPWF1 ZGlvIDQ5MTIwIFJUUC9BVlAgOTcgOTggOTkKICAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcv MTYwMDAKICAgICAgICAgICBhPXJ0cG1hcDo5OCBFVlJDV0IvMTYwMDAKICAgICAgICAgICBhPXJ0 cG1hcDo5OSBFVlJDQi84MDAwCi0gICAgICAgICAgYT1mbXRwOjk3IHNpbGVuY2VzdXBwPTA7ZHR4 bWF4PTMyO2R0eG1pbj0xMjtoYW5nb3Zlcj0xIFwKLSAgICAgICAgICBtb2RlLXNldC1yZWN2PTAs MSwyLDMsNCw1LDY7c2VuZG1vZGU9MAotICAgICAgICAgIGE9Zm10cDo5OCBzaWxlbmNlc3VwcD0w O2R0eG1heD0zMjtkdHhtaW49MTI7aGFuZ292ZXI9MSBcCi0gICAgICAgICAgbW9kZS1zZXQtcmVj dj0wLDQ7c2VuZG1vZGU9MAotICAgICAgICAgIGE9Zm10cDo5OSByZWN2bW9kZT0wO3NlbmRtb2Rl PTAKKyAgICAgICAgICBhPWZtdHA6OTcgc2lsZW5jZXN1cHA9MDtkdHhtYXg9MzI7ZHR4bWluPTEy O2hhbmdvdmVyPTE7IFwKKyAgICAgICAgICBtb2RlLXNldC1yZWN2PTAsMSwyLDMsNCw1LDYKKyAg ICAgICAgICBhPWZtdHA6OTggc2lsZW5jZXN1cHA9MDtkdHhtYXg9MzI7ZHR4bWluPTEyO2hhbmdv dmVyPTE7IFwKKyAgICAgICAgICBtb2RlLXNldC1yZWN2PTAsNAorICAgICAgICAgIGE9Zm10cDo5 OSByZWN2bW9kZT0wCiAgICAgICAgICAgYT1tYXhwdGltZToxMjAKIAogICAgRXhhbXBsZSBvZmZl ciBhbnN3ZXIgZXhjaGFuZ2UgYmV0d2VlbiBFVlJDLU5XIGFuZCBsZWdhY3kgRVZSQy1CIChSRkMK ICAgIDQ3ODgpOgogCiAgICAgICAgICBPZmZlcjoKIAogICAgICAgICAgICBtPWF1ZGlvIDU1OTU0 IFJUUC9BVlAgOTcgOTggOTkKICAgICAgICAgICAgYT1ydHBtYXA6OTcgRVZSQ05XMC8xNjAwMAog ICAgICAgICAgICBhPXJ0cG1hcDo5OCBFVlJDV0IwLzE2MDAwCiAgICAgICAgICAgIGE9cnRwbWFw Ojk5IEVWUkNCMC84MDAwCi0gICAgICAgICAgIGE9cnRwbWFwOjk3IG1vZGUtc2V0LXJlY3Y9MCwx LDIsMyw0LDUsNjtzZW5kbW9kZT0wCi0gICAgICAgICAgIGE9Zm10cDo5OCBtb2RlLXNldC1yZWN2 PTAsNDtzZW5kbW9kZT0wCi0gICAgICAgICAgIGE9Zm10cDo5OSByZWN2bW9kZT0wO3NlbmRtb2Rl PTAKKyAgICAgICAgICAgYT1ydHBtYXA6OTcgbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2Cisg ICAgICAgICAgIGE9Zm10cDo5OCBtb2RlLXNldC1yZWN2PTAsNAorICAgICAgICAgICBhPWZtdHA6 OTkgcmVjdm1vZGU9MAogCiAgICAgICAgICBBbnN3ZXI6CiAKICAgICAgICAgICAgbT1hdWRpbyA1 NTk1NCBSVFAvQVZQIDk5CiAgICAgICAgICAgIGE9cnRwbWFwOjk5IEVWUkNCMC84MDAwCiAKICAg IEV4YW1wbGUgb2ZmZXIgYW5zd2VyIGV4Y2hhbmdlIGJldHdlZW4gRVZSQy1OVyBhbmQgbGVnYWN5 IEVWUkMtV0IgKFJGQwogICAgNTE4OCk6CiAKICAgICAgICAgIE9mZmVyOgogCiAgICAgICAgICAg IG09YXVkaW8gNTU5NTQgUlRQL0FWUCA5NyA5OCA5OQogICAgICAgICAgICBhPXJ0cG1hcDo5NyBF VlJDTlcwLzE2MDAwCiAgICAgICAgICAgIGE9cnRwbWFwOjk4IEVWUkNXQjAvMTYwMDAKICAgICAg ICAgICAgYT1ydHBtYXA6OTkgRVZSQ0IwLzgwMDAKLSAgICAgICAgICAgYT1ydHBtYXA6OTcgbW9k ZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2O3NlbmRtb2RlPTAKLSAgICAgICAgICAgYT1mbXRwOjk4 IG1vZGUtc2V0LXJlY3Y9MCw0O3NlbmRtb2RlPTAKLSAgICAgICAgICAgYT1mbXRwOjk5IHJlY3Zt b2RlPTA7c2VuZG1vZGU9MAorICAgICAgICAgICBhPXJ0cG1hcDo5NyBtb2RlLXNldC1yZWN2PTAs MSwyLDMsNCw1LDYKKyAgICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCw0CisgICAg ICAgICAgIGE9Zm10cDo5OSByZWN2bW9kZT0wCiAKICAgICAgICAgIEFuc3dlcjoKIAogICAgICAg ICAgICBtPWF1ZGlvIDU1OTU0IFJUUC9BVlAgOTggOTkKICAgICAgICAgICAgYT1ydHBtYXA6OTgg RVZSQ1dCMC8xNjAwMAogCiAxNS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCiAKICAgIFNpbmNl IGNvbXByZXNzaW9uIGlzIGFwcGxpZWQgdG8gdGhlIHBheWxvYWQgZm9ybWF0cyBlbmQtdG8tZW5k LCBhbmQKICAgIHRoZSBlbmNvZGluZ3MgZG8gbm90IGV4aGliaXQgc2lnbmlmaWNhbnQgbm9uLXVu aWZvcm1pdHksCg== --_004_909F74681826104B8F3162A1A782323B5114E8AA86NALASEXMB13na_-- From chung.cheung.chu@ericsson.com Thu Apr 21 06:29:53 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8CC3BE0689 for ; Thu, 21 Apr 2011 06:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 oX8-HAeWNhfv for ; Thu, 21 Apr 2011 06:29:44 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfc.amsl.com (Postfix) with ESMTP id 33D6DE0655 for ; Thu, 21 Apr 2011 06:29:44 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3LDTgU3023696; Thu, 21 Apr 2011 08:29:43 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.2.195]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 21 Apr 2011 09:29:36 -0400 From: Chung Cheung Chu To: "Fang, Zheng" , "payload@ietf.org" Date: Thu, 21 Apr 2011 09:29:36 -0400 Thread-Topic: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Thread-Index: Acv1Jb8riP8RBI1FS1qqLbHSHs3ktgGTpXNAARNZY2AAAMekMAAYxrEQ Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDB77879D466@EUSAACMS0702.eamcs.ericsson.se> References: <26490BBDEEACA14EA1A0070367B3ADBDB77844F033@EUSAACMS0702.eamcs.ericsson.se> <909F74681826104B8F3162A1A782323B5114E8AA86@NALASEXMB13.na.qualcomm.com> In-Reply-To: <909F74681826104B8F3162A1A782323B5114E8AA86@NALASEXMB13.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_26490BBDEEACA14EA1A0070367B3ADBDB77879D466EUSAACMS0702e_" MIME-Version: 1.0 Subject: Re: [payload] Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 13:29:53 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDB77879D466EUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Zheng, Thank you for addressing my comments. I don't have further comments. Please go ahead with your submission. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. ________________________________ From: Fang, Zheng [mailto:zfang@qualcomm.com] Sent: April-20-11 10:25 PM To: Chung Cheung Chu; payload@ietf.org Subject: RE: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Hi Chung Cheung, Thanks for your comments (in this email and the previous one "Mode request = support in draft-ietf-avt-rtp-evrc-nw-02"). I adopted the changes accordingly. The diff is attached. Basically, 1) The clarifications regarding mode request support are adopted as you sug= gested. There are some wording differences, but those are inconsequential. 2) For the changes related to "sendmode", I instead would like to propose d= eprecating this parameter in EVRC-NW. I believe, by deprecating the "sendmo= de" parameter, this not only addresses the concerns you had, but also avoid= s further confusion in other usage scenarios which were not covered in your= emails. As an result, the "sendmode" attribute is removed from all the examples= as well. Please let me know if you have any additional comments; otherwise, I will s= ubmit this new version to the I-D repository later. Thanks, Zheng From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] Sent: Friday, April 15, 2011 6:53 AM To: payload@ietf.org; Fang, Zheng Subject: Change proposal to draft "draft-ietf-avt-rtp-evrc-nw-02" Background Draft "draft-ietf-avt-rtp-evrc-nw-02" defines the RTP payload formats and c= orresponding media type registrations for CDMA codec EVRC-NW [Ref. 3GPP2 C.= S0014-D]. EVRC-NW is a multi-rate low bit rate codec adopted by 3GPP2. Th= is codec supports a total of 8 modes of operation for narrowband and wideba= nd voice band traffic compression. Mode-0 is for wideband compression. Mo= de-1 to mode-7 are for narrowband compression where mode-4 is defined as th= e default mode. The average encoding rate for narrowband operation is decr= eased with increasing operating mode from mode-1 to mode-7. Three media subtype payload formats are defined in this draft. They are EV= RCNW, EVRCNW0 and EVRCNW1. This email concerns with operations associated = with the media subtype EVRCNW payload format definition. Media subtype EVRCNW payload format is defined with a payload header which = consists of a 3-bit mode request field "MMM" and other payload related para= meters [Ref. RFC3558]. Per MMM definition by RFC3558, EVRCNW traffic recei= ver uses this field to request an EVRCNW encoding mode to be used by the EV= RCNW traffic generator for new traffic in the reverse path. Draft "draft-ietf-avt-rtp-evrc-nw-02" adopts two optional SDP attributes "m= ode-set-recv" and "sendmode" from RFC5188. Attribute "mode-set-recv" is us= ed to indicate the preferred mode of bearer traffic supported by an EVRCNW = receiver. This attribute can assume a set of values 0, 1, ..., 7 denoting = mode-0, mode-1, ..., mode-7 support, respectively. Attribute "sendmode" is= used to announce the current EVRCNW encoding mode by an EVRCNW encoder. The draft states that in absence of mode-0 specification in "mode-set-recv"= or in absence of the attribute, an EVRCNW encoder at the other side can on= ly operate in narrowband mode. In absence of attribute "sendmode", the enc= oding mode is mode-4. Proposal It is understood that an EVRCNW encoder cannot autonomously generate and se= nd EVRC-NW mode-0 (wideband) traffic to the partner in absence of the partn= er's mode-0 (wideband) decoding capability. However, a user capable of dec= oding mode-0 (wideband) traffic should be allowed to request for mode-0 (wi= deband) traffic from the partner using the MMM field in the RTP RFC header.= Such an in-band request is an implicit indication of mode-0 (wideband) de= coding capability of the originator. Upon receiving the mode-0 (wideband) = request, a mode-0 (wideband) capable partner should be allowed to generate = and send EVRC-NW wideband encoded traffic to the request originator, regard= less of the SDP attribute "mode-set-recv". A partner not capable of wideba= nd encoding can ignore the request and should use a narrowband mode. An example where the MMM mode change request field facilitates narrowband-t= o-wideband and wideband-to-narrowband operation switching is as follows: An EVRCNW transcoding free (TrFO) call is established in a session between = mobile-A in a circuit switched network and mobile-B in a 4G network via a c= ommunication node in the core network, such as a media gateway. In this e= xample, mobile-A supports EVRCNW without wideband compression capability, a= nd mobile-B supports EVRCNW with wideband compression capability. The medi= a gateway sends at call setup time SDP mode-set-recv attribute to mobile-B = specifying only narrowband mode support in light of mobile-A EVRCNW wideban= d incapability. During the call, a call transfer (or call waiting) takes p= lace replacing mobile-A with an EVRCNW wideband capable device, mobile-C. = In this example, the media gateway does not update the optional SDP mode-se= t-recv attribute on the stationary side to mobile-B. In this scenario, EVRCNW wideband operation is allowed between mobile-C and= the media gateway but not feasible between the media gateway and mobile-B = according to the mode-set-recv definition in the current draft. This could= result in end-to-end EVRCNW operation in narrowband mode only. If MMM mod= e change requests for mode-0 traffic relayed from mobile-C is allowed and s= upported by mobile-B, end-to-end EVRCNW transcoding free operation would be= re-established in wideband mode. Conversely, when the wideband support capability is terminated during an ac= tive call session, for example due to a call transfer (or call waiting) bac= k from mobile-C to mobile-A, mode change requests relayed from mobile-A for= narrowband operation should be considered as a preference indication that = narrowband traffic is desired by the originator. Mobile-B should honor the= request and return narrowband compressed traffic. This is required even i= f the mode-set-recv SDP attribute from the media gateway to mobile-B includ= es mode-0 support. It is proposed that the following texts for media subtype EVRCNW SDP attrib= utes "mode-set-recv" and "sendmode" be clarified: Original text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. Suggested text: Section 9.1.1 mode-set-recv: A subset of EVRC-NW modes. Possible values are a comma sepa= rated list of modes from the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in = 3GPP2 C.S0014-D). A decoder can use this attribute to inform an encoder of= its preference to operate in a specified subset of modes. Absence of this= parameter signals the mode set {1,2,3,4,5,6,7}. During an active call session, the MMM mode request received from a communi= cation partner complements the mode set information in mode-set-recv. A mo= de request with MMM=3D0 from a communication partner is an implicit indicat= ion of the partner's EVRCNW wideband decoding capability and preference. A= n EVRCNW wideband capable node receiving the request can operate in wideban= d mode. A mode request with MMM=3D1, 2, ..., or 7 from a communication par= tner is an implicit indication of the partner's EVRCNW narrowband decoding = capability and preference. An EVRCNW node receiving the request should hon= or the request and operate in narrowband mode. Original text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter, an encod= er at the other side shall not operate in mode 0. Suggested text: Section 10 1. To inform the capability of wideband mode support: A decoder can alw= ays decode all the narrowband modes (modes 1 to 7). Unless the decoder ind= icates the support of mode 0 (i.e., preference) in this parameter and in th= e MMM mode request field in media subtype EVRCNW payload format, an encoder= at the other side shall not operate in mode 0. Original text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. Suggested text: Section 9.1.1 sendmode: A mode of the EVRC-NW codec. An encoder can use this to signa= l its current mode of operation. Possible values are 0,1,2,3,4,5,6,7 (see = Table 2.6.1.2-4 in 3GPP2 C.S0014-D). Absence of this parameter signals mod= e 4. It is not necessary to send this optional SDP attribute when an EVRCNW e= ncoder updates its encoding mode during an active call session such as in r= esponse to requests in the MMM mode request field from the other side. Conv= ersely, absence of this SDP attribute should not be interpreted as an indic= ation the encoder operates only in default mode-4. The suggested changes are for media subtype EVRCNW payload format only. Th= ey are not applicable to media subtype EVRCNW0 and EVRCNW1 payload formats = where the MMM mode request field is not supported. Regards, CC Chung-Cheung Chu Media Gateway DSP Design BCAM - Ericsson +514 345-7900 (x46489) This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_26490BBDEEACA14EA1A0070367B3ADBDB77879D466EUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Zheng,
 
Thank you for addressing my comments.
 
I don't have further comments.  Please go ahe= ad with=20 your submission.
 
Regards,
 
CC
 

Chung-Cheung Chu=20
Media Gateway DSP=20 Design
BCA= M -=20 Ericsson
+= 514=20 345-7900 (x46489)
This Communication is Confidential. = We only=20 send and receive email on the basis of the terms set out at=20 www.ericsson.com/email_disclaimer.

 

From: Fang, Zheng [mailto:zfang@qualcom= m.com]=20
Sent: April-20-11 10:25 PM
To: Chung Cheung Chu;=20 payload@ietf.org
Subject: RE: Change proposal to draft=20 "draft-ietf-avt-rtp-evrc-nw-02"

Hi=20 Chung Cheung,

 

Thanks=20 for your comments (in this email and the previous one “Mode request s= upport in=20 draft-ietf-avt-rtp-evrc-nw-02").

 

I=20 adopted the changes accordingly.=20 The diff is attached.

 

Basically,=20

1)=20 The clarifications regarding mode request support are adopted as you sugges= ted.=20 There are some wording differences, but those are=20 inconsequential.

2)=20 For the changes related to “sendmode”, I instead would like to = propose=20 deprecating this parameter in EVRC-NW. I believe, by deprecating the “= ;sendmode”=20 parameter, this not only addresses the concerns you had, but also avoids fu= rther=20 confusion in other usage scenarios which were not covered in your emails.=20  =20

    As=20 an result, the “sendmode” attribute is removed from all the exa= mples as=20 well.

 

Please=20 let me know if you have any additional comments; otherwise, I will submit t= his=20 new version to the I-D repository later.

 

Thanks,

Zheng

 

 

From:<= /B> Chung Cheung= Chu=20 [mailto:chung.cheung.chu@ericsson.com]
Sent: Friday, April 15, 2= 011=20 6:53 AM
To: payload@ietf.org; Fang, Zheng
Subject: Chan= ge=20 proposal to draft=20 "draft-ietf-avt-rtp-evrc-nw-02"

 

 

 

Background

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Draft "= draft-ietf-avt-rtp-ev= rc-nw-02" defines the = RTP=20 payload formats and corresponding media type registrations for CDMA codec=20 EVRC-NW [Ref. 3GPP2 C.S0014-D].  EVRC-NW is a multi-rate low bit rate = codec=20 adopted by 3GPP2.  This codec supports a total of 8 modes of operation= for=20 narrowband and wideband voice band traffic compression.  Mode-0 is for= =20 wideband compression.  Mode-1 to mode-7 are for narrowband compression= =20 where mode-4 is defined as the default mode.  The average encoding rat= e for=20 narrowband operation is decreased with increasing operating mode from mode-= 1 to=20 mode-7.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Three media su= btype=20 payload formats are defined in this draft.  They are EVRCNW, EVRCNW0 a= nd=20 EVRCNW1.  This email concerns with operations associated with the medi= a=20 subtype EVRCNW payload format definition.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Media subtype = EVRCNW=20 payload format is defined with a payload header which consists of a 3-bit m= ode=20 request field "MMM" and other payload related parameters [Ref. RFC3558].&nb= sp;=20 Per MMM definition by RFC3558, EVRCNW traffic receiver uses this field to=20 request an EVRCNW encoding mode to be used by the EVRCNW traffic generator = for=20 new traffic in the reverse path.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Draft "= draft-ietf-avt-rtp-ev= rc-nw-02" adopts two o= ptional=20 SDP attributes "mode-set-recv" and "sendmode" from RFC5188.  Attribute= =20 "mode-set-recv" is used to indicate the preferred mode of bearer traffic=20 supported by an EVRCNW receiver.  This attribute can assume a set of v= alues=20 0, 1, …, 7 denoting mode-0, mode-1, …, mode-7 support, respecti= vely. =20 Attribute "sendmode" is used to announce the current EVRCNW encoding mode b= y an=20 EVRCNW encoder.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

The draft stat= es that=20 in absence of mode-0 specification in "mode-set-recv" or in absence of the= =20 attribute, an EVRCNW encoder at the other side can only operate in narrowba= nd=20 mode.  In absence of attribute "sendmode", the encoding mode is=20 mode-4.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Proposal

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

It is understo= od that=20 an EVRCNW encoder cannot autonomously generate and send EVRC-NW mode-0=20 (wideband) traffic to the partner in absence of the partner's mode-0 (wideb= and)=20 decoding capability.  However, a user capable of decoding mode-0 (wide= band)=20 traffic should be allowed to request for mode-0 (wideband) traffic from the= =20 partner using the MMM field in the RTP RFC header.  Such an in-band re= quest=20 is an implicit indication of mode-0 (wideband) decoding capability of the=20 originator.  Upon receiving the mode-0 (wideband) request, a mode-0=20 (wideband) capable partner should be allowed to generate and send EVRC-NW=20 wideband encoded traffic to the request originator, regardless of the SDP=20 attribute "mode-set-recv".  A partner not capable of wideband encoding= can=20 ignore the request and should use a narrowband mode. 

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

An example whe= re the=20 MMM mode change request field facilitates narrowband-to-wideband and=20 wideband-to-narrowband operation switching is as follows:

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

An EVRCNW tran= scoding=20 free (TrFO) call is established in a session between mobile-A in a circuit= =20 switched network and mobile-B in a 4G network via a communication node in t= he=20 core network, such as a media gateway.   In this example, mobile-= A=20 supports EVRCNW without wideband compression capability, and mobile-B suppo= rts=20 EVRCNW with wideband compression capability.  The media gateway sends = at=20 call setup time SDP mode-set-recv attribute to mobile-B specifying only=20 narrowband mode support in light of mobile-A EVRCNW wideband incapability.&= nbsp;=20 During the call, a call transfer (or call waiting) takes place replacing=20 mobile-A with an EVRCNW wideband capable device, mobile-C.  In this=20 example, the media gateway does not update the optional SDP mode-set-recv=20 attribute on the stationary side to mobile-B. 

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

In this scenar= io,=20 EVRCNW wideband operation is allowed between mobile-C and the media gateway= but=20 not feasible between the media gateway and mobile-B according to the=20 mode-set-recv definition in the current draft.  This could result in=20 end-to-end EVRCNW operation in narrowband mode only.  If MMM mode chan= ge=20 requests for mode-0 traffic relayed from mobile-C is allowed and supported = by=20 mobile-B, end-to-end EVRCNW transcoding free operation would be re-establis= hed=20 in wideband mode.

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Conversely, wh= en the=20 wideband support capability is terminated during an active call session, fo= r=20 example due to a call transfer (or call waiting) back from mobile-C to mobi= le-A,=20 mode change requests relayed from mobile-A for narrowband operation should = be=20 considered as a preference indication that narrowband traffic is desired by= the=20 originator.  Mobile-B should honor the request and return narrowband=20 compressed traffic.  This is required even if the mode-set-recv SDP=20 attribute from the media gateway to mobile-B includes mode-0=20 support.

&= nbsp;

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

It is proposed= that=20 the following texts for media subtype EVRCNW SDP attributes "mode-set-recv"= and=20 "sendmode" be clarified:

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Original text: Sectio= n=20 9.1.1

mode-set-recv: A subs= et of=20 EVRC-NW modes.  Possible values are a comma separated list of modes fr= om=20 the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A= =20 decoder can use this attribute to inform an encoder of its preference to op= erate=20 in a specified subset of modes.  Absence of this parameter signals the= mode=20 set {1,2,3,4,5,6,7}.

 

Suggested text: Secti= on=20 9.1.1

mode-set-recv: A subs= et of=20 EVRC-NW modes.  Possible values are a comma separated list of modes fr= om=20 the set {0,1,2,3,4,5,6,7} (see Table 2.6.1.2-4 in 3GPP2 C.S0014-D).  A= =20 decoder can use this attribute to inform an encoder of its preference to op= erate=20 in a specified subset of modes.  Absence of this parameter signals the= mode=20 set {1,2,3,4,5,6,7}.

 

During a= n=20 active call session, the MMM mode request received from a communication par= tner=20 complements the mode set information in mode-set-recv.  A mode request= with=20 MMM=3D0 from a communication partner is an implicit indication of the partn= er's=20 EVRCNW wideband decoding capability and preference.  An EVRCNW wideban= d=20 capable node receiving the request can operate in wideband mode.  A mo= de=20 request with MMM=3D1, 2, …, or 7 from a communication partner is an i= mplicit=20 indication of the partner's EVRCNW narrowband decoding capability and=20 preference.  An EVRCNW node receiving the request should honor the req= uest=20 and operate in narrowband mode. = ;=20

 

 

 

Original text: Sectio= n=20 10

   1. = To=20 inform the capability of wideband mode support: A decoder can always decode= all=20 the narrowband modes (modes 1 to 7).  Unless the decoder indicates the= =20 support of mode 0 (i.e., preference) in this parameter, an encoder at the o= ther=20 side shall not operate in mode 0.

 

Suggested text: Secti= on=20 10

   1. = To=20 inform the capability of wideband mode support: A decoder can always decode= all=20 the narrowband modes (modes 1 to 7).  Unless the decoder indicates the= =20 support of mode 0 (i.e., preference) in this parameter and in the MMM mode request field in media subtype EV= RCNW=20 payload format, an encoder at the other side shall not operate in mo= de=20 0.

 

 

 

Original text: Sectio= n=20 9.1.1

   sendmode= : A=20 mode of the EVRC-NW codec.  An encoder can use this to signal its curr= ent=20 mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see Table=20 2.6.1.2-4 in 3GPP2 C.S0014-D).  Absence of this parameter signals mode= =20 4.

 

Suggested text: Secti= on=20 9.1.1

   sendmode= : A=20 mode of the EVRC-NW codec.  An encoder can use this to signal its curr= ent=20 mode of operation.  Possible values are 0,1,2,3,4,5,6,7 (see Table=20 2.6.1.2-4 in 3GPP2 C.S0014-D).  Absence= of=20 this parameter signals mode 4.

 &n= bsp; It=20 is not necessary to send this optional SDP attribute when an EVRCNW encoder= =20 updates its encoding mode during an active call session such as in response= to=20 requests in the MMM mode request field from the other side. Conversely, abs= ence=20 of this SDP attribute should not be interpreted as an indication the encode= r=20 operates only in default mode-4.

 

 

The suggested = changes=20 are for media subtype EVRCNW payload format only.  They are not applic= able=20 to media subtype EVRCNW0 and EVRCNW1 payload formats where the MMM mode req= uest=20 field is not supported. 

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Regards,

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

CC

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

Chung-Cheung=20 Chu

Media Gateway = DSP=20 Design

BCAM -=20 Ericsson

+514 345-7900= =20 (x46489)

This Communication = is=20 Confidential.  We only send and receive email on the basis of the term= s set=20 out at www.ericsson.com/email_discla= imer.

 

 <= SPAN=20 style=3D"FONT-FAMILY: 'Arial','sans-serif'">

--_000_26490BBDEEACA14EA1A0070367B3ADBDB77879D466EUSAACMS0702e_-- From Internet-Drafts@ietf.org Sat Apr 23 00:45:02 2011 Return-Path: X-Original-To: payload@ietfc.amsl.com Delivered-To: payload@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 75981E0690; Sat, 23 Apr 2011 00:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.427, 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 R-kn3jQinRrp; Sat, 23 Apr 2011 00:45:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2237E0693; Sat, 23 Apr 2011 00:45: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.52 Message-ID: <20110423074501.27489.21811.idtracker@ietfc.amsl.com> Date: Sat, 23 Apr 2011 00:45:01 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-avt-rtp-evrc-nw-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2011 07:45: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 Payloads Working Group of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Author(s) : Z. Fang Filename : draft-ietf-avt-rtp-evrc-nw-03.txt Pages : 28 Date : 2011-04-23 This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-03.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-avt-rtp-evrc-nw-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-23003744.I-D@ietf.org> --NextPart-- From Even.roni@huawei.com Thu Apr 28 01:32:12 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BEBE06DC for ; Thu, 28 Apr 2011 01:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.617 X-Spam-Level: X-Spam-Status: No, score=-100.617 tagged_above=-999 required=5 tests=[AWL=1.982, BAYES_00=-2.599, HTML_MESSAGE=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 fngeHpheVYj0 for ; Thu, 28 Apr 2011 01:32:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A3C78E062A for ; Thu, 28 Apr 2011 01:32:11 -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 <0LKC006YMT0618@szxga05-in.huawei.com> for payload@ietf.org; Thu, 28 Apr 2011 16:31:18 +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 <0LKC000K5T05J6@szxga05-in.huawei.com> for payload@ietf.org; Thu, 28 Apr 2011 16:31:18 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-7-230.red.bezeqint.net [109.64.7.230]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKC00E7ASZZHK@szxml12-in.huawei.com>; Thu, 28 Apr 2011 16:31:17 +0800 (CST) Date: Thu, 28 Apr 2011 11:30:11 +0300 From: Roni Even To: ietf-types@iana.org Message-id: <00b101cc057e$821da1e0$8658e5a0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3NnAYnFYTK9oS5nXebztBw)" Content-language: en-us Thread-index: AcwFfnxjlHJkjafvSnuGYHRK//xRTg== Cc: draft-ietf-avt-rfc3016bis.all@tools.ietf.org, payload@ietf.org Subject: [payload] updating the registeration of "MP4A-LATM" and "MP4V-ES" media sutypes. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 08:32:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3NnAYnFYTK9oS5nXebztBw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES" from RFC 3016. The new registrations are in Section 6.1 and Section 6.3 of the document. Comments on the registration are welcome. Thanks Roni Even Payload WG co-chair --Boundary_(ID_3NnAYnFYTK9oS5nXebztBw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

 

Hi,

 

draft-ietf-avt-rfc3016bis.txt has passed Working Group Last Call in the AVT Working Group (currently Payload). The document updates the media subtypes "MP4A-LATM" and "MP4V-ES"  from RFC 3016.  The new registrations are in Section 6.1 and   Section 6.3 of the document.

Comments on the registration are welcome.

 

Thanks

Roni Even

Payload WG co-chair

 

--Boundary_(ID_3NnAYnFYTK9oS5nXebztBw)--