From zfang@qualcomm.com Mon Oct 3 17:44:18 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 B24D821F8D8C for ; Mon, 3 Oct 2011 17:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uyjQiN2BiGN for ; Mon, 3 Oct 2011 17:44:08 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F021F8D7E for ; Mon, 3 Oct 2011 17:44:08 -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=1317689232; x=1349225232; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20|To:=20Ron i=20Even=20,=20"payload@ietf.org" =20|CC:=20"Wang,=20Min"=20,=20"Sinder,=20Dan"=20,=0D=0A =09"Huang,=20Pengjun=20(Jeff)"=20, =20"Kandhadai,=0D=0A=20Ananthapadmanabhan=20(Ananth)"=20< apadmana@qualcomm.com>,=20"Fang,=20Zheng"=0D=0A=09|Subject:=20RE:=20[payload]=20WGLC=20on=20dr aft-ietf-avt-rtp-evrc-nw-03|Thread-Topic:=20[payload]=20W GLC=20on=20draft-ietf-avt-rtp-evrc-nw-03|Thread-Index:=20 AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4A=3D|Date:=20Tu e,=204=20Oct=202011=2000:44:13=20+0000|Message-ID:=20|References:=20<008801cc5d9c$dd1eb400$975c1c00$%ro ni@huawei.com>=0D=0A=20<02b501cc663f$a40278e0$ec076aa0$%r oni@huawei.com>|In-Reply-To:=20<02b501cc663f$a40278e0$ec0 76aa0$%roni@huawei.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach:=20yes |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20multipart/mixed=3B=0D=0A=09boundary=3D"_ 005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqu al_"|MIME-Version:=201.0; bh=evMu4HrAhdgKaJSHlFExcat5Yi8+0AKYbB+2Qphz+bo=; b=gRD7i2JIMzNw9nZI69IYAArefyv40cJO7QIfSDXMsA/AudVhHS+yBQF8 dhtFtsliBzZquj84gm9S5haQB6jhOpnmiyB6M9Pvhb5WTbY9TxEctCXoG eDOCH/VDBl1WnHl7YXO7825MECsNzPO6FONjHGvIgRlMj0MQTYBYlKzIm w=; X-IronPort-AV: E=McAfee;i="5400,1158,6488"; a="124506357" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 03 Oct 2011 17:47:10 -0700 X-IronPort-AV: E=Sophos;i="4.68,479,1312182000"; d="diff'?txt'?scan'208,217";a="137297545" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 03 Oct 2011 17:47:10 -0700 Received: from NASANEXD01A.na.qualcomm.com ([fe80::88b1:1c81:4562:8797]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0339.001; Mon, 3 Oct 2011 17:44:13 -0700 From: "Fang, Zheng" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Thread-Index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4A= Date: Tue, 4 Oct 2011 00:44:13 +0000 Message-ID: References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> In-Reply-To: <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/mixed; boundary="_005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_" MIME-Version: 1.0 Cc: "Huang, Pengjun \(Jeff\)" , "Sinder, Dan" , "Wang, Min" , "Kandhadai, Ananthapadmanabhan \(Ananth\)" Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 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, 04 Oct 2011 00:44:18 -0000 --_005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_ Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_" --_000_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thank you for your comments and suggestions. I updated the draft based on y= our suggestions. Please find attached the modified text and diff. I am not sure how to address some of the comments. My answers to those ques= tions are in line. I would appreciate it if you could further comment on it= . I will submit a new version once I resolve all the comments. Thanks! Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Monday, August 29, 2011 4:35 AM To: payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I reviewed the draft and have some comments. 1. It looks to me that this draft updates RFC3558 similar to RFC 4788= and RFC 5188. It should be referenced in the header and in the text [Zheng] Although the payload definition of EVRCNW is similar to EVRCWB (RFC= 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only define= s the payload format for EVRCNW only. This is different than that of RFC 51= 88, which not only defines a new MIME type (EVRC-WB) but also update an exi= sting MIME type (EVRC-B in RFC 4788). 2. In section 6 first paragraph why not reference 3788 where ToC is d= efined. [Zheng] Reference is added. 3. In second 9 in the registration template you have sendmode depreca= ted. This is strange since this registration is a new registration so there= is nothing to deprecate . If you want to state that this optional paramete= r that is used in other EVRC modes is not used, please do it in another sec= tion and not in the registration section. [Zheng] The sendmode descriptions are removed from the registration templat= es. Instead a comment on it is added in Section 10 "SDP mode attributes for= EVRC-NW". 4. In section 9 in the published specification you mention RFC3558 wi= thout a reference. I think that this document need also to be specified sin= ce it defines the RTP header and the usage. [Zheng] References are added. 5. In section 9 in the author field add your email address [Zheng] Done. 6. In section 9 change controller should be " IETF Audio/Video Transp= ort working group delegated from the IESG." [Zheng] I am a little confused. The changed controller was indeed the same = as you mentioned. Can you please point it out in case I miss anything? 7. In section 13 how is "mode-set-recv" used in declarative SDP since = it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics can be asymmet= ric, i.e, incoming and outgoing streams use different sets of modes. It is = sufficient to declare decoder capability and the encoder at the other side = simply follows. Thanks Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-= nw-03 , RTP paylo= ad format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --_000_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thank you for your comments and suggestio= ns. I updated the draft based on your suggestions. Please find attached the= modified text and diff.

 

I am not sure how to address some of the = comments. My answers to those questions are in line. I would appreciate it = if you could further comment on it.

 

I will submit a new version once I resolv= e all the comments.

 

Thanks!

Zheng

 

From: Roni Eve= n [mailto:Even.roni@huawei.com]
Sent: Monday, August 29, 2011 4:35 AM
To: payload@ietf.org
Cc: Fang, Zheng
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

 

Hi,<= /p>

I reviewed the draft a= nd have some comments.

 

1.&n= bsp;      It looks to me= that this draft updates RFC3558 similar to RFC 4788 and RFC 5188.  It= should be referenced in the header and in the text

[Zheng] Although the payload definition o= f EVRCNW is similar to EVRCWB (RFC 5188), EVRCB (RFC 4788) and EVRC (RFC 35= 58), the current draft only defines the payload format for EVRCNW only. This is different than that of RFC 5188, which not only defin= es a new MIME type (EVRC-WB) but also update an existing MIME type (EVRC-B = in RFC 4788).

 =

2.&n= bsp;      In section 6 f= irst paragraph why not reference 3788 where ToC is defined.

[Zheng] Reference is added.

 

3.&n= bsp;      In second 9 in= the registration template you have sendmode deprecated. This is strange si= nce this registration is a new registration so there is nothing to deprecat= e . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do= it in another section and not in the registration section.

[Zheng] The sendmode descriptions are rem= oved from the registration templates. Instead a comment on it is added in S= ection 10 “SDP mode attributes for EVRC-NW”.<= /p>

 

4.&n= bsp;      In section 9 i= n the published specification you mention RFC3558 without a reference. I th= ink that this document need also to be specified since it defines the RTP h= eader and the usage.

[Zheng] References are added.

 

5.&n= bsp;      In section 9 i= n the author field add your email address

[Zheng] Done.

 

6.      In section 9 &= nbsp;change controller should be " IETF Audio/Video Transport w= orking group delegated from the IESG."

[Zheng] I am a little confused. The chang= ed controller was indeed the same as you mentioned. Can you please point it= out in case I miss anything?

 

7.      In section 13 = how is "mode-set-recv" used in declarative SDP since it is a deco= der capability and not an encoder one.

[Zheng] In some two-way conversation scen= arios, the traffics can be asymmetric, i.e, incoming and outgoing streams u= se different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows. =

 

Thanks

Roni Even

 

 

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even
Sent: Thursday, August 18, 2011 2:49 PM
To: payload@ietf.org
Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03<= /span>

 

Hi,

I would like to start a Working Group Last Call on draft-ietf-a=
vt-rtp-evrc-nw-03 , RTP payload format =
for Enhanced Variable Rate Narrowband-Wideband Codec  (EVRC-NW)

 

The WGLC will end on September 9, = 2011

Please review the draft and send comments to the lis= t.

 

 

Roni Even

Payload co-chair

 

--_000_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_-- --_005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_ Content-Type: text/plain; name="draft-ietf-avt-rtp-evrc-nw-03-update-a.txt" Content-Description: draft-ietf-avt-rtp-evrc-nw-03-update-a.txt Content-Disposition: attachment; filename="draft-ietf-avt-rtp-evrc-nw-03-update-a.txt"; size=35614; creation-date="Tue, 04 Oct 2011 00:42:48 GMT"; modification-date="Tue, 04 Oct 2011 00:32:41 GMT" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBaLiBGYW5nCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBRdWFsY29tbQpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDMsIDIwMTEKRXhwaXJl czogQXByaWwgNSwgMjAxMgoKClJUUCBwYXlsb2FkIGZvcm1hdCBmb3IgRW5oYW5jZWQgVmFyaWFi bGUgUmF0ZSBOYXJyb3diYW5kLVdpZGViYW5kIENvZGVjCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoRVZSQy1OVykKICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1hdnQtcnRw LWV2cmMtbnctMDQKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZWFsLXRp bWUgdHJhbnNwb3J0IHByb3RvY29sIChSVFApIHBheWxvYWQKICAgZm9ybWF0cyB0byBiZSB1c2Vk IGZvciB0aGUgRW5oYW5jZWQgVmFyaWFibGUgUmF0ZSBOYXJyb3diYW5kLVdpZGViYW5kCiAgIENv ZGVjIChFVlJDLU5XKS4gIFRocmVlIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9ucyBhcmUgaW5jbHVk ZWQgZm9yCiAgIEVWUkMtTlcgUlRQIHBheWxvYWQgZm9ybWF0cy4gIEluIGFkZGl0aW9uLCBhIGZp bGUgZm9ybWF0IGlzIHNwZWNpZmllZAogICBmb3IgdHJhbnNwb3J0IG9mIEVWUkMtTlcgc3BlZWNo IGRhdGEgaW4gc3RvcmFnZSBtb2RlIGFwcGxpY2F0aW9ucwogICBzdWNoIGFzIGUtbWFpbC4KClN0 YXR1cyBvZiB0aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJD UCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIElu dGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVy IGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy bmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBh dCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVz ZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhl bSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJh ZnQgd2lsbCBleHBpcmUgb24gQXByaWwgNSwgMjAxMi4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENv cHlyaWdodCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMg ZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwK ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0 ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVi bGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRz CiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rp b25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4 dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKCgoKRmFuZyAgICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgIFtQ YWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1h dCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMg YW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBpbiB0aGUg U2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJv ZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAzCiAgIDIuICBDb252ZW50aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNAogICAzLiAgQmFja2dyb3VuZCAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUKICAgNC4gIEVWUkMtTlcgY29kZWMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2CiAgIDUu ICBSVFAgaGVhZGVyIHVzYWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNwogICA2LiAgUGF5bG9hZCBmb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgNy4gIENvbmdlc3Rpb24gQ29udHJvbCBDb25z aWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDguICBTdG9yYWdl IGZvcm1hdCBmb3IgdGhlIEVWUkMtTlcgQ29kZWMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MAogICA5LiAgSUFOQSBjb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTEKICAgICA5LjEuICBNZWRpYSBUeXBlIFJlZ2lzdHJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgICAgICA5LjEuMS4gIFJlZ2lzdHJh dGlvbiBvZiBNZWRpYSBUeXBlIGF1ZGlvL0VWUkNOVyAgLiAuIC4gLiAuIC4gLiAxMQogICAgICAg OS4xLjIuICBSZWdpc3RyYXRpb24gb2YgTWVkaWEgVHlwZSBhdWRpby9FVlJDTlcwIC4gLiAuIC4g LiAuIC4gMTMKICAgICAgIDkuMS4zLiAgUmVnaXN0cmF0aW9uIG9mIE1lZGlhIFR5cGUgYXVkaW8v RVZSQ05XMSAuIC4gLiAuIC4gLiAuIDE0CiAgIDEwLiBTRFAgbW9kZSBhdHRyaWJ1dGVzIGZvciBF VlJDLU5XICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNwogICAxMS4gTWFwcGluZyBF VlJDLU5XIG1lZGlhIHR5cGUgcGFyYW1ldGVycyBpbnRvIFNEUCAuIC4gLiAuIC4gLiAuIC4gMTgK ICAgMTIuIE9mZmVyLUFuc3dlciBNb2RlbCBDb25zaWRlcmF0aW9ucyBmb3IgRVZSQy1OVyAgLiAu IC4gLiAuIC4gLiAuIDE5CiAgIDEzLiBEZWNsYXJhdGl2ZSBTRFAgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMQogICAxNC4gRXhhbXBsZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjIKICAgMTUuIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDI1CiAgIDE2LiBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAyNgogICAgIDE2LjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYKICAgICAxNi4yLiBJbmZvcm1h dGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI2CiAg IEF1dGhvcidzIEFkZHJlc3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyOAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRmFuZyAgICAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAg T2N0b2JlciAyMDExCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgdGhlIHBheWxvYWQgZm9ybWF0cyBmb3IgcGFja2V0aXphdGlvbiBvZgogICBFVlJDLU5XIGVu Y29kZWQgc3BlZWNoIHNpZ25hbHMgaW50byB0aGUgcmVhbC10aW1lIHRyYW5zcG9ydCBwcm90b2Nv bAogICAoUlRQKS4gIEl0IGRlZmluZXMgc3VwcG9ydCBmb3IgdGhlIGhlYWRlci1mcmVlLCBpbnRl cmxlYXZlZC9idW5kbGVkCiAgIGFuZCBjb21wYWN0IGJ1bmRsZSBwYWNrZXQgZm9ybWF0cyBmb3Ig dGhlIEVWUkMtTlcgY29kZWMgYXMgd2VsbCBhcwogICBkaXNjb250aW51b3VzIHRyYW5zbWlzc2lv biAoRFRYKSBzdXBwb3J0IGZvciBFVlJDLU5XIGVuY29kZWQgc3BlZWNoCiAgIHRyYW5zcG9ydGVk IHZpYSBSVFAuICBUaGUgRVZSQy1OVyBjb2RlYyBvZmZlcnMgYmV0dGVyIHNwZWVjaCBxdWFsaXR5 CiAgIHRoYW4gdGhlIEVWUkMgYW5kIEVWUkMtQiBjb2RlY3MgYW5kIGJldHRlciBjYXBhY2l0eSB0 aGFuIEVWUkMtV0IKICAgY29kZWMuICBFVlJDLU5XIGJlbG9uZ3MgdG8gdGhlIEVWUkMgZmFtaWx5 IG9mIGNvZGVjcy4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGYW5n ICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAgICAgICAg ICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUkMtTlcgUlRQIHBheWxvYWQg Zm9ybWF0ICAgICAgICAgICBPY3RvYmVyIDIwMTEKCgoyLiAgQ29udmVudGlvbnMKCiAgIFRoZSBr ZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwg Tk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFu ZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbMV0uCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgpGYW5nICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwg NSwgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEVWUkMtTlcgUlRQIHBheWxvYWQgZm9ybWF0ICAgICAgICAgICBPY3RvYmVyIDIwMTEKCgozLiAg QmFja2dyb3VuZAoKICAgRVZSQy1OVyBpcyBhbiBleHRlbnNpb24gb2YgYm90aCB0aGUgRVZSQy1C IFsyXSBhbmQgRVZSQy1XQiBbM10gc3BlZWNoCiAgIGNvZGVjcyBkZXZlbG9wZWQgaW4gM0dQUDIg d2l0aCBzdXBwb3J0IGZvciBkaXNjb250aW51b3VzIHRyYW5zbWlzc2lvbgogICAoRFRYKS4gIEl0 IHByb3ZpZGVzIGVuaGFuY2VkIHZvaWNlIHF1YWxpdHkgYW5kIGhpZ2ggc3BlY3RyYWwKICAgZWZm aWNpZW5jeS4KCiAgIFRoZSBFVlJDLU5XIGNvZGVjIG9wZXJhdGVzIG9uIDIwIG1zIGZyYW1lcywg YW5kIHRoZSBkZWZhdWx0IHNhbXBsaW5nCiAgIHJhdGUgaXMgMTYga0h6LiAgSW5wdXQgYW5kIG91 dHB1dCBhdCA4IGtIeiBzYW1wbGluZyByYXRlIGlzIGFsc28KICAgc3VwcG9ydGVkLiAgVGhlIEVW UkMtTlcgY29kZWMgY2FuIG9wZXJhdGUgaW4gZWlnaHQgbW9kZXMgKDAgdG8gNykKICAgZGVmaW5l ZCBpbiBbNF0uICBFVlJDLU5XIG1vZGVzIDAsIDEgYW5kIDcgYXJlIGludGVyb3BlcmFibGUgd2l0 aAogICBFVlJDLVdCLiAgRVZSQy1OVyBtb2RlcyAxIHRvIDcgYXJlIGludGVyb3BlcmFibGUgd2l0 aCBFVlJDLUIuCiAgIEVWUkMtTlcgbW9kZXMgMCB0byA2IHVzZSB0aGUgZnVsbCBzZXQgb3IgYSBz dWJzZXQgb2YgZnVsbCByYXRlLCAxLzIKICAgcmF0ZSwgMS80IHJhdGUgYW5kIDEvOCByYXRlIGZy YW1lcy4gIEVWUkMtTlcgbW9kZSA3IHVzZXMgb25seSAxLzIKICAgcmF0ZSBhbmQgMS84IHJhdGUg ZnJhbWVzLiAgQnkgZGVmYXVsdCwgRVZSQy1OVyBzdXBwb3J0cyBhbGwKICAgbmFycm93YmFuZCBt b2RlcyAobW9kZXMgMSB0byA3KS4gIFRoZSBzdXBwb3J0IG9mIHdpZGViYW5kIG1vZGUgKG1vZGUK ICAgMCkgaXMgb3B0aW9uYWwuICBNb2RlIGNoYW5nZSBhbW9uZyBtb2RlcyAxIHRvIDcgKG9yIGFt b25nIG1vZGVzIDAgdG8KICAgNyBpZiB0aGUgcmVjZWl2ZXIgc3VwcG9ydHMgd2lkZWJhbmQgbW9k ZSkgcmVzdWx0cyBpbiBjb2RlYyBvdXRwdXQKICAgYml0LXJhdGUgY2hhbmdlIGJ1dCBkb2VzIG5v dCBjYXVzZSBhbnkgZGVjb2RpbmcgcHJvYmxlbXMgYXQgdGhlCiAgIHJlY2VpdmVyLiAgRVZSQy1O VyBwcm92aWRlcyBhIHN0YW5kYXJkaXplZCBzb2x1dGlvbiBmb3IgcGFja2V0aXplZAogICB2b2lj ZSBhcHBsaWNhdGlvbnMgdGhhdCBhbGxvdyB0cmFuc2l0aW9ucyBiZXR3ZWVuIGVuaGFuY2VkIHF1 YWxpdHkKICAgYW5kIGluY3JlYXNlZCBjYXBhY2l0eS4gIFRoZSBtb3N0IGltcG9ydGFudCBzZXJ2 aWNlIGFkZHJlc3NlZCBpcyBJUAogICB0ZWxlcGhvbnkuICBUYXJnZXQgZGV2aWNlcyBjYW4gYmUg SVAgcGhvbmVzIG9yIFZvSVAgaGFuZHNldHMsIG1lZGlhCiAgIGdhdGV3YXlzLCB2b2ljZSBtZXNz YWdpbmcgc2VydmVycywgZXRjLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGYW5nICAgICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAgICAgICAgICAgW1Bh Z2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUkMtTlcgUlRQIHBheWxvYWQgZm9ybWF0 ICAgICAgICAgICBPY3RvYmVyIDIwMTEKCgo0LiAgRVZSQy1OVyBjb2RlYwoKICAgVGhlIEVWUkMt TlcgY29kZWMgb3BlcmF0ZXMgb24gMjAgbXMgZnJhbWVzLiAgSXQgcHJvZHVjZXMgb3V0cHV0CiAg IGZyYW1lcyBvZiBvbmUgb2YgdGhlIGZvdXIgZGlmZmVyZW50IHNpemVzOiAxNzEgYml0cyAoUmF0 ZSAxKSwgODAgYml0cwogICAoUmF0ZSAxLzIpLCA0MCBiaXRzIChSYXRlIDEvNCkgb3IgMTYgYml0 cyAoUmF0ZSAxLzgpLiAgSW4gYWRkaXRpb24sCiAgIHRoZXJlIGFyZSB0d28gemVybyBiaXQgY29k ZWMgZnJhbWUgdHlwZXM6IGJsYW5rIChudWxsKSBmcmFtZXMgYW5kCiAgIGVyYXN1cmUgZnJhbWVz LiAgVGhlIGRlZmF1bHQgc2FtcGxpbmcgcmF0ZSBpcyAxNiBrSHouICBJbnB1dCBhbmQKICAgb3V0 cHV0IGF0IDgga0h6IHNhbXBsaW5nIHJhdGUgaXMgYWxzbyBzdXBwb3J0ZWQuCgogICBUaGUgZnJh bWUgdHlwZSB2YWx1ZXMgYW5kIHNpemVzIG9mIHRoZSBhc3NvY2lhdGVkIGNvZGVjIGRhdGEgZnJh bWVzCiAgIGFyZSBsaXN0ZWQgaW4gdGhlIHRhYmxlIGJlbG93OgoKICAgVmFsdWUgICBSYXRlICAg ICAgVG90YWwgY29kZWMgZGF0YSBmcmFtZSBzaXplIGluIGJ5dGVzIChhbmQgaW4gYml0cykKICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KICAgICAwICAgICBCbGFuayhOdWxsKSAgMCAgICAoMCBiaXQpCiAgICAgMSAg ICAgMS84ICAgICAgICAgIDIgICAgKDE2IGJpdHMpCiAgICAgMiAgICAgMS80ICAgICAgICAgIDUg ICAgKDQwIGJpdHMpCiAgICAgMyAgICAgMS8yICAgICAgICAgMTAgICAgKDgwIGJpdHMpCiAgICAg NCAgICAgMSAgICAgICAgICAgMjIgICAgKDE3MSBiaXRzOyA1IGJpdHMgcGFkZGVkIGF0IHRoZSBl bmQpCiAgICAgNSAgICAgRXJhc3VyZSAgICAgIDAgICAgKFNIT1VMRCBOT1QgYmUgdHJhbnNtaXR0 ZWQgYnkgc2VuZGVyKQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRmFuZyAgICAgICAg ICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdl IDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAg ICAgICAgICAgT2N0b2JlciAyMDExCgoKNS4gIFJUUCBoZWFkZXIgdXNhZ2UKCiAgIFRoZSBmb3Jt YXQgb2YgdGhlIFJUUCBoZWFkZXIgaXMgc3BlY2lmaWVkIGluIFJGQyAzNTUwIFs1XS4gIFRoZQog ICBFVlJDLU5XIHBheWxvYWQgZm9ybWF0cyAoU2VjdGlvbiA2KSB1c2UgdGhlIGZpZWxkcyBvZiB0 aGUgUlRQIGhlYWRlcgogICBpbiBhIG1hbm5lciBjb25zaXN0ZW50IHdpdGggUkZDIDM1NTAgWzVd LgoKICAgRVZSQy1OVyBoYXMgYWxzbyB0aGUgY2FwYWJpbGl0eSB0byBvcGVyYXRlIHdpdGggOCBr SHogc2FtcGxlZCBpbnB1dC8KICAgb3V0cHV0IHNpZ25hbHMuICBUaGUgZGVjb2RlciBkb2VzIG5v dCByZXF1aXJlIGEgcHJpb3JpIGtub3dsZWRnZQogICBhYm91dCB0aGUgc2FtcGxpbmcgcmF0ZSBv ZiB0aGUgb3JpZ2luYWwgc2lnbmFsIGF0IHRoZSBpbnB1dCBvZiB0aGUKICAgZW5jb2Rlci4gIFRo ZSBkZWNvZGVyIG91dHB1dCBjYW4gYmUgYXQgOGtIeiBvciAxNmtIeiByZWdhcmRsZXNzIG9mCiAg IHRoZSBzYW1wbGluZyByYXRlIHVzZWQgYXQgdGhlIGVuY29kZXIuICBUaGVyZWZvcmUsIGRlcGVu ZGluZyBvbiB0aGUKICAgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBlbGVjdHJvYWNvdXN0aWMgYXVk aW8gY2FwYWJpbGl0aWVzIG9mIHRoZQogICBkZXZpY2VzLCB0aGUgaW5wdXQgb2YgdGhlIGVuY29k ZXIgYW5kL29yIHRoZSBvdXRwdXQgb2YgdGhlIGRlY29kZXIKICAgY2FuIGJlIGNvbmZpZ3VyZWQg YXQgOCBrSHo7IGhvd2V2ZXIsIGEgMTYga0h6IFJUUCBjbG9jayByYXRlIE1VU1QKICAgYWx3YXlz IGJlIHVzZWQuICBUaGUgUlRQIHRpbWVzdGFtcCBpcyBpbmNyZWFzZWQgYnkgMzIwIGZvciBlYWNo IDIwCiAgIG1pbGxpc2Vjb25kcy4KCiAgIFRoZSBSVFAgaGVhZGVyIG1hcmtlciBiaXQgKE0pIFNI QUxMIGJlIHNldCB0byAxIGlmIHRoZSBmaXJzdCBmcmFtZQogICBjYXJyaWVkIGluIHRoZSBwYWNr ZXQgY29udGFpbnMgYSBzcGVlY2ggZnJhbWUgd2hpY2ggaXMgdGhlIGZpcnN0IGluIGEKICAgdGFs a3NwdXJ0LiAgRm9yIGFsbCBvdGhlciBwYWNrZXRzIHRoZSBtYXJrZXIgYml0IFNIQUxMIGJlIHNl dCB0byB6ZXJvCiAgIChNPTApLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGYW5nICAg ICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAgICAgICAgICAg W1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUkMtTlcgUlRQIHBheWxvYWQgZm9y bWF0ICAgICAgICAgICBPY3RvYmVyIDIwMTEKCgo2LiAgUGF5bG9hZCBmb3JtYXQKCiAgIFRocmVl IFJUUCBwYWNrZXQgZm9ybWF0cyBhcmUgc3VwcG9ydGVkIGZvciB0aGUgRVZSQy1OVyBjb2RlYyAt IHRoZQogICBpbnRlcmxlYXZlZC9idW5kbGVkIHBhY2tldCBmb3JtYXQsIHRoZSBoZWFkZXItZnJl ZSBwYWNrZXQgZm9ybWF0IGFuZAogICB0aGUgY29tcGFjdCBidW5kbGVkIHBhY2tldCBmb3JtYXQu ICBGb3IgYWxsIHRoZXNlIGZvcm1hdHMsIHRoZQogICBvcGVyYXRpb25hbCBkZXRhaWxzIGFuZCBj YXBhYmlsaXRpZXMsIHN1Y2ggYXMgVG9DLCBpbnRlcmxlYXZpbmcsIERUWCwKICAgYW5kIGJ1bmRs aW5nLCBvZiBFVlJDLU5XIGFyZSBleGFjdGx5IHRoZSBzYW1lIGFzIHRob3NlIGRlZmluZWQgaW4K ICAgRVZSQyBbNl0sIEVWUkMtQiBbMl0gYW5kIEVWUkMtV0IgWzNdLCBleGNlcHQgdGhhdAoKICAg MS4gIHRoZSBtb2RlIGNoYW5nZSByZXF1ZXN0IGZpZWxkIGluIHRoZSBpbnRlcmxlYXZlZC9idW5k bGVkIHBhY2tldAogICAgICAgZm9ybWF0IE1VU1QgYmUgaW50ZXJwcmV0ZWQgYWNjb3JkaW5nIHRv IHRoZSBkZWZpbml0aW9uIG9mIHRoZQogICAgICAgUkFURV9SRURVQyBwYXJhbWV0ZXIgYXMgZGVm aW5lZCBpbiBFVlJDLU5XIFs0XS4KCiAgIDIuICB0aGUgbW9kZSBjaGFuZ2UgcmVxdWVzdCBmaWVs ZCBpbiB0aGUgaW50ZXJsZWF2ZWQvYnVuZGxlZCBwYWNrZXQKICAgICAgIGZvcm1hdCBTSE9VTEQg YmUgaG9ub3JlZCBieSBhbiBFVlJDTlcgZW5jb2RpbmcgZW5kIHBvaW50IGluIGFuCiAgICAgICBv bmUtdG8tb25lIHNlc3Npb24gd2l0aCBhIGRlZGljYXRlZCBFVlJDTlcgZGVjb2RpbmcgZW5kIHBv aW50CiAgICAgICBzdWNoIGFzIGluIGEgdHdvLXBhcnR5IGNhbGwgb3IgaW4gYSBjb25mZXJlbmNl IGxlZy4KCiAgIFRoZSBtZWRpYSB0eXBlIGF1ZGlvL0VWUkNOVyBtYXBzIHRvIHRoZSBpbnRlcmxl YXZlZC9idW5kbGVkIHBhY2tldAogICBmb3JtYXQsIGF1ZGlvL0VWUkNOVzAgbWFwcyB0byB0aGUg aGVhZGVyLWZyZWUgcGFja2V0IGZvcm1hdCBhbmQKICAgYXVkaW8vRVZSQ05XMSBtYXBzIHRvIHRo ZSBjb21wYWN0IGJ1bmRsZWQgcGFja2V0IGZvcm1hdC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKRmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAg ICAgICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJU UCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKNy4gIENvbmdlc3Rpb24g Q29udHJvbCBDb25zaWRlcmF0aW9ucwoKICAgQ29uZ2VzdGlvbiBjb250cm9sIGZvciBSVFAgU0hB TEwgYmUgdXNlZCBpbiBhY2NvcmRhbmNlIHdpdGggUkZDIDM1NTAKICAgWzVdLCBhbmQgd2l0aCBh bnkgYXBwbGljYWJsZSBSVFAgcHJvZmlsZTsgZS5nLiwgUkZDIDM1NTEgWzddLgoKICAgRHVlIHRv IHRoZSBoZWFkZXIgb3ZlcmhlYWQsIHRoZSBudW1iZXIgb2YgZnJhbWVzIGVuY2Fwc3VsYXRlZCBp biBlYWNoCiAgIFJUUCBwYWNrZXQgaW5mbHVlbmNlcyB0aGUgb3ZlcmFsbCBiYW5kd2lkdGggb2Yg dGhlIFJUUCBzdHJlYW0uCiAgIFBhY2tpbmcgbW9yZSBmcmFtZXMgaW4gZWFjaCBSVFAgcGFja2V0 IGNhbiByZWR1Y2UgdGhlIG51bWJlciBvZgogICBwYWNrZXRzIHNlbnQgYW5kIGhlbmNlIHRoZSBo ZWFkZXIgb3ZlcmhlYWQsIGF0IHRoZSBleHBlbnNlIG9mCiAgIGluY3JlYXNlZCBkZWxheSBhbmQg cmVkdWNlZCBlcnJvciByb2J1c3RuZXNzLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEy ICAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZSQy1O VyBSVFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCjguICBTdG9yYWdl IGZvcm1hdCBmb3IgdGhlIEVWUkMtTlcgQ29kZWMKCiAgIFRoZSBzdG9yYWdlIGZvcm1hdCBpcyB1 c2VkIGZvciBzdG9yaW5nIEVWUkMtTlcgZW5jb2RlZCBzcGVlY2ggZnJhbWVzLAogICBlLmcuLCBh cyBhIGZpbGUgb3IgZS1tYWlsIGF0dGFjaG1lbnQuCgogICBUaGUgZmlsZSBiZWdpbnMgd2l0aCBh IG1hZ2ljIG51bWJlciB0byBpZGVudGlmeSB0aGUgdm9jb2RlciB0aGF0IGlzCiAgIHVzZWQuICBU aGUgbWFnaWMgbnVtYmVyIGZvciBFVlJDLU5XIGNvcnJlc3BvbmRzIHRvIHRoZSBBU0NJSQogICBj aGFyYWN0ZXIgc3RyaW5nICIjIUVWUkNOV1xuIiwgaS5lLiwgIjB4MjMgMHgyMSAweDQ1IDB4NTYg MHg1MiAweDQzCiAgIDB4NEUgMHg1NyAweDBBIi4KCiAgIFRoZSBjb2RlYyBkYXRhIGZyYW1lcyBh cmUgc3RvcmVkIGluIGNvbnNlY3V0aXZlIG9yZGVyLCB3aXRoIGEgc2luZ2xlCiAgIFRvQyBlbnRy eSBmaWVsZCwgZXh0ZW5kZWQgdG8gb25lIG9jdGV0LCBwcmVmaXhpbmcgZWFjaCBjb2RlYyBkYXRh CiAgIGZyYW1lLiAgVGhlIFRvQyBmaWVsZCBpcyBleHRlbmRlZCB0byBvbmUgb2N0ZXQgYnkgc2V0 dGluZyB0aGUgZm91cgogICBtb3N0IHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIG9jdGV0IHRvIHpl cm8uICBGb3IgZXhhbXBsZSwgYSBUb0MgdmFsdWUKICAgb2YgNCAoYSBmdWxsLXJhdGUgZnJhbWUp IGlzIHN0b3JlZCBhcyAweDA0LiAgU2VlIFNlY3Rpb24gNCBmb3IgdGhlCiAgIG1hcHBpbmcgZnJv bSBmcmFtZSB0eXBlIHRvIFRvQyB2YWx1ZS4KCiAgIFNwZWVjaCBmcmFtZXMgbG9zdCBpbiB0cmFu c21pc3Npb24gYW5kIG5vbi1yZWNlaXZlZCBmcmFtZXMgTVVTVCBiZQogICBzdG9yZWQgYXMgZXJh c3VyZSBmcmFtZXMgKFRvQyB2YWx1ZSBvZiA1KSB0byBtYWludGFpbiBzeW5jaHJvbml6YXRpb24K ICAgd2l0aCB0aGUgb3JpZ2luYWwgbWVkaWEuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgpGYW5nICAgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAg ICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUkMtTlcgUlRQIHBh eWxvYWQgZm9ybWF0ICAgICAgICAgICBPY3RvYmVyIDIwMTEKCgo5LiAgSUFOQSBjb25zaWRlcmF0 aW9ucwoKICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgbmV3IEVWUkMtTlcgJ2F1ZGlvJyBt ZWRpYSBzdWJ0eXBlLgoKOS4xLiAgTWVkaWEgVHlwZSBSZWdpc3RyYXRpb25zCgogICBGb2xsb3dp bmcgdGhlIGd1aWRlbGluZXMgaW4gUkZDIDQ4NTUgWzhdIGFuZCBSRkMgNDI4OCBbOV0sIHRoaXMK ICAgc2VjdGlvbiByZWdpc3RlcnMgbmV3ICdhdWRpbycgbWVkaWEgc3VidHlwZXMgZm9yIEVWUkMt TlcuCgo5LjEuMS4gIFJlZ2lzdHJhdGlvbiBvZiBNZWRpYSBUeXBlIGF1ZGlvL0VWUkNOVwoKICAg VHlwZSBuYW1lOiBhdWRpbwoKICAgU3VidHlwZSBuYW1lczogRVZSQ05XCgogICBSZXF1aXJlZCBw YXJhbWV0ZXJzOiBOb25lCgogICBPcHRpb25hbCBwYXJhbWV0ZXJzOgoKICAgVGhlc2UgcGFyYW1l dGVycyBhcHBseSB0byBSVFAgdHJhbnNmZXIgb25seS4KCiAgIG1vZGUtc2V0LXJlY3Y6IEEgc3Vi c2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgY29tbWEgc2Vw YXJhdGVkIGxpc3Qgb2YgbW9kZXMgZnJvbSB0aGUgc2V0IHswLDEsMiwzLDQsNSw2LDd9IChzZWUK ICAgVGFibGUgMi42LjEuMi00IGluIDNHUFAyIEMuUzAwMTQtRCkuICBBIGRlY29kZXIgY2FuIHVz ZSB0aGlzCiAgIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4gZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5j ZSB0byBvcGVyYXRlIGluIGEKICAgc3BlY2lmaWVkIHN1YnNldCBvZiBtb2Rlcy4gIEFic2VuY2Ug b2YgdGhpcyBwYXJhbWV0ZXIgc2lnbmFscyB0aGUKICAgbW9kZSBzZXQgezEsMiwzLDQsNSw2LDd9 LgoKICAgcHRpbWU6IHNlZSBSRkMgNDU2NiBbMTBdLgoKICAgbWF4cHRpbWU6IHNlZSBSRkMgNDU2 Ni4KCiAgIG1heGludGVybGVhdmU6IE1heGltdW0gbnVtYmVyIGZvciBpbnRlcmxlYXZpbmcgbGVu Z3RoIChmaWVsZCBMTEwgaW4KICAgdGhlIEludGVybGVhdmluZyBPY3RldClbMC4uN10uICBUaGUg aW50ZXJsZWF2aW5nIGxlbmd0aHMgdXNlZCBpbiB0aGUKICAgZW50aXJlIHNlc3Npb24gTVVTVCBO T1QgZXhjZWVkIHRoaXMgbWF4aW11bSB2YWx1ZS4gIElmIG5vdCBzaWduYWxlZCwKICAgdGhlIG1h eGludGVybGVhdmUgbGVuZ3RoIE1VU1QgYmUgNS4KCiAgIHNpbGVuY2VzdXBwOiBzZWUgU2VjdGlv biA2LjEgaW4gUkZDIDQ3ODguCgogICBkdHhtYXg6IHNlZSBTZWN0aW9uIDYuMSBpbiBSRkMgNDc4 OC4KCiAgIGR0eG1pbjogc2VlIFNlY3Rpb24gNi4xIGluIFJGQyA0Nzg4LgoKICAgaGFuZ292ZXI6 IHNlZSBTZWN0aW9uIDYuMSBpbiBSRkMgNDc4OC4KCiAgIEVuY29kaW5nIGNvbnNpZGVyYXRpb25z OgoKICAgVGhpcyBtZWRpYSB0eXBlIGlzIGZyYW1lZCBiaW5hcnkgZGF0YSAoc2VlIFJGQyA0Mjg4 LCBTZWN0aW9uIDQuOCkgYW5kCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBB cHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDExXQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgRVZSQy1OVyBSVFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoK CiAgIGlzIGRlZmluZWQgZm9yIHRyYW5zZmVyIG9mIEVWUkMtTlcgZW5jb2RlZCBkYXRhIHZpYSBS VFAgdXNpbmcgdGhlCiAgIEludGVybGVhdmVkL0J1bmRsZWQgcGFja2V0IGZvcm1hdCBzcGVjaWZp ZWQgaW4gUkZDIDM1NTggWzZdLgoKICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IFNlZSBTZWN0 aW9uIDE1LgoKICAgSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczogTm9uZQoKICAgUHVi bGlzaGVkIHNwZWNpZmljYXRpb246CgogICBUaGUgRVZSQy1OVyB2b2NvZGVyIGlzIHNwZWNpZmll ZCBpbiAzR1BQMiBDLlMwMDE0LUQuICBUaGUgdHJhbnNmZXIKICAgbWV0aG9kIHdpdGggdGhlIElu dGVybGVhdmVkL0J1bmRsZWQgcGFja2V0IGZvcm1hdCB2aWEgUlRQIGlzCiAgIHNwZWNpZmllZCBp biBSRkMgMzU1OCBbNl0uCgogICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBl OgoKICAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBtYW55IFZvSVAgYXBwbGljYXRpb25zIChhcyB3ZWxs IGFzIG1vYmlsZQogICBhcHBsaWNhdGlvbnMpIHdpbGwgdXNlIHRoaXMgdHlwZS4KCiAgIEFkZGl0 aW9uYWwgaW5mb3JtYXRpb246CgogICBUaGUgZm9sbG93aW5nIGFwcGxpZXMgdG8gc3RvcmVkLWZp bGUgdHJhbnNmZXIgbWV0aG9kczoKCiAgIE1hZ2ljIG51bWJlcjogIyFFVlJDTldcbiAoc2VlIFNl Y3Rpb24gOCkKCiAgIEZpbGUgZXh0ZW5zaW9uczogZW53LCBFTlcKCiAgIE1hY2ludG9zaCBmaWxl IHR5cGUgY29kZTogTm9uZQoKICAgT2JqZWN0IGlkZW50aWZpZXIgb3IgT0lEOiBOb25lCgogICBF VlJDLU5XIHNwZWVjaCBmcmFtZXMgbWF5IGFsc28gYmUgc3RvcmVkIGluIHRoZSBmaWxlIGZvcm1h dCAiM2cyIgogICBkZWZpbmVkIGluIDNHUFAyIEMuUzAwNTAtQiwgd2hpY2ggaXMgaWRlbnRpZmll ZCB1c2luZyB0aGUgbWVkaWEgdHlwZXMKICAgImF1ZGlvLzNncHAyIiBvciAidmlkZW8vM2dwcDIi IHJlZ2lzdGVyZWQgYnkgUkZDIDQzOTMgWzExXS4KCiAgIFBlcnNvbiAmIGVtYWlsIGFkZHJlc3Mg dG8gY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoKCiAgIFpoZW5nIEZhbmcgPHpmYW5n QHF1YWxjb21tLmNvbT4KCiAgIEludGVuZGVkIHVzYWdlOiBDT01NT04KCiAgIFJlc3RyaWN0aW9u cyBvbiB1c2FnZToKCiAgIFdoZW4gdGhpcyBtZWRpYSB0eXBlIGlzIHVzZWQgaW4gdGhlIGNvbnRl eHQgb2YgdHJhbnNmZXIgb3ZlciBSVFAsIHRoZQogICBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lm aWVkIGluIFNlY3Rpb24gNC4xIG9mIFJGQyAzNTU4IFs2XSBTSEFMTCBiZQogICB1c2VkLiAgSW4g YWxsIG90aGVyIGNvbnRleHRzLCB0aGUgZmlsZSBmb3JtYXQgZGVmaW5lZCBpbiBTZWN0aW9uIDgK ICAgU0hBTEwgYmUgdXNlZC4KCiAgIEF1dGhvcjoKCgoKRmFuZyAgICAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0 b2JlciAyMDExCgoKICAgWmhlbmcgRmFuZyA8emZhbmdAcXVhbGNvbW0uY29tPgoKICAgQ2hhbmdl IGNvbnRyb2xsZXI6CgogICBJRVRGIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCB3b3JraW5nIGdyb3Vw IGRlbGVnYXRlZCBmcm9tIHRoZSBJRVNHLgoKOS4xLjIuICBSZWdpc3RyYXRpb24gb2YgTWVkaWEg VHlwZSBhdWRpby9FVlJDTlcwCgogICBUeXBlIG5hbWU6IGF1ZGlvCgogICBTdWJ0eXBlIG5hbWVz OiBFVlJDTlcwCgogICBSZXF1aXJlZCBwYXJhbWV0ZXJzOiBOb25lCgogICBPcHRpb25hbCBwYXJh bWV0ZXJzOgoKICAgVGhlc2UgcGFyYW1ldGVycyBhcHBseSB0byBSVFAgdHJhbnNmZXIgb25seS4K CiAgIG1vZGUtc2V0LXJlY3Y6IEEgc3Vic2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2 YWx1ZXMgYXJlIGEKICAgY29tbWEgc2VwYXJhdGVkIGxpc3Qgb2YgbW9kZXMgZnJvbSB0aGUgc2V0 IHswLDEsMiwzLDQsNSw2LDd9IChzZWUKICAgVGFibGUgMi42LjEuMi00IGluIDNHUFAyIEMuUzAw MTQtRCkuICBBIGRlY29kZXIgY2FuIHVzZSB0aGlzCiAgIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4g ZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5jZSB0byBvcGVyYXRlIGluIGEKICAgc3BlY2lmaWVkIHN1 YnNldCBvZiBtb2Rlcy4gIEFic2VuY2Ugb2YgdGhpcyBwYXJhbWV0ZXIgc2lnbmFscyB0aGUKICAg bW9kZSBzZXQgezEsMiwzLDQsNSw2LDd9LgoKICAgcHRpbWU6IHNlZSBSRkMgNDU2Ni4KCiAgIHNp bGVuY2VzdXBwOiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCgogICBkdHhtYXg6IHNlZSBT ZWN0aW9uIDYuMSBpbiBSRkMgNDc4OC4KCiAgIGR0eG1pbjogc2VlIFNlY3Rpb24gNi4xIGluIFJG QyA0Nzg4LgoKICAgaGFuZ292ZXI6IHNlZSBTZWN0aW9uIDYuMSBpbiBSRkMgNDc4OC4KCiAgIEVu Y29kaW5nIGNvbnNpZGVyYXRpb25zOgoKICAgVGhpcyBtZWRpYSB0eXBlIGlzIGZyYW1lZCBiaW5h cnkgZGF0YSAoc2VlIFJGQyA0Mjg4LCBTZWN0aW9uIDQuOCkgYW5kCiAgIGlzIGRlZmluZWQgZm9y IHRyYW5zZmVyIG9mIEVWUkMtTlcgZW5jb2RlZCBkYXRhIHZpYSBSVFAgdXNpbmcgdGhlCiAgIEhl YWRlci1GcmVlIHBhY2tldCBmb3JtYXQgc3BlY2lmaWVkIGluIFJGQyAzNTU4IFs2XS4KCiAgIFNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zOiBTZWUgU2VjdGlvbiAxNS4KCiAgIEludGVyb3BlcmFiaWxp dHkgY29uc2lkZXJ0YWlvbnM6IE5vbmUKCiAgIFB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOgoKICAg VGhlIEVWUkMtTlcgdm9jb2RlciBpcyBzcGVjaWZpZWQgaW4gM0dQUDIgQy5TMDAxNC1ELiAgVGhl IHRyYW5zZmVyCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAy MDEyICAgICAgICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZS Qy1OVyBSVFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgIG1ldGhv ZCB3aXRoIHRoZSBIZWFkZXItRnJlZSBwYWNrZXQgZm9ybWF0IHZpYSBSVFAgaXMgc3BlY2lmaWVk IGluIFJGQwogICAzNTU4IFs2XS4KCiAgIEFwcGxpY2F0aW9ucyB0aGF0IHVzZSB0aGlzIG1lZGlh IHR5cGU6CgogICBJdCBpcyBleHBlY3RlZCB0aGF0IG1hbnkgVm9JUCBhcHBsaWNhdGlvbnMgKGFz IHdlbGwgYXMgbW9iaWxlCiAgIGFwcGxpY2F0aW9ucykgd2lsbCB1c2UgdGhpcyB0eXBlLgoKICAg QWRkaXRpb25hbCBpbmZvcm1hdGlvbjogTm9uZQoKICAgUGVyc29uICYgZW1haWwgYWRkcmVzcyB0 byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOgoKICAgWmhlbmcgRmFuZyA8emZhbmdA cXVhbGNvbW0uY29tPgoKICAgSW50ZW5kZWQgdXNhZ2U6IENPTU1PTgoKICAgUmVzdHJpY3Rpb25z IG9uIHVzYWdlOgoKICAgVGhpcyBtZWRpYSB0eXBlIGRlcGVuZHMgb24gUlRQIGZyYW1pbmcsIGFu ZCBoZW5jZSBpcyBvbmx5IGRlZmluZWQgZm9yCiAgIHRyYW5zZmVyIHZpYSBSVFAgWzVdLCB0aGUg UlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmllZCBpbiBTZWN0aW9uIDQuMgogICBvZiBSRkMgMzU1 OCBbNl0gU0hBTEwgYmUgdXNlZC4gIFRoaXMgbWVkaWEgdHlwZSBTSEFMTCBOT1QgYmUgdXNlZCBm b3IKICAgc3RvcmFnZSBvciBmaWxlIHRyYW5zZmVyLCBpbnN0ZWFkIGF1ZGlvL0VWUkNOVyBTSEFM TCBiZSB1c2VkLgoKICAgQXV0aG9yOgoKICAgWmhlbmcgRmFuZyA8emZhbmdAcXVhbGNvbW0uY29t PgoKICAgQ2hhbmdlIGNvbnRyb2xsZXI6CgogICBJRVRGIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCB3 b3JraW5nIGdyb3VwIGRlbGVnYXRlZCBmcm9tIHRoZSBJRVNHLgoKOS4xLjMuICBSZWdpc3RyYXRp b24gb2YgTWVkaWEgVHlwZSBhdWRpby9FVlJDTlcxCgogICBUeXBlIG5hbWU6IGF1ZGlvCgogICBT dWJ0eXBlIG5hbWVzOiBFVlJDTlcxCgogICBSZXF1aXJlZCBwYXJhbWV0ZXJzOiBOb25lCgogICBP cHRpb25hbCBwYXJhbWV0ZXJzOgoKICAgVGhlc2UgcGFyYW1ldGVycyBhcHBseSB0byBSVFAgdHJh bnNmZXIgb25seS4KCiAgIG1vZGUtc2V0LXJlY3Y6IEEgc3Vic2V0IG9mIEVWUkMtTlcgbW9kZXMu ICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgY29tbWEgc2VwYXJhdGVkIGxpc3Qgb2YgbW9kZXMg ZnJvbSB0aGUgc2V0IHswLDF9IChzZWUgVGFibGUgMi42LjEuMi00CiAgIGluIDNHUFAyIEMuUzAw MTQtRCkuICBBIGRlY29kZXIgY2FuIHVzZSB0aGlzIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4KICAg ZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5jZSB0byBvcGVyYXRlIGluIGEgc3BlY2lmaWVkIHN1YnNl dCBvZiBtb2Rlcy4KICAgQSB2YWx1ZSBvZiAwIHNpZ25hbHMgdGhlIHN1cHBvcnQgZm9yIHdpZGVi YW5kIGZpeGVkIHJhdGUgKGZ1bGwgb3IKCgoKRmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBp cmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgW1BhZ2UgMTRdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAy MDExCgoKICAgaGFsZiByYXRlLCBkZXBlbmRpbmcgb24gdGhlIHZhbHVlIG9mICdmaXhlZHJhdGUn IHBhcmFtZXRlcikuICBBIHZhbHVlCiAgIG9mIDEgc2lnbmFscyBuYXJyb2JhbmQgZml4ZWQgcmF0 ZSAoZnVsbCBvciBoYWxmIHJhdGUsIGRlcGVuZGluZyBvbgogICB0aGUgdmFsdWUgb2YgJ2ZpeGVk cmF0ZScgcGFyYW1ldGVyKS4gIEFic2VuY2Ugb2YgdGhpcyBwYXJhbWV0ZXIKICAgc2lnbmFscyB0 aGUgbW9kZSAxLgoKICAgcHRpbWU6IHNlZSBSRkMgNDU2Ni4KCiAgIG1heHB0aW1lOiBzZWUgUkZD IDQ1NjYuCgogICBmaXhlZHJhdGU6IEluZGljYXRlcyB0aGUgRVZSQy1OVyByYXRlIG9mIHRoZSBz ZXNzaW9uIHdoaWxlIGluIHNpbmdsZQogICByYXRlIG9wZXJhdGlvbi4gIFZhbGlkIHZhbHVlcyBp bmNsdWRlOiAwLjUgYW5kIDEsIHdoZXJlIGEgdmFsdWUgb2YKICAgMC41IGluZGljYXRlcyB0aGUg MS8yIHJhdGUgd2hpbGUgYSB2YWx1ZSBvZiAxIGluZGljYXRlcyB0aGUgZnVsbAogICByYXRlLiAg SWYgdGhpcyBwYXJhbWV0ZXIgaXMgbm90IHByZXNlbnQsIDEvMiByYXRlIGlzIGFzc3VtZWQuCgog ICBzaWxlbmNlc3VwcDogc2VlIFNlY3Rpb24gNi4xIGluIFJGQyA0Nzg4LgoKICAgZHR4bWF4OiBz ZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCgogICBkdHhtaW46IHNlZSBTZWN0aW9uIDYuMSBp biBSRkMgNDc4OC4KCiAgIGhhbmdvdmVyOiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCgog ICBFbmNvZGluZyBjb25zaWRlcmF0aW9uczoKCiAgIFRoaXMgbWVkaWEgdHlwZSBpcyBmcmFtZWQg YmluYXJ5IGRhdGEgKHNlZSBSRkMgNDI4OCwgU2VjdGlvbiA0LjgpIGFuZAogICBpcyBkZWZpbmVk IGZvciB0cmFuc2ZlciBvZiBFVlJDLU5XIGVuY29kZWQgZGF0YSB2aWEgUlRQIHVzaW5nIHRoZQog ICBDb21wYWN0IEJ1bmRsZWQgcGFja2V0IGZvcm1hdCBzcGVjaWZpZWQgaW4gUkZDIDQ3ODguCgog ICBTZWN1cml0eSBjb25zaWRlcmF0aW9uczogU2VlIFNlY3Rpb24gMTUKCiAgIEludGVyb3BlcmFi aWxpdHkgY29uc2lkZXJ0YWlvbnM6IE5vbmUKCiAgIFB1Ymxpc2hlZCBzcGVjaWZpY2F0aW9uOgoK ICAgVGhlIEVWUkMtTlcgdm9jb2RlciBpcyBzcGVjaWZpZWQgaW4gM0dQUDIgQy5TMDAxNC1ELiAg VGhlIHRyYW5zZmVyCiAgIG1ldGhvZCB3aXRoIHRoZSBDb21wYWN0IEJ1bmRsZWQgcGFja2V0IGZv cm1hdCB2aWEgUlRQIGlzIHNwZWNpZmllZCBpbgogICBSRkMgNDc4OC4KCiAgIEFwcGxpY2F0aW9u cyB0aGF0IHVzZSB0aGlzIG1lZGlhIHR5cGU6CgogICBJdCBpcyBleHBlY3RlZCB0aGF0IG1hbnkg Vm9JUCBhcHBsaWNhdGlvbnMgKGFzIHdlbGwgYXMgbW9iaWxlCiAgIGFwcGxpY2F0aW9ucykgd2ls bCB1c2UgdGhpcyB0eXBlLgoKICAgQWRkaXRpb25hbCBpbmZvcm1hdGlvbjogTm9uZQoKICAgUGVy c29uICYgZW1haWwgYWRkcmVzcyB0byBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOgoK ICAgWmhlbmcgRmFuZyA8emZhbmdAcXVhbGNvbW0uY29tPgoKCgpGYW5nICAgICAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgQXByaWwgNSwgMjAxMiAgICAgICAgICAgICAgICBbUGFnZSAxNV0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgIEVWUkMtTlcgUlRQIHBheWxvYWQgZm9ybWF0ICAgICAgICAg ICBPY3RvYmVyIDIwMTEKCgogICBJbnRlbmRlZCB1c2FnZTogQ09NTU9OCgogICBSZXN0cmljdGlv bnMgb24gdXNhZ2U6CgogICBUaGlzIG1lZGlhIHR5cGUgZGVwZW5kcyBvbiBSVFAgZnJhbWluZywg YW5kIGhlbmNlIGlzIG9ubHkgZGVmaW5lZCBmb3IKICAgdHJhbnNmZXIgdmlhIFJUUCBbNV0sIHRo ZSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWVkIGluIFNlY3Rpb24gNAogICBvZiBSRkMgNDc4 OCBTSEFMTCBiZSB1c2VkLiAgVGhpcyBtZWRpYSB0eXBlIFNIQUxMIE5PVCBiZSB1c2VkIGZvcgog ICBzdG9yYWdlIG9yIGZpbGUgdHJhbnNmZXIsIGluc3RlYWQgYXVkaW8vRVZSQ05XIFNIQUxMIGJl IHVzZWQuCgogICBBdXRob3I6CgogICBaaGVuZyBGYW5nIDx6ZmFuZ0BxdWFsY29tbS5jb20+Cgog ICBDaGFuZ2UgY29udHJvbGxlcjoKCiAgIElFVEYgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IHdvcmtp bmcgZ3JvdXAgZGVsZWdhdGVkIGZyb20gdGhlIElFU0cuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKRmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIw MTIgICAgICAgICAgICAgICAgW1BhZ2UgMTZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJD LU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKMTAuICBTRFAg bW9kZSBhdHRyaWJ1dGVzIGZvciBFVlJDLU5XCgogICAnbW9kZS1zZXQtcmVjdicgY2FuIGJlIHVz ZWQgYnkgYSBkZWNvZGVyIHRvIGluZm9ybSBhbiBlbmNvZGVyIG9mIGl0cwogICBwcmVmZXJlbmNl IHRvIG9wZXJhdGUgaW4gYSBzcGVjaWZpZWQgc3Vic2V0IG9mIG1vZGVzLiAgTm90ZSB0aGF0CiAg IGluZGljYXRpbmcgYSBwcmVmZXJlbmNlLCBpbXBsaWNpdGx5IGluZGljYXRlcyBzdXBwb3J0IGZv ciB0aGF0CiAgIGNhcGFiaWxpdHkuICBDb252ZXJzZWx5LCBpZiBtb2RlIDAgaXMgbm90IHByZWZl cnJlZCwgdGhlbiB0aGVyZSBpcyBubwogICBpbmRpY2F0aW9uIHRoYXQgbW9kZSAwIGlzIHN1cHBv cnRlZC4KCiAgIDEuICBUbyBpbmZvcm0gdGhlIGNhcGFiaWxpdHkgb2Ygd2lkZWJhbmQgbW9kZSBz dXBwb3J0OiBBIGRlY29kZXIgY2FuCiAgICAgICBhbHdheXMgZGVjb2RlIGFsbCB0aGUgbmFycm93 YmFuZCBtb2RlcyAobW9kZXMgMSB0byA3KS4gIFVubGVzcwogICAgICAgdGhlIGRlY29kZXIgaW5k aWNhdGVzIHRoZSBzdXBwb3J0IG9mIG1vZGUgMCAoaS5lLiwgcHJlZmVyZW5jZSkgaW4KICAgICAg IHRoaXMgcGFyYW1ldGVyIG9yIGluIHRoZSBNTU0gbW9kZSByZXF1ZXN0IGZpZWxkIGluIGludGVy bGVhdmVkLwogICAgICAgYnVuZGxlZCBwYXlsb2FkIGZvcm1hdCwgYW4gZW5jb2RlciBhdCB0aGUg b3RoZXIgc2lkZSBzaGFsbCBub3QKICAgICAgIG9wZXJhdGUgaW4gbW9kZSAwLgoKICAgMi4gIFRv IGluZm9ybSB0aGUgcHJlZmVyZW5jZSB0byBvcGVyYXRlIGluIGEgc3Vic2V0IG9mIG1vZGVzOiBB IHNldAogICAgICAgaGFzIGJlZW4gZGVmaW5lZCBzbyB0aGF0IHNldmVyYWwgbW9kZXMgY2FuIGJl IGV4cHJlc3NlZCBhcyBhCiAgICAgICBwcmVmZXJlbmNlIGluIG9uZSBhdHRlbXB0LiAgRm9yIGlu c3RhbmNlLCB0aGUgc2V0IHs0LDUsNiw3fQogICAgICAgc2lnbmFscyB0aGF0IHRoZSByZWNlaXZl ciBwZXJmZXJzIHRoZSBzZW5kZXIgdG8gb3BlcmF0ZSBpbgogICAgICAgYmFuZHdpZHRoLWVmZmlj aWVudCBuYXJyb3diYW5kIG1vZGVzIG9mIEVWUkMtTlcuCgogICBOb3RlLCBkdXJpbmcgYW4gYWN0 aXZlIGNhbGwgc2Vzc2lvbiB1c2luZyB0aGUgaW50ZXJsZWF2ZWQvYnVuZGxlZAogICBwYWNrZXQg Zm9ybWF0LCB0aGUgTU1NIG1vZGUgcmVxdWVzdCByZWNlaXZlZCBmcm9tIGEgY29tbXVuaWNhdGlv bgogICBwYXJ0bmVyIGNvbXBsZW1lbnRzIHRoZSBtb2RlIHNldCBpbmZvcm1hdGlvbiBpbiBtb2Rl LXNldC1yZWN2LiAgQQogICBtb2RlIHJlcXVlc3Qgd2l0aCBNTU09MCBmcm9tIGEgY29tbXVuaWNh dGlvbiBwYXJ0bmVyIGlzIGFuIGltcGxpY2l0CiAgIGluZGljYXRpb24gb2YgdGhlIHBhcnRuZXIn cyBFVlJDTlcgd2lkZWJhbmQgZGVjb2RpbmcgY2FwYWJpbGl0eSBhbmQKICAgcHJlZmVyZW5jZS4g IEFuIEVWUkNOVyB3aWRlYmFuZCBjYXBhYmxlIG5vZGUgcmVjZWl2aW5nIHRoZSByZXF1ZXN0CiAg IGNhbiBvcGVyYXRlIGluIHdpZGViYW5kIG1vZGUuICBBIG1vZGUgcmVxdWVzdCB3aXRoIE1NTT0x LCAyLCAuLi4sIG9yCiAgIDcgZnJvbSBhIGNvbW11bmljYXRpb24gcGFydG5lciBpcyBhbiBpbXBs aWNpdCBpbmRpY2F0aW9uIG9mIHRoZQogICBwYXJ0bmVyJ3MgRVZSQ05XIG5hcnJvd2JhbmQgZGVj b2RpbmcgcHJlZmVyZW5jZS4gIFRoZSBlbmNvZGVyIG9mIGFuCiAgIEVWUkNOVyBub2RlIHJlY2Vp dmluZyB0aGUgcmVxdWVzdCBzaG91bGQgaG9ub3IgdGhlIHJlcXVlc3QgYW5kCiAgIG9wZXJhdGUg aW4gbmFycm93YmFuZCBtb2RlLgoKICAgJ3NlbmRtb2RlJyBpcyB1c2VkIGFzIGEgU0RQIG1vZGUg YXR0cmlidXRlIGluIEVWUkMgWzZdLCBFVlJDLUIgWzJdCiAgIGFuZCBFVlJDLVdCIFszXS4gIEhv d2V2ZXIgaXQgaXMgZGVwcmVjYXRlZCBpbiBFVlJDLU5XLgoKCgoKCgoKCgoKCgoKCgoKRmFuZyAg ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAg W1BhZ2UgMTddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZv cm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKMTEuICBNYXBwaW5nIEVWUkMtTlcgbWVkaWEg dHlwZSBwYXJhbWV0ZXJzIGludG8gU0RQCgogICBJbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSBt ZWRpYSB0eXBlIHNwZWNpZmljYXRpb24gaGFzIGEgc3BlY2lmaWMKICAgbWFwcGluZyB0byBmaWVs ZHMgaW4gdGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgWzEwXSwKICAgd2hp Y2ggaXMgY29tbW9ubHkgdXNlZCB0byBkZXNjcmliZSBSVFAgc2Vzc2lvbnMuICBXaGVuIFNEUCBp cyB1c2VkIHRvCiAgIHNwZWNpZnkgc2Vzc2lvbnMgZW1wbG95aW5nIEVWUkMtTlcgZW5jb2RlZCBz cGVlY2gsIHRoZSBtYXBwaW5nIGlzIGFzCiAgIGZvbGxvd3MuCgogICBvICBUaGUgbWVkaWEgdHlw ZSAoImF1ZGlvIikgZ29lcyBpbiBTRFAgIm09IiBhcyB0aGUgbWVkaWEgbmFtZS4KCiAgIG8gIFRo ZSBtZWRpYSBzdWJ0eXBlICgiRVZSQ05XIiwgIkVWUkNOVzAiIG9yICJFVlJDTlcxIikgZ29lcyBp biBTRFAKICAgICAgImE9cnRwbWFwIiBhcyB0aGUgZW5jb2RpbmcgbmFtZS4KCiAgIG8gIFRoZSBv cHRpb25hbCBwYXJhbWV0ZXJzICdwdGltZSBhbmQgJ21heHB0aW1lJyAoZm9yIHN1YnR5cGVzCiAg ICAgIEVWUkNOVywgRVZSQ05XMSkgZ28gaW4gdGhlIFNEUCAiYT1wdGltZSIgYW5kICJhPW1heHB0 aW1lIgogICAgICBhdHRyaWJ1dGVzLCByZXNwZWN0aXZlbHkuCgogICBvICBBbnkgcmVtYWluaW5n IHBhcmFtZXRlcnMgKGZvciBzdWJ0eXBlcyBFVlJDTlcsIEVWUkNOVzAgYW5kCiAgICAgIEVWUkNO VzEpIGdvIGluIHRoZSBTRFAgImE9Zm10cCIgYXR0cmlidXRlIGJ5IGNvcHlpbmcgdGhlbSBmcm9t IHRoZQogICAgICBtZWRpYSB0eXBlIHN0cmluZyBhcyBhIHNlbWljb2xvbiBzZXBhcmF0ZWQgbGlz dCBvZiBwYXJhbWV0ZXI9dmFsdWUKICAgICAgcGFpcnMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAg ICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZSQy1OVyBS VFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCjEyLiAgT2ZmZXItQW5z d2VyIE1vZGVsIENvbnNpZGVyYXRpb25zIGZvciBFVlJDLU5XCgogICBUaGUgZm9sbG93aW5nIGNv bnNpZGVyYXRpb25zIGFwcGx5IHdoZW4gdXNpbmcgdGhlIFNEUCBvZmZlci1hbnN3ZXIKICAgcHJv Y2VkdXJlcyBvZiBSRkMgMzI2NCBbMTJdIHRvIG5lZ290aWF0ZSB0aGUgdXNlIG9mIEVWUkMtTlcg cGF5bG9hZAogICBpbiBSVFA6CgogICBvICBTaW5jZSBFVlJDLU5XIGlzIGFuIGV4dGVuc2lvbiBv ZiBib3RoIEVWUkMtQiBhbmQgRVZSQy1XQiwgdGhlCiAgICAgIG9mZmVyZXIgU0hPVUxEIGFsc28g YW5ub3VuY2UgRVZSQy1CIGFuZCBFVlJDLVdCIHN1cHBvcnQgaW4gaXRzCiAgICAgICJtPWF1ZGlv IiBsaW5lcywgd2l0aCBFVlJDLU5XIGFzIHRoZSBwcmVmZXJyZWQgY29kZWMuICBUaGlzIHdpbGwK ICAgICAgYWxsb3cgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGFuIGFuc3dlcmVyIHdoaWNoIHN1cHBv cnRzIG9ubHkgRVZSQy1CCiAgICAgIGFuZC9vciBFVlJDLVdCLgoKICAgQmVsb3cgaXMgYW4gZXhh bXBsZSBvZiBzdWNoIGFuIG9mZmVyOgoKICAgICAgICAgIG09YXVkaW8gNTU5NTQgUlRQL0FWUCA5 OCA5OSAxMDAKICAgICAgICAgIGE9cnRwbWFwOjk4IEVWUkNOVzAvMTYwMDAKICAgICAgICAgIGE9 cnRwbWFwOjk5IEVWUkNXQjAvMTYwMDAKICAgICAgICAgIGE9cnRwbWFwOjEwMCBFVlJDQjAvODAw MAogICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0LDUsNgogICAgICAg ICAgYT1mbXRwOjk5IG1vZGUtc2V0LXJlY3Y9MCw0CiAgICAgICAgICBhPWZtdHA6MTAwIHJlY3Zt b2RlPTAKCgogICBJZiB0aGUgYW5zd2VyZXIgc3VwcG9ydHMgRVZSQy1OVyB0aGVuIHRoZSBhbnN3 ZXJlciBjYW4ga2VlcCB0aGUKICAgcGF5bG9hZCB0eXBlIDk4IGluIGl0cyBhbnN3ZXIgYW5kIHRo ZSBjb252ZXJzYXRpb24gY2FuIGJlIGRvbmUgdXNpbmcKICAgRVZSQy1OVy4gIEVsc2UsIGlmIHRo ZSBhbnN3ZXJlciBzdXBwb3J0cyBvbmx5IEVWUkMtV0IgYW5kL29yIEVWUkMtQgogICB0aGVuIHRo ZSBhbnN3ZXJlciB3aWxsIGxlYXZlIG9ubHkgdGhlIHBheWxvYWQgdHlwZSA5OSBhbmQvb3IgMTAw CiAgIHJlc3BlY3RpdmVseSBpbiBpdHMgYW5zd2VyIGFuZCB0aGUgY29udmVyc2F0aW9uIHdpbGwg YmUgZG9uZSB1c2luZwogICBFVlJDLVdCIGFuZC9vciBFVlJDLUIgcmVzcGVjdGl2ZWx5LgoKICAg QW4gZXhhbXBsZSBhbnN3ZXIgZm9yIHRoZSBhYm92ZSBvZmZlcjoKCiAgICAgICAgICBtPWF1ZGlv IDU1OTU0IFJUUC9BVlAgOTgKICAgICAgICAgIGE9cnRwbWFwOjk4IEVWUkNOVzAvMTYwMDAKICAg ICAgICAgIGE9Zm10cDo5OCBtb2RlLXNldC1yZWN2PTQKCgogICBvICAnbW9kZS1zZXQtcmVjdicg aXMgYSB1bmktZGlyZWN0aW9uYWwgcmVjZWl2ZSBvbmx5IHBhcmFtZXRlci4KCiAgIG8gIEFuIG9m ZmVyZXIgY2FuIHVzZSAnbW9kZS1zZXQtcmVjdicgdG8gcmVxdWVzdCB0aGF0IHRoZSByZW1vdGUK ICAgICAgc2VuZGVyJ3MgZW5jb2RlciBiZSBsaW1pdGVkIHRvIHRoZSBsaXN0IG9mIG1vZGVzIHNp Z25hbGVkIGluCiAgICAgICdtb2RlLXNldC1yZWN2Jy4gIEEgcmVtb3RlIHNlbmRlciBNQVkgaWdu b3JlICdtb2RlLXNldC1yZWN2JwogICAgICByZXF1ZXN0cy4gIEhvd2V2ZXIsIGEgcmVtb3RlIHNl bmRlciBzaGFsbCBub3QgYXNzdW1lIHRoZSBvdGhlcgogICAgICBzaWRlIGNhbiBzdXBwb3J0IG1v ZGUgMCwgdW5sZXNzIHRoZSBvZmZlciBpbmNsdWRlcyBtb2RlIDAKICAgICAgZXhwbGljaXRseSBp biAnbW9kZS1zZXQtcmVjdicuCgogICBvICBUaGUgcGFyYW1ldGVycyAnbWF4cHRpbWUnIGFuZCAn cHRpbWUnIHdpbGwgaW4gbW9zdCBjYXNlcyBub3QKICAgICAgYWZmZWN0IGludGVyb3BlcmFiaWxp dHksIGhvd2V2ZXIgdGhlIHNldHRpbmcgb2YgdGhlIHBhcmFtZXRlcnMgY2FuCgoKCkZhbmcgICAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQ YWdlIDE5XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZSQy1OVyBSVFAgcGF5bG9hZCBmb3Jt YXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgICAgIGFmZmVjdCB0aGUgcGVyZm9ybWFuY2Ug b2YgdGhlIGFwcGxpY2F0aW9uLiAgVGhlIFNEUCBvZmZlci1hbnN3ZXIKICAgICAgaGFuZGxpbmcg b2YgdGhlICdwdGltZScgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBpbiBSRkMgMzI2NCBbMTJdLgog ICAgICBUaGUgJ21heHB0aW1lJyBwYXJhbWV0ZXIgTVVTVCBiZSBoYW5kbGVkIGluIHRoZSBzYW1l IHdheS4KCiAgIG8gIEZvciBhIHNlbmRvbmx5IHN0cmVhbSwgdGhlICdtb2RlLXNldC1yZWN2JyBw YXJhbWV0ZXIgaXMgbm90IHVzZWZ1bAogICAgICBhbmQgU0hPVUxEIE5PVCBiZSB1c2VkLgoKICAg byAgV2hlbiB1c2luZyBFVlJDTlcxLCB0aGUgZW50aXJlIHNlc3Npb24gTVVTVCB1c2UgdGhlIHNh bWUgZml4ZWQKICAgICAgcmF0ZSBhbmQgbW9kZSAoMC1XaWRlYmFuZCBvciAxLU5hcnJvd2JhbmQp LgoKICAgbyAgRm9yIGFkZGl0aW9uYWwgcnVsZXMgd2hpY2ggTVVTVCBiZSBmb2xsb3dlZCB3aGls ZSBuZWdvdGlhdGluZyBEVFgKICAgICAgcGFyYW1ldGVycywgc2VlIFNlY3Rpb24gNi44IGluIFJG QyA0Nzg4IFsyXS4KCiAgIG8gIEFueSB1bmtub3duIHBhcmFtZXRlciBpbiBhbiBTRFAgb2ZmZXIg TVVTVCBiZSBpZ25vcmVkIGJ5IHRoZQogICAgICByZWNlaXZlciBhbmQgTVVTVCBOT1QgYmUgaW5j bHVkZWQgaW4gdGhlIFNEUCBhbnN3ZXIuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAgICAg ICAgICAgICAgIFtQYWdlIDIwXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZSQy1OVyBSVFAg cGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCjEzLiAgRGVjbGFyYXRpdmUg U0RQIENvbnNpZGVyYXRpb25zCgogICBGb3IgZGVjbGFyYXRpdmUgdXNlIG9mIFNEUCBpbiBTQVAg WzEzXSBhbmQgUlRTUCBbMTRdLCB0aGUgZm9sbG93aW5nCiAgIGNvbnNpZGVyYXRpb25zIGFwcGx5 OgoKICAgbyAgQW55ICdtYXhwdGltZScgYW5kICdwdGltZScgdmFsdWVzIHNob3VsZCBiZSBzZWxl Y3RlZCB3aXRoIGNhcmUgdG8KICAgICAgZW5zdXJlIHRoYXQgdGhlIHNlc3Npb24ncyBwYXJ0aWNp cGFudHMgY2FuIGFjaGlldmUgcmVhc29uYWJsZQogICAgICBwZXJmb3JtYW5jZS4KCiAgIG8gIFRo ZSBwYXlsb2FkIGZvcm1hdCBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgYXJlIGFsbCBkZWNsYXJh dGl2ZQogICAgICBhbmQgYSBwYXJ0aWNpcGFudCBNVVNUIHVzZSB0aGUgY29uZmlndXJhdGlvbihz KSB0aGF0IGlzIHByb3ZpZGVkCiAgICAgIGZvciB0aGUgc2Vzc2lvbi4gIE1vcmUgdGhhbiBvbmUg Y29uZmlndXJhdGlvbiBtYXkgYmUgcHJvdmlkZWQgaWYKICAgICAgbmVjZXNzYXJ5IGJ5IGRlY2xh cmluZyBtdWx0aXBsZSBSVFAgcGF5bG9hZCB0eXBlcywgaG93ZXZlciB0aGUKICAgICAgbnVtYmVy IG9mIHR5cGVzIHNob3VsZCBiZSBrZXB0IHNtYWxsLiAgRm9yIGRlY2xhcmF0aXZlIGV4YW1wbGVz LAogICAgICBzZWUgU2VjdGlvbiAxNC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKRmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAg ICAgICAgICAgW1BhZ2UgMjFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBw YXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKMTQuICBFeGFtcGxlcwoKICAg U29tZSBleGFtcGxlIFNEUCBzZXNzaW9uIGRlc2NyaXB0aW9ucyB1dGlsaXppbmcgRVZSQy1OVyBl bmNvZGluZ3MKICAgZm9sbG93LiAgSW4gdGhlc2UgZXhhbXBsZXMsIGxvbmcgYT1mbXRwIGxpbmVz IGFyZSBmb2xkZWQgdG8gbWVldCB0aGUKICAgY29sdW1uIHdpZHRoIGNvbnN0cmFpbnRzIG9mIHRo aXMgZG9jdW1lbnQuICBUaGUgYmFja3NsYXNoICgiXCIpIGF0CiAgIHRoZSBlbmQgb2YgYSBsaW5l IGFuZCB0aGUgY2FycmlhZ2UgcmV0dXJuIHRoYXQgZm9sbG93cyBpdCBzaG91bGQgYmUKICAgaWdu b3JlZC4gIE5vdGUgdGhhdCBtZWRpYSBzdWJ0eXBlIG5hbWVzIGFyZSBjYXNlLWluc2Vuc2l0aXZl LgogICBQYXJhbWV0ZXIgbmFtZXMgYXJlIGNhc2UtaW5zZW5zaXRpdmUgYm90aCBpbiBtZWRpYSB0 eXBlcyBhbmQgaW4gdGhlCiAgIG1hcHBpbmcgdG8gdGhlIFNEUCBhPWZtdHAgYXR0cmlidXRlLgoK ICAgRXhhbXBsZSB1c2FnZSBvZiBFVlJDTlcgaWYgd2lkZWJhbmQgbW9kZSBpcyBzdXBwb3J0ZWQ6 CgogICAgICAgICAgbT1hdWRpbyA0OTEyMCBSVFAvQVZQIDk3IDk4IDk5CiAgICAgICAgICBhPXJ0 cG1hcDo5NyBFVlJDTlcvMTYwMDAKICAgICAgICAgIGE9cnRwbWFwOjk4IEVWUkNXQi8xNjAwMAog ICAgICAgICAgYT1ydHBtYXA6OTkgRVZSQ0IvODAwMAogICAgICAgICAgYT1mbXRwOjk3IG1vZGUt c2V0LXJlY3Y9MCwxLDIsMyw0LDUsNgogICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9 MCw0CiAgICAgICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MAogICAgICAgICAgYT1tYXhwdGltZTox MjAKCiAgIEV4YW1wbGUgdXNhZ2Ugb2YgRVZSQ05XIGlmIHdpZGViYW5kIG1vZGUgaXMgbm90IHN1 cHBvcnRlZDoKCiAgICAgICAgICBtPWF1ZGlvIDQ5MTIwIFJUUC9BVlAgOTcgOTggOTkKICAgICAg ICAgIGE9cnRwbWFwOjk3IEVWUkNOVy8xNjAwMAogICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dC LzE2MDAwCiAgICAgICAgICBhPXJ0cG1hcDo5OSBFVlJDQi84MDAwCiAgICAgICAgICBhPWZtdHA6 OTcgbW9kZS1zZXQtcmVjdj0xLDIsMyw0LDUsNgogICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0 LXJlY3Y9NAogICAgICAgICAgYT1mbXRwOjk5IHJlY3Ztb2RlPTAKICAgICAgICAgIGE9bWF4cHRp bWU6MTIwCgogICBFeGFtcGxlIHVzYWdlIG9mIEVWUkNOVzA6CgogICAgICAgICAgbT1hdWRpbyA0 OTEyMCBSVFAvQVZQIDk3IDk4IDk5CiAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcwLzE2MDAw CiAgICAgICAgICBhPXJ0cG1hcDo5OCBFVlJDV0IwLzE2MDAwCiAgICAgICAgICBhPXJ0cG1hcDo5 OSBFVlJDQjAvODAwMAogICAgICAgICAgYT1mbXRwOjk3IG1vZGUtc2V0LXJlY3Y9MCwxLDIsMyw0 LDUsNgogICAgICAgICAgYT1mbXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCw0CiAgICAgICAgICBhPWZt dHA6OTkgcmVjdm1vZGU9MAoKICAgRXhhbXBsZSBTRFAgYW5zd2VyIGZyb20gYSBtZWRpYSBnYXRl d2F5IHJlcXVlc3RpbmcgYSB0ZXJtaW5hbCB0bwogICBsaW1pdCBpdHMgZW5jb2RlciBvcGVyYXRp b24gdG8gRVZSQy1OVyBtb2RlIDQuCgogICAgICAgICAgbT1hdWRpbyA0OTEyMCBSVFAvQVZQIDk3 CiAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcwLzE2MDAwCiAgICAgICAgICBhPWZtdHA6OTcg bW9kZS1zZXQtcmVjdj00CgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJp bCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDIyXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgRVZSQy1OVyBSVFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAg IEV4YW1wbGUgdXNhZ2Ugb2YgRVZSQ05XMToKCiAgICAgICAgICBtPWF1ZGlvIDQ5MTIwIFJUUC9B VlAgOTcgOTggOTkKICAgICAgICAgIGE9cnRwbWFwOjk3IEVWUkNOVzEvMTYwMDAKICAgICAgICAg IGE9cnRwbWFwOjk4IEVWUkNXQjEvMTYwMDAKICAgICAgICAgIGE9cnRwbWFwOjk5IEVWUkNCMS84 MDAwCiAgICAgICAgICBhPWZtdHA6OTcgZml4ZWRyYXRlPTAuNQogICAgICAgICAgYT1mbXRwOjk4 IGZpeGVkcmF0ZT0wLjUKICAgICAgICAgIGE9Zm10cDo5OSBmaXhlZHJhdGU9MC41CiAgICAgICAg ICBhPW1heHB0aW1lOjEwMAoKICAgRXhhbXBsZSB1c2FnZSBvZiBFVlJDTlcgd2l0aCBEVFggd2l0 aCBzaWxlbmNlc3VwcD0xOgoKICAgICAgICAgIG09YXVkaW8gNDkxMjAgUlRQL0FWUCA5NyA5OCA5 OQogICAgICAgICAgYT1ydHBtYXA6OTcgRVZSQ05XLzE2MDAwCiAgICAgICAgICBhPXJ0cG1hcDo5 OCBFVlJDV0IvMTYwMDAKICAgICAgICAgIGE9cnRwbWFwOjk5IEVWUkNCLzgwMDAKICAgICAgICAg IGE9Zm10cDo5NyBzaWxlbmNlc3VwcD0xO2R0eG1heD0zMjtkdHhtaW49MTI7aGFuZ292ZXI9MTsg XAogICAgICAgICAgbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2CiAgICAgICAgICBhPWZtdHA6 OTggc2lsZW5jZXN1cHA9MTtkdHhtYXg9MzI7ZHR4bWluPTEyO2hhbmdvdmVyPTE7IFwKICAgICAg ICAgIG1vZGUtc2V0LXJlY3Y9MCw0CiAgICAgICAgICBhPWZtdHA6OTkgcmVjdm1vZGU9MAogICAg ICAgICAgYT1tYXhwdGltZToxMjAKCiAgIEV4YW1wbGVzIHVzYWdlIG9mIEVWUkNOVyB3aXRoIERU WCB3aXRoIHNpbGVuY2VzdXBwPTA6CgogICAgICAgICAgbT1hdWRpbyA0OTEyMCBSVFAvQVZQIDk3 IDk4IDk5CiAgICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcvMTYwMDAKICAgICAgICAgIGE9cnRw bWFwOjk4IEVWUkNXQi8xNjAwMAogICAgICAgICAgYT1ydHBtYXA6OTkgRVZSQ0IvODAwMAogICAg ICAgICAgYT1mbXRwOjk3IHNpbGVuY2VzdXBwPTA7ZHR4bWF4PTMyO2R0eG1pbj0xMjtoYW5nb3Zl cj0xOyBcCiAgICAgICAgICBtb2RlLXNldC1yZWN2PTAsMSwyLDMsNCw1LDYKICAgICAgICAgIGE9 Zm10cDo5OCBzaWxlbmNlc3VwcD0wO2R0eG1heD0zMjtkdHhtaW49MTI7aGFuZ292ZXI9MTsgXAog ICAgICAgICAgbW9kZS1zZXQtcmVjdj0wLDQKICAgICAgICAgIGE9Zm10cDo5OSByZWN2bW9kZT0w CiAgICAgICAgICBhPW1heHB0aW1lOjEyMAoKICAgRXhhbXBsZSBvZmZlciBhbnN3ZXIgZXhjaGFu Z2UgYmV0d2VlbiBFVlJDLU5XIGFuZCBsZWdhY3kgRVZSQy1CIChSRkMKICAgNDc4OCk6CgoKCgoK CgoKCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCA1LCAyMDEyICAg ICAgICAgICAgICAgIFtQYWdlIDIzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgRVZSQy1OVyBS VFAgcGF5bG9hZCBmb3JtYXQgICAgICAgICAgIE9jdG9iZXIgMjAxMQoKCiAgICAgICAgIE9mZmVy OgoKICAgICAgICAgICBtPWF1ZGlvIDU1OTU0IFJUUC9BVlAgOTcgOTggOTkKICAgICAgICAgICBh PXJ0cG1hcDo5NyBFVlJDTlcwLzE2MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dCMC8x NjAwMAogICAgICAgICAgIGE9cnRwbWFwOjk5IEVWUkNCMC84MDAwCiAgICAgICAgICAgYT1ydHBt YXA6OTcgbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2CiAgICAgICAgICAgYT1mbXRwOjk4IG1v ZGUtc2V0LXJlY3Y9MCw0CiAgICAgICAgICAgYT1mbXRwOjk5IHJlY3Ztb2RlPTAKCiAgICAgICAg IEFuc3dlcjoKCiAgICAgICAgICAgbT1hdWRpbyA1NTk1NCBSVFAvQVZQIDk5CiAgICAgICAgICAg YT1ydHBtYXA6OTkgRVZSQ0IwLzgwMDAKCiAgIEV4YW1wbGUgb2ZmZXIgYW5zd2VyIGV4Y2hhbmdl IGJldHdlZW4gRVZSQy1OVyBhbmQgbGVnYWN5IEVWUkMtV0IgKFJGQwogICA1MTg4KToKCiAgICAg ICAgIE9mZmVyOgoKICAgICAgICAgICBtPWF1ZGlvIDU1OTU0IFJUUC9BVlAgOTcgOTggOTkKICAg ICAgICAgICBhPXJ0cG1hcDo5NyBFVlJDTlcwLzE2MDAwCiAgICAgICAgICAgYT1ydHBtYXA6OTgg RVZSQ1dCMC8xNjAwMAogICAgICAgICAgIGE9cnRwbWFwOjk5IEVWUkNCMC84MDAwCiAgICAgICAg ICAgYT1ydHBtYXA6OTcgbW9kZS1zZXQtcmVjdj0wLDEsMiwzLDQsNSw2CiAgICAgICAgICAgYT1m bXRwOjk4IG1vZGUtc2V0LXJlY3Y9MCw0CiAgICAgICAgICAgYT1mbXRwOjk5IHJlY3Ztb2RlPTAK CiAgICAgICAgIEFuc3dlcjoKCiAgICAgICAgICAgbT1hdWRpbyA1NTk1NCBSVFAvQVZQIDk4IDk5 CiAgICAgICAgICAgYT1ydHBtYXA6OTggRVZSQ1dCMC8xNjAwMAoKCgoKCgoKCgoKCgoKCgoKCgoK RmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAg ICAgICAgW1BhZ2UgMjRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXls b2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKMTUuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucwoKICAgU2luY2UgY29tcHJlc3Npb24gaXMgYXBwbGllZCB0byB0aGUgcGF5bG9hZCBm b3JtYXRzIGVuZC10by1lbmQsIGFuZAogICB0aGUgZW5jb2RpbmdzIGRvIG5vdCBleGhpYml0IHNp Z25pZmljYW50IG5vbi11bmlmb3JtaXR5LAogICBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBzcGVj aWZpY2F0aW9uIGFyZSBzdWJqZWN0IHRvIGFsbCB0aGUgc2VjdXJpdHkKICAgY29uc2lkZXJhdGlv bnMgc3BlY2lmaWVkIGluIFJGQyAzNTU4IFs2XS4gIEltcGxlbWVudGF0aW9ucyB1c2luZyB0aGUK ICAgcGF5bG9hZCBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBhcmUgc3ViamVjdCB0byB0 aGUgc2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMgZGlzY3Vzc2VkIGluIFJGQyAzNTU4IFs2XSwg UkZDIDM1NTAgWzVdIGFuZCBhbnkKICAgYXBwcm9wcmlhdGUgcHJvZmlsZSAoZm9yIGV4YW1wbGUg UkZDIDM1NTEgWzddKS4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK RmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAg ICAgICAgW1BhZ2UgMjVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXls b2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKMTYuICBSZWZlcmVuY2VzCgoxNi4x LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFsxXSAgIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRz IGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudAogICAgICAgICBMZXZlbHMi LCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoKICAgWzJdICAgWGllLCBRLiBhbmQgUi4g S2Fwb29yLCAiRW5oYW5jZW1lbnRzIHRvIFJUUCBQYXlsb2FkIEZvcm1hdHMgZm9yCiAgICAgICAg IEVWUkMgRmFtaWx5IENvZGVjcyIsIFJGQyA0Nzg4LCBKYW51YXJ5IDIwMDcuCgogICBbM10gICBE ZXNpbmVuaSwgSC4gYW5kIFEuIFhpZSwgIlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgdGhlIEVuaGFu Y2VkCiAgICAgICAgIFZhcmlhYmxlIFJhdGUgV2lkZWJhbmQgQ29kZWMgKEVWUkMtV0IpIGFuZCB0 aGUgTWVkaWEgU3VidHlwZQogICAgICAgICBVcGRhdGVzIGZvciBFVlJDLUIgQ29kZWMiLCBSRkMg NTE4OCwgRmVicnVhcnkgMjAwOC4KCiAgIFs0XSAgICJFbmhhbmNlZCBWYXJpYWJsZSBSYXRlIENv ZGVjLCBTcGVlY2ggU2VydmljZSBPcHRpb25zIDMsIDY4LAogICAgICAgICA3MCwgYW5kIDczIGZv ciBXaWRlYmFuZCBTcHJlYWQgU3BlY3RydW0gRGlnaXRhbCBTeXN0ZW1zIiwKICAgICAgICAgM0dQ UDIgQy5TMDAxNC1EIHYxLjAsIE1heSAyMDA5LgoKICAgWzVdICAgU2NodWx6cmlubmUsIEguLCBD YXNuZXIsIFMuLCBGcmVkZXJpY2ssIFIuLCBhbmQgVi4gSmFjb2Jzb24sCiAgICAgICAgICJSVFA6 IEEgVHJhbnNwb3J0IFByb3RvY29sIGZvciBSZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgU1REIDY0 LAogICAgICAgICBSRkMgMzU1MCwgSnVseSAyMDAzLgoKICAgWzZdICAgTGksIEEuLCAiUlRQIFBh eWxvYWQgRm9ybWF0IGZvciBFbmhhbmNlZCBWYXJpYWJsZSBSYXRlIENvZGVjcwogICAgICAgICAo RVZSQykgYW5kIFNlbGVjdGFibGUgTW9kZSBWb2NvZGVycyAoU01WKSIsIFJGQyAzNTU4LAogICAg ICAgICBKdWx5IDIwMDMuCgogICBbN10gICBTY2h1bHpyaW5uZSwgSC4gYW5kIFMuIENhc25lciwg IlJUUCBQcm9maWxlIGZvciBBdWRpbyBhbmQgVmlkZW8KICAgICAgICAgQ29uZmVyZW5jZXMgd2l0 aCBNaW5pbWFsIENvbnRyb2wiLCBTVEQgNjUsIFJGQyAzNTUxLCBKdWx5IDIwMDMuCgogICBbOF0g ICBDYXNuZXIsIFMuLCAiTWVkaWEgVHlwZSBSZWdpc3RyYXRpb24gb2YgUlRQIFBheWxvYWQgRm9y bWF0cyIsCiAgICAgICAgIFJGQyA0ODU1LCBGZWJydWFyeSAyMDA3LgoKICAgWzldICAgRnJlZWQs IE4uIGFuZCBKLiBLbGVuc2luLCAiTWVkaWEgVHlwZSBTcGVjaWZpY2F0aW9ucyBhbmQKICAgICAg ICAgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMiLCBCQ1AgMTMsIFJGQyA0Mjg4LCBEZWNlbWJlciAy MDA1LgoKICAgWzEwXSAgSGFuZGxleSwgTS4sIEphY29ic29uLCBWLiwgYW5kIEMuIFBlcmtpbnMs ICJTRFA6IFNlc3Npb24KICAgICAgICAgRGVzY3JpcHRpb24gUHJvdG9jb2wiLCBSRkMgNDU2Niwg SnVseSAyMDA2LgoKICAgWzExXSAgR2FydWRhZHJpLCBILiwgIk1JTUUgVHlwZSBSZWdpc3RyYXRp b25zIGZvciAzR1BQMiBNdWx0aW1lZGlhCiAgICAgICAgIEZpbGVzIiwgUkZDIDQzOTMsIE1hcmNo IDIwMDYuCgogICBbMTJdICBSb3NlbmJlcmcsIEouIGFuZCBILiBTY2h1bHpyaW5uZSwgIkFuIE9m ZmVyL0Fuc3dlciBNb2RlbCB3aXRoCiAgICAgICAgIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9j b2wgKFNEUCkiLCBSRkMgMzI2NCwgSnVuZSAyMDAyLgoKMTYuMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMKCiAgIFsxM10gIEhhbmRsZXksIE0uLCBQZXJraW5zLCBDLiwgYW5kIEUuIFdoZWxhbiwg IlNlc3Npb24gQW5ub3VuY2VtZW50CiAgICAgICAgIFByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9i ZXIgMjAwMC4KCgoKRmFuZyAgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIw MTIgICAgICAgICAgICAgICAgW1BhZ2UgMjZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJD LU5XIFJUUCBwYXlsb2FkIGZvcm1hdCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKICAgWzE0XSAg U2NodWx6cmlubmUsIEguLCBSYW8sIEEuLCBhbmQgUi4gTGFucGhpZXIsICJSZWFsIFRpbWUgU3Ry ZWFtaW5nCiAgICAgICAgIFByb3RvY29sIChSVFNQKSIsIFJGQyAyMzI2LCBBcHJpbCAxOTk4LgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRmFuZyAgICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEFwcmlsIDUsIDIwMTIgICAgICAgICAgICAgICAgW1Bh Z2UgMjddCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBFVlJDLU5XIFJUUCBwYXlsb2FkIGZvcm1h dCAgICAgICAgICAgT2N0b2JlciAyMDExCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgWmhlbmcgRmFu ZwogICBRdWFsY29tbQogICA1Nzc1IE1vcmVob3VzZSBEcml2ZQogICBTYW4gRGllZ28sIENBICA5 MjEyNgogICBVU0EKCiAgIFBob25lOiArMSA4NTggNjUxIDk0ODQKICAgRW1haWw6IHpmYW5nQHF1 YWxjb21tLmNvbQogICBVUkk6ICAgaHR0cDovL3d3dy5xdWFsY29tbS5jb20KCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkZhbmcgICAgICAgICAgICAgICAgICAgICAgRXhw aXJlcyBBcHJpbCA1LCAyMDEyICAgICAgICAgICAgICAgIFtQYWdlIDI4XQoMCg== --_005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_ Content-Type: application/octet-stream; name="draft-ietf-avt-rtp-evrc-nw-03-update-a-from-03.diff" Content-Description: draft-ietf-avt-rtp-evrc-nw-03-update-a-from-03.diff Content-Disposition: attachment; filename="draft-ietf-avt-rtp-evrc-nw-03-update-a-from-03.diff"; size=19256; creation-date="Tue, 04 Oct 2011 00:42:53 GMT"; modification-date="Tue, 04 Oct 2011 00:33:34 GMT" Content-Transfer-Encoding: base64 LS0tIDEvZHJhZnQtaWV0Zi1hdnQtcnRwLWV2cmMtbnctMDMudHh0CTIwMTEtMTAtMDMgMTc6MzM6 MzQuMTI1NDAxMTY0IC0wNzAwCisrKyAyL2RyYWZ0LWlldGYtYXZ0LXJ0cC1ldnJjLW53LTAzLXVw ZGF0ZS1hLnR4dAkyMDExLTEwLTAzIDE3OjMzOjM0LjEzNTQwNTU2OCAtMDcwMApAQCAtMSwxOSAr MSwxOSBAQAogCiBOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFouIEZhbmcKIEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBRdWFsY29tbQotSW50ZW5kZWQgc3Rh dHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIzLCAy MDExCi1FeHBpcmVzOiBPY3RvYmVyIDI1LCAyMDExCitJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJk cyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDMsIDIwMTEKK0V4cGlyZXM6 IEFwcmlsIDUsIDIwMTIKIAogUlRQIHBheWxvYWQgZm9ybWF0IGZvciBFbmhhbmNlZCBWYXJpYWJs ZSBSYXRlIE5hcnJvd2JhbmQtV2lkZWJhbmQgQ29kZWMKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAoRVZSQy1OVykKLSAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtYXZ0LXJ0 cC1ldnJjLW53LTAzCisgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWF2dC1ydHAtZXZy Yy1udy0wNAogCiBBYnN0cmFjdAogCiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyByZWFsLXRp bWUgdHJhbnNwb3J0IHByb3RvY29sIChSVFApIHBheWxvYWQKICAgIGZvcm1hdHMgdG8gYmUgdXNl ZCBmb3IgdGhlIEVuaGFuY2VkIFZhcmlhYmxlIFJhdGUgTmFycm93YmFuZC1XaWRlYmFuZAogICAg Q29kZWMgKEVWUkMtTlcpLiAgVGhyZWUgbWVkaWEgdHlwZSByZWdpc3RyYXRpb25zIGFyZSBpbmNs dWRlZCBmb3IKICAgIEVWUkMtTlcgUlRQIHBheWxvYWQgZm9ybWF0cy4gIEluIGFkZGl0aW9uLCBh IGZpbGUgZm9ybWF0IGlzIHNwZWNpZmllZAogICAgZm9yIHRyYW5zcG9ydCBvZiBFVlJDLU5XIHNw ZWVjaCBkYXRhIGluIHN0b3JhZ2UgbW9kZSBhcHBsaWNhdGlvbnMKICAgIHN1Y2ggYXMgZS1tYWls LgogCkBAIC0yNSwyMSArMjUsMjEgQEAKICAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBk b2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgICBUYXNrIEZvcmNlIChJRVRG KS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRz L2N1cnJlbnQvLgogCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxp ZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVw bGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgICB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQog ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jl c3MuIgogCi0gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIE9jdG9iZXIgMjUs IDIwMTEuCisgICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDUsIDIw MTIuCiAKIENvcHlyaWdodCBOb3RpY2UKIAogICAgQ29weXJpZ2h0IChjKSAyMDExIElFVEYgVHJ1 c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgICBkb2N1bWVudCBhdXRob3Jz LiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KIAogICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRv IEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICAgUHJvdmlzaW9ucyBSZWxhdGlu ZyB0byBJRVRGIERvY3VtZW50cwogICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2Ut aW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKQEAgLTE1OSw0MCArMTU5LDQw IEBACiAgICBjYXJyaWVkIGluIHRoZSBwYWNrZXQgY29udGFpbnMgYSBzcGVlY2ggZnJhbWUgd2hp Y2ggaXMgdGhlIGZpcnN0IGluIGEKICAgIHRhbGtzcHVydC4gIEZvciBhbGwgb3RoZXIgcGFja2V0 cyB0aGUgbWFya2VyIGJpdCBTSEFMTCBiZSBzZXQgdG8gemVybwogICAgKE09MCkuCiAKIDYuICBQ YXlsb2FkIGZvcm1hdAogCiAgICBUaHJlZSBSVFAgcGFja2V0IGZvcm1hdHMgYXJlIHN1cHBvcnRl ZCBmb3IgdGhlIEVWUkMtTlcgY29kZWMgLSB0aGUKICAgIGludGVybGVhdmVkL2J1bmRsZWQgcGFj a2V0IGZvcm1hdCwgdGhlIGhlYWRlci1mcmVlIHBhY2tldCBmb3JtYXQgYW5kCiAgICB0aGUgY29t cGFjdCBidW5kbGVkIHBhY2tldCBmb3JtYXQuICBGb3IgYWxsIHRoZXNlIGZvcm1hdHMsIHRoZQog ICAgb3BlcmF0aW9uYWwgZGV0YWlscyBhbmQgY2FwYWJpbGl0aWVzLCBzdWNoIGFzIFRvQywgaW50 ZXJsZWF2aW5nLCBEVFgsCi0gICBhbmQgYnVuZGxpbmcsIG9mIEVWUkMtTlcgYXJlIGV4YWN0bHkg dGhlIHNhbWUgYXMgdGhvc2Ugb2YgRVZSQy1CIGFuZAotICAgRVZSQy1XQiwgYXMgZGVmaW5lZCBp biBbMl0gYW5kIFszXSwgZXhjZXB0IHRoYXQKKyAgIGFuZCBidW5kbGluZywgb2YgRVZSQy1OVyBh cmUgZXhhY3RseSB0aGUgc2FtZSBhcyB0aG9zZSBkZWZpbmVkIGluCisgICBFVlJDIFs2XSwgRVZS Qy1CIFsyXSBhbmQgRVZSQy1XQiBbM10sIGV4Y2VwdCB0aGF0CiAKICAgIDEuICB0aGUgbW9kZSBj aGFuZ2UgcmVxdWVzdCBmaWVsZCBpbiB0aGUgaW50ZXJsZWF2ZWQvYnVuZGxlZCBwYWNrZXQKICAg ICAgICBmb3JtYXQgTVVTVCBiZSBpbnRlcnByZXRlZCBhY2NvcmRpbmcgdG8gdGhlIGRlZmluaXRp b24gb2YgdGhlCiAgICAgICAgUkFURV9SRURVQyBwYXJhbWV0ZXIgYXMgZGVmaW5lZCBpbiBFVlJD LU5XIFs0XS4KIAogICAgMi4gIHRoZSBtb2RlIGNoYW5nZSByZXF1ZXN0IGZpZWxkIGluIHRoZSBp bnRlcmxlYXZlZC9idW5kbGVkIHBhY2tldAogICAgICAgIGZvcm1hdCBTSE9VTEQgYmUgaG9ub3Jl ZCBieSBhbiBFVlJDTlcgZW5jb2RpbmcgZW5kIHBvaW50IGluIGFuCiAgICAgICAgb25lLXRvLW9u ZSBzZXNzaW9uIHdpdGggYSBkZWRpY2F0ZWQgRVZSQ05XIGRlY29kaW5nIGVuZCBwb2ludAogICAg ICAgIHN1Y2ggYXMgaW4gYSB0d28tcGFydHkgY2FsbCBvciBpbiBhIGNvbmZlcmVuY2UgbGVnLgog CiAgICBUaGUgbWVkaWEgdHlwZSBhdWRpby9FVlJDTlcgbWFwcyB0byB0aGUgaW50ZXJsZWF2ZWQv YnVuZGxlZCBwYWNrZXQKICAgIGZvcm1hdCwgYXVkaW8vRVZSQ05XMCBtYXBzIHRvIHRoZSBoZWFk ZXItZnJlZSBwYWNrZXQgZm9ybWF0IGFuZAogICAgYXVkaW8vRVZSQ05XMSBtYXBzIHRvIHRoZSBj b21wYWN0IGJ1bmRsZWQgcGFja2V0IGZvcm1hdC4KIAogNy4gIENvbmdlc3Rpb24gQ29udHJvbCBD b25zaWRlcmF0aW9ucwogCiAgICBDb25nZXN0aW9uIGNvbnRyb2wgZm9yIFJUUCBTSEFMTCBiZSB1 c2VkIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMgMzU1MAotICAgWzVdLCBhbmQgd2l0aCBhbnkgYXBw bGljYWJsZSBSVFAgcHJvZmlsZTsgZS5nLiwgUkZDIDM1NTEgWzZdLgorICAgWzVdLCBhbmQgd2l0 aCBhbnkgYXBwbGljYWJsZSBSVFAgcHJvZmlsZTsgZS5nLiwgUkZDIDM1NTEgWzddLgogCiAgICBE dWUgdG8gdGhlIGhlYWRlciBvdmVyaGVhZCwgdGhlIG51bWJlciBvZiBmcmFtZXMgZW5jYXBzdWxh dGVkIGluIGVhY2gKICAgIFJUUCBwYWNrZXQgaW5mbHVlbmNlcyB0aGUgb3ZlcmFsbCBiYW5kd2lk dGggb2YgdGhlIFJUUCBzdHJlYW0uCiAgICBQYWNraW5nIG1vcmUgZnJhbWVzIGluIGVhY2ggUlRQ IHBhY2tldCBjYW4gcmVkdWNlIHRoZSBudW1iZXIgb2YKICAgIHBhY2tldHMgc2VudCBhbmQgaGVu Y2UgdGhlIGhlYWRlciBvdmVyaGVhZCwgYXQgdGhlIGV4cGVuc2Ugb2YKICAgIGluY3JlYXNlZCBk ZWxheSBhbmQgcmVkdWNlZCBlcnJvciByb2J1c3RuZXNzLgogCiA4LiAgU3RvcmFnZSBmb3JtYXQg Zm9yIHRoZSBFVlJDLU5XIENvZGVjCiAKICAgIFRoZSBzdG9yYWdlIGZvcm1hdCBpcyB1c2VkIGZv ciBzdG9yaW5nIEVWUkMtTlcgZW5jb2RlZCBzcGVlY2ggZnJhbWVzLApAQCAtMjEzLDIxICsyMTMs MjEgQEAKICAgIFNwZWVjaCBmcmFtZXMgbG9zdCBpbiB0cmFuc21pc3Npb24gYW5kIG5vbi1yZWNl aXZlZCBmcmFtZXMgTVVTVCBiZQogICAgc3RvcmVkIGFzIGVyYXN1cmUgZnJhbWVzIChUb0MgdmFs dWUgb2YgNSkgdG8gbWFpbnRhaW4gc3luY2hyb25pemF0aW9uCiAgICB3aXRoIHRoZSBvcmlnaW5h bCBtZWRpYS4KIAogOS4gIElBTkEgY29uc2lkZXJhdGlvbnMKIAogICAgVGhpcyBkb2N1bWVudCBp bnRyb2R1Y2VzIGEgbmV3IEVWUkMtTlcgJ2F1ZGlvJyBtZWRpYSBzdWJ0eXBlLgogCiA5LjEuICBN ZWRpYSBUeXBlIFJlZ2lzdHJhdGlvbnMKIAotICAgRm9sbG93aW5nIHRoZSBndWlkZWxpbmVzIGlu IFJGQyA0ODU1IFs3XSBhbmQgUkZDIDQyODggWzhdLCB0aGlzCisgICBGb2xsb3dpbmcgdGhlIGd1 aWRlbGluZXMgaW4gUkZDIDQ4NTUgWzhdIGFuZCBSRkMgNDI4OCBbOV0sIHRoaXMKICAgIHNlY3Rp b24gcmVnaXN0ZXJzIG5ldyAnYXVkaW8nIG1lZGlhIHN1YnR5cGVzIGZvciBFVlJDLU5XLgogCiA5 LjEuMS4gIFJlZ2lzdHJhdGlvbiBvZiBNZWRpYSBUeXBlIGF1ZGlvL0VWUkNOVwogCiAgICBUeXBl IG5hbWU6IGF1ZGlvCiAKICAgIFN1YnR5cGUgbmFtZXM6IEVWUkNOVwogCiAgICBSZXF1aXJlZCBw YXJhbWV0ZXJzOiBOb25lCiAKQEAgLTIzNSw5MyArMjM1LDkwIEBACiAKICAgIFRoZXNlIHBhcmFt ZXRlcnMgYXBwbHkgdG8gUlRQIHRyYW5zZmVyIG9ubHkuCiAKICAgIG1vZGUtc2V0LXJlY3Y6IEEg c3Vic2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgIGNvbW1h IHNlcGFyYXRlZCBsaXN0IG9mIG1vZGVzIGZyb20gdGhlIHNldCB7MCwxLDIsMyw0LDUsNiw3fSAo c2VlCiAgICBUYWJsZSAyLjYuMS4yLTQgaW4gM0dQUDIgQy5TMDAxNC1EKS4gIEEgZGVjb2RlciBj YW4gdXNlIHRoaXMKICAgIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4gZW5jb2RlciBvZiBpdHMgcHJl ZmVyZW5jZSB0byBvcGVyYXRlIGluIGEKICAgIHNwZWNpZmllZCBzdWJzZXQgb2YgbW9kZXMuICBB YnNlbmNlIG9mIHRoaXMgcGFyYW1ldGVyIHNpZ25hbHMgdGhlCiAgICBtb2RlIHNldCB7MSwyLDMs NCw1LDYsN30uCiAKLSAgIHNlbmRtb2RlOiBUaGUgInNlbmRtb2RlIiBwYXJhbWV0ZXIgaXMgZGVw cmVjYXRlZCBmb3IgRVZSQ05XLiAgQW4KLSAgIEVWUkNOVyByZWNlaXZlciBNVVNUIGlnbm9yZSB0 aGlzIHBhcmFtZXRlciBpZiBwcmVzZW50LgotCi0gICBwdGltZTogc2VlIFJGQyA0NTY2IFs5XS4K KyAgIHB0aW1lOiBzZWUgUkZDIDQ1NjYgWzEwXS4KIAogICAgbWF4cHRpbWU6IHNlZSBSRkMgNDU2 Ni4KIAogICAgbWF4aW50ZXJsZWF2ZTogTWF4aW11bSBudW1iZXIgZm9yIGludGVybGVhdmluZyBs ZW5ndGggKGZpZWxkIExMTCBpbgogICAgdGhlIEludGVybGVhdmluZyBPY3RldClbMC4uN10uICBU aGUgaW50ZXJsZWF2aW5nIGxlbmd0aHMgdXNlZCBpbiB0aGUKICAgIGVudGlyZSBzZXNzaW9uIE1V U1QgTk9UIGV4Y2VlZCB0aGlzIG1heGltdW0gdmFsdWUuICBJZiBub3Qgc2lnbmFsZWQsCiAgICB0 aGUgbWF4aW50ZXJsZWF2ZSBsZW5ndGggTVVTVCBiZSA1LgogCiAgICBzaWxlbmNlc3VwcDogc2Vl IFNlY3Rpb24gNi4xIGluIFJGQyA0Nzg4LgogCiAgICBkdHhtYXg6IHNlZSBTZWN0aW9uIDYuMSBp biBSRkMgNDc4OC4KIAogICAgZHR4bWluOiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCiAK ICAgIGhhbmdvdmVyOiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3ODguCiAKICAgIEVuY29kaW5n IGNvbnNpZGVyYXRpb25zOgogCiAgICBUaGlzIG1lZGlhIHR5cGUgaXMgZnJhbWVkIGJpbmFyeSBk YXRhIChzZWUgUkZDIDQyODgsIFNlY3Rpb24gNC44KSBhbmQKICAgIGlzIGRlZmluZWQgZm9yIHRy YW5zZmVyIG9mIEVWUkMtTlcgZW5jb2RlZCBkYXRhIHZpYSBSVFAgdXNpbmcgdGhlCi0gICBJbnRl cmxlYXZlZC9CdW5kbGVkIHBhY2tldCBmb3JtYXQgc3BlY2lmaWVkIGluIFJGQyAzNTU4LgorICAg SW50ZXJsZWF2ZWQvQnVuZGxlZCBwYWNrZXQgZm9ybWF0IHNwZWNpZmllZCBpbiBSRkMgMzU1OCBb Nl0uCiAKICAgIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zOiBTZWUgU2VjdGlvbiAxNS4KIAogICAg SW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczogTm9uZQogCiAgICBQdWJsaXNoZWQgc3Bl Y2lmaWNhdGlvbjoKIAogICAgVGhlIEVWUkMtTlcgdm9jb2RlciBpcyBzcGVjaWZpZWQgaW4gM0dQ UDIgQy5TMDAxNC1ELiAgVGhlIHRyYW5zZmVyCiAgICBtZXRob2Qgd2l0aCB0aGUgSW50ZXJsZWF2 ZWQvQnVuZGxlZCBwYWNrZXQgZm9ybWF0IHZpYSBSVFAgaXMKLSAgIHNwZWNpZmllZCBpbiBSRkMg MzU1OC4KKyAgIHNwZWNpZmllZCBpbiBSRkMgMzU1OCBbNl0uCiAKICAgIEFwcGxpY2F0aW9ucyB0 aGF0IHVzZSB0aGlzIG1lZGlhIHR5cGU6CiAKICAgIEl0IGlzIGV4cGVjdGVkIHRoYXQgbWFueSBW b0lQIGFwcGxpY2F0aW9ucyAoYXMgd2VsbCBhcyBtb2JpbGUKICAgIGFwcGxpY2F0aW9ucykgd2ls bCB1c2UgdGhpcyB0eXBlLgogCiAgICBBZGRpdGlvbmFsIGluZm9ybWF0aW9uOgogCiAgICBUaGUg Zm9sbG93aW5nIGFwcGxpZXMgdG8gc3RvcmVkLWZpbGUgdHJhbnNmZXIgbWV0aG9kczoKIAogICAg TWFnaWMgbnVtYmVyOiAjIUVWUkNOV1xuIChzZWUgU2VjdGlvbiA4KQogCiAgICBGaWxlIGV4dGVu c2lvbnM6IGVudywgRU5XCiAKICAgIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZTogTm9uZQogCiAg ICBPYmplY3QgaWRlbnRpZmllciBvciBPSUQ6IE5vbmUKIAogICAgRVZSQy1OVyBzcGVlY2ggZnJh bWVzIG1heSBhbHNvIGJlIHN0b3JlZCBpbiB0aGUgZmlsZSBmb3JtYXQgIjNnMiIKICAgIGRlZmlu ZWQgaW4gM0dQUDIgQy5TMDA1MC1CLCB3aGljaCBpcyBpZGVudGlmaWVkIHVzaW5nIHRoZSBtZWRp YSB0eXBlcwotICAgImF1ZGlvLzNncHAyIiBvciAidmlkZW8vM2dwcDIiIHJlZ2lzdGVyZWQgYnkg UkZDIDQzOTMgWzEwXS4KKyAgICJhdWRpby8zZ3BwMiIgb3IgInZpZGVvLzNncHAyIiByZWdpc3Rl cmVkIGJ5IFJGQyA0MzkzIFsxMV0uCiAKICAgIFBlcnNvbiAmIGVtYWlsIGFkZHJlc3MgdG8gY29u dGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbjoKIAogICAgWmhlbmcgRmFuZyA8emZhbmdAcXVh bGNvbW0uY29tPgogCiAgICBJbnRlbmRlZCB1c2FnZTogQ09NTU9OCiAKICAgIFJlc3RyaWN0aW9u cyBvbiB1c2FnZToKIAogICAgV2hlbiB0aGlzIG1lZGlhIHR5cGUgaXMgdXNlZCBpbiB0aGUgY29u dGV4dCBvZiB0cmFuc2ZlciBvdmVyIFJUUCwgdGhlCi0gICBSVFAgcGF5bG9hZCBmb3JtYXQgc3Bl Y2lmaWVkIGluIFNlY3Rpb24gNC4xIG9mIFJGQyAzNTU4IFNIQUxMIGJlCisgICBSVFAgcGF5bG9h ZCBmb3JtYXQgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4xIG9mIFJGQyAzNTU4IFs2XSBTSEFMTCBi ZQogICAgdXNlZC4gIEluIGFsbCBvdGhlciBjb250ZXh0cywgdGhlIGZpbGUgZm9ybWF0IGRlZmlu ZWQgaW4gU2VjdGlvbiA4CiAgICBTSEFMTCBiZSB1c2VkLgogCiAgICBBdXRob3I6CiAKLSAgIFpo ZW5nIEZhbmcKKyAgIFpoZW5nIEZhbmcgPHpmYW5nQHF1YWxjb21tLmNvbT4KIAogICAgQ2hhbmdl IGNvbnRyb2xsZXI6CiAKICAgIElFVEYgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IHdvcmtpbmcgZ3Jv dXAgZGVsZWdhdGVkIGZyb20gdGhlIElFU0cuCiAKIDkuMS4yLiAgUmVnaXN0cmF0aW9uIG9mIE1l ZGlhIFR5cGUgYXVkaW8vRVZSQ05XMAogCiAgICBUeXBlIG5hbWU6IGF1ZGlvCiAKICAgIFN1YnR5 cGUgbmFtZXM6IEVWUkNOVzAKQEAgLTMzMiw3MiArMzI5LDY5IEBACiAKICAgIFRoZXNlIHBhcmFt ZXRlcnMgYXBwbHkgdG8gUlRQIHRyYW5zZmVyIG9ubHkuCiAKICAgIG1vZGUtc2V0LXJlY3Y6IEEg c3Vic2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAgIGNvbW1h IHNlcGFyYXRlZCBsaXN0IG9mIG1vZGVzIGZyb20gdGhlIHNldCB7MCwxLDIsMyw0LDUsNiw3fSAo c2VlCiAgICBUYWJsZSAyLjYuMS4yLTQgaW4gM0dQUDIgQy5TMDAxNC1EKS4gIEEgZGVjb2RlciBj YW4gdXNlIHRoaXMKICAgIGF0dHJpYnV0ZSB0byBpbmZvcm0gYW4gZW5jb2RlciBvZiBpdHMgcHJl ZmVyZW5jZSB0byBvcGVyYXRlIGluIGEKICAgIHNwZWNpZmllZCBzdWJzZXQgb2YgbW9kZXMuICBB YnNlbmNlIG9mIHRoaXMgcGFyYW1ldGVyIHNpZ25hbHMgdGhlCiAgICBtb2RlIHNldCB7MSwyLDMs NCw1LDYsN30uCiAKLSAgIHNlbmRtb2RlOiBUaGUgInNlbmRtb2RlIiBwYXJhbWV0ZXIgaXMgZGVw cmVjYXRlZCBmb3IgRVZSQ05XLiAgQW4KLSAgIEVWUkNOVyByZWNlaXZlciBNVVNUIGlnbm9yZSB0 aGlzIHBhcmFtZXRlciBpZiBwcmVzZW50LgotCiAgICBwdGltZTogc2VlIFJGQyA0NTY2LgogCiAg ICBzaWxlbmNlc3VwcDogc2VlIFNlY3Rpb24gNi4xIGluIFJGQyA0Nzg4LgogCiAgICBkdHhtYXg6 IHNlZSBTZWN0aW9uIDYuMSBpbiBSRkMgNDc4OC4KIAogICAgZHR4bWluOiBzZWUgU2VjdGlvbiA2 LjEgaW4gUkZDIDQ3ODguCiAKICAgIGhhbmdvdmVyOiBzZWUgU2VjdGlvbiA2LjEgaW4gUkZDIDQ3 ODguCiAKICAgIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zOgogCiAgICBUaGlzIG1lZGlhIHR5cGUg aXMgZnJhbWVkIGJpbmFyeSBkYXRhIChzZWUgUkZDIDQyODgsIFNlY3Rpb24gNC44KSBhbmQKICAg IGlzIGRlZmluZWQgZm9yIHRyYW5zZmVyIG9mIEVWUkMtTlcgZW5jb2RlZCBkYXRhIHZpYSBSVFAg dXNpbmcgdGhlCi0gICBIZWFkZXItRnJlZSBwYWNrZXQgZm9ybWF0IHNwZWNpZmllZCBpbiBSRkMg MzU1OC4KKyAgIEhlYWRlci1GcmVlIHBhY2tldCBmb3JtYXQgc3BlY2lmaWVkIGluIFJGQyAzNTU4 IFs2XS4KIAogICAgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IFNlZSBTZWN0aW9uIDE1LgogCiAg ICBJbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVydGFpb25zOiBOb25lCiAKICAgIFB1Ymxpc2hlZCBz cGVjaWZpY2F0aW9uOgogCiAgICBUaGUgRVZSQy1OVyB2b2NvZGVyIGlzIHNwZWNpZmllZCBpbiAz R1BQMiBDLlMwMDE0LUQuICBUaGUgdHJhbnNmZXIKICAgIG1ldGhvZCB3aXRoIHRoZSBIZWFkZXIt RnJlZSBwYWNrZXQgZm9ybWF0IHZpYSBSVFAgaXMgc3BlY2lmaWVkIGluIFJGQwotICAgMzU1OC4K KyAgIDM1NTggWzZdLgogCiAgICBBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhpcyBtZWRpYSB0eXBl OgogCiAgICBJdCBpcyBleHBlY3RlZCB0aGF0IG1hbnkgVm9JUCBhcHBsaWNhdGlvbnMgKGFzIHdl bGwgYXMgbW9iaWxlCiAgICBhcHBsaWNhdGlvbnMpIHdpbGwgdXNlIHRoaXMgdHlwZS4KIAogICAg QWRkaXRpb25hbCBpbmZvcm1hdGlvbjogTm9uZQogCiAgICBQZXJzb24gJiBlbWFpbCBhZGRyZXNz IHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb246CiAKICAgIFpoZW5nIEZhbmcgPHpm YW5nQHF1YWxjb21tLmNvbT4KIAogICAgSW50ZW5kZWQgdXNhZ2U6IENPTU1PTgogCiAgICBSZXN0 cmljdGlvbnMgb24gdXNhZ2U6CiAKICAgIFRoaXMgbWVkaWEgdHlwZSBkZXBlbmRzIG9uIFJUUCBm cmFtaW5nLCBhbmQgaGVuY2UgaXMgb25seSBkZWZpbmVkIGZvcgogICAgdHJhbnNmZXIgdmlhIFJU UCBbNV0sIHRoZSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC4yCi0g ICBvZiBSRkMgMzU1OCBTSEFMTCBiZSB1c2VkLiAgVGhpcyBtZWRpYSB0eXBlIFNIQUxMIE5PVCBi ZSB1c2VkIGZvcgorICAgb2YgUkZDIDM1NTggWzZdIFNIQUxMIGJlIHVzZWQuICBUaGlzIG1lZGlh IHR5cGUgU0hBTEwgTk9UIGJlIHVzZWQgZm9yCiAgICBzdG9yYWdlIG9yIGZpbGUgdHJhbnNmZXIs IGluc3RlYWQgYXVkaW8vRVZSQ05XIFNIQUxMIGJlIHVzZWQuCiAKICAgIEF1dGhvcjoKIAotICAg WmhlbmcgRmFuZworICAgWmhlbmcgRmFuZyA8emZhbmdAcXVhbGNvbW0uY29tPgogCiAgICBDaGFu Z2UgY29udHJvbGxlcjoKIAogICAgSUVURiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgd29ya2luZyBn cm91cCBkZWxlZ2F0ZWQgZnJvbSB0aGUgSUVTRy4KIAogOS4xLjMuICBSZWdpc3RyYXRpb24gb2Yg TWVkaWEgVHlwZSBhdWRpby9FVlJDTlcxCiAKICAgIFR5cGUgbmFtZTogYXVkaW8KIAogICAgU3Vi dHlwZSBuYW1lczogRVZSQ05XMQpAQCAtNDExLDIzICs0MDUsMjAgQEAKICAgIG1vZGUtc2V0LXJl Y3Y6IEEgc3Vic2V0IG9mIEVWUkMtTlcgbW9kZXMuICBQb3NzaWJsZSB2YWx1ZXMgYXJlIGEKICAg IGNvbW1hIHNlcGFyYXRlZCBsaXN0IG9mIG1vZGVzIGZyb20gdGhlIHNldCB7MCwxfSAoc2VlIFRh YmxlIDIuNi4xLjItNAogICAgaW4gM0dQUDIgQy5TMDAxNC1EKS4gIEEgZGVjb2RlciBjYW4gdXNl IHRoaXMgYXR0cmlidXRlIHRvIGluZm9ybSBhbgogICAgZW5jb2RlciBvZiBpdHMgcHJlZmVyZW5j ZSB0byBvcGVyYXRlIGluIGEgc3BlY2lmaWVkIHN1YnNldCBvZiBtb2Rlcy4KICAgIEEgdmFsdWUg b2YgMCBzaWduYWxzIHRoZSBzdXBwb3J0IGZvciB3aWRlYmFuZCBmaXhlZCByYXRlIChmdWxsIG9y CiAgICBoYWxmIHJhdGUsIGRlcGVuZGluZyBvbiB0aGUgdmFsdWUgb2YgJ2ZpeGVkcmF0ZScgcGFy YW1ldGVyKS4gIEEgdmFsdWUKICAgIG9mIDEgc2lnbmFscyBuYXJyb2JhbmQgZml4ZWQgcmF0ZSAo ZnVsbCBvciBoYWxmIHJhdGUsIGRlcGVuZGluZyBvbgogICAgdGhlIHZhbHVlIG9mICdmaXhlZHJh dGUnIHBhcmFtZXRlcikuICBBYnNlbmNlIG9mIHRoaXMgcGFyYW1ldGVyCiAgICBzaWduYWxzIHRo ZSBtb2RlIDEuCiAKLSAgIHNlbmRtb2RlOiBUaGUgInNlbmRtb2RlIiBwYXJhbWV0ZXIgaXMgZGVw cmVjYXRlZCBmb3IgRVZSQ05XLiAgQW4KLSAgIEVWUkNOVyByZWNlaXZlciBNVVNUIGlnbm9yZSB0 aGlzIHBhcmFtZXRlciBpZiBwcmVzZW50LgotCiAgICBwdGltZTogc2VlIFJGQyA0NTY2LgogCiAg ICBtYXhwdGltZTogc2VlIFJGQyA0NTY2LgogCiAgICBmaXhlZHJhdGU6IEluZGljYXRlcyB0aGUg RVZSQy1OVyByYXRlIG9mIHRoZSBzZXNzaW9uIHdoaWxlIGluIHNpbmdsZQogICAgcmF0ZSBvcGVy YXRpb24uICBWYWxpZCB2YWx1ZXMgaW5jbHVkZTogMC41IGFuZCAxLCB3aGVyZSBhIHZhbHVlIG9m CiAgICAwLjUgaW5kaWNhdGVzIHRoZSAxLzIgcmF0ZSB3aGlsZSBhIHZhbHVlIG9mIDEgaW5kaWNh dGVzIHRoZSBmdWxsCiAgICByYXRlLiAgSWYgdGhpcyBwYXJhbWV0ZXIgaXMgbm90IHByZXNlbnQs IDEvMiByYXRlIGlzIGFzc3VtZWQuCiAKICAgIHNpbGVuY2VzdXBwOiBzZWUgU2VjdGlvbiA2LjEg aW4gUkZDIDQ3ODguCkBAIC00NjksMjEgKzQ1OSwyMSBAQAogCiAgICBSZXN0cmljdGlvbnMgb24g dXNhZ2U6CiAKICAgIFRoaXMgbWVkaWEgdHlwZSBkZXBlbmRzIG9uIFJUUCBmcmFtaW5nLCBhbmQg aGVuY2UgaXMgb25seSBkZWZpbmVkIGZvcgogICAgdHJhbnNmZXIgdmlhIFJUUCBbNV0sIHRoZSBS VFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWVkIGluIFNlY3Rpb24gNAogICAgb2YgUkZDIDQ3ODgg U0hBTEwgYmUgdXNlZC4gIFRoaXMgbWVkaWEgdHlwZSBTSEFMTCBOT1QgYmUgdXNlZCBmb3IKICAg IHN0b3JhZ2Ugb3IgZmlsZSB0cmFuc2ZlciwgaW5zdGVhZCBhdWRpby9FVlJDTlcgU0hBTEwgYmUg dXNlZC4KIAogICAgQXV0aG9yOgogCi0gICBaaGVuZyBGYW5nCisgICBaaGVuZyBGYW5nIDx6ZmFu Z0BxdWFsY29tbS5jb20+CiAKICAgIENoYW5nZSBjb250cm9sbGVyOgogCiAgICBJRVRGIEF1ZGlv L1ZpZGVvIFRyYW5zcG9ydCB3b3JraW5nIGdyb3VwIGRlbGVnYXRlZCBmcm9tIHRoZSBJRVNHLgog CiAxMC4gIFNEUCBtb2RlIGF0dHJpYnV0ZXMgZm9yIEVWUkMtTlcKIAogICAgJ21vZGUtc2V0LXJl Y3YnIGNhbiBiZSB1c2VkIGJ5IGEgZGVjb2RlciB0byBpbmZvcm0gYW4gZW5jb2RlciBvZiBpdHMK ICAgIHByZWZlcmVuY2UgdG8gb3BlcmF0ZSBpbiBhIHNwZWNpZmllZCBzdWJzZXQgb2YgbW9kZXMu ICBOb3RlIHRoYXQKICAgIGluZGljYXRpbmcgYSBwcmVmZXJlbmNlLCBpbXBsaWNpdGx5IGluZGlj YXRlcyBzdXBwb3J0IGZvciB0aGF0CkBAIC01MDgsMjQgKzQ5OCwyNyBAQAogICAgcGFydG5lciBj b21wbGVtZW50cyB0aGUgbW9kZSBzZXQgaW5mb3JtYXRpb24gaW4gbW9kZS1zZXQtcmVjdi4gIEEK ICAgIG1vZGUgcmVxdWVzdCB3aXRoIE1NTT0wIGZyb20gYSBjb21tdW5pY2F0aW9uIHBhcnRuZXIg aXMgYW4gaW1wbGljaXQKICAgIGluZGljYXRpb24gb2YgdGhlIHBhcnRuZXIncyBFVlJDTlcgd2lk ZWJhbmQgZGVjb2RpbmcgY2FwYWJpbGl0eSBhbmQKICAgIHByZWZlcmVuY2UuICBBbiBFVlJDTlcg d2lkZWJhbmQgY2FwYWJsZSBub2RlIHJlY2VpdmluZyB0aGUgcmVxdWVzdAogICAgY2FuIG9wZXJh dGUgaW4gd2lkZWJhbmQgbW9kZS4gIEEgbW9kZSByZXF1ZXN0IHdpdGggTU1NPTEsIDIsIC4uLiwg b3IKICAgIDcgZnJvbSBhIGNvbW11bmljYXRpb24gcGFydG5lciBpcyBhbiBpbXBsaWNpdCBpbmRp Y2F0aW9uIG9mIHRoZQogICAgcGFydG5lcidzIEVWUkNOVyBuYXJyb3diYW5kIGRlY29kaW5nIHBy ZWZlcmVuY2UuICBUaGUgZW5jb2RlciBvZiBhbgogICAgRVZSQ05XIG5vZGUgcmVjZWl2aW5nIHRo ZSByZXF1ZXN0IHNob3VsZCBob25vciB0aGUgcmVxdWVzdCBhbmQKICAgIG9wZXJhdGUgaW4gbmFy cm93YmFuZCBtb2RlLgogCisgICAnc2VuZG1vZGUnIGlzIHVzZWQgYXMgYSBTRFAgbW9kZSBhdHRy aWJ1dGUgaW4gRVZSQyBbNl0sIEVWUkMtQiBbMl0KKyAgIGFuZCBFVlJDLVdCIFszXS4gIEhvd2V2 ZXIgaXQgaXMgZGVwcmVjYXRlZCBpbiBFVlJDLU5XLgorCiAxMS4gIE1hcHBpbmcgRVZSQy1OVyBt ZWRpYSB0eXBlIHBhcmFtZXRlcnMgaW50byBTRFAKIAogICAgSW5mb3JtYXRpb24gY2FycmllZCBp biB0aGUgbWVkaWEgdHlwZSBzcGVjaWZpY2F0aW9uIGhhcyBhIHNwZWNpZmljCi0gICBtYXBwaW5n IHRvIGZpZWxkcyBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSBbOV0s CisgICBtYXBwaW5nIHRvIGZpZWxkcyBpbiB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2Nv bCAoU0RQKSBbMTBdLAogICAgd2hpY2ggaXMgY29tbW9ubHkgdXNlZCB0byBkZXNjcmliZSBSVFAg c2Vzc2lvbnMuICBXaGVuIFNEUCBpcyB1c2VkIHRvCiAgICBzcGVjaWZ5IHNlc3Npb25zIGVtcGxv eWluZyBFVlJDLU5XIGVuY29kZWQgc3BlZWNoLCB0aGUgbWFwcGluZyBpcyBhcwogICAgZm9sbG93 cy4KIAogICAgbyAgVGhlIG1lZGlhIHR5cGUgKCJhdWRpbyIpIGdvZXMgaW4gU0RQICJtPSIgYXMg dGhlIG1lZGlhIG5hbWUuCiAKICAgIG8gIFRoZSBtZWRpYSBzdWJ0eXBlICgiRVZSQ05XIiwgIkVW UkNOVzAiIG9yICJFVlJDTlcxIikgZ29lcyBpbiBTRFAKICAgICAgICJhPXJ0cG1hcCIgYXMgdGhl IGVuY29kaW5nIG5hbWUuCiAKICAgIG8gIFRoZSBvcHRpb25hbCBwYXJhbWV0ZXJzICdwdGltZSBh bmQgJ21heHB0aW1lJyAoZm9yIHN1YnR5cGVzCkBAIC01MzMsMjEgKzUyNiwyMSBAQAogICAgICAg YXR0cmlidXRlcywgcmVzcGVjdGl2ZWx5LgogCiAgICBvICBBbnkgcmVtYWluaW5nIHBhcmFtZXRl cnMgKGZvciBzdWJ0eXBlcyBFVlJDTlcsIEVWUkNOVzAgYW5kCiAgICAgICBFVlJDTlcxKSBnbyBp biB0aGUgU0RQICJhPWZtdHAiIGF0dHJpYnV0ZSBieSBjb3B5aW5nIHRoZW0gZnJvbSB0aGUKICAg ICAgIG1lZGlhIHR5cGUgc3RyaW5nIGFzIGEgc2VtaWNvbG9uIHNlcGFyYXRlZCBsaXN0IG9mIHBh cmFtZXRlcj12YWx1ZQogICAgICAgcGFpcnMuCiAKIDEyLiAgT2ZmZXItQW5zd2VyIE1vZGVsIENv bnNpZGVyYXRpb25zIGZvciBFVlJDLU5XCiAKICAgIFRoZSBmb2xsb3dpbmcgY29uc2lkZXJhdGlv bnMgYXBwbHkgd2hlbiB1c2luZyB0aGUgU0RQIG9mZmVyLWFuc3dlcgotICAgcHJvY2VkdXJlcyBv ZiBSRkMgMzI2NCBbMTFdIHRvIG5lZ290aWF0ZSB0aGUgdXNlIG9mIEVWUkMtTlcgcGF5bG9hZAor ICAgcHJvY2VkdXJlcyBvZiBSRkMgMzI2NCBbMTJdIHRvIG5lZ290aWF0ZSB0aGUgdXNlIG9mIEVW UkMtTlcgcGF5bG9hZAogICAgaW4gUlRQOgogCiAgICBvICBTaW5jZSBFVlJDLU5XIGlzIGFuIGV4 dGVuc2lvbiBvZiBib3RoIEVWUkMtQiBhbmQgRVZSQy1XQiwgdGhlCiAgICAgICBvZmZlcmVyIFNI T1VMRCBhbHNvIGFubm91bmNlIEVWUkMtQiBhbmQgRVZSQy1XQiBzdXBwb3J0IGluIGl0cwogICAg ICAgIm09YXVkaW8iIGxpbmVzLCB3aXRoIEVWUkMtTlcgYXMgdGhlIHByZWZlcnJlZCBjb2RlYy4g IFRoaXMgd2lsbAogICAgICAgYWxsb3cgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGFuIGFuc3dlcmVy IHdoaWNoIHN1cHBvcnRzIG9ubHkgRVZSQy1CCiAgICAgICBhbmQvb3IgRVZSQy1XQi4KIAogICAg QmVsb3cgaXMgYW4gZXhhbXBsZSBvZiBzdWNoIGFuIG9mZmVyOgogCkBAIC01NzcsMjEgKzU3MCwy MSBAQAogICAgbyAgQW4gb2ZmZXJlciBjYW4gdXNlICdtb2RlLXNldC1yZWN2JyB0byByZXF1ZXN0 IHRoYXQgdGhlIHJlbW90ZQogICAgICAgc2VuZGVyJ3MgZW5jb2RlciBiZSBsaW1pdGVkIHRvIHRo ZSBsaXN0IG9mIG1vZGVzIHNpZ25hbGVkIGluCiAgICAgICAnbW9kZS1zZXQtcmVjdicuICBBIHJl bW90ZSBzZW5kZXIgTUFZIGlnbm9yZSAnbW9kZS1zZXQtcmVjdicKICAgICAgIHJlcXVlc3RzLiAg SG93ZXZlciwgYSByZW1vdGUgc2VuZGVyIHNoYWxsIG5vdCBhc3N1bWUgdGhlIG90aGVyCiAgICAg ICBzaWRlIGNhbiBzdXBwb3J0IG1vZGUgMCwgdW5sZXNzIHRoZSBvZmZlciBpbmNsdWRlcyBtb2Rl IDAKICAgICAgIGV4cGxpY2l0bHkgaW4gJ21vZGUtc2V0LXJlY3YnLgogCiAgICBvICBUaGUgcGFy YW1ldGVycyAnbWF4cHRpbWUnIGFuZCAncHRpbWUnIHdpbGwgaW4gbW9zdCBjYXNlcyBub3QKICAg ICAgIGFmZmVjdCBpbnRlcm9wZXJhYmlsaXR5LCBob3dldmVyIHRoZSBzZXR0aW5nIG9mIHRoZSBw YXJhbWV0ZXJzIGNhbgogICAgICAgYWZmZWN0IHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgYXBwbGlj YXRpb24uICBUaGUgU0RQIG9mZmVyLWFuc3dlcgotICAgICAgaGFuZGxpbmcgb2YgdGhlICdwdGlt ZScgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBpbiBSRkMgMzI2NCBbMTFdLgorICAgICAgaGFuZGxp bmcgb2YgdGhlICdwdGltZScgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBpbiBSRkMgMzI2NCBbMTJd LgogICAgICAgVGhlICdtYXhwdGltZScgcGFyYW1ldGVyIE1VU1QgYmUgaGFuZGxlZCBpbiB0aGUg c2FtZSB3YXkuCiAKICAgIG8gIEZvciBhIHNlbmRvbmx5IHN0cmVhbSwgdGhlICdtb2RlLXNldC1y ZWN2JyBwYXJhbWV0ZXIgaXMgbm90IHVzZWZ1bAogICAgICAgYW5kIFNIT1VMRCBOT1QgYmUgdXNl ZC4KIAogICAgbyAgV2hlbiB1c2luZyBFVlJDTlcxLCB0aGUgZW50aXJlIHNlc3Npb24gTVVTVCB1 c2UgdGhlIHNhbWUgZml4ZWQKICAgICAgIHJhdGUgYW5kIG1vZGUgKDAtV2lkZWJhbmQgb3IgMS1O YXJyb3diYW5kKS4KIAogICAgbyAgRm9yIGFkZGl0aW9uYWwgcnVsZXMgd2hpY2ggTVVTVCBiZSBm b2xsb3dlZCB3aGlsZSBuZWdvdGlhdGluZyBEVFgKICAgICAgIHBhcmFtZXRlcnMsIHNlZSBTZWN0 aW9uIDYuOCBpbiBSRkMgNDc4OCBbMl0uCkBAIC03MzQsMjQgKzcyNywyNCBAQAogICAgICAgICAg QW5zd2VyOgogCiAgICAgICAgICAgIG09YXVkaW8gNTU5NTQgUlRQL0FWUCA5OCA5OQogICAgICAg ICAgICBhPXJ0cG1hcDo5OCBFVlJDV0IwLzE2MDAwCiAKIDE1LiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMKIAogICAgU2luY2UgY29tcHJlc3Npb24gaXMgYXBwbGllZCB0byB0aGUgcGF5bG9hZCBm b3JtYXRzIGVuZC10by1lbmQsIGFuZAogICAgdGhlIGVuY29kaW5ncyBkbyBub3QgZXhoaWJpdCBz aWduaWZpY2FudCBub24tdW5pZm9ybWl0eSwKICAgIGltcGxlbWVudGF0aW9ucyBvZiB0aGlzIHNw ZWNpZmljYXRpb24gYXJlIHN1YmplY3QgdG8gYWxsIHRoZSBzZWN1cml0eQotICAgY29uc2lkZXJh dGlvbnMgc3BlY2lmaWVkIGluIFJGQyAzNTU4IFsxMl0uICBJbXBsZW1lbnRhdGlvbnMgdXNpbmcg dGhlCisgICBjb25zaWRlcmF0aW9ucyBzcGVjaWZpZWQgaW4gUkZDIDM1NTggWzZdLiAgSW1wbGVt ZW50YXRpb25zIHVzaW5nIHRoZQogICAgcGF5bG9hZCBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNh dGlvbiBhcmUgc3ViamVjdCB0byB0aGUgc2VjdXJpdHkKLSAgIGNvbnNpZGVyYXRpb25zIGRpc2N1 c3NlZCBpbiBSRkMgMzU1OCBbMTJdLCBSRkMgMzU1MCBbNV0gYW5kIGFueQotICAgYXBwcm9wcmlh dGUgcHJvZmlsZSAoZm9yIGV4YW1wbGUgUkZDIDM1NTEgWzZdKS4KKyAgIGNvbnNpZGVyYXRpb25z IGRpc2N1c3NlZCBpbiBSRkMgMzU1OCBbNl0sIFJGQyAzNTUwIFs1XSBhbmQgYW55CisgICBhcHBy b3ByaWF0ZSBwcm9maWxlIChmb3IgZXhhbXBsZSBSRkMgMzU1MSBbN10pLgogCiAxNi4gIFJlZmVy ZW5jZXMKIAogMTYuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCiAKICAgIFsxXSAgIEJyYWRuZXIs IFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJlbWVudAog ICAgICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4KIAogICAgWzJd ICAgWGllLCBRLiBhbmQgUi4gS2Fwb29yLCAiRW5oYW5jZW1lbnRzIHRvIFJUUCBQYXlsb2FkIEZv cm1hdHMgZm9yCiAgICAgICAgICBFVlJDIEZhbWlseSBDb2RlY3MiLCBSRkMgNDc4OCwgSmFudWFy eSAyMDA3LgpAQCAtNzYxLDQyICs3NTQsNDIgQEAKICAgICAgICAgIFVwZGF0ZXMgZm9yIEVWUkMt QiBDb2RlYyIsIFJGQyA1MTg4LCBGZWJydWFyeSAyMDA4LgogCiAgICBbNF0gICAiRW5oYW5jZWQg VmFyaWFibGUgUmF0ZSBDb2RlYywgU3BlZWNoIFNlcnZpY2UgT3B0aW9ucyAzLCA2OCwKICAgICAg ICAgIDcwLCBhbmQgNzMgZm9yIFdpZGViYW5kIFNwcmVhZCBTcGVjdHJ1bSBEaWdpdGFsIFN5c3Rl bXMiLAogICAgICAgICAgM0dQUDIgQy5TMDAxNC1EIHYxLjAsIE1heSAyMDA5LgogCiAgICBbNV0g ICBTY2h1bHpyaW5uZSwgSC4sIENhc25lciwgUy4sIEZyZWRlcmljaywgUi4sIGFuZCBWLiBKYWNv YnNvbiwKICAgICAgICAgICJSVFA6IEEgVHJhbnNwb3J0IFByb3RvY29sIGZvciBSZWFsLVRpbWUg QXBwbGljYXRpb25zIiwgU1REIDY0LAogICAgICAgICAgUkZDIDM1NTAsIEp1bHkgMjAwMy4KIAot ICAgWzZdICAgU2NodWx6cmlubmUsIEguIGFuZCBTLiBDYXNuZXIsICJSVFAgUHJvZmlsZSBmb3Ig QXVkaW8gYW5kIFZpZGVvCisgICBbNl0gICBMaSwgQS4sICJSVFAgUGF5bG9hZCBGb3JtYXQgZm9y IEVuaGFuY2VkIFZhcmlhYmxlIFJhdGUgQ29kZWNzCisgICAgICAgICAoRVZSQykgYW5kIFNlbGVj dGFibGUgTW9kZSBWb2NvZGVycyAoU01WKSIsIFJGQyAzNTU4LAorICAgICAgICAgSnVseSAyMDAz LgorCisgICBbN10gICBTY2h1bHpyaW5uZSwgSC4gYW5kIFMuIENhc25lciwgIlJUUCBQcm9maWxl IGZvciBBdWRpbyBhbmQgVmlkZW8KICAgICAgICAgIENvbmZlcmVuY2VzIHdpdGggTWluaW1hbCBD b250cm9sIiwgU1REIDY1LCBSRkMgMzU1MSwgSnVseSAyMDAzLgogCi0gICBbN10gICBDYXNuZXIs IFMuLCAiTWVkaWEgVHlwZSBSZWdpc3RyYXRpb24gb2YgUlRQIFBheWxvYWQgRm9ybWF0cyIsCisg ICBbOF0gICBDYXNuZXIsIFMuLCAiTWVkaWEgVHlwZSBSZWdpc3RyYXRpb24gb2YgUlRQIFBheWxv YWQgRm9ybWF0cyIsCiAgICAgICAgICBSRkMgNDg1NSwgRmVicnVhcnkgMjAwNy4KIAotICAgWzhd ICAgRnJlZWQsIE4uIGFuZCBKLiBLbGVuc2luLCAiTWVkaWEgVHlwZSBTcGVjaWZpY2F0aW9ucyBh bmQKKyAgIFs5XSAgIEZyZWVkLCBOLiBhbmQgSi4gS2xlbnNpbiwgIk1lZGlhIFR5cGUgU3BlY2lm aWNhdGlvbnMgYW5kCiAgICAgICAgICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlcyIsIEJDUCAxMywg UkZDIDQyODgsIERlY2VtYmVyIDIwMDUuCiAKLSAgIFs5XSAgIEhhbmRsZXksIE0uLCBKYWNvYnNv biwgVi4sIGFuZCBDLiBQZXJraW5zLCAiU0RQOiBTZXNzaW9uCisgICBbMTBdICBIYW5kbGV5LCBN LiwgSmFjb2Jzb24sIFYuLCBhbmQgQy4gUGVya2lucywgIlNEUDogU2Vzc2lvbgogICAgICAgICAg RGVzY3JpcHRpb24gUHJvdG9jb2wiLCBSRkMgNDU2NiwgSnVseSAyMDA2LgogCi0gICBbMTBdICBH YXJ1ZGFkcmksIEguLCAiTUlNRSBUeXBlIFJlZ2lzdHJhdGlvbnMgZm9yIDNHUFAyIE11bHRpbWVk aWEKKyAgIFsxMV0gIEdhcnVkYWRyaSwgSC4sICJNSU1FIFR5cGUgUmVnaXN0cmF0aW9ucyBmb3Ig M0dQUDIgTXVsdGltZWRpYQogICAgICAgICAgRmlsZXMiLCBSRkMgNDM5MywgTWFyY2ggMjAwNi4K IAotICAgWzExXSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlubmUsICJBbiBPZmZlci9B bnN3ZXIgTW9kZWwgd2l0aAorICAgWzEyXSAgUm9zZW5iZXJnLCBKLiBhbmQgSC4gU2NodWx6cmlu bmUsICJBbiBPZmZlci9BbnN3ZXIgTW9kZWwgd2l0aAogICAgICAgICAgU2Vzc2lvbiBEZXNjcmlw dGlvbiBQcm90b2NvbCAoU0RQKSIsIFJGQyAzMjY0LCBKdW5lIDIwMDIuCiAKLSAgIFsxMl0gIExp LCBBLiwgIlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgRW5oYW5jZWQgVmFyaWFibGUgUmF0ZSBDb2Rl Y3MKLSAgICAgICAgIChFVlJDKSBhbmQgU2VsZWN0YWJsZSBNb2RlIFZvY29kZXJzIChTTVYpIiwg UkZDIDM1NTgsCi0gICAgICAgICBKdWx5IDIwMDMuCi0KIDE2LjIuICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzCiAKICAgIFsxM10gIEhhbmRsZXksIE0uLCBQZXJraW5zLCBDLiwgYW5kIEUuIFdoZWxh biwgIlNlc3Npb24gQW5ub3VuY2VtZW50CiAgICAgICAgICBQcm90b2NvbCIsIFJGQyAyOTc0LCBP Y3RvYmVyIDIwMDAuCiAKICAgIFsxNF0gIFNjaHVsenJpbm5lLCBILiwgUmFvLCBBLiwgYW5kIFIu IExhbnBoaWVyLCAiUmVhbCBUaW1lIFN0cmVhbWluZwogICAgICAgICAgUHJvdG9jb2wgKFJUU1Ap IiwgUkZDIDIzMjYsIEFwcmlsIDE5OTguCiAKIEF1dGhvcidzIEFkZHJlc3MKIAo= --_005_E23CE350F3C94C4A834B4E7069CA567915FD1Dnasanexd01anaqual_-- From Even.roni@huawei.com Tue Oct 4 08:54:48 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 706E921F8CE3 for ; Tue, 4 Oct 2011 08:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.312 X-Spam-Level: X-Spam-Status: No, score=-106.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi9MDfaPzlMS for ; Tue, 4 Oct 2011 08:54:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 749BB21F8CEF for ; Tue, 4 Oct 2011 08:54:44 -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 <0LSJ003L8TOCUE@szxga04-in.huawei.com> for payload@ietf.org; Tue, 04 Oct 2011 23:57:48 +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 <0LSJ00ICMTOCZX@szxga04-in.huawei.com> for payload@ietf.org; Tue, 04 Oct 2011 23:57:48 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSJ001UKTNTQZ@szxml11-in.huawei.com>; Tue, 04 Oct 2011 23:57:48 +0800 (CST) Date: Tue, 04 Oct 2011 17:55:04 +0200 From: Roni Even In-reply-to: To: "'Fang, Zheng'" , payload@ietf.org Message-id: <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yNQjhJjW18P76QPYwKs7Rw)" Content-language: en-us Thread-index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQA== References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> Cc: "'Huang, Pengjun \(Jeff\)'" , "'Sinder, Dan'" , "'Wang, Min'" , "'Kandhadai, Ananthapadmanabhan \(Ananth\)'" Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 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, 04 Oct 2011 15:54:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_yNQjhJjW18P76QPYwKs7Rw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Zheng, See inline Roni From: Fang, Zheng [mailto:zfang@qualcomm.com] Sent: Tuesday, October 04, 2011 2:44 AM To: Roni Even; payload@ietf.org Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadmanabhan (Ananth); Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi Roni, Thank you for your comments and suggestions. I updated the draft based on your suggestions. Please find attached the modified text and diff. I am not sure how to address some of the comments. My answers to those questions are in line. I would appreciate it if you could further comment on it. I will submit a new version once I resolve all the comments. Thanks! Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Monday, August 29, 2011 4:35 AM To: payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I reviewed the draft and have some comments. 1. It looks to me that this draft updates RFC3558 similar to RFC 4788 and RFC 5188. It should be referenced in the header and in the text [Zheng] Although the payload definition of EVRCNW is similar to EVRCWB (RFC 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only defines the payload format for EVRCNW only. This is different than that of RFC 5188, which not only defines a new MIME type (EVRC-WB) but also update an existing MIME type (EVRC-B in RFC 4788). [roni] OK 2. In section 6 first paragraph why not reference 3788 where ToC is defined. [Zheng] Reference is added. 3. In second 9 in the registration template you have sendmode deprecated. This is strange since this registration is a new registration so there is nothing to deprecate . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do it in another section and not in the registration section. [Zheng] The sendmode descriptions are removed from the registration templates. Instead a comment on it is added in Section 10 "SDP mode attributes for EVRC-NW". 4. In section 9 in the published specification you mention RFC3558 without a reference. I think that this document need also to be specified since it defines the RTP header and the usage. [Zheng] References are added. 5. In section 9 in the author field add your email address [Zheng] Done. 6. In section 9 change controller should be " IETF Audio/Video Transport working group delegated from the IESG." [Zheng] I am a little confused. The changed controller was indeed the same as you mentioned. Can you please point it out in case I miss anything? [roni} my mistake should be "IETF Payload working group delegated from the IESG" 7. In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics can be asymmetric, i.e, incoming and outgoing streams use different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows. [roni] Declarative is a one way announcement like in SAP for streaming media, so there is no encoder at the other side. Thanks Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --Boundary_(ID_yNQjhJjW18P76QPYwKs7Rw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Zheng,

See = inline

Roni

 

From:= = Fang, Zheng [mailto:zfang@qualcomm.com]
Sent: Tuesday, = October 04, 2011 2:44 AM
To: Roni Even; = payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun = (Jeff); Kandhadai, Ananthapadmanabhan (Ananth); Fang, = Zheng
Subject: RE: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi = Roni,

 

Thank you for your comments and suggestions. = I updated the draft based on your suggestions. Please find attached the = modified text and diff.

 

I am not sure how to address some of the = comments. My answers to those questions are in line. I would appreciate = it if you could further comment on it.

 

I will submit a new version once I resolve = all the comments.

 

Thanks!

Zheng

 

From:= = Roni Even [mailto:Even.roni@huawei.com]
Sent: Monday, August = 29, 2011 4:35 AM
To: payload@ietf.org
Cc: Fang, = Zheng
Subject: RE: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I reviewed the draft and = have some comments.

 

1.       = It looks to me that this draft updates RFC3558 = similar to RFC 4788 and RFC 5188.  It should be referenced in the = header and in the text

[Zheng] = Although the payload definition of EVRCNW is similar to EVRCWB (RFC = 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only = defines the payload format for EVRCNW only. This is different than that = of RFC 5188, which not only defines a new MIME type (EVRC-WB) but also = update an existing MIME type (EVRC-B in RFC 4788). =

 

[roni] = OK

2.       = In section 6 first paragraph why not reference = 3788 where ToC is defined.

[Zheng] Reference is added. =

 

3.       = In second 9 in the registration template you = have sendmode deprecated. This is strange since this registration is a = new registration so there is nothing to deprecate . If you want to state = that this optional parameter that is used in other EVRC modes is not = used, please do it in another section and not in the registration = section.

[Zheng] The = sendmode descriptions are removed from the registration templates. = Instead a comment on it is added in Section 10 “SDP mode = attributes for EVRC-NW”.

 

4.       = In section 9 in the published specification you = mention RFC3558 without a reference. I think that this document need = also to be specified since it defines the RTP header and the = usage.

[Zheng] = References are added.

 

5.       = In section 9 in the author field add your email = address

[Zheng] = Done.

 

6.      = In section 9  change controller should be = " IETF Audio/Video Transport working group delegated from = the IESG."

[Zheng] I am a little confused. The changed = controller was indeed the same as you mentioned. Can you please point it = out in case I miss anything?

[roni} my mistake should = be "IETF Payload = working group delegated from the IESG"

 

7.      = In section 13 how is "mode-set-recv" = used in declarative SDP since it is a decoder capability and not an = encoder one.

[Zheng] In some two-way conversation = scenarios, the traffics can be asymmetric, i.e, incoming and outgoing = streams use different sets of modes. It is sufficient to declare decoder = capability and the encoder at the other side simply follows. =

[roni] Declarative is a one way announcement = like in SAP for streaming media, so there is no encoder at the other = side.

 

Thanks

Roni Even =

 

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even
Sent: Thursday, August 18, 2011 2:49 = PM
To: payload@ietf.org
Subject: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I would =
like to start a Working Group Last Call on draft-i=
etf-avt-rtp-evrc-nw-03 , RTP =
payload format for Enhanced Variable Rate Narrowband-Wideband =
Codec  (EVRC-NW)

 

The WGLC will end on September 9, 2011

Please review the draft and send comments to the = list.

 

 

Roni = Even

Payload = co-chair

 

= --Boundary_(ID_yNQjhJjW18P76QPYwKs7Rw)-- From zfang@qualcomm.com Tue Oct 4 16:38:14 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 DB5A621F8B53 for ; Tue, 4 Oct 2011 16:38:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGfZPEeuprCu for ; Tue, 4 Oct 2011 16:38:11 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 7853F21F8B50 for ; Tue, 4 Oct 2011 16:38:11 -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=1317771678; x=1349307678; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Fang,=20Zheng"=20|To:=20Ron i=20Even=20,=20"payload@ietf.org" =20|CC:=20"Fang,=20Zheng"=20|Subject:=20RE:=20[payload]=20WGLC=20on=20draft- ietf-avt-rtp-evrc-nw-03|Thread-Topic:=20[payload]=20WGLC =20on=20draft-ietf-avt-rtp-evrc-nw-03|Thread-Index:=20Acx dnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQAAPxDrg |Date:=20Tue,=204=20Oct=202011=2023:39:50=20+0000 |Message-ID:=20|References:=20<008801cc5d9c$dd 1eb400$975c1c00$%roni@huawei.com>=0D=0A=20<02b501cc663f$a 40278e0$ec076aa0$%roni@huawei.com>=0D=0A=20=0D =0A=20<037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> |In-Reply-To:=20<037101cc82ae$043c8fe0$0cb5afa0$%roni@hua wei.com>|Accept-Language:=20en-US|Content-Language:=20en- US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-originating-ip:=20[172.30.39.5]|Content-Type:=20multip art/alternative=3B=0D=0A=09boundary=3D"_000_E23CE350F3C94 C4A834B4E7069CA5679161C8Cnasanexd01anaqual_" |MIME-Version:=201.0; bh=XJpFC7BS7GtjbRZLr+Ov+jT/3O4kUMbNxeBpMfxjtBI=; b=EX8zI9z/BX+WQMUBQdq8UIUhXHbkkqkbN+BOYRJ/7A4zTVwVSV1LFysD HUjhu3iWThc1m1bkvRf8jyobdkPWPC4wT0D0+uOzU9yW3uHgw2BMBOgxq YVkB5i6loRNa8cSMOBWJqR6yq8Gx/ZVVLVt6DAd05p5kYIAZU9bLnKdT8 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6489"; a="124818200" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 04 Oct 2011 16:41:17 -0700 X-IronPort-AV: E=Sophos;i="4.68,485,1312182000"; d="scan'208,217";a="155920811" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 Oct 2011 16:41:17 -0700 Received: from NASANEXHC12.na.qualcomm.com (172.30.48.1) by nasanexhc05.na.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 4 Oct 2011 16:39:52 -0700 Received: from NASANEXD01A.na.qualcomm.com ([fe80::88b1:1c81:4562:8797]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.01.0339.001; Tue, 4 Oct 2011 16:39:51 -0700 From: "Fang, Zheng" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Thread-Index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQAAPxDrg Date: Tue, 4 Oct 2011 23:39:50 +0000 Message-ID: References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> In-Reply-To: <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA5679161C8Cnasanexd01anaqual_" MIME-Version: 1.0 Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 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, 04 Oct 2011 23:38:15 -0000 --_000_E23CE350F3C94C4A834B4E7069CA5679161C8Cnasanexd01anaqual_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni, Thanks for the follow-up comments. I will modify the change controller to be the Payload working group. For the last question, regarding declarative use of SDP parameters (copied = in below): 1. In section 13 how is "mode-set-recv" used in declarative SDP since = it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics c= an be asymmetric, i.e, incoming and outgoing streams use different sets of = modes. It is sufficient to declare decoder capability and the encoder at th= e other side simply follows. [roni] Declarative is a one way announcement like in SAP for s= treaming media, so there is no encoder at the other side. I propose to add the following text to Section 13 "Declarative SDP Consider= ations": o The usage of unidirectional receive only parameters, such as 'mode-set-r= ecv', should be excluded in any declarations, since these parameters are me= aningless in one-way streaming applications. Any comments would be appreciated. Thanks, Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Tuesday, October 04, 2011 8:55 AM To: Fang, Zheng; payload@ietf.org Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadman= abhan (Ananth) Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi Zheng, See inline Roni From: Fang, Zheng [mailto:zfang@qualcomm.com] Sent: Tuesday, October 04, 2011 2:44 AM To: Roni Even; payload@ietf.org Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadman= abhan (Ananth); Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi Roni, Thank you for your comments and suggestions. I updated the draft based on y= our suggestions. Please find attached the modified text and diff. I am not sure how to address some of the comments. My answers to those ques= tions are in line. I would appreciate it if you could further comment on it= . I will submit a new version once I resolve all the comments. Thanks! Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Monday, August 29, 2011 4:35 AM To: payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I reviewed the draft and have some comments. 2. It looks to me that this draft updates RFC3558 similar to RFC 4788= and RFC 5188. It should be referenced in the header and in the text [Zheng] Although the payload definition of EVRCNW is similar to EVRCWB (RFC= 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only define= s the payload format for EVRCNW only. This is different than that of RFC 51= 88, which not only defines a new MIME type (EVRC-WB) but also update an exi= sting MIME type (EVRC-B in RFC 4788). [roni] OK 3. In section 6 first paragraph why not reference 3788 where ToC is d= efined. [Zheng] Reference is added. 4. In second 9 in the registration template you have sendmode depreca= ted. This is strange since this registration is a new registration so there= is nothing to deprecate . If you want to state that this optional paramete= r that is used in other EVRC modes is not used, please do it in another sec= tion and not in the registration section. [Zheng] The sendmode descriptions are removed from the registration templat= es. Instead a comment on it is added in Section 10 "SDP mode attributes for= EVRC-NW". 5. In section 9 in the published specification you mention RFC3558 wi= thout a reference. I think that this document need also to be specified sin= ce it defines the RTP header and the usage. [Zheng] References are added. 6. In section 9 in the author field add your email address [Zheng] Done. 7. In section 9 change controller should be " IETF Audio/Video Transp= ort working group delegated from the IESG." [Zheng] I am a little confused. The changed controller was indeed the same = as you mentioned. Can you please point it out in case I miss anything? [roni} my mistake should be "IETF Payload working group delegated from the = IESG" 8. In section 13 how is "mode-set-recv" used in declarative SDP since = it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics can be asymmet= ric, i.e, incoming and outgoing streams use different sets of modes. It is = sufficient to declare decoder capability and the encoder at the other side = simply follows. [roni] Declarative is a one way announcement like in SAP for streaming medi= a, so there is no encoder at the other side. Thanks Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-= nw-03 , RTP paylo= ad format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --_000_E23CE350F3C94C4A834B4E7069CA5679161C8Cnasanexd01anaqual_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni,

 

Thanks for the follow-= up comments.

 

I will modify the chan= ge controller to be the Payload working group.

 

For the last question,= regarding declarative use of SDP parameters (copied in below):<= /span>

1.      In section 13 = how is "mode-set-recv" used in declarative SDP since it is a deco= der capability and not an encoder one.

       = ;      [Zheng] In some two-way conversation scenar= ios, the traffics can be asymmetric, i.e, incoming and outgoing streams use= different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply fol= lows.

   &nbs= p;         [roni] Declarative = is a one way announcement like in SAP for streaming media, so there is no e= ncoder at the other side.

 

I propose to add the foll= owing text to Section 13 “Declarative SDP Considerations”:=

o  = The usage of unidirectional receive only parameters, such as ‘mode-se= t-recv’, should be excluded in any declarations, since these parameters are meaningless in one-way streaming applications. <= /span>

Any comments would be app= reciated.

Thanks,

Zheng

 

From: Roni Eve= n [mailto:Even.roni@huawei.com]
Sent: Tuesday, October 04, 2011 8:55 AM
To: Fang, Zheng; payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananth= apadmanabhan (Ananth)
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

 

Hi Zheng,

See inline<= /span>

Roni=

 

From: Fang, Zh= eng [mailto:zfang@qualcomm.com]
Sent: Tuesday, October 04, 2011 2:44 AM
To: Roni Even; payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananth= apadmanabhan (Ananth); Fang, Zheng
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

 

Hi Roni,

 

Thank you for your comments and suggestio= ns. I updated the draft based on your suggestions. Please find attached the= modified text and diff.

 

I am not sure how to address some of the = comments. My answers to those questions are in line. I would appreciate it = if you could further comment on it.

 

I will submit a new version once I resolv= e all the comments.

 

Thanks!

Zheng

 

From: Roni Eve= n [mailto:Even.roni@huawei.com]
Sent: Monday, August 29, 2011 4:35 AM
To: payload@ietf.org
Cc: Fang, Zheng
Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03

 

Hi,<= /p>

I reviewed the draft a= nd have some comments.

 

2.&n= bsp;      It looks to me= that this draft updates RFC3558 similar to RFC 4788 and RFC 5188.  It= should be referenced in the header and in the text

[Zheng] Although the payload definition o= f EVRCNW is similar to EVRCWB (RFC 5188), EVRCB (RFC 4788) and EVRC (RFC 35= 58), the current draft only defines the payload format for EVRCNW only. This is different than that of RFC 5188, which not only defin= es a new MIME type (EVRC-WB) but also update an existing MIME type (EVRC-B = in RFC 4788).

 

[roni] OK

3.&n= bsp;      In section 6 f= irst paragraph why not reference 3788 where ToC is defined.

[Zheng] Reference is added.

 

4.&n= bsp;      In second 9 in= the registration template you have sendmode deprecated. This is strange si= nce this registration is a new registration so there is nothing to deprecat= e . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do= it in another section and not in the registration section.

[Zheng] The sendmode descriptions are rem= oved from the registration templates. Instead a comment on it is added in S= ection 10 “SDP mode attributes for EVRC-NW”.<= /p>

 

5.&n= bsp;      In section 9 i= n the published specification you mention RFC3558 without a reference. I th= ink that this document need also to be specified since it defines the RTP h= eader and the usage.

[Zheng] References are added.

 

6.&n= bsp;      In section 9 i= n the author field add your email address

[Zheng] Done.

 

7.      In section 9 &= nbsp;change controller should be " IETF Audio/Video Transport w= orking group delegated from the IESG."

[Zheng] I am a little confused. The chang= ed controller was indeed the same as you mentioned. Can you please point it= out in case I miss anything?

[roni} my mistake shou= ld be "IETF Payload working group delegated from the IESG"=

 

8.      In section 13 = how is "mode-set-recv" used in declarative SDP since it is a deco= der capability and not an encoder one.

[Zheng] In some two-way conversation scen= arios, the traffics can be asymmetric, i.e, incoming and outgoing streams u= se different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows. =

[roni] Declarative is = a one way announcement like in SAP for streaming media, so there is no enco= der at the other side.

 

Thanks

Roni Even

 

 

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even
Sent: Thursday, August 18, 2011 2:49 PM
To: payload@ietf.org
Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03<= /span>

 

Hi,

I would like to start a Working Group Last Call on draft-ietf-a=
vt-rtp-evrc-nw-03 , RTP payload format =
for Enhanced Variable Rate Narrowband-Wideband Codec  (EVRC-NW)

 

The WGLC will end on September 9, = 2011

Please review the draft and send comments to the lis= t.

 

 

Roni Even

Payload co-chair

 

--_000_E23CE350F3C94C4A834B4E7069CA5679161C8Cnasanexd01anaqual_-- From Even.roni@huawei.com Tue Oct 4 22:31:46 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 D1A3721F8B46 for ; Tue, 4 Oct 2011 22:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.32 X-Spam-Level: X-Spam-Status: No, score=-106.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GASS3DGsPfop for ; Tue, 4 Oct 2011 22:31:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0E621F8B44 for ; Tue, 4 Oct 2011 22:31:43 -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 <0LSK00IFDVHZWS@szxga05-in.huawei.com> for payload@ietf.org; Wed, 05 Oct 2011 13:34:47 +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 <0LSK003JXVHYN9@szxga05-in.huawei.com> for payload@ietf.org; Wed, 05 Oct 2011 13:34:47 +0800 (CST) Received: from windows8d787f9 (bzq-109-64-200-234.red.bezeqint.net [109.64.200.234]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSK00IXTVHSDS@szxml11-in.huawei.com>; Wed, 05 Oct 2011 13:34:46 +0800 (CST) Date: Wed, 05 Oct 2011 07:31:59 +0200 From: Roni Even In-reply-to: To: "'Fang, Zheng'" , payload@ietf.org Message-id: <044a01cc8320$1d50d2d0$57f27870$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MSkx+euCmSZWs6dE0G8IHQ)" Content-language: en-us Thread-index: AcxdnNfq/+ON2T4BTFKgzifiLMZLbwIopyFwBvqrU4AAILpqQAAPxDrgAAzxWYA= References: <008801cc5d9c$dd1eb400$975c1c00$%roni@huawei.com> <02b501cc663f$a40278e0$ec076aa0$%roni@huawei.com> <037101cc82ae$043c8fe0$0cb5afa0$%roni@huawei.com> Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 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: Wed, 05 Oct 2011 05:31:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MSkx+euCmSZWs6dE0G8IHQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Zheng, OK Regards Roni From: Fang, Zheng [mailto:zfang@qualcomm.com] Sent: Wednesday, October 05, 2011 1:40 AM To: Roni Even; payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Roni, Thanks for the follow-up comments. I will modify the change controller to be the Payload working group. For the last question, regarding declarative use of SDP parameters (copied in below): 1. In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics can be asymmetric, i.e, incoming and outgoing streams use different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows. [roni] Declarative is a one way announcement like in SAP for streaming media, so there is no encoder at the other side. I propose to add the following text to Section 13 "Declarative SDP Considerations": o The usage of unidirectional receive only parameters, such as 'mode-set-recv', should be excluded in any declarations, since these parameters are meaningless in one-way streaming applications. Any comments would be appreciated. Thanks, Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Tuesday, October 04, 2011 8:55 AM To: Fang, Zheng; payload@ietf.org Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadmanabhan (Ananth) Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi Zheng, See inline Roni From: Fang, Zheng [mailto:zfang@qualcomm.com] Sent: Tuesday, October 04, 2011 2:44 AM To: Roni Even; payload@ietf.org Cc: Wang, Min; Sinder, Dan; Huang, Pengjun (Jeff); Kandhadai, Ananthapadmanabhan (Ananth); Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi Roni, Thank you for your comments and suggestions. I updated the draft based on your suggestions. Please find attached the modified text and diff. I am not sure how to address some of the comments. My answers to those questions are in line. I would appreciate it if you could further comment on it. I will submit a new version once I resolve all the comments. Thanks! Zheng From: Roni Even [mailto:Even.roni@huawei.com] Sent: Monday, August 29, 2011 4:35 AM To: payload@ietf.org Cc: Fang, Zheng Subject: RE: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I reviewed the draft and have some comments. 2. It looks to me that this draft updates RFC3558 similar to RFC 4788 and RFC 5188. It should be referenced in the header and in the text [Zheng] Although the payload definition of EVRCNW is similar to EVRCWB (RFC 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only defines the payload format for EVRCNW only. This is different than that of RFC 5188, which not only defines a new MIME type (EVRC-WB) but also update an existing MIME type (EVRC-B in RFC 4788). [roni] OK 3. In section 6 first paragraph why not reference 3788 where ToC is defined. [Zheng] Reference is added. 4. In second 9 in the registration template you have sendmode deprecated. This is strange since this registration is a new registration so there is nothing to deprecate . If you want to state that this optional parameter that is used in other EVRC modes is not used, please do it in another section and not in the registration section. [Zheng] The sendmode descriptions are removed from the registration templates. Instead a comment on it is added in Section 10 "SDP mode attributes for EVRC-NW". 5. In section 9 in the published specification you mention RFC3558 without a reference. I think that this document need also to be specified since it defines the RTP header and the usage. [Zheng] References are added. 6. In section 9 in the author field add your email address [Zheng] Done. 7. In section 9 change controller should be " IETF Audio/Video Transport working group delegated from the IESG." [Zheng] I am a little confused. The changed controller was indeed the same as you mentioned. Can you please point it out in case I miss anything? [roni} my mistake should be "IETF Payload working group delegated from the IESG" 8. In section 13 how is "mode-set-recv" used in declarative SDP since it is a decoder capability and not an encoder one. [Zheng] In some two-way conversation scenarios, the traffics can be asymmetric, i.e, incoming and outgoing streams use different sets of modes. It is sufficient to declare decoder capability and the encoder at the other side simply follows. [roni] Declarative is a one way announcement like in SAP for streaming media, so there is no encoder at the other side. Thanks Roni Even From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Thursday, August 18, 2011 2:49 PM To: payload@ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-evrc-nw-03 Hi, I would like to start a Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-03 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) The WGLC will end on September 9, 2011 Please review the draft and send comments to the list. Roni Even Payload co-chair --Boundary_(ID_MSkx+euCmSZWs6dE0G8IHQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Zheng,

OK

Regards

Roni

 

From:= = Fang, Zheng [mailto:zfang@qualcomm.com]
Sent: Wednesday, = October 05, 2011 1:40 AM
To: Roni Even; = payload@ietf.org
Cc: Fang, Zheng
Subject: RE: = [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Roni,

 

Thanks for the follow-up = comments.

 

I will modify the change = controller to be the Payload working group.

 

For the last question, = regarding declarative use of SDP parameters (copied in = below):

1.      = In section 13 how is "mode-set-recv" = used in declarative SDP since it is a decoder capability and not an = encoder one.

       &nb= sp;     [Zheng] In some two-way conversation = scenarios, the traffics can be asymmetric, i.e, incoming and outgoing = streams use different sets of modes. It is sufficient to declare decoder = capability and the encoder at the other side simply follows. =

        &= nbsp;    [roni] Declarative is a one way = announcement like in SAP for streaming media, so there is no encoder at = the other side.

 

I propose to add the following text to Section 13 = “Declarative SDP Considerations”:

o   The usage of unidirectional receive only parameters, = such as ‘mode-set-recv’, should be excluded in any = declarations, since these parameters are meaningless in one-way = streaming applications.

Any comments would be appreciated. =

Thanks,

Zheng

 

From:= = Roni Even [mailto:Even.roni@huawei.com]
Sent: Tuesday, = October 04, 2011 8:55 AM
To: Fang, Zheng; = payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun = (Jeff); Kandhadai, Ananthapadmanabhan (Ananth)
Subject: RE: = [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi Zheng,

See = inline

Roni

 

From:= = Fang, Zheng [mailto:zfang@qualcomm.com]
Sent: Tuesday, = October 04, 2011 2:44 AM
To: Roni Even; = payload@ietf.org
Cc: Wang, Min; Sinder, Dan; Huang, Pengjun = (Jeff); Kandhadai, Ananthapadmanabhan (Ananth); Fang, = Zheng
Subject: RE: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi = Roni,

 

Thank you for your comments and suggestions. = I updated the draft based on your suggestions. Please find attached the = modified text and diff.

 

I am not sure how to address some of the = comments. My answers to those questions are in line. I would appreciate = it if you could further comment on it.

 

I will submit a new version once I resolve = all the comments.

 

Thanks!

Zheng

 

From:= = Roni Even [mailto:Even.roni@huawei.com]
Sent: Monday, August = 29, 2011 4:35 AM
To: payload@ietf.org
Cc: Fang, = Zheng
Subject: RE: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I reviewed the draft and = have some comments.

 

2.       = It looks to me that this draft updates RFC3558 = similar to RFC 4788 and RFC 5188.  It should be referenced in the = header and in the text

[Zheng] = Although the payload definition of EVRCNW is similar to EVRCWB (RFC = 5188), EVRCB (RFC 4788) and EVRC (RFC 3558), the current draft only = defines the payload format for EVRCNW only. This is different than that = of RFC 5188, which not only defines a new MIME type (EVRC-WB) but also = update an existing MIME type (EVRC-B in RFC 4788). =

 

[roni] = OK

3.       = In section 6 first paragraph why not reference = 3788 where ToC is defined.

[Zheng] Reference is added. =

 

4.       = In second 9 in the registration template you = have sendmode deprecated. This is strange since this registration is a = new registration so there is nothing to deprecate . If you want to state = that this optional parameter that is used in other EVRC modes is not = used, please do it in another section and not in the registration = section.

[Zheng] The = sendmode descriptions are removed from the registration templates. = Instead a comment on it is added in Section 10 “SDP mode = attributes for EVRC-NW”.

 

5.       = In section 9 in the published specification you = mention RFC3558 without a reference. I think that this document need = also to be specified since it defines the RTP header and the = usage.

[Zheng] = References are added.

 

6.       = In section 9 in the author field add your email = address

[Zheng] = Done.

 

7.      = In section 9  change controller should be = " IETF Audio/Video Transport working group delegated from = the IESG."

[Zheng] I am a little confused. The changed = controller was indeed the same as you mentioned. Can you please point it = out in case I miss anything?

[roni} my mistake should = be "IETF Payload working group delegated from the = IESG"

 

8.      = In section 13 how is "mode-set-recv" = used in declarative SDP since it is a decoder capability and not an = encoder one.

[Zheng] In some two-way conversation = scenarios, the traffics can be asymmetric, i.e, incoming and outgoing = streams use different sets of modes. It is sufficient to declare decoder = capability and the encoder at the other side simply follows. =

[roni] Declarative is a one way announcement = like in SAP for streaming media, so there is no encoder at the other = side.

 

Thanks

Roni Even =

 

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Roni Even
Sent: Thursday, August 18, 2011 2:49 = PM
To: payload@ietf.org
Subject: [payload] WGLC on = draft-ietf-avt-rtp-evrc-nw-03

 

Hi,

I would =
like to start a Working Group Last Call on draft-i=
etf-avt-rtp-evrc-nw-03 , RTP =
payload format for Enhanced Variable Rate Narrowband-Wideband =
Codec  (EVRC-NW)

 

The WGLC will end on September 9, 2011

Please review the draft and send comments to the = list.

 

 

Roni = Even

Payload = co-chair

 

= --Boundary_(ID_MSkx+euCmSZWs6dE0G8IHQ)-- From Rea@worldcastsystems.com Wed Oct 5 08:34:06 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 0AB1321F8DF4 for ; Wed, 5 Oct 2011 08:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUFc2o+JpqOt for ; Wed, 5 Oct 2011 08:34:05 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id D485121F8DF3 for ; Wed, 5 Oct 2011 08:34:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 16:37:10 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D0290FC0E@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] draft-rea-avt-rtp-aptx-00 Thread-Index: AcyDdISaiRO1RMWBS7uiOMVSrAOtEA== From: "Derrick Rea" To: Subject: [payload] draft-rea-avt-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: Wed, 05 Oct 2011 15:34:06 -0000 Hi, The internet-draft, draft-rea-payload-rtp-aptx-00, is due to expire next = week and I ask whether it can be moved to the next stage of the INTERNET = STANDARDS TRACK.=20 I've only had one comment, from Colin Perkins, made against the draft = over the last six months and I've made a small change as a result = (Discussion and change below). Can I update the draft and still ask = that it be considered by the IESG? Regards, Derrick __________________________________________________________________ Proposed Update __________________________________________________________________ (As in draft-rea-payload-rtp-aptx-00) 5.1. RTP Header Usage o M - As per [RFC3550] o PT - Payload Type to be defined according to MIME allocation: audio/aptx __________________________________________________________________ (Proposed update) 5.1. RTP Header Usage o M - This payload format defines no use for this bit. Senders SHOULD set this bit to zero in each outgoing packet.=20 o PT - A dynamic payload type, i.e. one within the range [96..127], MUST be used. [RFC3551] __________________________________________________________________ __________________________________________________________________ Email Discussion __________________________________________________________________ ---- Audemat | Ecreso | APT Dr Derrick Rea Principal Engineer E-mail : Rea@worldcastsystems.com Tel : +44 (0) 28 9067 7200 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 http://www.audemat.com | http://www.ecreso.com | http://www.aptx.com = -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: 25 July 2011 15:53 To: Derrick Rea Subject: Re: [payload] draft-rea-avt-rtp-aptx-00 renamed = draft-rea-payload-rtp-aptx-00 Derrick, Apologies for the slow reply. The issue with in-band auxiliary and synchronisation data is just that = RTP provides its own mechanisms for synchronisation, and to carry SMPTE = time codes. It's generally better to avoid providing two different ways = of performing a single function, where possible. Colin On 3 May 2011, at 05:24, Derrick Rea wrote: > Colin, >=20 > Thanks for the comments. Sorry for the delay in responding but I've = been off on holiday. >=20 > I'll fix the M bit reference issue and change the "Payload Type to be = defined according to MIME allocation" statement to clarify that it's a = dynamic assignment, negotiated by signalling, in the next version of = this draft.=20 >=20 > I'm a bit unclear where the problems with in-band auxiliary and = synchronisation data occur in the internet-draft. Both are very popular = features of the Standard and Enhanced apt-X algorithms. I'm aware that = the details of how the algorithm encodes these into the bitstream isn't = fully transparent to the IETF community but the internet-draft is not = meant to specify how to encode and decode the apt-X streams, only how to = packetize the encoded apt-X streams. Can you please explain your = viewpoint a little more? >=20 > Derrick >=20 >=20 > ---- >=20 > Audemat | Ecreso | APT > Dr Derrick Rea > Principal Engineer > E-mail : Rea@worldcastsystems.com Tel : +44 (0) 28 9067 7200 >=20 > Head office: > 20, av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy > 33700 Bordeaux-M=E9rignac - FRANCE > Tel: +33 557 928 928 - Fax: +33 557 928 929 >=20 > http://www.audemat.com | http://www.ecreso.com | http://www.aptx.com=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: 27 April 2011 19:20 > To: Derrick Rea > Subject: Re: [payload] draft-rea-avt-rtp-aptx-00 renamed > draft-rea-payload-rtp-aptx-00 >=20 > Derrick, >=20 > On 18 Apr 2011, at 10:57, Derrick Rea wrote: >> 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 > This looks greatly improved compared to draft-trainor-avt-rtp-aptx-00. = My notes on that draft had a number of issues that look to be still = present in this version though: >=20 > - Use of M bit "as per RFC 3550", but RFC 3550 doesn't define audio = specific rules. Needs to refer to RFC 3551. >=20 > - "Payload Type to be defined according to MIME allocation" -> the = intent it clear, but the wording needs to be changed to clarify that = it's a dynamic assignment, negotiated by the signalling. >=20 > - Auxiliary and synchronisation data carried in-band is not ideal, but = possibly unavoidable given the nature of the codec. >=20 > Hope this is useful. > Colin >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 -- Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Thu Oct 6 00:51:34 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 1E55B21F8CCA; Thu, 6 Oct 2011 00:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n36SzK73wQcc; Thu, 6 Oct 2011 00:51:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD02721F8C9D; Thu, 6 Oct 2011 00:51:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111006075133.6333.89988.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 00:51:33 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-04.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: Thu, 06 Oct 2011 07:51:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-04.txt Pages : 28 Date : 2011-10-06 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-04.txt From zfang@qualcomm.com Thu Oct 6 00:54:46 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 51F8B21F8CF2 for ; Thu, 6 Oct 2011 00:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KruqiceEzQHu for ; Thu, 6 Oct 2011 00:54:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0E321F8CEC for ; Thu, 6 Oct 2011 00:54:45 -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=1317887875; x=1349423875; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip: content-type:content-transfer-encoding:mime-version; z=From:=20"Fang,=20Zheng"=20|To:=20"pa yload@ietf.org"=20|CC:=20"Fang,=20Zheng "=20|Subject:=20FW:=20[payload]=20I-D =20Action:=20draft-ietf-avt-rtp-evrc-nw-04.txt |Thread-Topic:=20[payload]=20I-D=20Action:=20draft-ietf-a vt-rtp-evrc-nw-04.txt|Thread-Index:=20AQHMg/03nsHJJSysfkO R2Hn8cZfVUJVu8o1w|Date:=20Thu,=206=20Oct=202011=2007:56:3 8=20+0000|Message-ID:=20|Accept-Language:=20en -US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.48.1] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=0LH33ucdnXL8q1buAzQNPhdkYetDMmPUBcCSn9Atl9k=; b=hhs2W0xmvMK65xrr3iLae6Lo0SW5CSBsIT1pgIldBEi0Ovb2oMnZGoVq aQ4UNIDegjwOoMwszirdVB2q+KfLpt/cSOo4oVH1srv1O0DADzoRF+W9U 8rpmyzoKcGqPfVTRG9rYKzsFC+dU69UXM6tYF9dL8ZygoNQnYLNR9smgU g=; X-IronPort-AV: E=McAfee;i="5400,1158,6490"; a="125211580" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 06 Oct 2011 00:57:55 -0700 X-IronPort-AV: E=Sophos;i="4.68,495,1312182000"; d="scan'208";a="139326765" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 06 Oct 2011 00:57:55 -0700 Received: from NASANEXD01A.na.qualcomm.com ([fe80::88b1:1c81:4562:8797]) by nasanexhc05.na.qualcomm.com ([::1]) with mapi id 14.01.0339.001; Thu, 6 Oct 2011 00:56:39 -0700 From: "Fang, Zheng" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-04.txt Thread-Index: AQHMg/03nsHJJSysfkOR2Hn8cZfVUJVu8o1w Date: Thu, 6 Oct 2011 07:56:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] FW: I-D Action: draft-ietf-avt-rtp-evrc-nw-04.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: Thu, 06 Oct 2011 07:54:46 -0000 Hi all,=20 This updated draft addresses Roni's previous comments.=20 Thanks, Zheng -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org Sent: Thursday, October 06, 2011 12:52 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-04.txt Pages : 28 Date : 2011-10-06 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-04.txt _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From magnus.westerlund@ericsson.com Thu Oct 6 06:50:37 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 9FAC321F8B7B for ; Thu, 6 Oct 2011 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpLUdhZrjzwp for ; Thu, 6 Oct 2011 06:50:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6E21F8B79 for ; Thu, 6 Oct 2011 06:50:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-13-4e8db2eaac63 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 02.E8.20773.AE2BD8E4; Thu, 6 Oct 2011 15:53:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 15:53:46 +0200 Message-ID: <4E8DB2E9.9040509@ericsson.com> Date: Thu, 6 Oct 2011 15:53:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "payload@ietf.org" X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [payload] Question regarding SVC (RFC 6190) 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, 06 Oct 2011 13:50:37 -0000 Hi, In my thinking of multi-stream handling I have considered SVC a bit. But I don't find anything in the RFC that specifies how a receiver actually determine in an MST usage the SSRCs in the various sessions that are actually caries NALUs associated with a particular source. The setup is a single end-point, with two video cameras and a microphone that captures a lecture hall, it sends these two video streams using multicast and MST NI-T packetization mode in lets say three different RTP sessions each on different multicast groups. This setup results in that each of the three RTP sessions will have two SSRCs in each session carrying either of the sessions. Both video cameras and thus all the SSRCs will be associated with the same CNAME as they are part of the same synchronization context and need to be synced with the audio stream coming from that room. Can someone please explain how a receiver can determine which SSRC that are to be bound together and carries NALUS part of the same source stream? Based on that the spec says that SSRC shall be assigned as RFC 3550 says, they don't carry the same value. Is this a big bug in the spec, needing a solution like SRCNAME we suggested in: https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ Or am I missing to find the explanation in the RFC. I will confess that I haven't read it from first to last word. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Thu Oct 6 06:53:49 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 CE53F21F8AF7 for ; Thu, 6 Oct 2011 06:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[AWL=-1.510, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPJ46IjGUqwP for ; Thu, 6 Oct 2011 06:53:49 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F721F8B95 for ; Thu, 6 Oct 2011 06:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2518; q=dns/txt; s=iport; t=1317909419; x=1319119019; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=bRpVL4SiVtFDDK1Er4wIEZNdt43T/SpX5DKA195O5mU=; b=WLNUAo9m+QSJlg6+rzEg+omjmZYcvt1qlnYcwbiORcuzNPOXlt/PwSKu ZaooEyJPev94aKtssGhZBhmNccTKTnJODez5CGn6WD8Z0v8M6QwhiXI7v gix4o31nmlvm1T2NS6t8tENvUQlg2LcYmRjbd2ghAsRBudI8dPalU87Zf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAKSyjU6rRDoH/2dsb2JhbABEmRePHIEFgVMBAQEEAQEBCQYBHTcHFwICAgEIEQQBAQsGFwEGARoMHwkIAQEEARIIEweHY5hiAZ4hAwKGSWEEh32RIow1 X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="6289686" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 06 Oct 2011 13:56:58 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p96DuwmK032589; Thu, 6 Oct 2011 13:56:58 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 06:56:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 06:56:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5410097560@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E8DB2E9.9040509@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Question regarding SVC (RFC 6190) Thread-Index: AcyEL2HWtUzaJ/4qTHCes42nrzLkbwAAFyIA References: <4E8DB2E9.9040509@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 06 Oct 2011 13:56:57.0666 (UTC) FILETIME=[D01AFA20:01CC842F] Subject: Re: [payload] Question regarding SVC (RFC 6190) 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, 06 Oct 2011 13:53:49 -0000 Grouping (a:group or ssrc-group) handles that, no? > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Magnus Westerlund > Sent: Thursday, October 06, 2011 9:54 AM > To: payload@ietf.org > Subject: [payload] Question regarding SVC (RFC 6190) >=20 > Hi, >=20 > In my thinking of multi-stream handling I have considered SVC a bit. = But > I don't find anything in the RFC that specifies how a receiver = actually > determine in an MST usage the SSRCs in the various sessions that are > actually caries NALUs associated with a particular source. >=20 > The setup is a single end-point, with two video cameras and a = microphone > that captures a lecture hall, it sends these two video streams using > multicast and MST NI-T packetization mode in lets say three different > RTP sessions each on different multicast groups. >=20 > This setup results in that each of the three RTP sessions will have = two > SSRCs in each session carrying either of the sessions. Both video > cameras and thus all the SSRCs will be associated with the same CNAME = as > they are part of the same synchronization context and need to be = synced > with the audio stream coming from that room. >=20 > Can someone please explain how a receiver can determine which SSRC = that > are to be bound together and carries NALUS part of the same source = stream? >=20 > Based on that the spec says that SSRC shall be assigned as RFC 3550 > says, they don't carry the same value. >=20 > Is this a big bug in the spec, needing a solution like SRCNAME we > suggested in: > = https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and= -simulcast/ >=20 > Or am I missing to find the explanation in the RFC. I will confess = that > I haven't read it from first to last word. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From magnus.westerlund@ericsson.com Thu Oct 6 07:38:53 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 88D1421F8C1E for ; Thu, 6 Oct 2011 07:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxzVeCeC2CwW for ; Thu, 6 Oct 2011 07:38:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A649B21F8A55 for ; Thu, 6 Oct 2011 07:38:52 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-96-4e8dbe393d39 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.AA.20773.93EBD8E4; Thu, 6 Oct 2011 16:42:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 16:41:56 +0200 Message-ID: <4E8DBE2F.60002@ericsson.com> Date: Thu, 6 Oct 2011 16:41:51 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E8DB2E9.9040509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5410097560@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5410097560@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "payload@ietf.org" Subject: Re: [payload] Question regarding SVC (RFC 6190) 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, 06 Oct 2011 14:38:53 -0000 On 2011-10-06 15:56, Ali C. Begen (abegen) wrote: > Grouping (a:group or ssrc-group) handles that, no? Well, group is part of the examples using the DDP (Decoding Dependency) semantics to group the RTP sessions together. However, that doesn't resolve the SSRC grouping issue. And a=ssrc-group can only group SSRC within a single RTP session. It can't group the SSRCs from several sessions as being related. Cheers Magnus > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Thursday, October 06, 2011 9:54 AM >> To: payload@ietf.org >> Subject: [payload] Question regarding SVC (RFC 6190) >> >> Hi, >> >> In my thinking of multi-stream handling I have considered SVC a bit. But >> I don't find anything in the RFC that specifies how a receiver actually >> determine in an MST usage the SSRCs in the various sessions that are >> actually caries NALUs associated with a particular source. >> >> The setup is a single end-point, with two video cameras and a microphone >> that captures a lecture hall, it sends these two video streams using >> multicast and MST NI-T packetization mode in lets say three different >> RTP sessions each on different multicast groups. >> >> This setup results in that each of the three RTP sessions will have two >> SSRCs in each session carrying either of the sessions. Both video >> cameras and thus all the SSRCs will be associated with the same CNAME as >> they are part of the same synchronization context and need to be synced >> with the audio stream coming from that room. >> >> Can someone please explain how a receiver can determine which SSRC that >> are to be bound together and carries NALUS part of the same source stream? >> >> Based on that the spec says that SSRC shall be assigned as RFC 3550 >> says, they don't carry the same value. >> >> Is this a big bug in the spec, needing a solution like SRCNAME we >> suggested in: >> https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ >> >> Or am I missing to find the explanation in the RFC. I will confess that >> I haven't read it from first to last word. >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Thu Oct 6 07:48:44 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 EB78021F8C81 for ; Thu, 6 Oct 2011 07:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.972 X-Spam-Level: X-Spam-Status: No, score=-3.972 tagged_above=-999 required=5 tests=[AWL=-1.373, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0ebQggsiVzK for ; Thu, 6 Oct 2011 07:48:44 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC121F8C19 for ; Thu, 6 Oct 2011 07:48:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=4112; q=dns/txt; s=iport; t=1317912715; x=1319122315; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4E+GScEqPL65phWY61SNW0HYAWshuyCS6G+uxQlKrPk=; b=KiJBak7jG0jV5EBTfIEVSQ0Ay7w6xGnE6sPVe+x/UcxwdafD48MbJWFu WkX6Qb7HpNoR9Zp7VL86VQj6+2a4cHg3c6+tosu9+ymvhtbgvHhEDhTBi zkh4+jSAu7zDXJDwA9X55fRgCKV1cTlQV8TktcQG8zUbjKR+OWC2V4hL4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAEDAjU6rRDoH/2dsb2JhbABDmRePHIEFgVMBAQEEAQEBCQYBHTcHCwwCAgIBCBEEAQEBCgYXAQYBGgwfCQgBAQQTCBMHh2OZGwGeHwMChklhBId9kSKMNQ X-IronPort-AV: E=Sophos;i="4.68,496,1312156800"; d="scan'208";a="6313780" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 06 Oct 2011 14:51:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p96EpfRs028987; Thu, 6 Oct 2011 14:51:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 07:51:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Oct 2011 07:51:27 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541009757D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E8DBE2F.60002@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Question regarding SVC (RFC 6190) Thread-Index: AcyENh32du/O+u8OS2+/gubguUFkXQAATFng References: <4E8DB2E9.9040509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5410097560@xmb-sjc-215.amer.cisco.com> <4E8DBE2F.60002@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 06 Oct 2011 14:51:41.0058 (UTC) FILETIME=[7528D620:01CC8437] Cc: payload@ietf.org Subject: Re: [payload] Question regarding SVC (RFC 6190) 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, 06 Oct 2011 14:48:45 -0000 I agree that those semantics can satisfy your needs in certain scenarios = but not all. But the question is whether you need to cover every = possible scenario with such semantics or produce new semantics for that = purpose. -acbegen > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, October 06, 2011 10:42 AM > To: Ali C. Begen (abegen) > Cc: payload@ietf.org > Subject: Re: [payload] Question regarding SVC (RFC 6190) >=20 > On 2011-10-06 15:56, Ali C. Begen (abegen) wrote: > > Grouping (a:group or ssrc-group) handles that, no? >=20 > Well, group is part of the examples using the DDP (Decoding = Dependency) > semantics to group the RTP sessions together. However, that doesn't > resolve the SSRC grouping issue. >=20 > And a=3Dssrc-group can only group SSRC within a single RTP session. It > can't group the SSRCs from several sessions as being related. >=20 > Cheers >=20 > Magnus >=20 > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Magnus Westerlund > >> Sent: Thursday, October 06, 2011 9:54 AM > >> To: payload@ietf.org > >> Subject: [payload] Question regarding SVC (RFC 6190) > >> > >> Hi, > >> > >> In my thinking of multi-stream handling I have considered SVC a = bit. But > >> I don't find anything in the RFC that specifies how a receiver = actually > >> determine in an MST usage the SSRCs in the various sessions that = are > >> actually caries NALUs associated with a particular source. > >> > >> The setup is a single end-point, with two video cameras and a = microphone > >> that captures a lecture hall, it sends these two video streams = using > >> multicast and MST NI-T packetization mode in lets say three = different > >> RTP sessions each on different multicast groups. > >> > >> This setup results in that each of the three RTP sessions will have = two > >> SSRCs in each session carrying either of the sessions. Both video > >> cameras and thus all the SSRCs will be associated with the same = CNAME as > >> they are part of the same synchronization context and need to be = synced > >> with the audio stream coming from that room. > >> > >> Can someone please explain how a receiver can determine which SSRC = that > >> are to be bound together and carries NALUS part of the same source = stream? > >> > >> Based on that the spec says that SSRC shall be assigned as RFC 3550 > >> says, they don't carry the same value. > >> > >> Is this a big bug in the spec, needing a solution like SRCNAME we > >> suggested in: > >> = https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and= -simulcast/ > >> > >> Or am I missing to find the explanation in the RFC. I will confess = that > >> I haven't read it from first to last word. > >> > >> Cheers > >> > >> Magnus Westerlund > >> > >> = ---------------------------------------------------------------------- > >> Multimedia Technologies, Ericsson Research EAB/TVM > >> = ---------------------------------------------------------------------- > >> Ericsson AB | Phone +46 10 7148287 > >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 > >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > >> = ---------------------------------------------------------------------- > >> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From ietf-ipr@ietf.org Thu Oct 6 08:40:56 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 9FAFD21F8C8E; Thu, 6 Oct 2011 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yxb-kuNP7f0O; Thu, 6 Oct 2011 08:40:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9421F8BCD; Thu, 6 Oct 2011 08:40:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: patrik.westin@gmail.com, hlundin@google.com, X-Test-IDTracker: no Message-ID: <20111006154056.26687.91806.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2011 08:40:56 -0700 Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload-vp8-01 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, 06 Oct 2011 15:40:56 -0000 Dear Patrik Westin, Henrik Lundin, Michael Glover, Justin Uberti, Frank Gal= ligan: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Paylo= ad Format for VP8 Video" (draft-ietf-payload-vp8) was submitted to the IETF Secretariat on 2011-10-05 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1622/). The = title of the IPR disclosure is "Vidyo, Inc.'s Statement about IPR related to draf= t- ietf-payload-vp8-01.""); The IETF Secretariat From Even.roni@huawei.com Thu Oct 6 11:21:51 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 B02FE21F8E05 for ; Thu, 6 Oct 2011 11:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.343 X-Spam-Level: X-Spam-Status: No, score=-106.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eVoTfVLxV3r for ; Thu, 6 Oct 2011 11:21:50 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5521F8E04 for ; Thu, 6 Oct 2011 11:21:49 -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 <0LSN00HQYPTMPT@szxga05-in.huawei.com> for payload@ietf.org; Fri, 07 Oct 2011 02:24:58 +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 <0LSN002Z1PTMDN@szxga05-in.huawei.com> for payload@ietf.org; Fri, 07 Oct 2011 02:24:58 +0800 (CST) Received: from windows8d787f9 ([109.64.200.234]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LSN00BFFPTBBV@szxml12-in.huawei.com> for payload@ietf.org; Fri, 07 Oct 2011 02:24:58 +0800 (CST) Date: Thu, 06 Oct 2011 20:21:58 +0200 From: Roni Even To: payload@ietf.org Message-id: <069201cc8454$dd1df8b0$9759ea10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcyEPs4/dkRyPeFwQRWtNj/T/g1zKQAFfz5Q Subject: [payload] FW: IPR Disclosure: Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload-vp8-01 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, 06 Oct 2011 18:21:51 -0000 FYI -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org] Sent: Thursday, October 06, 2011 5:41 PM To: patrik.westin@gmail.com; hlundin@google.com Cc: gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; payload@ietf.org; Even.roni@huawei.com; abegen@cisco.com; ipr-announce@ietf.org Subject: IPR Disclosure: Vidyo, Inc.'s Statement about IPR related to draft-ietf-payload-vp8-01 Dear Patrik Westin, Henrik Lundin, Michael Glover, Justin Uberti, Frank Galligan: An IPR disclosure that pertains to your Internet-Draft entitled "RTP Payload Format for VP8 Video" (draft-ietf-payload-vp8) was submitted to the IETF Secretariat on 2011-10-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1622/). The title of the IPR disclosure is "Vidyo, Inc.'s Statement about IPR related to draft- ietf-payload-vp8-01.""); The IETF Secretariat From magnus.westerlund@ericsson.com Fri Oct 7 00:13:37 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 4BD5121F8B47 for ; Fri, 7 Oct 2011 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.487 X-Spam-Level: X-Spam-Status: No, score=-106.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwHolJSPUfNN for ; Fri, 7 Oct 2011 00:13:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4610921F8B45 for ; Fri, 7 Oct 2011 00:13:35 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a7-4e8ea760f320 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.115.81]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B2.5C.20773.067AE8E4; Fri, 7 Oct 2011 09:16:48 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 09:16:26 +0200 Message-ID: <4E8EA748.50209@ericsson.com> Date: Fri, 7 Oct 2011 09:16:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E8DB2E9.9040509@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D5410097560@xmb-sjc-215.amer.cisco.com> <4E8DBE2F.60002@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D541009757D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D541009757D@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "payload@ietf.org" Subject: Re: [payload] Question regarding SVC (RFC 6190) 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, 07 Oct 2011 07:13:37 -0000 On 2011-10-06 16:51, Ali C. Begen (abegen) wrote: > I agree that those semantics can satisfy your needs in certain > scenarios but not all. But the question is whether you need to cover > every possible scenario with such semantics or produce new semantics > for that purpose. >From an SVC perspective it is clear that this issue only arises in MST sessions. And in reality it only becomes a real problem when a given CNAME sends more than a single SVC encoded source. >From my perspective, the reasonable thing to do is to put it on the issue list for thing that needs a solution when developing scalable or other payload formats that has relation between SSRC and their packet flows, especially in other RTP sessions. I think the general topic should be discussed in AVTCORE but clearly PAYLOAD interest must be involved. An Ericsson co-author and I will submit before the deadline a draft discussing RTP's multi-stream architecture in a general case. This is a follow up on the https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-and-simulcast/ that I presented in Quebec in AVTCORE. When we agree on a general direction for handling these type of issues, PAYLOAD WG can consider to update the SVC payload format to resolve the identified issue following those agreements. Cheers Magnus Westerlund (As individual) ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jonathan@vidyo.com Sun Oct 9 19:15:50 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 2FC2C21F8560 for ; Sun, 9 Oct 2011 19:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbNsixRsEZK9 for ; Sun, 9 Oct 2011 19:15:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id B99C021F854E for ; Sun, 9 Oct 2011 19:15:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9EFB4416DE9; Sun, 9 Oct 2011 22:15:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2B861416D9A; Sun, 9 Oct 2011 22:15:39 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Sun, 9 Oct 2011 22:15:17 -0400 From: Jonathan Lennox To: Magnus Westerlund Date: Sun, 9 Oct 2011 22:15:36 -0400 Thread-Topic: [payload] Question regarding SVC (RFC 6190) Thread-Index: AcyG8nz0r7rf0nQiS+yA2Gb7L7tQTQ== Message-ID: References: <4E8DB2E9.9040509@ericsson.com> In-Reply-To: <4E8DB2E9.9040509@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Question regarding SVC (RFC 6190) 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, 10 Oct 2011 02:15:50 -0000 Hi, Magnus -- On Oct 6, 2011, at 9:53 AM, Magnus Westerlund wrote: > Hi, >=20 > In my thinking of multi-stream handling I have considered SVC a bit. But > I don't find anything in the RFC that specifies how a receiver actually > determine in an MST usage the SSRCs in the various sessions that are > actually caries NALUs associated with a particular source. [...] > Based on that the spec says that SSRC shall be assigned as RFC 3550 > says, they don't carry the same value. RFC 6190 doesn't explicitly say it, and I agree that's a flaw, but I was ce= rtainly under the impression that for mutli-session MST, the relevant part = of 3550 was section 8.3: 8.3 Use with Layered Encodings For layered encodings transmitted on separate RTP sessions (see Section 2.4), a single SSRC identifier space SHOULD be used across the sessions of all layers and the core (base) layer SHOULD be used for SSRC identifier allocation and collision resolution. When a source discovers that it has collided, it transmits an RTCP BYE packet on only the base layer but changes the SSRC identifier to the new value in all layers. That said, I think there would definitely be value in a way to do cross-ses= sion SSRC grouping, whether that's in RTCP or in SDP (or both). -- Jonathan Lennox jonathan@vidyo.com From gjshep@gmail.com Mon Oct 10 13:03:23 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 6090B21F8C17; Mon, 10 Oct 2011 13:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhqmnWwzbeUA; Mon, 10 Oct 2011 13:03:23 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72E8E21F8BE7; Mon, 10 Oct 2011 13:03:22 -0700 (PDT) Received: by bkaq10 with SMTP id q10so9803433bka.31 for ; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=ELOZPE0XyNa14ZGfHudpGpDFVJXy9EqDPvYz0ApYt1s=; b=E5t9Il+3GG1SLaIwxcytr70No9e6ILb73EmLZpHZTmqH2hcJZidSn1pbjK5p6nb2zU h7nV0KLUOvdSq3COe3ta5E0A4lQhhwAARFljHr34W769psj8NcZ6M+H8kNEP0jewJS4u 7lWasgyBQTaUsfCANX4Ve1wJAcisbDcIm5vxE= MIME-Version: 1.0 Received: by 10.204.136.12 with SMTP id p12mr7248960bkt.26.1318277001435; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) Received: by 10.204.56.148 with HTTP; Mon, 10 Oct 2011 13:03:21 -0700 (PDT) Date: Mon, 10 Oct 2011 13:03:21 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org, payload@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 10 Oct 2011 17:26:30 -0700 Subject: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gjshep@gmail.com 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, 10 Oct 2011 20:03:23 -0000 Please read, review, comment - a comment of support is also helpful - ASAP. This WG is very close to being finished and this is one of the few last bits. http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt Thanks!, Greg From hlundin@google.com Wed Oct 12 07:26:16 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 C442021F8B5C for ; Wed, 12 Oct 2011 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.603 X-Spam-Level: X-Spam-Status: No, score=-103.603 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iC4CEOnemrX for ; Wed, 12 Oct 2011 07:26:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2986621F8B52 for ; Wed, 12 Oct 2011 07:26:15 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p9CEQDvh003232 for ; Wed, 12 Oct 2011 07:26:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318429573; bh=7G4KLbRlOv86dJVNZdMmx0t+TvY=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=GJ7zON5eswq9bZA26D7FiBCo1Fon+beE09Uv1Ln9NI3g6DZuilO0xLgWFb7KQw7rW TUJl230ypO9tYiJfhDPDA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to: content-type:x-system-of-record; b=muZYYMeVV8rQ+Giu5Wf9E2c3Hf/5mJZY4W9wpRm8tHuRupX3QknkjAtNI5HYYVWR5 bsTtOU5UcrOLWDcUsUKrQ== Received: from vcbfl11 (vcbfl11.prod.google.com [10.220.204.75]) by wpaz33.hot.corp.google.com with ESMTP id p9CEL5ai003564 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 12 Oct 2011 07:26:12 -0700 Received: by vcbfl11 with SMTP id fl11so1220242vcb.4 for ; Wed, 12 Oct 2011 07:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; bh=E3o6j/RoWtCQrxPTVAgTwsdDRUGZlKpPGTpHeGkj1r0=; b=VVcBNCPqhftL5avJdhgM2xQYANV92IAZyYtl7nbS4ux+ZFs9NuMF1DG+lzcdA8MnTU S5Gw7AEuO/YUT0IDjs2g== Received: by 10.100.56.25 with SMTP id e25mr796375ana.70.1318429570295; Wed, 12 Oct 2011 07:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.56.25 with SMTP id e25mr796371ana.70.1318429570174; Wed, 12 Oct 2011 07:26:10 -0700 (PDT) Received: by 10.100.166.9 with HTTP; Wed, 12 Oct 2011 07:26:10 -0700 (PDT) Date: Wed, 12 Oct 2011 16:26:10 +0200 Message-ID: From: Henrik Lundin To: payload@ietf.org Content-Type: multipart/alternative; boundary=0016e647661c310edd04af1acebe X-System-Of-Record: true Subject: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 14:26:16 -0000 --0016e647661c310edd04af1acebe Content-Type: text/plain; charset=ISO-8859-1 I'd like to get the payload list readers' opinions on the topic of extended sequence numbers. In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb, it must not be possible to wrap the sequence number space in less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can happen, one should provide an extended sequence number field. Some quick calculations reveal that at an MTU size of 1500 bytes, a video bitrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes. It seems to me that the recently written RTP payload format for H.264/AVC and H.264/SVC does not mention sequence number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this. What is your opinion on this matter? Should future video RTP formats follow what the HOWTO suggests, or stick to current practice as manifested in the H.264 formats? Thanks for your input, /Henrik -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e647661c310edd04af1acebe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to get the payload list readers' opinions on the topic of = extended sequence numbers.

In=A0draft-ietf-payload-rtp-h= owto-01, Section 5.1.6, it is stated that "as a rule of thumb,=A0it mu= st not=A0be possible to wrap the sequence number space in less than 2 minut= es=A0(TCP maximum segment lifetime)". If earlier wrapping can happen, = one should provide an extended sequence number field.

Some quick calculations reveal that at an MTU size= of 1500 bytes, a=A0video bitrate of=A0approximately 6.5 Mbps is sufficient= to produce 2^16 (jam-packed) packets in 2 minutes.

It seems to me that the recently written RTP payload format for H.264/= AVC and H.264/SVC does not mention sequence number extension (please, corre= ct me if I'm wrong). Nor does the older H.263 RTP format mention this.<= /div>

What is your opinion on this matter? Should future vide= o RTP formats follow what the HOWTO suggests, or stick to current practice = as manifested in the H.264 formats?

Thanks for you= r input,
/Henrik

--=A0
Henrik Lundin=A0|=A0WebRTC So= ftware Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 646 13 41


--0016e647661c310edd04af1acebe-- From abegen@cisco.com Wed Oct 12 07:35:06 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 961D821F8B9A for ; Wed, 12 Oct 2011 07:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJwLlsb2D-ar for ; Wed, 12 Oct 2011 07:35:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9721F8B91 for ; Wed, 12 Oct 2011 07:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1570; q=dns/txt; s=iport; t=1318430106; x=1319639706; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=yGoJAEbSyJLqfDlBbNumbvXbO9TbHWZvs+bWmX0fnlo=; b=I6/Bpc63/2DGNt26xExTeLwUVgqvLPKoM5of/6R5xhLN5XgJdOXjY85A uJ+lY4exZ9oh+QygwMO27P5Zjv4Hfmvrj9LcNQcjyKYZsy1sQrGSM8H5e rMF5nDqQAxrCIqCryA+hzGu1Cl1Q8w9RgI9CkGdCw3NCWXxH/Low5ESFC 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnAAAC2llU6rRDoJ/2dsb2JhbABDmRSMcYIugQWBUwEBAQQSAR1VBAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIGqNCAZ5shndhBId/kSeMQw X-IronPort-AV: E=Sophos;i="4.69,334,1315180800"; d="scan'208";a="7419565" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 12 Oct 2011 14:35:05 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9CEZ5M1031217; Wed, 12 Oct 2011 14:35:05 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 07:35:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Oct 2011 07:34:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541013E04E@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Extended sequence numbers and video payloads Thread-Index: AcyI6uvkJ+YhyzOMS/65tSTxXSMRYQAARFeQ References: From: "Ali C. Begen (abegen)" To: "Henrik Lundin" , X-OriginalArrivalTime: 12 Oct 2011 14:35:05.0633 (UTC) FILETIME=[22518910:01CC88EC] Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 14:35:06 -0000 Extended seqnum is something you report in RTCP, which has provisions = for it already. Or did I misread your question? -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Henrik Lundin > Sent: Wednesday, October 12, 2011 10:26 AM > To: payload@ietf.org > Subject: [payload] Extended sequence numbers and video payloads >=20 > I'd like to get the payload list readers' opinions on the topic of = extended sequence numbers. >=20 > In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that = "as a rule of thumb, it must not be possible to wrap the > sequence number space in less than 2 minutes (TCP maximum segment = lifetime)". If earlier wrapping can happen, one > should provide an extended sequence number field. >=20 > Some quick calculations reveal that at an MTU size of 1500 bytes, a = video bitrate of approximately 6.5 Mbps is sufficient to > produce 2^16 (jam-packed) packets in 2 minutes. >=20 > It seems to me that the recently written RTP payload format for = H.264/AVC and H.264/SVC does not mention sequence > number extension (please, correct me if I'm wrong). Nor does the older = H.263 RTP format mention this. >=20 > What is your opinion on this matter? Should future video RTP formats = follow what the HOWTO suggests, or stick to current > practice as manifested in the H.264 formats? >=20 > Thanks for your input, > /Henrik >=20 > -- > Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 = 13 41 >=20 >=20 From stewe@stewe.org Wed Oct 12 07:43:17 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 D2AE421F8B86 for ; Wed, 12 Oct 2011 07:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48Sx697v3cML for ; Wed, 12 Oct 2011 07:43:17 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id C850E21F8B68 for ; Wed, 12 Oct 2011 07:43:16 -0700 (PDT) Received: from [10.0.0.12] (unverified [140.242.250.10]) by stewe.org (SurgeMail 3.9e) with ESMTP id 48928-1743317 for multiple; Wed, 12 Oct 2011 16:43:14 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 12 Oct 2011 10:43:06 -0400 From: Stephan Wenger To: Message-ID: Thread-Topic: [payload] Extended sequence numbers and video payloads In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3401260993_4160163" X-Originating-IP: 140.242.250.10 X-Authenticated-User: stewe@stewe.org Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 14:43:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3401260993_4160163 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The motivation behind the two minute rule never compelled me. However, even if it were deemed compelling by the folks here, the place to introduce longer sequence numbers would IMO have to be a generic "high nitrate" extension header, rather a payload format. Stephan From: Henrik Lundin Date: Wed, 12 Oct 2011 16:26:10 +0200 To: Subject: [payload] Extended sequence numbers and video payloads I'd like to get the payload list readers' opinions on the topic of extended sequence numbers. In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb, it must not be possible to wrap the sequence number space in less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can happen, one should provide an extended sequence number field. Some quick calculations reveal that at an MTU size of 1500 bytes, a video bitrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes. It seems to me that the recently written RTP payload format for H.264/AVC and H.264/SVC does not mention sequence number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this. What is your opinion on this matter? Should future video RTP formats follow what the HOWTO suggests, or stick to current practice as manifested in the H.264 formats? Thanks for your input, /Henrik -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --B_3401260993_4160163 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
The motivation behind the tw= o minute rule never compelled me.  However, even if it were deemed comp= elling by the folks here, the place to introduce longer sequence numbers wou= ld IMO have to be a generic "high nitrate" extension header, rather a payloa= d format.
Stephan


From: Henrik Lundin <hlundin@google.com>
Date: Wed, 12 Oct 2011 16:26:10 +0200
To: = <payload@ietf.org>
Subject: [payload] Extended sequence nu= mbers and video payloads

I'd like to get the payload= list readers' opinions on the topic of extended sequence numbers.

<= /div>
In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stat= ed that "as a rule of thumb, it must not be possible to wrap the s= equence number space in less than 2 minutes (TCP maximum segment lifeti= me)". If earlier wrapping can happen, one should provide an extended sequenc= e number field.

Some quick calculations reveal= that at an MTU size of 1500 bytes, a video bitrate of approximate= ly 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes.=

It seems to me that the recently written RTP= payload format for H.264/AVC and H.264/SVC does not mention sequence number= extension (please, correct me if I'm wrong). Nor does the older H.263 RTP f= ormat mention this.

What is your opinion on this ma= tter? Should future video RTP formats follow what the HOWTO suggests, or sti= ck to current practice as manifested in the H.264 formats?

Thanks for your input,
/Henrik

-- 
Henrik Lundin&n= bsp;| WebRTC Software Eng | hlundin@google.com | +46 70 646 1= 3 41


= _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.or= g/mailman/listinfo/payload --B_3401260993_4160163-- From hlundin@google.com Wed Oct 12 07:59:40 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 199B521F8C10 for ; Wed, 12 Oct 2011 07:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.347 X-Spam-Level: X-Spam-Status: No, score=-104.347 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqDHBo+NK9jx for ; Wed, 12 Oct 2011 07:59:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5937121F8BEB for ; Wed, 12 Oct 2011 07:59:39 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p9CExcHL018319 for ; Wed, 12 Oct 2011 07:59:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318431578; bh=dC/PMDfs9ULAl+NhOg55MSF41S4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=w/ZdUb7mBqkNlVHWaXCpmDSC4d23eHbeOz6wwnOdmKHx9qXemtuR509AmTFr3IHXy QhJDDTqdOtXo9CIWD6peQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=AYr+41ebXko6NTy9ceptSIJFsTp1uGfxIUDZz3pEFF00+9MHL2unpVoEEvkvVAEFm 4tA1Wz2dwwqiuLhu9w9fw== Received: from vcbfk14 (vcbfk14.prod.google.com [10.220.204.14]) by wpaz37.hot.corp.google.com with ESMTP id p9CEulUw024192 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 12 Oct 2011 07:59:37 -0700 Received: by vcbfk14 with SMTP id fk14so489457vcb.10 for ; Wed, 12 Oct 2011 07:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JHskct3pD9hVRsFQnIfYBAsYwF8Wcta43XcgAIWFgbU=; b=HeVR21V+cwsCofhFdzLZ3cyS2sMcxbGE74+xO1DfagvikdlEbHmH3GIbqS8U+j9NWM V6fRt2l2al0uJuJ34ppQ== Received: by 10.101.149.28 with SMTP id b28mr2952721ano.114.1318431577196; Wed, 12 Oct 2011 07:59:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.149.28 with SMTP id b28mr2952710ano.114.1318431576998; Wed, 12 Oct 2011 07:59:36 -0700 (PDT) Received: by 10.100.166.9 with HTTP; Wed, 12 Oct 2011 07:59:36 -0700 (PDT) In-Reply-To: References: <04CAD96D4C5A3D48B1919248A8FE0D541013E04E@xmb-sjc-215.amer.cisco.com> Date: Wed, 12 Oct 2011 16:59:36 +0200 Message-ID: From: Henrik Lundin To: Stephan Wenger Content-Type: multipart/alternative; boundary=0016e68ef096cec44c04af1b459d X-System-Of-Record: true Cc: payload@ietf.org Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 14:59:40 -0000 --0016e68ef096cec44c04af1b459d Content-Type: text/plain; charset=ISO-8859-1 True, I am talking about the sequence number field in the RTP header. /Henrik On Wed, Oct 12, 2011 at 4:43 PM, Stephan Wenger wrote: > I think he's talking about the 16 bit sequence number field in the RTP > header. > Stephan > > On 10.12.2011 10:34 , "Ali C. Begen (abegen)" wrote: > > >Extended seqnum is something you report in RTCP, which has provisions for > >it already. Or did I misread your question? > > > >-acbegen > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >>Behalf Of Henrik Lundin > >> Sent: Wednesday, October 12, 2011 10:26 AM > >> To: payload@ietf.org > >> Subject: [payload] Extended sequence numbers and video payloads > >> > >> I'd like to get the payload list readers' opinions on the topic of > >>extended sequence numbers. > >> > >> In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that > >>"as a rule of thumb, it must not be possible to wrap the > >> sequence number space in less than 2 minutes (TCP maximum segment > >>lifetime)". If earlier wrapping can happen, one > >> should provide an extended sequence number field. > >> > >> Some quick calculations reveal that at an MTU size of 1500 bytes, a > >>video bitrate of approximately 6.5 Mbps is sufficient to > >> produce 2^16 (jam-packed) packets in 2 minutes. > >> > >> It seems to me that the recently written RTP payload format for > >>H.264/AVC and H.264/SVC does not mention sequence > >> number extension (please, correct me if I'm wrong). Nor does the older > >>H.263 RTP format mention this. > >> > >> What is your opinion on this matter? Should future video RTP formats > >>follow what the HOWTO suggests, or stick to current > >> practice as manifested in the H.264 formats? > >> > >> Thanks for your input, > >> /Henrik > >> > >> -- > >> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 > >>13 41 > >> > >> > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > > -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --0016e68ef096cec44c04af1b459d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable True, I am talking about the sequence number field in the RTP header.
<= br>
/Henrik


On Wed, = Oct 12, 2011 at 4:43 PM, Stephan Wenger <stewe@stewe.org> wrote:
I think he's talking about the 16 bit s= equence number field in the RTP
header.
Stephan

On 10.12.2011 10:34 , "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

>Extended seqnum is something you report in RTCP, which has provisions f= or
>it already. Or did I misread your question?
>
>-acbegen
>
>> -----Original Message-----
>> From: payload-bounces@= ietf.org [mailto:payload-bo= unces@ietf.org] On
>>Behalf Of Henrik Lundin
>> Sent: Wednesday, October 12, 2011 10:26 AM
>> To: payload@ietf.org
>> Subject: [payload] Extended sequence numbers and video payloads >>
>> I'd like to get the payload list readers' opinions on the = topic of
>>extended sequence numbers.
>>
>> In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated th= at
>>"as a rule of thumb, it must not be possible to wrap the
>> sequence number space in less than 2 minutes (TCP maximum segment<= br> >>lifetime)". If earlier wrapping can happen, one
>> should provide an extended sequence number field.
>>
>> Some quick calculations reveal that at an MTU size of 1500 bytes, = a
>>video bitrate of approximately 6.5 Mbps is sufficient to
>> produce 2^16 (jam-packed) packets in 2 minutes.
>>
>> It seems to me that the recently written RTP payload format for >>H.264/AVC and H.264/SVC does not mention sequence
>> number extension (please, correct me if I'm wrong). Nor does t= he older
>>H.263 RTP format mention this.
>>
>> What is your opinion on this matter? Should future video RTP forma= ts
>>follow what the HOWTO suggests, or stick to current
>> practice as manifested in the H.264 formats?
>>
>> Thanks for your input,
>> /Henrik
>>
>> --
>> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646
>>13 41
>>
>>
>
>___________________= ____________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload





--
=
Henrik Lundin=A0|=A0WebRTC Software Eng=A0|=A0hlundin@google.com=A0|=A0+46 70 64= 6 13 41


--0016e68ef096cec44c04af1b459d-- From stewe@stewe.org Wed Oct 12 08:00:32 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 CB53321F8BEC for ; Wed, 12 Oct 2011 08:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W39GKU--qFe for ; Wed, 12 Oct 2011 08:00:32 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6B21F8BF9 for ; Wed, 12 Oct 2011 08:00:31 -0700 (PDT) Received: from [10.0.0.12] (unverified [140.242.250.10]) by stewe.org (SurgeMail 3.9e) with ESMTP id 48930-1743317 for multiple; Wed, 12 Oct 2011 16:44:06 +0200 User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 12 Oct 2011 10:43:40 -0400 From: Stephan Wenger To: "Ali C. Begen (abegen)" , Henrik Lundin , Message-ID: Thread-Topic: [payload] Extended sequence numbers and video payloads In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D541013E04E@xmb-sjc-215.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 140.242.250.10 X-Authenticated-User: stewe@stewe.org Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 15:00:32 -0000 I think he's talking about the 16 bit sequence number field in the RTP header. Stephan On 10.12.2011 10:34 , "Ali C. Begen (abegen)" wrote: >Extended seqnum is something you report in RTCP, which has provisions for >it already. Or did I misread your question? > >-acbegen > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >>Behalf Of Henrik Lundin >> Sent: Wednesday, October 12, 2011 10:26 AM >> To: payload@ietf.org >> Subject: [payload] Extended sequence numbers and video payloads >> >> I'd like to get the payload list readers' opinions on the topic of >>extended sequence numbers. >> >> In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that >>"as a rule of thumb, it must not be possible to wrap the >> sequence number space in less than 2 minutes (TCP maximum segment >>lifetime)". If earlier wrapping can happen, one >> should provide an extended sequence number field. >> >> Some quick calculations reveal that at an MTU size of 1500 bytes, a >>video bitrate of approximately 6.5 Mbps is sufficient to >> produce 2^16 (jam-packed) packets in 2 minutes. >> >> It seems to me that the recently written RTP payload format for >>H.264/AVC and H.264/SVC does not mention sequence >> number extension (please, correct me if I'm wrong). Nor does the older >>H.263 RTP format mention this. >> >> What is your opinion on this matter? Should future video RTP formats >>follow what the HOWTO suggests, or stick to current >> practice as manifested in the H.264 formats? >> >> Thanks for your input, >> /Henrik >> >> -- >> Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 >>13 41 >> >> > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From yekuiw@qualcomm.com Wed Oct 12 10:14:26 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 E03E021F8CD9 for ; Wed, 12 Oct 2011 10:14:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74IzUB7ep7kL for ; Wed, 12 Oct 2011 10:14:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 9131221F8CD8 for ; Wed, 12 Oct 2011 10:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=yekuiw@qualcomm.com; q=dns/txt; s=qcdkim; t=1318439665; x=1349975665; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Wang,=20Ye-Kui"=20|To:=20S tephan=20Wenger=20,=20"payload@ietf.org" =20|Subject:=20RE:=20[payload]=20Extend ed=20sequence=20numbers=20and=20video=20payloads |Thread-Topic:=20[payload]=20Extended=20sequence=20number s=20and=20video=20payloads|Thread-Index:=20AQHMiOr3xPOrzM 13TkiZftxThUT53ZV5PgQA//+00mA=3D|Date:=20Wed,=2012=20Oct =202011=2017:14:16=20+0000|Message-ID:=20<8BA7D4CEACFFE04 BA2D902BF11719A830B7111C0@nasanexd02a.na.qualcomm.com> |References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20en -US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |x-originating-ip:=20[172.30.39.5]|Content-Type:=20multip art/alternative=3B=0D=0A=09boundary=3D"_000_8BA7D4CEACFFE 04BA2D902BF11719A830B7111C0nasanexd02anaqu_" |MIME-Version:=201.0; bh=dqjXqp0I7EvnnOIE55k0x07E9H/Eq67DxXPksepjCjA=; b=cEaZUMmwawDr84tvkNNN117N8XztsCtLiRyb2l17lEunMkcyNg2k0Ili hb8rmwn1T7+OW2DaAHpHjwqhP8oBBYPNSJQZ0DvFIQyBrtcDofO0Uxftk 3PLHNty+A/0H44Qwrg2agc2yoDYDonT20eXEy4yJYI9YBdUHnnaoEGZhc w=; X-IronPort-AV: E=McAfee;i="5400,1158,6496"; a="126934004" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 12 Oct 2011 10:14:22 -0700 X-IronPort-AV: E=Sophos;i="4.69,334,1315206000"; d="scan'208,217";a="156007811" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 12 Oct 2011 10:14:22 -0700 Received: from NASANEXHC12.na.qualcomm.com (172.30.48.1) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 12 Oct 2011 10:14:18 -0700 Received: from NASANEXD02A.na.qualcomm.com ([fe80::a931:9f39:19db:cdbf]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.01.0339.001; Wed, 12 Oct 2011 10:14:17 -0700 From: "Wang, Ye-Kui" To: Stephan Wenger , "payload@ietf.org" Thread-Topic: [payload] Extended sequence numbers and video payloads Thread-Index: AQHMiOr3xPOrzM13TkiZftxThUT53ZV5PgQA//+00mA= Date: Wed, 12 Oct 2011 17:14:16 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A830B7111C0@nasanexd02a.na.qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A830B7111C0nasanexd02anaqu_" MIME-Version: 1.0 Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 17:14:27 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A830B7111C0nasanexd02anaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Stephan Wenger Sent: Wednesday, October 12, 2011 7:43 AM To: payload@ietf.org Subject: Re: [payload] Extended sequence numbers and video payloads The motivation behind the two minute rule never compelled me. However, eve= n if it were deemed compelling by the folks here, the place to introduce lo= nger sequence numbers would IMO have to be a generic "high nitrate" extensi= on header, rather a payload format. Stephan From: Henrik Lundin > Date: Wed, 12 Oct 2011 16:26:10 +0200 To: > Subject: [payload] Extended sequence numbers and video payloads I'd like to get the payload list readers' opinions on the topic of extended= sequence numbers. In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a = rule of thumb, it must not be possible to wrap the sequence number space in= less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping c= an happen, one should provide an extended sequence number field. Some quick calculations reveal that at an MTU size of 1500 bytes, a video b= itrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed)= packets in 2 minutes. It seems to me that the recently written RTP payload format for H.264/AVC a= nd H.264/SVC does not mention sequence number extension (please, correct me= if I'm wrong). Nor does the older H.263 RTP format mention this. What is your opinion on this matter? Should future video RTP formats follow= what the HOWTO suggests, or stick to current practice as manifested in the= H.264 formats? Thanks for your input, /Henrik -- Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 _______________________________________________ payload mailing list payloa= d@ietf.org https://www.ietf.org/mailman/listinfo/p= ayload --_000_8BA7D4CEACFFE04BA2D902BF11719A830B7111C0nasanexd02anaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Stephan Wenger
Sent: Wednesday, October 12, 2011 7:43 AM
To: payload@ietf.org
Subject: Re: [payload] Extended sequence numbers and video payloads<= o:p>

 

The motivation behind the t= wo minute rule never compelled me.  However, even if it were deemed co= mpelling by the folks here, the place to introduce longer sequence numbers would IMO have to be a generic "high nitrate" extension = header, rather a payload format.

Stephan

 

 

From: Henrik Lundin <hlundin@google.com>
Date: Wed, 12 Oct 2011 16:26:10 +0200
To: <payload@ietf.org>=
Subject: [payload] Extended sequence numbers and video payloads=

 

I'd like to get the payload= list readers' opinions on the topic of extended sequence numbers.

 

In draft-ietf-payload-= rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb,&nb= sp;it must not be possible to wrap the sequence number space in less t= han 2 minutes (TCP maximum segment lifetime)". If earlier wrapping c= an happen, one should provide an extended sequence number field.=

 

Some quick calculations rev= eal that at an MTU size of 1500 bytes, a video bitrate of approxi= mately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes.

 

It seems to me that the rec= ently written RTP payload format for H.264/AVC and H.264/SVC does not menti= on sequence number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this.

 

What is your opinion on thi= s matter? Should future video RTP formats follow what the HOWTO suggests, o= r stick to current practice as manifested in the H.264 formats?<= /span>

 

Thanks for your input,=

/Henrik

 

-- <= /p>

Henrik Lundin | WebRTC Software Eng | hlundin@goog= le.com |&n= bsp;+46 70 646 13 41

 

___________________________= ____________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload

--_000_8BA7D4CEACFFE04BA2D902BF11719A830B7111C0nasanexd02anaqu_-- From stewe@stewe.org Wed Oct 12 12:02:35 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 BC2D521F84A4 for ; Wed, 12 Oct 2011 12:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19kOee2zjCRR for ; Wed, 12 Oct 2011 12:02:35 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5217A21F84A2 for ; Wed, 12 Oct 2011 12:02:33 -0700 (PDT) Received: from [10.99.231.143] (unverified [166.137.137.113]) by stewe.org (SurgeMail 3.9e) with ESMTP id 49006-1743317 for multiple; Wed, 12 Oct 2011 21:02:29 +0200 References: <8BA7D4CEACFFE04BA2D902BF11719A830B7111C0@nasanexd02a.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A830B7111C0@nasanexd02a.na.qualcomm.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-17-836528977 Message-Id: <16050313-B2CC-4B88-A6B7-1ED21E9BB10D@stewe.org> X-Mailer: iPhone Mail (8L1) From: Stephan Wenger Date: Wed, 12 Oct 2011 15:02:02 -0400 To: "Wang, Ye-Kui" X-Originating-IP: 166.137.137.113 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (166.137.137.113) was found in the spamhaus database. http://www.spamhaus.net Cc: "payload@ietf.org" Subject: Re: [payload] Extended sequence numbers and video payloads 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: Wed, 12 Oct 2011 19:02:35 -0000 --Apple-Mail-17-836528977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii s/nitrate/bitrate/ :-) S. Sent from my iPhone On Oct 12, 2011, at 13:14, "Wang, Ye-Kui" wrote: > +1 >=20 > =20 >=20 > BR, YK >=20 > =20 >=20 > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf= Of Stephan Wenger > Sent: Wednesday, October 12, 2011 7:43 AM > To: payload@ietf.org > Subject: Re: [payload] Extended sequence numbers and video payloads >=20 > =20 >=20 > The motivation behind the two minute rule never compelled me. However, ev= en if it were deemed compelling by the folks here, the place to introduce lo= nger sequence numbers would IMO have to be a generic "high nitrate" extensio= n header, rather a payload format. >=20 > Stephan >=20 > =20 >=20 > =20 >=20 > From: Henrik Lundin > Date: Wed, 12 Oct 2011 16:26:10 +0200 > To: > Subject: [payload] Extended sequence numbers and video payloads >=20 > =20 >=20 > I'd like to get the payload list readers' opinions on the topic of extende= d sequence numbers. >=20 > =20 >=20 > In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a= rule of thumb, it must not be possible to wrap the sequence number space in= less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping ca= n happen, one should provide an extended sequence number field. >=20 > =20 >=20 > Some quick calculations reveal that at an MTU size of 1500 bytes, a video b= itrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) p= ackets in 2 minutes. >=20 > =20 >=20 > It seems to me that the recently written RTP payload format for H.264/AVC a= nd H.264/SVC does not mention sequence number extension (please, correct me i= f I'm wrong). Nor does the older H.263 RTP format mention this. >=20 > =20 >=20 > What is your opinion on this matter? Should future video RTP formats follo= w what the HOWTO suggests, or stick to current practice as manifested in the= H.264 formats? >=20 > =20 >=20 > Thanks for your input, >=20 > /Henrik >=20 > =20 >=20 > --=20 >=20 > Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 4= 1 >=20 > =20 >=20 > _______________________________________________ payload mailing list paylo= ad@ietf.org https://www.ietf.org/mailman/listinfo/payload --Apple-Mail-17-836528977 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
s/nitrate/bitrate/ :-)
S.

Sent from my iPhone

On Oct 12, 2011, at 13:14, "Wang, Ye-Kui" <yekuiw@qualcomm.com> wrote:

+1

 

BR, YK

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Stephan Wenger
Sent: Wednesday, October 12, 2011 7:43 AM
To: payload@ietf.org
Subject: Re: [payload] Extended sequence numbers and video payloads

 

The motivation behind the two minute rule never compelled me.  However, even if it were deemed compelling by the folks here, the place to introduce longer sequence numbers would IMO have to be a generic "high nitrate" extension header, rather a payload format.

Stephan

 

 

From: Henrik Lundin <hlundin@google.com>
Date: Wed, 12 Oct 2011 16:26:10 +0200
To: <payload@ietf.org>
Subject: [payload] Extended sequence numbers and video payloads

 

I'd like to get the payload list readers' opinions on the topic of extended sequence numbers.

 

In draft-ietf-payload-rtp-howto-01, Section 5.1.6, it is stated that "as a rule of thumb, it must not be possible to wrap the sequence number space in less than 2 minutes (TCP maximum segment lifetime)". If earlier wrapping can happen, one should provide an extended sequence number field.

 

Some quick calculations reveal that at an MTU size of 1500 bytes, a video bitrate of approximately 6.5 Mbps is sufficient to produce 2^16 (jam-packed) packets in 2 minutes.

 

It seems to me that the recently written RTP payload format for H.264/AVC and H.264/SVC does not mention sequence number extension (please, correct me if I'm wrong). Nor does the older H.263 RTP format mention this.

 

What is your opinion on this matter? Should future video RTP formats follow what the HOWTO suggests, or stick to current practice as manifested in the H.264 formats?

 

Thanks for your input,

/Henrik

 

-- 

Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41

 

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

--Apple-Mail-17-836528977-- From magnus.westerlund@ericsson.com Sun Oct 16 23:52:05 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 3E58421F8672 for ; Sun, 16 Oct 2011 23:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZJLaOdxDYF7 for ; Sun, 16 Oct 2011 23:52:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0CB11E8082 for ; Sun, 16 Oct 2011 23:52:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-bc-4e9bd09131ab Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.52.13753.190DB9E4; Mon, 17 Oct 2011 08:52:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 17 Oct 2011 08:52:00 +0200 Message-ID: <4E9BD08E.5080400@ericsson.com> Date: Mon, 17 Oct 2011 08:51:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "payload@ietf.org" Subject: Re: [payload] Extended sequence numbers and video payloads 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, 17 Oct 2011 06:52:05 -0000 On 2011-10-12 16:43, Stephan Wenger wrote: > The motivation behind the two minute rule never compelled me. However, > even if it were deemed compelling by the folks here, the place to > introduce longer sequence numbers would IMO have to be a generic "high > nitrate" extension header, rather a payload format. > Stephan Probably not a bad suggestion. Still payload formats would need to indicate the need to support them and under which circumstances. We also have the question if that header extension then truly follows the rules for header extensions being possible to ignore. About the 2 minutes. That is picked based on the TCP Maximum Segment Lifetime, i.e. a time where any packet is guaranteed to have expired in. In almost all networks the real time until a packet will have expired is shorter. And lets say we do the calculation using 5 seconds, that is 24 times longer. Which then would cover around 150 Mbps of well packed video. Henrik is correct that at least H.264 should have modes with extended sequence numbers due to that it is possible to have bit-streams that surpass with certainty the rate of wrapping which is safe in RTP. However, the HOWTO is written after the H.264 payload format was written the first time. In fact quite a lot of the video discussion are based on that particular payload format. I guess Henrik's question are in relation to WP8. My counter question is what is the highest bit-rate it can produce? If it can produce in excess of 100 Mbps I think the extended sequence number needs to be seriously considered. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Mon Oct 17 08:18:22 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 327E421F8CBC; Mon, 17 Oct 2011 08:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=3.100, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTBrtq+Hko1z; Mon, 17 Oct 2011 08:18:21 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF9EA21F8CA5; Mon, 17 Oct 2011 08:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1105; q=dns/txt; s=iport; t=1318864701; x=1320074301; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=RKGKSS+XS7+7gXR+L7D5VnQugBAxjITf/JYz+rZ/h0M=; b=ThoHDBpwmlYcL4Mc9K991eO9gifc0YXx8SMWI2DeE2MG+oSqHkQUBF/7 gUaIsQEX8VmpmIbeGiJZ7gWBAhatX8Vu4NX6ZkINxPdqjGA7jJlBI39+s RUAZYk2A8QkFGNuqYe+knkDpE2vlsNCS4SwxfHekTmL8UT3tj1SuvUinc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBANdFnE6rRDoG/2dsb2JhbABDmUaPI4EFgW4BAQEEAQEBDwEdPhcEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdllzgBnlKHJ2EEiAKRKoxE X-IronPort-AV: E=Sophos;i="4.69,359,1315180800"; d="scan'208";a="8204703" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Oct 2011 15:17:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9HFHuv2028688; Mon, 17 Oct 2011 15:17:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 08:17:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 08:17:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt Thread-Index: AcyHrG6S77S8QfE9TqKIuf0qsa8OiwFKGlRQ References: From: "Ali C. Begen (abegen)" To: , , X-OriginalArrivalTime: 17 Oct 2011 15:17:56.0860 (UTC) FILETIME=[F2F463C0:01CC8CDF] Subject: Re: [payload] LC draft-ietf-fecframe-rtp-raptor-05.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: Mon, 17 Oct 2011 15:18:22 -0000 Minor comments: - The framework draft was published as RFC 6363, the citation should be = updated. - 2119 keywords should not be used in the intro section. Just make them = small letters. - Provide some example apps in the registration section (Applications = that use this media type: is empty) - Controller should be PAYLOAD WG not AVT.=20 - I-D.ietf-fecframe-sdp-elements is also RFC 6364 now. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Monday, October 10, 2011 4:03 PM > To: fecframe@ietf.org; payload@ietf.org > Subject: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt >=20 > Please read, review, comment - a comment of support is also helpful - > ASAP. This WG is very close to being finished and this is one of the > few last bits. >=20 > http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt >=20 > Thanks!, > Greg > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From wwwrun@rfc-editor.org Tue Oct 18 11:32:57 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 3F1B721F8C6C; Tue, 18 Oct 2011 11:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOsQ8JbbxGrm; Tue, 18 Oct 2011 11:32:56 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id C6A7D21F8C6B; Tue, 18 Oct 2011 11:32:56 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6D1E98C29E; Tue, 18 Oct 2011 11:32:56 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20111018183256.B6D1E98C29E@rfc-editor.org> Date: Tue, 18 Oct 2011 11:32:56 -0700 (PDT) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6416 on RTP Payload Format for MPEG-4 Audio/Visual Streams 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, 18 Oct 2011 18:32:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6416 Title: RTP Payload Format for MPEG-4 Audio/Visual Streams Author: M. Schmidt, F. de Bont, S. Doehla, J. Kim Status: Standards Track Stream: IETF Date: October 2011 Mailbox: malte.schmidt@dolby.com, frans.de.bont@philips.com, stefan.doehla@iis.fraunhofer.de, kjh1905m@naver.com Pages: 35 Characters: 77031 Obsoletes: RFC3016 I-D Tag: draft-ietf-payload-rfc3016bis-03.txt URL: http://www.rfc-editor.org/rfc/rfc6416.txt This document describes Real-time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. This document obsoletes RFC 3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision of RFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC 3016 is provided to update and complete the specification and to enable interoperable implementations. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From magnus.westerlund@ericsson.com Wed Oct 19 00:58:30 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 AE42421F8B84 for ; Wed, 19 Oct 2011 00:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0wAaXXjPw1l for ; Wed, 19 Oct 2011 00:58:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DED1C21F8B79 for ; Wed, 19 Oct 2011 00:58:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f8-4e9e8324cfbe Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 85.2E.20773.4238E9E4; Wed, 19 Oct 2011 09:58:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 09:58:28 +0200 Message-ID: <4E9E830F.9090607@ericsson.com> Date: Wed, 19 Oct 2011 09:58:07 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jonathan Lennox References: <4E8DB2E9.9040509@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "payload@ietf.org" Subject: Re: [payload] Question regarding SVC (RFC 6190) 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: Wed, 19 Oct 2011 07:58:30 -0000 On 2011-10-10 04:15, Jonathan Lennox wrote: > Hi, Magnus -- > > On Oct 6, 2011, at 9:53 AM, Magnus Westerlund wrote: > >> Hi, >> >> In my thinking of multi-stream handling I have considered SVC a >> bit. But I don't find anything in the RFC that specifies how a >> receiver actually determine in an MST usage the SSRCs in the >> various sessions that are actually caries NALUs associated with a >> particular source. > > [...] > >> Based on that the spec says that SSRC shall be assigned as RFC >> 3550 says, they don't carry the same value. > > > RFC 6190 doesn't explicitly say it, and I agree that's a flaw, but I > was certainly under the impression that for mutli-session MST, the > relevant part of 3550 was section 8.3: > > 8.3 Use with Layered Encodings > > For layered encodings transmitted on separate RTP sessions (see > Section 2.4), a single SSRC identifier space SHOULD be used across > the sessions of all layers and the core (base) layer SHOULD be used > for SSRC identifier allocation and collision resolution. When a > source discovers that it has collided, it transmits an RTCP BYE > packet on only the base layer but changes the SSRC identifier to the > new value in all layers. Well, this section says should, so it isn't required by the RTP base specification. Thus I do think it really should be explicit about the issue. In addition there are reasons to question this recommendation as it is potentially problematic. Maybe not seriously so in the case of scalable codecs. > > That said, I think there would definitely be value in a way to do > cross-session SSRC grouping, whether that's in RTCP or in SDP (or > both). Updated drafts will be available no later than Monday for our proposal in AVTEXT for this particular solution. A general discussion piece will show up in AVTCORE. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Thu Oct 20 00:34:24 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 8138A21F8B1D; Thu, 20 Oct 2011 00:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaUkXqzviVpz; Thu, 20 Oct 2011 00:34:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D05121F8B12; Thu, 20 Oct 2011 00:34:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111020073424.10168.47569.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2011 00:34:24 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rfc3189bis-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: Thu, 20 Oct 2011 07:34:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for DV (IEC 61834) Video Author(s) : Katsushi Kobayashi Kazuhiro Mishima Stephen L. Casner Carsten Bormann Filename : draft-ietf-payload-rfc3189bis-03.txt Pages : 20 Date : 2011-10-20 This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV&quo= t; into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-03.txt From kaz.mishima@gmail.com Thu Oct 20 00:55:02 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 564B921F8BA4; Thu, 20 Oct 2011 00:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MANGLED_GOOD=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s60vtc-QqVrZ; Thu, 20 Oct 2011 00:55:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68CE921F8BA0; Thu, 20 Oct 2011 00:55:01 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3021861ggn.31 for ; Thu, 20 Oct 2011 00:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5NiKXAnbS2IAkI2vEpyG0lJmeyn3UVTX8jhiB5ecvkA=; b=QSdO1iVqxtY2AVM0Rv0Z+yN81DZh3sjED+E+Md7XzX+haIQyJlNixk5Fslqm8zs6zc WI+/six9UX9kH1fW9Z8RfUnYFD9NPx+eJD9wLyFZyCKXMhDet5AoeQqBnpCJEZjuR+EF DxZ2FnesAOz2p1bs7r1JzWvZohYnGuB+QpfeQ= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr13888507yhm.74.1319097300950; Thu, 20 Oct 2011 00:55:00 -0700 (PDT) Sender: kaz.mishima@gmail.com Received: by 10.147.169.2 with HTTP; Thu, 20 Oct 2011 00:55:00 -0700 (PDT) In-Reply-To: <086901cc7c7d$8fa14990$aee3dcb0$%roni@huawei.com> References: <17D448F688A3446180420DCC3AE3F66A@china.huawei.com> <086901cc7c7d$8fa14990$aee3dcb0$%roni@huawei.com> Date: Thu, 20 Oct 2011 16:55:00 +0900 X-Google-Sender-Auth: YxHufTdzcXWmRXTXOa6l8PJufM0 Message-ID: From: Kazuhiro Mishima To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ikob@riken.jp, Stephen Casner , payload@ietf.org, ietf@ietf.org Subject: Re: [payload] [Payload] Last Call: (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard 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, 20 Oct 2011 07:55:02 -0000 Hi Qin, Roni, Thank you for comments. I've just updated our draft as draft-ietf-payload-rfc3189bis-03. See comments in-line please. > 1. Section 1: > > [Qin]: It looks this version extends RFC3189 to support some new features= . > However I can not see any dependency to RFC3189 in the introduction secti= on > until > I read the last section in this document, is it more straigtforward and > clear to merge the section 7,8 > to the introduction section and clarify how this document is different fr= om > RFC3189. > > Roni: This document does not extend but obsolete RFC3189, so it should no= t > reference it. As for the difference from RFC3189 I think it is better to > have a separate section. Now, I keep the section by Roni's comment. > 2. Section 3.1.1 > > [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is > covered by SMPTE 314M format. > However in section 3.1.2, the value for SMPTE 306M is still kept in the > encode list. So the question is > where do you remove SMPTE 306M in this document? Why SMPTE 306M in the me= dia > type registration is still kept? > Does this conflict with what you said in the section 7? > > Roni: Maybe change the first bullet of section 7 > > " Removed SMPTE 306M, since it is covered by SMPTE 314M format" > > To > > "support for SMPTE 306M is only for backward interoperability, since it i= s > covered by SMPTE 314M format" I changed the sentence in 1st bullet of sec.7. > 3. Section 3.1.1 > > =A0[Qin]: Is it real that there is no interoperability consideration sinc= e > Interoperability with Previous Implementations is discussed in the sectio= n 8 > of this document? > > Roni: Go od, add of this RFC I added the "Interoperability Consideration" which refers to sec.8. > 4. Section 3.2.1 > > [Qin]: I believe it is not appropriate to spell this note out when this > document is published but you may put > it as errata or in the section 7. > > Roni: good point. Maybe discuss it in section 8, since this may be an > interoperability issue This discussion moved to sec.8. > Also not that the syntax " < > span lan > 0pt;font-family:"Courier New"'>a=3Dfmtp: encode=3D encoding> audio=3D